We are now working off agreed wireframes and user flows. The LSO team has provided quality feedback at all stages, which really helps.
This week has been focused on code details, how to make the app work with the realities of the ticketing process. A good example here is the use of local “caching” inside the iOS or Android device, meaning saving content locally.
With mobile devices being in and out of networks all the time, relying on a great 3G connection when a user is trying to view or show his/her ticket details at an event is not an option. We need to save down the event details and related fields as well as the mobile barcode that is the actual “ticket” locally to enable ticket redemption even where there is no mobile reception. As the creation of each ticket is happening server-side (backend), and can involve one user for one event ordering multiple tickets (for friends), with each one having to be generated and sent back and saved reliably on the app for future use – seamlessly and hidden from the user – not a trivial coding task.
PS: In this context I was amused to read so much this week about the “superfast 4G” trials by mobile operators in London, such as O2 – are these the same network operators that still can’t ensure a basic consistent 3G coverage in such remote locations as Wimbledon or Ealing?
Below a further screenshot from our project, this is from Survey Module and “work in progress”.
Just a quick update from the busy frontline of the LSO Mobile Ticketing app project. We’ve worked closely with the LSO team and had some input from our researchers Salford University to create
– app map (like a site map but for apps)
– data sets (list of data fields for each section, i.e. Contacts, Tickets, Events etc)
– user surveys (in-app)
and resolved many queries around the details of how, when, by whom tickets are currently produced and managed.
Up on the wall here are 2 tickets, one for LSO at Barbican, one at St.Luke’s – all we need to do is “mobilise” them…
The LSO team has defined a first version of the loyalty points scheme, this is used to encourage app users to share their ticket and event info and complete surveys, in return for rewards such as CDs and Spotify accounts. Think Tesco!
We’re hoping to finalise the app user flow within a week or so, then commence design for app and start backend coding. The app will be driven by our mobile marketing platform KOMOBILITY so many key features such as listings, push notifications, user profiles etc exist at least in basic module form, which will help cut down the development cycle – we hope!
See below some work examples…. we use Balsamiq for the mockups, and have set up a Basecamp account for everyone in the team to share and manage todo’s and calendar etc. This has proven very effective so far, cuts down on those emails with dozens of “cc’s” asking for “feedback” 🙂
Anyone from the wider group interested in a detailed aspect feel free to ping me.