Tag: Designer’s

02 Mar

State Of GDPR In 2021: Cookie Consent For Designers And Developers

by TBSCategories: News

Last week, I gave you an update on everything that’s happened with GDPR since 2018. (TL;DR: A lot has changed.) In this article, we’ll look at cookie consent: specifically, the paradox where marketers are heavily reliant on Google Analytics cookie data but need to comply with regulations.

We’ll take a look at two developments that have impacted cookies, plus a third on the horizon. Then I’ll walk you through the risk-based approach that we’ve taken — for the moment, at least. And come back next time for a deep dive into first-party ad tracking as we start to see moves away from third-party cookies.

Big Development #1: Cookie Consent

In May 2020, the EU updated its GDPR guidance to clarify several points, including two key points for cookie consent:

  • Cookie walls do not offer users a genuine choice, because if you reject cookies you’re blocked from accessing content. It confirms that cookie walls should not be used.
  • Scrolling or swiping through web content does not equate to implied consent. The EU reiterates that consent must be explicit.

What does this mean for our industry?

Well, the EU is tightening up on cookie consent — perhaps the most noticeable (and annoying!) aspect of GDPR. Critics say that cookie notices are a cumbersome block for users, and don’t do anything to protect user privacy. The EU is trying to change this, by promoting simple, meaningful, equitable options for cookie consent.

But that restricts what we can do with cookies, and it hints ahead to when the Privacy and Electronic Communications Regulation (PECR) may come into force. More on that shortly.

Big Development #2: Google and Apple crack down on third-party tracking; get hit by anti-trust complaints

As the big digital players figure out how to comply with GDPR — and how to turn privacy legislation to their advantage — some have already come under fire.

Google is being investigated by the UK’s competition watchdog, the Competition and Markets Authority (CMA), for its ‘Privacy Sandbox’ initiative, following complaints from adtech companies and publishers.

The Internet giant, which is also facing an antitrust investigation in Italy for display advertising, and in the US for its search advertising services, is looking to remove third-party cookies from Chrome. (Firefox and Safari already block these cookies by default.)

The complainants say that this change will further concentrate advertising revenue in Google’s hands. Google’s response? The advertising industry needs to make ‘major changes’ as it shifts to a ‘web without third-party cookies’.

Google’s not alone. In October 2020, four French digital advertising lobbies filed an antitrust suit against Apple’s forthcoming iOS privacy change, a feature it’s called App Tracking Transparency (ATT).

ATT, coming in an early-spring 2021 release of iOS 14, shifts app users from an opt-out to an opt-in ad-tracking model. With ATT, every app must get your permission to share your Identifier for Advertisers (IDFA), which enables third-party ad tracking across multiple sites and channels.

The complainants say that by restricting apps’ ad revenue, developers may have to boost app subscriptions and in-app purchases or switch to Apple’s targeted ad platform — all of which will funnel ad spend away from them and towards Cupertino.

Critics including Facebook have slammed the change, saying it’ll hit small businesses who rely on microtargeted ads. Apple has defended the move and praised the EU’s defence of citizens’ data privacy.

To sum up:

  • Implied consent doesn’t equal consent under GDPR, according to the EU.
  • We should also avoid cookie walls
  • Google and Apple are moving against third-party cookies — which some say exploits their dominant market position.

So what does that mean for us, as designers and developers? First, let’s take a look at why this is important.

Here’s What Designers Should Know About Cookies

  • GDPR is critical for you because you’ll design the points at which cookies are placed, what data is collected, and how it’s processed.
  • A functionality audit means you can map your cookie activity in the data and compliance layers on your service blueprint.
  • It can help to do a cookie audit and gap analysis, i.e. is the existing cookie pattern compliant? What content does it need around it?
  • Follow Privacy by Design best practices. Don’t try to reinvent the wheel — if you’ve created a compliant cookie banner, use your proven design pattern.
  • Work with your compliance and development teams to ensure designs meet GDPR and can be implemented. Only ask for the data you need.
  • If you need to compromise, take a risk-based approach. There’s a walk-through of one that we did further down.
  • Be aware that your content team may need to update your privacy policy as GDPR and your use of cookies evolve.

Here’s What Developers Should Know About Cookies

  • Make sure you’re involved upfront about cookie consent and tracking, so what’s decided can be implemented.
  • If you’re doing a product or website redesign, a cookie audit using Chrome Dev Tools can show you what tracking cookies are being used. Tools like Ghostery or Cookiebot give you more detail.
  • You should implement the standard cookie opt in/out as per GDPR guidance. (Note that while GDPR is standard, the enforcement of it varies across EU countries. There’s more on this further down.) You may stand to lose Google Analytics data. You might also come under pressure to implement things that could be considered as dark patterns. There’s more on this later, with a walk-through of what we did and a look at the risk.

So that’s where we are today. Oh, and there’s one more thing to be aware of: a piece of further legislation that might be coming our way. I like to call it Schrodinger’s Law.

Schrodinger’s Law: The ePrivacy Regulation

You may have heard of GDPR’s twin sister, the ePrivacy Regulation, who’s lurking on the legislative horizon. If you haven’t, here’s an introduction.

As I said above, cookie consent — the notice that pops up when you visit a website — is regulated by the GDPR. However, cookies themselves fall under a different piece of legislation, the ePrivacy Directive of 2002, commonly known as the Cookie Law. Like GDPR, it aims to protect customer privacy.

The ePrivacy Directive is due to be replaced by more stringent legislation, the ePrivacy Regulation. (If you’re interested in the difference between EU directives and regulations, EU directives set out the goals for legislation but delegate the implementation of those goals to member states’ legislatures. EU regulations mandate both the goals and the implementation at an EU-wide level.)

The draft ePrivacy Regulation goes beyond cookies and ad tracking. It applies to all electronic communications, including messaging apps, spam mail, IoT data transfer and more.

The draft ePrivacy Regulation was first presented by the EU in 2017. However, it has to be agreed by both the European Parliament and the Council of the European Union. (The Council consists of government representatives of each EU member state.)

This is where it gets messy. Since 2017, the European Parliament and the Council haven’t been able to agree on the scope and detail of the ePrivacy Regulation.

That’s because some countries — widely thought to include the Nordic states of Finland and Denmark — want to strengthen the current ePrivacy Directive. They want users, for example, to be able to set acceptance and rejection of tracking cookies in their browsers, not on every site they visit.

But other countries, notably Austria and believed also to include those with sizeable digital marketing and advertising sectors, say this is bad for business. It’s thought the 27 EU member states are split down the middle on this issue — and they’re all being heavily lobbied by the tech industry.

So the draft regulation has been ricocheting back and forth between the European Commission and its Working Party on Telecommunications and Information Society as they try to agree its scope. In November 2020, the Working Party rejected the redrafted legislation once again.

What happens next? There are two possibilities. Either a compromise will be reached, in which case the legislation will be agreed. Because it takes time for legislation to be implemented, the soonest the ePrivacy Regulation could become law is 2025.

Alternatively, the legislation cannot be agreed and is withdrawn by the European Commission. But the EU has staked so much on it. It will be extremely reluctant to take that step.

That’s why I call it Schrodinger’s Law. It’s hard for us to know how to plan for any cookie-related developments because we simply don’t know what’s happening.

So what should I do about cookies right now?

Different EU countries are currently implementing the ePrivacy Directive differently. Over in the UK, the ICO (the UK’s data protection authority) is taking a tough stance. It’s requiring strict consent for analytics cookies, for example, and has spoken out against cookie walls.

Until — and if — we get consistency from a new ePrivacy Regulation, if you’re based in an EU country, start by following the advice from your national Data Protection Authority. Then watch this space for developments around the ePrivacy Regulation.

If you’re based outside the EU, make sure you’re giving EU citizens the options required under the GDPR and the ePrivacy Directive.

However, when it comes down to the detail, there are times when I recommend taking a risk-based approach. That’s what we’ve done at Cyber-Duck — and here’s why.

Here’s our original cookie notice. You see these everywhere. They’re pretty meaningless — users just hit accept and continue on their way.

But we wanted to be compliant, so we replaced it with this notice. You’ll see that tracking cookies are turned off by default — in line with ICO guidance. We knew there was a risk we would lose analytics data as GTM would no longer fire on first load.

Let’s see what happened.

Problem solved? Actually, no. It just created another problem. The impact was far more significant than we expected:

Look at the collapse in the blue line when we implemented the new cookie notice. We released the new cookie consent on 17 December and went straight from plenty of tracked traffic to almost zero. (The orange line shows the previous year’s traffic, for comparison.)

In both the before-and-after scenarios, the default option was by far the most popular. Most users just naturally click on “accept” or “confirm”. That’s tricky, because we now know so little about the people visiting our site that we can’t give them the best information tailored to their needs.

We needed a solution. Analytics and marketing data ultimately drive business decisions. I’m sure we all know how important data is. In this case, it was like putting money in a bank account and not knowing how much we’d spent or saved!

Some of the solutions that were posed include design alternatives (would removing the toggle, or having two buttons with a visual nudge towards the “accept” help?) Or would we enable analytics cookies by default?

For now, we’ve implemented a compromise position. Marketing and analytics cookies are on by default, with one clear switch to toggle them off:

And here’s what that’s done to our stats:

The new cookie banner was relaunched on 15 January. You can see our website traffic starts to pick back up again. However, we’re not getting the full data we were getting before as Google Tag Manager doesn’t fire unless a user chooses cookies.

The good news is, we are getting some data back again! But the story doesn’t end here. After we had turned cookie tracking back on by default, the attribution model got messed up. It wasn’t attributing to the correct channel in Google Analytics.

Here’s what we mean:

Scenario 1: (Correct Attribution)

  1. User lands on our website via a paid ad (PPC) or from the search result (organic)
  2. User accepts cookies straight away.
  3. The channel source is attributed correctly, e.g. to PPC.

Scenario 2: (Incorrect Attribution)

  1. User lands on our website via a paid ad (PPC) or from the search result (organic)
  2. User visits a few other pages on our website without responding to the cookie banner prompt (banner appears on every page until it gets a response)
  3. User finally accepts cookie banner after browsing a few pages.
  4. Attribution comes through as direct — although they originally came from a search engine.

How does that work? When a user browses other pages on the site, nothing is tracked until they respond to the cookie prompt. Tracking only kicks in at that point. So to Google, it looks as though the user has just landed on that page — and they are attributed to Direct traffic.

Back to the drawing board.

Note: I’m sure by now you’re starting to see a pattern here. This entire experience is new for us and there’s not a lot of documentation around, so it’s been a real learning curve.

Now, how could we solve this attribution issue and stop users from navigating around the site until they’ve selected their cookie preference?

A cookie wall is one option we considered, but that would potentially push us further away from being compliant, according to the ICO. (Though you might like to try browsing their site incognito and see if they stick to their own guidance…)

But that’s what we’ve chosen to go with. The journey ends here for now, as we’re still gathering data. In the future, we want to explore other tools and the potential impact of moving away from Google Analytics.

So what’s everyone else doing?

Well, McDonald’s UK offers straightforward on/off buttons:

Coca Cola’s British site nudges you to accept by making the ‘reject’ option harder to find:

Whereas Sanrio just has an option to agree to ad tracking:

Hello Kitty, hello cookies.

Die Zeit offers free access if you accept tracking cookies — but for an untracked, ad-free experience you’ll have to pay:

And here’s one of my favourite dark patterns. This restaurant site only has the ‘Necessary’ cookies selected. But it nudges you to the ‘Allow all cookies’ big red button — and when you click that, the analytical and ad cookie boxes are automatically checked and set. Give it a go here!

Even the EU isn’t consistent on its own sites.

The European Parliament’s cookie consent offers two clear options:

The CJEU’s site isn’t so clear:

While Europol’s site comes with two pre-checked boxes:

And if you look at the sites for the German presidency of the Council of the European Union (July–December 2020), at first it seems as if there’s no cookies at all:

When you land on the site, there are no cookie banners or prompts. A closer look, with cookie extension tools, shows that no cookies are being placed either.

So are they capturing any analytics data? The answer is yes.

We found this little snippet in their code, which shows they are using ‘Piwik’. Piwik is now known as Matomo, one of a clutch of new tools that help with cookie compliance along with Fathom (server-side tracking) and HelloConsent (cookie management).

So alternatives and solutions are emerging. We’ll take a closer look at that next time — with new alternatives to third-party cookies that will help you take control of your data and get the insight you need to deliver optimum experiences to your customers. Stay tuned!

Further Reading

Articles on Smashing Magazine — For Web Designers And Developers

02 Mar

State Of GDPR In 2021: Cookie Consent For Designers And Developers

by TBSCategories: News

Last week, I gave you an update on everything that’s happened with GDPR since 2018. (TL;DR: A lot has changed.) In this article, we’ll look at cookie consent: specifically, the paradox where marketers are heavily reliant on Google Analytics cookie data but need to comply with regulations.

We’ll take a look at two developments that have impacted cookies, plus a third on the horizon. Then I’ll walk you through the risk-based approach that we’ve taken — for the moment, at least. And come back next time for a deep dive into first-party ad tracking as we start to see moves away from third-party cookies.

Big Development #1: Cookie Consent

In May 2020, the EU updated its GDPR guidance to clarify several points, including two key points for cookie consent:

  • Cookie walls do not offer users a genuine choice, because if you reject cookies you’re blocked from accessing content. It confirms that cookie walls should not be used.
  • Scrolling or swiping through web content does not equate to implied consent. The EU reiterates that consent must be explicit.

What does this mean for our industry?

Well, the EU is tightening up on cookie consent — perhaps the most noticeable (and annoying!) aspect of GDPR. Critics say that cookie notices are a cumbersome block for users, and don’t do anything to protect user privacy. The EU is trying to change this, by promoting simple, meaningful, equitable options for cookie consent.

But that restricts what we can do with cookies, and it hints ahead to when the Privacy and Electronic Communications Regulation (PECR) may come into force. More on that shortly.

Big Development #2: Google and Apple crack down on third-party tracking; get hit by anti-trust complaints

As the big digital players figure out how to comply with GDPR — and how to turn privacy legislation to their advantage — some have already come under fire.

Google is being investigated by the UK’s competition watchdog, the Competition and Markets Authority (CMA), for its ‘Privacy Sandbox’ initiative, following complaints from adtech companies and publishers.

The Internet giant, which is also facing an antitrust investigation in Italy for display advertising, and in the US for its search advertising services, is looking to remove third-party cookies from Chrome. (Firefox and Safari already block these cookies by default.)

The complainants say that this change will further concentrate advertising revenue in Google’s hands. Google’s response? The advertising industry needs to make ‘major changes’ as it shifts to a ‘web without third-party cookies’.

Google’s not alone. In October 2020, four French digital advertising lobbies filed an antitrust suit against Apple’s forthcoming iOS privacy change, a feature it’s called App Tracking Transparency (ATT).

ATT, coming in an early-spring 2021 release of iOS 14, shifts app users from an opt-out to an opt-in ad-tracking model. With ATT, every app must get your permission to share your Identifier for Advertisers (IDFA), which enables third-party ad tracking across multiple sites and channels.

The complainants say that by restricting apps’ ad revenue, developers may have to boost app subscriptions and in-app purchases or switch to Apple’s targeted ad platform — all of which will funnel ad spend away from them and towards Cupertino.

Critics including Facebook have slammed the change, saying it’ll hit small businesses who rely on microtargeted ads. Apple has defended the move and praised the EU’s defence of citizens’ data privacy.

To sum up:

  • Implied consent doesn’t equal consent under GDPR, according to the EU.
  • We should also avoid cookie walls
  • Google and Apple are moving against third-party cookies — which some say exploits their dominant market position.

So what does that mean for us, as designers and developers? First, let’s take a look at why this is important.

Here’s What Designers Should Know About Cookies

  • GDPR is critical for you because you’ll design the points at which cookies are placed, what data is collected, and how it’s processed.
  • A functionality audit means you can map your cookie activity in the data and compliance layers on your service blueprint.
  • It can help to do a cookie audit and gap analysis, i.e. is the existing cookie pattern compliant? What content does it need around it?
  • Follow Privacy by Design best practices. Don’t try to reinvent the wheel — if you’ve created a compliant cookie banner, use your proven design pattern.
  • Work with your compliance and development teams to ensure designs meet GDPR and can be implemented. Only ask for the data you need.
  • If you need to compromise, take a risk-based approach. There’s a walk-through of one that we did further down.
  • Be aware that your content team may need to update your privacy policy as GDPR and your use of cookies evolve.

Here’s What Developers Should Know About Cookies

  • Make sure you’re involved upfront about cookie consent and tracking, so what’s decided can be implemented.
  • If you’re doing a product or website redesign, a cookie audit using Chrome Dev Tools can show you what tracking cookies are being used. Tools like Ghostery or Cookiebot give you more detail.
  • You should implement the standard cookie opt in/out as per GDPR guidance. (Note that while GDPR is standard, the enforcement of it varies across EU countries. There’s more on this further down.) You may stand to lose Google Analytics data. You might also come under pressure to implement things that could be considered as dark patterns. There’s more on this later, with a walk-through of what we did and a look at the risk.

So that’s where we are today. Oh, and there’s one more thing to be aware of: a piece of further legislation that might be coming our way. I like to call it Schrodinger’s Law.

Schrodinger’s Law: The ePrivacy Regulation

You may have heard of GDPR’s twin sister, the ePrivacy Regulation, who’s lurking on the legislative horizon. If you haven’t, here’s an introduction.

As I said above, cookie consent — the notice that pops up when you visit a website — is regulated by the GDPR. However, cookies themselves fall under a different piece of legislation, the ePrivacy Directive of 2002, commonly known as the Cookie Law. Like GDPR, it aims to protect customer privacy.

The ePrivacy Directive is due to be replaced by more stringent legislation, the ePrivacy Regulation. (If you’re interested in the difference between EU directives and regulations, EU directives set out the goals for legislation but delegate the implementation of those goals to member states’ legislatures. EU regulations mandate both the goals and the implementation at an EU-wide level.)

The draft ePrivacy Regulation goes beyond cookies and ad tracking. It applies to all electronic communications, including messaging apps, spam mail, IoT data transfer and more.

The draft ePrivacy Regulation was first presented by the EU in 2017. However, it has to be agreed by both the European Parliament and the Council of the European Union. (The Council consists of government representatives of each EU member state.)

This is where it gets messy. Since 2017, the European Parliament and the Council haven’t been able to agree on the scope and detail of the ePrivacy Regulation.

That’s because some countries — widely thought to include the Nordic states of Finland and Denmark — want to strengthen the current ePrivacy Directive. They want users, for example, to be able to set acceptance and rejection of tracking cookies in their browsers, not on every site they visit.

But other countries, notably Austria and believed also to include those with sizeable digital marketing and advertising sectors, say this is bad for business. It’s thought the 27 EU member states are split down the middle on this issue — and they’re all being heavily lobbied by the tech industry.

So the draft regulation has been ricocheting back and forth between the European Commission and its Working Party on Telecommunications and Information Society as they try to agree its scope. In November 2020, the Working Party rejected the redrafted legislation once again.

What happens next? There are two possibilities. Either a compromise will be reached, in which case the legislation will be agreed. Because it takes time for legislation to be implemented, the soonest the ePrivacy Regulation could become law is 2025.

Alternatively, the legislation cannot be agreed and is withdrawn by the European Commission. But the EU has staked so much on it. It will be extremely reluctant to take that step.

That’s why I call it Schrodinger’s Law. It’s hard for us to know how to plan for any cookie-related developments because we simply don’t know what’s happening.

So what should I do about cookies right now?

Different EU countries are currently implementing the ePrivacy Directive differently. Over in the UK, the ICO (the UK’s data protection authority) is taking a tough stance. It’s requiring strict consent for analytics cookies, for example, and has spoken out against cookie walls.

Until — and if — we get consistency from a new ePrivacy Regulation, if you’re based in an EU country, start by following the advice from your national Data Protection Authority. Then watch this space for developments around the ePrivacy Regulation.

If you’re based outside the EU, make sure you’re giving EU citizens the options required under the GDPR and the ePrivacy Directive.

However, when it comes down to the detail, there are times when I recommend taking a risk-based approach. That’s what we’ve done at Cyber-Duck — and here’s why.

Here’s our original cookie notice. You see these everywhere. They’re pretty meaningless — users just hit accept and continue on their way.

But we wanted to be compliant, so we replaced it with this notice. You’ll see that tracking cookies are turned off by default — in line with ICO guidance. We knew there was a risk we would lose analytics data as GTM would no longer fire on first load.

Let’s see what happened.

Problem solved? Actually, no. It just created another problem. The impact was far more significant than we expected:

Look at the collapse in the blue line when we implemented the new cookie notice. We released the new cookie consent on 17 December and went straight from plenty of tracked traffic to almost zero. (The orange line shows the previous year’s traffic, for comparison.)

In both the before-and-after scenarios, the default option was by far the most popular. Most users just naturally click on “accept” or “confirm”. That’s tricky, because we now know so little about the people visiting our site that we can’t give them the best information tailored to their needs.

We needed a solution. Analytics and marketing data ultimately drive business decisions. I’m sure we all know how important data is. In this case, it was like putting money in a bank account and not knowing how much we’d spent or saved!

Some of the solutions that were posed include design alternatives (would removing the toggle, or having two buttons with a visual nudge towards the “accept” help?) Or would we enable analytics cookies by default?

For now, we’ve implemented a compromise position. Marketing and analytics cookies are on by default, with one clear switch to toggle them off:

And here’s what that’s done to our stats:

The new cookie banner was relaunched on 15 January. You can see our website traffic starts to pick back up again. However, we’re not getting the full data we were getting before as Google Tag Manager doesn’t fire unless a user chooses cookies.

The good news is, we are getting some data back again! But the story doesn’t end here. After we had turned cookie tracking back on by default, the attribution model got messed up. It wasn’t attributing to the correct channel in Google Analytics.

Here’s what we mean:

Scenario 1: (Correct Attribution)

  1. User lands on our website via a paid ad (PPC) or from the search result (organic)
  2. User accepts cookies straight away.
  3. The channel source is attributed correctly, e.g. to PPC.

Scenario 2: (Incorrect Attribution)

  1. User lands on our website via a paid ad (PPC) or from the search result (organic)
  2. User visits a few other pages on our website without responding to the cookie banner prompt (banner appears on every page until it gets a response)
  3. User finally accepts cookie banner after browsing a few pages.
  4. Attribution comes through as direct — although they originally came from a search engine.

How does that work? When a user browses other pages on the site, nothing is tracked until they respond to the cookie prompt. Tracking only kicks in at that point. So to Google, it looks as though the user has just landed on that page — and they are attributed to Direct traffic.

Back to the drawing board.

Note: I’m sure by now you’re starting to see a pattern here. This entire experience is new for us and there’s not a lot of documentation around, so it’s been a real learning curve.

Now, how could we solve this attribution issue and stop users from navigating around the site until they’ve selected their cookie preference?

A cookie wall is one option we considered, but that would potentially push us further away from being compliant, according to the ICO. (Though you might like to try browsing their site incognito and see if they stick to their own guidance…)

But that’s what we’ve chosen to go with. The journey ends here for now, as we’re still gathering data. In the future, we want to explore other tools and the potential impact of moving away from Google Analytics.

So what’s everyone else doing?

Well, McDonald’s UK offers straightforward on/off buttons:

Coca Cola’s British site nudges you to accept by making the ‘reject’ option harder to find:

Whereas Sanrio just has an option to agree to ad tracking:

Hello Kitty, hello cookies.

Die Zeit offers free access if you accept tracking cookies — but for an untracked, ad-free experience you’ll have to pay:

And here’s one of my favourite dark patterns. This restaurant site only has the ‘Necessary’ cookies selected. But it nudges you to the ‘Allow all cookies’ big red button — and when you click that, the analytical and ad cookie boxes are automatically checked and set. Give it a go here!

Even the EU isn’t consistent on its own sites.

The European Parliament’s cookie consent offers two clear options:

The CJEU’s site isn’t so clear:

While Europol’s site comes with two pre-checked boxes:

And if you look at the sites for the German presidency of the Council of the European Union (July–December 2020), at first it seems as if there’s no cookies at all:

When you land on the site, there are no cookie banners or prompts. A closer look, with cookie extension tools, shows that no cookies are being placed either.

So are they capturing any analytics data? The answer is yes.

We found this little snippet in their code, which shows they are using ‘Piwik’. Piwik is now known as Matomo, one of a clutch of new tools that help with cookie compliance along with Fathom (server-side tracking) and HelloConsent (cookie management).

So alternatives and solutions are emerging. We’ll take a closer look at that next time — with new alternatives to third-party cookies that will help you take control of your data and get the insight you need to deliver optimum experiences to your customers. Stay tuned!

Further Reading

Articles on Smashing Magazine — For Web Designers And Developers

01 Mar

State Of GDPR In 2021: Cookie Consent For Designers And Developers

by TBSCategories: News

Last week, I gave you an update on everything that’s happened with GDPR since 2018. (TL;DR: A lot has changed.) In this article, we’ll look at cookie consent: specifically, the paradox where marketers are heavily reliant on Google Analytics cookie data but need to comply with regulations.

We’ll take a look at two developments that have impacted cookies, plus a third on the horizon. Then I’ll walk you through the risk-based approach that we’ve taken — for the moment, at least. And come back next time for a deep dive into first-party ad tracking as we start to see moves away from third-party cookies.

Big Development #1: Cookie Consent

In May 2020, the EU updated its GDPR guidance to clarify several points, including two key points for cookie consent:

  • Cookie walls do not offer users a genuine choice, because if you reject cookies you’re blocked from accessing content. It confirms that cookie walls should not be used.
  • Scrolling or swiping through web content does not equate to implied consent. The EU reiterates that consent must be explicit.

What does this mean for our industry?

Well, the EU is tightening up on cookie consent — perhaps the most noticeable (and annoying!) aspect of GDPR. Critics say that cookie notices are a cumbersome block for users, and don’t do anything to protect user privacy. The EU is trying to change this, by promoting simple, meaningful, equitable options for cookie consent.

But that restricts what we can do with cookies, and it hints ahead to when the Privacy and Electronic Communications Regulation (PECR) may come into force. More on that shortly.

Big Development #2: Google and Apple crack down on third-party tracking; get hit by anti-trust complaints

As the big digital players figure out how to comply with GDPR — and how to turn privacy legislation to their advantage — some have already come under fire.

Google is being investigated by the UK’s competition watchdog, the Competition and Markets Authority (CMA), for its ‘Privacy Sandbox’ initiative, following complaints from adtech companies and publishers.

The Internet giant, which is also facing an antitrust investigation in Italy for display advertising, and in the US for its search advertising services, is looking to remove third-party cookies from Chrome. (Firefox and Safari already block these cookies by default.)

The complainants say that this change will further concentrate advertising revenue in Google’s hands. Google’s response? The advertising industry needs to make ‘major changes’ as it shifts to a ‘web without third-party cookies’.

Google’s not alone. In October 2020, four French digital advertising lobbies filed an antitrust suit against Apple’s forthcoming iOS privacy change, a feature it’s called App Tracking Transparency (ATT).

ATT, coming in an early-spring 2021 release of iOS 14, shifts app users from an opt-out to an opt-in ad-tracking model. With ATT, every app must get your permission to share your Identifier for Advertisers (IDFA), which enables third-party ad tracking across multiple sites and channels.

The complainants say that by restricting apps’ ad revenue, developers may have to boost app subscriptions and in-app purchases or switch to Apple’s targeted ad platform — all of which will funnel ad spend away from them and towards Cupertino.

Critics including Facebook have slammed the change, saying it’ll hit small businesses who rely on microtargeted ads. Apple has defended the move and praised the EU’s defence of citizens’ data privacy.

To sum up:

  • Implied consent doesn’t equal consent under GDPR, according to the EU.
  • We should also avoid cookie walls
  • Google and Apple are moving against third-party cookies — which some say exploits their dominant market position.

So what does that mean for us, as designers and developers? First, let’s take a look at why this is important.

Here’s What Designers Should Know About Cookies

  • GDPR is critical for you because you’ll design the points at which cookies are placed, what data is collected, and how it’s processed.
  • A functionality audit means you can map your cookie activity in the data and compliance layers on your service blueprint.
  • It can help to do a cookie audit and gap analysis, i.e. is the existing cookie pattern compliant? What content does it need around it?
  • Follow Privacy by Design best practices. Don’t try to reinvent the wheel — if you’ve created a compliant cookie banner, use your proven design pattern.
  • Work with your compliance and development teams to ensure designs meet GDPR and can be implemented. Only ask for the data you need.
  • If you need to compromise, take a risk-based approach. There’s a walk-through of one that we did further down.
  • Be aware that your content team may need to update your privacy policy as GDPR and your use of cookies evolve.

Here’s What Developers Should Know About Cookies

  • Make sure you’re involved upfront about cookie consent and tracking, so what’s decided can be implemented.
  • If you’re doing a product or website redesign, a cookie audit using Chrome Dev Tools can show you what tracking cookies are being used. Tools like Ghostery or Cookiebot give you more detail.
  • You should implement the standard cookie opt in/out as per GDPR guidance. (Note that while GDPR is standard, the enforcement of it varies across EU countries. There’s more on this further down.) You may stand to lose Google Analytics data. You might also come under pressure to implement things that could be considered as dark patterns. There’s more on this later, with a walk-through of what we did and a look at the risk.

So that’s where we are today. Oh, and there’s one more thing to be aware of: a piece of further legislation that might be coming our way. I like to call it Schrodinger’s Law.

Schrodinger’s Law: The ePrivacy Regulation

You may have heard of GDPR’s twin sister, the ePrivacy Regulation, who’s lurking on the legislative horizon. If you haven’t, here’s an introduction.

As I said above, cookie consent — the notice that pops up when you visit a website — is regulated by the GDPR. However, cookies themselves fall under a different piece of legislation, the ePrivacy Directive of 2002, commonly known as the Cookie Law. Like GDPR, it aims to protect customer privacy.

The ePrivacy Directive is due to be replaced by more stringent legislation, the ePrivacy Regulation. (If you’re interested in the difference between EU directives and regulations, EU directives set out the goals for legislation but delegate the implementation of those goals to member states’ legislatures. EU regulations mandate both the goals and the implementation at an EU-wide level.)

The draft ePrivacy Regulation goes beyond cookies and ad tracking. It applies to all electronic communications, including messaging apps, spam mail, IoT data transfer and more.

The draft ePrivacy Regulation was first presented by the EU in 2017. However, it has to be agreed by both the European Parliament and the Council of the European Union. (The Council consists of government representatives of each EU member state.)

This is where it gets messy. Since 2017, the European Parliament and the Council haven’t been able to agree on the scope and detail of the ePrivacy Regulation.

That’s because some countries — widely thought to include the Nordic states of Finland and Denmark — want to strengthen the current ePrivacy Directive. They want users, for example, to be able to set acceptance and rejection of tracking cookies in their browsers, not on every site they visit.

But other countries, notably Austria and believed also to include those with sizeable digital marketing and advertising sectors, say this is bad for business. It’s thought the 27 EU member states are split down the middle on this issue — and they’re all being heavily lobbied by the tech industry.

So the draft regulation has been ricocheting back and forth between the European Commission and its Working Party on Telecommunications and Information Society as they try to agree its scope. In November 2020, the Working Party rejected the redrafted legislation once again.

What happens next? There are two possibilities. Either a compromise will be reached, in which case the legislation will be agreed. Because it takes time for legislation to be implemented, the soonest the ePrivacy Regulation could become law is 2025.

Alternatively, the legislation cannot be agreed and is withdrawn by the European Commission. But the EU has staked so much on it. It will be extremely reluctant to take that step.

That’s why I call it Schrodinger’s Law. It’s hard for us to know how to plan for any cookie-related developments because we simply don’t know what’s happening.

So what should I do about cookies right now?

Different EU countries are currently implementing the ePrivacy Directive differently. Over in the UK, the ICO (the UK’s data protection authority) is taking a tough stance. It’s requiring strict consent for analytics cookies, for example, and has spoken out against cookie walls.

Until — and if — we get consistency from a new ePrivacy Regulation, if you’re based in an EU country, start by following the advice from your national Data Protection Authority. Then watch this space for developments around the ePrivacy Regulation.

If you’re based outside the EU, make sure you’re giving EU citizens the options required under the GDPR and the ePrivacy Directive.

However, when it comes down to the detail, there are times when I recommend taking a risk-based approach. That’s what we’ve done at Cyber-Duck — and here’s why.

Here’s our original cookie notice. You see these everywhere. They’re pretty meaningless — users just hit accept and continue on their way.

But we wanted to be compliant, so we replaced it with this notice. You’ll see that tracking cookies are turned off by default — in line with ICO guidance. We knew there was a risk we would lose analytics data as GTM would no longer fire on first load.

Let’s see what happened.

Problem solved? Actually, no. It just created another problem. The impact was far more significant than we expected:

Look at the collapse in the blue line when we implemented the new cookie notice. We released the new cookie consent on 17 December and went straight from plenty of tracked traffic to almost zero. (The orange line shows the previous year’s traffic, for comparison.)

In both the before-and-after scenarios, the default option was by far the most popular. Most users just naturally click on “accept” or “confirm”. That’s tricky, because we now know so little about the people visiting our site that we can’t give them the best information tailored to their needs.

We needed a solution. Analytics and marketing data ultimately drive business decisions. I’m sure we all know how important data is. In this case, it was like putting money in a bank account and not knowing how much we’d spent or saved!

Some of the solutions that were posed include design alternatives (would removing the toggle, or having two buttons with a visual nudge towards the “accept” help?) Or would we enable analytics cookies by default?

For now, we’ve implemented a compromise position. Marketing and analytics cookies are on by default, with one clear switch to toggle them off:

And here’s what that’s done to our stats:

The new cookie banner was relaunched on 15 January. You can see our website traffic starts to pick back up again. However, we’re not getting the full data we were getting before as Google Tag Manager doesn’t fire unless a user chooses cookies.

The good news is, we are getting some data back again! But the story doesn’t end here. After we had turned cookie tracking back on by default, the attribution model got messed up. It wasn’t attributing to the correct channel in Google Analytics.

Here’s what we mean:

Scenario 1: (Correct Attribution)

  1. User lands on our website via a paid ad (PPC) or from the search result (organic)
  2. User accepts cookies straight away.
  3. The channel source is attributed correctly, e.g. to PPC.

Scenario 2: (Incorrect Attribution)

  1. User lands on our website via a paid ad (PPC) or from the search result (organic)
  2. User visits a few other pages on our website without responding to the cookie banner prompt (banner appears on every page until it gets a response)
  3. User finally accepts cookie banner after browsing a few pages.
  4. Attribution comes through as direct — although they originally came from a search engine.

How does that work? When a user browses other pages on the site, nothing is tracked until they respond to the cookie prompt. Tracking only kicks in at that point. So to Google, it looks as though the user has just landed on that page — and they are attributed to Direct traffic.

Back to the drawing board.

Note: I’m sure by now you’re starting to see a pattern here. This entire experience is new for us and there’s not a lot of documentation around, so it’s been a real learning curve.

Now, how could we solve this attribution issue and stop users from navigating around the site until they’ve selected their cookie preference?

A cookie wall is one option we considered, but that would potentially push us further away from being compliant, according to the ICO. (Though you might like to try browsing their site incognito and see if they stick to their own guidance…)

But that’s what we’ve chosen to go with. The journey ends here for now, as we’re still gathering data. In the future, we want to explore other tools and the potential impact of moving away from Google Analytics.

So what’s everyone else doing?

Well, McDonald’s UK offers straightforward on/off buttons:

Coca Cola’s British site nudges you to accept by making the ‘reject’ option harder to find:

Whereas Sanrio just has an option to agree to ad tracking:

Hello Kitty, hello cookies.

Die Zeit offers free access if you accept tracking cookies — but for an untracked, ad-free experience you’ll have to pay:

And here’s one of my favourite dark patterns. This restaurant site only has the ‘Necessary’ cookies selected. But it nudges you to the ‘Allow all cookies’ big red button — and when you click that, the analytical and ad cookie boxes are automatically checked and set. Give it a go here!

Even the EU isn’t consistent on its own sites.

The European Parliament’s cookie consent offers two clear options:

The CJEU’s site isn’t so clear:

While Europol’s site comes with two pre-checked boxes:

And if you look at the sites for the German presidency of the Council of the European Union (July–December 2020), at first it seems as if there’s no cookies at all:

When you land on the site, there are no cookie banners or prompts. A closer look, with cookie extension tools, shows that no cookies are being placed either.

So are they capturing any analytics data? The answer is yes.

We found this little snippet in their code, which shows they are using ‘Piwik’. Piwik is now known as Matomo, one of a clutch of new tools that help with cookie compliance along with Fathom (server-side tracking) and HelloConsent (cookie management).

So alternatives and solutions are emerging. We’ll take a closer look at that next time — with new alternatives to third-party cookies that will help you take control of your data and get the insight you need to deliver optimum experiences to your customers. Stay tuned!

Further Reading

Articles on Smashing Magazine — For Web Designers And Developers

01 Mar

State Of GDPR In 2021: Cookie Consent For Designers And Developers

by TBSCategories: News

Last week, I gave you an update on everything that’s happened with GDPR since 2018. (TL;DR: A lot has changed.) In this article, we’ll look at cookie consent: specifically, the paradox where marketers are heavily reliant on Google Analytics cookie data but need to comply with regulations.

We’ll take a look at two developments that have impacted cookies, plus a third on the horizon. Then I’ll walk you through the risk-based approach that we’ve taken — for the moment, at least. And come back next time for a deep dive into first-party ad tracking as we start to see moves away from third-party cookies.

Big Development #1: Cookie Consent

In May 2020, the EU updated its GDPR guidance to clarify several points, including two key points for cookie consent:

  • Cookie walls do not offer users a genuine choice, because if you reject cookies you’re blocked from accessing content. It confirms that cookie walls should not be used.
  • Scrolling or swiping through web content does not equate to implied consent. The EU reiterates that consent must be explicit.

What does this mean for our industry?

Well, the EU is tightening up on cookie consent — perhaps the most noticeable (and annoying!) aspect of GDPR. Critics say that cookie notices are a cumbersome block for users, and don’t do anything to protect user privacy. The EU is trying to change this, by promoting simple, meaningful, equitable options for cookie consent.

But that restricts what we can do with cookies, and it hints ahead to when the Privacy and Electronic Communications Regulation (PECR) may come into force. More on that shortly.

Big Development #2: Google and Apple crack down on third-party tracking; get hit by anti-trust complaints

As the big digital players figure out how to comply with GDPR — and how to turn privacy legislation to their advantage — some have already come under fire.

Google is being investigated by the UK’s competition watchdog, the Competition and Markets Authority (CMA), for its ‘Privacy Sandbox’ initiative, following complaints from adtech companies and publishers.

The Internet giant, which is also facing an antitrust investigation in Italy for display advertising, and in the US for its search advertising services, is looking to remove third-party cookies from Chrome. (Firefox and Safari already block these cookies by default.)

The complainants say that this change will further concentrate advertising revenue in Google’s hands. Google’s response? The advertising industry needs to make ‘major changes’ as it shifts to a ‘web without third-party cookies’.

Google’s not alone. In October 2020, four French digital advertising lobbies filed an antitrust suit against Apple’s forthcoming iOS privacy change, a feature it’s called App Tracking Transparency (ATT).

ATT, coming in an early-spring 2021 release of iOS 14, shifts app users from an opt-out to an opt-in ad-tracking model. With ATT, every app must get your permission to share your Identifier for Advertisers (IDFA), which enables third-party ad tracking across multiple sites and channels.

The complainants say that by restricting apps’ ad revenue, developers may have to boost app subscriptions and in-app purchases or switch to Apple’s targeted ad platform — all of which will funnel ad spend away from them and towards Cupertino.

Critics including Facebook have slammed the change, saying it’ll hit small businesses who rely on microtargeted ads. Apple has defended the move and praised the EU’s defence of citizens’ data privacy.

To sum up:

  • Implied consent doesn’t equal consent under GDPR, according to the EU.
  • We should also avoid cookie walls
  • Google and Apple are moving against third-party cookies — which some say exploits their dominant market position.

So what does that mean for us, as designers and developers? First, let’s take a look at why this is important.

Here’s What Designers Should Know About Cookies

  • GDPR is critical for you because you’ll design the points at which cookies are placed, what data is collected, and how it’s processed.
  • A functionality audit means you can map your cookie activity in the data and compliance layers on your service blueprint.
  • It can help to do a cookie audit and gap analysis, i.e. is the existing cookie pattern compliant? What content does it need around it?
  • Follow Privacy by Design best practices. Don’t try to reinvent the wheel — if you’ve created a compliant cookie banner, use your proven design pattern.
  • Work with your compliance and development teams to ensure designs meet GDPR and can be implemented. Only ask for the data you need.
  • If you need to compromise, take a risk-based approach. There’s a walk-through of one that we did further down.
  • Be aware that your content team may need to update your privacy policy as GDPR and your use of cookies evolve.

Here’s What Developers Should Know About Cookies

  • Make sure you’re involved upfront about cookie consent and tracking, so what’s decided can be implemented.
  • If you’re doing a product or website redesign, a cookie audit using Chrome Dev Tools can show you what tracking cookies are being used. Tools like Ghostery or Cookiebot give you more detail.
  • You should implement the standard cookie opt in/out as per GDPR guidance. (Note that while GDPR is standard, the enforcement of it varies across EU countries. There’s more on this further down.) You may stand to lose Google Analytics data. You might also come under pressure to implement things that could be considered as dark patterns. There’s more on this later, with a walk-through of what we did and a look at the risk.

So that’s where we are today. Oh, and there’s one more thing to be aware of: a piece of further legislation that might be coming our way. I like to call it Schrodinger’s Law.

Schrodinger’s Law: The ePrivacy Regulation

You may have heard of GDPR’s twin sister, the ePrivacy Regulation, who’s lurking on the legislative horizon. If you haven’t, here’s an introduction.

As I said above, cookie consent — the notice that pops up when you visit a website — is regulated by the GDPR. However, cookies themselves fall under a different piece of legislation, the ePrivacy Directive of 2002, commonly known as the Cookie Law. Like GDPR, it aims to protect customer privacy.

The ePrivacy Directive is due to be replaced by more stringent legislation, the ePrivacy Regulation. (If you’re interested in the difference between EU directives and regulations, EU directives set out the goals for legislation but delegate the implementation of those goals to member states’ legislatures. EU regulations mandate both the goals and the implementation at an EU-wide level.)

The draft ePrivacy Regulation goes beyond cookies and ad tracking. It applies to all electronic communications, including messaging apps, spam mail, IoT data transfer and more.

The draft ePrivacy Regulation was first presented by the EU in 2017. However, it has to be agreed by both the European Parliament and the Council of the European Union. (The Council consists of government representatives of each EU member state.)

This is where it gets messy. Since 2017, the European Parliament and the Council haven’t been able to agree on the scope and detail of the ePrivacy Regulation.

That’s because some countries — widely thought to include the Nordic states of Finland and Denmark — want to strengthen the current ePrivacy Directive. They want users, for example, to be able to set acceptance and rejection of tracking cookies in their browsers, not on every site they visit.

But other countries, notably Austria and believed also to include those with sizeable digital marketing and advertising sectors, say this is bad for business. It’s thought the 27 EU member states are split down the middle on this issue — and they’re all being heavily lobbied by the tech industry.

So the draft regulation has been ricocheting back and forth between the European Commission and its Working Party on Telecommunications and Information Society as they try to agree its scope. In November 2020, the Working Party rejected the redrafted legislation once again.

What happens next? There are two possibilities. Either a compromise will be reached, in which case the legislation will be agreed. Because it takes time for legislation to be implemented, the soonest the ePrivacy Regulation could become law is 2025.

Alternatively, the legislation cannot be agreed and is withdrawn by the European Commission. But the EU has staked so much on it. It will be extremely reluctant to take that step.

That’s why I call it Schrodinger’s Law. It’s hard for us to know how to plan for any cookie-related developments because we simply don’t know what’s happening.

So what should I do about cookies right now?

Different EU countries are currently implementing the ePrivacy Directive differently. Over in the UK, the ICO (the UK’s data protection authority) is taking a tough stance. It’s requiring strict consent for analytics cookies, for example, and has spoken out against cookie walls.

Until — and if — we get consistency from a new ePrivacy Regulation, if you’re based in an EU country, start by following the advice from your national Data Protection Authority. Then watch this space for developments around the ePrivacy Regulation.

If you’re based outside the EU, make sure you’re giving EU citizens the options required under the GDPR and the ePrivacy Directive.

However, when it comes down to the detail, there are times when I recommend taking a risk-based approach. That’s what we’ve done at Cyber-Duck — and here’s why.

Here’s our original cookie notice. You see these everywhere. They’re pretty meaningless — users just hit accept and continue on their way.

But we wanted to be compliant, so we replaced it with this notice. You’ll see that tracking cookies are turned off by default — in line with ICO guidance. We knew there was a risk we would lose analytics data as GTM would no longer fire on first load.

Let’s see what happened.

Problem solved? Actually, no. It just created another problem. The impact was far more significant than we expected:

Look at the collapse in the blue line when we implemented the new cookie notice. We released the new cookie consent on 17 December and went straight from plenty of tracked traffic to almost zero. (The orange line shows the previous year’s traffic, for comparison.)

In both the before-and-after scenarios, the default option was by far the most popular. Most users just naturally click on “accept” or “confirm”. That’s tricky, because we now know so little about the people visiting our site that we can’t give them the best information tailored to their needs.

We needed a solution. Analytics and marketing data ultimately drive business decisions. I’m sure we all know how important data is. In this case, it was like putting money in a bank account and not knowing how much we’d spent or saved!

Some of the solutions that were posed include design alternatives (would removing the toggle, or having two buttons with a visual nudge towards the “accept” help?) Or would we enable analytics cookies by default?

For now, we’ve implemented a compromise position. Marketing and analytics cookies are on by default, with one clear switch to toggle them off:

And here’s what that’s done to our stats:

The new cookie banner was relaunched on 15 January. You can see our website traffic starts to pick back up again. However, we’re not getting the full data we were getting before as Google Tag Manager doesn’t fire unless a user chooses cookies.

The good news is, we are getting some data back again! But the story doesn’t end here. After we had turned cookie tracking back on by default, the attribution model got messed up. It wasn’t attributing to the correct channel in Google Analytics.

Here’s what we mean:

Scenario 1: (Correct Attribution)

  1. User lands on our website via a paid ad (PPC) or from the search result (organic)
  2. User accepts cookies straight away.
  3. The channel source is attributed correctly, e.g. to PPC.

Scenario 2: (Incorrect Attribution)

  1. User lands on our website via a paid ad (PPC) or from the search result (organic)
  2. User visits a few other pages on our website without responding to the cookie banner prompt (banner appears on every page until it gets a response)
  3. User finally accepts cookie banner after browsing a few pages.
  4. Attribution comes through as direct — although they originally came from a search engine.

How does that work? When a user browses other pages on the site, nothing is tracked until they respond to the cookie prompt. Tracking only kicks in at that point. So to Google, it looks as though the user has just landed on that page — and they are attributed to Direct traffic.

Back to the drawing board.

Note: I’m sure by now you’re starting to see a pattern here. This entire experience is new for us and there’s not a lot of documentation around, so it’s been a real learning curve.

Now, how could we solve this attribution issue and stop users from navigating around the site until they’ve selected their cookie preference?

A cookie wall is one option we considered, but that would potentially push us further away from being compliant, according to the ICO. (Though you might like to try browsing their site incognito and see if they stick to their own guidance…)

But that’s what we’ve chosen to go with. The journey ends here for now, as we’re still gathering data. In the future, we want to explore other tools and the potential impact of moving away from Google Analytics.

So what’s everyone else doing?

Well, McDonald’s UK offers straightforward on/off buttons:

Coca Cola’s British site nudges you to accept by making the ‘reject’ option harder to find:

Whereas Sanrio just has an option to agree to ad tracking:

Hello Kitty, hello cookies.

Die Zeit offers free access if you accept tracking cookies — but for an untracked, ad-free experience you’ll have to pay:

And here’s one of my favourite dark patterns. This restaurant site only has the ‘Necessary’ cookies selected. But it nudges you to the ‘Allow all cookies’ big red button — and when you click that, the analytical and ad cookie boxes are automatically checked and set. Give it a go here!

Even the EU isn’t consistent on its own sites.

The European Parliament’s cookie consent offers two clear options:

The CJEU’s site isn’t so clear:

While Europol’s site comes with two pre-checked boxes:

And if you look at the sites for the German presidency of the Council of the European Union (July–December 2020), at first it seems as if there’s no cookies at all:

When you land on the site, there are no cookie banners or prompts. A closer look, with cookie extension tools, shows that no cookies are being placed either.

So are they capturing any analytics data? The answer is yes.

We found this little snippet in their code, which shows they are using ‘Piwik’. Piwik is now known as Matomo, one of a clutch of new tools that help with cookie compliance along with Fathom (server-side tracking) and HelloConsent (cookie management).

So alternatives and solutions are emerging. We’ll take a closer look at that next time — with new alternatives to third-party cookies that will help you take control of your data and get the insight you need to deliver optimum experiences to your customers. Stay tuned!

Further Reading

Articles on Smashing Magazine — For Web Designers And Developers

google-translate-dashboard
24 Sep

4 Lessons Web App Designers Can Learn From Google

by TBSCategories: News

Whenever I’m curious about what more we could be doing to improve our users’ experiences, the first place I look to is Google. More specifically, I go to the Google Developers site or Think with Google to pull the latest consumer data.

But I was thinking today, “Why don’t we just copy what Google does?”

After all, Google has to walk the walk. If not, how would it ever convince anyone to adhere to its SEO and UX recommendations and guidelines?

The only thing is, Google’s sites and apps aren’t very attractive. They’re practical and intuitive, that’s for sure. But designs worth emulating? Eh.

That doesn’t really matter though. The basic principles for building a good web app exist across each of its platforms. So, if we’re looking for a definitive answer on what will provide SaaS users with the best experience, I think we need to start by dissecting Google’s platforms.

What Google Teaches Us About Good Web App Design

What we want to focus on are the components that make Google’s products so easy to use time and time again. By replicating these features within your own app, you’ll effectively reduce (if not altogether remove) the friction your users would otherwise encounter.

1. Make the First Thing They See Their Top Priority

When users enter your dashboard, the last thing you want is for them to be overwhelmed. Their immediate impression whenever they enter your app or return to the dashboard should be:

“I’m exactly where I need to be.”

Not:

“What the heck is going on here? Where do I find X?”

Now, depending on the purpose of your app, there are usually one or two things your users are going to be most concerned with.

Let’s say you have an app like Google Translate that has a clear utilitarian purpose. There’s absolutely no excuse for cluttering the main page. They’ve come here to do one thing:

So, don’t waste their time. Place the tool front and center and let all other pages, settings or notices appear as secondary features of the app.

Something else this example teaches us is how you should configure your tool for users. Google could easily just leave this open-ended, but it defaults to:

Default Language —> English

Google’s data likely shows that this is the most popular way users use this app.

Although you can’t see it in the desktop app, you can see it on mobile. The formula goes like this:

Default Language —> Recent Language

I suspect that, for first-time users, Google will set the translation to the user’s native language (as indicated in their Google user settings).

If you have the data available, use it to configure defaults that reduce the number of steps your users have to take, too.

Not every web app provides users with a hands-on tool for solving a problem. In some cases, apps enable users to streamline and automate complex processes, which means their primary concern is going to be how well those processes are performing.

For that, we can look at a product like Google Search Console, which connects users to data on how their sites perform in Google search as well as insights into problems that might be holding them back.

It’s no surprise then that the first thing they see upon entering it is this:

Performance (the number of clicks in Google search) and Coverage (number of pages indexed without error) are above the fold. Below it is another chart that displays recommended enhancements to improve core web vitals, mobile usability and sitelinks searchbox visibility.

Bottom line: The Overview page isn’t littered with charts depicting every data point collected by Google Search Console. Instead, it displays only the top priorities so users can get a bird’s-eye view of what’s going on and not get lost in data they don’t need at that time.

2. Create a Useful and Simple Navigation Wherever Relevant

This one seems like a no-brainer, but I’ll show you why I bring it up.

Zoom is a great video conferencing app. There’s no arguing that. However, when users want to schedule a meeting from their browser, this is what they see:

The “Join Meeting” and “Host Meeting” options are fine as they both eventually push the user into the desktop app. However, the “Schedule Meeting” in-browser experience isn’t great because it leaves the website navigation bars in place, which only serves as a distraction from the app’s sidebar on the left.

Once your users have created a login and have access to your app, they don’t need to see your site anymore. Ditch the website navigation and let them be submersed in the app.

Or do as Google Hangouts does. Lay your app out the way users expect an app to be laid out:

  • Primary navigation along the left side,
  • Hamburger menu button and/or More (…) button contain the secondary navigation,
  • Wide open space for users to play in the app.

But Google Hangouts doesn’t do away with the google.com website completely. For users that want to quickly navigate to one of Google’s other products, they can use the grid-shaped icon in the top-right corner. So, if you feel it’s necessary for your users to be able to visit your website once again, you can build it into the app that way.

This example also demonstrates how important it is to keep your navigation as simple as possible.

Google Hangouts’ primary navigation uses symbols to represent each of the app’s tabs/options:

While I think it’s okay for Google Hangouts to get away with this icon-only menu design, be careful with this approach. Unless the icons are universally understood (like the hamburger menu, search magnifying glass, or the plus sign), you can’t risk introducing icons that create more confusion.

As NNG points out, there’s a difference between an icon being recognizable and its meaning being indisputable.

So, one way you can get around this is to make the outward appearance of the menu icon-only. But upon hover, the labels appear so that users have additional context for what each means.

As for any secondary navigation you might need — including a Settings navigation — you can write out the labels since it will only appear upon user activation.

Although some of the icons would be easy enough to identify, not all of them would instantly be recognizable (like “Invites” and “Hangouts Dialer”). If even one tab in your secondary navigation is rarely seen across other apps, spell them all out.

One last thing: The divider lines in this menu are a great choice. Rather than jam 10 tabs/options into this navigation bar together, they’re logically grouped, making it easier for users to find what they’re looking for.

3. Provide Users with Predictive Search Functionality

Every app should have a search bar. It might be there to help users sift through content, to find the contact they’re looking for from a long list, or to ask a question about something in the app.

The more complex your app is, the more critical a role internal search is going to play. But if you want to improve your users’ search experience even more, you’ll want to power yours with predictive search functionality.

Even though I’m sure you have a Support line, maybe a chatbot and perhaps an FAQs or Knowledgebase to help users find what they need, a smart search bar can connect them to what they’re really looking for (even if they don’t know how to articulate it).

Google has this search functionality baked into most of its products.

You’re familiar with autocomplete within the Google search engine itself. But here are some other use cases for smart search capabilities.

Google Drive connects users to documents (of all types — Docs, Sheets, Slides and more) as well as collaborators that match the search query.

Users can, of course, be taken to a full search results page. However, the search bar itself predicts which content is the most relevant for the query. In this case, these are the most recent pieces of content I’ve written that include the term “speed” in the title.

Google Maps is a neat use case as it pulls data from a variety of connected (Google) sources to try and predict what its users are looking for.

In this example, I typed in “Alicia”. Now, Google Maps knows me pretty well, so the first result is actually the address of one of my contacts. The remaining results are for addresses or businesses within a 45-mile radius containing the word “Alicia”.

It doesn’t just pull from there though. This is one of those cases where the more enjoyable you make the in-app experience, the more your users will engage with it — which means more data.

For example, this is what I see when I search for “Three”:

The very first thing it pulls up is a restaurant called Three Sisters (which is a fantastic restaurant in the city of Providence, by the way). If you look just above the center of the map where the red heart is, that’s the restaurant. This means that I’ve added it to my Favorite places and Google Maps actually calls it out as such in my search results.

Imagine how much more your users would love your app if it wasn’t always a struggle to get to the content, data or page they were looking for. Or to perform a desired action. When you give your users the ability to personalize their experience like this, use the information they’ve given you to improve their search experience, too.

4. Enable Users to Change the Design and Layout of the App

As a designer, you can do your best to design a great experience for your users. But let’s face it:

You’re never going to please everyone.

Unlike a website, though, which is pretty much what-you-see-is-what-you-get, SaaS users have the ability to change the design and layout of what they’re interacting with — if you let them. And you should.

There are many different ways this might apply to the app you’ve built.

Google Calendar, for example, has a ton of customization options available.

On the far left is a list of “My calendars”. Users can click which calendars and associated events they want to see within the app.

In the bottom-right corner is an arrowhead. This enables users to hide the Google apps side panel and give them more room to focus on upcoming events and appointments.

In the top-right, users have two places where they can customize their calendar:

  • The Settings bar allows them to adjust the color and density of the calendar.
  • The “Month” dropdown allows them to adjust how much of the calendar is seen at once.

These customizations would all be useful for any sort of project management, planning or appointment scheduling app.

For other apps, I’d recommend looking at Gmail. It’s chock full of customizations that you could adapt for your app.

Previously, if users clicked the Settings widget, it would move them out of the app and into the dedicated settings panel. To be honest, it was annoying, especially if you just wanted to make a small tweak.

Now, the Settings button opens this panel within Gmail. It enables users to adjust things like:

  • Line spacing,
  • Background theme,
  • Inbox sorting priorities,
  • Reading pane layout,
  • Conversation view on/off.

This is a recent update to Gmail’s settings, which probably means these are the most commonly used design customizations its users actually use.

For any customizations users want to make that they can’t find in this new panel, they can click “See all settings” and customize the in-app design and layout (among other things) even further.

Other customizations you might find value in enabling in your app are:

  • Keyboard control,
  • Dark mode,
  • Color-blind mode,
  • Text resizing,
  • List/grid view toggling,
  • Widget and banner hiding,
  • Columns displayed.

Not only do these design and layout controls enable users to create an interface they enjoy looking at and that works better for their purposes, it can also help with accessibility.

Wrapping Up

There’s a reason why Google dominates market share with many of its products. It gets the user experience. Of course, this is due largely to the fact that it has access to more user data than most companies.

And while we should be designing solutions for our specific audiences, there’s no denying that Google’s products can help us set a really strong base for any audience — if we just pay attention to the trends across its platforms.

Further Reading on SmashingMag:

Articles on Smashing Magazine — For Web Designers And Developers

11 Sep

The Renaissance Of No-Code For Web Designers

by TBSCategories: News

The word Renaissance — which means “rebirth” in French — was given to a tremendous period of philosophical and artistic achievements that began in the 14th century.

During this time, there were a wide range of developments, including:

  • Use of oil paints, rather than tempera, which made the painting process easier.
  • Use of fabric, rather than wooden boards, which reduced the expenses of painting.
  • Translation of classical texts in architecture, anatomy, philosophy, and more, making knowledge more accessible to the general public.

These developments and more made the Renaissance one of the most productive artistic eras in history, dramatically reducing the creative barrier and attracting a large audience rather than just a small group of elites.

Just like the Renaissance era, today’s web design field is exploring its potential through no-code development platforms (NCDPs). These tools allow non-programmers to create application software through graphical user interfaces and configuration, instead of traditional computer programming.

The Designer/Developer Mental Model

In 2000, usability expert Jakob Nielsen introduced “Jakob’s Law,” the idea that users develop mental models of the products they interact with based on their previous experience. The more users can focus on their goal without challenging this mental model, the easier it is for them to achieve that goal.

“CSS is closer to painting than Python.”
— Chris Coyier, co-founder at CodePen

Design and development skills are rooted in different types of thinking and require different types of tools. While designers use WYSIWYG editors like Figma, Sketch, and Photoshop to place elements on the canvas, developers work with IDEs like VSCode, Webstorm, and Brackets. In order to remain productive, designers and developers need to be able to make changes and receive instant feedback, according to their mental model.

So, using drag and drop builders may actually interfere with developers who want to debug fast, but working only with a text editor may be inappropriate for designers who want to test composition.

Designers And Code

Many designers understand the functional differences between a mockup and a working product. In order to understand the possibilities of the medium, where to draw the boundaries and how to deal with the constraints, many designers are willing to “get their hands dirty” when it comes to learning code — but they have difficulties.

One of the main reasons designers are not coders is because there is a large gap between the designer’s mental model and the conceptual model of many code editors. Design and development take two very different modes of thought. This mismatch leads to a difficult and frustrating learning curve for designers that they might not be able to overcome.

Code Abstraction

Abstraction is a core concept of computer science. Languages, frameworks, and libraries are built on different abstraction layers of complexity to facilitate, optimize, and guarantee productivity.

“Visual programming tools abstract code away from the creator, making them significantly more accessible. The real magic of these tools, however, is how they integrate all of the underlying layers of software into end products, providing useful functionality through modular components that can be harnessed through intuitive visual interfaces.”
— Jeremy Q. Ho, No Code is New Programming

When working with abstraction layers, there are tools such as Editor X and Studio for websites/web applications, Draftbit and Kodika for mobile apps, and Modulz for design systems, which enable a visual representation of code, in addition to code capabilities.

By adopting a familiar visual medium, the learning curve becomes easier for designers.

If Chris Wanstrath the co-founder and former CEO of GitHub said, “the future of coding is no coding at all,” then surely no-code is a legitimate way to develop — despite the perception that these tools don’t offer the flexibility to write your own code, line by line.

Indeed, we see that interest in the term “nocode” is growing:

Difference Between Imperative And Declarative Programming

In order to understand the development of no-code tools for designers, you need to know the distinction between two types of programming:

  1. Imperative Programming
    Deconstruct the result into a sequence of imperatives, i.e. explicit control flow. For example: JavaScript, Python, C ++.
  2. Declarative Programming
    Declare the result, i.e. implicit control flow. For example: SQL, HTML, CSS.

Declarative languages are often domain-specific languages, or DSL, which means they’re used for a specific purpose, in a specific domain.

For example, SQL is DSL for working with databases, HTML is DSL for adding semantic structure and meaning to content on a web page, and CSS is DSL for adding style.

“There are too many variables to consider. The point of CSS is to make it so you don’t have to worry about them all. Define some constraints. Let the language work out the details.”
— Keith J. Grant, Resilient, Declarative, Contextual

Imperative programming sets specific, step-by-step instructions to the browser to get the desired result, while declarative programming states the desired result and the browser does the work by itself.

The Middle Ages

The effort to create a visual interface tool for web design development started in the 1990s through groundbreaking attempts like InContext Spider, Netscape Navigator Gold, Microsoft FrontPage, and of course, Dreamweaver.

During this period, the common terminology included: visual HTML authoring tool, WYSIWYG web page compositor, or simply HTML editor. The term “no-code” was popular in the 1990s — but for a different reason. In 1996, the American rock band Pearl Jam released their fourth studio album, No Code.

These no-code tools dramatically reduced the creative barrier and attracted a large audience, the Internet wasn’t ready for these types of tools at the time.

This effort was limited for the following reasons:

1. Layout

When the inventor of the World Wide Web Tim Berners-Lee launched his creation in 1989, he didn’t offer a way to design a website.

This came along in October 1994, after a series of suggestions on how to design the Internet by different people — including one from Håkon Wium Lie — who proposed an idea that attracted everyone’s attention. Lie believed in a declarative style that would allow browsers to handle the processing — it was called Cascading Style Sheets, or simply CSS.

“CSS stood out because it was simple, especially compared to some of its earliest competitors.”
— Jason Hoffman, A Look Back at the History of CSS

For a long time after, CSS provided design solutions for a single object — but it didn’t give an adequate response to the relationship between the objects.

Methods to address this were effectively hacks, and they weren’t able to handle a great deal of complexity. As sites evolved from simple documents to complex applications, web layouts became difficult to assemble. Instead of using a style in a declarative way as Lie designed, web developers were forced to use imperative programming.

A grid system based on the rules of Swiss designer Josef Müller-Brockmann that was customary in print from the 1940s seems like a distant dream when considering anything related to the Web.

Because of these layout limitations, no-code platforms were forced to add an abstract layer to perform backstage calculations. This layer causes a range of problems, including losing the semantic value of the objects, performance issues, bulky code, a complex learning curve, unscalability, and accessibility issues.

2. Browser Alignment

In the early days, browser makers were the ones who decided how to build the Internet. This led to the Web becoming a manipulative commodity. Competition between browsers led to unique “design features”. This forced the need to rebuild the same site several times, so it could be accessed from multiple browsers.

“Developers in the 90s would often have to make three or four versions of every website they built, so that it would be compatible with each of the browsers available at the time.”
— Amy Dickens, Web Standards: The What, The Why, And The How

To offset the need to build websites that fit specific browsers, the World Wide Web Consortium (WC3) community was established at MIT in 1994. The WC3 is an international community working to develop functional, accessible and cross-compatible web standards.

When the standards were introduced, browser makers were encouraged to stick to one way of doing things — thus preventing several versions of the same site from being built. Despite WC3’s recommendations, it took a long time for browsers to meet the same standards.

Due to a lack of alignment between the browsers (Internet Explorer, I’m looking at you), CSS for a time was stuck and no new capabilities were added. Once a declarative language doesn’t support something, it requires you to lean on all kinds of imperative hacks in order to achieve that goal.

3. Data Binding

In the early years of the Web, sites were developed as a collection of static pages with no semantic meaning. When Web 2.0 arrived, it received the description “the web as a platform,” which led to a significant change — pages had dynamic content, which affected the connection to the data, and of course the semantic meaning.

“Sites in the 1990s were usually either brochure-ware (static HTML pages with insipid content) or they were interactive in a flashy, animated, JavaScript kind of way.”
— Joshua Porter, Web 2.0 for Designers

Indeed, connecting to data using a no-code approach has existed for a long time — but the user experience was difficult. Additionally, the transition to semantic marking so content could be detected in no-code tools was difficult because of the mixing between declarative and imperative programming.

No-code tools didn’t mesh with those core tasks.

Proto-Renaissance

On June 29, 2007, the nature of the Internet was changed dramatically. This was the day when Steve Jobs introduced the iPhone — a combination of mobile phone and media player that connected to the Internet and enabled multi-touch navigation.

When the iPhone was introduced in 2007, it was a turning point for web design. All of a sudden web designers lost control of the canvas on which we designed websites. Previously, websites only had to work on monitor screens, which varied in size, but not all that much. How were we supposed to make our websites work on these tiny little screens?
— Clarissa Peterson, Learning Responsive Web Design

This created new challenges for web design development. Mainly, how to build a site that can be used on multiple types of devices. Many “hack” approaches to layout design simply fell apart — they caused more problems than they solved.

Everything needed to be reevaluated.

The No-Code Renaissance

Browsers supporting WC3 standards (Chrome and Firefox ) have huge market share today, which has pushed more browsers to support the standards. The fact that all of the browsers support the same standard, enable alignment in the building of sites and ensure these capabilities would continue to work as standards and browsers evolve.

Methods such as media query, flexbox and grid — which are natively available in the browsers for layout design — have paved the way for flexible layouts, even when element sizes are dynamic.

“When CSS Grid shipped in March 2017, our toolbox reached a tipping point. At last we have technology powerful enough to let us really get creative with layout. We can use the power of graphic design to convey meaning through our use of layout—creating unique layouts for each project, each section, each type of content, each page.”
— Rachel Andrew, The New CSS Layout

In this way, HTML became cleaner and it was able to achieve its original purpose: a semantic description of the content.

Finally, thanks to alignment between the browsers and new capabilities, no-code tools are backed by powerful, uniform technology. These changes created a clearer distinction between declarative and imperative. New possibilities were created to solve old problems.

“Simplicity is the ultimate sophistication.”
— Leonardo da Vinci

The Effect Of No-code On Designers

The developments of the Internet over the years has led to a situation where the abstraction between design and code is constantly improving. This has implications for the way web designers plan and implement their designs.

1. Design Planning

While popular design tools use static content for dynamic web design, no-code tools allow designers to work with the web’s own materials.

“Photoshop is the most effective way to show your clients what their website will never look like.”
— Stephen Hay, author of Responsive Design Workflow

If we have a complex design with different states, micro-interactions, animations and responsive breakpoints — by using no-code tools we can work in a more tangible way.

Additionally, the development of the web enables no-code tools to clearly separate content from the design (which allows designers to visually manage real content). Reflecting the dynamic content in the design (e.g. text, images, videos, and audio), gives designers a clearer understanding of how it will appear.

The advantage of working in the no-code workspace is that interactions appear immediately. This allows designers to quickly test their design choices and see if they work.

2. Design Implementation

After investing in design perfection, designers should explain the visual and conceptual decisions to developers through prototypes. Prototypes not only take time in terms of preparation, but their design is also often implemented incorrectly due to misinterpretations.

With no-code tools, designers are able to place objects on their display and handle their visibility and behavior with ease and speed. In other words, they can design the end result without depending on anyone else.

To use myself as an example, when the Coronavirus pandemic hit, I worked with a small team on a project to help connect young volunteers to isolated seniors. In just three days, myself and another designer built the website and connected user registration data to a database, while the team’s developer worked to integrate data from the site into a separate mobile app.

The Effect Of No-code On Developers

Will no-code tools completely replace developers? The short answer: No. The significant change is in the way designers and developers can work together to create websites.

In addition to the development of CSS, Javascript has also evolved in parallel and perhaps even more. The idea that frontend developers need to control all the abilities makes no sense. And yet, the development of no-code over the years has enabled designers to build their own designs.

It’s a win-win situation, in which  developers can focus on developing logic, and designers have more control over the user experience and styling.

The Effort Is Not Yet Complete

I don’t want to leave you with the impression that designers have complete freedom to design with no-code tools. There are still some missing style capabilities that CSS has not yet solved, and these still require imperative development.

Unlike in the Middle Ages, where art was considered as handicraft without a theoretical basis, Renaissance developments changed the status of the artist — who was suddenly considered a polymath.

No-code tools remove bottlenecks, which allows designers to gain more ownership, influence, and control over the experiences they design.

We’ve come a long way from the days when designers weren’t able to bring their designs to life. As the Internet evolves, browsers align, capabilities are added and the accessibility of technology becomes easier — designers are faced with new opportunities to create, think, and change their status with no-code tools.

The no-code movement not only affects how things are done, but by who.

Credits: Yoav Avrahami and Jeremy Hoover contributed to this article.

Further Reading on SmashingMag:

Articles on Smashing Magazine — For Web Designers And Developers

10 Sep

The Renaissance Of No-Code For Web Designers

by TBSCategories: News

The word Renaissance — which means “rebirth” in French — was given to a tremendous period of philosophical and artistic achievements that began in the 14th century.

During this time, there were a wide range of developments, including:

  • Use of oil paints, rather than tempera, which made the painting process easier.
  • Use of fabric, rather than wooden boards, which reduced the expenses of painting.
  • Translation of classical texts in architecture, anatomy, philosophy, and more, making knowledge more accessible to the general public.

These developments and more made the Renaissance one of the most productive artistic eras in history, dramatically reducing the creative barrier and attracting a large audience rather than just a small group of elites.

Just like the Renaissance era, today’s web design field is exploring its potential through no-code development platforms (NCDPs). These tools allow non-programmers to create application software through graphical user interfaces and configuration, instead of traditional computer programming.

The Designer/Developer Mental Model

In 2000, usability expert Jakob Nielsen introduced “Jakob’s Law,” the idea that users develop mental models of the products they interact with based on their previous experience. The more users can focus on their goal without challenging this mental model, the easier it is for them to achieve that goal.

“CSS is closer to painting than Python.”
— Chris Coyier, co-founder at CodePen

Design and development skills are rooted in different types of thinking and require different types of tools. While designers use WYSIWYG editors like Figma, Sketch, and Photoshop to place elements on the canvas, developers work with IDEs like VSCode, Webstorm, and Brackets. In order to remain productive, designers and developers need to be able to make changes and receive instant feedback, according to their mental model.

So, using drag and drop builders may actually interfere with developers who want to debug fast, but working only with a text editor may be inappropriate for designers who want to test composition.

Designers And Code

Many designers understand the functional differences between a mockup and a working product. In order to understand the possibilities of the medium, where to draw the boundaries and how to deal with the constraints, many designers are willing to “get their hands dirty” when it comes to learning code — but they have difficulties.

One of the main reasons designers are not coders is because there is a large gap between the designer’s mental model and the conceptual model of many code editors. Design and development take two very different modes of thought. This mismatch leads to a difficult and frustrating learning curve for designers that they might not be able to overcome.

Code Abstraction

Abstraction is a core concept of computer science. Languages, frameworks, and libraries are built on different abstraction layers of complexity to facilitate, optimize, and guarantee productivity.

“Visual programming tools abstract code away from the creator, making them significantly more accessible. The real magic of these tools, however, is how they integrate all of the underlying layers of software into end products, providing useful functionality through modular components that can be harnessed through intuitive visual interfaces.”
— Jeremy Q. Ho, No Code is New Programming

When working with abstraction layers, there are tools such as Editor X and Studio for websites/web applications, Draftbit and Kodika for mobile apps, and Modulz for design systems, which enable a visual representation of code, in addition to code capabilities.

By adopting a familiar visual medium, the learning curve becomes easier for designers.

If Chris Wanstrath the co-founder and former CEO of GitHub said, “the future of coding is no coding at all,” then surely no-code is a legitimate way to develop — despite the perception that these tools don’t offer the flexibility to write your own code, line by line.

Indeed, we see that interest in the term “nocode” is growing:

Difference Between Imperative And Declarative Programming

In order to understand the development of no-code tools for designers, you need to know the distinction between two types of programming:

  1. Imperative Programming
    Deconstruct the result into a sequence of imperatives, i.e. explicit control flow. For example: JavaScript, Python, C ++.
  2. Declarative Programming
    Declare the result, i.e. implicit control flow. For example: SQL, HTML, CSS.

Declarative languages are often domain-specific languages, or DSL, which means they’re used for a specific purpose, in a specific domain.

For example, SQL is DSL for working with databases, HTML is DSL for adding semantic structure and meaning to content on a web page, and CSS is DSL for adding style.

“There are too many variables to consider. The point of CSS is to make it so you don’t have to worry about them all. Define some constraints. Let the language work out the details.”
— Keith J. Grant, Resilient, Declarative, Contextual

Imperative programming sets specific, step-by-step instructions to the browser to get the desired result, while declarative programming states the desired result and the browser does the work by itself.

The Middle Ages

The effort to create a visual interface tool for web design development started in the 1990s through groundbreaking attempts like InContext Spider, Netscape Navigator Gold, Microsoft FrontPage, and of course, Dreamweaver.

During this period, the common terminology included: visual HTML authoring tool, WYSIWYG web page compositor, or simply HTML editor. The term “no-code” was popular in the 1990s — but for a different reason. In 1996, the American rock band Pearl Jam released their fourth studio album, No Code.

These no-code tools dramatically reduced the creative barrier and attracted a large audience, the Internet wasn’t ready for these types of tools at the time.

This effort was limited for the following reasons:

1. Layout

When the inventor of the World Wide Web Tim Berners-Lee launched his creation in 1989, he didn’t offer a way to design a website.

This came along in October 1994, after a series of suggestions on how to design the Internet by different people — including one from Håkon Wium Lie — who proposed an idea that attracted everyone’s attention. Lie believed in a declarative style that would allow browsers to handle the processing — it was called Cascading Style Sheets, or simply CSS.

“CSS stood out because it was simple, especially compared to some of its earliest competitors.”
— Jason Hoffman, A Look Back at the History of CSS

For a long time after, CSS provided design solutions for a single object — but it didn’t give an adequate response to the relationship between the objects.

Methods to address this were effectively hacks, and they weren’t able to handle a great deal of complexity. As sites evolved from simple documents to complex applications, web layouts became difficult to assemble. Instead of using a style in a declarative way as Lie designed, web developers were forced to use imperative programming.

A grid system based on the rules of Swiss designer Josef Müller-Brockmann that was customary in print from the 1940s seems like a distant dream when considering anything related to the Web.

Because of these layout limitations, no-code platforms were forced to add an abstract layer to perform backstage calculations. This layer causes a range of problems, including losing the semantic value of the objects, performance issues, bulky code, a complex learning curve, unscalability, and accessibility issues.

2. Browser Alignment

In the early days, browser makers were the ones who decided how to build the Internet. This led to the Web becoming a manipulative commodity. Competition between browsers led to unique “design features”. This forced the need to rebuild the same site several times, so it could be accessed from multiple browsers.

“Developers in the 90s would often have to make three or four versions of every website they built, so that it would be compatible with each of the browsers available at the time.”
— Amy Dickens, Web Standards: The What, The Why, And The How

To offset the need to build websites that fit specific browsers, the World Wide Web Consortium (WC3) community was established at MIT in 1994. The WC3 is an international community working to develop functional, accessible and cross-compatible web standards.

When the standards were introduced, browser makers were encouraged to stick to one way of doing things — thus preventing several versions of the same site from being built. Despite WC3’s recommendations, it took a long time for browsers to meet the same standards.

Due to a lack of alignment between the browsers (Internet Explorer, I’m looking at you), CSS for a time was stuck and no new capabilities were added. Once a declarative language doesn’t support something, it requires you to lean on all kinds of imperative hacks in order to achieve that goal.

3. Data Binding

In the early years of the Web, sites were developed as a collection of static pages with no semantic meaning. When Web 2.0 arrived, it received the description “the web as a platform,” which led to a significant change — pages had dynamic content, which affected the connection to the data, and of course the semantic meaning.

“Sites in the 1990s were usually either brochure-ware (static HTML pages with insipid content) or they were interactive in a flashy, animated, JavaScript kind of way.”
— Joshua Porter, Web 2.0 for Designers

Indeed, connecting to data using a no-code approach has existed for a long time — but the user experience was difficult. Additionally, the transition to semantic marking so content could be detected in no-code tools was difficult because of the mixing between declarative and imperative programming.

No-code tools didn’t mesh with those core tasks.

Proto-Renaissance

On June 29, 2007, the nature of the Internet was changed dramatically. This was the day when Steve Jobs introduced the iPhone — a combination of mobile phone and media player that connected to the Internet and enabled multi-touch navigation.

When the iPhone was introduced in 2007, it was a turning point for web design. All of a sudden web designers lost control of the canvas on which we designed websites. Previously, websites only had to work on monitor screens, which varied in size, but not all that much. How were we supposed to make our websites work on these tiny little screens?
— Clarissa Peterson, Learning Responsive Web Design

This created new challenges for web design development. Mainly, how to build a site that can be used on multiple types of devices. Many “hack” approaches to layout design simply fell apart — they caused more problems than they solved.

Everything needed to be reevaluated.

The No-Code Renaissance

Browsers supporting WC3 standards (Chrome and Firefox ) have huge market share today, which has pushed more browsers to support the standards. The fact that all of the browsers support the same standard, enable alignment in the building of sites and ensure these capabilities would continue to work as standards and browsers evolve.

Methods such as media query, flexbox and grid — which are natively available in the browsers for layout design — have paved the way for flexible layouts, even when element sizes are dynamic.

“When CSS Grid shipped in March 2017, our toolbox reached a tipping point. At last we have technology powerful enough to let us really get creative with layout. We can use the power of graphic design to convey meaning through our use of layout—creating unique layouts for each project, each section, each type of content, each page.”
— Rachel Andrew, The New CSS Layout

In this way, HTML became cleaner and it was able to achieve its original purpose: a semantic description of the content.

Finally, thanks to alignment between the browsers and new capabilities, no-code tools are backed by powerful, uniform technology. These changes created a clearer distinction between declarative and imperative. New possibilities were created to solve old problems.

“Simplicity is the ultimate sophistication.”
— Leonardo da Vinci

The Effect Of No-code On Designers

The developments of the Internet over the years has led to a situation where the abstraction between design and code is constantly improving. This has implications for the way web designers plan and implement their designs.

1. Design Planning

While popular design tools use static content for dynamic web design, no-code tools allow designers to work with the web’s own materials.

“Photoshop is the most effective way to show your clients what their website will never look like.”
— Stephen Hay, author of Responsive Design Workflow

If we have a complex design with different states, micro-interactions, animations and responsive breakpoints — by using no-code tools we can work in a more tangible way.

Additionally, the development of the web enables no-code tools to clearly separate content from the design (which allows designers to visually manage real content). Reflecting the dynamic content in the design (e.g. text, images, videos, and audio), gives designers a clearer understanding of how it will appear.

The advantage of working in the no-code workspace is that interactions appear immediately. This allows designers to quickly test their design choices and see if they work.

2. Design Implementation

After investing in design perfection, designers should explain the visual and conceptual decisions to developers through prototypes. Prototypes not only take time in terms of preparation, but their design is also often implemented incorrectly due to misinterpretations.

With no-code tools, designers are able to place objects on their display and handle their visibility and behavior with ease and speed. In other words, they can design the end result without depending on anyone else.

To use myself as an example, when the Coronavirus pandemic hit, I worked with a small team on a project to help connect young volunteers to isolated seniors. In just three days, myself and another designer built the website and connected user registration data to a database, while the team’s developer worked to integrate data from the site into a separate mobile app.

The Effect Of No-code On Developers

Will no-code tools completely replace developers? The short answer: No. The significant change is in the way designers and developers can work together to create websites.

In addition to the development of CSS, Javascript has also evolved in parallel and perhaps even more. The idea that frontend developers need to control all the abilities makes no sense. And yet, the development of no-code over the years has enabled designers to build their own designs.

It’s a win-win situation, in which  developers can focus on developing logic, and designers have more control over the user experience and styling.

The Effort Is Not Yet Complete

I don’t want to leave you with the impression that designers have complete freedom to design with no-code tools. There are still some missing style capabilities that CSS has not yet solved, and these still require imperative development.

Unlike in the Middle Ages, where art was considered as handicraft without a theoretical basis, Renaissance developments changed the status of the artist — who was suddenly considered a polymath.

No-code tools remove bottlenecks, which allows designers to gain more ownership, influence, and control over the experiences they design.

We’ve come a long way from the days when designers weren’t able to bring their designs to life. As the Internet evolves, browsers align, capabilities are added and the accessibility of technology becomes easier — designers are faced with new opportunities to create, think, and change their status with no-code tools.

The no-code movement not only affects how things are done, but by who.

Credits: Yoav Avrahami and Jeremy Hoover contributed to this article.

Further Reading on SmashingMag:

Articles on Smashing Magazine — For Web Designers And Developers

10 Sep

The Renaissance Of No-Code For Web Designers

by TBSCategories: News

The word Renaissance — which means “rebirth” in French — was given to a tremendous period of philosophical and artistic achievements that began in the 14th century.

During this time, there were a wide range of developments, including:

  • Use of oil paints, rather than tempera, which made the painting process easier.
  • Use of fabric, rather than wooden boards, which reduced the expenses of painting.
  • Translation of classical texts in architecture, anatomy, philosophy, and more, making knowledge more accessible to the general public.

These developments and more made the Renaissance one of the most productive artistic eras in history, dramatically reducing the creative barrier and attracting a large audience rather than just a small group of elites.

Just like the Renaissance era, today’s web design field is exploring its potential through no-code development platforms (NCDPs). These tools allow non-programmers to create application software through graphical user interfaces and configuration, instead of traditional computer programming.

The Designer/Developer Mental Model

In 2000, usability expert Jakob Nielsen introduced “Jakob’s Law,” the idea that users develop mental models of the products they interact with based on their previous experience. The more users can focus on their goal without challenging this mental model, the easier it is for them to achieve that goal.

“CSS is closer to painting than Python.”
— Chris Coyier, co-founder at CodePen

Design and development skills are rooted in different types of thinking and require different types of tools. While designers use WYSIWYG editors like Figma, Sketch, and Photoshop to place elements on the canvas, developers work with IDEs like VSCode, Webstorm, and Brackets. In order to remain productive, designers and developers need to be able to make changes and receive instant feedback, according to their mental model.

So, using drag and drop builders may actually interfere with developers who want to debug fast, but working only with a text editor may be inappropriate for designers who want to test composition.

Designers And Code

Many designers understand the functional differences between a mockup and a working product. In order to understand the possibilities of the medium, where to draw the boundaries and how to deal with the constraints, many designers are willing to “get their hands dirty” when it comes to learning code — but they have difficulties.

One of the main reasons designers are not coders is because there is a large gap between the designer’s mental model and the conceptual model of many code editors. Design and development take two very different modes of thought. This mismatch leads to a difficult and frustrating learning curve for designers that they might not be able to overcome.

Code Abstraction

Abstraction is a core concept of computer science. Languages, frameworks, and libraries are built on different abstraction layers of complexity to facilitate, optimize, and guarantee productivity.

“Visual programming tools abstract code away from the creator, making them significantly more accessible. The real magic of these tools, however, is how they integrate all of the underlying layers of software into end products, providing useful functionality through modular components that can be harnessed through intuitive visual interfaces.”
— Jeremy Q. Ho, No Code is New Programming

When working with abstraction layers, there are tools such as Editor X and Studio for websites/web applications, Draftbit and Kodika for mobile apps, and Modulz for design systems, which enable a visual representation of code, in addition to code capabilities.

By adopting a familiar visual medium, the learning curve becomes easier for designers.

If Chris Wanstrath the co-founder and former CEO of GitHub said, “the future of coding is no coding at all,” then surely no-code is a legitimate way to develop — despite the perception that these tools don’t offer the flexibility to write your own code, line by line.

Indeed, we see that interest in the term “nocode” is growing:

Difference Between Imperative And Declarative Programming

In order to understand the development of no-code tools for designers, you need to know the distinction between two types of programming:

  1. Imperative Programming
    Deconstruct the result into a sequence of imperatives, i.e. explicit control flow. For example: JavaScript, Python, C ++.
  2. Declarative Programming
    Declare the result, i.e. implicit control flow. For example: SQL, HTML, CSS.

Declarative languages are often domain-specific languages, or DSL, which means they’re used for a specific purpose, in a specific domain.

For example, SQL is DSL for working with databases, HTML is DSL for adding semantic structure and meaning to content on a web page, and CSS is DSL for adding style.

“There are too many variables to consider. The point of CSS is to make it so you don’t have to worry about them all. Define some constraints. Let the language work out the details.”
— Keith J. Grant, Resilient, Declarative, Contextual

Imperative programming sets specific, step-by-step instructions to the browser to get the desired result, while declarative programming states the desired result and the browser does the work by itself.

The Middle Ages

The effort to create a visual interface tool for web design development started in the 1990s through groundbreaking attempts like InContext Spider, Netscape Navigator Gold, Microsoft FrontPage, and of course, Dreamweaver.

During this period, the common terminology included: visual HTML authoring tool, WYSIWYG web page compositor, or simply HTML editor. The term “no-code” was popular in the 1990s — but for a different reason. In 1996, the American rock band Pearl Jam released their fourth studio album, No Code.

These no-code tools dramatically reduced the creative barrier and attracted a large audience, the Internet wasn’t ready for these types of tools at the time.

This effort was limited for the following reasons:

1. Layout

When the inventor of the World Wide Web Tim Berners-Lee launched his creation in 1989, he didn’t offer a way to design a website.

This came along in October 1994, after a series of suggestions on how to design the Internet by different people — including one from Håkon Wium Lie — who proposed an idea that attracted everyone’s attention. Lie believed in a declarative style that would allow browsers to handle the processing — it was called Cascading Style Sheets, or simply CSS.

“CSS stood out because it was simple, especially compared to some of its earliest competitors.”
— Jason Hoffman, A Look Back at the History of CSS

For a long time after, CSS provided design solutions for a single object — but it didn’t give an adequate response to the relationship between the objects.

Methods to address this were effectively hacks, and they weren’t able to handle a great deal of complexity. As sites evolved from simple documents to complex applications, web layouts became difficult to assemble. Instead of using a style in a declarative way as Lie designed, web developers were forced to use imperative programming.

A grid system based on the rules of Swiss designer Josef Müller-Brockmann that was customary in print from the 1940s seems like a distant dream when considering anything related to the Web.

Because of these layout limitations, no-code platforms were forced to add an abstract layer to perform backstage calculations. This layer causes a range of problems, including losing the semantic value of the objects, performance issues, bulky code, a complex learning curve, unscalability, and accessibility issues.

2. Browser Alignment

In the early days, browser makers were the ones who decided how to build the Internet. This led to the Web becoming a manipulative commodity. Competition between browsers led to unique “design features”. This forced the need to rebuild the same site several times, so it could be accessed from multiple browsers.

“Developers in the 90s would often have to make three or four versions of every website they built, so that it would be compatible with each of the browsers available at the time.”
— Amy Dickens, Web Standards: The What, The Why, And The How

To offset the need to build websites that fit specific browsers, the World Wide Web Consortium (WC3) community was established at MIT in 1994. The WC3 is an international community working to develop functional, accessible and cross-compatible web standards.

When the standards were introduced, browser makers were encouraged to stick to one way of doing things — thus preventing several versions of the same site from being built. Despite WC3’s recommendations, it took a long time for browsers to meet the same standards.

Due to a lack of alignment between the browsers (Internet Explorer, I’m looking at you), CSS for a time was stuck and no new capabilities were added. Once a declarative language doesn’t support something, it requires you to lean on all kinds of imperative hacks in order to achieve that goal.

3. Data Binding

In the early years of the Web, sites were developed as a collection of static pages with no semantic meaning. When Web 2.0 arrived, it received the description “the web as a platform,” which led to a significant change — pages had dynamic content, which affected the connection to the data, and of course the semantic meaning.

“Sites in the 1990s were usually either brochure-ware (static HTML pages with insipid content) or they were interactive in a flashy, animated, JavaScript kind of way.”
— Joshua Porter, Web 2.0 for Designers

Indeed, connecting to data using a no-code approach has existed for a long time — but the user experience was difficult. Additionally, the transition to semantic marking so content could be detected in no-code tools was difficult because of the mixing between declarative and imperative programming.

No-code tools didn’t mesh with those core tasks.

Proto-Renaissance

On June 29, 2007, the nature of the Internet was changed dramatically. This was the day when Steve Jobs introduced the iPhone — a combination of mobile phone and media player that connected to the Internet and enabled multi-touch navigation.

When the iPhone was introduced in 2007, it was a turning point for web design. All of a sudden web designers lost control of the canvas on which we designed websites. Previously, websites only had to work on monitor screens, which varied in size, but not all that much. How were we supposed to make our websites work on these tiny little screens?
— Clarissa Peterson, Learning Responsive Web Design

This created new challenges for web design development. Mainly, how to build a site that can be used on multiple types of devices. Many “hack” approaches to layout design simply fell apart — they caused more problems than they solved.

Everything needed to be reevaluated.

The No-Code Renaissance

Browsers supporting WC3 standards (Chrome and Firefox ) have huge market share today, which has pushed more browsers to support the standards. The fact that all of the browsers support the same standard, enable alignment in the building of sites and ensure these capabilities would continue to work as standards and browsers evolve.

Methods such as media query, flexbox and grid — which are natively available in the browsers for layout design — have paved the way for flexible layouts, even when element sizes are dynamic.

“When CSS Grid shipped in March 2017, our toolbox reached a tipping point. At last we have technology powerful enough to let us really get creative with layout. We can use the power of graphic design to convey meaning through our use of layout—creating unique layouts for each project, each section, each type of content, each page.”
— Rachel Andrew, The New CSS Layout

In this way, HTML became cleaner and it was able to achieve its original purpose: a semantic description of the content.

Finally, thanks to alignment between the browsers and new capabilities, no-code tools are backed by powerful, uniform technology. These changes created a clearer distinction between declarative and imperative. New possibilities were created to solve old problems.

“Simplicity is the ultimate sophistication.”
— Leonardo da Vinci

The Effect Of No-code On Designers

The developments of the Internet over the years has led to a situation where the abstraction between design and code is constantly improving. This has implications for the way web designers plan and implement their designs.

1. Design Planning

While popular design tools use static content for dynamic web design, no-code tools allow designers to work with the web’s own materials.

“Photoshop is the most effective way to show your clients what their website will never look like.”
— Stephen Hay, author of Responsive Design Workflow

If we have a complex design with different states, micro-interactions, animations and responsive breakpoints — by using no-code tools we can work in a more tangible way.

Additionally, the development of the web enables no-code tools to clearly separate content from the design (which allows designers to visually manage real content). Reflecting the dynamic content in the design (e.g. text, images, videos, and audio), gives designers a clearer understanding of how it will appear.

The advantage of working in the no-code workspace is that interactions appear immediately. This allows designers to quickly test their design choices and see if they work.

2. Design Implementation

After investing in design perfection, designers should explain the visual and conceptual decisions to developers through prototypes. Prototypes not only take time in terms of preparation, but their design is also often implemented incorrectly due to misinterpretations.

With no-code tools, designers are able to place objects on their display and handle their visibility and behavior with ease and speed. In other words, they can design the end result without depending on anyone else.

To use myself as an example, when the Coronavirus pandemic hit, I worked with a small team on a project to help connect young volunteers to isolated seniors. In just three days, myself and another designer built the website and connected user registration data to a database, while the team’s developer worked to integrate data from the site into a separate mobile app.

The Effect Of No-code On Developers

Will no-code tools completely replace developers? The short answer: No. The significant change is in the way designers and developers can work together to create websites.

In addition to the development of CSS, Javascript has also evolved in parallel and perhaps even more. The idea that frontend developers need to control all the abilities makes no sense. And yet, the development of no-code over the years has enabled designers to build their own designs.

It’s a win-win situation, in which  developers can focus on developing logic, and designers have more control over the user experience and styling.

The Effort Is Not Yet Complete

I don’t want to leave you with the impression that designers have complete freedom to design with no-code tools. There are still some missing style capabilities that CSS has not yet solved, and these still require imperative development.

Unlike in the Middle Ages, where art was considered as handicraft without a theoretical basis, Renaissance developments changed the status of the artist — who was suddenly considered a polymath.

No-code tools remove bottlenecks, which allows designers to gain more ownership, influence, and control over the experiences they design.

We’ve come a long way from the days when designers weren’t able to bring their designs to life. As the Internet evolves, browsers align, capabilities are added and the accessibility of technology becomes easier — designers are faced with new opportunities to create, think, and change their status with no-code tools.

The no-code movement not only affects how things are done, but by who.

Credits: Yoav Avrahami and Jeremy Hoover contributed to this article.

Further Reading on SmashingMag:

Articles on Smashing Magazine — For Web Designers And Developers

10 Sep

The Renaissance Of No-Code For Web Designers

by TBSCategories: News

The word Renaissance — which means “rebirth” in French — was given to a tremendous period of philosophical and artistic achievements that began in the 14th century.

During this time, there were a wide range of developments, including:

  • Use of oil paints, rather than tempera, which made the painting process easier.
  • Use of fabric, rather than wooden boards, which reduced the expenses of painting.
  • Translation of classical texts in architecture, anatomy, philosophy, and more, making knowledge more accessible to the general public.

These developments and more made the Renaissance one of the most productive artistic eras in history, dramatically reducing the creative barrier and attracting a large audience rather than just a small group of elites.

Just like the Renaissance era, today’s web design field is exploring its potential through no-code development platforms (NCDPs). These tools allow non-programmers to create application software through graphical user interfaces and configuration, instead of traditional computer programming.

The Designer/Developer Mental Model

In 2000, usability expert Jakob Nielsen introduced “Jakob’s Law,” the idea that users develop mental models of the products they interact with based on their previous experience. The more users can focus on their goal without challenging this mental model, the easier it is for them to achieve that goal.

“CSS is closer to painting than Python.”
— Chris Coyier, co-founder at CodePen

Design and development skills are rooted in different types of thinking and require different types of tools. While designers use WYSIWYG editors like Figma, Sketch, and Photoshop to place elements on the canvas, developers work with IDEs like VSCode, Webstorm, and Brackets. In order to remain productive, designers and developers need to be able to make changes and receive instant feedback, according to their mental model.

So, using drag and drop builders may actually interfere with developers who want to debug fast, but working only with a text editor may be inappropriate for designers who want to test composition.

Designers And Code

Many designers understand the functional differences between a mockup and a working product. In order to understand the possibilities of the medium, where to draw the boundaries and how to deal with the constraints, many designers are willing to “get their hands dirty” when it comes to learning code — but they have difficulties.

One of the main reasons designers are not coders is because there is a large gap between the designer’s mental model and the conceptual model of many code editors. Design and development take two very different modes of thought. This mismatch leads to a difficult and frustrating learning curve for designers that they might not be able to overcome.

Code Abstraction

Abstraction is a core concept of computer science. Languages, frameworks, and libraries are built on different abstraction layers of complexity to facilitate, optimize, and guarantee productivity.

“Visual programming tools abstract code away from the creator, making them significantly more accessible. The real magic of these tools, however, is how they integrate all of the underlying layers of software into end products, providing useful functionality through modular components that can be harnessed through intuitive visual interfaces.”
— Jeremy Q. Ho, No Code is New Programming

When working with abstraction layers, there are tools such as Editor X and Studio for websites/web applications, Draftbit and Kodika for mobile apps, and Modulz for design systems, which enable a visual representation of code, in addition to code capabilities.

By adopting a familiar visual medium, the learning curve becomes easier for designers.

If Chris Wanstrath the co-founder and former CEO of GitHub said, “the future of coding is no coding at all,” then surely no-code is a legitimate way to develop — despite the perception that these tools don’t offer the flexibility to write your own code, line by line.

Indeed, we see that interest in the term “nocode” is growing:

Difference Between Imperative And Declarative Programming

In order to understand the development of no-code tools for designers, you need to know the distinction between two types of programming:

  1. Imperative Programming
    Deconstruct the result into a sequence of imperatives, i.e. explicit control flow. For example: JavaScript, Python, C ++.
  2. Declarative Programming
    Declare the result, i.e. implicit control flow. For example: SQL, HTML, CSS.

Declarative languages are often domain-specific languages, or DSL, which means they’re used for a specific purpose, in a specific domain.

For example, SQL is DSL for working with databases, HTML is DSL for adding semantic structure and meaning to content on a web page, and CSS is DSL for adding style.

“There are too many variables to consider. The point of CSS is to make it so you don’t have to worry about them all. Define some constraints. Let the language work out the details.”
— Keith J. Grant, Resilient, Declarative, Contextual

Imperative programming sets specific, step-by-step instructions to the browser to get the desired result, while declarative programming states the desired result and the browser does the work by itself.

The Middle Ages

The effort to create a visual interface tool for web design development started in the 1990s through groundbreaking attempts like InContext Spider, Netscape Navigator Gold, Microsoft FrontPage, and of course, Dreamweaver.

During this period, the common terminology included: visual HTML authoring tool, WYSIWYG web page compositor, or simply HTML editor. The term “no-code” was popular in the 1990s — but for a different reason. In 1996, the American rock band Pearl Jam released their fourth studio album, No Code.

These no-code tools dramatically reduced the creative barrier and attracted a large audience, the Internet wasn’t ready for these types of tools at the time.

This effort was limited for the following reasons:

1. Layout

When the inventor of the World Wide Web Tim Berners-Lee launched his creation in 1989, he didn’t offer a way to design a website.

This came along in October 1994, after a series of suggestions on how to design the Internet by different people — including one from Håkon Wium Lie — who proposed an idea that attracted everyone’s attention. Lie believed in a declarative style that would allow browsers to handle the processing — it was called Cascading Style Sheets, or simply CSS.

“CSS stood out because it was simple, especially compared to some of its earliest competitors.”
— Jason Hoffman, A Look Back at the History of CSS

For a long time after, CSS provided design solutions for a single object — but it didn’t give an adequate response to the relationship between the objects.

Methods to address this were effectively hacks, and they weren’t able to handle a great deal of complexity. As sites evolved from simple documents to complex applications, web layouts became difficult to assemble. Instead of using a style in a declarative way as Lie designed, web developers were forced to use imperative programming.

A grid system based on the rules of Swiss designer Josef Müller-Brockmann that was customary in print from the 1940s seems like a distant dream when considering anything related to the Web.

Because of these layout limitations, no-code platforms were forced to add an abstract layer to perform backstage calculations. This layer causes a range of problems, including losing the semantic value of the objects, performance issues, bulky code, a complex learning curve, unscalability, and accessibility issues.

2. Browser Alignment

In the early days, browser makers were the ones who decided how to build the Internet. This led to the Web becoming a manipulative commodity. Competition between browsers led to unique “design features”. This forced the need to rebuild the same site several times, so it could be accessed from multiple browsers.

“Developers in the 90s would often have to make three or four versions of every website they built, so that it would be compatible with each of the browsers available at the time.”
— Amy Dickens, Web Standards: The What, The Why, And The How

To offset the need to build websites that fit specific browsers, the World Wide Web Consortium (WC3) community was established at MIT in 1994. The WC3 is an international community working to develop functional, accessible and cross-compatible web standards.

When the standards were introduced, browser makers were encouraged to stick to one way of doing things — thus preventing several versions of the same site from being built. Despite WC3’s recommendations, it took a long time for browsers to meet the same standards.

Due to a lack of alignment between the browsers (Internet Explorer, I’m looking at you), CSS for a time was stuck and no new capabilities were added. Once a declarative language doesn’t support something, it requires you to lean on all kinds of imperative hacks in order to achieve that goal.

3. Data Binding

In the early years of the Web, sites were developed as a collection of static pages with no semantic meaning. When Web 2.0 arrived, it received the description “the web as a platform,” which led to a significant change — pages had dynamic content, which affected the connection to the data, and of course the semantic meaning.

“Sites in the 1990s were usually either brochure-ware (static HTML pages with insipid content) or they were interactive in a flashy, animated, JavaScript kind of way.”
— Joshua Porter, Web 2.0 for Designers

Indeed, connecting to data using a no-code approach has existed for a long time — but the user experience was difficult. Additionally, the transition to semantic marking so content could be detected in no-code tools was difficult because of the mixing between declarative and imperative programming.

No-code tools didn’t mesh with those core tasks.

Proto-Renaissance

On June 29, 2007, the nature of the Internet was changed dramatically. This was the day when Steve Jobs introduced the iPhone — a combination of mobile phone and media player that connected to the Internet and enabled multi-touch navigation.

When the iPhone was introduced in 2007, it was a turning point for web design. All of a sudden web designers lost control of the canvas on which we designed websites. Previously, websites only had to work on monitor screens, which varied in size, but not all that much. How were we supposed to make our websites work on these tiny little screens?
— Clarissa Peterson, Learning Responsive Web Design

This created new challenges for web design development. Mainly, how to build a site that can be used on multiple types of devices. Many “hack” approaches to layout design simply fell apart — they caused more problems than they solved.

Everything needed to be reevaluated.

The No-Code Renaissance

Browsers supporting WC3 standards (Chrome and Firefox ) have huge market share today, which has pushed more browsers to support the standards. The fact that all of the browsers support the same standard, enable alignment in the building of sites and ensure these capabilities would continue to work as standards and browsers evolve.

Methods such as media query, flexbox and grid — which are natively available in the browsers for layout design — have paved the way for flexible layouts, even when element sizes are dynamic.

“When CSS Grid shipped in March 2017, our toolbox reached a tipping point. At last we have technology powerful enough to let us really get creative with layout. We can use the power of graphic design to convey meaning through our use of layout—creating unique layouts for each project, each section, each type of content, each page.”
— Rachel Andrew, The New CSS Layout

In this way, HTML became cleaner and it was able to achieve its original purpose: a semantic description of the content.

Finally, thanks to alignment between the browsers and new capabilities, no-code tools are backed by powerful, uniform technology. These changes created a clearer distinction between declarative and imperative. New possibilities were created to solve old problems.

“Simplicity is the ultimate sophistication.”
— Leonardo da Vinci

The Effect Of No-code On Designers

The developments of the Internet over the years has led to a situation where the abstraction between design and code is constantly improving. This has implications for the way web designers plan and implement their designs.

1. Design Planning

While popular design tools use static content for dynamic web design, no-code tools allow designers to work with the web’s own materials.

“Photoshop is the most effective way to show your clients what their website will never look like.”
— Stephen Hay, author of Responsive Design Workflow

If we have a complex design with different states, micro-interactions, animations and responsive breakpoints — by using no-code tools we can work in a more tangible way.

Additionally, the development of the web enables no-code tools to clearly separate content from the design (which allows designers to visually manage real content). Reflecting the dynamic content in the design (e.g. text, images, videos, and audio), gives designers a clearer understanding of how it will appear.

The advantage of working in the no-code workspace is that interactions appear immediately. This allows designers to quickly test their design choices and see if they work.

2. Design Implementation

After investing in design perfection, designers should explain the visual and conceptual decisions to developers through prototypes. Prototypes not only take time in terms of preparation, but their design is also often implemented incorrectly due to misinterpretations.

With no-code tools, designers are able to place objects on their display and handle their visibility and behavior with ease and speed. In other words, they can design the end result without depending on anyone else.

To use myself as an example, when the Coronavirus pandemic hit, I worked with a small team on a project to help connect young volunteers to isolated seniors. In just three days, myself and another designer built the website and connected user registration data to a database, while the team’s developer worked to integrate data from the site into a separate mobile app.

The Effect Of No-code On Developers

Will no-code tools completely replace developers? The short answer: No. The significant change is in the way designers and developers can work together to create websites.

In addition to the development of CSS, Javascript has also evolved in parallel and perhaps even more. The idea that frontend developers need to control all the abilities makes no sense. And yet, the development of no-code over the years has enabled designers to build their own designs.

It’s a win-win situation, in which  developers can focus on developing logic, and designers have more control over the user experience and styling.

The Effort Is Not Yet Complete

I don’t want to leave you with the impression that designers have complete freedom to design with no-code tools. There are still some missing style capabilities that CSS has not yet solved, and these still require imperative development.

Unlike in the Middle Ages, where art was considered as handicraft without a theoretical basis, Renaissance developments changed the status of the artist — who was suddenly considered a polymath.

No-code tools remove bottlenecks, which allows designers to gain more ownership, influence, and control over the experiences they design.

We’ve come a long way from the days when designers weren’t able to bring their designs to life. As the Internet evolves, browsers align, capabilities are added and the accessibility of technology becomes easier — designers are faced with new opportunities to create, think, and change their status with no-code tools.

The no-code movement not only affects how things are done, but by who.

Credits: Yoav Avrahami and Jeremy Hoover contributed to this article.

Further Reading on SmashingMag:

Articles on Smashing Magazine — For Web Designers And Developers

09 Sep

The Renaissance Of No-Code For Web Designers

by TBSCategories: News

The word Renaissance — which means “rebirth” in French — was given to a tremendous period of philosophical and artistic achievements that began in the 14th century.

During this time, there were a wide range of developments, including:

  • Use of oil paints, rather than tempera, which made the painting process easier.
  • Use of fabric, rather than wooden boards, which reduced the expenses of painting.
  • Translation of classical texts in architecture, anatomy, philosophy, and more, making knowledge more accessible to the general public.

These developments and more made the Renaissance one of the most productive artistic eras in history, dramatically reducing the creative barrier and attracting a large audience rather than just a small group of elites.

Just like the Renaissance era, today’s web design field is exploring its potential through no-code development platforms (NCDPs). These tools allow non-programmers to create application software through graphical user interfaces and configuration, instead of traditional computer programming.

The Designer/Developer Mental Model

In 2000, usability expert Jakob Nielsen introduced “Jakob’s Law,” the idea that users develop mental models of the products they interact with based on their previous experience. The more users can focus on their goal without challenging this mental model, the easier it is for them to achieve that goal.

“CSS is closer to painting than Python.”
— Chris Coyier, co-founder at CodePen

Design and development skills are rooted in different types of thinking and require different types of tools. While designers use WYSIWYG editors like Figma, Sketch, and Photoshop to place elements on the canvas, developers work with IDEs like VSCode, Webstorm, and Brackets. In order to remain productive, designers and developers need to be able to make changes and receive instant feedback, according to their mental model.

So, using drag and drop builders may actually interfere with developers who want to debug fast, but working only with a text editor may be inappropriate for designers who want to test composition.

Designers And Code

Many designers understand the functional differences between a mockup and a working product. In order to understand the possibilities of the medium, where to draw the boundaries and how to deal with the constraints, many designers are willing to “get their hands dirty” when it comes to learning code — but they have difficulties.

One of the main reasons designers are not coders is because there is a large gap between the designer’s mental model and the conceptual model of many code editors. Design and development take two very different modes of thought. This mismatch leads to a difficult and frustrating learning curve for designers that they might not be able to overcome.

Code Abstraction

Abstraction is a core concept of computer science. Languages, frameworks, and libraries are built on different abstraction layers of complexity to facilitate, optimize, and guarantee productivity.

“Visual programming tools abstract code away from the creator, making them significantly more accessible. The real magic of these tools, however, is how they integrate all of the underlying layers of software into end products, providing useful functionality through modular components that can be harnessed through intuitive visual interfaces.”
— Jeremy Q. Ho, No Code is New Programming

When working with abstraction layers, there are tools such as Editor X and Studio for websites/web applications, Draftbit and Kodika for mobile apps, and Modulz for design systems, which enable a visual representation of code, in addition to code capabilities.

By adopting a familiar visual medium, the learning curve becomes easier for designers.

If Chris Wanstrath the co-founder and former CEO of GitHub said, “the future of coding is no coding at all,” then surely no-code is a legitimate way to develop — despite the perception that these tools don’t offer the flexibility to write your own code, line by line.

Indeed, we see that interest in the term “nocode” is growing:

Difference Between Imperative And Declarative Programming

In order to understand the development of no-code tools for designers, you need to know the distinction between two types of programming:

  1. Imperative Programming
    Deconstruct the result into a sequence of imperatives, i.e. explicit control flow. For example: JavaScript, Python, C ++.
  2. Declarative Programming
    Declare the result, i.e. implicit control flow. For example: SQL, HTML, CSS.

Declarative languages are often domain-specific languages, or DSL, which means they’re used for a specific purpose, in a specific domain.

For example, SQL is DSL for working with databases, HTML is DSL for adding semantic structure and meaning to content on a web page, and CSS is DSL for adding style.

“There are too many variables to consider. The point of CSS is to make it so you don’t have to worry about them all. Define some constraints. Let the language work out the details.”
— Keith J. Grant, Resilient, Declarative, Contextual

Imperative programming sets specific, step-by-step instructions to the browser to get the desired result, while declarative programming states the desired result and the browser does the work by itself.

The Middle Ages

The effort to create a visual interface tool for web design development started in the 1990s through groundbreaking attempts like InContext Spider, Netscape Navigator Gold, Microsoft FrontPage, and of course, Dreamweaver.

During this period, the common terminology included: visual HTML authoring tool, WYSIWYG web page compositor, or simply HTML editor. The term “no-code” was popular in the 1990s — but for a different reason. In 1996, the American rock band Pearl Jam released their fourth studio album, No Code.

These no-code tools dramatically reduced the creative barrier and attracted a large audience, the Internet wasn’t ready for these types of tools at the time.

This effort was limited for the following reasons:

1. Layout

When the inventor of the World Wide Web Tim Berners-Lee launched his creation in 1989, he didn’t offer a way to design a website.

This came along in October 1994, after a series of suggestions on how to design the Internet by different people — including one from Håkon Wium Lie — who proposed an idea that attracted everyone’s attention. Lie believed in a declarative style that would allow browsers to handle the processing — it was called Cascading Style Sheets, or simply CSS.

“CSS stood out because it was simple, especially compared to some of its earliest competitors.”
— Jason Hoffman, A Look Back at the History of CSS

For a long time after, CSS provided design solutions for a single object — but it didn’t give an adequate response to the relationship between the objects.

Methods to address this were effectively hacks, and they weren’t able to handle a great deal of complexity. As sites evolved from simple documents to complex applications, web layouts became difficult to assemble. Instead of using a style in a declarative way as Lie designed, web developers were forced to use imperative programming.

A grid system based on the rules of Swiss designer Josef Müller-Brockmann that was customary in print from the 1940s seems like a distant dream when considering anything related to the Web.

Because of these layout limitations, no-code platforms were forced to add an abstract layer to perform backstage calculations. This layer causes a range of problems, including losing the semantic value of the objects, performance issues, bulky code, a complex learning curve, unscalability, and accessibility issues.

2. Browser Alignment

In the early days, browser makers were the ones who decided how to build the Internet. This led to the Web becoming a manipulative commodity. Competition between browsers led to unique “design features”. This forced the need to rebuild the same site several times, so it could be accessed from multiple browsers.

“Developers in the 90s would often have to make three or four versions of every website they built, so that it would be compatible with each of the browsers available at the time.”
— Amy Dickens, Web Standards: The What, The Why, And The How

To offset the need to build websites that fit specific browsers, the World Wide Web Consortium (WC3) community was established at MIT in 1994. The WC3 is an international community working to develop functional, accessible and cross-compatible web standards.

When the standards were introduced, browser makers were encouraged to stick to one way of doing things — thus preventing several versions of the same site from being built. Despite WC3’s recommendations, it took a long time for browsers to meet the same standards.

Due to a lack of alignment between the browsers (Internet Explorer, I’m looking at you), CSS for a time was stuck and no new capabilities were added. Once a declarative language doesn’t support something, it requires you to lean on all kinds of imperative hacks in order to achieve that goal.

3. Data Binding

In the early years of the Web, sites were developed as a collection of static pages with no semantic meaning. When Web 2.0 arrived, it received the description “the web as a platform,” which led to a significant change — pages had dynamic content, which affected the connection to the data, and of course the semantic meaning.

“Sites in the 1990s were usually either brochure-ware (static HTML pages with insipid content) or they were interactive in a flashy, animated, JavaScript kind of way.”
— Joshua Porter, Web 2.0 for Designers

Indeed, connecting to data using a no-code approach has existed for a long time — but the user experience was difficult. Additionally, the transition to semantic marking so content could be detected in no-code tools was difficult because of the mixing between declarative and imperative programming.

No-code tools didn’t mesh with those core tasks.

Proto-Renaissance

On June 29, 2007, the nature of the Internet was changed dramatically. This was the day when Steve Jobs introduced the iPhone — a combination of mobile phone and media player that connected to the Internet and enabled multi-touch navigation.

When the iPhone was introduced in 2007, it was a turning point for web design. All of a sudden web designers lost control of the canvas on which we designed websites. Previously, websites only had to work on monitor screens, which varied in size, but not all that much. How were we supposed to make our websites work on these tiny little screens?
— Clarissa Peterson, Learning Responsive Web Design

This created new challenges for web design development. Mainly, how to build a site that can be used on multiple types of devices. Many “hack” approaches to layout design simply fell apart — they caused more problems than they solved.

Everything needed to be reevaluated.

The No-Code Renaissance

Browsers supporting WC3 standards (Chrome and Firefox ) have huge market share today, which has pushed more browsers to support the standards. The fact that all of the browsers support the same standard, enable alignment in the building of sites and ensure these capabilities would continue to work as standards and browsers evolve.

Methods such as media query, flexbox and grid — which are natively available in the browsers for layout design — have paved the way for flexible layouts, even when element sizes are dynamic.

“When CSS Grid shipped in March 2017, our toolbox reached a tipping point. At last we have technology powerful enough to let us really get creative with layout. We can use the power of graphic design to convey meaning through our use of layout—creating unique layouts for each project, each section, each type of content, each page.”
— Rachel Andrew, The New CSS Layout

In this way, HTML became cleaner and it was able to achieve its original purpose: a semantic description of the content.

Finally, thanks to alignment between the browsers and new capabilities, no-code tools are backed by powerful, uniform technology. These changes created a clearer distinction between declarative and imperative. New possibilities were created to solve old problems.

“Simplicity is the ultimate sophistication.”
— Leonardo da Vinci

The Effect Of No-code On Designers

The developments of the Internet over the years has led to a situation where the abstraction between design and code is constantly improving. This has implications for the way web designers plan and implement their designs.

1. Design Planning

While popular design tools use static content for dynamic web design, no-code tools allow designers to work with the web’s own materials.

“Photoshop is the most effective way to show your clients what their website will never look like.”
— Stephen Hay, author of Responsive Design Workflow

If we have a complex design with different states, micro-interactions, animations and responsive breakpoints — by using no-code tools we can work in a more tangible way.

Additionally, the development of the web enables no-code tools to clearly separate content from the design (which allows designers to visually manage real content). Reflecting the dynamic content in the design (e.g. text, images, videos, and audio), gives designers a clearer understanding of how it will appear.

The advantage of working in the no-code workspace is that interactions appear immediately. This allows designers to quickly test their design choices and see if they work.

2. Design Implementation

After investing in design perfection, designers should explain the visual and conceptual decisions to developers through prototypes. Prototypes not only take time in terms of preparation, but their design is also often implemented incorrectly due to misinterpretations.

With no-code tools, designers are able to place objects on their display and handle their visibility and behavior with ease and speed. In other words, they can design the end result without depending on anyone else.

To use myself as an example, when the Coronavirus pandemic hit, I worked with a small team on a project to help connect young volunteers to isolated seniors. In just three days, myself and another designer built the website and connected user registration data to a database, while the team’s developer worked to integrate data from the site into a separate mobile app.

The Effect Of No-code On Developers

Will no-code tools completely replace developers? The short answer: No. The significant change is in the way designers and developers can work together to create websites.

In addition to the development of CSS, Javascript has also evolved in parallel and perhaps even more. The idea that frontend developers need to control all the abilities makes no sense. And yet, the development of no-code over the years has enabled designers to build their own designs.

It’s a win-win situation, in which  developers can focus on developing logic, and designers have more control over the user experience and styling.

The Effort Is Not Yet Complete

I don’t want to leave you with the impression that designers have complete freedom to design with no-code tools. There are still some missing style capabilities that CSS has not yet solved, and these still require imperative development.

Unlike in the Middle Ages, where art was considered as handicraft without a theoretical basis, Renaissance developments changed the status of the artist — who was suddenly considered a polymath.

No-code tools remove bottlenecks, which allows designers to gain more ownership, influence, and control over the experiences they design.

We’ve come a long way from the days when designers weren’t able to bring their designs to life. As the Internet evolves, browsers align, capabilities are added and the accessibility of technology becomes easier — designers are faced with new opportunities to create, think, and change their status with no-code tools.

The no-code movement not only affects how things are done, but by who.

Credits: Yoav Avrahami and Jeremy Hoover contributed to this article.

Further Reading on SmashingMag:

Articles on Smashing Magazine — For Web Designers And Developers

Newer postsOlder posts

Social Chat is free, download and try it now here!