During the course Deco7180 we worked for the first time with APIs. We were given an interesting mission: we needed to do "something" with the open API that the National Library of Australia (Trove) has. This was quite a duty, because the API is a bit messy and it is a bit hard to work with it.
We had an Exploration proposal session where everyone presented a proposal idea. Trove has a massive collection of images from Australian Women’s Weekly so Ann Maree (our teammate) came up with the idea of taking those images as inspiration and generate a DIYer community. The members of this community could log in, “pin” an image from Trove that they find interesting and suggest a method to replicate it. The team loved the concept, so we started working with it.
Australian Women’s Weekly is a popular magazine that has been around for decades. The regular content you can usually find is related with recipes, decoration, fashion etc… so having access to visuals from this magazine could generate a very unique vibe to the community.
We started a little research about the common DIYer communities already popular as a way of inspiration and also to detect common patterns between each platform. The main ones were:
Semi-structured interviews were conducted with four people. Our criteria for selecting participants was broadly any person interested in DIY, and this initially included people who were interested in areas such as cooking. While we eventually focused on users interested in craft, these interviews influenced the decision of the features included in the final design. From the interviews conducted, we discovered information about:
Motivations as to why people DIY
Where users find their projects
How DIYers share their experiences
What design elements influence the users’ experience
During interviews all users confessed to instances where they would not share their completed DIY project. When it came to displaying and sharing their own attempts at a project users wanted to ensure they still looked professional and competent. In particular, one participant noted that if he were to release a ‘cooking attempt’ into the online world he would first practice and and perfect his method. Another participant joyously mentioned that if she failed at something she would be reluctant to share it.
By contrast, participants mentioned that if they were proud of an attempt they would happily share it through a social media platform.
“If I can make something that looks great then I will [share the experience in an online community]”.
However, there are limits to sharing and where and when users will share. One participant noted that while she likes to share her completed projects online through her blog she wouldn’t do the same with Facebook purely because she “[thinks she] would lose a lot of friends if [she] clogged their feed with posts”.
Users briefly mentioned aspects of design and functionality that aid in the experience of the website. In relation to Pinterest and the ability to collect and store projects one participant said, “I love that I have somewhere to store everything”. Another participant mentioned that the website she most regularly uses allows you to choose different recipes according to the user that submitted them. She enjoys how the recipes are “classified” and that you have the ability to “comment and rate the recipes”.
We defined the personas (primary, secondary, and tertiary users) to start generating possible scenarios, figuring out how they would interact with the system depending of their motivations and needs.
Once we defined a couple of ideas and prioritised UX Goals, we started generating wireframes (all the members of the team created proposals for different parts of the system).
We defined which features we liked the most to generate a paper prototype. This paper prototype was quite useful to detect inconsistencies and to define (and decide) which interactions we were going to be implementing)
We invited other classmates to test our prototype to make quick adjustments before coding the system.
We listed out which tasks we were going to be working on to generate the working system. I worked mostly on the Back-end (the Php integration -sign in, log in, sessions) and some elements of the Style along the Index and Dashboard.
DIY Trove is a web service aimed at crafters - people who like to make things from scratch. The platform aims to connect these people with interesting content from vintage digitised magazines in the Trove database in order to inspire DIY projects.
The DIY Trove concept is based around the community created on the platform: “Trove Folk”. Trove Folk are members of DIY Trove who find and interpret raw and untouched data from Trove into tangible DIY projects. Trove Folk can utilise DIY Trove’s features to discuss, create and share projects, as well as look to others in the community for ideas and inspiration.
The main feature through which Trove Folk do this are through “Rough Cuts”. Rough Cuts are “undiscovered gems” in the Trove database, i.e. untouched content that is presented to users as a snippet from a digitized magazine like Women’s Weekly
Rough Cuts function as a call-to-action for committed users, encouraging them to take this raw content and use it as a base to create interesting DIY projects, which are then featured and shared. After choosing a Rough Cut to experiment with, users create any project that they feel is inspired by a piece of content. In the case of the Rough Cut, this could be a dress, a hat, or even a hairstyle.
Users are then invited to share the experience of turning a Rough Cut into a DIY project. Sharing their experience might be by writing a blog post about it, or uploading an image onto Instagram. A collection of all these posts will be displayed in a gallery that is at the bottom of each Rough Cut page.
Please navigate the Demo Website to have an idea of how it works. Feel free to generate a new user (or use the default one, user: MayiCervantes and password: Mayi12345)
Note: We created this project in 2014. Now it's Nov 2016 and I noticed that the API from Trove is not retrieving information as it used to, which makes me think they could have changed the way they handle images in the last months. I am still trying to sort out how to fix this integration. In the Demo version available here, most of the Images are hardcoded, but in the Fully-funtional system we presented in 2014 the images were retrived directly from Trove.