GWave

Well, the Wave project is over. Got back our results for it, and the marks for the aspirations are significantly higher than that of the first assignment (not really surprised there ^^) One gripe i have, however, isn't about the assignment, but the initiative (or lack thereof) of one of our teammates. His role could probably be described as the least technical, yet when he encountered some difficulty, did not opt for an ask-for-help approach, and instead told us only on the last day that it wasn't done as it referenced our work, which he was not familiar with. Put that together with the rush on the last day (unexpected synchronisation problems), our expectation that he had done (at least most of) it, and the fact that coding while writing the report takes two rather different mindsets... Let's just say the final few hours were rather harried ones. And despite claims to the contrary, I don't really think writing the report is extremely difficult... even points for us to elaborate on would have been nice.
(end gripe)

We had a video conference with Pamela from GWave on Monday. She described some very interesting new features of GWave that might actually have changed our projects significantly. Some were more developer-centric, like the Blip Contexts and Event Filters, but what intrigued me more were the new abilities granted to the extensions. The Active Robot API would enable access to a wave without needing to wait for an event triggered by a user, allowing the robot to read an update the wave on its own; essentially, becoming more like a participant in the wave. The SVN bot that Pamela showed as a demo was an interesting application of this feature. She also mentioned Proxying for Users, which allows robots to adopt a persona that it created, adopted or imported, which would greatly improve readability of a Wave conversation.

A few things stuck with me from her critique of our applications. Firstly, UI is very important. No matter how cool your application may be, if the user can't understand what he / she is supposed to do, you've lost one user. Secondly, give clear instructions. Suyuen made a similar comment on our first / final project. Show / tell the users what they need to do, and what each action will give them. Thirdly, give them a choice. While not explicitly mentioned by Pamela, it is what i took from her example of the application Cartoony that removed cleartext and replaced it with a drawn version. This hindered replying, copying, and integration with other extensions. Thus, when making an application design decision, make sure it does not remove any freedom the users expect to have.

And as our application rolls into launch mode soon, here's hoping that we get most of these... somewhat right ^^