Text Based GUI Prototypes
A few years ago I developed an Enterprise Architect CASE tool plugin for Wells Fargo bank. It allowed them to combine UML Activity Diagrams with the GUI prototyping diagrams, and then generate interactive HTML that users could explore. It was fun.
I like EA, but each tool comes with an overhead. You have to buy, learn, install and upgrade the tool. Also, it sits there using up memory and CPU. And, it's another "context switch" during development.
Given my current interest in .txt files, I've been playing with creating plain text files to mock up UIs. 1980's eat your heart out. I was able to mockup 8 screens in roughly 8 minutes, which is pretty good going. The format looks something like this (2 pages shown):
Login
=====
Username: XXXXXX
Password: XXXXXX
[x] Remember me
[Submit]
Register...
Forgot your password?...
Forgot Password
===============
Please enter your email and
we'll send you a password.
Email: XXXXXX
Enter Captcha: XXXXXX
[Send me my password]
One thing I like about this is that the essence of a GUI can be captured in very little time.
Like all models, this one helps me focus on a particular set of concerns. In this case, screens, content and workflow. Not layout, pixel perfection, design, colour, widgets adn controls, ajax, master pages and routes.
I'm not sure where all this is going, but I'm almost convinced the way to productivity is small, simple models that focus on a tiny subset of concerns. The problem I'm trying to get my head around is how to get value from such simple models in code, without making the models heavier. Perhaps you can't. Anyway, that's all for another rambling post :) ...
Anyone got any GUI prototyping experiences to share?
Comments
-
What you are doing is called a “Low-Fidelity Prototype”. There are pros and cons to this type of prototype. The customer will not think you are 95% done (like they do with high-fidelity prototypes), but you have to get the customer over the hump of how it will look and get them thinking about what they need.
-
Nice example, be interested in how it works if GUI is highly interactive e.g jquery or ajax. I say that as many guis are now highly dynamic and such simple methods might make that hard to capture. Thoughts?
-
@Kris
Good points. I’ll have to put one in front of a customer and see what the feedback is :) Or perhaps write a generator to convert them to HTML so I can do rapid screen prototyping with customer at hand.
@Colin Yeah, I couldn’t find an elegant way of capturing dynamic interactions with this. I’m not even sure I’d want to.
I’m certainly in favor of using the real thing to make decisions rather than throw-away documentation.
It’s just having the skills and tooling to allow the real thing to be developed in real-time during discussion. I still think I could do these ASCII sketches faster than writing HTML. But they’re throw away.
I tried a live search screen. But capturing the fact that it was live wasn’t achived :)
Search
Search For: XXXXXXXXX [Search] 1. XXX XXXXXXXXXXX XXX 2. XXX XXXXXXXXXXX XXX 3. XXX XXXXXXXXXXX XXX 4. XXX XXXXXXXXXXX XXX 5. XXX XXXXXXXXXXX XXX 6. XXX XXXXXXXXXXX XXX 7. XXX XXXXXXXXXXX XXX 8. XXX XXXXXXXXXXX XXX2031 results foundName Description Rank< Back 1 2 3 4 5 More > -
Tried this one yet? http://www.balsamiq.com/products
-
I did some work along these lines a while back and may yet put the ideas I developed to work. I basically did much the same thing but wrapped things in layout tables. Eg.
--------| [Edit Me] |--------| <click me> |--------Etc.
The main thing I leaned was to separate concerns. It’s becomes very hard to parse as you add new fancy markup features. So I ended up only putting id and class labels (I was using if for HTML) in these layout tables instead, and then in another section, mapped to the id or class, I’d “ascii” what was to go in them. Eg.
--------| #edit |--------| #submit |--------edit:
[Edit Me]
#submit: <click me>In any case I think the general approach has a lot of potential.
-
Interesting stuff Trans. Do you have the code? (I had a look on your link – cool stuff – but couldn’t see the generator)
You’re right about separating concerns. Adding new markup features/diagram elements starts to detract from the simplicity of the tool. It starts to look messy and diagram maintenance goes up too, thus reducing the flow.
I sometimes wish that we could somehow have a text editor with layers like Photoshop has. Once you need features at another level of abstraction, you could just add a new layer to the model. You’d just select the layer/level of abstraction you want to work in. Obviously you’d then need refactoring too, so that when you rename/delete something it prompts to cascade the operation to related items in other layers.
-
The great thing about using low-fidelity prototypes during the customer approval cycle is that they get many accessibility concerns met up-front. Your text representation can be restructured into semantic HTML directly, before you add on the visual design and interactivity. This gives you an instant preview of what your web page should look like when the CSS and Javascript are turned off—the way they would be if your site were being browsed with a text parser or a speech-enabled browser. Then, as you develop the full site, you can keep checking back with the prototype to make sure you don’t break the core functionality.