3 ms·

> brutalist buildings often reflect back the forms used to make them I like the core concept of brutalism, but I see problems with brutalism in general and in

by tomxor 8y ago

> brutalist buildings often reflect back the forms used to make them I like the core concept of brutalism, but I see problems with brutalism in general and in applicability to web design... The problem I see with brutalism in general is that it doesn't go far enough! removing the veneer and doing away with facades is the first step, the point is to be honest; not to intentionally make things aesthetically displeasing. Once it's honest you can focus on good function and beauty emerging from within. This principle isn't entirely incompatible with web design, however there is a significant difference that needs to be understood: With web design the aesthetics are not completely separable from the function, because in the most fundamental way - you operate a web page by looking at it. Because of this, I prefer to focus on minimalism and typography when it comes to creating highly functional, no bullshit web design. In other words, look at how books have been doing it for the past 1000 years, because beyond having to turn a page their basic function is very similar.

hashmal 8y ago
The problem I see with brutalist webdesign is that it focuses on the result instead of the process. Applying brutalism principles on the process (the upfront design and the actual code) would let beauty emerge by itself indeed, in a much more honest way.
- HelloNurse 8y ago
  The process is what is focused on the result: if you carefully avoid putting useless cruft in your pages, you get clean pages. It isn't a trivial principle because it has to be applied to a great variety of design choices with a great variety of technical means to meet a great variety of purposes.
robin_reala 8y ago
in the most fundamental way - you operate a web page by looking at it. I highly disagree with this. The most fundamental aspect of web design is that style is a layer that can be disabled, and that content is accessible to all, even if their access method is different from the norm (for example a screen reader presenting the information as an aural experience to the user).
- tomxor 8y ago
  Screen readers are an exception, 99.9% of use (probably more) will be through looking at the page. > that style is a layer that can be disabled It cannot be disabled, only changed. By "removing" the author's style you are replacing it with the default style sheet included in your browser, if you remove the default style sheet you are using the default values for all the css properties built into the rendering engine of your browser when it was compiled. Even if you put the source code in your text editor instead, you are now using your editor and terminal styles instead. My point is: in order to view text - it must be rendered, if it is rendered - it has a style, this is why the visually element is also a functional one, you cannot escape that unless you read text without your eyes.
Kagerjay 8y ago
I've done a fair amount of building architecture and design, as well as brochure and catalog design. I do frontend development now. These are my takeaways Every building has more or less the same requirements - you have a given space, you need X items to fill that space that meet functional Y requirements, etc. Doesn't really matter what you are doing its all the same really. You find the interior design aesthetic that works for your consumer after laying out the foundational "functional" aspects of the building. E.g. where are the toilets, where is the entrance, where are the exits, how large of a space should each tenant want, open or closed design, etc. You understand the user requirements and what the long term vision is for the site. Catalog, brochure, and book design preceded webdesign. I learned to appreciate the beauty of typography by understanding what problems people dealt with before the web. How do you manage to fit content with high density into a 8.5"x11" page or A4 size? What is the minimal font an average 18-30 year old can read VS someone who has deteriorating eyesight? Which font types work best in typography (Helvetica, times new roman, etc). Which font-types has the best information density per line-length (Arial Narrow)? What is the optimal line length and word count for a single paragraph line (its about 10-15). How many sentences should be in a paragraph for optimal readability? Which fonts have the highest density information in fractional fonts (Calibri). What is the leading typography research used in the past (NASA). 3 hole punch saddle stitch, what should your margins be, what font-size ratios for header tags vs subheaders vs paragraphs, text-justifications, etc. How will the page look with 2 pages side by side in a brochure, do they complmenet each other, etc. I learned all this above by taking the top 100 catalogs of every industry I could find, getting these books, taking a font ruler like this one https://www.amazon.com/Westcott-Graphic-Arts-Ruler-GA-86/dp/B007RHD2BS/ref=sr_1_4?s=office-products&ie=UTF8&qid=1531078204&sr=1-4&keywords=font+ruler https://www.amazon.com/Westcott-Graphic-Arts-Ruler-GA-86/dp/..., and overlaying it on top. Its extremely surprising how different companies handle things like color choices for certain categories, trimming, etc. You can also analyze these same principles sometimes even on their website, both good and bad. You can see a huge disparity difference in this by getting a McMasterCarr/Grainger catalog and comparing it to a fashion catalog. Webdesign is the same thing really. Actually I still apply many of the same principlces I learned from catalog design. I still put font-rulers onto my screen, measure things out with rulers, even though I have many chrome extensions / chrome debugger for handling this. When I read things things talking about responsive webdesign, I am reminded that it doesn't really matter what you set your breakpoints at. No mobile manufacturer is going to make a new device below 320px width wide, not many people will care about a site that supports 4K resolution because the human eye has its limitations, etc. People simply aren't going to care about phablets past a certain sizes since it won't fit naturally in most peoples hands. Breakpoints, I just use bootstrap's 4 breakpoint guidelines with some additions and a grand total of 3 sass mixins for responsive media queries. (320px, 576px, 768px, 992px, 1200px, 1400px, 1600px) Semantic HTML is like building lego blocks. A webpage is just a bunch of legos. We call this the DOM. Your body tag, html tag, section, etc. You can build the same website with different legos, but at the end of the day you'll favor some over others. Brutalist design to me is just thinking of content first and the purpose of the site over everything else first. Sometimes this is referred to as "progressive design". ------------------------------------------------------------------ - Don't use JS if CSS can do the job just fine. If you do use JS over CSS, have a good reason why (e.g. favoring simple jQuery statements over css "hacks" like clearfixes / checkboxes / special states) - Don't use an SPA like react if you don't have complex UI needs or need state management - HTML should be semantically pretty. You should be able to understand how a site is organized purely by grokking its HTML and class names. Don't have crazy amounts of ID's, if you use multiple classes for an element, have a good reason why (state modifiers). - Organize things using some CSS methodology (BEM, SMACSS, etc) or combination thereof. Especially if you have 2000+ lines of scss code to work with. Personally I just name things that can be interpreted in very few ways and use BEM for complex nested components. - If you pick a css framework it has its pros/cons (e.g. bootstrap, bulma). More bloated things to load, easier to get off the around with multiple people working on it (e.g. its opinionated), but harder to reason / modify later. Personally I just make my own versions of things like bootstrap containers, etc. - Don't overnest your SCSS code past 3 levels deep. - Use a HTML preprocessor like Jade/pug for websites that favor heavily on many unique HTML page layouts. Its much easier to reason about. ------------------------------------------------------------------ - Design your content first. E.g. If you aren't using an SPA approach, write your HTML first, some CSS, your JS, and then reiterate until you are finished. - Pick older more established technologies over new shiny tech. You'll find far more resources on blogs and stackoverflow for potential errors you encounter. e.g. startups using ruby on rails. - Use CSS flexbox whenever possible, ignoring IE11 users because its eventually going to be adopted. Unless you have good reason not too (e.g. developing for government sector, etc). - Develop in isolated environments for webcomponents (e.g. codepen) so you can reuse it in any project - Don't waste your time reinventing the wheel unless you have good reason to. E.g. understanding a concept, making a better variant of that library, etc. - Don't do UX research if you don't have to. Chances are someone else has done the research already for you and published it already. Look at competitors. Use that. This includes things like good webdesign practices, optimal webfonts and families (e.g. roboto), etc. - Look outward for inspiration in webdesign, and keep a catalog of that somewhere with whatever tool you use (bookmarks, etc). I have a number of systems for doing this depending on each platform I'm on. - Don't bother wasting too much time invested in one particular languages quirks unless your job demands it, rather understand the underlying principles (computer science, math, design patterns, UX functionality, etc) of what you are doing. ------------------------------------------------------------------ - Use color psychology/theory and color gradients to achieve desired effects. Some colors do not work well with others, using certain colors limits your overall pallete selection. Ideally have less than 4 colors stlyizing your website. For instance, if you use red as a primary, you will automatically most likely be using grey and black as support colors. Think of well established brands like cocacola for inspiration, etc. - Use HSL colors over RGB or Hex since its designed to be human relatable. - Use CSS Tools for designing more complex web frontend components. These include box shadows, buttons, textures, etc. - Don't worry about EM vs REM vs PX this can always be changed down the road for handling impaired users / zooming in effects. If you designed your webpage well with highly readable fonts and sizes, you might not need to do much here anyhow. - Consider using an image over some complex HTML/CSS component. Instead of building a shopping cart button for instance, load a single image background on a div for an ecommerce site. Other things this would include are global banners and banner buttons. - Keep it simple stupid (KISS) - Consider the takt time of how long it takes a user to do simple common tasks for an SPA. E.g. in ecommerce, how long would it take a person to add an item to cart and checkout. How long would it take to look up a specsheet. When you scroll down the page would you as a user get confused by the design for doing common tasks? Most of this is common sense, but you could still benefit from doing UX research. - Your first performance bottleneck you should consider is images, not the sizes of libraries you are loading in. Learn how to use CSS sprites for instance, and use tools to streamline it. ------------------------------------------------------------------ Basically brutalist design to me is building the crappiest version possible that meets your projects / user requirements (rapid prototyping). Then building iterations on top of it until it looks unique and pretty. Because good UX and aesthetics should still be achieved in the end, but if and only if the building blocks are in place already. Performance is important but past a certain point it just doesn't matter. Really brutalist design IMO just derives alot of its philosophies from LEAN-based design which is an industrial engineering philosophy. Building an actual product with nice ergonomics is not that much different than shipping out a nice UX frontend. But you need the engineering (circuit board design, CAD model) much like you do in webdesign (organize css code, SPA, libraries, backend, etc).

by tomxor 8y ago

hashmal 8y ago

The problem I see with brutalist webdesign is that it focuses on the result instead of the process. Applying brutalism principles on the process (the upfront design and the actual code) would let beauty emerge by itself indeed, in a much more honest way.

HelloNurse 8y ago
The process is what is focused on the result: if you carefully avoid putting useless cruft in your pages, you get clean pages. It isn't a trivial principle because it has to be applied to a great variety of design choices with a great variety of technical means to meet a great variety of purposes.

robin_reala 8y ago

in the most fundamental way - you operate a web page by looking at it. I highly disagree with this. The most fundamental aspect of web design is that style is a layer that can be disabled, and that content is accessible to all, even if their access method is different from the norm (for example a screen reader presenting the information as an aural experience to the user).

tomxor 8y ago
Screen readers are an exception, 99.9% of use (probably more) will be through looking at the page. > that style is a layer that can be disabled It cannot be disabled, only changed. By "removing" the author's style you are replacing it with the default style sheet included in your browser, if you remove the default style sheet you are using the default values for all the css properties built into the rendering engine of your browser when it was compiled. Even if you put the source code in your text editor instead, you are now using your editor and terminal styles instead. My point is: in order to view text - it must be rendered, if it is rendered - it has a style, this is why the visually element is also a functional one, you cannot escape that unless you read text without your eyes.

Kagerjay 8y ago

I've done a fair amount of building architecture and design, as well as brochure and catalog design. I do frontend development now. These are my takeaways Every building has more or less the same requirements - you have a given space, you need X items to fill that space that meet functional Y requirements, etc. Doesn't really matter what you are doing its all the same really. You find the interior design aesthetic that works for your consumer after laying out the foundational "functional" aspects of the building. E.g. where are the toilets, where is the entrance, where are the exits, how large of a space should each tenant want, open or closed design, etc. You understand the user requirements and what the long term vision is for the site. Catalog, brochure, and book design preceded webdesign. I learned to appreciate the beauty of typography by understanding what problems people dealt with before the web. How do you manage to fit content with high density into a 8.5"x11" page or A4 size? What is the minimal font an average 18-30 year old can read VS someone who has deteriorating eyesight? Which font types work best in typography (Helvetica, times new roman, etc). Which font-types has the best information density per line-length (Arial Narrow)? What is the optimal line length and word count for a single paragraph line (its about 10-15). How many sentences should be in a paragraph for optimal readability? Which fonts have the highest density information in fractional fonts (Calibri). What is the leading typography research used in the past (NASA). 3 hole punch saddle stitch, what should your margins be, what font-size ratios for header tags vs subheaders vs paragraphs, text-justifications, etc. How will the page look with 2 pages side by side in a brochure, do they complmenet each other, etc. I learned all this above by taking the top 100 catalogs of every industry I could find, getting these books, taking a font ruler like this one https://www.amazon.com/Westcott-Graphic-Arts-Ruler-GA-86/dp/B007RHD2BS/ref=sr_1_4?s=office-products&ie=UTF8&qid=1531078204&sr=1-4&keywords=font+ruler https://www.amazon.com/Westcott-Graphic-Arts-Ruler-GA-86/dp/..., and overlaying it on top. Its extremely surprising how different companies handle things like color choices for certain categories, trimming, etc. You can also analyze these same principles sometimes even on their website, both good and bad. You can see a huge disparity difference in this by getting a McMasterCarr/Grainger catalog and comparing it to a fashion catalog. Webdesign is the same thing really. Actually I still apply many of the same principlces I learned from catalog design. I still put font-rulers onto my screen, measure things out with rulers, even though I have many chrome extensions / chrome debugger for handling this. When I read things things talking about responsive webdesign, I am reminded that it doesn't really matter what you set your breakpoints at. No mobile manufacturer is going to make a new device below 320px width wide, not many people will care about a site that supports 4K resolution because the human eye has its limitations, etc. People simply aren't going to care about phablets past a certain sizes since it won't fit naturally in most peoples hands. Breakpoints, I just use bootstrap's 4 breakpoint guidelines with some additions and a grand total of 3 sass mixins for responsive media queries. (320px, 576px, 768px, 992px, 1200px, 1400px, 1600px) Semantic HTML is like building lego blocks. A webpage is just a bunch of legos. We call this the DOM. Your body tag, html tag, section, etc. You can build the same website with different legos, but at the end of the day you'll favor some over others. Brutalist design to me is just thinking of content first and the purpose of the site over everything else first. Sometimes this is referred to as "progressive design". ------------------------------------------------------------------ - Don't use JS if CSS can do the job just fine. If you do use JS over CSS, have a good reason why (e.g. favoring simple jQuery statements over css "hacks" like clearfixes / checkboxes / special states) - Don't use an SPA like react if you don't have complex UI needs or need state management - HTML should be semantically pretty. You should be able to understand how a site is organized purely by grokking its HTML and class names. Don't have crazy amounts of ID's, if you use multiple classes for an element, have a good reason why (state modifiers). - Organize things using some CSS methodology (BEM, SMACSS, etc) or combination thereof. Especially if you have 2000+ lines of scss code to work with. Personally I just name things that can be interpreted in very few ways and use BEM for complex nested components. - If you pick a css framework it has its pros/cons (e.g. bootstrap, bulma). More bloated things to load, easier to get off the around with multiple people working on it (e.g. its opinionated), but harder to reason / modify later. Personally I just make my own versions of things like bootstrap containers, etc. - Don't overnest your SCSS code past 3 levels deep. - Use a HTML preprocessor like Jade/pug for websites that favor heavily on many unique HTML page layouts. Its much easier to reason about. ------------------------------------------------------------------ - Design your content first. E.g. If you aren't using an SPA approach, write your HTML first, some CSS, your JS, and then reiterate until you are finished. - Pick older more established technologies over new shiny tech. You'll find far more resources on blogs and stackoverflow for potential errors you encounter. e.g. startups using ruby on rails. - Use CSS flexbox whenever possible, ignoring IE11 users because its eventually going to be adopted. Unless you have good reason not too (e.g. developing for government sector, etc). - Develop in isolated environments for webcomponents (e.g. codepen) so you can reuse it in any project - Don't waste your time reinventing the wheel unless you have good reason to. E.g. understanding a concept, making a better variant of that library, etc. - Don't do UX research if you don't have to. Chances are someone else has done the research already for you and published it already. Look at competitors. Use that. This includes things like good webdesign practices, optimal webfonts and families (e.g. roboto), etc. - Look outward for inspiration in webdesign, and keep a catalog of that somewhere with whatever tool you use (bookmarks, etc). I have a number of systems for doing this depending on each platform I'm on. - Don't bother wasting too much time invested in one particular languages quirks unless your job demands it, rather understand the underlying principles (computer science, math, design patterns, UX functionality, etc) of what you are doing. ------------------------------------------------------------------ - Use color psychology/theory and color gradients to achieve desired effects. Some colors do not work well with others, using certain colors limits your overall pallete selection. Ideally have less than 4 colors stlyizing your website. For instance, if you use red as a primary, you will automatically most likely be using grey and black as support colors. Think of well established brands like cocacola for inspiration, etc. - Use HSL colors over RGB or Hex since its designed to be human relatable. - Use CSS Tools for designing more complex web frontend components. These include box shadows, buttons, textures, etc. - Don't worry about EM vs REM vs PX this can always be changed down the road for handling impaired users / zooming in effects. If you designed your webpage well with highly readable fonts and sizes, you might not need to do much here anyhow. - Consider using an image over some complex HTML/CSS component. Instead of building a shopping cart button for instance, load a single image background on a div for an ecommerce site. Other things this would include are global banners and banner buttons. - Keep it simple stupid (KISS) - Consider the takt time of how long it takes a user to do simple common tasks for an SPA. E.g. in ecommerce, how long would it take a person to add an item to cart and checkout. How long would it take to look up a specsheet. When you scroll down the page would you as a user get confused by the design for doing common tasks? Most of this is common sense, but you could still benefit from doing UX research. - Your first performance bottleneck you should consider is images, not the sizes of libraries you are loading in. Learn how to use CSS sprites for instance, and use tools to streamline it. ------------------------------------------------------------------ Basically brutalist design to me is building the crappiest version possible that meets your projects / user requirements (rapid prototyping). Then building iterations on top of it until it looks unique and pretty. Because good UX and aesthetics should still be achieved in the end, but if and only if the building blocks are in place already. Performance is important but past a certain point it just doesn't matter. Really brutalist design IMO just derives alot of its philosophies from LEAN-based design which is an industrial engineering philosophy. Building an actual product with nice ergonomics is not that much different than shipping out a nice UX frontend. But you need the engineering (circuit board design, CAD model) much like you do in webdesign (organize css code, SPA, libraries, backend, etc).