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