Generally speaking I have 2 gripes with wireframes. One is that they're very limited and come with issues in terms of communicating design. Secondly, they're not fast and flexible enough as communication artifacts.
HTML wireframes and prototypes provide some relief from some of the issues, and I'd like to hear what other people are looking for when doing HTML wireframes in order to fix and overcome the limitations of wireframes made in graphics software.
First, here is my gripe list. And for clarity, I use OmniGraffle primarily to create wireframes now.
Limitations for communicating design
1) People have to learn to read low fidelity schematics
You end up with clumsy disclaimers about design, people focus on their rough aesthetics rather than on functionality, etc. This is why so many people find sketch-style artifacts useful. The "unfinished" quality allows people to get past the surface qualities because the final product obviously won't look like that.
2) People sometimes expect them to demonstrate final visual design
This is the other end of the fidelity spectrum. People just have a hard time with both gray box diagrams and with detailed wireframes. Some repeated education and introduction to the wireframe is needed to summarize the purpose it serves.
Limitations when producing wireframes
1) Components are not reusable as updatable instances
Some applications allow you to use stencils and external files imported into a document. But they don't have the behavior of instances, as Flash does, where updating the master object updates instances. You can fake this in some tools, and other tools provide real libraries, e.g. Fireworks. Flex's UI Component Library may come closest to what I'm looking for--library items that can be instantiated and properties customized. The extension of this is to allow the component to be saved and extended so it can be re-used, i.e. a private library.
2) Common behaviors have to be represented multiple times--CRUD, design pattern
A lot of these behaviors can be represented in a design pattern library perhaps. What I've done in the past is to create storyboards for common behaviors across a document, so that their behaviors need only be represented once. Something like this is useful if it can be used with the local library ideas mentioned above. Create a local library of components and they only need to be designed once. Insert where needed in the prototype and the behavior is identical. A separate document can be created to demonstrate all of these and perhaps organize them for developers to view.
3) Some people expect them to be updated constantly, which is hard given the re-use issues
The goal is to both make these easier to update globally and to make small changes. Issues related to this include version control and rolling back changes. This also would be an issue for library components. Documents and libraries can be backed up for brute force versioning, but use of version control systems would be ideal.
4) They're time consuming and therefore costly to make, as opposed to sketching.
I'm still not sure if HTML wireframes will come with time savings, but I am hopeful that their ability to demonstrate ideas more clearly and effectively wipes out those costs by allowing shorter iterations.
What are your gripes?
Do you have any other ideas about what needs to be fixed about wireframes? This is an effort at a "Pony" brainstorming meeting (as in "I want a pony!") to see what other people want to solve with html wireframes that graphic wireframes fail at.
If you want to participate in our project to assemble an HTML prototyping kit, please read our mission statement and find out how to get involved.