Opera Mini: the Nokia browsing experience, now on iPhone.

Essentially, Opera Mini doesn’t feel at all like an iPhone app. The gestures are all wrong to varying degrees, the interface is jarring and detracts from the pages you’re trying to view, and it’s not fast enough (its main selling point) to justify using it over Safari (particularly given the myriad interface oddities).

Gestures

Scrolling

Let’s start with the most basic interaction we have on iPhone: scrolling. Scrolling on iPhone is fun. iPhone uses inertial scrolling; it employs real-world physics to make scrolling feel like you’re interacting with something physical with weight and friction. People sit and endlessly scroll back and forth through their lists on iPhone because it’s so tactile.

I have to admit, I spent about five minutes simply scrolling around in Opera Mini. Not because it was fun, mind you, but because it felt so badly wrong. In Opera Mini, scrolling doesn’t accelerate or decelerate in the same way as elsewhere on iPhone, or bounce back when you hit a boundary.

But then again, sometimes it doesn’t do that: sometimes, it slides at a constant rate until it stops and then jumps in the /opposite/ direction to your gesture and scrolls a little bit in that direction. Not because it hit a page edge, though (those stop scrolling dead, mostly): these reversals tend to happen just when you think you’ve got the measure of scrolling in Opera.

Then there are the invisible pseudo-boundaries Opera puts into the page: if you’re within a column in the page you’re looking at (the sort that double-tapping in Safari would fill the screen with; more on that later), Opera will put a scroll boundary around that so that flinging the page across hits that boundary and stops or, more likely, scrolls a little further vertically. I suspect these boundaries are what cause the aforementioned changes in direction, come to think of it.

Zooming

So what about the other most common gesture in Safari? Zooming in Opera is a little like scrolling: it feels like a first-cut demo that you’d get if you described how an iPhone does it to someone who had never used one, then had them build their own.

Opera Mini has two levels of zoom: in, or out. In Safari, if I want to zoom in just a little, I can zoom to exactly the level I want. I have full control. In Opera, if I’m zoomed out and pinch in either direction, for any distance, I get zoomed right in. If I’m zoomed in and pinch at all, I get zoomed out fully.

For a time, I thought that double-tap-to-zoom (in both directions) didn’t work in Opera Mini. As it happens, it does but you have to tap in exactly the same spot for both taps, or Opera considers it a scroll instead of a zoom. Unlike Safari, double-tap doesn’t zoom in on the content you tapped to fill the screen’s width, though: it simply zooms you all the way in where you double-tapped.

But that’s OK because you can single-tap to zoom in. Yes, you read that right: single-tap when zoomed out zooms you in. Know the site you’re visiting well enough that you know exactly which link you want to click on as soon as you see it? Well, tough: you have to zoom in and then click the link.

What if I want to focus on a picture that takes up two thirds of the page? I either have to look at it one bit at a time, fully zoomed in, or as a thumbnail when zoomed out.

Also: since when is zooming a browsing operation? If I’m zoomed in, why does pressing ‘Back’ zoom me out? Why can’t I just navigate back to the page prior to the current page?

Text selection

Remember the days when iPhone didn’t have copy and paste (or text selection), and how Apple’s solution seemed to fit into the OS so naturally?

Opera doesn’t. If you try to select text by pressing and holding when zoomed out, you get zoomed in (or maybe scrolled). If you try to select text when zoomed in, a spinning cursors orbits your fingertip for a few seconds and, sometimes, presents you with a popup menu. Unless you’ve lost your internet connection since loading the page, in which case it doesn’t.

Typically, this menu offers simply ‘Select Text’. If you press-and-hold on, or near, an image, the popup menu offers, in addition to text selection, the option of opening or saving the image, as you’d see in native image selection popover dialogs.

So you click on ‘Select Text’, and a serifed bar cursor (rather than iPhone’s native slab bar cursor) is inserted where your finger was. You then have to click at the beginning of the text you wish to select, and drag to the end.

Sounds like iPhone text selection, right? Wrong: you get no insertion-point loupe like you would elsewhere on iPhone, making precise selection impossible. Made a mistake in your selection? You have to deselect (by clicking away from the popover offering to copy, search, etc.) and start again.

Interface & rendering

Opera Mini really seems to have an inferiority complex.

Whenever you’re using it, the interface screams ‘you’re using Opera!’, detracting from the web pages you’re trying to read. For starters: I know I’m using Opera Mini. I clicked on the app icon on my home screen, so I really don’t need to see Opera’s logo for my entire browsing session. Sure, this is subtle and in the title bar, but it’s another un-iPhone-like touch. Worse, this title/branding bar is fixed and never leaves the screen , regardless of where you scroll.

The branding, though, pales in comparison to the ‘look at me!’ colour scheme. If I’m using a web browser, I’m using it to look at web pages. This means browser chrome should be kept to a minimum, fade into the background, and be relatively low-contrast.

It does not mean that you should make the browser chrome black and red stripes around the web page I’m trying to use. Red and black is high-contrast and, thus, attracts the eye to it. If I’m using Opera, this means my eye is drawn away from the sole reason for me using the app.

This, of course, is ignoring the fact that Opera commits the ultimate faux pas: it uses iPhone’s light status bar instead of the black status bar, despite most of the app’s chrome being black. Whilst we’re looking at visual faux pas, the settings interface is awful, using completely custom controls for everything.

All that said, there is one piece of Opera Mini’s interface that is quite nice: the tabs. Where Safari shuffles you off to a full-screen tab switcher, Opera Mini slides a pane up from the bottom of the screen with small snapshots of your tabs stacked on top of one another, with the active tab frontmost. It’s not worlds ahead of Safari’s implementation, granted, but it’s a nice differentiator.

Speed, privacy, and JavaScript

I mentioned at the outset that Opera Mini isn’t fast enough to justify using it over Safari. That’s not to say it’s not faster than Safari in terms of raw page rendering speed. The problem is that the difference in speed isn’t significant enough to justify using it over Safari, particularly when you take into account the cognitive dissonance required to use it on iPhone. Sure, the page renders a second or two faster but, if it takes you an extra half-second to second-guess everything you do, what’s the point?

This speed-boost is achieved by Opera’s servers downloading, rendering, and compressing the requested page into one bundle, then passing that back to the user’s browser. On older phones this was a boon because they were underpowered enough that rendering HTML and CSS was a significant overhead. On iPhone, sufficient processing power makes performance increase from offloaded rendering moot, but the connection-and-compression optimisation can still be a significant benefit over slow EDGE and GPRS connections.

On top of that, there’s the matter of privacy: with all the data going through Opera’s servers, you have to trust Opera. If you’re just checking the news or weather, that’s no big deal. The idea of checking email, or doing mobile online banking, through Opera Mini and, thus, Opera’s cache servers (even if nothing is cached) concerns me.

And then there’s JavaScript. Opera Mini doesn’t support JavaScript. Except where it does, which tend to be the most inconvenient places. Yahoo! Finance News, for example, sports a number of progressively enhanced personalisation features. If you visit the page in Opera Mini, it executes the first-run JavaScript but disables any further JavaScript-enhanced interactions.

It seems that Opera Mini runs JavaScript on the server such that pages are progressively enhanced, then delivers the rendered page to the client. For any progressively enhanced pages that hide the non-JavaScript interactions when they’re not needed (read: most of them), this will mean that Opera Mini users get a broken experience.

On the plus side, at least the JavaScript experience matches with the rest of the Opera Mini for iPhone experience.

It uses (and complements) my Fire Eagle API binding to wrap up the process of authorising your Django application with Fire Eagle into little more than pointing your users at a URL and setting them free.

For the third year running, now, I’m on my way to Austin, Texas for SXSW.

Past

The first year (2006), travelling with Fatty (whom I had met but once before), was an incredible experience. I got to make lots of new friends and, generally, learn a huge amount and have a brilliant time.

Fast-forward a year to 2007 and Fatty and I were joined by Ben, and I got to share a room with the inimitable Faruk. There were lots of complaints, from others, of the conference becoming too big for its own boots, of too many panels with too little content, and so forth; generally, there seemed to be an air of malaise about SXSW.

Socially, for me, it was bigger and better than my first year: I went to more parties, spent time with more people, and generally made more friends than in 2006. It was good.

Present

I fully expect this year to continue that trend given that, at the airport this morning, Ben and I (alas, no Fatty this year) bumped into Stuart Colville before we had even checked in, Paul Duncan over breakfast, Cyril Doussin and Tristan Turpin (who, along with Stuart, are on the same flight as Ben and me) just after breakfast, and Gareth Rushgrove in the departures lounge.

All this, mark you, before we had even left Gatwick Airport.

Granted, this was aided in no small part by the magic of Twitter (and generally being better acquainted with more people in the web scene), but there was also a certain amount of serendipity thrown in for good measure, too.

Near-Future

Compared to the last two years, my aims have ever-so-slightly changed, too. Rather than, as last year, placing the focus on attending sessions and parties, my focus this year will simply be on “am I making the most of this time?”. I intend to be rather mercenary about this, in fact: last year and the year before, there were times when I stayed at a party for fear of not knowing anyone at another. That shan’t happen this year.

Further, I intend to be very much, to use an NLP phrase, “in the moment”. Also, in a change to normal programming, I shall be drinking alcohol (although hopefully not to the levels of excess seen at d.Construct 07).

The biggest change, though, is that I shall, finally, be attending SXSW music. The past two years, I’ve lusted after that extra week of partying and gigs (and envied Keith horribly when he’s stayed on); this year, I get to partake myself (along with Ben, Alex Lee, and Lindsey Mooney). Not only that but, thanks to contacts in Yahoo! Music UK, I may have wangled access to closed recording sessions for Yahoo! Music with Ben, Alex, and Lindsey.

I’m looking forward to it all more than you can possibly imagine.

In a flustered, last-minute, push to get the Fire Eagle Python API binding ready to ship, I had to switch it to use HTTPS (and point to fireeagle.yahooapis.com, natch).

Given that I’m relatively new to Python, it took a moment to realise I had simply to switch from httplib.HTTPConnection to httplib.HTTPSConnection. This would have all been fine, save one issue: apparently, the otherwise wonderful MacPorts doesn’t appear to link OpenSSL in Python by default (which, naturally, is a requirement for HTTPS).

Without OpenSSL linked, trying to use HTTPSConnection (or, one would imagine, any SSL-related task) results in an error akin to AttributeError: 'module' object has no attribute 'ssl'.

To rectify this is, actually, very simple: run sudo port install py25-socket-ssl in the Terminal (assuming you’re using Python 2.5: other versions of Python will require different ports).

Good, innit?

For those of you that don’t quite get it, the point is that it’s a central location-brokering service. You tell Fire Eagle where you are (or set your devices and web apps to tell it), and other applications can, if you allow them, use that data in fun and interesting ways (think auto-geo-tagging of photos on flickr, or mapping where your friends are, to name the most obvious).

Anyway: Fire Eagle really caught my attention and, thanks to my friendship with the lovely Mr. Coates, I got to play a little with its API before launch. Whilst it’s not quite finished yet (the methods to find users of your application within a given area, within, and to find recent location updates from your users, recent, are not there at the time of writing), the API and, indeed, website are decidedly lovely.

The website is friendly, playful, and takes all the hard edges off of the concept of using a web app whose sole purpose is to serve other applications and widgets. It has non-awful markup and CSS (although there are a few things I might quibble with in a code review). The URLs, though…

Oh, the URLs! Whoever came up with the idea of allowing http://fireeagle.com/my/location/is/Austin%20TX (or, indeed, any other location, but Austin, Texas is particularly apt for me right now) is an evil genius after my own heart.

The API has had as much care and attention as the web interface, though: no method is out of place, everything accepts what you’d expect. What’s more, it uses OAuth for authorising third-party applications to access user data (and Fire Eagle allows you to specify what level of granularity you want to allow per-application), so even that is positively simple given the existence of libraries to deal with OAuth for you.

If it all still seems like too much hard work to implement bindings for the API in your app, that’s been covered, too: there are bindings for Javascript, PHP, Ruby, Perl, and even one for Python written by yours truly.

I intend to spend a sizeable chunk of my time over the next few weeks playing with Fire Eagle, both updating my Python API binding and hacking around with various ideas I’ve had for fun, useful little apps using Fire Eagle data.

Now, where was I?

As I approached she perked up, attentive to my presence, a youthful exuberance in her eyes. My hand lightly touching her side, she drew me closer. As I pushed all the right buttons, she progressed from a quiet whimper to an excited, throaty purr.

I still don’t know her name. Her number, though, is 368 of 500.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

This sentiment is just as true for markup, style, and behaviour on the web. The trick, though, is to find the optimal balance between the four.

Markup

When building a page, one should assume nothing: mark it up in the most minimal, sparse way possible whilst still maintaining a logical structure.

No classes. No ids. No divs or spans. Just pure, semantically rich HTML elements.

Next, divide the page into major logical divisions using divs with apt ids. Use classes to identify patterns used throughout the page (cf. Microformats). At this stage, one should be adding semantic context as minimally as possible.

Further, this context should be added at the highest level in the DOM that is appropriate, and no higher. For example, an ordered list of blog posts should not feature a class of post on each list item; rather, the list itself should have the class posts.

Remove redundancy in all aspects of the markup. Consider different choices of elements, even if they seem unfit for purpose.

If, at the end of this process, it seems like the document should be easy to style accordingly then there are probably too many styling hooks, in the form of non-semantic classes, ids and elements, in place already. Go back and think about everything once more. Make every element and attribute justify its existence.

By this point all functionality of the page, be it part of an application or straight prose, should be exposed and fully usable.

All of it.

If there’s a single piece of functionality that you feel you can’t provide in raw HTML, you’re doing it wrong.

This doesn’t mean the interaction has to be as rich as it might be, but it should be usable.

Style

As with the markup, styling should be approached by using the most simple approaches possible to achieve the desired look.

The styling shouldn’t obfuscate any functionality: everything should still work as intended.

Avoid adding extra markup at all costs. If it seems that extra markup is necessary to aid styling, consider that the approach being used to acheive the style is the wrong one.

Behaviour

Finally, enhance the behaviour as necessary. As with styling, consider that the desire to add to the DOM (either before or during the life of a script) could be a sign that the solution is not the optimal one. Similarly, if styles must be added before any interaction occurs, separate them using some class high in the DOM tree.

If anything must be added, be they elements, ids, classes, or styles, add them at the latest possible instant and promptly remove them when unneeded. When applying behaviour use, as far as possible, already extant semantics for context.

Further, if the behaviour relies on styling to justify its existence, it may need rethinking.

Throughout all three, one should attempt to focus on the smallest area possible at a time. Break the document into its requisite parts, developing these in isolation from one another and the framework to bind them together.

Above all: if you’re not finding it hard, and agonising over it, you’re probably not doing it right.

Whilst I don’t intend to mimic his goal (I already get up at 6:30am thankyouver’much), I have a habit of not doing things (posting here, writing for Web Typography, exercising, and the list goes on) for similar reasons. I bemoan a lack of time, a fear of failure, a lack of knowledge… Anything, in fact, to excuse myself from doing things that might challenge me and require me to put effort into something.

So, to echo Ben’s sentiment:

This week, I’m taking the “don’t be so pathetic” method to not being shit at stuff.

Vote for it, you know you want to!

It must be the best solution, mustn’t it, if all these sites use similar techniques?

The objective of my affection

If we step back for a moment, to examine the user’s needs, we can see two objectives for the average searcher: find something and [perhaps] make it of this type.

The ‘something’ for which the user is searching is, in their mind, the foremost concern. Everything else is secondary. When searching, a user’s first instinct will almost always be to enter their search terms (and why should it be otherwise?). Everything about a search interface is geared toward this: the keyword input has the most visual weight on the screen — on a typical search index page — and the most prominent position — either near dead-centre or in the head of the page, depending on the type of page.

The accepted solution, happily, cedes to this under all circumstances.

The second objective, then, is the type of results that will satisfy the search. The introduction of this second objective is where user behaviour will begin to deviate: depending on their priorities and personal inclinations, users’ execution of this may take place before, after, or even during the steps to meet the primary objective. Unlike the emphasis placed on the keyword input, the type of results to return should be — and, typically, are — de-emphasised where possible, but be present — and have their presence known — should the user require them (either to confirm their beliefs or to make a change).

Humbled

But the accepted solution only pays lip-service to this more complex interaction: for any user without JavaScript, the only acknowledged paths for them to change the channel in which they are searching is to select it before they begin their search or, assuming that the search engine alters the links based on the latest query, directly after (and before they attempt to manipulate their search further).

By using JavaScript to bludgeon links into selecting from a choice of mutually exclusive channels, the user experience of what should be a simple search form is broken for many users when they attempt to interact with it in a way that seems natural to them. To compound this issue further, the use of links means that screen reader users may never be able to use this functionality, as links within the form will never be announced when they are entering their search terms.

The problem is that whomever has implemented these solutions (or their forebears) had the mindset of ‘HTML is static, JavaScript is dynamic’ — or simply didn’t care enough to question the accepted norm — and so overlooked what was staring them right in the face: HTML already has a perfectly good input device for selecting one and only one item from a collection:

The humble radio-button.

Given a little semantic markup and CSS (with a smattering of JavaScript to add extra styling hooks), it’s entirely possible to style a group of radio-buttons in a more visually apt way to indicate that it is filtering the search input, whilst offering a far more interactive experience to all users of the site, not just those with JavaScript.

So I did.

That’s what you can see in action on the new Yahoo! UK and Ireland TV (along with France, Germany, Italy, and Spain).

Implementation notes

As noted above, the main components of the form are a list of radio-buttons, a textbox, and a submit button. Of particular note is the way the radio-buttons are scripted and styled, and the structure of the radio-button labels relative to the form’s <legend>. Further, implementing the search this way requires that the server-side script be able to handle the new field being passed its way appropriately.

Scripted style

For all users, the core functionality of the radio-buttons is available, with these styled as an inline list for users with CSS enabled. The JavaScript, when enabled, will simply add a class to the root of the list, along with an extra <span> to allow styling of the labels in accordance with the design. When the radio-buttons receive focus the ‘selected’ class is moved to the new selection. This activity takes place on focus, mark you, and not click: click events fire on the originating control which, when navigating with the keyboard, will mean the previously selected radio-button.

A <legend> in its own life-time

It was brought to my attention that a form’s <legend> will, by default, be announced before each and every form field by screen readers. To make this as unobtrusive as possible, each radio-button’s <label> is worded such that it makes the most possible sense when preceded by the legend text. In English, for example, the radio-buttons will be announced as ‘Search… the web’, ‘Search… for images’, and so forth (where ‘Search’ is the form’s <legend>).

The radio-buttons’ full text, though, would not make sense in a visual context: they should be presented as tabs titled ‘Web’, ‘Images’, and so on. To achieve this, the visually inappropriate portions of the <label> are wrapped in <span>s and positioned outside the browser’s viewport — along with the form’s legend and the radio-buttons themselves — such that they may still be accessed by screen readers and the like.

Furthermore, because the radio-buttons are still present in the content of the page, keyboard users may navigate the form fully through the keyboard (using arrow keys to move between items radio-buttons in a collection).

Once again, this can all be seen in action on the new Yahoo! UK and Ireland TV (along with France, Germany, Italy, and Spain). [Links added at Mike's suggestion]

Thanks

I can by no means take full responsibility for the successful implementation of this concept, though: I’d particularly like to thank Norm!, Mike Davies, Alex Lee (our designer), Tim Huegdon, and Ann McMeekin (of the RNIB) for all their help, advice, and patience (particularly when I got things working and made lots of excited noises at them), and this wouldn’t have ever been a reality on Yahoo! TV for Europe if it hadn’t been for the receptive, responsive attitude of the engineers working on Yahoo! Search for Europe.