Archives

Instead of the typical hand-off of deliverables accompanied by a firm handshake and a heartfelt "good luck!", recent projects have us iteratively engaging with both the business stakeholders and the developers early on in our design process. Yes, we’ve gone agile and that’s not necessarily a bad thing.

Once a project has the green light, we begin by directly working with development in an iterative fashion, bringing them into our process and getting their input early on in the project lifecycle. First up, translating the initial requirements into visuals — defining actors, diagramming the user activities, task flows and personas. During this flurry of visuals, we’re presenting and discussing the diagrams, etc., with the team to determine that we’re on target and to get their input. From here, iterations of screen flows and wireframes are diagrammed and discussed with the developers to demonstrate how the presentation layer and user interaction are being envisioned, get their input, check that requirements are being met, that the back-end can support the design, etc., etc. Rinse and repeat.

Share/Bookmark

GWT 1.4 RC has been released. What’s new? Just a sample:

• Code generation is more efficient, maybe 10-20% smaller than in 1.3.
• Improved loading code lowers load times by a third.
• Lots of new widget enhancements, including the RichTextArea. Since a rich text editor seems to be a big requirement in lots of content managent apps, removing the need to drop in FCK or TinyMCE gets rid of a big debugging headache.
• ImageBundle does the whole image concatenation thing for you. Basically, you glue all of your images into one image, and use CSS to clip just the image you want. That way you only have to do one image load instead of a few dozen for a image-rich app. Here’s a post by one of the guys at Zimbra explaining what’s involved in more detailed.

I’m especially excited by the new deployment options:

• GWT RPC is no longer tied to exclusively to servlets. New modularized RPC server code makes it easy to connect GWT RPC to your choice of Java back-ends.
• Adding GWT modules to an HTML page has been simplified: just add a <script> tag. You no longer need to use <meta name=”‘gwt:module’”> and <script src=”gwt.js”>. Just reference your module and go.
• Cross-site script inclusion is now supported. The compiler produces a “-xs” (meaning “cross-site”) version of your module’s startup script that can be included without being restricted by the same-origin policy. Be careful, though. Including scripts from other sites that you don’t fully trust is a big security risk.

All of those issues I’ve had with GWT just got solved. No more trying to plunk around trying to figure out why your module isn’t loading in a different page on your site. or why it won’t load on a third-party site. Also, integrating GWT with existing backend services was a bit of a hack; now replacing an existing interface with GWT becomes more feasible.

Here’s hoping that all of the IDE folks, JetBrains, etc., update their GWT plugins soon to take advantage of the new features.

Technorati : ajax, gwt, java

Share/Bookmark

So what are the big boys doing? Are they using Dojo, Prototype, etc.? After another disappointing stroll through the top 100 sites (a few more uses of Scriptaculous, yawn), I discovered that Monster.com is in Beta with a spiffy new OpenLaszlo Job Search app. Unfortunately it uses Flash, not the new Ajax runtime, but I’m guessing they started development well before the release of 4.0. I’d be curious to know if they are considering a flashless version for the future.

Technorati : ajax, flash, monster.com, openlaszlo

Share/Bookmark

A running discussions I have with my mom revolves around a cellphone: I think she should have one; she disagrees. I say it makes sense to carry one in case of emergencies; she says her regular phone is good enough for her. I say her regular phone doesn’t work in the car; she states that you shouldn’t talk and drive. Her logic defies a response.

But what I think she really dislikes about cell phones is that they’re just too complicated to use. When my mom looks at my phone, her first question is, well how would I know how to use it?  A valid point. She is accustomed to a landline — you pick up the handset and there’s a dial tone (no, don’t even start — she has no cordless phones). Her phone has raised buttons, not a flat touchpad, and these buttons contain numbers, not icons. (I have to admit, I don’t blame her about the icons. I couldn’t even begin to describe the icon on my phone to pick up a call — it has no name. You have to train yourself as to its meaning.) What she really needs is a phone designed just for her.

Share/Bookmark

As you might expect, I have a suggestion or two. Firstly, I would confirm my standing as a heretic by questioning the hegemony of typography. Put five designers in front of lattes and the one thing they will all agree on with mumbled nods is the importance of Typography. Of course I would too, but this reflexive assent masks a larger problem in how design is practiced and taught.

The design profession has been so deeply fractured in the last 15 years typography has remained one of the few common links between this new multiplicity of practitioners.

Well, for better or worse, the aesthetics of desktop and browser based applications use type in extremely limited ways that are an intersection between common system installed fonts and informative hierarchies. And common system fonts, consider Arial, Impact and Papyrus for a moment, leave much to be desired. However this is the palette of many desktop and browser based applications.

Often the more complex issues in these engagements are how to assemble, change and order vast amounts of information. Designers bring a vastly different focus to these activities than most developers. The developer concentrates on a micro level of specific code interactions to construct a working system while a user experience designer connects the user to a much more general picture. Factors that might be involved include business problems, a users cognitive interest/abilities and the the capabilities of the developers systems.

There are user research activity models, interface and task modeling considerations that have little to do with what anyone would describe as sophisticated print typography. Yet notions of hierarchy and the effect of symbols and composition are elemental to forming easily navigated tasks. So mere type skills will not be adequate; understanding interaction from a standpoint of task and capability is the core activity.

This means that the designer must have a comprehension of the basics of digital design history as well as what is current, and this is equally as trend driven as any part of print culture, in development terms.

I see this as the formation of the question, not an answer. What we do know is that the answer is a moving target, obfuscated by the claims of those who market digital culture. But the challenge to answer it is as real as any aspirations we have as providers of both sensible and innovative solutions.

Share/Bookmark

I share the responsibilities of hiring decisions for a small consultancy and being a design educator. Hiring new staff gives me one perspective on the state of education, and designing and delivering classes another.

Our consultancy delivers user experience design for applications; the participation of any kind of designer in these tasks is a relatively new thing, and is too often seen with some suspicion by both developers and financial officers in the organizations we consult with. The ability to convey the passion that is required for the work is an asset, and one beyond any discussion of teaching methodologies. That said, I see it as vitally important work that is rooted in a strong understanding of typographic hierarchies, information design and the mechanisms of interactivity.

Experience in the former role tells me that hiring a design graduate with less than 3 to 5 years experience is usually a mistake. Surprisingly, I have had better luck with geeky film or architecture grads. They tend to have stronger conceptual abilities.

We can deduce that design programs are non-functional in developing graduates capable of exploring and understanding these tasks. This is a simple and troubling assumption, particularly as I am complicit in the activity of educating them.

The organizers of the Schools of Thought conference have recognized a broader problem, inclusive of this issue, and have organized their spring conference around it.

http://superstove.blogs.com/schoolsofthoughts3/portal/index.html

My question is this. Is it presumptuous to expect Design Schools to graduate students with even a roadmap of the skills of information design, interactivity and typography? The problem lies less with graduate programs – where students should have some breadth of experience – but is pronounced in undergraduate education.

I hear no end of lip service; these are core values all lay claim too; yet the results are a vision of the emperors new clothes.

Share/Bookmark

I’ve been going through the Scriptaculous effects library in some detail. After grokking all there is to know about effects queues, I was left with one question: why does the effects library have a dependency on Prototype? The dependency could be removed with maybe two dozen lines of Javascript. So, why the dependency?

After having several other frameworks arm wrestle me for the $ identifier, I’d like to drop Prototype at the nearest corner.

Anyhow, I’m working on something involving Scriptaculous now that will likely make me the but of both jokes and death threats. Stay tuned.

Share/Bookmark

Jan Erik Paulsen has been writing some sample Apollo applications. In his view, Apollo isn’t quite there yet:

The Apollo SDK also feels a bit lightweight for something coming out of
Adobe. Apollo/Flex is very powerful indeed, but the SDK does not
reflect this. Third party applications are currently in crash-o-rama
spectacular mode since about 60% of non-Adobe demo applications throw
exceptions. It is alpha after all.

Yes, it is alpha software, but 60%? I’ve seen about the same rate. That seem a bit high. Presumably these apps all ran on the developer’s local machine. I know that is a bad way to test apps, but since they aren’t a) complicated and b) running on a supposedly platform independent runtime, you would expect this rate to be a bit lower.

Share/Bookmark

Over the last month or two I’ve noticed some definite trends in the sorts of questions that clients and prospective clients are asking my company (Pathfinder). Comparing notes with friends and competitors, it seems that the following technologies are really picking up steam towards the second half of 2007:

1. Ruby on Rails as a replacement for PHP. Big, complicated applications are still being written using Java and C# and their related frameworks. For those apps where speed to market is key, however, Ruby is starting to supplant PHP.
2. GWT for client-side Ajax apps. After an initial bit of nervousness ("Compiling to Javascript? Whah?"), the debugging capabilities and single language attraction of GWT seems to be winning out. People are still writing plenty of traditional web stack apps, with Prototype and its descendants leading the way, but look for more companies to make the jump to GWT.
3. Agile development. While not technically a technology, this trend has some real consequences for web and RIA development. The tools and frameworks that are agile influenced will give the teams and companies that adopt them a competitive advantage. Mind you, I’ve see "agile" and "iterative" thrown around in corporate circles as far back as 1999, with little positive impact. Now, I think, we have a new generation of managers who have some sense of what an agile development process can yield; they aren’t adopting it to be buzz-word compliant — they actually want the benefits that come from an agile approach.

The one trend that really seems to be accelerating is the PHP->Ruby migration. There has been hand wringing about this threat in the Drupal community since 2005. Time to saddle up, fellas. This time it’s really coming.

Share/Bookmark

Too often, usability testing is judged to be a “nice-to-have,” but dispensable within the time and budget constraints of a full design and development project.

This activity is often incorrectly perceived as being solely a formalized study that is time and labor intensive, with the potential to threaten the timeline and swell the budget. This is especially the case with the increasing dominance of Agile development methodologies, in which usability testing is thought to be a hindrance to the rapid iterative process.

However, there are many methods to elicit user feedback, both during development and pre-release. Here are the pros and cons of a few.

Read more »

Share/Bookmark