ahandrewh teaches IAT-339web design & development

P3: Portfolio (due November 28)

This document is a draft

Until October 31As a result it may still change up until October 31.

Introduction

You will be developing a portfolio website. This website must be fully functional and ready for use as a portfolio.

P3: Portfolio is worth 30% of your final grade.

I already have a portfolio

If you already have a portfolio we will need to know of its existence to avoid any potential plagiarism. Please email Andrew with a link to the existing portfolio by November 7.

If you are happy with your existing portfolio and do not want to build a new one, you can organize with Andrew an alternative final project. This must be done before November 7.

Portfolio content requirements

The portfolio will require the following content:

The list above is not a list of 'pages' required. All this content could appear in one URL or multiple URLs across a website.

Framework and other code

You are allowed to use frameworks (ie. Bootstraps, Foundation) and libraries to make working on the site easier, but the final design must be your own work. When in doubt, or email Andrew as plagiarism can warrant more serious repercussions.

Remember that this project is an opportunity to showcase you. Working with someone else's design or creating a website similar to others doesn't show off you. Students who heavily rely on a framework for the design of their portfolio have not historically done well in this project.

Weekly instructions

This project spans multiple weeks. Please read the weekly instructions carefully.

From October 31 to November 7

This week is about defining you and your content for the portfolio.

  1. Draft your ethos. To start doing so answer these questions in words or sketches:
    • What is the job you want?
    • What are the qualifications for this job?
    • What kind of verbal language would people hiring for this job expect?
    • What kind of visual language would people hiring for this job expect?
    • How does your experience prepare you for this job?
    • What characteristics do you have that make you well suited for the job?
  2. Based on your answers to the questions above, select a prior project and complete a process analysis which helps support why you are qualified for the job. The process analysis should:
    • Show your ability to think through a problem from start to finish.
    • Show how you iterate over the course of a project.
    • Have accompanying artifacts — images, video, audio — that support what the text is saying.
    • Be approximately 250-300 words in length.
  3. Write a draft bio using no more than 100 word to introduce yourself.
  4. Setup a git repository for the project.
Bring to your November 7 class

A URL to your materials or your git repository containing:

  • Responses to the ethos draft questions.
  • An initial process analysis.
  • A draft bio.

We will chat about your deliverables in-class.

From November 7 to November 14

This week is for taking the content and building it into an initial website.

  1. Based on the feedback in the class, integrate the process analysis and bio into an initial portfolio site. Keep in mind:
    • Start responsive, don't leave responsiveness until last.
    • Can we clearly identify your ethos through the visual and textual language being presented?
    • Focus on layout and branding first, flashy effects later.
    • Ensure that if working with a framework, it does not dictate your design.
  2. Push your changes to your git repository.
  3. Please upload your portfolio to your SFU filespace.
Bring to your November 14 class

A URL to your initial portfolio site. We will chat about your deliverables in-class.

From November 14 to November 21

This week is for further improving your portfolio and ensuring it works across browsers and devices.

  1. Based on feedback from the class, continue to work on and improve your portfolio.
  2. Test on multiple browsers:
  3. Test on Multiple devices:
    • Laptop,
    • desktop,
    • tablet,
    • smartphone,
    • TV,
    • gaming console,
    • etc. (use whatever is available to you)
  4. Test at multiple resolutions:
    • 320 pixels wide
    • 1280 pixels wide
    • 1280 pixels wide by 320 pixels tall
    • etc. (use any resolutions you can)
  5. Push your changes to your git repository.
  6. Please upload your portfolio to your SFU filespace.

From November 21 to November 28

Work with feedback you receive in the class to revise your portfolio website. Ensure you continue testing it on multiple browsers and devices.

Grading rubric

Your project will be graded on the following criteria:

Grading rubric for P3: Portfolio.
A B C D

Code (10 points):

  • Is HTML mark-up semantically appropriate?
  • Does CSS use responsive units? Are they applied appropriately?
  • Is JS functionality accessible through appropriate application of ARIA?
  • Is the website still usable without JS?
  • Does the code follow modern best practices as taught?
  • Are there any HTML and CSS errors identified by a validator?
  • Is the file and folder structure organized and web appropriate?
  • Used git for the project?
  • Is speed optimization used?
  • There is little to no room for improving the semantics of the HTML.
  • The CSS is using responsive units appropriately for sizing fonts and adjusting media queries.
  • Added JS functionality is made accessible through appropriate application of ARIA.
  • The website is still usable without JS.
  • The code follows modern best practices as taught or discovered.
  • The code is valid HTML5 and CSS3.
  • File/folder structure is clean and web appropriate.
  • Used git through-out the project.
  • Compression (of code and image), request reduction and lazy loading are used to increase page-loading efficiency.
  • Semantic HTML elements are used appropriately but there are missed opportunites for improving the semantics.
  • The CSS is using responsive units appropriately for sizing fonts and adjusting media queries.
  • Added JS functionality is made accessible through appropriate application of ARIA.
  • The website is still usable without JS.
  • There are up to 4 minor errors (things we have not taught you) in following modern best practices.
  • The code is valid HTML5 and CSS3.
  • File/folder structure is clean and web appropriate.
  • Used git through-out the project.
  • Compression (of code and image) as well as request reduction are used to increase page-loading efficiency.
  • There is a semantically inappropriate use of HTML elements.
  • The CSS is using responsive units appropriately for sizing fonts but not for adjusting media queries.
  • Added JS functionality makes no use of ARIA to ensure accessibility.
  • The website is still usable without JS.
  • There is 1 major error (a thing we have taught you directly) and up to 4 minor errors in following modern best practices.
  • The code is valid HTML5 and CSS3.
  • There are some minor concerns with the cleanliness or web appropriateness of the file and folder structure.
  • Used git through-out the project.
  • Compression (of code or image) is used to increase page-loading efficiency.
  • There is a semantically inappropriate use of HTML elements or old non-semantic elements continue to be used.
  • There is little use of responsive units in the CSS for sizing fonts and adjusting media queries.
  • The website is still usable without JS.
  • There are up to 4 major errors (things we have taught you directly) and up to 8 minor errors in following modern best practices.
  • The code is not valid HTML5 or CSS3.
  • There are major concerns with the cleanliness or web appropriateness of the file and folder structure.
  • Little to no use of git.
  • Little to no work to increase page-loading efficiency.

Design (10 points):

  • Does the website look unique or distinct?
  • Does the website look cohesive and consistent?
  • Does the website make effective use of space at different browser sizes?
  • Does the website use responsive images to enhance responsive experience?
  • Is it clear what is an interactive element (and not)?
  • Do interactive elements provide clear feedback on mouse hover and keyboard focus?
  • The website looks uniquely branded and communicates the individual's type of work through visuals or interaction.
  • The website uses a consistent visual language.
  • The website reorganizes effectively to make use of space in the browser window.
  • The website uses responsive images to support a variety of devices and display resolutions.
  • It is easy to distinguish between interactive and non-interactive elements.
  • Interactive elements clearly change visual states on mouse hover and keyboard focus.
  • The website looks uniquely branded.
  • The website uses a consistent visual language.
  • The website reorganizes at different window sizes, but could use the space more effectively.
  • The website does not use responsive images.
  • It is easy to distinguish between interactive and non-interactive elements.
  • Interactive elements clearly change visual states on mouse hover, but not keyboard focus.
  • The website looks similar to other portfolios of a similar job type.
  • The website uses a consistent visual language.
  • The website reorganizes at different window sizes, but could use the space more effectively.
  • The website does not use responsive images.
  • It is somewhat difficult to distinguish between interactive and non-interactive elements.
  • Interactive elements clearly change visual states on mouse hover, but not keyboard focus.
  • The website looks similar to other portfolios of a similar job type.
  • The website does not use a consistent visual language.
  • The website does not reorganize at different window sizes and/or a horizontal scrollbar appears at some browser sizes.
  • The website does not use responsive images.
  • It is somewhat difficult to distinguish between interactive and non-interactive elements.
  • Interactive elements do clearly change visual states on mouse hover, but not keyboard focus.

Content (10 points):

  • Are there different and effective routes to find projects?
  • Is labelling of navigation and headings logical for the user?
  • Is all the required project content included?
  • Bio describes clearly 'what they do'?
  • Does the portfolio illustrate what they do?
  • Does the process analysis explain what they did individually?
  • Does the process analysis show why this process was followed?
  • Does the process analysis speak to the images or other artifacts used?
  • Does the process analysis show what they learned?
  • The user can find projects through different types of navigation - i.e. on-page listings of projects and links embedded in the bio.
  • All labelling of navigation and headings is clear and logical for the user.
  • All required project content is included.
  • Bio describes clearly what they do, and their employment interests.
  • The process analysis connects clearly to an aspect of what they do.
  • The process analysis explains clearly what they did individually.
  • The process analysis shows the thinking used, it is clear why the project had the resulting outcome.
  • The process analysis clearly explains how images or other artifacts (video, audio, code snippets, etc) are connected to the process.
  • The process analysis clearly illustrates something learned specific to the project as an individual.
  • The user can find projects through different types of navigation - i.e. on-page listings of projects and links embedded in the bio.
  • Most of the labelling of navigation and headings is clear and logical for the user.
  • All required project content is included.
  • Bio describes clearly what they do.
  • The process analysis connects clearly to an aspect of what they do.
  • The process analysis explains clearly what they did individually.
  • The process analysis shows the thinking used.
  • The process analysis uses captions to explain how images or other artifacts (video, audio, code snippets, etc) are connected to the process.
  • The process analysis clearly illustrates something learned specific to the project.
  • The user can find projects through different types of navigation - i.e. on-page listings of projects and links embedded in the bio.
  • Some of the labelling of navigation and headings is clear and logical for the user.
  • Most of the required project content is included.
  • The bio is unclear in what they do or provides lots of unrelated details.
  • The process analysis somewhat conveys what they do.
  • The process analysis explains some pieces that were done individually, but others that were done as a team.
  • The process analysis shows some of the thinking used.
  • The process analysis uses images or other artifacts (video, audio, code snippets, etc) to illustrate the process.
  • The process analysis illustrates general takeaways.
  • The user can find projects through mostly one type of navigation.
  • Little of the labelling of navigation and headings is clear and logical for the user.
  • Some of the required project content is included.
  • The bio is unclear in what they do and provides lots of unrelated details.
  • The process analysis does not convey what they do.
  • The process analysis only explains what was done as a team.
  • The process analysis focuses on what was done.
  • The process analysis uses no images or other artifacts to illustrate the process.
  • The process analysis provides little to no takeaways from the project.

Final submission requirements (November 28)

The final submission for P3 is:

All are submitted as a URL (or set of URLs) to Canvas.

Your project submission is due to Canvas before your November 28 lecture.

Please make sure double-check all your submitted files and URLs to ensure they can be opened. We want to avoid late or problematic submission penalties whenever possible.