- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Artifacts of a Presentation
We had an company brown-bag lunch the other day, presenting a case study of one of our Agile projects where UXD and Development are integrated into one, big happy family. It was a great talk, explaining how UXD fits in with the Agile process and highlighting the bumps, expectations and jargon differences all members had to overcome in order to meld as a team. Discussion was generated throughout the lunch, and we all agreed that we’d like to continue the talk at another brown-bag. Good feelings all around.
A pity that the dynamic of the talk wasn't captured on the slides. As we’ve all seen on a million other presentations, the slides displayed a bulleted list of talking points. Very high level and maybe effective during the presentation but loses all effectiveness after the fact. Unless you were an attendee, reading the bullet points afterwards will only give you the vaguest idea of the topic and probably won’t even hold your interest long enough to finish viewing all the slides.
And yet, think about it -- this file is the artifact that lives on as a representation of the talk. It should be strong enough to be used as a marketing piece; or a blog posting; or the foundation of future talks. Which means it should be able to stand on its own and be meaningful to readers who never attended the original presentation.
Joe Walker/DWR Webinar
Joe Walker of DWR fame is giving a Tibco sponsored Webinar on July 19th entitled DWR "Reverse Ajax": Breaking the Web's Request-Response Barrier. For those of you who like to not just read about new technologies, but also hear, check it out. Requires registration.
Topics: Ajax Frameworks, Announcement
Plug: Integrating Agile and UXD
FYI, my company has just released a whitepaper on integrating Agile Development and UXD (User Experience Design), a subject of great interest to anyone developing Ajax/Web 2.0 apps. As the complexity and sophistication of our webapps increase, we have to rise to the challenge of making them easy to use. The whitepaper is an overview of some of the best practices and ideas from our own experiences of bringing our UXD and Agile Appdev practices together. Warning: the paper is free but requires registration (i.e. an email). So, if you are easily annoyed by this sort of thing, you probably don't want to click on the link above.
Topics: Announcement, Best Practices, User Experience
Agile Practices and Ajax Toolkits
I've been practicing agile development in one form or another through my involvement with open source projects since the early 90's. Of course at the time, we didn't know we were practicing Agile development. We were distributed, we had real jobs, we were pressed for time. Often we compensated by eyeballing requirements, having rapid releases, and evolving the SW over time as new needs and requirements were discovered. Now many of those shortcuts that grew out of necessity are at the core of Agile.
In all that time, I've developed my own philosophy (when you turn 40, your "opinions" turn into a "philosophy") on how Agile development should be done. There are a number of core principles I adhere to:
- Short iterations. Thirty days is a nice number.
- Pair programming (not necessarily the one keyboard, one mouse variety). Yes, two developers working on the same tasks do get more done than the same developers working on separate tasks. The practice also really boosts quality and learning.
- Test Driven Development. If you've ever worked on projects that don't have extensive unit and integration tests, then you've experienced the waves of bugs that appear with every new feature or enhancement. TDD -- rather than after the fact unit test development -- is also the only way to guarantee that the practice doesn't slip during stressful times.
- Continuous integration. Hourly is good enough. If you've worked on projects without CI, then you've felt the pain of week long "build and deployment" sessions, driven by the poor sods condemned to being the "build masters."
- Self organizing teams practicing continuous improvement through process reviews.
Everything else is negotiable, as far as I'm concerned. Through #5, each team will find the right agile methods and practices for themselves and the client. No single method (note, "methodology" is the study of methods) is appropriate for all situations and teams. I myself favor Scrum as a wrapper around the development process, as it incorporates #5 as a core principle.
Turning now with these Agile principles to the world of Ajax frameworks, which of them explicitly incorporate unit testing into their development? This is an important consideration, since if a framework doesn't provide unit testing facilities or hooks, you will have to develop and maintain them in step with the framework. As an example, with full unit test coverage (branch and line) in place, you can weather the release of new browser version (think IE7 and Safari for Windows) much more easily. Not only will you know that your sophisticated Ajax interface doesn't work, but you will know exactly why it doesn't work (probably).
So, which frameworks do incorporate unit tests, and how easy do they make it to hook those into your own development machinery?
- GWT, of course, lets you use JUnit directly.
- Prototype and Scriptaculous both use the same unit test harness, which already comes integrated with Rake (Ruby make), but would take a little work to integrate with other build environments.
- JQuery does have unit tests that can be run with make or ant, but they aren't extensively documented, so extending them to your own development environment will require a bit of work.
- Of the straight Javascript frameworks, Dojo has the best documented unit testing approach, as well as a build process that can be integrated into your build environment.
(BTW, has anyone else noticed that YUI doesn't have a publicly available SVN?)
The one tricky bit with testing Javascript is that object definition and creation can be pretty complex code itself. Ideally it should be tested as well, though that doesn't always happen in the above frameworks. Whatever framework you choose, make sure that it provides unit testing facilities that your developers can and will use, otherwise your user interface will be the redheaded stepchild of your web 2.0 webapp.
Technorati Tags: ajax, agile development, unit testing, test driven development
Microsoft’s Inductive User Interface
MSDN (the Microsoft Developers Network) has a short introduction to a relatively new trend in the way Microsoft thinks about Interface Design.
Inductive User Interface (IUI for short) is a term that describes the collection of methods and guidelines for designing interfaces that, according to Microsoft, are easier to follow than the current generation of software products are.
According to Microsoft, IUI gained traction as a design process as a result of the research they’ve done on actual users performing tasks on their products. In short, they found that a number of important assumptions that are commonly made by User Experience practitioners are incorrect. They found that, contrary to the commonly held notion, most users are unable to successfully perform even basic computer tasks. The article stated 3 key reasons as to why they have concluded that software is hard to use:
- User’s don’t understand the software’s conceptual model. From the original article:
“The interface design for most current software products assumes that users will understand a conceptual model that the designers carefully crafted. Unfortunately, most users don't seem to ever acquire a mental model that is thorough and accurate enough to guide their navigation. These users aren't dumb — they are just very busy and overloaded with information. They do not have the time, energy, or desire to wonder about a conceptual model for their software.”
- Even expert users never master common interface tasks. From the original article:
Designers know that new users may have trouble at first, but expect these problems to vanish as users learn common tasks. Usability data indicates this often doesn't happen. In one study, researchers set up automated equipment to videotape users at home. The tapes showed that users focusing on the task at hand do not necessarily notice the procedure they are following and do not learn from the experience. The next time users perform the same operation; they may stumble through it in exactly the same way.
- Every piece of functionality on a screen takes effort to figure out how to use. From the article:
Most software products are designed for (the few) users who understand its conceptual model and have mastered common procedures. For the majority of customers, each feature or procedure is a frustrating, unwanted puzzle. Users might assume these puzzles are an unavoidable cost of using computers, but they would certainly be happier without this burden.
Most current software GUI’s aren’t addressing these problems. Instead, assuming the user’s (1) are familiar with standard Interface controls (2) have the time or the desire to learn the software’s conceptual model (3) Are willing to put up with a steep learning curve for additional functionality rather than use a more basic, yet simpler product.
As a result is what Microsoft calls the Deductive User Interface (see image). An Inductive User Interface is one whose screens require the user to figure out what can be done, and how to do it. The more time spent trying to figure out what can be done, the less energy and patience the user has left to actually perform them.
Microsoft’s solution is to design interfaces that induce, or lead, the user through one task at a time. As such, the computer screen should act not unlike an expert standing over the user’s shoulder, directing them through one screen at a time. The four essential ingredients to designing an IUI are:
1. Focus each screen on a single task.
Don’t try to accommodate multiple distinct and possibly unrelated tasks onto one screen. This will potentially overwhelm the typical user, in order to satisfy the expert, or speed user.
2. State the task.
Part of identifying a task, is stating it, clearly. This sounds elementary, but there is actually a lot of literature on the advantages of compact, even terse language in interface design. IUI screen title should use natural language and state the exact task at hand, using verb / object phrases. The example Microsoft gives in the article is from it’s redesign of Microsoft Money: One of the original screen title’s was this too general “Account Details”, whereas the redesigned screen title was “Change account setup”—much clearer.
3. Make the screen's contents suit the task.
Once users have read the screen title they will proceed directly below, to the contents of the screen, IUI’s make that transition effortless, as the tasks associated with the screen are intuitive and natural, corresponding directly with the title (or primary task).
4. Offer links to secondary tasks.
Unlike the Wizard, that ubiquitous and often controversial feature of many a Microsoft product, IUI’s aren’t meant to be modal, and according to Microsoft, aren’t intended to impede the expert user. Adding links to secondary tasks allows the user some flexibility in the way he/she goes about performing their tasks.
Criticisms:
The web is full of interfaces that exhibit many of these same characteristics for a few reasons:
- Relatively slow reaction times as commands are frequently sent over the internet and processed remotely
- Products need simple interfaces so as to flatten learning curves, to thwart the relatively quick abandonment resulting from the democratic, highly competitive nature of the web
Microsoft calls the IUI design process an extension of the Web –Style Interface, and a few bloggers have commented that there isn’t really much new here. Just a rehashing of tried and true design practices applied to the desktop model.
Additionally, there has been much discussion in the blogshpere on the relative merits and disadvantages of IUI. Most comments have lamented IUI’s similarities with Wizards, which have been rightly blamed for dumbing down the population of computer users by unnecessarily shielding them from any complexity, and preventing them from learning.
What is Role of an IA?
I was recently asked what the difference was between a BA and an IA. The person asking mentioned that a BA can end up doing wireframes and an IA will at times write business requirements, so how do they differ.
While the skills may overlap, I think the difference arises in the point of view each bring to a project. The BA tends to be more business focused, sussing out the needs and requirements of the business. The IA tends to be more user focused, championing their needs and desires. (Yes, this is overly broad but let's go with it for now.) That doesn't mean that BAs don’t "get" user-centric design or that IAs can't write business requirements. However, while we may have overlapping skills, I think where we diverge is more in our focus than our skills.
It's this divergence of focus, in fact, that brings a richer element to a project team. In an ideal world, well-designed software will meet the business needs, the user needs and the technical needs. To achieve this ideal world, a project team needs members who can understand and balance the needs of all three and still meet the release date. Rarely can one person fill all three roles since they are usually not an expert in the world each role represents. It’s the understanding of the nuances of that space that enriches a project.
We’ve recently started a BA/IA collaborative group at Pathfinder -- an informal group that'll meet, discuss successes, frustrations, etc., and hopefully come away with a better understanding of the strengths we each bring to a project. I'll let you know how it goes.
Topics: Information Architecture
Beefing Against OpenLaszlo
Elliotte Rusty Harold is a well know author on Java and XML. His take on OpenLaszlo is that it is a misuse of XML.
OpenLaszlo seems like a confusing mix of JavaScript and XML. I never got clear on just why there was so much XML. It seemed like a classic case of misusing XML because it’s there. I suspect JavaScript alone wasn’t strongly typed enough, and the developers didn’t want to bother writing a parser for a custom format. GWT, by contrast, is pure Java so it’s a lot cleaner. I like XML; I like Java; and if I’ve taken enough drugs, sometimes I even like JavaScript. However mixing them together in the same program just seems like a really bad idea. It’s like constantly switching from English to Chinese and back again in the same sentences.
I've got to agree that the mixing of XML and Java/Javascript seems like a bad idea. As I observed in Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks:
But why do we get a headache? Back in the 1950's, a professor of Psychology named George Miller observed that the average human being could retain seven items in short term memory, plus or minus two items. When we work with ideas or concept in any sort of analytical thinking, we run up against this limitation again and again.
John Sweller, a professor of Education, came up with the idea of cognitive load in the late 1980's. The basic idea was that your ability to learn and problem solve was limited by your short term memory. If a particular learning task required keeping track of many concept at the same time, it is said to have a high cognitive load and as a result you don't learn as well or as easily. In fact, in analytical tasks like doing complex arithmetic, it can increase the rate at which you make errors. There's a whole body of literature on cognitive load, cognitive stress, etc. Applied to our example of web application development, we see that juggling all of those different concepts in different programming and markup languages and runtime environments in our head, creates a high cognitive load, increases our error rate and impedes our ability to problem solve.
The same criticism could be made of ZK, with it's ZUML that mixes XML and Java (or other languages). I'm still OK with using XML to wire up components, such as Spring and SwiXML, as these are minimal and have a configuration purpose.
Technorati Tags: ajax, openlaszlo, gwt, xml
Topics: Ajax Frameworks, XML, ZK
GWT with JSONP
I've been looking to add to my JSONP series with some examples using GWT. Dan Morrill over at Google has beaten me to the punch with an article on just this subject. The code for it is rather straightforward, but there are a few sticky bits that make it a little less so:
I spent quite a while debugging this, until I finally asked Scott Blum, a GWT Engineer. Scott merely asked a question: "Was the array created in the same window in which you're testing it?"
What Scott knew that I did not, is that the JavaScript classes (like Array) corresponding to the primitive types are constructed along with the window object. Because JavaScript is a prototype-oriented language, the "classes" are really just object instances with special names. These two issues combine to reveal a subtle but important issue: the Array objects from two different windows are not the same object! The expression "x instanceof y" in JavaScript boils down to something like this pseudocode: "if the 'prototype' property of 'x' is the same object as 'y', return true, else return false".
At this point, you may be wondering how multiple windows entered the discussion. The key is the
$wndvariable, which points to the hidden iframe in which the application's GWT code is loaded. The DOM object in GWT, however, points to the parent window'sdocumentobject; after all, your application code is interested in manipulating the browser window, not GWT's hidden iframe. As a result, in the code above, the<script>tag is added to the parent window, while the code using it resides in a different iframe. This means that the object is created in a window different from where the "instanceof" checks are made, thus causing the issue above.
The solution Dan chose was to add the <script> tag to the iframe that contains the GWT code.
Of course the new "cross site" compilation option produces code that loads directly into the main page, so this hack may not in fact be necessary.
Visual Design as a Balancing Act
Visual Design for software can sometimes be a balancing act. Successful visual design requires both a close relationship with developers, and the foresight to know when to pull back and be a proper user’s advocate.
The Visual Designer should maintain a close relationship with development for a few reasons. First, the role of the visual designer is to ultimately deliver production ready screen comps to the developer. It is essential to have intimate knowledge of the technologies behind the implementation, so that those comps can be reproduced in code. In addition, realistically, the Visual Design, and Implementation phases will overlap significantly, and the designers and developers have to work together to solve UI challenges that weren’t uncovered in previous phases of the project. In such instances, inevitably design decisions will have to be made on the fly, and the informed and aware designer will be better prepared to make good design decisions in that environment.
Yet, it is also important that the relationship not be deleterious to the ultimate goal—building a product that works for the user. By definition, development’s concern must be with technology—defining and configuring the tools that access, process, and render data. Designers must be aware of the technology, but focus primarily on the user experience. More succinctly, development must focus on how, while design must focus on what. Getting to involved on the development side of the equation, the tendency will be to start focusing on the how more than the what. That’s when designers must pull back, and realize where their role should be.
Progress on GWTaculous
Just for those scoring at home, I've moved GWTaculous, my effort to rewrite Scriptaculous in GWT, over to GWT 1.4. I've also gotten Fade working on IE6. Sorry, nothing to see yet, but hopefully next week I'll have time to put up a side-by-side demo of GWTaculous and Scriptaculous.
All of that being said, performance is fine in Firefox, Safari, Opera and IE7, but somewhat uneven in IE6. My suspicion is that the iterator I'm using may be too fat for the effects queue loop.
Iterator it = queue.iterator(); long now = System.currentTimeMillis(); while (it.hasNext()) { EffectHooks effect = (EffectHooks) it.next(); if (effect.isDone()) { it.remove(); } else { effect.loop(now); } } // since we may have removed some effects, we should check to see if our queue is empty if (queue.size() == 0) { stopTimer(); }
I'll do a little bit of profiling, but since IE6 is on it's way out, I'm wondering if I should really worry about it. Premature optimization is the root of all evil.
Technorati Tags: ajax, gwt, scriptaculous, gwtaculous
Topics: Ajax Frameworks, GWT
SEO and Unobtrusive Javascript
There's a short article over at softwaredeveloper.com on incorporating the Ajax without breaking your Google friendliness. They have a few concrete tips:
- Design your site with degradable AJAX, that way users with JavaScript disabled can view a working version of your website along with JavaScript enabled visitors.
- After you've established a non-AJAX working version of your website, go back and include an alternative AJAX enhancements where you desire.
- When designing, make sure to check your website with JavaScript disabled as well as through the eyes of a text only browser such as Lynx or SEO-Browser.
- Perform a browser check to make sure the user has JavaScript enabled, that way you're only serving AJAX pages to users that can view them.
Useful stuff, though you may want to check out this book for the nitty-gritty on unobtrusive Javascript.
The best link from the article is this presentation, which is itself and excellent example of unobtrusive Javascript.
Technorati Tags: ajax, unobtrusive javascript, google, search, SEO
Topics: Ajax Development, Google, Javascript
What can you do on this site? Well…
3 big questions all web designers should be familiar with:
Where am I? What can I do here? Where else can I go?
Web designers should design sites that answer those questions for visitors. But it’s easier said than done, and as a result, it’s unfortunately all to often that many large web sites are more like forests than cities.
Surfing the web, looking for web design blogs, I stumbled upon something so simple and yet so effective in dealing with this problem; a gem of an item on the About Us page of a Graphic Design tutorial site (http://www.graphic-design.com/about.html ). It’s an overview of the things that you can do on the web site, in bullet points, and with the action verbs linking to the respective pages. 
Now the site itself is not all that impressive, from a design or an architecture standpoint. There’s a whole lot of information available, but it’s hard to find your way around…in other words, it’s easy to get lost. Which is perhaps the reason this overview of the site was included.
It does an excellent job of communicating what the site has to offer. It is succinct, but not terse, and it talks to me, telling me what I can do there, rather than what one might do. This goes a long way towards making me feel comfortable in the environment.
The web has come so far, technologically speaking, since I’ve been browsing, but it’s nice to see that the simple things can still have great impact. There’s no Ajax, or DHTML here; no draggable elements, or expanding/collapsing drawers; no semi transparent floating divs, or animating elements. It’s just a plain old static HTML list, thought out, and done right. And it accomplishes everything it sets out to do.
Google Gears Security Thoughts
The new Google Gears comes with a long set of security warnings and disclaimers. Nitesh Dhanjani over at O'Reilly's ONLamp.com had some initial thoughts about the security of Google Gears:
If I had to pick ..., I’d guess that we are most likely to hear of existing XSS or browser vulnerabilities being abused to steal (or manipulate) Gears databases.
I agree with Nitesh: the attack vectors will remain the same, but the consequences will be much greater. Some folks, such as those working on the Dojo framework, are addressing some of the offline storage issues with encryption:
Right now Dojo offline adds a DES encryption library with functions to encrypt and decrypt. The example used encrypting/decrypting SSNs. He also pointed out that doing this in javascript can be computationally intensive and hasn’t been that feasible before. Right now though using Google Gears worker threads they can encrypt/decrypt in javascript at about 80k/second.
You could also roll your own from this implementation of AES, RC4, RSA and a number of other algorithms. While this approach solves the stolen laptop problem, it doesn't solve the XSS problem, i.e. as long as you can inject Javacript into a page, you can bypass this security. After all, the plain text has to pass through the sandbox, where it is fair game. In this case, Google Gears just papers over the shortcomings of browsers.
It is possible that WorkerPool could be used to limit the kinds of modifications that are made to the encrypted data:
The WorkerPool behaves like a collection of processes, rather than threads. Workers do not share any execution state. Changing a variable in one worker has no effect in any other worker. And created workers do not automatically inherit script code from their parents.
Members of a WorkerPool interact with each other only by sending message strings. Workers can also pass richer data types, by first converting objects to strings using JSON.
We can hide the encryption details in a WorkerPool member and communicate with it via messages. We still pass plain text data through the main browser execution context, but we can at least regulate the access to the encrypted database -- i.e. no bulk downloads or modification.
As a final thought, what's bad for ActiveX is also bad for Google Gears. The fact that the project is open source and thus not a black box, mitigates this criticism only somewhat. To make me comfortable with Google Gears, all of the XSS volnerabilities will have to be closed first.
Technorati Tags: ajax, google gears, security, dojo, encryption
Topics: Ajax Frameworks, BJAX, Dojo, Google, Security
Agile Usability Testing
Even in waterfall-based design and development projects, formal usability testing at the time the system is being finalized is essentially “too much, too late”: a time-consuming, labor-intensive activity yielding results that are frequently unactionable for the current release. Several iterative assessment techniques, however, can be employed throughout any process, providing timely insight and direction. These techniques are readily adaptable to the Agile methodology, and, with some minor adaptations, can in fact be regarded as “agile” usability testing methods. Low-fidelity testing, using paper prototypes (or even hand sketches) can provide a quick benchmarking, and can be incorporated into a scrum meeting.
Why is usability testing important in the Agile environment?
A crucial component of the Agile methodology is the practice of obtaining customer feedback after every iteration and then making functional changes accordingly. Introducing usability assessments at key points in the process can ensure that the users’ requirements will also be recognized and accommodated within the development process, at a point when any potentially off-course decisions can be corrected and improvements implemented.
The nature of Agile development is to focus on individual features and although the project “epic” attempts to preserve the big picture for the product, this view is nevertheless focused on the functional and business requirements, rather than on the holistic user experience. Usability testing can document and validate issues that may only be the opinions of the team.
Cooee - Branch of Echo2 Project
I've thought for a while now that Echo2 wasn't really working as an Open Source project; I even have a couple of posts laying out some of the reasons that Echo2 was in danger of losing out to other, inferior frameworks all for a lack of organization and activity. Ultimately I didn't post them because I didn't want to undercut what I considered to be an otherwise excellent framework. But it's not surprising that someone else has felt the same way and taken action to rectify the situation.
Cooee, a fork of the Echo2 project, aims to make community participation much easier. From the FAQ:
What we're doing is trying to provide a much more open environment to stimulate the growth and acceptance of Echo2 / Cooee. We've spent a lot of time making sure that everything that happens as part of the Cooee project can directly benefit the work of Nextapp and other projects like EchoPointNG. For instance, all changes to the code base are tracked through JIRA, and marked appropriately in the commit comments. This means applying the changes / fixes we make back to Echo / EchoPointNG are exceptionally easy. To put it simply - we want to work with Echo and maintain as much API compatibility as possible. Not work against it.
The project has all the usual Open Source fixings: JIRA (bug reports), Confluence (wiki), Bamboo (continuous integration), forum, and Fisheye. It consolidates the several different jar files of Echo2, Extras and EchopointNG into a single jar file. A few other Echo2 related projects are also maintained on the site. It's early days yet, so the project doesn't seem to have a lot of momentum, but from the public roadmap to JIRA, they seem to be doing a few things right. Ultimately their success will depend on their ability to recruit other developers. The same is true, by the way, for the main Echo2 project.
Open source forks are not always a good thing. Sometimes an already small community gets split so far that the projects die of neglect. Of course Echo2 has been so moribund for the last few months that I think this particular fork is a good thing. The folks from NextApp seem to have gotten a kick in the pants as a result of this development. I've never seen them this engaged in the forum.
Let the competition begin.
Topics: Ajax Frameworks, Echo2, Open Source
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