I get a lot of different SharePoint branding questions these days when I speak or work our booth at trade shows (like SPTechCon!), but one of the more popular questions has to do with SharePoint 2010 and mobile devices like the iPhone, iPad and Android.

SharePoint 2010 has a mobile view that displays by default for many devices, but it’s primarily focused on getting you access to the content of your SharePoint site without much consideration for the look and feel. It’s really better suited for an intranet environment and does a great job of making sure mobile devices can access SharePoint 2010.

When most people ask me about mobile devices, they are wondering about public-facing Internet sites or blogs that are accessed by anonymous visitors. Until recently I hadn’t looked into this problem too closely… but then one of my coworkers, Todd Klindt, was complaining about how Android and iPad visitors weren’t able to scroll on his blog. Maybe it was because of Todd’s booming voice and boyish good looks, or perhaps it was because he asked at just the right time (when I had a SP2010 virtual machine open), but I took some time to help him fix the issue, and I’ll share the results with you now.

The first thing you need to do is turn off the mobile view for the browsers that will show the full view of your website. This can be done by editing the compat.browser file on your Web server. The exact path to the file is dependent on the directory in which your Web files are stored, but an example path would be:


Then find the <browser> node for the particular device you are interested in and change the value of isMobileDevice to false. You can find more information here: http://technet.microsoft.com/en-us/library/ff393832.aspx.

With that change in place, your mobile devices should be showing the full Web view of your SharePoint site, but you will quickly see that long pages will not scroll properly on some devices. The big problem here is actually how the ribbon code for SharePoint 2010 is implemented. By default, SharePoint 2010 turns off the normal browser scrollbars and then adds them back in with JavaScript in order to ensure that the ribbon stays at the top of the page, no matter how long the page is. Unfortunately, many mobile browsers don’t have the same JavaScript support as desktop browsers, and the scrolling simply fails.

So how do we fix this problem? Turns out there are a few options:

Option 1: Turn off the ribbon for anonymous users
This method uses <Sharepoint:SPSecurityTrimmedControl> and <asp:LoginView> to remove the ribbon control for anonymous users as well as to change some of the CSS that is automatically applied. This is a simple solution, since most anonymous users have no reason to see or use the ribbon. One thing to consider, though, is that the login button will disappear, so you will need to add a login link for yourself, or remember the URL /_layouts/authenticate.aspx.

Option 2: Turn off the ribbon positioning code
This is perhaps the simplest solution, as all you are really doing is removing some code and overriding the body CSS to make sure SharePoint turns off the default ribbon positioning behavior. Once the code is in place, devices should be able to scroll fine, but for all users, the ribbon will now scroll away on really long pages. This is very easy, but if you do a lot of long page editing, it can be really frustrating to chase the ribbon up and down the page.

Option 3: Turn off the automatic ribbon positioning and replace it with CSS positioning
This is probably the most complicated solution in the bunch, but it is also the closest to out-of-the-box behavior. In this method, you actually override the default ribbon JavaScript with custom code that uses CSS instead of script to pin the ribbon to the top of the page. This is probably how Microsoft should have done it initially for simplicity (but I’m sure there were technical reasons why JavaScript was a more complete solution for them). Unfortunately, adding it in later involves overriding default behavior, which can be risky, so use this method at your own risk.

So at the end of the day, which solution is best for you? It all depends on how you plan to use the ribbon in your site. If no anonymous or mobile users need the ribbon, option 1 should be fine. If you don’t care if the ribbon scrolls off the page, option 2 will work. And lastly, if you want the closest to the out-of-the-box experience for the ribbon but still have mobile users that need access to it, option 3 is probably the most complete.

For Todd’s solution, option 1 was the simplest and best solution… and for the record, I made him make the changes himself (I like him, but not that much).

Randy Drisgill is a consultant at SharePoint911 and a Microsoft MVP in the technology.