Monthly Archives: April 2006

At the Revue..

Last night I was treated to a rare experience: The Mathematics Revue at the University of Copenhagen. My friend Jakob was playing saxophone in the revue band and had invited us to spectate. It was good fun. It reminded me of Biella Coleman’s research on hacker wit and humor, and it seems that this sort of punny, witty humour isn’t just for hackers but are common throughout the hard natural science subjects.

Actually, many of the best punchlines of the night were delivered by the lively audience rather than by the performers themselves. And whenever the lights dimmed for a change of scenery, the merrily drunk mathematicians (and physicists and computer scientists) happily began singing their favourite (mathematics-related drinking songs), beating a rhythm with their coconut shells (one of many Monty Python references).

It was all in Danish, and most of it pretty complicated stuff, punning on mathematical principles in ways I couldn’t make much sense of. But lots of it was pretty easy to follow, and with lots of pythonesque humor. As with all good revues, there were a number of songs – in Danish to wellknown Danish melodies, but here’s an bit that might give you an idea of the humor involved (the song is called “Det gode ved matematik” – which would translate as “What I like about math” – to the tune of “These are a few of my favourite things” from “Sound of Music”:

Diagonale komplekse matricer
Søde lemmata med smukke beviser
Operatorer og lækker logik
Det er det gode ved matematik

which roughly translates as:

diagonal complex matrices
sweet lemmata with beautiful proofs
Operators and luscious logic
That is what I like about math

.. It is self-deprecating irony and at the same time a straight-faced celebration of their subject’s weirdities. The encore was a pastiche on the Beatles’ “Let it be” which became “Få det læst!” (eng.: “Get it read!” or “read it now!”:

Jeg syn’s at matematik er herligt, frem for alle andre fag
Så jeg bør jo kunne få det læst
Men der er andet man kan lave, drikke løs og fyr’ den af
Jeg kan ikke klare det, få det læst!

Again, translated:

I like mathematics better than any other subject here
So I should be able to get it read
But there are things to do, getting drunk and naked, yeah
I’m not gonna make it, get it read!

Again, as I said, it was good fun.

Old Media on New Media

Delivery of the Economist seem to be spotty at best around here, so it wasn’t until today that I got my hands on last week’s issue with its survey of new media. It considers, in some detail, the possible consequences of everybody having a medium of expression through blogs like this one. Participatory media that may change the basic format of news. As Blog-venturer Sabeer Bhatia puts it:

??Journalism won’t be a sermon any more, it will be a conversation.”

The proper revolution of new media such as blogs and wikis is this: It will turn publishing into a social phenomenon where there is no final, authorized opinion – instead there’ll be a polyphonous whole based on open-ended equality, allowing each reader to make up her own mind from a wealth of various sources.

As Wired editor Chris Anderson says:

??We are entering an age of cultural richness and abundant choice that we’ve never seen before in history. Peer production is the most powerful industrial force of our time,?

He states that “opinion is a marketplace, and marketplaces work when you have liquidity.” To Anderson, the new participatory media provide that liquidity. And what is truly amazing is the speed with which this change is coming about. New media publishing in the form of blogs, wikis and podcasts is less than 10 years old. Wikipedia, perhaps the best known example of collaborative editorship, is only 5 years old.

This new, organic and social negotiation and interpretation of news and facts may well be as big a revolution for the way we perceive and develop knowledge as the transition from oral sharing of knowledge to a written and printed sharing.

Again, note that the keyword here is the “sharing” of intellectual property – an oft-discussed concept.

The global benefits of F/OSS?

In a Slashdot discussion on Open Source Software in the developing countries, the following comment was made by the self-consciously monikered FlyingPig:

At the moment software is frequently a tax that poor countries pay to rich countries to be allowed to participate. Poor countries often have weak currencies, but the local cost of goods and services is much lower than you would expect from the exchange rate. It’s like living at the top of an economic inverted gravity well; moving around the local maximum is not too hard, but bringing things in from outside is difficult. Any goods that have to be bought in the West are relatively speaking very expensive. Since the major desktop and server OS is produced in a small corner of the US, this represents a tax on international trade, applied to the Third World and with the proceeds going to Redmond.

FOSS means that work, whether localisation or support, can be done in the local region at local prices. It therefore levels the playing field, helping to achieve the (supposed) objectives of the WTO. And, in reality, it doesn’t reduce Microsoft’s profits as much as you might think because, in many cases, the alternative is actually piracy.

On the other hand, it creates middle class jobs (jobs relying on literacy, professional skills etc.). The biggest problem of many Third World countries is the lack of a middle class. Between the very poor (exploited) and the very rick (exploiters) there is no buffer of people to create a civil society. In China the very concept of civil society is still alien while it has emerged rapidly in Hong Kong, Taiwan and South Korea. India has a rapidly increasing middle class and is the world’s biggest democracy.

So, I know this may seem over the top: but FOSS provides support to fair trade, emerging democracy and free markets. And it does it while expending very little energy, so it contributes little to climate change.

Hell yeah!


Last night I spent some time downloading the beta version of Ubuntu 6.06. As it suggested that you use a Bittorrent client to download the 684 MB file, I dutifully complied in order to strain the Ubuntu servers as little as possible.

Unfortunately, I hadn’t looked properly at how the bittorrent protocol actually works. It is a Peer-2-Peer sharing application where “Peers download missing fragments from each other and upload those that they already have to peers that request them. The protocol is ‘smart’ enough to choose the peer with the best network connections for the fragments that it’s requesting.”

Since I live at a hall of residence which uses the University of Copenhagen internet connection which is very good indeed. That means that instead of downloading just the 684 MB or so I expected, it instead sent information back and forth to a total of 2300 MB.


Since we have such a good connection here, there are rules against abusing it. You’re allowed to download 2 GB a day, 3 GB a week and 6 GB a month. If you break the rule, the sanctions are simple: They cut your connection for a minimum of 4 days.

Which was what happened today. It looks like I’ll have to do without the Internet this weekend. A sort of forced holiday. Might just as well enjoy it…

Fieldwork in the Ubuntu community

Well, today I’m taking what feels like a plunge, though I guess that’s mostly in my mind. I’ve just sent this mail to the Ubuntu Sounder mailing list:

Hello all Ubunteros,

My name is Andreas Lloyd and I am a graduate student at the department of Anthropology at the University of Copenhagen, Denmark. Having used and enjoyed Ubuntu since november 2004, I have become very interested in the social workings of Free Software projects, and I wanted to combine my interest in F/OSS projects with my graduate studies. Therefore I propose to start an anthropological fieldwork study of the Ubuntu development community.

As I’m not much of a computer expert myself, I’ve been considering various other ways to contribute to the Ubuntu community. I’ve spent some time contributing to the Ubuntu documentation and the Danish translations, but I believe that it would be better for me to help improve the project by examining it from an anthropological perspective. You may have heard of American anthropologist Gabriella Coleman’s work in the Debian community[1], and it is this sort of studies of how F/OSS projects are governed and maintained that I take as my inspiration.

With Ubuntu’s ??Linux for human beings? catchline, and its much-mentioned Bug #1 [2], the project seems to have a clear goal of developing a F/OSS operating system for a wider user base ?? especially in the Third World. With this goal in mind, I find it central to examine the way that Ubuntu developers percieve, use and talk of computers, as it is my hypothesis that the shared cultural and social values and ideas of the developers are shaping the way the average user perceives and uses the computer. Take, for instance, the fact that Ubuntu is a distribution of Linux whose basic shape and form is inspired by Unix ?? an operating system whose cultural heritage originates from an age when there were few computers and no end users – and continues to shape the way both users and developers perceive and use the computer.[3]

I am especially interested in how and to what degree social conceptions and jargon concerning computing technology govern the way we use it, and I hope that this fieldwork will help uncover new perspectives on how software developers encode the computer and the software they write with their own social and cultural values and ideas.

One of my key interests here is the interplay between developers and users in the community – especially with regards to the development and discussion on usability issues such as User Interface Design, Internationalization, Localization and Accessibility which seem to rarely receive much attention in F/OSS projects. By studying the way the developers work together and discuss these issues, I hope to pinpoint some of the problems that can arise between users and developers of Free Software. And furthermore, I hope that my fieldwork will help create more focus on a field of study which has received very little social scientific research attention so far.

A fieldwork study such a this one is a mandatory part of my graduate studies and will be the basis on which I will write my Master’s Thesis. Initially, it was my plan to fit my fieldwork along a complete Ubuntu development cycle as the Ubuntu 6 month release cycle matches the average length of such a fieldwork quite well. I had planned to follow the now-codenamed Edgy Eft release cycle running from April to October 2006. But with the postponed release of Dapper Drake and the related shortening of the Edgy Eft release cycle, I am now ready to begin my fieldwork ahead of the new schedule. But in order to have the full 6 months in the field, I would like to begin the fieldwork soon after the date of Dapper’s originally planned release ?? which is today!

This may seem like short notice, but in an online context it is rarely any good announcing a project until you’re ready to follow through. Traditionally, anthropological fieldwork involves travelling to some remote part of the world, and spending a long period of time immersed in the local culture, learning their ways by taking part in their everyday life. But since the Ubuntu project is not centralized in any single location and has volunteers and developers spread all over the globe (though primarily Europe and North America), I will seek to do both

1. an online fieldwork and participation in the many digital fora and means of information exchange that used by the Ubuntu community: discussing on IRC channels and the mailing-lists, helping with bug triage in Launchpad, reading blogs and writing documentation and suggestions in the Wiki.

2. an in-person fieldwork focusing on visits to individual developers where I will spend some time interviewing, observing and participating their daily life and work routines around the computer in order to examine how the development work takes place first-hand. Along with this, I will go to the developer’s summits ?? such as the one announced to take place in June ?? and the few ??sprints? in order to meet the developers and study how they meet each other to create and develop the personal and social ties which are the basis of the online collaboration.

This form of ??multi-sited? fieldwork coordinated through the Internet has been developed by anthropologists in the last ten years, as it reflects the fragmented and globalized world which the discipline has as its object of study. I have received some grant funds to help finance these in-person field trips, so there it will not become any economical burden for the Ubuntu project.

Furthermore, as is usual practice with anthropological fieldwork data, all the material that I gather during the course of the fieldwork will be anonymized ?? unless the interviewed informants wish otherwise [4]. Also, I will make sure to present all of my findings to you, but please be fore-warned that an anthropological fieldwork takes time ?? and there are rarely any easy answers.

You are all most welcome to contact me (contact info below) ?? both those of you who may have questions regarding the fieldwork, or those who already now know that they do not want to take part.

If you are interested to know more about the theoretical basis for the fieldwork, I can send you the 10-page fieldwork proposal upon which the department of Anthropology at the University of Copenhagen has approved my fieldwork. It is rather full of anthropological jargon, but does explain the my project in greater detail.

If you are interested in knowing more about me and my academic background, feel free to read my weblog at or my Ubuntu wiki page at I will also be participating in the Bug Day tomorrow, and will be online in the Ubuntu IRC channels under the name ??lloydinho? – feel free to ask me questions there as well.

Best regards,

Andreas Lloyd
IRC: lloydinho on network


Let the fieldwork commence…

Fiction and gender

Two British literature experts have been conducting a study comparing the favourite fiction books of men and women. Many of the interviewed had some professional connection to literature.

Apparently, they were much surprised by their findings which showed that men preferred angsty existentialist books while women preferred books of passionate struggle. The top 5 lists of each gender were as follows:

Men’s favourites:
(note: Marquez and Tolkien are in joint fourth place)

1. Albert Camus ?? The Outsider
2. J.D. Salinger ?? Catcher in the Rye
3. Kurt Vonnegut ?? Slaughterhouse Five
4. Gabriel Garcia Marquez ?? One Hundred Years of Solitude
J.R.R. Tolkien ?? The Hobbit
5. Joseph Heller ?? Catch 22

Women’s favourites:
1.Charlotte Bronte ?? Jane Eyre
2.Emily Bronte ?? Wuthering Heights
3. Margaret Atwood ?? The Handmaid??s Tale
4.George Eliot ?? Middlemarch
5.Jane Austen ?? Pride and Prejudice
Toni Morrison ?? Beloved

What I notice is not so much the theme of these books but rather the simple fact that men prefer books with a male protagonist while women prefer books with a female protagonist.

Big surprise.

My guess is that people prefer books with a protagonist and situations that they easily can relate to. That this is now proved as be gender stereotypical shouldn’t really surprise anybody.

A brief primer on Human-Computer Interaction

I’ve been reading several books on Interaction Design and how to design usable computing interfaces. I’ve read Alan Cooper’s About Face 2.0 and Klaus Kaasgaard’s Software Design & Usability. The former is a sort of entry-level book to the world of HCI, and it takes the reader through all the various stages of design ?? from the initial inquiry to prototyping and usability testing. The latter is an interview book where the author discusses issues central to HCI and Interaction Design with leading people in the field. Here I’ll try to sum up some of the insights of these two books that struck a chord with me – and maybe add some of my own.

** A goal oriented approach

Alan Cooper’s first central observation is that for most users, computing technology is only a means. Not a goal in itself. This observation is central to understand how computers are perceived and used. Many HCI models (and thusly most software documentation) focus on the various taks associated with computers: pointing, clicking printing, saving; Cooper argues that all good design should begin with making clear what the user would want to accomplish using the software.

As longtime HCI consultant Stephanie Rosenbaum tells Klaus Kaasgaard:
??For most people, the computers that they use as tools are not central to their goals, so they are not willing to spend much time to understand computers.?

Much software is technically capable of any task that the user might have to do, but still fails as its designers haven’t considered which of these tasks are essential in achieving the users’ goals:

Software that enables users to perform their tasks without addressing their goals rarely helps them be truly effective. If the task is to enter 5000 names and addresses into a database, a smoothly functioning data-entry application won’t satisfy users as much as an automated system that extracts the names from the invoicing system.

Cooper states that the users’ most important goal is ??is not to feel stupid.? You do feel stupid if you have to enter 5000 names by hand. And you do feel stupid everytime you see a dialogue box telling you that the program ??has encountered an error? or has ??failed to notify the library? or couldn’t ??query the database? without telling why or what to do about it, and only offering a ??OK? option.

What?! My program just crashed, it’s not ‘okay’!

** Contextual inquiry

Cooper, and most other interaction designers with him, argue that in order to identify user goals and thereby streamline design to fit the user, it is necessary to study the users’ daily routines. Observing and discussing the daily goals and tasks of the users in their own work environment can help the designer understand the needs and perceived needs of the user.

This sort of ??contextual inquiry? is a very ethnographic encounter. A sort of ??collaborative exploration? of the workplace over an entire day. The user tells of his routines and goals in a discussion subtly led by the designer to touch upon on the relevant aspects that he has identified. By encouraging story-telling and show-and-tell the designer can develop a better understanding of how work flows in the workplace.

Cooper warns that the designer shouldn’t discuss product-related technology with user (such as ??what kind of wireless networking would you prefer??), and avoid making the user a ??co-designer? (by asking questions like ??how would you like it?) as the user rarely have a complete conceptual model of the work he performs (Cooper argues that this is what the designer should focus on constructing).

Instead, questions should focus on the actual daily use of technology, preferences, motivations and priorities of the users:

What are the most common things you do with the product?

What do you like about it? What drives you crazy?

What is most important to you in your work?

What do you enjoy most about your work?

What do you do when you encounter a problem?

** Design paradigms

Once you have a clear idea of what the users’ goals are (having interviewed more than a few users in the manner described above), you can begin designing ?? that is the openended, creative process of finding a solution to the users’ problem ?? ie. the goals they want to accomplish.

A lot has been written about design in general but the essential element here is to base the design in the observations you’ve made, constantly testing your ideas against them. Many of the designers and consultants that Klaus Kaasgaard interviews state that it is very important not to begin coding a prototype of any of these early designs, because most programmers will grow very attached to any code that they have produced, even if it is just a 1000 line mockup.

Instead, it is best first to decide on a form before any coding is done at all: Use storyboards, dramatizations, mockups to present how you envision the use and feel of the program so that there is a final goal that the programmers can work towards.

According to Alan Cooper, there are three dominant paradigms in the conceptual and visual design of User Interfaces:

1) Implementation-centric
based on understanding how things work. The design mirrors the actual construction of the program. It often demands understanding of the program. Command line programs work in this way, and it is the way that is preferred by programmers themselves as they often find an inherent elegance and simplicity in the fact that the interface design reflects the system. I guess this makes it easier to fix interface bugs, as well.

2) Metaphoric
based on intuiting how things work. The design mirrors well known real life interfaces that the user is already familiar with, and therefore has some intuition from which to extrapolate how to use the interface. One of the most developed examples of such design is the desktop metaphor with its iconic trash bin, in and out boxes, files and folders. Other examples are music and video players that copy the interface from CD or DVD players.

3) Idiomatic
based on learning how things work. Idioms aren’t intuitive or sensible but they stick once they’re learned. We understand idioms like ??kicking the bucket? or ??beating around the bush? not by understanding or intuiting it (if you hadn’t been told, how would you figure out what ??cannot hold a candle to? means?) but by memorizing it. Most GUI conventions are idiomatic ?? such as resizable windows and endlessly nested folders. Most computer games use idiomatic design as well.

In an implementation-centric paradigm, users are most often simply expected to know what a given program is capable of (or be able to read the documentation to find out). But since most users would rather be successful than knowledgeable, it is required that the functions of programs under both the the metaphoric and idiomatic design paradigm are easily usable without much prior knowledge ?? that the affordances of the program is made evident.

Affordance is a term introduced by the nestor of UI design, Don Norman, and is defined as ??the perceived and actual properties of the thing, primarily those fundamental properties that detemine just how a thing could possibly used.? That is: how obvious an item’s use and mode of use is to the user. The way that things can communicate their use through their design.

For example af door bell usually has button the size of the tip of a finger, at just the right height to be easily pushed. According to Norman, it is basically begging us to push it. The same with power buttons on PC cabinets, they tend to be so big and tempting, anybody who has had their computer accidently turned off by a toddler will know the lure of the power button whispering ??Push me!?.

With user interfaces on the computer, it is slightly more tricky. GUIs tend to be two-dimensional, grey and boring. But by using simple shading techniques, buttons can appear more pushable, windows can appear more draggable, by hinting that it can be manipulated in new ways, the user will often try, and thus learn new ways of using the computer.

I find that the best use of the idiomatic design paradigm takes place in computer games which often use tutorials to good effect, showing off the conventions and idioms of the game one by one. Often, the best part of the game play is where the learning curve matches perfectly the pace of play. Conveniently introducing new elements of play just as the player has memorized the old parts. Games like Prince of Persia: Sands of Time or Civilization get this learning curve just right. I think it should be perfectly possible to make tutorials for most programs in much the same way.

Also, see Seymour Papert’s interesting discussion of the failure of “edutainment“.

** A brief discussion of semiotics
I’ve found that the semiotic theory of Charles Peirce is helpful here in order to understand the creation and navigation of the signs used in GUIs.

Semiotics is the study of signs, not merely visual signs such as road signs or symbols or paintings ?? but also words, sounds and even body language. Peirce says that anything can be a sign as long as someone interprets it as ‘signifying’ something – referring to or standing for something other than itself. Peirce found three main types of signs, categorized according to the relationship between the sign and the signified object. In a GUI that would be the relationship between a button and the associated function.

These three types of signs are

1) Icons
are signs that are perceived as resembling or imitating the signified objects (recognizably looking, sounding, feeling, tasting or smelling like it) – being similar in possessing some of its qualities. Icons are a central part of any GUI ?? for instance the use of the trash bin to signify deletion; an envelope to signify sending a message or a house to signify Home (whether it is a home directory or a start home page in a browser).

2) Symbols
are signs that do not resemble the signified object. Instead it is fundamentally arbitrary or purely conventional – so that the relationship must be learnt. Most GUIs use some symbols as well: The ??refresh? button in the browser or the alert icon (the exclamation mark in a triangle).

3) Index
are signs which are not arbitrarily but directly connected (physically or causally) with the signified object. This link can be observed or inferred, such as footprints, echoes or a pointing ‘index’ finger.
Indexical signs in GUIs are often related to user actions. For example marking a selected object in a different colour or the cursor changing shape when associated with a certain action ?? such as copying or moving a file.

For a comparison of GUI icons in various modern operating systems, check out this wonderful chart.

The problem with these signs usually arise when the user interprets a certain sign in a markedly different manner from what the designer expects. Designers often call this confusion on themselves by using the same signs for several different functions. For example the magnifying glass which is both used as an icon for zooming in and out, but also as an index for searching ?? probably due to a cultural connection with Sherlock Holmes, cf. the Mac OS 9 search application named Sherlock.

For more on the use of semiotics in relation to GUI design, check interface designer Luke Wroblewski’s homepage and blog and this interesting essay on the issue.

** Actual implementation
When you have decided on the design paradigm you want to base your design on, and have developed the appropriate idioms or metaphors, affordances and signs to make the program easy to learn and use. And you have visualised how the user is going to use the program, you can begin the actual implementation of the code. Cooper has a fair few pet peeves and pointers on how to develop the GUI for any program:

– Avoid unnecessary reporting: Don’t use dialogs to report normalcy!
Ex. When you put something in the trash, you expect it to go in the trash. Don’t ask me if I’m sure. Just make sure I can undo it later.

– Ask forgiveness: Don’t hold up procedures but finish them and tell us of any errors afterwards!
Ex. If I copy several hundred files all at once, and one of them have a permission problem, then don’t stop the entire program to receive response on that file. Instead, copy all the other files with proper permissions and gather up the problematic ones in one error report afterwards. Extra points if there’s an offer to solve the permissions problem with that report.

– Modeless feedback: Offer relevant information immediately and dynamically.
Ex. Many people use the ‘word count’ function all the time. Why is it hidden away in a menu and a dialogue box when that information could be directly accessible from the normal document view.

In general: Minimize excise!
Excise is the extra work that doesn’t contribute to reaching a goal but are necessary to accomplishing it all the same. Excise comes in many forms, but especially these are worth noting:

– Flowstoppers: Remove flowstoppers such as dialog boxes, passwords, permissions, errors and unresponsiveness. And if flow stoppers are absolutely necessary in a given situation – make sure to make it as clear and as helpful as possible. For a comprehensive list of un-helpful flowstoppers, see the Interface Hall of Shame.

– Navigation: Reduce the number of places to go. Simplicity in presentation is apparent: Don’t force the user through submenus and dialog boxes to reach a certain function. Place functions according to use. Provide an overview of the functions. Avoid hierarchies (I, for one, continue to have great expectations to the use of tagging and integrated searching utilities. When can we expect an OS based on tagging rather than a hierarchical file structure?)

** Getting help
Once you have your program prototyped, or even finished, you can worry about documentation. Alan Cooper argues that documentation is mostly read by what he calls the “perpetual intermediates”.

He argues that since most beginners work relatively hard to acquire the basic computer skills and understand the basic conventions of the GUI, they quickly learn enough to succesfully accomplish the goals they want to achieve, thus becoming intermediate users. Most users are thus intermediates, only a few of which will have the drive and the interest to become proper computer experts.

These intermediate users tend to have an idea if something can be done through a given application, and are they will try to use the documentation to find out how. Cooper’s advice is to optimize documentation for these intermediates. And again, it is important to think in goal-oriented solutions: When users consult the documentation it is usually with a ??How do I…? question on their lips but usually they will lack the proper technical vocabulary to know where to look.

As the usability expert Jakob Nielsen says to Klaus Kaasgaard: ??Anytime a user goes looking for help, it is a cry of desperation, almost.?

Most users usually try to figure stuff out themselves before consulting the documentation when this fails they’re already frustrated, and as Nielsen states: ??From the moment you ask for help, until you get it you start forgetting what you’re doing.?

Therefore, documentation needs to be as gentle a ride as at all possible. It is essential to have an index with lots of cross-references and a brilliant search function. The sort of search function that can guess that when you enter “make picture brighter” will refer you to the entry on the brighten-contrast tool, or when you enter “show time on message” will refer you to the entry on the timestamp function.

Also, to help and encourage the user to use keyboard short-cuts, these should be both easily learnable and usable (preferably with just one hand – but no space cadet keyboards, please!). All of these short-cuts should also be available as a list from the help menu, so that it is easy to look up in case you forget one.

** Conclusions…
With so much thought and deliberation on the matter of Human-Computer Interaction Design, it seems relevant to ask how it can be that there continues to be companies that produce software without thoroughly considering the way it will be used.

The computer scientist Terry Winograd touches upon this in his discussion with Klaus Kaasgaard: There is a constant rush to bring new products to the market. Just as quickly as you have something usable, it gets marketed, packaged and sold. No matter whether it is ready or not.

The programmer-turned-novelist Ellen Ullman reflects on this mode of constant hurry and turmoil which defines the entire computing industry. She says:

“We build our computer (systems) the way we build our cities: over time, without a plan, on top of ruins”

She argues that the strain between backwards compatibility and the integration of new features leaves little room for concern for polish and usability. New ideas develop so quickly that we have come to expect “new” all the time. We absorb change so quickly that we tend to forget how short a time much of this technology has been with us.

One illustration of this can be found in Kaasgaard’s 1999 interview with Winograd. Winograd had supervised Google founders Larry Page and Sergey Brin’s doctoral work at Stanford as part of a project under the Digital Library Initiative, and could recommend the new start-up Google as an example of a promising new technology. Kaasgaard later notes that “it does seem rather efficient.”

But Google’s phenomenal rise to fortune and verbdom isn’t simply because of its technological capabilities. Its popularity might well also be related to the fact that it makes the computer simpler and easier to use. Just type your query, and Google will find what you’re most likely looking for. Automagically.

It is that kind of simplicity that appeals to user. The computer itself is only a means. It is the goals that it allows you to accomplish that are interesting. The less central the computer is to the user, the less patience they will have with it. This is not necessarily a bad thing. Sometimes you learn more from the doubting late-adopters than from the ones willing to change their routines to accomodate new technology.

Some Interaction Design thinkers, such as Anne Galloway and Jean Burgess argue that we need to slow down this accelerating technology race. That calmness and even boredom also are relevant aspects to consider about interaction design.

Slow or not, design of Human-Computer Interaction does require attention. Perhaps most basically, Interaction Design requires a change in attitude towards software production in general. Perhaps even a turn away from crufty compatibility concerns or fancy features to a focus on useful simplicity.

Fredericia Hardcore Festival

Having blog often leads to being in the awkward position that you realize that there are things that you want to blog about but you don’t quite manage to fit in. I’m in such a situation now, having looked through some of my old pictures, I’ve realized that I wanted to blog about my adventures at the Fredericia Hardcore Festival last year.

Now, that festival was in late July of 2005, so I’m basically out pretty late with this one, but little matter. I think the pictures are worth sharing all the same. I went to the FHF just to listen to one band, as I’m not really a big fan of hardcore punk. The band is Against Me which isn’t your average punk band. They manage to infuse their brand of punk with strands of folk and blues, maintaining the rebel nerve and energy of the punk with the melody, melancholy and charm of folk blues.

I first heard of them through the Golublog in some discussion on what songs to play at your funeral. I don’t recall how exactly, but Against Me’s “What we worked for” was mentioned, so I went to download that from their website. I liked it a lot, but didn’t manage to find out more about them, until I happened on the program for the FHF where Against Me were to play their only gig in Denmark. So, off I went.

The festival took place in a community youth centre in the Danish provincial town of Fredericia. The centre is an adapted train station:

A fair bit of graffiti had been done for the occasion:

It was a lovely evening…

And then there was the concert itself. It was good fun. Unfortunately, all of the pictures I took turned out kind of bad, as my camera couldn’t deal with the light and the movement on stage. This one is the best of a bad bunch:

I enjoyed the concert, though I didn’t know any of the songs. Afterwards I bought their latest album, “As The Eternal Cowboy” which I can only recommend.

The anthropology of shopping

Yesterday I went shopping with my mother and my little sister in Randers (being back home for Easter and all). Both are preparing for my little sister’s big day of confirmation in May. Danish tradition bids that this coming-of-age rite is turned into a grand feast of consumerism, elevating the young teens to a whole new level of consumption: From plush toys and gaudy, childish colours to young trend and electronic gadgetry.

Of course, this transformation from nagging pre-teen to self-conscious shopping teen doesn’t happen overnight (and, I hasten to add, not all pre-teens nag – at least not all the time..). But the confirmation seems to be the grand formalisation of a new full-blown consumer. Specifically, most youngsters ask for money as presents for their confirmation party, as this puts them in the enviable position to blow all of that money in whatever way they want to come Blue Monday.

Blue Monday is the first week day after the confirmation parties, where all the newly-confirmed gather in the larger cities of Denmark, all dressed up in the latest streetwear and ready to spend money. They go browsing around town, drinking their first beers, maybe even smoking their first cigarettes and grow ever more distracted by the opposite sex.

All this still awaits my little sister (12 years younger than me) So it was with some interest I went out shopping with her to get her young trend street outfit for the big day-after-the-day. And it turns out that she’s already an extremely accomplished shopper. At age 13, she’s probably better at shopping than I’ll ever be. Where my self-confidence drops upon entering a high-street shop, knowing that I’ll be brandishing my (lack of) style in front people who sell clothes for a living, my little sis enjoys making these people jump to do her every bidding.

My mother tells me that sis and girlfriends spend hours every week after school hanging out in various clothes shops, browsing, combining various styles, discussing which pieces of clothing might look good together. They don’t buy a lot, obviously. Since they don’t have much money. But that will change soon enough.

But this made me think. I guess it’s quite the standard for young people today to spend (what I consider) inordinate amounts of time browsing and shopping. They graduate with a degree in shopping at age 13 or 14, and with those skills honed so well at that age, they can scale almost to absolutely outrageous levels of consumption.

And with professions like “personal shopper” and “home stylist” becoming more and more accepted, the culture of shopping is reaching a wholly different level that I find both intriguing and desperately frightening.

So I looked around to see if there were any anthropological studies on shopping. Sure, there’s plenty of stuff on “Material Culture” and “the Anthropology of Consumption”, but I’m more interested in the phenomenology of shopping: The general bodily experience and exploration of shopping. It is much like Walter Benjamin’s concept of the flaneur, but even closer: It is no longer window shopping, it’s entering and conquering the shops to define it in your own image.

It seems that most of the anthropology that is being done in the field of shopping is done by the money-making kind of anthropologists. The sort hired to help shops make it even more likely that people don’t merely browse but buy, too. To most of the anthropology students I know, this would be considered a bad application of anthropological methods. Take for instance this observation taken from a New Yorker article on “The Science of Shopping“:

Paco [former student of urban anthropologist William Whyte and self-proclaimed “retail-anthropologist”] is considered the originator, for example, of what is known in the trade as the butt-brush theory-or, as Paco calls it, more delicately, le facteur bousculade-which holds that the likelihood of a woman’s being converted from a browser to a buyer is inversely proportional to the likelihood of her being brushed on her behind while she’s examining merchandise. Touch-or brush or bump or jostle-a woman on the behind when she has stopped to look at an item, and she will bolt.

So, of course, Paco’s advice to shop managers is: “a women’s product that requires extensive examination should never be placed in a narrow aisle.” It’s obviously good for business, though most anthropologists, being of a more idealistic, anti-capitalistic bent, would shudder at the thought of giving such advice. It seems low, somehow.

Yet, it is turning into a full-fledged branch of anthropology: Business Anthropology. I found this very informative discussion of the matter on BBC, which describes the various aspects of the field – and obviously, not all of it is as foul sounding as the retail anthropology mentioned above.

One of my fellow anthropology students at the University of Copenhagen, Mikkel, is currently doing his fieldwork at a Danish firm hoping to be at the forefront of this new trend. Funnily enough, it sounds like he might be the only real anthropologist there – but since other professionals have no qualms about taking on the challenge of the ethnographic method, they claim the title as well.

So where was I going with all this? Oh yes: Shopping is both an art and a science nowadays. It most certainly isn’t something for the casual participant.