Comments on Prototyping with XHTML

Ken Whaler — Tue, 16 Dec 2008 15:22:16 GMT

This is a very interesting topic indeed. My job (UX Strategist) is to show a design/interaction concepts… a balancing act of detail and concept.

My main problem here is that interaction design / UX is not just layout out a page of boxes (or DIVs), its about explaining what the purpose of the boxes are and what experience they are intended for- to explain why the layout is better because its usable or will allow the target user to use the site that its intended to. This can be summed up in one word: documentation. I agree that its handy to use html to align boxes. But what about the other typical deliverables of a UX professional: sitemaps, user journeys, etc.? The one real solution is a drawing program that can be exported out as a Hi/Lo fidelity prototype and integrates notes and specifications (and everything else under the sun).

I have used: HTML, iRise, Protoshare, AXURE, Visio, Paper and pen, OmniGraffle, Illustrator, Fireworks, the list goes on… All have their strengths and weaknesses. The search continues…

Tim Sheiner — Fri, 12 Dec 2008 17:20:31 GMT

Anders;

Excellent, complete and even handed description of a work process.

When I first stumbled into XHTML prototyping I found myself second guessing my plan to embrace it. The approach seemed so much more efficient to me than static wire framing that I couldn’t understand why it wasn’t a more common practice. I wasted a fair amount of time wondering if I was missing something and even had a disappointing experience trying to evangelize the idea when I worked briefly at Apple. There I had zero success suggesting that XHTML prototyping might have as much or more value than ‘pixel-perfect’ PS or AI files.

Nice to read someone else confidently putting forward this approach as valid.

Thanks!!

Tim

Anders Ramsay — Fri, 12 Dec 2008 16:08:57 GMT

Hi Alex – I’d definitely be interested in beta-testing this tool. You can reach me via the website listed above.

alex morris — Fri, 07 Jan 2011 19:48:41 GMT

I am currently working on an online tool that hopes to address all of these issues, with easy sitemapping, wireframing and collaborative working. Its called boxmapr and will be launched in March 2009!

http://www.boxmapr.com

beta program will be live in the new year, would be great to have some testers from B&A

Martin Tschofen — Thu, 04 Dec 2008 02:33:08 GMT

Great discussion. Tools will help make prototyping easier (eventually—I hope). While not all tools fit every project, they to me stimulate creative solutions because of their limitations.
While considering prototyping on a large project a couple of years ago and looking at various tools to do the job, I noticed that in order to do fast, iterative prototyping it helps to break interactions into reusable micro patters e.g. inline editing of text, progressive reveals of additional information. (Identifying these IA micro patterns during the process will allow for consistency in the design and faster development.)

To make such IA micro patterns interactive and easily changeable requires them to be reusable objects (think stencils in OmniGraffle or Visio.) Changing the underlying object should change it throughout your prototype. The prototyping tools I’ve seen don’t (yet) seem to focus on this approach.

To facilitate IA micro patters I pulled together a solution based on a wiki (DokuWiki) customized for the project. For each IA micro pattern I either used existing plugins or added new wiki syntax for each pattern. Hence it allows for quick prototype iterations using existing solutions—just to see if the ideas are worth pursuing.

The nice part about it is that it’s all open source, thus there are no restrictions.
And being able to collaborate in one space, do ongoing usability, online reviews, notations, without special software… improved the process tremendously.

Take a look: http://tr.im/1tet

John Que — Tue, 02 Dec 2008 01:04:00 GMT

+1 for Axure. It is powerful, easy to use, and can allow even those without HTML/CSS knowledge to create complex and functional prototypes.

Holger Maassen — Wed, 26 Nov 2008 15:56:38 GMT

I really like this discussion – because it exposes the various aspects of the design process.
You mentioned / pointed out: |quote| My main concern with this tool as with any canned prototyping software is that it does not constrain you to what the actual technology is capable of, but rather to what to the tool is capable of, which isn’t very conducive to innovation.” |/quote| . I have the same opinion! And I think that’s an important point, not for each designer or developer, but for quite a lot of people.
We have to be conscious of the fact each tool has on the one hand its capabilities and on the other hand its limits and restrictions. Especially our applications we use with our mice and keyboards.
When I think of my time as architect and town-planer for the “real world” – I had to realize that lots of colleagues avoided to draw or to develop forms, details or whole constructions just out of the reason, they don’t know how to draw it with their CAD program. Some months before it was no problem to drew these forms, details and construction. They drew them very easy with pencil or ink on a piece of paper. What I am trying to say is: every tool restricts us either because we don’t know how to draw it or to code it or because the tool isn’t able to do it.
Regarding to this fact we have to keep this in mind and the strength / courage to switch the applications, tools or methods.
Yes (@Jonathan + @Anders), you are right, we should build on a valid foundation (either by |quote| “start by letting Google inform you” |/quote| or the |quote| “capability of a tool” |/quote|), we haven’t to reinvent the wheel. But we should not copy the wheel just because we need something to move. Maybe there is something else needed or possible – like “ Beam me up Scotty!” :-) … and then there aren’t any tools or “google” which can serve you a pre-builded or pre-designed UI / UXD.
There is no rose without a thorn – Sometimes XHTML is a more than a powerful tool both for internal processes and for external processes – it’s the rose, but sometimes it’s the thorned stalk.

Anders Ramsay — Wed, 26 Nov 2008 04:53:20 GMT

Hi Philip – Flash is great for prototyping applications, and if I were a Flash expert, I would probably sketch out design ideas in Flash no matter what the production technology, just as if I were a PowerPoint or Visio or Illustrator or Fireworks expert, I would use those tools for all my explorations. (They would be my hammer and every design problem would be a nail.) But no matter what tool you use, at some point you will have to face reality. And if you’re designing an application that will be implemented with one technology and exploring the solution with another, be it flash or whatever, you are really only sketching, only exploring, and you can keep simulating away until the cows come home and you’re still never going to have actually validated the solution.

The points you raise above seem to tell me that I may have not done such a good job of communicating a fundamental aspect of the methodology I described in the article. In the iterative development methodology, after having done some sketching and prototyping, using everything from pen and paper to Flash or whatever, you then actually *fully implement* that unit of the application. In other words, you are at that point *not* prototyping, you are actually building. Then, for later iterations, you can take the XHTML/CSS/JS production files and use them as a starting point for prototypes for other application units or updates to that unit. I’ve done this many times, and it is incredibly efficient and powerful. I realize that, particularly since the article is titled “Prototyping with…” that this may be a bit confusing. And the fact that iterative development is a completely different paradigm compared to traditional waterfall probably doesn’t help much either.

Philip Fierlinger — Wed, 26 Nov 2008 04:08:52 GMT

I’m a big fan of prototypes. My entire career has revolved around prototyping.

In my experience, there are major problems with HTML prototypes:

1. HTML + CSS need to be well formed to look/work properly, requiring too much time + effort to build the prototype, time that should be spent designing and refining your concepts.

2. Design refinements are painful and time consuming because you have to re-engineer your code.

3. Re-engineering makes you reluctant to make significant changes, so you end up exploring fewer alternatives (the main purpose of prototyping).

4. There is a natural inclination to build on top of the prototype code, as the starting point for the production code. Prototype code, by it’s definition, is a hack. That’s an awful starting point for production code.

I find Flash to be the ideal prototyping tool.

Flash is a drawing tool – you just draw your design, no coding whatsoever, so significant changes take no time at all. Plus, it’s 100% compatible in ALL browsers.

If you want to make an interactive prototype then Flash can be coded with one basic line of Actionscript: onRelease.gotoAndStop(frame).

If you want to build more complex functionality with drag-and-drop then you can, and it requires less expertise than Javascript. Again, it’s 100% compatible in ALL browsers.

Flash prototypes won’t be completely identical to the final experience, but no prototype is. Flash prototypes can be as lo-fi or as hi-fi as you want. With Flash there is no limitation to the concepts and feature ideas that you can simulate – it’s an unlimited toolbox.

With Flash you explore more ideas, more quickly, producing better solutions. It’s as simple as that.

Philip Fierlinger
http://skyrize.com

Anders Ramsay — Tue, 25 Nov 2008 20:44:55 GMT

Jonathan – re. how a prototyping tool constrains you vs letting Google inform you about an existing solution, they are definitely not the same. The constraint created by a prototyping tool is an artificial one, while existing solutions on the web are not so much a constraint but a *starting point.*

In other words, if I have an idea for a design solution, I will only be able to simulate it with a prototyping tool if whatever widget or behavior I want to use is supported by that tool. (For example, if I want to prototype drag and drop behavior, but my tool does not support that, this is an artificial constraint that has nothing to do with the real-world solution.) A Google search, however, would reveal what the latest and greatest ideas are out there relating to that idea, essentially what the state of the art is. And I might be giving Google too much credit in being able to show that, but the larger point is to simply to use the web itself to see what the limits are of what has been accomplished so far. And, more importantly, to be able to *build on those ideas* rather than being constrained by a certain prototyping technology.

Keith Sherwood — Tue, 25 Nov 2008 16:45:29 GMT

Great article! I like to be flexible and use the right type of prototyping for the task at hand, but, with that said, I’ve used XHTML prototyping for my last few projects and the practice has definitely paid off in terms of efficiency and speed.

I’m the sole UX designer in my development shop, and while we have developers who understand markup and CSS, the largest portion of XHTML, JavaScript, and CSS work usually falls to me. Because of having to wear multiple hats of designer, lead, and trench-coder, I find that prototyping in XHTML helps me combine project phases and alleviate bottlenecks (not to mention that there isn’t a graphic design department to hand my sketches to).

The best two aspects for me would definitely be code reuse and catching “gotchas”. Having the actual markup ready by the time the prototype gets the “OK”, with maybe a few small tweaks, has increased our team’s efficiency. I’ve been able to pass the prototype on to other developers, with very little training or question answering after the fact. I don’t want to say that it enables “cut and paste” development, but there is definitely a lower learning curve for everyone.

Also, getting to see how realistic a design is in a browser, rather than Illustrator, is a huge benefit and helps us get out in front of possible issues much earlier in the development cycle. I shudder to think at how many pie-in-the-sky faux interfaces were approved in my department a few years ago, only to find that parts of them would take an inordinate amount of hours to pull off. On the flip side, having a realistic prototype that people can actually “click on” has given prototypes more of a “wow” factor than before—an idea that challenges my former love for the static graphic prototype.

Anders Ramsay — Fri, 21 Nov 2008 17:42:09 GMT

Ryan – protoshare looks interesting – like you said, Axure but online. My main concern with this tool as with any canned prototyping software is that it constrains you not to what the actual technology is capable of, but rather to what to the tool is capable of, which isn’t very conducive to innovation. Though I generally stay away from any kind of prototyping tool, I think protoshare could be useful for the intermediate stages of a design evolution, (i.e. after sketching, but before actually starting to build something), particularly for someone who may not have access to developers in the early stages of the design process (an unfortunate reality IMO.)

But the big problem with these tools is that they create a very sophisticated illusion of something that does not exist, meaning that while customers think everything they see will work just the way it works in the prototype, the actual experience built with real code may be very different. For that reason, it’s critical not to assume that a prototype is a validation of your idea, and that you actually have to build it to know if and how your solution really will work.

Ryan Smith — Wed, 24 Jun 2009 13:50:39 GMT

Great article. We tried a similar process on a few projects, but also ran into issues presenting it effectively to our clients. We started using axure and have been fairly happy with the results. Has anyone tried protoshare? I just started a trial a couple of weeks ago and am looking for holes in it, but haven’t found anything major. It’s a lot like axure but has built in review functionality and its web based (how has this not been done before??). Getting instant client feedback on our prototypes could definitely change the way we work. I still start with pencil and paper though.

Holger Maassen — Mon, 05 Oct 2009 20:47:55 GMT

Hey – in addition to my last post…
there is something that slips my mind – do you know in this context the site of Mark Boulton?
It shows the (HTML) prototype development of drupal.org. You can check the steps from the first prototype up to the current version 6 and it’s still in process.
Drupal.org prototype development = http://drupal.markboultondesign.com/

Holger Maassen — Mon, 05 Oct 2009 20:47:55 GMT

First of, let me tell you that this is a great article and interesting discussion. I really like to work with HTML-prototyping, no matter if its done using tools like Dreamweaver, GoLive, SeaMonkey or by direct coding. But…
...the never-ending story and discussion of the “best tool” or “best delivery” is like the search for the holy grail. It seems we are always looking for the best and “coolest” tool or kind of deliverables we like to work with, but leave the main aim out of sight – the best tool and deliverables suited to solve the problem at hand.
When I work with XHTML-prototyping my work is similar to the one I create when using diagram software. I have a set of stencils/templates to put my idea/sketch together.
But the reason why I write this comment is – I don’t like to go into details to early – to make discussion like “should it be a pulldown / should it be a div-layer or iframe / should it be checkboxes / or / or / or … what ever it will be … I will keep my mind free …
We should not plan too much in too much detail. Yes we need these things – but with each deliverable which is so detailed – a part of our idea expires / dies.
(At this point a video-clip strikes me: http://www.youtube.com/watch?v=gYEf8XZKlUU ) … but this just en passant)
The first thing I do when I start to work is, I grab a piece of paper and a pencil – And as long as I can I keep these drawing and sketches and improve them, I’m happy.
Yes, we all work and plan for online media, but does that also mean we have to do it the same way?
For me it’s important to get an idea quick and rough on the paper. I work with sketches as long as possible. So I like to do paper-prototyping.
We are dealing in abstractions. Often all we have is just an idea. In the best case we have a common understanding of the app or interface we are going to build. We might know which content we want to have and features we like to integrate. But – the sooner we begin to put our ideas into code the sooner we bastardize and blur our ideas.
But don’t get me wrong, (X)HTML-prototyping is a good thing – but for me just in a few cases.