AuthorJet

I'd like to validate the following sentiment that dawned at me.

Wireframes and prototypes suggest primarily that the design solutions are presented visually, annotated with callouts or footnotes at the sidebar.

However, the same thing can be also presented in form of documentation (text or spreadsheet) . Moreover, during certain phases of wireframing/prototyping, it is often more desirable to abstract from the visual layouts and rather to work with the documentation.

My idea is that the wireframing/prototyping tool should allow the designer to work with the both views (visual and documental) simultaneously or interchangeably, when either is more appropriate. While the both views share the same data source, i.e. the changes made to the wireframe are reflected in the documentation, and vice versa.

The existing tools used for wireframing and prototyping seem to underestimate the frequent need for annotating and documenting design elements. If you need to annotate something, you a) draw your footnote or callout as a yet another graphic object, and maintain its connection to the annotated object manually, because the tool does not "understand" it is an annotation or b) select the element to be annotated and enter plain text somewhere far in the sidebar "Properties" panel, and then lose it out of sight when you select something else. Both approaches become clunky when you need to create different layers of annotations for different audiences, which is a common task.

Afterwards, the existing tools can usually spit out a functional spec in Word or PDF that is rather a formal red-tape "deliverable". Or if you are not satisfied, you can go to a word processor or a spreadsheet and write the documentation manually (and I often do) , but then it will not be connected to the wireframe/prototype anyhow but in your mind, so you have to maintain them in sync manually as well. Besides, you find yourself dealing with many documents and tools instead of one.

Am I on the right track? What are your hardest challenges of documenting design? Have I overlooked something?

Download the Prototype App and look at:

• The HTML Content panel at the bottom: select a widget and just type the HTML code in the panel's text box, and the widget will immediately display the content.
  
• CSS - you can apply styles from an external CSS using the Provide CSS button. See the example CSS file included in the downloaded ZIP.
  
• The Auto-Size to Content button: select a widget and make it resize to fit its HTML content and/or child widgets - a very handy feature!

While I feel quite confident with HTML and CSS, it seems to take a bit of pain to use Dreamweaver for wireframing, perhaps because it tends to force you into detail too early, when you are still on the "vision" stage of the process, and feel like a WYSIWYG tool would be more appropriate.

On the other hand, wireframing in the WYSIWYG way entirely without HTML also feels wrong, because first, the target medium is Web so it's closer to the reality to think in HTML, and second, HTML is a powerful and expressive language, and quite a mature one. In fact, all those WYSIWYG tools in their development tend to invent (unnecessarily) their own pseudo-languages to imitate a subset of HTML.

This opposition causes a lot of debates on HTML vs. WYSIWYG wireframing and prototyping in the designer community.

I am now trying to hit the balance between these two approaches. I have created a prototype of a wireframing tool, where you can move and resize widget boxes freely on the page in a WYSIWYG manner (based on the wireframe editor prototype I presented you earlier) and then insert tidy pieces of HTML into those boxes. All styling is guided by an external CSS file you can provide.



This prototype is fully HTML-based. It displays and behaves exactly like if it were an HTML page. In fact, you can think of those widgets as DIV-s that are absolutely positioned on an HTML page. Yet you have all the power of WYSIWYG at your disposal. A special bonus of my prototype is that it allows testing what happens to your layout when you resize the page, or any section of it. WYSIWYG editors do not allow this as a rule.

For more convenience, and also for those who are not very intimate with HTML, I am planning to add a library of HTML "snippets" that will represent typical content assets, controls or even entire design patterns from various different UI libraries etc. Another idea for the future is to use XSLT transformations to populate the wireframes with data from external sources, such as XML files and databases.

Coming up next: Annotation and documentation features.

Download the Prototype App

Download the Prototype App and look at:

• Elastic widgets and automatic guides
  
• Container widgets
  
• Docking
  
• Anchoring
  
• Snapping

I'm very thankful for all the interest and feedback I have received from the IXDA community about my table-based wireframe editor prototype. At the bottom line, the initial idea has been criticized (justly) for its inability to handle floating elements, which are common in Web 2.0 applications. On the other hand, everybody liked the easiness of moving content assets between table cells and the way how the assets got automatically aligned.

I have tried to combine the benefits of the two approaches (widget-based editor vs. table-based editor), and added some candy from the best widget-based layout editors I know.



The new prototype is widget-based, but the widgets are now elastic. Namely, when some widgets are aligned to each other by any of their borders, and you move the mouse over that border, an automatic guide appears. You can drag that guide, and all adjacent widgets at once update their positions and sizes. This is how I achieve the easiness of modifying layouts like in the previous table-based prototype. Yet you can still resize and position any particular widget arbitrarily on the page.

What I also really like about the widget-based approach, and I have implemented it in my new prototype as well, is the container widgets. Any widget can be a container, i.e. have child widgets, which also can have child widgets and so on. Just double-click any widget and you can edit its children. The ability to encapsulate a set of widgets inside a container means easier change management, reusable widget groups and just better design due to fewer dependencies between widgets.

To make the encapsulation even more powerful, I have implemented the anchoring and docking features that you might know from Microsoft Expression Blend. These features allow maintaining the desired layout of child widgets even when the container is resized. Play with the example wireframe - try to resize the page and the widgets - and you will see how anchoring and docking actually work. Anchoring means you can tie any border of a widget to the corresponding border of the parent container, so that the distance between them will remain constant when the parent is resized. Docking means you can make a widget occupy all the available space at the specified parent's border, or between other sibling widgets (respecting the z-order). Docking has a higher priority over anchoring.

With the topping of nifty snapping (to grid, to other widgets, with the corresponding highlight), this new prototype seems to be pretty promising. Can't wait to see your feedback!

Coming up next: Adding sample content to the gray boxes of widgets.

Download the Prototype App

Download the Prototype App

All drawing and diagramming tools that we use to create wireframes are based on shapes or widgets. You drag a widget from a palette and drop it onto the page, then set its position and size with mouse. The operation is easier if the editor supports snapping to the grid and guides.

I wonder however if this is the optimal way of drawing wireframes, because it doesn't account for their peculiarities, namely:

• Content rectangles never overlap each other but cover the entire page "real estate"
  
• Content rectangles are mostly aligned in columns and rows, i.e. often have one or more of their boundaries aligned to each other
  
• During design, content areas frequently need to be rearranged – columns and rows are resized, content areas are swapped etc.

So, I've got the idea that instead of presenting each content rectangle as a separate widget, we could present the entire page layout as a table, where content assets go into the cells. Much like you draw tables in Microsoft Word or in Macromedia Dreamweaver, you split the whole page area into arbitrary cells with horizontal and vertical lines. Then you drag-and-drop content assets into the cells, and they automatically take up the entire cell space.

Afterwards, when you need to resize a column or a row, you just drag a table line. This is unlike widget-based editors, where you would need to resize and reposition each affected widget along the table line. Also, moving content assets between cells and swapping assets is much easier with the table-based editor.

I want to test this idea. I have created a prototype application which you can download and play with. I'd like to hear your comments. Is it going to speed up wireframing? What are the other pro and cons of this approach?