One of the biggest problems I have experienced in learning to code is translating my knowledge to something physical. Over the years I have seen many developers ask the question of “I’ve learnt HTML/CSS, what now?”. The answer is more often than not:
“Build something”
So, I built something. It’s a personal website/portfolio and I want to take you through how I built it. Although my goal is to show others how they can build a website, it’s also a great way of documenting my process and progress.
Have an idea
Your website doesn’t need to be special. It also doesn’t need to get you favourites or tweets or fist bumps or 1,000 visits a day. It just needs to be something you’re going to enjoy.
I’m sure that no-one sits down and immediately conjures up an amazing idea. Most of my ideas have come to me when I’m falling asleep or taking a shower. I can think of something exciting one day but not have another idea for a week or two.
Don’t try to force yourself to have an idea. It doesn’t work like that and leads to a lot of frustration. Start simple. Build for yourself. Often I’ll see something in the world and say to myself “Huh, I think I could build my own version that’s better suited to me”. Or “I’d like a tool that does this boring task for me, so I’ll try to build it myself”. That right there is a brilliant place to start.
I have a long list of ideas. None of them award-winning but all something that interests me. If something comes to you, write it down and when you’ve got the time to build something you can take a look at all the fun ideas you came up with.
Sketch your idea
All you need is a pen and a piece of paper. Before starting my portfolio I sketched out the basics and adding some notes on what colours and fonts I’d like to use.
My finished product look quite different to my sketch in the end, but it was a great starting point. I also sketched many versions of the website so don’t be afraid if your final product looks nothing like what you started with.
Mock it up in Photoshop
After sketching my idea I took to Photoshop and laid out my site, according to the sketch I had done. Some people design in Photoshop before progressing to code, some people prefer to go straight to the code and design in the browser. Do what feels best for you.
Set up your project
I like to keep all my projects in the same folder on my desktop. I created a new folder within my projects folder and set up the following within it:
The index.html stays in the top of the directory (the root). The other most important files live within my “assets” folder. This separates my CSS, JavaScript and images into their own folders to keep it nice and organised.
Lay out your HTML
Without HTML, there is no website. It contains all the information you will display on your site, whereas CSS just makes things look better.
I started by laying out the containers of each part of my website: the header, the main content and the about article. I didn’t know exactly what content I would display and went through several changes before settling. That’s okay, just make sure to add in some fake content so you can see how it will all look when it comes to styling with CSS.
Choosing Fonts and Colours
In my sketch I wrote down a few colours that I wanted to use in this project. Most came from my twitter profile, which in turn were colours that I matched with my avatar (the main image in my site header).
There are some great tools out there for finding and creating colour schemes, like Colour and Coolors. I decided to keep this site simple and clean, with one or two accent colours.
I also picked two fonts from Google Fonts. These are free to use and easy to include within your project. I wanted to use a clear sans-serif font Open Sans for the body text and subheadings and a serif font Roboto Slab for the larger text like the large quote and the “About” heading.
I like light fonts but it’s important not to have a font with too low a font-weight (boldness) as it can make your text unreadable. It’s also important not to use too many fonts as it becomes too frantic and messy, as well as increasing the time your site will take to load. You want your reader to absorb what you’re trying to say, not the fifteen fonts you used in a single paragraph if they decided to wait for them to load rather than violently exit your page.
Styling with CSS
The first thing I did was add normalize.css to my CSS folder and link to it in my HTML.
Building a website in one browser (e.g. Chrome) does in no way mean it will look the same in another browser (e.g. Internet Explorer). Normalize.css aims to fix this as much as possible by providing your site with a sort of “reset”. It allows your site to display well across browsers and I believe it’s crucial to developing a site that looks good across many different browsers.
I then set my own styling with the most important styles first, like the fonts and font sizes for the body and the headers. I then proceeded to work down the page and style each element in turn as best as I could without jumping around the page too much.
Accessibility
When building anything you should always think about your user. It is important that any app, product, leaflet, letter, poster, website, bench, shop or anything else in the world can be used by as many people as possible. To understand why sites need to be accessible, check out “Why Bother with Accessibility?” by Laura Kalbag.
Making my site accessible was fairly simple. I added ARIA landmark roles in the appropriate places to denote what type of content it was to screenreaders (used by people with poor or no vision). I ensured that all links were accessible using the keyboard and were focused well in CSS.
When it came to the social icons at the bottom of the page, I added in text denoting what website each icon linked to. I hid it from the browser but made sure it was visible by screen readers.
A few people patted me the back for thinking about accessibility when building my site. Although that makes me feel proud, it shows that accessibility is not thought about enough if I can be praised for giving it the attention it deserves. If you’d like some awesome resources on making accessible websites then check out A11Y Project.
Testing
As I mentioned before, it’s rare that a website will look the same in every browser and on every device. Testing can be time-consuming and even tricky depending on the resources at your disposable, but it’s incredibly important. Test now so that you don’t find out your website is broken when it is already there for the world to see.
If you’d like a quick illustration on why it’s important that you test across mutliple devices and browsers, below you will find the stats from people who visited my website over the last 24 hours. Some came from within an app using Safari (26%), some came from Android (3%), some came from Internet Explorer (2%) and others from Chrome (39%) and Opera (2%). It is important these different users have a good experience on your website, so do test in as much as different situtations as you can.
I tested my website using the latest versions of the following browsers: Chrome, Firefox, Opera, Safari and Internet Explorer. It is easy to downloaded the first four. If you’re not on a Windows machine it’s a little harder to test on IE. To test on IE you can load a version of Windows onto your Mac using Virtual Box. Microsoft themselves have made a website showing you how to do this at no cost: Modern IE.
There are tools out there that will take screenshots of your site in a tonne of browsers and devices and send them back to you. I asked some friends what they used for testing and you can check out their answers here. Modern IE will also take screenshots of your site free of charge in nine widely used browsers/devices.
It’s awesome if you have unlimited access to a multitude of devices that can access the web but you probably don’t. I have access to an iPad, a Samsung Galaxy S3 and an old iPod Touch, I am hardly covering the entire population with these.
If you’re on a Mac then you can use XCode to load up an iOS Emulator which allows you to test on several iPhone and iPad versions. For a rudimentary approach you can also resize your browser to a mobile device width but this isn’t really a foolproof alternative.
Other things I tested were whether the site was readable, well contrasted, valid and accessible.
My last point about testing is this: You should be testing your website all along the development process. That way you can fix bugs before you’re at the end of your project, before it gets too frustrating and you potentially make it worse. I have experienced the situation in which a developer didn’t think to test their product until the end. It was hours of painful repetitive testing for me whilst they tried to fix the tonne of bugs I was reporting to them. It was such a mess and would have been so much calmer if they had tested their site throughout.
Share it, have your friends look it over
So I’ve just built a website and I learnt a lot of stuff by building it. Despite this, I know there are things I could have done better. So I’m sharing my code with you in the hopes that not only you will learn from it, you’ll also be able to point out my mistakes!
You can find the code for my personal site here and you can view the final site here. Please let me know if you have found something that doesn’t work, or something that I could do better!
I hope this helped! Don’t take my process as gospel. I’m sure it will change over time and even if it doesn’t, many people build websites in different ways.
Charlotte Spencer's Blog 