Thanks!

I was wondering what chart widget did you use for this? Is it something you developed custom?

K.

Get some stakeholders in a room, have them write tasks on index cards, arrange the cards in roughly chronological order.

We might also set up an OpenJam session on it next year. Jeff Patton’s OpenJam on Story Mapping was really successful.  We could do one on personas, transitioning from design to development...something…

-isaacw

A related point: UI copy writing is an under-appreciated skill. I am amazed at my own reactions to the words that web apps use.

Twitter, for example, says “That’s a nice picture,” when you upload a new avatar. Yeah, it’s a machine. Yeah, it says that to all the girls. But you know what? I still get the warm fuzzies when I see it.

That kind of thought makes software fun to use and carries over into brand perception.

BJ Fogg’s book “Persuasive Technology” touches on similar ideas. He heads the Captology Lab at Stanford U. They do research into how we can design interfaces that prompt people to take a particular action.

Adam Greenfield’s “Everyware: The Dawning Age of Ubiquitous Computing” is only tangentially related to this topic. But I think it raises some issues of ethics, privacy, intrusion, and interfaces that are helpful to think about.

I, like Michael, am curious about what variables you have and have not accounted for. Do you calculate my default text size? Do you record whether I bump up the text size using browser text scaling or page zooming? (I didn’t, as I assumed you wanted me to not do this, but you might want to include that in your instructions.)

In any case, thanks for putting this together.

Let’s make another analogy, familiar to web designers, which might work out—we’ll see: in attempting to simplify something, you’re like an image compression algorithm. Ideally, you work like PNG, compressing and simplifying the image without a loss of quality, by removing unnecessary information that no one would have missed anyway.

PNG works well on many images, especially those that don’t need all the extra information and a large color palette.  It doesn’t work well on finely-detailed images or those that require a large number of colors.

Now, some of those images can be compressed with JPEG instead, but you run the risk of removing important information from the image. At best, this looks like minor artifacts around detailed parts of the image. At worst, it becomes unintelligible in comparison with the original.

Some images just can’t be significantly compressed, and will be a large image no matter what.

Long analogy almost over: sometimes ideas just can’t be compressed down to a tiny kernel. These ideas take explanation, detail, and will never be simple.  Trying to simplify these complex ideas is akin to applying JPEG with a low quality rating—you lose important details that matter.

Most of the time, good design is like PNG—removing unimportant information, while still providing a clear picture.

One cannot condemn simplicity in favor of something that should be complex simply because we are used to things that way. It is our job as designers to turn these very concepts around.

“Every day after a user begins learning your design, they move more toward that expert category.” Right on, it is the failure to foresee scalability that prevents users turning into power-users.

Andy Rutledge has an interesting post about this, Complex Order, Simple Chaos.

:) Well, I’m one of them so I just want to confirm some things and sort them out.

BTW, @Jackson This is a nice read. Thanks!

In our testing, which was done originally in 2002, we found that 72-96 had the best reading and retention rates. We saw reading and retention drop off around 110-112 characters per line (12-14px font size 1.125-1.5 line height). We’ve done a number of studies since, where line length wasn’t the focus of the study, but a secondary measurement, and we continue to see the same results today.

The crux of the issue is that people say they “prefer” to fill their browser windows, but when line lengths get over 110, they’re actually doing themselves harm, or creating sub-optimal situations.

I didn’t think about it, but you’re right about the cultural considerations. Do you have any references or resources pointing to why Asian societies value busy UI’s? (Other than just looking at their designs.)

Thanks! =)

It’s probably important to remember, in this discussion, that accessibility is not a standing target. Being accessible to a mass audience often means avoiding overwhelming a user, and is far different from being accessible to experts who usually want all relevant information. Every day after a user begins learning your design, they move more toward that expert category.

There are cultural considerations as well: Asian societies value a busy interface far more than one more simple.

@Karine: I don’t think today’s web *should* be about blind simplicity, but I think there are far too many examples that simple approaches are chosen when a more complex approach is really needed to solve the problem.

Today’s web is all about providing the simplest answer to a given problem. Yet, simplest can still be complex if you indeed take into account parameters that really matter.

Like the minimalist artwork of Sol Lewitt, there is beauty in simple rhythms, shapes, lines, forms, but I find work like the Issenheim Alterpiece to be unbelievably human and deeply compelling. The Altarpiece is complex, and possibly even over-busy by today’s standards, but it remains the more accessible piece by a greater number of people.

I wonder how those principles play into how we architect and design for the web?

It’s powerful stuff, even if it’s not tied to a mobile device.

On the 508-compliant project that went through ten iterations, I would copy the entire set of wireframes and add in the new functionality. The previous iteration’s signed and approved wireframes were saved for baseline purposes. Inevitably, post signoff, there are always additional changes, and when necessary, the wireframes would be updated. However, I still haven’t fully reconciled how to ensure the wireframes completely match all the functionality of the production version. For the most part, the last set of wireframes is a reasonably close match to production.

There has been some talk of creating our own custom UI control library with a corresponding list of visual icons. The IAs/UI designers could use the icons in the design and the development team would then know that those match up to a specific component in the UI control library. However, we haven’t fleshed this out yet. It seems like it would help by eliminating the IA/UI designer’s need to spend excessive time tweaking the HTML prototype, and the developers would already have a reusable component to start from and customize as necessary. It sounds efficient in theory, but I’d be curious to know if anyone else had implemented a solution of this sort.

I can read small print on a cereal box, but I sure don’t enjoy it. (But alas, I have nothing better to do at the breakfast table :)

Very useful tutorial!  Such a simple thing, but think how many UX lives it can make better.

It’s too bad you didn’t finish, or we’d have been able to see how the combination impacted you!

PPS: the lines spacing of the text in these comments here is much better than the one from your test.

I believe, a bigger line spacing would have improved readability of the textmuch more, than shorter lines would.
So here’s food for another stufy ;-)

Thanks for sharing,
Mike

It’s certainly a belief of mine that research should be readily available to the industries it impacts as much as possible.  For those who work on the web, “readily-available” is largely synonymous with “googleable.” If we were talking about a field dominated by academia, it would, I argue, be a different story.

I assert that a decent estimate you can put your hands on, as a practitioner in this field, is far better than the best-laid research you can’t. What we’re offering is an attempt at a decent estimate, and that’s all it claims to be.  I welcome your dissent as well as your support.

I don’t find it “unsatisfactory” that peer-reviewed research is published in actual journals. You seem to think everything should be Googlable. What if not everything should?

Really, you seem to be insisting that “dissent” disproves reputable scientific claims because you can’t search for and read those claims from your iPhone.

I’m not even going to bother with your pointless little demo. Hire a Ph.D. to run a real controlled experiment and then we’ll talk.

I found that XHTML prototyping makes sense when I free-lance and have a close relationship with my client. With less parties involved, I can take the time to explain UX, aesthetic, and behavioral decisions step by step, and gain the trust of the client by involving him that much in the process.

On the corporate level, however, some rules are fixed through strict guidelines, others through experience, and yet others are my personal view on the question after testing what works and what doesn’t. Showing an XHTML prototype or even a wireframe to the hierarchy is risky at best, for the amount of questions regarding revisions is unlimited. This environment leads me to favor non-recyclable work that is really explicit of the expected production level: a photoshop comp, sometimes as stand-alone, sometimes as background of an XHTML-enhanced prototype.

I guess my goals are different depending on the environment… In the first, it is a real dialog. In the second, I need validation as quickly and painlessly as possible. The discussion has not mention the client’s experience.

The line length was uncomfortable, but not so much to be unreadable. The terminology of the piece made it difficult to comprehend at first and I found myself re-reading whole sections. Also, knowing it was a test of some sort, I forced myself to read it more carefully than I might have under other conditions. The questions themselves were about pivotal or repetitive portions of the text.

I can’t help but wonder if those things will skew your results.

Still, I’m sure you’ve thought about some of this and I’m interested to know what your testing criteria are. I certainly appreciate something simple that continues the conversation while its hot. :)

I also want to read more about this now.

However, it’s a bit unsatisfactory that the relevant research isn’t terribly accessible to the people who need it most.

So today, we opened a bit of a research project that might help the situation a bit.  Head on over to http://readability.viget.com where we have a timed reading sample and some straight-forward comprehension questions.

Maybe we can come closer to some decent conclusions.

In other words, this post’s reliance on a single study is unwise.

@Carson — Glad to hear it’s working for you too!

@Brian — It ended up about 1:2 in terms of time spent sketching to doing the walkthroughs.

I’d imagine you’d want a good amount of time to extract concepts and goals from visual UI sketches with the client. How much of the allotted time have you been spending in executing the exercise versus reviewing its outcomes in meetings?

@anon, I’ve found that an internal cardsorting exercise, in an IA-driven project, can produce the same type of results, where clients are describing often specific content/functionality first which later generate (via a review) concepts and goals.

Keep getting the word out. Great stuff.

You really can’t have a productive discussion of line length without discussing height and spacing. This topic has been explored so extensively in real, peer-reviewed and published academic research studies that you can’t just say “Users will be perfectly fine reading longer columns of text.” It’s like saying “it’s perfectly fine to use Flash on any site you want” and leaving it as a blanket statement without even mentioning accessibility, seo, penetration, etc. It’s so vague and incomplete as to be misleading and effectively would be bad advice if followed literally.

To readers who want to know more, get on an academic research database and search for ‘readability’. There’s plenty of information out there waiting for those willing to search for it.

I find simpler and more efficient approach is to just create a bunch of grey boxes (using divs, 960.gs and some minimal CSS) to represent the layout of the new features, then fill those boxes with textual information about interactions, states and functionality. In the case of forms I just go ahead and markup the forms straight off. It is a very low-tech approach. :)

There is very little duplication of work doing it this way because you need that markup anyway, and the only CSS you need is to color the boxes different shades of grey to differentiate them from each other.

Incidentally I found a jQuery library the other day that you could use if you want to get a bit more sophisticated with representing different states in your wireframes: http://24ways.org/2008/easier-page-states-for-wireframes

That said, this is an area that could probably use some more research/study. The medium (paper vs lcd) may affect this rule, but only in the sense that the light coming off the screen will burn your eyes out.

Plus research should never stop.

1. To help the reader easily find the next line of text.
2. To cause less distractions.
3. To not tire the reader.

All 3 improve readability. Speed and efficiency aren’t the main priorities of the rule. Speed actually doesn’t matter at all and faster reading could affect comprehension.

I think test is flawed because it’s measure the wrong attributes.

@John, I’m curious how you’ve managed the wireframe styling/presentation of new pages when working in a currently designed app/site. Do you have separate CSS files for wireframes and the final site design? Also, when working in these new pages, how do you find yourself describing interactions, states and functionality?

I like the idea of making this work more transparent to the client through your suggestion of weekly releases. It definitely fosters education on the design/UX process and why its there. I’d assume you’d need to set expectations with your client in a few ways with these releases, but aside from that, have you noticed any downsides to working this way?

For example, I can think of a couple of reasons why line-length MAY be allowed to get longer on the web:

a) Writing *tends* to be in shorter paragraphs, broken up by blockquotes, lists, and other visual clues. Links, bold/italic text, and other graphics alongside the copy can all aid the eye when returning to the beginning of the line.

b) For some readers, the distance between the top of the viewport (think of this like a ruler or bookmark) might be much closer to the text itself than the top edge of a book (if no other aid is available). This can aid visual location, and scrolling down a page is natural and easy whilst reading a long article.

Based on my current understanding of the (limited) research I’ve read based on Tiff’s reply, though, the way we read would be impacted less favorably by the distance to the object than one might expect.

My understanding is that the time involved in the eye movements made while reading is fairly negligible, while the fixation of the eye on a set of characters is really what’s taking up the time.