- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Where is Flash at?
For some time now, I've been using the same site to see how much has Flash content advanced - www.thefwa.com
Topics: Flash, flash awards, User Experience
Facebook apps: Not too late to compete on the user experience front
Despite the hype, Facebook's a frontier rather than an established metropolis. There's still room to ride into town on a white horse and save the day, earning yourself a healthy reward in the process. Exhibit A? The so-so user interface standards of the social network's most popular applications.
I recently, belatedly started playing Scrabulous with various friends and I'm shocked at the just-okayness of its UI. The lack of an on-screen legend for the mechanics of the variously shaded bonus squares? Puzzling. The drag-and-drop interface for shuffling tiles around in your tray? Maddeningly persnickety. The mismatch between the word lookup feature, which uses thefreedictionary.com, and the application's own, internal whitelist of valid words? A real bummer.
Scrabulous provides an adequate ripoff of a venerable and justly loved board game. But the rough edges of its user experience suggest that Facebook still has plenty of room for folks who know how to polish a UI till it gleams. Sure, first-to-market advantage gets magnified on social networks. But as these new application platforms mature, I'm convinced user experience design can provide a compelling means of product differentiation.
Topics: Facebook, Games, User Experience
All the news that was fit to print
The New York Times has unveiled an archival service called Times Machine which archives the past 100 years of the newspaper of record. Along with the benefit of seeing ads for trusses, we see a very sophisticated and robust interface using HTML + CSS + Javascript of a very easy way to scan large amounts of printed text. There have been so many of these kind of apps, almost always using Flash with proprietary back end processing, it's refreshing to see these sorts of interfaces with the code all public and easy to steal learn from.
In this case, the clever interaction design (and a hurdle for HTML) is to pair the actual article image (spanning multiple columns) with the text summary. The implementation makes scanning the paper a breeze and has a great visual clue of highlighting the image and overlaying the summary text. I'm delving into the markup to see how they managed to dynamically pair the images with the representative text, and seeing what other magic is under the hood.
Another nice feature was the rotating 'share' button, which takes care of not prominently promoting digg or reddit, but subtly reminding users that if they like to vote, here's where to do it. The only bad feature is that this is for paying customers only, but NYT has made free its online articles, hopefully in time this will follow suit, the days of microfilm readers may be numbered.
Topics: User Experience
Upcoming Talk at RIApalooza: Fast. Smart. Agile. User Experience Driven Agile Development
Look Ma, no Powerpoint! My colleague Matt Nolker will be giving a talk entitled Fast. Smart. Agile. User Experience Driven Agile Development at the upcoming RIApalooza to be held at the Illinois Technology Association (ITA), 200 S. Wacker Dirve, 15th Floor, Chicago, on Saturday, May 31st.
The event has an interesting restriction: no Powerpoint. So no snooze fest sales presentations with endless bullet points. Since UXD (User Experience Design) has some visual aspect to it (you can only wave your hands and speak to a point for so long), we will be making due with "more primitive visual aids" as Tom Lehrer put it.
See you at the networking even on Friday.
A case study in Flash UI annoyances: style-card.com
Maybe I read too much Victorian literature, but I've always wanted a personal calling card. Recently, I decided to get one: a little something to help new acquaintances remember my phone number, email address and important URLs. Based on a recommendation from Time Out Chicago, I turned to Style Card, a slick consumer service that promises a less generic riff on the basic business card.
Here's how the company describes its product:
It's a social networking card created by you for the purpose of sharing your details and your style. Let people get to know the real you – or the not-so-real you.
Sure, I could have fired up an Adobe product, used a commercial printing service and gotten 1,000 copies of my own design for about $25. But owing to my lack of graphic design mojo, I decided to shell out $59 (plus shipping) for a mere 80 shiny, round-cornered Style Cards. The 3,000 percent markup is ridiculous, but I wanted to see whether I could benefit from the company's idiot-proof design interface. Besides, I figured I could get a blog post out of the experience. I wasn't wrong.
Topics: Adobe, Flash, User Experience, User Interface Standards, Web Standards
Top 5 Iphone styled websites
In the oxymoron that was mobile web design for many years we struggled to try our HTML pages out on different mobile devices only to have to resort to stripping out anything resembling good design or usabilty. On my trusty RAZR phone, I was content with using java apps to display things in a meaningful way, but having to learn the arcane hotkeys for each app became a chore, and they went little used. With the iphone, the promise was that regular sites look like their BS (big screen) brethren, where users can not have to learn new interaction conventions for their favorite sites outside of zooming and moving around to fit the screen. However, there is a second wave of web apps that optimize their site for the iphone. Using conventional xhtml, css, and some javascript, with a few unordered lists you can distill most complex sites into something new, and in many cases are easier, faster, and better user experiences than the 'real' sites! I hope this gives notice to web designers to pare down things that users rarely need and keep things simple. You may have your favorites, please add them to the comments, and non-iphoners can usen this emulator to try out the alternate sites:
5. iPhlickr - http://www.chandlerkent.com/iphlickr/
What sets this apart is a seeming blur between the iphone features and the browsing world, when you select a photo, you can then share it, send it, or view it within the flickr world, unfortunately when iphone apps become available next month, flickr will probably become an 'app', but until then, this is a very ingenious and useful approximation.
4. Wikipedia
Iphones aren't fast in downloading data (yet) so when I want some info, I don't want a huge load time with lots of info that isn't getting me to my goal, this interface is very fast, and also does a great job in reformatting wikipedia content to take advantage of show/hide heading behaviors, which is a new iphone 'standard', and one that helps parse long documents quickly.
3. Amazon
A old-time favorite (was iphonized pretty much right away), but Amazon should be applauded by honing down their value propositions to fit on this screen, that is product, price, ratings. Thats it, and thats what In need when I'm thinking about picking up that camera in Circuit City, i want to swoop in and Amazon it for comparison and this does the job.
2. Reqall - www.reqall.com
I mentioned how much I liked this the other day, a technologically amazing mashup of voice/text note taking, plus some nice keyword recognition make a pretty darn useful to-do list! Add on the iphone interface, with good integration of thick finger style tabs, gets a reasonable amount of navigation in a small place to seal the deal. Bummer is that it makes you login every time, but I am lobbying for that to be fixed 
1. Google reader - www.google.com/reader/i
I could say the google iphone interface, but the reason for this post is a huge shout out to Google for their revamping of the RSS interface for the iphone. I am super picky about RSS readers, my copy of NewsFire broke the other day in an update and I was in a panic to find a replacement, to no avail (I fixed it by installing a previous version). The thing I dislike most about other RSS readers is using the metaphor of email. I think we all get too much email, and RSS is not email, its more like a very personalized newspaper. The google reader nails this, and has kept me busy on train trips really enjoying reading stories, with excellent ajax integration, which really shines on the iphone since refreshing the page can take 20+ seconds, keeping info inline is imperative.
I also want to give credit to the password filler-inner 1password for their iphone interface, and twistori that shows that the same design works on both BS and little if the concept and interaction are clear. If I had a wishlist for sites I wish worked on the iphone it would be cellartracker (their regular site is not too great either, but the content is invaluable on mobile) and chase - if you are really embracing mobile users, let me really bank online.
The environment will change in the next month with the introduction of iPhone apps, but the resourcefulness of these developers to take 'plain ol' HTML and make a good user experience in a very constrained environment shouldn't be lost. Give your comments and contribute your favorites I may have missed.
Topics: iPhone, User Experience
37signals and the pain of the below-the-fold button
Google Notebook finally got a feature I've been asking for since the beginning: The ability to remember whether I want my notebooks sorted alphabetically or by date of last update. When the service launched, notebooks were always sorted by last update. When they finally added the option of alphabetical sorting, they left out the ability to make your choice sticky across sessions. This little wrinkle annoyed me almost as much as the Google Calendar search box's default action of searching public calendars rather than my own. I can't believe what a difference it makes in your relationship with a webapp when you don't curse out loud every time you use it.
Many users have the tendency to get bent out of shape about deficiencies in a tiny, tertiary portions of an application - or, for that matter, an operating system. Mac users devote entire forums to complaining about changes to, or lack of changes to, the Dock. PC users are still cursing those stupid Windows XP "You have unused icons on your desktop" messages. When we spend increasingly endless stretches of our lives in front of a terminal, tiny annoyances add up.
I call this the Disproportionately Annoying Detail Syndrome, or DADS. It has a tendency to flare up worst when you're working late on a short deadline and your computing environment fails to read your mind.
A couple of years ago, when I first started abandoning desktop software for cloud computing, I gave Ta-Da List a shot. I couldn't get over the placement of the "Add another item" command. Instead of putting it at the top of the list, they stuck it at the bottom. Every time I wanted to add a task, I had to scroll down to the bottom of the page before I could start typing. I worked with this system for about a week before jumping ship to Remember the Milk, where I can hit the "t" key to add a task without ever picking up my mouse.
Topics: Usability, User Experience, User Interface Standards
The User Interface is the Root of All Evil
I'm into my third decade of developing software now. I've gone from Structured Design, to OOAD and SOA; from waterfall to RUP to Agile. There is one aspect of software development that has remained fairly constant in all of that time: nothing causes as much complexity and bad architecture and design as the user interface.
I'm not saying that MVC or PAC based UI's are complex to design and implement, though they can be. Rather, I'm saying that the user interface can infect the rest of your system -- the domain model and other business logic -- leading to a poorly designed and hard to maintain system.
Topics: Best Practices, User Experience
Delighting the user with the tiniest of details
Building software people love involves learning to read minds - or at least learning to think like your users. In the world of free, web-based software, there will always be 10 versions of every application: 10 different to-do lists, 10 different dictionaries, 10 different bookmark organizers. It's not enough to meet users' expectations about features; you've also got to delight them if you want to win market share. If you don't think through every interaction and use case, you're probably annoying the hell out of people without even knowing it.
That's why it's important to actually watch users in action with your application. It's a maxim in user experience design circles that you, the programmer, are not the user. Sure, you should eat your own dog food, but remember that the experience of using software that you wrote - and whose every shortcoming and compromise you understand from the inside - isn't the same as chancing upon that software in the wild and giving it a shot. Look at your software through the fresh eyes of users who didn't write a single line of the code. That's when you'll actually learn what you've created and how to improve it.
... all of which proselytizing serves only to introduce one rant and one rave about free software I use every day. Neither of these are web applications, but both of them are tied directly to the 'net.
Topics: User Experience, User Interface Standards
Gmail, agile development and user experience design
Ionut Alex Chitu of Google Operating System posted yesterday about Gmail's evolution from internal beta to public beta to today's constantly-evolving-but-still-beta version. Gmail's Humble Beginning never uses the phrases "agile software development" or "user experience design." (Nor, for that matter, does the original post, by Gmailer-turned-FriendFeeder Paul Buchheit, from which Chitu liberally quotes.) Regardless, the evolution of Gmail provides a case study in the combination of agility and UxD.
Sample quote from Chitu's post:
Gmail got a delete button after many months of requests from users, even if Gmail's philosophy was "archive, don't delete". Gmail will also add some functionality from folders to its labels, most likely drag and drop.
The key step is to build a product that's interesting enough to a attract an audience and learn from people who use the product. "The sooner you can start testing your ideas, the sooner you can start fixing them," explains Paul.
Topics: Agile Development, Google, User Experience
Agile User Experience: If you have a silo, knock it down
In many development processes, team members are organized by functional group. A project might have a team of developers building the code, and then down the hall or across the globe, a separate team of designers working on the visual and usability aspects of the application. The two sub-teams are walled off in their own silos, and communication between the two sides is minimal.
This structure is not compatible with an Agile software process -- it's too hard to get rapid feedback between the teams that make a process truly Agile. Worse, if the two teams are separated, the odds that they will have a common conception of the project, or even a common set of terms for discussing the project.
The most important step in tearing down the silos in your project is just switching your mindset from function-based teams to project-based teams. Continuous integration spreads from being just something the developers do to a way of making sure that all aspects of the project are in synch.
At the most basic logistical point, the designers and developers should share a common code repository. There's a certain amount of overlap in the tools used for web applications on both sides. If designers can see the latest version of the application when making CSS or HTML changes, then developers can see those changes and work with the most current design as quickly as possible.
In order for this structure to work well, each side needs to move out of its silo and toward the other. Developers need to have an awareness of usability and design issues, and be able to discuss potential problems with the designers. Developers also need to be willing to do any rework that will be needed as the design changes.
Designers need to be willing to work at least some of the time in the developer toolkit, working with source control, able to make CSS or HTML changes directly in the code files (even better if the designers and developers can make it easy to make tweaks at the JSP or ERB level). Not everything that a designer does can be captured this way, but using common tools and files where available increases the team's ability to work together. Sharing knowledge makes the team more able to notice potential problems, and makes teams more stable over time.
Last week, I wrote about how a user proxy can help integrate Agile and User Experience Design.
Once again, let me mention the upcoming book Professional Ruby on Rails. Available mid-February.
Topics: Agile Development, Ruby on Rails, User Experience
Agile User Experience: If you don’t have a user, invent one of those too…
Following up on Brian's point...
A customer proxy of one kind or another is also important in integrating Agile practices with User Eexperience Design.
One of the long standing issues in combine Agile development with User Experience Design is just the differing time cycles between Agile developers, who are running on a test, develop, refactor cycle that could be mere minutes long, and the UXD designer, who is working on a longer, perhaps more traditional, cycle.
The problem comes in when the developers start making coding decisions for the interface. Without immediate feedback from the UXD designers, the developers are often left to their own devices for the initial versions, with revised designs coming weeks or months later.
Our goal is to keep the development team moving forward with current feedback from the design team. For exactly this reason, the original XP book listed Onsite Customer as a core XP practice. However, that's not always feasible, and in any case for User design you want the user's feedback, which may not be the same as the customer's.
What we try to do is use the idea of a customer or user proxy to allow us to have incremental refinement of design, and allow the development team to get quick feedback and continue with the next fine-grained task.
When a developer has a usability question, the developer asks a team member acting as a user proxy. This is either an analyst on the project or one of the designers. The user proxy makes a decision on the question -- if not a final decision on all details of the problem, at the very least a consensus on some aspect of the problem that the developer can do next. While the developer does that task, the user proxy goes off and consults with the design team and the customer.
Ideally, by the time the developer is ready for the rest of the task, the user proxy has more detailed requirements and design for the developer. The key is making sure the developer's next step is always covered.
This does require some effort from your team -- the developers have have awareness of usability issues and concerns and the design team has to have the ability to respond to developer concerns quickly. Again, though, the design team doesn't need to have all the answers at once, they just need to be able to give incremental details to the developer.
(The image of the floor appearing directly underfoot is from the ad campaign for Gatorade G2)
Have I mentioned my upcoming book Professional Ruby on Rails, yet? Available mid-February wherever fine computing books are sold.
A UXD Lesson from the Gas Station
This past weekend I was up on Howell Mountain in Napa, tasting the ultra tasty wines there and taking in the gorgeous views. On the way back to SF, we stopped at a Shell gas station. It took me a good 20 minutes to gas up. Why? Lousy user experience. Let me explain.
This was a new, fancy pump. It had a TV up top, a 4"x6" LCD screen just below crotch level (I'm 6'4"), a numeric keypad with a credit card reader about a foot to the right, and three fuel selectors another foot above. It was about 11:30, and the sun was shining right at the LCD screen. First I thought the TV was saying something relevant about my fueling my car. The Doppler effect of several other TV's saying the same thing at slight offsets around the gas station was also a little disconcerting. I finally figured out that the TV was just polishing the Shell brand and flogging sitcoms (aren't the writers on strike?).
Topics: Testing, Usability, User Experience, User Interface Standards
Lessons in usability from a trio of remote controls
I wasted eight hours trying to set up a high-end universal remote control last week. In the process, I was reminded that usability matters as much in the world of physical gadgets and desktop software as it does in the web-browser ghetto.
My new Logitech Harmony 670 Universal Remote was supposed to replace the dusty old universal remote I've been using for the past eight years. The old remote - a Home Theater Master SL-8000 - was state-of-the-art for its time, but I could never get it to replicate the functionality of my Tivo Series 2 DVR remote, perhaps the most ergonomic and usable remote control ever designed. I was happy enough with my two-remote setup till I saw the Logitech, a programmable universal remote especially designed for the DVR aficionado. It was shaped like a Tivo remote, so I figured it would combine the simplicity and elegance of my Tivo remote with the universality of my Home Theater Master.
Fat chance. Thanks to terrible software and abysmal hardware design, the Logitech sent me scurrying back to the comfort of my two existing remotes. Here are the five reasons why:
Topics: Usability, User Experience, User Interface Standards
Usability review: Amtrak.com checkout process
Many large ecommerce sites work beautifully as long as users do what they're supposed to. The minute users make mistakes, however, the UxD falls apart completely. Case in point: Amtrak's online checkout process, in which poor choices about error handling can make it a real hassle to check out successfully.
Amtrak's first mistake was to create an email address verification field. Plenty of usability experts have decried this silly device for encouraging error-free user input. The annoyance would be minor, however, if Amtrak at least autofilled the email verification field for returning visitors. It doesn't. When you log into an existing Amtrak account and try to purchase, your address is autofilled in the main email field, but it's not autofilled in the verification field. Because there's only one field in the entire "Contact Information" section of the page that doesn't get autofilled, it's easy to breeze past and not realize that input is required. You go on to enter your credit card information and click "purchase," only to end up with an error. Until recently, that error wasn't caught by any client-side validation, so you had to wait for a round trip to the server before being notified. Recently, though, the interface has been updated so that you get a 1999-era JavaScript popup telling you to fill in all required fields. It's nice that Amtrak at least reduced the annoyance of this bug, but why not just fix the root problem by either getting rid of the email verification field altogether or autofilling it for returning customers?
Topics: Usability, User Experience, User Interface Standards
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
Web 2.0
Web Design
Web Development
Webkit
Weblogs
Web Services
Web Standards
Widgets
will_paginate
Windows
Wireframes
WordPress
workflow
XML
XML Metadata
XUL
Yahoo Map AS3 API
Zeigarnik
Zeigarnik Effect
ZK