Mockup Tips: Datagrids and Specifying Interaction
We often get questions about how to do complex things in Mockups. I think the best bet is try to design with minimalism in mind. That goes equally for simplying your wireframes as well as your interface.
One of things we get asked about a lot is formatting tables, aka datagrids. For the most part, formatting tips for columns can be found in our documentation. But you may or may not know that text inside the datagrids may be styled using our wiki-style text formatting syntax.
Here's an example I re-created based on a customer question we got recently for designing a table with formatted text, icons, and links inside the table.
[The image above was based on a mockup made provided by w3pllc.com.]
It's not entirely simple to do complex tables like this, but if you need to, you can. You just have to use some of our formatting and text syntax to make things fit well.
Mockups is made for wireframing, not prototyping. But people need to describe and specify interaction and behaviors. Typically in a wireframe you do this in one of several ways:
Techniques for demonstrating interaction (complex to simple):
- Create click through wireframes showing the state change in subsequent compies of the wireframe, i.e. create multiple duplicate mockups use links to demonstrate changes
- Use a storyboard to show the change in state for the relevant element, e.g. changes to a component in a page.
- Use callouts and show the state change in the wireframe--useful for single state changes, but you still have to describe subsequent effects of actions.
A lot of the storyboarding techniques we use in wireframing are borrowed from film and animation, where artists dealing with time have found ways to markup and show keyframes. The screenshot above shows the last technique, a simplified version way of showing state changes that I tend to do.
As an in-house interaction designer I've tended to use as few words and pictures as possible to describe behaviors if I know that I can communicate the idea, or can reference a design pattern that I know my team is familiar with because I may have described in greater detail elsewhere.
The object for me in doing wireframes is to get far enough in specifying the interface until the idea is understood and agreed upon, iterated on, or scrapped. If you can't do that with the simpler techqnique and you need to describe behavior more completely, then you move up in the order of complexity to specifying more. But I think the ideal is that you capture and communicate the idea as simply as possible and then build something.
This is just one way of looking at the difference between wireframing and prototyping. We fit in a place that satisfies the needs of the designer/developer looking for the simpler end of the spectrum. Hopefully this describes one way of doing that.