Obligatory (my editor made me add it) Disclaimer đ
All scenarios presented in this article are intended purely for humorous purposes and reflect the personal opinions of the author. The intention is not to offend anyone or specifically target real situations or projects. Any resemblance to actual events or projects is purely coincidental.
Intro
Are you familiar with that feeling when you come across a design that immediately triggers a cascade of expletives in your mind, making you question every decision that brought you to that particular moment? No? Well, consider yourself fortunate. Certain design practices have the uncanny ability to evoke such reactions from front-end developers. Regrettably, encountering one of these design challenges in a project often implies a high likelihood of encountering more. In this article, we will delve into the realm of designs that pose significant obstacles during development. Brace yourself for an insightful journey into the world of frustrating design choices. Let's embark on this adventure together!
Diagonal lines
Let's dive into a common predicament that many web developers face, regardless of their experience level. CSS, known for its love affair with rectangles, tends to make life difficult when it comes to anything else. You can squeeze out some rounded corners if you're lucky, but anything beyond that requires delving into the realm of hacky solutions. And that's exactly what we're about to explore. Picture this: a well-intentioned designer decides to spice things up with a "dynamic" and "interesting" divider between different sections of a website.
There are numerous approaches to tackle this problem, but my personal preference would be to employ an SVG triangle, as demonstrated in the illustration below. Implementing this solution isn't overly complicated, but how should it behave when scaling the browser? This crucial consideration should be in every designer's mind when creating any application element. Should the triangle maintain a fixed height or scale down accordingly? How will it affect the elements positioned below it? These are the pivotal questions that must be addressed in the design notes if the designer chooses to incorporate this element.
Floating elements
I canât count how many times I had to deal with this one. Picture this scenario: the designer sees a bit of empty space on the page and starts thinking: âHow can I make it more interesting?â, after exactly 0.01 seconds he figures it out: âLetâs add some floaty stuff and make the devs hate me!â.
I hate them so much đ„Č Those things are impossible to make them responsive. Usually, I just implement them on desktops, pray that they work on all the desktop screen sizes and completely remove them on mobile and tablets.
Inconsistent components
Here is another scenario. Your team has dedicated an entire week to diligently implementing the sleek and modern form components meticulously crafted by your designer. As the next sprint kicks off, you eagerly await the designs for a new contact page, only to be greeted by a jarring sight. The designer, seemingly in a quest for uniqueness, has opted for completely different components on this particular page. Faced with this situation, you have two possible routes to take:
- Take a break to cry in the toilet and implement a second set of components to confuse the rest of the devs working on the project
- Try to persuade the designer to use the already implemented elements, fail at it and finally go with route no. 1
Untranslatable design
Here's another familiar scenario that frontend developers often encounter. Imagine you're working on a multilingual page, and everything seems to be going smoothly with the design in the English version. However, as soon as you delve into different languages, the trouble begins to rear its head. Take a glance at the design above: a visually appealing offset image positioned behind a text box. Yet, when you switch to a language with more condensed text, such as Chinese, or one with wider text, like German, things start to appear a bit off.
So, how can we address this issue effectively? Well, the key here is open communication and collaboration with the designer. It's essential to consult with them and discuss potential solutions. And here's the twist: we might just need to make those delightful language-specific adjustments. Oh, the joy of adding complexity and messiness to our code! Who needs streamlined and clean code anyway, when we can have a tangled web of exceptions? However, by actively collaborating with the designer, we can find the right balance between accommodating different languages and maintaining code cleanliness. Together, we can navigate these challenges and ensure that the design looks fantastic, regardless of the language used.
Ending notes
One of the fundamental aspects of working with designers is creating a collaborative environment and ensuring a seamless exchange of ideas and experiences. As a programmer involved in a project, it's crucial to actively participate in the design process. By providing thoughtful notes and explaining your reasoning behind them, you can save valuable time by avoiding the need for extensive revisions or complicated design implementations. It's important to acknowledge that as a developer, you may not always have the final say in design decisions. After all, applications are built for users, not for developers. Keeping this perspective in mind will help foster a user-centric approach and ensure the ultimate success of the project. Remember, effective collaboration and embracing the user's perspective are key ingredients for creating remarkable applications!
The example design used in this article is available here: Figma Design. Send it to all your designer friends to either teach them something or just have a laugh! Those are only some of the annoying elements to code. Are you interested in learning more? Let me know in the comments because believe me, I have a lot more of themâŠ
Top comments (15)
Happens to me regularly that a design works for desktop and few mobile devices and does not scale to anything in between.
Or the designer just shared some examples of the happy flow, no page loading or errors of any kind are expected on those applications..
Yeah, especially larger screens or tablets are the problem for me. Most of the time I just have to improvise. Loaders are also rarely seen, but fortunately usually I do get error states in the designs.
I consider myself a designer, and I think you should level up your development skills! Also, change your mindset, my friend. If diagonal lines and simple :before and :after elements leave you puzzled, then beware! The AI will snatch your job faster than you thinkâprobably in two or three years, or maybe even quicker. Keep up, mate!
I think you may have missed the point of this article, my friend! Iâve highlighted that there are many approaches to addressing the diagonal separator issue, as it is quite common. Personally, I am not particularly fond of using :before and :after in that case, as they feel a bit hacky to me. The main idea is that designers can significantly simplify development by avoiding some practices. By achieving easier and faster development, the client's costs can be minimized. As for my job, I must say that I feel quite secure. Thank you for your concern, and I hope you have a pleasant day!
i feel pseudo elements are a great fit for this use case, since the diagonals arenât semantically important. đ€·ââïž who cares đ
good article and sense of humor⊠thanks for highlighting the importance of intra-team comms.
Pseudo elements, in my opinion, are also a good solution, especially when dealing with a wave-like shape. If it's just a straight, non-horizontal line, then I would use CSS clip-path
I understood the idea of your article - designers and developers need to communicate with each other. And the communication must be reasonable, so that people can learn and grow. As for untranslatable design and the inconsistency of elements, those are clearly problems faced by beginner designers. Let me tell you something, everyone has to start somewhere and learn, so don't mock and assume that you know better.
Considering that you struggle with basic CSS, you're probably a complete beginner yourself. When two beginners come together and one mocks the other, the result is always bad.
As for the notion that offering a lower price to the client through simpler and faster development is rubbish. Maximize your profit and maximize it in long term. Always give your best and try different things, so that all team members evolve. If you only stick to boxes and circles in CSS, you'll keep scraping pennies.
Saw that way too often đ€Ł
But yes in all case, communication is key, and as early as possible.
My other "fights" is overly complex feature that will take 5 months to build and doesn't make sense to be split in smaller chunk as everything is designed to fit with everything else...
Spend a month arguing something won't work due to conflicting concepts, being talked down to, as if you are missing some secret insight.
Spend two weeks hacking your way implementing two disjoint parts which will never fit together.
Spend couple of more weeks finding a semi working way to build adapter and build the two.
Get feedback from users that they are really confused.
Throw away one of the concepts.
Try to see your brain by rolling your eyes while listening that this is how "agile" works, and we needed to do all this extra shit to discover what some people have been saying from day one
ĐĄongratulations đ„ł! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up đ
Programmer vs Graphic Designer | Coder vs Designer - YouTube
Subscribe to @SarwarSateer #shorts #designer #programmer
Inconsistent components can be a real headache for developers, but finding ways to collaborate and adapt can lead to remarkable applications.
Thankfully, in my case, usually it is an honest mistake on the designer side. If you tell them that we can keep the app consistent by using our pre-made components, they are fine with it. The trouble begins when they do it on purpose...
Or sometimes you are just given a desktop design and then you have to build the mobile site as well but then they complain when they don't look the same .
"Programmers, beware!" or "Designers Attack!" both seem like reasonable titles for an indie video game.
I know that's not what the article is about.