Image Image Image Image Image
Scroll to Top

To Top

User Experience

Beyond Lorem Ipsum and why QWERTYUIOP ASDFGHJKL is not good enough.

On 27, Sep 2010 | 4 Comments | In User Experience | By Ryan Feeley

Whether you’re presenting designs for software interfaces, or working versions of software, using good example data can make the difference between a presentation that goes smoothly and a stuttering mess of interruptions.

Ham-fisted developers often have the tendency to SAgfjhtdFYT ITRYFITY their way through form fields when testing application forms, and this soon leads to an interface that bears no resemblance its real-world existence. Worse still, they erase all data from the application with each build so that the interface remains in an “infant” state.

Why use good example data?

  • Enjoy distraction-free presentations. Never again hear “Those dates are wrong.” “That name appears twice.” “That’s not in alphabetical order.” etc.
  • Identify short-coming in the design. Will designs scale to fit content? Will truncation handling be necessary?
  • Find bugs. Does auto-complete work properly? Will it handle non-alphanumeric characters?
  • Mitigate developer aversion to complexity Though it pains them, real-world data reveal bugs earlier and helps developers build better tests.

How can example data best be used?

  • Pre-sort the data so it appears in the desired alphabetical and/or chronological order.
  • For wireframes, use names consistently to better illustrate a real user scenario.
  • De-duplicate examples to avoid confusion.
  • Compile large example sets of data that populate the application with each build.

What tools can help me create better example data?

  • The classic Lorem Ipsum generator is best used sparingly for user-generated paragraphs of text like bio, notes, description. Using it to complete our incomplete design is not advised.
  • The Calendar Date Generator from RANDOM.ORG allows you to generate random calendar dates useful for inboxes, tables and… um… calendars.
  • The Integer Generator from RANDOM.ORG allows you to generate random integers for things like phone numbers, file sizes, and quantities.
  • The Random Name Generator uses data from the US Census to randomly generate male and female names. Most useful for names, but with a bit of processing can be useful to generate usernames, and domains.
  • Existing files are a great source of data. Use Google’s filetype operator to find Excel files, CSV files or plain text files

Have your own favourites? Please post in the comments and I’ll update this post accordingly.

Comments

  1. Great advice Ryan. I prefer demos with real data as I focus on the app and not the data.

  2. Steve Miller

    Nice collection of tools Ryan, gonna add those to my collection. It’s funny… because i came into this field from a writing background it was always my first instinct to “write” my interfaces. In addition to the benefits you mention above I’d also add that it helps you work out the design – not just for the truncation, etc., but I find when I’m thinking through things like instructional text I often identify opportunities or problems with the interface I’ve just designed. Nice post.

  3. Thanks Steve & Jamie!

  4. I couldn’t agree more regarding the scourge of ASDFGHJKL and the importance of real data. As a front-ender, the sooner you can begin working with it, the better …and for all the reasons you outlined.

    It’s the reason that I asked a developer to help me begin piecing together a better solution… which eventually gelled into an open source toolkit called Dummy – http://dummy.kerns.dk

    Dummy provides a simple way to automate the rotation of believable looking data into what would otherwise be a static, disconnected layout. This could be standard data that ships with the tool, or data you add/edit yourself. Because these text assets are just flat txt files, they are easy to modify and amend on a per project basis.

    And it out-performs even real real data in one significant way in that it is ALWAYS changing…every string of text and on every load of the page. Subsequent reloads of a document become like watching a time-lapse of a normal test phase.

    Test cycles speed up accordingly, as the chaos unleashed on a layout reveals weak points, trouble areas, etc…all the advantages you list in this post. Just accelerated, on steroids, to borrow a cliché. You could think of it like load testing for your design and underlying CSS structure.

    Please have a look, maybe add it to the tools section of this post if you find it useful.

Submit a Comment