- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Book Review: The Human Factor
Studying how people interact with technology should play an important role in the software design process. A program that is built without an understanding of how it’s users interact with the device it runs on is likely doomed to fail. But prioritizing human factors is not only important in software design. It can also save lives, according to “The Human Factor”, by Kim Vicente.
The book makes clear, with some intriguing stats, as well as real life horror stories, that the lack of priority placed on understanding human factors carries drastic and sometimes fatal consequences.
We as a society come to rely on sophisticated technology more and more every day, not just for entertainment purposes, but for basic living needs. But surprisingly little time or money is devoted to understanding how we interact with the technology around us. So as it becomes more sophisticated, the products and systems that use it-- products that are critical to our everyday lives--are growing more complex and less usable. According to Vicente, if we don’t do something about it soon, the result is a situation that endangers each and every one of us.
Much of the book is devoted to the problems that plague three industries that are vital to our health as a society, and could potentially cause the most harm: health care, air transportation and energy generation. Mr Vicente peeks behind the curtains of these industries to show us why human factors gets neglected, what the consequences are, and what can be done about it.
He observes that human factors study is sorely lacking at both the system and the manufacturing levels, infecting not just products, but organizations as well.
In the case of health care, as aversion to understanding how its professionals interact with technology seems to be pervasive and ingrained. As a result, medical products suffer from seriously flawed design, and are frequently counter-intuitive to use. The health care system as a whole is also designed poorly. Harsh scheduling results in doctors who are overworked and understaffed, and flawed error recovery policies mean mistakes are repeated over and over again. When mistakes occur on operational products, it is usually ascribed to human error, even though it is the confusing technology that is frequently at fault. It’s not surprising that over 90,000 preventable deaths occur each year in us hospitals.
Health care is not the only industry in which a lack of attention to human factors has potentially fatal consequences. Nuclear power plants are among the most complicated pieces of technology in the world. The number of systems running/data points needing to be monitored/factors needing to be controlled is staggering. The design of nuclear control rooms desperately needs an infusion of some human factors thinking or the consequences could be devastating. The first pages of the book describe the Chernobyl disaster from inside the control room, and it quickly becomes clear that had it been designed with its users capabilities in mind, the result would have been far less damaging. Vicente advocates the need to learn from Chernobyl (and Three Mile Island, among others) to design control rooms that make sense to their operators.
The airline industry is yet another example of the potential harm that a lack of human factors study can have, Neither the systems that pilots work within, or the airplanes they fly are designed with their capabilities and constraints in mind. Pilot schedules are notoriously harsh, causing in flight fatigue. And current cockpits seem to be designed to cause the maximum amount of confusion. Like in healthcare, human error is frequently blamed when the real culprit is operational, but unusable, technology. The resulting risk in air transportation is sobering; reminding us how important human factors is.
Vicente persuasively demonstrated how critical it is that we prioritize human factors study, and what the consequences may be if we don’t. Although I don’t work on anything that has the potential to do as much harm as that of an airplane or a nuclear power plant, I came away with a better understanding of the value of human factors study.
Ambient Signifiers
I recently came across Ross Howard’s essay on ambient signifiers, subtle design elements that give the user context. They work at a more subconscious level than overt signifiers; yet, even without a conscious effort from the user, their constant presence affords an effective means of communication.
The author’s musings came from his experience with the Tokyo rail network. Along with a station’s obvious and somewhat standard clues (signage, train colors, audio announcements, etc.), each station has its own chime melody. By remembering the chime for their final stop (which they’re exposed to while waiting for the train) along with the chime for the station before their final stop (which they can hear when the doors open), commuters can more or less ignore the passing landscape and still be cued into their surroundings. Ambient signifiers allow them to maintain a sense of where they are without having to actively seek it out.
Moving into the digital realm, consider when a browser changes the background color of the location field once the user is on a secure site. It’s a subtle change, but once the user associates it as an indicator of a secure site, a quick glance at the field will reinforce that they’re in the secure portion of a site.
The challenge is how to integrate this concept into your web design methodology. Overt signifiers, such as navigation, will always be necessary but perhaps we should also develop a vocabulary of ambient signifiers as reinforcement. A deepening of background colors to indicate sections a user visits often; a lightening of colors to indicate links to older items; differences in font size to show depth of a category, etc. Once you start thinking along these lines, you realize there are a number of ways to incorporate this concept into your design, aiding in the effective use of the site or web app.
Topics: Color, Design, Interaction Design
When content overwhelms community
In his Alertbox article, Participation Inequality, Jakob Nielsen asserts that "In most online communities, 90% of users are lurkers who never contribute, 9% of users contribute a little, and 1% of users account for almost all the action." And that's his best-case scenario: he claims that the "more radical" 99--1--0.1 distribution is common in some social websites. Worst of all, the lurker-poster ratio for Wikipedia, by Nielsen's reckoning, tallies in at an even more disproportionate 99.8--0.2--.003.
We recently worked on creating a vision for optimizing the community features of a large, content-rich website. Aside from some acknowledged usability issues, a major user barrier to community participation was the issue of trust: target users were hesitant to share personal information in a public forum. We felt this reluctance had its roots in the demographics of the site's users, whose average age was in the early forties. Contrast this with the openness of communities such as myspace, which attracts a younger user base willing to provide the most personal information--even to the point of rashness. On our project, we had to take the conservative user preferences as a given, and try to develop ways to entice users into interacting with the site more frequently and easily.
To do this, we had to encourage our client to think beyond the concept of "Community"= Message Boards alone, and give their users more pathways for generating content for the site, which is driven by features, content and experience. We gave a lot of thought to how the participatory elements would be placed, and conceived flow-based design to enhance how people touch them, interact and behave.
I'll discuss some of our specific strategies in Part II.
Topics: Case Studies
101 Ideas for JSONP - Idea #1: RSS to JSONP
I've been working with lots of Ajax projects that make use of JSONP. JSONP is basically wrapping JSON in a callback script. So a return such as the following
callback({"IBM":"82.53"});
allows you to include the call as a script tag, for example
var script = document.createElement("script");
script.src = 'http://remoteserver/stockquote?symbol=IBM&callback=renderQuotes';
script.type = 'text/javascript';
document.body.appendChild(script);
will dynamically add a script to our page which will call back an already existing function renderQuotes in our page. This technique is very useful if you are including Ajax widgets on remote sites or using bookmarklets or GreaseMonkey scripts to pull information from remote servers.
Now you can use some ready made JSONP capable web services to build your applications and mashups -- certainly Yahoo has quite a few -- but that won't get you all of the types of information that you might want. Proxying other sites and sources of information and turning the results into JSON is a good way of getting the content you need.
I'm starting a little series called "101 Ideas for JSONP," where I'll give 101 different techniques, sources and ideas for getting information into a JSONP service.
Idea #1: RSS to JSONP
RSS is an XML format for content syndication widely used by just about everybody. The JSON library from json.org is a handy little utility library that allows you to convert JSON to and from XML and Java Objects. Combine the two and you've got an easy way of providing a JSONP service.
I've got an example of this right here that takes the RSS feed for New York City resumes from Craig's List and transforms it into JSONP.
resumes
The above widget updates every 30 seconds (you can look at the Javascript file that populates it from the proxy server here). The code we use to get the RSS and transform it into JSONP is pretty basic. The one thing to note in the code below is that the org.json.XML class doesn't allow for streaming. That means we have to read the whole RSS feed into memory in order to convert it. That's really not an issue in most cases with RSS feeds, but it's a gap that I'll try to remedy at some point in the near future.
package com.pathf.demo.jsonideas;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.MultiThreadedHttpConnectionManager;
import org.apache.commons.httpclient.methods.GetMethod;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.json.XML;
import org.json.JSONException;
import java.io.IOException;
public class RSSGetter {
private HttpClient httpClient;
private Log log = LogFactory.getLog(RSSGetter.class);
public RSSGetter() {
httpClient = new HttpClient(new MultiThreadedHttpConnectionManager());
}
public String getRSS(String uri) {
// we get it as a string, since the JSON lib doesn't handle streams
GetMethod get = new GetMethod(uri);
get.setFollowRedirects(true);
try {
httpClient.executeMethod(get);
return get.getResponseBodyAsString();
} catch (IOException e) {
log.error("Problem getting rss feed " + uri, e);
return "Problem getting RSS feed ";
}
}
public String getJSONRSS(String uri) {
try {
return XML.toJSONObject(getRSS(uri)).toString();
} catch (JSONException e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
return "{\"Result\":\"Error\"}";
}
}
}
The servlet below just wraps the result of the RSS retrieval in the callback function that is passed as a parameter. If no callback parameter is passed, it reverts to plain old JSON.
package com.pathf.demo.jsonideas;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
import javax.servlet.ServletConfig;
import java.io.IOException;
public class NYCResumeServlet extends HttpServlet {
private RSSGetter rss = null;
private static final String NYC_RESUMES = "http://newyork.craigslist.org/res/index.rss";
protected void doGet(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) throws ServletException, IOException {
httpServletResponse.setContentType("text/javascript");
String callback = httpServletRequest.getParameter("callback");
String json = rss.getJSONRSS(NYC_RESUMES);
if (callback == null) {
httpServletResponse.getOutputStream().println(json);
} else {
httpServletResponse.getOutputStream().println(callback + "(" + json + ");");
}
}
public void init(ServletConfig servletConfig) throws ServletException {
super.init(servletConfig);
rss = new RSSGetter();
}
}
There are other ways of pulling in an RSS feed via JSONP, some of which will allow us to use the browser's machinery for operating on XML to transform and add content via remote widgets.
Topics: JSON
the iPhone and Touch screen technology
By now you have probably seen or heard about the iPhone, Apple Inc.'s (no longer Apple Computer) revolutionary mobile device that is scheduled for sale in the spring. There are so many bright ideas packed into this thing--the wide-screen iPod, all the neat phone features, laptop like web browsing--but what pulls it all together, and in my mind makes everything else possible, is the touch screen. The iPhone is the first commercial product that comes close to using the vast potential that touch screen technology represents, and it is therefore a model for the future of the Graphical User Interface.
Touch screens are advantageous to other input devices for one fundamental reason: It feels natural to manipulate something by touching it. Other input devices, like the mouse or the keypad force us to overrule our natural instincts by making a mental leap: manipulating this thing over here will have an effect on something else over there. We have adjusted to this over time and repetitive use, but the unnatural separation between cause and effect limits our speed, effectiveness and creativity.
Today's commercially available touch screens don't offer much of an alternative to other input models because they are binary--either a touch is registered or it isn't--and therefore act only as buttons.
But touch screens don't necessarily have to be binary. They can react to pressure, speed, angle, direction, rotation and many other input types, thus creating a User Interface with a more natural feel.
Devices like the iPhone--with it's enhanced touch screen capabilities--will bridge the gap between cause and effect, allowing use to interact with digital User Interfaces like we do with objects in the real world. Users will be able to complete tasks much faster, with fewer mistakes or frustration. Finding information will be easier, more natural, and fluid. Creative work will be less restricted by concentration on hand gestures, freeing up mental power for solving problems. Communicating will behave more like it does in the real world, effortlessly among multiple people.
As touch screen technology advances, digital interfaces will learn to behave like their analog counterparts, diminishing the barriers to digital device usage. Eventually, the difference between analog and digital will vanish altogether from the users perspective.
Using Design Patterns
Design is a creative process, not a recipe. Good design is an iterative process where refinement is incorporated into each successive rendering. So how in the world does a pattern fit into a creatively, iterative process?
First off, let’s discuss what design patterns are. In essence, design patterns are a record of best practices derived to solve a particular problem. They are an abstract capture of a common structure, without dictating the concrete details. They give you a basis for where to start in order to come up with a solution. It is up to the designer to adapt the pattern to their particular context in order to solve the recurrent problem described by the pattern.
Actually, if you’ve been designing for a while you’ve probably already incorporated design patterns into your toolkit. Let’s say, for example, you’re designing a screen that requires a large amount of data to be presented in a very tiny space. Staring off into space, you remember a previous project and how you solved a similar problem. You adapt that solution to fit the context of the current application and viola! You’ve just used a design pattern.
Or you’re in a design meeting debating the merits of using breadcrumbs vs. a sequence map. Well, you’re actually debating two navigational design patterns – in this case, best practices that help with context. The chosen pattern solves the problem of giving users a sense of where they’re at in the application. How you implement the visual presentation of the pattern is up to you.
The recent books and articles on design patterns are, in effect, a formal codification of best practices that can aid in designing an elegant solution and also provide a common language for team discussions (sequence map is understood; 1-2-3 thingy at the top might not be). The more experience you have, the less likely you may be to consult design patterns. However, if you’re new to the field, encountering a problem for the first time, or wish to establish a common language for the team, they’re a good place to start.
And to help you get started, here’s a list of pattern repositories you might find interesting.
Topics: Design Patterns
Onward to Web 3.0
In 2007, we’ll be seeing how Web 2.0 matures from a trendy buzzword into the realm of web standards. With the 2.0 technology and interaction, the idea of ‘community’ won’t be limited to a few oddball sites but will rather become an integral part of many mainstream sites.
You can already see this happening with the array of social bookmarking and media sharing links. What began as an oddity of icons encountered on the rare blog or two, is now becoming a standard one-click sharing device on such venerable sites as the New York Times. It’s a global community out there!
So with the maturing of Web 2.0 a given, the obvious question is what’s next? If I knew, trust me I’d be buying stock in the next killer app right now. But indications seem to be pointing towards a connection of data in a more intelligent manner, making it more relevant to the user.
Let’s face it, there’s a lot of data out there that in theory is searchable but not always connectable without spending a lot of time pouring over the results. And who has time for that. So we usually end up taking the first few results and running with that, but it doesn’t always work out.
So, what if we had a system that could rank and weigh people’s comments (which are fast becoming a standard feature thanks to Web 2.0) and, by cognitive deduction, find just the right result for that user. That is, our system would mine the data in the Web to detect relationships between the information that’s out there. Once established, it would be easier to extract and aggregate information tailored to fit the user.
Pie in the sky? Well the folks at the University of Washington don’t think so. Check out what they’re doing with their KnowItAll and Opine systems. Play around with their demos and think of how this would change your interaction with, say, a travel site if the system could provide a useful and meaningful result by distinguishing between concepts such "great" and "almost great".
"The system will know that spotless is better than clean," said Oren Etzioni, an artificial-intelligence researcher at the University of Washington who is a leader of the project. '"There is the growing realization that text on the Web is a tremendous resource."
And so in the next few years, we just might see this definition:
Web 3.0 – a web of connected data; i.e., moving from a web of connected documents/sites to a web of connected data.
Topics: Domain Knowledge, Interaction Design, Web 2.0
When your best is too much
Opinions can be strong and diverse in the Information Architecture arena--for example, just try and find consensus on the ideal wireframing tool. Granted, this is an easy target because everything currently available is decidedly non-ideal in all situations. Other issues seem to attract less debate and may, in time, provide one or more proven strategies we formalize as “best practices.”
I've recently run across several articles on prototyping that convey a notably consistent viewpoint. The authors’ common thread—that we are too-often prone to invest time, effort and budget producing an over sophisticated prototype—is certainly self-evident, but this impulse nevertheless presents a real temptation for designers. We want to dazzle clients with our artifacts or simply exercise our creativity by “filling in” design elements to enable us to visualize the finished product before all the design work has been thought out.
Kathy Sierra, in her blog, Creating Passionate Users, advises Don’t make the demo look done, noting that the level of fidelity of a work-in-progress sets expectations that can ultimately backfire on the designer. Her bottom line: How “done” something looks should match how “done” something is.
Sierra’s second point goes beyond perceptions and addresses the actual point of demo-ing a prototype to team members and stakeholders: The more “done” something appears, the more narrow and incremental the feedback. A concept executed to a level of fidelity that makes it look almost completely done will elicit detailed tweaks to specific features, while a rough sketch (even if produced with an application) allows reviewers to question higher-level features and consider bigger changes. She argues that even more revolutionary, big-picture changes are enabled by eschewing screen representations entirely and instead presenting storyboards or use cases. Her advice? “If you want big picture, make it fuzzy!”
Henrik Olsen has two worthwhile articles on prototyping available on his website. The first, Balancing fidelity in prototyping, acknowledges the hesitancy of designers to show clients something that appears unfinished, but immediately notes that the “fact is that prototypes by definition are unfinished.” Excess visual detail in prototypes subverts the effectiveness of the iterative design process and usurps the role of the graphic designer.
Olsen’s most interesting concept regards the potential breadth and depth of the prototype. He defines breadth as “the scope of features covered by the prototype,” while depth is “how deep the prototype goes into each feature.” He advises that a successful prototype will not compromise on breadth, but should limit the amount of depth.
In Olsen’s more recent article, intriguingly titled The dark side of prototyping: How to steer clear of the pitfalls in prototyping, the author is quick to reassure readers that there aren’t really any downsides to prototyping, but there are some banana skins to steer clear of. He identifies these perils as (1) Not aligning the design with project constraints; (2) Going high-fidelity early in the design process and (3) Not involving colleagues.
Topics: Prototyping
The Web’s Most Useful Sites
Although I consider myself a savvy web user, I'll admit I wasn't familiar with many of the web sites featured in the cover article of this month’s issue of PC World, "The Webs Most Useful Sites". It's a well-written, well-researched and useful bit of journalism.
The article presents what PC World considers the best sites in each of 14 categories, ranging from Word Processing, and Spreadsheets, to Calendars and Mapping. Below I go through some of the more interesting and potentially useful sites the article uncovered for me.
Word Processing: Zoho Writer.
PC World rates this tool better than Google Docs primarily due to the easy-to-use interface. It has all of the same tools Google Docs provides, including find/replace features, Microsoft word compatibility, and blog publishing. It's an interesting find.
Password Manager: JustKey.
I don't use a password management tool, but after reading the article, perhaps I should. For less than $3 a month JustKey provides encrypted, secure password management so that you don't have to remember the password to every web site you've registered with.
User Review Sites: Yelp
According to the blurb on it’s home page, “Yelp is the fun and easy way to find, review and talk about what's great - and not so great, in your area.” The web site automatically sends you to the area you are located in, so there’s no typing zip codes, or selecting cities from a map, which is nice. The integration with Google maps is also done well. However, like other user generated sites, the key to it’s utility will be the amount of content. The idea is great, but currently there’s not enough content to provide me with an alternative to the more traditional city guides like CitySearch, and Metromix.
Event Calendars: Upcoming.org
This is, again, a great idea in need of content. “A social events calendar, driven by people just like you”, Upcoming.org is a social networking site with listings from around the world, the ability to view who is planning on attending events, and integration with calendaring and blogging. However, it needs to be more extensive and content laden to be useful.
To do list: Remember The Milk
My introduction to web based to do lists was 37Signlas’ Ta Da List. RememberTheMilk.com blows it away with features such as configurable categories, calendar synchronization, recurring tasks, and email reminders.
Web Operating Systems: You OS
This category is totally new to me, but the concept is intriguing. In a nutshell, You OS is an operating system that runs in your browser window. It’s slow, and not very feature rich, but with server farms and Pcs getting ever faster, and broadband more ubiquitous, according to PC World, Web OS’s “may well be computing’s future”. For now, it’s a curious anomaly.
Aejaks - Tcl/Tk Style Framework Built on Echo2
For those Ajax cowboys out there who pine for the power and simplicity of Tcl/Tk, there is good news for you: Aejaks lets you write Ajax apps using Tcl. The widget model is inspired by that of Tk, but is not compatible with it.
#####################################################################################
# showCode - create a new window, show the code from the code array
proc showCode {name} {
global code
set w .split.s2.win
if {[info exists ::$w.code_$name]} {
return
}
WindowPane $w.code_$name -title "$name Code" -width 600 -height 600
ContentPane $w.code_$name.c -background white -insets 10
Pack $w.code_$name.c -insets {10 10 10 10} -border {4 black solid}
TextArea $w.code_$name.c.t -text $code($name) -foreground black -background white -width 800 -height 600 -border {3 black groove}
Pack $w.code_$name.c.t
Pack $w.code_$name
}
It uses Jacl, a Java implementation of the Tcl language and is implemented on top of another framework we are familiar with: Echo2.
Echo2 is a Java based windowing toolkit for building Ajax-enable applications. Aejaks translates most of the Echo2 Java objects into Tcl objects, but provides many shortcut features, such as anonymous object construction for attribute-type objects.
There is a console included in the source that allows you to do some interactive scripting with Tcl, otherwise it looks like you have to compile the Tcl into an app before deploying.
This is another sign that 2007 will be a year of intermediate forms, i.e. frameworks the compose and build on other frameworks. Wait until 2008 until we see something truly new.
Topics: Echo2
The Iphone, why.
Years ago I would go to conferences and people would hold up their Palm and lecture us on why it worked, the economy of means, the elegance. Time passed and the same people - usually people who had not actually participated in the design process of the particular device - would hold up an Ipod and preach the wonders of the clickwheel and how it had revolutionized design on the order of bread slicers or fishnet hose.
That they usually missed the point was irrelevant. The value of the Palm was that it was much smaller than a Newton, and much faster because Palm asked people what they actually used. And both of them had coherent software interfaces that easily synced the stuff on your desktop machine. That the Ipod made having many gigabytes of purloined music sort of marginally legitimate was not trivial, either.
So I wanted to get in on the ground floor of helping Apple hype the Ipod phone, because I am predicting that this will save me a significant amount in conference fees over the next two years.
Why does this phone elicit responses like Alice’s, a post or two back? Which I fully admit I shared as all the Mac addicts read the real time blogs from Macworld while jobs was unveiling it. Oh yeah, it is cool!
But what it makes such a big splash is a study in contrasts, and how the competition failed to develop and market something that people can feel affection for.
The current crop of cellphones are junk. There are so many difficult to use features that the cellphone companies market a special line of simple phones for the very young, very old or especially annoyed.
And the phone companies are completely oblivious to this resistance. Because of the way that cell phones are sold, really as a token of the extortionist contract with the service provider, there is a critical reduction that occurs to the feedback from the user. The design of the phones is passed on as a feature list and separated from everything else in the users existence. An elaborate, undoubtably extensively discussed system to create a broken wheel.
The worst thing about the current phones - and don’t get me wrong, Razors look cool and have great ads - is that if you lose it your numbers and all of the phone specific programming is gone. Unless you have a Trio or a Blackberry, you are just out of luck. But even Trio’s and Blackberries don’t have a good mp3/mp4 implementation. Much less the overwhelming cultural currency [read: cool] of the Ipod.
The Ipod advantage in both cases is it’s connection to the desktop.
For phone numbers, it leverages a much more powerful interface; your desktop through any Vcard compliant program. So you have all of your email addresses on the phone; and backed up. Think weeks of texting saved. Imagine what you will do with that time.
In terms of features, the new phone is configurable. Which means, to a luddite like me, that you can turn most of them off. Thankyouverymuch!
Not having to carry around my Ipod and my phone is probably the least of the advantages. Waiting until all the early adopters buy it and the price falls will be the hard part.
Topics: Best Practices, Design, Desktop, Interaction Design, iPhone, Usability
The EMusic Experience
I came across a reference to Emusic.com recently while reading an article in Wired magazine. The article mentioned that Emusic, although a distant second in terms of membership was a strong competitor to iTunes.
I use iTunes exclusively for downloading music—having realized that the feeling I got when I used the free method was because it was illegal. But I was intrigued by what Wired mentioned about Emusic. It had some features that iTunes didn’t: Up to 50 free downloads upon signup, a monthly subscription fee that, if maximized to capacity comes to .33 a download, and the ability to burn Emusic mp3 files onto a CD.
I decided to give it a try. And what ensued was, in my opinion, a perfect example of the importance of a well designed user experience to the success of a product. Emusic may offer some features that I can’t get with iTunes, but iTunes makes music consumption and management a breeze, while Emusic, well, just doesn’t.
Before I began downloading music, I had to sign up to Emusic’s service by providing a user name, password and credit card info. I quickly noticed a lack of clear indication of when my credit card had been billed. Eventually I did receive confirmation, but not before a little apprehensiveness, and some rather frantic clicking. As it turns out Emusic works by installing an application on your hard drive, which acts as a sort of decompresser of the proprietary files that download to your desktop from the site. Only once I finished installing the app and then moved back to the web site did I receive confirmation that I was billed. It isn’t made clear, though, until the end of the process.
Once registration/installation/billing had finished, I proceeded to try and start downloading my 50 free songs. The most frustrating aspect of the Emusic experience is finding music. Both the browse and the search functions are poor. Browsing titles left me wondering where the user generated content was. Clicking on the Alternative/Punk link in the Genres section brought up a list of Sub-Genres (defined by who?) as well as a number of “Featured” albums (again, selected by who?). Nowhere could I find an easy way to get to music I like without it mirroring their grouping model. So browsing became a trial and error process—the familiar click then back pattern that I’ve become tired of already.
Emusic may
not have any songs by either Pearl Jam or Alice n Chains, but it sure wa
s hard to tell from the search results. All Three search queries resulted in long lists of artists and bands, which I had to scroll and click through to find a match. (I didn’t find any matches.) The site should be intelligent enough to recognize that I only wanted an exact match, and returned 0 results, so I know the site doesn’t contain that artist.
When I finally found a song I liked, I clicked download, but other than the page refreshing, nothing appeared to have happened. It took 4 times clicking download, including 2 on another browser I had opened before I had realized that the song file had actually downloaded and was ready to be opened by the Emusic app. The downloaded Emusic file needed to be converted to an Mp3 in the Emusic app. Once the file has been converted to Mp3 I was able to listen to it by clicking ‘listen’. But the app only converts files to Mp3. It doesn’t play them. So the song opened in Real Player.
Lets recap the Emusic experience of finding, downloading and playing songs: Open Emusic.com in a browser, look (possibly long and hard) for a song, download it to your desktop, open it in the Emusic App, wait for it to convert to Mp3, and then listen to it in Real Music player. That’s 3 applications I need to move back and forth between, which isn’t an experience I relish doing again.
The itunes experience, on the other hand, is simple, largely because everything can be taken care of—browsing, locating, downloading, playing, Synching with the iPod, and burning CDs (when possible)--in one app.
Although Emusic has features that iTunes doesn’t, I wont be making the switch anytime soon. For Emusic to become a viable alternative to iTunes, it needs to figure out how to make the user’s experience simple and intuitive.
More Articles Needed on How to Design Ajax Apps, not Just How to Program Them
I've been busy with yet another big launch (YABL), so I've only had time to read a few things on Ajax. I've long argued that Ajax wasn't just going to give us a few nice widgets, but that it would change the way we developed web applications (and how that will give you less of a headache). Apparently Christian Heilmann agrees in his juicy enchilada of a post entitled Event-Driven Web Application Design.
Rather than arguing as I do that the proper model for Ajax webapp development is the desktop GUI, he starts at a more basic level: the event-driven nature of Ajax webapps. He draws a distinction between the traditional way of doing event handling in Javascript -- page finishes loading, do some initialization; click a link, trigger another function; etc. -- and the DOM way of doing things -- adding specific event listeners to elements.
He goes on to describe how to plan an event driven app, how to add custom events, and walks through planning an example app. While I think that he's thinking too small (developing apps with Echo2 like a Swing app is the way to go), I think more articles like this are needed, not on how to add an Ajax widget, but rather on new ways to develop Ajax webapps.
Topics: Ajax Development, Editorial
Why Not? Rewriting jQuery and Scriptaculous in GWT
jQuery has just turned one year old and, to celebrate the matter, they have released version 1.1 to the world. Looking at the changes and improvements has me considering the situation in that other framework I've been working with of late -- GWT. GWT has a tame little DOM class behind which it hides the messy browser discrepancies; still, it looks just like the document element with its getElementById and company.
What I want is the coding style of jQuery in GWT. I'd like to be able to write something like
// $("p").after("Hello");
jQuery.S("p").after("Hello");
Now one of the first things that people did with GWT was splice in libraries like Scriptaculous via JSNI. It was easy and ladled all sorts of neat effects into a GWT-based application. Why rewrite perfectly good Javascript libraries when they could be included with such ease? Well, as it turns out, there are more than a few reasons.
- Writing utility and effects libraries in the GWT allow the browser specific stuff to be handled where it belongs -- in the GWT.
- Splicing in complicated and voluminous Javascript native code complicates testing and debugging. Rewriting the Javascript libraries in Java allows the whole sticky mess to be debugged and tested in hosted mode.
- The DOM class is pretty dull, just like the
documentelement. There is a reason why libraries like Prototype and jQuery came about with their compact chained-method style. It's just a lot more efficient and snort-inducing fun to manipulate the DOM this way.
It might be a little bit difficult to really get a 1-1 port of something like jQuery, but it's certainly worth a try. If I have time this week, I will have a look at both jQuery and Prototype/Scriptaculous and see which one is the easier one to tackle.
Topics: GWT, Javascript Libraries
ESPN.com likes and dislikes
I love sports and I can’t get enough of the web, so I’m naturally a regular visitor to ESPN.com. In this post I’d like to share my likes and dislikes of the site.
I like…
The persistent navigation gives you access to every section of the site with one click, and it’s only 28 pixels wide.
The stunning imagery compliments the journalism perfectly, and creates an aesthetic appeal, which keeps me coming back to ESPN over the dozens of other sites I can get scores and analysis from.
ESPN’s video features (ESPN Motion, and ESPN 360) keep improving, which illustrates to me that the company understands the future of the web, and its place in it.
The Spotlight feature. This dynamically refreshing feature cycles through a series of ‘hot topics’. Usually at least one of the topics piques my interest, or at least my curiosity. (And more often than not, it’s the imagery that pulls me in).
The news headlines on the right hand side of each page give me a nice at-a-glance overview of the day’s happenings in each sport.
The Flash generated polling. I’m almost always intrigued by the poll questions on the site, and I love looking at the interactive results pages, which provide you with a state-by-state breakdown of the results.
The interactivity with the offline world. Features such as chats with players, question and answer sessions with analysts and coaches, and the ability to vote for magazine and television coverage make me feel like an active participant, not just a passive information gatherer.
Gamecast, which is a program that plays in a browser window, allows you to follow any live game in major sports around the globe. Besides being almost real time, Gamecast gives you access to a depth of information about the current situation in the game (player at-bat, Goal scored, etc.) than you cannot get from any other medium. It’s a great use of the web, and a precursor to some of the things to come as sports programming as TV and the Internet merge.
The section specific background images tell you instantly and beautifully what section you’re in by depicting the playing surface of the sport.
The NFL drive charts, which graphically all of a game’s possessions, including where and how they ended, how many plays they took, and how long they lasted in a concise interactive format.
The wide format on the home screen takes nice advantage of the ubiquity of higher resolution monitors.
I dislike…
The video on the home page plays automatically. If I want to watch one of the segments, I’ll press the play button. I don’t like the distraction, or having to turn off my computer’s volume every time I go to the site.
The ads. I guess that’s how large content sites now work, but I don’t have to like it. Especially annoying are the ones that require you to click a link just to skip the ad and go to the home page.
The site is slow to load. ESPN has obviously made a choice in favor of glitz and glamour, and I agree with that choice. However there are times when the home page is slow to load on even my cable connection, and I won’t be dialing up to ESPN.com anytime soon.
My ESPN—a personalized sports portal—is awkward to use and unattractive. Although it has potential, I prefer the home page, even if it means additional clicks to get the info I want.
And finally…not enough Hockey! This is probably more of a complaint about sports interest and coverage in the US in general, but I wish I could find more hockey on the front page.
About Pathfinder
Recent
- Walk-Through Test Coverage
- Where minimalism fails: The problem with Apple’s less-is-more approach
- jQuery goodness with ASP .NET
- Design Thinking
- Bullseye Diagram
- Roles Testing For Security
- Blackbird takes the pain out of JavaScript logging
- Making GWT JSON not Quite so Painful
- IDEA - preconference workshop 06 Oct 08
- HTML5, Ajax history management, and The Ajax Experience 2008 Boston
Archives
- October 2008
- 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
37signals
Accessibility
actionscript
activerecord
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
apple
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
Business Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
chess
Chicago
Cloud Computing
CMS
COBOL
code art
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
design thinking
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player
flash player 10
Flex
flexunit
Flock
Flow
Frameworks
front end
front end development
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
hardware
Healthcare
Hibernate
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
ILOG JRules
Information Architecture
Innovation
Instructional Design
Interaction Design
Interview
iPhone
iPod
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSR-94
JsUnit
laptop
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
logging
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
Microsoft
minimalism
Mobile
Mootools
mouse
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
notebook
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
Open Source
Opera
Oracle
ORM
osx
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Product Definition
productivity
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
rubyamf
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
Startups
STI
Story Telling
Struts
Tamarin
Task Flows
Test Driven Development
Testing
The Ajax Experience
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