Managing Wireframes More Effectively in OmniGraffle
I’ve been using OmniGraffle as my primary tool for wireframing (and most everything else) for about 3 years. In that time I feel like I’ve gotten pretty good at using it efficiently, but I do try to keep an eye out for new tips and tricks. Recently, I’ve been following along as the documentation geniuses at EightShapes have developed and released their InDesign-based documentation system called Unify. I was intrigued by one idea in particular: keeping wireframes and wireframe documents as separate files.
Continue reading "Managing Wireframes More Effectively in OmniGraffle"
Testing Web Text Readability
Since my post about line length on the web got a bit of attention, much of it calling for more research, I figured we could help out with that a bit.
We've written up a brief reading comprehension test that can help us figure out if there are conclusions to be made about web text readability in different conditions. It's fast, it features a fun and quirky Cory Doctorow story, and it needs your input.
So head on over to the readability test and spend 10-15 mins to help us gather some great results. While you're at it, try to get everyone you know to take it as well, eh?
Once we've gotten a decent sample, we'll post the results here, so stay tuned.
Sketching in the Kickoff Meeting
I recently had to deal with a frustrating (but relatively common) problem: A client had a pretty clear idea of what they wanted, but that idea wasn’t clearly communicated in the RFP. We went through a few iterations of wireframes, and finally found a design that felt comfortable to everyone. We plan our engagements with just this approach in mind. However, I couldn’t help but wonder if we could have gotten to that point sooner if we’d been able to take the picture the client already had in their head and use it as our starting point.
The Line Length Misconception
Classically-trained designers, and really every professional designer, should know the old adage that long line lengths can have a counterproductive impact on readability. The trusty copy of Bringhurst's authoritative The Elements of Typographic Style makes this rule fairly cut-and-dry:
Anything from 45 to 75 characters is widely-regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal.
So naturally, when designers work on the web, they're keeping this rule in mind. Consequently, it's become a best practice on the web to keep line lengths below 75 characters, and this best practice has been the source of dissent against movements for things like variable-width (fluid) layouts and the like.
But research doesn't support this claim, at least on the web. Instead, users are able to read significantly longer line lengths on the web, and it actually increases efficiency and comprehension.
Prototyping with Production Purposes in Mind
(X)HTML Prototyping and Agile Development go hand in hand. When working in a faster, more iterative process, there are definite benefits to using (X)HTML in communicating an interface and the various flows users traverse through them. Along with those benefits come challenges that many UX professionals continue to wrestle with. Existing wrestling matches aside, another challenge presents itself once the prototyping phase has served its initial purpose. After that point, do you throw away that Front End Development work or re-cycle it into the foundation of the project to be visually designed and technically developed?
Continue reading "Prototyping with Production Purposes in Mind"