- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Four blatant iPhone usability blunders (and one constant annoyance)
I've been an iPhone 3G owner for about six weeks now - six weeks of love, loathing, cool apps and connectivity problems. Rather than complain about poor network coverage, though, I'd like to delve into some of the vexing usability problems that hamper the phone's user experience.
No ability to disable autocorrect completely
Like pretty much every autocorrect feature ever built, the iPhone's does more harm than good. It always thinks it knows best. If you don't watch it like a hawk, it will render everything you type completely nonsensical. Proper nouns, abbreviations, profanity - all get turned into gibberish by this well-meaning but deeply flawed function. And god forbid you try to use the classic email e.e. cummings mode in which uppercase letters don't exist. The iPhone literally will not let you output the word "iPhone" without throwing in that capital "P." It's maddening.
If the purpose of autocorrect is to allow you to type quickly without having to monitor your output, it fails miserably. On the iPhone, if you want what you type to show up verbatim on the screen, you have to pause at the end of each word to ensure that the OS is not about to substitute its own wisdom for your actual intent. I would honestly rather type on a 1999-era StarTAC numeric keypad.
None of this would be as galling if there were a setting to turn this feature off. But there isn't. Elaborate, unwieldy workarounds have been suggested - all because Apple users know that the folks in Cupertino often paternalistically ignore their users. Microsoft's OS and apps may suck, but you can usually customize the hell out of them. Not so Apple's.
Topics: iPhone, Mobile, Safari, Usability, user experience design
Google Calendar: Finally, a search box that makes sense
I've been complaining for months about a usability problem with Google Calendar's default search behavior, so I figure I should document that it's finally been fixed. Ever since gCal introduced the concept of public calendars, hitting "enter" in the global search box has kicked off a trawl through the public-calendar database. Instead of searching MY OWN calendar for, say, my Aunt Donna's birthday, gCal instead searches public calendars of, like, sports schedules and Kazakhstanian bank holidays. Smart.
Now, though, that behavior seems to have been flipped. "Search My Calendars" is now the default action, while "Search Public Calendars" has become the secondary action. Bravo!
Topics: Google, Google calendar, Usability, user experience design
Chicago Front-End Web Developers group forms on LinkedIn
LinkedIn's Groups feature hasn't quite reached maturity yet, but my friend and occasional colleague Zack Frazier hasn't let that get in his way. Zack recently launched the Chicago Front-End Web Developers group as a way to help UI specialists network and connect.
According to their site, the LinkedIn folks are apparently hard at work making Groups more useful:
The groups directory is not currently open. We are working on creating a searchable directory for all groups. If there are groups you wish to join, you may click on the group logo from the profile of a group member and request to join.
In the meantime, you can join Chicago Front-End Web Developers using this direct link. Joining allows you to put your loyalties on display to prospective contacts (see screenshot).
UI folks, stand and be counted!
Topics: front end development, LinkedIn, Usability, user interface
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
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
Viewport width: Size matters, but not in the way you’d expect
When a company gears up to redesign its website, the question of screen resolution always seems to eat up tons of time and energy. Despite the long, slow evolution of the browser from a publishing medium to an application platform, many developers still think in terms of "web pages" - large units that require, if not fixed dimensions, then at least a fairly defined range of viewport mins and maxes. Rather than thinking of the browser window as an operating system full of work spaces, palettes and menus, we think of it in print terms, like a newspaper page full of columns and sidebars. This occurs despite a decade of education to the contrary from any number of software and visual design experts.
Topics: Usability, User Experience, Web Design
The Confluence of UXD and Agile
User experience design is integrated into software development and other forms of application development in order to inform feature requirements and interaction plans based upon the user's goals. The benefits associated to integrating these design principles include:
- Reducing excessive features which miss the needs of the user
- Improving the overall usability of the system
- Expediting design and development through detailed and properly conceived guidelines
- Incorporating business and marketing goals while catering to the user
Consultants lie. They tell you that software X can be developed in time Y for cost Z. That is a lie, plain and simple. The consultant has developed software before, and you know your business, but the two of you have never developed this particular piece of software before, otherwise you would be using it now instead of developing it. So, by definition, in software development you are doing something for the first time, otherwise you would be performing system integration.
This may explain why study after study finds that Software Engineering is notoriously poor at estimating, and why software projects typically run over in terms of cost and time. Enter Agile. Agile doesn't so much eliminate risk as admit that it is there. You don't bother putting together a 24 month project plan because you realize that:
- The estimate will be off my 400% or more.
- The client thinks they know what they want, but really doesn't.
- You'll know way more and make better estimates after 3 months of working on the project.
Topics: Agile Development, Best Practices, Usability, User Experience
Worst user experience ever….
We were in a meeting talking about possible ways to showcase user experience design when I brought up statistics or quantifiable metrics. Everyone groaned, as they do when I bring things up, but mainly because it tends to be a bit of a sore spot in the world of usability, It seems obvious that good user experiences lead to more popularity, sales and general peace and happiness. However, percentage gains and metrics are suspect since there is no way to have a double blind scientific study of 'usable' vs 'unusable'. Thus, the practice of reviewing and refining the user experience can often be considered optional or put off till after release or just too hard to 'bake in' to the process because it doesn't produce hard numbers. In my defense I did come up with a situation where hard numbers and user behavior told a very interesting story.
The 'worst experience ever' in the title came to mind as an illustration of the confusion and opportunities that surround metrics and usability design. I speak of last months release of Radioheads "In rainbows" (since decommissioned). If you haven't downloaded the music yet, or heard the story umpteen times, it happens that Radiohead created a sanctioned way to pre-offer their new record it for download as mp3. Radically, customers could pay what they wished for it, including nothing. The real story as I saw it came from the way they managed this transaction - in the most confusing, user unfriendly way possible. The site is garish and difficult to comprehend, even though the download to the music is the only goal. You are asked to pay before even sampling the album. When purchasing, the amount is left blank, and in pounds, so no translation of other currency, no 'suggested' price. If you enter an amount below 1 pound you are greeted with errors, any questions or advice explaining the process all appear in popup windows, its a mess. When the user is finally able to complete the transaction, they receive nothing, but wait for an email with download instructions.
With all these hurdles, it only seemed natural to pay nothing, which I did, since it all seemed like some kind of con, as trustful as I am of their brand. After a few days (I did it before 'release'), an email arrives with a download link. Then you can finally sample what you (didn't) pay for. It was my intention to check out the record (which was quite good, actually), then return to offer a few buck donation to the cause. However, you have to essentially re-purchase the record as another 'person' so it seemed as though I would be guilty of 'stealing' it the first time, and I got busy and...well...
Even though it has been a kept secret of the band, news stories came out speculating that as many as 60% of people did not pay. Many commentators used this metric as somehow holding some significance of why and how people think of paying for music. No one mentioned the horrible shopping experience, outside of a few blogs like this one. In all, it should be noted that every person using the site did complete the task successfully, and no animals were harmed in the 'stealing' of the music. The only casualty was the business model. If the goal was to monetize the download, it failed in every respect by making it difficult and unwieldy for the user to pay a fair amount. However, the user was satisfied by getting the music they wanted. So perhaps usability is better defined as aligning business strategy with user goals? I know the statistics on the user behavior was much reported, so perhaps it's time for a double blind study for their next record - with a better user experience will people pay more? Can't wait.
Topics: Usability
Luke W on Web Form Design Best Practices: no need to wait for the book
In my coverage of An Event Apart Chicago 2007, I enthused about the work of Luke Wroblewski, whose presentation on web forms was one of the conference highlights. If you care about UxD and you're not keeping up with Functioning Form, his blog, you're missing out. His book Web Form Design Best Practices won't be out till next year, but Wroblewski regularly updates his blog with slideshows, conference notes, insightful thought posts and raw material for the upcoming book. If you're still slapping your web forms together without much thought, you should definitely check out the wealth of material he's released on the topic and keep tabs on the book's publication date. It's good stuff.
Technorati Tags
Topics: Usability, User Experience, User Interface Standards
DUX2007 - Simplicity
Too often, the overarching requirement we hear from clients is that the product must be simple to use. As designers, we nod our heads and agree that yes indeed, simplicity is a worthy goal for this project, without ever defining what is meant by simplicity.
At the opening night of the DUX07 conference, B. J. Fogg, from Stanford University's Persuasive Technology Lab, talked to us for a bit via video about his recent explorations into simplicity. What exactly does simplicity mean? What are the determining factors of simplicity, i.e., what am I looking at in order to rate whether or not a product is simple to use?
To Dr. Fogg, simplicity is not a characteristic of the product but rather a perception of the experience. From his studies and research, he's determined there are six elements of simplicity:
- time - can I spend the time learning to use a new product? no? then it's not simple
- money - can I spend money on a new product?
- physical effort - does it require exertion beyond my usual effort?
- brain cycles - do I have to think for a long time?
- social deviance - does it go against the social norm?
- non-routine - does it break my routine?
These six elements vary by individual and by context and there are trade-offs. For example, if I'm a college student who has time but not a lot of money, I might be more willing to invest my time in learning a new product than, say, a business executive who doesn't have the time but would be more willing to spend a little more money on a product that doesn't require a lot of time.
Simplicity, therefore, is a function of the user's scarcest resource at the time. To state it another way: a product, task, etc., is truly simple until it requires a resources that's not available. But remember, Dr. Fogg said that simplicity is determined by the perception of the experience. Which means a task can be perceived as simple if it uses less resources than expected.
Now I'm not saying that from now on we market our products by setting the expectations high to guarantee the perception of simple .... but it sure is tempting.
Technorati Tags: Design, Information Architecture, Usability
Do sweat the small stuff
In designing user interfaces, it's often the tiny details that can drive your users batty or earn their loyalty. Case in point: Apple's latest iTunes update. iTunes 7.4.2 received plenty of attention for wiping out the black market in iPhone ringtones. I was more interested, however, in a couple of subtle but long-overdue improvements in the iPod syncing interface:
- If you try to sync more data than your iPod can hold, iTunes now tells you, in megabytes, how much you're trying to sync vs. how much room you have. As the owner of a 4 GB nano and 450 GB of music, I've always struggled to finesse as much data into my nano as possible without getting that annoying "not enough room" error message. The process used to be:
- Try to sync.
- Receive annoying error message.
- Agonize over which playlist to uncheck to free up some space.
- Repeat ad nauseam, or at least until I stop receiving the error message.
Now, finally, I have enough information to uncheck the correct number of playlists to achieve a successful sync in one or two tries instead of seven or eight.
- When you sync specific playlists with your iPod, iTunes now retains your playlist folder structure on the sync screen instead of flattening all playlists into one alphabetized list. The consistency of the redesigned interface is a huge improvement if, like me, you have entire directories of archived playlists and no interest in paging through them every time you sync. Even cooler, you can sync an entire folder of playlists with one click.
These little improvements may not seem like much, but they add up over time. The mental cost of switching to different software can be high, but users are more than willing to jump ship if your UI accumulates as many petty annoyances and lingering bugs as it does new features. That's even more true when your software is free and lives in the browser.
As Ajax applications get more complex and desktop-y, users are going to demand the same level of polish and sophistication they expect from traditional software***. Agile development helps us get hot new features into users' hands at regular intervals, but it shouldn't lead us to settle for feature-rich, UI-challenged applications. Iterative development works best when subsequent releases add polish to existing functionality. For every feature release, product managers should schedule a separate maintenance one.
Of course, maintenance doesn't mean just fixing things that are broken; it also means taking things that work pretty well and making them work better. As developers, we should apply the same level of scrutiny to the apps we develop as we do to the ones we use. I learn a lot about UI development by analyzing what I love about the software I use. But I learn more by analyzing what I hate.
Take Zimbra, the powerful Outlook clone. The Ajax version totally rocks except for one glaring problem: its appalling lack of graceful field focus. For instance, when I click the icon to compose a new mail message, the "to" field doesn't automatically receive focus. The result is an app that demands either constant use of the mouse or frequent wild goose chases with the tab key. Other annoyances include the JavaScript confirmation box that pops up every time I try to navigate away from the application. By the time I received this warning for the third time, I was done with Zimbra. I clicked "OK" and hightailed it to the Thunderbird download page. (Not that Mozilla's mail client is free of exasperation.)
Ajax increases the number of UI blunders you can commmit, but some of the most common annoyances date back to Web 1.0. Since the Mosaic days, many sites have suffered from a lack of granular error messaging. Take login pages. They often provide a single error message for a bad login, such as "Invalid username or password. Please try again." The user has no idea whether the username or the password caused the error, so she's left to try random combinations. Often, she'll give up and use the retrieve/reset password dialogue. The result is five minutes of frustration and a trip to her mail client just to get past your front door. If your application let her know the specific problem - "That username does not exist" or "That password doesn't match that username" - then she'd have a lot more luck.
In some cases, field labels are just as much to blame. If usernames on your site are always email addresses, then label the field "email address." Users have to juggle dozens of usernames on hundreds of sites. Give them as many clues as possible about how things work on your site.
Of course, not all user gripes stem from bugs. Often, they stem from lack of configurability. I jumped for joy when Google Notebook finally offered me the option to sort my notebooks alphabetically rather than by date. But I still have to click the "A-Z" link every time I visit the app. The interface defaults to sort-by-date, doesn't store the current sort method in a cookie, and doesn't expose a user preference to set it permanently. Thus a welcome interface improvement leaves its own nitpicky new annoyance.
The same thing happened with the iTunes update I mentioned. As much as I love the retention of my playlist folder structure on the sync screen, I can't believe that the folders are all expanded by default - let alone that they re-expand themselves every time I navigate away from the sync screen and then come back. God truly is in the details.
*** That was meant to be only semi-humorous. Users do expect polish from shrinkwrapped software. Whether they receive it is another story....
Technorati Tags
Topics: Ajax Development, Usability, User Experience
Cognitive Load, Portability and the Superiority of Client-Side Frameworks
The recent introduction of TrimPath Junction got me to thinking about Dietrich's widely read post on Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks. GWT's big advantage is that it mobilizes armies of Java programmers to write browser-based applications without having to learn JavaScript. This is clearly of enormous benefit to organizations with lots of Java programmers, few client-side resources, and a burning desire to build powerful webapps. Yet for the similarly huge army of client-side programmers out there, GWT is pretty useless. Why learn a foreign language just to have it translated back into your native tongue?
I haven't yet had a chance to play with TrimPath Junction, but it sounds pretty cool. Using the open-source Helma framework, it offers Rails-style MVC scaffolding in a JavaScript syntax that executes the same code on the client and server. Basically, it's RoR meets Adobe AIR for JavaScript programmers. I hope to give it a test drive soon.
Server-side JavaScript has been around for ages, but it's never really become a common development model. I remember writing ASP Classic apps in server-side JScript back at the turn of the millennium and having people wig out on me. "Why not write in VBScript like everyone else," they'd ask. My answer: "Because I can save time by running the same validation libraries on the client and the server ... and because I can write the entire app in one language." I obviously have no argument with Dietrich's thesis on cognitive load. It's just that my brain features a JavaScript compiler, not a Java one.
GWT is a great piece of engineering that keeps getting better; just check out the new non-beta 1.4 release. But I think there are a lot of advantages to frameworks that mobilize the JavaScript masses to write front-to-back webapps. The same cognitive efficiencies can be achieved, plus client-side programmers already know all the pieces of the UI puzzle. Ask a room of Java developers how to build accessibility and usability into standards-compliant XHTML and CSS. Nine out of 10 wouldn't have a clue.
The other big advantage to developing UI code in its native language is that you can port it to any server platform. With GWT and similar frameworks, you've got to rebuild much of your UI from scratch if you want to change course in mid-stream. With purely client-side frameworks such as Prototype, jQuery, YUI or MooTools, switching libraries may entail rewiring some of your code to a new API. But switching server platforms, from J2EE to .Net to PHP to RoR, can be done without much work at the UI layer. "The right tool for the right job" is a truism for a reason. Pure client-side development of UI code allows for the development of reusable components whose only dependency is on the standards bodies and browser vendors who control JS, CSS and HTML. GWT and its peers are useful for some teams and some projects, but they're not the only answer to webapp development.
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