REVOLD— Join Web Design Revolution
TL;DR:
I’m going to develop the best open-source tools for responsive web design. But it’s impossible without you — let me know how your dream ones should look like! Web: Revold.app.
Chapters
- Intro
- Web Design — Classic approach
- 9 Circles of Hell
- 9 Spheres of Heaven
- Next steps
- Join The Revolution!
It’s a little bit long. Make a cup of coffee. I’ll wait here for you.
Imagine a world without Sketch or Adobe XD.
Without HTML and CSS.
There’s only a blank canvas, you and your creativity.
You want to be new da Vinci.
You want to create your magnum opus. Your monalisa.com.
Just prepare your canvas and let art happen!
Canvas color? — White, we can change it later — checked.
Material? — Just pixels, we don’t have these medieval problems — checked.
Size? —
Size??
Oh, shit…
Web Design — Classic approach
- Pick some random values between 320 and 1920. Call them breakpoints.
- Use these numbers as canvas width. Draw a new version of your masterpiece for each width.
- Send all versions to your developer and run away.
- Wait until the developer calms down and somehow makes a prototype.
- Play ping-pong with developer.
A ball can be:
- “How this form should look like on iPad?”
- “What color should this button have on mouse hover?”
- “It looks terrible on a small phone with Android!”
Yeah, it’s a little bit too simplified but it’s enough for us to demonstrate basic pain points:
9 Circles of Hell
1. Responsiveness
- Developer has to “fill” gaps between breakpoints.
Developer finds constraints and patterns in your design and writes CSS or JS methods to transform your static images to functional responsive pages.
Transforming depends mainly on the developer’s experience and complexity of the given domain. It can be a hard and repetitive process (= boring and expensive).
2. Text
- Container with a text content has unpredictable size.
Text has many specific attributes (font-family, space width between letters, each letter can have different width or height, etc.). Text also have specific behaviors (e.g. line breaks, floating, alignment).
So it’s difficult to get container’s size before rendering the page.
And don’t forget the multi-language support, dynamic changes and browsers can have different default settings or missing fonts.
3. Collections
- Collection contains from Zero to Infinity items. Some items may break the rules of collection’s patterns.
Let’s say we want to show a photo gallery:
1) The gallery is empty — we need to show something like: “Please add some photos”
2) There is only one photo — should it be rendered in the center of the screen?
3) There are 4 photos — is there only one infinite line or we should break the line after 3rd photo? Should we show a scrollbar within the container or resize it?
4) 2nd photo is wider than others — where we should break the line?
4. State changes
- Some elements may change their attributes or visibility over time.
Even the simplest landing page has a subscribe form — you need to handle at least field validation errors.
Well, and then we have single page applications — developer will ping-ponged you with many application states you didn’t assume during design (missing error messages, unhandled empty collections, missing loading spinners, different designs for administrator and public user, etc..)
5. Custom elements
- Some elements need special algorithms for layout and behavior or are external.
- Special layout and behavior— see Masonry.
- External— Google Maps, Mailchimp’s Sign Up Form, social share buttons, etc.
We haven’t got full control of these elements and they are often integrated into our pages with low level connections.
6. Animations
- Every element can be animated.
There are more types of animations: e.g. CSS, JS, Gif. And many libraries / frameworks (Animejs).
Some animations may be attached to page events (click, scroll, etc.) —see Snake highlight.
Animations could be pretty trivial for integration into the page (Gif) but others could be very complex, depend on events and state or even modify page layout.
7. Implementation
- Designer has to know implementation details.
The only technical limitation of your design process is a canvas size. (You should follow some style-guides / design systems, branding colors, etc…, but such things can be changed or updated).
However, developers are much more limited — they need to take into account HTML and CSS rules, old and different browsers, loading speed, touch vs mouse control, CSS frameworks with different default breakpoints, etc.
If you don’t know developer’s limitations, you can expect long ping-pong matches.
8. Proprietary software
- You can’t help to fix bugs, do customization or create plugins with deep domain understanding for closed-source SW.
And it’s impossible to help to make given SW cross-platform, do security checks and so on.
Also, SW’s developers have to implement some anti-piracy protections, special user authentications or role management, etc., which will bloat thr code base and slow down development of main features.
9. Testing
- There are many browsers, many platforms and many evolving technologies. Each has specific features and bugs.
- Soo.. would you like to create a cross-platform progressive single page web app based on web-assembly with CSS grid? And your clients use Internet Explorer? Well, good luck!
- Does that gradient look different on mobile and desktop? Good luck!
- Is that cool animation slow on smartphone and Windows? Good luck!
- Is your page blank on desktop Firefox? Good luck!
- Do standard JS functions have bugs on an older iPad? Good luck!
Question for Reader:
[0.1] Do you see any other web design circles of hell?
How to resolve our pain points?
9 Spheres of Heaven
1. Responsiveness
Developer has to “fill” gaps between breakpoints.
Possible solution:
Let’s give that problem to the machine. You define design for the smallest and for the largest display and the computer interpolates designs in between.
You can define more designs manually for more control (e.g. you don’t want to show some images on a mobile version or you want different menu bar on a desktop one).
Interpolation of some elements can be difficult. See some of those cases below.
Question for Reader:
[1.1] Do you have another idea?
Link to discussion: forum.revold.app/t/responsiveness-interpolation-between-breakpoints/15
2. Text
Container with a text content has unpredictable size.
Possible solution:
Let’s say we have an article with some images (like this article). We want to get y-coordinate of the last image. The exact design isn’t defined for current display’s width.
We don’t want to compute that value before rendering because it would be a complex problem (we would have to find out all line breaks, margins between rows, font sizes..) — computation would be probably slow + don’t forget recalculations because of dynamic changes.
However we can just say “Hey PC! Just remember to put this image below this text!”
Well, let me introduce to you the concept Keep distance.
For our example above:
1) Select the last image
2) Set property Keep distance to Top (other options: Bottom, Left, Right)
3) Set property Keep distance from to Sibling (other option: Parent’s boundary)
Questions for Reader:
[2.1] Do you see problems in this solution?
[2.2] Do you think values Above / Below will be better than Top / Bottom?
[2.3] Do you have another idea?
Link to discussion: forum.revold.app/t/text-keep-distance/16
3. Collections
Collections contain from Zero to Infinity items. Some items may break the rules of collection patterns.
Possible solution:
I think the most of places where we are using collections are menus, galleries and lists (e.g. search results).
A) Menus
The most of them are horizontal or vertical bars and all their items are a simple text. Let’s say we want a vertical one:
1) Design menu with 2 items in a column
2) Select both items
3) Click on something like Create collection
4) Select items’ container (parent)
5) Set Auto-resize to Y
The machine derives patterns from these items— it extracts space height between them and their margins — so it can predict the location of the next item.
Algorithm will try to put next items to the right and start a new line from the left and below the previous one— if you want to override this behavior, you will have to mark items with order numbers (at least the first and the last item for the most cases).
B) Galleries
1) Design gallery with 2 items in a row
2) Select both items
3) Click on something like Create collection
4) Select items’ container (parent)
5) Set Auto-resize to No
6) Set Scroll to Y
The gallery will wrap its items to more lines and show scrollbar when necessary.
Questions for Reader:
[3.1] Do you like more 2 separated properties Auto-resize & Scroll or only Overflow-(x/y) property (like in CSS)?
[3.2] Do you think it is necessary to force a scrollbar to be visible in some cases (equivalent to CSS’s “overflow: scroll;”)?
C) Lists
1) Design an order items container with 2 products in a column
2) Select both items
3) Click on something like Create collection / Create table
4) Select items’ container (parent)
5) Set Auto-resize to X
6) Set Scroll to Y
Lists have similar behavior like menus. But we often want to implement them as tables — it will be necessary to create some design tools for them.
—
Designer should create designs for at least 0, 1, 2 and some higher numbers of items in collection, so he won’t forget to handle these cases and because developer & copywriter will need them.
We have to switch somehow between those designs which depend on the items count — see State changes below.
Questions for Reader:
[3.3] How do you want to design recursive collections (e.g. a tree of folders and files)?
[3.4] Do you think some cases are impossible to model with principles above?
[3.5] Do you have another idea? Should we introduce a concept of layouts?
Link to discussion: forum.revold.app/t/collections-auto-resize-scroll-items-order/17
4. State changes
Some elements may change their attributes or visibility over time.
Possible solution:
Let’s say we want to design a page with a to-do list.
Every list item contains a checkbox and a label. And there is a title with a checkbox above that list.
Title’s checkbox is checked and visible when all items are marked as done.
We want to design at least 2 versions of this page:
1. version — only some items are done
2. version — all items are done => title’s checkbox is checked
Let’s first think about standard implementation process of this example for a real web-page:
Developer will prepare a model according to designer’s assets and inputs—model is de facto a structured set of variables which contains some data.
Our model will be probably mainly a collection of items, where each item contains two values —1. value is text (we can name it label) and 2. value can be either true or false (let’s name it checked). Also, our model should contain the main title (some text).
Well, that model is good enough for a developer — if he wants to find out whether title’s checkbox is checked, he’ll call a function which checks every to-dos and when all of them are done, the function returns true.
The next step is to create an HTML template. Then he needs to write a render function which takes the model and the HTML template and outputs a nice HTML page. Done.
Designer can take a similar approach but in a reverse order:
1) Start designing
2) Associate* each designed element with appropriate model’s variables
3) If the design is done, the model is done — let’s call it the Design-driven model
4) Developer will use the design and the model to build a complete application
So we have two models — developer’s (standard) and designer’s (design-driven). They are a little bit different because we don’t want to write functions during designing — we need to add an extra variable with a name like “title_checkbox_checked” to design-driven model with value true or false.
*Associate (= bind, map..) variables to elements — it’s a way how designer defines rules for transforming a certain model to the corresponding design.
Two examples from our to-do page:
- Title’s text is associated to variable title
- Title’s checkbox is visible and checked when title_checkbox_checked is set to true
Question for Reader
[4.1] Do you want more details about association process? Well, wait for a next article or suggest your ideal way!
Link to discussion: forum.revold.app/t/state-changes-design-driven-model/18
5. Custom elements
Some elements need special algorithms for layout and behavior or are external.
Possible solution:
We unfortunately can’t run away from low-level technologies. There have to be a way how to integrate custom elements to our applications.
When we assume that they are isolated inside their container, we can treat them like containers with a text — black boxes with a variable size.
However it’s too soon to invent some integration concepts, we should focus on general principles now.
But we can checkout HTML custom elements.
Link to discussion: forum.revold.app/t/custom-elements/19
6. Animations
Every element can be animated.
Possible solution:
Well, I think it’s a nice-to-have feature from the current point of view. Let’s focus on this later.
Question for Reader:
[6.1] What types of animations do you use? And how?
Link to discussion: forum.revold.app/t/animations/20
7. Implementation
Designer has to know implementation details.
Possible solution:
- A) Don’t allow to design something that’s impossible to implement.
- B) Allow developers to choose their favorite technology and to optimize or modify design’s low-level attributes (i.e. how certain design should be transformed to HTML).
—
From Idea to Implementation:
- Designer designs pages (app states) in REVOLD Editor.
- Designer associates page elements with his Design-driven model (see 4. State changes).
- Designer includes some testing data for his DD model.
- Designer (REVOLD Editor) synchronizes saved project with developer.
- Developer download or write own REVOLD Transformer.
- Transformer is something like render function implemented in the chosen language — it processes input data & configs and outputs HTML or templates.
- Example 1: Send data to Frontend Typescript Transformer and it will render HTML page in the browser.
- Example 2: Send data to Backend Elixir Transformer and it will return HTML or some Elixir templates.
- Example 3: Send data to Static Transformer and it will generate static website which you can immediately upload to your server. - Developer integrates chosen Transformer into application (it’s the optional step for Static Transformer).
Well, with this architecture we can use many technologies, implement auto-deploys and let developers to create own transformers.
It won’t be easy to find a good general solution (and don’t forget custom elements), but with solid foundations it will be much easier to support new frameworks and platforms.
Question for Reader:
[7.1] Do you have another idea?
Link to discussion: forum.revold.app/t/implementation-high-level-architecture/21
8. Proprietary software
You can’t help to fix bugs, do customization or create plugins with deep domain understanding for closed-source SW.
Possible solution:
Open-source.
Questions for Reader:
[8.1] One has to eat — do you recommend Patreon?
[8.2] Or do you have another idea?
Link to discussion: forum.revold.app/t/proprietary-software-no-we-want-open-source/22
9. Testing
There are many browsers, many platforms and many evolving technologies. Each has specific features and bugs.
Possible solution:
- Design tools should only support features which work on the most used browsers.
- Design tools can be developed using web technologies — so they will share same technical benefits and problems like projects created by them.
- We can run local development server and write some extensions for browsers for better design and testing experience. It will be possible to connect WiFi devices (tablet, smartphone) to that server.
- A nice-to-have would be testing on a bigger number of physical devices — to integrate some services like Kobiton or BrowserStack.
Question for Reader:
[9.1] How do you test?
Link to discussion: forum.revold.app/
Next steps
- Gather ideas, needs and opinions from you.
- Implement the most promising ideas as the simple online proofs of concepts.
- Write articles about project’s progress or about specific features.
- -> Step 1.
Join The Revolution!
Help me to create better tools for web design
- Write your ideas, needs and opinions
A) on forum.revold.app,
B) to me: martin@revold.app — Example: “Hi! I need a 1-click upload of my project to Netlify!”. (But don’t be afraid to write me a long story.) - Subscribe to news on revold.app
- Support revolution on PATREON
- Write comments for this article
- Don’t be afraid to criticize everything — it’s often the only way to start improving and I want to know your opinions
P.S.
REVOLD is the acronym for The Revolution in Design.
Also, Axel Revold was a Norwegian artist who discontinued his engineering studies and became art professor. I believe we can do the similar change — let’s elevate web design from image rewriting to art.
If you have to develop your project now or don’t want to imagine world without HTML and CSS — check out my 2nd project: FusionD.
Credits
- Picture Uncle Sam & Devices
- Illustrations were drawn by my amazing girlfriend & me in Krita
Some inspiration from these great articles:
Viva la revolución!