Peter Cliff, Senior innovation developer from Jisc writes about the Hackathon he led at 12-13 March at Digifest 2019.
We took advantage of DigiFest 2019 to run a student hackathon alongside the main event. It was great to be able to see the wonder that is DigiFest and I think the students appreciated the opportunity to see the conference too. Before we get to the outcomes of the event though, what is a hackathon?
What is a hackathon?
There are lots of definitions. I think of hackathons as time-constrained events during which teams or individuals work towards solving a problem, often building a tangible prototype. That prototype may be implemented in software, but could just as easily be paper models, sketches, a poem, or hardware to express their ideas. We ask the participants at our hackathons to present their problem and the idea to solve it at the start and present what they built or found out at the end. In the middle we provide the time, space, equipment and sustenance to ensure the participants can work without external worries.
Why run a hackathon?
Because of the time-constraint a hackathon focusses activity on producing a tangible thing. This helps repress inner critics and provides the perfect excuse to note and ignore all the “what if” questions that can limit creativity. Those “what ifs” are not thrown away though and it is through the creative process that unknown issues can come to light. These issues can themselves be a valuable hackathon output. The events also create a strong sense of community, promote team work, co-operation and healthy, friendly competition. They are also a great personal development opportunity, help on student CVs and provide interesting things to talk about at interview – what was the problem and how did you solve it?
The output of a hackathon is often extremely impressive but sometimes this can be misleading. The same things that make a hackathon a creative and exciting event will lead to shortcuts being taken. Software may be created with a disregard for software engineering principles to create well structured, tested and maintainable code. Constraints are ignored: the Raspberry Pi will run fine during the demo attached to a battery on unsecured wifi but attaching it to power and WLAN in an office is going to take time. You are unlikely to deploy the paper-based prototype shelter into the field. It is important to realise that hackathon outputs are the solutions, noted pitfalls and ideas rather than finished products.
Themes and Teams
This year we asked for student ideas to solve problems in the themes of student wellbeing, shaping the curriculum, using AI or intelligent assistants or making campuses more responsive and welcoming. We finalised on seven teams from five different universities and an apprentice team from Jisc.
The range of problems they wanted to address were broad:
- Student ID cards are easy to lose and create plastic waste (The ‘big’ Hull team)
The campus app does not work very well (The ‘big’ Hull team)
Lecture sign-in has potential for abuse ((The ’small’ Hull team)
Language students may suffer from anxiety and shyness (Huddersfield team)
Students with restricted mobility may like to experience things like extreme sports though VR (Buckingham team)
Students coming to a campus may want to acclimatise to the culture and surroundings before arriving (Buckingham team)
Voice assistants may require proprietary models and applications where they exist at all for a campus (Coventry team)
It is difficult to track contributions to group projects, potentially skewing marks (Jisc apprentices)
Can AR be used as a technique to improve memory and recall? (Glasgow
In no particular order, here is a summary of the the solutions created:
- The team from Huddersfield built a flipped classroom to aid learning French – here Moodle was used to create a course for use at home to deliver lectures and other content to the learner. Google Classroom was used as a support mechanism for speaking and writing practice in class or remotely. This mean that shy learners could practice their speaking and writing in a safe environment and this work also suggested using speech interfaces as a means to assess pronunciation. I wondered here if institutions could offer greater support to their societies in using tools like Moodle.
- Coventry used Google’s DialogFlow to build a campus voice assistant that could respond to questions like “how busy is the Library?”. The great thing about this solution is that it can integrate with existing voice apps such as those built into phones and near-ubiquitous apps like Facebook Messenger. The team from Coventry had built their model prior to the event and worked at the event integrating with several solutions including Google voice assistant and Alexa. Sadly a bug in the framework prevented the Alexa integration but Google worked well and they demoed this working on the phone.
- The Jisc apprentices built a React-based application and a mobile app that allowed students to upload work and assign a percentage contributed to the project. The others in the could then peer review the work and the self-assessed percentage and post their agreement or otherwise. Disagreements would be dealt with by the tutor. This is a nice idea that we could develop further internally or at future events.
- The team from Buckingham (a postgrad aided by our new developer Rebecca Flook whose second/third days at Jisc were the hackathon!) explored AWS Sumerian to build a prototype 3D model of a campus, illustrating us of voice to welcome visitors and demoed how videos can be embedded into the VR/3D interface. This team also explored further the issues of using campuses for the first time and suffered from lack of decent WiFi during the event.
- The ’small’ Huddersfield team (2 members versus the ‘big’ 4 member team) produced a fully working app that used proximity to an iBeacon (a Bluetooth beacon specification from Apple) to prompt via a notification that students to check into their lecture. They also produced a lecturer tool that should show the students who had checked in, provide a real-time question/answer system, display the lecture room schedule (useful if you’re overrunning!) and even a whiteboard.
- The ‘big’ Huddersfield team created a well designed application that offered a complete on-boarding process to the campus including setting up Eduroam on the device, viewing timetables and schedules and lots of other things including an iBeacon-based lecture check in system.
- The Glasgow team – who were not developers – worked towards making their idea reality through use of AR toolkits and possibly existing applications. They took advantage of being at DigiFest to talk through their ideas and look at the technology on display. They also had a good conversation with Suhad Aljundi, one of Jisc’s Futures developers.
You said “healthy competition”…
All of the teams worked extremely hard and produced some incredible things. In the end we had to pick a winner and in this instance it was the ‘big’ Hull team for going from a few designs to a well-produced and functional application in a very short space of time. Their solution could solve a number of issues including saving the cost (and waste) of producing plastic cards and hopefully make it clearer why open APIs are the means to developing user-friendly applications and breaking down silos of information. While there was a single winner, there were no losers and all the teams took home a prize.
A huge thank you to all the Jisc staff who helped before, during and after the hackathon! If you want to know more about any of the ideas or make suggestions for future events, please get in touch!