As part of the Readability 2.0 project, we’re trying a few different approaches to making text beautiful and easily readable on a mobile device in Firefox for Android. When text isn’t readable, most people think that increasing the size of the text is the answer to making it readable, and this is one approach, which we call “font inflation”. This technique is described (in probably excruciating detail) in a previous blog post 1. There are a couple of other approaches, though, that we’ve been toying with.
One solution is to offer users a “mini reader mode” – a pop-over or “light box” that contains the text, in a more readable format, which floats over the main page. Kats 2 is working on a prototype to show how this might work. The original idea for this was to have a floating box overlay the text in a given area, so that user could see both the box with the more readable text, but also the context in which that text fits into the underlying page by showing the page behind the box. The idea is novel and unique to Firefox, although it’s not clear whether this prototype is going to ship in a release yet or not. In any case, Kats’ prototype is really beginning to demonstrate the possibilities of this approach to improving readability.
Another approach is the “reflow on zoom” approach. Basically, the idea here is to reflow the page as the user zooms in, potentially narrowing the text frames in order to force text wrapping. This is a solution to the horizontal scrolling problem described in Font Inflation, Fennec, and You 1. The technical details of this aren’t incredibly exciting – I added an API for specifying the max line box width, which, when changed, generates a reflow event 3. This API is accessible from chrome javascript, meaning that webpages don’t have access to this API, only javascript used as part of the rendering of the browser itself (what we call the “browser chrome”, meaning the window decorations, the address bar, etc…). Inside of the browser itself, on mobile, I then specify the max line box width to be no greater than the width of the viewport (minus some padding so that text doesn’t go right to the edge of the screen). Currently, this is still a pretty rough prototype. There are a number of things that still need to be polished before it can be ready for actual use. You can see an example of what the prototype looks like in the following image, though:
 Article without any reflow-on-zoom enhancements |
 Article text with reflow-on-zoom (line box width constrained to viewport width). |
The problem I’m currently working on is a positioning problem. There are two methods commonly used to trigger zoom on mobile – a double tap gesture, and a pinch gesture. If the user double taps the screen, it will find the element associated with a particular point where the double tap occurred and then zoom in to this element. Unfortunately, this is somewhat less than ideal, since the whole point of the reflow on zoom concept is for the user to specify what the ideal zoom level is for her, then have the text wrap according to this width. Many elements are already almost as wide as the viewport, so enhancing them just a bit isn’t really a useful technique – we’re not actually increasing readability.
The other gesture, pinching to indicate the level of zoom, is more promising, but comes with its own set of difficulties. The biggest difficulty is that when the user zooms in to a particular rectangle, we want to maintain the position of the text she zoomed in to in relation to the viewport. When the reflow event happens after changing the line box width, the text moves a bit to the left, since the width of the element changes, causing it to no longer be centered within the viewport. This can be rectified easily using similar code in the double-tap gesture approach, but only if we can identify the element into which the user wanted to zoom. This is further complicated by the fact that pinching doesn’t have a single point to zoom in on like double-tapping does. Instead, it has a beginning point, several points as the user widens their fingers, and then a final point. These points appear to track the center of the line between the user’s two fingers. So, do we take the average of these points? The first point where the user’s fingers are close together? The last point, where the user’s fingers are furthest apart? As an additional problem, we might not be able to identify a specific element correctly – a DOM element might be too large of an area for us to use – perhaps we want something more like a piece of text to target.
All of these problems are solvable, but the prototype is still in the early stages. It’ll probably be many more iterations of this prototype before it’s finally ready for the prime time.
References
[1] Johnson, Scott. Font Inflation, Fennec, and You (2012). The Nothingness of Scott. Retrieved 31 August, 2012 from http://jwir3.wordpress.com/2012/07/30/font-inflation-fennec-and-you/.
[2] Gupta, Kartikaya. Readability 2.0 Prototyping (2012). Retrieved 31 August 2012 from https://staktrace.com/spout/entry.php?id=759.
[3] Bug 780258: Add support for max line box width API
« Font Inflation, Fennec, and You (Hopefully) Easier Firefox Building with JMozTools »
You don’t have to look too far as to what the experience should be. The baseline should be user experience similar to zooming in and out on iOS. Any incremental updates can be made once this, now de facto, experience has been accomplished.
The overall experience, yes. But reflow-on-zoom is not implemented by iOS Safari, only text size adjustment (what we call font inflation).
The best right now is opera mobile on android, reflow on zoom and double tab. Right now I can think of even another way to do it but complicated. If the text inflated would make the box bigger, let the box stay the same but when scrolling the page make the page itself scroll slower than the text, so the box stay with the same dimension but the more text is inside it. Like if the text is seen in a magnifier. It would be like the text scroll inside the box. I don’t know if that is possible but it’s an idea.
Interesting idea, AV. I think this is very similar to what kats is working on in his prototype. We’re certainly up for looking into it as a possibility. Thanks for the suggestion.
yes, it’s similar to kats, the difference is the overlay would be above the box. And scrolling it would also scroll (slower) the page and vice versa
You r so right Scott. When I enlarge the font on my firefox it flows outward and I have to keep moving my page to read the whole sentence or paragraph. So with that in mind..I try my best to read the small print.
I will not help, but i can only agree on the reflow-on-zoom solution. It’s really something missing on FF Mobile. I wish you’ll achieve this thing
We’re working on it. “These things” get accomplished faster if others help, though.
-_-’ if only … i’m just a poor web designer who don’t know anything about software dev … I got this post from a guy on a french mozilla help forum called http://www.geckozone.org/ while i was searching for information about reflow on zoom. What skills are required ? I could relay on the french forum.
Hey! I’ve been following your progress on this and I’m looking forward to finally seeing it implemented. I’d like to add my vote for doing it the way Opera Mobile does. Double-tap zooms in/out a fixed distance, and/or the user can pinch zoom in and out to refine the zoom level – the text dynamically re-flowing all the while. It’s easy enough for the user to keep their zooming centred on the text they’re trying to enlarge – I think the zoom just centres on the mid-point between their fingers. It might be handy if the page could be panned at the same time by moving both fingers around in unison. Resizing the text just doesn’t work in my opinion. Some elements get re-sized and others don’t. Look at the Ableton (www.ableton.com) website and forum with default Firefox settings for a good example. Some elements are nicely re-sized and others are way too small – only using the “tiny” font size provides a uniform looking page and that leads to too much pinch zooming and horizontal scrolling. This is one of the last issues which keeps me from using Firefox as my main Android browser. I can imagine it’s an issue for a lot of people. I have practically every Android browser installed and test them all constantly. Opera does have some really annoying rendering quirks (or maybe it’s websites targeting WebKit!), so if Firefox could take a few of the good things that Opera does, I’d much prefer to use Firefox. An option to put the tab switcher at the bottom of the page would be nice too. It’s so much nicer to be able to reach them easily with your thumb in one-handed operation. Opera and Boat do this well. I guess a toggle to put the urlbar/tab switcher at the bottom would do it. Is this possible through some about:config or userchrome-type adjustment, like on desktop Firefox?
Hi Conor:
Thanks for the comments.
With respect to putting the url/tab switcher at the bottom of the screen, I think this is a valid idea, and I would encourage you to submit your idea as a bug on bugzilla.mozilla.org. I don’t believe there is a way to do this currently, but I could be incorrect. Click on “File a bug”, then click on “Firefox for Android”, and put it in the “General” component.
With regard to the other inquiries you’ve made, we’re definitely working to get this into the product. There is an implementation that has landed in current Nightlies, so feel free to download Firefox for Android nightly build and test it out!