Apps, the web, and productivity

Inspired by this public discussion on Asa Dotzler’s Facebook wall, I reflected on my own current use cases of web applications, native mobile apps, and desktop clients. I also thought about my post from 2012 where I asked the question whether web apps are accessible enough to replace desktop clients any time soon.

During my 30 days with Android experiment this summer, I also used Gmail on the web most of the time and hardly used my mail clients for desktop and mobile, except for the Gmail client on Android. The only exception was my Mozilla e-mail which I continued to do in Thunderbird on Windows.

After the experiment ended, I gradually migrated back to using clients of various shapes and sizes on the various platforms I use. And after a few days, I found that the Gmail web client was no longer one of them.

The problem is not one of accessibility in this case, because that has greatly improved over the last two years. So have web apps like Twitter and Facebook, for example. The reason I am still using dedicated clients for the most part are, first and foremost, these:

  1. Less clutter: All web apps I mentioned, and others, too, come with a huge overload of clutter that get in the way of productivity. Granted, the Gmail keyboard shortcuts, and mostly using the web app like a desktop client with NDA’s virtual mode turned off, mittigate this somewhat, but it still gets in the way far too often.
  2. Latency. I am on a quite fast VDSL 50 MBIT/S connection on my landline internet provider. Sufficing to say, this is quite fast already. The download of OS X Yosemite, 5.16 GB, takes under 20 minutes if the internet isn’t too busy. But still managing e-mail, loading conversations, switching labels, collecting tweets in the Twitter web app over time, browsing Facebook, especialy when catching up with the over-night news feed, take quite some noticeable time to load, refresh, or fetch new stuff. First the new data is pulled from servers, second they are being processed in the browser, which has to integrate it into the overloaded web applications it already has (see above), and third, all the changes need to be communicated to the screen reader I happen to be using at the time. On a single page load, this may not add up much. But on a news feed, 50 or so e-mail threads, or various fetches of tweets, this adds up time. I don’t even want to imagine how this would feel on a much slower connection that others have to cope with on a daily basis!

Yes, some of the above could probably be mittigated by using the mobile web offerings instead. But a) some web sites don’t allow a desktop browser to fetch their mobile site without the desktop browser faking a mobile one, and b) those are nowadays often so touch optimized that keyboard or simulated mouse interaction often fails or is as cumbersome as waiting for the latent loads of the desktop version.

So whether it’s e-mail, Twitter, or Facebook, I found that dedicated clients still do a much better job at allowing me to be productive. The amount of data they seem to fetch is much smaller, or it at least feels that way. The way this new data is integrated feels faster even on last year’s mobile device, and the whole interface is so geared to the task at hand, without any clutter getting in the way, that one simply gets things done much faster over-all.

What many many web applications for the desktop have not learned to do a good job at is to only give users what they currently need. For example as I write this in my WordPress installation backend, besides the editor, I have all the stuff that allows me to create new articles, pages, categories, go into the WordPress settings, install new plugins etc. I have to navigate past this to the main section to start editing my article. This, for example, is made quick by the quick navigation feature of my screen reader, but even the fact that this whole baggage is there to begin with proves the point. I want to write an article. Why offer me all those distractions? Yes, for quick access and quick ways of switching tasks, some would say. But if I write an article, I write an article. Thanks for the WordPress app for iOS or Android, which if I write an article, don’t put all other available options in my face at the same time!

Or take Twitter or Facebook. All the baggage that those web apps carry around while one just wants to browse tweets is daunting! My wife recently described to me what the FB web site looks to her in a browser, and fact is the point where the action is happening, the news feed, takes only a roughly estimated 10 or 15 percent of the whole screen estate. All the rest is either ads, or links to all kinds of things that Facebook has to offer besides the news feed. Zillions of groups, recommended friends, apps, games nobody plays, etc., etc., etc.

Same with Twitter. It shoves down one’s throat trendings, other recommendations, a huge menu of other stuff one would probably only need once a year, etc. OK, desktop screens are big nowadays. But offering so many bells, whistles and other distractions constantly and all around the place cannot seriously be considered a good user experience, can it?

I realize this is purely written from the perspective of a blind guy who has never seen a user interface. I only know them from descriptions by others. But I find myself always applauding the focused, concise, and clean user interfaces much more than those that shove every available option down my throat on first launch. And that goes for all operating systems and platforms I use.

And if the web doesn’t learn to give me better, and in this case that means, more focused user interfaces where I don’t have to dig for the UI of the task I want to accomplish, I will continue to use mobile and desktop clients for e-mail, Twitter and others over the similar web offerings, even when those are technically accessible to my browser and screen reader.

So, to cut a long story short, I think many mainstream web applications are still not ready, at least for me, for productive use, despite their advancements in technical accessibility. And the reason is the usability of things for one, and the latency of fetching all that stuff over the internet even on fast connections, on the other hand.

Started a 30 days with Android experiment

After I revisited the results of my Switching to Android experiment, and finding most (like 99.5%) items in order now, I decided on Tuesday to conduct a serious 30 days with Android endeavor. I have handed in my iPhone to my wife, and she’s keeping (confiscating) it for me. I will also keep a diary […]

Revisiting the “Switch to Android full-time” experiment

Just over a year ago, I conducted an experiment to see whether it would be possible for me to switch to an Android device full-time for my productive smartphone needs. The conclusion back then was that there were still too many things missing for me to productively switch to Android without losing key parts of […]

Quick tip: Add someone to circles on Google Plus using a screen reader

In my “WAI-ARIA for screen reader users” post in early May, I was asked by Donna to talk a bit about Google Plus. Especially, she asked how to add someone to circles. Google Plus has learned a thing or two about screen reader accessibility recently, but the fact that there is no official documentation on […]

Accessibility in Google Apps – an overview

I recently said that I would write a blog series about Google apps accessibility, providing some hints and caveats when it comes to using Google products such as GMail, Docs, and Drive in a web browser. However, when I researched this topic further, I realized that the documentation Google provide on each of their products […]

WAI-ARIA for screen reader users: An overview of things you can find in some mainstream web apps today

After my recent post about WAI-ARIA, which was mostly geared towards web developers, I was approached by more than one person on Twitter and elsewhere suggesting I’d do a blog post on what it means for screen reader users. Well, I’ve got news for all my blind and visually impaired readers: You’re not getting one […]

Improvements to the handling of the aria-pressed attribute

On Monday this week, Heydon Pickering brought to my attention that Firefox has a problem with the way it handles the aria-pressed attribute in some circumstances. aria-pressed is used on buttons (or elements that have a WAI-ARIA role of “button”) to turn it into a toggle button which can be either pressed or not. Think […]