Ecommerce in Germany: Opportunity Amidst a Pandemic

Germany hosts Europe’s biggest economy and, with 83.7 million people, its second-largest population, after Russia. It is the fifth-largest ecommerce market in the world and the second-largest in Europe, behind the U.K. Eighty-five percent of the population has Internet access. Germany has one of the world’s best-developed logistics infrastructures and navigated the Covid-19 pandemic better than most European countries. It has limited the damage to its economy and offers a stable environment for ecommerce.

In short, Germany represents a good opportunity for online sales.

According to Statista, which adjusted its forecast to account for Covid-19 impacts, German ecommerce revenues will reach roughly US$82 billion in 2020, a 13 percent increase year-over-year.

Covid-19 Effects

Like other countries, Germany has experienced an uptick in online sales during the pandemic — especially for groceries and pharmacy items — and attracted shoppers who were not previously regular ecommerce customers. The products that are currently flourishing online are food and hygiene products. Online fashion sales have declined.

According to July research from AfterPay Insights, a European pay-after-delivery service, German consumers continued to shift purchases from offline to online in June.

Seventeen percent of German online shoppers say they shopped more online and less in physical stores in June, while 7 percent stated they shopped more in physical stores and less online. German shoppers say they will buy less overall but will do more of their purchasing online in July.

Before the pandemic, online-only merchants dominated ecommerce sales. German brick-and-mortar retailers have been slow to establish an online presence but Covid-19 prompted some to establish websites. The majority of brick-and-mortar retailers are small businesses with fewer than five employees; before the pandemic they saw little reason to sell online. Some of these businesses have formed small local online marketplaces that cooperate to deliver groceries and other goods locally.

Online Shoppers

German consumers prefer to shop from ecommerce sites that are in their native language and have a “.de” domain, according to the “Germany 2020: Ecommerce Country Report” from RetailX. Shoppers prefer detailed product descriptions. Cross-border sales are lower than in other European countries, with more consumers purchasing from national retailers. In 2019, 37 percent of German consumers bought from sellers abroad according to RetailX, mostly from China.

Electronics and apparel/accessories are the products Germans most frequently purchase online.

Laptops are the most popular devices for shopping online, with 58 percent of shoppers using them in 2019, according to RetailX. Smartphones have overtaken desktop computers to become the second most popular way to shop online in Germany, with 49 percent of respondents saying they use smartphones.

Germans like to return items. Any online merchant selling in Germany should be prepared for a high return rate. Apparel returns are roughly 40 percent, for example. German law requires retailers to offer a 14-day return period.


Another unique aspect of German ecommerce is the large number of consumers who pay via invoice. This aligns well with the lenient return policy. Invoicing means that consumers can receive and examine their goods without having to pay upfront. They can decide whether they want to keep or return them before paying. In 2019, 81 percent of German businesses still offered payment on account or invoice.

Gradually, Germans are adapting to digital payments, however. According to the Ecommerce Foundation, PayPal now accounts for 56 percent of online payments with invoices at 26 percent.

Major Online Sellers

Marketplaces dominate ecommerce in Germany, accounting for 40 percent of online revenues., which serves Germany, Austria, Belgium, Switzerland, and The Netherlands, accounts for about 35 percent of the German ecommerce market, according to RetailX. Seventy percent of shoppers pay by invoice, although 67 percent are now also using Amazon Pay and PayPal, according to research by German ecommerce association Handlerbund. The estimated monthly traffic on is 434.5 million visits. is the second most visited online etailer in Germany, with 25 percent of the total monthly visits and 22 percent of marketplace sales. It, too, offers payment terms via invoice. Another site, eBay Kleinanzeigen, focuses on used goods, memorabilia, and collectibles, which are popular among German consumers. eBay Kleinanzeigen has a 14 percent share of German marketplace sales, according to RetailX. has 25 percent of total marketplace visits in Germany and 22 percent of marketplace sales. has 25 percent of total marketplace visits in Germany and 22 percent of marketplace sales.

Otto. Founded in 1949 as a mail-order company, Otto is the leading German marketplace for home, fashion, sports, and electronics goods. It offers roughly 2 million products from around 5,000 brands, including its own label. The Otto Group operates in over 20 countries. Otto offers personalized service, with customer helplines staffed by real people. It also runs a logistics service.

Zalando. Headquartered in Berlin, Zalando offers clothing, shoes, sportswear, and beauty products in 17 European countries. It’s one of the best-known online sites in Germany, especially among females. Merchants and brands selling on the Zalando marketplace are increasing, with 250 signed up on the Zalando Partner Program. The company intends to bolster its third-party sales with Zalando Fulfillment Solutions and Zalando Marketing Services.

MediaMarkt. Founded in 1979 as a brick-and-mortar store, MediaMarkt is a German electronics seller, similar to Best Buy in the United States. It now operates in 12 other countries.

Notebooksbilliger primarily sells electronics and related media, maintaining a large online market share.

Lidl, a discount supermarket chain offering groceries and other goods, has become a household name across much of Europe. It has 10,000 stores across Europe and the United States. Its online store sells clothing, sporting goods, and home improvement products as well as groceries.

An Introduction To Stimulus.js

An Introduction To Stimulus.js

An Introduction To Stimulus.js

Mike Rogers

2020-07-15T10:30:00+00:00 2020-07-16T00:07:23+00:00

The web moves pretty fast and picking an approach for your frontend that will feel sensible in a year’s time is tricky. My biggest fear as a developer is picking up a project that hasn’t been touched for a while, and finding the documentation for whatever approach they used is either non-existent or is not easily found online.

About a year ago, I started using Stimulus and I felt really happy about the code I was shipping. It’s a ~30kb library which encourages small reusable sprinkles of JavaScript within your app, organized in such a way that it leaves little hints in your accessible HTML as to where to find the JavaScript it’s connected to. It makes understanding how a piece of JavaScript will interact with your page almost like reading pseudocode.

Stimulus was created by the team at Basecamp — they recently released the HEY email service — to help maintain the JavaScript they write for their web applications. Historically, Basecamp has been quite good around maintaining their open-source projects, so I feel quite confident that Stimulus has been tested thoroughly, and will be maintained for the next few years.

Stimulus has allowed me to build applications in a way that feels reusable and approachable. While I don’t think Stimulus will take over the web like React and Vue have, I think it is a worthwhile tool to learn.


Like all frameworks, Stimulus has preferred terms for describing certain things. Luckily (and one of the main reasons I’ve taken to liking Stimulus), there are only two you’ll need to know about:

  • Controller
    This refers to instances of JavaScript classes which are the building blocks of your application. It’s safe to say that when we talk about Stimulus Controllers, we’re talking about JavaScript classes.
  • Identifier
    This is the name we’ll use to reference our controller in our HTML using a data attribute that is common to Stimulus codebases.

Let’s Jump Into Stimulus!

In the following few examples, I’m going to use code you can drop into the browser to get started right away via the library distributed via Later on, I’ll cover the webpack approach which is highly encouraged as it allows for improved organization of your code and is the approach used in the Stimulus Handbook.

The Boilerplate

See the Pen [The Boilerplate – Stimulus]( by Mike Rogers.

See the Pen The Boilerplate – Stimulus by Mike Rogers.

Once you understand the gist of the above snippet, you’ll have the knowledge to be comfortable picking up a project that uses Stimulus.

Pretty awesome, right? Let’s jump into what everything is doing!


This line tells Stimulus to add the listeners to the page. If you call it just once at the top of your page before you add any Stimulus code, it’ll return an instance of the main Stimulus controller which includes the method register that is used to tell Stimulus about the classes you’d like to connect to it.


The data-controller attribute connects our HTML element to an instance of our JavaScript class. In this case, we used the identifier “counter” to hook up an instance of the CounterController JavaScript class to our div element. We told Stimulus about the connection between this identifier and the controller via the application.register method.

Stimulus will continuously monitor your page for when elements with this attribute are added and removed. When a new piece of HTML is added to the page with a data-controller attribute, it’ll initialize a new instance of the relevant controller class, then connect the HTML element. If you remove that element from the page, it’ll call the disconnect method on the controller class.


Stimulus uses a data attribute data-action to clearly define which function of the controller will be run. Using the syntax event->controller#function anyone reading the HTML will be able to see what it does. This is especially useful as it reduces the risk of unexpected code from other files, making it easier to navigate the codebase. When I first saw the approach Stimulus encourages, it felt almost like reading pseudocode.

In the above example, when the button fires the “click” event, it will be passed onto the addOne function within our “counter” controller.


Targets are a way to explicitly define which elements are going to be available to your controller. Historically I’ve used a mix of ID, CSS class names and data attributes to achieve this, so having a single “This is the way to do it” which is so explicit makes the code a lot more consistent.

This requires defining your target names within your controller class via the targets function and adding the name to an element via the data-target.

Once you’ve got those two pieces setup, your element will be available in your controller. In this case, I’ve set up the target with the name “output” and it can be accessed by this.outputTarget within the functions in our controller.

Duplicate Targets

See the Pen [Duplicate Targets – Stimulus]( by Mike Rogers.

See the Pen Duplicate Targets – Stimulus by Mike Rogers.

If you have multiple targets with the same name, you can access them by using the plural version of the target method, in this case when I call this.outputTargets, it’ll return an array containing both my divs with the attribute data-target="hello.output".

Event Types

You listen for any of the events you’d commonly be able to attach via the JavaScript method addEventListener. So for example, you could listen for when a button is clicked, a form is submitted or an input is changed.

See the Pen [Event types – Stimulus]( by Mike Rogers.

See the Pen Event types – Stimulus by Mike Rogers.

To listen to window or document events (such as resizing, or the user going offline), you’ll need to append “@window” or “@document” to the event type (e.g. resize@window->console#logEvent will call the function logEvent) on the console controller when the window is resized.

There is a shorthand way to attach common events, where you are able to omit the event type and it has a default action for the element type. However, I strongly discourage using the event shorthand, as it increases the amount of assumptions someone who is less familiar with Stimulus needs to make about your code.

Uses Multiple Controllers In The Same Element

Quite often you may want to break out two pieces of logic into separate classes, but have them appear close to each other within the HTML. Stimulus allows you to connect elements to multiple classes by placing references to both within your HTML.

See the Pen [Multiple Controllers – Stimulus]( by Mike Rogers.

See the Pen Multiple Controllers – Stimulus by Mike Rogers.

In the above example, I’ve set up a basket object which only concerns itself with counting the total number of items in the basket, but also added a child object that shows the amount of bags per item.

Passing Data To Your Object

See the Pen [Passing Data – Stimulus]( by Mike Rogers.

See the Pen Passing Data – Stimulus by Mike Rogers.

Stimulus provides the methods and within the controller class, this will allow you to change data attributes which are within the same namespace as the identifier. By this I mean if you want to pass data to your stimulus controller from your HTML, just add an attribute like data-[identifier]-a-variable to your HTML element.

When calling, it will update the value in your HTML so you can see the value change when you inspect the element using your browser development tools.

Using namespaced data attributes is a really nice way to help make it really clear which data attribute is for what piece of code.

Initialize, Connected, Disconnected

As your application grows, you’ll probably need to hook into ‘lifecycle events’ to set defaults, fetch data, or handle real-time communication. Stimulus has three build-in methods which are called throughout the lifecycle of a Stimulus class.

See the Pen [Initialize, Connected, Disconnected – Stimulus
]( by Mike Rogers.

See the Pen Initialize, Connected, Disconnected – Stimulus
by Mike Rogers.

When Stimulus sees an element with a matching data-controller attribute, it will create a new version of your controller and call the initialize function. This will often run when you first load the page, but will also be run if you were to append new HTML to your page (e.g. via AJAX) containing a reference to your controller. It will not run when you move an element to a new position within your DOM.

After a class has been initialized, Stimulus will connect it to the HTML element and call the connect function. It’ll also call connect if you were to move an element within your DOM. So if you were to take an element, remove it from one element, then append it somewhere else, you’d notice only connect will be called.

The disconnect function will be run when you remove an element from your page, so for example, if you were to replace the body of your HTML, you could tear down any code which might need to be rerun if the element isn’t in the same position. For example, if you had a fancy WYSIWYG editor which adds lots of extra HTML to an element, you could revert it to its original state when disconnect was called.

Inheriting Functionality

On occasion, you may want to share a little common functionality between your Stimulus controllers. The cool thing about Stimulus is that (under the hood) you’re connecting somewhat vanilla JavaScript classes to HTML elements, so sharing functionality should feel familiar.

See the Pen [Inheriting functionality – Stimulus]( by Mike Rogers.

See the Pen Inheriting functionality – Stimulus by Mike Rogers.

In this example, I set up a parent class named ParentController, which is then extended by a child class named ChildController. This let me inherit methods from the ParentController so I didn’t have to duplicate code within my ChildController.

Using It In Production

I demonstrated some fairly stand-alone examples of how to use Stimulus above, which should give you a taste of what you can achieve. I also thought I should touch on how I use it in production and how it has worked out for me.


If you’re using Webpack, you’re in for a treat! Stimulus was totally made to be used with Webpack. Their documentation even has a lovely starter kit for Webpack. It’ll allow you to break your controllers into separate files and Stimulus will decide on the correct name to use as an identifier.

You don’t have to use webpack if you want to use Stimulus, but it cleans up the experience a bunch. Personally, Stimulus was the library that helped introduce me to Webpack and really feel the value it offered.

Filename Conventions

I mentioned in the introduction of this article that I enjoyed using Stimulus because it felt organized. This really becomes apparent when you are combining it with Webpack, which enables auto loading and registration of controllers.

Once you’ve set up Stimulus in Webpack, it’ll encourage you to name your files like [identifier]_controller.js, where the identifier is what you’ll pass into your HTMLs data-controller attribute.

As your project grows, you may also want to move your Stimulus controllers into subfolders. In a magical way, Stimulus will convert underscores into dashes, and folder forward slashes into two dashes, which will then become your identifier. So for example, the filename chat/conversation_item_controller.js will have the identifier chat--conversation-item.

Maintaining Less JavaScript

One of my favorite quotes is “The Best Code is No Code At All”, I try to apply this approach to all my projects.

Web browsers are evolving a lot, I’m pretty convinced that most of the things I need to write JavaScript for today will become standardized and baked into the browser within the next 5 years. A good example of this is the details element, when I first started in development it was super common to have to manually code that functionality by hand using jQuery.

As a result of this, if I can write accessible HTML with a sprinkling of JavaScript to achieve my needs, with the mindset of “This does the job today, but in 5 years I want to replace this easily” I’ll be a happy developer. This is much more achievable when you’ve written less code to start with, which Stimulus lends itself to.

HTML First, Then JavaScript

One aspect I really like about the approach Stimulus encourages, is I can focus on sending HTML down the wire to my users, which is then jazzed up a little with JavaScript.

I’ve always been a fan of using the first few milliseconds of a user’s attention getting what I have to share with them — in front of them. Then worrying setting up the interaction layer while the user can start processing what they’re seeing.

Furthermore, if the JavaScript were to fail for whatever reason, the user can still see the content and interact with it without JavaScript. For example, instead of a form being submitted via AJAX, it’ll submit via a traditional form request which reloads the page.


I love building sites that need just small sprinkles of maintainable JavaScript to enhance the user experience, sometimes it’s nice to just build something which feels simpler. Having something lightweight is great, I really love that without too much cognitive load it’s pretty clear how to organize your files, and set up little breadcrumbs that hint about how the JavaScript will run with a piece of HTML.

I’ve really enjoyed working with Stimulus. There isn’t too much to it, so the learning curve is fairly gentle. I feel pretty confident that if I was to pass my code onto someone else they’ll be happy developers. I’d highly recommend giving it a try, even if it’s just out of pure curiosity.

The elephant in the room is how does it stack up compared to the likes of React and Vue, but in my mind, they’re different tools for a different requirement. In my case, I’m often rendering out HTML from my server and I’m adding a little JavaScript to improve the experience. If I was doing something more complex, I’d consider a different approach (or push back on the requirements to help keep my code feeling simple).

Further Reading

  • Stimulus Homepage
    They have a fantastic handbook that goes into the concepts I’ve outlined above into a lot more depth.
  • Stimulus GitHub Repository
    I’ve learned so much about how Stimulus works by exploring their code.
  • Stimulus Cheatsheet
    The handbook summarized on a single page.
  • Stimulus Forum
    Seeing other people working with Stimulus has made me really feel like it’s being used in the wild.
Smashing Editorial (sh, ra, yk, il)

SmashingConf Fully Online For 2020

SmashingConf Fully Online For 2020

SmashingConf Fully Online For 2020

Rachel Andrew

2020-07-14T14:30:00+00:00 2020-07-15T00:06:10+00:00

2020 has been quite the year, and it’s only July. None of us can be certain what the rest of the year looks like, in particular for travel and events where lots of folks gather together. Given the uncertainty and the success of our online workshop series and Meets events, we’re taking all of our 2020 conferences online. How will that work? Read on to find out!

All of our online conference events will take place on the Hopin platform. We roadtested this platform for our Smashing Meets, and we love the way it allows for social chat and side events alongside the main conference. It’s as close as we can get to an in-person experience.

First Up: The Rescheduled SmashingConf Live!

We will be presenting SmashingConf Live on August 20th-21st. Two half-days, with four talks each day on UX, data visualization, CSS, and JavaScript.

Meet other people in our chat or network on our event platform. Join in on our Design and Coding Tournament, or enjoy watching folks taking part.

Join one of the many sessions! Listen to one of the fireside chats on privacy, web performance, and Machine Learning (ML). Get your website reviewed by one of our speakers.

Take a look at the full schedule. If you have bought a ticket to the postponed SmashingConf Live, your ticket will still be valid. We still have tickets available: register here and we will see you at the event.

We are still scheduling new workshops and repeats of our most popular workshops. Purchase a workshop with your conference ticket and save 100USD.

Then, we have moved our in-person events online. These will be as close as possible to the in-person experience, with side-events, a mystery speaker, and all the fun you expect from a SmashingConf.

September 7th–8th: SmashingConf Freiburg Online

SmashingConf Freiburg Online 2020The Freiburg conference is moving online on the original dates: September 7th–8th. One track, two days and 13 speakers, with all of the actionable insights you expect from SmashingConf. We’ll be running the event tied to the timezone in Germany — making this a great event for Europeans. Check out the schedule, and buy tickets here.

October 13th–14th: SmashingConf Austin (and New York) Online

SmashingConf Austin Online 2020We have combined the programming for New York and Austin as these two events were so close together and similar to each other. We’ll be running this event in Central time, just as if we were all in Austin. Check out the schedule, and buy tickets here. We’d love to see you in October!

November 10th–11th: SmashingConf San Francisco Online

SmashingConf San Francisco Online 2020In PST join us for a virtual San Francisco event on November 10th–11th. The schedule and tickets are online for you to take a look. We’ll be sure to have a great celebration for our final event of 2020!

Existing Ticketholders

We have moved your in-person ticket to the 2021 edition of your chosen conference and in order that you don’t miss out this year, you are invited to the online version of the event you registered for. Two for the price of one as our thanks for your support. If that doesn’t work out for you, we do have options as explained in the email. Didn’t get the email? Drop the team a line at and we will get back to you.

Join Us!

There are tickets now on sale for all of the above events — we are really looking forward to all of them! One thing we have learned with our online workshops is that taking events online means that lots of people can attend who can’t travel to conferences even in more usual times. That’s really exciting, and we look forward to sharing some days of learning and fun with you all!

Smashing Editorial (cr, aa, il)

To Master Data Visualization, Start with These 3 Books

Your boss requested an urgent report that shows the trends of key metrics in Google Analytics. You need to locate the data and create a few charts. What kind of charts should you choose? What colors should you use? Should you create a dashboard? Or maybe a story?

An understanding of data visualization informs all of these decisions. Here are three books to get started.

Essential Data Visualization Books

Storytelling with Data by Cole Nussbaumer Knaflic

Storytelling with Data

Storytelling with Data

“Storytelling with Data” ignited my passion for data visualization. The book is accessible for beginners and is structured around six key data visualization concepts:

  • Understand the context,
  • Choose an appropriate visual display,
  • Eliminate clutter,
  • Focus attention on where you want it,
  • Think like a designer,
  • Tell a story.

Each chapter covers one data visualization lesson and includes many simple, practical examples, as well as step-by-step instructions. “Storytelling with Data” provides an excellent foundation to prepare for advanced data visualization topics. A key passage in the book:

What do you need your audience to know or do? This is the point where you think through how to make what you communicate relevant for your audience and form a clear understanding of why they should care about what you say.

Avoiding Data Pitfalls by Ben Jones

Avoiding Data Pitfalls

Avoiding Data Pitfalls

Too often, we think of data visualization only from a design perspective. However, the design process is the middle step. We first need a clear understanding of the data itself. “Avoiding Data Pitfalls” is a helpful resource to increase data literacy. It’s an easy read, packed with examples. The author provides a structure for thinking about data and avoiding seven common pitfalls:

  • “Epistemic [knowledge] errors,”
  • “Technical trespasses,”
  • “Mathematical miscues,”
  • “Statistical slipups,”
  • “Analytics aberrations,”
  • “Graphical gaffes,”
  • “Design dangers.”

Here’s a favorite paragraph in the book:

But when is a given data set clean enough? Like a kitchen countertop, it can always be cleaner. We hit a point of diminishing returns in our preparation of any data set, though, where more elbow grease and scrubbing doesn’t yield sufficient incremental benefit to warrant the time and effort.

Info We Trust by RJ Andrews

Info We Trust

Info We Trust

What comes after a visualization — the storytelling piece — is just as essential as the data before it. “Info We Trust,” published in 2019, teaches data storytelling. The book does not include how-tos. Instead, it convinces the reader that data is beautiful. The book provides a deep understanding of why and how we tell stories with data — addressing history, philosophy, and human psychology. The book also contains fascinating illustrations, all drawn by the author.

“Info We Trust” is a dive deep into the art of storytelling. It’s unlike any other data visualization book.

Here’s an excerpt:

To harness data, the world needs information: more information, better information, more complex and more nuanced understanding, and better narratives that can show ways for all to flourish. […] To be a data storyteller is to be a creator, a maker, a constructor. We do not just make information, but new and enthusiastic visions of how things are and how they might be.

Broad Perspective

The three books provide a broad perspective and a deeper understanding of the craft and science of data visualization. “Storytelling with Data” addresses design aspects. “Avoiding Data Pitfalls” stresses the importance of understanding the data. And “Info We Trust” explains the importance of data storytelling.

Is Redesigning Your Mobile App A Bad Idea?

Is Redesigning Your Mobile App A Bad Idea?

Is Redesigning Your Mobile App A Bad Idea?

Suzanne Scacca

2020-07-14T11:00:00+00:00 2020-07-20T01:08:02+00:00

I’m all for updating and upgrading mobile apps. I think if you’re not constantly looking at ways to improve the user experience, it’s just too easy to fall behind.

That said, a redesign should be done for the right reasons.

If it’s an existing app that’s already popular with users, any changes made to the design or content should be done in very small, incremental, strategic chunks through A/B testing.

If your app is experiencing serious issues with user acquisition or retention, then a redesign is probably necessary. Just be careful. You could end up making things even worse than they were before.

Let’s take a look at some recent redesign fails and review the lessons we can all learn from them.

Lesson #1: Never Mess With A Classic Interface (Scrabble GO)

Scrabble is one of the most profitable board games of all time, so it’s no surprise that EA decided to turn it into a mobile app. And it was well-received.

However, that all changed in early 2020 when the app was sold to Scopely and it was redesigned as an ugly, confusing and overwhelming mess of its former self.

Let me introduce you to Scrabble GO as it stands today.

The splash screen introducing gamers into the app looks nice. Considering how classically simply and beautiful the board game is, this is a good sign. Until this happens:

Scrabble GO home screen
The Scrabble GO home screen is distraction overload. (Source: Scrabble GO) (Large preview)

I don’t even know where to start with this, but I’m going to try:

  • The colors are way over-the-top and there are too many.
  • Since “Start New Game” is the primary action users want to take, it should be the only button in that color, but “Level 5” and “Level 6” distract from it.
  • The interface is so cluttered that it’s hard to focus on any particular part of it.
  • There’s no sense of control or priority within the design.
  • The navigation has gated pages! And I’m not sure what that icon on the left is supposed to be… gems and rewards? Why then is there a gem counter in the top banner?

Beyond the UI of the homescreen, the UI and UX within the game board have been altered, too.

Take, for instance, this plea from @lageerdes on Twitter:

Twitter user @lageerdes tells Scrabble GO she wants the old app back
Twitter user @lageerdes asks Scrabble GO why the old functionality is gone. (Source: Twitter) (Large preview)

It took Scrabble GO over a week to tell @lageerdes something that could’ve easily been spelled out in a game FAQ or Settings page. These aren’t the only classic features that the new app has either complicated or done away with.

Now, Scopely took note of the negative comments from users and promised to revamp the app accordingly (which was promising). But rather than revert back to the old and much-loved design, it just added a new mode:

Scrabble GO settings with 'Mode Settings'
Scrabble GO added new ‘Mode Settings’ to appease users. (Source: Scrabble GO) (Large preview)

You’d think that the mode switcher would be more prominently displayed — like in the menu bar. Instead, it’s buried under the “Profile Settings” tab and there’s no indication anywhere in the app that the classic mode even exists.

Sadly, classic mode isn’t much of an improvement (classic is on the right):

Scrabble GO home screen vs. the newly designed classic home screen
The new Scrabble GO home screen versus the newly designed classic mode home screen. (Source: Scrabble GO) (Large preview)

The colors are toned down, some of the elements in the top-half have been cut out or minimized, but it doesn’t address any of the users’ issues with the app or game play.

Worse, many users are reporting the app crashes on them, as this complaint from Twitter user @monicamhere demonstrates:

Twitter user @monicamhere complains that Scrabble GO app crashes
Twitter user @monicamhere complains to Scrabble GO about the app crashing. (Source: Twitter) (Large preview)

I suspect this is happening because the developers jammed a second overloaded mode into the app rather than simply refine the existing one based on user feedback.

So, what’s the lesson here?

  • For starters, don’t mess with a classic.
    The old mobile app closely resembled the physical board game and it was a huge part of its appeal. When you throw out an old design for something (seemingly) more trendy, you run the risk of alienating once-loyal users.
  • Also, if it ain’t broke, don’t fix it.
    Previously, the app was very easy to use and came with all the features and functionality users were familiar with from the board game. Now, they’re left with a non-intuitive and distracting mess.
  • If your users are telling you to ditch the redesign, listen to them.
    Who are you building this app for? Yourself or the users who are going to play with it and put money into your pocket?

Listen to what your users have to say. It’s valuable feedback that could make a world of difference in the user experience.

Lesson #2: Never Mislead Users At Checkout (Instacart)

This is an interesting case because the people who objected to this particular Instacart UI update weren’t its primary users.

Here’s why the change was an issue:

Users go onto the Instacart website or mobile app and do their grocery shopping from the local store of their choice. It’s a pretty neat concept:

Instacart mobile app - shopping with Wegmans
Instacart users can do virtual shopping with grocery stores like Wegmans. (Source: Instacart) (Large preview)

Users quickly search for items and add them to their virtual shopping cart. In many cases, they have the option to either do curbside pickup or have the groceries delivered to their front doorstep. Either way, a dedicated “shopper” picks out the items and bags them up.

When the user is done shopping, they get a chance to review their cart and make final changes before checking out.

On the checkout page, users get to pick when they want their order fulfilled. Beneath this section, they find a high-level summary of their charges:

Instacart checkout tab with summary of charges
Instacart checkout sums up the total costs of a user’s order. (Source: Instacart) (Large preview)

At first glance, this all appears pretty-straightforward.

  • The cost of their cart is $174.40, which they already knew.
  • There’s a service fee of $9.99.
  • Sales tax is $4.11.
  • And the total is $197.22.

But before all that is a section called “Delivery Tip”. This is where Instacart’s shoppers take issue.

They argued that this is a dark pattern. And it is. Let me explain:

The first thing that’s wrong is that the Delivery Tip isn’t included with the rest of the line items. If it’s part of the calculation, it should be present down there and not separated out in its own section.

The second thing that’s wrong is that the tip is automatically set at 5% or $2.00. This was the shoppers’ biggest grievance at the time. They believed that because the “(5.0%)” in the delivery tip line wasn’t there in 2018, users might’ve seen the amount and thought “That seems reasonable enough” and left it at that. Whereas if you spell out the percentage, users may be inclined to leave more money.

For users who take the time to read through their charges and realize that they can leave a larger tip, this is what the tip update page looks like for small orders:

Instacart delivery tip customization
Instacart enables users to change the way they tip the delivery person. (Source: Instacart) (Large preview)

It’s oddly organized as the pre-selected amount sits at the very bottom of the page. And then there’s a random $6 tip included as if the app creators didn’t want to calculate what 20% would be.

That’s not how the tip is presented to users with larger orders though:

Instacart users can customize delivery tip on big orders
Instacart enables users to customize the tip they leave the delivery person, from 5% to 20% or they can customize the amount. (Source: Instacart) (Large preview)

It’s a strange choice to present users with a different tip page layout. It’s also strange that this one includes an open field to input a custom tip (under “Other amount”) when it’s not available on smaller orders.

If Instacart wants to avoid angering its shoppers and users, there needs to be more transparency about what’s going on and they need to fix the checkout page.

Dark patterns have no place in app design and especially not at checkout.

If you’re building an app that provide users with delivery, pickup or personal shopper services (which is becoming increasingly more common), I’d recommend designing your checkout page like Grubhub’s:

Grubhub checkout page with tips
The Grubhub checkout page recaps the user’s order and provides tip amounts in percentages. (Source: Grubhub) (Large preview)

Users not only get a chance to see their items at the time of checkout, but the tip line is not deceptively designed or hidden. It sticks right there to the bottom of the page.

What’s more, tips are displayed as percentage amounts instead of random dollars. For U.S. consumers that are used to tipping 20% for good service, this is a much better way to ensure they leave a worthwhile tip for service workers rather than assume the dollar amount is okay.

And if they want to leave more or less, they can use the “Custom” option to input their own value.

Lesson #3: Never Waver In Your Decision To Roll Back (YouTube)

When the majority of your users speak up and say, “I really don’t like this new feature/update/design”, commit to whatever choice you make.

If you agree that the new feature sucks, then roll it back. And keep it that way.

If you don’t agree, then tweak it or just give it time until users get back on your side.

Just don’t flip-flop.

Here’s what happened when YouTube switched things up on its users… and then switched them again:

In 2019, YouTube tested hiding its comments section beneath this icon:

The Verge and XDA Developers - YouTube comments test
The Verge and XDA Developers report on a new placement of YouTube comments in 2019. (Source: Verge) (Large preview)

Before this test, comments appeared at the very bottom of the app, beneath the “Up next” video recommendations. With this update, however, they were moved behind this new button. Users would only see comments if they clicked it.

The response to the redesign clearly wasn’t positive as YouTube rolled back the update.

In 2020, YouTube decided to play around with the comments section again. Unlike the 2019 update, though, YouTube’s committed to this one (so far).

Here’s where the comments appear now:

YouTube comments section design in 2020
The YouTube comments redesign puts the comments above the ‘Up next’ section. (Source: YouTube) (Large preview)

They’re sandwiched between the “Subscribe” bar and the “Up next” section.

If YouTube users go looking for the comments section in the old spot, they’re going to find this message now:

YouTube notice: ‘Comments have moved’
A notice appears when YouTube users go looking for comments in the old location. (Source: YouTube) (Large preview)

This is a nice touch. Think about how many times you’ve had to redesign something in an app or on a website, but had no way of letting regular users know about it. Not only does this tell them there’s been a change, but “Go To Comments” takes them there.

With this tooltip, YouTube doesn’t assume that users will zero in on the new section right away. It shows them where it is:

YouTube new comments section tooltip
YouTube users see tooltip that shows them where the new comments section is. (Source: YouTube) (Large preview)

I actually think this is a good redesign. YouTube might be a place for some users to mindlessly watch video after video, but it’s a social media platform as well. By hiding the comments section under a button or tucking them into the bottom of the page, does that really encourage socialization? Of course not.

That said, users aren’t responding well to this change either, as Digital Information World reports. From what I can tell, the backlash is due to Google/YouTube disrupting the familiarity users have with the app’s layout. There’s really nothing here that suggests friction or disruption in their experience. It’s not even like the new section gets in the way or impedes users from binge-watching videos.

This is a tricky one because I don’t believe that YouTube should roll this update back.

There must be something in YouTube’s data that’s telling it that the bottom of the app is a bad place for comments, which is why it’s taking another stab at a redesign. It might be low engagement rates or people expressing annoyance at having to scroll so much to find them.

As such, I think this is a case for a mobile app developer not to listen to its users. And, in order to restore their trust and satisfaction, YouTube will need to hold firm to its decision this time.

Is A Mobile App Redesign The Best Idea For You?

Honestly, it’s impossible to please everyone. However, your goal should be to please, at the very least, most of your users.

So, if you’re planning to redesign your app, I’d suggest taking the safe approach and A/B testing it first to see what kind of feedback you get.

That way, you’ll only push out data-backed updates that improve the overall user experience. And you won’t have to deal with rolling back the app or the negative press you get from media outlets, social media comments, or app store reviews.

Further Reading on SmashingMag:

Smashing Editorial (ra, yk, il)

Smashing Podcast Episode 20 With Marcy Sutton: What Is Gatsby?

Smashing Podcast Episode 20 With Marcy Sutton: What Is Gatsby?

Smashing Podcast Episode 20 With Marcy Sutton: What Is Gatsby?

Drew McLellan

2020-07-14T05:00:00+00:00 2020-07-27T01:35:24+00:00

Photo of Marcy SuttonToday, we’re talking about Gatsby. What is it and how does it fit into your web development stack? Drew McLellan talks to expert Marcy Sutton to find out.

Show Notes

Weekly Update


Drew McLellan: She is the lead engineer on the Developer Relations team at Gatsby. Previously, she worked on the open source axe-core accessibility testing library, and has also worked as an accessibility engineer at Adobe. She’s passionate about improving the web for people with disabilities and often speaks about it at conferences. In 2016, O’Reilly gave her web platform award for a work in accessibility.

Drew: She also co-leads the accessibility Seattle and NW Tech Women Meetups in a local region. So, we know she’s a skilled engineer and an accessibility expert. But did you know she wants to send it Angel Falls in a barrel? My smashing friends please welcome Marcy Sutton.

Marcy Sutton: Hello.

Drew: Hello. Marcy. How are you?

Marcy: I’m smashing. How are you?

Drew: I’m very good. Thank you. I wanted to talk to you today about Gatsby. Because it came up in a conversation I was having on a previous episode about learning React with Mina Markham. I realized I was in danger of doing the typical man on the internet thing of giving an opinion on something that I had no direct experience of. So that’s not how we do things at Smashing.

Drew: And I want to make sure that we properly cover Gatsby. And what better way to do it than to talk somebody who knows it inside and out. So, presuming that perhaps I’ve heard the name Gatsby. But I’ve got no idea where it fits into the stack when building website. What exactly is Gatsby.

Marcy: Gatsby is a website generator, it currently uses React. But it will create a static website for you that then will rehydrate into a full React web application. So you really get the best of both worlds with fast builds that you’re compiling HTML files that will load fast for users. And then you get all of this enhancement with JavaScript to make really interactive dynamic web apps.

Marcy: So, it’s really exciting space to be in. And I’ve been working on the learning side with documentation and now on the Devrel team, I’m focused on making it as good as it can be, knowing accessibility challenges with JavaScript and just trying to fix it from the inside out.

Drew: Many of us will be familiar, I guess, with the concept of a static site generator. And Gatsby seems to broadly fit into that role. But to me, it seems like it goes a lot further than the most SSG’s do. And most site generators are front-end code agnostic. It seems that with Gatsby, you end up with Gatsby code running as part of your site. Is that a fair assessment? And if so, what sort of things is Gatsby actually doing in your front-end?

Marcy: Yes, I’d say the biggest piece of that is client side routing. So, Gatsby right now is using reach router under the hood. It does kind of its own implementation. But that is the piece that when you load your static site for the first time, there are HTML files there. So, if the user turns JavaScript off for some reason, your site should still be there, still have content.

Marcy: But if JavaScript is enabled, that’s when this hydration step happens where, when you use links in your Gatsby site, it will go pre-fetch resources from that page, so it will load faster. So, that is all enabled with this JavaScript layer that Gatsby gives you. And so beyond that, it really depends kind of what you’re using in your site will end up in that JavaScript bundle.

Marcy: But for things that use a lot of interactivity, like accessible interfaces, that’s a good place to be. For me, I really enjoy having JavaScript available to me at all times, and having my markup just be in a good spot. I know it’s a matter of preference, whether you want your HTML and your JavaScript and your CSS all kind of neatly coupled and there’s room for variations within building Gatsby

Marcy: You don’t always have to use something like CSS and JS. But it’s really about getting the power of that dynamic JavaScript layer, available to you while you’re writing your website. It’s not like this add on in a separate file.

Drew: When I think of how a static site generator usually works, I’m thinking of content in perhaps Markdown files. And the generator runs across that content and merges it with templates and creates 10s, hundreds, thousands of HTML files, which are the pages of your website. When I think of a React site or app, I’m thinking more about single page experience where the interfaces be created by React on the fly. So, you’re saying Gatsby does both of those? It’s creating all the pages and also enhancing it with JavaScript?

Marcy: It is, yes. Gatsby will use Node.js at build time, it will go over your React components and compile them into HTML files. Which honestly, the first time I looked at Gatsby I wouldn’t turn JavaScript off and was like, “All right, are there other pages here, what is this?” And I was so happy that Gatsby works that way by default. It will create built files from your react components, which is awesome.

Marcy: I have explored more progressive enhancement approaches since it’s in JavaScript. Like what if you want to output something progressively enhanced for users, where if they do have JavaScript turned off, you don’t want all this broken code that assumes JavaScript is there. So there are some quirks with it. But you can work around that kind of thing at least for your core user flows where you want someone to still be able to buy something, you might need to add some support and for those use cases.

Marcy: But I’ve been pleasantly surprised that the way that Gatsby rolls that out by default. And so, it is a choice that they made to build sites that way, and we’re always evaluating it. Is it still the best way? What do we need to do to give our users what they’re asking for? So, we’re doing some explorations internally, ongoing just to make sure Gatsby is doing the best job it can at building a website.

Marcy: So keeping bundle sizes small, and making sure that for making trade offs for what we say is performant code with pre-fetching. Like, do we have the data to back that up? That’s the kind of thing as a developer advocate that I’m super interested in, is making sure that what we’re packaging and bundling on websites is actually needed and will really make the best Gatsby site it can make.

Drew: You mentioned performance there, and there’s a big focus on performance. It certainly seems from the way that Gatsby presents itself. Is that a true feature of Gatsby or is it just the nature of JAMstack websites?

Marcy: I think it can be a nature of JAMstack websites. Ultimately, it’s going to come down to what you’re bundling on your website. So, no matter what framework or tool you’re using, we still have to be thoughtful in what we’re putting in those bundles for end users. But Gatsby really aims to give you good defaults. Not only for performance, but for accessibility as well.

Marcy: But that always takes evaluation, we always have to make sure that if we’ve added something, that it’s still performant. But yeah, getting that initial payload of static files, they load fast. Much faster than classic WordPress site that I used to have. But then enhancing it with JavaScript. There are some trade offs there for sure.

Marcy: But it works really well, lots of people, they really like their Gatsby sites. So, it’s been fun to get to work on it full time, and learn the ins and outs of a JavaScript framework like Gatsby.

Drew: What sort of performance features just Gatsby actually put into place to speed up your sites?

Marcy: Well, with the pre-fetching for links, this client said routing stuff, I’d say that’s probably the biggest one. Making it really easy to generate a progressive web app. So, having some offline capabilities, you can sort of pick and choose what you want in terms of offline and PWA type stuff. But they really make that part of the initial experience, like a lot of the starter example sites that you might start from have examples of using a manifest, and kind of making that modern version of your website.

Marcy: Really, it’s like not shipping code that you don’t need. That’s a big part of it. Caching, that’s really the pre-fetching for links. That’s what I would say is the biggest piece of it.

Drew: So this is where the site is actually anticipating where the user is going to go. Is it as intelligent as that or does it pre-fetch everything on the page or?

Marcy: No, it’s based on user interaction. So, if the user scrolls down the View port, there’s something pre-fetching that happens there. If you hover over links, it will kind of estimate that there’s a pretty good chance that you might go to that page. We’ve been talking internally, well, I guess, open source to about whether that pre-fetching should happen on keyboard focus too, so that intersection of accessibility and performance is very interesting.

Marcy: There’s some trade offs there like should a keyboard user who can’t use the mouse and is tabbing through every link to navigate, should that really be fetching content for every single one of those because a mouse user might be a bit more selective about where they put their mouse cursor. So, those conversations I find extremely fascinating.

Marcy: And trying to think of what data do we need to validate these assumptions too. So yeah, it’s been super interesting to look at those defaults and what improvements can we make and really checking like how much data is that fetching? Is that really a good thing? Just to speed it up a little bit? Or is it fast enough without that? Are there alternative solutions that we could use as part of the fun of working on a framework because being able to evaluate all those trade offs.

Drew: This is pre-fetching something that users just get for free in their site. So do they have to do any work to implement it?

Marcy: You do get it for free using Gatsby link. So it’s a component that comes with Gatsby and when you use that, it outputs anchor tags. So your HTML is real HTML and you’ve leveraged the web platform in that way. But in your React components, you are working directly with the Gatsby link component. And that has all of those mechanisms for… It looks at whatever your future HREF will be, for that link of where you want to go to and it will go and grab resources from that link and preload them.

Marcy: And it’s only internal to your site. So it’s not going off and trying to fetch things on other websites. But it seems to work pretty well. I know some users are actively looking for ways, like you actually have to opt out of some of these things. At least routing, not using the pre-fetching. You just use regular anchor tags. And then you don’t really get that functionality. It’s pretty easy to use something else. But some of the discussions we’re having are around client side routing, and how to make that the best it can be. And so, that’s a really interesting space too.

Drew: How closely do you have to work within the Gatsby ecosystem in terms of if I wanted to have my own link component? Would that be completely fine, I wouldn’t be fighting against Gatsby to do that sort of thing?

Marcy: No, you could slot in whatever components you want, as long as they work with the React runtime. That’s really the beauty of it. Anything you could put in a React app, you could put in a Gatsby app. There’s even a pre-React plugin. So, there are some alternatives to working with Gatsby. But I love how you can pull in whatever, off the shelf components that you want to use or write your own.

Marcy: And I think that flexibility is what people really enjoy. There is the caveat of it uses the React runtime. And so, you have to be okay with using react or using this pre-React plugin. But personally, I really like react and JSX for working with accessibility and templates, especially with React hooks. So, being able to use the hut in my Gatsby site is just so cool. I really like it.

Drew: And how’s the process of building a Gatsby site that’s presumably a node module that you can just install and you would do a build like you would with any other static site generator?

Marcy: Yes. There is a CLI that you install globally. And I guess it’s whether you want to install it globally. That’s what we recommend, because then you can run it from any directory on your computer, but it will pull down whatever you need to build a Gatsby site. And then you can add on, say you wanted to use WordPress as a headless CMS or some other content source.

Marcy: You can install packages, plugins to make that work, and then integrate it with your site. There’s also some starters and themes that you can use to get up and running quicker. I’ve used those if I want to test out something or start a site rapidly for a specific integration like Drupal or prismic or whichever CMS or eCommerce solution or something I want to use.

Marcy: There’s lots of examples. So you’re not always tinkering with trial and error trying to figure it out, but it’s sort of these building blocks that you can piece together and create… It’s what we call the content mesh. And so, you can use these best in breed integrations to create a site instead of, if I had a classic WordPress site, the authoring experience and working with teams is really great.

Marcy: But there were shortcomings in the front end, like how it would work on a mobile device. What else? If I wanted an eCommerce solution? I think there’re some things that are easier to do these days, but being able to pick whichever kind of best solutions you want for authentication, or whatever that modern thing is, you’re like, “I wish I could use that.” With Gatsby, you can pull a lot of these things together and make this content mesh way of building that’s pretty refreshing.

Marcy: Especially when you can still use those integrations like WordPress and still work with teams. So, we’re pretty excited about this new way of working where you can pick all the technologies that you’ve like, or that work for your team.

Drew: One of the big features that Gatsby has tout strongly is this ability to pull in data or content from a variety of different sources. You mentioned things like WordPress and Drupal, and what have you. Traditionally, if I was using something like Jekyll or Eleventy, or something like that, I would need to wire up that myself to interact with API’s, perhaps pull content down and write it into markdown files or JSON files, and then have the generator work with those files.

Drew: So it would be a sort of two step process, could use something like source bit, which we covered on a previous episode that does that sort of thing? Do I understand rightly that Gatsby has just this native ability to consume different sources in a way that other static site generators, just don’t?

Marcy: I think what makes Gatsby really strong in this area is its GraphQL data layer, and the plugin ecosystem. So, chances are someone has already written a plugin for whatever data source you’d be looking to build. And if not, there’s probably something close. But using GraphQL, is kind of the under workings of it. The layer that makes all of these integrations possible is using GraphQL.

Marcy: And so, there’s lots of possibilities for what you could pull in and we try to make it easy to write plugins too. So it’s been really neat learning about how to write a plugin, and the AST or Abstract Syntax Tree that it creates and kind of learning about how all that works has been really cool. But yeah, I’d say, there are a lot of things off the shelf that you could pick up without having to write it all yourself, which is pretty awesome.

Marcy: And it’s nice to have the flexibility to pull in markdown. Say your developers want to write their blog content markdown, but the marketing team is really not happy with that, you could combine content sources, and source them from multiple places. I’ve seen people sourcing things from other GitHub repos, and they use a get plugin to pull in markdown content that way. Lots of flexibility.

Drew: And I guess you’ve got the option then of writing your own plugins to pull from a custom data source. Say you’ve got some legacy system and you want to put a nice, shiny new website on the front of it. You could write a plugin that would get the data out in whatever format that is needed and translate it into something that gets bigger than work with?

Marcy: You could yes. And so, plugins enable that. And then there’s this abstraction on top of that, which we call Gatsby themes. And those are not only user interface code, but they could be GraphQL queries, configurations that set up a plugin, so it’s like a plugin with usage kind of bundled together. And you can distribute those themes on NPM.

Marcy: And then, their version and you can pull them in. And that whole API is really interesting too for teams who say you have multiple repos, and you want to pull data into those, it would be very repetitive to have the same queries in all of these repos in the same code. So, to dry things up a bit and not repeat yourself so much. You can use these abstractions called themes, to sort of distribute around that logic or code that would enable that source plugin. So, there’s these kind of layers of abstractions that you can build on top of it that we’ve heard that teams are really getting a lot out of right now.

Drew: So a theme in the Gatsby world isn’t a look and feel like it would be with CMS like WordPress.

Marcy: Yeah, I mean, it can but that’s not all that it is. So, naming things is very hard. But themes I’ve really enjoyed learning about just the flexibility and being able to, yes, you could include some user interface code. But there could be some query language code that goes in there as well. But the fact that it’s kind of bundled together, makes it easy to distribute. Yeah, it’s been a really neat abstraction that it’s been cool to see what people are building and what themes they’re shipping, and all that.

Drew: Yeah, I can imagine it would lead to some fairly innovative uses of Gatsby. Have you seen anything that’s been, in particular that caught your eye that customers are doing this particularly creative?

Marcy: Yeah. Well, in terms of themes, I mean, one of the first ones I read about there’s a case study on the Gatsby blog, I think from Apollo. And they wrote a documentation site using Gatsby themes and that used a get source plugin. And so, it really kind of decouples your sourcing, and your content, making it so that teams can pull in a theme to use across multiple repos.

Marcy: I’d say that’s the most interesting to me just because of what I can envision it enabling like, past teams I was on where we had to source content, we were just so like limited and where that code could live and how repeatable it could be. And so, seeing a solution now where teams are like, “Oh, this works great.” And that was even last summer, or like that was a case study a while ago.

Marcy: So since then, API’s have been improving, and there’s a whole team working on Gatsby themes. And I know they are rolling out some big improvements in the next few weeks. So, I don’t want to steal their thunder, but there’s some neat stuff coming with themes. They’ve been overhauling some of the blog themes like the core themes that we offer from Gatsby.

Marcy: I know they’re using it internally to build some of our own product announcement, or product improvements that will be announced here in the next couple of weeks. So, lots of cool stuff going on with Gatsby themes, and people selling their own themes and starters. I think that’s really interesting too.

Drew: There’s a bit of a marketplace springing up around Gatsby.

Marcy: There is, Yeah.

Drew: Is there any sort of online training and those sorts of things if somebody wants… If somebody decided that they were really going to get into Gatsby and they needed to learn it quick? Are there run places they can go with that sort of information is available?

Marcy: A ton of it? Yes. There’s definitely the Gatsby Doc’s site, which is’s. And we have tutorials, and I’ve been doing live streams almost every week for Gatsby stuff. There are a ton of educators who have Gatsby material on YouTube and various learning platforms. Egghead, I think some of my teammates from Gatsby have egghead videos as well.

Marcy: So, there is a ton of stuff out there. I would say check the dates on it if you find something. We’re always actively updating the Gatsby Doc’s, some of the older third party videos and things that may, check the dates on those because we can’t monitor every single learning resource for update. It’s hard to keep up with our own staff.

Marcy: Because there’s just so much with how many content sourcing options and use cases. It’s a very broad space. But there’s so much learning material out there, and a ton of ways to get started that you can sort of try and find things like depending on where you are on your learning spectrum. Are you at the beginning stages, are you coming from other technologies and you just need to learn about like what is this React thing.

Marcy: You can sort of pick and choose which materials will work for you based on where you’re at. I’ve been doing a course recently through live streams called Gatsby Web Creators, where we went all the way from beginner HTML, CSS and JavaScript through to creating our first Gatsby site. We just completed that on Friday. And so, it’s been really neat to go all the way back to the beginning.

Marcy: And because a lot of materials with Gatsby, it uses React. So, it’s a pretty big jump to get started with that. So, I really wanted to go back and take the steps to get all the way through to building things with React and Gatsby. So that was really neat. And I’m excited to continue on that route, so that there is more beginner material and more things to help people understand how to build a site with Gatsby because a lot of those skills are portable to other frameworks.

Drew: One of the big questions that is going to come up for anybody who’s thinking about building sort of client project sites using Gatsby, one of the big questions that’s going to come up is about managing content and putting stuff in front of a client. You mentioned already how Gatsby can connect to different content management systems. Is that the primary method that you would put in place to deal with that question? Or does Gatsby have anything in its ecosystem that would enable people to edit content in any way?

Marcy: Yeah, I would say having a CMS or something can make those team relationships work a lot better. I’ve been in those use cases where the dev teams like, “Just learn HTML.” And you see this glaze over from the client of like, “No, I can’t believe you just said that.” So having a system where people can do their best work in whatever ways suits them best, is super, super important.

Marcy: Like you just can’t handle marketer GitHub, and might work some of the time but not all the time. And so, having like a preview and build infrastructure makes that better, and that’s where the Gatsby cloud product space kind of enters into the fray. There are ways to do preview. Without the paid cloud side and Gatsby cloud does have a free tier for personal projects, so it’s not all paid.

Marcy: But we have this, like the open source and the product ecosystem kind of come together so that Gatsby can as a founding organization, make enough money to keep the open source framework, keep that healthy, and keep our community rolling along with that. So, that’s kind of where this open source commercial side comes together, and really enabling some of these workflows that teams need.

Marcy: Some things like getting fast previews, getting builds out the door fast and deployed. And so, there are solutions on the Gatsby cloud side specifically, and then wherever there is an open source way to make Gatsby work like with a preview server or something, we try to document that and make sure our community knows what’s what and how to serve those team needs.

Marcy: Yeah, I would say like, you need some way to preview your CMS changes because it’s like that instant gratification. You don’t want to be waiting an hour for a build to see some content.

Drew: So that’s interesting. The Gatsby cloud service gives you that ability to use a headless CMS service, where you’re just working with the content, but you’ve got no visualization of what it would look like in your site enables you to get a preview of how that would work. Is that right?

Marcy: It is, yeah. And so, it’s part of the trade off of decoupling, your headless CMS, which may have had, like WordPress, you could just look up the front end, but we’re giving it a new front end, and potentially pulling in other sources and other things that WordPress doesn’t know about. And so, decoupling it in that way makes sense. But you still, as a team member, you have to be able to do your work in the speed that you’re rapidly used to.

Marcy: And so, that is where Gatsby preview, Gatsby builds come in to give that front end back to teams so they can collaborate, they can make decisions, get something shipped. So that has sprung up in the last year, getting more features and improvements in all the time and that we’ve heard from some teams that are really starting to see speed increases.

Marcy: And as we figure out like, “Okay, if this build is going slow, why is that?” It’s usually because the site is really, really big. So we’ve been focused a lot on improvements for large sites, and really improving those team, collaborative workflows. It’s a big focus of the team right now.

Drew: So Gatsby cloud is, I guess at its heart is a hosting service. Is it a CDN for deploying your Gatsby sites with a load of Gatsby specific functionality and features around it?

Marcy: I would call it more of a continuous delivery product because it’s not an actual CDN. It integrates with CDNs like Fastly, Netlify. There’s a lot of different providers that you can hook up and some of them for free. You can do a lot for free, which is pretty awesome. I just did it the other day in our last Gatsby web creators session, we use Gatsby cloud and Netlify to build our site.

Marcy: And it enables you to make Gatsby sites faster specifically, because it does have those improvements. It only has to build one type of site. So, there’re some improvements that Gatsby cloud can make, that no other platform can make because they are trying to like support all of these different types of websites and they do them all very well.

Marcy: But for Gatsby, if that’s all you’re building, and there’s quite a few agencies, who are all in on Gatsby, and they want to make it as fast as they can. So, that’s where Gatsby cloud can make some performance improvements specifically for Gatsby, because it doesn’t have to worry about any other platforms.

Drew: So, Gatsby cloud would do your build, and it would then just deploy it to something like Netlify or presumably a whole range of different places.

Marcy: Yep. Yep, it will. And so, it’s the piece of Netlify that it would be using then as it’s uploading these built packages. Built files. It’s not using their builds, so the builds are happening on Gatsby clouds infrastructure, and that’s where some a lot of speed increases can happen. And then there’s still that upload step to get it out to a CDN, whichever one you’ve chosen.

Marcy: But yeah, it seems like teams are really loving this ability to see. I mean, it’s functionality that you would have missed. And so, that’s a necessary thing to add back in, is to be able to do these collaborative previews and get sign offs and all of that.

Drew: So, Gatsby cloud is provided as a service from Gatsby the company, and there’s Gatsby the open source project as well. Is this a similar sort of relationship to like WordPress and automatic have, where you’ve got a commercial entity developing an open source product?

Marcy: I would say so yeah, like Drupal. There’s precedent in tech to have these founding organizations where it’s kind of a virtuous cycle. And we’re working on publishing some governance documentation right now to make sure that, that’s super clear to our community, how we make decisions. But the entire goal is to keep Gatsby sustainable, so that it can continue to be an open source project that people can use it with ever even getting into Gatsby cloud.

Marcy: You could use other solutions with it if you want. And so, we need like enough business to sustain, like the people working on it. And so, I’m kind of in between, like I float in between the open source and commercial side and trying to make sure that we’re prioritizing things. I mean, as you could imagine, we’re juggling a lot of things with how broad the spaces like, we all have our niche use cases that we like, feel really strongly about, we need to do for our jobs.

Marcy: That adds up to be a lot of niche use cases. So, we try to juggle and prioritize and really listen to our community about what hurts right now, what’s painful, what’s going well. And so, that’s been an interesting journey to get for me personally to get back into devREL and really be listening to the community about, how can we make us be even better?

Drew: And is there a big community around Gatsby lots and lots of people using it?

Marcy: There are a lot of people using it, a lot of contributors. So for a lot of folks, it might be their first time contributing to open source like coming over to our docks and joining us for Hacktoberfest and things like that. And so, it has been really neat to see what a big community Gatsby does have, especially with things like accessibility and trying to make sure that frameworks do all they can out of the box for free.

Marcy: And so, there’s this, I don’t know, subset or intersection of accessibility and Gatsby and that’s my happy place. But the broader community, a lot of people learn React or learn web development through Gatsby. And so, that’s really neat to see a progression through our community, and hopefully we get people to come contribute, even if it’s an issue or something of like, “Hey, this link was broken or this part of the docks was confusing to me or it’s outdated.”

Marcy: Like even just telling a framework or a project that you use, that something could be better is a great way to contribute, because you can help us gain insight into the things that could use improvement. So that’s a great way to contribute.

Drew: You mentioned accessibility and of course, people will know you as being an accessibility expert. And they might be surprised to see you working with sort of fully featured front end framework like React, thinking that perhaps the two don’t really go together. Is that always the case at JavaScript heavy front ends are worth less accessible?

Marcy: Well, I wish it weren’t the case. But I think the data has shown that a lot of websites that do use front end frameworks are less accessible than those that don’t. A project that comes to mind is the Web a Million. And actually, I have a blog post, I’m refreshing the Gatsby site to see if my blog post has launched yet. But webbing through the web a million this project, they used their automated wave tool to crawl the top 1 million home pages and evaluate them for some accessibility violations.

Marcy: And it was really depressing results. Like they’ve run it twice now I think, and I think it got worse. So, it’s not great, but I don’t think you can really point to any one framework because there’s plenty of sites that don’t use frameworks that have lots of accessibility problems. So, it’s kind of a broader industry issue, a really society.

Marcy: And so, for me working on a full featured web framework, I saw as an opportunity to try and get more accessibility awareness in the mainstream. And so, that was an intentional move on my part to go and try to make an impact on a lot of sites like working on one site is cool. You can solve some really interesting problems. For me, I wanted to advocate accessibility much more broadly and try to make frameworks the best they can be from the inside.

Marcy: So even if something is rough right now, trying to play that long game of like, “Okay, what web standards things can we talk about? What framework improvements can we make so that if this is kind of rough, like not just give up on it.” So, even if I know it’s… I don’t know, JavaScript is some folks enemy I feel like I like it. You need some JavaScript to make accessible user interfaces, you just do.

Marcy: So, I am trying to like straddle those viewpoints and do the right thing while listening to my activist colleagues and friends kind of out there like pushing us forward as an industry. And then on the inside, I can be the messenger and the person that could try and reconcile some of those huge trade offs and ethical questions about What are we building?

Marcy: So, it’s challenging, but I really like it, because I have an impact to make on the web. And so, web framework. Lots of people are building Gatsby sites. So, seems like a good place to try and make an impact.

Drew: You mentioned briefly that Gatsby uses React at the moment. Is there a possible future where Gatsby might work with other frameworks, might receive a view version of Gatsby?

Marcy: I would love that. I’ve certainly talked about it. There is a pre React plug in, as I mentioned earlier. So you can swap that out. I think a big part of what we are talking about is sustainability of projects, trying to make the right call, these aren’t easy choices to make. It’s not just like rip it out and start over. There’s a lot of concerns that go along with that. It goes deep.

Marcy: So, it’s something we’re actively talking about. And I don’t really have anything specific to share right now. But we do have some internal meetings coming up soon to talk about that sort of thing. So, it’s being discussed, and I would love to have a view flavor, that’d be amazing. But as you can imagine there’s some interesting challenges that come along with that, and we want to make sure it’s the right move so that we’re not like, I don’t know, going down a path and having it not work for whatever reason, then we’re maintaining two frameworks, like how do we make that actually realistic in terms of what we can maintain and make succeed for an open source community?

Drew: So I’ve been learning all about Gatsby. What have you been learning about lately Marcy?

Marcy: Well, I wish it was better but work life balance. I’ve been learning about, for me, unfortunately, I’m in like a burnout cycle. And so, I feel like I’m continually learning the lesson of how to be productive, especially this year in 2020. There’s just like one thing after another. So, trying to get really clear focus on where I want to go in my career, what makes me happy?

Marcy: How can I sustain, and we’re talking about sustainability. Like how can I sustain my own life after a career of really pushing hard on accessibility in particular like, “Okay, how can I kind of take a little step back and make sure that what I am putting out there, what I am doing is meaningful, worth the energy.” See, a lot of my lessons have been kind of that intersection of work and life and trying to make the most of the time that’s been… I don’t know about you, but it’s been pretty stressful for a lot of people including me.

Drew: It’s been very, very stressful. We are at very difficult times, isn’t it?

Marcy: Yeah, yeah. I mean, we have so much to be thankful for in this industry, having opportunities and skills that you can apply. Seeing a lot of layoffs in our industry, really trying to make decisions that reflect where we’re at and not just going through the motions. So that was a big motivator for Gatsby web creators was, “Wow, there’s a lot of school age kids not in school this year, it would be really cool to see an outcome of turning some kids’ eyes onto web development.”

Marcy: Like when I was in seventh grade, and someone came to a class of mine to talk about photojournalism. I was like, “I want to be a photojournalist.” So that actually did work. I got some feedback from someone that said, “My seventh grader’s learning from you, and now they’re really excited about code.” So, that was a really good thing to spend some energy on, in a time where like, that wasn’t something I would have necessarily thought of before being in these circumstances in 2020.

Marcy: So, really trying to be like nimble and make choices that kind of reflect where I want to go and what’s happening.

Drew: If you the listener would like to hear more from Marcy, you can find her on Twitter where she’s @marcysutton and find all her latest goings on, on her personal website, And of course you can find out how to get started with Gatsby from Thanks for joining us today Marcy, do you have any parting words?

Marcy: Make the most of it wherever that might be.

Smashing Editorial (il)

13 Free Themes for Publishing on Ghost

Ghost is an open-source publishing platform. Started as a Kickstarter campaign by a former developer with WordPress, Ghost offers simple content management and built-in features for search engine optimization and email newsletters.

Ghost can turn a subscriber list into a member site, run subscription payments with Stripe, and integrate with hundreds of other tools. Ghost is free for self-hosting and also offers hosted premium plans.

Here is a list of free templates to publish content on Ghost. There are minimalist themes with text-driven styles, lively designs with multiple posts and images, and essential publishing tools.




Massively is an article-centered design with a large background image and scroll effects powered by Scrollex.




London is a minimalist design, built for clean text and image-centric layouts. London uses the Ghost Handlebars Theme API to provide many customization options and dynamic styles.




Ghostium is a content-based design inspired by the style and interface of Medium.




Saga is designed to look good with media, such as images or embedded videos. Saga uses a Pinterest-styled layout to feature image-driven posts. The main page features images from your latest post.




Ghostwriter uses a minimal style focused on typography, with AJAX loading for fast, smooth transitions between posts and pages. Ghostwriter features a home page post and then directs users to additional content.




Mapache comes with a variety of home page layouts and post formats, utilizing sidebars, headers, images, video, and more. Mapache supports six languages, light and dark mode, Instagram feed, 404 error page, members and subscriptions, and more.




Fizzy is a lively image-driven theme with a carousel slider to highlight tagged posts, as well as two more featured post images in the showcase section (above the main content posts).




Biron is a clean, responsive theme — ideal for a blog or a magazine site. Built with a Bulma CSS framework, Biron features custom logo support, tagging for related posts, and Disqus comments.




Caffeine is a Material-Design-inspired theme that began as a fork of Uno Zen. Caffeine uses the Masonry.js library for an attractive grid layout, ScrollReveal for sleek animations, and Disqus comments.




Attila is a minimal, responsive Ghost theme with a similar style to the Medium platform. Features parallax scrolling, content images for each post, author info, social media buttons, Disqus comments, and more.




Editorial is a news-oriented layout with a locking sidebar. Designed initially for HTML5 UP, Editorial was later ported to Ghost.

Open Writer

Open Writer

Open Writer

Open Writer is a clean theme with a large cover image. It features responsive design, parallax scrolling, pre-installed contact form, support for private blogs, and more.




Casper is the default theme for Ghost. It offers a balance of text and images for a modern magazine-style design.

Crowdfunding Web Platform Features With Open Prioritization

Crowdfunding Web Platform Features With Open Prioritization

Crowdfunding Web Platform Features With Open Prioritization

Rachel Andrew

2020-07-13T13:00:00+00:00 2020-07-13T23:34:39+00:00

In my last post, I described some interesting CSS features — some of which are only available in one browser. Most web developers have some feature they wish was more widely available, or that was available at all. I encourage developers to use, talk about, and raise implementation bugs with browsers to try to get features implemented, however, what if there was a more direct way to do so? What if web developers could get together and fund the development of these features?

This is the model that open-source consultancy Igalia is launching with their Open Prioritization experiment. The basic idea is a crowdfunding model for web platform features. If we want a feature implemented, we can put in a small amount of money to help fund that work. If the goal is reached, the feature can be implemented. This article is based on an interview with Brian Kardell, Developer Advocate at Igalia.

What Is Open Prioritization?

The idea of open prioritization is that the community gets to choose and help fund feature development. Igalia have selected a list of target features, all of which are implemented or currently being implemented in at least one engine. Therefore, funding a feature will help it become available cross-browser, and more usable for us as developers. The initial list is:

  • CSS lab( ) colors in Firefox
  • :focus-visible in WebKit/Safari
  • HTML inert in WebKit/Safari
  • Selector list arguments for :not( ) in Chrome
  • CSS Containment support in WebKit/Safari
  • CSS d (SVG path) support in Firefox

The website gives more explanation of each feature and all of the details of how the funding will work. Igalia are working with Open Collective to manage the pledges.

Who Are Igalia?

You may never have heard of Igalia, but you will have benefited from their work. Igalia works on browser engines, and have specialist knowledge of all of the engines. They had the second-highest number of commits to the Chrome and WebKit source in 2019. If you love CSS Grid Layout, then you have Igalia to thank for the implementation in Chrome and WebKit. The work to add the feature to those browsers was done by a team at Igalia, rather than engineers working internally at the browser company.

This is what makes this idea so compelling. It isn’t a case of raising some money and then trying to persuade someone to do the work. Igalia have a track record of doing the work. Developers need to be paid, so by crowdsourcing the money we are able to choose what is worked on next. Igalia also already have the relationships with the engines to make any suggested feature likely to be a success.

Will Browsers Accept These Features If We Fund Them?

The fact that Igalia already have relationships within browser engine teams, and have already discussed the selected features with them means that if funded, we should see the features in browsers. And, there are already precedents for major features being funded by third parties and developed by Igalia. The Grid Layout implementation in Chrome and WebKit was funded by Bloomberg Tech. They were frustrated by the lack of Grid Layout implementation, and it was Bloomberg Tech who provided the money to develop that feature over several years.

Chrome and WebKit were happy to accept the implementation; there was no controversy over adding the feature. Rather, it was a matter of prioritization. The browsers had other work that was deemed a higher priority, and financial commitment and developer time was therefore directed elsewhere. The features that have been selected for this initial crowdfunding attempt are also non -controversial in terms of their implementation. If the work can be done then the engines are likely to accept it. Interoperability — things working in the same way across browsers — is something all browser vendors care about. There is no benefit to an engine to lag behind. We essentially just get to bypass the internal prioritization process for the feature.

Why Don’t Browsers Just Do This Stuff?

I asked Brian why the browser companies don’t fund these things themselves. He explained,

“People might think, for example, ‘Apple has all of the money in the world’ but this ignores complex realities. Apple’s business is not their Web browser. In fact, the web browser itself isn’t a money-making endeavor for anyone. Browsers and standards are voluntary, they are a commons. Cost-wise, however, browsers are considerable. They are massively more complex than most of us realize. Only 3 organizations today have invested the many years and millions of dollars annually that it takes to evolve and maintain a rendering engine project. Any one of them is already making a massive and unparalleled investment in the commons.”

Brian went on to point out the considerable investment of Firefox into Servo, and Google into LayoutNG, projects which will improve the browser experience and also make it possible to implement new features of the platform. There is a lot that any browser could be implementing in their engine, but the way those features are internally prioritized may not always map to our needs as developers.

It occurred to me that by funding browser implementation, we are doing the same thing that we do for other products that we use. Many of us will have developed a plugin for a needed feature in a CMS or paid a third party to provide it. The CMS developers spend their time working on the core product, ensuring that it is robust, secure, and up to date. Without the core product, adding plugins would be impossible. Third parties however can contribute parts to that platform, and in a sense that is what we can do via open prioritization. Show that a feature is worthwhile enough for us to pledge some cash to get it over the line.

How Does This Fit With Projects Such As Web We Want?

SmashingConf has supported the Web We Want project, where developers pitched web platform ideas to be discussed and voted for onstage at conferences. I was involved in several of these events as a host and on the panel. I wondered how open prioritization fits with these existing efforts. Brian explained that these are quite different things saying,

“… if you asked me what could make my house better I could name a million things. Some of those aren’t even remotely practical, they would just be really neat. But if you said make a list of things you could do with a budget for what each one costs — my list will be considerably more practical and bound by realities I know exist.

At the end of the month if you say “there is your list, and here is $100, what will you do with it?” that’s a very direct question that helps me accomplish something practical. Maybe I will paint. Maybe I will buy some new lighting. Or, maybe I will save it for some months toward something more costly.”

The Web We Want project asks an open question, it asks what we want of the platform. Many of the wants aren’t things that already exist as a specification. To actually start to implement any of these things would mean starting right at the beginning, with an idea that needs taking right from the specification stage. There are few certainties, and they would be very hard to put a price on.

The features selected for this first open prioritization experiment are deliberately limited in scope. They already have some implementation; they have a specification, and Igalia have already spoken to browser maintainers to check that the features are ready to work on but don’t feature in immediate priorities.

Supporting this project means supporting a concrete chunk of development, that can happen within a reasonably short timeframe. Posting an idea to Web We Want, writing up an idea on your blog, or adding an issue describing a totally new feature on the CSSWG GitHub repo potentially gets a new idea out into the discussion. However, those ideas may have a long slow path to becoming reality. And, given the nature of standards discussions, probably won’t happen in exactly the way that you imagined. It is valuable to propose these things, but very hard to estimate time and costs to a final implementation.

The same problem is true for the much-wanted feature of container queries, Igalia have gone so far as to mention container queries in their FAQ. Container queries are something that many people involved in the standards process and at browser vendors are looking into, however, those discussions are at an early stage. It isn’t something it would be possible to put a monetary value on at this point.

Get Involved!

There is more information at the Open Prioritization site, along with a detailed FAQ answering other questions that you might have. I’m excited about this because I’m always keen to help find ways for designers and developers to get involved in the web platform. It is our platform. We can wait for things to be granted to use by browser vendors, or we can actively contribute via ideas, bug reports, and with Open Prioritization a bit of cash, to help to make it better.

Smashing Editorial (il)

USPS Woes Could Impact Ecommerce SMBs

The United States Postal Service reported a $4.5 billion loss in the fiscal 2020 second quarter, which ended on March 31. Democratic members of Congress have proposed investing $25 billion to help the USPS. Whatever happens to the agency will likely impact small and mid-sized ecommerce companies.

The USPS has generated losses for years.

While some might argue that a governmental agency empowered by the U.S. Constitution and created by Congress to carry the mail to every address in the country doesn’t have to be profitable, other political and business leaders, including Gary MacDougal, who is also a director for UPS, have called for changes to or the elimination of the USPS.

“The responsible course is to set the Postal Service on a careful path to liquidation. This can be done in a way that wisely uses USPS assets, such as the 31,000 post offices, most of which are on valuable property in commercial areas, to wind the business down,” MacDougal wrote in a The Wall Street Journal editorial published on May 5, 2020.

The USPS has produced billions in losses, but it is critical to ecommerce SMBs. Photo: Pope Moysuh.

The USPS has produced billions in losses, but it is critical to ecommerce SMBs. Photo: Pope Moysuh.

How the USPS moves forward is critical for ecommerce SMBs.

“Without the services of the USPS or with a significantly altered version of the USPS than we know today, we would see significant impacts on the ecommerce landscape,” said Mario Paganini, the head of marketing at Shippo, which makes multi-carrier shipping software.

“For context,” Paganini continued, “the USPS delivers almost half of the world’s mail, exponentially more than any individual private carrier and even all of the major private carriers combined. …Without the USPS, it won’t be Amazon or other major corporations that suffer —at least not significantly. It will be small businesses and consumers that suffer the most.”

4 Keys for Ecommerce

As the debate regarding the USPS continues, small and mid-sized merchants should watch for four things:

  • What sorts of packages and envelopes the USPS delivers,
  • What rates the USPS charges,
  • Which addresses the USPS serves, and
  • If the USPS is shuttered.

Package and envelope type. First Class Mail applies to cards, envelopes, and packages that weigh less than 16 ounces. It’s the most popular and affordable method for customers and the least profitable for the USPS. But if the agency is asked to limit its services to cut losses, ecommerce merchants will want to pay close attention to which services end up on the chopping block.

For example, in his editorial, MacDougal noted that the USPS “cooperates with [FedEx and UPS] by assuming some ‘last mile’ deliveries in unprofitable remote areas it is required by law to serve.”

Essentially, last-mile services such as FedEx’s SmartPost and UPS’s SurePost use their own networks to bring packages close to recipients, where the USPS takes over and delivers to those recipients’ doorsteps. The last mile portion of this delivery can be a significant money loser for the USPS.

But the USPS may not retain all last-mile deliveries, anyway. FedEx, for example, announced last year that by the end of 2020 all of its SmartPost packages would be delivered via the company’s own ground services.

Finally, Priority Mail — First Class Mail packages that weigh 16 ounces or more — is the most important to many ecommerce SMBs. If the USPS dropped this service, some merchants would need to alter fulfillment tactics.

USPS rates. “The USPS, for the majority of domestic deliveries — but often also international — is the most cost-effective option for small businesses. Its flagship service, Priority Mail, starts around $7 per shipment and gets most items anywhere in the U.S. in two to three days — even during the pandemic. We see roughly a 2.5-day average delivery time across the Shippo network,” said Paganini.

USPS package rates could rise. President Trump recently suggested that if the USPS is going to get additional funding from taxpayers, it will need to raise rates.

“The Postal Service is a joke,” the President said in April 2020, according to The Wall Street Journal. “They’re handing out packages for Amazon and other internet companies. And every time they bring a package, they lose money on it…If they don’t raise the price, I’m not signing anything.”

The President suggested that rates should be quadrupled.

Paganini disagrees.

“I’ve heard speculation about how large corporations, mainly Amazon, are to blame for the current struggles of the USPS. Specifically, that they are underpaying the USPS and that these economics are a primary driver of the USPS recent struggles. However, Amazon is not the driver of the USPS’s challenges. In fact, Amazon is a major contributor to the continued growth of the USPS’s most profitable revenue stream: package delivery.”

Regardless, ecommerce SMBs should pay attention to USPS as this political discussion continues.

Delivery addresses. A third and unlikely change may impact which addresses the USPS delivers to and how often.

It seems unlikely that the USPS could stop delivering to some rural addresses. But doing so would significantly reduce costs. Similarly, the agency could save money delivering to rural routes less often, perhaps, three days per week instead of six.

This change could impact ecommerce SMBs that sell heavily into rural areas.

USPS is closed. Online sellers who depend on the USPS’s relatively low-cost shipping should also monitor the discussions of closing the USPS altogether.

“Overall, I think that in the absence of the USPS, we’d see a drop in the rate of digital entrepreneurship,” said Paganini.

“I’ve always seen selling online as somewhat of an equalizer. You don’t need to buy the most expensive real estate in your city or have the biggest spot in the mall to reach customers. Now, in the face of Covid-19, even more businesses are turning online to keep up. Without the USPS, the barriers to entry would be higher. I don’t think as many entrepreneurs and historically offline businesses would be able to transition online as easily — many might not be able to do so at all.”

“It’s worth noting that the major private carriers are making moves to better support small businesses,” Paganini added.

“I don’t think it is accurate to say that UPS and FedEx are not helping small businesses. They are expanding their ground fleets, working to make their services more accessible to SMBs, and investing in technology and partnerships to reach more SMBs. I applaud their efforts and think that they are making the right investments. However, right now, and for the foreseeable future, no one is equipped to fill the gap that would be left if the USPS were to cease operations. Private carriers simply wouldn’t be able to keep up with the volume, nor would they be able to profitably service as wide of a net of businesses and consumers as the USPS.”

Entrepreneur Sells the Most Competitive Product on Amazon, and Thrives

What’s the most competitive product on Amazon? Smartphone cases. What does Matt Altschul’s company, Smartish, sell? Smartphone cases. And it thrives.

“To even think about competing in a space like phone cases,” he told me, “you have to use every one of Amazon’s marketing tools simultaneously — advertising, coupons, deals of the day, lightning deals, bigger campaigns, running ads from outside into Amazon.”

I spoke with Altschul recently about Amazon, phone cases, and custom manufacturing, among other topics. What follows is the entire audio version of our conversation and a transcript, edited for length and clarity.

Eric Bandholz: Tell us about Smartish and yourself.

Matt Altschul: I started Smartish in 2009. I still love it. We’re based here in Austin, Texas. We sell a lot of products on Amazon and some direct to consumer. It’s all online. We try to keep our business simplified for sanity. We don’t have the exposure of brick and mortar retail. My life is happy and good.

Bandholz: Do you have any business partners or investors?

Altschul: I maintain 100-percent control in the company. We have 14 people — a good team. A couple of them run the operational side and the sales and marketing side, respectively. But I oversee the ship.

We originally had co-founders that eventually either died, or I bought out.

Bandholz: Literally passed away?

Altschul: Yes. It was stressful. But through all of it, I’ve been in charge of everything. It’s been lonely sometimes. Who do you lean to? Who do you look to for advice? To a fault, I worked on my own for a long time. So, whoever is listening to this is already doing better than I did. You’re looking to connect with people in the community and understand more about entrepreneurship. I didn’t do that as much from the beginning.

About five years ago, I was involved in an accelerator called SKU, a consumer-product accelerator here in Austin. Now they’re starting to open some branches around the U.S. But I joined to get involved with more like-minded people in our community. And it helped a lot. It helped me open my eyes to some mistakes I was making.

It’s an excellent accelerator to join for any consumer packaged goods company, specifically in Austin, that already has a market-validated product. You give them a particular amount of equity for an accelerator program; they provide you with access to mentors and capital or at least introductions to potential investors.

Bandholz: You have to give up equity for that?

Altschul: Some equity, yes. It’s a small stake in the business that in the grand scheme of things is worth it.

Bandholz: Employees are never going to understand the pressure of growing a business. As an entrepreneur or business owner, it’s 24/7. We don’t turn it off. Have you mellowed over the years in that respect?

Altschul: I think we as entrepreneurs come to terms with a lot of things. Things that created stress in the first five, six years, over time do not. It’s a feeling of no matter how bad it looks, we’ll get through this.

Collecting state sales tax was one of those things that happened to me a couple of years ago. I was thinking, “I’ll figure out this state sales tax thing down the road.” I didn’t realize I was incurring liability for that tax I was supposed to be collecting.

I eventually came to grips with how much money I owe these states. If I encountered that in my first five years, I would’ve been stressed. But being eight years into it, I realized we’ve gotten through similar problems before, and we’ll get through this.

Bandholz: Let’s talk about your distribution strategy. You’re primarily on Amazon.

Altschul: I was selling on Amazon before I started Smartish. My previous company sold high-end headphones. I helped a friend launch that business. All told, I’ve been selling Amazon for about 14 years. I’ve seen many iterations of how Amazon works. Because of that experience, I’m able to maneuver and to navigate the marketplace pretty well. But there’s a new challenge every day. Some things I can anticipate and others completely blindside me.

Bandholz: My company, Beardbrand, doesn’t sell anything on Amazon. I was afraid of the fact that they could snap their fingers and our sales would be gone.

Altschul: Yes, that could happen. We had perhaps the biggest scare ever on Amazon a couple of months ago. Our products were deprioritized from fulfillment centers and got pushed out to a one month delivery on both the vendor and the seller side — 1P and 3P.

It’s certainly a risk that I’m trying to dilute by growing our direct-to-consumer market, which we’re doing a pretty good job at. But certainly a large percentage of our sales is still on Amazon.

Bandholz: You seem to have created a brand on Amazon, which is different than most Amazon sellers. Talk about that strategy.

Altschul: My idea has always been to have a brand that people like, engage, and buy products from. The flip side of an Amazon business is finding an opportunity in a product and just cranking it out for a dollar cheaper. That’s not as fun to me. I enjoy product innovation. And we try to stay in our lane. Smartish sells phone cases and related stuff. We don’t make desk mats or pens or CBD oil.

Bandholz: From an outsider’s perspective, phone cases seem highly commoditized. How do you compete?

Altschul: Phone cases are probably the second most commoditized market on Amazon (behind supplements) and the most competitive. There’s no barrier to entry for a Chinese factory to create an injection mold of an iPhone case and sell it directly on Amazon.

Most of the top 100 sellers are from China. Their products are a lot cheaper than mine. I have to have a genuinely good product — the more innovative, the better. I need to seriously consider the functionality, the style, the colors, every facet of it. Otherwise, I get bad reviews, which can sink a company. There’s no way you can live on Amazon without a really, really good product.

To even think about competing in a space like phone cases, you have to use every one of Amazon’s marketing tools simultaneously — advertising, coupons, deals of the day, lightning deals, bigger campaigns, running ads from outside into Amazon, having a PR team getting write-ups and having those write-ups pushed to your site, using Vine, using Early Review. All those things have to be running simultaneously and well.

But even that’s not going to get you in the top 100 in cases because it’s just so competitive. But fortunately so many people buy phone cases that you can live outside of that ranking and still have a pretty profitable business.

Bandholz: You’re manufacturing in China. That’s got to be challenging to manage the relationship with the factory.

Altschul: Yes. They can get lazy, for sure — about as lazy as you let them. We have a full-time team in China. I have an ex-pat who runs product development there. His team is on our payroll full time. They are in the factory almost every day working in quality control, shipping — making sure everything is under control.

Bandholz: It wouldn’t surprise me if there were Chinese factories that sell their customers’ designs.

Altschul: Out the back door. It happens. It comes down to what type of factory you’re dealing with. What’s tough is when you’re in the early stages of a business, you’re on the smaller end, and you have to deal with some smaller factories, which are sometimes less honest.

Bandholz: Are you able to get pre-production iPhones from Apple so your cases are available on launch day?

Altschul: It’s a good question. The answer is no.

How do we know how the specs or the details a new iPhone case? We have to start designing six months beforehand. We have to begin tooling four months before. Two to three months before, we have to go into production, and we’re cranking out tens of thousands of units two months before the phone’s even announced. It’s a big risk.

Almost every case manufacturer works off of leaked three-dimensional models. Whether Apple allows this to happen, they know they can’t control it. But nearly every case manufacturer has to work off rumored designs. We’re like, “Okay, I think this is correct.” Or, “This is probably 90 percent correct.” Or, “Maybe this is probably 97 percent correct.” And then one day we have to decide, “We’re going to lock-in. We hope that it’s right.”

Bandholz: I can’t imagine. I always assumed that Apple had these relationships with case makers and sent them prototypes.

Altschul: No, they don’t. Only the top two or so case manufacturers have official specs from Apple. But it can be a disadvantage as well because you’re in bed with Apple, and it’s controlling when you can produce your products. They say, “You can’t even start your manufacturing until the day we tell you.” You can’t even speak the name of the new iPhone until after the announcement. In contrast, everyone else is already putting the listings up and producing inventory. So, there are pros and cons.

Bandholz: I’ve enjoyed our time. Where can people learn more about you and your products?

Altschul: They can find us at or Amazon.