OpenAustralia Foundation

Application structure to progress to paper prototyping (by Nathanael Boehm)

SCREENS

1. Splash/category selection

Four icons with labels representing four main categories of issue to inform user of purpose of site through types of issues that can be accepted, funnel issues through submission. Decided as compromise between free text and fixed selection (such as FMS).

2. What

Title/short desc field plus photo selection placeholder. Clicking on placeholder brings up iPhone OS Select Image or Take Photo interaction. Once selected will load into placeholder.

3. Where

Loads map. If photo geocoded default to that. Show address as text. Give option to override but assume likely correct. If no geocode available then default to GPS but make easy to change. If no GPS or geocode then no specific default, expand location entry form.

4. Your details

Name, phone, email. All optional - with note that if details not provided issue may not be actioned.

5. Confirmation

Show category, photo, optional description field, location/map, your details and Report button

6. Thanks!

Expected that first release will simply save submission for manual processing. This will ensure that a) all of Australian can be covered rather than Canada version which is limited to 5 cities, and will get an interim app out there ahead of the work required to put together a location/council (& contact details) mapping database.

First version of prototype in Balsamiq prepared at hackfest.

Would be great to also have an Android version. I notice that fixmystreet also have an android version now

https://secure.mysociety.org/admin/lists/pipermail/developers-public/2009-May/004812.html

Happy to try and have a go at an Aussie version if people think it has merit. We also have some iphone experience - but are mostly Java guys so Android fits better with us.

Just for reference, the Fix My Street list of options (that we're trying to condense into half a dozen broad groupings):

Abandoned vehicles
Bollards
Bridges
Bus stops
Car parking
Dog fouling
Flyposting
Flytipping
Graffiti
Gullies
Manholes
Parks/landscapes
Pavements/footpaths
Potholes
Public toilets
Road traffic signs
Roads/highways
Rubbish (refuse and recycling)
Street cleaning
Street furniture
Street lighting
Street nameplates
Traffic lights
Trees
Trenches
Utility cabinets
Zebra crossing
Other

The survey we're using to inform the classification and iconography is at:

https://explore.wufoo.com/entries/fixmystreet-australia-iconography/

Just for info, the other classification schemes that were considered were:

Cause or effect of issue:

Damage/broken
Decay
Obstruction
Intentional damage or Criminal damage

...

Action required to resolve:

Clean
Remove
Fix
Upgrade

It was considered too hard to try to map these concepts to controls and mental models and were abandoned, pending outcome of the evaluation of the current scheme.

Is this going to just be an iPhone app, or will there be a web app component as well?

It could be a good idea to code the web app in RoR as there is already an established Objective-C library for connecting RoR apps to iPhone apps.

There will be a web component, but we're starting off with the iPhone app because the UI is simpler and will form the basis of the full-blown web app.

Report on testing of first cut of classification/iconography.

The "correct" icon is the one that the survey designer (me) expected participants to select.

There were 31 participants.

**************************************************************************************

93% participants selected the correct icon to report: a broken street light.
74% participants selected the correct icon to report: graffiti on the side of a bridge.
67% participants selected the correct icon to report: a dangerous crack in a pavement/sidewalk.
74% participants selected the correct icon to report: fallen tree branch that was obstructing a pavement/sidewalk.
96% participants selected the correct icon to report: an abandoned car.
51% participants selected the correct icon to report: dumped garbage.

**************************************************************************************

The qualitative feedback received included the following (paraphrased):

****

Regarding the broken street light:

• using a residential-style streetlight instead of curved "major road" style.
• a broken streetlight
• the lines coming from the streetlight indicate a functioning light

****

Regarding the graffiti on the side of a bridge:

• something that looks more like a bridge
• graffiti is unclear
• kid holding spraycan
• looks like a spider

****

Regarding the dangerous crack in a pavement/sidewalk

• someone falling over (suggested three times)
• bike indicates refers to transport
• road/pavement looks in good condition - should be cracked
• show curb/gutter
• something depicting danger

****

Regarding the fallen tree branch that was obstructing a pavement/sidewalk

• might have selected the road/pavement icon - hard to choose between source and thing affected
• tree doesn't appear broken (suggested three times)
• something showing obstruction would work better

****

Regarding the abandoned car

(no qualitative feedback)

****

Regarding dumped garbage

• pile of rubbish (could not be discerned from icon)
• broken furniture
• overflowing garbage bins
• tyres/mattresses
• cans, bins on ground (suggested five times)

****

The following comments were also submitted by users:

• they would select the tree icon for park problems and the pavement/road icon for overgrown paths.
• broken pavement and dumped rubbish were hardest to associate with icons (mentioned twice)

Some positive feedback on the general approach was received although one participant mentioned that the icons sucked, it was terrible, crap, silly and recommended using words instead.

Analysis to follow in separate comment. Survey has now been taken offline ... although I'm trying to find out if I can keep it published for reference but inactive.

Analysis of report on testing of first cut of classification/iconography.

The testing showed that the proposed use of a half-dozen icons to represent broad high-level groupings (instead of Fix My Street's approach of using a drop-down list with 28 items) is viable and provided valuable information about how to adjust the approach to map the icons to users' mental models and incorporate some of the other classification schemes such as cause, effect etc into the realistic depiction ... so for example instead of going with just a tree (for the selected scheme) or attempting to embody the concept of an obstruction, combining the two without creating an icon that is only relevant to obstructions caused by trees ... which would only lead to having a menu of ~28 icons.

Based on the feedback and analysis of this survey we'll go away and work on the scheme some more.

Title of ticket changed to be more specific, limiting scope of ticket to design and prototyping phase.

it might not be a bad idea for people to identify where the problem is before describing the problem - that way you can show them a list of already reported problems and they can simply "I'd like this fixed too" rather than creating duplicates.

Well, it will be good with the new Maps APIs in iPhone 3.0, being able to integrate a map into the interface. Maybe the first step in reporting a problem could ask the user "Where's the problem?" with an embedded map centered on the current GPS location, and then the next step could be "Is it one of these problems?" if there are other problems reported in the area.

Duplicates? I don't think that the size of an iPhone screen is enough to display a long enough list to try and capture duplicate reports ... but it's something we can do for the full website version for sure.