Digital Prototype: Off-class tests by Rena

Here are some records for the Digital Prototype test session I ran in my friend's house last Sunday. Both of the tester are bachelor students major in IT related fields with some fundamental HTML and CSS knowledge.

Number of users: 2

Task 1: Login stress test and workflow test

• Didn't realise he had to sign up first as the sign up button is not clear enough
• In the [member area], found that there is not [back to home] link after login
• Would prefer a automatic drop down list of [About]

Task 2: Working panel and accessing help

Did you read the instructions on the home page?

• yes, and it looks interesting
• yes 

Would you expect further instructions at this point?

• No, it's quite clear x 2

Do you know what to do on this page?

• No, because I don't know I should sign up first
• Yes, to choose category after sign in 

What would make the errors easier to read?

• It's pretty obvious
• maybe present the Errors messages in red colour

If you didn't understand an error, where would you look for help?

• 1.Help Button -> Google -> w3school
• Google is our good friend:)

For each web page, there are multiple modules (e.g. Cricket Australia has 8 modules) that all pertain to the one page.  When you add CSS to the CSS editor and save, would you expect to see your saved CSS when you progress to the next module (i.e. Module 1 to Module 2)?

• Yes
• Yes, that would look more organised

Task 3: Use the working panel

• When click [save], would be better if there is a message saying "processing", otherwise I will click the button several times, and feels like its not working
• As it requires some time to process the validate function, it would be better to show up a "please wait" message after clicking [validate]

Feedback response: update

Here is the amalgamated feedback we have received to date (Part A presentation, paper prototype, Part B presentation, Digital prototype) and how we have or will incorporate it into our design.

Done! Will do (but haven't yet) Might do (if there's time) update

Feedback	When	Responses
Levels/Gamification
Add gamification including level up, easy/hard mode, or points for completion. Hard mode could include editing without validating first (see if you can find the errors yourself).	Part A /Digital prototype	Easy/hard mode has been added.   Easy/hard has been changed to modules.  Easy levels have smaller modules, code is broken up into chunks
Content
Add in option for users to find out more about their content.  Could be through linking back to trove to search topic.	Part A	Will add if there's time. Tangential learning is a sub-goal of our product. Users will already be learning through the content provided within the websites.
Have multi-user option (like google drive) or set up a study group to work on problem together to solve collaboratively.	Part A	Context of use is for classrooms or extension work.  The style of problem is more suited to individual learning.  We will add a commenting feature for other user’s projects if there is time. Likely we will not have time to implement this feature.
Help
How do users get help?  Could add chat panel or discussion board. Make help more obvious on editor page	Part A /Digital prototype	Help section has been added.   Help similar to codeacademy where they link to relevant stack overflow discussions. Will include glossary page with information from W3C on tags and tag changes across versions. Will move help button to errors panel.   Will make help a pop-out if time.
Audience
Concerns that initial audience of grade 7 & 8 students is too young.	Part A	Did further research that is discussed in previous blog post. Audience has been modified Web historians is for people: who are familiar with HTML and CSS but still beginners might know what validation is but don't necessarily understand it's importance or how/when it can be used would suit grade 10 at school but other beginners in the general public and university would suit classroom use or as extension work for school students
Features
Add in extra level of complexity with option of re-designing pages, not just cleaning up old tags and layout.  HTML5 validators don’t check for aesthetics.	Part A	Will add redesign feature if there is time but is not part of our core concept of correcting archived content to current web standards. Likely we will not have time to implement this feature.
Add in a gallery of finished projects with a voting system	Part A	Gallery of finished projects added (for all users to see). Will add in voting if we have time to implement redesigning feature as well otherwise voting doesn't’ serve much purpose. Likely we will not have time to implement working gallery feature.
Separate profile setting and instruction page.	Paper prototype	Done.
Logo position and style not consistent across all page.	Paper prototype	Done, logo and header now consistent.
Landing/Home Page
Reduce the amount of text to explain concept	Paper prototype	Added an infographic/flowchart to explain concept and how you use site.
It should be more obvious whether you are singing up or login (make buttons more distinct from each other).	Paper prototype	Done with colours/CSS styling
Add explanation for difference between easy and hard mode.	Paper prototype	Done on infographic.
Add in extra explanations/instructions for use.	Paper prototype	Will add more instructions on 'getting started page.
Make categories more obvious and easier to read.	Paper prototype	Done with CSS Styling. Have increased font size and made categories more obvious through use of colour.
Add in more categories	Paper prototype	If there is time. Likely we will not have time to implement this feature.
Editing page
Make it obvious what and how users are doing on this page. Make errors easier to read	Paper prototype /Digital prototype	Will display number of errors left to solve. Have changed layout of page to reflect order of work (e.g. errors 1st, editor 2nd, "Save" and "Publish" 3rd) Add small tutorial/instructions on how panels work/what you do on this page. Will group errors together, add space between each error, numbering if possible.
Make sure "Publish" button saves as well	Paper prototype	Will be removing Publish button based on other feedback.  Users will get a 'winning' screen when all errors are solved that will allow them to publish.
Make navigation consistent across all pages (currently different on this page)	Paper prototype	Navigation/header has been updated on all pages to be the same.
Make layout of editor customisable.	Paper prototype	Will do if there's time.  This is high on the list of to-do features. Suggested toggle box to make windows larger or smaller and continue to work in them or a pop-out system.
(relates to previous feedback) Make code editing window larger. (breaking up the errors into segments would also help with smaller code blocks).	Part B	We will need to look into the current capabilities for adjusting the editors size as well as users ability to resize windows. (Changes to overall page width will need to be represented across the site). ather than make panels movable, put content in tabs, either errors thin at top, 2 tabs: html editor and css side by side; viewer, OR separate html/css/viewer separate tabs and errors visible all the time
Add user name to work	Paper prototype	Has been implemented on gallery page
Let users know when they have solved errors.	Paper prototype/ Part B	Will add a 'congratulations' screen. Remove publish button and allow users to publish privately or public gallery via win screen/pop-up. Option to share success to social media if there is time.Likely we will not have time to implement this feature.
Add in a seperate box for CSS	Paper prototype/ Digital prototype	Have done (but not currently fully functional). Will make CSS save between modules.
Large amount of errors which load into the working panel. Hard to read/understand/manage (looks hard on easy level). Suggestions: order the errors by importance (must be fixed vs best practice) break  rebuild into sections; could be a good way to tie in gamification components would be a good way to work, encouraging users to encapsulate their code for each segment of a page.	Part B/ Digital prototype	Done See: Easy/hard has been changed to modules.
HTML editor text is small for some users.  Many found side scroll annoying.	Digital prototype	Let users use in-browser magnification to increase or decrease text size as needed. Have changed scroll to text wrap in editors.
Users would like ability to upload own images to working panel	Digital prototype	Will not have time to implement this feature
My Restorations
Make format similar to Gallery/Categories (i.e. tiles in a column/grid)	Paper prototype	Done
Change % progress bar to actual number of errors to make it more meaningful	Paper prototype	Done
Login
Would like log in to autofill after sign-up align font awesome icons	Paper prototype	Will do if there is time.

Digital Protoype: In class session results

Here are the result of the Digital Protoype test session we ran in our contact session this week.  We aim to conduct the same test with real users in the next week.

Number of users: 5

Task 1: Login stress test and workflow test

• Would like log in to autofill after sign-up
• align font awesome icons

Task 2: Working panel and accessing help

Did you read the instructions on the home page?

• no but prior knowledge of product x2
• yes x2

Would you expect further instructions at this point?

• as a dev, would rather play first
• small tutorial maybe?
• no
• instructions didn’t cover working panel windows, this is what each bit is, need to understand layout

Do you know what to do on this page?

• yes
• where can i type?  looks a bit scary?

What would make the errors easier to read?

• grouped together, space between each error, numbering would be good, bullet points, checkmarks
• they are fine to read
• multi-line erros, where does one error end and another start, gaps between each error, alternting line colours, wrap in container

If you didn't understand an error, where would you look for help?

• google problem, not go to internal help
• help should not be at the bottom
• help should be modal or pop-out
• difficult to see help button, add '?' help to error panel
• put help with errors
• google, stack overflow is industry standard on how to look for help

For each web page, there are multiple modules (e.g. Cricket Australia has 8 modules) that all pertain to the one page.  When you add CSS to the CSS editor and save, would you expect to see your saved CSS when you progress to the next module (i.e. Module 1 to Module 2)?

• blank, prefer to start fresh each module
• carry over if part of same website
• frustrating to start over
• would copy and paste if not automatic
• yes, definetly

Task 3: Use the working panel

• would like ability to upload own images 
• html editor text small x 2
• html editor wrap text rather than scroll x2
• rather than make panels movable, put content in tabs, either
• errors thin at top, 2 tabs: html editor and css side by side; viewer, OR
• separate html/css/viewer separate tabs and errors visible all the time

Digital Protoyping Usability session

This is the procedure we used in the digital protoyping session in class and will repeat with real users in the next week.  Sessions are run a one-on-one, in-situ interviews and usability tests.  Encourage users to talk aloud as they participate.  Remember - it is the system being tested, not the user.

Pitch the concept:

Explain concept but don't give any specific instructions on how to use site.

Web standards are important to ensure that web pages display correctly in all browsers. Learning current web standards and how to comply with them are an essential part of learning how to write HTML and CSS. As web standards change over time, they depreciate old tags and introduce new tags and new features. One of the problems with archiving old websites (e.g. Trove, Pandora, Wayback Machine) is that even as web standards change, the archived websites still use the old, out-dated HTML tags.
Web Historians provides HTML/CSS beginners with a practical, interactive web application to familiarise them with correct syntax and layout, the concept of web standards, the process of validating code against the latest standard, in context use of HTML and CSS, and basic editing.

Task 1: Login stress test and workflow test

Ask users to familiarise themselves with the home page (index.php) and when they are ready, sign up, log in, and log out.
(tests the login system, workflow of log in/out and set-ups for the next task to see if the instructions/information on the home page are read)

Task 2: Working panel and accessing help

Ask users to log in with test account (tester/tester) and navigate to the test module for Cricket Australia. (tests navigation to working panel)

Questions:

• Did you read the instructions on the home page?
• Would you expect further instructions at this point?
• Do you know what to do on this page?
• What would make the errors easier to read?
• If you didn't understand an error, where would you look for help?
• For each web page, there are multiple modules (e.g. Cricket Australia has 8 modules) that all pertain to the one page.  When you add CSS to the CSS editor and save, would you expect to see your saved CSS when you progress to the next module (i.e. Module 1 to Module 2)?

Task 3: Use the working panel

Ask users to have a play with the working panel, they can edit HTML, add CSS, and re-validate.  Ask if they have any comments or feedback.

Feedback response to date

Here is the amalgamated feedback we have received to date (Part A presentation, paper prototype, Part B presentation) and how we have or will incorporate it into our design.

Done! Will do (but haven't yet) Might do (if there's time)

Feedback	When	Responses
Levels/Gamification
Add gamification including level up, easy/hard mode, or points for completion. Hard mode could include editing without validating first (see if you can find the errors yourself).	Part A	Easy/hard mode has been added.   'Easy' is as normal, hard allows users to go straight to editing without validating.  Validation would be an option during the editing process but users could start without an error list to challenge themselves further.
Content
Add in option for users to find out more about their content.  Could be through linking back to trove to search topic.	Part A	Will add if there's time. Tangential learning is a sub-goal of our product. Users will already be learning through the content provided within the websites.
Have multi-user option (like google drive) or set up a study group to work on problem together to solve collaboratively.	Part A	Context of use is for classrooms or extension work.  The style of problem is more suited to individual learning.  We will add a commenting feature for other user’s projects if there is time.
Help
How do users get help?  Could add chat panel or discussion board.	Part A	Help section has been added.   Help similar to codeacademy where they link to relevant stack overflow discussions. Will include glossary page with information from W3C on tags and tag changes across versions.
Audience
Concerns that initial audience of grade 7 & 8 students is too young.	Part A	Did further research that is discussed in previous blog post. Audience has been modified Web historians is for people: who are familiar with HTML and CSS but still beginners might know what validation is but don't necessarily understand it's importance or how/when it can be used would suit grade 10 at school but other beginners in the general public and university would suit classroom use or as extension work for school students
Features
Add in extra level of complexity with option of re-designing pages, not just cleaning up old tags and layout.  HTML5 validators don’t check for aesthetics.	Part A	Will add redesign feature if there is time but is not part of our core concept of correcting archived content to current web standards.
Add in a gallery of finished projects with a voting system	Part A	Gallery of finished projects added (for all users to see). Will add in voting if we have time to implement redesigning feature as well otherwise voting doesn't’ serve much purpose.
Separate profile setting and instruction page.	Paper prototype	Done.
Logo position and style not consistent across all page.	Paper prototype	Done, logo and header now consistent.
Landing/Home Page
Reduce the amount of text to explain concept	Paper prototype	Added an infographic/flowchart to explain concept and how you use site.
It should be more obvious whether you are singing up or login (make buttons more distinct from each other).	Paper prototype	Done with colours/CSS styling
Add explanation for difference between easy and hard mode.	Paper prototype	Done on infographic.
Add in extra explanations/instructions for use.	Paper prototype	Will add more instructions on 'getting started page.
Make categories more obvious and easier to read.	Paper prototype	Done with CSS Styling. Have increased font size and made categories more obvious through use of colour.
Add in more categories	Paper prototype	If there is time.
Editing page
Make it obvious what and how users are doing on this page.	Paper prototype	Will display number of errors left to solve. Will change layout of page to reflect order of work (e.g. errors 1st, editor 2nd, "Save" and "Publish" 3rd)
Make sure "Publish" button saves as well	Paper prototype	Will be removing Publish button based on other feedback.  Users will get a 'winning' screen when all errors are solved that will allow them to publish.
Make navigation consistent across all pages (currently different on this page)	Paper prototype	Navigation/header has been updated on all pages to be the same.
Make layout of editor customisable.	Paper prototype	Will do if there's time.  This is high on the list of to-do features. Suggested toggle box to make windows larger or smaller and continue to work in them or a pop-out system.
(relates to previous feedback) Make code editing window larger. (breaking up the errors into segments would also help with smaller code blocks).	Part B	We will need to look into the current capabilities for adjusting the editors size as well as users ability to resize windows. (Changes to overall page width will need to be represented across the site).
Add user name to work	Paper prototype	Has been implemented on gallery page
Let users know when they have solved errors.	Paper prototype/ Part B	Will add a 'congratulations' screen. Remove publish button and allow users to publish privately or public gallery via win screen/pop-up. Option to share success to social media if there is time.
Add in a seperate box for CSS	Paper prototype	Have done (but not currently fully functional).
Large amount of errors which load into the working panel. Hard to read/understand/manage (looks hard on easy level). Suggestions: order the errors by importance (must be fixed vs best practice) break  rebuild into sections; could be a good way to tie in gamification components would be a good way to work, encouraging users to encapsulate their code for each segment of a page.	Part B	Will discuss/research/implement a solution to this starting with suggestions from Part B presentation.
My Restorations
Make format similar to Gallery/Categories (i.e. tiles in a column/grid)	Paper prototype	Done
Change % progress bar to actual number of errors to make it more meaningful	Paper prototype	Done

Week 9 Demo Code Feedback

For specific feedback we asked how everyone felt about the publish button. What if you publish something unfinished?

• There was no solid opinion on yes or no. But an interesting point was made about removing the publish button and instead having some sort of WIN! or achievement type system pop up when the user gets to 0 errors (ie. has completed the task).
• This could have an option to share the success to social media or publish to private or public gallery.

Multiple points of Feedback on the HTML editor or Working Panel.

• Users agree that the windows for editing the code should be larger, so that there is less scrolling to do (breaking up the errors into segments would also help with smaller code blocks).
• Artuo suggested toggle box to make windows larger or smaller and continue to work in them. While Fatimah suggested a similar idea of a pop-out system. 
• We will need to look into the current capabilities for adjusting the editors size as well as users ability to resize windows. (Changes to overall page width will need to be represented across the site).

This lead into a discussion about the Number of Errors.

• Currently there are a large amount of errors which load into the working panel. Users were concerned with the amount of errors and how they would be managed.
• Artuo suggested ordering the errors by importance (Must be fixed, not webstandard but wont break HTML, minor)
• The whole validator section will need to be styled and themed appropriately into the future.
• In terms of number of errors there was a suggestion to break the rebuild into sections. This could be a good way to tie in some gamification aspects as we are finishing up the build. 
• Components would be a good way to work, encouraging users to encapsulate their code for each segment of a page.

From this we touched again on the Target Audience.

• This is the second time target audience has been raised. This is probably out of fear that the task of validating a whole site with no help is too difficult for students mid-highschool. Perhaps we should look to pitch it at senior years (validate and redesign could be a good final project) and entry level for university.
• Looking at the volume of errors it is clear that re-validating is not a simple process, and saving progress will be important along the way.

Where to?

Setting up the back end database management system. Filling the database with content of archived websites, finding applicable images from trove and thumbnails to represent websites.

Paper prototype user Feedback

Landing Page
1. Too much text to read for the construction.  -Could consider using flow chart or combination of pictures
2. The "Sign in" and "Login" button should be more distinguishable (separated?) and more informative to users what the difference is.


Home page
1. More instructions to tell the user what they should do (e.g. What's the difference of Hand and Easy;)
2. Emphasise the category tags, letting users choose among different topics
3. Whether to show the current works if users have already signed up and made some edit
4. More pages for different topics?

Editing page
1. More objective-orientated that users should know what to achieve (e.g. the total number of errors,  etc)
2. Layout of the page should be changed to follow the sequence of the work (e.g. errors 1st, editor 2nd, "Save" and "Publish" 3rd)
3. Change "Publish" to "Save & Publish" or a popped up windows with confirmation
4. Consistent navigation bar, allow users to navigate to different page.
5. Layout of the editor (customisable? switchable tags?)
6. Users are allowed to add name to their works
7. Any hint to users if they have solved all the errors
8. Users are only required to edit on page (no hyperlink include)
9. Inline CSS or separated stylesheet

My Restoring
1. The way of presenting: follow the format of "Gallery" or "Homepage"
2. Process recording presents as number counter instead of percentage bar.
3. Name of the works: customised name instead of numbers


Gallery
1. The work shown in Gallery would list its author
2. Develop presenting style as light box


Others
1. Do we need to make a profile setting page and a separated instruction page ("Help")
2. Logo position, Logo consistency.
3. To import the website (index) with only one stylesheet, by restricting the year range.



By Felix
Thanks

Rough Wireframe Ver 2

1. It would be easier and more convenient to adjust and finalise our website's functions with wireframing in the initial stage:)

2. Once we got the main functions and pages sorted out, I'll finalise the wireframe in united screen size for paper prototyping and try to make a mocking up.

3. There is one uncertainty put at the end of the pages. It would be a good idea of having the page as long as we don't have too many technical difficulties in creating that. 

Home

Sign up page

My Restoring Page (Achievements)

Working Panel (Easy Mode)

Working Panel (Hard Mode)

Others Works (Gallery)

Full View of Other's Work

(Uncertain: This should be one more page popping up when people clicked on the HTML bottom to refer others' works. What do u guys think? :) )

Part A Feedback Response

This is our response to the feedback we received as part of our Part A presentation.  This information is also reflected in our Part A document submission.

Item	Response
Add gamification including level up, easy/hard mode, or points for completion.  Hard mode could include editing without validating first (see if you can find the errors yourself).	A normal/hard mode will be implemented.  Normal mode is as described above, hard mode allows users to go straight from selecting the website to editing without validating.  Validation would be an option during the editing process but users could start without an error list to challenge themselves further.
Add in option for users to find out more about their content.  Could be through linking back to trove to search topic.	Tangential learning is a sub-goal of our product.  Users will already be learning through the content provided within the websites.  If there’s time we will add this.
Have multi-user option (like google drive) or set up a study group to work on problem together to solve collaboratively.	Context of use is for classrooms or extension work.  The style of problem is more suited to individual learning.  We will add a commenting feature for other user’s projects if there is time.
How do users get help?  Could add chat panel or discussion board.	Will add a help section similar to codeacademy where they link to relevant stack overflow discussions.  Will also include information from W3C on tags and tag changes across versions.
Concerns that initial audience of grade 7 & 8 students is too young.	Did further research that is discussed in previous blog post. Refinement of audience Web historians is for people: who are familiar with HTML and CSS but still beginners might know what validation is but don't necessarily understand it's importance or how/when it can be used would suit grade 10 at school but other beginners in the general public and university would suit classroom use or as extension work for school students
Add in extra level of complexity with option of re-designing pages, not just cleaning up old tags and layout.  HTML5 validators don’t check for aesthetics.	Will add if there is time but is not part of our core concept of correcting archived content to current web standards.
Add in a gallery of finished projects with a voting system	Will add in gallery of finished projects for all users to see.  Will only add in voting if we have time to implement redesigning as well otherwise voting doesn't’ serve much purpose.

Target audience research: Interview with a teacher

One piece of feedback following our presentation of Part A was around the appropriateness of our target audience.  While I had intended to talk to a teacher before hand, I had run out of time.  Given this feedback, it became necessary as the curriculum did not give the whole picture, and a lot of the conversation we have had about the age-group revolved around anecdotal evidence.

To gain more insight on our potential audience and how our product could be used, I interviewed a high school information technology (IT) teacher who teaches grades 7-12.  Their experiences include teaching at a co-ed independent school, a state school and being involved in an Education Queensland monitoring program for IT subjects across a selection of schools (colloquially known as 'panel').

During my research, I had looked at the ACARA curriculum for Digital Technologies to see where HTML and CSS were taught. By speaking to a current teacher with first-hand experience, I was able to find more information of how this played out in a classroom.

Here are the main points from my interview.

• The National Curriculum (NC)is still in draft, but any curriculum is only used as a guideline.  The curriculum provides the framework and topics but the depth varies between schools and resources.
• Some GPS schools are very well resourced with IT teachers and teach in-depth HTML, CSS and Javascript.
• At their current school, they do not teach multimedia/IT in grade 7 and 8 but will be moving in that direction sometime in the future, possibly to align with NC.
• In grades 9 and 10 (junior) they teach a combined multimedia/IT subject and in grades 11 and 12 (senior) it is split into Information Technology Systems (ITS) and Information Processing Technology (IPT).
• ITS includes multimedia, web design and development, with a light focus on coding
• Grade 9
• introduce HTML and CSS
• use Dreamweaver but not drag and drop feature
• code single page with nav, insert pictures, links and concepts of HTML layout
• Grade 10
• build on knowledge, more HTML and CSS
• code multi-page site
• IPT includes AI, software development, databases and focuses on coding
• Used to do visual basic 9-12, now javascript in junior, objective c in senior 
• W3C is used like a textbook from grade 9
• HTML5 specifically is taught including what the '5' means, how it relates to W3C and web standards
• Students are made aware of HTML validators but are not required to use them in assessment as Dreamweaver does a lot of that for them.

What does this mean for the target audience for our project?

Web historians is for people:

• who are familiar with HTML and CSS but still beginners
• might know what validation is but don't necessarily understand it's importance or how/when it can be used
• would suit grade 10 at school but other beginners in the general public and university
• would suit classroom use or as extension work for school students

Week 6: Feedback

After our in-class presentation for Part A, we received a number of pieces of feedback for our project. Later this week, we will discuss the feedback as a group and assess how we will incorporate it.

Here is the feedback we received plus some additional questions it raised for us to research.

Gamification

• level up
• easy: validate
• hard: no validator = more points

Tangential learning

• do you want to learn more about a topic? Go to Trove and search the rabbit hole of links.

Multi-user

• more than one person editing like Google Drive
• set-up a friends group or study group to work on a problem together
• solve collaboratively

Help

• How do they get help?
• discussion board
• chat panel
• links to stack overflow (see codeacademy)

Web design

• add in an extra level of complexity 
• validation doesn't make it look better

Audience

• is years 7 and 8 too young?
• when is validation appropriate
• what are students really learning in the classroom
• how hard are the validation problems

Gallery

• add a voting system

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.