Better late than never: here is our third and final release of our Social Fridge app! Unfortunately we won’t be able to properly evaluate this release, due to the timing and the fact that there are still quite a few show-stopping bugs. Still, we didn’t want you to miss out on the chance of giving this release a try, although we recommend wearing a hardhat because things might break. (more…)
While working on our evalution overview, we noticed we never posted the evalution and results of the second version of our paper prototype. Probably, the reason for that was that we started working on the third version almost instantly after making the second version and we only had two test persons for the latter one.
But, because the final overview can’t have too many details and we don’t want to completely discard this iteration, we present the results in this post.
Sixth session, the last HCI session before the Easter Holiday. This evaluation is gonna be a (very) short one: it’s clear now what the expectations are and what needs to be done in the next weeks. (more…)
First of all the professor repeated that blogging shouldn’t be a burden, but something in our advantage, mainly because of the fast feedback we can get from other people. We should also post our session evaluations soon enough, so that they can still be of any use for the next session. I guess I’m already a bit too late with this post, sorry.
Anyway, some positive notes about last session: less talking, more working; good feedback; and a nice overview of what we could use for our digital prototypes. Quite surprisingly the first digital version of our app must be released before the Easter Holidays, which is sooner than most of us expected. We probably wanted to know this a bit earlier. It’s not that it won’t be achievable, but together with all our other deadlines it will be tight.
A final remark: Professor Duval took a look at our planning and adviced that, in order to have a testable digital version before the holidays, we should only focus on the main functionality: finding and inviting partners and choosing time slots to make spaghetti. I personally found it a pity that some things (like choosing a dish) were set aside, but it’s probably best to do so.
Session 4 was quite similar to the previous session. Professor Duval had evaluated our current testing and iterating methods and recommended a more formal approach based on a standardized
strategy. Why you change something is equally (if not more) important as how you change it. We already documented everything fairly detailed, but now we’ll try to do even better.
A positive note about the session again was that we had enough people testing our second version, amongst them professor Duval.
After the noon break we watched HCI videos for a small hour, which didn’t do me very good honestly as I got really tired after that. It was a sunny day and the room temperature got a bit too high and there wasn’t a lot of ventilation.
The third session kicked off with some HCI stories of the week and a few general remarks about how to blog and comment. We learned about paper prototyping and how to evaluate (i.e. get feedback from) a paper version of our application. Not too much time was spent on this which left us a lot of time to work on the project.
At a certain point (after an hour or so) professor Duval took a look at our progression. He noticed that we were working on three different parts of our application at the same time. He suggested strongly that for now we should only focus on prototyping the main functionality, which is selecting a dish and finding/inviting friends to make it. Professor Duval then said the same thing in front of the class also. A good thing he did and maybe next year this should be done immediately at the start.
The active help and feedback from the professor during the session in general was very good. What eventually helped us the most in analyzing our first prototype version was to have 4 fellow students test it. Or better, to observe them testing it. Based on some common problems they had, we were able to create and finish a second version just before 16h.
I can’t think of any negative points about this session. The explanation about paper prototyping was sufficient, but maybe too brief for some.
Personas are detailed descriptions of fictitious users, acting as a representative for some subset of the target user audience. They allow the designer to reason about his targeted audience in terms of only a few concrete (but fictitious) users, which helps to solve difficult design questions. Instead of asking “would our users be able to use this?” he can instead ask “would John be able to use this?” We created two personas to assist us with designing the user interface for our app: Riccardo and Elke. (more…)