There was a time when front-end developers would frown upon (former) print designers that designed for the web. At their usage of ‘perfect’ yet unrealistic content, and their creative ideas that were impossible to build with web tech. If this frowning since has scared print designers away from web design, I hope that they return in 2018. New CSS possibilities are ending the unrealistic content problem and the generic layout problem. It’s a great time to build layouts in CSS!

Problems solved

The unrealistic content problem

It is now not as common, but I’ve still seen it happen in the past few years. A designer presents a design. The content lines up beautifully, because it is picked to fit perfectly. Headlines that only ever need one line, that sort of thing. It can result in beautiful and balanced visual design. But it doesn’t take many years of front-end experience to know that such designs risk breakage as soon as the template is hooked up to a CMS. The content is updated, and boom, it no longer fits. With new or real content, either the design loses some of its tidiness, or the CMS is set up to force character constraints on content. That leaves the design tidy, but the content inflexible.

When content for one of the blocks changes, it will not be trivial to line up

Most of these problems have to do with keeping things the same height and doing advanced alignment. These are both requirements that are super easy to do on paper and in design software. Easy to do when making a static comp. I guess. But CSS never had tools for doing this flexibly and with unknown content (table layout excepted).

In the CSS Layout workshop I ran for Fronteers last week, I tried to emphasise that recent updates to CSS mean that the above is soon (or now, actually) no longer an issue. CSS Grid Layout (and flexbox, to some extent) will let us have our cake and eat it, too. We can make things line up or be the same height in a whim, regardless of content. We get flexible units like ch and fr that make it easier to line things up in a way that was always quite sensible, but never quite feasible. Unrealistic content, then, is less of a problem, as we have actual alignment options, rather than CSS trickery.

The defensive design problem

Every so often, contracting for agencies, the designer of a new website would come to me and ask ‘What kind of layout framework are you using? What’s the grid, are we doing Bootstrap or Foundation?’ Sometimes the agency had already listed one of these as a requirement during recruitment. I often found that the in-house developers were used to dictating these kinds of things. Lucky bastards! The reason is probably practical: when producing website after website, it makes sense for a team to start optimising things and have one way of doing grids. When working with contractors, it is useful if that one way is a broadly used open source framework. But it also seems oddly out of order: it can be a lot like solving problems before you have them.

The thing with CSS layout frameworks is that there is a fixed amount of stuff they can do. The things that are generic enough to make it into the framework. They speed up things, and are super helpful for prototyping and even creating production sites. But they don’t just create a generic way of working. They also create a generic look of websites. I’m not the first to conclude that.

Defensively designed websites tend to look the same

Web design with CSS frameworks in mind is, I think, to design defensively. The approach gives a lot of certainty about whether something can be built, which leads to happiness throughout the team, including product owners.

2018 may be the year that we no longer need to design defensively. Because Grid Layout is here. By ‘here’, I mean in our users’ browsers. In The Netherlands, on average 85% of users use browsers with full or partial (IE11) Grid Layout support.

With CSS Grid Layout, we no longer need frameworks, CSS now is the framework. This is great, we can now solve problems when we have them. With something that is a web standard.

New challenges

There are new challenges, too. The stuff Grid (and flexbox, to some extent) does, can be unexpected to those who have not mastered the spec. That’s probably most of us. They have documented Grid’s behaviour exceptionally well there, but it is perhaps only in real life designs that we will get a feeling of how it all works. For instance, what autoplacement does and how to leverage features like minmax and min-content to get our designs exactly how we want them.

Letting it go

Grid Layout has a lot of ‘leave it to the browser’ kinds of settings. Rather than ‘make this thing 400px wide’, you set things like ‘make it fit roughly between 40 and 60 characters’. More than ever, it is clear that CSS isn’t about exactly specifying what we want.

John Allsopp famously discussed this in A Dao of Web Design, over 17 years ago. He talks about “to suggest the appearance of a page, not to control the appearance of a page”. For this, he says we need to let “go of control”:

It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all. The journey begins by letting go of control, and becoming flexible.

(Emphasis mine).

“Letting go of control” is about letting the browser decide based on our hints. Browsers are good at this. They have all the knowledge: what device they’re running on, how much space is available, what fonts are available, which settings the user has set, et cetera. But it isn’t necessarily something all web teams like to do, I found.

Communicating flexibility

Even if we as CSS developers have mastered the spec, we still need to be able to communicate and explain the consequences of our code to designers, product owners and stakeholders. This is key. It requires us to explain stuff to the rest of our team. Results that struck us as unexpected will likely strike them even more.

Historically, we’ve seen a lot of website owners like the idea of their websites looking exactly the same everywhere. But it is now clear to most that this is no longer feasible. The case for flexibility has become lots stronger in our current multi-device reality. The internet is on so many devices: fridges, cars and watches with browsers now exist. This reality has powered the responsive design argument, and think it can power the flexible layout argument, too.

Conclusion

So, yes, the web is ready for great graphic design. The flexibility it was invented with has recently flourished with the surge of responsive web design. We now have CSS layout methods that let us embrace flexibility and they have good browser support. Cool experiments are done with CSS Grid Layout.

The case for using flexible layout methods will require clear communication between front-end developers and the rest of the team, as well as in-depth knowledge of these new lay-out tools. But I think we can do this. We’ve done it before with responsive web design, and we can do it again!

Originally posted as The web is ready for great graphic design on Hidde's blog.

Reply via email

This month is my last at Wigo4IT, and I’m excited to start new projects at Mozilla and the Dutch Ministry of Internal Affairs.

Leaving Wigo4IT

For years, I’ve wanted to work on front-end code for the public sector, inspired by the awesome user-centered design work that the Government Digital Service (GDS) have done in the UK. While I lived there, I wasn’t in London, the closest I got to the GDS was working for Nomensa and sitting near a team that did a GDS project.

Back in the Netherlands, I was quite excited when Informaat, a user experience agency, approached me and asked me for a project they did for local government. Long story short: I spent a bit of last year and a large part of this year contracting for them at Wigo4IT. Wigo4IT is a cooperation of the four largest Dutch municipalities, who work together on software related to social welfare.

I worked on a portal where people can apply for income support. The role of our front-end team was to build a responsive component library that can be used to create WCAG 2.0 compliant pages. The project was full of challenges related to web forms, front-end pattern libraries and theming. It was also a lot of fun to advocate for accessibility as part of the project, and my first time to have the JAWS screen reader software available to test on. I learned a lot about differences between the public and private sector, on many levels.

New challenges

Mozilla

As of next month, I will join Mozilla for a couple of months as a freelance front-end developer. I will be working for the Participation Systems team, the team that has as its goal to make it easier and more effective to contribute to Mozilla projects for all. I am incredibly excited (and slightly scared) about getting the chance to work with some brilliant minds.

Government

I have also recently started to work on two projects for the Dutch Ministry of the Interior and Kingdom Relations together with Atticus: one to apply a redesign to a set of government data related websites, and another one related to accessibility guidelines conformance statements. I love this, because this is the Ministry where a lot of the official Dutch accessibility information and guidelines are published.

CSS Workshops

Lastly, this year I will also be giving my first workshop (organised by Fronteers). Two times, in fact. It’s going to be about modern CSS Layout, including flexbox and CSS Grid Layout. I hope I’ll convince the attendees that those who haven’t yet can now safely abandon Bootstrap for layout, and that we can have lots of fun exploring and using new layout-related properties and thinking.

Originally posted as New challenges on Hidde's blog.

Reply via email

I wrote a post about Web Components about two years ago, wondering what kind we would need, if any. More companies have recently started adopting web components. I’m starting to get more excited about them, and think they can be very helpful to encapsulate compositions of elements.

Please note: this isn’t a recommendation for ‘switching to Web Components’, at the time of writing browser support is weak and the ‘components without libraries’ is not reality yet. I’m only exploring the theoretical argument.

We have all the elements we need…

At university, I learned something about Conway’s Game of Life: it can do super complex things with only four simple rules. It has been used to implement things as spectacular as Boolean logic, a clock and a Turing Machine. Similarly, I have always thought the small set of existing HTML tags is enough to build interfaces suitable for anything. From your local grocer to rocket science (for most websites, with some exceptions). We have all the elements we need.

Glider Gun in Game of Life (source)

To have the capability of creating one’s own elements seemed like fun to me, but unnecessarily complicated. At first sight, it seemed puzzling to me: how many companies are there with the resources to implement Web Components and implement them well (fast, usable and accessible)? Two problems still stand out to me: the need for polyfilling and the fact that going custom means having to provide custom usability and accessibility.

Web Components require polyfilling

To get Web Components working in most browsers, we need to use some sort of polyfill or framework. This puts our problems on users. Maybe they don’t have a fantastic connection or a brand new device. To put it bluntly, they might now experience issues they would not have had to experience if it weren’t for our custom element usage.

Custom makes usability and accessibility harder

Custom elements are custom, so browsers and device don’t ‘know’ what they are for. This means:

• they can’t provide a perfect UI that seamlessly matches the platform (as they do for native elements like select), which could result in reduced usability
• they can’t give assistive technology information about semantics, which could result in reduced accessibility

When the (Shadow) elements inside a web component are native elements, part of this problem goes away, as for those native elements, browsers would likely have perfect UIs and good exposure to assistive technologies.

…but we don’t have all the compositions of elements

Maybe providing new “primitive” HTML elements isn’t the point of Web Components. Although the basic building blocks are there, we often combine basic elements. We combine them to create our own things, our own components, patterns, modules or widgets. We may have all the required elements, we don’t have all the required compositions of elements.

Components are often that: compositions of existing elements, complemented with JavaScript and CSS to make a New Thing. The question is: do we want to encapsulate our New Things, so that they are actual, separate things?

We do this without Web Components, too. In front-end pattern libraries, each pattern often has its own folder, its own CSS file and its own scripts. In React or Vue, developers often blend markup, style and behaviour together in one piece of JavaScript.

A web standards way to compositions of elements

In recent years, the web standard gods have worked on lots of new stuff that allow developers to have more access to and influence on the web platform. And more control. Numerous new APIs have been released to give developers access to stuff that only the OS could access, like location and Bluetooth, and to stuff that only browsers could access, like stylesheets and the network. Getting access to the set of elements that exist, and being able to extend that, makes sense in that bigger picture.

Web Components provide a component model to web standards, so that we can stop using complex tools. Yup, less or no external tooling is part of the argument for web components.

With components that are part of web standards, we need less reliance on frameworks, says Alex Russell in his post Bedrock:

We observed that most of what the current libraries and frameworks are doing is just trying to create their own “widgets” and that most of these new UI controls had a semantic they’d like to describe in a pretty high-level way, an implementation for drawing the current state, and the need to parent other widgets or live in a hierarchy of widgets.

In that 2012 (!) article, he observes that creating widgets becomes the core of what modern web development looks like:

Let that picture sink in: at 180KB of JS on average, script isn’t some helper that gives meaning to pages in the breech, it is the meaning of the page. Dress it up all you like, but that’s where this is going.

So, creation of components, widgets, modules, reusable patterns for user interfaces on the web is commonplace — most web teams do it in some way or another. Frameworks provide ways to do this, but Web Components provide a standardised way to do this. See also: Web Components, the long way.

The bright side

I think the decision to go all Web Components shouldn’t be taken lightly, as many organisations may not have the problems they solve, but there are definitely upsides to them. The future for web components is looking quite bright.

Accessibility

Native elements do a great job at having accessibility built in, i.e. if you use a select you can be quite sure most of your users will be able to select stuff with them, even if they use assistive technologies to access your site, even if they have colour blindness. At the point of usage, you don’t need to worry (much) about how accessible it will be.

If you build your own component now, you will likely use some JavaScript to make accessibility provisions. There’s some risk they get lost when being copy/pasted. With Web Components, those provisions are not in the markup, they are an integral part of the component. They will be there every time you use the component’s terse syntax.

Even better, if the Accessibility Object Model becomes a thing in browsers and Web Components are better implemented, we can set accessibility properties and states directly in JavaScript.

Real encapsulation

With custom elements, you can have scope in HTML and CSS, not just in JavaScript.

IMHO, this is a solution for a problem that is not a problem, but I realise people disagree about this. The advantage of this solution is that you never need to worry about where you use a component, as it will have exactly the styles you’ve applied to it. Personally, I will probably still take advantage of CSS’s cascade.

Conclusion

And that’s what I’d like to end this with: the pre web component web is not going to go anywhere. If your website is not extremely complicated, it still makes lots of sense to just write HTML, CSS and JavaScript, keep things simple and stay away from custom elements and Shadow DOM. Peruse that cascade, do some simple DOM scripting, leverage all that built-in usability and accessibility, and be done with it.

If you have quite a complex codebase that is componentised through a framework like React, it would make sense to look at Web Components, the web standards way to build encapsulated components. In the future, when they are supported across the board. That isn’t the case at this time, so for now, they are still just theoretical awesomeness.

Update 24 October: removed parts that suggested I was recommending Web Component usage today; added a note at the top to clarify.

Originally posted as Web Components as compositions of native elements on Hidde's blog.

Reply via email

I recently had a conversation with a recruiter that went more or less like this:

• He: Are you available for a project?
• Me: What kind of project?
• He: I have one React project and one Angular project

In my head, I have trouble classifying projects in terms of the specific front-end frameworks that power them. We’re using technology, sure, but what are we using it for?

My ideal client knows the answer to the latter question and leaves implementation mainly to the team. The longer I’ve worked as a front-end developer, the more I’ve realised that specific technologies don’t matter that much, especially in projects that run for more than a couple of months.

Anyone can learn how to operate a gearbox or figure out how to reverse in a specific type of car. But where are we driving to? Ok, silly metaphor, but hopefully it gets my point across. We’re putting stuff on the people’s screens. It’s mostly about what and making stuff that matters, but those are (mostly) not front-end things.

Front-end wise, I think these things are probably key:

• are we making a fast website, i.e. do we optimise assets and avoid sending unnecessary bytes to the client?
• are we making a usable website, i.e. have we provided ease of use, rather than confronting our users with problems resulting from our complex business logic?
• are we making a website that doesn’t exclude people, i.e. do we have all users in mind when hiding and showing content and is our interface keyboard accessible?

I don’t want to be all millennial and display overly unrealistic idealism, but these things seem quite basic to me. Why strive for less? Of course, in actual interviews, it would be interesting to gloss over technologies to use to reach those goals, but I can’t see how filtering for them works as a recruitment strategy.

In order to find good people to solve your development problems, problem-solving and people skills are probably going to help much more than previous experience with specific tricks of the trade.

Originally posted as On recruiting for specific technologies on Hidde's blog.

Reply via email

This week I attended Brique, a design conference by the lovely people of Fabrique in Rotterdam’s Kunsthal. It felt like a Dutch dConstruct for designers, like Creative Mornings meets This Happened. I had a great day!

The programme was extremely well-curated, with a great variety of talks, but an overlapping theme as well. Every talk approached the subject of reality. Some were about how to experience it, through inquiry, investigative journalism or photography. Others talked about how to shape reality to tell a story, with animation, graphs, VR or even classic cars. And then there were talks about how to change reality for the greater good, to decrease income gaps and make solar power work.

Photo credit: Fabrique on Twitter (original)

Stop motion filmmaker Rogier Wieland showed some of his work and the process it involves. He makes animation films, mostly with stop motion. The attention to detail was nothing more than impressive, and it shows in the result. It did seem like a lot of work, but lots of fun too (see also the photos on their website.

Philosopher Bas Haring talked about the daily life curiosity that brings him so much: when he encounters something he just does not understand, he investigates the thing. Whether it is the history of the Panama Channel, the economy or why someone would claim that homosexuality is not natural. This attitude of inquiry often brings him to more questions and answers. Interestingly, it also inspired him to write multiple popular philosophy books.

Jeffre Jackson explained that asking ‘seriously?’ is his “standard mode”. Reality isn’t always what it seems, he said, and part of why is that we don’t know everything. We need to inquire, ask questions and realise we don’t know everything. Withhold judgment, he advised. Throughout his talk, he referenced the humanist Michel de Montaigne, whom he said “would have loved the web”. Great stuff! Still in doubt whether I should get Montaigne’s essays.

Ionica Smeets, mathematician and professor in explaining scientific research to the world. She talked about the fascinating subject of a language used by experts talking to non-experts. She explained that one way to make sure your word usage is accessible is to ask the people you talk to for a summary of what you’ve just said. It might appear they misunderstood. Or filled in blanks wrongly. She also showed how graphs can be extremely misleading, and how some use them to tell stories their way.

Storyteller Steye Hallema did the first VR talk that overwhelmed me, mostly because of the meaningful examples. I had seen VR talks at tech conferences before, Steye’s talk had a different angle: he talked about what kind of stories can be told with VR and how. VR, he said, is a bit like extracting consciousness from your brain and passing it around the room. He showed us how VR was applied to swap genders, make a music video, and experience a peep show. VR is hard, he said, from which I concluded: only use it when it improves how the story is told. He showed many examples where VR adds a new level and lets the public experience stories in ways that aren’t possible in traditional film.

Lawyer Aernoud Bourdrez enlightened us about conflict resolution. He talked about Shapiro’s five emotional aspects: appreciation, affiliation, autonomy, status and role, and ensuring to cover them all in every negotiation move. He also showed how to use this to obtain art, with some entertaining examples, such as how he managed to get the original x-rays of a car that is stuck in the Jackass’ Ryan Dunn’s buttocks.

Martijn Kieft of tv programme Tegenlicht told us how his tv programme looks at things that aren’t typically in the news, but have a huge impact with how they shape the world. Some of these things are very abstract, such as the process of creating money or negotiating for disinvestment in companies that harm the earth. For something to make the news, it requires images, but one needs creativity to find imagery if your subject is an abstract process.

Architect Kristian Koreman talked about how his team challenge reality with the projects they do. They don’t always do projects because clients ask for them, they sometimes give unsolicited advice. I like the idea of that. He showed how they helped the city of New York with a project around gentrification – quite a problem here, but a much bigger problem there. They studied differences between poor and rich and tried to come up with ways to challenge that reality.

Photographer Otto Snoek talked about his Europa project: he left his home city of Rotterdam to travel Europe and photograph people there. With his photos rotating in the background, he shared his thoughts about photography, Rotterdam and the world, and read three short stories.

Closing the day was the technologist, designer and philosopher Koert van Mensvoort. He showed some product designs to make us think about the future of our society: new technological possibilities arise, but are we comfortable with what can be achieved? He showed us the ‘speculative products’ he developed to start a discussion, and different kinds of in vitro meat products, some real and some imagined. He also talked about what ‘nature’ is, and argued the traditional definition should be widened to include hard to control human-made systems (such as financial markets and the internet). And that we should have the ambition for technology to become part of our nature, rather than just to the job they were invented for. More about how technology becomes part of nature in this TED Talk Koert gave.

Originally posted as Brique: a conference about challenging reality on Hidde's blog.

Reply via email