My colleague Niels, for example, used this approach to study how people interact with touch screens of mobile phones. But, instead of collecting touch events in a boring, repetitive task he developed a game where users have to burst bubbles by touching them. And instead of conducting this study in the sterile environment of a lab he published the game on the Android Market for free, so it was installed and used by hundreds of thousands of users. So, while these users were enjoying the game they generated millions of touch events. And unlike traditional lab studies, this data was collected from all over the world and many different contexts of use. The results of this study were reported at MobileHCI ’11 and were received enthusiastically.

Since my work is on pedestrian navigation systems & conveying navigation instructions on vibration feedback, lab studies are oftentimes not sufficient. Instead we have to go out and conduct our experiments in the field, e.g. by having people navigate through a busy city center.

So, if we can bring lab studies “into the wild” can we do the same with field experiments?

My colleague Benjamin and I started addressing this question in 2010. We developed a consumer-grade pedestrian navigation application called PocketNavigator and released on the Android Market for free. Then, we developed algorithms that allow us to infer specific usage patterns we were interested in. For example, these algorithms allow us to infer whether users follow the given navigation instructions or not. We also developed a system that allows the PocketNavigator to collect these usage patterns along with relevant context parameters and send these to one of our servers. On a side-note, the collected data does not contain personally identifiable information, so it does not allow us to identify, locate, or contact users.

With this setup we conducted a quasi-experiment. Since my research is about the effect of vibration feedback on navigation performance and the user’s level of distraction, we compared the usage patterns of situations where the vibration feedback was turned on versus turned off. Our results show that the vibration feedback was used in 29.9 % of the trips with no effect on the navigation performance. However, we found evidence that users interacted less with the touch screen, looked less often at the display, and turned off the screen more often. Hence, we believe that users were less distracted.

The full report of this work has been accepted to the prestigious ACM SIGCHI Conference on Human Factors in Computing Systems (CHI ’12) and will be presented in May 2012 in Austin, Texas.

• The Tacticycle is a bicycle navigation system for tourists, which uses vibrating handle bars to provide directions.
• The PocketNavigator is an OSM-based pedestrian navigation systems that uses vibration patterns to tell the user which direction to go.
• The Virtual Observer is a research tool that allows collecting usage data (GPS tracks, Images, Experience Sampling Questions) and play them back in order to study in-situ usage of above (and other) applications.

The work presented here is part of the EU-funded HaptiMap research project (FP7-ICT-224675) , which aims at making maps and location-based services more accessible. The PocketNavigator is one of the project’s outcome developed at the Intelligent User Interfaces Group of the OFFIS Institute for Information Technology, Oldenburg, Germany.

The PocketNavigator is available for free on the Android Market: https://market.android.com/details?id=org.haptimap.offis.pocketnavigator

The instant communication enabled by those social networks has however created a form of peer-group pressure to constantly check for updates. For example, has an informal get-together been announced or has somebody requested to become your friend? This emerging pressure can make people return to the computer more often than they want. This is why we find our colleagues regularly looking for new status updates in meetings, or on our parties we see it more often that our friends cannot resist to check their Facebook account.

One solution to this is notifying users when something important happened. Mobile phones as personal, ubiquitous, and always connected devices lend themselves as platform, as they are carried with the user most of the time. This, it is no surprise that our phone now not only notify about incoming short messages, but do the same for Twitter @mentions, Facebook message, or friend requests. However, these notifications may go unnoticed, too. Thus, instead of checking our Facebook & Twitter account, we keep looking at our mobile phone for notification items.

With AmbiTweet, we investigate conveying social network statuses by ambient displays. We use a live wallpaper showing a beautiful blue water.The wallpaper can be connected with a Twitter account and visualizes the level of activity in an ambient way. The higher the level of activity on this Twitter account, the brighter and the more busy the water becomes. This can be perceived even in the periphery of the field of vision. Thus, users can become aware of important activity without the need to focus the eyes on the phone.

Ambient displays, in general, have the advantage that they convey information in a continuous but unobtrusive way. They exploit the fact that the brain can process information pre-attentive, i.e. without generating apparent cognitive load. AmbiTweet therefore allows concentrating on a primary task while remaining aware of the level of activity on a social network account.

As Human Computer Interaction as a research field is receiving more and more recognition in Germany my collages and me, as members of the Intelligent User Interfaces Group at OFFIS, are more often approached when it comes to developing novel user interfaces or findings innovative solutions for industry partners.

Usually, the idea is that we conduct interviews with (potential) end users and ask them what they want to come up with a innovate ideas. While this may work in some occuasions, I believe that this naïve approach misses a few important points. I will try to elaborate my view in the following:

Most people cannot think outside the box

With his famous quote “If I’d asked customers what they wanted, they would have said “a faster horse”. Henry Ford wanted to say that customers cannot clearly express their needs. What people actually want is getting fast and cheap from A to B with little maintenance and overhead. Most people are not able to imagine a car, if all they know are horse and carriage.

Instead try understanding their problems

Roger L. Cauvin points out that instead of asking users want they want it is more important focus on their problems by asking the right questions and interpreting answers carefully. Sometimes, he argues, it may even be better to ask no question at all but just observe and listen to your users.

Go into detail and then envision perfect solution

Frankie Johnson suggests to do that by going into detail and ask what people dislike about current practices (e.g. horses are time consuming, smelly, and may at times act unpredictably). He believes that talking about people’s dislike and then asking how a perfect carriage looks like would have resulted into the answer “a carriage without horse”.

Serendipity & Being Prepared

In addition, I believe that serendipity – the faculty of making fortunate discoveries by accident – plays another important role. A famous example is the serendipitous discovery of Penicillin by Sir Alexander Fleming, who, returning from holiday, found bacteria cultures having been killed by dishes Penicillium contamination. However, “by accident” may be misleading. Most people without the scientific background of Alexander Fleming would not have recognized the importance of that observation. Thus, I believe, that it is important to “go pregnant” with an problem and keep your eyes open for things that might fit that problem.

Get out there!

Helen Walters gives a few tips on increasing the chance of serendipitous findings, including to get outside the office, build prototypes instead of talking about the idea, and explore instead of execute. Further, it is important to not expect results too soon, which is really a tragic insight given that most work today is driven by deadlines and milestones.

I presented the results from a user study of our Tactile Compass. The basic idea of the tactile compass is that vibration patterns tell you, in which direction to go, so you can use it as a navigation system but never have to look at the mobile device.

In this study, we asked 21 participants to follow three routes through the city centre of Oldenburg. In random order they were equipped with the Tactile Compass, a common visual navigation system, or both. In brief, we found that

• with the visual system the participants walked fastest, which is a sign that the users had to think least
• with the tactile system the participants were least distraction and paid most attention to the environment
• with the combination of both systems the participants made least navigation errors.

For the details and our conclusions please refer to the full paper.

In this post you will find a light-weight Android Java library, consisting of four classes only, that allows you to create complex 3D sound scenes. An additional Hello World example building upon this library will show how to create a scene with three different sound sources.

OpenAL4Android Library

Download the library from http://pielot.org/wp-content/uploads/2011/11/OpenAL4Android.zip. The library contains the following classes:

• OpenAlBridge: this class contains all the native methods used to communicate with the OpenAL native implementation
• SoundEnv: this class allows to manage the sound scene. It for example allows registering new sounds and moving around the virtual listener
• Buffer: a buffer is one sound file loaded into the RAM of the device. A buffer itself cannot be played.
• Source: a source turns a buffer into an actually sounding object. The source allows changing the parameters of the sound, such as its position in 3D space, the playback volume, or the pitch. Each source as one buffer, but one buffer can be used by different sources.

If you turn it into an Android library, you can use it in several projects at the same time. Go to Properties -> Android and make sure that the check box “Is Library” is checked.

The following Hello World example shows how to use the library.

HelloOpenAL4Android

HelloOpenAL4Android is a demo application illustrating how to use OpenAL4Android. The complete code + Eclipse project files can be downloaded here.

Create a new Android project. Use Android 1.6 at least. Visit the project properties and add OpenAL4Android as library project (project -> android -> library). The the following code shows how to create a complex 3D scene.

To run without errors, the program requires two sound files named “lake.wav” and “park.wav” in the project’s assets folder. If the folder does not exist, just create it on the top level of the project, next to src, res, … .

package org.pielot.helloopenal;

import org.pielot.openal.Buffer;
import org.pielot.openal.SoundEnv;
import org.pielot.openal.Source;

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;

/**
 * This tutorial shows how to use the OpenAL4Android library. It creates a small
 * scene with two lakes (water) and one park (bird chanting).
 * @author Martin Pielot
 */
public class HelloOpenAL4AndroidActivity extends Activity {

    private final static String    TAG    = "HelloOpenAL4Android";

    private SoundEnv            env;

    private Source                lake1;
    private Source                lake2;
    private Source                park1;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.i(TAG, "onCreate()");

        this.setContentView(R.layout.main);

        try {
            /* First we obtain the instance of the sound environment. */
            this.env = SoundEnv.getInstance(this);

            /*
             * Now we load the sounds into the memory that we want to play
             * later. Each sound has to be buffered once only. To add new sound
             * copy them into the assets folder of the Android project.
             * Currently only mono .wav files are supported.
             */
            Buffer lake = env.addBuffer("lake");
            Buffer park = env.addBuffer("park");

            /*
             * To actually play a sound and place it somewhere in the sound
             * environment, we have to create sources. Each source has its own
             * parameters, such as 3D position or pitch. Several sources can
             * share a single buffer.
             */
            this.lake1 = env.addSource(lake);
            this.lake2 = env.addSource(lake);
            this.park1 = env.addSource(park);

            // Now we spread the sounds throughout the sound room.
            this.lake1.setPosition(0, 0, -10);
            this.lake2.setPosition(-6, 0, 4);
            this.park1.setPosition(6, 0, -12);

            // and change the pitch of the second lake.
            this.lake2.setPitch(1.1f);

            /*
             * These sounds are perceived from the perspective of a virtual
             * listener. Initially the position of this listener is 0,0,0. The
             * position and the orientation of the virtual listener can be
             * adjusted via the SoundEnv class.
             */
            this.env.setListenerOrientation(20);
        } catch (Exception e) {
            Log.e(TAG, "could not initialise OpenAL4Android", e);
        }
    }

    @Override
    public void onResume() {
        super.onResume();
        Log.i(TAG, "onResume()");

        /*
         * Start playing all sources. 'true' as parameter specifies that the
         * sounds shall be played as a loop.
         */
        this.lake1.play(true);
        this.lake2.play(true);
        this.park1.play(true);
    }

    @Override
    public void onPause() {
        super.onPause();
        Log.i(TAG, "onPause()");

        // Stop all sounds
        this.lake1.stop();
        this.lake2.stop();
        this.park1.stop();

    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        Log.i(TAG, "onDestroy()");

        // Be nice with the system and release all resources
        this.env.stopAllSources();
        this.env.release();
    }

    @Override
    public void onLowMemory() {
        this.env.onLowMemory();
    }
}

It is not only possible but also dead easy:

http://www.youtube.com/watch?v=GxZuq57_bYM#t=1m26s

The example above features the famous Amen Break, a 6-second drum break of the song Amen Brother by The Winstons. This break can be found in many old school hip-hop and drum ‘n’ bass songs.

So, how does it work?

The added parameter #t=1m26s defines the starting point. #t=… identifies the start time parameter. 1m26s means that the song starts at 1:26. It is, however, also possible to just provide seconds, e.g. #t=86s.

Why is that useful?

Whenever you want to cite parts of a video as e.g. an example or as proof of an argument, jumping to the right start time makes it unnecessary for the reader to search for it.

The day before, a cyclist had stolen a mobile phone right out of the hand of another conference attendee. Knowing that made me quite afraid something similar could happen to me too. Without the phone I would have been completely lost.

Here, serendipity hit. Since my research group was already working on tactile displays for navigation and orientation, I wondered whether it was possible to create a navigation system for mobile phones that guided by vibration only, so it could be left in the pocket.

Back at OFFIS we quickly tested a few prototypes, including a hot/cold metaphor and a compass metaphor. The compass metaphor prevailed. The design was to encode the direction the user should be heading (forward, left, right, backwards) in different vibration patterns. Our testing participants liked that design most. Later we tested the vibration compass design a forest and found that it can replace navigation with a map.

The development and the studies was presented at the 13^th IFIP TCI3 Conference in Human-Computer Interaction (INTERACT) in Lisbon, Portugal in September 2011. The article is available here.

If you own an Android phone you can try this vibration compass by downloading our PocketNavigator navigation application for free from the Android market.

On Google+ the publisher chooses who receives the status update by selecting the circles to share the update with. The crux is that you can add anyone to your circles without consent. And if you add a person to a circle you can immediately send her status updates. These updates will then appear in her Incoming Stream (https://plus.google.com/stream/incoming) with the note:

“these posts were shared with you by people who aren’t in your circles”

This means, anyone can send status messages to your Incoming Stream without your consent. Doesn’t this sound like spammers will love this? Yes, you can block further updates and report abuse, but only after you received at least one update from an account.

Background

In previous studies we found that tourists actually do not desire strict navigation support. Often, they only start with a rough idea where to go. They plan their route on-the-fly based on their surroundings and their intuition. With the Tacticycle we built a navigation system for bikes that aims at accommodating these usage patterns.

Tacticycle

The Tacticycle can roughly be described as a point of interest (POI) radar. Instead of streets and buildings the user gets a quick overview of the direction and distance of nearby POIs. As a special feature users can select one of these POIs. The Tacticycle then cues the direction of this POI by two vibration motors fixed to the handle bar. Instead of seeing its location on the screen the riders can feel where the POI is, which allows them to keep their eyes on the road.