Trade show / Course Reflection (Week 13)

For my full thoughts on the course please read my Course Reflection as part of my portfolio found at: http://folio.uqcloud.net/s4175953/courseReflection.html

In terms of my thoughts about the Tradeshow. They are very mixed, it was a wild day as I was babysitting my nephew. So I probably did not get the full experience (or the drinks afterwards) but the feedback on the project was really great to hear.

It was really nice to hear from Ben that our project was Ambitious, which I guess means that all the work and pain and hard work learning PHP means that we created something actually difficult and to be proud of. I feel that the level of functionality that we delivered was great, everything that we really wanted to do get done we did. There were no major catastrophes, apart from some websites not working saving correctly, shout out to Felix for manually editing the Database to pull out all the script tags and additional single quotations which were killing those modules.

We did not have to compromise our vision, everything we considered core got done and while there could have been some extra design work on the visuals or the interactions. Positive feedback aside it was really nice to see all the teams enjoying themselves and happy of what they had produced. Everyone had a solid display as well as candy the shipwreck crew even had goodies to play with.

Extra Migrations From Team Blog

Some extra content I put on the team blog earlier in the Semester: Our blog address is http://restoringtheweb.blogspot.com.au/

Original link: http://restoringtheweb.blogspot.com.au/2015/08/validator-api-research.html

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)

ORIGINAL LINK: http://restoringtheweb.blogspot.com.au/2015/09/week-9-demo-code-feedback.html

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.