Links to Additional Views Disappear in SharePoint 2013 When OOTB Style is Applied

Here’s some magic for you. If you add an out of the box style to a view of an App (list or library) the links to the views disappear. We are not talking custom code here. We’re talking about selecting a view style from the Style drop-down.

Surprise!

View with no Style added.

View Links

Add Style.

Add Style

Select Style

Links to additional views are missing.
Style is applied, but your links to additional views have disappeared.

Links to additional views missing.

You can still get to the additional views by clicking on the List or Library tab, and clicking the drop-down for Current View:

Current View drop-down

This is NOT the type of behavior I expected. How about you?

Please comment if you see different behavior in your uncustomized environment.


Keep Track of SharePoint Permissions without a Third Party Tool

It’s not very high tech, but it works. Create a spreadsheet with tabs for your SharePoint Groups/Sites Matrix and each permission level used on the site. You may need to expand the SharePoint Groups/Sites Matrix to include lists and libraries that are uniquely secured.

Here is an example of one I’ve used.

PermissionsMatrix

View and download a copy of the spreadsheet here.


5 Steps to Manage Scope Creep in Projects, especially SharePoint Projects

While defining requirements for any project, you will run into scope creep. You get talked into adding little bits of functionality because “It shouldn’t take anytime.” Then you end up with an additional 900 requirements that “shouldn’t take anytime.” This happens A LOT in SharePoint projects, because SharePoint is so easy (according to some). If you don’t get a grip on this early in the process, you will run into this….

SCOPE

You are hired to build this within a specific timeline and budget

SCOPE CREEP

While defining requirements, the project morphs into this, but has the same timeline and budget

SCOPE SPRAWL

As you build, the requirements keep rolling in. Now people want this within the same timeline and budget

Here are 5 steps to manage scope creep before it becomes scope sprawl…

1.  Figure out what you want to accomplish

  • Clearly define what you want to see at the end of the project
  • If you want to save time or money, figure out how much time and money you are spending now
  • How much do you want to save? Pick a number or percentage. Example: We want to save 30 minutes per transaction. We want to reduce repair costs by 3%.
  • If this is a new process or solution, figure out what the CEO wants to see
  • All requirements need to map back to these decisions

2.  Rate requirements

  • All requirements should map back to what you want to see at the end of the project
  • Rate requirements on three things:
  1. Relevance to project end state – Is this requirement needed to reach the end state? Would this requirement make the end state better? Would this requirement make the end state perfect?
  2. Effort – How much time and money with this take? Which resources do we need to complete this requirement?
  3. Other Systems – Will meeting this requirement make changes to systems not currently involved in the project? The more systems we touch the more challenging it will be to meet the requirement. Was changing these systems part of the original scope?

3.  Next Version

  • If a requirement is not integral to the end state, the effort would be too great, or would touch too many systems, consider making it part of the next version or update to the end state

4.  Sign Off

  • Get sign off from the sponsor before the build. Very surprised at how often this doesn’t happen in SharePoint projects
  • Understand that even though you have sign off, there will be changes

5. Share

  • When there are changes requested, share with the rest of the team
  • Run the request by the sponsor after clearly defining relevance, effort and effect on other systems

What steps do you use to manage scope creep? Add them to the comments below.


Peek a Boo Where is My View in SharePoint 2013

It should come as no surprise to anyone that how we switch views in SharePoint 2013 lists and libraries has changes.

To make it easier to spot the differences between 2010 and 2013 let’s do a side by side comparison.

2013

2010

Document Library
In 2013 the Add New Document option is at the top of the library. In 2010 the link is at the bottom.

What to click on to change views
The Library tab is available in both 2013 and 2010.
Notice in 2013 all views are listed. In 2010 you need the dropdown in the breadcrumb

Make the View Menu appear
In 2013 click the ellipse. In 2010 click the dropdown in the breadcrumb.

View Menu from Library tab
Icons in 2013 look cleaner, but basically remained the same.

With another web part on the page
In both 2013 and 2010 adding another web part to the page makes the Ribbon disappear.
Users must select the web part they want to work with before the contextual Ribbon re-appears.
In 2013 the views remain listed. In 2010 the dropdown in the breadcrumb disappears.

Please let me know if I should add something to this side by side comparison for Views.


Your SharePoint User Is Not Stupid

That’s right!

Your user isn’t stupid; SharePoint is stupid.

There I’ve said it.

Let the skies open up and lightning strike me dead.

  • SharePoint is a tool.
  • Tools don’t do anything. They are stupid.
  • People use tools to build things.
    • The tool appears brilliant, but really it’s the builder, or the business analyst, or that team that knows the process/issue.
  • Teach people to use what was built.
    • Remember how intimidating and exciting it was to drive a car or ride a bike for the first time?
    • Did you try to do it on your own the first time?
    • Did you have help?

If you don’t teach your user how to use what was built, you will need to point that stupid finger at yourself, not your user.

You were hired for your job, solving issues with SharePoint (if you are lucky). The sales team you are building a solution for was hired for sales jobs. They are not stupid because they don’t know SharePoint. You are not stupid because you don’t know sales. SharePoint isn’t stupid because tools can’t be stupid they are inanimate (unless you have enchanted tools).

Consider this the next time you want to call a user stupid because they don’t know SharePoint.