Adaptive Path Blog

I was at Rich Web Experience last week and Yahoo’s Bill Scott presented a session on his recently unveiled prototyping library. It’s called Protoscript and he’s written a blog post as well. Both of these sources get technical fairly quickly so the implications may not be immediately obvious to non-programmers. Even though Protoscript is still very much a work in progress and there’s some distance between its current state and Bill’s vision for its future, the opportunities it opens up are are exciting.

The driving force behind this library is Bill’s opinion that “Prototyping is too hard for non-techies”. I wouldn’t make quite the same blanket statement, but I do agree that some of the most useful, effective prototyping approaches do require developer resources or developer assistance. These technical resources are not always readily available. Protoscript shifts the requirements and ultimately will allow designers with little or no actual coding expertise to rapidly prototype in an interesting way.

The Protoscript bookmarklet allows you ‘inject’ Ajax behaviors into existing web pages. That means you can start with an html mockup or a client’s existing site as a starting point and try all sorts of different approaches. Do you have a list of items somewhere on a web page? Want to see what it would be like if they were drag and drop elements? Want to see what it would look like if you could delete list elements and have them fade and disappear? Somebody asks to see what they would look like in some sort of accordion layout? Imagine being able to run through those three iterations in the space of 10 minutes. Now imagine being able to do that as a designer without a developer to help you.

Being able to get by without development resources will require the completion of the GUI interface Bill envisions but even in its current state, Protoscript could fundamentally change work flows. A designer and a developer can sit together over a common screen run through ideas in a much more lightweight way than they currently can. Or, in other words, Protoscript shifts this type of prototyping from a multi-day email interchange with the IT department to something that feels more like sketching quickly on whiteboard.

Share This

I’m going to be speaking at the fast approaching and local Rich Web Experience 2007. It’s in San Jose on Sept 6-8 and it’s put on by the excellent No Fluff Just Stuff folks. Several things to recommend this year’s event:

1. 90 minute sessions: It can be hard on the speakers, but as an attendee it’s great seeing topics explored more in depth than shorter sessions allow.
2. Our own Jesse James Garrett will be one of the keynote speakers.
3. One of the few conferences that has schwag worth paying attention to. This time it’s a video ipod or a Nintendo Wii.
4. Bill Scott will be unveiling his Ajax prototyping library. I got a sneak peak at our recent UX Week event and it’s amazing.
5. You can get $200 off with the promo code ‘nfjs2007speaker200’.

Come if you can and say hello.

Share This

I did an interview with Bill Scott and Karon Weber a couple weeks ago discussing the content for their upcoming session at UX Week. It should be an intriguing session and I’m looking forward to hearing more about their experience. On a selfish note, as I’m doing a session on prototyping at UX Week as well, I was interested to see how critical having a working prototype was to their process and the success they achieved with their project.

I’m a big fan of prototyping. Over the last couple of years, I’ve accumulated more and reasons for this attitude. I’ve generated wireframes, I’ve developed from wireframes and I’ve developed from large specifications documents. Increasingly, the frustrations around these approaches have caught up with me. They have felt more and more like a set of old clothes that no longer quite fit. Assuming you are fortunate enough to have a process that allows some sort of iteration and collaboration between developers and designers, trying to collaborate with designers by passing wireframes back and forth is loaded with hidden costs. I like to think I can visualize with the best of them, but often the results of IxD or IA decisions don’t really become apparent until I am actually confronted with them in an interactive fashion. Even focusing purely on development concerns, there’s an entire class of problems that you never see until you’re halfway down the road to implementation. Prototypes, by pushing some form of implementation early, can help avoid unpleasant surprises late in your product development cycle.

Fortunately, it’s getting easier and easier. As Ajax settles in and becomes more common place, and as the front end developer talent pool deepens, it becomes easier to find people that can use a library of interaction scripts to mock up much more interactive html/css/javascript than before. There are open source frameworks that allow developers to build out entire applications in a fraction of the time it use to take. While these applications may not be suitable for a public launch, they are an excellent method for exploring the problem at hand in a way that all the interested stakeholders can immediately apprehend. There are also more and more 3rd party tools designed addressing this niche with varying degrees of robustness and effectiveness.

We’re on the rising curve of this trend. There are are plenty of contexts where wireframes themselves seem to be an adventurous leap of faith. Still, this is going to be an interesting area for growth both as we get better at creating prototypes and better at using processes that can take advantage of them.

Share This

It’s long been my belief that the perceived dichotomy between design and development, a dichotomy that is often fostered by both, exists to the detriment of both. The potential negative impact of of this dichotomy has increased as recent developments continue to challenge us. To use Ajax and RIA’s effectively requires expertise that spans both design and development. On another front entirely, as we move into the realm of service design, we enter a territory whose constraints and possibilities are unfamiliar to us.

This was brought to mind again several months ago as I was listening to a presentation given by a hardware designer. In discussing how closely, or not, some hardware designers work with manufacturers he posited a dichotomy between design integrity and manufacturing priorities. My hackles rose instantly. The implication was that there was some clear and pure design vision and that anything that pushed back against it was to be avoided. Including, evidently, the real world. Clear design vision is a wonderful thing but it doesn’t mean that there are not real physical and manufacturing constraints to building products that designers should be aware of. I was disheartened but not surprised to hear a sentiment so familiar to us in the web applications world. Designers can be deeply distrustful of the developers that are actually going to make their visions and ideas real.

Here is one of the few effective keys to the design problem — the ability of the designer to recognize as many of the constraints as possible — his willingness and enthusiasm for working within these constraints. Constraints of price, of size, of strength, of balance, of surface, of time and so forth.

- Charles Eames

Developers work in an environment of constraints. There are only so many developers or a limited amount of time. The database will only fetch the data so fast. There is often amongst developers, just like designers, a strong desire to find technically elegant solutions. These elegant solutions are not reached by being willfully ignorant of the constraints or being negligent about learning what is actually possible. But, whether or not an elegant solution can be found, the ultimate metric of success for developers is “Does it work?”.

So what do we do? One simple answer is that we work more closely together. This is easier with smaller teams. Significant web applications can and are being built with fewer than 10 people involved from start to finish. Even in cases where larger teams are unavoidable, approaches that involve prototyping or some sort of iterative cycle can be useful. Aside from their other benefits, these approaches can ‘game’ the corporate structure to get the right people in the same rooms on a regular basis. With increased exposure, both developers and designers get a much better sense of each other’s expertise and concerns. With increased exposure we both get better at finding the place where the possible and the ideal come together. Most importantly, we get to align behind the realization that we are all trying to build an application that we’re proud of and we’re trying to do it together.

Share This

I attended O’Reilly’s RailsConf last week in Portland Oregon. What a difference a year makes. There were 550 attendees at last year’s sold out conference. This year’s conference, moved to a larger venue, also sold out early with a final head count of 1600 participants. It’s a testament to the continued growth of Rails as a platform and makes it clear that Rails isn’t going to disappear. Now that at week has slipped by, looking back at the conference I’m left with several distinct thoughts.

I presented a session on Design for Developers that was standing room only, clearly indicating a trend that I’ve been pointing to for the last couple of years. Rails, other similar frameworks, Ajax and the increasing adoption of Agile inspired development practices have pushed developers to work more and more closely with designers. With Rails in particular, developers often find themselves challenged directly with design questions. This has left a real thirst in the developer community in general and the Rails community in particular for guidance and information around issues of design. There’s a real opportunity for practitioners on both sides of the developer/designer divide to help each other work more effectively and share information.

Judging by the keynotes, there seemed to be a lot of concern about whether Rails is ready for the Enterprise or not. This echoed conversations at last years RubyConf as well. Maybe I’m not reading the right blogs but curiously, this question doesn’t seem to take up as much space in the general community dialog. I don’t know if it’s even the right question. An impromptu, raised hands survey during one of the keynotes revealed approximately a third of the attendees came from a Java background. As Java developers in enterprise become increasingly interested in and enamored by Rails, it will leak into the enterprise environment whether management wants it there or not. Initially small projects will get done in Rails where there is a management blind eye. With a foothold established, it will be easier to employ Rails as an approach to larger and larger projects. JRuby and the associated ability to deploy rails apps to existing Java application servers is only going to exacerbate this trend .

And finally…Twitter Twitter Twitter. It’s clear that Twitter is going to be the poster child of Rails scaling issues both good and bad. Scaling has always been a perceived achilles heel for Rails applications and Twitter’s tremendous growth has resulted in some visible hiccups. Progress has been clear though and it’s likely that were will be solutions for most of the Rails specific performance issues in the near future.

All in all, it was a great conference and a pleasure to participate. I can’t wait until next year’s.

Share This

“Everything that can be invented has been invented.”
–Charles H. Duell, Commissioner, U.S. Office of Patents, 1899.

This quote speaks directly to one of the things I love about many web applications that have appeared over the last several years. These applications directly address problems that were considered ‘solved’ or markets that had such clear leaders it seemed ridiculous to enter. If you had asked me a couple years ago if it was wise to build a personal finance application to compete with Quicken I would have said no. But Wesabe, an online personal finance application, has come up with a compelling new offering by rethinking what people really want from their personal accounting system.

I received an early beta account for Wesabe and, in a common new application life cycle for me, played around with it some, was interested, then got distracted and let it languish. I picked it up again a month ago. In that time Wesabe has gone through a public launch and incorporated many feature upgrades that have changed it from an application that is merely interesting to a service that I find very useful.

One of the things I like is that it inspired me to reconsider my approach to money. Long long ago, driven by a need to budget, I started using Quicken. The goal back then was simply to determine where my money was actually going. I was quickly turned off by the yearly death march of Quicken upgrades providing more and more features I had no interest in. However, despite hopping off that bandwagon, I remained on autopilot. I balanced statements every month and was more or less rigorous about entering detailed information, muttering under my breath all the while about how tedious the whole process was.

But why? At the end of all that care and feeding, what was I really getting out of the process other than a handful of reporting numbers and a vague feeling that I was being ‘responsible’ about money? After a month of steady use, Wesabe has made me rethink the things I actually want to do. And fortunately, the things I actually care about are things that Wesabe makes easy to do. Getting information in: easy. Assigning transactions to categories I care about: mostly automatic. Reporting to the level that I care about: easy. There’s the added bonus of the community aspect of Wesabe. Based on categories and tags, there’s links to various hints, tips, business recommendations or warnings, and goals. In other words, a whole other area of functionality is now available that is impossible in a stand alone desktop app. So Wesabe is now replacing my 5 year old version of Quicken and that area of my life not only requires less effort, but the results are more useful.

Wesabe for personal finance, Flickr for photo sharing, Basecamp for project management — these are clear indications that there is plenty of room for new ideas. Everything that can be invented has not yet been invented. Better yet, many things that have already been invented are still wide open for re-invention.

Share This

A few days ago, I finally got an Amazon EC2 beta account, spent a little time playing with it and had some initial thoughts about the service.

The Getting Started Guide was reasonably straightforward with the expected gotcha’s and a couple unclear instructions. Took me about an hour to set up a stock virtual machine, get it running, modify it, save my changes to an encrypted copy stored on S3, and relaunch my my customized version. Not bad. Still, the process is complicated enough my mother is never going to do this and anybody who is not familiar with unix command lines is going to be pestering their geek friends for help.

The pricing is such that if you need one machine, it’s cheaper and more reliable to go to ServerBeach, Rackspace or some other dedicated hosting provider. Bandwidth costs are not that high but if you have an application that involves huge amounts of bandwidth, you can beat the pricing by buying in bulk. The RAM provided on the virtual machine doesn’t seem beefy enough for anything involving a heavy database work. And the transitory aspect of the machines (and IP addresses) provide some challenges.

That being said, it seems clear that there could be some great opportunities here for rapidly scaling up and down in a cost effective manner, the challenge being how to architect an application to be able to take advantage of this. Seems like somebody should set up an service that acts as a front end to EC2, transparently proxying requests, providing load balancing and scaling up or down as needed. There’s a need for user friendly tools to create, manage, launch, and save instances. Could be cool for teaching too. Give each student their own linux box w/ root access for the duration of the class or quarter.

Ultimately, whether or not we harness EC2 to solve our current needs, I’m most interested in seeing the new types of applications that evolve. My experience is that it is easier to perceive problems when we have the tools to build solutions. This is a new tool in the toolbox and there is potentially a whole new class of problems that we can solve. I think we’ll see some entirely innovative uses for EC2.

Share This

Last year the Smithsonian produced a wonderful traveling show: Doodles, Drafts & Designs: Industrial Drawings from the Smithsonian. The exhibition was based on drawings produced by ‘engineers, inventors and designers’ and explored the different ways those drawings are used. Many of these drawings are now available in an online exhibit.

Aside from my immediate interest in the content, the exhibition called to mind recurring discussions we have internally or with clients about documentation. Often disagreements about the type, nature or amount of documentation required can be traced to confusion or differing assumptions about the specific function of the documentation in question. Complicating matters further, documentation can often explicitly be used to serve multiple functions. If you’re just exploring potential solutions, a transitory whiteboard sketch is sufficient. In contrast, when passing a ‘final’ design to a development group your team may never get to interact with, documentation needs to be more substantial. Wireframes in particular seem susceptible to this type of confusion or disagreement as they can be used to fill so many different roles: exploration, documentation of process, documentation of the solution, guidelines for development, demonstration, persuasion, explanation or contract mandated deliverable.

It can be helpful to remember that often the goal is not documentation but communication, and that communication may or may not require documentation as an actual artifact. It can be even more helpful, when documentation truly is required, to step back and determine what exactly it is that you are trying to accomplish.

Share This

I attended Microsoft’s Expression Session yesterday, the launch event for their new Expression suite of products. I came away hopeful and frustrated in equal parts. Microsoft has jumped with both feet onto the User Experience bandwagon. It’s just not clear that they understand what User Experience means.

The first red flag was this quote: “Design is form + function + flair” followed up with the Mont Blanc Diamond pen as an example. Just picture a Mont Blanc pen literally encrusted with diamonds. Admittedly I’m not the target audience for such a thing but it does highlight the fact that ‘design’ is not equal to ‘good design’, nor is it something that is lathered onto a product.

More telling was this snippet. After stating “the experience is the product” (I heard that exact phrase several times), they stated “platform+tools+craft = UX” As with the design quote, they conflated user experience with good user experience. Craft was defined as “that thing that designers do”, which wouldn’t be so bad if it wasn’t combined with “designers work in Photoshop and produce tiffs”. There was no sense of design strategy, or even design on a deeper level than visual design. There is also something that seems disconnected about discussing user experience and user centered design by discussing tools and platform rather than talking about the user and their interactions with your product.

And finally, there was a graphic at the end that showed a spectrum from web applications to desktops applications, with the former labeled ‘basic user experience’ and the latter labeled ‘best user experience’. Microsoft still thinks more bells and whistles means richer experience and richer experience means better experience. Good user experiences can be affected by visual design or richer interfaces but its foundation needs to be the appropriate interface to what the user is trying to accomplish.

That being said, there were positive notes:

Expression web actually seems like a pretty nice front end developer tool, head and shoulders above previous efforts and it appears to generate clean, standards compliant code.

They understand that developers and designers need to work more closely together. They are starting to understand the importance of ‘knowing the user’ though it still seems they often confuse after the fact usability tests with user centered design.

Even if they don’t understand it, they are definitely on the User Experience bandwagon and with their tremendous audience of developers I’m happy to have another voice pushing things in the right direction. I spoke to the Director of Product Management for the Expression suite and he not only gets but is articulate about UX, the importance of the user, user centered design, the spectrum of design tasks and their role during product development.

It’s clear from the Xbox 360 and from how well Media Center does with the 10ft experience, that Microsoft can do good work. It’s clear that there are pockets of excellence and a growing number of people within Microsoft who get User Experience. Yet, as a company, it’s also clear that there are some fundamental flaws in Microsoft’s understanding of design and it’s role in building good user experiences. I remain hopeful that those pockets of excellence will continue to grow in reach and influence inside Microsoft.

Share This

During OSCON last week, Tim O’Reilly raised the issue of Open Source Licenses and their applicability today. His subsequent blog post, Open Source Licenses are Obsolete, goes into more detail and is worth the read. His thesis is that open source licensing is less significant in the current climate where many of the important web sites, despite being built on open source software, provide services rather than software. He uses this statement as a call to develop an open services definition, encompassing services and perhaps data, in the same vein as the original open source definition.

This issue reminded me of a series of discussions we had internally when developing Measure Map. We felt that the user’s data belonged to them and that it was important to provide some access to that data beyond the application itself. There were several challenges. Some of the data was so specific to our application that it wouldn’t be meaningful out of context. Also, the amount of data we were collecting was enormous and keeping detail data for every user for all time wasn’t feasible. We had to have many back and forth discussions about data retention. Jumping to consider not just data but services as well, each site thinking about these issues will likely have unique challenges and I’m uncertain whether a definition general enough to apply to all can be specific enough to be meaningful. As a start in the right direction though, I would love to see sites being transparent about their practices and policies just as has become increasingly common with privacy policies. At least that way users can have clear expectations about how open, or not, the site they’re considering investing their time and data with may be.

Share This