itaysk

With SharePoint 2010, comes a new design concept for the site.. and with it some new design questions. The biggest one has to be – What’s with the ribbon??
I think that designers and web developers, which up until now were quite comfortable with designing master pages for SharePoint, are somewhat puzzled now with this thing in the middle of their page.

Should we ditch it? Can we? But we kind of need it, don’t we..? Is is the right place for it?
In this post I will try to provide some answers to some of these questions, and try and discuss the rational behind the look and behavior of the SharePoint Ribbon.

Forget about the ribbon for just a moment.
Every site has a banner, or a header, right? A cool picture banner or at least some kind of visual element at the top of the page that shows the name of the site, logo, and stuff. This is exactly what a SharePoint 2010 user sees when he enters the page – The “Browse” tab, that contains the site icon, name and navigation. The “Browse” tab is basically just like your good old banner or header.

 
A site with a banner

So we all agree about the browse tab. But what if we need some place to put some menus, buttons, and functionality elements. Where would we put them?
I would say that the top of the page is a good candidate. It’s convenient and centralized. But we already got the banner there.. wouldn’t it be too much to put both the page banner and a menu system like the ribbon on the top of the page? I think it would.

A site with both banner and ribbon

I say, if a user wants the ribbon, lets drop that banner, and put it the banner’s place. At this stage, the user wouldn’t be interested in the banner anyway, because he is now focused on editing rather then browsing the site.
Actually, That's exactly what’s happening when you click on one of the other tabs like “Home”. The banner goes away, and instead comes the menu with all of it’s glory. In other words, we are hiding the ribbon behind our page banner, and taking a peek at it when we need it.

The browse tab

Don’t think of the “Browse” tab as just another part of the menu, or another tab in the ribbon, because it’s not. It’s your site banner.
This perception is backed up by the implementation of the Master Page. If you take a look at the Master Page’s code, you see the ribbon apart from the Browse tab. Further more, the Browse tab is in fact part of the page’s body, where’s the ribbon is part of the page’s header.
If you wanted to hide the Ribbon, the Browse tab won’t go away, and if you scrolled the page, the browse tab scrolls with the page, where’s the ribbon doesn’t.
It now makes sense with the different roles that we gave to Browse tab and the Ribbon.

So, we are designing a page. How should we handle the ribbon?
If your design include some kind of page banner (or header), then integrate your banner into the browse tab. Here’s how to do that:
http://blogs.microsoft.co.il/blogs/itaysk/archive/2010/04/23/editing-the-ribbon-s-browse-tab.aspx

If you are working on a public facing internet site, you will probably want to hide the ribbon from regular anonymous users, but sill have it for content editors. Here are my thoughts on that: http://blogs.microsoft.co.il/blogs/itaysk/archive/2010/04/23/hiding-the-ribbon-for-anonymous-users.aspx

To conclude:
The Ribbon is a new concept, and therefore introduces some new design challenges. The Browse tab provides a way to keep the ribbon, without distorting the visual flow of the page, and without taking up too much screen space.
Take some time to think about what kind of site you are working on, and who is the site’s audience, and then use the tutorials I gave to implement your needs.

If you are designing a public facing internet site based on SharePoint 2010, you probably don’t want the ribbon in your design. Still, the ribbon provides the basic tools that your authors use, so you probably need a way to show it only to them.

I have tried so search for opinions and implementations for this on the web, and found several different approaches to complete this task.

Client side:

Pros: It’s easy to integrate into your site. Toggling visibility of the ribbon is super fast.

Cons: The entire control hierarchy is still loaded to the page, so it makes loading a bit slower.

Here is a video that shows you how you can check for anonymity, and hide the ribbon using java script:
http://www.youtube.com/watch?v=k5vg4DYUJNI

Server Side:

Pros: You have more control over what happens and when. Say, if you wanted to hide the ribbon based on a custom logic. Also, the Ribbon doesn’t render at all – faster loading times.

Cons: Harder to implement. Switching the ribbon on and off (if possible) is slow. Harder to implement. Requires admin and server access.

Here is a post that shows how to hide the ribbon by using SPSecurityTrimmedControl, which is a standard SharePoint control that gives control over content that needs to be security trimmed:
http://www.thesug.org/Blogs/kyles/Lists/Posts/ViewPost.aspx?ID=34&RootFolder=/Blogs/kyles/Lists/Posts

Another approach is to use LoginView, which is a standard ASP.net control:
http://vspug.com/benrobb/2008/06/20/howto-display-parts-of-a-page-to-anonymous-users-only/

Another server side approach, which to I haven't found references, might be to place the ribbon inside a EditModePanel control. In this approach, the ribbon will be shown only when the page is in edit mode. This approach is relevant only to publishing pages.

Login Control:

Regardless of the approach you choose, you should remember that the “Login” control is actually placed inside the ribbon, and so if we hide the ribbon, users won’t be able to log in.

The solution is easy, take the login control (it’s name is “wssuc:Welcome”) and move it from the ribbon to somewhere else on the page.

Since the Browse tab is pretty much the first thing you see on a SharePoint 2010 page, you will probably want to edit it.

Although it appears as a ribbon tab, it’s not. So you don't have to deal with features and custom actions in order to edit it. it’s much simpler:

Just open your master page. Find the div element who’s id is “s4-titlerow”. This is your Browse tab (You can clearly see that it’s not part of the ribbon, but part of the body of the document).

you can edit the inner content of the div as you want, but it’s recommended to leave the div itself intact since SharePoint’s new positioning and scrolling system is using these ids.

The most Common method to expose SharePoint to extranet, is to use Forms Based Authentication, with ASP.net SQL Membership Provider. This topic has been covered a lot on many different places.

The thing is, when you setup for this scenario, you end up with everything working, but nor GUI to manage users in the DB.

IIS 7 has built in management for ASP.net Providers such as Membership, Roles, and Profiles.
And it’s really helpful!

You can see the list of users, add and delete users, and perform basic actions on them.

Same goes to roles.

And you can assign users to Roles.

If you don’t need self management features, and only use admin management, this addition to IIS can save you a great deal of development.

Credit for this cool trick goes to Ziv Cohen (from BSP)who found and showed it to me.

If you want to limit the number of items in a repeating table, there no apparent way in the UI to do it. Here’s a quick way to do it without writing code.

1. On a form with a repeating table. Pay attention to the Group that the Repeating table is bound to.
   
2. Get the source files of the form. (in 2007: File –> Save as source files. in 2010: File->Publish->Export Source Files)
3. Close InfoPath.
4. Open the schema file. It’s the file with XSD extension.
5. Find the part representing the Group of the Repeating table (from step 1), and it’s sequence in it’s parent group.
   
6. The group should have an attribute called “maxOccurs”
7. This is what we’re looking for, set your limit here. (any number)
8. Open the modified form in InfoPath (the easiest way is right click on manifest.xsf and click “Design”)
9. Continue your editing… When you’re done just save the file as normal XSN, and you can dump the source files.

When you fill out the form, you won’t be able to fill more items then what you’ve specified in the schema file

This should work for browser forms too.