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.


8 thoughts on “Apps, the web, and productivity

  1. Marco, well said! I agree and follow the same strategy. Productivity, especially for screen reader users, is the biggest challenge we have in the workplace today. Web page distractions and technology curiosity robs us of real productive work.

  2. Hi Marco. I just read this post and although I’m not in a fast-paced work environment, I have to agree with you. First of all, I have stopped using Facebook. For one thing, I couldn’t even get their mobile site to work with VoiceOver. But in addition, I just find the whole Facebook interface very difficult and cluttered. Wonder what the accessibility team’s been doing over there lately, if they’re even active anymore. I’ve actually been meaning to delete my Fb account entirely but just haven’t gotten around to it. Perhaps it’s laziness. I actually heard about a website that will supposedly do it in one single step, and last I checked the site looked all right in terms of accessibility. I forget where I heard about it though. The website in question is , so if anybody knows anything about it I’d really appreciate hearing from you. For Twitter, I’ve been using Easy Chirp lately. I liked it in its original form, and the revamped website is also very nice. I have also used The Qube before and really like it, but I haven’t installed it on my Mac. I’ve been thinking about trying out Youru Fukouru, or whatever that Twitter client is for the Mac. It’s the one whose name is a Japanese swear word. Lol sorry if I’ve offended anyone, but I couldn’t resist that one. As far as blogging, I’ve started one on Dreamwidth. Thus far I’ve only used this service with VO and for a brief period Chromevox, but it rocks in terms of accessibility. When I was last a Serotek customer, I used the built-in SAMNet website creator tool and found it to be excellent.

  3. I have the same feelings about most web applications. Facebook is a particularly bad example, but a common theme — core content and productivity is undermined by a cluttered interface, or sacrificed to make space for advertising.

    For me, the compelling thing with desktop applications is that they all look basically the same. Productivity apps like email, word processing, spreadsheets etc. all use the same GUI components — the same buttons, the same menus and text fields, the same tab groups, the same font. Applications share a common design and interactivity with all applications on the same platform.

    But this is not the case with web applications. Every web application is different, with a visually and behaviourally unique interface that you have to learn from scratch each time. As a sighted user, I find that a constant source of frustration, annoyance and time-wasting. But for individuals such as yourself, with more specific accessibility requirements, the problems must only increase.

    I can’t really see how this problem will ever be solved, unless web applications begin to use a common set of interface components. A basic example is HTML form fields, like drop-down menus, buttons and text boxes. If sites just left them alone — never tried to change their appearance or behaviour — then all applications which used them would have a consistent GUI. But that’s not what site owners and designers want. They want their applications to have a unique brand and a stand-out design.

    Yet that is exactly what makes them less usable and accessible!

  4. Hey Jake. I work on Facebook’s accessibility team (we are indeed still active and regularly post on and @fbaccess). Could you send a bug report to We’d like to better understand the challenges you’re experiencing with Facebook and your screen reader. Could you include a description of the URL/application you’re using, as well as your current screen reader/version and browser/version? We’ll take a closer look. Thanks!

  5. I agree, but there’s an aspect in this that I think was forgotten. The screen reader’s method of accessing web content plays a role and I’ve found that virtual buffer-based screen readers like NVDA or JAWS have a much harder time in dealing with web applications than screend readers that do not use this concept, such as VoiceOver and ChromeVox. I’ve found that, in web applications that do not use or need the application role, that the need to turn on and off the virtual buffer not only makes us slower at using them by adding extra keystrokes, but also causes the screen reader to lose track of where you are in the web app itself. The end result is that you try to use the web app correctly, but when you need to review content more closely you have to find it all over again with your screen reader. In essence, you have to find what you want twice. This is a problem avoided by other platforms’ screen readers that don’t use virtual buffers, because as your system’s focus moves along the web app so does the screen reader and when you need to review, simply switch to your screen reader’s review commands and you’ll be right where you need to be.

    1. Thanks for your comment! And yes, when I wrote the post, I did consider virtual buffer and non-virtual buffer approaches. To be honest, I find Facebook, for example, equally unpleasant to use on OS X using VoiceOver and Safari. And that’s not just because of the terrible bugs that made it into the Yosemite release re the aria-label breakage. I found that the FB shortcuts to move from post to post often enough yielded incomplete speech even on Mavericks. Yes, you can more easily review surrounding text information around a control, but every time a page reloads or causes enough content to be re-rendered, even VoiceOver starts at the top of the page, and you have to find your location again, having to bypass all the cruft that the web site carries around.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.