Storyboarding and Prototyping the Mobile Filer

Problem Definition

In last week's need finding post I came up with the, not particularly original, idea of a mobile filer, this week it's time to prototype that. The first thing we want is a point of view, a very high level problem definition :

I want to record or copy documents and other objects and file them so that I can easily find them.

Having a definition, we flesh things out with a couple of storyboards, at this stage we are still in the 'fail early' mindset -trying to get something that looks like it will work.

Storyboarding

I created two storyboards, showing the flow through the application.

First Storyboard

In the first storyboard the user organises his files on a computer, this gets around the challenge of the small screen size  and the poor interface of the phone.

Second storyboard

In the second version we accept the limitations of the mobile device, on a tablet these wouldn't be so bad, and do the organising there. This means that we do the job in one go.

Ideally we would be able to use stuff we already know such as the date and time, or the location or type of image, or stuff we can work out -perhaps via OCR to carry out much of the classification automatically.

Paper Prototypes

Ideal Input System

 The ideal input system above may look a bit facetious (moi?), but it serves to illustrate a point, if this system was smart enough this is how we would like the input to work.

Likely Input System

A more likely system lets the user choose between our two storyboards above, if he presses 'upload' then the image will be filed immediately, and he will probably have to sort it out later. Otherwise the user can tag the image -default tags are time stamp and location.

Finding Notes

To retrieve documents the user selects a category of note and drills into it. I have just realised that I need a way to move notes between categories, so there would be an edit screen in here too.

There is also an opportunity for a simpler output system, which I had better sketch up now.

Search Based Interface

In this version  the user gets a set of important (flagged?, latest?) notes up front and access to the rest of the documents is driven through search.


If I get a chance I'll put up a video demonstration -but life is getting in the way.

Needfinding

The task was to observe some people and derive a product by finding a need that they had.Unfortunately most of the people that I interact with regularly aren't suitable subjects -I had an idea based around homework, but understandably schools won't let you in to observe the pupils; the other idea was based around the elderly but similar problems arise and, in addition, there comes a stage where the new technology you are going to be picking up  is a Zimmer and not an iPhone.

Capturing a document, need to share it

In my interactions with these two groups I did observe some tasks that I was carrying out, so I decided to use these for my needs. Both groups get documents that need to be dealt with, say homework for one and hospital appointments for the other, this generates a lot of paper, people need copies and all the usual. I found myself taking photos of these, as did my daughter -who promptly deleted it highlighting the need for off-phone storage, with our phones. So far so good, but the filing is where it falls down.

Document upload and filing -there has to be a better way.

The document has to be got off the phone, one way or another, then filed somewhere locally or remotely and found again when you need it.

Needs and Goals

Here's a brainstorming list I came up with :

1. Quick
2. Simple
3. Easy to use
4. Documents are easy to find
5. Categories
6. Tags
7. Date/time stamps
8. Location stamps
9. Safe
10. Secure
11. On hand -don't have to find a computer to access.
12. Shareable
13. Feature extraction for filing/tagging
14. OCR for filing/tagging
15. Social coz you have to
16. Calender integration

Inspirations

Five things that might help define the solution :

The fridge wall of information

Important household information is posted in a known, obvious and prominent place.

Filing Wallet

The old school definition of organised, either alphabetically or, as this one is, 'tagged'.

Filing Clerk

Someone to get the piece of information you want. They may have their own system specifically tailored to where they work. Slobber extra.

It should be, one click is a bit of an ask but we need to get as close as possible.

Shiny, the app should look sleek and crafted -which will be a challenge for me.

Analysing an Online Community

I had a look at carrying out network analysis of the relations in an online community for the Coursera Social Network Analysis class.

Original Bulletin Board Graph

The community was a UK based bulletin board of general chat, completely anonymised. I wanted to look at the relationship between topics and see what could be inferred from that, so in the graphs the nodes are threads and the edges are people who posted between threads. This post is mainly about the network analysis, another will look at nitty gritty of how I carried it out.

Tools

In short, Python and Gephi -more details later.

The Network

I ended up with a network of 79 nodes and 345 edges. The node labels were extracted keywords from the threads -edges were people who posted between threads.

Analysis

First question is there anything to look at? Any Structure? One way to tell is by constructing a random graph and comparing it's properties with those of our graph -this can be done, a little tediously, with Gephi.

Our graph has an average degree of 8.73, a shortest path length of 2.22 and an average clustering coefficient of 0.634. In comparison a random graph with same node and edge counts has a degree of ~4.4 a path length of 2.2 and the clustering coefficeient of 0.144 degree is considerably lower than our graph, so nodes are more connected and, although the path length is similar to a random graph the clustering is higher, indicating small world properties -which gives us something to look at.

There are a 3 super nodes in the graph :

Node	Betweenness
clarkson, people, one, bbc	1015
people, like, money, would	650
clarkson, one, public, sector	343.

People in the UK can probably guess the reason for the first and third nodes. The comment was so outrageous that perhaps most people felt that they had to say something about it, and abnormal relationships in the graph could be created. After removal of the clarkson nodes the graph is as below:

Clarkson free graph

Running Gephi Modularity with a resolution of 1.0 gives us 6 groups. Groups 4, 5 and 0 seem to be too diverse to say anything much about. Group 1 is mainly about sport, although its' highest degree node is about Apple. Group 3 is about UK domestic topics, Group 2 is more global centring around politics and economics.

Summary

We can see that there is some clustering of subjects when we relate them by people although we have not discovered any surprises on this small data set, as similar subjects cluster together. Next steps for this study would be too use a more sophisticated way of extracting the labels from the thread text, run against a larger data set and perhaps introduce the notion of time as an attribute, one could then perhaps look at 'contagion' of the network by a topic, the Clarkson posts might be interesting here. We could also invert the network and relate people by posts -but that seemed less interesting.

Ubuntu Cross-Platform Mobile Setup

I had 3 candidates for a cross-plattform development framework, Cordova, Appcelerator and Corona not knowing which to choose I looked at all three.

Corona

I liked the look of this framework, but it doesn't work with Linux (although it could be possible to make Corona work with Ubuntu with a little hacking.). It's Java based (remember 'write once, run anywhere'?) so I don't know why they don't fix it, but that's one down.

Cordova

Cordova on Linux

There aren't instructions for Linux -but the Mac ones looked reasonable so I thought that I'd give it a go. I already had Android Developer Toolkit installed so I adjusted the paths accordingly, ran the create script, and it fell flat on it's arse. Not a good start. Did the obvious and fixed the permissions, still no joy. Had a look at the script and several lines ended with '&> /dev/null' -hmm. I write scripts that go '1>/dev/null 2>&1' so I assume that is what these mean. Maybe the other syntax is a Mac thing, but on my machine it ends up with processes being backgrounded that shouldn't be as the script then tries to remove files that aren't downloaded yet. I deleted the  '&> /dev/null'  and 'create' generates a project.

Fire up the ADT , based on Eclipse (oh well), open up the project as described in the instructions, Eclipse hides it from me, eventually find the right button. Attempt to deploy the script ADT dies horribly, there are a few libcurses5 errors that I have been ignoring. Turns out the Android SDK is 32 bit, wheras I have a beefy 64 bit machine, 'apt-get install lib32ncurses5 lib32stdc++6' sorts this out for me. I fire up ADT redeploy and hey presto!

Appcelerator

Titanium on Linux

They make me sign up, and then immediately want an update, some smart marketeer on the job counting the number of fields that we'll fill in at once. Having done that it's off to the Titanium Quick Start Guide.

Next we download, unzip and run Titanium Studio (again Eclipse based), so far so good, the first thing it wants to do is update itself and it runs into a problem with nodeJS. Fortunately this is documented and after following a couple of links I run :

   sudo add-apt-repository ppa:chris-lea/node.js
   sudo apt-get update
   sudo apt-get install nodejs npm

and we are off to the races.


I was able to point the SDK at the one in ADT, which saved a bit of time, although I also installed Android 2.2 as that's what my ancient phone uses, and then ran through the rest of the Quick Start with the result above. The emulator takes forever to fire up, but Eclipse looks a lot more rational than it does in Cordova.

Brainstorming and Prototyping

This week's design exercise for the HPU Mobile course was around the beginnings of the process of delivering a mobile app -getting a concept and making a prototype.  A good introduction to this is in Scott Klemmer's HCI course.

Brainstorming

The challenge was to come up  with 20 things to do on your mobile whilst waiting in line, a crack brainstorming team of myself and the trainee woman was assembled and this is what we came up with.

1.     Gambling  (bingo, roulette, fruit machine)
2.     Vouchers (did this one for real)
3.     Find someone to have a coffee with
4.     Browse Comics
5.     Listen to Jokes (Professor?)
6.     Local News & Events
7.     Watch a clip (trailer, sports, music vid)
8.     Gossip
9.     Update Shopping List
10.     Take a virtual tour.

Language learning -about item of shopping?     Play a game     Read Magazine (e.g. Hello! guess who?)     Diet program linked to your shopping     Styling app -beauty products on your photo     Test the Kids app. (for mums in the line)     Recipe for item of shopping.     Queue switcher -the other queue is always faster.     Interactive Story     This has been deleted for reasons of taste, let's say dating app.

Prototyping

The next step was to build two paper prototypes. Firstly, I chose the Queue Switcher - it's simple to explain, it's a bit like a game (come to think of it there could  be a collaborative Queue Racer version) and I haven't seen one before. Secondly, it was the Recipe maker -because when I am standing in the supermarket staring vacantly at the food shelves I could use one. It is one of the perennial problems of family life -what am I going to cook tonight?

It seems the Queue switcher does need a bit more explanation after all, it's based around the perceived wisdom that the other queue always moves faster than the one you are in. The app lets you track that and suggests when you should move queues, based on their relative speed -of course we all know that as soon as you leave your original queue it speeds up! Thinking about it now we could add in a bit of social allowing you to share the outcome and a bit of gamification -you too can be a 'Quintessential Queuer'!

Queue Switcher

Recipe App

User Feedback

Next step was to try out the prototypes on some users. I wasn't really up for buttonholing strangers in the street so I picked on the family :

Entering an ingredient

Generally they got the idea pretty well, but one thing I did learn is that it helps to screen your testers : My wife has never used even a feature phone; and the daughter doesn't really shop for food.

Recipe Dropdown

Insights Gained

1. Better window titling to flag up what each screen is for.
2. Error messaging would be needed.
3. More interior navigation -having picked a recipe all the ingredients may not be available, so the ability to go back to the recipe list or the recipe search would be useful.
4. Predictive typing would speed things up.
5. The shopping list feature could just be a list, it was felt that the ability to tick items off, or remove items was unnecessary.

Fast Track to Mobile -Part Deux

This week we run up a couple of quick mobile pages and publish them on dropbox -not without it's idiosyncrasies- and install ADT the Android Development Toolkit.

A note on pronunciation -the dog jokes should be read in the voice of our late, lamented court jester -Spike Milligan.

Sencha App on Playbook

First off Sencha, I just copied the test page, updated the text and dropped it onto dropbox. The Sencha page looks reasonable to me -but it's just a test page. Looking at the source, it's a bit less friendly than jQuery Mobile for something this simple which implies there might be a slighly steeper learning curve. Time will tell.

jQuery Mobile page on Playbook

The jQuery Mobile page  also looks good, again it was just copied from the quick start. The code looks a lot more like a normal web page with the contents driven through named div blocks -view source on the pages and you'll see what I mean.

Dropbox had issues, or rather Chrome did, with using either 3rd party sources or mixing http & https requests -these were resolved by copying the css and javascript files into the Dropbox public folder so that they could be served from there.