How do I annotate a mockup image? [closed]

Question

I need to specify colors, font-sizes, space between elements, sizes, etc right in a mockup picture for people who will work on a layout. What is the best way for doing it?

Answer 1

For annotating the mockups, it's good to use a tool like specctr, but anything which gives you a new layer is fine.

You mentioned that fireworks is not part of your toolset right now (it's a very nice tool), well, specctr is expected to have a photoshop version sooner or later, but on the other side, it's a matter of a few lines. Tools like Microsoft Office, Google Illustrator or OmniGraffle might help you, or any vector editor for the matter - you load the raster graphics on one side, and you add arrows and annotation to this background on the other side.

But the whole point of such documents is not this usually.

Think of it what will be needed on the other side.

Usually, your mockup will be used in order to develop a CSS-based webpage. The more you know about what does it take to build a CSS-based website, the more you know about what to include.

CSS defines margins, borders and padding. It has usually a top-to-bottom approach, with left-to-right painfully added to the process with some tricks (I never understood why the authors of CSS didn't incorporate a proper handling of the horizontal dimension).

Horizontal handling is usually approached either by table-celling or, more commonly, floating. The underlying trick is easier if you have a grid system in your design. In case you have such a grid system, make sure you communicate this grid to the developers as well.

Nowadays, it's important to have a "responsive" design, which is a short term for "Android devices have too many different screensizes but all of them are small". It means that in case people look at the application / webpage designed by you on a mobile screen, it might have to look differently.

Google for responsive css grid to understand the options the developers have right now. I don't claim you have to choose one of them but you have to understand the overall concept of responsive grids.

CSS also defines classes, that is, a group of properties shared by a bunch of objects. If all your headers are expected to be set in blue, with Univers font, and 18 point x-size, you can group these together to a class called ".header". Notice the . in the beginning, that means it's a class. Multiple classes can be applied to a given element, eg. it could be that you have "green" headers and "blue" headers. that is .blue.header and .green.header CSS-wise.

Although CSS in itself doesn't support it, it's wise to keep variables. Variables are your specific choices which you use over-and-over. Eg. if you used a color wheel, and decided you need a blue in the shade of a cornflower, instead of using its hex-triplet color code #6495ED, it's better if you define your color this way, like $cornflower: #6495ED, and use background-color: $cornflower or color: $cornflower (for text color) in the wireframes, it makes your design easier to understand.

All in all, make sure, there's not just the hows there but also the whys. A programmer might not understand why you need a certain feature, and if it's hard to do, (s)he might just leave that one out. I understand that for you, the design concept is an integrated whole, but a programmer just won't care.

What I'd enjoy:

• color definitions up front (what color is used for what), in hex triplets
• font definitions up front (what typography is used for what), along with typical font sizes (size of body font, size of first level fonts, etc), illustrated
• definition of the macrotypography with annotated examples, for all expected elements:
  • body text
  • menu items
  • list items (along with spaces before and after the bullet, and bullet shape)
  • quote blocks (how it should look like if a source is quoted)
  • header styles and their hierarchy
  • presentation of links
• iconography, also in a separate, single image file with no text (used for CSS spriting), like here
• layouts, annotated only by what's not trivial based on the previous section, (eg, if there are two similarly looking elements, define which is which; also use classes from the previous sections), along with your grid.
• widths defined in terms of a grid system (eg, 2-columns, 3-columns, etc)
• widget definitions, using margin-padding-border definitions and widths on grid
• notes on how the layout should alter on a mobile device

This is how a decent style guide looks like (and I've got some from professional designers without even being this specific). It denotes what's good, what's wrong, and it's an awful lot of work and thinking, which evokes respect towards the designer.

Of course, some parts might be unfeasible and then you have to redesign. Design is an iterative process, it should employ a dialogue between client, designer and developer. It's true that there are lazy developers who don't want to do what's otherwise possible, but there are also lazy designers as well, who don't incorporate any knowledge of the medium (eg, what if the text is larger than their Lorem Ipsum). You have to sort it out, perhaps ask another developer friend personally if the given feature is possible or not.

If you disintegrate all your thinking into such a decent document, then you'll have less annotations, and something which is perhaps easier to handle, grasp or process by developers. You'll also have a clear visual language, as nothing will be left arbitrary: no arbitrary font choices, no arbitrary color choices, you have a "dictionary" for your visual language.

Even the most rudimentary applications, like Jing can be used for layouts:

As you see, it's pretty rudimentary, we could say, it's downright ugly. But still, it could be enough to convey the message through if you have all the rest dispersed through a consistent styling document.