CTEC3905 Past Student Work

Screenshots of overall design

Here are some examples of student work from the previous two years, with a rough idea of how they were marked overall.

Please note that this only shows how the pages look, it doesn't show any animations or hover effects, and most of all it does not show the quality of the code. So some of the pages are marked higher or lower overall perhaps than you might expect due to underlying issues with the code. This includes for example API calls that bring in content dynamically from external sources which might not be clear from simply looking at the final design of the website.

1. HTML and CSS Code Quality

1.1. Valid HTML5 and CSS3 source code throughout

Try and fix any errors and address warnings that are raised by the validator. Mostly this will catch serious syntax errors but it also points the way to good practice in general.

For the HTML validation, errors must be avoided completely to get "partially" or "fully addressed". Warnings are less severe but you should still try to address them.

Depending on the amount of CSS errors you have you might still get "partially addressed" if they are minor (or for example are to do with browser compatibility). Again warnings are less severe but you should still try to address them.

Validation is your friend! Use it often!

Often, programmer's text editors will highlight syntax errors as shown below (either by squiggly underline or by a change in colouring (e.g. white text instead of green). This can help you debug your code.

note the missing closing > bracket of the p tag on line 96, and the typo on line 99 showing an opening t tag instead of a p tag

the validation for the HTML code shown just now highlights several issues, for instance a warning about the section missing a heading which can be ignored, but also error 2 which indicates to the missing bracket on line 96, error 4 points to the erroneous t tag, the other errors here are actually propagation errors

note the typo on line 58, the missing semi-colon on line 64, and the extra closing brace on line 70

the validation results here highlight very precisely were those errors are and even gives an idea of how to fix them

1.2. Consistent code nesting and indentation (2 spaces is industry-standard)

If you are unsure about your indentation practice you can use a beautifier to indent your code for you (yes, we are essentially giving away marks here)! See links below:

• codebeautify.org
• beautifier.io

1.3. Separate .css and .js files (e.g. no "style=" or "onclick" in HTML)

This is largely marked on amount of inline logic in the HTML. So for instance one occurance of "onclick" or a "width" declaration inside an <img> tag would be considered "partially addressed". Several instances of this would be "not addressed" and of course no inline styles or scripts would be "fully addressed".

The examples below are taken out of context of the whole repository so I can't really show the grading element for these fairly. Suffice to say inline styles and scripts like these should not happen ever.

note missing video tag instead of div, inline styles ("align" marked in red), spaces between attributes and values (e.g. class = "VideoEmbed" instead of class="VideoEmbed"), inline JS (onclick instead of eventListener)

note excessive use of onclick, inline styles, the div with class "tab" should simply be a <nav> tag, the section with class "mainbody" should be a <main> tag

note the setting of background colour inline and also the div with class "Header" should be a <header> tag, and the <b> tag should be a <strong> tag instead

note line 51 shows a syntax error of a tag without a name just a class, indentation is bad, and contains inline CSS styles for the image

1.4. Use of CSS3 features e.g. flexbox, animations, CSS grid

This largely depends on the number and quality of examples found in the code. There isn't a specific number of features you have to include, but it should cover at least one of the examples above well. For example you can use advanced flexbox to create multi-column layouts that adapt to screen-size, or you add a few different animations to your site, or you layout the page with grids that adapt to screen size too.

1.5. Tidy file and folder organisation with lower-case names

This should be fairly self-explanatory. Keep file and folder names lower-case and don't include any spaces or underscores (use hyphens if necessary). We normally expect you to keep your images, CSS, and JS files in a separate folder each. Don't include any unused files you used during development. Clean the repository for your final commit. Your main homepage must be called "index.html". This is necessary for GitHub Pages to work and most web servers too.

2. JavaScript, APIs & JSON

Please note that you should only use native code e.g. no JQuery, Bootstrap, etc. External assets such as images, FontAwesome icons and Google fonts are acceptable.

2.1. No JavaScript errors in the browser console

This largely depends on the number of instances found in the console and the severity of the errors. Errors that break functionality are worse than warnings for example.

It may be a good idea to include console.log() statements for debugging purposes. Remove them if things work out, or if not then leave them in to show your attempt of fixing them. Please also note that you should remove any console.log() statements before your site goes live as it is considered bad practice.

Warnings can often be ignored as they're browser related, e.g. ad-block.

2.2. Use of JavaScript for DOM manipulation and/or interaction

This largely depends on how JS was used. The point of this crtieria is for you to use JS to manipluate some content on the HTML page, for instance feedback of user input from a form (e.g. user enters name, name gets printed into a paragraph on the page). An alert box does not really count as "DOM manipulation" so would get "not addressed".

This also includes "tabbed" layouts that dynamically show or hide content and hamburger mobile menus that are shown or hidden via JS.

Please not that PHP scripts for contact forms are unmarked - we will ignore them completely. It's not going to affect your mark to have a non-functional contact form.

2.3. ES6 syntax: e.g. "let" and "const" over "var", template literals, arrow functions

2.4. Use of JavaScript to handle data (e.g. JSON from an external API)

As mentioned briefly above in point 2.2 using a Google map in not technically handling JSON data via an API, so this might only get you "partially addressed" (depends on how much you customise the map for instance).

There are many services out there with APIs related to images, news, weather, videos, Wikipedia, translations, maps, etc.

The use of the Google Fonts API or embedded YouTube videos, or Twitter "widgets" do not count towards this point.

Although Google maps is used in the examples below it is not compulsory.

2.5. DRY code e.g. no repeated similar functions without parameters

Code can generally be divided into two categories: DRY and WET code. DRY stands for Don't Repeat Yourself and WET stands for Write Everything Twice. Industry best practice suggests you should use a DRY coding style instead of a WET one, as this is much more efficient and easier to debug and maintain.

you can clearly see the amount of duplication here that could have been prevented by writing a function with parameters

again, this could have easily been turned into a simple function. create two variables that hold the lists of images and modals, then loop through the images one by one and change the style for the corresponding modal

This second example above could be rewritten easily as such:

or even better (because style.display essentially adds an inline style to the HTML rather than a style rule to the CSS stylesheet) replace the "modals[i]" line with:

and add this rule to the stylesheet:

This easily reduces down the roughly 200 lines of code the student had previously (only a tiny proportion is shown in the screenshot above) to 7 or 8.

3. Responsiveness, Accessibility and Interaction

3.1. Responsive at any size with mobile-first CSS breakpoints

The starter code we have provided you with contains two breakpoints (@media rules in the CSS) in a mobile first style. This means that any styles for mobile go above (and outside of) the two media queries, any styles for tablet size devices should go into the first media query and styles for desktop monitors should go into the bottom media query.

Most websites will not need any more breakpoints unless you have a very complex laypout. In fact you may not need the intermediary "tablet" size breakpoint even.

There is no set number of breakpoints but we recommend either 1 or 2. For any specific extra breakpoints please explain in a code comment why they are needed.

3.2. Well-ordered information architecture, ease of navigation at all sizes

This largely refers to the site navigation, i.e. the menu. This needs to adjust to different screen sizes, for instance by having a "hamburger" menu on mobile, and has to be well organised.

3.3. Web accessibility (e.g. HTML5 semantic elements, "alt" attributes, heading structure, etc.)

3.4. Coherence of overall design - colour, content, styles, etc.

3.5. CSS layout of HTML5 elements e.g. no tables

this is a goldmine: blockquote is used for centering an image, empty paragraphs with just a space ( ) inside are used for spacing, and also: the images folder has a capital "I", the image name has spaces in it, and there's an inline script ("onmouseover")

4. GIT & GitHub

4.1. Source code and live site on GitHub Pages

This should be "fully addressed" for all of you if you've managed to set up your GitHub Classroom repo properly and enables GitHub Pages in the settings. This is really only for some cases were students simply haven't followed these instructions at all and end up submitting a zip file via email (yes, we've seen it all).

4.2. Use of GIT branches for feature development

Branches are slightly more advanced feature of git. They should normally be used for feature development (e.g. a new JavaScript feature, or a re-design half way through).

Here's some excellent resources on git branches:

• Atlassian Git Branch Tutorial
• Git Branching - Branches in a Nutshell

4.3. Regular commits, not all last few days

There isn't a set amount of commits you have to create in order to get "partially" or "fully addressed" here. It is possible to get full marks for this component if you have ten excellent commits, with very good commit messages spread out over a decent period to show progress.

We might "checkout" individual commits to verify progress if there are concerns about the integrity of the code (i.e. suspected plagiarism).

Here's an excellent resource on this topic in general:

• Commit Often, Perfect Later, Publish Once: Git Best Practices

4.4. Brief, informative commit messages

Look at the examples above to get an idea of what would be considered bad, good, and excellent commit messages.

Normally, you should use imperative mood to write your messages, for example "add readme file" instead of "added readme file". Read this excellent resource on this if you'd like to know more:

• How to Write a Git Commit Message

4.5. Basic readme.md file with references in Markdown format

The readme ("readme.md" or "README.md") should contain some key information about your repository and website in valid Markdown text.

Mini Markdown Cheatsheet:

    # Heading 1
    ## Heading 2, etc
    [link text](https://link.url)
    ![image alt text](folder/image.png)
    - bullet 1
    - bullet 2, etc
    1. numbered item 1
    2. numbered item 2, etc
    

The content of your readme is very individual and depends on your site, the issues you've faced, etc. But at the very least you should include references here to any external sources you've used (e.g. images, text content, embeded videos, API code, code examples from CodePen, W3Schools or other sources, etc.) Note that this does not have to be in Harvard referencing format but could simply be a url with a short description of what it was used for, for example:

    # References
    - image gallery code adapted from [here](https://link.url)
    - Google maps code adapted from [here](https://link.url)
    

The beauty of GitHub is that if your readme file is named and formatted correctly (and at the root of your repo, i.e. not in a sub-directory) then GitHub will automatically display it nicely on your repo website as shown below.

General Issues

really no need to add a class to the table data tags, just style them directly

note the strange indentation (probably tabs rather than spaces used), the amount of redundant code (e.g. the menu div is completely unnecessary) often the HTML tag can be styled directly without a class or id. no real need to make the menu a <ul> either.

note inconsistent indentation, the inline styles at the top, inline script in the middle (although fairly well commented), and the <br> tags at the bottom for layout (you should use CSS to pad things out)

note the "max-width" and "width" inline styles at the top, and inline script below (although fairly well commented)

note the vendor prefixes (-webkit, -moz, -ms) which are not needed since flexbox and transitions are supported in all browsers