Sunshine, seasides, and sandy beaches: that was how I spent my birthday this year. Months of savings took me all the way to Mallorca, where I tried squid for the first time and nursed copious amounts of my new favourite thing: Prosecco Sangria (recipe below). 'Twas absolute bliss.
As I write this, however, I'm sat in a soggy little city at the heart of the West Midlands. A change of scenery, to put it mildly. It was on the train journey back from Manchester Airport that I concocted the idea for this new series. Those of you following me on Twitter will already know what it entails:
Thinking of starting a new series of articles on Dev.to: 'Arrested (Web) Development'. It would look at real life instances of questionable app/site design and discuss the code required to avoid it in future.
Any thoughts on this? Or examples to share?14:20 PM - 31 Aug 2019
My intentions for this series are simply to be kind and constructive. This will not become a platform to put-down other developers or their work. Rather, I want it to be a way of pointing to real-world examples of code and saying: 'I like this but I'd do it differently - and here's how.'
With that in mind, the logical first candidate for this series is: myself.
The fairest way to start this process is to prove that I fully intend to be able to take what I will be 'dishing out', and also to enjoy my most laughable website.
So sit back, relax, and prepare for some good ol' fashioned cringeworthy web design. Courtesy of Yours Truly.
Arrested Web Development: Part 1
My First Website
The scenario was simple: create a website about yourself. My first ever portfolio, if you will. My most extensive use of HTML 'in the real world' at the time had been tinkering with my Tumblr blog's theme.
This was the result:
Now, there are many ways I could tear this website apart (and I have in the subsequent years). However, as promised, I will remain kind and constructive, even to my former self, who I must give some slither of credit for cobbling such a thing together without a lick of technical knowledge to her name.
The first thing I will say is that there are plenty of things going on behind-the-scenes that I'm pleased about.
All the images have alt tags with accessible and helpful image descriptions.
<img src="images/2004-square.jpg" width = "170" height = "170" alt = "a picture of Katie Adams as a young child, wearing aviator glasses and a pearl necklace">
Not only do alt tags keep a website accessible, it can also improve SEO (Search Engine Optimisation).
For some context, this image was taken during a primary school assembly, in which I played the role of a meteorologist. My mother rose to the challenge of dressing me thusly. At the time, I believe it must've been endearing and adorable for the gathered parents and faculty. Now when I do this, however, I'm 'out of date' and 'no longer need to attend school assemblies'.
Back on topic! All of my images resize based on the screen size of the device upon which it is being viewed. I also have multiple versions of my images in varying quality to accommodate for differing screens. The latter is achieved using the picture tag, and the source tag in conjunction with the srcset attribute.
<picture>
<source srcset = "images/2004.jpg" media="(min-width: 990px)">
<source srcset = "images/2004-crop.jpg" media="(min-width: 768px)">
<img src="images/2004-square.jpg" width = "170" height = "170"
alt = "a picture of Katie Adams as a young child, wearing aviator glasses and a pearl necklace">
</picture>
Each image has also been compressed. This improves the loading time of the webpage on mobile phones and other, smaller devices.
Did you know?
The average user will leave your site if it has not loaded within 10-20 seconds. Scarier than this, the first 3 seconds appear to be vital for 40% of users, who will leave if site processing is any longer.
The icons on the site are all SVGs too (yes, including that horrible lightbulb logo). As well as this, the selected option from the navigation bar at the top is clearly highlighted using a box-shadow. Perhaps it is not the most attractive way to highlight it but it cannot be disputed that it's obvious the user is on the 'Home' page.
As a middle point, I did not include Modernizr in my site (as was recommended by the brief). If I'm being brutally honest, it was because I didn't understand how it worked and ran out of time to learn. The feedback I received, however, did note that I'd achieved a similar effect with Javascript.
In my HTML documents, I inserted a p tag noting that JavaScript was turned off. My first line of JavaScript removed this tag from the DOM. Something to consider when it comes to learning new tools/features: you may understand it better than you give yourself credit for.
Now onto the less pleasing things. Hoo boy, where do I begin?
The colour scheme could use a lot of work. In theory, it works well - the white text on the dark green background, for instance, is clear and legible - but any good designer will agree that the nuances of balancing accessibility and attractiveness are not so callously implemented.
Were I to update the site and create something more aesthetically pleasing, the easiest way to do so would be to declare variables in the CSS files. Variables will store any values you give them; in this case, it would be the hex codes for our colour scheme, making any future amendments easy to implement throughout the whole site.
In a trivial project such as this, variables can be declared at the top of the CSS file so changes cascade down.
:root {
--mainColour: #76BC46;
--accentColour: #C14868;
}
.nav {
background-color: var(--mainColour);
}
If you're using other frameworks, however, be sure to find the best method for the project. For example, CSS preprocessors like SASS and SCSS might be worth looking at. I recently utilised SCSS in a VueJS project; it involved creating a variables.scss file and declaring global values inside, like font-family values and hex codes for my colour scheme. When I inevitably wanted to update these at a later date, I was only changing code in one place!
Advice: remain consistent with your variable names to maintain clean code. No swapping from camel case to hyphenated names halfway through a project! You'll thank yourself later.
The nav bar at the top of the webpage is sticky too, which means that when the user scrolls down, it remains at the top of the page. There is plenty of debate on how best to achieve this effect. I settled on using position:fixed on my navigation bar, sectioning off my page content into a div, and lowering it pushing it beneath my navigation bar changing the margin-top value.
It is not the worst way to achieve this effect but there is one that reduces the amount of code rendered.
#navBar
{
position: sticky;
}
Now, it is very easy to use the position:sticky CSS, as I didn't. However, it is not currently as widely-supported. At least, not as much as position:fixed. I will allow people much cleverer than I to debate the best practice here.
There is a lot more that I could delve into for this article, the writing process for which was made much easier by having the developer herself to talk to (though it did earn me a few strange looks at the library). Future articles will be trimmed into bitesize nuggets of knowledge.
If you can suggest alternatives to the advice I've given, or wish to contribute to this personal roasting session, leave me some feedback! It can only make me better.
And lastly, as promised:
Prosecco Sangria Ingredients
- Prosecco
- Orange Juice
- Fanta
- Fresh Fruit
- Ice
Don't ask me for the proportions. I still haven't figured them out and fear I never will.
Oldest comments (2)
I love the idea! It also makes me realize just how much code I've written and lost track of completely. I wish I'd done better about preserving some of that stuff if for no other reason than to look back on (and hopefully see how I've improved?).
I love looking (and cringing) at my old projects. On particularly poor days, it can really help curb the imposter syndrome. ❤️ See what you can dig up! You'd be surprised to see how far you've come. 😁