 |
« | Week of Apr 20 | < | Individual Entries | > | Week of May 4 | » |  |
 |
 |
Research and Content Management
information, software development, usability
May 03, 2003, 12:00 PM
I've recently become more and more aware of the need for a "single source paradigm" in productivity applications. To gloss over a complicated topic, single sourcing calls for the separation of the content you create (the text, images, raw data, etc.) from the medium you view or present it in. Here's a diagram of such a system:
Imagine this weblog post is the semantic content. I'd use my entry editing tool (Movable Type in this case) to create the semantic post; I'd write this text and the diagram above and break the post down into its semantic parts (such as the "main points", "examples", etc.) Once I had that, I'd be able to tell the system to generate not only the HTML pages that normally make up the post, but a printable PDF, a Powerpoint presentation to show to my bosses, etc. based on stylesheets for each presentation medium I had previously defined. Having a system like this would bring us closer to the view of application-agnostic computer use that I've mentioned before, since we could use many types of editors to create the appropriate view of the content we've already defined.
Single sourcing has long been a promise of computing but has yet to be delivered in any satisfactory form. So I thought I'd describe the problem we're having where single sourcing might apply to help reason about what an adequate single source solution would need to do.
For my work on Usability and Software Architecture (U&SA) with Bonnie and Len, we have a number of "scenario packages" we are developing that contain, among other things, a description of a system usage scenario with architectural implications, a list of responsibilities the system must fulfill to implement this scenario, benefits to the user of including the scenario in the system, etc. These scenario packages are the cornerstones of our work.
There are a number of properties these packages have that would make them amenible to a single source solution. Here's a list of them:
- We produce a number of publications about these scenarios. These publications span data formats (we produce Word documents and PDFs for academic journals, Powerpoint presentations for giving tutorials on our scenarios, I'm now trying to put together a U&SA website, etc.) as well as presentation formats (even publications that all accept Word document submissions all have different ideas of how the paper should be organized, what the font and spacing should be, etc.). We waste a lot of time fooling around with getting the scenario text, graphics, etc. out of one presentation format and into another.
- The scenario packages change frequently. Since this is still an area of active research, we're still developing the notion of what makes up an architecturally-sensitive usability scenario package. And when we change our minds, we want all our future publications to include the updated scenarios and not the old stuff. We've also wasted a lot of time fooling around with doing manual "diffs" of old material to make sure its up to date with respect to our new understandings of the problem.
- We don't want to be limited in what we can express by the particular presentation-oriented tool we're using. For example, most of the diagrams we're developing are currently done in Powerpoint, but Powerpoint is not a diagramming tool and it places limits on the ease with which we can create and modify these graphics. I've proposed using Omnigraffle instead, but Omnigraffle and Powerpoint don't always play well together. Plus, when I create a diagram in Omnigraffle it may be more detailed than what I want to show on a Powerpoint slide; I may want to be able to generate a stylized version of the diagram for presentation purposes.
- We use different machines running different platforms (mostly Windows and Mac OS) to develop this material. This isn't directly solved by the single source paradigm, but by centralizing the content in a single location, we could more easily share our work, track versions, and attribute changes to who made them. This would help solve a frequently occuring problem where Bonnie changes her copy of our slides, I change mine, and then I have a messy and error-prone manual merge task to perform.
Micah is hopeful that Office 2003 will help solve some of these problems. I'm skeptical, but willing to reserve judgement. At this point I'm willing to see anyone take the next step forward, since this idea has been in gestation far too long without much real progress to show for it.
Defining "Design"
design, language, philosophy
April 29, 2003, 11:53 PM
I was ruminating on the nature of design last night: what design is, what it means to design something, what the place of design in the world is, and so forth. I've especially been pondering the question of to what extent I'm a designer; on the one hand I've always felt that design was a very "artsy" notion that was mysterious to a not-very-artsy person such as myself. On the other hand, I've been called a software designer for awhile, and I've always had a suspicion that "design" ran through much more of what I do than just that; perhaps through almost everything I do. So I dreamed up the following definition that seems to work well for me, and I thought I'd share.
Design is: "a deliberate action prompted by an understanding of the state of the world intended to transform the world into an improved state."
Allow me to now dissect this definition in excruciatingly painful pedantic detail.
"a deliberate action" - This phrase says two things. First off, design to me is a verb, not a noun; it is something we do. Although you can also speak of "a design", this strikes me as a derivative sense of the term. "A design" is just something that has been designed; it has no meaning except in its relation to the verb sense since two arbitrary things that are called "designs" may have nothing in common except that they were both designed. Thus I consider design proper to be an act, not a thing. Secondly, this phrase says design must be intentional; only conscious beings can design and they cannot design by accident.
"prompted by an understanding of the state of the world" - This phrase also says two things. By saying "prompted" I'm implying that design has a source, you don't decide to design "out of the blue". And that source, according to the rest of the phrase, involves some conception of the way the world works. Thus, all design is performed in the context of some kind of framework, the "understanding" you have about the world. This doesn't imply, of course, that your understanding is correct; lots of design gets done based on completely wrong understandings. So in a sense, the main point here is that you will start your design with initial preconceptions, the only question is how accurate these preconceptions are.
"intended to transform the world" - Design is an inherently normative action. By designing you are changing the world, moving it in a direction it otherwise would not have gone. Thus you are going against the current, and, as "intended" implies, you may not succeed in the ways you thought. Whenever you try to transform the world, you're taking a gamble that the world won't outsmart you.
"into an improved state." - Improved state according to whom? Well, the designer of course. This final phrase inserts something tricky into our definition since different people will probably have different notions of what an "improved state of the world" is. Yet rational designers will act to bring about their own conception of "improved", which is worth keeping in mind if you're hiring one to help design something for you. In a sense there is no designing for someone else; the designer ultimately works only for herself and her visions of improving the world.
Currently, I think this definition neatly captures all the factors of the "design" concept that I find critical. But I admit I haven't read much by people who've thought about this at a much deeper level than I have. Comments and suggestions are very welcome as always.
Email Rob:
Online Publishing, from the Trenches
aesthetics, internet, society & sociology, writing & communication
April 28, 2003, 08:15 PM
There's an interesting article over on Kuro5hin about localroger's experience with publishing his book online and the success (or not) of the "tip jar" economic model for freely available online works.
For those of you who don't read K5, localroger (Roger Williams) is a member there who also happens to be an excellent amateur (in the not-getting-paid sense) writer. Awhile back, he posted a short science-fiction story called "Passages in the Void", which I've read and highly recommend. It went over so well that Rusty (K5 founder and proprietor) created a fiction section to house such content. Roger mentioned in the comments that he'd written a novel called "The Metamorphosis of Prime Intellect" but was unable to get it published via conventional means, so several K5 users convinced him to publish it online and Rusty agreed to host it. I haven't read it yet (although I intend to). From people's comments I expect it will also be quite good, although apparently it contains some content that many may find disturbing (rape, violence, etc.).
Roger's analysis of his online publishing experience is thoughtful and objective, and his conclusions, although not unexpected, are worth pondering. Basically he found that he has attained a much wider distribution and rate of feedback through the web publishing medium than he ever would have through conventional publishing. From the tip jar he made around 760$, which, although not insignificant, is much less than a typical publishing advance and not something that he could quit his day job over. And he admits that his is really a best-case situation; he had the backing of Rusty and the benefit of two appearances on Slashdot, which is more than the average budding author is likely to get.
Roger's experience highlights the fairly obvious fact that many people still fail to admit: artists just can't make money by giving their work away and relying on audience generosity. On the other hand, Roger was approached by an agent who is now interested in publishing his work via conventional means. So we see a pattern which crops up frequently where the internet is a good way for budding content creators to get "known", but one that they quickly must switch out of and lock up their content into for-pay conventional schemes if they want to make a living. And maybe this is a fine role for the internet to play. However it doesn't take full advantage of the potential of the internet's highly efficient content distribution systems (which provided Roger with the wide distribution and quick feedback he discusses) and may not even be a viable option in a future where all content is digital and copying is quick and easy.
As a society, I think we're going to have to get over this "content on the 'net must be free" mentality. Someone's going to have to pay, one way or another, and that someone is going to be determining what the economic incentives for artists, writers, and other content producers are. Do we the people want to be determining those incentives, or are we willing to leave it to advertisers who are more interested in selling their products and services than in appreciating art and literature? To me the answer is clear. How about you?
Email Rob:
Omelette du Fromage!
life & times, personal
April 27, 2003, 11:35 AM
Omelettes? Check.
Posted by gh on October 05, 2003 at 09:13 PM
*drools*
Posted by g on October 23, 2003 at 08:05 AM
this made my day
Posted by moo on January 07, 2004 at 10:50 AM
omelette du fromage!!
omelette du fromage!!
ooh lala!!
Posted by Miztah Prezident foo on May 05, 2004 at 06:44 AM
Omelette du fromage!!
Omelette du fromage!!
Email Rob:
Show Me All My Options
design, usability
April 27, 2003, 01:17 AM
Many interfaces give their users a great deal of control over the appearance and behavior of the application. Unfortunately, the means for exercising this control are usually hidden away in obscure preferences dialogs or even worse (horror among horrors!) configuration files written using some obscure, usually nonstandard syntax. To help fix this, I'd like to propose a new user-interface design principle for consideration. Here it is: "Keep configuration options close to the things they configure."
A classic example of this principle in action is the ubiquitous (and often overused) "Don't show me this again" dialog box. Here's one from IE/Mac:
This design is good because if the user doesn't want to be bothered by messages such as this one again, he can simply click the check box that is right there in front of him. He doesn't have to go figure out where in IE's voluminous configuration dialogs the relevant preference to disable these messages appears.
Here's another example from Movable Type's author's interface:
Note the option to change the default welcome message is clearly displayed right below the message itself; this makes it easy for the weblog author to 1) realize that the message can be changed and 2) click the link to go straight to the configuration screen where he can make the change.
You may object to this principle on the grounds that putting all the configuration options relevant to a given interface object right near the object would often clutter the screen horribly and likely confuse users who are new to the system and aren't ready to start reconfiguring it yet; they just want it to work. I have a couple of responses to that. First off, you may be able to design your configuration option so that it doesn't require any screen space; this is frequently possible with direct manipulation. For instance, I can reconfigure the order of my programs in the Mac OS X dock just by dragging them around:
If your configuration option is difficult to represent with direct manipulation, then we need another metaphor. One possibility is to extend the GUI to support the concept of standard "tools" which are always available regardless of the application the user is in. Think of an extension of the contextual help system in Windows, where you can click on a "?" button to turn the cursor into a question mark, then click on any interface element (theoretically) to get a nice little tooltip explaining what it does. That would be how a "help tool" would work. A "configuration tool" would instead provide you with the screen of configuration options when you clicked on that interface element to let you change its appearance or behavior.
These interfaces help solve the configuration problem because they provide the option right when the user needs it; when she has hit the point in her task where she wants the appearance or behavior of the application to be different than what it currently is. This integrates the "reconfigure the interface" task in with the user's primary task, rather than forcing it to become a secondary task that will likely be forgotten since it isn't a part of the user's main workflow, especially if it's difficult to figure out. If you're a cognitive walkthrough fan, you'll notice this helps to both ensure the user trys to achieve the "reconfigure the interface" affect and to ensure the user notices the relevant reconfiguration option is available.
Email Rob:
Email Rob: