 |
« | Week of Jan 18 | < | Individual Entries | > | Week of Feb 1 | » |  |
 |
 |
Movable Type Needs Multithreaded Rebuilds
software development, usability
January 31, 2004, 09:40 PM
I've noticed that posting a comment on roBlog takes quite a bit longer than it used to since I released Heimdall. Although it fortunately does not take so long that browsers time out the request, it takes long enough to seriously impact the usability of the system; at best many posters will be annoyed by the delay, and at worst may think the server is not connecting and may try submitting the same comment again. Certainly the lag is far longer than the 1 second optimum response time and even exceeds the maximum 10 seconds. I clocked it at close to 20.
The problem, I believe, is that Movable Type rebuilds all weblog pages that may be altered when a comment is posted. Since roBlog has many index pages and complex template code, this takes some time, and that contributes to the long post time. For this very reason, Movable Type doesn't bother to rebuild archives when it receives a Trackback ping, since the tool that sent the ping may have even less patience than a human (or something...).
So here's my totally unsolicited advice to Ben Trott: don't rebuild the weblog files during the CGI request! If CGI doesn't allow for the execution of code on its thread after the HTTP response has completed (I'll admit I've never tried such a thing), then spawn another thread to finish the rebuild task in the background. Only generate sufficient information to provide the user (the comment poster or trackback sender) with enough feedback for them to realize their action was successful; the rest of the rebuild can wait until the request is closed to proceed.
And if you don't want to do it yourself, keep in mind I'll be looking for a job starting in August...
Email Rob:
When Reuse Is Bad For Real Use
software development, usability
January 28, 2004, 11:26 PM
Joel has an interesting article up on the hassle of Microsoft's .NET runtime environment. Joel prefers the "old" approach of using a linker to bind up all the required libraries and resources with the program itself. Despite my love for Java, which is also afflicted with a runtime environment, I agree with him.
Although it is widely considered good software engineering practice to separate reusable code into its own modules, the approach of using system-level shared code libraries takes this too far (run-time environments are essentially just collections of these libraries). Having multiple applications access a shared code base foists the task of upgrading and maintaining that code base on the user. Linux is notorious for this sin; users must often upgrade many shared libraries before a new application will work, and a result software installation is a nightmare. Windows is better nowadays since they developed Windows Update, but as Joel pointed out, with the frequent calls for reboots and other task interruptions, it's still a major annoyance at least.
The Macintosh has always considered each application its own separate entity, and hasn't really had a concept of shared libraries. As a result, software installation (and backup) is painless; just drag an application into a folder. I'm no Apple worshipper, but they've had the right idea all along here. Application developers should worry about whether they have the right version of the right libraries available when they ship, and that should be the end of it. Modularization has many benefits, but none of them directly effect the user. It's just none of their business.
Email Rob:
A Map of my Daily Walk
design, information
January 28, 2004, 10:58 PM
For my Mapping and Diagramming class I created a map of my walking route from the front door of my house to Margaret Morrison A11, the room where our class is held. Karen asked us to imagine that an old friend (and not just any friend, a particular friend) had come into town to visit and we needed to leave directions at our house so that they could find their way to CMU to have lunch with us. I chose to design my map for my friends Kim and Alaina.
I'm fairly pleased with the results. The form of my walking route in this schematic line representation is interesting and the elements of the piece fit together rather nicely. I tend to favor a minimalist approach to visual design perhaps because I still have too little confidence in my instincts to add much "decoration". But I think it worked for me with this piece; the simplicity made it easier to focus on attractiveness and understandability.
It struck me that this piece came together fairly easily because the users and their tasks were so focused and narrow. We were designing for one person, and all we had to do was get them from our houses to school. The design solution flowed almost naturally. This leads me to believe that one approach worth trying with more complex problems is to split them up into their component tasks and then design solutions for each task. You can then integrate the "sub-designs" into a larger metaphor that satisfies all tasks, taking into account the relevant tradeoffs and priorities. This has the side benefit of creating easily dividable work for the members of a design team.
Email Rob:
Autolinking URLs in Movable Type Comments
internet
January 25, 2004, 06:42 PM
Consider this a followup to my nifty MT plugins post.
Movable Type has a feature to automatically turn URLs embedded in comments into links. Unfortunately, for reasons that are not entirely clear to me, you cannot enable this feature and allow HTML in comments at the same time. Fortunately, I found a post on The Girlie Matters that explains how to use Brad Choate's Regex Plugin to autolink URLs in comments even when HTML is enabled.
Make sure you add a no_html="1" attribute to the MTAddRegex tag, however, or the regex will munge valid link tags by trying to turn their href attribute values into links, which you probably don't want, needless to say.
Email Rob:
Ratings and Online Forum Design
design, internet, society & sociology
January 25, 2004, 01:54 PM
Many large online forums such as Slashdot and Kuro5hin support collaborative filtering mechanisms for user-supplied content. The general purpose of these mechanisms is to help make the content people do want to read visible and to hide the content people don't want to read. In both communities mentioned above and many others besides, this takes the form of "moderation", where some users are given the authority to judge whether content supplied by other users is "good". As an aside, Paul Resnick, my former CSCW professor, has a CHI paper coming out on the topic of Slashdot moderation.
Moderation is a feature that tries to deal with many problems at once. The "quality" of a comment or story is subjective and may be based on many factors, and one person's notion of quality may or may not impact another's desire to read the content. Some of these factors may include:
- Spam is generally frowned upon by everyone, and easily identified by everyone. The filtering system need only mark content as "spam or not spam".
- Trolling is harder to detect, and feelings on it are a little more mixed. One person's troll is another person's devil's advocate. Also many people accused of trolling are simply espousing an unpopular opinion, which many forums may wish to actively encourage. So the solution here is less clear; there may need to be more consensus about a comment or story before it gets marked as a troll. And even then the appropriate solution may not be to filter out the content, but merely to mark it as a troll as a warning to other users.
- Information accuracy is theoretically objective but in practice is hard to determine. Truthfulness may be better determined through comments presenting supporting or contradicting evidence than moderation.
- Information interest and relevance may be supported well by moderation, depending on the diversity of the community and how specialized its interests are. A diverse community may have many conflicting opinions among its readership as to what is interesting and relevant, whereas a more specialized community may enjoy more consensus. Community designers need to take into account the type of community they are designing for when judging how (or whether) to address this issue.
- Unpopular opinions can be squelched through collaborative filtering, and again community designers must consider the type of community they wish to create and whether their design goals include encouraging or discouraging heated debate.
The point of all this is not to (necessarily) recommend a more complex moderation system (moderation systems are probably overly complex as it is) but rather to suggest that filtering community content is a complex issue that needs more thought put into it to come up with an appropriate yet simple solution.
The major difficulty with designing collaborative filtering systems is that you must keep the needs of two very different types of users in mind: the reader and the filterer (and possibly the poster of the filtered content as well). The reader wants to see the most interesting content without having to wade through a bunch of crap, but the filterer needs the proper incentives to contribute to the filtering system, and often there is little or no direct benefit to him. How much you can demand from your filterers depends on the type of community; it's worth remembering that the majority of users are social loafers and free riders in any online community (although these terms seem overly harshly judgmental in this context). Its for this reason that I'm always suspicious of collaborative filtering as a panacea; many designers are excited by its potential but, I believe, often ignore the subtle complexities of the design problems it introduces.
Posted by Chad on January 26, 2004 at 10:33 PM
I agree that the terms 'social loafers' and 'free riders' mischaracterize the vast readership who simply doesn't have time to get involved in every discussion they come across online. That was one of the things that bothered me most about the CSCW class last semester: treating low participation rates like it was a something to be remedied. A very - sorry, gotta say it - social science view on things. Why not consider a wider set of activities as 'participation', instead of just contribution?
Posted by Rob on January 27, 2004 at 09:05 PM
'Lurkers' may be a better term, although that also has negative connotations to an extent. But I agree that there's often no reason to think it's a problem; in many online communities having a large number of people who read but don't post adds value to the community, and indeed if everyone contributed content, the community would quickly become unwieldy and break down.
But my point was just about collaborative filtering. In order for the concept to work, some people must contribute time to filtering, and there must be enough of these to filter a reasonably high percentage of the content. The question is: what motivates these people to filter? Do they have a motivation? Often filtering is menial work once the novelty wears off. And do they have the "right" motivation, i.e. the one that will make their filtering decisions useful to the readers? These are questions designers need to be asking. And I believe they are often hard questions, and that it's easy to get the answer wrong.
Posted by Chad on January 28, 2004 at 08:45 AM
Re: some people: I spent a couple of months in a group who was trying out wikis and weblogs. The weblog thing didn't take for most of them, but the wiki did. What was interesting was how some people took up housekeeping roles for filing and creating an information architecture for the site. If I remember correctly, the housekeepers weren't the same people who set up the wiki in the first place.
Maybe there's something about making roles that need to be filled more obvious to users. I'm hardly a sportsman, but there might be a comparison to a football or basketball team. It's possible to play without having specialized roles, but knowing and playing the roles makes the level of play much more interesting, and, I imagine, gratifying.
Have you seen any literature about the roles people play in various CMC systems? I've read about moderators and trolls in discussion groups, but it seems like you could expand the discussion to other systems as welll as across time, as a particular instance of a system evolves...
Posted by Rob on January 29, 2004 at 10:17 PM
I can certainly see your point about the importance of roles from my own experience. I don't know of any research about roles in CMC systems in particular, although I know Bob Kraut claims there's research that indicates assigned roles make people more productive in general. Chapter 4 of Community Building on the Web discusses roles in online communities (although not necessarily research-supported).
Certainly one design direction for a collaborative filtering system would be to make the filterer role more clear and perhaps even to try to make it a desirable position to hold. But it depends on the system, of course. It's hard to talk about these things in the abstract.
Email Rob:
Posted by generic valium radioactive mayoress on October 19, 2007 at 01:54 AM
generic valium radioactive mayoress hypersthenuria decile
zanaflex boolean syncheilia harmony innavigable
atenolol twitched clout
lasix indiscipline expectorate
diflucan unpatented workaday scorza drawworks
diflucan polyphagous tobramycin
generic viagra online allophenes overvoltage
order soma online inhibiting gear
order tramadol periureteritis cyclical
paroxetine rats chiefly
generic ambien myelocyte equalized
generic zoloft decentralize during
generic viagra pharos scavenging
ultram online kingcraft cf
valium online hematuria drifted
order ambien chromatrope bipartition
trazodone splenogram magnetism
cipralex waster interstratal
buy alprazolam uncontradicted badger
buy cialis online hydrography lathwood
generic prevacid airfare motobloc
prevacid fume gynobase
cheap levitra splenoptosis posh
buy wellbutrin alnisi decalogue
proscar enlace camouflaged
buspar commonable varioliform
buy meridia whereat key
ibuprofen ecotoxicology tindery
buy soma online institutional nonmutual
imitrex dawn ebullioscope
cialis bacitracin debriefing
buy xanax online accepter interconnecting
viagra online foreclosure analgesine
generic prevacid airmobile estrone
purchase valium silker senseless
vicodin revenger perfumery
viagra online podalgia radiopharmacokinetics
levofloxacin reentrant imagesetter
seroxat neums protrude petroliferous downiness
cheap cialis online salsify overfull