 |
« | Week of Apr 13 | < | Individual Entries | > | Week of Apr 27 | » |  |
 |
 |
Retroactive New Year's Resolution: Cook More
life & times, personal
April 26, 2003, 01:07 PM
I've decided that one interest of mine that is sorely in need of development is "cooking". I've always claimed I like to cook, but on the rare occasions that I have time to cook for myself I tend to stick to the easy stuff I already know how to make (spaghetti, scrambled eggs, rice, etc). I made scones from scratch at the beginning of this semester, and that turned out pretty well I thought, but I can't remember anything else particularly interesting I've cooked since then.
So I'm making a resolution. I'm going to cook something new at least once a week starting this summer. So hold me to this, guys. Ask me, "what did you make this week, Rob?" and if I say "ummm... Microwaved macaroni and cheese?" smack me upside the head or something.
I pretested this resolution today by making myself an omelette. Omelette lesson number one: make sure you prepare the fillings before the omelette is sitting in the pan, cooked, waiting for them. It turned out ok though, just a tad, um, "browned" on the bottom.
I'll give it another shot tomorrow.
A Recommender System for End-Consumer Service Providers
information, internet, society & sociology
April 25, 2003, 08:46 PM
A sector of the economy that I've always experienced problems with, and I think many others have too, is the end-consumer service providers industry. This is just a fancy way of referring to auto mechanics, maid services, landlords, and anyone else who sells a service directly to individual private citizens (as opposed to other businesses or government organizations, which are a different story). Note that many companies that nominally produce goods may fall into this category as well since most provide some sort of service to support their products. For example, Compaq makes computers but also has a tech support line.
I don't mean to imply that its impossible to get excellent service from this sector; the problem I'm describing is that its hard to determine who will provide good service and who will not without a lot of trial and error. Part of the problem is that many of these services have slow cycles; unless I frequently experience car problems I won't need the services of a mechanic too often. Landlords generally sign leases for a minimum of one year. So you may have to go through several providers before you find one that's good. Meanwhile the not-so-good providers may stay in business through people who are uninformed or just don't want to have to take a chance with someone else. To compound the problem, if you're like me and you move fairly frequently then even if you do locate a good service provider, you'll have to start all over again when you reach your new home.
To help solve this problem, I propose a web site that allows consumers to rate service providers and discuss their service experiences. Kind of the same intent as Amazon.com's product rating system, except for service providers. This would allow consumers to mobilize and take crappy service providers to task, while promoting the businesses of honest, competent providers.
Aside from all the problems that normally confront recommender systems, one obstacle for this system might be slander and libel laws. Users of the system who are upset at a service provider may post comments to the site that aren't true, and of course it is impossible to check up on the facts for all comments. I'm no lawyer, but I have listened to lectures on business law and torts, and my understanding is that you can get sued for publishing libelious comments that another person made. I'm not sure if this applies differently to community web sites, but I imagine the proprietor of such a system might need to be prepared to defend himself in court.
Email Rob:
What's Related to this Post?
design, information, internet
April 23, 2003, 06:31 PM
One question I've frequently wanted to know the answer to since I started this here weblog is: "Now that I've finished this entry, what things are other webloggers saying that are related to the topics I discussed?" So I have a modest proposal for a solution to this problem.
I propose someone create a server that listens for weblogs.com XML-RPC pings from weblog updates. But instead of just providing a recently-updated list like weblogs.com does, when this server receives a ping it will fetch the weblog's RSS feed and extract the entry content and any associated metadata (title, category, whatever). Then it would run a "what's related" algorithm comparing the new post to all the posts in its database. Finally it would generate a report of weblog entries that are related to the new entry, and spit out an HTML page to a web server that could distribute this information to the masses.
The final system would look like this:
A nice extension to the system would be to send the URL of the final report back to the weblog tool so it could include a "Related Entries" link next to the post (if the weblog's author wanted it to do so, of course). But I don't know of any way to accomplish this without extending existing weblog tools.
I must confess I'm not sure how "what's related" algorithms work or how useful the current state of the art tools are. Google's concept of what's related to my page is a little strange (why does Micah's gesture literature review page come up, but not his weblog? And why does Mathilde's friend Mav's page appear?) although not completely inaccurate. But hey, that's a problem for the Language Technologies people to solve :).
Currently, the automatic notification ("ping") features built into most popular weblog tools are, in my opinion, underexploited. We could probably think of lots of other cool things to do with them if we tried.
Email Rob:
Bringing Usability to Open Source Software
processes & methodologies, software development, usability
April 23, 2003, 12:07 AM
I'm thinking of doing an independent study during the summer on the topic of "Improving the Usability of Open Source / Free Software". It is widely realized among open-source software users and the more level-headed developers that the usability of most open source software products is abysmal. Unfortunately, the response of many open-source advocates is to stick their heads in the ground, but even those who are seriously looking into the problem have yet to propose a sound human-centered open source development process that has a chance of actually getting used by J. Random Hacker (at least, no one has that I've heard of).
Basically, I'd like to write a "Usability HOWTO" that's based on some actual experience running a human-centered open source project. I have a few ideas to start with:
- Developing and using scenarios and user personas as a way of encoding a shared perspective of the target user population among contributers to the project.
- Using inspection methods like Heuristic Evaluations and Cognitive Walkthroughs periodically on the user interface and filing usability "bugs" in the project bug tracking tools.
- PUI-style user testing where contributors go out into the world and test their interfaces on people who belong to the target user population of the project, then bring the results back to the other contributors to advise the interface design.
To flesh out and validate these ideas, I want to run a small open source project of my own. I was thinking of doing a server-side RSS News Aggregator since there don't seem to be many good ones in the open source world. But anything would do as long as usability is critical to the project.
I haven't decided for sure whether I'm going to do it or not; I'm not positive I have the right expertise. But I do think it's an important problem that needs to be solved, so I may start casting around for a faculty sponsor.
If anyone out there has any thoughts or suggestions, they'd be much appreciated as always.
Posted by *abby on April 25, 2003 at 03:59 PM
Rob - this is a great idea. However one thing you need to keep in mind is that people don't generally follow "guidelines". Maybe instead of passive references the answer is a open-source builder of some sort that will actively guide the developer. Or what if there was an "auto cognitive walkthrougher" in which you could enter the task, and then the system would run through your interface and list the failures. If you're interested in pursuing this (do you think it's possible?), I would be interested in working on it if you want assistance...
Posted by Rob on April 25, 2003 at 08:55 PM
Hi Abby,
Yeah, it is true that often people don't follow guidelines, but what I was hoping to accomplish with this project was to determine what a usability process would look like that was sufficiently lightweight that it could be used by individuals, rather than organizations, with 0$ budgets. This is a problem the vast majority of open source projects face.
But I do think your suggestion is a good one, and is in line with another interest I have, which is developing tools to support usability techniques. Someone called them "CAUSE" (Computer-Aided USability Engineering) tools (Nielsen?). I'm not sure how much of the standard usability techniques we could effectively automate, but perhaps we could get a lot of leeway out of providing "usability support" tools that helped out designers by walking them through the process of doing, say, a cognitive walkthrough and providing recommendations for what problems the user may experience at each step.
Those are my thoughts at any rate.
Posted by Andyed on April 29, 2003 at 09:45 AM
I've got two open source projects with good chunks of code:
card sorting tool
http://uzilla.mozdev.org/cardsort.html
heuristic review sidebar
http://uzilla.mozdev.org/heuristicreview.html
Other related topics:
In general, usage data should be a key feature in high level open source development reasoning. http://citeseer.nj.nec.com/136409.html
re: Abby. F.Paterno has done some nice work onmatching usage data to task models, potentially "automating the cognitive walkthrough" based on data. http://www.ercim.org/publication/Ercim_News/enw51/paterno.html
Posted by Rob on April 30, 2003 at 12:22 AM
Hi Andy,
Thanks for the pointers; I hadn't even heard of the card sorting technique. Looks like I forgot to mention it in the post, but I was also thinking that high-level log analysis of existing open-source products as a means of guiding redesigns might be a good thing to look into since it seems to play to the strengths of openness. It also strikes me as potentially more appealling to OSS developers for some reason.
Micah mentioned that you're working on bringing usability techniques to Mozilla. I'll have to check out your Uzilla stuff once I can unbury myself from the dying semester's last gasp of work...
Email Rob:
Quality Attributes and Human-Centered Design
software development, usability
April 22, 2003, 05:50 PM
In Software Engineering, we analyze and design systems based on known "software quality attributes", or general properties of software that define what makes a "quality" system. Some examples of these attributes include performance, reliability, security, maintainability, etc. The Software Engineering Institute has a technical report on the topic.
Usability is sometimes included as a quality attribute (though it's all-too-often omitted), but it is only one among many. Software engineers are busy people and when they have performance and modifiability and all those other attributes to worry about, usability often understandably falls by the wayside. So no one ever thinks to call in the HCI people.
However, I suspect that if we carefully examine all of these quality attributes, we'd find that human-centered design must underlie all of these concerns. After all, software systems are tools to help provide for human needs, right? It stands to reason, then, that we can't design quality systems without understanding what those needs are. So no discussion of quality attributes can truly begin until we uncover the human needs the system must support.
To help support this argument, I'd like to consolidate some real findings (either hard research results or best practices and industry folklore) for each quality attribute proving how it ultimately relates to human-centered design. For example:
- Performance - Anyone who knows anything about tuning systems for performance knows that having a quick response is much more important for some parts of the system than others. So what determines how fast a system operation has to be? It's how fast the user of the system expects that operation to be, of course. If the user expects an operation to take a long time, it doesn't matter if you can shave off a couple of minutes of execution time; the user won't notice. This is most apparent in problems like computer displays; humans can't perceive the difference between display refresh rates faster than 50 times a second. So if you're trying to tweak your algorithm so it can throw pixels on the screen faster than that, you're wasting your time.
- Security - Security people spend a lot of time coming up with newer, harder-to-break cryptography, more powerful firewall systems, etc. Yet the vast majority of systems are compromised because of "user error"; perhaps someone used a weak password, or a cracker used "social engineering" to fool an authorized user into giving them access to a secure system. Bruce Scheier is known for making this point.
- Reliability - When most software engineers think of reliability, they think of redundant components or extensively tested systems. Yet Jim Gray has found that the largest single cause of failures is operator error. No matter how many well-functioning, redundant components you have, if the guys who are supposed to plug them all together screw up, you're hosed.
If anyone has any other thoughts or leads, I'd love to hear of them. Some day I'd like to write an essay or a paper on the topic.
Email Rob:
Tiered Architectures and Cross-cutting Concerns
design, software development
April 21, 2003, 01:12 PM
In Architectures for Software Systems today we had a guest lecturer: Bob Monroe from Freemarkets.com. He talked about tiered architectures for web-deployed enterprise information systems. Having already built such a system (albeit a relatively small one) myself, most of what he discussed was old hat for me.
However, as he was discussing the separation of enterprise applications into tiers to handle presentation, business logic, and data persistence (a standard, well accepted pattern for such systems) I got to thinking about some of the problems we ran into with EE in splitting our systems across these lines. Basically, we found that certain concerns have a tendency to cut across those layers, an example being data correctness checking, or ensuring that data sent to the system by a user or another system conforms to the structure you expect it to. For instance, a "payment" field should only contain numbers and an optional decimal point, and no more than two digits after the decimal point. Some software component has to be responsible for ensuring this is true for all incoming payment values. But where should this component live? It'd be nice to have it on the Presentation Tier so we could provide the user with better feedback if they enter incorrect values (the payment text field could be programmed to prevent the user from entering numbers, @ signs, etc). But what if we have multiple clients? And what if the correctness of the data is security critical and we can't trust the clients to perform the check? Then we should probably also put it in the Business Logic Tier. But what if multiple applications are sharing the same data store? If one application doesn't perform the check properly, it may corrupt the shared database. So we should really also put the check in the Persistence Tier as well. So we wind up with this:
But hold on one sec. This means I have to replicate the data correctness checking code across all of these tiers! Not only does this add to the performance overhead, but since oftentimes the tiers are implemented using different languages (in EE's case, we use DHTML/JavaScript for the client-side Presentation Tier, Java for the Business Logic Tier, and SQL for the Persistence Tier) we have to duplicate the same logic in at least three locations in the system, which clearly violates the DRY principle. So it seems none of our options are viable.
After the talk, I asked Bob how his teams confronted this issue. He said it was certainly a problem, and they usually wound up doing validation checking via social conventions (in other words, pick a tier to check data correctness so you can guarantee to lower tiers that the data is correct. Then tell the programmers "you'd better make sure you get the data checking right or the rest of our application is screwed!"). Though I do believe this is the best decision given the current state of the practice, I'd think we could find a better technical solution than this.
I have a few thoughts on how to solve this issue. Aspect-oriented programming may hold some promise, since the cross-cutting concerns can be implemented as aspects that can be attached to the relevent objects. But most aspect-oriented implementations I've heard of only work with a single language. This won't help if you've got the Javascript/Java/SQL combination we've had to deal with.
Another possibility is to represent cross-cutting concerns in a language-neutral format (such as a simple domain-specific language) and write code generators to produce the necessary Presentation, Business Logic, and Persistence code. This is the approach advocated by the Pragmatic Programmers. But this can get complicated since you may have to write quite a bit of infrastructure code to properly integrate the generated code in with your exising HTML pages, Java classes, and SQL tables.
It seems to me that vendors could provide better frameworks to help support cross-cutting concerns such as data correctness checking. These sorts of concerns are where architects and developers need the most help, so why aren't they being addressed? I can only conclude that most vendors are out of touch with the real needs of their users.
Posted by Dave on April 23, 2003 at 01:20 PM
Right on Brother...Damn EE cross-concerns....
Email Rob:
Dreaming Up Mantras
usability
April 20, 2003, 10:08 PM
Kevin recently posted an interesting comment about usability mantras in the U.S. government. He specifically refers to the "three clicks or less" mantra of the OMB's government information consolidation project. His slant is that this mantra is meaningless from a usability perspective since finding information has much more to do with search interaction and results presentation than it does with the number of clicks, so "three clicks or less" is really more of a non-goal and may well lead the project down the wrong directions. And I think he's right.
The problem here as I see it is that the usability goals of the project aren't made clear (at least in the PR article). Why three clicks? Is the point that people should be able to find government information quickly? If so, then perhaps that should be the stated goal, and the designers should be given sufficient leeway in how to realize it. All too often I've seen people get bogged down by an oversimplified solution to a complex problem. This fixates their thinking into a framework that hides the true solutions from them, potentially causing huge wastes of time and money.
What's even worse from my perspective, however, is that the article doesn't mention how they came up with this consolidation idea in the first place. Did anyone do any studies of how people use government information services? What sorts of information do they look for? At what times and from where? What sorts of people look for what types of information? Simply consolidating the government's databases may not be the whole solution, or even part of it. The point is you just can't know until you go out and see what your users need. And it is shameful how rarely that gets done. I'm sure even a project with a "paltry" five million dollar budget could afford to run a few such studies. And I'm really becoming convinced that even a few can be much better than nothing.
Email Rob:
Email Rob: