Earlier this year, I was lucky enough to meet Josh Clark at FOWD. I’d been reading his articles about flagship apps and content first, and I was very keen to have a chat with him about a discussion I’d had with a client. I had been discussing which platform they should be targeting, and depending upon who I was talking to at the client (and their opinions on the goals of the project) the decision on a choice of platform was different.
Josh, and his mobile vs native talk, positioned this decision as an “audience/content/budget” question, which matched the conversations I’d been having with my client. At the end of his talk I said to Josh, “this would make a great flow-chart, like that one that Jessica Hische did!”, “Yeah, that’d be awesome!”, said Josh.
I’m very pleased to say, that after some delay, it’s ready for public consumption.
It’s still a simplification of the whole process but, in researching it, three things became abundantly clear:
You must know your audience – there are no exceptions to this. People use different phones for very different things. Blackberries are used by teenagers for BBM and by corporations because of it’s security and low data usage; iPhones are very high-end consumer devices; and Android phones are thought of as being for very technically minded people, but they’re also entry-level smart phones. Picking a platform without knowing what your content and its audience is a recipe for disaster.
Your content needs to be simple to access – all end-points on the flow-chart will need some form of content platform behind them to drive engagement, re-use and to keep the app up-to-date. If you’ve got an old CMS, you may have to build a light-weight web service to let your app access the content easily, quickly and efficiently. People use apps to get at content, and whether they’re a game or social media, your content is king.
You cannot do this half-heartedly – and by that I mean you’ve got to have a decent budget. Also at FOWD, Matt Gifford was joking that the £50 website was now a £75 website; apps are suffering this problem. Apps are viewed as small, simple bits of functionality that you can knock-up in a weekend; this is simply not true. Apps are often full-sized websites with the added complexity of fitting the core content onto a tiny screen, but since they look small clients think they’re easy to make and do, and are therefore cheap. Stories in the news of 14-year-olds making games in the app store top 10 aren’t helping either. Start with a 5-figure sum, and keep going upwards if you want your app to really succeed.
I also mention PhoneGap a lot in the flow-chart, and that’d because I genuinely believe it’s a great solution to the “discoverability” problem. This is where you have a mobile web site that isn’t getting enough exposure as people think of “apps” as items in the “app store”. PhoneGap fills this hole nicely, and gives you access to device hardware as a brilliant bonus. The tools are easy to use and PhoneGap Build now takes all of the hard bits of building for Blackberry and Windows Phone away.
Still, there are gray areas in the platform selection process, especially when it comes to tight budgets and enterprise apps. If there’s only one thing you take away from this tool it should be this: Content is King, know your audience and how they will use your app. The rest flows from there.
Over the last few months I’ve been making a web site for my wedding. Emily (my fiancée) and I didn’t want your run-of-the-mill wedding website, hosted by someone on an unrecognisable domain (for example, ewedding.com or gettingmarried.co.uk sub-domains). I wanted something that I had control over, that I could make as the perfect website for us, not a nice template that thousands of others have. We wanted something personal.
Secondly, these pre-packaged themes aren’t suited to modern web standards. They just-about work on small screens, and quite a few of them use flash, or they take 5-10 seconds to load (lots of people, heavily shared servers, you do the math). Don’t get me started on the ones that play music in the background.
So I started with a solid foundation of responsive web design and HTML5. This is how I did it.
WordPress
I used wordpress because it’s easy to make great themes quickly. You’ve got full control of the output in a simple CMS. Job done, but for one thing: the default theme doesn’t use HTML5 semantics.
I took the WordPress html5 boilerplate from Jeffrey Sambells and used that as my base, giving me a good template for responsive web design.
320 and up
The choice of layout framework, 320 and up, comes from seeing Ethan Marcotte present at Future of Web Design, showing off the Boston.com re-design. I thought it was a wonderful talk and seeing how a site responds to screen size and context on such a high profile site made me rethink my views on responsive design. I used to think that for large, image-heavy sites, it just wasn’t economical to make a site work with media queries.
It’s a change in mind-set to design for mobile first. Thinking like that, instead of retrofitting a smaller design onto your UI, makes the whole proposition a lot more appealing. Andy Clark took this concept and made a framework out of it, and that is 320 and up.
320 and up works on the principle that you code a mobile site, and layer additional layout on top with media queries for each of the sizes you want to support. Coding this way also makes you very aware that the content is very much the purpose of the site, and that nothing should be left out, no matter what screen size you’re on.
Adding 320 and up to the HTML5 WordPress baseline wasn’t as easy as I’d have liked. No offence to Malarkey, but you don’t need all of the 320 framework to make a great site, so I cut a number of the hacks out and updated the respond.js library. Still, it solves many of the gotchas for you, so use it
320 and up has these screen size stops built in: 480, 768, 992, 1182, and a high-dpi option for retina displays . For my this site, I added in 768 and orientation: portrait to deal with iPad portrait mode problems. It’s up to you what stops you use, but these worked for me. If you want to support the galaxy tab and other screen sizes, more media queries are easy to add in.
The Design
There’s a lot of CSS3 that’s gone into this site. The background and header uses CSS3 multiple backgrounds to allow the layout to flex without the overhead of another div to layer the extra backgrounds on. Note, I did chicken out and add those extra divs in as it just didn’t look as good on IE7/8 and that’s what 30% of people are using on my this site.
The font choice was very important for me and Emily, and FontSquirrel came to the rescue. It’s got a great selection of script fonts that just aren’t available in the standard set that comes with computers these days. Text shadow adds to the effects but isn’t essential, so it doesn’t look out of place on IE.
My use of box shadow is basically in place of borders. It makes the whole theme pop off the page with slight shadows and a red tint that matches the theme really well. However, box shadow on the iPhone and small screen devices slows down scrolling, and should be used sparingly. Lovingly, responsive web design lets me turn it off for small screens
There’s lots of other little things, like using CSS3 selectors so that class names don’t have to be used all the time, and some nice stuff for the first letter, and also border radius (as standard).
Performance
The site uses appcache to speed up the site loading, and it makes a massive difference. The cache is around 1MB, that’s data I’ll never have to download again. It works on all of the latest browsers and mobiles (where is makes the most difference). I can’t recommend it enough.
For the useful information section, I used local storage to keep the different sections open/closed so that it’s the same when you come to the page next time.
Summary
In summary, this site has allowed me to showcase responsive design, mobile first, lots of CSS3 and make it work in IE7/8. Take a look at the source code, and learn. Oh, and wish us well on our wedding
I came up onto the District line platform at South Kensington station this morning just as a train pulled in. Normally, I would find my door (the one that opens straight onto the exit at Victoria) and jump in, but this time, whilst minding the gap, I brushed past a man trying to work on his laptop.
Seriously. A man trying to work on his laptop. Whilst stood up. On a busy rush-hour train in central London.
I was astonished at a few things:
the man’s ability to hold a 15″ old-school laptop on a moving train
his lack of forethought in trying to edit a private word document on a very public train
his inability to use something more appropriate
It’s this last thing that really gets to me. At my work, I’m trying to bring my clients to the modern world by freeing their data and mobilising their workforce. This man exemplifies why I’m trying to do these things. It’s simply not feasible to work on the move without a device built for mobility, and no, not even a Macbook Air would have been suitable for this kind of use. A 7 to 10 inch device would have worked, something that isn’t going to endanger the passengers stood next to you if the train brakes suddenly, something that won’t run out of battery before you get into the office. Yet, conversely, something that you can access everything you need at work from your device.
As the PunchCut blog said, “Mobile is not a device, it’s a lifestyle“. Bosses: embrace this. Let your employees use their own phones and tablets to access data. If you don’t let them, they will find a way around it because the busy people of this world simply can’t work the old way any more: there’s just too much to do.
This is the year that businesses should be unleashing their employees. Give them the freedom to work the way they want to (like working from home and flexi time have done) and they will pay dividends, simply by being happier. A happy employee is a productive employee, and when you let that happy employee out of the office, they will tell their friends and be happier still.
So don’t let your employees be the ones stood on the tube holding a laptop, be the ones leaning by the doors, smiling at their iPad.
A friend of mine recently bought a HTC HD2, the extra large touch screen Windows Mobile 6.5 phone. He loves it, it’s great for movies and the mobile web, thanks to Opera and other apps built in to the Sense UI.
A friend of his gave him a memory card with a load of programs on it. Whilst on the tube, my friend went through the list and selected a few to install, things like extra dictionaries, radios and the like. By the time he had reached his stop, he couldn’t make phone calls directly from the contacts list, and by the time he was at his front door, text in SMS messages was ten times larger than normal.
This is an issue for “open” operating systems, and especially true for constrained mobile OSs that rely on a small number of core classes. These can have fundamental settings overridden by apps which appear quite innocent at first, but have ramifications across the device if programmed improperly. That’s just the start; all sorts of things can go wrong including the potential for malicious apps to quietly access all of your data and e-mail it to anyone it wishes.
OS makers have now learnt their lessons, sandboxing apps and allowing for limited communication between services using registered links and restricted APIs. This ‘closed’ solution hasn’t limited developers as many expected, most have simply found ways around the solution, often coming up with innovative and novel methods, working with the strengths of the device instead of against each other.
My friend has learnt his lesson too. He’s reset the phone to factory settings and is building the application library up one at a time from trusted sources. He’ll know better next time.
