I am a web developer and a consumer who has a simple philosophy for both roles.
Lets stop making things that only “look like they work” and instead build things that “work like they look”.
I started learning to code in 2001 pumping out my first !DOCTYPE declaration in an HTML class using just notepad. Back then Dreamweaver was still owned by Macromedia and WordPress did not exist.
A few years later I was faced with my first professional code challenge: Can you make our website somehow change size to work on all monitors? It was before CSS3 responsive design existed so I decided to use percentages (and allot of JS) to change the width of website elements.
This was the first time I had encountered a very real problem that I would face for the rest of my career as a developer.
The designer sent over a file – of course it only looked like it worked, it would not actually work as a website.
Back then (around 2003) on that first freelance job either I did not know about “web-standards” or perhaps it was not yet a hot topic at the W3C. I intuitively knew that the files I was getting from graphic designers were ‘not good’ for the web, but I could not quite put my finger on exactly why that was… at least not yet.
I suspected (and still do) that a combination of print deign philosophy and a lack of understanding of code were major culprits. Based on that theory I eventually began to inquire of designers, politely, the following:
- Is there a reason you decided to make this font larger than that one?
- Usual answer: “It looks good, attracts the attention of the eye.”
- Correct answer: “Because its an H1 tag and has priority for SEO and Keyword strategy, everything on this page is directly related to that line of text.”
- Is there a reason you decided to crop this image and place it here in this particular blog post?
- Usual answer: “I saw it on another website and thought it made sense.”
- Correct answer: “Because its an inline featured image and will be used in XML or OG:Metta feeds, it must appear on the page and the page title will be merged with the image element title attribute for sharing purposes.”
- Is there a reason you decided to make the main content this exact pixel size?
- Usual answer: “I centered it based on my screen and negative space.”
- Correct answer: “Because responsive design dictates a 12 column grid as logical, you can ignore my exact pixel dimensions and take any liberty needed to ensure that aspect ratio is preserved in the process of testing mobile devices.”
- Is there a reason these two buttons look different from the other links?
- Usual answer: “I just wanted to bring attention to it, but its not actually a button, users are not supposed to click on it.”
- Correct answer: “Yes, its the CTA and clicking it creates a lead in our CRM, therefore the UX communicates that clearly. In addition we will be using heat maps and funnel tracking with goal conversions to determine how users got here and which checkout button they prefer to click; hence the two buttons are part of an A/B test.”
No designer ever gave the correct answer. Not ever – and I know why.
Since it was not my job to be a ‘yes-man’ I was usually able to gain respect using patience, perseverance, tenacity, logic and of course; proof.
In the past I resorted to using the W3C Validator and the old “Semantic Data Checker” to prove why web-standards are important. I needed an elegant way to communicate why doing design after planning saves allot of money and produces a better final product.
My solution eventually evolved into this: A Light Project Specification Phase
I believe in Modern Web Standards and Product Responsibility, which is why I seek to join the Toptal Web developers community.
I believe a good website will work like it looks instead of just “look like it works“… It is my job to build things that not only work, but work well.
~Christian W. Zagarskas