In this episode Mike and Matt discuss what it's like to take on your first website contract as a complete beginner web developer, focusing on a small business website refresh.

Segment 1 - Gathering Requirements

We’ve talked about requirements a few times but this whole conversation will be very specific to a typical first site that a developer will have to do for their first project.
So in this scenario a small business call Happy Coffee has approached you with a request for their old site to be updated. The site is from the early 2000 and is very old, not responsive and has outdated information about their business.
They would like you to update their online presence with the new web standards and make their site look more modern.
Your job here is to figure out what the clients preferences are and if they align with your vision for the new site
Ask them to send you some sites of the their competitors they like and to highlight the specific sections that appeal to them
Ask them about specific features that you know are common to these kinds of ‘business card/online presence’ type sites.
- Contact forms
- Large cover images
- Services offered
- Map of the location
- Hours of operation
- Small “Our Story” section
- Photo Gallery
It’s also important to gauge if they have content for you or if you will need to generate content yourself, whether that is images or text.
This will give you a great starting point for either creating a static site from scratch or choosing a template to fill in and adjust
Now usually during the more general portion of this process you’ll also be discussing pricing but I’m going to intentionally leave that part out as it’s a whole other can of worms and can be discussed in a separate episode. But usually for a first project, my advice is to be reasonable with your pricing, don’t do it for free but know that this is a stepping stone and the client is taking as much of a risk on you as you are sacrificing price wise for the client.

Segment 2 - Design and Iteration

Generally when someone wants a basic website, especially when it’s a small business, they’ll want to keep the budget low, cutting down on hours is probably one of the easiest ways to lower the price for a customer, having a basic design allows you to cut down some hours while maintaining quality
Often times on larger websites clients will want a wireframe, as well as a prototype, or a fully done-up visual design before they’ll approve the look and you can start coding
When it comes to smaller projects we’ll generally skip a lot of the designing procedure and rely solely on wireframes for a visual aid
As a brief aside, even some of our larger customers accept wireframes as the basis of their design in order to keep costs down and get the project up and running as quickly as possible
Typically we’ll make 3-4 different wireframe layouts based on what the customer has requested, often times we’ll get a few reference sites (as Mike mentioned) from them during the gathering requirements stage of our interaction to speed up our wireframe creation
After showing off the various wireframe designs, we’ll get the client to choose their favourite one, get general feedback if they’re not happy with any of them, or get them to mix-and-match pieces of the wireframes together (slider from design 1, footer from design 3, etc.)
This part of the procedure can take anywhere from a few hours, to over a week depending on how involved your client would like to be in the design - sometimes the design will flip-flop between a few options before finally landing on the one that will be put into production, so this step requires patience
One thing of note, all clients are different, but from our experience if you’re struggling with the basics of choosing one of the designs that you made (ie the client doesn’t like any of them) sometimes you need to have a discussion with them to reiterate what their goals are to ensure that you’re on the same page (ie you might be focusing on showing off their photos, while they just want people to see the phone number and call the office)
Luckily with simple designs the selection procedure is often the least painful and you’ll be off to the development stage in no time

Segment 3 - Development

Since this is a simple static site development is fairly straight forward
There are a few choices you will be faced with
- Go with a template
- Create a static site from scratch
If time allows I would recommend creating a site from scratch as you will learn the basics a lot better, and give yourself a better understanding of CSS, HTML and JS
The workflow I do when creating a site is I first create a skeleton file structure with the typical css and js and img folders. Depending on how you were taught you can either do this manually or with webpack and babel. I’ll focus more on just a simple file structure now but don’t be afraid to use the tools you were taught if you are comfortable with them.
When creating the folder structure create all the necessary files you’ll need to start the site
- Index.html
- Main.css
- Main.js
- mailer.php
For the html I like to create the structure of the entire site (assuming it’s a one page site like this one)
- I try to keep it as basic as possible with the fewest container divs as I can
- Hopefully you have all the content you need for the site already but if you don’t make sure to use lorem ipsum or placeholder images so you can just quickly replace the when you have them
For css my recommendation is to start with a flexbox layout, as it’s supported on most browser version and will not require you to create backwards compatibility/fall back css
- Remember to make the site responsive, combining flexbox features and media queries makes this relatively simple for a small site such a this
For js all you’ll really have to handle is the contact form ajax call. So organize a ajax object based on your input fields and create a ajax request to your php contact form to start the mailer process
Mailer.php will then handle creating the email and sending it.
Make sure to do some testing on any device you can get your hands on. Especially smaller phones and tablets as those can be weird resolutions you might have missed. If you have a few friends that can test out the site for you that's always suggested as getting a fresh look on something can be hugely beneficial. They will be able to pick out any glaring errors if they exist right away.
It is also a good idea to set yourself up for future revisions, so if the client states that they will be updating the logo every season or year create a simple file structure and file naming scheme without your application that will make it easy for you to update these files in the future

Segment 4 - Deployment

Often times when a customer is just refreshing their design, they’ll want to keep the same setup that they have - same host, domain name, etc. which makes your setup rather easy
Assuming they want their setup the same, you can typically ask for FTP access and then upload your new site design, this is of course assuming you want to go live right away
One important thing of note, is that if you’re replacing an existing website, it’s a good idea to take a backup of it. All setups are different, but in general, creating a new folder called “OLD” and putting the old site files in there is a good way to ensure you don’t delete something vital, or have the site go down for long in the event that something goes wrong with your new design
If something does go wrong with the new design, you can always revert your changes to the old design by copying those “OLD” files back to where they were to lessen the amount of downtime a user might see
In addition, a site owner may want to keep the old site around for people to use for a few weeks before migrating over to the new one, or they may want to get customer feedback on the new design before fully committing and taking the OLD site offline
Every situation is different when it comes to deployment - always remember to never delete something that you can’t get back easily - back it up, even if the changes you’re inputting seem trivial

Web News - Android Desktop & Chrome OS

Software ecosystems are meant to bridge the gap between different pieces of hardware - computer (desktop/laptop), tablet, phone, smartwatch
These ecosystems bring the notifications and other features that we all enjoy, cross-platform so that we can continue to enjoy them at our desk or on the go
In general, a lot of these ecosystems are bridging a literal OS gap where people use multiple operating systems in a single device setup such as Windows, Android, Wear OS
Recently the Pixel Slate was released bringing a “laptop-like” tablet that can run Android apps on top of Chrome OS, this type of device is basically a hardware bridge of sorts that is trying to bring you the portability of a tablet, the versatility of using familiar Android apps from your phone, while still having the ability to be used as a traditional laptop - assuming you buy a type-cover for it
This begs the question, where does Chrome OS fit into the equation, when it leverages the use of Android apps?
Should we just have an Android version that is “computer friendly” or goes into a “computer mode” of sorts (ie Samsung Dex)?
Is this rather strange hardware/software bridge pointing towards a future of one OS on multiple devices?

You can find us on...

Facebook | Twitter | Instagram

RSS | Spotify | Reddit

Medium | YouTube | GitHub

Patreon

Your First Website Contract 01:12:05 Share

HTML All The Things - Web Development, Web Design, Small Business

Shownotes Transcript

Your First Website Contract