Week 5: Meeting minutes 26 Aug

Attendance:

All

Discussion:

We discussed our concept ahead of our Part A presentation and concept documentation next week.

Specifically the scope of what would and would not be included, refined our target audience (what they would get out of it, what their needs are) and went over the work we have already completed on wireframes, APIs and technical research.

Actions:

Part A Concept Document: complete (barring feedback from presentation) by Sunday 30 August

• Lyndon and Felix to write up research (noted in Google Doc)
• Rena to add wireframes + description to an appendix
• Lilly to type up dot points and finalise document

Part A Presentation: plan completed by Sunday 30 August

• Google doc outlining plan includes
• what each member will say
• list of props
• who will print what
• Summary:
• Overview of concept incl Audience (Lilly)
• Details of screens and what's included (Rena)
• Design Walkthrough of user behaviour (Felix)
• Technology/APIs used (Lyndon)

Style Guide: Started this week, to be complete by week 9 (Part B deadline)

• Start a CSS file in GitHub
• comment styles with reasoning
• start research into decisions (reversed out code panel to make it easier on the eyes, etc)

Wireframes feedback: Rena

• remove search
• add validate button next to 'error's solved'
• do we need a CSS pane?  need to research.

Trove API limitations

We met today (meeting minutes to follow) to refine our concept and discuss our research so far.

There is an initial problem that we are currently working through regarding the brief requirement of using the Trove API.  During our research we discovered that the trove API does not provide access to the websites listed on the trove website.  We can however, use the Wayback Time-machine API (that Trove refers to) to get this information.

A closer read of what the Trove API can and can't access says:
"Search Trove newspaper articles, lists and works. (Works are made up of “versions”. They can be books, images, maps, music, sound, video, archives, journal articles…) Archived websites, people and organisations have not been included at this point."

We also looked at the search function of the API, and the 'search all' does not include archived websites:
"Search across the records in Trove. The same records you search from the Trove homepage, excluding archived websites, people and organisations."

We are in the process of discussing solutions with our tutors and course coordinator and have contact Trove to see if there is any support or workarounds for accessing archived websites.

Our current suggested fix is to organise the websites accessed via categories (e.g. sport, arts, education, government...) and to illustrate the categories (background, button?) with trove images (related to the category but not the actual websites) which are pulled using the trove API.

We would still need to use the Wayback Time-machine API to get the website details to validate but at least we are not by passing Trove altogether.

One of the risks we discussed today was having to make design decisions based solely on checking off a box in the brief and not on what would make the best product that suits our user needs.  While for the most part these two considerations are not opposites and inform decisions in consort, we are hoping that this problem is not the case of the former.

The core part of the brief that we are answering is to:
"highlight, reveal, [or] focus the content available through Trove ... something that goes beyond the simple search paradigm that they currently have and that sheds light on rarely visited corners of Trove."

We believe our concept definitely does that.  Stay tuned for more concept updates.

UPDATE: The course coordinator emailed back straight away with an OK to go ahead with our proposed suggestions.  We also chatted more with our tutor at the workshop and with the course coordinator after Friday's lecture.

Rough Wireframe ver 1

Home

Sign Up Page

 My Restoring Page (Achievements)

 Working Panel

Validator API Research

Posting a document as the HTTP request. Looks like it can be done through JavaScript in the form of an AJAX call.

This method—POSTing a document as the HTTP entity body of a request—is the recommended way to use the checker as a Web service.

To use this method to check a document:

• Issue an HTTP request with a URL for an existing checker instance such ashttps://validator.w3.org/nu/ or https://validator.nu/.
• Use the POST method for the request.
• Include the document to check as as the entity body of the request.
• Include the Content-Type request header to communicate the MIME type of the entity body; e.g., Content-type: text/html; charset=utf-8.
• Encode common parameters as query-string parameters; that is, just as you would with a GET request.

https://github.com/validator/validator/wiki/Service:-Input:-POST-body

The link below shows examples of POST requests using AJAX.

http://www.w3schools.com/ajax/ajax_xmlhttprequest_send.asp

Can get the Nu Validator to Output JSON objects.

Format is:

Type (The type of message / INFO / WARNING ect, Also where it occurs lines columns)

Subtype (Warning)

Message (The actual warning message to display / The semantics needed to fix the error)

Extract (Code snippet)

Refining the target audience

As part of refining the target audience for the web app, I looked into the current IT curriculum for high school students, specifically when and how web languages (HTML and CSS) are taught.

The Australian Curriculum Assessment and Reporting Authority has a draft national curriculum for Information Technology (up to grade 10).  The draft curriculum introduces the concepts of HTML and CSS for grades 7 and 8 (pages 89 and 90).

As I am not a teacher (and have been told the national curriculum is open to interpretation), I  also plan on speaking to an IT teacher to confirm what they actually teach and when.

Even though this forms a minor part of our assessment, I believe having a specific target audience will help us develop a more useful application.  The target audience will also go to forming the basis of any personas we develop.

Initial concept

This week, we formed groups around concepts presented by each student.  Below is the initial concept, as presented by Lyndon.