SharePoint 2013: How to Hide the Ribbon Bar

Strangely enough, one of the first things that seems to be sacrificed in a branding engagement is the SharePoint Ribbon bar.  For some reason it’s just too “SharePointy” and ends up being one of the first things to go, especially for publishing sites and intranets (At some point I have to wonder if Microsoft will just give in and bake a ribbon hiding feature into the site settings?).

That being said, it’s one of those incredibly useful components for those of us who have to maintain and edit a site.

A couple of years ago I wrote about How to Hide the Ribbon from Anonymous Users and Users without Edit Privileges.   This approach is of course still valid for 2013, but there are of course more than one way to accomplish this.

With SharePoint 2013 we have HTML master pages that are converted to SharePoint master pages.  So one “correct” way to handle this is that we need to hide the ribbon bar from users of the site who don’t have the rights to manage the content on the site.

If you open your HTML masterpage and search for “SID:02” you’ll find the ribbon snippet that we are looking for.  This is the control that we want to be able to hide for the users who don’t have the correct permissions to modify our publishing site – which can be defined by the SharePoint security mask of “ManageWeb”.   Since only those users who have to modify the site will need to see the ribbon, we just need to wrap the ribbon snippet inside a SPSecurityTrimmedControl that has it’s permissions set to “ManageWeb”.

Anything controls that are placed within this snippet will then be displayed only to the users who match that particular security mask.

<!–MS:<SharePoint:SPSecurityTrimmedControl runat=”server” Permissions=”ManageWeb”>—>

{Your controls go here}


For me, I’m generally using the ManageWeb for the permissions since I’m hiding the ribbon bar for all users except people who are editing and creating content.  However, there is a whole set of SPBasePermissions that can be used when defining what sort of permissions you are wrapping your SPSecurityTrimmedControl around:

Member name Description
EmptyMask Has no permissions on the Web site. Not available through the user interface.
ViewListItems View items in lists, documents in document libraries, and view Web discussion comments.
AddListItems Add items to lists, add documents to document libraries, and add Web discussion comments.
EditListItems Edit items in lists, edit documents in document libraries, edit Web discussion comments in documents, and customize Web Part Pages in document libraries.
DeleteListItems Delete items from a list, documents from a document library, and Web discussion comments in documents.
ApproveItems Approve a minor version of a list item or document.
OpenItems View the source of documents with server-side file handlers.
ViewVersions View past versions of a list item or document.
DeleteVersions Delete past versions of a list item or document.
CancelCheckout Discard or check in a document which is checked out to another user.
ManagePersonalViews Create, change, and delete personal views of lists.
ManageLists Create and delete lists, add or remove columns in a list, and add or remove public views of a list.
ViewFormPages View forms, views, and application pages, and enumerate lists.
AnonymousSearchAccessList Make content of a list or document library retrieveable for anonymous users through SharePoint search. The list permissions in the site do not change.
Open Allow users to open a Web site, list, or folder to access items inside that container.
ViewPages View pages in a Web site.
AddAndCustomizePages Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a SharePoint Foundation–compatible editor.
ApplyThemeAndBorder Apply a theme or borders to the entire Web site.
ApplyStyleSheets Apply a style sheet (.css file) to the Web site.
ViewUsageData View reports on Web site usage.
CreateSSCSite Create a Web site using Self-Service Site Creation.
ManageSubwebs Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites.
CreateGroups Create a group of users that can be used anywhere within the site collection.
ManagePermissions Create and change permission levels on the Web site and assign permissions to users and groups.
BrowseDirectories Enumerate files and folders in a Web site using Microsoft Office SharePoint Designer 2007 and WebDAV interfaces.
BrowseUserInfo View information about users of the Web site.
AddDelPrivateWebParts Add or remove personal Web Parts on a Web Part Page.
UpdatePersonalWebParts Update Web Parts to display personalized information.
ManageWeb Grant the ability to perform all administration tasks for the Web site as well as manage content. Activate, deactivate, or edit properties of Web site scoped Features through the object model or through the user interface (UI). When granted on the root Web site of a site collection, activate, deactivate, or edit properties of site collection scoped Features through the object model. To browse to the Site Collection Features page and activate or deactivate site collection scoped Features through the UI, you must be a site collection administrator.
AnonymousSearchAccessWebLists Content of lists and document libraries in the Web site will be retrieveable for anonymous users through SharePoint search if the list or document library has AnonymousSearchAccessList set.
UseClientIntegration Use features that launch client applications; otherwise, users must work on documents locally and upload changes.
UseRemoteAPIs Use SOAP, WebDAV, or Microsoft Office SharePoint Designer 2007 interfaces to access the Web site.
ManageAlerts Manage alerts for all users of the Web site.
CreateAlerts Create e-mail alerts.
EditMyUserInfo Allows a user to change his or her user information, such as adding a picture.
EnumeratePermissions Enumerate permissions on the Web site, list, folder, document, or list item.
FullMask Has all permissions on the Web site. Not available through the user interface.

And now when the user accesses the page, unless their permissions match the ManageWeb permission mask they will no longer see the “SharePointy” ribbon bar or be able to access it’s functionality.



Visual Studio 2015: Change Default Location for Projects

This is just one of those little pet peeves I have regarding setting up development environments.  For some reason, the default location for your VS project files is under your user folder’s documents location.  Usually something like:

C:\users\{loginID}\documents\visual studio 2015\Projects

Which is of course a horrible place to put it for a number of various reasons.  If there is one thing I’ve really learned over the years it is that you don’t store work product on your system drive.  Always keep your system drive as clean as possible and your data and work product on a separate drive (This of course also makes it much easier when upgrading to a new OS or computer or figuring out what data needs to be backed up).

So one of the first things I do when I’m setting up a new development machine or VM is to configure my Visual Studio environment to use a different location for my files – usually on some data drive.

There are of course a ton of other options for Customizing Development Settings in Visual Studio.  If you haven’t looked at it in a while, I highly recommend reading through Microsoft’s page as you’ll see they’ve added a lot of nice-to-have features over the years.

Now, as for changing the default value of your project folder location, to access this dialog box, click Tools / Options expand Projects and Solutions, and click General.

From there you’ll see right there at the top “Projects location:”

And that’s where you can change it to a more appropriate path that is not actually on your system drive.

Projects location

Sets the default location where new projects and solution folders and directories are created. Several dialog boxes also use the location set in this option for folder starting points. For example, the Open Project dialog box uses this location for the My Projects shortcut.


There are a lot of other items in the Projects and Solutions, Options Dialog Box that you may want to also review – even if you’ve been using Visual Studio for years – because sometimes a few simple check marks in the right place can vastly improve your development experience.






Cringe Factor: When Designing You Need To Use Real Content

I got a design packet the other day that made me cringe.  It was full of that “LatinCryptic” placeholder text, you know the one I mean that starts of with “Lorem Ipsum” that Apple’s PageMaker has made so famous in today’s digital world.

It’s meant to be a placeholder that shows a general look and feel of the page without actually focusing on content.  When this used, it means the designers are focusing on only one possible use case.  It’s tough to break out of the box with these designs and often enough a design needs to be reworked either before or after the implementation.  When I see this sort of thing in my head I translate it as:

“Lorem Ipsum” == “I am too lazy to think up some real content that is relevant to this application”

Volume Should Match Design

Using this sort of placeholder doesn’t help communicate what sort of content we’re actually dealing with.  Is it a company article? A procedural manual? An event alert? Who knows?  Worse, what if the real content doesn’t fit within the actual design?  They’ve designed for 200 words of content and in reality there are 2000 words of content – now what?  Or what if the opposite is true? A design built for paragraphs of content when in reality only a sentence or two is needed.  What if the person writing the content starts trying to write according to how many paragraphs were in the original design?  Lengthy, wordy  and confusing content may end up in your final product simply because there was space for it.

Understanding the Context

Writing sample headlines, menus and micro copy that is specific to the application or business helps you nail the design and allows you to catch any misunderstandings with the design prototypes early in the process. Better to clear the air and catch miscommunication early in the project rather than after the design has been built out and you’re populating the website with content.

Support Real World Scenarios

One of my favorite parts of the design process is the pen and paper walk through.  Designers can create their own pictures and pixel perfect mockups, but there is just something magical about sitting down with a user and putting a pencil in their hands.  It’s awesome to see how empowered they become when they realize they’re allowed to mark up these beautiful pictures however they want.  If they don’t understand the context of what their looking at they can’t give you the feedback you need to give them the awesome user experience they want.

Don’t Become Another Visual Element

To use the often overused adage, “Content Is King.” When you use Lorem, you diminish the importance of the content to the same level as any other visual element – it ends up becoming a supporting role to your design.  Effectively, your content is enhancing your design rather than your design enhancing the meaning of your content.  Lorem is a work around that largely ignores the most important part of your site.

Ultimately your design is supposed to enhance your content and usability.  IF you have the most uber awesome site with all sorts of wiz-bang widgets and animations but your content is junk then nobody will use it.  If you build it does not mean they will come.




Sign In As A Different User In SharePoint

I’ve seen or searched for this about a million times so far, so why not write up a quick post about it…

With SharePoint 2013, a decision was made to remove the “Sign in as different user” option.  It was a weird decision to take that out and yet leave in the “Sign Out” option considering most people using SharePoint are in a corporate environment with access to Active Directory.

This creates a rather confusing situation for the user where they click the “Sign Out” button, close the browser and when they reopen the browser they are signed in again.  To the average end user it looks like they were never actually signed out and that the sign out button is useless.

For me as a developer, I absolutely loved the ability to sign out and sign back in as a different user because it allowed me to quickly switch between users as I was testing my site.  Luckily, while the option is now hidden from users, the functionality remains.

In order to sign out and sign in as a different user, all you need to do is use the close connection URL:


So if you want to quickly logout and log in as someone else, all you need to do is go to:


Since this link is so incredibly useful to me, I generally end up putting a link to it in my favorites bar when I’m working on testing the site, or even a temporary link in the masterpage for other testers to click on as the site is developed.



SharePoint Branding, Don’t Remove the Quick Launch

Last month I wrote about SharePoint Branding and made this point:

Maintain Functionality

This is especially important, and one of the reasons that creating a customized masterpage can be a little intimidating.  SharePoint is both and application and a platform and has a lot of baked in functionality and content that will need to be available for the site to function and grow properly.  And yes, the site will grow.  Remember that you are building out a framework for content.  While you may be able to create specific prototypes for specific use cases by hacking up a default masterpage, don’t forget that there are a number of sections that need to be included in order to have the entire SharePoint experience available once the site is live.

And this is especially important when working with designers who are more client focused than they are administrator focused.  When designers are working on use cases, they almost always focus on the client presentation layer and sometimes forget that there are several types of users for the system (Hence why I love personas and use cases that include ALL users).  One fairly common scenario I’ve seen is the following:

  • UI Designer delivers the design comps focusing on the “front door” – i.e. home page.
  • Home page comps don’t have the left navigation.
  • Left navigation is removed because it is not needed
  • Admin goes to add content to the site and…???
  • Left Navigation now becomes an important design element

SharePoint Quick Launch may be ugly, but it’s an integral part of how SharePoint functionality works.  If you remove it you end up affecting many of the components of the site like calendars, managed metadata navigation, blogs, etc.

When a design comp is created, often times there are elements of SharePoint functionality missing because it’s not needed for that page.  But that doesn’t mean the site overall won’t need access to that functional area in the future or in some other use case.  One of the biggest mistakes I’ve seen is to remove elements from the master page (or create a bunch of master pages for each use case) instead of just hiding these elements.

The best solution for this situation is to just add the Quick nav back to the masterpage and then hide it when you don’t need it or enable it when you do.

How To Hide Left Display Panel in SharePoint 2010 and 2007

SharePoint – How To Hide Recycle Bin & View All Site Content links in SharePoint 2010 and 2007