Archives

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.

Share/Bookmark

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.

Technorati Tags: dwr, webinar

Share/Bookmark

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.

Technorati Tags: UXD, agile

Share/Bookmark

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:

1. Short iterations. Thirty days is a nice number.
2. 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.
3. 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.
4. 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."
5. 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?

1. GWT, of course, lets you use JUnit directly.
2. 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.
3. 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.
4. 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

Share/Bookmark

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.

Share/Bookmark

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.

Share/Bookmark

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

Share/Bookmark

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 $wnd variable, 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’s document object; 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.

Technorati Tags: ajax, gwt, jsonp

Share/Bookmark

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.      

Share/Bookmark

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

Share/Bookmark