SourceBottle

This past year has probably been one of the most interesting in my professional career. 

A year ago I joined the team at Animoto, leaving the world of corporate American behind me. I had spent the past five years working for American Express, developing web applications and driving their online strategy. The opportunity to work on such high profile web sites and applications, visited by over a million people each day, made all the internal politics worthwhile! It really helped me develop from an occasional web developer to a professional, crossing disciplines and along the way I learned a great deal.  I don't know if it was itchy feet or the chance to really own the development of a product end-to-end, but I decided it was time to move on.

Over the past year, it has been refreshing - moving to a much smaller and agile company, getting the chance to see the direct impact of my work. I'm honored to have the opportunity to work with such a talented team on such an innovative product. 

Looking beyond my own employment, the technology arena has also changed dramatically in 2009. I feel as though the building blocks of web apps have finally matured and the pains of the browser-wars are fading. 

On the Javascript side of things, jQuery has seen numerous refinements and optimizations, making it the framework of choice for many. Atlas has raised its head, offering developers a promising environment for creating Cappuccino based web applications. Across the major browsers, JavaScript performance has also significantly improved.

On the CSS side, more and more of the CSS3 spec have been implemented by Mozilla, Webkit and Microsoft. Finally, it is becoming a viable option to use border-radius, box-shadow, RGBA opacity. For developers and designers this potentially can streamline the workflow, and making rich-HTML prototyping much more attractive.

IE6's market share has also diminished significantly with browsers such as Firefox and Chrome gaining market share, and Microsoft pro-actively pushing IE7 and IE8 on users. For developers, this is really starting to change the levels of browser support we offer. Since the red-headed step-child is finally in the minority, progressive enhancement is a much more acceptable option.

Whilst I don't think anything game changing has yet emerged, these are the perfect building blocks for the web of 2010, and it will be exciting to see where enterprising developers take this. Already there are rumors of the iSlate/iTablet/iProd redefining the mobility computing space, I tend to think that whilst 2009 was the year of software maturity, 2010 will be the year of hardware maturity.

 

Long time no post! Here it is, the annual post where I announce that the future is all bright and sunny, and that I intend to post more often, covering a range of topics from getting the most out of CSS3 to the pro's and con's of specific user interface design patterns. We'll see how that turns out!

I have taken the opportunity to move this blog over to Posterous, for a number of reasons. The first being that in using the service over the year for other blogging projects, it has always managed to impress me, and as a publishing platform it has matured significantly. The second, and perhaps most important reason is that it shifts the focus back towards content - I'm no longer dealing with my own Wordpress install and the overhead that adds, instead I can post content from anywhere. Hopefully this is the kind of thing which will encourage me to write more.

I have to say, the migration itself appears to have gone smoothly - importing all of my old posts in a few minutes. A bit of theme tweaking and everything should be good. 

For the past four-and-a-half years I have been deeply entrenched in corporate life - working for American Express several different roles. When I joined the company I started as a programmer developing intranet dashboards and web applications with J2EE, before moving on to focus on the front-end user experience of users on the companies website. This led to my involvement in usability testing, front-end design and build which saw excellent improvements in both satisfaction and conversion rates of various online processes and applications. Over the past year, I have also had the opportunity to really focus on the design and creative strategy for American Express's online presence, as well as working to optimize what we have.

The corporate life has been fun, giving me the opportunity to make an impact and learn a variety of skills which I'm sure will continue to be useful; however I've decided to actually take the leap and http://startup.partnerup.com/2007/11/01/leaving-corporate-america-for-a-startup/

I have a love-hate relationship with Getting Things Done or GTD as it is often referred. Slipping in and out of various systems ranging from simply jotting tasks down on the back of a napkin, to tracking progress against specific goals and measuring productivity. So far it has been hard to actually find a system which seems to work for me &emdash; until now.

A good friend of mine is responsible for GTDInbox, an implementation of the GTD principles built on top of Google Mail. As a willing guinea pig, this has led to me learning about the GTD system and trying to implement it with my life. When I started my previous job, my boss presented me with a copy of David Allens book which I have read several times, and I tinkered with various ways to make it work for me.

Up until now Omnifocus was my tool of choice, providing a nice clean interface and also an iPhone client which meant I could carry around my task list and enter things on-the-go. The trouble for me however was that as nice as the application was, it was overwhelming - offering perhaps a few too many options (or hoops) when it came to categorizing, viewing and sorting your tasks. This tended to put me off entering tasks and using the iPhone application, the capture process is not quick if you want to stay organized.

Another thing which didn't really work for me was the notion of context, a component taken directly from Allen's methodology. Whilst for some it may make sense to group tasks by context or location, such as 'home' or 'office', when your laptop is essentially your home and office it all blends into one and you end up making 'meta-contexts' such as 'email' and 'web browser' to keep things organized. In addition, having a context for errands is all when and good, but when you are in this context, you are unlikely to be referring to your task list to see what there is to do!

I don't want people to think that I am being harsh on Omnifocus or that it is a bad application - it is an excellent piece of software which has been lovingly developed by a very talented company, but unfortunately mine and its mental models don't align.

Recently, I think I may have found an application which is right for me - Things by Cultured Code.

It has a wonderfully minimalistic UI, which adapts to how it is used. You want something simple? It looks like a to-do list. You want to go the whole hog with contexts, tags, projects? It looks more like OmniFocus. Much nicer to look at however you choose to work.

The other thing I really like is the metaphor of time used within the interface to prioritize tasks. First you list all your tasks out, tagging and adding other information if you desire. Next you categorize by time - so you group all tasks which are due Today and the rest are grouped under 'Next'. The idea being that you restrict the view to today's tasks, and then if you get those done you can move on to whatever is next.

This categorization also allows you to schedule recurring tasks and also put tasks into a 'Someday' folder, essentially saving them for when you have downtime. Projects can also be used to group things together, and tags to organize.

So far, this concept seems to work for me - it seems much more logical and the application itself seems on par with OmniFocus in terms of quality. I'm planning to try it out for the next week, along with its iPhone companion app, and see where it gets me. I'll also be taking a closer look at how new tasks can be quickly inputted, which has been another pain point for me in the past.

Its hard to believe that its almost 2009, its also quite embarrassing to see the single-digit total of blog posts that I have made this year - must try harder next year!

This year has been a hectic one - on a personal note, I have moved to another country and gotten engaged whilst also tinkering with JavaScript, ActionScript 3.0, Oracle RTD, Rails and Processing - I even started to play with Django before deciding I didn't like it! On a professional level, I've written a book, worked on a variety of interesting projects (which corporate confidentiality agreements prevent me from talking about in too much detail) and also have something really exciting on the horizon that I'll be able to talk about in a month or so.

From a technology perspective, I think 2008 has been the year where things on the web have really started to change. Developers are starting to implement HTML5 and CSS3 features which have slowly been creeping into browser releases, Google has entered the game with Chrome and Microsoft are finally starting to up the ante with Internet Explorer 8 which is due for public release in 2009. In addition Silverlight, JavaFX and the latest enhancements to the Flash platform have also given fuel to RIA and multimedia developers.

This year I have seen fewer web apps taking the world by storm. The leaders, such as Gmail, have really focused on enhancements rather than anything radical. Facebook has undergone a dramatic redesign, but it is very hard to single out the "killer app" of the year. The key development that comes to mind is the release of services such as Google's App Engine and Amazon Simple DB - providing the cloud infrastructure for developers to create apps with virtually no server/database overhead, so you only pay for the capacity you use. In 2009 I expect this to become even more important and also something which will begin to see major adoption within the enterprise.

As we look ahead into 2009, things look tough - the global economic crisis has already led to layoffs across many different industries, and consumer spending is an all time low. As customers tighten their belts, this is having a knock-on effect within the online-sector, making it even harder to fuel the business models of many freemium or subscription based services. Spend on online advertising is down, despite media budgets being directed from direct mail to the online channel.

As a result, I think the next year is going to be more and more focused on experience - as product development budgets are cut we are going to see less new features, but instead there will be a focus on profitability. As smaller companies struggle to survive, user experience is going to be the key differentiator between products and the driving factor towards increasing user-base and driving revenue. More on that to come.

Before I go, let me leave you with a little something. Created with Animoto and comprised of Boston.com's top photos of the year, it provides a retrospective on the events of 2008.

2008 Retrospective from Chris Korhonen on Vimeo.

Happy Holidays and all the best for 2009!

One thing to be wary of as your prototypes increase in fidelity is setting client expectations accordingly. If someone see's a polished and working front-end, then more often than not assumes that the product or web site is almost finished. It becomes hard to reset expecation that in actual fact it won't be ready for another few weeks or months. Techniques I tend to use vary, from simply explaining that whilst the facade is functioning, the back-end is in no way read. Often, I will reinforce this by doing elemental prototypes - so building out widgets, UI controls etc. and placing them on a separate page with no other content. This makes it easier to not only focus on the interaction, but also to communicate the disassembled state of the application to the client. In other cases, where it becomes important to show the functionality of an application as a whole, one approach I find really useful is to re-skin the application to look 'rougher'. Within Flex, I love the Napkin skin by xxx. Instantly you can change the style of your application to look like it is drawn on the back of a napkin whilst retaining all the functionality. Similar things possible in CSS

A recent Ajaxian post asks how developers prototype their apps., in addition at the recent Future of Web Design conference this also came up a lot, with designers and developers weighing up the benefits of designing with design tools or jumping straight into the code. Preferences really vary, so I thought I would throw my thoughts out there. If I was asked the question "How do you prototype your Web apps?" then my answer would be simple - it depends!

Designing Visual

In my professional and personal design work it really varies, mainly down to what I am developing - if it is a site where design is most important then I tend to jump into Photoshop and begin thinking about design elements; taking inspiration from various sources such as Smashing Magazine, interesting photo's on Flickr and artistic styles. This helps me put together a creative direction in my head which I can then refine and experiment with. Often in these cases I would spend a lot of my time in Photoshop (and/or Flash if we have interactive elements) refining the concept before following the traditional approach of cutting graphics and building my XHTML and CSS. I find this tends to work well for sites where you are trying to do and communicate visually, and when you are working with a page/system which already has well defined layouts for content - so for example when you are re-skinning a blog or designing a product landing page.

Designing Process

If I am working on an application which is either transactional or data orientated, I'll often take a very different approach to my design and prototyping. Many applications have a finite number of states, so for example on a very basic level Amazon has category landing pages, product list pages, product pages and the checkout flow. I would first try and list out the set of states for an application, and then create a rough 'napkin-sketch' of each, either on the back of an actual napkin or using a quick and easy wireframing tool such as the excellent Balsamiq. This helps to get thinking about the components of an application up front, ensuring that you have covered all of the use-cases and hopefully prevents the situation where at the end of the design you realize a feature has been missed and you need to go back and try to retrofit it into the application. From their I tend to move straight to XHTML/CSS, getting the layout setup and beginning to focus on the 'feel' and interaction a user has with the page page. This I find, especially when designing a transactional process, helps to stay focused on the underlying goal of the page which is often to support a user in completing a task or driving an actual conversion. Working direct with XHTML/CSS really emphasizes the interaction portion of design - at an early stage you can see how a user will move through the process and identify any bottlenecks or any opportunities. This is also the stage where you can also start thinking about behavior - how can you use JavaScript (or Flash) to enhance a transaction? This may be as simple as prototyping how an Ajax auto-completer could be applied to a form field, to visually experimenting with how a page is displayed. By adopting this high-fidelity prototyping approach, you also generate reusable code which can be worked into the final design in addition to artifacts which are often more value when it comes to presenting to clients and usability testing.

The profiliation of technologies such as Flash, combined with the growing feature sets of the web browser and widespread adoption of broadband, have really transformed the web over the past ten years. Whereas previously web pages were mostly static, with conservative use of images and minimal animation; the web of 2008 is a visual and aural extravaganza. Aside from an additional layer of visual richness and interactivity, web publishers are increasingly relying on video and audio in order to connect with visitors on both a rational and emotional level. Broadcasters and news agencies have long been the pioneers in this space. If we take the BBC as an example, their online services have evolved from RealPlayer clips attatched to news articles, to streaming radio, to the iPlayer, a web or desktop based means of streaming radio and television programmes after they have aired. As technology has evolved, the BBC has also followed, recently adopting Flash as the delivery mechanism - a much more ubiquious and flexible solution compared to the ever-so-slightly-old-in-the-tooth RealPlayer. In fact, today audio/video is the only way some news stories and features can be experienced - a sign that this is becoming a mainstream expectation among users. Part of what has been responsible for this mainstream acceptance of video is in no small part due to social sites such as YouTube - growing communities around the concept of creating and sharing video content. Television networks and movie studio's have also embraced this medium both for making regular content such as TV episodes and trailers available, producing web-only interviews, documentaries and "webisodes"; and by specific viral marketing campaigns. Marketers have embraced the likes of YouTube as an additional marketing channel, where one can generate buzz around a product. What all this goes to show is that with the careful combination of the visual and the aural, incredible experiences can be created and user engagement can be taken to the next level. It can compliment existing content as is the case with BBC News, or it can often stand on its own. Technology has also been an enabling feature - once in an environment of several competing and non-compatible plug-in technologies it was frustrating just to begin the process of watching a video or listening to a piece of music. Today, this is less of an issue with the majority of web video being made available using Adobe Flash or Quicktime - both boasting a high install base and seamless integration with the web browser.

Sound: The Red-headed Stepchild

In many ways, this is paradoxical given the rise and very rapid fall of one "feature" of the web. Does anyone remember back in the 1990's when you would visit a website and be greeted with an exceptionally loud sound, jingle or other device. Usually it would scare the hell out of you, sending you scrambling for the mute button. Most companies soon got the idea and realized that this kind of "sonic branding" was a bad idea (and others are living in blissful ignorance). Why did this fail when at the same time multi-media took off? There are several reasons, the first being that in many ways surfing the web is a private, contemplative, experience - it is akin to reading a book. The user is often in a focused state of mind, and to interrupt them is a jarring experience similar to how interruptions during the working day have been proven to have a negative impact on productivity. Imagine if you were forced to listen to a soundtrack as you read the latest Harry Potter novel! Or the sense of intrusion which you get when your favorite iTunes track is interrupted by a web page with obnoxious theme music. The user does not want to be surprised, and this becomes even more important when we consider the context as to where people are using the internet - more often than not at work, where it could cause embarrassment if co-workers knew what they are up to. Perhaps they are at home, with a sleeping child, where it would cause frustrating if a virtual marching band caused the child to wake up. Even if the initial surprise was acceptable, online audio branding faces another challenge - how does the user feel on repeat listening? If someone is visiting a website on a regular basis, it is a sure bet that over time any "theme music" may become annoying and become a reverse-branding play. Another more recent problem is the user being unable to associate the sound with the web page (or brand). All modern browsers support tabbed browsing, leading to the behavior of many users to queue up several pages in multiple tabs and then processing the content. If a page in one of the closed tabs starts to play audio, the user will either associate it (and all their feelings toward it) with the currently open tab, or engage in a frantic game of hide and seek as they rush to kill the offending sound. Following this theme of disconnected audio, another thing to watch out for is misassociation with advertising banners or other elements which may also be animating on the page and causing the user to draw the mental connection.

When does it sound good?

Recognizing some of the fundamental usability and user experience issues associated with a musical web, are there any times when it is appropriate? The answer is yes.

Audio and Video - A Match Made in Heaven

Obviously, audio goes hand in hand with video content. When a sound is played, it is natural human behavior to associate it with moving objects (animation or video) or the most current interaction (opening a page, clicking a button).

Good, Sound, Experience Design

When you are not dealing with video content, it is important to consider how sound is going to integrate with an experience - will it be synced with animation, or triggered when a user clicks a button? Its important to avoid simply adding a sound to a page without considering how it will be perceived, and what events it will be associated with. For example, simply tacking an MP3 onto an onLoad event will likely not present a good experience.

Notifications

Sound can be a powerful tool when it comes to notifications, as can be seen by its use within the operating system - whether to signify a system error or an incoming email, it can instantly communicate changes in state to the user. On the web this is certainly still the case, with Google Mail and Facebook's chat facility providing excellent examples of this. A short, distinctive beep is used to alert the user to a new message. When using sound for notifications on the web, it is worth taking a step back and considering what you are notifying a user and if it is really necessary. Is it an event which demands the user's immediate attention, or can it wait until later? For example, do you really need to notify the user that they have just clicked a button? There is a limit on the number of short distinctive beeps one can process, and they should be kept for signifying activity which occurs whilst a user may have their browser window in the background.

Giving Back Control

Going back to why websites tend not to have theme tunes, many users dislike not being in control and dislike unexpected surprises. Whilst a user watching a video on YouTube expects to hear sound, someone logging onto their bank's website may not. Where possible, best practice is to ensure that all audio (and visual) content is user initiated.

A Kill Switch

Whilst many of these strategies may help you best add sound to an experience, there is still the chance that the user may not want or desire it to be part of an experience. This is more often the case when we consider theme music or notifications. Always provide a mute button.

Sanity Check

Finally, ask yourself, how does audio enhance the user experience of my website? Alongside video this may be a no brainer, but if you do not have a compelling answer then that should be an instant warning sign. Could a sound be misinterpreted? An example might be using a ka-ching sound on the checkout page of an e-commerce site. Whilst it may evoke the emotional feelings of a transaction, it could also convey the undesired feeling that someone is being ripped off. In the case of theme music or notifications, does the audio have the potential to sound annoying? How about if you had to listen to it hourly?

I do feel like I have been neglecting this blog a bit over the past few months, but unfortunately moving from one country to another tends to take up a fair amount of time. I'm now nicely settled in New York City, and have furniture in my apartment! All in all, the transition has been quite smooth, and I've found everyone to be friendly - obviously, I'm sure my charm and English accent has also played a part! Last Wednesday I went along to Flash Coders New York, which was great fun, with an excellent presentation by Seb on the Arduino board, which allows you to do a bit of home electronics hackery, controlled by Flash. In other news my book, Creating Mashups with Adobe AIR and Flex 3.0, has gone off to the printers and should be on the shelves come April 28th. More on that over the coming weeks, but in the meanwhile, I would heartily recommend that you go and check out Adobe AIR. More soon...

As I'm sure eagle eyed readers may have noticed, I am in the process of migrating blogging platforms, from Mephisto to Wordpress. I figure it distracts readers from the lack of posts as of late!

Its a move I have been toying with for a while, mainly because I have not been impressed with Mephisto as a blogging platform at all. There was a lot of promise, but development seems to have stalled, leaving users without basic and essential features without getting knee deep in Ruby code.

Wordpress so far has been a dream in terms of setup and configuration, and I am already impressed by the amount of quality plugins available, coupled with the ease of installation. My only gripe has been that all my posts seem to have lost their text formatting, making me look like a dumb monkey who has never been introduced to the concept of a paragraph! I'm working on that!

Coming in the next few weeks is a pretty redesign, replacing the Wordpress theme, and some other bits and pieces...