I thought a good place to start on this blog would be at the beginning – what happened at dev8D. Unfortunately we were only able to attend the 2 days of the developer decathlon, so missed out on the other fun events.
Early.
Five of us met at TFE-o’clock at Canterbury East train station, where we made our way up to London, meeting with the 6th team member on the way.
After a few issues getting in due to a landslide further up the line, and the tube at Victoria being stuck, we eventually arrived at Birkbeck to find an extremely welcome breakfast laid on. We picked up our funky name badges and poker chips, then headed off to see which of the lightning talks looked interesting. We all settled on the same one – Paper Prototyping, by Mark van Harmelen.
Prototyping.
We went over the basics of paper prototyping to rapidly define scope and functionality and then develop and simulate a user interface. The talk was one of the longer lightning talks, but extremely useful, and well deserving of one of my precious poker ‘reward’ chips. I was glad to see Mark was one of the winners of the 4 Individual Medley Prize netbooks.
After the paper prototyping session we moved on to interview one of the UberUsers. The idea was to get a collection of relatively tech savvy users who could articulate the problems that they face. We (and a few others) had a chat with someone who was both admin staff and a student, so had an interesting point of view. It rapidly became clear from talking to our UberUser and others that universities in general are slow to respond to user needs, largely due to limited resources and complicated organisational structures.
We discussed things that might make life easier for a typical student, and a few ideas started to come out. One was a kind of ‘academic facebook’ — building on the idea of a VLE, but making more use of ‘social’ features, tagging relevant external and internal institutional content with some level of moderation to reduce the risk of plagiarism.
This seemed like a cool idea, but rather more than we could achieve in the time we had available.
The other clear idea that came out of the chat was reading list material. On the course our UberUser was taking, reading material was presented as a word document on their website. It only contained text, author and chapter information, with no links to the items held by the institution. Our user felt this was inefficient, and made searching for course reading much more difficult than it needed to be.
At Kent, we do have a reading list system forked from the open source Loughborough Online Reading List System. This has worked pretty well for us for a few years, but has a number of issues. Among other things we’ve had to bodge in support for multiple years of lists with our module code format which has caused all sorts of headaches, and it’s not very user friendly.
We decided this fitted pretty well. It’s a problem that affects ourselves as well as our UberUser, and having spoken to other people at the event it seemed we’re not alone. It also seemed like something we could feasibly get a working prototype going in a couple of days.
After a pretty good lunch we moved on to defining the scope of our prototype. We started with simply listing features or requirements, and roughly categorising them. At this point, everything went on the board, until we were reasonably sure we’d covered the important functionality.
We then prioritised this list, and started to turn these requirements into basic paper UI mockups, and workflow diagrams. We used loads of post-it notes, several giant post-its, and a large window to hold all the relevant information.
The ability to quickly sketch, rearrange and scribble out UI elements, required data and architecture meant we all had a good idea of what needed doing after just an afternoon, and we’d considerably simplified the amount of work that needed to be done without significantly affecting functionality.
Beer.
We’d pretty much finished as it was time to start packing up and head for the bar, so we did. The event had generously laid on a free bar, so we took advantage of that (mmmm, Erdinger), and discussed our prototype ideas further amongst ourselves, and chatted about the event in general with a couple of other developers who were there.
We then headed off to check into our hotel and then on to meal at the always excellent Ciao Bella Italian Restaurant.
Coding.
The following morning, we arrived back at Birkbeck after breakfast at the hotel and headed down to the basement where the coding day was taking place. This seemed reasonable for a room full of developers, several of who were either hungover, had been up most of the night writing code, or in some cases both.
It was on this day that the official twitter #dev8d tag really started to come into its own. A projector had been set up to project any mention of #dev8d onto the screen at the front. This was an excellent communication tool and source of information and amusement for the event.
There was a good selection of food and drink available, but sadly coffee supplies were a bit lacking in this part of the building. Our team quickly split into 3 parts as we’d worked out the night before – frontend UI, admin UI, and API services.
Once we’d got settled, the frontend UI team started to come up with a number of ‘student’ views of the readinglists, including sample dept web pages, mobile phone pages and portal/VLE integration examples, using Javascript and JSON to retrieve and render the data.
The admin UI team started developing a basic AJAXy UI on top of the Symfony PHP framework to manage lists and the items on them.
The API team started work on a set of tools to query external data sources (amazon, and a library catalogue) which fed data back to the admin UI. Just to make life interesting and due to differing areas of expertise, these were written in perl, again using JSON to exchange data. I also had the chance to sort out some UTF issues with the new perl Z39.50 modules that had been annoying me for some time, so that was an unexpected bonus.
We worked on these pretty much all of the second day, testing some ideas and throwing them away as we went to save time while keeping others, and cursing repeatedly due to wireless issues. All the code produced was a complete bodge, but reasonably functional.
Lunch arrived in the form of the pre-ordered burritos which were *excellent*. Developer happiness clearly peaked at this point according to the Happier Pipe which had been knocked up the night before to measure happiness on twitter at the event.
After lunch we started to tidy up and test code with some test data. A few issues aside, we had a mostly-working prototype just before we left a final rude ascii art message on the live event twitter feed, then packed up to get a train home.
Done.
In the following week, we tidied up the prototype for the production of the screencast that we had to submit as the competition entry. We used a new presentation tool called Prezi to create the slideshow, which seemed to work pretty well, especially for showing architectural diagrams and making the presentation look a bit more exciting.
We somehow managed to get the entry submitted on time, then had to wait for what seemed like ages for the results…
Overall, it was an excellent event and very well organised. We met some cool people, had a lot of fun, and it was a good opportunity to have a go at some new development methodologies we wouldn’t ordinarily have tried. If we get a chance to go next year, assuming it is running again, it would be nice to attend the full week.
