Google Introduces “Invisible” Gmail Messages!

A Google “Project Fi” user contacted me on Google+ this afternoon, expressing his extreme displeasure at a Gmail message (please see image below) that he received a week or so ago from that project. His comment: “I’m sure they’re trying to tell me something, but I can’t really read it.”

Not surprisingly, it’s in the dandy new Google low-contrast font style — oh so pretty and oh so useless to anyone with less than perfect vision.

Perhaps he saw my recent post “How Google Risks Court Actions Under the ADA (Americans with Disabilities Act)” — https://lauren.vortex.com/2017/06/26/how-google-risks-court-actions-under-the-ada-americans-with-disabilities-act — in any case he thought that I might be able to help with this overall accessibility issue.

Well, I’m willing to keep writing and talking about this until I’m Google blue, green, yellow, and red in the face — but so far, I’m not having much luck.

I’ll keep on tryin’ though!

–Lauren–

How Twitter Killed My Twitter Engagement by Killing Email Notifications

I don’t currently use Twitter all that much — it’s become loaded down with too much timeline content in which I’m utterly disinterested, and I’m far happier with ad-free Google+ (https://google.com/+laurenweinstein). But I do post on Twitter those items that I hope are interesting, nearly every day, via https://twitter.com/laurenweinstein.

I’m also more than happy to stay engaged with my Twitter followers. Lately though, a number of them have been emailing me and contacting me through other means, asking why I’ve been ignoring their replies and other routine Twitter-based interactions.

The reason is simple — Twitter doesn’t tell me about you any more. At least, not in a way that’s useful to me.

Until early this month, Twitter would send me a short, individual notification email message for mentions, replies, new follows, retweets, and likes. These were easy for me to scan using my available tools as part of my normal email workflow.

But now, Twitter no longer sends these individual notifications. Instead, once a day I receive an utterly useless “digest” from them, only providing me with the counts in each of those categories. No clue as to the contents. For example, the one I received today looks like this:

– 6 new followers – See them
> https://twitter.com/i/notifications
– 32 likes – See them
> https://twitter.com/i/notifications
– 3 replies – See them
> https://twitter.com/i/notifications
– 29 Retweets – See them
> https://twitter.com/i/notifications
– 5 mentions – See them
> https://twitter.com/i/notifications

A Twitter help page claims that this is to reduce my “email clutter.” It wasn’t clutter to me, it was how I stayed on top of my Twitter activities. 

Pretty clearly, this change was made to reduce Twitter’s email load, and to try drive users more frequently back to their site.

Frankly, I don’t have the time to keep running back to that one ridiculously long page on their site to plow through all of those notifications, which are stuffed in there like a Thanksgiving turkey. I presume this isn’t a big problem for folks who live on Twitter all day long, but it’s a total no-op for me.

So unless somebody knows of a way to get those individual email notifications back again (screen scraping apps, perhaps?) you can safely assume that your Twitter interactions with me will almost certainly be going into a black hole for now.

And that’s really a shame. Or to put it another way — shame on you, Twitter.

–Lauren–

Google Asked Me How I’d Fix Chrome Remote Desktop — Here’s How!

Since my posting a few days ago of “Another Google Accessibility Failure: Chrome Remote Desktop” — https://lauren.vortex.com/2017/07/21/google-accessibility-failure-crd — I’ve been contacted by a number of Googlers whom I know, asking me specifically how I’d address the accessibility problems that I noted therein. These queries were all friendly of course — not of the “put up or shut up” variety!

OK, I’ll bite. And Google can have this one for free — but like I’ve said before, this isn’t really rocket science.

Before I begin, I’ll answer another question that a number of readers have posed to me in response to that same post.

Why do I think that Google has so long ignored these sorts of problems with Chrome Remote Desktop (and various other of their products, for that matter)?

Without addressing Chrome Remote Desktop (CRD) or Google products specifically in this context, I’ll offer one possible explanation.

Around the information tech industry, it just isn’t usually considered to be career enhancing to be working on older software fixes and/or improvements, even when that application is fairly important and widely used.

By and large, most software engineers feel that rising on the career ladder is facilitated by working on new and “sexy” projects, not by being assigned to the “maintenance detail” — so to speak.

That’s a difficult corporate cultural problem, but a very important one to solve.

All right, let’s get back to Chrome Remote Desktop.

Here’s how I would fix the most glaring accessibility problem that I’ve noted regarding CRD operations — the damned “share mode ten minute timeout” (which, as I’ve noted in the referenced post above, actually can push users into terrible security practices when they attempt to work around the sorts of problems that the timeout causes — please see that previous post for details about this).

There are various somewhat complex ways to approach this issue — such as permitting the local user (the user who is sharing their screen with a remote user) to specify a desired timeout interval.

But the most straightforward and likely most useful approach for now in most cases would be to permit the local user to simply disable that timeout at the start of individual sessions, for the duration of those sessions.

Currently, when a local user provides a one-time CRD access code to a remote user, and the remote user attempts to connect using that code, the local user is presented with a dialogue box (which varies a bit across operating system platforms) that typically looks like this:

Obviously, only the local user can interact with this dialogue. They click “Share” if they wish to accept the connection.

And this is the obvious location to place a “session timeout disable” flag, as emphasized in my quickie demo mock-up here:

It’s that simple — and that logical. This checkbox (which defaults to timeouts enabled) only applies to the current session. The usual ten minute timeout is automatically restored for the next session.

– – –

Addendum: As suggested in the first comment on this post today, it would be reasonable to also provide this same timeout disable option in the actual ten minute timeout popup dialogue boxes themselves, so that even if the local user did not disable timeouts at the start of a session, they’d be able to later disable them for the remainder of the session if they so chose.

– – –

We probably should remind the local user that they’ve disabled timeouts for a session. There are logical places to do this, too.

CRD already provides a warning to local users that they’ve shared their desktop. For example, in Chrome OS (e.g. Chromebooks), a dialogue box like this is used:

An information notification is also popped up for the user with the same information in the Chrome OS notification area.

The CRD implementations for other OSes behave similarly. Windows systems provide a “currently sharing” dialogue box similar to the above, and also display a “floating” notification:

For all of these info notifications when timeouts have been disabled, it would be straightforward to add within them a text “warning” such as:

Timeouts have been disabled for this session.

If we’re feeling particularly paranoid about this — even given all of the other security elements that have already been satisfied to get the sharing connection open in the first place — we might want to add some sort of new warning box that can’t be covered, minimized, or moved by remote users, providing the same reminder that timeouts have been disabled.

That’s pretty much the whole enchilada. This paradigm should not be difficult to implement, and from security, usability, and accessibility standpoints overall it’s definitely a big plus for Chrome Remote Desktop users.

OK, Google — the ball’s back in your court!

–Lauren–