All Posts in mobile

October 3, 2014 - Comments Off on Avoiding a Mobile House of Cards

Avoiding a Mobile House of Cards

netflix-kevin-spacey

"There’s no better way to overpower a trickle of doubt than with a flood of naked truth." -Francis Underwood

In 2010, Morgan Stanley Research extended their financial necks and predicted that the "mobile internet would overtake the desktop PC by 2014." I talked about the importance of that research the first time I spoke at the PRSA International conference about mobile in 2011. So, how accurate were they (and [arguably] even more importantly, how foolish might I look this year, if they were wrong)?

In January 2014, according to data from comScore, cited by research firm, Enders Analysis, mobile devices accounted for 55% of Internet usage in the United States. Traffic from PC's clocked in at 45%. A mobile strategy is no longer a "nice to have" luxury - it's the present and future of communications with regard to B2C and B2B communications. Companies and corporations that have yet to allocate resources for a mobile strategy, or have taken shortcuts with their mobile approach are building a house of cards – and it's about to take a tumble. Mobile has won.

The dictionary defines a "House of Cards" as a flimsy structure, arrangement, or situation that is in danger of collapsing or failing.

Your first consideration for expanding or enhancing any brand within the digital space begins with how the information will be received on a mobile device. While the near future will likely include universally acceptable, massive flatscreen entertainment portals with easy-to-use internet access, for the moment we’re talking about the now instead of the future now – while planning both responsively and reactively for the eventual.

Three Questions

There are three high-level questions to ask when building a strategy to avoid a house of cards. While these bullets may appear simple, the details are important. Building upon a structure of understanding carefully will elevate further insights and ultimately determine how well received your digital experience will be on all devices.

  • Who is the audience?
  • What do they want?
  • Where are they accessing content?

"After all, we are nothing more or less than what we choose to reveal." -Francis Underwood

Who is the audience?

Speak openly and honestly with your client about their audience. Conduct interviews with key stakeholders. Learn about your clients competitors and review the digital experiences they are likely to visit in tandem with your clients brand. Build exhaustive and clear user case studies to better understand gender, age and other criteria, to consider who will be accessing brand from a digital perspective. If the client has been online for some time, request access to a potentially vast treasure trove of information available from Google analytics to expose further details about the audience: specific times they are most likely accessing the site; what devices they are using. All of this information will allow you to prepare surmountable goals and clear the path for the measurable and appropriate design/UI decisions you will soon be making.

What do they want?

From a mile up, the client or a copywriting research team should be able to articulate what content best suits the audience. Aside from the standard questions that will help design a high-level content inventory plan, the importance of how vastly different mobile content is from the desktop is crucial and must be articulated to the client. To start with the obvious, the real estate you have to work with is different. Consider quantity and the breadth of content you should show to someone on a mobile device vs. a larger tablet or desktop device. Keep in mind, mobile users are on the go, and have a shortened attention span. Content should should always be readable, usable and most importantly – appropriate for the device.

To take a page from Apple’s iOS guidelines, "Text is legible, icons are precise and lucid, adornments are subtle and appropriate and a sharpened focus on functionality should motivate the design." For smartphones in particular, a single column layout is the easiest to absorb for mobile, and calls to action should should be represented by areas no smaller than 44px x 44px (here's a case where a "rule of thumb" is about your actual thumbs). Place important content above the "fold", or immediately viewable area on mobile – like contact info and important calls to action.

Where are they accessing content?

Business Intelligence gained through data collection is imperative. According to IBM, Five petabytes of data are generated every day by mobile phone subscribers. This is roughly the equivalent of 100 million four-drawer filing cabinets filled with paper. The means the data you need to best serve mobile content to your audience is out there.

Google Analytics (GA) data will help, as will statistical data, reports about your client's industry and the general mobile landscape, and interviews with key stakeholders and investors. Google Analytics reports will aid in understanding the devices and mobile operating systems currently accessing a digital experience, as well as the location that they are accessing the experience from. If your client is international, pay close attention to their specific carriers and regions. This is also important if your client is predominantly reaching a North America or United States-only market as well. There are still areas in this hyper-connected country where connectivity is spotty or slower than you might expect.

Your plan should be to create the fastest loading experience for your mobile audience as possible, regardless of the device. This can be accomplished in several ways, one of which is limiting or eliminating images that are unnecessary for the overall user experience. When using icons as calls to action, utilize a single image (usually referred to in the HTML development world as a "sprite") for multiple icons to create a single call to the server, cutting down on latency issues that slow down user experience. 60% of visitors on a mobile device wait 3 seconds or less for your page to load on mobile.

We no longer access the majority of our internet content from the desktop. According to a survey run by Google/Nielsen in Q4 of 2012, 77% of mobile searches were from a location (work or home) likely to have a desktop PC available. Stationary, plugged-in devices are not suitable for today's attention deficit disorder audience. We're easily distracted multi-taskers – always on the move – and as such – we want our content to join us on our journey. We desire access to data at our beck and call. Always consider how to deliver content to smartphones, phablets, tablets, wearables, and even ultra books - all devices that are in the mobile ecosystem and the inevitable future of the post desktop landscape.

"There are two kinds of pain. The sort of pain that makes you strong and useless pain, the sort of pain that’s only suffering. I have no patience for useless things." -Francis Underwood

Building a mobile strategy isn't easy. Mobile involves many moving parts, working with right digital partners, and the willingness to take risks based on the inevitable future. 40% of mobile users turn to a competitor’s site after a bad mobile experience, and this number is growing. It's especially difficult for large corporations to jump in full throttle – but they must. If not, they will likely perish under the waves of progress and watch helplessly as the mobile house of cards inevitably collapses around their valuable brand.

Published by: davefletcher in Entertainment, The Thinking Mechanism
Tags: ,

January 4, 2012 - Comments Off on Starting Mobile Web Development

Starting Mobile Web Development

We recently underwent the process of making our site mobile and tablet friendly. 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 a redirect is probably in order. 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.

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
  • Smashing Magazine Intro Tutorial
  • Less useful Adobe Tutorial but with great list of possible properties
  • ProtoFluid is a great way to test out your Media Queries. It essentially creates a iFrame of a given URL with dimensions specified by the chosen device. I found it to be a bit unstable and often designs look different on the actual device. There is also the lack of scroll/touch, the persistence of hover states and other Desktop-Device hybrid funniness but its great for checking your initial layout. BE SURE TO TEST ON DEVICES AS WELL!!! (Note: since Protofluid works via Desktop browser, make sure all your queries specify "width" and "device-width" as outlined above)
  • Hide address bar in iOS mobile Safari
  • Google+ plusone mobile button fix

Published by: benchirlin in The Programming Mechanism
Tags: , , , ,