Mobile consultant and web evangelist Jonathan Stark answers your questions on the future of mobile development, PhoneGap, the offline app cache and more
@DVIMedia Have you any advice on selling change/progress without scaring the site owner? Jonathan Stark: This is a tough one. I think it’s a lot more effective to try to attract clients who already value what you offer than to attempt to convince, cajole, or otherwise 'educate' existing clients. Be awesome at what you do, shout about it from the rooftops, and eventually the clients you want will come knocking.
That said, mobile is white-hot and I’m seeing it become an inadvertent backdoor that can lead to big change. For example, the work we did on the mobile version of People.com was intended strictly for phones and small tablets. However, Josh Clark and Ethan Marcotte designed it to scale up beautifully on larger displays.
I imagine that the client will eventually ask themselves why they’re maintaining two different sites, and transition away from the legacy desktop site. Would People have approved a ground-up rewrite of their existing site? No way. But it’s there waiting for them if/when they are ready to make the leap.
Latest Videos From Creative Bloq
@deanleigh Will simply rearranging and showing/hiding be best practice in the future, or will server-side queries drive device-centric content? JS: I'm not sure I understand the question correctly but I think you're asking whether the 'responsiveness' of a web experience should be implemented on the client (for instance media queries or JavaScript), or on the server (UA sniffing or WURFL). In general, I recommend the client-side because it's more about feature detection than UA sniffing, which is a more future-friendly approach. From time to time, I have to do UA sniffing on the server, but I consider it a workaround that I only use as a last resort. You don't want to get yourself into a position where you have to update your site every time a new device or browser is released.
@alexjgarrett We’ve seen a massive change in the approach to mobile development recently, but what do you predict for the future? JS: More massive change. Platform and device diversity is going to continue to accelerate. The iPhone 5 – perhaps the most advanced piece of consumer electronics ever created – is going to look like a fax machine compared to what’s coming. Devices will get smaller, faster, and more specialised. Completely new input/output methods will emerge. Everything will be connected to the network.
Although it’s impossible to predict exactly what the future of development will look like, I think there are a few things that we can do to make our stuff more 'future friendly'. Here are two:
Think of your API as your app. The app that your users install on their smartphones is merely a client of your API. The API + client combination is not one big app – it’s two apps talking to each other. Your API is the true app.
Embrace a 'create once, publish everywhere' content model. You must not pollute your CMS with context-specific layout instructions. You can no longer know where your content is going to appear: maybe on a web page, in an SMS message, in a status update, on a car dashboard, in an ebook, and so on. In other words, if you're embedding RTF, HTML, or CSS in your content, you’re doing it wrong.
@mcneela86 I have had a lot of trouble getting the HTML5 manifest to work correctly – do you have an resources that could help? JS: My short answer is to keep it simple. My long answer is, read these posts:
Chrome also has an extremely helpful app cache inspection feature that not everyone is aware of. Load the following internal URL in Chrome to access it:
chrome://appcache-internals/
It is true that app cache can be frustrating to work with, but it opens up a whole new world to web developers. Before app cache, 'offline web app' was an oxymoron.
@agcolom Which mobile UI design principlesdo you follow and would recommend? JS: Great question – but probably too long an answer to post here. Fortunately, I covered it in detail previously in The 10 principles of mobile interface design.
@LiveDevelop With regards to the larger corporations out there, do you feel PhoneGap has a place out there? Or do you feel native is king? JS: PhoneGap absolutely has a place in the enterprise, particularly for B2E applications. People think I’m anti-native but I’m not – I’m against building only native. If you can afford to build a mobile web (or responsive web) experience and native apps for all your target platforms, then have at it! Unfortunately, most large organisations don’t have the expertise, time, or budget to do this. If you have to pick one, pick mobile web. Once you have mobile web, it’s a small jump to PhoneGap. The thing that organisations shouldn’t do is start with a native app. Remember: links don’t open apps, they open web pages. If sharing matters to your organisation, a solid mobile web experience is table-stakes.
@robtheshep Where should a relative novice start when trying to update an existing site to be mobile friendly? JS: This is a very tough question to answer without more info. My gut reaction is 'start from scratch', but I know that this is not often an option. It’s excruciatingly hard to use responsive web design techniques to make a big site small. It’s far easier to start small and work your way up.
@developer_sears Do you think HTML5 canvas development for mobile devices will continue to rise, especially in mobile game development? Great question. I assume the answer is yes, but I know very little about canvas or game development in general. I mostly work with large organisations in the retail, hospitality and publishing sectors, so canvas-style gaming is rarely of much interest.
@christianoliff There are a lot of different ways of serving images for HiDPi screens. Which do you think is best? JS: It's too soon to say. It really depends on your situation. Here are a few emerging techniques that show promise:
Try to replace UI images with CSS wherever you can
Use pixel density media queries to serve hi- and lo-res background images
Experiment with very low quality settings in your JPEGs
SVG might be worth looking into, but I’m told that your mileage may vary
Icon Fonts are another promising approach, but again, YMMV
