 |
« | Week of Jul 20 | < | Individual Entries | > | Week of Aug 3 | » |  |
 |
 |
roBlog's Scannability
internet, personal, writing & communication
August 02, 2003, 10:15 PM
Neema told me yesterday that he finds all the content on this weblog hard to digest. He suggested I provide a summary or bulleted "main points" section for each points so he could get the gist of the content without having to read the entire article.
I tend to post a lot of content on this forum because I see it primarily as a form of personal reflection and only secondarily as a form of communication. However, I'd love to improve on the second goal if there are ways of doing it without sacraficing the first, and I do realize that having several paragraphs of dense text is asking a lot from my loyal readers :). So I'm open to comments, ideas, and criticisms on how best to fix this problem.
For now, I'm trying a technique Jacob Nielsen uses on his Alertbox: he recommends highlighting important words and phrases to improve scannability. Personally, I feel this makes his essays "shout" a bit too much, but I'll give it a shot anyway. Feedback would be greatly appreciated.
Email Rob:
A Foray into the Asylum
software development, usability
August 01, 2003, 12:41 AM
I've finally gotten around to reading Alan Cooper's "The Inmates are Running the Asylum", something I felt I should do since I'm pushing personas and Goal-Directed Design as a key component of open-source usability (in my defense, I have read several articles about personas while researching this project, just never one of Cooper's books). I've skipped the first half of the book since I hear its just a long rant about how programmers don't know how to design software systems for users. I picked up where he starts getting into the real meat of his techniques.
First off, I'm in the process of revising Newsable's personas to make them a little more specific, a little more human, and to give them explicit goals. Mathilde made most of these suggestions when she read the personas; I waffled on changing them for a variety of reasons but now I think she was right and I was wrong, as is often the case ("Correct as usual, your majesty"). Those changes should be up in a day or two.
I liked Cooper's arguments in favor of focusing on a single, primary persona for your design, on the need to get away from the "elastic user" whose personality, goals, and desires change from situation to situation depending on the current needs of the developers and managers. Cooper's description bolsters my hope that this technique will help bring more coherence to usability discussions about open source software. Ideally, it will end the "creeping features compromise" that plagues so many projects, where new features are added because someone felt like coding them, not because most of the users want them (which also leads to confusingly crowded preferences dialog boxes). On the other hand, I'm concerned about how this narrow focus will play with potential project contributors who don't fit the persona. Will they be turned off by the lack of attention to their needs, thus losing valuable help? Would it be sufficient to capture them as secondary personas? These are some of the questions I hope to discover the answers to.
Just to throw out a couple more thoughts while I'm on the topic: Cooper argues vehemently for "polite" software; he quotes Clifford Nass's work which demonstrates that people interact with computers in a very similar fashion to the way they interact with humans, even people who "know better", i.e., Stanford computer science undergraduates (as an aside, Cliff Nass gave a talk here at CMU last fall, which was excellent and drove home this very same point in the area of speech interfaces). So he proceeds to list a series of characteristics which are intended to make software more polite. Which is all well and good, but on the surface many of these heuristics are pretty obvious. The hard part comes in trading them off against one another as well as other usability concerns, something Cooper hasn't given much guidance on yet. For instance, Cooper asserts that "polite software is taciturn about its personal problems"; he complains "I don't need to hear the modem whistling or see information about the computer's data transfer rates..." Yet I often find this information essential for troubleshooting when things go wrong (if I don't hear the modem whistle, maybe the wire isn't plugged in?) Granted, a perfect interface would deduce the problem itself and tell me how to fix it, thus bypassing the need for such arcane techniques, but given that the interface does not do this (probably because it would be too time-consuming to implement), I'd like to keep my modem whistle, thank-you-very-much.
Which leads to my second point; Cooper is either quite naive about many implementation issues or he is purposefully ignoring them. Many of the problems he decries (such as how all his personal preferences aren't shared among all his computer's software applications) are the result of interoperability problems which spring from social and market failures; different companies have little incentive to make their products share such information. And some of what he recommends is just outright tough to implement; polite software may anticipate our needs, but predicting the future is often hard and may require sophisticated predictive models of human behavior. Bonnie considers this an interesting research question, but even she will probably admit we aren't there yet in terms of mass commercialization.
Ordinarily I wouldn't harp on these points at such length, but I strongly believe they are important for interaction designers and usability professionals to understand. If all of them adopt Cooper's attitude (basically, "damn the implementation; usability is the only consideration!"), then I fear for the fate of interdisciplinary collaboration, which is so essential for producing usable, "sane" software.
Posted by Jeff on August 01, 2003 at 11:25 PM
Cooper's attitude toward programmers often stands in the way of his message. That's unfortunate. It's hard to get past hundreds of pages pointing out fault, but I still think the first half of the book is above being dismissed. One example: the articulation of the gulf between users, programmers, marketers and designers provides helpful insight into the building of successful collaborations.
Posted by Rob on August 03, 2003 at 12:27 PM
Hi Jeff,
His attitude does make things difficult. I'm reluctant to recommend "Inmates" to other programmers, despite the many great ideas and high-quality, readable discussions of them, because I'm afraid his attitude will turn them off. I'm sympathetic to usability and interaction design, but I know many people who are less, shall we say, "inclusive" than I am. I'll buy your point that there are probably more insightful ideas in "Inmates", but I'd argue that a less vitrolic presentation would be worth much more. I'd point to "Extreme Programming Explained" and "Agile Software Development" as excellent examples of books that discuss how marketers, users, and programmers differ while giving the sense that everyone has something to contribute and is a valuable part of the process (both books, sadly, have little to say about design and usability; an oversight that I hope will be corrected in the future).
Email Rob:
Quality, Quantity, Progress, and Design in the World
aesthetics, design, society & sociology
July 29, 2003, 12:51 AM
Once again, CDF has reset itself and we've procured a new teacher. This week its Craig Vogel, an industrial design teacher with a penchant for waxing philosophic on the nature of design and its place in society.
Craig described the design problem as a process of understanding the existing world and then envisioning the world in a new, preferred state. Progress, then, is moving from the first to the second. I've described something similar in my definition of design. Yet people have different definitions of "preferred", as I hinted at in my earlier post. Some argue that modern society's concept of a preferred state of the world, and perhaps even its understanding of the existing state, is short-sighted, misled, or even downright inhumane. Craig mentioned an environmentalist architect (whose name escapes me) who felt this way. I thought of an old roommate back in college, Eric, who passionately believed that architecture and urban planning could be conducted in harmony with the environment, leading to a better world for all, except that society didn't value these things and thus they never entered into these visions for a preferred state of the world. Maybe he's right, maybe we need to develop such a vision. Alexander had lots of ideas along those lines back in the seventies, maybe its time for more people to listen to him.
Next, Craig discussed qualitative versus quantitative methods. He argued that qualitative methods have been deemphasized, when not actually reviled, in modern society. Our society values quantitative methods and skills such as mathematics and "hard" science. Our educational system emphasizes these skills and even defines intelligence (the primary educational value) in terms of these skills, while paying small heed to more qualitative skills like art and design.
So far so good. Personally, I'm very interested in merging quantitative data gathering with qualitative design and decision making, since I strongly believe both have great value for different purposes and both are essential for a healthy society. Along these lines, Craig discussed the cultural divide between engineering and design, which perked up my ears since I see my work on U&SA as one facet of bridging an instance of this divide. However, although Craig preached for bringing the two perspectives together on equal footing, the rest of his talk, I felt, had a definite "design has got it right; engineering is so materialistic!" slant to it. Over dinner, Matt remarked that it seems every area of study he encounters preaches interdisciplinary unity at first, then turns around and argues why their particular discipline is the best and should ultimately be in charge.
All too often, such discussions turn into power games. Perhaps its due to our tribal ancestries, but we humans always seem to want "our people" to be the dominant ones, whether our people are defined by nationality, race, gender, or discipline. Too few of us genuinely see ourselves as truly multidisciplinary, as having a foot firmly planted in two or more such cultures at once. Yet the disciplines must cooperate, and to do so they must see the other's point of view. Sometimes I'm amazed that anything ever gets done...
Craig also discussed the MAYA principle of design, which stands for "Most Advanced Yet Acceptable". A powerful concept, that speaks to the need for progress to proceed in digestable portions. Too many sweeping changes, and you've developed a product, interface, or system that is unusable, aesthetically displeasing, or otherwise rejected by the populace. Sometimes we refer to products and ideas of this ilk as "ahead of their time" (if they're lucky). Which is very visionary and avant-guard and all, but such ideas, almost by definition, never pan out, never make a significant difference. Keeping this principle in mind is especially important for us intuitives, who are always seeing the possibilities of the future and risk losing touch with the here-and-now reality our fellow humans live in. Perhaps here is where the quantitative methods come in.
Craig contrasted the design of two cars, one of which he held up as a better example of design. He mentioned that buyers know there is a problem with the second car but can't necessarily articulate what the problem is. They're likely to say "it just looks ugly" or something similar. This reminds me of the maxim of HCI that "the user is not always right". The designer's job is to define, articulate, and respond to the problems the users "know" are there but can't quite grasp, let alone offer solutions for.
As we talked more and more about these two designs, I couldn't help but feel how ironic it was that, after all that initial high-minded anti-modernity talk, we wound up discussing cars. If ever there was an example of a poor definition of progress, I'd argue its embodied in the automobile. They're dangerous, bad for the environment, expensive (on both the personal and societal level), and yet our society keeps demanding more of them, with more features and better designs. And thus our designers fight with our engineers over how to make the cars pretty and cheap at the same time rather than confronting the larger issues. Do we even need these things at all? Why is the only alternative an overpriced fancy scooter?
Unfortunately, all people, even designers, work within frameworks. Cars are so much a part of the framework of American society that people either take them for granted or dispair at ever improving on them. And no matter how convinced you are that you're discipline should rule the world, you still should recognize that its culture lives within a larger culture that dictates a surprising array of its values in deviously subtle ways.
I guess no one has all the answers, be they engineers, designers, or HCI people. But hey, if there weren't all these important unanswered questions out there, there'd be nothing for people like me to write about.
Email Rob:
Posted by Dan on August 03, 2003 at 11:50 AM
Ever thought about some subheads? Those might be better than the phrases bolded scattered throughout the page.
Posted by Rob on August 03, 2003 at 12:31 PM
I've used subheadings occasionally before: http://www.lokislabs.org/~loki/weblog/archives/2003/06/25/the_ways_we_read.php
Generally, however, I've only used them when the post is particularly long and is easily divided into multiple sections. Most of my posts are at least _supposed_ to express only one primary thought (yeah, I know it doesn't always turn out that way).
I could try reflecting the outline in subheadings; I worry this will create too many subheadings and break up the flow of the text. OTOH, it would be more scannable and perhaps that's more important. Thoughts?
Posted by Jeff on August 03, 2003 at 06:23 PM
I don't see it as a problem, but if it is, the best solution is probably to write more concisely. Write, edit ruthlessly, rewrite. That's difficult in a medium as off-the-cuff as a weblog, and might cut into the personality of your posts.
An alternative might be to write an introductory summary for especially long posts--after the fact. The only example of this I can think of at the moment is Zeldman.com's RSS feed. Hand-tooled exerpts (not machine trunctated posts) give an overview of the post, along with a link to the full text.
Expanding on that, you could use kuro5hin's technique of posting the exerpt (an introduction) on the front page, and the full verson on the individual entry's page.
Posted by Rob on August 04, 2003 at 11:13 PM
Yeah, I realize that the optimal solution to the scannability problem would be to simply write more succinctly. But as I said, this weblog is primarily intended for personal reflection and secondarily intended for communication. In theory, my writings section is intended for polished, ruthlessly edited communication pieces that express my ideas in a more widely digestible form. Of course, if you visit that section you'll find that I haven't made too much progress there. Which is exactly the problem; if I have to hold myself to high standards of excellence I'll write much less often. It already takes me an hour to two hours to write these posts; if I had to follow the get feedback, edit, rewrite, etc. cycle, I'd have to update _much_ less frequently than I do.
A summary would be nice if I could think of a way to integrate it into the weblog design. Movable Type already supports an "Entry / Extended Entry" concept that lets you do something similar to the K5 approach for long posts if you want; I've shied away from that approach since I was afraid breaking up the posts would make it even harder to scan and read. But its worth thinking about.
So I'm not sure what to do about this problem. I guess I'll just "wontfix" it for now and see if any great ideas strike me later. It's good to know that Jeff, at least, doesn't think it's a problem at all :).
Posted by Jeff on August 05, 2003 at 12:39 PM
I just think it's a benefit to post less superficial entries if the tradeoff is a slightly longer read. There are lots of paragraph breaks, and most posts stay reasonably ontopic. As long as you don't have to paginate your articles, it doesn't seem too bad.