Week of Oct 12, 2003

About

Syndication

Categories

Archives

	«	Week of Oct 5	<	Individual Entries	>	Week of Oct 19	»

Active Reading

teaching & learning, writing & communication

October 17, 2003, 09:59 PM

Since I came to Carnegie Mellon, and especially since I started roBlog, I've developed a new approach to reading nonfiction books and articles, both for classes and for myself. In the past, I've found that I got very little "take away" knowledge from reading papers; usually I'd remember one or two of the main points, if I was lucky. The problem, I believe, is that I was taking a very passive approach to reading; I would just sit back, scan the text, and hope to absorb the knowledge. Sometimes this works ok, but I've found a more effective way to learn.

I call it "active reading", but its basically just a matter of reading and writing about your understanding of the reading. Sometimes I try to just summarize, but often I'll reflect on the important points behind the prose, and try to connect them to other facts I've collected in the past. This serves two purposes:

1. Writing ensures I really have a complete understanding of the concepts; I won't be able to put them into words if I don't.
2. The resulting text serves as a "backup" of my reading of the article; when I inevitably forget something important, I can return to my synopsis/reflection to find it again.

On the down side, this process takes longer and consumes more energy than just sitting down and reading does alone, but I find the depth of understanding I take away from it is much greater.

[ Permanent Location ]

Got Something to Say About This?

Email Rob:

OR Post a Comment:

Name:*		Remember me
Email:*		Email me responses
Web:
Enter the number below into the text box next to it.*

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

Posting Tool Wish List

internet, writing & communication

October 17, 2003, 09:36 PM

Micah has been pondering switching from his beloved Radio Userland to Movable Type, but has found a few of his favorite features in Radio missing in MT. In particular, he wants:

1. Rich text editing. Basically, an embedded HTML editor.
2. Automatic file uploads. I.e., you drag your file into a special folder on your local machine, and the client automatically uploads it to the server.

These sound like some pretty useful features to me. Although I love the web interface to MT (mainly because I can post from any computer) I also wouldn't mind having a more featureful local client, which is quite possible since MT supports the Blogger API. And as long as we're rattling off a wish list, I wouldn't mind seeing the following:

1. Local saving / crash protection. Sometimes I'd like to be able to write entries when I have no available network connection, so a local entry cache would be nice, but even more importantly, the tool should provide crash protection so I don't lose my posts to an application or system crash. Safari sadly lacks such a feature and I've lost more than one post to a badly-timed "unexpected quit".
2. Fix some of the annoying usability bugs in Movable Type. For instance, MT sets the posted-on date to the "first saved" timestamp, not the "first published" timestamp like I want (and which makes the most sense). Not a big deal since I can manually change it, but it's still irritating. A good tool should provide a more sensible interaction design for the posting task.
3. Spell checking. I already get this with Safari, but it's a feature I definitely don't want to lose.
4. Auto-linking certain words. Some words, like the names of my friends, I almost always link to a particular website. It'd be nice if the posting tool did this for me.
5. Smarter link management in general. I link a lot. It's what webloggers do. A good posting tool should make the process of finding and inserting links easier, perhaps through browser integration. For instance, perhaps it could help me track down references on the web for a paper or idea I'm referring to.
6. An embedded outliner. Maybe I'm the only one who does this, but I frequently outline my posts before writing them in full. A good tool should support this progression of outline-to-post in a more direct fashion.
7. Mac support. Again, maybe only I care. But I post from my Mac laptop the vast majority of the time. If a tool doesn't work on my Mac, I'm not using it. Period.

If anyone knows of a tool that implements a reasonable number of the aforementioned features, please do give me (and Micah!) a heads up.

[ Permanent Location ]

Commentary

Got Something to Say About This?

Email Rob:

OR Post a Comment:

Name:*		Remember me
Email:*		Email me responses
Web:
Enter the number below into the text box next to it.*

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

The Design and Development Disconnects

design, software development, usability

October 14, 2003, 10:14 PM

I've been thinking a lot recently about the communication between software developers and usability/design people, for my usability and software architecture work, my open-source and usability work, and for an SSS topic I proposed. Here's a preliminary list I came up with of development & usability problems that might inhibit good design.

First off, one central point to make up front is that in most cases, everyone on the team; usability professionals, designers, and developers; wants the final product to be usable. Very few people set out to create a system that is useless to their target users.

That said, the system might wind up less-than-usable because of one or more of the following reasons:

1. A design may call for solving impossible problems. There are a few classes of problems in Computer Science that are genuinely unsolvable for all practical purposes; "Traveling Salesman"-style problems with exponential time complexities are examples, as well as incomputable problems like the Halting Problem. These are pretty rare in everyday system design, however, so chances are a design will be at least theoretically implementable.
2. A design may call for implementations that are possible, but infeasible. These types of designs may be theoretically implementable, but they would take far too long to implement and/or too many resources given the current state of the art. This changes with time, of course; once-upon-a-time building a WIMP-style interface would have been infeasible for most projects; with modern toolkits it is fairly trivial.
3. Implementing certain design features may necessitate sacrificing others. Some design features take longer than others. Given that the project must be completed in a fixed time frame, in order to get these features in as designed, other features may need to be sacrificed. XP's Planning Game provides a mechanism for communicating these tradeoffs based on experience-based estimates and encourages informed decision-making on the part of management and design.
4. Implementing certain design features may necessitate sacrificing other software quality attributes that are important to the project. Examples of quality attributes include performance, modifiability, and reliability. Sometimes, certain design features may require an implementation that performs slower than design alternatives, for example. Designers must be educated on how these quality attribute tradeoffs influence their designs, and Software Engineers must understand how these quality attributes influence the user experience, which is ultimately the most important consideration.
5. Architectural decisions made early on in the development lifecycle may preclude the implementation of certain design features. Generally speaking, this is a time tradeoff that didn't need to be made had these design features been considered earlier in the process. The solution, of course, is to ensure these features get considered early enough for them to be feasible. Our U&SA technique attempts to tackle this issue.
6. Design and development may have different priorities. Design tends to focus on the features that are most necessary for their users, based on their research and testing. Development tends to focus on the features that are the riskiest to implement, generally preferring to tackle those first to make the project more manageable. These two groups must come to a consensus; the developers must understand that the most technically sophisticated features aren't always the most important to users, and design must understand that development's technical priorities must be respected if the project is to get completed on time and under budget.
7. Design and development may experience simple miscommunications. Design may think they are proposing a particular interface design solution, but development might hear something different. The way it works out, of course, is that development's version actually gets implemented in the final product. The solution to this problem might lie in more rigorous specification techniques or formal sign-off procedures, but I tend to lean towards Agile Software Development's philosophy of simply having Design and Development work together more closely, ideally in the same room, all the time.

[ Permanent Location ]

Commentary

Got Something to Say About This?

Email Rob:

OR Post a Comment:

Name:*		Remember me
Email:*		Email me responses
Web:
Enter the number below into the text box next to it.*

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

On Constrained Diets

aesthetics

October 14, 2003, 10:15 AM

There's an article on K5 written by a guy who's giving up vegetarianism after 8 years. It presents an interesting perspective on what it means to be a vegetarian in our society. As a vegetarian of 9 months (and the only one in my immediate social circle), I'd say my experiences with anti-vegetarian prejudice aren't nearly as bad as the author makes his out to be, but they are there, and noticable. He makes some other good points, too. I especially liked the following paragraph:

The longer I was a vegetarian (and the longer I studied diets) the more I realized how complex the issue was. My very rational decision to give up meat highlighted the irrationality of our society's relationship to food. After 8 years of dietary exile, one thing is clear: not only is our diet bad for our health, our environment or the animals, and it isn't even very tasty. When people say they like the taste of meat, I wonder if they ever eat anything else satisfying. Odds are better than even that their veggies, if something other than potatoes, are always served terminally limp, that their desserts are mostly fat and sugar, and their salad base - if they eat salads - is an uninspiring iceberg lettuce.

For a society that consumes as much as ours, we generally have a pretty boring relationship with food. The solution to mass-producing "tasty" food is to load it up with fat, salt, and sugar. Quite contrary to my expectations, I've found that when I gave up meat my diet got significantly more interesting, because I was forced to stray from the "standard fare" of steaks, burgers, chicken patties, etc. Certain connoisseurs may argue that you can have this experience with a conventional diet as well. This is entirely correct, but for many of us, constraining ourselves to new ground is the only way to encourage exploration.

[ Permanent Location ]

Commentary

Got Something to Say About This?

Email Rob:

OR Post a Comment:

Name:*		Remember me
Email:*		Email me responses
Web:
Enter the number below into the text box next to it.*

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

Deos It Mttaer Waht Oredr the Ltteers in a Wrod Are?

language, psychology

October 13, 2003, 11:21 AM

Matt Davis, an actual researcher at Cambridge University, has an interesting page discussing the word scrambling and perception net-meme that was going around last month. The bottom line is that some of the claims in the email are at least partially true, but the central thesis (that we only read the first and last letters in a word) is false. Check out the page for the details, but note that it's designed very badly and you have to scroll past all the word-scrambling-in-multiple-languages stuff to get to the actual analysis.

Found via Andy.

[ Permanent Location ]

Got Something to Say About This?

Email Rob:

OR Post a Comment:

Name:*		Remember me
Email:*		Email me responses
Web:
Enter the number below into the text box next to it.*

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

Using Research to Guide Design

design, processes & methodologies, society & sociology

October 13, 2003, 11:15 AM

As I've mentioned before, I'm taking CSCW: Designing Online Communities this semester and one of the stated goals of the class is to figure out a way to translate the knowledge gleaned through social science experiments into a set of principles that can guide the design of online communities. The way we've been approaching this so far has been to distill out a set of stylized social science facts and then brainstorm features that would conform to these principles (generally by altering the design of an existing system, MovieLens).

My preliminary thought on this approach, however, is that this is the wrong way to go about applying social science to design. The problem is that brainstorming features from social science facts doesn't take account of the holistic nature of design; the principles are very specific and reductionist and thus the feature ideas you tend to get may violate some principles while supporting others, or just be bad ideas for other reasons. Some of the stylized facts are even contradictory, at least at this abstracted phase (e.g., disclosing personal details about yourself makes you like the people you disclose them too, but spending too much time with people you have an intense relationship with makes you like them less). They also might not fit into the conceptual structure of the design, or the culture of the particular community.

This is not to say that the whole idea is fundamentally flawed, just that I believe we should take a slightly different approach. Instead of using social science to guide design explicitly, we should use our stylized social science facts and distilled design principles as heuristics that can be applied in a post-design analytical usability evaluation, similar to Heuristic Evaluations. Although these principles may influence community designers, just as Nielsen's heuristics influence user interface designers, they are primarily intended as a checklist. Nobody comes up with interface designs merely by pondering Nielsen's heuristics, so we shouldn't expect that of community design either.

[ Permanent Location ]

Got Something to Say About This?

Email Rob:

OR Post a Comment:

Name:*		Remember me
Email:*		Email me responses
Web:
Enter the number below into the text box next to it.*

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

CSS and Linked File Types

internet, software development

October 12, 2003, 01:13 PM

Andy writes of a CSS rule to auto-insert file type images after your URLs, so that your readers will know what kind of file the link points to. This struck me as a nice, easy way to warn readers about PDF content if you don't want to have to create a gateway page every time you link to one, so I stole his rule for my stylesheet and added one for Flash movies. As an aside, Micah had another nice tip relating to linking to specific PDF pages.

CSS seems to be getting better as a means of separating web content from its presentation. Used to be, you couldn't really do jack squat with CSS except change the font colors (slight hyperbole, but only slight), which really hurt the CSS advocates' case since the kinds of page designs you could do in pure CSS were pretty limited and boring. You still can't do everything you want to in CSS but at least it is getting better. RoBlog still uses table-based layouts, for instance, and will continue to do so until CSS positioning gets better. I heard awhile ago that CSS3 was going to contain constraint-based layout rules; I wonder if that's still true.

Oh, and if you're wondering why you can't see any file type icons, do note that this flavor of CSS doesn't work with Internet Explorer (or, as Andy puts it, "it's only gonna work in browsers with a conceptual grasp of the twenty-first century" :).

[ Permanent Location ]

Got Something to Say About This?

Email Rob:

OR Post a Comment:

Name:*		Remember me
Email:*		Email me responses
Web:
Enter the number below into the text box next to it.*

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

© 2003-2010 Rob Adams ()

Last Modified: Wednesday September 17, 2008

Unless otherwise indicated, all original work appearing on this web page is licensed under the Attribution / No Derivitive Works Creative Commons license. Please before using any page content in a manner not covered by this license.