Saturday workshop reflections

Reflections on Prof Damith’s presentation about presentations

Prof Damith was quite engaging despite it being a saturday morning and everyone looking slightly tired and unresponsive. As Assignment 2 has a presentation component I feel that the tips he gave would be applicable, especially his emphasis that we would learn by taking initiative to follow up his on presentation, and that there really is no substitute for practice and taking action, which was quite a meta call to action.

Prof Damith gave us a high level overview into different aspects of presentations, and also introduced to us his ‘puma’ framework, which consisted of starting strongly with a punchline, considering “what’s in it for the user”, and a specific promise of a gain. And then considering the audiences’ desired actions, beliefs and knowledge to craft key points and evidences.

Keeping the user’s needs in mind helps us to prioritise the features we consider when we develop, so we can present a compelling argument to use our app in terms of the users’ benefit, and not just the features we develop. Of course if that user was the developer then that process would be easier, to get a real feel for the problem you would know it at least exists, even better if that developer can build it.

In terms of presentation visuals, I think he made a good case for appealing to emotions to make it memorable, and selling benefits instead of features, as that is what makes a difference to users. Also the way he contrasted between boring statistics like ‘1000GB of memory’ and ‘1000 hours of movies’ was a good reminder of how to craft a meaningful message to our audience.

Deciding on which framework to use for the Facebook app

After experimenting with different boilerplates like react-starter-kit, our team decided against using the new boilerplates as we just did not have the time to figure out new tools like GraphQL, and risk getting stuck or wasting time getting familiar with new file structures. Also we had to spend an unknown amount of time learning new conventions and best practices of the tools and boilerplate.

We decided to use MeteorJS, React and Redux as Irvin and I had previous experience developing apps with it and our other developer Thanh picked up most of it relatively quickly.

Although we were required to submit a SQL schema and the official supported database was MongoDB, we could also use MySQL with Meteor.

We also chose React over Angular / Blaze for the rendering engine as there were front-end libraries like Material UI which provided us with components to use, helping us save the little time that we have to deliver a working prototype.