SharePoint and Your Mobile Strategy: Be Sure to Have One!

These days, if you have a site running in SharePoint the odds of someone coming to it with a mobile device are increasing extremely rapidly. This is certainly true if you have an Internet-facing site, but also highly likely even for corporate Intranets.

For this post, I’m going to pick on my friends at the Boston Area SharePoint Users Group (BASPUG) and then I’m going to help them fix the problem.

If you go to the home page for BASPUG on an iPhone (and probably any device that declares itself as a mobile one), you get a very basic WAP-like view from SharePoint 2010.

photo 3

And scrolling down to the bottom of the screen:

photo 2

This is nothing like the actual home page of the site, with its useful and interactive content:


Even if I scroll down to the bottom of the mobile view on my iPhone, I can’t switch to the full view of the site. In case you don’t know, the iPhone runs Safari, which is a fully functional browser. The screen is just smaller and you need to pinch and zoom a bit to view full-sized Web sites. So I’d actually rather switch to the full site so that I can read what I know is there, but I can’t.

So my point here isn’t that the mobile view in SharePoint 2010 sucks. Sure, it’s probably not what you want out of the box, but the engine is there and it’s fixable. My point is that you have to have a mobile *strategy* for your SharePoint installation.

In many cases, the best strategy will be to just turn it off. The mobile view above doesn’t enhance my experience, it ruins it. That’s not the starting point that you want to have for your users. IMHO, it’s better for them to have to navigate the full site in a cumbersome way than to not be able to read anything useful.

So be sure to have a strategy for mobile, even if it is to admit that you don’t have one. Put it into your deployment plans so that you don’t forget about it later. Revisit it when you have to or have the time to deal with it after launch. But *don’t* forget about it.

In looking around for how to turn the mobile view off in SharePoint 2010, it was no surprise that I came upon a blog post from my pal Randy Drisgill, SharePoint branding guru, which explained it: SP2010 Branding Tip #6 – Mobile Browsers. You can edit the compat.browse file in

C:\inetpub\wwwroot\wss\VirtualDirectories\[Your Web App Here]\App_Browsers\compat.browse

to change the settings for specific browsers. Read @drisgill‘s post for the details.


  1. Marc,

    I completely agree that turning it off should probably be the ‘default’ setting.
    Until I read your reference to Randy Drisgill’s post, I was hoping you would provide further guidance on this – especially from the MTDev point of view.
    What about using jQuery libraries (regular, UI, SPServices) for mobile users? How do we allow them to view an acceptable view – without the ‘bells and whistles’ that are adding functionality to a ‘desktop’ use but would certainly bloat mobile users’ connections?


    • Greg:

      The answer is, of course, as you probably guessed: It depends. ;+) The nice thing about *most* of the Middle Tier things you might be doing is that they ought to be portable to mobile devices. It all depends on what you are doing, of course. Navigational widgets that look and function great on full-sized screens may work and look horrible on small mobile screens. jQuery itself is highly cross-platform, but that doesn’t mean that what you choose to do with it will be.

      All of this needs to be a part of your mobile strategy: What similarities and differences do you want to be there for your users across the different access methods? As I say above, starting with the same experience is probably a good start, but you can use variations or handle the different device types in your code (not my first choice). There’s no single answer, nor is the right answer for you necessarily going to be simple or obtained by a simple settings change.


  2. Hi Marc,

    I agree that turning off mobile, especially for public facing sites is the right thing to do. Often that is your shop front and you want it to look its best.

    What we’re doing is using responsive web design through CSS media queries to set the user experience to the devices resolution.

    This can be hard for areas such as the calendar component but there are work arounds that can achieve great results. Best of all it doesn’t rely on flaky UA detection etc. So rather than worrying about the resolution you’re delivering content for the screen size. You then use progressive enhancement to build the experience for users so that visiually it scales based on browser capabilities.

    I think this needs to become the cornerstone of any modern mobile strategy for public facing sites.



  3. The mobile view for Publishing Sites is completely irrelevant. SharePoint is a platform and this is certainly something that if you wanted a true micro browser view of a SharePoint site you’d need to hand bake it. I like the WordPress mobile view of publishing sites personally on iPhone.

    • Jeremy:

      The more SharePoint 2010 public-facing sites I see with broken or unusable mobile views, the more I worry that SharePoint will once again take the bad rap for poor implementations.

      With my clients who use SharePoint as their internal platform, I’m seeing more and more iPhones, Blackberries, and even iPads used inside the firewall. You don’t want the first time you think about mobile to be when the EVP of something decides to show off their site on their iPad to a packed room.


  4. Yea, agree with you Marc, those mobile settings in compat.browse ‘should’ be configured for every public faced SP2010 site at least for the common devices, or at least is it a good idea to inform the customer about the possibilities for this settings. This will mean indirect requirements for the web standard, the site should then work ‘perfect’ in more kind of browsers than normal requirements for just computer based browsers.
    / Christian


Have a thought or opinion?