Cover photo by mohamed abdelghaffar from Pexels
1. Not Designing for Mobile First
You know what’s difficult? Taking a complex, intricate design that looks pixel-perfect on a 24 inch monitor and trying to shove it on a 300-pixel-wide screen.
How do you decide what to cut? How do you ensure the most important info is still above the fold? You go back in time and design the mobile view first.
If you’re not optimizing your design for mobile, you’re likely serving a subpar experience for a majority of your users.
Start with a simple prototype that gives users easy access to the most important information on the page. Add design elements as you scale for bigger devices.
If you’re not a designer, take advantage of tools like Bootstrap.
2. Not Being Consistent
Consistency helps users know what to expect from your website and helps teach them how to use it. Being inconsistent can lead to frustration, despair and high bounce rates.
Inconsistent Links
You should treat links of the same type the same. If one of your external links opens in a new window, they should all open in a new window. (Don’t forget to think about users using screen readers. Check out these suggestions on making target=”_blank” more accessible)
This includes links to media! Don't indicate a link opens a PDF in one place and neglect to add that info everywhere.
Inconsistent Style / Design
While it's more than likely that you'll have multiple page templates and designs, users shouldn't think they've navigated to a new website or caught you in the middle of a theme update when the open a new page.
You should have your basic theme colors and include a header, navigation and footer where appropriate. (E.g. If you're building a JavaScript SPA browser game, you probably don't need a footer.)
It can be tempting to use an entire palette of colors and six different Google fonts, but less is...way less confusing. Define your CSS styles for font families, colors and sizes and use them.
3. Hardcoding Full Paths
Stop. It. Do you enjoy doing things multiple times? Does it bring you joy to install a plugin that literally only does one thing that you could’ve done yourself? Stop hardcoding full paths!
I cannot express to you how many times I’ve had someone ask me to troubleshoot a website issue that turned out to be a hardcoded full path for an image source attribute or external stylesheet.
Clients change their minds about domain names, production and development domains differ. Using partial paths gives you the freedom to make changes and push to production without having to go back and look for references to a previous domain.
4. Not Using Image Alt Tags
Seriously, it’s 2021. Adding alt tags to images is literally the most basic thing we can do to make a website or app more accessible. This is especially true for any images that contain text. The goal is to express the function, meaning or information portrayed by the image to all users.
Check out this alt decision tree for help deciding how to make images in specific contexts more accessible.
5. Being Div-Happy
Listen, we all love divs. They're fun little boxes that you can use for almost anything. But just because you can doesn't mean you should.
We should try to use divs only when there are no more appropriate - read semantic - elements for the job. You could use a div for your menu and everything would work fine. But using a <nav> element helps anyone using a screen-reader and the non-humans (i.e. search engines) understand the meaning behind your code. This isn't just a box with links in it, it's a navigation elements that holds a menu that will guide me through the rest of the site.
Instead of using a div to...
Place text under an image ... use <figure> and <figcaption>
Make a link that performs an action (e.g. uses JavaScript to open a modal or page through a multi-page form) look like a button ... use <button>
Group the main part of your page ... use <main>
What are your web development bad habits? Which ones do you come across most often?
Top comments (49)
Do not use a button just to "style a link". Buttons are intended to perform actions on the current page.
Side note: also please don't use anchor elements which have
onclickevent handlers and a placeholderhref(e.g.#) -- use a button instead.I wasn’t very clear with this. Often I see people using divs with an internal link where they should probably use a button element. For example, opening modals, paging through multi-page forms, etc.
this does not depend on the place you put'em but the context where the items are and the most important is what the user expect to happen. Most UX studies reveal that there are many differences depending on the professional market it's web app is working, cultural history, target of the web app and so.
If your users expect a button (layout) which triggers an action (logic) that according to standards or for convenience needs to be an "a" tag then use an "a" tag and add the proper styles to make it look like a button instead of being stubborn and use a button (which merely purpose is to trigger a "submit" in its context).
If we start talking about A11Y or this kind of things that nobody takes care of excepting when you need to build an application for people with some particular disability (usually never) then it's another story and we can discuss with that in mind.
Being cruel to people isn't a good look, and certainly doesn't make a positive contribution to this community. Folx are here to learn, not to exchange vitriol.
Yeah, that I completely agree with. :)
Because they're crappy coders but amazing at code exercises.
Another thing would be to stop worrying about using the latest tech, developers get so caught up not wanting to use jquery cause its becoming out dated and want to use Vue yet they have no experience using Vue and there's projects that need to be done in company, learn tech in your own time but as for bringing new tech into the business don't worry about it unless they are paying u time and research on it, cause by the time you learn Vue, react, angular etc, another tech would come out, it all does the same job at the end of the day, just another boring old website, if u are so desperate in making sure u are relevant in the market, learn VR or machine learning etc, something that's different, cause learning Web frameworks would only lead to new frameworks and then more and then more, does the same job, get it done
I agree, if the only reason you’re learning a new framework is because you think you should, you’re on the wrong path. BUT if you really enjoy learning new ones, I say go for it. Just learn it well before jumping to the next one.
Disagree with both comments. Learning new tech to be more productive and keep company applications at the leading edge of functionality which is a competitive advantage. Old tech is getting impossible to recruit for. Experienced Devs have retired and new Devs aren't interested in being onboarded, otherwise they would all be learning COBOL.
That’s a good point. However, I do think trying to learn EVERY new framework to stay competitive isn’t the best course of action. If you’re learning specific new frameworks used by companies or sectors or cities you’re interested in, I get it.
as with all things, balance is important. can't lean in either direction too heavily
I am a div lover 😅
I am also a little div crazy. 🙈
I found this post really helpful especially the 4th part. Thanks For Posting
I too loved this post
I guess this link would also help you @krishan111 searchenginejournal.com/10-importa...
Designing a website mobile first is definitely a fabulous idea. It is a lot easier to create a website that way. It is a nice challenge to be able to design something that looks appealing to the eye on a small mobile screen.
Do not be like me , I use ( text-align ) to center everything in a div container (e.g image, text buttons ) .
Instead , you should use the right property ( display: flex ;
Align-item: center
Justify-content: center
Speaking more as a user, I hate mobile first. Too often it turns into "mobile only". I have the space, use it to full advantage. Just looking at this page, there's a huge amount of white space on the sides, why? There's close to a thousand px of whitespace if I keep things maximized, and it's not like I'm using a 4K screen.
The DIV-Happy one is like my most-used bad habit. I do design stuff for mobile view, but after I've gotten it down in a computer's view first. If I make a navbar, I'll design what it looks like on a computer first and then add media queries to make it responsive.
Nice article.
One question I have is that is a link styled to look like a button (the link has no onclick but just goes to a new different page) a bad habit ? If so I'd like to learn why
Because a button is expected to trigger an action within the context of the page. A link is a navigation tool. The confusion often comes from the action (e.g. form submit) also has the side effect of a navigation.
I don’t think so! I often create a btn class that gives links the padding, background color and box-shadow to look like a physical button. It would be using a div with an a tag where you SHOULD use a button element.
I found this article really interesting, and it touches on how screenreaders interact differently with links and buttons: css-tricks.com/use-button-element/
Nice. thanks a lot. I wanted to be sure I wasn't doing the wrong thing all along
Also I learnt a ton from the article about buttons.
Of course! I am growing and learning right there with you.
Great article thanks
I'm a beginner but still I wanna say "mobile first approach sucks"
Interesting! Do you mean you don’t like the process or that you don’t like the concept? What’s you’re preferred approach?
Such a wonderful day it is thanks for replying.
Generally I tend to make desktop version first and afterwards I add or remove sections accordingly.
The approach to make a mobile first version seems pretty decent when it comes to using only floats . But grids makes the process way swift and easy.
I totally get it! I think flexbox makes responsive design a lot easier.
Hi i'm gonna made some puns from a side and to the other:
half of the issues you mentioned are designers concern and not from developer side. Consistent design and Mobile first is something that needs to be achieved on design side, then a layout builder (that does not need to be a programmer) mocks it with html and CSS (on the perfect world the designer would itself provide the HTML and CSS being a Web Designer instead shitty .psd files or similar things that graphic designers does when working on a job that it's over its skills -> digital responsive design, but this is another story).
The rest of "bad habits" are simplified to: use HTML elements for and how it's intended for. Apart from that there are tones of opinionated stuff around front-end layout and styling which, being html and css not programming languages they are interpreter-dependant so... maybe i'm getting old but if something fits for your needs, use it, just make sure you understood what you are using and what is intended for.
True, some are related to design. When working on a small team, for small businesses, or for personal projects (so from my experience), you tend to find yourself doing double duty as developer and designer.
I tend to be pretty opinionated in my personal blog posts 😂. This one was inspired by a particularly frustrating experience with a very pretty website that didn't work very well. It's not meant to an end-all-by-all guide, but rather some things to think about that I come across often.
I know your situation and I've lived it myself but... Then, to avoid this kind of issues you'll need to dig deeper in Color theory, Shape and Form, digital composition and a pair more of subjects if you want to properly design a good product and even that, you'll make mistakes because it's a completely different job even being related...
just try to focus in what it serves you and always apply the KISS principle so you don't get burnt down by tedious processes and the feeling that you can't get further :)
Really interesting, I'll for sure use semantic elements as well in the future, they seem to make the code even more readable 😄
EVERY is a bit of a strawman, the argument was about someone introducing a web framework. It mentions Vue, which is actually one of the easiest to progressively introduce into a web page.
What do you guys think about anchors vs. buttons in SPA navigation.
i.e. if in a todo-list, you hover over the todo and a "view details" link appears. This will take you to a separate page, but still inside that tab / SPA.
Should this be a button or anchor?
Look at the user concepts. If it LOOKS like a panel opened in the list (even if the URL changed) then use a button (style). If it looks like a new page use a link style. But most of all, be consistent.
One of the hardest things for newbie.... Experience talking here.... Been there done all the mistakes....
Some comments may only be visible to logged-in visitors. Sign in to view all comments.