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.

Experience with Digital Prototype and User Test (Week 11)

For this testing session the groups swapped members, so Lilly and I conducted the testing session. Well, I mostly observed and provided technical support. Lilly created a great document to run the testing session to make sure we got consistent feedback which can be found at this link 

While the prototype performed ok, I would have really liked if we had the CSS panel functional so we could have tested it also. But it remains a thorn in our side much like the dynamic saving and loading. There are still a few weeks left to go so hopefully we can get it all finish in time to add some polish before the final trade show.

I am confident though after this testing session that I have correctly implemented the log-in system and it will be usable for the final prototype. I just need to un-hardcode the data loading as the next step in the PHP chain the get us closer to final functionality.

I was hoping that testers would interact and play with the code a lot more during the testing session, but I guess they were excited to see what other teams were doing as well. Our project is not exactly the sexiest when compared to the Findamals game. Never the less peeking at other teams prototypes I think we are well on our way.

I was actually surprised by how little seemed to have changed in the Pinboards prototype there were a few more pages but the core functionality and using HTML5 canvas was not completed. The Truth Detective game was looking really good though, I really liked to cartoonish art style they were going with. 

Enough jabber, here are the results from the test again migrated from the team blog.

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

Dont stop the PHP Train

Another update on my PHP Progress. The Index.php file is now working completely, and has been restyled to fit in with the current style guide. The database is correctly storing usernames, passwords and emails, without a hitch. It is also redirecting users on log in to the home page.

While that sounds like not a lot given that is was 'ready to go', '90% complete', 'pretty much done' a few weeks ago. In reality it took a lot more blood, sweat, and tears over the Midsemester break to figure out what was going on. Why the redirect was not working correctly, why the sessions were not connecting. Why I was being locked out of the database.

In short the struggle was real friends. But we got there in the end.

current Index.php page

The good news now is after this weeks team meeting and the news that there will be a digital prototyping session next week. The PHP train is going to keep on rolling. The plan is to get the database completely set up so that each registered user has their own website code which they can work on which is they are able to save.

If the progress so far is anything to go by this is going to be a big effort. But once its done the back of the project will be broken and it will be on to bigger and better things.

PHProgress

Just a quick recap of the work done in the final workshop for last week. There were not a lot of people around with groups climbing into holiday mode and illness going around. Which was good as I was able to really did into the PHP and hog Artuo's time in this session to get our Login system set up and working. 

Unstyled Log In Fun

While it looks terrible at the moment all the elements from our original site are ready to be put into place. I was testing this PHP experiment in a separate folder to ensure that I did not cause any issues with the gitHub repository or anyone else's work so it has no style sheet attached to it.

Please Register

A page that I had forgotten about, users will need to actually sign up. So we will have to do a bit of work styling this page as it is a new addition compared to the paper prototype. We also allocated jobs during this workshop session so I am confident that the team will be able to achieve another round of testing with a hi fidelity prototype after the break.

Database Entries

The fruits of today's labor. It is a small step in the right direction, but I am definitely starting to feel more confident not only with the PHP code syntax but how to spot errors. We looked today at the error log and how to print PHP errors to the screen to help with the debugging process and this will be invaluable as I try to load more data into the system over the break and convert more pages from straight HTML to PHP.

While there is no class next week, it definitely does not mean an end to the work and I am hopeful to have the PHP code finished by the end of mid-term break so that we can focus on additional aspects of the concept in the future weeks as well as adding polish.

Turning up the Heat

This week it was time to really get serious with the Project and kick it into high gear. Time to walk the walk and stop talking about "yeah so its all working we just need to hook it up".

That was the start of this week. What followed were some long nights, intense levels of frustration, vague JavaScript errors (along with the specific ones with no googleable solution >.<).

For my part of the project putting it all together meant that all the JS, JQuery, AJAX code that I had written I now needed to put into other peoples pages and made sure it worked in the environment that it was supposed to. Along with helping out the rest of the team with styling, and other page coding where ever they needed me.

Our end result demo code (live here) shows almost all of the functionality we want to include in our project as a core (CSS and HTML editors not playing together yet). I would have liked the styling to be a little bit more complete and consistent, but the team has identified this as an area we can work on other the break to make sure the prototype is higher fidelity and more easily able to be tested.

The other big hurdle that we are going to run into is our Back end system, which is currently non-existent. This is going to be my major role for the project so I am going to be spending a lot of time looking at this guy:

It is definitely exciting and scary at the same time, seeing as this is my first experience with PHP but it is something that I am really interested in for my later Thesis work. I am planning to make a solid dent on the back end systems over the break so that we can get into more gamification aspects of our project and improve user experience over and above the basic functionality.

Ill let you know how it goes ^.^

Feedback Presentation

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.