I’m trying to masquerade as a hip and trendy designer-type today at IxDA’s Interaction08 conference, but I fear my geeky ways will betray my role on the implementation side of the aisle. We know that many Ajaxian readers are designers or interested in creating well-designed products. Indeed, Ajax has been about empowering us to create websites that don’t suck. I’ll be blogging various Interaction08 sessions over at my personal blog, and for those sessions that seem to relate to Ajax development, I’ll repost them here as well.
In particular, I thought Alan Cooper’s keynote, An Insurgency of Quality, was extremely interesting. It’s a verbose transcript; hope you don’t mind.
===
Robert Reimann kicked off the first (full) day of Interaction08. He started with a charged introduction, telling us that this is the first-ever conference of the IxDA group and represented a major milestone in the emergence of “Interaction Design” as the pre-eminent discipline involved in the creation of digital products.
The energy level in the room is very high–it reminds me of the first Ajax Experience, though enthusiasm is higher here as the IxDA community has been around in various forms for so much longer.
Alan Cooper just took the stage. Alan co-authored “The Inmates are Running the Asylum” (a difficult word to spell, by the way) and has long been an authority in the space. I’ve read much of his work over the years.
Both Robert and now Alan talked about the self-identification of Interaction Designers (Alan: “We’re not prototypers, testers, or eyeball-tracking wonks”); some of the rhetoric sounds like a social movement.
Alan’s first point is that “Best-to-market trumps first-to-market”, offering as examples:
- an ergonomic peeler versus a dinky metal peeler
- some clunky MP3 player versus the iPod
- AltaVista versus Google
Good design–innovative products–creates loyalty and enthusiasm in users that overcomes the advantages of first-movers.
If best-to-market is so important, why is “first-to-market” deemed so important by business people?
I don’t think we ought to be emphasizing innovation; in our industry, it will happen. Innovation means invention, but in the minds of business people, I believe it has come to mean “success”. But innovation doesn’t mean success (holds up that original clunky MP3 player that failed–”this was innovative, but was never successful”).
It’s design that leads to success, not first-to-market. Business people accept the need for design, but don’t understand its importance. Business people who rush to market and then innovative in subsequent versions–that’s hellishly expensive.
The Seek Paradigm: Have the user ask for what they want.
The Show Paradigm: Display everything up front, and let the user explore and organize it.
“The first is usually more prevalent on the web. The latter usually more prevalent on desktop or deeper web applications. Theresa lists 10 different patterns illustrating Seek and Show.”
She details both paradigm with very nice real world examples.
I remember sitting in a Microsoft presentation that first showed off Expression Web, and the promise of finally moving past the current way of working with designers:
Designer: "Here mate, enjoy this jpg"
Developer: "Ok, I cut it up and made it into a web page, but now I need to tweak this area, can you send me a new one?"
Designer: "Here mate, enjoy this jpg"
... repeat ...
Now it is Adobe's turn to have a swipe at the problem, and they have released Adobe Thermo to help you design RIAs and really use artifacts.
I don't think anyone refutes the wisdom of this suggestion, but many folks responded to Aza's article with the complaint that the implementation of undo is too hard to be generally feasible. Aza has now come back with his thoughts on a simple client-side implementation of undo for Ajax (part 1).
I admit I personally cut corners all the time in this matter, violating my own beliefs and issuing warnings. :-) Has anyone in the community had experience implementing a robust undo?
John Allsopp has developed XRAY, a bookmarklet that launches a tool to visualize the web page that you are on (a little like features in Firebug and Firefox). The look and feel is great, and the margin popups look like the new Safari/Webkit search functionality (mmm orange).
What is XRAY
XRAY is the first in hopefully a suite of free cross browser tools for helping web designers and developers better visualize what their code is doing in a browser. XRAY is designed to help you get beneath the skin of your web page.
XRAY let's you see the box model for any element on a page in action - where is the top and left of an element, how big is each margin, how big is the padding, how wide and high is the content box?
What platforms and browsers is XRAY available on?
XRAY currently has been tested on Safari 2 and 3 on Mac OS X, Webkit nightly builds, and Mozilla based browsers (Firefox, Camino and so on) on Mac OS X and Windows. At present it won't work on Internet Explorer (XRAY uses the canvas element, but plans are afoot to adapt it for Internet Explorer), and has not been adapted for Opera. We hope to have versions for Opera shortly, and Internet Explorer on Windows in the not too distant future. XRAY works in Safari 3 on Windows, but clicking a bookmark does not fire any Javascript it contains. To use XRAY on Safari 3 for windows at present, you'll need to paste the XRAY link into the address field and hit return.
Sarah Nelson and David Verba of Adaptive Path presented Practical Design for Ajax, a very good overview of many of the design and user experience issues in web development. They covered a lot of ground in 90 minutes and still had some good concrete examples. There were also several book recommendations to explore issues more in depth – I’ve collected those at the bottom of this post.
User Experience
success comes from the user experience (editor: see also Creating Passionate Users, if you aren’t already subscribed)
successful design depends upon context, priorities
know who users are – design for all users
understand your users – context, motivations, challenges
consider the user experience from ground up, not something you can throw in at the end
Strategery
what we do we want to get out of the site?
what do users want out of site?
determine our site objectives: ie revenue, or community, or sales
get to know the users
find the overlap between what stakeholders want and what users want
what we learn from users should drive strategy
Scope
dont try to be everything to everybody
fall back on ecosystem of apps – ie use apis/mashpus to bring in other sites’ strengths
just build the damn thing. prototype it in html/js/css
no best practices
Q&A
q: How to deal with designers who expect us to replicate pixel perfect photoshop mockups?
a: Patience, communication. The issue starts to go away as more designers learn to operate in a more agile way, working with developers instead of throwing their designs over the wall.
q: How can you get designers and programmers to work together with ajax?
a: work for a Rails startup. Or go agile. or work for adaptive path. Real answer: education or just game the system: just get the right people in the same room and get them talking. Find receptive designers and work from the bottom up.
q: Can you recommend any accessibility books?
a: Not really. (ed: Dive Into Accessibility is a free online book. Its old so it won’t cover ajax accessibility, but many of the fundamental principles apply.)
CSS is pretty central to Ajax, and large Ajax projects often have a lot of CSS to deal with, so it's worthwhile asking how to maintain all of it. Garrett Dimon's Architecting CSS is a good set of advice for structuring your CSS files (from July, 2005; unearthed on Digg).
The article identifies three ways to organise your stylesheets:
Archetype-Based A stylesheet for each class of page, e.g. homepage stylesheet, article stylesheet, etc.
Page Element/Section-Based A stylesheet for each class of page section, e.g. header stylesheet, sidebar stylesheet.
Tag-Based Similar to the previous approach, but based around tags, e.g. form stylesheet, table stylesheet.
Digg this review!
Christian Gross' Ajax Patterns and Best Practices is a quality book for the intermediate to advanced ajax programmer who is looking to expand their skills. This is definitely not a beginner's introduction to ajax, as once you get past the first three chapters or so Gross dives into some heavy duty patterns for difficult problems in ajax. The book suffers from a lack of editing and a few curious technical remarks, but overall it does a good job of covering ajax patterns and practices. Gross is obviously a fan of REST and XML, so your views on this book might depend upon how much you agree with his technical choices.
Chapters one and two cover the basics of the XHR object and using the factory pattern to abstract away browser differences for the object. Chapter three covers "Content Chunking", Gross' term for what he admits is core to ajax - an event leading to an asynchronous request with then responds with some sort of content to inject back into the document. Chapter four covers caching practices, and five covers the "permutations" pattern - ie separating the URL resource from the representation. Six covers "decoupled navigation" (ie seperating the event triggering/handling from the business logic they fire), seven covers switching between states seamlessly, and eight covers the even popular "persistent communication" (ie polling) pattern that many of you may have seen yesterday in coverage of the WWDC. Nine covers workflows in ajax with the "state navigation" pattern, ten is "infinite data" (see the scrollbar at live.com), and eleven covers treating remote services as the model in MVC via REST.
So there is a lot of content here, and the code examples are done well for the most part. The code used in the book was extracted later into a framework, so its nice to see the code being used for something beside toy examples. Server side examples are in Java or C# with a few exceptions, with all of the serialization in XML with some XLST examples also shown. The javascript code seems to follow some strange conventions, with TitleCase function names for example. There are no third party frameworks used or covered.
Regarding serialzation, Gross has this to say about XML vs everything else:
Many people might think that XML has its problems and have proposed protocols that are better. Frankly, I think that is plain wrong...Therefore, when writing your own Ajax and REST applications, stick to XML.
While I certainly see Gross' point about the benefits of interoperability with web services when using XML, he fails to mention how sites like Yahoo and del.icio.us are offering their data in JSON. If your app will only ever talk to del.icio.us, for example, it might not be best to go with XML. There are also the cases where you have complete control over the services, for an intranet app for example, and you may go with JSON or YAML for developer friendliness. I think at least discussing serialization in the context of a simpler app that doesn't talk to web services would have been helpful for developers who aren't writing the next big XML mashup.
Besides that nitpick, this book will be great for someone who wants to know some of the big pitfalls of creating large scale ajax apps, and ways to sidestep them. The only other significant fault is the editing, with one too many awkward run-on-sentences. The overall tone is conversational and easy to follow once you get past that. The patterns covered are very useful, particularly the caching pattern and the different ways of handling transitioning and transforming state. Recommended, particularly if you are doing a lot work with REST/XML and multiple web services. If you can only own one Ajax book - get Ajax in Action - if you own two, make Ajax Patterns and Best Practices your second choice.
In the guide which you can download from the link below I'll cover the process I have developed in the course of implementing two AJAX applications as a developer for Duo Consulting in Chicago. This approach has made it easier for me to work with the design team, produce estimates for this type of project and communicate what is involved each step of the way to the project managers for scheduling purposes.
He begins by taking a UI sketch and marks all "discreet sections". Each section becomes its own JS file. From there, you decide on each interaction in each section, and create a Javascript function for it, later consolidating repeated functions into reusable objects.
You also need to consider the nature of remoting, and the guide distinguishes between four styles - essentially a 2x2 quadrant. One dimension is Uniqueness, i.e. whether the call is cacheable. The other dimension concerns the destination of the call - will it be some HTML rendered directly on a UI element, or some metadata that's interpreted by the Javascript event handler. The document shows how to use the Prototype library to achieve all these combinations.
Duo is hiring right now, looking for ColdFusion developers to work in Chicago.
Particletree has posted two parts in a series for designers trying to develop site structures that will use Ajax for some of their functionality - "A Designer's Guide to Prototyping Ajax".
A combination of CSS, XHTML and JavaScript, prototypes help interface designers convey effectively how an Ajax page should behave to a programmer. Over the next three weeks, Kevin will be going over some guidelines our team uses when tackling an Ajax project.
They introduce various skills the designer will need to accomplish the job - relationship skills, XHTML skills, and CSS skills.
In the second part of A Designer's Guide to Prototyping Ajax, learn about some of the wireframing techniques we use to prep an interface design for prototyping.
...gets more into things like keyframing (different versions for different events), stacking (layering the possibilities in one file to avoid multiple versions), using useful class names in your CSS, and using the CSS boolean.
- before Jesse coined Ajax...
- opinionated usability.
- learn about your users by observing them.
- THE book for information architecture.
