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)

Week 11: Digital Prototype in class test

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

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

Week 11: Digital Protoype Test procedure

This is the procedure we used in the digital protoyping session in class and will repeat with real users in the next week.  Sessions are run a one-on-one, in-situ interviews and usability tests.  Encourage users to talk aloud as they participate.  Remember - it is the system being tested, not the user.

Pitch the concept:

Explain concept but don't give any specific instructions on how to use site.

Web standards are important to ensure that web pages display correctly in all browsers. Learning current web standards and how to comply with them are an essential part of learning how to write HTML and CSS. As web standards change over time, they depreciate old tags and introduce new tags and new features. One of the problems with archiving old websites (e.g. Trove, Pandora, Wayback Machine) is that even as web standards change, the archived websites still use the old, out-dated HTML tags.
Web Historians provides HTML/CSS beginners with a practical, interactive web application to familiarise them with correct syntax and layout, the concept of web standards, the process of validating code against the latest standard, in context use of HTML and CSS, and basic editing.

Task 1: Login stress test and workflow test

Ask users to familiarise themselves with the home page (index.php) and when they are ready, sign up, log in, and log out.
(tests the login system, workflow of log in/out and set-ups for the next task to see if the instructions/information on the home page are read)

Task 2: Working panel and accessing help

Ask users to log in with test account (tester/tester) and navigate to the test module for Cricket Australia. (tests navigation to working panel)

Questions:

• Did you read the instructions on the home page?
• Would you expect further instructions at this point?
• Do you know what to do on this page?
• What would make the errors easier to read?
• If you didn't understand an error, where would you 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)?

Task 3: Use the working panel

Ask users to have a play with the working panel, they can edit HTML, add CSS, and re-validate.  Ask if they have any comments or feedback.

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

Week 10: Modules

This was a little more of the same.  Once I got the api/images/angular working for the sport category I then repeated the process for all the other categories, checking nothing broke as I copy-and-pasted code.  

I also started into php for the first time for this project.  Lyndon had created log-in and sign-up pages in php and I edited them and styled them to look like the rest of our site.

The other large change was to simplify the html content that users edit and validate.  Some of the feedback we had was that the errors panel was too complicated and the easy level wasn't that easy.  To counteract how complicated it is, we decided to break down each website into smaller modules.  I took our cricket website (which we seem to use as our test case for everything) and broke it down into 8 different modules.  I tried to pick obvious break points in the module and had to edit the code a little to make sure all tags in each module had both opened and closed.

By changing the website into modules, we also had to change the easy/hard approach.  Instead of each website having easy or hard mode, now, depending on how modular each website is, it is now easy OR hard.  And we added more instructions to the website hover, 'begin restorations'.

Mid-semester break: style updates and more angular

I used the break to work on CSS/SASS and spend time with trove and the Wayback Time-machine.

Styles

• fixed some style inconsistencies with p and h styles
• fixed the logotype: h1 size ration (logotype in now larger)
• looked at the design of the page and changed from the 'indigo' colour palette to 'blackboard green' to match the infographic
• crop the category image using CSS

CSS Crop

Page design

Trove/Wayback machine

My next task for the break was sourcing material for our site.  We had already decided on the four categories (sport, arts, education, government) and my task was to find approx 3 websites per category and source appropriate illustrative images from Trove, and web historical content from the Wayback Time-machine.  I search a combination of Pandora and Wayback Time-machine to find good examples of sites for each categories.  I concentrated on local sites (Brisbane, Queensland, Australia).

Once I had selected the sites and made a list of the Wayback Machine addresses, I then went to Trove to find good search queries for each site.  Some were definitely easier than others.  I had AFL listed as one of the sport categories but was unable to find any images that were copyright free/retrievable with the Trove API.  I then proceeded to make the API calls, found the work IDs I needed, checked the calls work, and added the image URLs to an array to access for home.html.  

Problems and solutions

I used Plnkr to test adding real images to angular using a hard-coded array.  I then applied that to our real code but changed the hard coded array to the dynamic one constructed using API calls to Trove.

The complicated part of using this array is the combination of Angular and Trove loading times.  The angular repeat happens much quicker than the Trove API calls.  Given that a lot of the information about the website (the link, website name, alt text, etc) the order of the images in the image array is important. The first step was then to direct each API call to a specific place in the array that corresponded to the data in the angular file.  

e.g. imageArraySport[1]=olympicsImg;

Where imageArraySport is the array to store the images for the sports tab and olympicsImg is the variable storing the image for the Sydney Olympics website.

The next problem I had adding the images to the html generated by Angular.  I wrote a jQuery function that worked in plnkr that targeted a class and added the image source link from the links in the array.  This worked fine but wouldn't work when I used the real API calls instead of the hardcoded array.  I realised this was because the API calls came back at different times and when the function iterated over the array, it was not always full and returned a src link of nothing.

To counteract this, I ran the function in each AJAX API calland added an if statement to check if the array had the number of images.

e.g. if(imageArraySport.length == 3)

Where the sport category has 3 websites and the if statement checks this first before running the rest of the function.

Week 9: update and angularjs

This week I completed more work on styles and set-up html for the other pages we will be including on our project.  It was a lot of 'busy' work.

Headers

We had feedback that the header/nav wasn't consistent across the site so I tidied that up, updated the logo from an image to a text-only logotype.  Using the fonts Rena had used when creating the infographic, I created two options for our group to consider and vote on.  We all agreed that the first option looked best.

Structural elements

I set-up the following pages/sections:

• breadcrumbs on all pages
• profile page (editing feature to come later)
• footer on all pages with copyright info (+ footer styles)
• separated the landing page (index.html) where users log-in/sign-up from the home page (home.html) where users browse and select websites to restore
• style log-in/sign-up box on index.html
• moved save/publish to bottom of page (from feedback) on working_panel.html
• created gallery page with lightbox
• used bootstrap's modal to get the lightbox working
• created 'who we are page'
• created a help page and filled with intro content
• created 'getting started' page and filled with dummy content

Home.html/categories

To set-up the categories and websites to choose from on the home page, we looked at a tab layout provided in bootstrap and considered different ways to incorporate images from trove.  Rather than repeating the content within html, I looked into using AngularJS repeating function.  I used stock images from http://www.fillmurray.com/ and http://www.placecage.com/ to populate the content and took a screen recording of the two category tab options to present to the team.

We decided to go with the second option in the video with the long image taking up the width of the container. After we tested this format, I then made a few style changes (3 col layout, tabs more readable).

Angular JS

I created a controller file with all the information to be repeated and then put the div block to be repeated in the html file.

HTML

Controller JS

Week 8: SASS how-to

Initial set-up

1. Download the source files from Bootstrap 
2. Unzip them into the folder where you will be using them (in our case, I have set-up a 'SASS' folder in our git repo)
3. Follow the instructions on tooling set-up on Bootstrap (repeated below)
1. Download and install Node.js
2. Using the command line (Terminal, iTerm, Powershell, what-have-you), install Grunt with npm install -g grunt-cli
3. After a quick refresher in command line, navigate to the Bootstrap folder that you unzipped (for us: 'SASS' as above).  OK, so now you're using the command line and you're in the Bootstrap folder.  If you type ls it should look similar to this:
   
   
4. Install the local dependencies listed in package.json by running npm install
5. Next up is Ruby.  If you are on a mac, you should have it already installed but can check by typing ruby -v into the command line.  If you need to download or update there is info here and here.  But, if you need to install on Windows, we ran into a few problems and used this tutorial from Forward HQ to sort it out.
6. Almost there! Two-parter for Bundler: 1) install in the command line by running gem install bundler and then 2) run bundle (for all the Ruby dependencies you will need).
4. Last step, install SCSS Lint by running gem install scss_lint

Phew, you still with me?  You may (or hopefully not) have any errors.  You may need to prefix the command line with sudo (I know, I know, lots of people say you shouldn't), or might get other random errors (google is your friend), but hopefully you have the things installed.  Now for the fun part :)

Using SASS

In your Bootstrap folder (for our team 'SASS') is a folder called 'scss' which is filled with many, many .scss files.  Being Bootstrap, it is all fairly logically named so it shouldn't be too hard to find any CSS you need to change.  '_variables.scss' has all the colours and typography (amongst other things), etc, etc. Have a look at the SASS documentation for how to use variables, nesting, other syntaxy-things.

Once you've changed the things you need to, how do you get it to be a CSS (and JS) file to use on the website?  Back to the command line!

To compile the CSS/JS files:

1. Using command line, navigate to the bootstrap folder we were working in before.  You may still be there :)  (I'm a broken record but "For our team it is the 'SASS' folder")
2. run grunt dist and fingers crossed, 0 errors!

For our purposes, that's about it but there is more info on grunt commands in the Bootstrap documentation.

Notes for team

• No need to copy/paste files or folders, the CSS and JS import links are now up to date!
• Remember: sync git, make changes, sync git
• The Bootstrap 4 documentation has lots of great info, start with Layout, Content, Components
• Bootstrap also has a slack channel - a great place to go for help!

Week 8: Prep for Part B

Our team met this week to discuss the division of tasks ahead of Part B being due next week.  Part of my task list was having a look at the header again and styling.  We decided as a group not to pursue web components at this time.  There are some cross-browser issues and ultimately it came down to time available vs core functionality we need to do first.  Web components hasn't been ruled out, just put in the 'nice to have' basket.

Part of the feedback we got from the paper prototype we tested last week was to make all our header/nav the same across all pages.  While updating the header (and taking it out of its own HTML import), I had a look at the bootstrap framework we were using  the material design theme.  I decided to ditch the theme in an effort to make the design more our own and instead build on vanilla Bootstrap.

I had a look into the newly released Bootstrap 4 and thought this would be a good option, but it is only available as source files (not pre-compiled code), which means setting up SASS for our project.

Today in our workshop I went through how to set-up SASS with my team and how to edit and compile.  In my next post I will document the how-tos for our team to refer back to if necessary.

I also wrote a set of success criteria for our Part B report based on the interactions we want our users to have with our web app.  We will discuss these as a group next week.

Week 7: Experiences with paper prototype

For the paper prototype this week, we split our group into two groups.  Two people (Felix and Rena) conducted the paper prototype session with classmates (results posted on our blog) and Lyndon and I tested the paper prototypes for the other groups.

Our paper-prototype

We had paper mock-ups of all the main screens in our app, including pop-ups, and a list of tasks we wanted users to complete.  These tasks were designed to test navigation, whether the path needed to complete tasks was clear, and whether the layout of individual elements of complex pages (e.g. the working panel) had a logical layout that made sense to users.

Other groups

It was interesting to see how the other concepts were progressing, but more interesting to observe other prototyping practice and procedure.

A great example was pinboards.  They used a digital version of the paper prototype - it had the same level of interactivity as the paper version but was able to record user's inputs digitally.  Their session was reminiscent of the Digital Prototyping subject many of us are also doing this semester.  They had clear objectives of what they wanted to test (i.e. what questions is the prototype trying to answer) and followed up with a user questionnaire to help quantify and record their results.  They also took the session seriously, they used a script and addressed testers as potential users rather than classmates (i.e. more formally).

There were elements of concepts from some of the other groups that I really struggled understanding, but that is part fo the process of testing, helping to clarify concepts and how users will interact with the project.

Even though I didn't run the paper prototyping session for our group, it was still a worthwhile experience to act as a user for other groups.

Portfolio overview Weeks 1-7

Empathise

• research into target audience (internet and user interview)

Define

• Trove API limitations
• Part A project documentation

Ideate

• Technologies
• use of HTML imports
• Javascript and jQuery to make HTML imports work and interactive
• familiarity with node.js, npm, bower to install jquery, bootstrap and bootstrap themes
• (future - Compass and SASS)

Prototype

• (future - paper prototype this week)
• (future - prototype header/nav with users)

Test

• Not yet

Week 7: HTML imports and setting up CSS

Part of my tasks for this week included looking into web components or HTML imports for our header and starting on our CSS styles.

Header

The idea behind using web component or HTML import for our header was to reduce the amount of code we needed to write and maintain across the site.  Instead of creating the header on one page, copying it to other pages, and then editing every page when there was an update, I decided to look into alternatives.  I had a look at web components (I have used polymer in the past) but also something a bit simpler with HTML imports.

Requirements

• header and nav consistent across every page
• 'active' class needs to be applied to nav of current page
• need a log in/log out view

As most of content is static for this section, I decided to go with HTML imports as I didn't need to create a template for content reuse.  I had a look at the following tutorials: treehouse, html5rocks, sitepoint, webcomponents.org.

Step 1: Create the header 

Create a separate HTML file for the header.  No need for head or body tags, just the parts that relate to the header.  I'll go into more detail about what I put into the header when I talk about styles. I saved this as header.html

Step 2: Import HTML

Import the HTML file into the head of your index page (or page you will use it on)

Step 3: Use the HTML import on your page

This step is quite varied depending on what you want to do and how.  I did this by creating a header section in the body, and then using javascript to target the header and insert header.html. I also added in a line of jQuery to target a particular child in the nav to add the active class.

I haven't added in any script for the login yet but feel it will be easy enough to do once it is ready.

The other thing to note is the HTML imports need to run on a local server when testing (you can't just open the HTML file in your browser).  I found some really good instructions at superuser (see answer by Jake Gould) and installed MAMP.

Styles

Last week at our team meeting, we briefly discussed styles and using material design as a template. I think it is a good idea but am not overly attached if we go in another direction.

I found a version of material design theme for bootstrap which I thought would be good for our project and went down the rabbit hole of installing things.

Material Design for bootstrap http://fezvrasta.github.io/bootstrap-material-design/#getting-started
and demo http://fezvrasta.github.io/bootstrap-material-design/bootstrap-elements.html

I used bower but also had to install Node.js and npm (good overview here), XCode.  I then installed bootstrap and finally material design for bootstrap (and their snackbar).

I'm looking to using SASS for our CSS variables and also installed Compass but haven't got any further on that yet.

I used the material design nav styles straight out of the box.  I'm sure we will change colours and other elements but for the moment the structure is there.

Week 6: Experiences in the Poster & Pitch

Concept, project and design process  

Documentation

Writing up part A document was fairly similar to project documentation I have written for projects at work.  While it seems like a lot of writing and a lot of work, it is an important skill with workplace application.  It is also important because it clarifies a lot of the detail of our project and outlines our plan for how we will turn our concept into an application.

Design thinking

Design thinking last semester taught us a lot of different processes and design techniques.  They were all clearly prescribed and written into our assessment criteria.  The criteria for this project doesn't have the same level of detail and I found myself thinking back to those pieces of assessment as a guideline.  I imagine my design thinking toolbox will get easier to remember the more I use it.

The brief

Student briefs are generally comprised of two elements, the 'client' needs and the assessment needs. One of the problems we have already come across (as detailed in a previous post) is which APIs we will need to use to complete the project.  The 'client' needs is to highlight an area of Trove, the assessment needs is to learn how to use API calls (in particular the Trove API).  It was good to find out that there was a little room to move so that the 'client' need still came first.

Feedback

I did a quick write-up of the feedback we received from our Part A presentation on our team blog. We also went over the feedback in more detail in our Part A document.  The piece of feedback that stood out most to me was around help.  Our intention for our concept was never to provide training but for it to be a tool students could use to practice html skills and in the process learn about web standards and practice validation.  It hadn't occurred to me to provide help information or how our users would go about getting help if they were stuck.  There were many suggestions from class including a discussion board, chat or links.

I recently did the AngularJS track in Codeacademy and really liked the way they did help.  One problem with chat (and other types of help) is that it requires staffing or moderation.  The way codeacademy approach is to leverage existing methods of getting code help and incorporating it in context (i.e. where the student needs it). Here are some screen shots.

 

Even though they use other services to provide the help, they still guide the user there with questions. This is a much better approach than just providing links or a discussion board.  While we can put together information on tags and tag depreciation to get users started, if they are looking for more in-depth help, Stack Overflow would be the best source for this.  The other benefit of this is familiarising users with standard help channels for code that they can use in future for other coding problems.

Other teams

Seeing other teams progress was good inspiration.  It was interesting to see how they had divided the team responsibilities and how technical their projects will be.  I know there will be quite a lot of learning ahead of me to be able to complete the project but I found it encouraging listening to other teams proposals and how they are approaching the different components.  The other concepts were also interesting to see, especially the shipwreck one (Atlantis).  Early Australian shipwrecks was the individual concept I presented and I'm really interested to see how another team will pursue and change the idea. Seeing it progress to a more complete interface from the wireframes I presented was great.

My process

Completing the part A presentation and documentation has reiterated to me the importance of planning in design thinking techniques to a project.  It would be easy to plan a project considering only the end product and the technical needs (i.e. how am I going to make this).  But it is important to plan in time for research, testing and feedback.  I know that there are a lot of design resources (like the d.school) but I also think it might be good for me to keep a record of the different techniques I've used to add to as I progress.

Week 6: 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.

I originally posted this on the Restoring the Web blog.

Week 6: Progress and Part A concept document

The last week or so has been spent concentrating on part A, what was needed for the pitch and the document.  While other team members concentrated on the presentation or further technical or design research, I spent this week considering the project documentaiton and writing up the part A document.

As I read through the document requirements, it seemed to partly reflect project documentation I had previously worked on in my job.  Thinking about how the major project is meant to feed into our portfolio assessment at the end of semester, I had previously only considered the technical elements I could include.  It occurred to me that project management and documentation were also important skills I could gain from this project and add to my portfolio.

While it might have been easier to just answer the couple of dot points required for the document, I thought it would be more useful to use some of my existing project documentation skills and create a more comprehensive document.  My approach was to look at the assessment requirements, look at what I would include for a real project proposal including supporting documentation and then cut or add what we needed for the project.

Matching assessment requirements with project documentation

Document requirements	Project documentation
A survey of relevant background material – which published works does the design build on and how these are related.	Rationale for project. Why are we doing this? What problem are we solving? What does the research say?
Consideration of the intended audience and the experience you want them to have – who are your intended audience, how and in what context do you expect them to interact with your work, and what do you want them to experience as a result.	Outcomes, benefits and impacts. What are the users needs and how will they met? What personal/student benefits are there (learning technical skills).
Project plan including scope for implementation	Scope What is the level of detail? What is in scope and out of scope. Time is fixed, scope is flexible.
Breakdown of milestones with expected tasks & completion times for delivering the project	Task Analysis Could include: Deliverable, Effort, [Must, Should, Could, Won’t], Status, Notes. This might be too much detail, minimum is item, week, and notes.
Breakdown of who in the team will be responsible for tasks and how the workload will be spread across the team.	Proposed staffing Team members including roles and responsibilities
Issues you think that you may encounter in the implementation of your project and suggestions for how to overcome them.	Risk Analysis List risk, impact (1-5), likelihood of risk (1-5), overall risk score(1-25) and mitigation. This might be too much detail, minimum is risk and mitigation.
Response to feedback received in presentation	Include in other areas as needed.

Other project documentation

Other items normally included in project proposals and documentation that may or may not be relevent to this project.

Item	Rationale	Include in Part A
Success criteria Could be as simple as a finished product or include learning outcomes	Is a requirement of Part B documentation, will include then.	No
Assumptions and constraints What box are we working inside (fixed deadline of assessment and semester deadlines). It is assumed that… (through a combination of formal teaching and self-directed learning that team members will be to technically deliver this project).	Probably overkill for our assessment, won't include.	No
Proposed costs Should be nil, expectation of software that each team members will have (mostly freeware)	Not neccessary for this project	No
Communication plan Internal only as there is no real client/audience stakeholders. Include github, drive, plus, facebook etc. Could include tutors, brief (client)??	Will include internal only.  Had listed in in team charter (informal)	Yes
Stakeholder analysis. Include audience in this. What other stakeholders do we have? Could include audience, team members roles, tutors/teaching staff, team members as students (what will i get out of this course - skills). Present as stakeholder interest, expectations, and strategy.	More detail than needed for this project. Combine audience with outcomes, benfits and impacts.	Incorporated in other section
Proposed deliverables  Specific items we will achieve by end of semester Proposed time frame  Time frame for deliverables (milestones)	Not enough items/too early in the project to have separate task analysis, proposed deliverables and proposed time frame.  Combine into one section.	Incorporated in other section

Week 6: 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

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

Week 5: 6 thinking hats activity

For this week's contact session, we ran our concept through the six thinking hats.

From http://johnkapeleris.com/blog/?p=418

Concept:

This project, Web Historians, aims to highlight the importance of archived websites and their potential decay, by providing a solution through an interactive educational experience.  It will use a combination of Trove and Wayback Machine APIs to access archived websites that are then evaluated through a HTML5 validator.  Users will be able to choose websites in a category of interest to them, select a specific site to restore, fix the highlighted problems, and save the completed, restored files for the future. Users will also be able to save their progress by creating an account.

White hat

The information in our concept is the html of archived websites.  The html is validated and is presented to the user as html mark-up, a list of errors, and the displayed website.

Red hat

Our concept has feelings of nostalgia and a respect for history and its preservation.  

Yellow hat

Best case scenario, we complete the app with all the 'if there's time' features, the technical requirements are challenging and we learn a lot but is not beyond our skill level.  The product is useful for our target audience and provides users with a positive experience of html. 

Black hat

There are a lot of technical components and it will be hard to draw a line in the sand for what we deliver.  There are a lot of things I would like to do with the project (like use web components) but not necessary to the delivery of the project.  Worst case scenario is we don't get the minimum requirements over the line and spend too much time in getting individual elements right at the expense of the bigger picture

Green hat

The initial concept is a creative way of using archived content by turning it from something static to something interactive.

Blue hat

The concept seems like a great way to both save historical content and provide a learning tool for students.

Week 5: Trove API limitations

We met today (meeting minutes to follow) to refine our concept and discuss our research so far.

There is an initial problem that we are currently working through regarding the brief requirement of using the Trove API.  During our research we discovered that the trove API does not provide access to the websites listed on the trove website.  We can however, use the Wayback Time-machine API (that Trove refers to) to get this information.

A closer read of what the Trove API can and can't access says:
"Search Trove newspaper articles, lists and works. (Works are made up of “versions”. They can be books, images, maps, music, sound, video, archives, journal articles…) Archived websites, people and organisations have not been included at this point."

We also looked at the search function of the API, and the 'search all' does not include archived websites:
"Search across the records in Trove. The same records you search from the Trove homepage, excluding archived websites, people and organisations."

We are in the process of discussing solutions with our tutors and course coordinator and have contact Trove to see if there is any support or workarounds for accessing archived websites.

Our current suggested fix is to organise the websites accessed via categories (e.g. sport, arts, education, government...) and to illustrate the categories (background, button?) with trove images (related to the category but not the actual websites) which are pulled using the trove API.

We would still need to use the Wayback Time-machine API to get the website details to validate but at least we are not by passing Trove altogether.

One of the risks we discussed today was having to make design decisions based solely on checking off a box in the brief and not on what would make the best product that suits our user needs.  While for the most part these two considerations are not opposites and inform decisions in consort, we are hoping that this problem is not the case of the former.

The core part of the brief that we are answering is to:
"highlight, reveal, [or] focus the content available through Trove ... something that goes beyond the simple search paradigm that they currently have and that sheds light on rarely visited corners of Trove."

We believe our concept definitely does that.  Stay tuned for more concept updates.

UPDATE: The course coordinator emailed back straight away with an OK to go ahead with our proposed suggestions.  We also chatted more with our tutor at the workshop and with the course coordinator after Friday's lecture.

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

Week 5: Refining the target audience

As part of refining the target audience for the web app, I looked into the current IT curriculum for high school students, specifically when and how web languages (HTML and CSS) are taught.

The Australian Curriculum Assessment and Reporting Authority has a draft national curriculum for Information Technology (up to grade 10).  The draft curriculum introduces the concepts of HTML and CSS for grades 7 and 8 (pages 89 and 90).

As I am not a teacher (and have been told the national curriculum is open to interpretation), I  also plan on speaking to an IT teacher to confirm what they actually teach and when.

Even though this forms a minor part of our assessment, I believe having a specific target audience will help us develop a more useful application.  The target audience will also go to forming the basis of any personas we develop.

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

Week 4: Forming Teams

After presenting our concepts, everyone voted on their top 3 preferences for concept/group.  During the following workshop session, we finalised our groups.  Even though my Shipwreck concept received enough votes, I chose to work on another concept:  Restoring the web.  I really liked the problem that it solved.  I will be going into more detail in the near future as our team refines the concept, but here is a brief overview:

Project Description

Restoring the Web is a web-based learning environment aimed at teaching high school students basic web design skills.

Week 4: Design Exploration Concept

This week in class we presented our final Design Exploration Concept and submitted an A3 poster.  Here is my final concept.

Early Australian Shipwrecks (-1900)

Concept

Early Australian Shipwrecks is a web app detailing shipwrecks on the Australian coast up to 1900.  The concept is aimed at people interested in Maritime History, particularly early modern history.

The web app would consist of a marked up Google Map of shipwrecks around the Australian Coast.  When you click on a particular spot.  It brings up historical photos and newspaper articles through the Trove API.

Relevant Information

The Western Australian Museum has a website on its Shipwrecks with an API with relevant data at http://www.museum.wa.gov.au/maritime-archaeology-db/wrecks/map and http://www.museum.wa.gov.au/sandbox/.  This would only be useful for part of the coast.

Wikipedia has a list of Australian Shipwrecks including dates and locations at https://en.wikipedia.org/wiki/List_of_shipwrecks_of_Australia.

The Australian Government also has a page about Early Australian Shipwrecks, which is where the definition of up to 1900 comes from at http://www.australia.gov.au/about-australia/australian-story/early-austn-shipwrecks.

Design Mock-up

Clicking on a particular article will bring up the details within the frame.

Map Research

There are many examples of maps displaying more detailed information on click.  There was a notable style in having a ‘pop-out’ for this information, headed by Google maps and maps made with the Google Maps API.

Map Research

http://googleresearch.blogspot.com.au/2011/05/

make-beautiful-interactive-maps-even.html