Wednesday, March 25, 2015

Twitter App Sets Browsers Back 10 Versions

Screen shot of a web page as seen in the Twitter app, with a menu showing the option to open in the user's default web browser.

The title of this post may be a bit of hyperbole for some, but it is completely true for me.

Sometime over the course of the last week Twitter changed what happens when I tap links in the native Twitter app on Android. Links now open within an embedded browser, not in my default browser.

I have Chrome 40 installed on my Android phone. The built-in web view on my phone is 10 releases back, at Chrome 30. Normally this isn't a concern of mine, but when a good deal of my Twitter timeline consists of bleeding edge web development techniques, I want to view those on a current release of Chrome.

The first image shows that the user agent string within the Twitter app includes Chrome 30. The second image shows my default browser user agent string is Chrome 40.

This change appeared while I was traveling internationally, which means I had a slower connection than usual as well as a data cap. Not only do I have to view content in an old browser, I have to know that the web view is older so that I then know to open it in my default browser.

That's at least two more taps, plus the burden of the download starting in the web view that I don't want. That extra download burden also impacts my data cap, which is an even bigger issue if I have chosen to surf with Opera Mini to make the most of my limited data cap (you know, data budgeting).

Not only did I never enable this feature, I cannot disable it. It appeared three weeks after my last Twitter app update (see the caption below).

The first image shows the settings screen in the Android Twitter app, version 5.48.0. You can see there is no option to disable the in-app browser, though it has been enabled. The second image is the note in the Google Play store that tells me the only change in the new release is updated profiles so it's easier to view bios, Tweets and photos. The final image shows the option to disable the in-app browser, but only because I updated to version 5.51.0 (when I returned from home and shed my data cap).

So What?

A couple months ago Peter-Paul Koch wrote about the massive fragmentation in the world of Chrome (Chrome continues to fall apart at brisk pace), something to which Twitter is now contributing en masse.

In the modern world of rapidly updating browsers, 10 releases may not seem like a big deal. I guess it comes down to what you want to see, or more importantly, what you want your users to see. Can I Use provides a quick way to compare Chrome 30 and Chrome 40 to see which features you may be missing. Here's a short list:

  • The ability to discard many -webkit- prefixes,
  • Font unicode-range subsetting,
  • matches() DOM method,
  • CSS touch-action property,
  • CSS Font Loading,
  • Custom Elements,
  • picture element,
  • Web Cryptography,
  • WOFF 2.0 - Web Open Font Format.

If you rely on any of these (or many other) features of the open web platform, and you receive traffic from Twitter, I suggest you monitor your logs to see if the most common version of Chrome drops.

As for user experience, If you plan to allow users to toggle a new "feature," don't push that feature to them without the toggle. Especially when you exclude it from your update notes within the app store.

Monday, March 16, 2015

ACE! Conference Slides: Selfish Accessibility

ACE! Conference on Lean and Agile Best Practices

In addition to the slides, I've embedded video of my talk and way too many tweets after that.

Video

Impressing everyone on the internet, Paul Klipp has already gotten videos from ACE! posted less than 24 hours after the event ended. That's impressive. I understand his tactic is to upload lower resolution videos immediately and then slowly replace them with higher resolution videos. Depending on when you see this, it may still be the low-res video.

Tweets

Tweets from ACE! that satisfy my ego, show me in a photo, or might be funny.

Feedback (Added 26 March 2015)

I've received the audience feedback from my talk and overall was pleased. 17 people responded (out of what I estimate was ~40+ in the room) with the following rankings:

  • Loved it! 10
  • Liked it: 2
  • Meh: 4
  • Didn't like it: 0
  • Hated it! 1

Of those 17, 10 left comments (which I greatly appreciate!). Sadly, the one Hate it vote did not leave any comments.

  • Liked it: Too basic for me, but nice examples of disabilities.
  • Loved it! I loved the idea how to easily test your apps.
  • Loved it! Great that this topic emerged.
  • Loved it! Great approach to creating sites/apps friendly for impaired.
  • Loved it! Full of very practical suggestions. Thanks for including it.
  • Loved it! Content that usually doesn't get a forum.
  • Meh: Interesting, however I won't get a chance to use what I learned.
  • Loved it! Interesting point of view. I did not consider accessibility during software design. I should start.
  • Liked it: Most important is to think about problem, not about product/project.
  • Meh: Nicely said, but too short.

The two Meh comments are mostly out of my control. I was given a 30 minute slot, which I agree is too short for all that can be said on the topic. As for the commenter who claims he/she won't be able to use it, I feel that the testing parts of my talk at the very least are in everyone's reach, so I think it comes down to deciding to use it. Even if only to troll the Virgin America site.

Saturday, March 14, 2015

Typefaces for Dyslexia

Example showing the letterforms of b, p, and d, and how they have a thicker stroke on the bottom.
Both typefaces claim that heavier strokes on the bottom prevent dyslexic readers from flipping the letters when viewing them. The original caption: A heavier bottom is used to show which way is supposed to be down.

I've been writing this post in fits, so it may be a bit disjointed. I started it on my flight home from CSUN, and continued to work on it on subsequent flights. Apologies if it's a bit chaotic.

TL;DR: Typefaces designed to help dyslexics have no effect.

I'll list information about the two typefaces that I am aware of (which are designed explicitly for readers with dyslexia), as well as notes from the talk at CSUN and a couple other examples.

Typefaces

I am aware of two typefaces that are designed with dyslexic readers in mind.

OpenDyslexic

Open Dyslexic is an open source typeface for readers with dyslexia. The rationale behind the design:

OpenDyslexic is created to help with some of the symptoms of dyslexia. Letters have heavy weighted bottoms to indicate direction. You are able to quickly figure out which part of the letter is down which aids in recognizing the correct letter, and sometimes helps to keep your brain from rotating them around. Consistently weighted bottoms can also help reinforce the line of text. The unique shapes of each letter can help prevent confusion through flipping and swapping.

Dyslexie

Dyslexie is a paid typeface (free for home use). The site references research that supports the following claim:

Representative research among many dyslectics has shown that the font Dyslexie actually helps them with reading texts faster and with fewer errors.

I would like to note that copying that text directly from the browser wasn't easy. The use of Cufon to embed the typeface drops each word into its own element that itself hides and replaces the raw text in a canvas element. I'm sure you can imagine how much that offends me.

The following video explains the idea behind the typeface:

Study: Can a font improve reading?

The latest study to suggest that typefaces designed to aid reading for dyslexics had little to no effect was presented at CSUN this past week. As I noted on Twitter, I already had an idea what the results would be, and I came away feeling validated.

The study hasn't been pubished yet and I saw its first general presentation. The study was conducted at Mount Allison University, a 2,500 student college with 215 full-time students with disabilities. 50% of those students are classified as having a learning disability.

The questions asked by the study:

  • Do the style of the letters on a page mean that you read faster and make fewer errors?
  • Do persons with LD [learning disabilities] using this font read faster and make fewer errors?
Anne Comfort, Matt Kalichuk, Harry Wenban and Dr. Louise Wasylkiw

The typefaces (Open Dyslexic and Dyslexie) make claims about their benefits, aggregated in the presentation as:

  • Students with surface dyslexia experience letters flipping and moving around; Letters needed to be bottom heavy to prevent them from moving around
  • New font would increase reading speed
  • Will also increase accuracy (fewer errors)
  • Will decrease reading stress
  • Widely promoted to on-line uses and in word processing (Instapaper, iPad, an app)
  • Strong anecdotal feedback
Anne Comfort, Matt Kalichuk, Harry Wenban and Dr. Louise Wasylkiw

The presenter outlined some literature references, the procedure the team followed to perform the study, the nature of the participants (and control group), and the overall results.

The first bullet in the summary wraps it up nicely:

  • The font does NOT improve reading speed or accuracy for students with LD.
Anne Comfort, Matt Kalichuk, Harry Wenban and Dr. Louise Wasylkiw

An interesting note from the study was that half of each group (50% of control, 57% of LD group) said they would consider using the font and were then shown how to access it (download and install it, which I assume was Open Dyslexic). In a follow-up, none of those participants were using the font.

Another interesting point was that 40% of the control group and 48% of the LD group thought they performed better when using Open Dyslexic, though that was not the case.

As anyone who's done user testing knows, it's not uncommon for users to report one thing while doing or thinking another, so I consider this to be anecdotal reinforcement that the typeface had no benefit for users.

Study: Good Fonts for Dyslexia: An Experimental Study

In late 2013 I found a write-up on a Spanish study that reviewed which fonts were easiest for readers with dyslexia. The post summarizes the study:

Based on the evaluation of 48 dyslexic subjects ages 11-50, reading 12 texts with 12 different fonts, they determined that reading performance was best with sans serif, monospaced, and roman fonts used in the study. They also found that reading was significantly impaired when italic fonts were used.

[…]

Use of the OpenDyslexic font did not enhance text readability or reading speed. The study participants strongly preferred Verdana or Helvetica over the OpenDyslexic alternative.

You can find the full text of the study in a PDF file on the site for the Natural Language Processing group of the Department of Information and Communication Technologies at Pompeu Fabra University.

General Tips

For those of us who build applications and sites with content of any length (whether instructions for shopping carts or rant-laden long-form articles), I have found a few techniques are generally agreed upon by the community (feedback is welcome!):

  • Avoid justified text.
  • Use generous line spacing / leading.
  • Use generous letter spacing.
  • Avoid italics.
  • Generally use sans serif faces.
  • Use larger text.
  • Use good contrast.
  • Use clear, concise writing.

This generally follows rules for good typography.

You may have heard that Comic Sans is easier for readers with dyslexia to understand, but so far that evidence appears to be anecdotal. Certainly not enough to warrant punishing all your other users.

If you read an article that suggests users with dyslexia see letters flip or rotate, then be wary. Not only was this assertion challenged by participants in the study reported at CSUN, but generally the participant reaction was anger. The flipping/rotating may be a myth perpetuated by those without dyslexia in an effort to make sense of its effects.

Update: March 26, 2015

In a post from 2011 (Dyslexia, Fonts & Open Source), Mike Gifford outlines some of the issues related to supporting readers with dyslexia, including typefaces.

Wednesday, March 11, 2015

Booster Conference Slides: Making Your Site Printable

Giving my talk at Booster.
Giving my talk at Booster. Photo from Booster by Tatiana Kolesnikova.

I'll fill this up with notes and other content later, but in the meantime here are the slides from my talk this morning:

I've written a bunch of handy stuff on print styles, here are some links (or you can see all posts tagged print on my blog) along with other resources (most of this is referenced in my slides):

The Twitters

Booster had a lot of activity on Twitter (not just about my talk, imagine that). I've collected some of the tweets below.

Feedback (Added 26 March 2015)

I got feedback from my talk, and it was overwhelmingly positive. Consider mine was the first lightning talk of the first session of the first day immediately after the keynote, I'm just pleased people took a moment to vote.

Voting consisted of asking attendees to drop a colored card into a basket representing my talk. There were three options. I got 15 green cards (it was amazing), 4 yellow cards (it was okay), and no red cards (I didn't like it).

Only one person left a comment, which was Talked too fast. I cannot disagree with that. With 10 minutes to cover 42 slides and do so to an audience of non-native English speakers, I'm thrilled I only received that comment once (though I suspect many others agreed).

Monday, February 16, 2015

Speaking at Avega Group in Stockholm

Avega Group logo

Rounding out my European tour (I'll be at Booster in Bergen and ACE! in Krakow) is a speaking gig not at a conference. I've been grabbed by the fine folks at Avega Group to speak to their team in Stockholm on the evening of March 19.

I'll be speaking about accessibility not just to Avega Group, but apparently whomever else might like to attend who is in the area. There is a Google Form you can fill out if you would like to attend (it's after business hours, so it needn't eat into your day too much).

The abstract from my talk:

We can all pretend that we're helping others by making web sites accessible, but we are really making the web better for our future selves. Learn some fundamentals of web accessibility and how it can benefit you (whether future you from aging or you after something else limits your abilities). We'll review simple testing techniques, basic features and enhancements, coming trends, and where to get help. This isn't intended to be a deep dive into ARIA, but more of an overall primer for those who aren't sure where to start nor how it helps them.

More information is on the Google Form, which I have also embedded below:

If you will be in the area, here's a map of Avega Group's venue:

Saturday, February 14, 2015

Using Bookmarklets on Mobile

Viewing comments on Medium. Login prompt when tapping to view comment replies.
Viewing comments on Medium (first image), then being prompted to login in order to view comment replies (second image). Both images are current version of Chrome on Android.

This is a follow-up to my post CSS Bookmarklets for Testing and Fixing.

While surfing Medium the other day I chose to read a comment. As usual, the comment overlay came up at the bottom of my screen with an option to see replies. When I tapped the replies link, I was immediately prompted to log in. This was new.

In the time between me tweeting Medium to complain, and them responding that it was a bug, I wrote a bookmarklet to remove that login overlay.

This was the easy part. The hard part was using the bookmarklet on my mobile.

As you may already know, there is no bookmark bar in the average mobile browser (at least not on smaller screens). Viewing bookmarks will generally take you to a new tab or screen, meaning a bookmarklet cannot affect the page you were viewing.

Conveniently, once you create a bookmark it becomes available through the auto-complete feature of the browser address bar. In this case, while viewing the page I tapped the address bar and started typing the name of my new bookmarklet. It helps that I remembered this, otherwise it might have taken more time.

Typing the name of the bookmarklet into the address bar as it shows options from auto-complete. Once the bookmarklet fires I can see the comment replies.
Typing the name of the bookmarklet into the address bar as it shows options from auto-complete (first image), then once the bookmarklet fires I can see the comment replies (second image). Both images are current version of Chrome on Android.
This allows you to use bookmarklets you have specifically crafted to improve your mobile experience, or just general bookmarklets that you might not have thought would work on mobile.

Related

Fix Medium Bookmarklet

Hopefully by the time your read this Medium will have fixed the issue. If not, here is the bookmarklet I use:

javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('.overlay{display:none !important;}',0);})()

Of note: after you do this, the hit state of the View n replies link is partially blocked. You need to tap at the very top of the link. If that requires too much precision, then zoom in until it it wraps to two lines and tap the top line of text.

What I Was Reading on Medium

Christian Heilmann wrote a great post on the web application myth, which may be the title, though I can't be sure because Medium's URLs never match what may be the page title, which is denoted by an h3 because there is no h1 nor h2 on the page...

Anyway, regardless of title, go read what I'll title The Web Application Myth: Web applications don’t follow new rules.