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.
I’ve got this great idea for an app…… what do you think?
I run the mobile development team at my employer, a role that I really enjoy and feel privileged to be doing. I get to work with cutting edge technology, forward-thinking clients and brilliant developers and user experience experts. There’s always a flip side, and for this role it is filtering out the bad ideas from the good ones.
The process
I have a simple process for capturing and evaluating ideas: listen, write it down and do a quick estimate of effort and benefits. If the benefits do not heavily outweigh the effort, say thank you and move on.
That’s it in a nutshell, but it’s a bit more complicated than that. Lets step through the process.
Ideas
An idea will come from one of two sources:
The media, or
A personal need
Ideas based in the media
The request goes a bit like this:
Hi Steve, have you seen this article about this cool iPhone/android app? Well, I think we could do something similar (for the other platform)! It’d be great for [publicity/marketing/a demo/this client I have/making lots of money]. What do you think?
If I get a request like this alarm bells start ringing in my head. Clearly, someone else has already done this, and therefore has 3-6 months development time ahead if we were to start developing a rival app. Requests based on the media tend to be for porting android apps to iOS, and unless it’s an android-only developer, there’s likely to be a good reason why there’s no iOS version. Take the BBC 3G strength meter app. It’s only on android and I was asked if we could do an iPhone version. The answer was simply “no”. The long answer was, “do you really think the BBC wouldn’t have tried to make an iOS version? Of course they would have. It’s not possible. iOS doesn’t allow you that level of access to the phone’s hardware.”
The only time that an idea from the media would meet the benefits/effort threshold is if there was a direct client opportunity and the idea came from demand, rather than porting an app. Augmented Reality was a big buzz topic a few years ago, but finding a useful application for it for a client was a challenge, hence I didn’t make an AR app.
So, unless there’s a direct need for an app, it’ll go into my big black book of ideas for a rainy day.
Ideas from personal need
The best ideas for apps come from genuine need. You can quote me on that. When someone comes up to me and says,
I’ve got this problem, I need to …… I thought it could work as an app?
I listen and I’m always much more hopeful. If someone has a need, then you can bet that other people have that need too. It may be something like large manuals or reference information for a specific sport e.g. SCUBA diving, or an app that collects a lot of information together and displays it usefully. These are the kinds of apps that I like people to talk to me about, and that straight away get to the top of the to-do list.
Which app to do first?
This is a tricky question, but it should be one that you can answer. Follow this formula:
Potential audience * USP / effort
Your potential audience, on a scale of 1-10 where 1 is “just you” and 10 is “every phone owner”
USP (Unique Selling Point) on a scale of 1-10 where 1 is “It’s a twitter app” and 10 is “best idea ever, never been done before, it’ll revolutionise the way we live”
Effort is a 1-10 scale of how long it’ll take you to make the USP work (1 is short time, 10 is long time). It is not how long until you can get a first release out, it is how much effort will it take to create the hook for users.
So, for a basic twitter app, you will end up with a formula of 8*1/4 = 2. For an app for flight controllers, you’d get 3*7/7 = 3, so you’d be better-off spending your time on the flight controllers app. Either way, they’re both not very high scores, so you may want to keep looking for better ideas.
Yes, I know it’s a contrived example, and that it won’t apply in every case, but give it a go if you are given a few ideas and don’t know which one to do.
What next?
Once you’ve got your good idea, don’t ignore any other ideas that come your way. Keep writing them down, keep doing the analysis, and you’ll always have an idea in your pocket to fall back upon. You may have so many good ideas that you’ll have to hire some more developers to work on more apps, and that is a very good problem to have.
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
