- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
A New Workflow for Web Designers
It was Tim Berners Lee's original vision of the web that online documents be both readable and writable. He notes in his book "Weaving the Web" that that he was disappointed with the way the browser was initially developed as a read only technology, making it expensive and onerous for the asses to publish online content, and essentially creating a top down system, with lots and lots of readers but few writers.
Only recently has the technology that allows anyone to easily publish and edit online documents, in the form of Wiki's and Blogs, been developed. These tools have become so popular, so ubiquitous precisely because they cater to what users really want, fulfilling the potential that the web's founding father had envisioned for it almost 20 years ago.
Continue reading »
Topics: CMS, Web Design, workflow
Viewport width: Size matters, but not in the way you’d expect
When a company gears up to redesign its website, the question of screen resolution always seems to eat up tons of time and energy. Despite the long, slow evolution of the browser from a publishing medium to an application platform, many developers still think in terms of "web pages" - large units that require, if not fixed dimensions, then at least a fairly defined range of viewport mins and maxes. Rather than thinking of the browser window as an operating system full of work spaces, palettes and menus, we think of it in print terms, like a newspaper page full of columns and sidebars. This occurs despite a decade of education to the contrary from any number of software and visual design experts.
Topics: Usability, User Experience, Web Design
Plug: Designing Invisible Interfaces Webinar
My colleagues Matt Nolker and Shalom Sandalow have put together a nice little webinar entitled "This Won’t Hurt a Bit": Designing the Invisible Interface.. For those of us writing Web 2.0 applications, there are some key insights here, such as: "interacting with the software is not the primary goal or responsibility of the user." So when you use those nifty Ajax widgets, think about whether you are placing a usability burden on the user or are using the power of Ajax to make the interface disappear.
Technorati Tags: uxd, webinar, invisible interfaces, usability
An Event Apart Chicago: Day 2
Tuesday saw the conclusion of An Event Apart Chicago 2007, the two-day web-development conference from the folks at A List Apart. Here's my sequel to yesterday's day-one overview. I'll be back Friday with analysis and afterthoughts.
Jeremy Keith, author of "Bulletproof Ajax" and "DOM Scripting," led the day. His topic? "Be Pure. Be Vigilant. Behave," wherein he outlined the concepts behind "Hijax," the application of progressive enhancement to Ajax functionality. A staunch proponent of unobtrusive JavaScript, Keith warned against throwing web standards out the door when developing Ajax functionality. His examples demonstrated how to separate behavior from content and presentation by abandoning such outmoded techniques as the
Next up was Luke Wroblewski, a Yahoo product designer whose resume includes work on the original Mosaic web browser. Wroblewski covered "Best Practices for Form Design" using exhaustive research from his forthcoming book on the subject. In case study after case study, he demonstrated how simple choices in the design and deployment of HTML forms - from the widths and alignment of inputs and labels to the placement and visual differentiation of cancel and submit buttons - can cut the time it takes to complete them in half. Wroblewski's most persuasive argument, however, was conceptual rather than technical. He made a powerful case that because forms are barriers between users and the things they want to do - buy your product, join your site or begin creating content - you should make them as easy to get through as possible. This central thesis added considerable weight to his many practical how-tos.
Accessibility advocate Derek Featherstone closed off the morning with "Accessibility: Lost in Translation." Featherstone looked at how markup choices can make a site transparent to assistive devices - or render it totally opaque. Using real-world examples from Amazon and other sites, he demonstrated how screen-reading software actually parses markup. His live examples proved that the lack of semantic markup and the absence of ostensibly optional HTML attributes can render a site worthless for disabled users. Featherstone then went beyond the basics, explaining how source order - the sequence in which nodes appear in your markup - can be used to enhance accessibility. By placing your central content first, then positioning chrome above it with CSS and providing jump navigation to skip past inessential modules, you can achieve the presentation you want for typical users without shortchanging disabled ones. In another example, Featherstone examined the ways in which meaning can be encoded in the color and position of elements on the page - and how to replicate that meta-data in a way that disabled users can understand. As with many of the other speakers, Featherstone's examples argued persuasively for the continuing relevance of web standards.
After lunch, CSS expert Eric Meyer again took the stage, this time to explore "The State of CSS in an IE7 World." Using the recent release of Microsoft Internet Explorer 7 as a springboard, Meyer illustrated the concepts that have governed the changing of the browser guard for more than a decade. His overall premise was that developers need to use their own server logs to gauge when support for an older browser can safely be dropped for their site. For most of us, IE6 isn't going away anytime soon, so we need to get creative if we want to harness advanced functionality. To that end, Meyer delved deeply into the details of IE7 techniques, filters and hacks. He praised the browser for the strides it makes over IE6's CSS engine in such areas as child selectors, adjacent sibling selectors and attribute selectors. His real-world examples demonstrated how such functionality adds power and elegance to our code. To cope with IE6's continuing market share, Meyer advocated the use of Dean Edwards's IE7 compatibility script, a JavaScript library that adds IE7 capabilities to older versions of the browser. The take-home message was that older browsers may take a long time to die out, but creative programming techniques can harness the future of CSS now.
The final two sessions for AEA Chicago 2007 were a little offbeat, which was a relief after 10 technical sessions in the previous 32 hours. In the highly anecdotal "Selling Design," ALA publisher Jeffrey Zeldman used stories from his own long career to illustrate best practices for handling difficult clients. His thesis was that collaborative work requires us to deal with a wide range of other people, so we should hone our ability to influence our collaborators - and pick good clients to begin with. Agency owner Jim Coudal closed things off wittily with "Dealing With the Both of You," a slide-free presentation about the crossover between personal projects and professional work-for-hire. Coudal assembled a number of satirical short films to drive home his point: Because most web developers are curious and easily bored, we should strive to marry passion with professionalism whether our clients are external or ourselves.
An Event Apart Chicago: Day 1
The folks from A List Apart rolled into town yesterday for An Event Apart Chicago 2007, a two-day web-development conference. Around 500 programmers, designers and information architects flocked to the seventh floor of the downtown Mariott for a varied slate of talks by some of the biggest names in the industry. Today and tomorrow I'll give high-level overviews of each day's sessions. On Friday, I'll provide some color commentary.
Stylesheet guru Eric Meyer's "Secrets of the CSS Jedi" kicked things off with an in-depth case study in which pure CSS 1 and 2 transformed tabular data into an Excel-style bar graph. Meyer's presentation was interesting not only for what his techniques could accomplish, but also for what they couldn't. It was inspiring to see that plain-vanilla data could be given a powerful visual makeover, yet still remain completely semantic and accessible to handicapped users. But it was disheartening to see that the simple addition of tick marks within the graph demanded the addition of hard-coded percentage values to a number of CSS classes. The lack of simple computational ability within CSS declarations has long been a drawback of the "not a programming language" language. CSS remains a powerful and flexible technology, but, as I discussed at length a few days ago, it's got a lot of room for growth. For those who were already conversant with Meyer's techniques, perhaps the most interesting digression in his talk was the chance to tear through Firefox's built-in browser stylesheets and see how even the most fundamental rules of HTML presentation - such as the invisibility of meta tags and the entire <head> block - are controlled by CSS behind the scenes. Meyer also went over the basic building blocks of the kind "reset" stylesheet most jedis use.
Up next was Jeffrey Zeldman, publisher of A List Apart and therefore another another rock star to this crowd. A lot of recent ALA content has focused on the overlooked art of writing for the web, so it was no surprise that Zeldman tackled the topic "Writing the User Interface," which packed in plenty of practical advice for writers and non-writers alike. His central thesis was that copy was the cheapest and easiest thing to improve on most sites. Using lots of witty real-world examples, he provided a useful paradigm for breaking textual content into discrete components - guide copy (a.k.a. instructional text), brand copy (taglines and other branding assets), copy copy (a.k.a. real content), labels and URLs - and applying different editing criteria to each. As befits the author of "Designing With Web Standards," Zeldman was careful to demonstrate that the rules of good web writing and the rules of semantic markup are often one and the same. As with most of Zeldman's advice over the years, he started with a compelling philosophy, then showed how to break it down into small, actionable steps.
Happy Cog designer Jason Santa Maria finished off the morning block with "Design Your Way Out of a Paper Bag," a look at the process of rebranding and redesigning an existing site. An illustrated tour of Santa Maria's own iterative design process, the presentation was, like the earlier sessions, a case study in how a series of small steps can have a big impact on the usefulness of a site. Using an amusing Flickr tour of real-life signage and the abuse and misuse of the poor apostrophe therein, the designer drove home his biggest advice: "Sweat the small stuff." Along the way, he touched on typography, branding, logo development, grid-based layout, whitespace and other design concerns. As befits a designer, Santa Maria's session was probably the most visual and the least easily captured in the PDF slides distributed to attendees. He did, however, suggest some excellent further reading, most notably "The Elements of Typographic Style," "Thinking With Type," "Grid Systems" and "Making and Breaking the Grid."
After lunch, Lou Rosenfeld led with "Search Analytics For Fun and Profit." In a series of painstaking real-world case studies - most notably of my alma mater Michigan State University - Rosenfeld explained how server logs and especially search engine logs offer the keys to a successful site redesign. It's a simple idea that may seem elementary to many developers, but given how infrequently web-development teams actually use this feedback loop effectively, Rosenfeld's techniques struck me as really powerful. You would expect a session like this to show you how users' most popular search terms could serve as the springboard to an overhaul of your navigational systems. But Rosenfeld also delved several levels deeper, showing how much powerful business intelligence can be obtained from inexpensive tools with little or no custom code to support them. Site indices, metadata, search algorithms and the search interface itself - all can be tweaked based the subtle metrics that emerge from careful, detailed session analysis.
Perhaps the most inspiring session was Liz Danzico's "The Seven Lies of Information Architecture," in which the Happy Cog information architect recast the high commandments of IA as guidelines rather than rules. Danzico used copious examples to demonstrate how the most successful sites often bend or break the supposedly unwavering rules of IA. The idea of the magic number - most users can only remember 7 +/- 2 items in their short-term memory at any given time - was the first concept to show cracks under Danzico's microscope. She went on to debunk the holy status of such maxims as "consistency is good," "navigation is necessary," "the shortest path is the best path," "experience must be seamless" and "users should always know where they are." Sometimes, the idiosyncratic nature of her examples suggested that certain guidelines work for most sites and are best broken only for a specific purpose. Other times, especially in her examination of Amazon's and Apple's navigational systems, her case studies suggested that even mainstream sites do and should break the rules. It was Danzico's last rule - the idea that only IAs should do IA work - that she most thoroughly debunked by the end of her session. She argued passionately that site owners, designers, programmers and end users can and should understand the guidelines of information architecture - but, like IAs themselves, they should apply those guidelines judiciously rather than rigidly.
Last up was designer Dan Cederholm, founder of SimpleBits and Cork'd. He constructed an elaborate site prototype, ToupeePal, to demonstrate "Interface Design Juggling," his thesis that great design involves keeping lots of balls in the air at the same time. Delving deeply into typography, microformats and the development of favicons, Cederholm demonstrated that beautiful and useful interfaces can be constructed using the supposedly unsophisticated visual and informational tools already at our disposal. Cederholm cried foul on the idea that web typography sucks because too few cross-platform fonts are available. He argued that the single-font typography of the Itallian Renaissance is some of the most beautiful ever created, then he demonstrated practical techniques for getting similar mileage out of limited existing web fonts. Word-spacing, letter-spacing, line-spacing, color, weight, italicization and other simple tools can all elevate even the most familiar typefaces into the design stratosphere. Likewise, even a tiny 16x16-pixel favicon can provide a powerful branding tool when designed correctly. Cederholm closed with an in-depth look at the "accidental API" of microformats, demonstrating that a even a grassroots open-source movement can add power and value to the web without the support of standards bodies and browser vendors.
Check back tomorrow for coverage of today's sessions, from Eric Meyer's look at the post-IE7 world to Derek Featherstone's talk on accessibility.
CMS and AJAX
Back in April, CMS Watch published an article entitled Ajax and Your CMS. The article looks at the impact of AJAX on CMS systems from both the content author's and the site visitors perspective. From the author's perspective, the news is all good and pretty conventional as far as AJAX articles go: fewer click, drag-and-drop, faster, more powerful UI. There are a few noteworthy points to the article, however. For one, content management with AJAX enabled, single-page sites puts a premium on managing assets:
If you are going to use a heavily-Ajax-driven interface on your websites, then it is worth considering a CMS to manage intra-page snippets and interaction as discrete elements. In practice it could be difficult to manage a rich, interactive site that uses single page interfaces without a CMS, since at this point you are managing content components rather than entire "pages." The whole notion of "pages" tends to dissipate, which would call for a more component-oriented -- rather than page-oriented -- CMS for those looking to manage Ajax-driven websites.
So, if you're publishing content rather than constructing an application, then composing a bunch of widgets together using a CMS sounds plausible. However,
Web CMS tools are notoriously poor at managing stylesheet elements and client-side scripting in particular. The rise of Ajax should prompt some improvements here.
Improve or die, I guess.
The few bad patches for the content author are things that people are already working on: back button, refresh/reload an state, etc. Previewing content from a single page interface is a problem not just restricted to CMS's. You can identify the "states" within the single page interface and preview those, i.e. "show me the state after a restaurant has been picked."
That's It?
The fact that CMS Watch really struggled to find much more to say about AJAX than "will make it easier to use, may make content harder to manage," I think points out that nobody really has a clue about how to effectively use AJAX for content sites. All of the major AJAX enabled sites these days seem to be collaborative filtering excercises like digg and dzone. There must be better ways than this to apply this nifty technology.
I think we can come up with a few ideas. What are some of the content display issues we can tackle with AJAX? Let me give three off the top of my head:
- Screen real estate - we can summarize an article and expand the full test into a new reading context when the user navigates to it. I have a primitive little example here. Just click on one of the text boxes to read the full article in place.
- Breadcrumbs on steroids - this is more about providing a better reading metaphor. We can make the sections of the paper fold and unfold, allow the reader to rapidly navigate through tabs or trees. No more slow postback means we can try more stuff.
- Contextual control - the WSJ already has the capability to right click on a selected word and perform a search. But contextual search, navigation, and other operations are the next step. Imagine an online newspaper where a reader can right click in an article about their neighborhood and get restaurant review listings for nearby establishments. You no longer have to cram every single relevant thing into the sidebars!
The day is still young on CMS and AJAX. Think outside the box and share your own thoughts on what AJAX can do for CMS.
Smell the Hype - Gartner Analyst Puffs up AJAX
From a UPI article quoting the gartner analyst David Mitchell Smith at a conference in Tel Aviv.
By this time next year, Web sites not developed using the Ajax technique "will simply not be cool enough to use," an Internet analyst said Tuesday.
[...]
The research firm, noted for its predictions on technology and business, summed up by positing that there is an 80 percent chance that "By 2008, Ajax-style (sites) will be the dominant style for Rich Internet Application interfaces."
[...]
Gartner analysts expected most businesses to rush out and try Ajax without effectively utilizing Web 2.0's community, social and user-driven aspects. In this case, "the result (of adopting Ajax and other new technologies like Really Simple Syndication and Mashups) will have minimal business impact," Gartner research said.
His advice to businesses was to get on board -- "Management should lead cultural change by example ... by blogging to the staff. This sends the message that this is the way the company should think."
"Denial is pointless," Smith said to sum up. "Don't just roll your eyes -- this is going to be a really big thing when it all comes together."
And they get paid for this advice? Perhaps they need to switch to decaf and read 10 Business Reasons to Use AJAX.
Topics: Business Reasons for Ajax, Web Design, Web/Tech
AJAX and the Zeigarnik Effect
My colleague Bob Moll over in the UXD blog writes about the Zeigarnick Effect and it's implication for designing GUI's. What is the Zeigarnick Effect? Bluma Zeigarnick was a Russian psychologist who in the 1920's discovered that we remember unfinished tasks much better than completed ones. This memory comes from a psychological pressure to complete unfinished tasks.
Bob notes that in a rich GUI, the psychological pressure is to detour and finish short tasks, leaving a trail of longer, unfinished tasks. He suggests that we include a facility for a queue of unfinished tasks in applications so that users can easily go back and finish them.
In the web application world, we avoided this aspect of the Zeigarnick Effect by making it difficult if not impossible for the user to diverge from the page flow. Now, with the capability to use fancy modal dialogs that interact with the server, we can add optional subtasks into the flow. AJAX-powered command completion helps prevent the the user wandering off in another window to search for the right thing to enter. My favorite example is the WSJ's selection-based search, which avoid interrupted reading to search for another term.
As you design your applications, give some thought to the Zeigarnick Effect and how you can use AJAX to smooth the continuation of interrupted tasks.
Topics: Design Patterns, Patterns, User Experience, Web Design, Zeigarnik Effect
Quick, It’s the Feds! Hide the AJAX!
I was arguing with a speaker at an SOA conference yesterday about whether AJAX for public facing websites was a bad idea. He kept insisting that if you use AJAX, you will get sued, and that Southwest Airlines had in fact lost a case on accessibility already. His claim was bugging me for the rest of the conference, so after I got back to the office I checked up on it. It turns out Southwest actually won that case. But there are new lawsuits springing up all the time.
It seems that to comply with the ADA and other state laws is onerous, to say the least. The following excerpt is taken from an article published in 2000, a time when the amount of non-accessible mischief one could in the browser was comparatively small:
The British national anthem has been described as a series of curt demands on
Jehovah, but it has nothing on the list of demands placed on Web developers by
the "Web Content Accessibility Guidelines," published by the private but
quasi-official W3 Consortium's Web Accessibility Initiative (which Brewer
directs). "Don't rely on color alone" to convey information. Don't use
navigation methods that require a mouse; some users have motor impairments.
"Until user agents allow users to freeze moving content, avoid movement in
pages." Same with blinking or, worse yet, flickering text (which may cause
seizures in persons with photosensitive epilepsy). Don't use tables for layout
unless you're really trying to render tabular data, and watch out even then
(text readers for the blind have trouble with tables). Don't use block
quotations as a shortcut when all you're trying to do is indent. (For the full
text of the guidelines, see www.w3.org/TR/WAI-WEBCONTENT.)That's just a sampling. Other sins include "poor color contrast," "lack of
alternative text for imagemap hot-spots...lack of alternative information for
users who cannot access frames or scripts." Don't use auto-redirect or
auto-refresh, or cause links to open in a new window. "Use style sheets to
control layout and presentation"--and if you haven't gotten around to learning
style sheets or you use older page authoring software that doesn't provide for
them, that's your problem. Don't use audio clips on your site unless you
caption them for the deaf, or video clips unless you attach descriptions of
what's going on for the blind.
Now providing alternative, textual ways of doing things is fine if you're talking about entering dates via a choice of a text field or a popup date picker. It's a bit more challenging to do that with direct manipulation interfaces -- certainly with my favorite example, UML, which is a visual representation of non-visual concepts. Yes, you have the ability to transform the model into XML or some other textual form which could then be read by screen access software or printed on a tactile display, but providing a way to manipulate the textual "diagram" would require a whole new user interface. Let me repeat that: fully functional, accessible alternatives for direct manipulation user interfaces would require the development of a whole new user interface. That's cost prohibitive for most businesses. Tactile displays are an option, but they are low-res and expensive. (See here for a presentation on UML for blind programmers.)
Even for sites employing very simple and limited uses of AJAX the news is not good. James Edwards has done some practical tests of screen readers with Javascript, i.e. can they detect changes in the DOM and so on? His conclusion:
I'm forced to conclude that, unless a way can be found to notify screen
readers of updated content, AJAX techniques cannot be considered
accessible, and should not be used on a production site without a truly
equivalent non-script alternative being offered to users up-front.
In the desktop world where RIA's are the norm, there are API's and standards
for integrating screen readers with applications. Maybe each rich web
application should come with an XML feed that accomplished much the
same thing.
Of course this isn't just a dollars and cents or even a legal issue. It is a moral issue as well. My mother-in-law became legally blind as an adult, just a bit too late to learn braille and most of the other tools of which the blind make use. Her tools are the worlds largest magnifying glass and software that reads the text of web pages to her. The number of sites that she just plain can't use has gone up over time, and has really soared in the past 18 months. (If you want to know what that feels like, download the lynx browser -- one of the first web browsers back in the pre-image days. Even sighted, navigating through pages with their reams of sidebar crap is excruciating.)
Yes, she represents a small market. Yes, it's expensive to provide fully functional, accessible alternatives to the RIA's we want to write. But should we shut her out of what goes on online just so we can use our nifty RIA apps? Personally, I don't think there is an effective way to split this baby. Provided that you make use of only limited amounts of AJAX such as autocomplete in forms, you can probably make it work, but when the drag and drop starts flying, and the visual metaphors abound, what can you do?
Topics: Accessibility, User Experience, Web Design
Direct Manipulation Interfaces, Document-Centric Applications and 7 More Reasons to Use AJAX
Alex Bosworth over at Source Labs has a blog entry up entitled 10 Places You Must Use Ajax. I count six places you should use them and six that you shouldn't. His arithmetic aside, he makes some good points about where AJAX can be employed, mostly from a general usability standpoint. For instance,
- Deep hierarchical tree navigation.
First of all, applications with deep hierarchical tree navigation
are generally a nightmare. Simple flat topologies and search/tagging
works very well in most circumstances. But if an application really
calls for it, use Javascript to manage the topology ui, and Ajax to
lessen the burden on the server by lazy loading deep hierarchy data.
For example: it's way too time consuming to read discussion threads by
clicking through and loading completely new pages to see a one line
response.
In point of fact, these types of uses are already commonplace. I'd add one big category that he missed, namely the Direct Manipulation Interface. From the wikipedia definition:
Direct manipulation is a human-computer interaction style that was defined by Ben Shneiderman
and which involves continuous representation of objects of interest,
and rapid, reversible, incremental actions and feedback. The intention
is to allow a user to directly manipulate objects presented to them,
using actions that correspond at least loosely to the physical world.
Having real-world metaphors for objects and actions can make it easier
for a user to learn and use an interface (some might say that the
interface is more natural or intuitive), and rapid, incremental
feedback allows a user to make fewer errors and complete tasks in less
time, because they can see the results of an action before completing
the action. An example of direct-manipulation is resizing a graphical
shape, such as a rectangle, by dragging its corners or edges with a
mouse.
Google Maps is a good example of this style as realized in AJAX, as are the drag-and-drop aspects of many of the new AJAX enable mail and calendaring applications. The places to look for good uses of this style are existing desktop applications. In fact, beyond direct manipulation, there are a number of other techniques worth using as we move from the simple data report applications that Alex envisions and the more document centric apps of the web future. It is the user's experience with these desktop applications that will make their introduction in the web effective -- in short, the user already knows how things should work.
- Use visual metaphors whenever appropriate
Alex argues that "a slider to pick the price to the cent is just overkill." I agree, but that's not an argument not to use a color picker or a slider to manipulate contrast settings in an image within a CMS.
- Spacial data manipulation
We've already mentioned Google Maps as one example of this. Management and monitoring of nodes and edges, such as UML class diagrams, Physical computer networks, BPM diagrams, are also a staple of desktop apps that are now within reach of the webapp with AJAX.
- Modal dialogs for presentation of finite tasks
Ironically, it is the use of modal dialogs within the AJAX app that makes the webapp less modal as a whole. It removes the need for separate data entry and support screens -- two distinct "modes" of the program. As it stands now you have an unpleasant choice, as popping up non-modal browser windows to perform modal tasks is problematic.
- Modeless dialogs for presentation of ongoing tasks
Displaying controls and results in modeless dialogs allows users to work their way rather than in a tightly constrained flow dictated by the application designer. Searching and search results, detail information, task lists, tool bars, contextual help -- all optional or peripheral information that can benefit from modeless dialogs.
- Visual Feedback for long-running tasks
That's right, long running tasks. It was awkward tracking ongoing processing before AJAX. Now that we can handle them, we should use thing like progress bars to give users an idea of what exactly is going on or dynamic tooltips to allow users to investigate status on demand.
- Application level undo instead of the Back button
When manipulating documents instead of doing CRUD, the back button can be pressed into service as an undo, but it takes some work. Better to use application level undo than the ham handed back button. Do you search the interface of your word processor or the documents on the hard disk? Do you email a bookmark to a particular UI state or the document you've produced?
- Contextual controls
Don't display all the controls -- buttons, sliders, tree controls -- at once. Display only high level controls and display new controls as you display new context. This is especially important when we are working on documents rather than reports. For example, AJAX based word processors should not display controls for editing headers and footers at the same time as displaying the controls for editing the main body.
This is just a sampling of what it a rich body of knowledge from the world of desktop WIMP GUI's can yield to the astute AJAX developer.
Alex seems to disagree with the use of some of the above applications because they are either too bandwidth intensive or because they lead to poor application design. Actually, it seems he's just plain opposed to the use of AJAX for anything beyond data updates. I agree that if write the new AJAX apps the way we've designed the layered form-and-reports page oriented applications of the past, adding any sort of sophisticated UI styles will lead to some major spaghetti code. You need to think outside the box for this sort of application, otherwise you as a developer will spend more time writing the same old forms and reports apps with a little bit of AJAX sugar, while other programmers are cranking out Rich Interaction Applications in a fraction of the time.
That's why I recommend looking at the various component based GUI's for AJAX, either the client side ones like Tibco GI or OpenLaszlo (for DHTML) or the server side ones like Echo2.
Topics: Ajax Examples, Design Patterns, Patterns, Web Design
Ajax & the “Back” button III. To boldly go where they have just come from.
It starts with a simple question.
A question that didn’t seem relevant until a bunch of others had been decided. A question that too often catches us by surprise.
The client asks - “So what happens if I click the back button?”
Why would they ask? There are many reasons, but the primary is that it is a convention they already know. The back button is one of the most reliable & flexible controls in a browser. People hit the back button when:
_ They didn’t go where they meant too.
_ They didn’t find what they were looking for
_ The server is slow and the page isn’t loading
_ The network is slow and the page isn’t loading
_ Someone designed a huge flash file into the page & failed to warn the user, so they think the site is broken
_ Someone designed poorly tested javascript or other code into the page & it is crashing the browser
So this is something people use to solve multiple problems. The one case that usually comes up in a client meeting is not finding what you were looking for.
User are drawn to the back button like moths to a flame. We see this often in mirrored testing, it precipitates a greek chorus of UXD people behind the glass moaning and wringing thier hands.
Why do they love it so? It’s big. It’s always in the same place. It does something predictable, and usually pretty quickly. Designers should be so lucky to make something that users learn so well & trust so automatically.
Topics: Best Practices, Web Design
Ajax, PageViews and the Advertising Based Business Model
As far back as December of last year, Forbes was ringing the alarm bells about Ajax breaking the advertising business model:
While a popular approach to monetizing AJAX
applications is advertising, there is a problem: There are no "page
views." For example, suppose that on an AJAX Web page, you want to view
the body of a news article, so you click a news headline link. Rather
than refresh the entire page (a page view) as you would with a
traditional web page, the AJAX technology downloads just the body of
the news article and rearranges the Web page to present the article
content.
They go on to correctly point out that Ajax presents a potential boon to advertisers, with Ajax powered ads allowing them much greater control. I would add that it could give them a much greater ability to measure who is exposed to their ads and for how long.
"Adviews," i.e. the number of ads viewed (changing every X seconds) may become the new measure, rather than pageviews. Perhaps this will drive a change in site, getting them to make the page -- rather than the site -- more sticky, and getting rid of such annoying things as article splitting.
Topics: Business Reasons for Ajax, Web 2.0, Web Design
Ajax and the “Back” button II
Designer's (of which I am one), are beginning to wrestle with the consequences of implementing Ajax, Flash and other rich interface technologies on the web.
Among those consequences, is what to do with the "Back" button. It alone is responsible for almost 50% of web user clicks on today's web. However, it can lose its usefulness--In fact become somewhat of an obstacle-- on sites powered by Ajax, Flash, and other Rich interface technologies.
Mike Stenhouse of Content With Style believes that the back button is too important not to spend significant design and development time making certain it functions properly on Ajax web apps. Without it...
The most fundamental online behaviour – click then back, is broken.
and sites become irritating at best, downright unusable at worst. Ensuring that Ajax, as a web standard fails. More here
Topics: Best Practices, Design Patterns, Rich Interactions, Web 2.0, Web Design, Web/Tech
What the Commodore 64 can Teach Us About Ajax
Here's just a little sampling of articles from the November 1983 issue of COMPUTE!'s Gazette.
- Computer Graphics - The Age Of Electronic Art
- VIC Super Expander Graphics64
- Introduction To Custom Characters For VIC And 64
- VICreations: Animating With Custom Characters
It seems every issue would have at least two articles on how to twiddle the graphical bits on the C64 or VIC-20, articles on how to make sprites dance across the screen or writing your own video game or drawing program in 6502 assembler. You had similar articles in similar magazines with the introduction of the IBM PC.
With the advent of the Mac (yes, yes, Xerox did it first), all that bit twiddling disappeared. People started wondering more about how to get windows and menus and buttons to do what they wanted them to do, or even to start developing their own controls.
Fast forward almost 23 years and read just about any blog or magazine that features Ajax articles. The articles are almost universally about nuts and bolts, nitty-gritty details, i.e.:
- Writing a server-side Ajax handler
- Creating souped up popup windows with Javascript
- Implementing fancy form controls in Javascript
- Understanding the DOM
It's bit twiddling all over again. Perhaps it's time to write an article on how to do Sprite animation with Javascript.
DO NOT PRINT THIS FORM
A number of years ago I was part of a team that developed a workflow application for a company to replace a paper based process. The new workflow app was quite a success in testing and training, so we felt fairly optimistic about the rollout. On a Monday we stood in a bullpen area in the company's Manhattan headquarters and watched the application go live. One woman used the application to fill out a form and then, rather than hitting submit and sending it on its merry workflow way, printed it out and put it in her outbox.
I'm sure most people involved in systems development have experienced this sort of infuriating situation -- I've seen enough "DO NOT PRINT THIS FORM!!!" messages on the bottoms of pages to know I'm not alone. No matter how much testing and training is done, some people can't get their heads around a new way of doing things. They remind me of those stories of the industrial age, when new machines were introduced into traditional ways of doing things, often to comical results.
In order to avoid being stuck in the past like this, you have to remember why you do things in the first place and continually question if they are sensible or necessary. I remember when I started designing what now would be called web applications back in 1994 or so. Stateless searching and reporting was easy to do, but the major challenge came in chopping up your application into different "pages", retaining state across several page loads and dealing with the "Back" button, a sort of rogue "Undo" function that didn't play nice with the application design. You ended up doing lots of kludgy things that you wouldn't do in a GUI or command line application. You had to think differently in order to build successful web apps.
As I review the various web application frameworks, most of which have the page based concept at their core, I have an uneasy feeling that we're missing an opportunity to rethink how we build webapps. Isn't it time to discard the page model and go back to a component model that has been so successful and productive on the desktop? Imagine undo functions that don't depend on the "Back" button, Browser specific code that is concentrated in a few classes, powerful, rich client applications in a fraction of the code. Let's rethink and DO NOT PRINT THIS FORM.
About Pathfinder
Recent
- Dealing With A Legacy
- Big Changes Underway at LinkedIn for Groups
- Four blatant iPhone usability blunders (and one constant annoyance)
- Flash/Flex physics engines and examples
- A Rails Story, Or An Engine That Really Could
- Data visualization and the art of conveying information
- What’s In Your Junk Drawer?
- Selling Git on the Business End
- IE8 Beta 2 Released
- Faster JavaScript for Firefox 3.1 Thru JIT
Archives
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
2d physics
3d
3D GPS
3D physics
Accessibility
actionscript
activerecord
Add new tag
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Frameworks
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Analysis
Android
Announcement
Announcements
antennae
Apollo
Application Architecture
Application Development
AS3
ASP.NET
Asynchronous Processing
awards
Back Button
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
Chicago
CMS
COBOL
code art
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
Echo2
Echo3
Editorial
ERP
Ethnographic Research
Ext JS
Facebook
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player 10
Flex
flexunit
Flow
Frameworks
front end
front end development
Games
Gauge Component
Git
Google
Google calendar
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
Gwittir
GWT
Healthcare
Hibernate
IDE
Ideation
IE
IE6
IE7
IE8
ILOG JRules
Information Architecture
Innovation
Instructional Design
Interaction Design
Interview
iPhone
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSR-94
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
MetaWidget
Methodology
Microformats
Microsoft
Mobile
Mootools
Mozilla
Music
MVC
MySql
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
Open Source
Opera
ORM
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Progressive Enhancement
Project Website
Prototype
Prototyping
PV3D
QA
qooxdoo
Radiant CMS
rails
Really Simple History
References
Requirements
Requirements
Alice Toth
Requirements Visualization
Restlet
RETE
Review
Rich Interactions
ruby
Ruby on Rails
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
SDLC
Search
Security
Selenium
Semantic web
SEO
Server Side
Silverlight
SOA
Social Networking
Software Processes
Songbird
SpiderMonkey
Sprajax
Spreadsheets
Standards
STI
Story Telling
Struts
Tamarin
Task Flows
Test Driven Development
Testing
Tilt Component
Tools
TraceMonkey
Training
Trends
Tumblr
Tutorial
Tutorials
Unit Tests
Usability
Usability Testing
User Experience
user experience design
user interface
User Interface Standards
User Research
UXD
Video
Visualization
VLC
Volta
Web/Tech