I’ve read a few things in the last week about Oxford’s Mobile App – mainly tweets about #ucisa10 and various follow-up blog posts – so thought I’d have a look. I am particularly pleased to see that their well put together and well received mobile provision is a web app rather than a native app or proprietary service offering.

Critically this development route and the technologies applied affords them every opportunity to improve, amend and react to criticism and suggestion both quickly and simply.

Even better, they’re using services such as Open Streetmap for their location services, various location code mechanisms and the supplemental use of QR Codes and barcodes.

Looking around the m.ox.ac.uk app site you find some interesting solutions.

For the Iphone and browsers such as Opera Mini (for Windows Mobile), they’ve re-used their homepage iconography to create short, meaningful breadcrumb navigation as you drill deeper.

The risk of lengthy trails is eliminated with the use of ellipsis characters ( … / …).

They’ve a desktop site for previews, information on data costs and usage. A very thorough approach.

More info’ about developments on m.ox.ac.uk can be found at: http://m.ox.ac.uk/desktop/#blog.

Skip to the Ten Things>>
The launch of the iPad has reinvigorated discussion on the use of small(er) scale devices. with particular interest from the UK HE sector. This may be partly attributable to meeting the technological expectations of students, as well as the constant problem of discovering just what they may be.

A discussion kicked off by Brian Kelly, the UK Web focus at UKOLN highlighted the appeal of Apple’s devices – in particular their UIs (discussion on just how revolutionary the iPad hardware is being beyond the scope of this post ) – and how they made some open source advocates think twice. The limitations of software sources (the App Store), the missing technologies such as Flash, and the pitfalls of the approvals process may be outweighed by the device’s promise.

The primary thinking on development for these devices is native, so discussion rarely looks at the most prevalent platform available to iPhones and iPads: The Web, plain old HTML.

This article on O’Reilly Radar was posted in a follow up to Brian’s topic and goes some way to explain the opportunities that Mobile Safari and HTML 5 offer, and what may be achieved when extend with Javascript libraries.

Apple have allowed web developers the techniques to ensure that web apps integrate with their devices as seamlessly as native apps. Home screen icons, full screen viewing, inline data loading, geolocation, offline data storage and multi-touch UI capabilities are all achievable using conventional web development techniques. They’re also very well documented on Apple’s site.

Ten Things…maybe eleven

There’s nothing new here, so if you’re familiar with the technology already there’s little to excite. However, reiterating these points may highlight just how accessible this technology can be for those in the front line of web-based information provision.

For more on the App vs Web App debate, take a look at earlier discussion on the QuirksMode Blog.

Below are a number of  features web developers can use right now on the Iphone and Ipod Touch to make their web apps run as smoothly as native ones.

1. Boomarking to the Home Screen

Once a user has visited your web app, they can choose to bookmark it. If they select to bookmark it to their device home screen, an icon based on a preview of the site will be placed there.

2. Use Custom Icons

If you don’t want a site preview for your icon, you can create and embed a custom icon in your HTML code which will be picked up when your web app is bookmarked to the home screen.

<link rel=”apple-touch-icon” href=”apple-touch-icon.png”/>

3. Use a Full Screen App view

A single line of code in your HTML turns a web site into an web app. Once a user bookmarks the page to their home screen, the developer is afforded the trust to run a web app full screen, with no Mobile Safari UI visible:

<meta name=”apple-mobile-web-app-capable” content=”yes” />

4. Keep things inline

Clicking on a link from your web app will invariably switch to Mobile Safari – but there are ways around it. See design decisions further down the page.

5. Extend beyond HTML

For Javascript support Mobile Safari can be treated very similarly to desktop browsers. You can use JQuery, Script.Aculo.Us and Prototype to your heart’s content. Additionally there are device specific events and features you can access, and dedicated libraries for Iphone development, such as JQTouch.

Using these libraries gives you improved control over the DOM elements for updating areas of your App page and makes data handling far simpler.

6. Use the Touch UI (and multitouch)

The Touch UI is available by default, but extending your web app with JQuery and the JQTouch plugin allows you to create multi-touch interactions such as scaling and rotating web page elements and even throwing them around the screen, should you need to.

7. Use Screen width detection

When the device is rotated, Mobile Safari will rotate the view accordingly, you can anticipate this in your CSS.

You can control how the screen behaves in terms of width, height and zoom properties using custom <meta> elements.

See the Apple Dev Centre guide to supported meta elements.

8. Use Geolocation services

As with other modern web browsers such as Firefox 3.5+, pages in Mobile Safari can request location information from a user. If provided this can be used to customise content based on location, putting custom maps,  location pushpins and  site-specific news alerts into the web developer’s toolkit.

This is especially useful to HE institutions with their need for Campus Maps.

Desktop Safari and Firefox 3.5+, and Mobile Safari all implement some if not all of the W3C Geolocation spec, so geolocation apps need only be written once for these browsers.

9. Use clickable Phone Numbers

Mobile Safari automatically makes phone numbers clickable. Embedding phone numbers in a basic <a> link can allow an Iphone user to start a call or send an SMS message with a click or to, just like the email Mailto.

<a href=”tel:11111111 “>Call now!</a>

10. HTML5 Canvas

It doesn’t have to even look like a web page.

Developed by Apple and now becoming widely adopted (a Google Code add-on, Explorer Canvas, ports most of the features to internet explorer too) the <canvas> tag allows scripting of vector shapes, the embedding and alpha transparency of images; repetition, scaling and rotation are all possible in page scripting.

This cuts server-side imaging libraries out of the loop for the data-driven site and brings code-based imaging and animation direct to web browsers, including Mobile Safari.

11. Cache In

Using the Iphone and Ipod Touch Caching capabilities, you can cache commonly used elements of your web app, such as the main User interface files and images. You can then control when they’re updated.

Additionally, you can cache data offline using the Javascript/SQLite databasing tools.

Safari Client Side Storage

Design Decisions – the app page

To keep a web app fullscreen it needs to stay on the one web page, and perform all subsequent data interactions using asynchronous requests.

By treating the one page as your bookmarked web app, you can supply data in RSS, JSON or just HTML over AJAX to update elements of your page.

You get to manage just one beautifully crafted home URL, cached with it’s component images and scripting, and link everything from it. Using a manifest file, you can then cache your UI on the device, so future loads are minimal.

What can’t be done

Web apps aren’t a panacea, there are of course things that you cannot yet acheive in Mobile Safari. Access to the accelerometer is currently unavailable, so shake actions, tilt detection and so on are out of reach, as are Apple push alerts.

How limiting these features are is dependent on what you’re trying to do, and what your user base expects. Custom tilt and shake actions are by their nature new functionality from the user perspective.Their appropriate application must be carefully considered by the developer and for end users how they operate must be learned or discovered, per app.

Screen interaction, for simple content delivery remains the most reliable and understood method of interacting with information on these devices.

Apple Push Alerts are again, limited in their use. The alerts notify the user with a short message, impressing upon them the need to launch the associated app to have it update with new information. The app can then be launched with click on the alert box.

However native apps, like web apps, do not update information in the background, they must be running on the screen for them to retrieve new data.

Conclusion

If there’s any conclusion to be drawn, it’s about understanding the technology and it’s appropriate application. There’s also the requirements of support availability, installation assistance, speed of updates and bugfixes to be considered.

If the above features are sufficient to deliver your content, then they also afford the opportunity to design and build killer interfaces to it, with just a few limitations.

More information on custom icons and web app configuration can be found here on Apple’s Dev site.

Of course if you’re thinking augmented reality, you might want to go native.

Work on the Course Finder has increased, now it has been positively received. I’m now working to improve the usability even more, and ensure reliable data sources can be put in place, along with workflows to manage them.  Here’re some annotated shots of the current state of development.

First Load

The default view will load Undergraduate Courses, or the previously chosen award type if you’re returning from other pages. The Course List will be to view.

Where previously A-Z Letter links would filter out non-matches, they now simply scroll down to the selected point in the alphabetised course list.

When the Course JSON file is first loaded, and on each subsequent load, checks are performed to see which letter of the alphabet is not represented (we have few courses beginning with ‘K’, for example), and those letters are greyed out.

As you Type Filtering & Highlighting

As planned typing in the box filters the Course List. Now a message appears reporting on the number of courses visible compared to the total count. Clicking the ‘X’ in the field will clear it, and restore the full list. Clicking an A-Z letter will restore the full list and scroll as required.

As you type, the part of the Course Title where your phrase appears is highlighted in the text.

Inline Search Results

This feature has been a long time coming. Search results are loaded via an XML-to-JSON filter script adapted to limit the search to the selected award. Title, relevance score and a basic summary are displayed. The JSON data contains everything needed to paginate the results, a feature that will follow. The script returns the data within an XJSON header which is then parsed into place on the page.

Showing Course search results gives rise to layout issues: where to put the Course listings and how to differentiate between them. Sub-tabbing was one option which was discarded, and in the end the choice was to shift the Course listings down the screen and to put Search results in their place, with a button to close them and restore the prior layout.

Search results use an alternate list style too, to highlight the expanded information available.

Switching to another Award Type hides (gently…) any visible Search results and restores the default listings view, loading the appropriate set of Courses.

I Produced these three a few weeks ago after I decommissioned an old disk. I’m now trying to choose the best outlet to sell them. Recommendations welcome.

Course Finder Demo App for Iphone

Here’s the Iphone & Touch version of the newly spruced Course Finder. The function is far more simple than the conventional web version, just select your award and then locate a course from the list.

The labelled buttons and alphabetical list format closely mirrors the Iphone’s internal layouts. The latter was achieved quickly using the excellent Contact List on Webkit package from cubiq.org.

For this project to be adopted it will need to be presented with full corporate branding. Something I have thus far steered clear of. However, the greater task of search integration is my next priority.

For full details of the project click here: Guerilla Gardening.

Here’s the presentable, standalone variant of the demonstration Course Finder I showed at BathCamp.

note: Compatibility View required for IE8, I’m working to fix this now.

It’s probably best viewed on this project’s category page.

Tested in a handful of browsers including IE8, Firefox, Chrom and Opera.

The Iphone demo web application will follow shortly.

For some time now I’ve been thinking about writing a post on designing for previews, those small boxes that pop-up over links on all kinds of sites.

My mind has been focussed by a few chance events that have lead to a striking example of the difference that adding a few design elements to a layout can make.

My (current!) blog layout is fairly simple, I’ve stripped back foreground images and simply have a title ‘tab’. For reading, it’s probably fine, but in a thumbnail preview at under 300 x 200 pixel dimensions, the layout does me few favours in grabbing and retaining viewer attention and inciting, inviting them to click.

We have precious little time to grab reader attention at higher resolutions, never mind when they’re taking a split-second to peek through the letter box.

So when you consider the great pains many of us go to create pixel-perfect, high usability, flexible or fixed layouts to get our brand, our ideas or our tone expressed it makes sense to make sure that when you have content worth linking to that it does the same.

So the story of this post goes like this: I took a photo on the Sunday at BathCamp, of the stencil they used to brand our complimentary camping chairs. A marketing masterpiece in their own right, snaps of these chairs bearing the BathCamp logo are turning up everywhere.

The next day I wrote up my thoughts on BathCamp, and sent them live. Shortly after publish (nothing’s ever really finished is it?) I added the stencil snap.

This morning I see a link to my post on Ann Oldroyd’s Blissfully.me blog, and saw my page appear in a pop-up when I hovered over the link.

Without that image the small type, small header, no medium-sized design elements would have made the page look simply like a page of text.

With it, it makes that one post  signify in no uncertain terms what the posts about and adds some visual interest to another otherwise textual page. In some ways image is enhanced by the lack of surrounding interface elements.

Words are useless when you can’t read them, so in my case previews clearly matter. In this instance the preview service understands this and has picked out keywords to aid the reader.

All of this will be considered with every new post, new site I develop and with any future redesigns I undertake.

Just back from BathCamp and keen to blog the things that most impressed me. This was my first time at BathCamp and my first ever BarCamp so was not sure what to expect.

Friday

Excellent meal at The Bell in good company then retired to the Media Barn for a spell before climbing under canvas nylon.

Saturday

Woke early helped with the registration prep’, thick coffee n’ Croissants then straight into talks.

Giles Turnbull’s talk about his part in the URL Shortening phenomenon was good, especially how he linked it to digital and hardcopy preservation and the ways in which we retain, discover and prize certain formats (papers, journals, newspapers) of old data. He then introduced the Newspaper Club to us, and how it’s helping create traditional format versions of digital content.

Dan Hilton talked about clients – how they understand and interpret digital media, often come to inappropriate conclusions on cross-media marketing; and agencies – how they’re often too willing to benefit from clients misunderstanding of the field, and ways that both can work better to make the most of the medium.

During questions Dan also pointed out the ways media providers are sharing cookie information to market recently viewed items on previously visited shop sites amongst similar content across other sites, reminding visitors of products they’ve examined.

Rick Hurst’s talk about the features and uses of JQuery interested me as it mirrored much of what I’ve been doing in recent weeks with the Guerrilla Gardening project, with the problems of access to data, hijacking HTML content for UI enhancement and problems formatting data from Content Management Systems.

I’m now reassured that switching to JQuery from Prototype will be trivial as DOM traversal, helpers, chaining, events and actions barely seem to differ between the two.

Caz Mockett showed us how she uses Blurb for high-quality self publishing of her photographic content. The results were impressive, something I may pursue for future art projects.

Chris Leonard presented his thoughts on providing publishing & discussion of scientific research outside of the conventional journal, using extant services as a starting point he discussed ways to provide effective peer review, reward schemes and metrics.

Rich Quick presented insights from his recent work on HTML emails for a number of clients. How we need to work HTML in ways that would make us sick to even to think about normally, considerations on the range of major desktop and web mail clients, quirks of each, how to make the best of the anticipated viewport with appropriate calls to action, A-B Split testing to provide feedback on more effective layouts.

Rich also discussed the issues of permission based marketing, legal and privacy concerns as well as the use of online services such as Campaign Monitor.

Saturday night saw a great barbecue, sponsored beer and cider, a band and a camp fire under a clear sky lasting into the early hours.  Pleasing to meet such a diverse bunch of dedicated, motivated and knowledgeable people doing interesting work and more than willing to share it with their peers.

Sunday

Excellent breakfast helped everyone recover from the night before, then I attended Alex T’s talk on the fun he’s been having using a PHP/MySQL API to track Forex currency trading.

After which I gave my (first, ever) BarCamp talk about the work I’ve been doing to improve the University Course Finder using html hijacking techniques, making data sources from the CMS and using AJAX and JSON to provide an enhanced user-experience with zero impact upon the usual management of course information. More information on this ongoing project can be found in the Guerrilla Gardening category.

Shortly after we said our goodbyes and began to head home. In the last twenty-four hours I’ve  probably gained more insight into the tools and techniques I use now and will go on to use than I have in months. it’s also good to see those areas where you’re exactly on track with your own developments and be able to help others with theirs.

More photos on Flickr of BathCamp09.

Prototype growing nicely

View the category Guerrilla Gardening for the full story

Here’re some screens of the new AJAX driven course finder. I’ll shortly add a hosted example but in the meantime the screens are sufficient to discuss some of the observations made now that development has begun.

First load

A-Z Links – filtration and index

It became apparent quickly that having the A-Z links work the same as the Search Field (filtering by word beginning) could be confusing. For example with 5 Courses to view, a word-beginning filtration could show 5 courses who’s titles begin with A.

So the A-Z links operate as before, they filter purely on title starting letter.

I intend to change this however, from a filter that removes non-matches to a scroll mechanism: rolling the full Course List down to the starting letter, not unlike a thumb-tab in an address book.

Search Field Filtration

Typing in the Search Field removes any course that doesn’t contain the words being typed. It’s rudimentary right now, filtering only on complete phrases starting with word-beginnings, but the quantity of content being dealt with, and the nature of the search requirements could mean that this is lightweight approach could suffice.

Initial testing with a single volunteer was positive.

The … Iphone

The layout used for prototyping is deliberately flexible to cater for varying screen sizes and devices. Overall the layout worked well on the smaller screen, of course buttons sizes will need to be increased for SSDD users.

I had to test the initial offering on a device, and had made an oversight I won’t be repeating. Using the onscreen keyboard obscures the dynamically updating list of courses, until you click the ‘done’ button. Additionally, autocomplete was trying to make a word on my behalf when all I wanted was the first few letters to narrow my results.

For mobile devices then providing just the A-Z Links will be a faster mechanism, and we can save the overhead of the periodic updater routine for those users too.

JS/DOM event handling

At present no controls are placed on the tabs aside from firing the AJAX requests, but the actions in the Search Fields and A-Z Links are mutually exclusive, especially with the periodic updater running, so require additional safety measures.

Clicking an A-Z Link disables the periodic updater. Actions in the Search Field restore the periodic updater and reset the visual state of the A-Z Links.

What’s Next

A live working example, more on the mobile usage, and a little user-acceptance testing.

Got content.  Got concept.

View the category Guerrilla Gardening for the full story

On day one I had a rough plan of how to make the improvements to the Courses UI.

How it’ll work

The pencil sketch above is a fair representation of my plan – each Course Type available is clearly visible near the top of the view. The Undergraduate courses tab is activated by default, and the full list of clickable Undergraduate Course titles appears in the ‘results’ box below.

Switching tabs loads the Course listings for that Course Type into the results box, and the A-Z and Search box now operate on the new listings.

Typing into the Search input box filters the current listings by the phrase you’re typing, but if you click ’search’, you are taken to the search page and your query results are shown (I’ll return to this later).

In the absence of Javascript, the interface should be split back into the sequential copies of the A-Z links per Course Type, the way it appears now, and all functionality back to basics.

Refining the proposed UI

Looking at the diagram, I wonder how I’ll fit a whole alphabet in the space, alongside a search box and submit button. I may have to sacrifice the  scant advantage it brings in order to make the page easier to understand.

However the A-Z links are a feature of the page as it now stands, so will be part of the original and non-javascript views at the very least. I could perhaps make the options (re-) appear when a control is moused over or clicked. For the moment the feature will be developed whether or not it makes it to the final cut.

As-you-type Course Filtering

If retained, the A-Z links will act as shortcuts to the filtering action of the Search input box. This will be an improvement over their current action, which returns pages of links based on the first letter of the course title.

Right now, clicking on ‘A‘ will give you Applied Psychology, but not History of Art and Museum Studies.

The javascript filtering should instead detect the chosen letter at both the string and word beginnings. Clicking on ‘A’  would give you Nursing BA – Adult, Graphic Arts and Pharmaceutical Analysis.

It will also include every course with ‘and‘ in it, so some common word exclusion will be necessary too.

Returning Search results

Right now Search results are displayed in the Search context – our query takes you away from the current page to the search server and a web page is generated to show results. This new scheme’s aim is to keep navigation within the Course Area, retaining appropriate navigation.

Using the Search facility’s API, the results should be retrieved as XML, parsed and formatted then shown in the same Course listings ‘results’. This means we’ll need to highlight the difference between search results and Course listings.

The next stage will be getting some working examples going. First though I’ll need to note the order of the dynamic events incorrect rendering of the tabs and results.

Order of events in the JS driven UI

The page hinges on the Course Type, so switching Course Type can trigger resets of other elements such as the text in the search area. It’s probably best to clear the results area too – in readiness for new AJAX loaded data, and allowing the visual change in the tab from inactive to active to occur only on successful load of that data – otherwise network issues could result in a very confused page.

In addition to the clickable events, there’s the periodic routine checking the contents of the Search box and filtering the list accordingly.

I’ve tried to anticipate what should happen along with each event below:

Event	reactions
Tab Selection
Active tab	No action.
Inactive tab	Disable A-Z links, disable periodic Search box routine, clear Search and results areas, display loading message/icon, load data into results area, use signal in results to switch to make tab active, make others inactive, re-activate A-Z links and periodic Search box routine, clear loading message, displaymessage/icon to denote listing type as ‘Courses’.
A-Z link click	Replace content of Search box with selected letter. Start the periodic search box routine.
Search box focus	Start the periodic search box routine.
Periodic Search box routine	Take contents, format for filtering (remove common words and inappropriate characters), set the display of matching/non-matching courses appropriately.
Search Submit box click	Disable A-Z links, ‘fade’ A-Z links buttons to show they’re not available in this context, disable periodic Search box routine, clear results area, load data into results area, use signal in results to switch to display message/icon to denote listing type as ‘Search Results’.

That’s enough forward planning for the moment. It’s time to start prototyping.