Mobile – Quoderat

It’s never the end of history

David Megginson — Sat, 23 Aug 2014 16:46:48 +0000

Link: http://alistapart.com/article/fluidgrids/

Ten years ago, circa 2004, it felt like the web had found its rut and would never get out: XML and XHTML had failed to fix the browser-incompatibility mess, the horrid Internet Explorer had achieved almost total browser-market dominance, and web designers were focussing on animated pre-rolls and big screens. Even in 2009, when the rise of mobile was impossible to ignore, Ethan Marcotte still sounded like an Isaiah shouting from the wilderness when he pleaded with us to think differently:

Instead of exploring the benefits of flexible web design, we rely on a little white lie: “minimum screen resolution.” These three words contain a powerful magic, under the cover of which we churn out fixed-width layout after fixed-width layout, perhaps revisiting a design every few years to “bump up” the width once it’s judged safe enough to do so. “Minimum screen resolution” lets us design for a contrived subset of users who see our design as god and Photoshop intended.

It turns out that we weren’t at the end of web history, but just finishing the first act. After a decade-long intermission of stagnation, things started changing even faster than they had in the optimistic early days of the mid 1990s. IE has become so irrelevant that it’s barely necessary to test against it any more (unless your audience is big industry or government office workers using obsolescent desktop computers), HTML5 and CSS3 have exploded, the Javascript ecosystem has matured, the majority of page views happen on small-screen mobile devices, and those devices ensure that most users always have the latest version of their browsers (a vain hope in 2004 or 2009).

Five years after Marcotte’s article, any so-called web designer proposing to work with a fixed “minimum screen resolution” would … and should … be fired.

Except maybe in government and big industry.

Mobile web app or web site?

David Megginson — Mon, 17 Mar 2014 14:15:46 +0000

If you’re creating an HTML5 mobile web application, this is the minimum you need to give your users what Google calls a “homescreen launch experience” on an iOS or Android mobile device:



 
  Awesome app

The “shortcut icon” link element is pretty straight-forward: it simply provides a pretty, app-style icon to save to the iOS homescreen or Android launcher. The “mobile-web-app-capable” meta element, on the other hand, strikes right to the core of what you’re doing: are you creating a web app, or a web site?

I’m a web app

Here’s what Chrome for Android gives me if I save a web app to the homescreen (launcher), then tap on that icon:

The app gets its own entry in the task switcher.
All the browser chrome is hidden, and there’s no way to add a new tab, create a bookmark, change options, etc.
If the user chooses a link outside my domain, Chrome will animate a normal browser launching, to warn me that I’m outside the app.

I’m a web site

If I don’t include “mobile-web-app-capable,” then Chrome for Android will still let me create an icon on the homescreen, but when I tap on it, I’ll see my regular browser launch, with all its chrome, tabs, bookmarking, etc.

So which am I?

A web app is a loner. It has several advantages over a native mobile app (cross-OS/-device compatibility, avoiding app-store bottlenecks and censorship, more-flexible security model, linkable, etc.) and several disadvantages (can’t handle an Android Intent, weaker notification support), but its plan is clearly to stand on its own, like a native mobile app. A web app is designed around actions: with a clever combination of HTML5, CSS, JavaScript, and newer stuff like AppCache and LocalStore, you could create (e.g.) a Twitter web app that was very similar to the Twitter native app (important caveats). The web app designer doesn’t want her app open in one browser tab with a different site open in another, while the user switches back and forth. Online video games, interactive edit/design tools, and anything that is supposed to feel a bit like a MacOS or Windows program installed from a CD-ROM 15 years ago is likely an app.

A web site is a social creature. It’s orthogonal to a native mobile app, because it inhabits a different universe. A web site is RESTful, designed around pages (more generally, “resources”), most of which contain either information a user wants to see with links for navigating to related information, or a means to create/change/delete that information (there’s also typically a search feature). Unlike web apps, web sites embrace the browser chrome, which provides an important part of the user experience: because the browser allows a user to search for text within a page or bookmark any page, the web site itself doesn’t have to provide that support; similarly, the browser lets a user open multiple views into the same site using different tabs by default (so that a user can view two pages at the same time), while an app treated as an app has to have that support built in. Wikipedia, blogs, tutorials, newspapers and magazines, most online discussion forums, and my own OurAirports are all examples of things that are most naturally web sites.

Last thoughts

I’m starting the process of making OurAirports responsive and otherwise mobile-friendly, and one of the first things I tried was adding “mobile-web-app-capable” and then saving the icon to my Android desktop. It worked exactly as advertised — it was cool having the site open up as if it were a phone app, appear in the task switcher, etc., but it took me only minutes to realise that I’d crippled it: a user launching OurAirports that way could no longer bookmark a specific airport page to come back to it later; could no longer open two airports in different tabs; and could no longer search for text in a long comment stream. I removed it and let the browser chrome come back, because really, that browser chrome is a lot of what makes a web site useful.

So when you’re designing your next web thingy, ask yourself a few questions:

Is it valuable for users to be able to search for text within a page, bookmark pages, and open multiple tabs (site)?
Is it mainly about manipulating an external resource, such as a picture or diagram (app)?
Does it have lots of pages with relatively stable URLs (site)?
Can it potentially provide a reasonably-complete offline experience using only a small number of files containing markup, code, and data (app)?
Is it designed as part of a bigger web, linking out and receiving inbound links (site)?
Would browser chrome distract rather than help the user (app)?
Is it something that Google should index and make searchable (site)?

Over the past few years, I think, too many people have been taking things that are more-naturally sites (e.g. newspapers) and trying to force them to behave like apps by forcing in AJAX, hashbang URL syntax, etc.: the result is typically impressive and flashy, but a crappy user experience. On the other hand, the greatest advance in the Web over the past ~10 years has been its growing ability to support activities like creating spreadsheets or editing photos that really don’t fit the REST/web-site model. So by all means, if you have an app, let it be an app, but don’t try to force everything into app world; REST is still the web’s heartbeat.

Link: Transitioning To a Mobile Centric World (Bill Gurley)

David Megginson — Fri, 19 Jul 2013 07:18:00 +0000

http://abovethecrowd.com/2013/07/17/transitioning-to-a-mobile-centric-world/

This article argues that the verdict is in, and users want apps, not mobile web sites. My friend and colleague Michael Roberts (who, I suspect, is neutral in the debate) shared this link on Google+, and – as if to prove Mr Gurley’s thesis – I read his posting in the Android G+ app, not the mobile site.

Here is the comment I left:

Interesting piece – thanks, Michael . He’s absolutely right that people prefer apps to the browser for common tasks, but I don’t think he’s got the whole story. For example, like most people, I currently read G+, Facebook, and Twitter in the dedicated mobile apps rather than in the browser. However, a large plurality (if not majority) of interesting posts to those services are actually links back out into the web, so the result of of reading a tweet is generally opening not a dedicated app, but a web site.

Case in point – we’re both reacting to a pro-app/anti-browser article, but the only reason we know about it is that you were able to share a web link in your G+ post. If Mr. Gurley had created a “GurleyPosts” app for his thoughts, then (a) most people probably wouldn’t have it installed, and (b) you wouldn’t have been able to pass a link from iOS that I could use to read it on Android.

In other words, for something I do a lot (read Facebook, check the weather, play a game, get driving directions) I will tend to use an app. But I won’t install a dedicated app just to read an article from a magazine or newspaper, and even when I am using an app, I need a link if I’m going to share it with anyone else.

So in 2013 for mobile, apps are for the tall head of any user’s activities, and the browser is for the long tail. Of course, every startup thinks it’s going to be the next Facebook (at least in terms of its importance to the people who use it), but few of them end up there, so the way people are going to find them is by following links from FB, Twitter, Google+, emails, chats, etc. I wouldn’t give up on that mobile web site quite yet.

The mobile development challenge

David Megginson — Sun, 23 Jun 2013 18:37:33 +0000

A bit over a week ago, I set myself a challenge: develop a mobile app entirely using mobile devices. I must never touch the app with a laptop or desktop computer, for even the most-trivial reason. I don’t have a lot of free time in my life, so I’ve been able to tinker for only an hour here or there, but so far, I’ve had good success.

Tools

Here are the ingredients:

the Android OS (Jellybean) running on a Nexus 7 tablet, with a small Bluetooth keyboard
the Android Integrated Development (AIDE) app, which uses the Eclipse project format and includes a git client
GitHub, for storing my source code

Progress and gotchas

I decided to create a kind of app that made sense as a mobile app (rather than a web site): a SQL query tool for databases on the device. I’m calling it “Sloop-SQL”, and while my early prototype isn’t in the Play Store yet, you can grab the Public Domain source from GitHub: https://github.com/davidmegginson/sloop-sql and build your own copy with AIDE on your phone/tablet or Eclipse on your laptop/desktop.

The process has worked surprisingly well so far. When I want to test on my phone (rather than my tablet), it takes only a few seconds to do a git pull on the phone, and build and run using AIDE. I also enjoy the simpler AIDE UI over the cluttered Eclipse one.

I’ve run into only two significant annoyances:

GitHub doesn’t have a mobile-friendly site, and their mobile app is severely limited, so it was a bit frustrating creating the repository.
As of Jellybean, Android doesn’t let apps request permission to see other apps’ logs, so AIDE can’t show me the app’s logcat (which includes crash reports from uncaught, top-level exceptions).

I could work around the second problem by rooting my N7, but that’s also cheating.

I hope that the Android team will consider adding the read-logs permission back in — perhaps backed by a special developer setting — so that Android can grow into a full software development environment, rather than being nothing more than a development target (like iOS).

Mobile users want fresh data

David Megginson — Mon, 09 Aug 2010 13:35:48 +0000

Summary: Mobile web users’ needs differ by more than UI features (small touch screen): they may check information more often, and expect it to be fresher.

Last night, I finally got around to installing Google Analytics on ourairports.mobi, the mobile version (for pre-smartphones) of ourairports.com, and this morning, I got my first stats: all of 3 visits yesterday (vs. 1,677 for the non-mobile site).

I expect that number to climb when the site is collecting stats for a complete 24-hour day, but already, I’ve noticed a significant difference in use:

Site	Visits	Page views	Pages/visit
Mobile	3	93	31.00
Desktop	1,677	4,748	2.83

Of course, the mobile sample is too small to be statistically significant, but it still made me think about how a mobile user will use the site:

A desktop user at home may check information for an airport once while planning a flight (as pilot or airline passenger).
A mobile user, at or on the way to the airport, will keep checking for changes (new weather forecast, NOTAMs, etc.), constantly updating the same few pages.

A closer look at the analytics confirms that hypothesis, with a small number of airports updated multiple times (there were four pageviews for Sunbury Airfield in Australia, for example).

Further hypothesis: timely data is important for all web users, but it may be disproportionately important for mobile users. If this is true, it’s probably worth spending less time trying to make your mobile site (or app) look like a fourth-year graphic design college project, and more time making sure that it has the best, and most recent information.

I’ll watch the analytics for ourairports.mobi over the next month to see if this trend continues.

The past, future, and present of mobile apps

David Megginson — Sun, 16 May 2010 22:35:33 +0000

Now that I’ve had a few weeks to play with my Nexus One, I’m starting to grok the gut-level experience of living with a smart phone. I understand why people download apps, how it feels to have the Internet with me everywhere, and what it’s like to experience the web by touch on a screen that’s only a few centimetres square.

Past

Device-specific apps are sweet and shiny at first, but after a couple of weeks, it becomes obvious that many of them are the encore of the floppy-based PC shareware world of the 1980s and early 1990s (SEND $5 TO GET RID OF THE ANNOYING ADS! ONLY $10 FOR THE FULL VERSION!).

Discovering an interesting app through Apple’s or Android’s market (or taking a picture of a barcode on your computer screen) is surprisingly awkward compared to just following a link from one web site to another, and as we’ve learned from the postal service, the telegraph, the telephone, email, and the web, connectivity always wins in the end.

Future

Web apps run everywhere and connect to each-other seamlessly, and HTML5 allows a well-written web app to do almost everything a closed, device-specific app can do on a smart phone — many of the mobile web sites I’ve used (hello, Google!) are as good as or better than the corresponding device-specific apps. There are some things, though, that make mobile web apps stand apart:

The built-in buttons on your smartphone are tied to the browser, not to the app, so the Android menu or search button (for example) brings up a browser menu or search box, not an app one.
For good security reasons, a web app will probably never have as much access to the filesystem and device hardware as a closed device-specific app (do you want a malicious web app to be able to turn on your video camera when you’re browsing in bed? do you ever consider that when you give a downloaded app access to your camera?).
While HTML5 supports notifications, you have to actually be on the web page to receive them. That can be fixed by allowing the browser to launch web pages automatically on start/restart, but it’s still more awkward than an autostart app.
Web app processes need to be managed from inside the browser, not from a device-wide process manager.
As far as I know, there’s no way for a web app to install its own icon on the device home screen — the user has to install it manually (though it’s pretty easy).

I don’t consider most of these to be a big deal, but they do point to the fact that no matter how much extra functionality HTML5 provides, web apps have a different world view: they’re nodes in a huge network, not standalone silos.

Present

I’ll probably have to continue to use a device-specific app for anything related to playing music or capturing photos/video for a while longer, and I’ll hang onto the Android WiFi analyzer I’m running on my phone. Android has a lot of the same apps that show up in iPhone commercials (like Urban Spoon), but while they’re pretty, they’re limited in the end — there’s way more out there on the web than there will ever be an an app store.

If you’re an person or organization that wants to interact with people on mobile devices, you have two choices:

You can develop and maintain separate apps for iPhone, Android, Blackberry, Palm, and any other smart-phone OS’s that may come along, and let the phone vendors be gatekeepers between you and your users.
You can run a single mobile web app on your own server, one that’s only a click away from any other web site that links to it.

The first option lets you force an icon onto the users desktop, but the direct development costs and opportunity costs of losing inbound links and search-engine love just seem too high.