In this final post we will look back and reflect on the whole process of the project and the obtained results. For the interested, some music to set the mood. Ok, here we go.
The good, the bad and the ugly
We personally feel that the final result is a good looking application. Social Fridge definitely has some strong points:
- Inviting people and responding to an invite is really easy to do.
- Logging in with Facebook (and the use of this social network in general) was also a good idea, although a bit obvious.
- The ‘View Parties’ screen makes it easy to review or remove the parties you are in.
- The app supports all Android versions.
- It was promising to see that our SUS-score was improving (from 72% to 79%), although we’ll never know the score for our final release.
- Finally, despite some discussion on our blog about the benefit of having fridge management (see the discussion in the comments here) , we are happy with the ‘My Fridge’ outcome, which proved to be simple, easy to use and fast.
Of course, we are also aware of some of the weak points in our final result:
- Picking time slots remains an issue for some of the new users. This has been a problem since the beginning, but the way it is now, we don’t think it can be any better.
- Inviting friends is easy, but understanding what happens after isn’t (“Am I done? Do I have to wait for their reply?”). We had to use a warning message to explain that.
- It takes quite some time to fetch all the necessary data (e.g. fridge content, list of friends, etc.) from the database.
- Unfortunately the app occasionally has caching problems or crashes.
Now, about our approach. We believe that we followed the approach taught quite well. One thing we remember from the brainstorm session was that we thought to structured, but came up with this idea anyway. An idea that is quite original and might help students all around the globe! The evaluation of our first paper prototype release was a bit sloppy, but from then on (after we learned the key points in evaluating) we tried to do this in a more structured way. One thing we didn’t really do was analytics and keeping track of some important buttons. We had this implemented via Google Analytics, but we never felt the need to check them thoroughly. Maybe this would be more useful in a later stage, with much more users. We were always good on schedule (probably one of the first groups to start coding) until after the holidays. Although we kept coming together every week and meet our deadlines, things went a bit slower from then on. We also maintained our blog quite well, but the gaps between successive releases was too big. This resulted in a third and final release that came too late for a thorough evaluation.
If we would start all over again (hopefully we don’t have to 😛 ), we would try to find an app idea that needs less backend work. This would allow us to mostly focus on the user interface. We would also plan some sessions to learn Android development together. Two of our team members weren’t really experienced and, despite some effort, couldn’t really help with implementing the application logic. Another problem worth solving would be to find more test users. We could for example try to establish a group of permanent testers (people in our environment, i.e. siblings, friends and fellow students), perhaps in collaboration with other teams.
Obviously, with more time left, we would thoroughly test and evaluate our current release as it is the release where all different parts (i.e. fridge management, selecting a dish and inviting friends) come together. We would then do one more release to try to fix the main problems, and evaluate that fourth release.
Some extra features that would probably be really nice to include are for example inserting new recipes (of your own), publishing requests for missing ingredients on Facebook (which also helps advertising the app itself) and adding the party to your Google Calendar. Besides starting from a certain dish and then inviting people with matching ingredients, one of the original ideas was also to do this the other way around, i.e. starting by selecting some friends and then find a matching dish based on all the available ingredients. This website actually does something like this, but only if you first choose a bunch of ingredients.
From a more technical perspective, our choice for Android paid off: the user interface was simple to build and worked great. Google App Engine on the other hand proved to be a problematic choice though. We want all users in a party to see the party in the same consistent state at all times, but the eventually consistent nature of the backing Datastore made this very hard to achieve. A more classic backend using a classic RDBMS (e.g. MySQL) would probably more than suffice for our limited scaling needs (up to 20 to 50 users) while providing a consistent view on the data (but without replication).
We conclude this post, and our project, in SOS Piet style: “What have we learned this semester?”
- Workflow: Don’t lose too much time creating persona and storyboards. Instead invest time in making sure everybody knows the tools/language/platform so that everybody can help with every part of the implementation. Also, to avoid stalling, define todos for every week. An issue tracker (such as GitHub issues) can be used to follow up on these todos, even if they’re not code-related.
- Things that are obvious to the developers are not always as clear for users. We learned this the hard way with the infamous “Done”-button on the ‘Invite partners’ screen, which was refined in release 2.
- Things tend to get complicated by themselves. Start off simple and avoid getting trapped in discussions about details.
- Blogging is an interesting replacement for classic reports. You can converse with others (other teams and actual users), and it helps the team to stay up-to-date on the progress of other team members.
There’s only one appropriate way to end this: so long, and thanks for all the fish! 😀