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)