Archives

The opportunity and options for online user interaction span a continuum from the tightly controlled, such as moderated message boards, to the organic, dynamic and unconstrained: think of sites that are almost completely comprised of user-generated content, like MySpace, flickr, and YouTube.

Sites in the latter genre grew and thrived in an environment of chaotic autonomy. However, their success has raised their profile and invited the attention of the corporate sensibility; the prominence of YouTube, amplified by Google’s acquisition of the site, has resulted in a trend toward censoring or restricting contributor content. Sites such as Facebook and MySpace are now routinely mined by corporate recruitment firms in an attempt to screen out prospective job seekers that may present themselves unfavorably in the context of their college lives. More seriously, MySpace has come under criticism as being a resource for predators and in response has subsequently had to tighten the rules for contributors who are minors.

Recently, YouTube became Big Brother (albeit wearing the white hat) for members of the Franklin, MA police department, who posted on the site a surveillance video of two men allegedly using stolen credit cards at a retail chain store. “You don’t have to be a technology wizard to figure out how to watch a video on YouTube,” commented one of the officers, an observation that demonstrates the low cost of admission to community and social networking sites.

One suspects that the Wild West days of the self-generating, self-maintaining social network sites are waning, ironically due to their appeal. Community has become a commodity—so much so that site owners are rushing to incorporate features such as blogging, commentary, content ranking and other interactive enhancements on their sites. USAToday’s recent conversion to a socialized environment has created a tidal wave of criticism from current users (92% of whom dislike the redesign) as well as a lively dialogue on the concept of social design. As Martin Neumann observes, “People seem to consider the social, but don’t realize the design is what makes people want to be social. . . If you want people to interact and use your site as a social web tool than you have to make it inviting enough for them to want to do so. . .” Communities originally grew and prospered organically, linking participants through common interests and impulses. The hundreds of Usenet groups that still exist today are living proof of this. Corporate-driven communities—because they are created to serve business, rather than genuinely social needs—must be nurtured carefully and must retain an element of user control. To paraphrase an old saw, you can bring a visitor online, but you can’t force them to rank your content.

Research is an integral component of Pathfinder’s UXD methodology, and we strive to incorporate research strategies throughout the design process and beyond, into post-development usability assessments. However, some clients are confused by—or worse, resistant to—the idea of front-end “user research.” How, they ask, do our activities and findings differ from the analyses and resultant charts, graphs and PowerPoint presentations provided to the firm by the Marketing department?

The first stumbling block is largely semantic: many business stakeholders regard their customer segments as their “users,” and fail to make the (sometimes subtle) distinction between buyers, the target of market research and end-users, the focus of UXD consideration. In lieu of the term “user research,” several firms have adopted the title “design research,” thus taking the emphasis off the subject and placing it on the ultimate goal. While this is a step forward in clarity, it may present a different semantic stumbling block for those who think of design strictly in terms of visual look-and-feel.

After some brainstorming, our team came up with the descriptor “Behavioral Analysis.” We feel this term gets to the heart of the essential difference between market and user research—our goals are to observe and explore what people actually do, as opposed to what they might say in the context of market research. We see Behavioral Analysis as an inclusive rubric that includes our various techniques, including site visits, contextual inquiry, ethnographic studies and interviews, as well as usability assessments.

Certainly, there is no hard line between market and UXD research. Initiatives such as “Voice of the Customer,” in which cross-functional teams pay site visits to their customers to see their environment first-hand, is essentially a business-oriented ethnographic study. Market segmentation studies are the first step in the creation of personas, providing UXD a valuable roadmap for focusing their attention on potential interviewees. However, market research, no matter how thorough, can never substitute for front-end user research, and we need to make the distinction clear to our clients and articulate the value of both.

At the beginning of the year, I made a few predictions about Ajax in 2007. In particular, I predicted that

Microsoft and Mozilla will add new features to their browsers to extend Ajax support. These features will address things like cross site scripting (making it easier and more secure), security, widgets standards support, extensions of Javascript, etc. The browser will evolve into more of an application platform than it is now.

That doesn’t really seem to be happening, from what I can tell, since Firefox 4 won’t be available until 2008, and Firefox 3 is making only modest changes on the Ajax front. It’s too soon to say anything about IE8.

InfoWorld has a breathless article about the revolutionary changes coming in Firefox 3. A careful reading of the article, however, shows that most of the really interesting changes are planned for Firefox 4, such as support for Javascript 2.

You can read the detailed feature list for Firefox 3 here, in the form of a Google Spreadsheet. It doesn’t look like either of the two features — web services as Mime-type handlers and SQL Lite for offline storage — are in Alpha 2, but hopefully they’ll show up in the next release.

What these two new features might look like isn’t exactly clear from the planning documents, but they should take their direction from section 5 of the WhatWG specification on Web Applications 1.0.

The registerProtocolHandler() method allows Web sites to register themselves as possible handlers for particular protocols. For example, an online fax service could register itself as a handler of the fax: protocol ([RFC2806]), so that if the user clicks on such a link, he is given the opportunity to use that Web site. Analogously, the registerContentHandler() method allows Web sites to register themselves as possible handlers for content in a particular MIME type. For example, the same online fax service could register itself as a handler for image/g3fax files ([RFC1494]), so that if the user has no native application capable of handling G3 Facsimile byte streams, his Web browser can instead suggest he use that site to view the image.

At the simplest level, when a particular Mime type is encountered, a web application will be launched, instead of the usual desktop application. The feature list, however, states that Firefox 3 will Support web services as MIME type handlers. That sounds a little bit different from what the WhatWG spec provides.

All Ajax-enabled web developers should take an interest in browser standards and developments. The future of their profession depends upon it.

Technorati : ajax, firefox 3, sql lite, web services, whatwg

One of the most important lessons I’ve learned in Six plus years as an Interface Designer is that Visual Design can mean many different things.  There’s ample opportunity for misunderstanding between client and designer at this phase of a project.  Which is why it’s so important to clearly define what’s involved and what will be delivered prior to starting work on the Visual Design phase.

No Two interface design projects are the same.  Each has its own unique characteristics, assumptions, expectations and final deliverables.  I’ve worked on projects where Visual Design meant custom building every widget, every window and every button in the application.  Months were spent hand crafting scroll bars, window resize handles, navigation tabs, and window frames.   I’ve also worked on projects where Visual Design was only a matter of positioning and aligning form fields. Although on paper a Visual Design process should be standardized, it also needs to be flexible enough to handle a diversity of projects without shoehorning them all into the same rigid methodology. 

A critical step in this process is defining what the client expects when they talk about Visual Design.  It’s important to interview the key client stakeholders to get an accurate description of their expectations.  Be as detailed as you can in your interviews.  Try to leave no stone unturned.  The more you know about what they expect you to deliver, and in what form they need it, the greater the odds of a successful product being delivered.  Sometimes the client can’t clearly define what they need.  Sometimes they aren’t really even sure what they need.  And sometimes they might even misunderstand the nature and implications of their request.  In these cases it’s important that you use your role as domain expert to help them get a better understanding of the complexities and issues involved in the Visual Design phase.  Client education is sometimes an integral part of defining the scope of the project.

After this step, which I call diagnosis, you should be more informed about the scope and specifics of the project.  You should know what platform the interface will be rendered on, and what development environment it will be developed in.  You should know to what extent you need to customize, and how much can and will be programmatically generated.  You’ll understand what level of graphic sophistication the Product Manager expects, and what types of production files the developer needs. 

Having clearly defined all of these variables, you can get to work designing with the focus you need to deliver a successful product.

Since the fifteenth century, when Gutenberg’s press enabled the production and distribution of printed materials to the masses, technology has influenced not only our means of communication, but often, the very medium itself: language. This year marks the twentieth anniversary of version 1.0 of Powerpoint (interestingly, initially designed for the Apple Macintosh). Still supporting an older technology, the early releases of Powerpoint simply created pages to be used for overhead transparencies. The first Windows-based version appeared in 1990, and, in the view of Edward Tufte, quickly grew into a ubiquitous and malevolent influence that formulated new cognitive and aesthetic models constructed of a decontextualized, sequential series of choppy phrases and an appetite for “smarmy, chaotic, incoherent chartjunk” graphics.

The Web has provided a potentially universal platform for communication—a virtual printing press—and has even more strongly shaped the way we think, communicate, and even think about communicating.

The explosion of community sites, blogs and message boards have inspired multitudes of nascent authors to reach out and express themselves. E-mails not only function as direct communication, but are forwarded large-scale as electronic entertainment. The easy entry into this environment has relaxed the standards of formal written communication, much to the annoyance of “grammar queens” who zealously police the online world, pouncing upon errors in spelling and syntax. (Full disclosure: Former English teacher here.)

A burgeoning glossary of acronyms and emoticons have been developed to accommodate technology, whether to speed up online chat to approach the speed of actual verbal conversation, or to accommodate the small canvas of the text message. To a degree, this is Powerpoint regimentation redux: do so many people really LOL at the slightest suggestion of humor?

A recent AP article notes that Web newspeak has extended into the naming of products (think flickr) and on to websites and products themselves, which are increasingly boasting names derived from newly invented words: ikbis, joost, Woomp!, to reference only a few.

To me, the most moving example of the power of technology to change communication for the better concerns Amanda Baggs, a severely autistic woman who found her voice in the digital world. Her eloquent writings express the intelligence and sense of humor that she is unable to convey in verbal communication. Read her blog and enter a world that was previously inaccessible to outsiders.

Change in all things is sweet. — Aristotle

You work for company A whose bread and butter is a desktop GUI application that it provides to it’s customers for a monthly fee and via something like the Citrix Presentation Server. Life is good, but it’s time for work to start on the next version and a manager drops the word “Ajax” in a meeting.

You get nervous. Ajax means web and from what you’ve heard from your buddies in marketing who help to run the web site, web development is different and hard. You’ve got a browser, three or four different languages, threads, cats and dogs living together. You start to update your resume. But where does a desktop developer go when all the world is going web?

You call up a friend at company B. Company B also has a desktop GUI application that it provides to it’s customers for a monthly fee via something like the Citrix Presentation Server. You meet for lunch (“Uh, when you say “next door”, do you mean Chili’s or Flingers?”) and start to cry in your beer.

“Dude,” says your friend, “we’re moving to Ajax too, and it’s way cool and easy.”

You fall out of your chair.

Now take a deep breath and realize that…

Your Desktop GUI Skills are More Valuable than Ever

I’ve written reams of posts on why component GUI development is better than the typical web development approach (Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks is probably the most cerebral), but the guys over at the ZK framework put it better than I can:

In 1994, we developed an infrastructure, inspired by zApp and OWL, for developing an accounting system for Windows. In 2000, we developed another infrastructure, inspired by Struct and WebWorks, for developing another accounting system for J2EE. After coaching and watching the development of both systems, we found that not only the Web edition required much higher programming skills and prerequisites, but also its total cost is four times more than the client/server one. Worse of all, the user experiences reminded us the age of green terminals, though the look, after decorating with proper images and CSS, is modern and fresh.

Four times as expensive seems a touch high to me, but I’ve seen worse. Certainly twice as expensive wouldn’t be a stretch. Now we’ve come a long way since I wrote my first CGI script back in 1993 (I think I used /bin/sh), but the difficulties of juggling browser and server contexts and languages in your head at the same time has gotten worse, not better. There’s just a lot more technology of which to keep track.

Face it, developing code using the event driven component GUI model is just more efficient and, yes, pleasant. And that’s great for you because that is the skill set you already have.

Refreshed from your lunch (the calamari was excellent) and armed with your friend’s helpful suggestions, you run back to the office and scan your calendar for the next product planning meeting. There’s one that afternoon. You bring a new yellow legal pad, a sharp pencil and an eager expression. When the manager opens up the floor to suggestions, you’re hand shoots up and you yelp, “Echo Two!”

“Echo what?” says the manager.

“Echo2,” you say, catching your breath. “It’s a component GUI framework for writing Ajax applications. We would write the new application pretty much like we write the current application, except that the result would be an Ajax application and run on the web. And we wouldn’t have to fire anybody and hire all new expensive programmers.”

Your manager looks impressed. The other developers shoot you envious glances, especially the guy with the copy of Real-World Ajax tucked under his arm.

So, crisis averted, right? The new version is coming along and it’s all milk and honey while you write the same type of code as before, right? Well, not quite. There are still some differences between your prized desktop app and the web app you will soon come to love. But never fear. You are about to be enlightened as to

Things You Should Keep In Mind When Moving from the Desktop to the Webtop

This list could be endless, but let me focus on those things that I’ve found to be particularly salient in desktop to webtop projects.

• Is your old application concurrent (possibly having two or more actors — users, threads, systems — operating on the same data), i.e. is it client/server or is it stand alone?
• Are you going to want any specialized or custom components for your application? Does your old application make use of lots of third-party components and widgets?
• Bandwidth: even a LAN tends to be slower than your computer’s data bus.
• The component GUI model is so nice, but what if something blows up on the browser? Help!

I could go on, but these are the biggies. Let’s take on these issues one by one.

Concurrency

The easiest thing to do with your application in terms of concurrency is to leave it alone. If it was a single user, one-thing-at-a-time type of application, let it be that kind of web application. If it was a client/server app that already handles concurrency, reuse your data model, your business and persistence logic as much as you can.

The hard part comes when you want to make the transition from a non-concurrent to concurrent app. If you’ve got a data model that looks pretty standard, i.e. related entities represented as one or more tables in an RDBMS, you can use tried and true design techniques (see ORM, Spring, Hibernate, optimistic locking, pessimistic locking, etc.) to transition your app. If, on the other hand, your app deals with a complex document, something that looks more like a tree, an acyclic directed graph or even a cyclic directed graph (think word processing doc, UML diagram, etc.), then you’ve got trouble.

You would like to be able to provide atomic transactions on these hierarchical structures, something which is still an active area of research. There’s also the issue of document validation, i.e. is it still valid to add a footnote to a document if the paragraph it was attached to has been removed. Finally, there is the problem of presenting all of this complex hierarchical collaboration data to the user in a way they can make sense of. The truth is that collaboration with complex documents or information structures is something with which everyone struggles. No one has gotten it right as yet.

If you must introduce concurrent features under these circumstances, go with add-ons instead: shared bookmarks, a comment system, a shared whiteboard or clipboard. Or try coarse-grained locking of document sections.

Specialized Components

Just as with traditional component GUI frameworks, with Echo2 you can compose new, more complex components out of existing components. Three drop down lists can become a date picker, for example. But sometimes what you need is just not in the toolbox.

In the case of Swing or AWT you would dust off the low level pixel painting API and have at it. In the case of Echo2 you’re going to have to dust off something you don’t already have: a knowledge of Javascript, CSS and XHTML (and HTTP). You didn’t think you would be able to get away from that stuff entirely, did you? The good news is that you will only need a few of these highly skilled Java/Javascript/CSS/XHTML widget designers and, once they’ve developed their excellent reusable widget, it’ll be at least another day before another requirement forces them back to the keyboard.

Bandwidth

Your desktop GUI was pushing things to the screen; your Ajax webapp will be pushing things to a browser. Besides network connectivity being slower than intra computer connectivity, the two operations are fundamentally different. Take for example the case of a list of 5000 emails that are displayed in a scrolling table. At any one time, perhaps only a dozen emails will be displayed at once. In the case of the desktop GUI, only a small area of pixels need to be updated as you scroll through the list. In the case of an Ajax application, you will need to send the data for those 5000 messages to the browser, either all at once or incrementally as they scroll into view. This data is then inserted into the document object model (DOM) of the web page. This can be an expensive operation and if not carefully thought through can make certain operations awkward or impossible.

Take for example the Yahoo! Mail Ajax GUI. It incrementally loads emails as you scroll through the list. It’s slow. And if you want to delete all of the emails in the list, you have to painstakingly scroll through all of the emails so that they load. Otherwise you can’t select the whole list and delete them. That’s behavior very different from that of a desktop app.

When Things Go Wrong

Things do occasionally go wrong in Echo2/Ajax land, and when they do they can be very hard to diagnose. The nice fiction of a Java-only development environment breaks down and you have to trace through your Java, the client-side Javascript engine and your components, the DOM of the application page, the CSS, etc. When this happens, bring one of those widget developers to the party. You’ll use your IDE’s debugger, tools like Firebug and Venkman, and the built in message debugging support in Echo2, all to track down and eliminate your bugs.

All I can say is welcome to the world of web development. This is what we go through all the time with or without Echo2.

Conclusion

We’ve looked at one way of developing Ajax applications with Echo2 that will let you reuse most of your desktop GUI development skills. Echo2 may not be your cup of tea. There are other server-side frameworks, such as ZK, and there are client-side frameworks like GWT and Tibco GI that have things to recommend them for the component GUI developer.

Also, I haven’t even touched on the .NET side of the house. That will be the subject of a separate post.

Last, it would have been impractical to touch on all the differences between Ajax and desktop apps. For some ideas, have a look at Michael Mahemoff’s excellent Ajax Patterns wiki or, better yet, buy his book.

Technorati : ajax, desktop apps, echo2