Coding / Programming Videos

Post your favorite coding videos and share them with others!

How i go about my work – William Iehl – Medium

Source link

There is a process we go through when building websites or components of a website. I would like to make that process a more conscious and consistent step of my work and so will write down what goes on in my mind when I build the components that make up these websites. I also would like to share these ideas as I believe they can only be beneficial to the readers.

I believe this process can be summarized with a rather simple idea. A website’s job is to facilitate a business’ job.

I have broken down this idea into 3 categories:
The business: whom the website/component is built for.
The editors: those who will fill up the website using these components.
The devs: present and future devs that will also work on the project.

The business

This is the website’s goals, its audience and how they will interact with said website.

Nowadays, with more than 50% of a websites audience being on mobile, being responsive is a given. We don’t even need to think about that. But I think it’s worth remembering why we build responsive websites. We do it because it improves user experience on mobile. And better user experience improves the website’s success according to whatever metrics the business rates that success on. There are other aspects of a website that improve user experience that I like to keep in mind while I work.

The first thing a user experiences when going to a website is the time it takes for it to load. This is also the first thing I am concerned about at the start of a project. Slow load speed has a big impact on bounce rate and general frustration. This is especially true and important when looking at mobile load speed where download speed and CPU speed is much slower and where data consumption is also a concern. There is a plethora of resources online that you can have a look at to get the specifics but this is a good place to start: Why performance matters

Accessibility is also important and not only for disabled people. Think of how hard it is to read text on your phone on a sunny day. Power users (I am one of them) also enjoy using their keyboard for navigation. And, of course, disabled people may want to use your website. It is, therefore, important for me to ensure that all areas of the website are accessible via keyboard navigation in a predictable way and that contrast ratio is high enough for readable content. Again, keyboard navigation, skip-nav, and color contrast are good places to start.

And then there is generic user experiences questions that I often ask myself; Should this whole component be clickable or just the CTA? Should I ajax in the data or trigger a navigation? Should I store the data in local-storage? And many others. All in all I just like to spend some time pondering how I want the components to behave and to be used before touching my keyboard.

The editors

How easy is it to implement the different parts of the website (mainly for content websites).

This is not the place where I have the most impact as a front-end but it still is worth keeping in mind how editors will interact with the site (within the CMS). My guideline here is; how much work can I remove from their hands?

Is there a way to automate data input via APIs? If so I would always suggest going that way, especially if this is a redundant task. If some configs never change then it may be worth hiding them away.

The devs

This will determine how easy it is to make non-breaking changes.

Clients projects are never really finished, are they? Module specs will change, new ones will be built. Writing clear, understandable code is very important to me. Maintainability ensures that future you or the devs to come after you will be able to quickly get the job done.

I often time sit there, looking at my screen, wondering if there is a better way to write that piece of code. Usually it simply requires extracting the bit of functionality and putting it inside a function. More complex tasks may require things like a pub-sub. Compare these two examples:

// Preferred
const increment = x => x + 1;
const temp = [1, 2, 3, 4, 5].map(increment);
// Not preferred
const temp = [1, 2, 3, 4, 5];
for(let i = 0; i < temp.length; i++) {
temp[i] += 1;

Or these two:

// Preferred
const increment = x => x + 1;
const temp = [1, 2, 3, 4, 5].map(increment);
// Not Preferred
const temp = [1, 2, 3, 4, 5].map(x => x + 1);

I hope we can all agree that in both cases solution one is more readable and the most maintainable. Solution one also has the added benefit of creating a reusable increment function.

Documentations also are a big help when it comes to making changes that won’t break the current behavior of the module. Writing down the specs of that module ensures that the devs that come after us know what how that module is meant to behave.

Javascript the Good Parts and Javascript Design Patterns are my personal recommendations.


Programming is a mean to an end. This is something that is clear to me and so, when I write my code, my main concern are the above mentioned ones. This has led me to always look for a better way to do things and in turn became a framework for learning and expending my abilities as a front-end developer.

Thank you for reading.

Source link


Leave a Reply

Please Login to comment
Notify of
Translate »