After the comments on Lobste.rs the first introductory part (Comps) and the last sections (Pain; Cure) of this article were rewritten. The rest, the case study was untouched.
The original article is still available here.
I'm both a designer and developer primarily focusing on my own projects. Occasionally I do freelancing for clients and often times I'm hired at the development phase.
This means I'm receiving comps from designers either coming from Photoshop or Sketch, wrapped or not into Zeplin. I find these comps unusable.
I have to slice, calculate, convert pixels to elastic measures; have to figure out the responsive grid structure, the responsive typography, all the reusable design elements — code them — and start adding all the exceptions every comp comes with — blowing the source code and the project.
I've been long waiting for a case study which speaks for itself. Let's see it.
It sounds simple: list the latest posts on the homepage in a responsive way. On large screens there should be 8 posts displayed 4 in a row, on medium screens 6 posts / 3 in a row, on tablet 4 posts / 2 in a row, on mobile 2 posts each on its own row.
The comps are blurred out to protect the designer and the company. The black and red boxes are ad placeholders, and, there are gray vertical lines between columns the blurred screenshots can't show.
The comps were replicated using mockups. You can check it live on Codepen to better sense the task.
Since the designer doesn't code ...
The designer doesn't knows content cannot be get in a responsive way only displayed in a responsive way.
... and creates comps which makes the developer to fetch all 8 posts on the back-end and hide some of them on the front-end — such a performance waste — put to be supported by those devices which have the poorest resources.
The designer doesn't knows the CSS Grid specification
The designer doesn't knows exceptions are painful and bloat the source code
... and inserts an ad between the rows. The ad has different dimension and positioning which breaks the grid. An exception has to be added to support this design decision bloating the code during development time and later during maintenance.
If the designer were coding the following design decisions were taken:
Do not hide posts on smaller screens — wrap them into a navigation element. This way the resources used to get all posts on the back-end would have been not wasted on the front-end.
Forget the vertical column separator lines. They can't be implemented with current best practices and they need workaround. Let form follow function even if function is coding standards.
Put that ad elsewhere. Combined with 2.) it's dangerous. Moving out of the grid will spare around half of development time and budget.
With these practical design decisions the implementation would have been easy: use the CSS Grid. Time spent would be from minutes to around half an hour.
With vertical borders the CSS Grid technique — used across the site up until now — cannot be re-used. A research has to be done to see if the specification added the grid gap styling feature recently, or if there is a polyfill, or a nice workaround.
It turned out only a workaround exists which won't fully solve the problem since the suggested bordering is ... complicated: it applies to middle columns treating columns at the edge as exceptions.
Time spent with research and workarounds: around an hour.
To implement the comp a loop has to be created over grid elements adding border only where necessary. For that I've already had a component built on Flexbox. Importing, adjusting to this current project took around half an hour. If it had to be written from scratch it would take at least an hour in plus.
Inserting the ad between the posts is way more complicated. It's about adding exceptions to an existing well working code. The back-end code displaying a post list has to be modified to insert the ad; on the front-end the grid has to be re-drawn and re-bordered.
The final front-end code is so ugly it is worth a look. 1
Time spent: around an hour.
|Practical implementation||30||Using the CSS Grid|
|Vertical borders — research||60||Wasted. Only a nasty hack found|
|Vertical borders — implementation||30||+60 mins if the Flexbox grid component were not be already written|
|Ad between rows||60||The result is a very ugly patch over a well written code|
|New code||Lines of code (LOC/SLOC)||Time spent (mins)|
|post-list-with-ad.php||37 / 32||15|
|flexbox-grid mixin||62 / 54||60|
|responsive-flexbox-grid mixin||48 / 39||15|
|flexbox-grid-borders mixin||30 / 26||15|
|latest-posts mixin new code||15 / 15||15|
|latest-posts--regrid-for-ad mixin||108 / 97||45|
|Total||300 / 263||165|
|Post list with ad||Added||It might be not re-used again|
|Flexbox grid||Added||It might be not re-used again|
|Responsive flexbox grid||Added||It might be not re-used again|
|Responsive grid||Skipped||It is not re-used now while it is re-used across the entire site|
This project has a good few dozens of sections like this Latest posts depicted above. More than half of them is designed in the same unimplementable way. Or, in the same costly implementable way.
Remember: on this component alone we've spent at least 2.5-3 hours instead of half an hour. Yes,
5 times or 500% more than usual.
That's immense. It all adds up during development time, and, rolls out as a technical debt for the future.
Big / well organized / informed teams might be lucky. They've probably enrolled a perfect designer ←→ developer communication strategy to avoid this kind of extra cost and technical debt.
Small teams can do three things:
Acknowledge the problem.
Find a designer who code — there are plenty out there. Or
Involve the developer as early as possible in the design process to help the designer with feasibility tips.