Having the chance to develop and deploy a Google Wave gadget as part of a school assignment is something I’d never thought I’ll write about. I begun using Wave pretty much since it was available, but not to the extent that my daily workflow was dependent on it. It has been really convenient to discuss and collaborate on ideas within Wave, real-time or not, and somehow the interface seems more appealing to me than using Google Docs.
Regardless, Wave has at best been an easy means to certain ends, but it is probably a lack of maturity and adoption of the platform that has slightly reduced its appeal. It is useful, no doubt, but thinking of particular scenarios where one might use Wave hasn’t been all that simple a task. Brainstorming for an idea to execute upon for the assignment was painful for me, and admittedly I initially didn’t have much interest in what I’ll be able to learn from it. I had been pretty busy with sgBEAT and preparing for the pitching session, and my lack of enthusiasm was probably more apparent than I would have liked.
I was decidedly comfortable with most of the ideas that the rest of the group had come up with – as usual my concern lay more in the challenge of the execution as opposed to the idea-generating process. Nonetheless, I felt that it was a good choice for us to settle on an event organiser, as it was something that I could definitely see myself using in future. Our interface would be a simple grid reflecting the immediate week and a relevant selection of hours, and all the participants of the Wave would have to do would be to select their available timings on the timetable. The grid would reflect the selections accordingly, and the most suitable time slot would be indicated to everyone.
Coding this was not as straightforward as I had hoped, as the HTML could not be static and had to be dynamically generated depending on the current date and time. We assigned each cell the UNIX time it represented as its ID, and I used Javascript to render the layout of the timetable. We then used jQuery to facilitate the dragging nature of selecting the cells, and up to then the easier part of the execution was complete.
The challenging part was having the gadget interact with the Wave state, and the problem was the number of keys we were going to have. Eventually we decided on having one key per selected cell, and through the efforts of one of my group mates, we were able to effectively map each cell to its own key, which we then used to keep count of the number of selections by the participants.
From there, development was much easier, and we simply used CSS styling to indicate the selected cells, with the most popular time slot shown with a different colour. A consideration made was whether we wanted each user to be assigned a colour of his or her own, but the overlapping choices was a problem because the colours would have to merge to form another colour on its own. We thus chose to indicate to the user his or her own selections by marking them with a cross. Other features like adding a title, notes as well as an extra week was included to make the application more robust, and just in time for our submission as well.
It was definitely a challenging development project, and also a pretty good Javascript refresher for me. I got to dabble in HTML, CSS and Javascript this time round, not to mention the relevant Wave APIs, so there was much learning involved as well. Perhaps if there’s time during the holidays I’ll try developing another gadget, but school is pretty much the priority now.
Tags: CSS, Google Wave, HTML, Javascript, jQuery, sgBEAT
