The idea of responsive Web design is that you create one website design, with one structure that will load a given Web page for any device. The Web page will respond automatically to the device at the client-side, adapting to the device’s width and rendering a semi-tailored interface for it.

Briefly, this is done through fluid grid technology, which sets the width of the Web page at percentages based on the width of the device display, rather than fixed widths. As the screen shrinks, the HTML and CSS will hide some elements the screen has no room for, or switch from a three-column format to two-column, or even perhaps change the navigation to make it more mobile friendly.

The term was coined around June 2010 (Ethan Marcotte on the website “A List Apart” has written extensively on the subject) and it has made its way into the SharePoint world last year.

Yet SharePoint presents certain challenges when it comes to deploying on mobile devices.

The good news is that not too many people have yet tried to deploy SharePoint onto mobile devices, according to Eric Overfield of PixelMill. Responsive Web design “is still really new in the SharePoint world. It’s kind of difficult because SharePoint wasn’t built around those principles,” he said.

In responsive Web design, the browser knows its own width (thanks to a property in CSS3 called media query) and loads what it’s told to load, based on that width. A quick problem for SharePoint right out of the chute is that IE8, Microsoft’s browser, doesn’t recognize CSS3.

But beyond that, there are other challenges.

First, in a responsive design world, the server does not care about what it’s sending to the device; the server sends the same files to every different device, and the device is given enough information to know how to render the page based on the device. (This, Overfield noted, points out a problem: This strategy requires every device to download all data and styling that it might not even need, and at a heavy cost to those using devices tied to limited data plans.) In the SharePoint world, you can use device channels coupled with responsive Web design to create a semi-custom experience for each device, he said, but he added that “it’s kind of tricky to do. SharePoint 2013 is supposed to help out with the image-loading a little bit, but I don’t have enough experience with it to tell you if that is or is not the case. My initial feeling is that it’s still going to take a lot of work, probably more work than people are going to want to put into it.”

To make SharePoint look good on devices of different widths, “The CSS is a little more challenging, the div structure takes a little more work,” said Overfield. “Now, instead of testing your work on Firefox; IE8, 9 and 10; Safari; and Chrome, you now need to worry about it across all different widths, so in a sense you’ve now doubled or tripled your testing time… It’s actually requiring a little more skill on the developer because they need to understand widths better, they need to understand CSS better, they need to build better HTML code.”

Even with that, though, an inherent flaw in SharePoint for mobile is that SharePoint, according to Overfield, “loves really wide tables. That’s a problem. How are you going to display a thousand-pixel-wide table that has been fixed for you by SharePoint in a browser width that’s only 320 pixels wide, say, on an iPhone. It’s a challenge, and I’ve yet to find a good solution for that. Without rewriting the entire code of SharePoint, you’re kind of stuck with wide lists every once in a while.”

And then there’s the issue of hover-over. SharePoint enables hover-over events, but some devices don’t have hover, so that bit of code would have to be rewritten, Overfield pointed out.

“You can use jQuery, you can use all kinds of things,” he continued. “Given enough money, you can do it, but it’s not as easy as one may have hoped.”

So what does it mean for Web designers? “Branding people are going to get pushed out because they’re going to need more experience with CSS, HTML5, JavaScript and jQuery,” Overfield said. “They’re going to have to be more programmers than designers. The graphic artist is going to be pushed out of this because it may be above their programming abilities, or they’re going to have to catch up. The coding structure requires more of a [computer science] background than a Photoshop/graphic design background. My designers who are more graphic artists are struggling to keep up, and I’m having to spend more time training them to build proper HTML and CSS because it’s a little more tricky; there’s a lot more going on.”

David Rubinstein is editor-in-chief of SD Times.