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 as
https://validator.w3.org/nu/orhttps://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-Typerequest 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
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.
No comments:
Post a Comment