Looking at standard development phases, as a background.
Lo-fi using stickies (post-it notes) to capture design features. Then lo-fi UI sketches. For some sites, this is where we would stop, no need to go any further because it’s obvious - can just go straight to detailed visual design.
Richard’s showing some detailed wireframes. These are actual web pages. ratemyarea.com - the final site ended up very different from the wireframe, but that’s fine. The wireframe contained all the basic content. Yes, CSS isn’t magic and they did have to re-code HTML and CSS, but still, can retain some things like usage of microformats.
Looking at sites like Kayak and Google Analytics with a ton of Ajaxy complexity. Can’t get a feel for this until you play around with it.
Patterns - design that can be reused: e.g. headers and footers.
Behaviours - e.g. progressive disclosure. e.g. including a lightbox in the wireframe because it’s trivial for us to put it in there (using a standard library, without bothering to customise it at this stage), and it is significant to the interaction, so we can see if it feels right. e.g. on e-commerce site, adding to basket updates the basket field - doing this in the wireframe lets us see if users notice the update.
Views - Exploring/experimenting with views of particular interest. e.g. how a significant table or list might be ordered.
Notes - Embedding design notes inside the page, using CSS to toggle them on and off. e.g. simulate login/logout by stylesheet toggle (not real login). (a specific css class for “logged in” or “logged out”). See polypage library.
You can use a single CSS attribute to reference whichever is supported on the currently browser and gracefully degrade on browsers that don't support either technology:
What's the greater of these evils: contorting site designs around the standard Web-safe fonts, using images to render type, or relying on sIFR to render type with Flash?
Who knows, but man, it sure would be nice if we could reliably use any font we wanted in our web work. And, as it turns out, IE4+ and Safari 3.1 offer mechanisms for doing just that.
The linked font can be a regular old TrueType font. Compare this to IE6/7 which also support the @font-face at-rule but only support special "Embedded OpenType" fonts.
At first blush, you and I might think, "Yay for Safari! And, thanks IE for yet another screw." But that was before we considered the DRM issues. You see, there's an established technology for enforcing the use of fonts in embedded applications, and CSS's @font-face bypasses it by directly linking to TrueType fonts. At least one major font foundry is mighty uncomfortable with the thought of more browsers following Safari's lead.
Hence fontembedding.com, a newly-launched site promoting the virtues of the long-misunderstood and under-loved Embedded OpenType (EOT) format and the evils of linking to TrueType on the Web, complete with a call to action to other browsers to support EOT once the recent W3C EOT submission is ratified (i.e., maybe we can expect to use them cross-browser in 2014). EOT, you see, embeds the URL of the website that licensed the font for embedded use so that User-Agents can enforce font licensing restrictions.
Fascinating.
I wish them luck with EOT; in the meantime I suspect Firefox will implement @font-face and enough high-quality freely embeddable TrueType fonts will emerge to ensure that EOT remains as irrelevant as it ever was.
But then, I've been wrong before.
Still, fun to realize that as soon as Firefox implements @font-face, thanks to TrueType-EOT converters, we can finally use fonts on the web. Myspace will never be the same.
Jake Brumby of the European Ajax development shop Magic Toolbox recently pointed us to three of their creations: Magic Zoom, Magic Magnify, and Magic Thumb.
Each of these effects has a really nice implementation that works across a large number of browsers:
Jake shared some of their experiences building these effects with us:
Initially, our key challenge was making it work in all browsers. As usual, IE 6 and IE 5.5 gave the most headaches and we spent a long time finding workarounds. Getting the expand/contract effect to work smoothly in IE took quite a while. Getting the close/next/previous buttons to fade in and out in IE was also tough.
Another lesson is that when you are building a tool that will be used on many websites, you need to test under a lot more conditions than a script for a single website. One of our first customers used it on a site with Flash navigation. The Flash navigation continued to be visible after the image had expanded, which is not what you want. So we needed a way to keep the enlarged image above all the other content. No matter how much testing you do, there are likely to be small bugs after launch and you need to be able to react quickly to fix them.
To ensure the smallest possible script, they built it without using an existing JS library:
One other lesson was that for the best results, you need to code from scratch. We did an initial trial using MooTools and we achieved the effect we wanted but the source code was well over 100kb which we deemed too high. It was useful as a proof of concept, but the final version of the tool was coded entirely from scratch.
This is all well and good, but... are they worth paying for? Each of these three effects is sold separately. On the one hand, with such excellent open-source frameworks out there for doing Ajax effects, etc., having to buy these seems... weird. On the other hand, they are free for non-commercial sites and if you're an e-commerce site, if you apply these effects all across your site, they can have a big impact, and having someone else deal with all the cross-browser issues for you (or else you get your money back) seems like a good deal, along with the 30 minutes of free support they throw in.
I confess I have a soft spot for ISVs (Independent Software Vendors). I love to see small teams out there making quality software for a living, especially now that so many have to compete against free software. Do these products from Magic Toolbox compel you to consider purchase? Or do you feel the open-source stuff is good enough?
A final note from the Magic Toolbox team:
Magic Thumb provides a lot of customisation features that you don't get with other lighbox effects. It's also the only one we've come across that "grows" the image immediately in front of the user. It gives the user a greater feel of control and because it loads immediately it keeps them flowing through the website. That's good for usability.
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.
, Design
- before Jesse coined Ajax...
- opinionated usability.
- learn about your users by observing them.
- THE book for information architecture.
