Google Sharing vs. Tumblr? Tumblr!!

Main point of this post: I'm now going to share interesting links that I find with commentary on my Tumblr page.  (RSS feed is here.)  You can stop reading right here!   For more on the reasoning behind this decision, keep reading ahead. 

I wrote a long post on how the disabling of the Google's "Note in Reader" bookmarklet (which went hand-in-hand with disabling Google Reader's sharing features) had taken the wind out of my sails, turning it into a lengthy point about how designed products end up working out for reasons other than what their designers envisioned. 

That was an academic point.  But what next?  I am really confused.  On the one hand, there is the Greasemonkey script that re-installs the sharing features in Google Reader; on the other is Tumblr which I have started to use as a sort of scrapbook of excerpts of interesting articles that I have read.

The Greasemonkey script is great - and it sort of suggests that Google has left the infrastructure for sharing in Reader intact while disabling the outer manifestations of it (the "share" "share with note" buttons, the list of followed people, etc.)***.  But how long will this infrastructure stay the way it is?  Google Buzz is going to be phased out soon and many people used Google Buzz to see the shared items rather than seeing them to Google Reader - so will this feature ever be the way it was?  And on and on - the uncertainty seems too much.


Which is why I've pretty much decided to take the leap into using Tumblr.  Of course, this means that I have to start building my network from scratch - but at least there's no uncertainty.  And one of the great things about Tumblr - as I've discovered from using it over the past few days - is that it really makes you read the piece in question.  That's because Tumblr is set up as a kind of commonplace book which means you need to pick out a paragraph or so from the piece that really really intrigues you; I've found myself reading pieces with that in mind and it's a big help.  Plus the commentary format where you take an extract from the piece and offer commentary on it is great for expressing quick thoughts on the piece in question.  In Google Reader, I would often share a piece without reading it with great care; it only needed to pass a certain minimum standard of "interestingness" and Reader made sharing much easier than Tumblr.  But all in all, there may be some advantages to the Tumblr model.  (Again, the whole thing goes to show how technical systems structure our practice in interesting ways.) 

That is all.  Tumblr link here. 

*** This seems like a true instance of the "Do no evil" motto that Googlers spout.  Also it's an interesting facet of information systems in general.  You can leave the infrastructure intact while still disabling a feature, thus allowing users to use it for themselves if they are enterprising enough.  Plus only some users need to be enterprising (the guys who wrote the Greasemonkey script in this case); the rest of us can reap benefits if the workaround is shared widely enough (and it seems to be, in this case). 

The unintended consequences of technical tools: the demise of sharing in Google Reader and why I will miss it

One of the first things we learn in fields like STS, HCI or Design Studies is that technologies often get used in ways that their designers have not imagined, and that this is both wonderful and productive, but can also be subversive and frustrating (for different people).  It's particularly trying for a designer: after all, the most important thing about design is to make people behave in a certain way, through certain kinds of artifacts (the button that is the only thing that can be clicked, the door-knob that has to be turned in order to pull the door, etc.) - and yet try as you might, it's never quite possible to get people to behave in exactly the way you want.  However, sometimes, having users do things with your design is a boon; it makes the application more flexible and increases its value.  One of the things about good designers then is that their designs are useful, rigid but not too rigid, and leave just enough room for all those workarounds, tricks and shortcuts that users will come up with.

All of this is a long way to say: I am bummed because Google Reader has disabled its "Sharing" features. I'm still going to continue to use Reader, I still like its interface and I love its "tagging" feature and its keyboard shortcuts.  I'll miss the "Sharing" aspects because I'd built up a group of like-minded contacts (most of whom, I'd never met or talked to, my Reader buddies, so to speak) whose links I often found most interesting and most relevant to my own interests.  But even more than that, the "Sharing" feature of Google Reader allowed me to do what I'd always wanted to do: have one receptacle for everything on the Web that I found interesting, which I could then search through as and when I wanted to.  I don't think the Reader designers imagined that their "Sharing" feature could have other uses but that's what hurts most right now.  I had a workflow which I thought I had perfected and it was all through Reader - and now I have to start all over again and come up with another workflow.  In a way, this goes to show the danger of overly relying on one particular technology. 

Let me start from the beginning.  The discovery of RSS feeds was the best thing that happened to my web reading habits.  I read randomly back then, and one had to actually go to a website to read - and this was difficult to do, I used bookmarks to remember all these sites I found interesting - yet it never quite worked out.  Then came RSS feeds and suddenly, I didn't have to go to a website anymore, instead the website came to me.  I experimented with a number of desktop RSS readers, then shifted to Bloglines (remember Bloglines??!!!) for a long time, before finally taking the plunge into Google Reader. It was great - I loved it.  I could tag items that I thought were interesting and worth storing and it had an excellent "Search" feature which meant that I could look through all my feeds using keywords.  This is most useful when you are blogging or writing: you can look through all your read-and-tagged articles and find the ones that most relate to the argument you are making.

There was one problem.  But to explain that, I have to talk about my long-standing obsession with information.  One of the things about reading on the Web is that you get access to lots of material that you wouldn't have before.  And you don't actually get to read most of these pieces; some of them you skim, some of them you skim, find interesting and then read deeply; some of them you don't even skim but you think these could be potentially useful at a later time.  Which means that you want to store everything that you think is useful - even remotely.  And the great thing about the internet is that storing things is inexpensive and easy, although there are infinite ways to do it.  I tried a variety of options: Google Bookmarks, Evernote, Delicious - but it never worked.  There were just too many options and working across applications was tiring and inefficient and frankly, not very useful.  Storing links and text is only useful if you re-read them and use them; and I found that I was rarely going back to what I had stored.

This started to change as I started reading more and more through Google Reader, I would tag anything I thought remotely useful (the story of what tags I came to use is something I'll tell another time). Thus I had a nice folder of items that I thought might come in handy for me later.
 
But there were other articles that I would read outside Reader (usually links that came from the blogs that I read in Reader).  And I wanted to store these too - but there was never a way to put them into Reader.  So for the longest time, I had two places where I stored interesting things I'd read: in Google Reader and in Evernote - and needless to say, it got pretty unwieldy.

And then I discovered sharing on Reader which was pretty cool.  And somewhere in the midst of this, I discovered Google's "Note in Reader" bookmarklet, which was designed so that you could share interesting things with you Reader friends even if what you were reading was not actually through Reader. 

That was the breakthrough.  But not in the way the Google designers imagined.  True, I used the bookmarklet to share more links.  But once I clicked on "Note in Reader," I had the option of not just sharing the article, but also tagging it so that it would be accessible from within Google Reader.  So there were a lot of pieces that I used the bookmarklet to just save and tag, and not necessarily to share with others.  I had my one application to store everything on the Web that I found interesting: it was Google Reader.  At some point, I stopped using Evernote.

Which is why the loss of the Sharing functions in Google Reader is depressing.  Now when I click on "Note in Reader" here is what I get:

So forget sharing, I can't even tag and web-page and move it into my Google Reader folders.  Which means I have to start my search for one storage application all over again - or content myself with two.  I'm hoping that even as Google has disabled Sharing through Reader, they will at least allow us to import web-content into Reader folders.  But we'll see.

As we learn all the time as designers, when  you take away a feature, you take away practices that users have been relying on, practices that may not have been what you intended.  It's a good lesson to learn as a user - hopefully it'll be something I'll remember when I do any kind of design work.

Interactive computing systems and the relationship between embodiment and teachability

In this post, I am going to talk about the notion of "embodiment" in human-computer interaction. In particular, I will explain how my understanding of the term has changed and how experiences with teaching my Dad how to use certain programs (Picasa, the Indian Railways online website, etc.) revealed to me another facet of the term: the relationship between the embodiment and teachability of an interactive system. If one wants to teach someone how to perform a certain task on an embodied interactive system, then written instructions (without pictures or visual aids) are almost always insufficient. In other words, one measure of the embodiment of an interactive system can be found by looking at the efficacy of written instructions in helping a novice perform a certain task.

Paul Dourish's "Where the Action is" is possibly one of my favorite books. The book's thesis is that as computers have developed, our interactions with them have changed in nature and have progressively become more "embodied." Dourish divides the history of computer systems into 4 successive time-periods based on the mode of interaction:

• Electrical: To program a computer, one had to rewire its hardware.
• Symbolic: Abstraction was introduced and separated hardware from software. Abstraction meant that coding got progressively simpler: from machine language to assembly language to high-level Fortran-like languages.
  
• Textual: This refers to the development of command-line interfaces. These, for the first time, made interacting with the computer, seem like a "conversation."
• Graphical: Finally, there was the development of the graphical user interface (GUI) with its desktop metaphor and 2-dimensional arrangement of files and icons. The 2-dimensionality of the GUI meant that users were able to exploit "further areas of human ability as part of the interactive experience." This meant the use of faculties such as peripheral attention, pattern recognition and spatial reasoning.

Dourish sees each successive stage as involving more and more of the distinctively "human" capabilities i.e. those skills that are most used in our interactions in our everyday life with other human beings. Embodied interaction, as Dourish defines it, therefore means an interaction that involves more and more of distinctively human skills. These could be bodily skills (like pointing, gesturing, moving, pattern recognition) or social skills (our workplace habits, our everyday assumptions, etc.). In other words, embodied interaction is a move towards integrating more and more of our real-world practices (at home, at work, at play and so on) in our interactions with computing systems.

There is another aspect to embodied interaction that has slowly come to my attention as I have been trying to teach my Dad to use computer software (email, Picassa, certain websites, etc.). It involves what I call its teachability.

Let me give some background. My father worked during a time when computers were not such a ubiquitous part of the everyday work environment. In particular, he worked at a time when there were special people who did computer work -- and therefore not everybody needed to use the computer. More so, the computer was used for what can be called high-tech scientific stuff; it wasn't used at all for the mundane things at work: sending emails/memos, for filling up your time-sheets, submitting vouchers for reimbursement, etc.

Consequently, my Dad never interacted with computers in any sustained way when he worked. But he was certainly aware of them. However this was back in the times when the command-line (Dourish's 3rd stage) was the primary mode of interacting with computers; MS-DOS ruled. When my Dad did start interacting with computers in a sustained way however (primarily to keep in touch with me here in the US), he was dealing with the GUI, a new and much more embodied stage of human-computer interaction.

Consequently he would ask me to write down instructions for him on how to do a certain action. I would agree but I would find the writing of instructions to be extraordinarily hard. Here's an example of what I mean. To copy a file from one directory to another in DOS is a simple command:

Now of course, even here, there are variations. You don't have to specify the directory if you want to copy something from or to the same directory you are in, etc. But the command itself is fairly simple and easy to understand.

Now consider doing the same thing in Windows and there turn out to be quite a few ways to copy a file from one folder to another (drag-and-drop, Edit menu, Context menu). I'm going to consider one of them here, to illustrate its complexity:

Go to the folder you want to copy from. Select the file and copy it (this can be done either by right-clicking the file and selecting "Copy" or by selecting the file and selecting "Copy" from the Edit menu). Then go to your target folder and paste the file there (again, this can be done in two ways, right-clicking in the target folder and selecting "Paste" or selecting "Paste" from the Edit menu).

Just the sheer complexity of what I wrote above makes it clear that in terms of giving written instructions, the command-line interface is far simpler than the GUI and involves less tacit assumptions (the phrases in red font, above).

Talking about the GUI involves an almost taken-for-granted use of metaphors. Consider, for example:

Go to the folder/Be in the folder/Be in some application: Go to a folder implies that the folder is a place. Go in a folder implies that the folder is like a house which you can go inside. I also ask him frequently to be inside some folder or to be inside some application.

Select the file: This is not really a metaphor although it comes up frequently in my discussions with my father. Many times, when I instruct him over the telephone to "select the file," he doesn't get what I mean or asks me whether I mean to left-click or right-click on the file icon. I also frequently ask him to "select the text" (e.g. to copy a hyper-link from Skype to Firefox to open a link that I sent him)

How does one teach people to use embodied interactive systems (GUIs), particularly when they have very little experience with computers, don't use the computer frequently and most important, are distant from us so we can only communicate with them through spoken and written instructions? Some points and observations:

Written instructions without pictures are almost completely useless.

Written instructions with pictures (screen-shots) can be useful.

However, it is best to give verbal instructions especially during the task itself*. That way, your instructions can be followed in real time and you will get immediate feedback about their intelligibility (i.e. whether or not they're understood) and efficacy (whether or not they worked).

Having a shared referenced visual object is even better. Meaning that if you are teaching someone how to use the Indian Railways Ticketing website, it is best to have it open in front of you and to carry out an instruction yourself so that you know exactly what the person you are instructing is looking at. This is easy to do for websites but much harder if you are instructing someone about how to use Picasa or how to copy files from a flash-drive to the hard-disk.

Which leads to the best possible and most embodied form of instructions. Screen-sharing along with a voice communication channel is the best way of all! This way, you know exactly what the other person sees and the instruction itself can be modified depending on how you see it being interpreted. E.g. if you ask someone to copy a file to a certain folder and this doesn't seem to get through, you can immediately supply them with instructions on how to copy files and take them through it step-by-step.

I guess the broader point that I am trying to build to is this: embodied interaction uses many bodily and social skills, and these are almost always tacit; it is hard to translate them into words. Verbal instructions (spoken and written) need to be backed up with visual aids like screen-shots and screen-sharing. Therefore it follows that one rough measure of the embodiment of an interactive system can be found by measuring the efficacy of written and spoken instructions, especially when the student and the teacher are distant, and the student is a novice at using computers.

*Whether your instructions will be remembered is another question.

On ontologies

The latest issue of the International Journal of Human-Computer Studies is a special issue on the role of ontologies in knowledge representation.

For a list of all publications in the issue, see here.

These are the two papers I found interesting:

Knowledge representation with ontologies: Present challenges—Future possibilities
Christopher Brewster and Kieron O’Hara

Abstract: Ontologies have become the knowledge representation medium of choice in recent years for a range of computer science specialities including the Semantic Web, Agents, and Bio-informatics. There has been a great deal of research and development in this area combined with hype and reaction. This special issue is concerned with the limitations of ontologies and how these can be addressed, together with a consideration of how we can circumvent or go beyond these constraints. The introduction places the discussion in context and presents the papers included in this issue.

Knowledge representation with ontologies: Present challenges—Future possibilities
Christopher Brewster and Kieron O’Hara

Abstract: In information systems that support knowledge-discovery applications such as scientific exploration, reliance on highly structured ontologies as data-organization aids can be limiting. With current computational aids to science work, the human knowledge that creates meaning out of analyses is often only recorded when work reaches publication—or worse, left unrecorded altogether—for lack of an ontological model for scientific concepts that can capture knowledge as it is created and used. We argue for an approach to representing scientific concepts that reflects (1) the situated processes of science work, (2) the social construction of knowledge, and (3) the emergence and evolution of understanding over time. In this model, knowledge is the result of collaboration, negotiation, and manipulation by teams of researchers. Capturing the situations in which knowledge is created and used helps these collaborators discover areas of agreement and discord, while allowing individual inquirers to maintain different perspectives on the same information. The capture of provenance information allows historical trails of reasoning to be reconstructed, allowing end users to evaluate the utility and trustworthiness of knowledge representations. We present a proof-of-concept system, called Codex, based on this situated knowledge model. Codex supports visualization of knowledge structures through concept mapping, and enables inference across those structures. The proof-of-concept is deployed in the domain of geoscience to support distributed teams of learners and researchers.