Get a cuppa… this is going to be a long recap!
The teams are ready for a final show-and-tell of what they have achieved this weekend. Steve has made everyone pick the running order using random cards, so no one had to volunteer to go first. We’re having a competition where participants can vote for which project has made the best progress this week.
First up, #BigSociety. Perhaps the short straw… but at least they get it out of the way nice and quickly so they can enjoy the other team’s presentations. #BigSociety are matching volunteers with opportunities – a dating app for volunteers! They want to improve on the mechanisms that are already out there for doing this, by making it faster and more slick.
They have a website demonstration on the screen, they are logging in as a “user” – a person who is looking for volunteer work. There are tick-boxes for skills, and one for locations that they are available to work in.
Once the user is registered, a community group/event organiser (the “admin”) can post up an event/job opportunity through this app. The criteria are the same as what the user can see to ensure that the application can provide a perfect match. The admin can also fill in free-text detail about the opportunity, information on how to travel to the location of the opportunity, and various other relevant details that the user would need to see before applying.
The user is then alerted to the event that there is an available volunteer opportunity that would be suitable for their skills and within the area that they are available to work. They have the option to Apply for this work, and when they have done that they receive an email confirmation of that.
Still to be completed are the alerts for the admin that there is a pending application and also allowing the admin to then invite the applicant to interview, or reject the application.
Next on the demonstration is showing us how an admin could list a community event. This would then be available for people to view on an application. While this prototype is still rough – it is very easy to see how this would work very effectively.
Second is Iain from #FOIAWiki. He has created some slides for the purposes of this presentation! The aim of this project was to open up FOI disclosures by opening up the information that is already on the Aberdeen City Council website. Currently it’s difficult to navigate and not searchable. The aim was to include crowd sourced tagging and allow reuse of data.
First steps for this team were to identify available data. Building schemas included the OWL and linked data. They built their ontology using LODE which Iain recommends to other participants. Using D2R Server and a MySQL back-end he has created the linked data.
Iain demonstrates the front-end, where you can search by tag and keyword to view the relevant PDFs. Currently they have scrapers from ACC and E Lothian but they have done it in a modular way so that people can submit requests to have their own LAs scraped and aggregate the data together.
#GoWithFlo are third on the list. Their aims have evolved over the weekend. They started out looking at producing accessibility guidelines for developers but discovered that there are already great resources out there for this. They then looked at producing a resource for the clients of the InfoHub that Flo had discussed who require easy read content to access internet page. It’s estimated that 10% of internet users have accessibility needs, so this page has been named “Ten Percent News”. The idea is that members of the InfoHub can create easy read versions of news stories. Long term they are looking to go bigger with this and allow people in other areas to read the news. They will use an app which auto summarises an article, and uses the Flickr API to match a picture with the story. After that a volunteer can review what the app outputs and tweak it, changing the suggested pictures and ensuring that the stories make sense. We’ve had a quick demo of searching for pictures by keyword and the page showing you the top five suggestions.
#Oranj have drawn number four in the running order. A mock up of a request form for a translation job is on the screen. Matias explains that the form has been designed according to the brief from the Translation Team. Once the product is finished it would link to a database, create a log-in for the requester, and email the request to the Translation Officers who could progress the job. A list of the requests made by the customer can be viewed, showing summary details of the requests that they have already made and allowing the person to view the full details input.
#JuicyWords, another part of the Translation project have drawn fifth. They have focused on the self-employed translators who would be applying for the available translating jobs. They’ve also created a presentation! It has a very attractive team logo. Artjoms explains that they wanted to create a team message along with the logo.
Their aims and objectives were to develop a web page with user-friendly design and assist translators in finding jobs. We are now seeing screen shots of how the interface would operate. It looks pretty slick! A demonstration of the prototype… You can sign up as a variety of different categories. A calendar appears which shows the dates that jobs are available to apply for. When you click on the date, the jobs appear. There is a profile where you can upload your details (languages spoken etc) and then that will filter the jobs that you can see based on your skills. There is also a page to communicate with the Translation officers, ask questions, cancel and accept offered jobs etc.
We’re now pausing for a bit of banter about different technology standards……!
#RosettaRoot have hosted their prototype on Google Docs for us to view. They are the final piece of the Translation team solution, centred around the Translation Officers themselves. They need to verify both posted jobs from customers and potential applicants who want to do the work. They’ve created a front-end that they’ve attempted to make API-ready. What they’ve created would provide a ready-made shortlist of applications for a particular job. An admin can log in using a username and password, and Danny demonstrates the ‘forgotten password’ function. The first thing the Translation Officer would need to see is a summary of requested jobs, with job numbers and other priority information. Filters are built in that filter by location, language and other criteria. They’ve also built a directory of potential applicants, that can also be filtered so that it’s easy to get in touch with the translators on file. Jobs can be viewed individually and a shortlist of potential applicants is also shown on that view.
#ActiveAberdeen make the penultimate presentation. Their project has progressed from a series of Statty-notes to a particular issue they want to solve. People may want to find friends to be active with. The team thought around the various situations people might want to participates in and settled on the idea of someone identifying an activity that they would like to participate in in quite a free-form way and finding people to do it with. Activities are searchable on this site, with the example being used being football. A user could post up an potential ‘event’ even if that’s just a kick about in the park, with the eventual idea being that people can comment via Facebook and other social media and indicate their interest. They’ve produced an attractive example site for this.
#MatchTheCity – the initial idea was to provide a back-end for the many ‘matching’ ideas that have been pitched this weekend. They’d started out with a tripartite model of people, opportunity and skills which would all required to be matched. They created a basic database for this quite quickly, other teams tested it, and then they had the opportunity to expand their idea by including other points to include ssh as venues, activities and events. These were all in a variety of formats (pdf, xml etc) which had to be parsed. Not all were very user friendly, an example being the Aquatics timetable, which we are being shown and I can confirm that it’s hard to see what time things start and finish and even what the events are.
We’re now being shown an example front end, with the caveat that they were concentrating on producing a useable back end! An example used is swimming, with many different swimming sessions and other aqua activities being shown – the venue, date/time, category and other criteria being easily shown in summary, and also a map of where the activity is. Iain from the FOIA wiki team has also been producing linked data for this. At the moment to find swimming you have to go and look on many different websites to find detail, whereas this shows it in one easy-view format. This technology could be used for many more different purposes than just finding sporting activities. With the times and status of activities subject to change (for example a swimming pool could be closed for refurbishment or a holiday) this could be incorporated into this database and updated in a similar way to how live traffic reports would be updated.
And that’s all eight teams… some very impressive demonstrations have been made, and everyone is off to vote for their favourite.