Rethinking Menus
One of the topics in software usability is about how to structure and label menus. I have been reading a few human-computer interaction (HCI) papers and books over the last couple of weeks, and I started thinking about how menus could be integrated in the whole user-participation web 2.0 thingy.
What about users being able to relabel and restructure menus and menu items? And allowing users to create their own menu items for certain functionalities which require a combination of different operations (like a macro)? This could help users when they are learning to use a new software, and infrequent users when they are coming back. In addition to that, we could have a ‘social network’ for menus where users can import other people’s menu items, labels, shortcuts, and functionalities, and can learn how other people are using the software.
No idea if anyone has done this before. Just had the idea, and thought it would be a cool feature.
Barriers to Entry and FOSS
Next term, I will be a teaching assistant for the imperative programming course at my university. This second-year course will require students to learn C programming on (Lin|U)nix, and one of their first tasks will be to set up an appropriate programming environment. On the course website, I therefore added a link to VirtualBox Linux images which the students can download. I assumed that they will be able to figure out themselves which Linux to chose and what software they need to install in order to solve the course exercises.
A bit of background: A couple of years ago, I was in China and Thailand doing research for my master thesis in Asian studies on Asian participation in Free and Open Source Software (FOSS). And one of my conclusions, amongst others, to the question why Chinese and Thais have difficulties participating in FOSS was the barriers to entry.
While preparing the imperative programming course, I suddenly realised that I was increasing the barriers to entry for my students. Since I had to learn how to set up a Linux system by myself, I just assumed that the students would have to learn it the hard way too. Additionally, when I first started to use Linux, I only had a dial-up internet connection, and finding information was much harder than today.
I started out by thinking what the students would need to do: Searching the internet to compare different Linux distributions, downloading the image, setting up VirtualBox, importing the image, setting the proper parameters for the virtual machine, running the virtual machine, searching the website where they downloaded the image for the user credentials, logging in. And then? Choosing an editor or IDE, finding out how to use the packaging system to install it, setting up sudo, opening a terminal and trying to run ‘gcc’, just to find out that it’s not installed yet, and so on. Students who have no experience with any of that are likely to spend a few days, only to figure things out, and before they get to the actual course exercises.
Conclusion is: I decided to prepare a virtual machine for the students, all set up with editor and the programming tools they will need throughout the course. It’s not the primary goal of the course to get them to set up an environment, the course is about learning to program in C and about how Linux works with threads, processes, and stuff.
Now how is this related to FOSS? Well, anyone who tries to get involved with FOSS, has to do a huge amount of effort just to get the trunk version of the software up and running. I recently started working on multiple mouse pointer support in webkit. I got, like everyone who tries to compile software, lost in the land of dependencies, configurations, compile errors , inadequate documentation, and unhelpful mailing lists and irc channels. Additionally, I was recently asked to deploy a version of my adapted webkit browser for Ubuntu. And what I experienced was even worse than on my Linux distro. Most of the required versions of the dependencies weren’t available in the Ubuntu packaging system (yes, I also checked the testing repositories) and I ended up compiling many of the dependencies myself. I am quite experienced when it comes to compiling things, but despite everything (add a couple of version conflicts, and some weird compile errors), it took me two full days to get my browser running on Ubuntu.
The barriers to entry for most FOSS projects is extremely high. Getting the code up and running is definitely far from easy. Recently, FOSS is trying to get more and more people, and non-coders, involved for testing, usability, bug triaging, design, and other community tasks. However, how will these non-coder people be able to run the required version of the software which is still a development version and therefore needs to be compiled? IMHO, the FOSS communities have to start thinking about lowering the barriers.
I wrote a blog post about a similar topic a few years ago. It’s available here.
Paul Dourish on Postcolonial Computing
Paul Dourish was recently speaking at Xerox Parc about postcolonial computing (you can watch the talk here and read the paper here). The talk is part of the Ethnography in Industry series.
It’s an excellent presentation that shows new ways of how culture can be tackled by technology and how technology itself plays an important role in culture. He provides many examples as illustration which makes the talk really worth watching even if you have read the paper.
Intelligibility of Pervasive Applications
In pervasive computing, one of the major concerns is which data an application uses as input and what it produces as output. Additionally, pervasive applications seem unpredictable to users as it is sometimes not clear why an application does something and what kind of input has invoked that action. Very often context-aware applications fail to adequately predict user intent, since the real context is much more complex than the context which is used for computation. Anind Dey has published a paper about “Modelling and intelligibility in ambient environments“. In the paper, he shows how implicit input in context-aware environments make it more difficult for users to create a mental model of an application.
In a previous post, I discussed how a user can become an application developer with the appropriate tools. I think a similar method could be used to visualise application-internal data. The ‘About’ section of an application could show which sensors are active, what data is being transferred between software modules, and even give the user the possibility to turn certain sensors on and off, or to choose what data is being transferred. Some of the data could also be set manually by the user if they wish to do so.
A simple mock-up of such a visualisation and configuration interface could look like this:
This could be an application which gathers some sensor data, combines them with information from a user’s google and facebook profile, then does some operation on this data and displays in on a UI with additional synchronisation with facebook and google. The idea is that a user could click on the sensors to turn them on or off, click on the connections to see what data is being transferred, and click on the modules to get a more detailed view of what operations are being done.
This would give the user the possibility to understand application internals without reading the source code. It would also allow for configurable settings at all levels of the application. Plus, if the user is not happy with the produced input/output, they could have the option to set them manually.
I believe such an “About” page could help users create a more appropriate mental model of an application, and gives them the possibility to actually understand what is happening on the inside of the application.
Thumb Hieroglyphs
I loved this post. It’s about a curtain of emoticons and how it looks very much like hieroglyphs:
“What will archaeologists think when they dig one of these up in 5,000 years? [...] [wonder if they'll] puzzle out that these are facial expressions, and conclude that all humans of our era had our heads tilted at 90 degrees to the left.”
Adam Greenfield about “Every User a Developer”
Adam Greenfield wrote two very insightful blog posts (and another interesting one) about how every user could be a developer (you can find them here and here). The stumbling block is the recent announcement of the Google App Inventor which allows non-developers to create applications for Android. To be honest, I wasn’t that excited about the Google announcement. I put it off as one of these graphical programming environments that are too scary for non-programmers. And, seriously, if you look at Google’s other user interfaces, I don’t think we can expect any miracles.
Anyway, Adam Greenfield’s blog posts are really cool because he shows how creating applications for non-developers contributes to “demystification and user empowerment”. I like how he uses Lego bricks as comparison. Imagine what it means if software was modifiable (and re-distributable) by everyone, and not just by software developers. And, with modification, I don’t speak about user interfaces, but about “deep” functionality and structure. It would mean that the four freedoms of FOSS would apply to much more people than only geeks. Potentially everyone who has access to a computing device could create, modify, and distribute their own software. It’s taking the concept of the read-write web to whole different level where people can create exactly the software they want by themselves.
Greenfield even goes a step further than that:
“One, two, many Facebooks. Or Photoshops. Or Tripits or SketchUps or Spotifys. All interoperable, all built on a framework of common tools, all producing objects in turn that could be taken up and used by any other process in the weave.”
Unfortunately, for this vision, we need to develop and respect standards or come up with a whole new concept for interoperability.
On Ontologies and Meaning
Ontologies have received quite a lot of attention in the context of the Semantic Web, Context-Aware Computing, and a few other computing-related areas. Ontologies, in a computing perspective, promise to make the meaning of things machine readable. They are based on the assumption that entities have a concept and a set of relations with other entities which can be categorised and structured for use in software engineering. As Paul Dourish puts it:
“When I encounter a glass of wine, even though I have never seen this particular one before, I can still recognise it as being a glass of wine because of the way in which it fits into my model as an instance of the abstract class of glasses, and other drinking vessels.” [p. 21]
However, when you see the glass of wine, the way you see it and the way you relate to it is unique to you. You might have pleasant memories associated to it, or you might have experienced how an alcoholic relates to it and associate it with something bad. The wine glass itself could trigger good or bad mood, or more complex feelings and memories. You have learnt the meaning for “wine glass” through your experience with the real world, your ontology for it might be completely different from mine. Individual ontologies are “embodied” as Paul Dourish would say, they are part of the Dasein in Martin Heidegger‘s terms.
Of course, the fact that ontologies are individual doesn’t mean that we can’t build “objective” ontologies to represent a certain set of entities. These “objective” ontologies are in a certain sense a shortcut since our computer systems cannot spend years learning and deriving ontologies from experience. If we want to build truly context-aware systems, we should however consider that ontologies in humans are composed of individual experience, relations, and history.
ALG: An example
I have experienced an impressive example myself of how real world interaction and context can enable someone to learn the meaning of words and sentences in the real world. When I was in Bangkok, I studied Thai at AUA with a method called Automatic Language Growth, or ALG. As a student at AUA, all you need to do is to sit in class and open your senses (or should I say sensors?) to what happens in front of you. There is no homework and no book, it is all about real experience and context.
In class, two teachers are talking to each other in Thai while you watch, listen, and learn. The teachers use common situations such as shopping, eating, or prostitution (very common in Thailand ). They use Thai words in a context associated with specific actions, drawings, or any other way which allows students to understand without using an English translation. With that method, people learn Thai through “embodied” experience and interaction rather than in the traditional, more abstract way of translation.
The interesting thing about ALG is that people who have followed the whole program are able to speak Thai fluently and almost without accent. What happens is that you learn to associate sound with meaning, experience, and a real world context. Students therefore learn to use the language naturally, almost like a child learns speaking.
You can find an example of how Thai is taught at AUA here.
Note: The word ontology is used here in a very informal way.
5 Reasons for Using Digital Artifacts
I have recently started looking into ways of how physical artifacts can be used, represented, and incorporated in the digital world. At some point I started wondering, why we actually would want to use digital representations at all if we have a physical equivalent, so I started making a list. Digital artifacts are:
- Modifiable: Writing a document on your computer allows you to edit and modify it. Have you ever tried this with a handwritten paper? Same holds for software. If you have the source code, you can modify and adapt it to your needs. I have written about that in the context of FOSS a while ago.
- Findable: A piece of digital information can be found with search and filter mechanisms.
- Reusable: You can reuse the content of a digital entity in a different context, for instance by using copy-paste.
- Shareable: You can share digital entities with as many people as you want at the cost of a click or a drag and drop (unless it’s proprietary and copyrighted of course). Sharing physical entities is usually harder and depends a lot on the nature of the entity. If it’s paper you can use a copier and send it to people by mail.
- Reproducible: It’s usually fairly easy to create a clone of a digital entity.
Above list is rather document-centred. And I am sure I could have listed many more reasons, but these were the ones that came to mind. I still will have to think about what implications physical artifacts have for the interaction with the digital.
Synchronising my N900 with Google Calendar
I have been trying to synchronise my shiny N900 with Google calendar for I while, but it always failed. Today I decided to to give it another try and googled the issue. I finally found the solution here. The thread has been getting very messy over time, so here is what you need to do:
Go to your phone calendar and delete all events in the default ‘N900′ calendar, then open the mail for exchange application (Settings/Connectivity/Mail for Exchange), and enter the information as described on the google support page (set port 443 and choose secure connection). Alternatively you can also create a new calendar just for synchronising with the newest version of Maemo’s Mail for Exchange application.
Now sync your calendar and let the MfE magic do its work.
Using Dropbox without GUI
I have always wondered if this has already been done by someone, but I have been too lazy to figure it out. I use the awesome window manager and don’t like to start nautilus just for dropbox. Today I found the answer in my feed reader. And it worked nicely for me. You can find it here.
