Web User Interface Architect

Won't tell you how to do things; will describe what I do and has worked best for me over years.

Filed under: Interactive Mockups

Tips: Building Wireframes for Web UI

The nature of UI development is so complex that fitting it into a set of rules is simply not possible. The only way to become a pro in this field is only through constant practice and efforts to better the results by learning more out of small mistakes.

When one is working on a wireframing (also called as 'interactive mockups') assignment, the very first difficult thing is to plan your bits and pieces across HTML and CSS. Things keep changing all the time; so whatever you do, must be flexible enough. This is not possible most of the time and that shouldn't de-motivate you from delivering quality. Do not hesitate to go back to completed wireframes as many times as required and revise them. You will face a lot of reluctance from the developers in this process, but just keep one thing in mind - the only thing that matters at the end is the quality; no one will ever bother to listen to your excuses. So, don't worry about the re-work trouble you are creating for others; this has to be done.

I usually try to follow these tips (I expect readers of this article to be familiar with building HTML wireframes. So forgive me for not providing detailed explanation on each tip. Also, please note, this is what I believe and follow; it may or may not suit everyone out there; so please be kind enough to ignore what doesn't seem right for you)

  • Request for as many screen mockups (PSD or whatever your designers use) as possible before starting. Talk to your manager/client/team lead/visualizer to get as much idea about the application as possible and thereby, understand the expected user experience flow before-hand. Ask for sketches or anything that will give you a rough idea about the rest of the screens in the application.
  • Once you have the base ready to start your work, put everything together at one place (I usually keep it under a folder called 'source') so that you can refer to all of them at any point you wish. Believe me you will be hitting this place more often than anything else.
  • Before starting, go through all screens, preferably arranged in user experience flow order, as many times as you can; slowly. Identify the repetitive elements and plan immediately how you are going to structure them.
  • Now think whether you can employ a common layout template. First, plan everything (HTML, CSS, JavaScript) in your mind. Remember that age-old saying, "Everything happens twice. Even God created this Universe twice; first, in mind and then in real."
  • Structure your files properly. I usually follow this basic template:

    <application-root>
    |----    index.html
    |----    {other html files}
    |----    <stylesheets>
             |----    common.css
             |----    home.css (and so on)
    |----    <javascripts>
             |----    common.js
             |----    messages.js (internationalization/localization) - never use hard-coded strings in your JS code
             |----    home.js (and so on)
    |----    <images>

  • I use HTML5 doctype and I recommend that to everyone. Don't worry, all browsers support it. Yes, IE6, too!! So, the top of every HTML file I code, looks like this

    <!DOCTYPE html>
    <html>
        <head>
            <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
            <title>....

  • Keep validating your HTML before every 'file close' action on your HTML document. I use gedit and rely on http://validator.w3.org/#validate_by_input - which works pretty well for me.
  • Try to make your HTML structure support SEO well, even if your application specs didn't mention about it.
  • Keep your HTML clean - absolutely NO CSS or JavaScript
  • Use <table>s. What??? Yes, not for layouts, but wherever there is tabular data in the content, use tables.
  • Make sure every 'clickable' text uses anchor. Don't just hook-up JavaScript handler to a span, div or an li element. (Talk to someone from QA if you are in doubt over this :P)
  • For CSS, stick to the thumb rule - no inline styles. Not even the jQuery $(".blah").show() or hide(). Define an application level CSS class .hiddenEle {display: none;} and toggle (add/remove) the class through JavaScript.
  • The CSS class names should be brief; but don't mind using a narrative name rather than something absurd. You can always gzip your resources later.
  • Avoid defining a CSS class by an element id as much as possible; unless you are very sure that there is absolutely no scope for the style definition to be reused anywhere else in the application. e.g. #myElement {...}.
  • Never declare a CSS class by HTML tag name. e.g. body {...}. (A brief discussion with a colleague about it - http://www.webuiarchitect.com/never-declare-a-tag-level-css-class-0 )
  • If you see any inconsistency in the design elements across the screens given to you; please don't be shy to point it out. Nobody is perfect. And your suggestion is to improve the user experience, so fight for it, if you need to. This is going to make your work more interesting and add substantial value to what you do. So don't sit there like a clerk.
  • It is quite possible that you identify a common pattern a bit late in the design process. Pull it out immediately in common.css. Revise the already delivered HTML pages. Talk to developers and make sure they take care of the changes at their end. Every time, you go back to them and ask for making changes, do not expect a warm welcome. Try to explain to them why the change is important. Those thoughts will be even more clear in your mind when you talk about it to others; making it sound in your own knowledge-base.
  • Ok, now on how to handle the God itself - JavaScript. I never had a doubt that JavaScript is the most powerful programming language, the machine race has ever seen. And with great power, comes even greater responsibility. Avoid using third-party ready-made widgets/plug-ins as much as possible. The whole developer world thinks they do a smart job by just utilizing the code already written by somebody else. Please try to understand, on a Web UI, even a slightest requirement difference can make the third-party plug-in either completely useless or a huge overhead. So adopt wisely, if you have to, at all. I would advice to stay away from it, unless what you need is a very complex component like a editable grid. Code everything yourself! Of course, use jQuery for the base. When it comes to Web UI development, believe me, it is totally different from any kind of development - all rules fail. What ultimately counts is experience - mainly from failures. So take my word - kill your urge to make use of pretty looking and so called smart-choice JavaScript plug-ins - they will make your life difficult later on. I just completed an assignment and like always, only used core JavaScript with some help from jQuery to add all event listener place-holders. Tabs, modal dialog, complex form elements and all; I did it on my own. It wasn't more than 4-5 lines of code each, anyway.
  • Use CSS rounded corners and shadows unless it comes to branding. Avoid images for buttons and section headers. If needed you can use background image; but big 'no' to text embedded in an image. Convince your manager/client on the performance benefits and inform about the small compromise. And let them take a call on it.
  • CSS sprites a must!!!
  • Double verify the image optimization your designers have done. Damn, you are fighting day and night for every KB that gets in through your code, and you don't want it getting nullified by improperly optimized images.
  • Please! please!! please!!! format your code (HTML, CSS and JavaScript) thoroughly. For indentation, I use 4 spaces as 1 tab; I have seen it a common practice.
  • Comment anywhere and everywhere - HTML, CSS, JavaScript. Don't think about file size here. Put comments on new line - especially HTML. Back-end developers normally use tools like Eclipse or Aptana where they could collapse/expand tags/code blocks. Having comments on separate lines will help in this case. The comments are anyway going out after compression process. What's more important here is making your developers' life easy; and they will love you for this.
  • Throughout the process keep talking to the designers - to learn about forthcoming changes; and to developers - to cross-check their comfort in adapting to your front-end. Take suggestions from both of them and implement wherever possible.
  • If you find any usability concern, raise your hand immediately. Remember, you are the first user.
  • Being socially active and aware helps in every aspect of life, but in UI development, it could be life saving. Hook yourself on Twitter and other social platforms and be in touch with professionals in this field. This thing keeps you running on your toes forever.
  • If you haven't already, then learn what HTML5 offers in totality. I loved everything it introduced; especially, the 'data-' attributes. HTML5 talks pure common-sense. (I am in the process of completing my article "HTML5: A-to-Z in brief" and will shortly post it here).
  • Keep all browsers from the specs matrix open while you work on each of the views. And test well before you deliver; especially before you deliver. It leaves a bad after-taste if someone finds out a small problem in your submission. So add those 2 extra, but crucial minutes to each cycle and have a good-night sleep.
  • Once the whole assignment is delivered, your job is done! You lazy bum, get up!!! It has just started. Now, how useful all your hard work will be, if one of the back-end person misses a closing tag!! Validate the end markup from the browser (served by the actual server) and even the AJAX updates (forgive me, I simply decline to write it as 'Ajax'). Also, make sure they are all aware of the resource distribution and compression techniques to score high on bandwidth.
  • When you take up the next wireframe assignment and learn something new which could also help in the previous project, have a casual talk about your findings with the respective manager/client. Believe me once again, they will appreciate it.
Posterous theme by Cory Watilo