===
Module leader:
General queries and admin issues:
Graeme Stuart: [email protected]
===
COVID-19 has meant all teaching is now online
- Fania and Graeme will be present in one of the 14 BlackBoard Online Classroom sessions during the usual lab times
- Please be patient with emails, we have many queries across modules!
- Double-check your website in various browsers (NOT IE!) to be sure everything works
Please attend online, even briefly, if only to email later with specifics
if you really need to—only one or two issues at a time, please!
===
For those who turn up(!) these have been very useful
See Graeme's announcement to choose a lab time - there are 14 online labs each week, which you can join from the Online Classroom link
===
Make sure:
- you read the marking criteria (BlackBoard: Assessment) on Blackboard and examples
- you push all files to your GitHub classroom repo
- your
index.html
file is in the root directory index.html
and folders are all lower-case
We will mark your code from GitHub classroom
NOT from your personal GitHub account.
You can check this:
your GitHub Classroom repo name starts with
"CTEC3905/website-" e.g.
github.com/CTEC3905/website-myRandomNameHere
QUALITY NOT QUANTITY
There's no definite limit to features, commits, JavaScript functions/functionality.
So use what will show your knowledge and demonstrate "USUP":
- Understanding of HTML, CSS and JavaScript
- Structure, validity and tidiness of code
- Usability of website (PARC, IA)—ask people!
- Progression of development (commits, branches)
…in a coherent, error-free, validated, well-organised site.
Keep your code comments brief and meaningful. Although, when well-written…
the code is the comment
See The Pragmatic Programmer,
—Andrew Hunt and David Thomas
===
You can use Markdown, a simple ‘language’ that ensures semantic markup in a plain-text format, for your readme file
You can use GitHub-flavoured Markdown (see guide)
for your readme.md file
You can use an image or two, for example to:
- illustrate something you solved
- show how you improved an earlier version
resize images and screenshots before adding them to your website
or to your readme.md file
This Markdown creates an HTML "img" tag:
![alt text](images/myimage.png)
- Don't credit images
- Do reference code you've used
- Don't write an essay
- Do briefly explain your thinking
References can just be a link—no need for Harvard format.
This Markdown will create an HTML link ("a" tag):
[Some tutorial](https://sometutorial.com/)
===
- use branches for developing a feature
- branches preserve the "master" branch from harm
- develop the new feature on the branch until it works
- push the branch to the GitHub classroom
- you can then merge the branch back into "master"
git branch
shows all branches with a*
on the current one
Here's how to use git branch…
- save all the files in your master branch
git add .
andgit commit -m "message here"
- now create and checkout a new branch with:
git checkout -b my-new-branch
- work on the code, check it works
- then push the new branch with:
git push -u origin my-new-branch
- finally:
git checkout master
git merge my-new-branch
git add .
thengit commit -m "merge new branch"
If you have uncommitted changes on master there will be conflicts. These are marked by GIT like this:
<<<<<< HEAD
new code (keep)
======
old code (delete if you’re sure)
>>>>>> master
- edit files and remove the old code
- all good?
git add .
and commit!
===
Many frameworks promised to deliver this idea (e.g. Meteor, Ionic, Appcelerator Titanium, Sencha, React Native (Adobe PhoneGap is a distribution of Apache's Cordova)
Increased browser functionality, advances in JavaScript, HTML and CSS drove a significant shift towards using web technologies for mobile development, so Google introduced a concept…
Progressive Web Apps (PWAs), which took off quickly!
When dealing with clients… by far the most common thing I’ve noticed is: they do not care if it’s HTML5 or native. In fact, despite explanation, they rarely ever understand the difference. Deliver what they want and they will be happy no matter what you make it with.
7 Lessons from 3 Years of HTML5 Mobile App Dev (2017)
HTML5/CSS/JS can access/do many things e.g.
location, camera, push messages, file access…
see What Web Can Do Today
- “Progressive Web Apps vs. native”… the wrong question…
- Progressive Web Apps vs Native Apps
- Progressive Web Apps: When Short on Resources
===
Can give users an app-like experience from a SPA website
- Save to home screen with an icon
- Will now show among open apps
- Can increasingly access device hardware
- Are based on the open web
- By-pass the App Store, Google Play
- Are securely served (SSL—free SSL with LetsEncrypt)
progressive web apps start mobile-freindly, go much further
Are enabled by—and compete with—native Apple and Google apps
have code telling the device they’re PROGRESSIVE, so are “installed” when saved to the home screen. This means they’re full screen, and stay in open apps separate from the browser.
The fact that web apps are on the open web allows developers to publish anything they want (and compete with anyone they want) and charge for their own in-app purchases or even “downloads,” without paying fees to Apple or Google…
…developers can create an app as a side project and actually “ship” it.
Installable Web Apps May Be the Future of the Open Web
—Drew Thomas, 2014.
- single-screen navigation (a SPA or JavaScript navigation)
- fully responsive design (see RWD best practices)
- various icons and splash screen graphics
- wipe cookies and local data if required
- some understanding of offline storage
- use HTTPS and and SSL certificate (LetsEncrypt is free)
- a valid manifest file (replaces
<meta>
tags) for offline use - server config code for the manifest (e.g. Apache)
- service workers: cache assets, offline data and push notifications
- read up on IndexedDB and an offline data comparison
Your First Progressive Web App
===
COVID-19 is a serious threat to people of all ages
Remember to help and protect your older relatives and friends, and anyone with a pre-existing condition