Agile UXD
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.
Topics: Methodology
GWT 1.4 RC Now Available
GWT 1.4 RC has been released. What's new? Just a sample:
I'm especially excited by the new deployment options:
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.
Topics: Announcement, GWT
Monster.com’s Job Search Beta Runs on OpenLaszlo
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.
Design? Meet Research.
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.
Topics: Accessibility, Design, Usability, User Research
Que Multimedia, Part 3, Beyond Typography
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.
Que Multimedia: Part 2, A Dilemma:
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.
Why Does Scriptaculous Need Prototype?
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.
Topics: Ajax Frameworks, Prototype, Scriptaculous
Apollo: How Alpha is Alpha?
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.
Topics: Apollo
Ajax and Agile Trends for Q3 and Q4 of 2007
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:
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.
Topics: Analysis
Usability Testing Techniques
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.
Pibb - Commercial App that Uses GWT on the Client Side
I almost missed this article in Ajax Magazine about Pibb, a commercial Ajax-based communications center (chat, channels, etc.). The client is all GWT and uses a Python web server and some Ruby for data persistence. That's right, no Java GWT services on the back end. The money quote from the article:
When asked about the choice of GWT precisely and not any other JavaScript library, Grant explained "I would hate to think of tracking down the silly bugs that the compiler catches just using the tools available in the browser. There are javascript debuggers out there, but they are pretty painful. GWT also has a special "hosted-mode" browser that you can use to get full tracebacks when errors occur".
Well said. For anyone who has felt the pain of Firefox/IE6/IE7/Safari debugging, we feel your pain.
Topics: Ajax Frameworks, GWT
Angry at GWT
Ryan Doherty is an angry man. What is he angry about? He is angry at GWT. Why is he angry?
The bottom line is GWT doesn't give a damn about the web and treats it as an inconvenient interface that needs to be avoided at all costs. And it does, but to a terrible outcome. The developers obviously do not understand the paradigms and principles of the web. It's amazing the amount of work they put into creating this Java based toolkit when quite possibly a lesser amount of time could have been spent working on a great Javascript/HTML/CSS library (YUI, jQuery, Ext, Scriptaculous) that would promote web standards.
Ryan sprinkles his gunpowder over four points in his blog entry, Why Google Web Toolkit Rots Your Brain:
Let me rebut the easiest ones first. So what I think that Ryan is trying to say with the web site versus applications statement is that we are developing web applications, not just applications. So emphasis is on "web." And Ryan thinks that if you are writing a web application, you should use web standards, not the funky, ugly code that GWT produces. I say make the code as ugly and funky as possible. Write clean Java code, then let the GWT compiler deal with generating the target Javascript code. As they improve the compiler, the quality of the HTML/Javascript/CSS will improve without my having to change my application code.
As for the browser sniffing, the GWT generates different code for different browsers and, once again, it is compiled. As new browser types and versions come out -- a very likely scenario in the world of mobile devices -- you don't have to decorate your code with lots of excess conditionals to test for browser properties. All those extra conditionals add up. And you'll have to rewrite your code (or library) to support other browser types and versions as they come out.
Now, is GWT bloated? Ryan's example is "Hello, World!" Not exactly a fair test, since most of the code there is setup and Java lib code; it would be better to look at a larger example. Plus, he counts in all of the alternate files for different browsers. Since they are generated by the compiler and don't have to be maintained seperately, you should count only one of them. Beside, he counts them in lines, not bytes. Last, lines of generated code versus lines of hand written code is misleading. Since many Javascript libraries do lots of initialization on loading and on object creation, you really have to count its memory footprint, not it's linecount.
As to losing the benefits of the target language, there are benefits and drawbacks to all languages. I'd say that for large, complex systems, a strongly typed language has its advantages. As I've already written, dynamically typed languages like Javascript have some pitfalls:
But code completion and tools are a bit of a red herring here. I've always felt uncomfortable with programming languages that depend on good programmer behavior -- essentially obeying code level idioms -- to allow for the development of large, interdependent systems. Alex Russell, in my interview with him, argued that Javascript was a "more powerful" language than Java and cited this paper by Lutz Prechelt that claimed to show that scripting languages are moe powerful and productive than the statically typed, OO languages (in part -- it's a simplification of the thesis). I agree that I can do in 1 hour in Perl what it would take me 10 hours in Java. I might even hope, as a single developer writing my own well understood style of OO Perl, to write a large application more quickly in Perl than in Java. But add in multiple developers, and you start to enjoy the complexity problem that Bruce Johnson mentioned. The same, in spades, goes for Javascript.
Ryan's complaints soundly eerily like those of the assembly language programmers throwing thier verbal sabots into the gears of early compilers. They would produce code that was bloated, poorly written, slow, etc. Programmers who used these higher level languages would rot their brains. That battle has been settled in favor of the compilers. No one would write substantial amounts of assembly code these days. The humans have lost.
With the likely inclusion of Tamarin (the ActionScript Virtual Machine 2) in future versions of Mozilla browsers, what's to say that future versions of GWT won't produce compiled bytecode for the Firefox platform?
Topics: Ajax Frameworks, Editorial, GWT, Javascript
RAJAX - A Leaner Alternative to DWR
If you feel that DWR is a little too beefy for what it provides, then you might want to look at RAJAX (not to be confused with the Comet/Rajax that gets mentioned in DWR circles), a Java framework that does something similar, i.e. expose Java methods via Javascript proxies. In the words of the author of RAJAX:
I've been investigating the DWR Toolkit and other AJAX libraries and I didn't found then to be that simple and easy to use. DWR was kind of OK but 6Mb of code is way to much. So I wrote my own Remote AJAX library (RAJAX).
RAJAX is different because all the source code is under 60Kb (20Kb compiled) and you don't need to code configuration files for it. To keep it simple all the public methods whose name starts with "rajax" are automatically exposed to the JS layer. All communications between server and client are made using JSON notation and the library has been tested with success on Firefox, IE and Opera.
It may not be as featureful, but if you are looking for a DWR-lite, take a peek.
Topics: Ajax Frameworks
Wireframes: Much More Effective than Interpretive Dance
Wireframes are a valuable tool in designing a site or application. They enable us to communicate both the layout and page content to fellow team members and business stakeholders and get their signoff. They’re essential because they force viewers to focus on the content, not the visual design, which means preliminary design meetings won’t get sidetracked into discussions on colors and fonts.
Basically, wireframes are a sketch of the business and user requirements. Since they are a drawing, they allow us to demonstrate how these requirements, nicely bulleted in a list format, are translated to a visual medium. In addition to showing that the requirements are met, wireframes can generate discussions uncovering what may have been overlooked. As the project progresses, we use them to begin explorations on how the user will interact with the screens and which data is affected.
ZK 2.3.1 Released - Adds new CAPTCHA Component
ZK continues to kick Echo2's ass when it comes to releasing new versions. I know activity for activity's sake is not the point, but Echo2 has stagnated a bit while the Ajax world has marched steadily on.
OK, enough about my disappointment. What about the new release of ZK 2.3.1? From the announcement:
captcha is added to simplify the use of CAPTCHA. Java Interpreter (based on BeanShell) supports hierachical scopes, aka., nest scopes.I haven't seen CAPTCHA components in too many places yet. CAPTCHA is pretty much required for any app that allows public registation, so I'd expect to see this one used pretty heavily.
Topics: Ajax Frameworks, ZK
