Final: Course reflection

Week 1 vs week 13

Week 1

Studying Design Computing Studio I this semester, I expect it to be  I expect that  Through the glimpse I got during the first lecture, I’m hoping that this course will put the Masters program in a new perspective, pulling in skills learned from different courses so far. Most of the courses I have taken to date have stood alone but I think this course will start to bring it all together. I’m also hoping a might get closer to a definition of what design thinking is :P

I’m a little worried about the technical component of this course, and my current abilities. Learning Python last semester was so time intensive so I’m hoping it's not (but expecting) that it might be similar.

I’m looking forward to getting stuck into a new project and hopefully having something to add to my portfolio from this.

Week 13

My expectations of the course were both met and exceded. The concepts of design thinking are firmly planted in my brain and have almost become second nature in the way I approch design projects and design problems.

The group work was better than previous experiences but I think it was in part due to putting things in place to help prevent bad group expereinces (and our group were all great). We established team expectations early and lived by the motto of 'sawy what you'll do, do what you say, and raise any and all problems early'.

In terms of what I learnt, I spent way more time than I did on Python but learnt more too. I successful wrote and de-bugged php and mySQL queries and these weren't on my radar at the beginning of the semester. I was also able to learn some AngularJS and SASS which I have been wanting to look at but didn't know if I would get a chance in the course. I was also hoping to use HTML imports and maybe even polymer but that didn't pan out for our project needs.

Most of what I learnt was not through any of the formal learning (classes, workshops, etc) but through self-directed learning, either looking at documentation or doing differnt code tracks on Code Academy or Treehouse. The contact sessions gave me the pportunity to run prototyping sessions and garner feedback which was very helpful.

Final: Part C reflection and last minute feedback

The Tradeshow went really well.  We had lots of positive feedback from both staff and students.  It was so relieving to have it working and presentable.  I pitched the product to people who came to see and that definitely got better and better the more times I had to do it, which was really great practice.  I am so happy with the work that our group that produced this semester and our final product.

Some last minute changes from tradeshow and user test:

Save

On the Working panel, there was no confirmation to users that save worked when they clicked it.  I added a simple alert function to the success script: alert("Module saved!");  to achieve this.  Such a small piece of code to fix something that confused every person who tried it during the tradeshow!

Part C report + code clean-up

In the Process of writing the Part C report, I doubel checked all the code snippets and plugins I had used and doubel checked all my code commenting.  I also went through and clean-up the code for formatting, etc.

Tutorial

A tutorial was added just before the tradshow to the working panel to show users what each section did.  This was done as a result of feedback we received that our inital instructions (in the infographic) didn't covere the nitty-gritty of this page and there is a lot of detail to cover here.  I used a jQuery plugin from http://zurb.com/playground/jquery-joyride-feature-tour-plugin for this and changed minimal styling.

Module HTML clean

The main function that casued problems at the tradeshow was saving.  The saving function was running and returning success console.log text but only some modules for some websites wer actually saving to the database.  This was discovered the day before the tradeshow so we cam armed with a list of ones that would work to show-case.

While we had tested different aspects of javascript and PHP as we built the project, we fell into the trap of mainly testing the same module (Module 1 of Website 1 - Cricket Australia).  To tackle this problem, we took a logical approach.  First we looked at the ‘Working panel’ page, it was the same page (with the same inked js files) for all modules, the only variable was the module HTML data that was loaded.  Knowing that the content in the HTML and CSS editor panels had previously affected this page, we took a close look at the HTML that was being imported and did a more thorough clean of the HTML to make it work.

The first module we looked at was the one that went to a white screen if you tried to type in the editor panel.  It had a script tag in the code which was affecting the whole page.  Once this was deleted, that module worked fine.  The other elements we had to clean from the code were similar, mostly single or double quotes that caused the editor to think it was a string or other javascript elements (like “on-click”).  We all went through and methodically cleaned the code from all the elements and tested each one thoroughly to ensure that it would load, be edited, re-validated, saved, and that the saved module would populate on the ‘My restorations’ page.  This was quite a long and tedious task but thankfully we got them all and tested that each modules was able to be saved.

Week 13: User test with high school teacher

I also conducted the digital prototyping test with a high school teacher on 27 October.  This prototype version was further along than the last one we tested and included some changes to the error panel and addition of tutorial.

Task 1: Login stress test and workflow test

• Went as expected, worked fine
• Would like forget password option for students (future feature)

Task 2: Working panel and accessing help

Did you read the instructions on the home page?

• yes, infographic was good, are there more instructions somewhere (Getting started page)

Would you expect further instructions at this point? (Included tutorial)

• yes, liked tutorial giving step-by-step

Do you know what to do on this page?

• yes

What would make the errors easier to read?

• yes, numbering is a good idea

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

• would google problem, use often for HTML/CSS resources

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)?

• definitely save, kids wouldn't re-type

Task 3: Use the working panel

• QTAC module was broken (it produced a white screen when trying to edit)
• Some modules did not save

Other feedback

• Would use more for extension students
• Use Dreamweaver to code which auto-validates
• Like links to original website

Week 13: Final touches

Dynamic h1 tags

I checked that each page had a unique h1 tag and <title> tage for accessibility and SEO.  I then wrote a piece of javascript to dynamically add the Website name and Module to the Working panel H1 tag based on php variables.  I used the same method of converting PHP variables to Javascript as I did for the My restorations page.  See below.

Once this code was successful, I then helped modify it with Rena to amke dynamic 'History' buttons on the page that linked back to the original webpages.  

Minor fixes

• aligned font awesome icons on login page (user feedback)
• spell check content

Congratulations

I created a Congratulation modal (initially with a button input) to display a pop-up for when users have validated their errors to 0. I then had to write a bit of javascript to trigger the modal when this happened.  In the cricket.js file, Lyndon had already had a variable 'errornumber' when he wrote the HTML validator API call.  I appended this code to use this variable and add an action that displayed the number of errors and activated the congratulations modal when errors reached 0.  Both of which were tied into validation so were run every time the 'validate' button was clicked.

While adding the error number to the Errors panel, I also added some space to the errors and numbered them.  As the errors were text inside a <textarea> tag, I had to add a hard break in rather than use padding to add space.  Numbering the errors was just a matter of editing Lyndons code to include the index number from the error Array to the text using the 'i' variable:

for (i = 1; i < errorList.length; i++) {
$(errorListContainer).append(i + ". " + errorList[i][0] + " From line " +errorList[i][1] + " Column " +errorList[i][2] + "\n" + "\n");
}

PHP

I also added the PHP variables containing the user details to the Profile page so it now dispalys real data.

<p id="uName">Username: <?php echo $SessionUsername; ?></p>
<p id="uEmail">Email: <?php echo $SessionEmail; ?> </p>



Lots of work this week but almost there.

Week 12: Help and content

Lots of small fixes and additions this week.  I added real content to the help and getting started pages with efforts to top and front load content.  In addition to adding help content, I also added a link to Help on the Errors section of the Working panel page in line with user feedback.  I initially linked this Help to a modal lightbox but thought it would be more useful to have it pop-out into a new window.  This way users could view help (and go onwards to the help links) while still viewing and editing the Working panel page.  I used a plugin from http://www.quackit.com/javascript/popup_windows.cfm to achieve this. Help was also moved out of 'About' on the Nav and up to the top section so it is viewable without having to click down further into the nav.  

The other main achievement for this week was making a solid start on the Part C report.  I copied the dot points mentioned on the deco1800 website and wrote paragraphs relating to each point, tagging group members in sections where they needed to write for items I couldn't answer (e.g. problems they had solved).

Week 11: Optimisation and new 'My restorations'

This week started the final stretch where we begun optimising and finessing code/elements.  Based on feedback, we also took another look at how 'My restorations' worked.

Home page

Now that the Trove API calls and adding the images to the Home page works, I looked at how we could make the API calls run faster as it is quite slow.  Each image is retrieved with a separate API call based on a relevant keyword search limited to 50 results.  As I curated the images we used to illustrate each website, I could limit the API calls to return only the number of results required to included the image needed.  I went through each query, found which number the desired image was in the list, and then changed the API call to reflect only that number of results.  For some calls, that meant reducing the query from 50 results to 2 results and overall, this improved the loading speed of this page.  It was a bit tedious but worthwhile.  After I had completed it I spoke to another student of this course who suggested creating a list on Trove with only the desired images to call but as I had already refined our queries, I added this to the 'if there's time list' and left it at that for the time being.

It seems like there is often a 'better' way to do things, best practice, easy, optimised, etc, that I don't discover until I have spent hours using trial and error and stack overflow to just get it to work.  This can be really frustrating.  It is definitely rewarding to figure something out yourself and get something that hasn't worked after hours and hours of trying to finally work.  But, it is hard to accept a 'better' way to do something that is different to the way I figured out because of the time involved.

This week in 'PHP'

I added the logout function to all pages in the nav which meant re-saving all the pages as.php, not .html to make this work.


Working panel - HTML Editor
In response to feedback received I changed the HTML editor (and CSS editor) to wrap text so users don't have to scroll sideways to view long lines of code.

This is a feature of the ACE Editor and only required the addition of one line:
    aceEditor.getSession().setUseWrapMode(true);

My restorations

This week we changed how my restorations worked in response to adding modules last week.  I realised that by adding modules, it became confusing how users access these modules.

Previous flow:
Home (choose website) > Website page (displaying modules) > Working Panel > My restorations (displays saved websites).

To access the second module, a user would have to return to the Home page and reselect the website as we did not provide navigation links to each website.

New flow:
Home (choose website) > Working Panel (module 1) > My restorations (dynamically displays websites and modules indicating which modules have been started).

To accomplish this I did the following:

• Got rid of individual website pages and replaced them with individual html file with only the website module information (ie not head or body, just a div)
• Created a plunkr to test using Javascript to add html snippets to a page based on hardcoded variables
• Created an AngularJS repeater function to add divs with IDs to the 'My restorations' page so there is an empty, targetable div on the page for each website
• Make the Javascript work with PHP variables to tell when a module has been saved or not.

Using PHP variables in Javascript

To use the PHP variables in javascript, they need to be converted, e.g. var cricket = <?php echo (json_encode($cricket_start)); ?>;.  Where ‘cricket’ is a new Javascript variable and ‘$cricket_start’ is a variable in PHP that we need access to.  The syntax for converting variables was easily found using a Google search but the javascript file did not work as expected when added to the top of a modules.js file.  Knowing that the hardcoded variables worked, I knew it was the variables, not the Javascript that was the problem. The simple fix for this turned out to be converting the variables in a script tag on the my_restorations.php page rather than the modules.js file. 

Week 11: Feedback 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.

(Originally posted on our team blog: Restoring the web)