- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Not-So-Great Expectations
Joel Spolsky, at Joel on Software, had a provocative post earlier this month, entitled "Usability in One Easy Step (First Draft)."
Here's an extract:
So, usability. That's really at the heart of good design, and I'm going to spend a lot of time on it.
The good news is that I can teach you everything I know about usability while standing on one foot. Ready? Here we go:
Something is usable if it behaves exactly as expected.
That's it! That's the whole story! As Hillel said, all the rest is commentary.
One foot, ladies and gentleman! The other, we presume, is aimed squarely at the collective posteriors of UXD practitioners everywhere, with their techniques and theories and methodologies and other varieties of snake oil.
It's a truism that "making things easy is hard." Spolsky's Principle (First Draft) strikes me as being simultaneously concise, self-evident and facile. His use of the passive voice is revealing:
". . . if it behaves exactly as expected."
Expected by whom? Under which conditions? Spolsky makes an easy argument by dividing the world into two groups (Mac and PC users), whose expectations have been created and honed by software developers with extreme--documentable--precision. But how many real-world cases are this clear-cut? User expectations often come in more than two flavors.
User-centered design has developed various methods for discovering and confirming user expectations throughout the design process, from research on best practices through full-blown usability testing. Indeed, a classic probe incorporated into usability walkthroughs (and one I use heavily) is the repeated question "Is this what you expected to see/happen?"
It can take a lot of skill, time, and effort to gather and synthesize user data, and then determine the most effective way to apply the knowledge to the design. And what happens in the (all-too-frequent) instances in which there are no expectations?
Looking forward to Spolsky's Second Draft. Hopefully, he'll have both feet on the ground next time.
Topics: Design, Ethnographic Research, Personas, Usability, User Experience
ASP.NET Ajax Reviews
Daniel Zeiss has put together the and excellent review of Ajax frameworks for ASP.NET. He narrowed down his selection of frameworks as follows
First, let me explain why only these 11 Frameworks are included although there is a lot more AJAX stuff for ASP.NET out there. All the frameworks listed here have one unique AJAX feature: They allow updating page content without programming AJAX directly - i call it indirect AJAX programming - a comparable concept is called Hijax. To make it concrete: Direct AJAX programming would mean dealing with client scripts, DHTML, method proxies, client side rendering and so on... Another important property the framework must have is the ability to support non-AJAX controls and enhance them with AJAX features. Therefore, frameworks that supply only controls with built in AJAX-features (Buttons, Trees, Grids, Lists and so on...) are not included in the comparison.
He has done extensive work in road testing and comparing. Well worth a look.
Topics: Ajax Frameworks, ASP.NET, Frameworks, Review
Thoughtful gesture? Peter Coffee’s column misses the point.
As I leafed through my ever growing stack of tech magazines
yesterday, a column in eWeek by Peter Coffee, entitled Thoughtful gestures
– don’t make complexity elegant; make it disappear caught my eye.
Mr. Coffee was writing about a patent
application from Apple for processing multipoint gestures on a touch input
device. The language of patent applications is notoriously dense and jargon laden, so in laymans terms, this is about making it easier to interpret what a user wants when they touch a screen or touch pad at multiple points at the same time. Some simple examples of multipoint gestures include squeezing, stretching or twisting motions while touching a screen with your finger tips.
Mr. Coffee's contention is that this invention is a way of making
more complex tasks easier to perform, that it has no real-world, practical application, and that this is the wrong problem for
inventors to tackle. He states
that “I’d rather see interface efforts based on watching what
users do, understanding common needs and designing systems in which those
actions are simple. Making complexity elegant is an achievement, but I'd rather
just make that complexity invisible.”
This is a fine sentiment, and a good one-sentence
description of user experience design, but he really misses the point of how
new input device inventions relate to user-experience design.
He illustrates the uselessness of gestural interfaces by describing
two ways of saving a users work – one using a whole series of convoluted
gestures that makes the user look like she’s doing the Macarena, and a simple,
elegant way of using keyboard strokes. Boy, based on that example, gestural interface sure sounds like a bad
idea, and inventors should stick to improving how to use existing input
devices.
The trouble with this example is that the same argument was
made about the mouse when it joined the keyboard as an interface device. There were (and are) many things that are
easier to do with a keyboard than with a mouse – saving a file using shortcuts,
typing a letter, entering data in a spreadsheet, just to name a few. Does that make the mouse useless? Why use something as complicated as a
mouse?
Let’s take the case of a user putting together a process
diagram in Visio. Using a keyboard
interface, a user can perform a lot of complicated keyboard strokes to
generate, place, link and annotate the diagram elements. Meanwhile, back in the real world (as Mr.
Coffee would say) the user simply drags and drops the elements in place using
his mouse, touch pad or pointer.
Clearly, different interfaces are good for different types
of actions, and it’s up to the user experience designer to apply the
appropriate combination of available interfaces in a way that lets the user
simplify and streamline their interactions.
So where might using a multipoint gesture interface simplify
a current, real world interaction? How
about Google Maps: Multipoint gestures such as squeezing,
stretching or turning, combined with single point gestures like dragging, could
make navigation significantly simpler and faster than the current mouse-based approach.
The point of inventions like this is not to make more
complex acts achievable, but what things can be simplified using these
inventions. Almost all ways in which we
interface with computers are pretty complex. For example, learning to use a keyboard is a lot more complex and time
consuming than learning to use a mouse, and learning to navigate using keyboard
shortcuts requires much more familiarity with an application than using a
mouse. Gestural interfaces need be no
more complex than keyboard or mouse interfaces.
So inventors, keep inventing! Between user experience designers, developers and usere, we'll take the best inventions to make things genuinely simple.
Requirements Visualization, V1
At Pathfinder, we have developed some responses born of our collective experiences to the problem of huge requirements documents.
The problem is that on a complex project, a network of interdependent decisions is constructed, then shoehorned into an essentially linear document. While this functions as a form to analyze these problems, it's very [linear] nature makes it... well, boring! Even developers and designers are human!
The functional result is that it ends up as a doorstop somewhere in the office, or finds a quiet angle of repose near a bookshelf and no one ever reads it. These typically represent months of work by large, passionate teams and great expenditures. Not an ideal outcome.
What can prevent this? With all our focus on our favorite personas, and the scenarios we construct to walk them through, it is easy to forget that the person who was just handed 150 pages of your careful work is arguably your most important audience.
Take a moment and review that the order of the parts feels obvious. Make sure that the document has a clear and accessible structure. This means a contents page with content areas that have immediately understandable names. Even though it may seem unnecessary to you, having spent the last 4 months on it, a general overview that orients a first time reader is appreciated. This sets them up for the detailed decisions that follow. Starting someone in the middle of these processes, as I too often see, tends to make people glaze over and just make it up as they go.
Comprehension is more important than brevity here - at PFA, we find that annotated pictures are far more specific & engaging than trying to describe with only text things that can be easily shown. If that adds pages to the document, it is a small price if it gets read and understood. These visualizations do not need to be elaborate. In fact, we are facile at understanding abstracted representations - look at the drawing languages of cartoons. The messages are clear, despite the fact that Mickey has only three fingers or Charlie Brown has a single squiggle that stands for hair.
In sum, showing what you intend is powerful, yet doesn't need to be elaborate in production. The other side of the coin is to spend endless amounts of time illustrating a solution at the expense of more iterations, but that's another blog.
Topics: Personas, Requirements, Requirements Visualization, Scenarios
What the Commodore 64 can Teach Us About Ajax
Here's just a little sampling of articles from the November 1983 issue of COMPUTE!'s Gazette.
- Computer Graphics - The Age Of Electronic Art
- VIC Super Expander Graphics64
- Introduction To Custom Characters For VIC And 64
- VICreations: Animating With Custom Characters
It seems every issue would have at least two articles on how to twiddle the graphical bits on the C64 or VIC-20, articles on how to make sprites dance across the screen or writing your own video game or drawing program in 6502 assembler. You had similar articles in similar magazines with the introduction of the IBM PC.
With the advent of the Mac (yes, yes, Xerox did it first), all that bit twiddling disappeared. People started wondering more about how to get windows and menus and buttons to do what they wanted them to do, or even to start developing their own controls.
Fast forward almost 23 years and read just about any blog or magazine that features Ajax articles. The articles are almost universally about nuts and bolts, nitty-gritty details, i.e.:
- Writing a server-side Ajax handler
- Creating souped up popup windows with Javascript
- Implementing fancy form controls in Javascript
- Understanding the DOM
It's bit twiddling all over again. Perhaps it's time to write an article on how to do Sprite animation with Javascript.
Learning Complex Domains for User Experience Design (UXD) Projects
Legend has it the famous advertising slogan “Two scoops of raisins in Kellogg’s Raisin Bran” was created by an energetic copywriter who literally dumped out the box of cereal on a table and scrutinized the content for inspiration. Moral of the story: As designers we have to know our product. But what do you do when your product involves biological science, electrical engineering or any other complex domain? Here’s a few suggestions for getting up to speed in a complex subject areas.
Speak the Language
First, you have to speak the language. Ask your subject expert to outline the top ten or fifteen words or expressions used on a daily basis by your users. Then have him or her define those words in terms that you can understand. Keep the number of words to ten or fifteen, and only the most important terms.
Key Scenarios
Next, identify the top five or so key scenarios your users do in a typical day. Each scenario should have a simple title and a set of steps. Remember, the goal initially isn’t to do user research, but just to get a feel for what people are doing. Try to cover the five scenarios in an hour or less. This will help your expert from getting too bogged down in details you won’t be able to digest yet.
Map the Scenarios
Once you have the key scenarios, arrange them in a hierarchy. Of course, it’s possible the scenarios are isolated tasks and don’t fit a hierarchy, which is fine. But usually a hierarchy of some kind applies. This hierarchy will become a context for understanding when your user does various things.
Construct a Day in the Life Narrative
To test your understanding of the domain, take the information you have gathered and construct a day in the life narrative of your user. In doing so, you will create a vehicle for refining your domain knowledge and a start to your more serious user research.
Two Hours or Less
No matter how complex the domain, make it your objective to get through the above tasks in 2 hours or less. By time limiting the exercise, you can keep your subject matter expert from straying into the details before you have the basics solidified.
DO NOT PRINT THIS FORM
A number of years ago I was part of a team that developed a workflow application for a company to replace a paper based process. The new workflow app was quite a success in testing and training, so we felt fairly optimistic about the rollout. On a Monday we stood in a bullpen area in the company's Manhattan headquarters and watched the application go live. One woman used the application to fill out a form and then, rather than hitting submit and sending it on its merry workflow way, printed it out and put it in her outbox.
I'm sure most people involved in systems development have experienced this sort of infuriating situation -- I've seen enough "DO NOT PRINT THIS FORM!!!" messages on the bottoms of pages to know I'm not alone. No matter how much testing and training is done, some people can't get their heads around a new way of doing things. They remind me of those stories of the industrial age, when new machines were introduced into traditional ways of doing things, often to comical results.
In order to avoid being stuck in the past like this, you have to remember why you do things in the first place and continually question if they are sensible or necessary. I remember when I started designing what now would be called web applications back in 1994 or so. Stateless searching and reporting was easy to do, but the major challenge came in chopping up your application into different "pages", retaining state across several page loads and dealing with the "Back" button, a sort of rogue "Undo" function that didn't play nice with the application design. You ended up doing lots of kludgy things that you wouldn't do in a GUI or command line application. You had to think differently in order to build successful web apps.
As I review the various web application frameworks, most of which have the page based concept at their core, I have an uneasy feeling that we're missing an opportunity to rethink how we build webapps. Isn't it time to discard the page model and go back to a component model that has been so successful and productive on the desktop? Imagine undo functions that don't depend on the "Back" button, Browser specific code that is concentrated in a few classes, powerful, rich client applications in a fraction of the code. Let's rethink and DO NOT PRINT THIS FORM.
Ajax and the “Back” button
Among the issues that the increasing ubiquity of Ajax on the web brings up is, where does that leave the "Back" button. Or, is the page metaphor still relevant, and if not, how soon before everyone knows it?
Essentially all worthwhile new technologies ask us to change our understanding of the domain they effect, and the compilation of techniques together known as Ajax have the potential to do just that. But it will take time, no doubt. There's still a lot of work to be done--both for developers and designers--before adoption becomes universal, and years more before the inevitable breakdown of the page metaphor. On the way, questions will need to be asked about where we as web app developers see our role in the transformation to "Web 2.0".
Shocking - Forrester Produces Shody Work
woolfel gets bent out of shape about an abstract by Forrester that states that InRule uses RETE for it's .NET based BRE when, in fact, they talk about a decision table based approach:
There's a slight chance that InRule is using Microsoft's BRE engine, but I would
think MS would require someone licensing the engine to state that fact clearly.
Since the InRule website doesn't, I suspect InRule doesn't use MS BRE and isn't
RETE.
From my conversations with the InRule guys, it seems that InRule is a hybrid that started out as decision table based but has started to incorporate RETE. That may seem to be a franken-engine, but isn't actually so far fetched when you think about the algorithms. I'm pretty certain that Microsoft's BRE has nothing to do with it, since I believe InRule predates the MS BRE.
Anyhow, I can't get quite as worked up about RETE vs anything else as woolfel can. Most real world applications of rule engines end up being so small in terms of numbers of rules and facts that the advantage of the RETE algorithm doesn't really show up. This is sort of like quicksort vs insertion sort. Yes, quicksort is O(n log n), and insertion sort is O(n^2), but insertion sort is just faster on average for small n.
BTW, does anyone know the the worst case time and space complexity for RETE? I've been able to locate a paper on the average case complexity for RETE, but nothing for the worst case.
Topics: Business Rules
Why Frameworks are Important
I've been beating the drum of component based GUI frameworks for Ajax for a while now. To understand why, I think it's useful to look at the evolution of the desktop GUI framework and understand what makes them so successful. Over at ACM's Queue publication, I came across an article that gives a nice overview of what an application framework does and the characteristics that make it successful. This following struck me as especially apropos with regard to most of the current Ajax frameworks.
A framework exhibits "inversion of control" at runtime
via callbacks. These callbacks invoke the hook methods of
application-defined components after the occurrence of an event, such as a mouse
click or data arriving on a network connection. When an event occurs, the framework
calls back to a virtual hook method in a preregistered application component,
which then performs application-defined processing in response to the event.
The hook methods in the components decouple the application software from the
reusable framework software, which allows each to change independently as long
as the interface signature and interaction protocols are not modified. Since
frameworks exhibit inversion of control, they can simplify application design
because the framework—rather than the application—runs the event
loop to detect events, demultiplex events to event handlers, and dispatch hook
methods on the handlers that process the events.
Inversion of Control, it's not just for Spring anymore. 
Seriously, though, how many of the current Ajax toolkits -- I'm not sure that with the exception of appfuse it's correct to call them application frameworks -- give you IoC? I'll be watching to see if they make the transition to frameworks and will give credit where credit is due.
Visualizing Rich Interactions in Paper Prototypes
Wireframes and paper prototypes work well in documenting the standard page metaphor of the Web, as the functionality of each screen can be captured in a single wireframe. Rich interactions, though, pose the challenge of expressing a series of states that may occur on a single screen.
As technologies like AJAX gain greater popularity, designers face the challenge of exploring and developing new and innovative visual vocabularies and flexible tools for capturing the microflows of rich interactivity.
At Pathfinder, we are drawing inspiration from the discipline of storyboarding, which is, of course, closely related to wireframing. Storyboards express ideas in a sequence of "key frames," showing only the minimum number of frames to convey the idea. The richness of storyboards comes not from just the individual pictures, but from the change from picture to picture. It's possible, then, to embed a miniature storyboard into a wireframe, thus illustrating the quality of the rich interaction.
A second technique is to create a visual taskflow representation to the system. In this format, all screens are miniaturized to capture both the linear and non-linear flows within individual screens and from screen to screen.
Our fellow practitioners are tackling this challenge as well. Bill Scott considers several strategies for creating interactive wireframes, including the PowerPoint clickthroughs, the development of quick and easy RIA toolkits, and standardized notations to indicate interaction effects in traditional, static wireframes. His personal technique involves the creation of storyboards in Visio, which he then animates. The strategy is detailed in his blog entry, "Interactive Wireframes: Documenting RIAs."
Topics: Ajax, Prototyping, Rich Interactions, Wireframes
Ajax AIM Client
I know this is old news, but for those not scouring the web for what can be done with Ajax, check out this instant messaging client. It definitely pushes the boundaries of what can be done with rich clients. If you can do IM, the most interactive and instantaneous of all of our desktop apps, what else is possible?
Topics: Ajax Examples, Ajax Tools, Review
Echo2 a Cult?
Paul Browne has nice little survey post over at O'Reilly about Ajax frameworks. All's cool until I stumble across the following:
Echo2 - Evolution of original Echo Framework, can run in any Servlet container.
Original has cult following, but doubt if it will become the number 1
web framework.
I hear you, Paul. I remember evaluating Echo1 a long while back and thinking to myself: "why would you want to build a web application the way you would a component based desktop GUI? The behavior is so different, the lack of control, layout, look and feel, etc., etc." My conclusion was that Echo1 was a nice design solution applied to the wrong problem.
Fast forward to today. I have DHTML, CSS, Javascript, XHR, etc. I have complete control over what shows up in the browser, anywhere, any time, anyhow. I've got people writing thousands of lines of rich client application code, business tier logic leaking into the browser, cat and dogs living together...you get the idea.
Now the Echo design solution makes plenty of sense. The simple report and forms beast of the early 90's has turned into a kind of GUI desktop. Now my reaction is "why wouldn't you want to write a rich client web app the way you would write a component based desktop GUI?" It's a proven design. Nobody twiddles the bits by hand anymore. And when the browser wars start up again, the standards start diverging, and your Ajax apps start breaking, then the problem starts resembling that of a cross platform GUI, i.e. isolating Ajax variations in browser specific peer classes, much like AWT.
You can easily imagine running the same application as a Swing desktop GUI or a browser embedded Flash app. That's if the design is right and makes use of what? That's right, browser or rendering layer specific peers.
Guess who has all that today? That's right, Echo2. Come on and drink the Kool-Aid.
Useful Guidelines for Ajax Developers
I came across a nice post by Greg Murray on recommendations for AJAX component writers. It's a summary of a larger document. I particularly liked this point:
Protect your serverside assets
Never put business logic or server-side access code in JavaScript.
Be careful for example when exposing
JSF method/value binding expressions like #{SomeBean.someMethod} or
classes/methods names to be invoked on the server as it exposes your
internal domain model and could be exploited. If you provide such a
mechanism make sure a JavaScript client can call only the
methods intended to be available to the client. Never put SQL
statements in JavaScript code. Always remember JavaScript code is
visible to the client with the click of a button.Always validate request parameters on the server regardless of whether the request originated from an AJAX client or not.
I see plenty of Ajax applications or enhancements being written that access a backend via simple CRUD messages, making it simple for an attacker to gain access to your persistence layer/database. I'd go a step further to say that you ought to treat DHTML/Javascript as just a rendering tier, keeping your display and validation logic and its interactions with the business tier (provided you're using the knee jerk n-tier design) on the server side.
Topics: Ajax Components, Best Practices, Web/Tech
Economist gets it Wrong
I'm straying a little from the subject of Ajax, but this article from the latest issue of the Economist has me a little steamed. I've long been a fan of the Economist and its smarter-than-you-on-the-one-hand-but-on-the-other-hand style. They often take contrary or unpopular views and give them a hearing. But when they get it wrong, they can really put their foot in it.
I've been working with the Internet for some time (1983) and had one of the first 100 web pages, and I've seen Open Source evolve over that time into something that threatens traditional business models. So I almost fell off my chair when I read this:
There are two doubts about its staying power. The first is how
innovative it can remain in the long run. Indeed, open source might
already have reached a self-limiting state, says Steven Weber, a
political scientist at the University of California at Berkeley, and
author of “The Success of Open Source” (Harvard University Press,
2004). “Linux is good at doing what other things already have done, but
more cheaply—but can it do anything new? Wikipedia is an assembly of
already-known knowledge,” he says.
Innovative? Do they not remember the World Wide Web? That's Open Source at its roots, baby! NCSA httpd was the first web server and was distributed with a BSD style license. Lynx, Cello and all the various early browsers were all open source. Sure, NCSA's Mosaic started to cloud the waters a little bit (was it commercial, open source, etc.?) and then along came Netscape and IE, but the roots are Open Source. One of the reasons that Apache is more popular than IIS is that it's been around longer and is the direct descendant of NCSA httpd, not because it just replicates what IIS already did.
One can make similar arguments about various web technologies, P2P, and even Ajax, but that was a huge oversight.
For an excellent historical look at the Internet and WWW, see The Living Internet.
There are other issues with the article (hey, everyone knows that sourceforge is the open source ghetto, but have they heard of codehaus?), but they make some good points as to the management of successful open source projects. They don't, however, put commercial software under the same microscope. From experience I can tell you that the quality of most commercial software -- with the exception of the core products of companies like Oracle -- is design illiterate to borderline fraudulent. I've rarely seen commercial code that is even close to the quality of even middling open source. I guess embarrassment is a strong motivator.
Update 1:
Michael at coldfusion was a little put off by the same quote by Steven Weber. He sites some of the innovations in browser technology provided by Firefox. Still, does anyone remember the days prior to the commercialization of the Internet? You didn't buy WWW software, you compiled it from source. Open source, baby!!
Update 2:
Glyn Moody picks the same nit on innovation.
But let's leave GNU/Linux aside, and consider what open source has
achieved elsewhere. Well, how about the Web for a start, whose
protocols and underlying software have been developed in a classic open
source fashion? Or what about programs like BIND (which runs the
Internet's name system), or Sendmail, the most popular email server
software, or maybe Apache, which is used by two-thirds of the
Internet's public Web sites?
Not maybe on Apache, which traces it roots directly from CERN and NCSA web servers, both open source (yeah, yeah, BSD style).
Topics: Open Source, Peer Creation, Web 2.0
About Pathfinder
Recent
- Faster JavaScript for Firefox 3.1 Thru JIT
- Implementing linked multiselects with jQuery, LiveQuery, and Low Pro: Part 2: First pass at the actual code
- I’m Cranky Because I’m Not Getting Enough REST
- Flex Gauge Component Example with source
- Plugging Some Cool Tools
- Implementing linked multiselects with jQuery, LiveQuery, and Low Pro: Part 1: Requirements and interaction design
- Many Varied Components, or… Multi Variable Complexity, or… Mainly Vanilla Coding
- Custom Flex 3 Lightweight Preloader with source code
- Mass Assigning Inheritance Column Values for ActiveRecord STI with Rails
- Working effectively as a team of one: Five tips for front-end developers on Agile teams
Archives
- 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
3d
3D GPS
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
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 Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CSS
Custom Flex Component
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
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
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