Rough Cut Selector Implementation

For implementation I am responsible for how users search and select Trove content to be turned into Rough Cuts. For the moment I've just called this part of the site the 'Rough Cut Selector' page. Since Akanksha and Young are still working on getting the CSS and HTML for the site finished, I've just used bootstrap's jumbotron template to get started.

I looked a bit more into the kinds of results that are returned from both the Digitised newspapers and the Photos, objects and pictures section of Trove and decided to construct the API calls from the digitised newspapers simply because there was not that many results for crafting. I've based the code for what we demonstrated during our progress demonstration on the Trove Basic Search example from the DECO1800 resources site.

A major problem I've encountered is that Trove's API doesn't allow me to directly access the jpeg urls of scans of digitised newspapers, although I am able to access a pdf file containing these images.

Although digitised newspapers have an option to be rendered as jpeg files, I am having trouble targeting the URLs

You would think that the URLs Trove provides for the jpeg option would simply return the image src, but the URL returns a combination of image and text.

URLs for jpeg images return a combination of text and image 

This means that when I try to put this URL into an src tag I get the following instead of an image:

I've talked to Michael about this during the practical sessions and he suggested trying out plugins like FancyBox. I've also looked at trying some sort of image scraping to access the images directly. At this point I'm just going to see what works. Although I could change our content to what is returned from Photos, pictures, and objects, I think that the scanned images are a better fit for the retro/vintage feel of our site.

Paper Prototypes for Workshop

Some pictures of the paper prototypes I created for our team to test user interaction in week 7's workshop. The actual feedback we received from using these prototypes can be found on our team blog.

Wireframes for Communicating Changes

I think our team was a little bit confused after we tried to incorporate some of the changes we made based on the feedback from presentations. To try and communicate some of the changes that were made a bit more clearly I made some very rough wireframes to highlight certain aspects of the concept and communicate some of the changes we made. 

Officially Lisa, Young, and Akanksha are working on finalising the wireframes and then implementing a layout in CSS/HTML based on this. Katie and Mayi will also be using the finalised wireframes to create a style guide and some visual mockups. I think the main purpose of the wireframes I created above was as a communication tool, and attests to the wide variety of uses something like a wireframe can have. 

Project A Documentation

This post is just to document what I did for the presentation we made last week for project A. I think that my role for this part of the project could be described as "compiler". I essentially compiled, edited and added content to what everybody else had worked on.

Breakdown of what I was responsible for:

Document

• Compiling everyone's work into a cohesive document structure.
• Content for the background research section of the document
• Supplementing things like wireframes etc with descriptions (e.g. Mayi created wireframes for us, and I wrote up a supplementary paragraph explaining them in more detail for the document)

Presentation

• Presenting the slides themselves (speaker)
• Coming up with the questions for feedback + idea to use post-it notes as a way to get feedback. I thought that this might encourage more people to provide feedback (not everyone wants to voice opinions in front of the entire class)
• Structuring the presentation slides (Lisa created the slides)

Feedback from the presentation - Lisa has collected and recorded all the feedback that was left on the post-it notes during our presentation and summarised some of the key points in a post on our team blog.

Our presentation tried to focus on presenting our intended users and the type of experience we wanted them to have on our site. I think this was mainly because we were conducting quite a bit of user interviews and persona-creation activities this week and it ended up influencing how we presented.

While I don't see this as a negative approach to take for our project's process, I think in terms of presenting an idea it was not necessarily the best way to communicate a concept. During a service design workshop I took over the winter break, one of the facilitators talked about the idea of the "Golden Nugget" in communicating an idea. Essentially this is a short and sweet sentence akin to a slogan that communicates the core idea of a concept. In terms of presenting DIY Trove, I think our concept could have used this.

What is DIY Trove?

One of the things that we have been struggling with this week has been trying to pinpoint exactly what DIY Trove is and does. I think the problem is that as a group we have been going for breadth this week and trying to explore a wide range of potential features that DIY Trove could have. In the midst of this we might have lost what the most essential or core features of DIY Trove should be.

During meetings we've been trying to do workshop-type activities like the one above aimed at generating a wide breadth of ideas.

I think it is a problem when a concept is hard to communicate. If your own team are not all 100% sure about what the concept is, then trying to pitch it to others is going to be impossible. In addition I think that everyone is unable to work independently because they are not so sure about which elements of the concept can be cut, and which should stay.

As a response to this, I've tried to think of a different way of communicating the DIY Trove concept instead of simply explaining what it is. The first diagram below shows how we as a team scoped DIY Trove, and the one below it is an attempt to communicate the core idea behind the concept.

Diagram explaining our concept from our presentation

Simplified diagram explaining our presentation. To be included in our concept proposal document

Although I don't think the diagrams make our concept that much clearer, I think it is a good start. At the very least the process of making these things forced me to recognise that DIY Trove is mainly about "RoughCuts" and "TroveFolk". I think the next step is deciding on which of the many features we've brainstormed in the past few weeks will support these areas of the concept.

In terms of managing our team, we more clearly decided what roles each team member is going to take. In terms of deciding this I asked everyone in the team what they were interested in getting out of the DECO7180 course, and also what kinds of activities they wanted to do. I also asked Lisa to start a group blog separate from our individual documentation. I thought it would be a good way for us as a team to keep track of our progress as a group as well as serve as a central area to dump any resources and information that needs to be communicated to the group.

In the end we've decided to split the team up into two main mini-groups of two, with Lisa and I working on other things:

• Akanksha and Young will be responsible for front-end technical implementation (CSS, HTML, & Javascript)
• Katie and Mayi will focus on interaction and graphic design of the site (visual mockups, style guide) as well as user research
• Lisa will concentrate of prototyping as well as documenting our group's progress through the team blog.
• I will work on back-end implementation (server-side/database stuff) as well as organising the team.

Week 4/5

After presenting our posters and pitching the associated ideas, DIY Trove was chosen as one of the concepts to be developed further. Although we haven't formally decided what roles we will be taking, from the way things have been going I think that I will probably be at least partly responsible for organising and managing the team that has formed around this concept. I think we have the largest group in the course (6 people), so I am a little bit concerned about how we are going to manage workload and finding times to meet.

I set up a Facebook group for our team, as well as a Drive folder. In the past teams I've worked in most people suggested that Facebook is the most convenient way of communicating things quickly, so we decided to go with that.

In addition I sent around a Doodle (scheduling software) to try and find out when everyone is usually free to meet. We've all set aside Wednesdays 9am-12pm and Fridays 10am-11am as times we can meet if there is a need to. 

We only have about a week and a half until we have to submit and present out design proposals, so I think that this will be the main focus of the agenda for our first meeting.