• Mobile: while it’s been on our radar for a long time, the Australian market’s never had a lot of demand for mobile web; Apple and the iPhone have helped push through the idea of the mobile web as a stripped down version of the “real” web, so we’re eagerly experimenting with our options there; curiously, at the same time, we’re seeing huge opportunities in China where some 500 million people use mobiles more than they use PCs, but are stuck with tiny and slow devices, so it’s back to WAP and the stripped-down web to support that market

• HTML5: between Google’s HTML5 Playground and HTML5 Boilerplate, the collection of technologies under the HTML5 umbrella are suddenly becoming more widely usable, and reaching that point where we can integrate them into our day-to-day work

• Open Gov: we’re in a sort of limbo while the Australian government is headless, but recent developments, including AGIMO’s Declaration, around the key principles of Informing, Engaging, Participating, are very encouraging; will be interesting to see whether a new government and minister can run with it after Lindsay Tanner’s departure though; there’s some particularly thoughtful discussion going on around the role the public service plays in this, see Nick Gruen’s Those ‘crazy’ public servants’

• Scaling: we’re experimenting with different scaling solutions on a few different fronts, with interesting things being done with caching of generated web pages, or of data or indexes, and experimenting with both scaling up and out — we’re really liking the idea of throwing very specific hardware at particular tasks, so those CPU intensive tasks can be farmed out to fast hardware where it won’t interrupt regular service; the favourite approach we’re coming back to is faking it — making things almost live rather than actually live

• Things On The Front Page Of A University Website
  
  Applies, of course, to a lot more than just university websites, but it takes a lot of discipline to actually implement.

Starting to Get Twitter

Admittedly, it took a long time (I first signed up in the second half of 2006), but Twitter has grown on me. It’s not quite right, and it’s still incredibly geeky, but it points to an always-online, always-chattering future for everyone.

While it’s geeky, it’s not necessarily techy, so there are a lot of different people on Twitter, every one of them using it slightly differently. Some are using it to broadcast, some are using it to chat, some are using it to keep in touch with a group of friends. Many do all that and more. I find myself using Twitter in two very different ways. On the one hand, I follow people for their links to news or cool new things online. I’ll ocassionally tweet in the same mode myself. But on the other hand, I follow people I know in the real world. This is, for the moment, a much smaller group of people, and their updates tend to get lost in the noise created by the first group. But it’s the mode I normally tweet in myself, and it’s by far the mode I’m most interested in.
…

Real People

The thing about ambient intimacy, is that it really only works with real people. Characters and personas you can get away with — we’re all putting on personas, all the time, both online and in the real world. But no-one wants to be intimate with a corporation. And a corporation can’t tweet about what it had for breakfast.

So there’s no easy answer for companies, no three-step process to monetise those eyeballs. No-one will own the æther. There’ll be money in plugging people into the æther, and in helping them filter it. But you’ll be working with a whole lot of other people, and other systems. And through it all, you’ll have to be yourself — be a real person.

At work we’re starting to get into the social media space a whole lot more. But when we looked at the idea closely, we realised, we don’t want to go into that space as Gruden. Most of us already have a presence, and an identity of our own, and Gruden is just a part of that identity. So we blog and tweet in our own spaces, and sometimes we blog in Gruden’s space, and sometimes we link or tweet each other, just like anyone else in our social space. It’s not about creating a new persona, it’s about being real people. And any company looking to get into this space needs to be ready for that — you don’t do this as a job, it’s just something you do as a person.

The essay explores more of the cultural impacts of these services. But what about the impacts on companies, and on marketing? Everyone seems to be aware that “social media” is something they should be doing, but no-one’s really sure of what that means, or how they’d go about taking their brand message into the social media space. The key, however, is to not think about social media the same way you think about your traditional media. There are half-way points, like Facebook’s Pages, designed for a traditional brand presence within Facebook. But if you’re going to embrace the social aspects, you need to be sending real people into the space. In some ways you’re loosening control over your company’s message, letting all your employees into the social media space. Some won’t want to identify their work, some will embrace it.

To take it further, let key outward-facing staff (be they marketers, public relations, sales, customer service) put some of their work hours into their social media presence. Obviously, such an investment requires some return, but the pay-offs are, initially, going to be difficult to measure. The key, in the short term, is in establishing a presence as a recognisable and real identity.

Steve Rubel is arguing that, while it’s clear that Facebook and Twitter will be replaced, they won’t be replaced by a new ‘hub’, but rather by the open web. The argument is that the web will become “one giant social network”. So you’ll no longer be able to setup your brand presence on the kids’ latest favourite website, but will instead need to focus on your identity, and really participate.

Marketers need to really embrace the fact that it’s peers and their data, rather than brand, that will become the primary way we make decisions. The greatest rewards will go to those who embrace and participate in as many communities as they possibly can in credible ways.

The social media space is still in its infancy. It’s an area in which we’re all experimenting. It takes such a dramatic rethink of the way we market a brand that it’s bound to ruffle a few feathers. We’ll look back on this period and wonder why it was so difficult. But this experimentation is only human; it’s what makes our presence all the more real.

So we’ll continue experimenting with our own presence. And we’ll encourage clients to start sending people into the social media space. Some are going to be more ready than others — we’re not suggesting everyone go create a Twitter account immediately. But as you start to look at what you or your employees are already doing with your personal presence, you’ll find it becomes easier to bring the company into the conversation.

These two represent two very different approaches to the semantic web. The web has traditionally been designed and written for humans. The semantic web represents an effort to design and write the web for machines. We can run a search, look at certain results in context, and determine that one particular string is an address, another is a phone number, another is a name. But a machine struggles to tell those apart. The “lower-case” semantic web attempts to introduce some structure to the human web in order to assist a machine’s interpretation. The strong “upper-case” Semantic Web introduces data specifically designed for machines, oft-times invisible to humans.

The Microformats effort attempts to extend the human web by encouraging the adoption of common semantic structures in order that a machine might also read this web. Google’s recent announcements included initial support for the hCard and hReview microformats, used to identify names and addresses (hCard) and reviews (hReview). Initially, Google are reading the hReview microformat to pull ratings for businesses and include that information in search results.

While it’s only in the initial stages, we’ve seen Google slowly extend search results with rich snippets in the past, and this is an indicator that they’re taking microformats seriously. This is a strong case for adding hCard (or other microformats) to your website — it’s not hard to imagine Google pulling address data and showing maps next to search results. This is something we’ll be adding to the Gruden website in the coming weeks, and we’ll include details of our implementation. In the meantime, Google’s webmaster documentation includes detailed examples to markup business and organisation data.

Another new Google feature sits between the lower-case and upper-case forms of the semantic web. Google Squared (link is to a YouTube video) lets you setup a grid for comparative search results. Eg, a search for Hotels might return different hotels down the page, with locations, prices, ratings across the page. In typical Google fashion, all this data is mined from the human web, but there’s an obvious attempt to impose machine-readable structure on the content.

Wolfram|Alpha has been compared to Google, but really is a radically different approach, and for a very different end. Wolfram call it a “computational knowledge engine”. It works with strongly structured data — it’s designed to give answers, not a list of results a human then needs to mine. Some example searches are:

• Sydney, Australia, which returns population data, a map, the current time and weather
• apple and orange protein, which returns detailed nutrition information

And then there are the classic unanswerable questions (via Amnesia blog):

• life, the universe, and everything
• the speed of an unladen swallow

We recently commenced an effort to make the Gruden website more mobile-friendly. With the overabundance of iPhones in our office, that provided an easy start, and an easy platform to test with.

We’ve always been believers in the separation of presentation and content. We code our HTML to best practices, with a focus on semantic markup and well-structured documents. With this background, we didn’t want to go about creating a completely separate (or crippled) version of the site for mobile users. Mobile Safari on the iPhone makes it obvious that you really can deliver the real web on mobile. So instead, we looked into the little things we could do to incrementally improve the mobile browsing experience.

Everything we’ve done to date has been achieved with CSS. There’s no browser or user-agent sniffing, no redirecting users to an m-dot or dot-mobi version of the site. While such approaches are well-suited to providing mobile versions of an app (GMail comes to mind), they can be misleading when dealing with a website. As far as the end-user is concerned, they’re looking at the same website, and there’s no need for bookmarks or shared links to present something different on different devices.

So there are three main areas we’ve looked at:

• Trimming pages to improve readability
• Increasing hit areas to help touchscreen users
• Improving content flow to fit narrow screens

Targeting the iPhone

<link rel="stylesheet" href="/lib/main.css"
    type="text/css" media="screen,print">
<link rel="stylesheet" href="/lib/mobile.css" type="text/css"
    media="handheld, only screen and (max-device-width: 25cm)">

The iPhone, along with other recent mobile browsers (such as Opera), loads the “screen” stylesheet ordinarily. It ignores “handheld”, though we keep that around for the older mobile browsers that do support the type.

But the iPhone also supports media queries, from the CSS3 spec. This lets you target devices based on the media features they support, including device-width/height, orientation, aspect-ratio, color, resolution. We’re targeting devices with a max-device-width of 25cm, which will include the iPhone, and any netbooks that go the way of supporting the directive.

Trimming Pages

We’re not actually doing anything server-side, and we’re still presenting most of the same content, so total download sizes aren’t going to be reduced dramatically. We already make an effort to keep download sizes pretty slim, however, and we’re not targeting those old mobile phones with web-lite browsers and 2kpbs downloads.

What we’re really interested in is removing noise; because we’re targeting small screens, we don’t want to be filling the screen up with unnecessary content or large images that are little more than decoration.

Home — Safari

Home — iPhone

The Differences

The most obvious difference, as a user, is that we don’t have Flash on the iPhone. So we’ve a couple of images as fallback content instead of the Flash-based carousel of portfolio items.

But we’ve also trimmed some content. We’ve removed the footer altogether — the content is available on our Contact page, and this was a couple of screens worth of content on the iPhone. And we’ve removed the big background image (a series of tubes).

We’ve also pushed content to the edges of the screen rather than leaving whitespace around the content area. In CSS, we’ve changed most elements to use % based widths rather than pixels to better allow the device to fit the content.

Solutions — Safari

Solutions — iPhone

The Differences

These are obvious. We’ve removed the large images, and removed the floated columns layout. The images are effectively decoration anyway, and would fill a screen if we left them in. This leaves the page with just the key content.

Increasing Hit Areas

With touch becoming a common interface, we can no longer rely on the precision of a mouse pointer, or even a stylus. Wherever we can, we’ve increased padding on elements and switched many a elements to display:block, with exaggerated boundaries.

Some of this can be seen in the home page examples above, where the top menu items all have a little more padding in the iPhone version.

Portfolio — Safari

Portfolio — iPhone

The Differences

In the desktop browser version, each Portfolio item has two links — the name, and a “read more”. In the iPhone version, we hide the “read more” and have the name link displayed as a block, so the whole box becomes clickable.

Improving Flow

Regardless of which screens we’re targeting, horizontal scrolling has never been particularly user-friendly. On the desktop, we minimise this by limiting the width of the content area. On the iPhone, we’ve eliminated floated columns in a number of locations. Combined with the change to % based widths, this makes most pages better fit the width of the screen, and to flow vertically as much as possible.

Portfolio Item — Safari

Portfolio Item — iPhone

The Differences

In this example, instead of floating the portfolio images alongside the content, we’ve dropped them to sit below the content instead. Because the HTML is written to flow correctly even without CSS, this was a simple matter of adding width:100% to any columns in the mobile CSS sheet.

The Beginning

This is only the beginning of our venture into making the Gruden site mobile-friendly. It does, however, demonstrate our key principles. Any difference between the desktop and mobile versions of the site needs to consider the user, and their context. We don’t want to remove any important content, but, as always, we need to keep in mind how the user is interacting with the site.

With the increase in popularity of mobile devices (be they phones or netbooks) with full featured web browsers, sites are going to see more and more visitors coming from devices with unique physical constraints. The changes we’ve made are all simple to implement, but provide immediate benefit to these users. And we’re going to keep working on those incremental improvements.

But as with many HTML forms, the feedback provided to users wasn’t ideal. Support staff would regularly field calls from users unsure if their upload was going through. When you’re uploading a large proposal on a slow connection, and your only feedback is IE’s little flag waving around, it can get pretty disconcerting.

Part-way through the redevelopment of eTendering, we came across Moo’s implementation of SWFUpload, a JavaScript/Flash library that provides an interface to Flash’s FileReference, allowing us to greatly enhance the file uploading experience. We researched the implementation options and pitched it to Commerce, who responded enthusiastically. One of their most common feature requests was for more feedback around file upload when lodging responses, so the feature was quickly scheduled in as a post-live enhancement.

The Design

The system degrades gracefully – users without the Flash Player get ordinary file fields. With Flash Player 9+, users get a single ‘Browse’ button, which pops up a Flash driven file dialog when clicked. After selecting a file, we output the file name and size alongside the button.

The flash uploader interface

Users hit ‘Lodge Response’ and the uploads begin, with a progress bar showing actual upload progress, and a countdown timer showing our best-guess time remaining. Users can immediately get an idea of how long the largest file is going to take, and can see if a connection drops out and the upload progress just stops.

The flash upload interface showing upload progress

Once files are uploaded, the system has to compress and encrypt the files. Depending on the size of the files, this process can take up to a minute and previously at this point most browsers would just stop giving feedback altogether. So we’ve added some extra progress indication in the form of three steps “Uploading files”, “Encrypting uploaded files”, “Preparing response receipt”. The system highlights the current step in bold, and greys out the completed step/s.

The flash upload interface with file upload completed

Conclusion

The take-away? Never stop thinking about the end-user’s experience. We had a system that we thought worked, well enough. But a little extra feedback goes a long way.

We’ve uploaded a screencast (1.5Mb SWF) of the new process in action.