TIPS FOR A HEALTHY WEEKEND, WHEN YOU JUST FEEL LIKE SLEEPING

We recently underwent the process of making our site mobile and tablet friendly. The next phase in growing our business and making it much more accessible is definitely to branch out and use services of qualified companies like Vecro Tech for our application making it easily accessible on android, windows, and ios operating systems. The results look fantastic but our implementation has, in places, been a bit cumbersome since the original site was not laid out with such an adaptation in mind. Now that we're more or less done I felt it would be pertinent to create a list or useful resources found and lessons learned along the way. Since this entire branch of web development is still so young and liquid I don't know how long the following will be useful but I hope it helps those as lost as I was when we began this trek.

Adapt or Leave?

One of the biggest questions when faced with the prospect of creating a mobile site is "Should my site adapt or redirect?" Unfortunately I don't believe there is one right answer to such a question since, like so much in life, it depends!

Some key factors that might affect our decision include the functionality we want, type of content we mean to serve and look/feel of our design. Is it important that our mobile version have stunningly different design and/or app-like animation effects? Then we probably need to hire a landing page expert. Are we mainly trying to provide a mobile version of a news, blog or other site where content is the focus? Then a media query adaptation would be beneficial as we make it easier for users to share content between devices (and keep all that traffic in one place to boot). However both options can be adapted either way if we put in enough work.

Let's not forget the last option: making a web app. Using services like PhoneGap we can take a our HTML and make it into a bonafide app on the user's device...well it's really just a virtualized webpage with greater device integration (accelerometer, media, camera, etc.)  and a dedicated icon on the device but sometimes that can be a great branding edge. And there's the added bonus that users can then use our "site" even when not connected to the internet though the line between website and app begins to blur at this point. A direct migration of your website to an app will probably never clear the iTunes store's strict approval process so we need to add something unique which may  be more trouble than its worth.

Let Me Pose You a Query Sir

Media Queries: confusing, under-documented, cutting-edge, useful as all hell and bloody confusing! It took me awhile to get my head around these little statements of goodness. Once I did I came to understand their power and structure. We have two main options when dealing with media queries; we can use them to specify certain CSS links or alternatively we can write them into an existing CSS file. Personally I used a mix. It made sense to use the internal CSS version when altering this blog's WordPress theme while on the other hand the link option made sense for most other pages. In general I'd  recommend the linking option since it keeps each CSS shorter, allows for easier document navigation and generally keeps our process cleaner.

It's easiest to think of media queries as giant "If" statements that inject our extra CSS when our given properties are met. As such, we must remember to override existing styles in order to apply our new device-friendly ones. It can be tedious searching through our original CSS file to see which specific properties need to be overwritten. I found it easiest to simply copy the entire original CSS, do all changes as required and then go through and delete any definitions or properties that remained constant (I sniff an extremely useful code highlighting/SVN tool that could do this comparison automatically along the liens of CSSlint).

Another nice benefit of media queries is the ease of testing and updating them. During the development process, make sure to specify "max/min-width/height" AND "max/min-device-width/height." This will ensure that our queries appear not only devices with the specified resolution but also any similar window viewport allowing us to use Firebug/Chrome Inspector as we normally do for a familiar debug cycle as well as useful previewing tools like Protofluid. Just remember that once the site is live, we should only target devices if we don't want adaptive versions appearing on desktop browser windows of the required size as was our case since the mobile versions or so device specific.

Quite Novel

Don't forget this is a completely new ballgame. Using media queries, especially with mobile devices, we can add all sorts of fun and/or hidden functionality into a site. How about a site that literally changes personality the smaller the window? Maybe you have a logo or character that actually reacts to the changing amount of space they're given as elements shift about them? And don't be afraid to think even more radically. The very function of a page could alter depending on a devices orientation. We could have our copy appear in portrait and then an image gallery appear in landscape (as is the case for our iPad site). Such novel use of media queries can completely redefine how people interact with a site and help redraw the front lines of the ongoing war between app and webpage.

No touchy

Of course not all the changes that come out of these new device are solely good. In fact the biggest one requires a fundamental change in how we think about design and interaction: touch. No cursor means no hover. Truly though, hover is simply an artifact of the invention of the mouse, itself not very old and clearly diminishing in importance. There's now a new frontier of interaction and design patterns to be explored.

Here though, the waters are still quite murky. Some plugins, like this jQTouch one, allow a webpage to respond to touch-specific events that most browsers and libraries don't yet natively handle. Of course this comes with the down side that we also lose our native touch-to-scroll ability (though theoretically we could reconstitute this functionality by hand or via work-arounds). For sites designed specifically for small screen devices this opens up many new possibilities that before only existed natively in apps and not on the browser.

Real Estate

One clear limitation we have on mobile devices is the lack of real estate. Design is all about creating something to fit within certain restrictions which are quite tight in this case. However good design often comes out of such challenges so the news isn't all bad. Sadly problems arise since lack of space also reduces our margin of error. When designing a website for the browser, we can safely assume that most screens will fit a design of a specific minimum height and width with room to spare or allow the user to easily scroll about the page to see everything. You can read the Space Selectors blog for more information (https://spaceselectors.com/blog/).

Alas the fragmented nature of the mobile market, even if we disregard tablets, poses greater challenges since different devices not only have a wide range of sizes and screen ratios but also numerous different abilities and native elements. As such we must be dead certain that our site is adaptive to many heights, widths and especially devices. Yet by in large the best mobile sites are designed to fill the screen perfectly so making adaptive designs can be difficult to impossible. Perhaps this is where "good enough" is fine since the prospect of specifying designs for each resolution is daunting to say the least. Furthermore, we can try and maximize our real estate by hiding browser elements when possible. For instance many mobile sites "hide" the address bar on mobile Safari by programmatically scrolling the page down by the bar's height giving us more space above the fold.

If It Ain't Fixed

We've grown used to a lot of functionality on the web but many of these norms may not have been carried over to the mobile world, at least not yet. Some APIs may not yet have native support for our platform of choice but we can, on occasion, find workarounds like this one for the Google plusone button. However, sooner or later we have to simply cut functionality from our mobile site and sometimes this may be for the best considering the restrictions and problems discussed so far. So if you're wasting time trying to get a certain resource to function on your mobile site when you could be perfecting the design itself or, better yet, device testing, consider simply hiding that element or simplifying the functionality. After all, even if you get it to work it's only a matter of time until official support rolls out and your work's left out in the cold.

References