One of the three services that I’m working here at the Aus-e-Stage project, part of the larger AusStage project, is the Audience Participation Feedback service. This service will use mobile technologies to gather feedback from audience participants. For this reason we call it the Mobile Service for short. A key component of this service is using mobile devices to gather feedback from audience participants either during, or within two hours of the performance finishing.
Feedback will be gathered using three different mechanisms and they are:
- Short Message Service – every mobile phone has at least this capability
- Twitter – users of twitter can provide feedback using Twitter from their smartphone or other mobile device
- Mobile Web – users of smartphones or other mobile devices can use a website optimised for mobile devices to submit feedback
This post will focus on the second feedback mechanism and outline how AusStage is integrated with Twitter.
The key to the integration is the hash tag. In essence hash tags, or hashtags depending on your preference, are defined at the Twitter Fan Wiki as a
community-driven convention for adding additional context and metadata to your tweets. They’re like tags on Flickr, only added inline to your post. You create a hashtag simply by prefixing a word with a hash symbol: #hashtag.
Our system uses hash tags to identify twitter messages, or tweets as they’re known, that are pieces of feedback using hash tags that are associated with our partner organisations.
The integration of AusStage with the Twitter service is achieved using our TwitterGatherer application that I’ve developed. This application is written in Java and uses the tweetStream4J library to access the Twitter Streaming API and the twitter-text-java library to parse messages and retrieve a list of hash tags.
The workflow for the TwitterGatherer application is outlined in the diagram below:
Importantly no identifying information is stored in either the log files or the AusStage database. The list of changes made to a tweet as a means of de-identifying users is outlined here.
In the above workflow an exception report is generated when no matching performance can be found in the AusStage database. An exception report can also be generated as a result of an error such as the database not being available. In this case the email contains a brief message about the error that occurred and a copy of the log file. This will provide sufficient information for a member of the AusStage team to take remedial action as required. For example adding the message text and associated metadata in manually once the database becomes available.
Importantly at no time in the process is personally identifying information either stored in the log files, the database or in the exception reports.
Once data is stored in the AusStage database it can be used for things such as data analysis or displayed on a web page that would provide live feedback at the venue using part of the Mobile Service API that is currently under development.
The “Audience at Humanities Theatre” photo was uploaded to Flickr by Mohammad Jangda and used under the terms of a Creative Commons License.

