Thursday, 27 August 2009

Android Haiku

Our phones have arrived.
We ordered them two months back.
So what? A miracle.

Monday, 24 August 2009

Android XML parsing

CloudBank communicates with a REST server to read/write application data from/to the cloud. As our server speaks XML, we need to parse XML on the Android client. However, a quick look at the documentation reveals that Android has no less than three different XML parsers: the traditional DOM and SAX parsers plus the recently added XML Pull Parser, which promises to deliver high performance at a small memory footprint.

Great, this is exactly what we want: higher performance with less memory!

But does the promise hold up? Too lazy to set up my own performance test and confident that others have done that already, I dug up a recent article on Android XML parsing by Shane Conder. It describes a performance test for all three parsers with different data volumes, which surprisingly found the SAX parser to perform best on all three data sets.

Monday, 17 August 2009

Users, systems and their models

We're still digesting the feedback from our second user meeting, this time with our larger focus group consisting of eleven pre-sessional English students, from a range of countries including China, Japan, Thailand, Vietnam and Russia. Because of the large number of participants, this was run as a general focus group to gather opinions on the proposed system and its functions, rather than as a practical design session. And very interesting it was too.

Like the participants in the co-design session, the students were clearly used to using their mobile phones to retrieve information and were much more comfortable seeing CloudBank as a kind of hand-made dictionary for them to consult, rather than as a resource to contribute to. This led to an emphasis in the discussion on trust, authority and the quality of the information in the CloudBank repository.

This gives us some food for thought. Do we place more emphasis on the quality of the language data, maybe with trusted authors, even teachers, involved, turning the system into a resource to be consulted individually rather than contributed to? This would be risky, because it's not hard to predict that our database of words won't be as full or reliable as a plain old online dictionary, the obvious model.

Or do we follow the original concept of a self regulating collaborative community of language learners contributing what seems of use or interest to their peers, with no teacher involvement? Or some hybrid? If we stick with our original concept, it's clear we have a lot of thinking to do about the model of the system that we project to the potential users (through interface design, brand name, termininology, publicity material), to avoid misconceptions and disappointment.

Hmmmmm.

Wednesday, 5 August 2009

Co-design session 1

Time is flying! End of last week we had our first co-design session with users, and I didn't even find time to blog about it. So here's a brief summary. The meeting took place on 30th of July for 2½ hours. As one would expect for this time of year, only 3 of the 6 invited 'super-users' were available. The schedule included:
  • 15 minute questionnaire to establish participants' background and views
  • 15 minute introduction to CloudBank (included below)
  • 5 minute questions & answers
  • 15 minute viewing a very English film (A Private Function)
  • 50 minute discussion: what was difficult to understand, why, similar situations in other contexts, measures to improve, etc.
  • 50 minute co-design: feedback and ideas based on initial interaction designs
The whole meeting was video-taped (with participants' consent) and two researchers took notes during the session.

And what did we learn? A lot! The session brought up many aspects we did not think of before. It helped to further develop our initial interaction designs and in the process led to a more rounded, complete service: Whereas we initially thought of the CloudBank Android client as an application to collect, annotate and tag language related content, with distribution handled through RSS feeds and mobile alerts, our users placed equal emphasis on querying and editing the data on their handsets. Yippee, this makes it a much more useful service! Ouch, we just added several layers of complexity!

Many other ideas were thrown in, ranging from the extremely useful and powerful, like filtering based on social networking concepts, to the more adventurous, like voice recognition and synthesis. Sadly though we only can note them down at this point as the project must end in November. However, the most promising ideas might well inform a follow-up project :-)