I came across a situation recently where a JavaScript widget didn’t ‘work’ on the iPhone. It did technically work, but without knowing about two-fingered scrolling (and when you need to use it), it didn’t appear to work. So how do you differentiate the iPhone (and other touch based devices) from a regular browser?
Well, we all know object detection beats browser detection, but what object would you detect?

The issue in this case was with the Stylish Select jQuery pluggin. It replaces a standard drop-down with a nicer looking one. It is reasonably accessible as well, supporting keyboard use.

However, it creates a div with overflow of auto and a fixed height, which in desktop browsers creates a scroll bar. In the iPhone, it looks as though you can only select the ones that are initially visible, because there is no scroll bar.

In this case there is a nice fall-back: the select box that the JavaScript is replacing. The iPhone (and I assume other mobile browsers) show this in a system-native way.

So the question becomes how do you detect that a touch-based device is in use?

The solution came from this article on Detecting event support without browser sniffing, however, it does more than I was looking for, and wasn’t aimed at touch based detection.

I put together a little script that so far, seems to do what I’d like:

function isTouchDevice() {
   var el = document.createElement('div');
   el.setAttribute('ongesturestart', 'return;');
   if(typeof el.ongesturestart == "function"){
      return true;
   }else {
      return false
   }
}

Currently this script gives good results for:

• IE8 / Win (no event detected)
• FF 3.6 / Win (no)
• Chrome / Win (no)
• iPhone 4.0 (yes)

I originally picked ontouchmove as a fairly advanced touch event, but Google’s Chrome started firing for that event. I’ve moved to ongesturestart which works for now, but may also be used in Chrome later.

If you have another device or browser, please try the test page and let me know the results.

Joel Spolsky – Keynote

Joel’s keynote was on the theme of simplicity vs power, or rather, the third way.

I’m afraid that this is my interpretation entirely from memory, but essentially:

• A couple of fundamental assumptions are that users do not like to make decisions, and that just about every design decision should lead to the user being more likely to get laid.
• There has been a great upswing in simple interfaces, at least partially lead by 37signals. (Perhaps another contributory factor is the rise of internet applications? Services that can do one thing well.)
• However, some types of commercial applications (e.g. bug trackers) will need to cover the 80% of features that aren’t covered by these ‘simple’ applications. Alhtough 80% of people use 20% of the features, they are often different features. Otherwise you are cutting off too many people.
• Creating elegant code often takes more time and thought that simply typing out standard code. NB: Elegant was defined as doing things well, and making it look effortless.
• Creating elegant interfaces also takes more work, both in creating the UI and often more so in the coding behind it.
  A good example is the Amazon one-click. When you move form the (standard?) method of click, then confirmation screen (then rest of checkout process), you suddenly have more work to do. For example, queuing the order (in case they order more things), allowing undo within a certain time, making sure there’s a default address etc.
• Rather than not adding features to keep an interface simple, keep it simple by not forcing the user to make decisions. The interface should certainly start simple, but allow it to be extended, perhaps on a per client/site basis.

Joel’s assertions certainly match my experience with Content Management Systems, which are probably the hardest and least solved programming / interface problem. Whilst 37Signals have been very successful, I don’t see them tackling CMSs any time soon…)

Michael Sparks – Python

Michael essentially took us through the finer points of Python by demonstrating how you can create the Google-style spelling match function, in 21 lines of code (plus a few books worth of content in text files).

It was really good to see an expert use the Python interpreter well (including running into a couple of problems, and solving them). I’d never really understood how you use it for complex functions before, for example,  indentation matters in Python, and you put it in a command line?? Anyway, that explains the spaces being preferred to tabs thing, and it will certainly help in my dealings with Django. Hopefully Michael can post something about it soon, in the meantime the code is available.

Joel Spolsky – Fogbugz

We had plenty of Joel time today, this was his demo of Fogbugz, where it’s a disservice to describe it as bug-tracking software. It’s obviously modelled on Joel’s copious experience in developing software, and includes things like Bayesian driven email direction, and predicting launch times better than developers. I’m not sure it would work for us (juggling 15 web projects at the same time), but it will certainly make me wish for more next time I look at Trac or Bugzilla.

Reto Meir – Android

I have to admit, the technical side of mobile application development (rather than mobile web development) is still pretty intimidating for me, and doesn’t particularly float my boat. Reto also needs to either increase the font size in Eclispe, or use the ‘only when the cursor reaches the edge’ settings in OS X’s accessibility preferences.

From doing previous presentations I’ve learned the hard way to:

• practice it at 800×600 resolution,
• check it in 1024, and
• even if the projector supports more, keep it to 1024!

On the positive side, it was good to see some use of Google moderator. Not only does it make it easy to ask questions (and for people to vote up the best questions), Reto answered the top ones on the spot, and has since answered them all.

Remy Sharp – jQuery

Remy gave good talk on jQuery (presentation), something I’ve used quite a bit. It was great to include how to creat a plugin, and it explained a few things I’d seen around but didn’t understand. I liked Remy’s approach to the brief of using code,

The things that most interested me were:

• Having looking up “equality without type coersion” (the triple equals).
• jsbin.com looks like a very useful service.
• There’s a good IRC channel for getting help.
• How to add a plugin to jQuery.

Jeff Atwood – Stackoverflow

Jeff’s talk was less on code, and more the experiences around Stackoverflow, I can’t remember of it much specifically, but after listening to lots of podcasts it’s good to put a face to the voice!

Pekka Kosonen - Qt

Pekka’s presentation on Qt was intriguing, partly for the upfront honesty (tackling people’s scepticism about platforms from Nokia), and partly because of the possibilities of Qt.

Although Nokia was presenting about Qt, the platform itself is not originally from Nokia, in fact, it is designed to build cross-OS applications, desktop and mobile. Applications such as Skype and Google Earth have been built with it, so it seems that it can produce native looking applications.

It looks like you have to go whole-hog into Qt development, it’s an SDK, IDE and they may even have server-side compiling of code to for platforms you don’t have. The demo wasn’t incredibly convincing, but it does seem like a an option to investigate if you need to develop desktop/mobile applications across several platforms. See also getjar.

Phil Nash – iPhone

Phil’s presentation on iPhone development wasn’t quite what I expected, it took us through a short history of the language that iPhone development uses (Objective-C), before creating a little app from scratch. Phil’s dry sense of humour and occasionally cheesy slides helped make the first half more entertaining, especially as I wasn’t really target audience and haven’t quite got the different versions of C straight yet.

The outline of Objective C drew a few gasps: garbage collection? It seemed most of the audience are used to higher level languages, and Objective C seems like a step backwards.

However, the impression was improved a great deal once Phil opened up Xcode and put together a quick application. Phil was the only mobile developer who managed this. As well as the support of the IDE, emulation is obviously easier for the iPhone than Android or Qt, because you’re targeting a much more narrow range of devices.

Jon Skeet – Humanity: Epic Fail

The ‘phenomenal’ Jon Skeet presented a very funny look at why programming is generally hard, based on a rant he had recently about time zones. There isn’t much for me to say on this, but it’s worth checking out the presentation and audio on the Stackoverflow podcast soon.

Paul Biggar – How not to design a scripting language

I hadn’t really expected much of this talk, essentially what’s wrong with modern compilers, however, Paul’s enthusiasm really carried it.

Christian Heilmann – Yahoo! Developer Tools

For me the best was saved until last. I haven’t seen Christian talk on this before, and despite reading about Yahoo! pipes and YQL, I just hadn’t really groked it before.

It doesn’t really hit home until you see someone put an example together in front of you, but the upshot is that there are about a 100 APIs (everything from Amazon to Weather) that you don’t need to read.

You select a data source from the right of the console, adjust the ‘selector’, the YQL statement top left, and preview the results in the middle.

If the result is good, then copy the URL from the top right box, and use that with your backend (or ajax/ajaj), and hey-presto.
Example uses are:

• Showing all your disparate content on other sites in one place, for which Christian’s site is a prime example. It’s basically built with YQL, virtually all the content is from other sites! (Presentations, videos, books, blog articles etc.)
• YQLAutoTagger – automatic tag generation with a single line of JavaScript.
• Translate tweets.
• Create a set of Flickr photos from a particular geo-location.
• You can even scrape HTML for redisplay, narrowing the area using an xpath statement.

It uses a SQL like syntax to allow a great deal of granularity, both in terms of filtering things to get just the information you want, as well as using several input sources (URLs) at the same time.

I am not closing the YQL tab I have in Firefox until I’ve used it somewhere! I think this is the closest video on YQL I’ve seen that covers the same content.

Josh Lioncourt spoke to Apple‘s Mike Shebanek about the new features:

Understandably, a device as small and compact as the iPod Nano hardly has the processing power to generate text-to-speech (TTS) on the fly… iTunes taps into your Mac or PC’s processing power to generate tiny audio files for the various menus, artists, album, song titles, in your library. When you sync, that information is sent to your iPod Nano 4G.

I wondered about this a couple of years ago based on the patent for the technique, I guess it took quite a while for the various parts of the puzzle to come together. I can see this getting quite widespread use outside of the accessibility community, as it’s a general feature that suits the click wheel very well. Not so with the touch screen, for obvious reasons. You could even produce a Nano-shuffle hybrid that has the click wheel but no screen.

ars technica covered speech in the new Nanos as well:

you have speakable items set up on your computer, the nano will inherit the voice you chose to use. It’s unclear whether this feature will also be part of iPod touches and iPhones.

It seems that the aspects of voice inherit from your system setting. I hope that simply adjusting the speed doesn’t require a whole new batch of the voice files though? Adjusting the speed is quite easy with Voiceover, and I do that every so often. (NB: I am sighted, I just like using Voiceover sometimes!)

Apple have also been active in the Windows accessibility world, working with GW Micro (makers of the Windows Eyes screen reader) to make iTunes 8 accessible for that screen reader. I don’t know that they worked together, but considering the more widespread JAWs wasn’t included, it’s the most likely explanation.

And finally, Apple have published accessibility information in an easy to find place. Most of it seems good, and it’s definately good that Apple has taken the step to actually publish this, however, I couldn’t help feeling that the iPhone page leaves a lot unsaid.

It finished with a link to the “User Guide tagged for screen readers”.  Um, no one who needs to use a screen reader is going to have any luck with the iPhone at this stage!

The site was using Internet Explorer’s conditional comments to overcome some limitations in IE, and a reverse conditional comment for non IE browsers:

<!--[if !IE]> <-->
        <script type="text/javascript" src="scripts.js"></script>
<!--> <![endif]-->

Unfortunately, when sent over my mobile connection (Orange) the page is reformatted, even though I’m only using it as a modem. The file is stripped of line breaks, and that comment comes out as:

<!--[if !IE]><-->
  <script type="text/javascript" src="/scripts/basic.js"></script>
<![endif]>

Missing the close of the comment, the strict display mode triggered by the mime type means that only an XML style error message is displayed.

I guess this has to be added to the list of issues (such as user-added content) that makes an XML mime type difficult to manage?

Standard mobile GMail

I was quite happy with the standard GMail on my mobile (a Nokia N80), it was quick and reliable:

It wasn’t just better than the free webmail client I had used (which, to be fair, was aimed at desktop browsers), it was also better than the phone’s inbuilt email system. When using two different computers (on two platforms) as well as a phone, I need server-side storage so IMAP has been my method of choice. Unfortunately, the inbuilt email on the N80 doesn’t handle that very well.

So I was happily using GMail on my mobile, and then I noticed a Get faster GMail link at the top of my inbox. Speed? Hmm, it was already quick. I was suspicious I might end up downgrading my service!

However, it turned out to be speeding up the interaction, not raw speed.

Java based GMail client

If you have a Symbian S60 phone, you will get that link and you can download the 111k GMail client.

The data is similar, heck, even the display isn’t that different:

However, what makes this about five times better in use, is the menu.

What do you do with email before even reading them? In my case, a few spam still get through, so quite often I have to send a few emails to the trash immediately. If you haven’t set up filters for some things, you might want to send them off to the Archive immediately as well.

With a web based interface, the best approach you could have would be to include tick-boxes by each email, and then go to the bottom (or top) and perform an action on the selected emails. But the GMail client makes this even easier:

Each common action is not only available for each item as you select it, it is available via an ‘accesskey’.

Don’t get me wrong, I still think accesskeys are not useful on the web at large, but for a platform-specific application like this, they move the interaction from sluggish to slick. The interface also makes these keys discoverable, although I do wonder if people might think the number next to each email is a short-cut?

With GMail’s standard ‘conversation’ convention, where replies are included within one page (like threading in traditional email clients), and it’s well implemented hiding of quoted text, your inbox just feels less cluttered. It is also the first time I’ve felt a little stirring of convergance, I’m using the same interface (or as near as) on different devices in different contexts.

The only press release I could find on this was on the Nokia forum… Uh oh, this is starting to sound like an advert, this doesn’t mean I’ve forgiven Google for using CAPTCHA, and for some reason it’s dropping emails to me from my blog.

Now if only I could sync my phone’s calendar with my Google calendar…

Technorati Tags:

• mobile
• email
• symbian
• gmail
• nokia
• google
• convergance

In the same way that we (i.e. web developers) can deal with JavaScript or not, but not a Frankenstein monster in between, so it is with CSS in the mobile world. This is my home page rendered by the default Nokia/Orange browser (apologies for the poor pictures):

Not too good, mostly because it understands the @import but does no better than Netscape 4 in rendering CSS. There is little you can do about it in practice, apart from perhaps create a different version for each of the 40+ different mobile user agents, trying the futile dance of user-agent detection.

New league of mobile browsing

There are two new mobile browsers that confound the generally dire opinion of mobile browsers. Jon Christopher highlighted the first in August, the Opera Mobile browser. Relative to the other mobile browsers, this is practically desktop quality.

In terms of rendering, the Opera mobile browser is pretty damn good, in ‘Desktop’ mode it is very similar to the desktop Opera browser but with scrolling:

The default mode is actually more useful in practice, it re-formats the page to fit the screen width:

With my shiny new Nokia N80, I can use either the Opera mobile browser, the Opera mini, or the new Webkit based Symbian web browser that uses the same base as Safari. (Using any of these will drain the batteries remarkably quickly, but that’s another story!)

The Webkit browser also renders my home page very well:

This simple fact puts both Opera & Webkit in a league of their own in mobile browsing, as my site was developed (quickly and easily) for desktop browsers, no thought was given to mobile browsers apart from hiding the CSS with an @import method.

Notice also that the Webkit browser uses a pointer, and the way you scroll around and use the interface feels very similar to using a screen magnifier on the desktop.

One of the main things the Webkit based browser does differently is applying a max-width to the items with text. Although it uses the standard desktop sytle layout, any element (like <p>s) is given a max-width of the size of the screen. In general this is very useful, and is a great compromise between Opera’s desktop and standard modes.

The easiest way to show this is with another of the Webkit browsers features, the page map that you can get to by pressing 8:

The red outline shows the screen size, and this view allows you to scroll through a page quickly to the place you want and start reading.

The browser must do some kind of thumbnail caching for each page, as pressing back brings up this type of picture, and you can cycle through them like the gallery’s carousel:

There are great features of both Opera and Webkit, after a brief use of each, my first impression is that Opera has better advanced features, and Webkit has the edge in the basic browsing mechanisms. Which one you might use will probably come down to personal preference, or the price tag of each. (Opera is available on many phones for a price, Webkit is only available on a few, but is the default browser when it is.)

Mobile browsing paradigm shift?

“Paradigm shift” isn’t a phrase I’ve used before, but these browsers do break the mold. I saw Cameron Moll‘s presentation at @Media this year (a good primer is Mobile Web Design), and he suggested that good mobile sites or applications should assume that the person is mobile, not just the browsing, and that the tasks and content possible should be oriented towards that scenario.

I agreed with his conclusions, they are something that you would expect to hear from a usability bod like myself. However, these browsers afford easy reading, even articles like this! I’ve been using the Webkit browser for a couple of months, and whilst stuck on a train or on holiday without a laptop, I can follow my usual browsing habits. (I.e. reading articles, checking webmail etc.)

One of Cameron’s 4 mobile development options is ‘do nothing’, and the quality of that option is now a whole lot better. I even (just about) managed the AJAX style drag and drop of the items on my google home page! That might be an unique advantage of Webkit, as other mobile browsers do not have a pointer.

These new browsers do not change the scenarios where the mobile web is most useful, but they do add a scenario of use that is more similar to desktop browsing. It is entirely possible that only the first-movers or web-geeks will notice though? Although the Nokia N80 is on the forefront of mobile phones with computing power, you have to wonder how long it will be before this browser is standard?

The Opera browser makes use of handheld media style sheets in the standard fit-to-screen mode, but not when in desktop mode, which makes sense. It’s just a shame that you can’t target the Webkit mobile browser (that I know of), items like the boxes on the Nomensa.com home page are somewhat crushed due to the max-width. (Although the JavaScript ‘big hit area’ works fine.) Out of interest the user agent string is:

Mozilla/5.0 (SymbianOS/9.1; U; en-us) AppleWebKit/413
 (KHTML, like Gecko) Safari/413

Technorati Tags:

• mobile
• browsing
• symbian
• opera
• nokia
• web development
• CSS