• we need to look at the use of colour on the welcome page
• we need to change the languages/flags at the bottom of the welcome page

Jeff will action these, and we are due to meet up in the new year to make sure that we have completed all the elements for this module for final delivery on 15 January.

• Jeff to continue with programming the interface, including researching sound for screen solutions. This involves looking into two types of sound, one to recognise touch-screen button function (positive), and one to recognise failed action (negative). In addition, Jeff will also research into why certain sounds are agreeable/disagreeable to the human ear.
• Jamie to continue blogging the account of our development (see below), create flow charts of the “service string” or more specifically the process maps of the customer pathway. Also to prepare Keynote/Powerpoint presentation for Thursday 17th December.

Just to reiterate, the main take-out from our initial presentation was that we had to focus on simplicity. As such we removed such functions as the interactive map with local services, scrapped the ‘Oyster’ card system in favour of using debit/PIN technology, built in a facility to incorporate different languages, focussed on the user benefits of speed and efficiency.

• research into user reaction to speech recognition/voice prompts – some users may be hearing/speech impaired, or may not understand the language
• visual triumphs over voice recognition in its adaptability to different languages
• Jeff brought up the issue of pattern matching and the need to match car registration numbers with those stored on the DVLA database. There are currently many services advertised on TV that will give you details about a car – history, price, etc – if you text the registration to a certain number. So the information is available at a price.

Also, we found a parking meter which is credit card ready, and can be accessed in different languages, so we feel safe that our idea is valid, and not just a hypothetical exercise:

But someone has already thought to use different languages in their interface, so we feel our thoughts on this aspect were validated as well!

SmartPark was set up by Jamie Buckley, a journalist, and Jeff Townsend, a software programmer at IBM.

We were tasked in October with coming up with a type for screen solution to a problem of our own making. We chose to address the problem of cashless parking at parking meters, aiming to make it possible to park easier and avoid the inconvenience of getting parking tickets. Our initial presentation on 29 October lead us to some interesting conclusions, which we are in the process of implementing.

Background:

Our initial presentation proved fertile ground for discussion among the group. We had a system whereby you would approach the meter with an Oyster card equivalent and key in a PIN number; the meter could be used to top-up credits, give information on parking restrictions, etc. In addition, it featured a local map which gave information on shops and amenities in the area. The group also raised questions over the users’ willingness to migrate to the new system, and raise the spectre of vandalism.

The feedback led us to believe that we had created some complications in our approach to the design problem. Why not simplify it, was the basic message. Why not focus in on user benefits, and decide who exactly it is you are designing for.

To this end, we would redesign the interface to be operated by a debit/credit card, and the users’ existing PIN would be used to activate payment. By cutting out the Oyster-style approach, we would avoid the problem of having to register over the phone/online. No top-up facility would be needed. And we also dispensed with the local map, as this introduces a whole new raft of complications, and would have required updating and all sorts of data-feeding. The take-out from the presentation was that we had to focus on specific problems/solutions, and not over-complicate the meter.

Goal:

“We aim to make parking simpler and more flexible in built-up areas through the use of cashless parking meters.”

Constraints:

Some users will prefer to use cash, as they inherently avoid change to habits. The installation of meters might be delayed until present meters reach their end of use. New meters will require connectivity and might therefore be dependent on WiMax.

Target participants/viewers:

We would want anyone who parks regularly in built-up areas which are patrolled by traffic wardens to be aware of our proposal to install new meters. Car users who are shopping in hot areas for which they do not have a permit.

Design:

We will design the screen interface using Flash. The screen will present a series of buttons that will take you through the process from start to finish.

First-time users will receive different instructions to returning customers.

Card reader and connectivity are essential.

Also Jamie is researching the technology used for LCD screens which make them adaptable to different ambient light conditions.

Next steps:

Jeff is designing the interface using Adobe Flash which will be ready to present as a prototype in the new year. Jamie will be following up his enquiries with Wandsworth to see how information can be seamlessly passed from individual meters to traffic wardens via their handheld devices.

SmartPark was set up by Jeff Townsend and Jamie Buckley in September 2009.

Jeff and I thought we’d get things started by explaining a little of the background behind SmartPark, in order to establish a context for all our hard work and to try and explain its reason for being.

As part of the Experience Design I module for our MA in Digital Practice at Kingston University, we were given the following challenge for the group assignment to be undertaken and completed between end of Septmeber 2009 and 15 Jan 2010:

“Develop your group identity; identify an existing design problem; discuss and make notes of our design solution”. Further to this, we were urged to “apply primary research and user experience analyses to your own prototypes” and “critically explore what constitutes ‘good’ and ‘bad’ design”.

So at the end of September, Jeff and I got together and came up with a problem that we thought we could get our teeth into, both bringing our different skills and experience to the task. My background is in journalism; Jeff’s is in programming.

The problem we addressed was how to make street parking simpler and more flexible, using type for screen design and a cashless form of payment. This was the definition of our project.

Next came stakeholder research, which was anecdotal and involved us quizzing friends and family about whether they thought parking meters could be made more simple. The answer was a resounding yes, and the idea of a simple, cashless frm of payment got a ringing endorsement.

So we knew we weren’t wasting our time, and put some initial design research together (please see presentation below). We looked at the current design of coin-operated parking meters, and although there now exists a cashless, mobile-operated payment method, we wanted to see if we could cut out the mobile interface and augment the user experience, employing Dan Safer‘s principles of making the interface trustworthy, appropriate, smart, responsive, clever, ludic and pleasurable.  OK, so it didn’t have to have a ludic quality necessarily, but the principles were there.

Our first presentation was nothing if not ambitious, as this Powerpoint/Keynote will hopefully attest. First up, I gave a brief introduction to the problem and basically iterated what I have outlined above:

Firstly, we outlined what we considered to be barriers to easy use. Throughout this process we became aware of the fact that it is perhaps not in the interests of local authorities to make parking easier for users, as they rely on their built-in inconvenience for issuing parking tickets, and thus raising revenue. We immediately saw this as an opportunity for users, but a barrier to uptake by local authorities:

We then showed what ParkMobile has achieved, which endorses the fact that parking is a problem that requires private initiatives, and these initiatives can be brokered with local authorities. Research revealed that the present system is popular, and that the registration process is quick and simple, involving registering a mobile number, registration number and bank account details:

By following ParkMobile lead, we initially proposed introducing a card system similar to the Oyster card. Users would register details online or over the phone, then be issued with cards that would carry credits and could be topped-up at the meter or online. It soon became apparent that we had over-complicated the issue, but it was a very valuable learning curve and reminded us that rigorous research, and “stress-testing” is essential to effective project stewardship.

We chose to illustrate the basic linear flow of ‘predictable’ user behaviour with the following, simple PowerPoint presentation:

We wanted to make the user’s initial experience uncomplicated and approachable, following Hick’s Law: “The time it takes for users to make decisions is determined by the number of possible choices they have.”

User’s are given language options, cash payment is still available while users are migrating to ParkSmart. The map indicates an interactive guide to local shops, services and amenities:

Once the language choice has been selected, users can enter details of car registration number – users do not have to have used ParkSmart before in order to enter these details:

Then users is offered options for hourly parking, or a “Touch in, touch out” option similar to that used on Oyster cards:

A confirmation page will pop up. Users can change information as necessary or simply confirm:

Confirmation of registration and time would then be sent to traffic wardens’ hand held devices: