Gathering requirements for your ribbon needs

In the first post in this series, Boil it down to the basics… the SharePoint 2010 Ribbon, we looked at the different components in the ribbon area and saw what was really a part of the ribbon and what wasn’t. At the end of the post you may have ended up with a custom master page with a simplified ribbon block and SharePoint page components, such as the Site Actions menu and the social tagging buttons, moved to other locations in your site layout and design. In the second post of this series I am going to focus on ribbon placement requirements and more importantly, what do your users need.

When we looked at getting page components separated out from the Ribbon show/hide toggle it was because of well established usability patterns. Now that is done, what to do with the ribbon? What are the usability patterns for that? I wish I had a simple and straightforward answer for you, but like with many things it starts with end user and site requirements. Now I know I just jumped from usability patterns to requirements but I think they are tied together.

  1. Who are your content editors?
    This is the most important question of all. Who is editing your SharePoint content and what is their average skill set? Let’s look at some common scenarios:

    • A savvy web team that knows HTML and is comfortable with all things computers
    • Technology minded people who know how to use Word, Excel and similar applications
    • Folks who know their way around a keyboard but their job includes other aspects that doesn’t require knowing Office applications inside and out
    • Individuals who are timid around new technologies, processes and tools
    • A mix of some or all of these different user groups
  2. How many content editors do you have?
    A handful? 10-20? Over 50? The number of editors is another important item to consider. Dealing with a few people who are nervous with change vs. a 100 will definitely affect your content editor training and support plans. And it doesn’t just matter in regards to people new to technology… if too many hot shots have access to edit a site you can end up with a real nightmare on your hands. People who know how to manipulate HTML will have more confidence to start tweaking pages and can create a lack of consistency in content organization and presentation.
  3. What is the content?
    Is your SharePoint site mainly lists and libraries? Publishing pages? Complex dashboards using Data View Web Parts? SharePoint is a powerful tool and users will handle the various features and functionality based on their skill set. A techno-savvy content editor who is a whiz at Office may do great with editing publishing pages but be scared off by making changes to a dashboard. Someone who is busy doing 25 different things at their job may learn how to use a list or library but grow frustrated when asked to edit a publishing page because things are slightly different and beyond what they learned to support this one aspect of their job.
  4. How often will the content change?
    This is really key. Are your content editors looking at making changes daily, weekly, monthly, quarterly, or yearly? I like to consider myself pretty computer savvy but if you hand me an application to use only once every few months, I am going to spend a few minutes staring at it trying to remember how to do anything!

I bring this up because usability patterns for the web are easy to identify… we are all web site users. Usability patterns for Office apps can be picked out… heck analysis of that is what drove the organization of the ribbon. But what about usability patterns for SharePoint? That is a lot tougher to pin down. The content needs change from organization to organization. People use sites differently based on the content within. You are the best person to identify usability patterns for your organization and SharePoint sites. I can’t tell you what they are; I don’t interact with your site and data.

Once you have figured out these starting points for your requirements, you can look at ribbon placement and treatment options and determine what would be best for your users. Your ribbon requirements may reflect one or more of the following:

  • What is all the hub but about!  Leave the ribbon as is.
  • Keep the ribbon but shift it closer to the content, leaving the site wrapper (header, nav, logo, etc) outside of the ribbon so that is what people see first.
  • Keep the ribbon but get rid of the navy bar at the top of every screen.
  • Hide the ribbon from people without access to edit pages and/or list content.
  • Hide the ribbon from people with access to edit pages and/or list content until they decide to edit that content.
  • Let the users decide when to toggle the ribbon on or off.
  • Get rid of the ribbon.  Period.

There is more to this than just users.  What about custom branding?  Do you have specific ribbon requirements based on a site design you need to implement? Do you need to brand the ribbon or change up anything about the presentation?

Something I always tell my students starts with one of my favorite quotes from Dustin Miller, “We don’t like the term Best Practices because what is best for us may suck for you.”  I am not going to tell you what I think you should do based off my experiences with my content, but what I can do is tell you about some options.  So sort out your requirements FIRST and then come back check out how you can best meet those requirements using available ribbon placement and treatment options.

Up next, the docked ribbon.