Collective #583

Inspirational Website of the Week: Everything on basement is bold: from its striking typography to the brilliant effects and playful interactivity. Fantastic work. Get inspired This content is sponsored via Thought Leaders Clubhouse: Make 2020 your most productive year Clubhouse is a Read more

Collective #577

dreamt up by webguru in Uncategorized | Comments Off on Collective #577

Collective item image

Mix and Jam

André Cardoso started a gamedev journey and shares it by creating videos and making all of the code available.

Check it out

Collective item image


A free and open-source tool to easily transform any image or photo into a multi-colored SVG file. Created by Vincent Will with Next.js.

Check it out


Bot Land

Bot Land is an automated strategy game where you have to create bots, write scripts, and battle other players.

Check it out

Collective item image

From Our Blog

Case Study: Akaru 2019

In this creative breakdown you will learn how the signature WebGL oil effect of the new Akaru website was created.

Read it

Collective #577 was written by Pedro Botelho and published on Codrops.

Source: Codrops, Collective #577

How To Decide Which PWA Elements Should Stick

dreamt up by webguru in Uncategorized | Comments Off on How To Decide Which PWA Elements Should Stick

How To Decide Which PWA Elements Should Stick

How To Decide Which PWA Elements Should Stick

Suzanne Scacca

As the number of website visitors and shoppers grows on mobile, it’s important to consider how small additions to your design will encourage them to do more than just research and browse. One of the elements I think mobile designers — for PWAs and mobile websites — need to do more with is the sticky bar.

What exactly do I mean by “more”? Well, I mean using the fixed navigation bar at the top or bottom of a mobile site for more than just navigation or branding.

Today, I’m going to show you some creative uses for sticky elements in mobile design, so you can help more of your visitors to take action.

Sticky Element Inspiration For Mobile Design

Think about the main challenge we face when it comes to mobile. While users are more than willing to take their first steps on a website or PWA from their mobile devices, conversion often happens on desktop (if they remember to do it at all).

When used properly, fixed elements can encourage more mobile visitors to take action right where they are. And this works for all kinds of websites.

1. Make the Top Sticky Bar Useful

The sticky bar at the top of your mobile site shouldn’t just be there for branding.

That said, I get that it can be tricky using that space when the logo may end up comprising a good chunk of that space. But if you design it thin enough, you can stack another banner beside it. Just make sure it’s useful.

The Lancome PWA is an interesting example because it simultaneously does this well and poorly:

Lancome sticky bars

Lancome has three sticky bars at the top of its PWA. (Source: Lancome) (Large preview)

There are three sticky bars at the top of the PWA:

  • A banner promoting a special offer,
  • A standard navigation bar,
  • A secondary navigation bar with shop categories.

The two navigation bars are great. Together, they don’t take up too much space and they make it much easier for users to find what they’re looking for and to complete their purchases. However, that promotional banner is not very well executed.

For starters, it’s too big and demands too much attention. Secondly, there’s no way to dismiss the message. It just stays there, stuck to the top of the PWA, no matter where the visitor goes.

If you’re going to use a sticky bar to promote an offer — no matter its size — give your users the option to move it out of the way if it’s irrelevant or if they’ve already collected the pertinent details from it. is another e-commerce web app that takes advantage of the top sticky bar. This one, however, doesn’t waste the space with distracting elements. sticky navigation and search uses a standard navigation bar and sticky search bar on its PWA. (Source: (Large preview)

On the home page, attaches a sticky and voice-enabled search bar to the top of the page. This is great as it caters to a number of visitor types:

  • Visitors that prefer to use the standard navigation from the menu.
  • Visitors that prefer to type a quick search to the exact item they need.
  • Visitors that want to use their voice to search for something.

It checks off all the boxes.

In addition to providing a great search experience for its store, also customizes this sticky element as visitors go deeper into the site: sticky Sort and Filter provides shoppers with a sticky Sort and Filter bar. (Source: (Large preview)

As shoppers peruse product pages, the sticky search bar becomes a Sort and Filter bar that follows them down the page. For big online stores, this is a useful tool so mobile users don’t have to scroll all the way to the top to adjust their search results.

The top sticky bar isn’t just useful for e-commerce stores as you’ll see in the rest of the examples in this article. However, when it comes to mobile, there’s a greater opportunity for e-commerce sites to pack extra value into this space, so take advantage of it.

2. Add a Bottom Navigation Bar with Quick-Tap Actions

Okay, so we’ve established what makes for a good sticky top bar. But what about a bottom bar? Is it even necessary?

One of the benefits of designing a PWA instead of a mobile site is that we can give it the top and bottom wrapper. But it’s not always needed. I’d say as a general rule of thumb to include a bottom bar when there are commonly used actions you want users to have easy access to.

Let’s start with an example that’s a mix of the good and the eh: Twitter.

Twitter sticky bottom navigation bar

Twitter places its sticky navigation bar on the bottom of the PWA. (Source: Twitter) (Large preview)

Twitter has chosen a different placement for its navigation bar. While the sticky bar at the top provides a place to access user settings, the bottom is for:

  • Visiting one’s news feed;
  • Searching for posts, people, hashtags, etc.;
  • Checking on notifications and direct messages.

For a social media app, this design makes a lot of sense. It’s not as though users are going to spend much time updating their settings, so why not put it out of the thumb zone and keep the regularly used elements within reach?

The issue I take with Twitter’s sticky elements is the click-to-tweet button (the big blue button in the bottom-left). While it’s not high enough to cover content being read at the top of the page, it does cover part of it down below.

It’s awfully reminiscent of those floating social icons that used to cover content on mobile. You don’t really see that anymore and I think it was for that exact reason.

If you’re thinking about adding a free-standing sticky element of your own to your site, make sure it doesn’t cover any content. Twitter may be able to get away with it, but your brand might not.

As for other examples of bottom bars, let’s turn our attention to the Weather Channel PWA:

Weather Channel PWA sticky bars

The Weather Channel PWA uses both a sticky top and bottom bar. (Source: Weather Channel) (Large preview)

What’s nice about the top bar, in particular, is that it prioritizes the user experience instead of its own branding. Once a visitor enters their location, the rest of the site’s content is personalized, which is great.

As for the bottom navigation, Weather Channel has done a really nice job with this. Similar to how Twitter places commonly used buttons in its bottom bar, the same idea is present here. After all, it’s not as though Weather Channel visitors are coming to the site to read about Dover Federal Credit Union. They want to get precise predictions for upcoming weather.

Now, the two examples above show you how to use the bottom navigation bar as a permanent fixture on a mobile site. But you can also use it as a custom feature on your internal pages as job search site The Muse does:

The Muse bottom sticky bar

The Muse uses a sticky bar to shortcut various actions visitors might want to take. (Source: The Muse) (Large preview)

This bottom sticky bar appears only on job listings pages. Notice how it doesn’t just say “Apply”.

I’m willing to bet The Muse designer spent time studying its user journey and how frequently job seekers actually apply for a position the first time they see it. By including “Email Myself” and “Save” buttons in this action bar, it addresses the fact that job seekers might need time to mull the decision over or to prepare the application before filling it out.

So, while you can certainly use a sticky bottom bar as a type of secondary navigation for commonly-clicked pages, I’d also suggest looking at it the way The Muse has: by designing a sticky bar that’s tailor-made for your own user’s journey.

3. Simplify Order Customization with Sticky Elements

Remember the days when you’d have to call up your local restaurant to place an order for delivery or when, gulp, you had to actually visit a store to buy something? Online ordering is an amazing thing — but it could be even better if we set up our mobile sites and PWAs the right way for it.

Again, I want to start with an example that kinda gets it right.

This is the PWA for MINI USA:

MINI USA PWA car customization

Users customize their Mini Cooper on a page with an oversized sticky element. (Source: MINI USA) (Large preview)

This is what users go through when they want to customize their car before purchasing. Looking at it from this screenshot, it looks nice. You can see the car in its customized state along with the updated price.

However, that entire section — down to the “Review” and “Save” buttons — is fixed. That means that all customization takes place on about a third to a quarter of the screen down below. It’s not an easy customization experience, to say the least.

While the customization screen needs some work, it’s the final Review screen that is done nicely:

MINI USA sticky action bar

The MINI USA Review page adds a sticky action bar to the bottom. (Source: MINI USA) (Large preview)

Here the top bar has gone back to a normal size while a new action bar has been added to the bottom. This is similar to what The Muse does to streamline the next steps with job applicants. In this case, MINI gives potential customers the ability to choose one of a number of options, even if they don’t lead to an immediate sale.

There are other types of PWAs and mobile sites that can and should simplify the online ordering process. Like MINI, Uber Eats uses custom sticky elements to help users put together their orders.

Uber Eats sticky menu

Uber Eats includes a top menu navigation bar in its PWA. (Source: Uber Eats) (Large preview)

When a user has selected a restaurant to order from, a sticky menu bar appears at the top of the page. This is especially useful for lengthy menus as well as to help users quickly navigate to the kind of food they’re jonesing for.

Assuming the user has found an item they want, the next page removes the top sticky bar and adds an “Add to Order” button/bar instead.

Uber Eats “Add to Order” button

Uber Eats places an “Add to Order” button at the bottom of its web app. (Source: Uber Eats) (Large preview)

This way, the distraction of other menu categories is gone and now the user only has to focus on customizing the selected item before placing it in the cart.

Again, what this comes down to is being able to predict your users’ steps before they even get there. You can use either the top or bottom navigation to aid in this process, but it’s best to place initial steps in a sticky top bar and later steps at the bottom as they near conversion.

4. Display “Sidebar” Widgets On Digital Publications

Without a sidebar on mobile, you might try to tuck the widgets that would otherwise be there at the bottom of your content. But unless you know that your content is going to be read all the way through and that visitors will keep scrolling for more, there’s no guarantee they’ll see anything you put down there.

So, when it makes sense to do so, use sticky bars to add only the most essential sidebar-esque content.

Let’s take Inc., for example.

nc.’s sticky bars and elements

Inc.’s PWA comes with a sticky subscription bar, banner ad and secondary hamburger menu. (Source: Inc.) (Large preview)

There are three sticky elements that appear around Inc.’s articles:

  • A subscription form (which can be dismissed),
  • A banner ad (which cannot),
  • A floating hamburger menu.

The first two elements are fine since at least one of them is dismissible. However, the floating hamburger menu is problematic since it covers part of the content. Considering this is a content-centric site, it’s probably not a good idea to cover any part of the page.

The only way we might be able to excuse the placement of this fixed element is if it were to add extra value to the content. However, all it does is give readers more articles to read:

Inc. floating hamburger menu

Inc.’s floating hamburger menu contains more articles to read. (Source: Inc.) (Large preview)

The goal on any content website is to get visitors to actually read the content. But if you’re presenting them with other options straight away, you’re only giving them more content to get distracted by.

The concept of this floating menu is a good one, but the execution isn’t great. I’d recommend displaying it as visitors get at least 75% of the way down the page. That way, it only comes into view when they should be looking for related content to read.

As for publications that get the sticky elements right, look for ones that keep it simple.

The New Yorker, for instance, does a nice job of using the sticky navigation bar and a darker, less distracting bottom bar to promote its subscriptions:

The New Yorker sticky bars

The New Yorker uses sticky bars to promote its paid subscriptions. (Source: The New Yorker) (Large preview)

If it’s important to you to get subscribers for your publication — especially paid ones — this is a good way to make use of the fixed bars on mobile.

If, instead, you’re more focused on getting the word out about your content, then a sticky bar like the one The Billings Gazette uses would be better:

The Billings Gazette sticky social bar

The Billings Gazette prioritizes sharing over subscribing of its content. (Source: The Billings Gazette) (Large preview)

This is really well done. Social media sharing options are limited to the ones that make the most sense for mobile users. The same goes for the other share options here: WhatsApp, text, and email. When clicked, the corresponding app opens, so readers don’t have to use their browser sharing options or copy-and-paste the link.

In all honesty, I’m not sure it should be an either/or. I think you could use the top bar to promote your subscription so long as it’s easy to dismiss. Then, the bottom bar could be used for sharing links. Just make sure one of the bars moves out of the way so you can maximize the reading space.

Wrapping Up

Bottom line? It’s time to start using your sticky mobile elements for more than just storage of a logo, hamburger menu or search bar.

As we’ve seen here today, the key is to figure out what your users need most from you. Then, use your sticky elements to build a shortcut that makes a difference in their experience.

Smashing Editorial
(ra, yk, il)

Source: Smashing Magazine, How To Decide Which PWA Elements Should Stick

2019: A Smashing Year In Review

dreamt up by webguru in Uncategorized | Comments Off on 2019: A Smashing Year In Review

2019: A Smashing Year In Review

2019: A Smashing Year In Review

Rachel Andrew

2019 has been a productive — sometimes challenging — but ultimately very successful year for the Smashing Team. In this annual round-up, I’d like to share some of my thoughts and those of some of the Smashing team, as we look back on the past year as well as look ahead and forward to 2020.

Travel And Friendships

As always, my 2019 has involved a lot of travel. In addition to my conference speaking engagements and travel to W3C meetings, I attended all four of our Smashing conferences; I ran CSS Layout workshops in Toronto, New York and San Francisco. The conferences are a time when most of the team is together in person.

An illustration of Topple the Smashing Mascot cat networking while sitting in a comfortable couch with its laptop placed on its lap holding a cup of coffee or tea, who knowsThe home of Smashing is in Freiburg, Germany, and before SmashingConf Freiburg, we held a big team meeting, with almost everyone who is involved with Smashing able to take part. There have been many changes in the Smashing Team this year, and that meeting in Freiburg was a chance for us all to come together; I believe that it was one of the most valuable things we have done this year.

There are many challenges in doing all of the things we do as a small (mainly part-time and remote) team. However, if we keep talking and keep the Smashing community at the heart of everything we do, the past year demonstrates that we can achieve amazing things!

The Conferences

The SmashingConf team of Amanda Annandale, Charis Rooda and Mariona Jones are a force of nature. They seem to achieve the impossible and (as Charis told me) still have time to enjoy the surroundings of the places they visit.

The team in front of the Toronto sign

The SmashingConf team in Toronto

I’m always blown away when I walk into the venue and see what has been achieved — even before the event starts. Artwork created by the talented Ricardo Gimenes is everywhere — such as the movie posters from Toronto, and the artwork in the theater we use as a venue in New York.

Movie posters features Topple the Smashing cat

Our movie posters in Toronto (Photo credit Marc Thiele)

A large theatre sign featuring Topple the cat

The signage in the theater in New York (Photo credit Drew McLellan)

One of my favorite things to do at the conferences is to lead the Smashing Run, which we normally manage to do on both conference days. This is becoming quite a fixture, with several attendees and speakers running and chatting for half an hour before breakfast. I’m already looking forward to our inaugural run in Austin in 2020, though it may be a bit of a warm one!

I sometimes help the conference team out when words need writing or editing, and sometimes when the legality of balloons is called into question. As Amanda Annandale (Senior Event Manager) remembers:

“September marked my third year at Smashing, and while it provided a whole new set of challenges, it also provided a huge sense of accomplishments. The conference team sat down at the end of 2018 and was able to make some big plans for the future.

“It’s been amazing to see these plans (from organization to side-events to new locations), and our team, come together. But, new tasks can bring about some hilarious roadblocks. Smashing is on a long and necessary quest to reduce our carbon footprint. BUT, Vitaly is rather partial to balloons.

“For those who may not know (because Rachel Andrew and I were shocked to learn), foil balloons are heavily regulated in the state of California. This (we discovered while spending a disproportionate time researching eco-balloons over plastic balloons) is obviously bad for the environment. We’ve never been so happy to find a company making fully eco-friendly balloons, that are fully biodegradable in a very short amount of time! This experience definitely strengthened our resolve.

“We are now working with a company out of Austin to improve our printing processes to be more eco-friendly, and working with each of our caterers to reduce our waste. We still have a way to go, but we’re aiming for a Smashing impact in 2020!”

Conference attendees standing up throwing balloons

The (eco-friendly) balloons are deployed in San Francisco (Photo credit Marc Thiele)

Conferences are expensive to produce and we are fortunate to have some wonderful partners who help us to create these events. They are looked after by our partnerships manager Mariona Jones, who has been joined this year by Esther Fernández. Between them, they are working to bring together all of the Smashing properties in order to create new partnership opportunities. Mariona told me,

“The most exciting moment this year has been to be able to create together with the whole team the Smashing Media platform bringing together events, magazine, publishing house, membership and Smashing TV. The highlight of the year is undoubtedly the birth of the partnerships and data office and the addition to the Smashing Family of my dear colleague Esther.”

Esther adds,

“Joining the Smashing team has been one of the highlights of the year. It’s been a pleasure to enter this community and to make the Smashing conferences happen.”

I’m looking forward to working together with Mariona and Esther this year as we open up new opportunities for partnerships that cross the boundaries of the different parts of the platform!

Smashing Magazine

Topple the Cat wearing its Thinking HatThe heart of what I do at Smashing is the online magazine; as Editor in Chief, my role here is to try to bring you web design and development content that will inform you, help with your day-to-day work, and also make you think. We publish almost every weekday, so always have a large list of articles moving through the writing, editing and publishing process.

Looking through our analytics, I pulled up a list of the most popular articles published in the last year. The range of topics making it to the top may surprise you, and demonstrate the wide range of subjects we cover here. We have the Front-End Performance Checklist, an article comparing Sketch, Figma, and Adobe XD, and two articles about designing tables: Table Design Patterns On The Web and How To Architect A Complex Web Table. HTML and CSS are always popular with How To Align Things In CSS, How To Learn CSS and HTML5 Input Types: Where Are They Now? —all getting a top spot. They are joined by Styling An Angular Application With Bootstrap and Using Vue.js To Create An Interactive Weather Dashboard. That’s quite the range of subject matter!

Covering such a broad spectrum of web design and development is certainly a challenge and one I couldn’t do alone. My subject editors Alma Hoffmann, Chui Chui Tan, Drew McLellan and Michel Bozgounov bring their expertise to the topics they help curate. Copy editors Andrew Lobo and Owen Gregory help preserve the tone of voice of our authors while ensuring the content is easy to understand for an international audience. Cosima Mielke ensures that the newsletter is well researched along with many other roles (including eBook production), and Yana Kirilenko does a great job of getting articles from Google Docs, Dropbox Paper and various Markdown apps into the CMS. Senior editor Iris Ljesnjanin does an amazing job of keeping everything on track, fielding the email, hitting publish on most of the pieces, and making sure that we are all using smashingly correct punctuation! I am very grateful for all of their work.

Vitaly and I are well-known faces in the web community, however, there is a whole cast of folk working behind the scenes to keep the magazine running successfully. I don’t say thank you enough, but I sincerely appreciate all the work that goes into the magazine across the team.

Smashing Magazine turned 13 this year to which I shared personal stories from the team — you can read more about the people behind the Smashing scenes over here.

This year, I’ve tried to bring the various facets of the business into the magazine. For example, each conference results in a set of high-quality videos of the presentations which was hidden away on Vimeo. This year, I’ve published a write-up of each event, listing all of the videos. I hope that this means more people can benefit from the wisdom of our speakers and also shows the brilliant work the conference team does in curating and putting on these events.

Something that I really enjoy is to publish articles by folks who have never written for a large publication before and to help their articles go through the process. Earlier this year, I wrote an article on Pitching Your Writing To Publications. If your 2020 goals include writing for Smashing Magazine, drop us a line with an outline of your idea. We would love to work with you!

Smashing Books And Our First Print Magazine

In 2019, we published two printed books, plus our very first print magazine. Art Direction For The Web was published in the spring, and at the end of the year, we began shipping Inclusive Components.

In the middle of the launch of Inclusive Components, we welcomed a new team member, Ari Stiles. She told me,

“It was challenging and fun to start working on the Smashing Library right after Heydon’s book was released, when promotion was already in full swing. A bit like stepping in front of a firehose — but in a good way! It helps that Inclusive Components is a well-written, timely book. I love helping people discover new and helpful resources like this one, and I’m excited about all of our new books for 2020.”

Topple the Cat presenting the Smashing Print coverSelecting a topic for our first print magazine was tricky. We wanted these magazines to be a snapshot of the industry at a certain time, but also to have a longer shelf life than tutorials on topics that will be out of date in a few months. Ultimately, for issue one, we chose a subject that was at the forefront of many minds in 2019 — that of ethics and privacy. The collection of essays I commissioned is designed to make you think, and we still have a few print copies and the digital version, if you would like to read them.

🎉 We’re currently in the planning stage for issue 2 — watch this space!

All of our books come with an eBook version, and one of Cosima Mielke’s many roles is to produce this version from the final manuscript. Memories of working on these projects were her response when I asked her about her 2019:

“As an eBook Producer, the moment when you’re being handed over the proofread manuscript to get started with eBook production is always a special moment. So many people — reviewers, proofreaders, and most importantly, the authors themselves, have already invested so much time and efforts into the manuscript, and now it’s your turn to put it into its final shape: the eBook that people are going to download and read.

“My personal highlight (and biggest challenge) this year was to turn the monumental opus that Andy provided with “Art Direction for the Web” into an eBook. The assets included almost 600 images — most of the designs created by Andy from scratch — and turning these into an eBook that does justice to the author’s meticulous work, provides a pleasant reading experience (given the rather limited possibilities that eBook reading devices usually offer), and has a reasonable file size at the same time, was quite a balancing act. Looking back, it was the most challenging eBook I have worked on to date — and, naturally, these kinds of projects make you feel proudest once you’ve accomplished them. I’m already curious to find out what 2020 will bring.”

The Smashing Podcast

Smashing Podcast moderated by Drew McLellanFor the first time this year, Smashing Magazine has a podcast. Hosted by Drew McLellan, this bi-weekly show interviews someone from the world of web design and development. We hope to bring you some well-known names, but also speak to folks doing interesting things across the industry.

In addition to having a very broad base of subject matter, Smashing has a global audience; we’d like to reflect that and bring you interviews from people all over the world. I asked Drew for his thoughts on these first few episodes:

“I was really pleased to be able to launch the Smashing Podcast this year. We spent quite a bit of time in development with it, trying to work out what the best format and tone to take would be. We tried to make it sound like Smashing and embody the same values; a good place to learn and stay informed, but with a sense of fun.

Our early guests have included experts such as Jina Ann, Liz Elcoate, and Jason Pamental. And we’ve spoken to authors of Smashing books Andy Clarke and Heydon Pickering.

The reception so far has been great, and you can always let us know what you think via the contact page. I’m looking forward to releasing episodes with the guests we have lined up for 2020!”

If you haven’t listened to an episode yet, you can catch up by subscribing here, or check out the individual episodes and full transcripts.

Smashing Membership

Topple the Cat showing off its ice skating skillsWe love our Smashing Members! This year you have continued to sign up and support the publication of independent content. We’ve been running webinars (with the help of Scott Whitehead and Bethany Andrew where members get to chat with one another in our Membership Slack, while enjoying free copies of our eBooks, plus a copy of the print magazine! We’re really keen to build on and evolve membership over the next years, and we sincerely thank our members for their support.

We have been running a membership table at our event, where members and prospective members can chat with the team. Our partnership manager, Mariona Jones remembers,

“While running the membership table at SmashingConf, I met a group of attendees who shared their passion for many things, among them open-source, stickers, code, and caffeine while browsing together through the first-ever Smashing print magazine on ethics and privacy and conversing about the relevance of this important topic.”

That’s enough from me! Still, we can’t wrap up 2019 without some thoughts from Vitaly, without who Smashing would not exist at all.

Vitaly on stage in front of a slide saying Welcome

Vitaly opens a SmashingConf (Photo credit Marc Thiele)

“It’s common to think that it’s all about the achievements or goals that make a year special, but for me, this year was full of meeting wonderful people. So, so many people. I’ve had a chance to speak with hundreds of people all around the globe, learning from their experiences and sharing mine. I was lucky to travel to over 40 places this year, from Albania, Serbia and Bosnia-Herzegovina to Kyiv, Sweden and Budapest. I vividly remember some of the stories and experiences I shared over a fire in the evening, in cars on the way somewhere, and in buses talking to strangers I’ll never see again. These were extremely rewarding, valuable and precious moments for me. They are the ones that I’ll be looking back to years from now. In essence, it’s all about people in the end.

“It was wonderful to connect with some of our readers at New Adventures in Nottingham, InfoShare in Gdansk, Poland, BTConf in Dusseldorf, FrontEndUnited in Utrecht, Netherlands, YGLF in Vilnius, Lithuania, in Amsterdam, Netherlands, and so many others! That said, travel is not without drama. When I was on a short vacation in Albania, I ended up getting lost in the woods in the middle of nowhere at midnight. That was quite scary, but thanks to 6% on my phone and a hardly visible, remote McDonalds sign, I was able to get out in a few hours, returning to the hotel around 5 AM.

“I think that this year at Smashing we’ve learned what it really means to be a team. We had tough and difficult situations, but we pulled together in a respectful, kind and very supportive way, and we kept strong and we made it. It was a year full of challenges and adventures, but in the end, we’ve grown even closer together, and I’m very proud of our team for getting there. I’m also very proud of the fact that we have been exploring topics that are often not seen as particularly interesting nor trendy — accessibility, ethical design, privacy. At our conferences, for example, we’ve looked into common problems and issues that developers and designers struggle with, and tried to find solutions and common techniques to tackle them. It’s something that I strongly believe is important for the health of our industry, and I’m happy to see more discussions around these topics this year.

“My sincere hope is that we’ll establish an even stronger team filling in the gaps we currently have, and we’ll manage to create a very strong alignment within the company. I hope we’ll be able to reach out to more people — especially the new generation of designers and developers — and connect with them. I can’t wait for the books that we’ll be releasing next year as well! I have a number of ideas in mind of things I think we could do, but before jumping there, I want to make sure we are stable, healthy and strong. No rush — I’ve been patient my entire life.”

Onwards To 2020!

The whole team is looking forward to seeing what 2020 brings, and to sharing that with the Smashing Community — wherever you are in the world. Thank you for being part of our journey!

A lineup on stage in front of a screen saying Thank you

The Smashing team on stage in New York (Photo credit: Drew McLellan)
Smashing Editorial

Source: Smashing Magazine, 2019: A Smashing Year In Review

New Adventures Ahead! (January 2020 Wallpapers)

dreamt up by webguru in Uncategorized | Comments Off on New Adventures Ahead! (January 2020 Wallpapers)

New Adventures Ahead! (January 2020 Wallpapers)

New Adventures Ahead! (January 2020 Wallpapers)

Cosima Mielke

Let’s welcome 2020 with a new wallpaper! After all, the new year is the perfect occasion to tidy up your desktop and start on a fresh, blank slate — no clutter, just the things you really need and space for what’s about to come. And some inspiration, of course.

As every month since more than nine years already, artists and designers from across the globe once again took out their favorite tools to create wallpapers to inspire you, make you smile, think, or just to cater for a blob of color on a dark winter day. The wallpapers are available in versions with and without a calendar for January 2020 and can be downloaded for free. And since this little challenge has brought forth so many unique artworks over the past few years, we also assembled a selection of older January favorites at the end of this post. We wish you a wonderful start into the new year and a lot of exciting adventures to cross your way in 2020!

Please note that:

  • All images can be clicked on and lead to the preview of the wallpaper,
  • We respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience through their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us but rather designed from scratch by the artists themselves.

Submit your wallpaper

Do you have an idea for a February wallpaper design? We are always looking for creative talent to be featured in our wallpapers posts. Don’t be shy, join in! →

New Year, New Beginnings

— Designed by MasterBundles from USA

New Year, New Beginnings

National Popcorn Day

“In this epic Netflix and Chill era, nothing has gotten more important than popcorn during the newest blockbuster! Time to gain awareness about celebrating our delicious guilty pleasure during the movies!

A little story around the wallpaper: Mr Popcorn and Mrs Popcorn are enjoying a great movie with… You guessed it right, popcorn!! But Mr Popcorn is somewhat annoyed as his Mrs eats Popcorn from his head instead of eating from the bucket right in between the loved ones.”

Designed by Nicolas van der Straten Ponthoz from Belgium

National Popcorn Day

It’s Snowing!

“It is January, it’s cold and snowy… In the house, the fireplace is on and it’s hot. Only penguins are enjoying time out there.”

Designed by Veronica Valenzuela from Spain

It’s Snowing!

Month of the Garnet Birthstone

“I wanted to approach the monthly challenge from a more unique perspective. Instead of chosing a cliché subject that has been done way too many times before, I chose a less known, special subject. The birthstone. Enjoy.”

Designed by Bram Copermans from Belgium

Month of the Garnet Birthstone

Rubber Ducky Day

“Winter can be such a gloomy time of the year. The sun sets earlier, the wind feels colder and our heating bills skyrocket. I hope to brighten up your month with my wallpaper for Rubber Ducky Day!”

Designed by Ilya Plyusnin from Belgium

Rubber Ducky Day

Good Intentions

— Designed by Jonathan Verhaegen from Belgium

Good intentions

The King Of Rock And Roll

“On January 8th 1935, the creator of the rock ‘n’ roll genre was born and he’s back for his final debut on this wallpaper!”

Designed by Bailey Lievens from Belgium

The King Of Rock And Roll


“Aquaman relaxing in the ‘nice’ January weather.”

Designed by Ricardo Gimenes from Sweden


Laughter Is An Instant Vacation

“These are polarized times we’re living through. It seems like there is division all around. So sometimes you just have to find the time to remember that the one thing that connects us all is a good laugh. And there is no better laugh than the belly laugh! So on the 24th of January, let’s celebrate one of life’s truly great joys and let it all hang out!”

Designed by Ever Increasing Circles from the United Kingdom

Laughter Is An Instant Vacation

Chocolate Cake Day

“I really love chocolate cake, so when I found out about “Chocolate Cake Day” I had to make a wallpaper about it!”

Designed by Aaron Claes from Belgium

Chocolate Cake Day

Earth’s Rotation Day

— Designed by Bob Storms from Belgium

Earth’s Rotation Day

Go Green & Save The Earth

“Taking care of the Earth is not just a responsibility, it’s a necessity. So I designed a wallpaper to remind everyone what we can do to help save the planet.”

Designed by Farhat Asif from India

Go Green & Save The Earth

Stickers from the 70’s

“I didn’t want to make a typical New Year themed wallpaper for January so I started looking for fun ideas. Apparently January 13th is day of the stickers and so I made something original with this. I wanted to add an extra challenge that was totally out of my comfort zone. So I designed everything in seventies style. Grooovy baby!”

Designed by Bastien Corens from Belgium

Stickers from the 70's

The Wolf’s Month

“I love wolves!”

Designed by Morgane Van Achter from Belgium

Wolfs month

Oldies But Goodies

The beginning of something new, the colors of winter, local New Year’s traditions — these are just a few of the things that inspired people to create a January wallpaper over the years. Below you’ll find a selection of designs from our archives that are just too good to be forgotten. Enjoy! (Please note that these wallpapers don’t come with a calendar.)

Start Somewhere

“If we wait until we’re ready, we’ll be waiting for the rest of our lives. Start today — somewhere, anywhere.”

Designed by Shawna Armstrong from the United States

Start Somewhere


“I was reminded of a simple fact while I was browsing for inspiration for this wallpaper. I’ve read on Wikipedia that January is the coldest month on most of the northern hemisphere and the hottest one on most of the southern hemisphere. I found it fascinating that someone in Australia is enjoying a surf while I am watching the first snowflakes of the winter. I was hoping to create a wallpaper that will serve as a reminder of the fact that we live in a fascinating world full of varieties and contrasts. The old-worn-out-encyclopedia style hopefully emphasizes the educational theme of the wallpaper.”

Designed by Danijel Gajan from Serbia

Smashing Desktop Wallpapers - January 2012

Hidden Gem

“Kingfishers are called ‘ijsvogels’ (ice-birds) in Dutch. Not because they like the winter cold, but because of the intense blue and teal colors…”

Designed by Franke Margrete from the Netherlands

Hidden Gem


“It is great to take shots of birds and think about the freedom they have. Then I start dreaming of becoming one and flying around the world with their beautiful wings.”

Designed by Marija Zaric from Belgrade, Serbia


January Is The Month For Dreaming

“It can be very hot in Australia and very cold in Europe so I think that it is a good month for dreaming and making plans.”

Designed by Tazi from Australia

January Is The Month For Dreaming

Travel And Explore

“For once you have tasted flight you will walk the earth with your eyes turned skywards, for there you have been and there you will long to return. (Leonardo da Vinci)”

Designed by Dipanjan Karmakar from India

Travel & Explore

A New Beginning

“I wanted to do a lettering-based wallpaper because I love lettering. I chose January because for a lot of people the new year is perceived as a new beginning and I wish to make them feel as positive about it as possible! The idea is to make them feel like the new year is (just) the start of something really great.”

Designed by Carolina Sequeira from Portugal

A New Beginning

Open The Doors Of The New Year

“January is the first month of the year and usually the coldest winter month in the Northern hemisphere. The name of the month of January comes from ‘ianua’, the Latin word for door, so this month denotes the door to the new year and a new beginning. Let’s open the doors of the new year together and hope it will be the best so far!”

Designed by PopArt Studio from Serbia

Open the Doors of the New Year

“I wanted to try my hand at creating a low poly illustration and thought a champagne glass would be fun.”

Designed by Denise Johnson from Chicago

Pop, Fizz, Clink

Oaken January

“In our country, Christmas is celebrated in January when oak branches and leaves are burnt to symbolize the beginning of the New Year and new life. It’s the time when we gather with our families and celebrate the arrival of the new year in a warm and cuddly atmosphere.”

Designed by PopArt Studio from Serbia

Oaken January

Snowy Octopus

— Designed by Karolina Palka from Poland

Snowy Octopus

Soft Wishes

“Let yourself be carried away by the delicate desires of your heart…”

Designed by Katia Piccinni from Italy

Smashing Desktop Wallpapers - January 2012


— Designed by Elise Vanoorbeek from Belgium


The Early January Bird

“January is the month of a new beginning, hope and inspiration. That’s why it reminds me of an early bird.”

Designed by Zlatina Petrova from Bulgaria

The Early January Bird

Winter Leaves

— Designed by Nathalie Ouederni from France

Winter Leaves

Caucasian Mountains

“From Caucasus with love!”

Designed by Ilona from Russia

Smashing Desktop Wallpapers - January 2012


“Wolf-month (in Dutch “wolfsmaand”) is another name for January.”

Designed by Chiara Faes from Belgium


Be Awesome Today

“A little daily motivation to keep your cool during the month of January.”

Designed by Amalia Van Bloom from the United States

be awesome today

Blue Neon Sign

— Designed by Jong S. Kim from the United States

Smashing Desktop Wallpaper — January 2013

Join In Next Month!

Thank you to all designers for their participation. Join in next month!

Smashing Editorial
(cm, il)

Source: Smashing Magazine, New Adventures Ahead! (January 2020 Wallpapers)

Smashing Podcast Episode 6 With Luca Mezzalira: What Are Micro-Frontends?

dreamt up by webguru in Uncategorized | Comments Off on Smashing Podcast Episode 6 With Luca Mezzalira: What Are Micro-Frontends?

Smashing Podcast Episode 6 With Luca Mezzalira: What Are Micro-Frontends?

Smashing Podcast Episode 6 With Luca Mezzalira: What Are Micro-Frontends?

Drew McLellan

Luca MezzaliraWe finish off this year with yet another Smashing podcast! This time, we’ll be talking about micro-frontends. What is a micro-frontend? How is it different from the sort of approach we might be taking at the moment? Let’s find out from micro-frontend pioneer, Luca Mezzalira.

Show Notes

Weekly Update



Drew McLellan: He’s a Google developer expert on web technologies and manager of the London JavaScript community. With more than 15 years experience, he currently works as VP of Architecture, designing sports video platform DAZN, which delivers on demand sports content to millions of users all watching live. He’s the author of the book Front-End Reactive Architectures for Apress and is also a technical reviewer for Apress, Packt Publishing, Pragmatic Bookshelf, and O’Reilly, as well as being an experienced public speaker at technical conferences all around the world. He’s Italian, sports a handsome beard, and clearly has deep knowledge of the web platform. But did you know he once crossed South America on an ostrich? My smashing friends, please welcome Luca Mezzalira. Hi, Luca. How are you?

Luca Mezzalira: I’m smashing.

Drew: I want to talk to you today about the subject of micro-frontends. Now this is a concept that’s completely new to me, certainly by the name, and I expect it’s new to a lot of our listeners, too. Before we get into micro-frontends themselves, I guess we should understand the problem that you’re looking to address with them. So perhaps you could tell us a little bit about how you see applications in a more traditional way and what sort of problems do those things hit that maybe micro-frontends might be the solution to?

Luca: Okay, that’s a good starting point, in my opinion. So usually when you implement or design a new green field project and you want to work with front end applications, you have a few architecture that you can leverage. You can use a single page application, you can use a server side rendering application, or you can use a multi-page application composed by just simple HTML pages. Obviously those are super valid options and I think very used by many, many developers. The real problem that we’re trying to solve here is how you can scale these concepts with distributed teams to hundreds of developers working on the same codebase, because the reality is when you’re working in these platforms in particular, when you think about SaaS platform for instance, you need to have multiple developers and multiple teams that are working on the same project. And obviously the way how, for instance, you do acquisition or retention is completely different on the way how you expose the catalog or how you show a specific part of a platform.

Luca: So now in my experience I work a lot with single-page application. I work with server-side rendering application, but at some point in DAZN I’d be asked to think about a way to scale our technical team. And I need to come up … if for backend we have some solution that are microservices in this case, so we can scale our APIs independently, and take in consideration that the scale and the volume for a specific throughput on a specific API. On the front end, really, it’s really more difficult because if you think about that, you don’t have technical problem to solve when you need to scale, if you’re using a single page application, for instance. Probably for a server-side rendering you have some, but on a single-page application, for instance, it’s distributed by nature because it’s on client-side, different client-side.

Luca: So the only thing that they are loading are just some static files like CSS and HTML and JavaScript that are served by CDN, and in that case you can scale accordingly, it’s not a big challenge. But the real challenge is how you scale the teams working on the same platform, because sometimes the challenges that are faced by one team could be completely different from the challenges that are faced by another team, and usually what you do is you try to find a lot of tradeoffs between the things. Because if you think, let’s try to think on a normal use case. So usually when you start a platform you’re starting small. So you try to create that quick single-page application, as well you have your monolith, so you just set up everything in your CICD just once for front end and back end, and then you start to iterate on your logic. But the reality is when you have success, you need to evolve this part, and it’s not always maintaining the same architecture that could, let’s say, create the benefit for your business, because maybe you can find some bottlenecks.

Luca: So now going back to the single-page application part. So if we want to scale a single-page application part, the challenge is not technical, it’s with humans if you want. So how we can scale teams working on the same application. So what I did a few years ago is, was the starting to look at a possible architecture that and principles that would allow me to scale the front end as well as the backend. So working on the backend principles so that you can find the microservices. I started to look at the different solution and they came out with the micro-frontends that at the beginning we didn’t even call it that way because obviously for years ago there wasn’t the, let’s say, that name for that specific architecture.

Luca: But the reality is taking a monolith, so a single page application and slicing it in a way that will allow us to focus ourselves in a tiny problem. So a smaller problem than the entire application and trying to solve that in the best way possible. Technically speaking. Obviously that lead to have independent pieces of your frontend application that could be deployed in production without affecting all the others. So the challenge basically for Micro-frontend is trying to figure out their way to take a single page application or server side rendered application and create a artifact of these, let’s say, as close as possible to a business domain, and can be deployed independently.

Drew: So I mean you mentioned micro services on the back end. So conceptually this is a similar sort of solution to the problem. The micro services serve on the back end, but ported over to the front end. Is that a rough equivalence or is it more involved in that?

Luca: Yes. No, it’s a way to solve the same problem it is trying to solve microservices on the back end but on the front end in this time. Usually when I started this journey at the beginning, you know, you start to think about that and you start to evaluate different approaches. And in the last few months I came up with what they call, the Micro-frontend decision framework that basically is four steps that they use in order to, let’s say you identify an approach for Micro-frontend, because if up to now, we usually pick one framework that designed architecture for us and we implement on top of their architecture. If you think about angular or think about React or Redux. You have all the pieces that are needed but you don’t take architectural decisions. You would take a design decisions or how you implement on top of that specific architecture.

Luca: So on Micro-frontend you need to start the step back. So we need to think about how we want to first slice our application. So there are two usually options for that. You can slice horizontally, so you can have multiple micro-frontends in the same view or you can slice vertically. Therefore you always load one Micro-frontend per time. And those decision are quite key because it will then cascade certain other options that you have based on the initial decision to make. So the first, as I said, you decide how you want to slice your application. The second one is how you want to compose your application. So you want to have like, for instance, an app shell that is loading one or multiple micro-frontends in the same view. You want to have, I don’t know, application server that is composing different fragments of your applications, so different Micro-frontend and then serve the final view to your user. Or you want to use edge-side included, it’s a standard that is inside of CDNs in order to compose a page and serve these there.

Luca: Those are three of the options that you have. And then apart from composing, then you need to think how you want to route. So how you route from, I don’t know, /login or /signin to the catalog part or a specific detail object. Also here you have like three option. You can do it at the application server, you can do it on CDN level with Lambda Edge or any other web workers in CloudFlare or anything else. Or you can do a client site. So you have a logic inside your app shell that you say, okay, now for this specific URL you need to load another view or another micro-frontend. And the last bit is how you communicate with Micro-frontend.

Luca: So usually if you have like multiple Micro-frontend on the same page, there is higher complexity on managing this communication, because you need to maintain the different Micro-frontend independent. So that means you cannot have any reference on how the page is structured. So usually you can use stuff like custom events or an event meter that is injected inside each single Micro-frontend. And then the Micro-frontend are communicating together. Obviously in the other case when you have like let’s say a vertical split off your Micro-frontend is way easier, because inside the vertical basically the representation of a vertical Micro-frontend is a single page application or a single page. And in that case it’s easier to let’s say create and share having a shared state across the entire Micro-frontend.

Luca: Then if you think about having multiple Micro-frontend all together, then you should avoid to have states that are shared across Micro-frontend, because otherwise you are coupling things. Instead of the whole concept here is decoupling and have independent deployment. And therefore let’s say the challenges of a horizontal split, which is the first decision you should take or vertical split, are completely different, and we need to be very well aware which one fits our use case.

Drew: So rather than a specific technical solution, micro frontends are very much like a design pattern that you would implement in whatever technology is appropriate for the particular problem you’re trying to solve?

Luca: Yeah, more than technology, I would see that we pick the right architecture for the right job. Just to give you an example, I was talking … there is a famous framework, a fairly new for Micro-frontend, it’s called Luigi framework, that was released by SAP open source. What they are doing is creating some iframes where they are wrapping their Micro-frontend inside it. So now if you think about that, let’s say, using iframes nowadays, you’re on a public website that maybe as the SEO or other features that are mandatory, it could be problematic.

Luca: But in the case of SAP, if you think about that, they have like enterprise application where they can control the browser that the user is using, they can control the environment, they don’t need to be available on a multitude or different version of the browser. So for them these thing allows them to have certain areas of the application that are constant and they have certain areas that are changing independently without any problem. But obviously an iframe solution wouldn’t work in other situation. Just to give another example, Spotify, we’re using iframes at the beginning. In fact the desk publication is still composed by multiple iframes and each single iframe is a tiny application that does, I don’t know, just a music player or just their recommendation, whatever it is. They try to have the same approach on web, but they dismissed that this year in order to move back to a single page application.

Luca: And that means, they explain why in the technical blog, they were saying that obviously if you apply that to millions of users that are using iframes that needs to load every time the same vendors file. And then you have like a lot of dependancies duplicated and the time for interacting with your page would be longer. So in reality, this approach could fit for certain use cases, but they shouldn’t fit for all of them. That’s why I’m saying, as I described before, if you have a decision framework that helps you to address those thing and you can start to say, okay, I sliced the application in this way, therefore I have those options that are available when I want to compose, when I want to route, when I want to communicate, it should guide you in order to have the right decision at the right time.

Luca: Then obviously apart from those four decisions, there are many others. Like how you create consistency in the design system that you have across all the Micro-frontend. Or I don’t know how you manage the dependencies and avoid the clashing of the dependency inside the Micro-frontend, but the reality is those four decisions that I mentioned before will allow you to then take all the others in a quick way without having the problem of overthinking, which is the best solution because you already set the cornerstone, the four pillars, that will allow you to take all the other decision … I don’t say in a easy way, but in a quicker way than a review or the spectrum of opportunities.

Drew: You mentioned before, the way that Micro-frontend can help with the sort of structure of teams within your organization and having lots of people working on the same application. What are some of the implications then and does it make any difference if your teams are distributed or co located or are there any challenges that are faced there?

Luca: Yes. So I can tell you what is the story of DAZN. That is the company where I’m working on. Currently in DAZN, we had like a nice challenge. So currently we have over 300 people that are working on the front and the back end of our platform. It’s an OTT platform that is streaming live at sport events globally. And the interesting bit is if all microservices we know how to manage more or less and we have distributed teams. So we have four dev centers. We’d want to put teams in each single dev centers on the front, and we tried this approach and it work pretty well. So with Micro-frontend we were able to provide different business domains in different locations and allow the cross communication between teams inside a specific business domain, very because the worst case scenario there that if you have to speak with another team on your same business domain, you just reach the walking distance from your desk. If instead you need to discuss specific thing on the distributive team, so with maybe somebody in London instead of Amsterdam, or instead of company in Poland, you just organize a call.

Luca: But those kinds of communication are more rare than the ones that are happening across teams inside the same location. And that’s why we started working on that. So the first thing that they did was looking at how our users were interacting with our website, how did the company was structured. And when we identify the four key areas that we are working on, that are currently acquisition and retention, let’s say porting of their core application on multiple TV’s and mobile and having the core domain that for us is the video player and the discovery phase of our content. And finally all the back office elements. I was able to identify those four areas and we those four areas we assigned for each single dev center.

Luca: Obviously there are some point of contacts between those areas, but then there are ways that you can let’s say mitigate and have some initial workshop with the different teams that are in different location and then work towards the same API contract for instance, or the same goal with having some checkpoints during the development. But the nice thing of approaching that allowed approaching with Micro-frontend is the fact that we finally understand deeply how our system was working. We sit down and we analyze how we were structured and we changed not only the way how we were affected things, but also how the company was working. And that was a kind of a different approach from what they have seen so far. But it’s proving that is working pretty well in the case that each single team can interact with the team of the same location in the same domain.

Luca: So they are talking exactly on the same language if you are talking about the domain driven design. And that is that if they need to interact with other teams, they can literally share the workshop or flying to another dev center and it’s less than a problem. But in this way we let’s say, augment the throughput and reduce the communication overhead, and the extent of dependencies that were happening in other situation that they were working on.

Drew: And do all these teams need to be using like a standardized JavaScript framework? Do they all need to be coding in the same things, they all need to be either React or Angular or to enable the interoperability between them or can people be using different things for different Micro-frontend?

Luca: Yeah. So in DAZN we decided to slice vertically our Micro-frontend and that was a decision that allowed us to have the freedom to pick the technology that we need for each single Micro-frontend. Considering that every time we load one Micro-frontend per time and this means that for instance, that how we have a landing page is different from the sign in / sign up journey. So we can update … we’re mainly using React at the moment. But if, for instance, I remember when React 16 was a release that we were able to release in production React 16, also if it wasn’t in the stable version for just a landing page and see if it was working without affecting all the other teams.

Luca: And then at their own speed, at thier own pace, they were updating their own stuff. So that allows us also to let’s say try new technologies or new assumptions that we have on the existing application with a certain amount of users. Because we implement the also candidate releases for front end. We implement the, let’s say several practices that allows us to just try certain times in production and see how the things are working.

Luca: The beauty of these approaches that we can independently decide to have the right tool for the right job more than having a common denominator across the entire stack. Because as you can imagine, when you started to work on a project, the decision that you made the first few years are probably different on the decision that you made in a trajectory where the company’s growing, the business is evolving and these became more mature and the challenge is completely different. So it wouldn’t be flexible enough or agile enough, if you think about that, the fact that we stick with the same decision we take two years ago. In particular an institution like DAZN, that we move from basically zero to 3000 employees in three years. So as you can imagine it was a massive growth and it was a massive growth for the company as well as on the user base.

Drew: Is there an established way for the different Micro-frontend to share data and to communicate with each other, for example, just to keep each other in step with the same view or is there a way to do that?

Luca: Yes, there is. It depends which of the decision framework, which path you’re going to take. Because if you’re going to take the vertical slice that became very easy. So what we have in order to communicate through Micro-frontend is an app shell that is loading in Micro-frontend inside itself. And what it does is storing everything that has to be, let’s say, shared across different Micro-frontend or on a web storage, either a session or local storage or in memory. And then based on those information, the Micro-frontend is loaded, can retrieve from the app shell to this information and then consume that, amend that or change them. It’s completely up to how you slice the application, but in this case, just to provide an example, if you think when you are authenticated users and you need to go to the sign in page, when you in and the APIs are our consumed and they are providing a JWT token, Micro-frontend is passing these to the app shell and the app shell these starting we saved their web storage.

Luca: Then after that the app shell is loading the new authenticated area for that specific application and those authenticated areas, they’re retrieving the JWT token from the app shell and is performing either a refresh access token or is validating some data starting inside the JWT token. So it’s using basically the information that were produced by another Micro-frontend at their own wheel.

Drew: It sounds like a very interesting concept and I can potentially see lots of big advantages to working this way, but it can’t be without its challenges, surely. Are there any particular things that are more difficult to deal with when architecting things in this way?

Luca: I think first and foremost the main challenges that I see is the shift of mindset. Because before we were used to have a, let’s say, the tech leads or the lead developers that were deciding everything around an entire application taking all decisions. Now finally we move from this centralized entity to a de-centralized entity that is local for each state. As you can imagine, this is bringing some challenges because if before we have someone that is tracing the path, now is that we have, let’s say, multiple people at the top defining the right path inside their domain, and this is a huge shift of mindset.

Luca: On the other side, I think the complexity is accepting sometimes that you doing the wrong abstraction could be, let’s say, more expensive than duplicating code. And that’s I know there’s something that I found very challenging in managing developers because they’re thinking, “Okay, now I can reuse this object or this specific library hundreds of times inside the project,” but the reality is very different. I saw components library that were abstract and they spend a lot of time making that as the best code ever or the best in a perfect shape. But the reality were used just twice. So the effort of doing that, it wasn’t exactly that. I saw on the other side libraries that they started with a couple of use cases for a specific component. And then those use cases became 10 and then the code became unmaintainable.

Luca: So trying to add a new function inside the same component could be more at risk than a benefit. So I think the other thing that we need to understand with Micro-frontend is how much we want to share it and how much we want to duplicate. And there is no harm, honestly, duplicating. In our case for instance we have a duplication of footer and header, and we did that mainly because we changed like three times the header in four years. So as you can imagine the fact that we are centralizing these, are assigned to a team and create an external dependency for all the teams, all the hundreds of developers that we have, is more let’s say an issue that a benefit for the company because we are not adding an enormous value.

Luca: At the same time currently we are refactoring, our shared libraries that would be payment library, because obviously payment has some logic behind that and if we want to change once, we don’t want to apply that twice in multiple parts of the code. We want to have just one library that is a source of truth, but for the header and footer, also if there is a discrepancy or for pixel or there is a function that this is deployed like a week later, it won’t hurt the application.

Drew: So are there some telltale signs that people should look for when evaluating an application and thinking, “Oh yes, this would be a good candidate to move to a Micro-frontend sort of architecture?”

Luca: Yeah, so my suggestion would be first and foremost I wouldn’t start a greenfield project with Micro-frontend unless we know exactly how it should be built. And usually it’s very unlikely that you have this information because, particularly if you have a new platform or a new project and it’s the first time that you are working on this, it could be a nontrivial finding this information. Usually what I suggest is starting with an existing architecture that would be so a single page application and then evolving that. In particular for instance I found, I think that using Micro-frontend for legacy applications or when we want to replace specific part of the application or when we have a project that we want to evolve and scale for multiple teams, those are three use cases that I feel very strong could suit the Micro-frontend architecture. Obviously that doesn’t mean that from now on everything should be made Micro-frontend, because Micro-frontend is not the silver bullet at all.

Luca: What they are is an additional architecture that we can leverage on the front end world. And up to now we had like a certain amount of architectures, now we have an additional one. But that’s a lot of challenges because obviously you need to, if before server side rendering or a single page application, there are clear patterns that were explored and then implemented by several framework and so on. With Micro-frontend currently, is one way to do things. But adding the decision framework probably should allow people to make the right decisions for their use cases. Because often there are a lot of misconceptions on what Micro-frontend are and how they should be used. And lots of people are thinking that maybe let’s say, are evil for, I don’t know, having too many libraries in one view or other things.

Luca: The reality is you need to understand deeply the concept, understand how to implement that and then you can start to work on that. I fully agree that there are technical challenges and there are a lot of decisions that you have to make and you cannot just start straight away with an editor in front of you writing code and thinking, okay, now I’m creating a micro-frontend architecture. Because you need to understand the concept, understand the context and create, also governance around that because the complexity is not just writing the code, it’s also understanding how all the pieces are fitting together in the CICD part the SEO part and so on.

Luca: So Micro-frontend does provide, let’s say a level of flexibility and require a lot of effort for defining the governance right. Because when you have the governance right, everything would be smooth. Often and unfortunately I would say too often, I saw companies that where they don’t spend enough time on the governance side, understanding the CICD for instance, because they don’t think that this is important. But instead for Micro-frontend, like for microservices, having automation right will allow you to speed up the development. If you don’t spend enough time on the automation bit, you risk to have more burden than benefits.

Drew: I guess it’s like so many things in the web development world where people are in danger of diving in with a technical solution before they’ve really understood the problem. And it sounds like with Micro-frontend is very much a case you need to see the problem and then implement the solution to know what problem that you’re solving. I guess the very nature of Micro-frontend make it very easy to start integrating into an existing application, to spot a small problem and swap it out with a Micro-frontend in order to solve that problem. Is that a reasonable suggestion?

Luca: Yeah, I would say so. In this case, the only thing that I would suggest if we start in this way is looking more at the vertical slicing over the horizontal slicing, because otherwise you need to solve so many problems about, let’s assume that for instance you’re using Angular and you want to move to a new version of Angular. If you need to have two Angular version living together without using I-frame, it could be complicated or even not possible. So if you start, you the aspect not from … if you check the challenge, not from the technical point of view, but from the business point of view. Maybe for instance, you can take, I don’t know, the sign-in part on that you want to write with a different version or the same version but more update version of a framework and that could be a good way. And then you route through the path. That could be a good way to replace slowly but steady a specific application.

Luca: What we have done in our case is basically applying the strangler pattern that is a well known pattern for microservices, but on the front end. So based on the URL and based on the browser and country of the user. So slowly but steady, basically we were killing the monolith, that in this case was single page application, releasing our new application more often and see the behaviors of the users, if it was improving the experience, it was causing any problem on our system or not. And that allowed us to provide immediate value to the business, but at the same time allowed us to test our assumptions and see if we were going to the right direction or not.

Drew: It sounds like a very attractive solution to some problems I’m sure a lot of people are facing. If I, as a developer, wanted to start investigating more about Micro-frontend, where would be a good place to start?

Luca: Yes, so currently I’m spending a lot of my spare time trying to advocating around these architecture, because I think there are a lot of misconceptions. On my Medium account. I’ve wrote several articles that are available there as well. A recorded a lot of videos in conferences that you can find on YouTube without any problem. And the other thing I would suggest if you’re looking for some code example on some frameworks, the one that I would recommend to start with is a single SPA, mainly because it has a vertical slicing approach, it’s easier to pick it up and you can start to understand the benefit of this architecture. Then there are many others that are available. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they’re out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let’s say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn’t, just one way to do things. We are used that we take a framework and immediately we start to work on it and it’s super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I’ve been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I’m learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I’m studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I’m SVP of architecture. I have a team of architects that I’m leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I’m studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he’s @LucaMezzalira or find his activities collected together at Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.

Smashing Editorial
(dm, ra, il)

Source: Smashing Magazine, Smashing Podcast Episode 6 With Luca Mezzalira: What Are Micro-Frontends?

5 Things To Stop Doing In Mobile App Design

dreamt up by webguru in Uncategorized | Comments Off on 5 Things To Stop Doing In Mobile App Design

5 Things To Stop Doing In Mobile App Design

5 Things To Stop Doing In Mobile App Design

Suzanne Scacca

I move to a new state every two to three years, so it’s important for me to live “light”. Every time I prepare to move, I go through the “Do I really need to keep this?” exercise. Although I’ve been doing this for almost 20 years, it never gets any easier. I wonder things like:

What if I sell my bed and never have a comfortable night’s sleep again?

What if I get rid of the fancy dress I wore once but might need for some hypothetical future event?

What if I decide to start baking cupcakes again and don’t have my cupcake tin anymore?

It’s easy to get attached to things when they served you well at one time or another. But if you take a closer look at the “stuff” you’ve accumulated, you’ll realize that a lot of it has lost its usefulness along the way.

I think it’s important to run through a similar type of decluttering exercise in the work you do as a designer. That way, the apps you build always look fresh and modern instead of weighed down by antiquated features or functionality that at one time had a purpose.

Before you start charging ahead into the new year, take a moment to reflect on how you approach mobile app design. If you’re still holding onto components or functionality that no longer serve any purpose or, worse, intrude on the user experience, it’s time for a change.

Want some help? I’m going to run through some elements you can afford to scrap from mobile app builds in 2020 and beyond.

Related Reading on SmashingMag:

1. Harmful FOMO Elements

You know why marketers, influencers, and designers use FOMO (i.e. it can be really effective in boosting sales). However, you also know how damaging it can be for users’ mindsets (not to mention the distrust they feel towards brands as a result).

You could avoid FOMO altogether, but it’s a tricky thing, isn’t it?

You know that (when left to their own devices) mobile app users may forget that your app even exists on their phones without something to pull them back in. But it’s too easy to go overboard with FOMO-inducing components.

For example, this is ToonBlast:

ToonBlast home screen countdown timers

The ToonBlast gaming app has numerous modules and countdown timers to induce constant FOMO. (Image source: ToonBlast) (Large preview)

The home screen is incredibly overwhelming. More than that, those ticking clocks (there are four of them) are a nightmare for users who can’t help but click on things they feel they’re going to miss out on by not doing so. And for users who can ignore the timers, they won’t be completely unaffected by them either. The game displays pop-up reminders for each of the countdowns. It’s impossible to ignore them.

This is FOMO at its absolute worst.

Even if reminders for each of the countdowns were sent as push notifications instead of disruptive pop-ups, it still would be bad for the user experience. There are just too many things competing for the user’s attention and each of the clocks is like a ticking time bomb.

I know it might seem like giving app users more reasons to engage is a good idea, especially if you’re struggling to attract and retain users. But if that’s really an issue, then you need to work on improving the core product first and foremost.

Going forward, I think we’d all do well to move away from harmful FOMO elements and embrace more simplified and stronger core products.

If you’re not sure what that looks like, I’d recommend turning your attention to Instagram:

Instagram FOMO-free

Instagram is working on removing FOMO from its app. (Image source: Instagram) (Large preview)

Instagram is a simple and straightforward product. Users turn their news feeds into personal curations of people and accounts they want to follow while sharing their own content with the world.

Now, Instagram isn’t completely FOMO-free as you can see from the Stories bar at the top of the page. However, there’s nothing really urgent about the way these stories are displayed. They don’t take up much space in the app (unlike the way Facebook handles it, for instance) nor are there any screaming alarms that say, “Hey! So-and-so’s story is about to expire! Watch it now!”

That said, Instagram is working to remove the harmful effects of FOMO in its app by doing away with like counters and cracking down on influencers and companies that don’t mark ads as such. If you want to create a strong yet simple product that keeps harmful FOMO elements out of the picture, keep this one on your radar.

2. Out-of-Context Access Requests

Unlike mobile websites and PWAs, mobile apps have the ability to get in front of 100% of users who activate push notifications. But that’s the catch. Your users have to be willing to press “OK” or “Allow” when you display that push notification (or phone access) request pop-up.

So, how do you get more of them to do that without constantly shoving those requests down their throats?

Some brands haven’t figured this out yet, to be honest. Take Snapchat, for example.

Snapchat push notification request

Snapchat doesn’t like when users disable notifications and phone access. (Image source: Snapchat) (Large preview)

This is one of those apps that just goes way overboard when it comes to requesting access to users’ devices. It wants to:

  • Send push notifications.
  • Use the camera.
  • Use the microphone.
  • Access saved photos.
  • Enable location tracking.
  • And so on.

Rather than ask for access when it’s relevant, it often sends a deluge of requests first thing when users sign into the app. That’s the wrong way to create a welcoming environment for your users.

A better way to go about asking for access or permissions would be to place it in the context of the app — and only when it makes sense. I’ll show you a couple of examples.

This is the app for ParkWhiz:

ParkWhiz location tracking request

ParkWhiz reminds users about the benefits of enabling location tracking. (Image source: ParkWhiz) (Large preview)

Look at the section called “Help Us Find You” toward the bottom.

Not only does ParkWhiz gently remind users to enable location tracking on their devices, but it does so by explaining the reasons why it would benefit them to do so. Notice also that this isn’t displayed in an intrusive pop-up at the point of entry. Instead, it’s in a spot in the app where, when enabled, it can help streamline the search experience.

YouTube is another app that does this well.

YouTube push notification tooltip

YouTube displays a small tooltip to remind users to turn on notifications. (Image source: YouTube) (Large preview)

In this example, YouTube quickly displays a tooltip over the disabled notification icon. The notice reads:

“You’re missing out on subscriptions! Tap the bell to turn on notifications.”

They’re right. I’m subscribed to this channel and, yet, I haven’t received notifications (push or email) about new videos for a while. I hadn’t realized this until I saw this reminder.

The way this is handled is nice. It makes users stop and think about what they’re missing out on instead of rushing to close out another request pop-up. It also doesn’t force them to turn on push for everything. They can customize which notifications they receive.

Push notifications are supposed to be helpful. And access to your users’ phones is supposed to enhance their experience. That’s why it’s important to ask for their cooperation in enabling these features within the right context. Rather than bombard them with request after request at the outset of installing or opening an app, deliver them within the experience as in-line elements.

3. Unnecessary Icon Labels

Note that this point is called unnecessary icon labels and not just a sweeping generalization of all of them. That’s because there are certain parts of an app where icon labels still work well. Like the navigation bar.

However, I’ve noticed an alarming trend lately whereby apps pair every page or tab name with a matching icon. There are a number of reasons why this is an issue and I’m going to use the GEICO app to demonstrate them.

GEICO mobile app home page

The GEICO mobile app home page comes with a list of services and modules paired with icons. (Image source: GEICO) (Large preview)

This home page makes it easy for users to take advantage of their auto insurance and related services on the go. Let’s focus on the “Vehicle Trouble” section though.

There are four tabs:

  • Emergency Roadside Service represented by a tow truck icon,
  • Start a New Claim represented by a car with what looks like a crash symbol,
  • Report Glass Damage represented by a car with a crack on the windshield,
  • View Recent Claims represented by a clipboard with the letter “C” on it.

The icons aren’t all that easy to decipher (except the tow truck) and I’m just not sure they add any value here. Really, if you can’t think of anything better than putting a letter “C” on a clipboard to represent claims, maybe icons aren’t needed after all?

Next, let’s take a look at the GEICO app’s list of settings:

GEICO app navigation

The GEICO app’s navigation pairs each page with an icon. (Image source: GEICO) (Large preview)

There are a lot of settings pages here. Not only that, they’re not the kinds of pages you’d typically see in other mobile apps, so the designer has had to get creative in pairing them with icons.

If this navigation didn’t have icons, I think it would be much easier to read through the options. The same goes for the home page. Without the icons, the font size could be increased so the focus could strictly be on the page names and insured users could get to the information they need more quickly. As it stands now, the icons are just wasted space.

Let’s look at another example.

Rover is an app that pet owners can use to book pet sitting and walking services. Icons are used sparingly through the app to distinguish services from one another as well as to label the navigation pages.

Rover mobile app with icons

The Rover mobile app includes icons to label its navigation and services. (Image source: Rover) (Large preview)

I don’t think the icons on this page are necessary in terms of expediting user selection (e.g. “I need overnight house sitting so I’m going to choose the moon-over-the-house icon.”). That said, I don’t think the icons detract from the button text since each option is clearly labeled with big, bold font. What’s more, the icons do a nice job of bringing balance to the buttons so there aren’t huge white gaps in the middle.

Now, let’s look at what the designer has chosen to do under the “More” tab:

Rover app settings

Rover’s list of “More” settings don’t include icons like the rest of the app. (Image source: Rover) (Large preview)

This is similar to GEICO’s slide-out navigation menu. But notice how Rover’s is text only. Considering how common these settings are from app to app, it would’ve been easy enough to add icons to each, but the designer chose to leave them off and I think that was a good decision.

There’s a time and place when icons serve a purpose. As far as labeling a secondary navigation menu in your app, it’s time to do away with that. I’d also express caution over labeling pages with icons if it’s a struggle to find a match. That should be a sign to you that they’re not needed to begin with.

4. Excessively Long Home Pages

In web design, we’re seeing much shorter home pages than in years past, thanks to the need for more efficient mobile experiences. So, why isn’t this something we’re doing in mobile app design?

There are some apps where this isn’t an issue. Namely, ones where there’s no scrolling at all (e.g. dating apps, gaming apps, etc.). And there are some cases where endless scrolling on the home page is fine (e.g. news and social media apps).

But what about other apps?

Listings apps (like for real estate or travel) sometimes have a hard time with this. For example, this is the top of the Airbnb mobile app:

Airbnb app home page

Airbnb app home page with search bar and categories. (Image source: Airbnb) (Large preview)

This part of the page is well done and includes everything users need to find what they’re looking for:

  • A search bar,
  • A list of travel categories to swipe through,
  • Quick links to recent search queries.

But for some reason, Airbnb has designed this home page to go on and on and on with sections for:

  • Top-rated experiences,
  • Airbnb Plus places to stay,
  • Introducing Airbnb Adventures,
  • Places to stay around the world,
  • Featured Airbnb Plus destinations,
  • Stay with a superhost,
  • Unique places to stay for your next trip,
  • Explore New York City,
  • And on and on it goes.

Airbnb promotional content

Airbnb includes over a dozen sections of content on the home page of its app. (Image source: Airbnb) (Large preview)

I’m not sure what the logic was here. While I understand wanting to help your users by providing them with useful recommendations, this goes way overboard. It’s not even as though this is personalized content based on the user’s profile or recent searches. It’s just a smattering of categories that, if anything, are going to overload and overwhelm users with options.

If the app you’re building or have built runs into a similar problem, check out for inspiration: Discovery page in app

The app provides users with a search bar and recently viewed hotels upon entering the app. (Image source: (Large preview)

Unlike Airbnb,’s home “Discover” page is short. All it takes is three swipes to get to the bottom of the page. Users see sections for:

  • Recent searches,
  • A city guide (based on a recent query),
  • Last-minute deals,
  • Current bookings,
  • Rewards standings (if relevant).

For the most part, the content is 100% relevant to the user and not just meant to promote every possible service or feature of the app.

If you really feel like users would benefit from seeing every possible feature, create a secondary navigation for it. That way, they can quickly scan through the options and pick the one(s) they’re most interested in. When you give them an endless home page to scroll through and too many listings and buttons to click, you’re only going to make it harder for them to take action.

5. Dark Patterns in Ads

You have to monetize a mobile app if you’re going to make the original investment worth your while. It’s as simple as that.

But I’ve recently encountered some very scary dark patterns in mobile app monetization — specifically, with the way ads are designed. And it’s got me wondering if third-party ad networks are really the smartest way to monetize if they’re going to compromise everything you’ve done to create an awesome in-app experience otherwise.

Now, I understand that app designers usually don’t have any role in designing the ads that appear. That said, do you really think your users know anything about ad networks and how those ad placements get inside your app? Of course not!

So, when one of your users has a bad experience with an ad, what do you think is going to happen? They’re not going to think:

“Oh, that advertiser is terrible for doing that.”

Instead, they’re going to think:

“If I see one more ad like this, I’m uninstalling this app.”

Let me show you some examples of ads that will push the limits of your users’ patience.

This is Wordscapes, a gaming app I’m quite fond of:

A cutoff banner ad in Wordscapes app

A banner ad at the bottom of the Wordscapes app is cut off. (Image source: Wordscapes) (Large preview)

I’ve been playing Wordscapes for a long time and when I first started, it was great. The banner ads were there, but they never really got in the way. And the interstitial video ads only appeared every few rounds or so. They were always easy to dismiss, too.

Over the past year or so, however, the quality of ads has majorly deteriorated. Take the banner ad above. That’s actually a video ad that doesn’t fit in the allotted space.

Then, you have this badly designed banner ad for Jynarque:

Dark banner ad for Jynarque

A banner ad that’s too dark appears at the bottom of Wordscape (Image source: Wordscapes) (Large preview)

Neither of these banner ads are really dark patterns. However, they do suggest there’s something not quite right about where Wordscapes is sourcing their ad content from.

Now, I’m going to show you some of the more deceptive ads I’ve come across.

This is an ad from Showtime to promote the TV show Shameless:

Wordscapes interstitial ad for Showtime

Wordscapes shows an interstitial video ad for Showtime’s Shameless. (Image source: Wordscapes) (Large preview)

See the number “5” in the top-right corner? That’s a countdown timer, which should tell users how long they have to wait until they can dismiss the ad. However, when the timer is up, this icon appears:

Showtime ad without an exit

A Showtime ad provides users with an untraditional escape after the timer runs out. (Image source: Wordscapes) (Large preview)

The timer gets to “0” and is replaced by this button. It’s not the traditional “X” that app users are accustomed to when it comes to watching ads, so they might not realize this will take them back into the game. In fact, they might misinterpret this “Next” symbol as a “Play” button and watch the ad in full. While it’s nice that Showtime gives users an exit, it would be better if the iconography were consistent with other video ads.

Then, there’s this interstitial ad for DoorDash:

DoorDash ad with no exit

A DoorDash ad includes two fake “X” buttons. (Image source: Wordscapes) (Large preview)

This is what the ad looks like the second it appears on the screen, which is actually encouraging.

“An ad that’s going to let us exit out of it right away! Woohoo!”

But that’s not the case at all. Notice how there are two X’s in the top-right corner. One of them looks fake (the plain “X” symbol) while the other looks like an “X” you’d use to dismiss an ad.

The first time I saw this, I clicked on the good “X”, hoping my finger would be small enough to miss the fake target. Yet, this is where I ended up:

DoorDash ad to app store exit

An ad for DoorDash tries to take Wordscapes visitors to the app store (Image source: Wordscapes) (Large preview)

The click takes users out of the Wordscapes app and tries to move them to the app store. After hitting “Cancel” and sitting through five more seconds of the DoorDash ad, this new “X” appears in the top-right corner:

DoorDash deceptive mobile ad

DoorDash finally displays the real exit button for its mobile ad. (Image source: Wordscapes) (Large preview)

At this point, I can’t imagine users are very happy with DoorDash or Wordscapes for this experience.

These examples of bad ads and dark patterns in monetization are just the tip of the iceberg, too. There are ads that:

  • Provide no timer or indication of when the ad will end.
  • Switch the placement of the “X” so users unintentionally click the ad instead of leave it.
  • Auto-play sound even when the device’s sound is turned off.

I know I’m picking on Wordscapes because I spend the most time inside the app, but it’s not the only one whose reputation is being hurt by third-party ad content.

Again, I recognize that you have no say in the design or execution of ads that come from ad networks. That said, I’d really urge you to talk to your clients about being more discerning about where they source their ads from. If mobile ads continue to be this bad, it might be worth sourcing your own ad content from partners and sponsors you trust instead of random companies that use deceptive advertising tactics.

Wrapping Up

There are a ton of reasons to declutter your mobile app designs. But if these examples have demonstrated anything, the most important reason to clean up is to get rid of useless and sometimes harmful design elements or techniques.

And if you’re having a hard time getting rid of the excess, I’d encourage you to reevaluate the core product. If it’s not strong enough to stand on its own, in its simplest of forms, then it’s time to go back to the drawing board because no amount of distractions you fill it with will make it a worthwhile download for your users.

Smashing Editorial
(ra, il)

Source: Smashing Magazine, 5 Things To Stop Doing In Mobile App Design

Helping Browsers Optimize With The CSS Contain Property

dreamt up by webguru in Uncategorized | Comments Off on Helping Browsers Optimize With The CSS Contain Property

Helping Browsers Optimize With The CSS Contain Property

Helping Browsers Optimize With The CSS Contain Property

Rachel Andrew

In this article, I’m going to introduce a CSS Specification that has just become a W3C Recommendation. The CSS Containment Specification defines a single property, contain, and it can help you to explain to the browser which parts of your layout are independent and will not need recalculating if some other part of the layout changes.

While this property exists for performance optimization reasons, it can also affect the layout of your page. Therefore, in this article, I’ll explain the different types of containment you can benefit from, but also the things you need to watch out for if applying contain to elements in your site.

The Problem Of Layout Recalculation

If you are building straightforward web pages that do not dynamically add or change elements after they have loaded using JavaScript, you don’t need to worry about the problem that CSS Containment solves. The browser only needs to calculate your layout once, as the page is loaded.

Where Containment becomes useful is when you want to add elements to your page without the user needing to reload it. In my example, I created a big list of events. If you click the button, the first event is modified, a floated element is added, and the text is changed:

A listing of items with a button to change some of the content in the first item

(See the initial example on CodePen)

When the content of our box is changed, the browser has to consider that any of the elements may have changed. Browsers are in general pretty good at dealing with this, as it’s a common thing to happen. That said, as the developer, you will know if each of the components is independent, and that a change to one doesn’t affect the others, so it would be nice if you could let the browser know this via your CSS. This is what containment and the CSS contain property gives you.

How Does Containment Help?

An HTML document is a tree structure which you can see when inspecting any element with DevTools. In my example above, I identify one item that I want to change by using JavaScript, and then make some changes to the internals. (This means that I’m only changing things inside the subtree for that list item.)

DevTools with the list item of the featured item expanded to see the elements inside

Inspecting a list item in DevTools

Applying the contain property to an element tells the browser that changes are scoped to the subtree of that element, so that the browser can do any possible optimizations — safe in the knowledge that nothing else outside of that element will change. Exactly what a particular browser might do is down to the engine. The CSS property simply gives you — as the developer and expert on this layout — the chance to let it know.

In many cases, you will be safe to go right ahead and start using the contain property, however, the different values come with some potential side effects which are worth understanding before adding the property to elements in your site.

Using Containment

The contain property can set three different types of containment:

  • layout
  • paint
  • size

Note: There is a style value in the Level 2 Specification. It was removed from Level 1, so does not appear in the Recommendation, and is not implemented in Firefox.


Layout containment brings the biggest benefits. To turn on layout containment, use the following snippet:

.item {
  contain: layout;

With layout containment enabled, the browser knows that nothing outside the element can affect the internal layout, and nothing from inside the element can change anything about the layout of things outside it. This means that it can make any possible optimizations for this scenario.

A few additional things happen when layout containment is enabled. These are all things which ensure that this box and contents are independent of the rest of the tree.

The box establishes an independent formatting context. This ensures that the content of the box stays in the box — in particular floats will be contained and margins will not collapse through the box. This is the same behavior that we switch on when we use display: flow-root as in explained in my article “Understanding CSS Layout And The Block Formatting Context”. If a float could poke out of your box, causing following text to flow around the float, that would be a situation where the element was changing the layout of things outside it, making it a poor candidate for containment.

The containing box acts as the containing block for any absolutely or fixed position descendants. This means it will act as if you had used position: relative on the box you have applied contain: layout.

The box also creates a stacking context. Therefore z-index will work on this element, it’s children will be stacked based on this new context.

If we look at the example, this time with contain: layout, you can see that when the floated element is introduced it no longer pokes out the bottom of the box. This is our new Block Formatting Context in action, containing the float.

A listing of items, a floated element is contained inside the bounds of the parent box

Using contain: layout the float is contained (See the layout containment example on CodePen)


To turn on paint containment, use the following:

.item {
  contain: paint;

With paint containment enabled, the same side effects as seen with layout containment occur: The containing box becoming an independent formatting context, a containing block for positioned elements, and establishing a stacking context.

What paint containment does is indicate to the browser that elements inside the containing block will not be visible outside of the bounds of that box. The content will essentially be clipped to the box.

We can see this happen with a simple example. Even if we give our card a height, the floated item still pokes out the bottom of the box, due to the fact that the float is taken out of flow.

A floated box poking out the bottom of a containing box

The float is not contained by the list item

With paint containment turned on the floated item is now clipped to the size of the box. Nothing can be painted outside of the bounds of the element with contain: paint applied.

A box with a floated box inside which has been cut off where it escapes the box

The content of the box is clipped to the height of the box (See the paint example on CodePen)


Size containment is the value that is most likely to cause you a problem if you aren’t fully aware of how it works. To apply size containment, use:

.item {
  contain: size;

If you use size containment then you are telling the browser that you know the size of the box and it is not going to change. This does mean that if you have a box which is auto-sized in the block dimension, it will be treated as if the content has no size, therefore the box will collapse down as if it had no contents.

In the example below, I have not given the li a height; they also have contain: size applied. You can see that all of the items have collapsed as if they had no content at all, making for a very peculiar looking listing!

A listing of items with a button to change some of the content in the first item

(See the size example on CodePen)

If you give the boxes a height then the height will be respected when contain: size is used. Alone, size containment will not create a new formatting context and therefore does not contain floats and margins as layout and paint containment will do. It’s less likely that you would use it alone; instead, it is most likely you would apply it along with other values of contain to be able to get the most possible containment.

Shorthand Values

In most cases, you can use one of two shorthand values to get the best out of containment. To turn on layout and paint containment, use contain: content;, and to turn on all possible containment (keeping in mind that items which do not have a size will then collapse), use contain: strict.

The Specification says:

contain: content is reasonably “safe” to apply widely; its effects are fairly minor in practice, and most content won’t run afoul of its restrictions. However, because it doesn’t apply size containment, the element can still respond to the size of its contents, which can cause layout-invalidation to percolate further up the tree than desired. Use contain: strict when possible, to gain as much containment as you can.”

Therefore, if you do not know the size of the items in advance, and understand the fact that floats and margins will be contained, use contain: content. If you do know the size of items in addition to being happy about the other side effects of containment, use contain: strict. The rest is down to the browser, you have done your bit by explaining how your layout works.

Can I Use Containment Now?

The CSS Containment specification is now a W3C Recommendation which is what we sometimes refer to as a web standard. In order for the spec to get to this stage, there needed to be two implementations of the feature which we can see in both Firefox and Chrome:

Screenshot of the browser support information on Containment on Can I Use

Browser support for containment (Source: Can I Use)

As this property is transparent to the user, it is completely safe to add to any site even if you have lots of visitors in browsers that do not support it. If the browser doesn’t support containment then the visitor gets the experience they usually get, those in supporting browsers get the enhanced performance.

I would suggest that this is a great thing to add to any components you create in a component or pattern library, if you are working in this way it is likely each component is designed to be an independent thing that does not affect other elements on the page, making contain: content a useful addition.

Therefore, if you have a page which is adding content to the DOM after load, I would recommend giving it a try — if you get any interesting results let me know in the comments!

The following resources will give you some more detail about the implementation of containment and potential performance benefits:

Smashing Editorial

Source: Smashing Magazine, Helping Browsers Optimize With The CSS Contain Property

Beyond Sprint 0: An Alternative For Integrating Teams

dreamt up by webguru in Uncategorized | Comments Off on Beyond Sprint 0: An Alternative For Integrating Teams

Beyond Sprint 0: An Alternative For Integrating Teams

Beyond Sprint 0: An Alternative For Integrating Teams

Shamsi Brinn

Scrum is the most popular project management methodology in the world with over 72% of teams using Scrum or a scrum-hybrid. Chances are good that if you work in web development you are using Scrum in some form.

A current trend in Scrum is the “Sprint 0” or its more artsy cousin the “Design Sprint”. Much has been written about whether these are true sprints (they are not) but less has been said about why they exist in the first place, why they so stubbornly stick around, and what alternatives exist.

I personally love Scrum and I’m always on the lookout for ways to incrementally improve how I implement it. In this article, I’d like to share the methods I have incorporated into my workflow and one I find helpful when merging UX/UI and development, as well as creating stronger project visions.

A few quick definitions before we get started:

  • Sprint 0
    The initial effort of a team to create the guiding documents required for scrum projects: a vision, a product backlog, and product release estimates.
  • Design Sprint
    The initial effort of a team to create a guiding design for the rest of the release.

Why Sprint 0 And The Design Sprint Exist

It’s all well and good to say, “Sprint 0 is not a real sprint, don’t do it.” But these sprint-ish adaptations exist for a reason. Many teams adopt them because their project has an unmet need beyond the immediate scope of Scrum. My observation is that Sprint 0 and design sprints are most often used to address the following situations:

  1. Lack of a strong guiding vision;
  2. Lack of design integration into the development work flow.

The Scrum process assumes a clear vision has been developed and communicated by the product owner. But raise your hand if you’ve worked on projects where the vision is either weak, wrong, or invisible. Me too! Sprint 0 is an attempt by the development team to fill in the vision gap. It’s not the worst idea, so what’s the problem? From an agile perspective, Sprint 0 isn’t iterative, doesn’t utilize the talents of the whole team, and delivers nebulous results. And before you point out, “Hey, the real problem here is that scrum teams shouldn’t have to do the product owner’s job,” I actually believe a cross-disciplinary agile team is one of the best environments to develop a strong, realistic vision and goals.

I propose a more agile method of building vision that I’ve used successfully in no-handoff projects. I will explore both situations where these sprint-like adaptations are used and describe how this alternative first sprint better supports the agile workflow.

Vision And The Prototype Sprint

In the first situation, where there is a lack of strong vision, the guiding documentation or ideas are too weak to truly begin a Scrum project. For any process (Scrum included), you need direction before starting the journey. Agile is great for figuring out the best way to reach a goal, but generating the initial vision is not within its scope. In fact, missing from Scrum altogether is a description of the required vision for the development process to begin. Whether it’s really Scrum or not, Sprint 0 is just a web team on the front lines, using the tools they have, trying to figure out what they need to do before they start doing it.

The real drawback of Sprint 0 is that building the guiding document for the project at the time when you have the least information provides low value to the development process that follows.

Fat cat says 'Take my project vision and bring me greatness!'

Guiding project visions that don’t align with the iteratively emerging reality either need to go through the expensive process of another Sprint 0, or more often simply get ignored.

A better alternative is the prototype sprint: a first sprint that engages the entire team while actually building out the initial prototype itself.

The Prototype Sprint Vision Process

Brainstorming ideas are translated into a low visual fidelity, working prototype as quickly as possible. The prototype is written in a functional front-end HTML and CSS framework, i.e. the shared language of the team. Not everyone can understand a spec sheet or a vision statement. Everyone can understand a website and communication is easier and incorporates a wider array of disciplines.

By the end of the first sprint, the prototype is ready for initial testing across several fronts including general usability, accessibility, and mobile responsiveness. On my teams, this is a valid and important done increment. The prototype sprint also produces an initial product backlog. As backlog items get completed in future sprints the prototype gains in fidelity. The prototype is not throwaway code — it’s foundational.

In some projects, a written vision is generated as the prototype is produced. But in many projects, the prototype is the vision. It speaks in the shared language of the team and is, of course, never out of step with the product.


The example below is of a working prototype for an e-commerce app, completed from the rough outline in the initial RFP. Rough as it is, it was instrumental in focusing the team’s energies in a productive direction, leapfrogging many potential distractions and pitfalls to focus on functional criteria.

prototype of ecommerce app landing page

Landing page working prototype (Large preview)

An initial prototype will often result in changes to the requirements, which are simply best guesses until held up to the light of user experience. As an example, one of the insights we gained from the prototype sprint shown above is that the pricing and ‘buy’ button were originally much too low on the page. The initial request was to place them below product info and above recommendations, but a functional prototype quickly showed that hierarchy was not very functional.

Another functional that came to light was that the gallery images were originally requested to be large and stretch the full width of the page. Rather than laying out hypothetical reasons to stakeholders why that wouldn’t work the prototype was able to demonstrate the issues in a shared language the whole team understands. In a power session with stakeholders, we quickly reorganized this page to a universally agreed-upon hierarchy.

Because the prototype is born accessible and responsive we can begin testing on multiple devices and technologies right away. Though the design (if it can even be called that at this early stage) is intentionally kept low fidelity it was immediately apparent that the year switcher messaging on desktop was too big on mobile and interfering with usability (left). We quickly updated the prototype to use a smaller switcher in the header (right).

Working prototype of mobile landing page with changes to mobile switcher

Mobile landing page with changes to mobile switcher (Large preview)

A few other issues came quickly to light during this prototype sprint:

  • The client, after clicking through the functional navigation, immediately realized they had missed a major functional component in their spec: a blog. This affected the estimate and timing but we were able to adjust quickly.
  • It was evident to the UI team that the pricing display was overly complex and confusing. We explored other possibilities with the client and were able to rapidly prototype and user test several solutions during the prototype sprint.

Instead of the vision potentially being an impediment or becoming outdated as soon as development begins, in a prototype sprint the vision and functional criteria are developed together and support one another. And because the vision is generated by the team there is no handoff to the team and handily avoids that risky period in the development process.

Design And The Prototype Sprint

In the second situation — a lack of integration of design with development — is often when you will see a “design sprint” used. I find this direction even more counterproductive than a Sprint 0. The challenges of integrating design into a complex development process are real but a design sprint is a self-defeating approach. The design sprint is a bandaid for the symptom — the challenge of building integrated teams — but doesn’t address the underlying issue — the challenge of understanding and meeting user needs. Front-loading design into one sprint avoids the challenge of integration, but the benefits of an integrated and incremental design process and the window it opens to understanding and reaching users is entirely lost.

The prototype sprint I use in no-handoff projects is a productive and fully agile alternative to the design sprint. It is collaborative and merges both UI/UX and development from the earliest stages of the project. Even the most experienced design team can benefit from the involvement of other disciplines and, critically, it ensures code and design goals are not at cross-purposes.

Unlike this photo of fighting cats, code and design goals should be aligned and support the project vision.

Often the design sprint is also expected to flesh out vision. This is a desperate move based on a vague but insightful understanding that the design process is better equipped to generate vision than development. However, a design-generated vision is a poor substitute for a real, collaborative, team-wide effort.

The poor designers are saddled with generating an end product to kickstart development without the cross-disciplinary information necessary to make that effort truly valuable. Though a designer with technical knowledge and more experience will have a better chance of getting this right it is still very risky. With no potentially shippable product at the end of the phase to test against the guesswork continues into development. If the design didn’t hit the mark, or if the specs change, it can result in long delays as it goes back to the design team. Agile is at its core a risk management process, and we can do better than starting our agile projects with an inherently risky design sprint.

The Prototype Sprint Design Process

The most important change from a more traditional design sprint is that during the prototype sprint the team goes straight from paper to the prototype and skips the use of Sketch, InVision, Photoshop, or other digital layout programs. They act as a visual crutch at this stage, appearing to introduce value very quickly (because good designers make good-looking things), but the real value of a high-fidelity mockup this early is very low, while the potential danger it introduces — wedding stakeholders to the wrong solutions — is high.

These tools are best at high-fidelity flat mockups but the initial prototype is neither high fidelity nor flat. Whiteboard and pencil and paper let the teamwork through ideas quickly without being wedded to them. Then get that thinking into a functional prototype as soon as possible.

Every team member, including designers, should become familiar with and be able to work on the prototype directly during lo-fi phases. But if that’s not possible (or it’s a longer-term goal and you need to move forward now), then a paired approach where a designer and developer work side by side is good. Sketches can be described by the designer and interpreted by the developer together, broadening their shared understanding of each viewpoint.


The example below shows our process distilling an in-depth analysis of an existing website directly into a functional prototype. It allowed the findings of the report to be evaluated in a native web setting, a very different experience from intellectually analyzing recommendations in a print document:

Analysis of resource site and resulting working prototype

Resource site analysis and resulting prototype (Large preview)

Also, unlike the in-depth analysis document (as helpful as it was) the functional prototype is free from jargon and uses a shared verbal and visual language that everyone can understand. It opens the conversation on visual display to all team members and disciplines.

Our main question while building this template was how much design detail to include. Because we had a rich document full of analysis to draw from we could have taken the prototype further. But, keeping in mind that visuals can quickly (and unintentionally) move from the realm of idea to the realm of fact, we kept the layout non-committal and distilled the document to just its essential elements and meaning.

Internal testing got us into the ballpark of a more user-focused solution, leapfrogging over many potential issues, but we consciously avoided making any refined design decisions this early in the process. It’s important to continually weigh all ideas and suggestions, including the client’s, against known data and to remember that our pool of knowledge is smaller at this point than it will be at any other stage of the project.

Another reason it’s critical to keep the initial prototype lo-fi and not include any “design” elements is that team buy-in can be derailed by irrelevant visual elements that elicit unintended visceral reactions. We stay away from color and don’t even include the client logo (instead use a blank space or a light gray box as a placeholder). The conversation must be continually guided towards functional criteria like content hierarchy, accessibility, usability, language, and meaning. Reassure the team that the “fun stuff” will come but not at this early stage.

In fact, an important goal of a successful prototype sprint is to make as little upfront design decisions as possible. Successful design is fed by user experience so allow time for emerging project knowledge to inform the UI.

When Is The Prototype Sprint Complete

The sprint is complete when the prototype and accompanying artifacts are approved by the full team (including the client), and the prototype is deemed ready for initial usability and accessibility testing.

An early functional prototype brings to life the project vision through scale (number of pages, scope of navigation and other main UI elements), future complexity (placeholder content with useful descriptors, possibly some early functionality coded), and identifying needs (specific technologies needed, where they will be deployed, any dependencies). Decisions regarding tools, working environment, and code stack will be made with the input of the entire team.

Reaching this done increment can take as little as one day for a seasoned team with a responsive client but typically lasts about one week and no more than two weeks. Prototype sprints should move at a quick pace and going over the two-week time frame can be a red flag. It may mean there are other issues at play.

Some Common Issues To Look Out For During A Prototype Sprint

A few common issues to look out for when implementing the prototype sprint include:

  • Embrace the value of low fidelity and avoid emphasis on the visuals. Be vigilant about this point as teams who are new to this approach might need help and reassurance as they move beyond “where’s the logo” and focus on deeper questions of functionality and hierarchy.
  • A different facet of the above, also be vigilant about not getting attached to your own design/layout ideas. It’s helpful to remember during prototype sprints that nothing precious is being generated and to remain detached from the end results. Also, its yet another reason to keep the prototypes minimal and, frankly, rather ugly. It serves the purpose of keeping users detached.
  • Early process buy-in from leadership is critical. Because the entire team is involved your client, your boss, and the developers all need to support and nurture the process with their engagement, creativity, and time. Don’t be a lone cheerleader, your whole team needs to wave their pom-poms!
  • Poor communication is the Achilles heel of all teamwork. The prototype sprint won’t solve persistent communication issues but it will bring them to the fore sooner as the entire team dives into a collaborative workflow almost immediately. Any already existing communication issues will come up early and often in a prototype sprint as you work towards consensus and your first done increment. Embrace the opportunity for improving communication and engage the whole team in finding solutions.
  • Pick the right front-end framework. If you don’t have one already you might need to try out various front end frameworks before you find one that clicks with your team’s workflow. I recommend looking into minimal frameworks like Fomantic or Bulma and not getting bogged down by bells and whistles. However, the right framework is always the one that works for your team.
  • The UI/UX team needs to develop a comfort level with and access to the front end framework. Ideally, they will work directly on the prototype, avoiding unnecessary handoff and the need for translation from one medium to another (i.e. from Sketch to the prototype). If your front-end team do not have familiarity with CSS and HTML, then a paired approach (with one designer and one programmer working together on the framework) also works well.
  • Last but not least, remember that you’ll get better and faster as a team! Running a productive prototype sprint is a skill that grows with practice.

What Happens Next

The done increment of the first sprint — the functional, low fidelity prototype — sets the stage for all the sprints that follow. With a working prototype user testing for usability, accessibility, and responsiveness can begin right away, ensuring future sprints are informed by UX.

The prototype sprint is a great start to any scrum process, but in my projects, our next step is to move to a dual-track workflow where UI/UX works a half or whole sprint ahead of development doing discovery and visually updating the prototype to reflect new insights.

In a dual-track agile process the design and development teams continually feed into and draw from each other’s work.

(Large preview)

The prototype organically develops and becomes increasingly more refined, fed by UX research and realistic functional needs. That information, not available during the prototype sprint, only incrementally emerges as the project progresses. UI/UX and development feed into each other’s workflows through the dual-track agile process.

There is no handoff of design to development to be built, or a developed app to design to skin. Instead, the prototype sprint engages the entire group from the start and forms a strong foundation for a collaborative agile workflow throughout the project.

The guiding vision that results from a prototype sprint won’t be perfect and will likely change as more is learned, but the recognition that we know less at the beginning than at any other phase of a project is at the heart of the agile workflow. When we apply this same philosophy to the emergence of the project vision and design through a prototype sprint what results is an actionable done increment, genuinely useful artifacts, shared buy-in, and a pattern of teamwork and collaboration that can be sustained throughout the project.

A Note About Agency Settings

If you work at an agency you might be thinking this approach will be a hard sell. Unfortunately, you are probably right. Many agencies are inherently un-agile and actively strive for total project handoff, often with official signoff and carefully documented repercussions to making changes down the road. Advocating for a prototype sprint in a non-agile organization is a non-starter: it’s just not in their DNA. Once an organization embraces agile and cross-discipline teams then they can easily consider if the no-handoff prototype sprint will enhance their process.


Sprint 0 and design sprints address real challenges many scrum teams face: lack of vision, lack of integrated design, or both. They are understandable and logical responses, but they don’t provide high value or contribute to strong agile teams.

Replacing them with a prototype sprint is a practical way to address the drawbacks of Sprint 0 and design sprints while simultaneously laying the groundwork for stronger agile collaboration during future sprints.

A prototype sprint utilizes the talents of the entire team, generates the necessary vision, results in the team’s first done increment, and avoids project handoff. Through this process, teams build shared ownership of the project vision and a stronger foundation for cross-disciplinary cooperation in the agile spirit.

Further Reading on SmashingMag:

Smashing Editorial
(cc, yk, il)

Source: Smashing Magazine, Beyond Sprint 0: An Alternative For Integrating Teams

Creating Voice Skills For Google Assistant And Amazon Alexa

dreamt up by webguru in Uncategorized | Comments Off on Creating Voice Skills For Google Assistant And Amazon Alexa

Creating Voice Skills For Google Assistant And Amazon Alexa

Creating Voice Skills For Google Assistant And Amazon Alexa

Tris Tolliday

Over the past decade, there has been a seismic shift towards conversational interfaces. As people reach ‘peak screen’ and even begin to scale back their device usage with digital wellbeing features being baked into most operating systems.

To combat screen fatigue, voice assistants have entered the market to become a preferred option for quickly retrieving information. A well-repeated stat states that 50% of searches will be done by voice in year 2020. Also, as adoption rises, it’s up to developers to add “Conversational Interfaces” and “Voice Assistants” to their tool belt.

Designing The Invisible

For many, embarking on a voice UI (VUI) project can be a bit like entering the Unknown. Find out more about the lessons learned by William Merrill when designing for voice. Read article →

What Is A Conversational Interface?

A Conversational Interface (sometimes shortened to CUI, is any interface in a human language. It is tipped to be a more natural interface for the general public than the Graphic User Interface GUI, which front end developers are accustomed to building. A GUI requires humans to learn its specific syntaxes of the interface (think buttons, sliders, and drop-downs).

This key difference in using human language makes CUI more natural for people; it requires little knowledge and puts the burden of understanding on the device.

Commonly CUIs comes in two guises: Chatbots and Voice Assistants. Both have seen a massive rise in uptake over the last decade thanks to advances in Natural Language Processing (NLP).

Understanding Voice Jargon

(Large preview)
Keyword Meaning
Skill/Action A voice application, which can fulfill a series of intents
Intent Intended action for the skill to fulfill, what the user wants the skill to do in response to what they say.
Utterance The sentence a user says, or utters.
Wake Word The word or phrase used to start a voice assistant listening, e.g. ‘Hey google’, ‘Alexa’ or ‘Hey Siri’
Context The pieces of contextual information within an utterance, that helps the skill fulfill an intent, e.g. ‘today’, ‘now’, ‘when I get home’.

What Is A Voice Assistant?

A voice assistant is a piece of software capable of NLP (Natural Language Processing). It receives a voice command and returns an answer in audio format. In recent years the scope of how you can engage with an assistant is expanding and evolving, but the crux of the technology is natural language in, lots of computation, natural language out.

For those looking for a bit more detail:

  1. The software receives an audio request from a user, processes the sound into phonemes, the building blocks of language.
  2. By the magic of AI (Specifically Speech-To-Text), these phonemes are converted into a string of the approximated request, this is kept within a JSON file which also contains extra information about the user, the request and the session.
  3. The JSON is then processed (usually in the cloud) to work out the context and intent of the request.
  4. Based on the intent, a response is returned, again within a larger JSON response, either as a string or as SSML (more on that later)
  5. The response is processed back using AI (naturally the reverse – Text-To-Speech) which is then returned to the user.

There’s a lot going on there, most of which don’t require a second thought. But each platform does this differently, and it’s the nuances of the platform that require a bit more understanding.

(Large preview)

Voice-Enabled Devices

The requirements for a device to be able to have a voice assistant baked in are pretty low. They require a Microphone, an internet connection, and a Speaker. Smart Speakers like the Nest Mini & Echo Dot provide this kind of low-fi voice control.

Next up in the ranks is voice + screen, this is known as a ‘Multimodal’ device (more on these later), and are devices like the Nest Hub and the Echo Show. As smartphones have this functionality, they can also be considered a type of Multimodal voice-enabled device.

Voice Skills

First off, every platform has a different name for their ‘Voice Skills’, Amazon goes with skills, which I will be sticking with as a universally understood term. Google opts for ‘Actions’, and Samsung goes for ‘capsules’.

Each platform has its own baked-in skills, like asking the time, weather and sports games. Developer-made (third-party) skills can be invoked with a specific phrase, or, if the platform likes it, can be implicitly invoked, without a key phrase.

Explicit Invocation: ”Hey Google, Talk to <app name>.”

It is explicitly stated which skill is being asked for:

Implicit Invocation: ”Hey Google, what is the weather like today?”

It is implied by the context of the request what service the user wants.

What Voice Assistants Are There?

In the western market, voice assistants are very much a three-horse race. Apple, Google and Amazon have very different approaches to their assistants, and as such, appeal to different types of developers and customers.

Apple’s Siri

Device Names: ”Google Home, Nest”

Wake Phrase: ”Hey Siri”

Siri has over 375 million active users, but for the sake of brevity, I am not going into too much detail for Siri. While it may be globally well adopted, and baked into most Apple devices, it requires developers to already have an app on one of Apple’s platforms and is written in swift (whereas the others can be written in everyone’s favorite: Javascript). Unless you are an app developer who wants to expand their app’s offering, you can currently skip past apple until they open up their platform.

Google Assistant

Device Names: ”Google Home, Nest”

Wake Phrase: ”Hey Google”

Google has the most devices of the big three, with over 1 Billion worldwide, this is mostly due to the mass of Android devices that have Google Assistant baked in, with regards to their dedicated smart speakers, the numbers are a little smaller. Google’s overall mission with its assistant is to delight users, and they have always been very good at providing light and intuitive interfaces.

Their primary aim on the platform is to use time — with the idea of becoming a regular part of customers’ daily routine. As such, they primarily focus on utility, family fun, and delightful experiences.

Skills built for Google are best when they are engagement pieces and games, focusing primarily on family-friendly fun. Their recent addition of canvas for games is a testament to this approach. The Google platform is much stricter for submissions of skills, and as such, their directory is a lot smaller.

Amazon Alexa

Device Names: “Amazon Fire, Amazon Echo”

Wake Phrase: “Alexa”

Amazon has surpassed 100 million devices in 2019, this predominantly comes from sales of their smart speakers and smart displays, as well as their ‘fire’ range or tablets and streaming devices.

Skills built for Amazon tend to be aimed at in skill purchasing. If you are looking for a platform to expand your e-commerce/service, or offer a subscription then Amazon is for you. That being said, ISP isn’t a requirement for Alexa Skills, they support all sorts of uses, and are much more open to submissions.

The Others

There are even more Voice assistants out there, such as Samsung’s Bixby, Microsoft’s Cortana, and the popular open-source voice assistant Mycroft. All three have a reasonable following, but are still in the minority compared to the three Goliaths of Amazon, Google and Apple.

Building On Amazon Alexa

Amazons Ecosystem for voice has evolved to allow developers to build all of their skills within the Alexa console, so as a simple example, I am going to use its built-in features.

(Large preview)

Alexa deals with the Natural Language Processing and then finds an appropriate Intent, which is passed to our Lambda function to deal with the logic. This returns some conversational bits (SSML, text, cards, and so on) to Alexa, which converts those bits to audio and visuals to show on the device.

Working on Amazon is relatively simple, as they allow you to create all parts of your skill within the Alexa Developer Console. The flexibility is there to use AWS or an HTTPS endpoint, but for simple skills, running everything within the Dev console should be sufficient.

Let’s Build A Simple Alexa Skill

Head over to the Amazon Alexa console, create an account if you don’t have one, and log in,

Click Create Skill then give it a name,

Choose custom as your model,

and choose Alexa-Hosted (Node.js) for your backend resource.

Once it is done provisioning, you will have a basic Alexa skill, It will have your intent built for you, and some back end code to get you started.

If you click on the HelloWorldIntent in your Intents, you will see some sample utterances already set up for you, let’s add a new one at the top. Our skill is called hello world, so add Hello World as a sample utterance. The idea is to capture anything the user might say to trigger this intent. This could be “Hi World”, “Howdy World”, and so on.

What’s Happening In The Fulfillment JS?

So what is the code doing? Here is the default code:

const HelloWorldIntentHandler = {

    canHandle(handlerInput) {

        return Alexa.getRequestType(handlerInput.requestEnvelope) === 'IntentRequest'

            && Alexa.getIntentName(handlerInput.requestEnvelope) === 'HelloWorldIntent';


    handle(handlerInput) {

        const speakOutput = 'Hello World!';

        return handlerInput.responseBuilder





This is utilizing the ask-sdk-core and is essentially building JSON for us. canHandle is letting ask know it can handle intents, specifically ‘HelloWorldIntent’. handle takes the input, and builds the response. What this generates looks like this:


    "body": {

        "version": "1.0",

        "response": {

            "outputSpeech": {

                "type": "SSML",

                "ssml": "Hello World!"


            "type": "_DEFAULT_RESPONSE"


        "sessionAttributes": {},

        "userAgent": "ask-node/2.3.0 Node/v8.10.0"



We can see that speak outputs ssml in our json, which is what the user will hear as spoken by Alexa.

Building For Google Assistant

(Large preview)

The simplest way to build Actions on Google is to use their AoG console in combination with Dialogflow, you can extend your skills with firebase, but as with the Amazon Alexa tutorial, let’s keep things simple.

Google Assistant uses three primary parts, AoG, which deals with the NLP, Dialogflow, which works out your intents, and Firebase, that fulfills the request, and produces the response that will be sent back to AoG.

Just like with Alexa, Dialogflow allows you to build your functions directly within the platform.

Let’s Build An Action On Google

There are three platforms to juggle at once with Google’s solution, which are accessed by three different consoles, so tab up!

Setting Up Dialogflow

Let’s start by logging into the Dialogflow console. Once you have logged in, create a new agent from the dropdown just below the Dialogflow logo.

Give your agent a name, and add on the ‘Google Project Dropdown’, while having “Create a new Google project” selected.

Click the create button, and let it do its magic, it will take a little bit of time to set up the agent, so be patient.

Setting Up Firebase Functions

Right, now we can start to plug in the Fulfillment logic.

Head on over to the Fulfilment tab. Tick to enable the inline editor, and use the JS snippets below:


'use strict';

// So that you have access to the dialogflow and conversation object
const {  dialogflow } = require('actions-on-google'); 

// So you have access to the request response stuff >> functions.https.onRequest(app)
const functions = require('firebase-functions');

// Create an instance of dialogflow for your app
const app = dialogflow({debug: true});

// Build an intent to be fulfilled by firebase, 
// the name is the name of the intent that dialogflow passes over
app.intent('Default Welcome Intent', (conv) => {
  // Any extra logic goes here for the intent, before returning a response for firebase to deal with
    return conv.ask(`Welcome to a firebase fulfillment`);

// Finally we export as dialogflowFirebaseFulfillment so the inline editor knows to use it
exports.dialogflowFirebaseFulfillment = functions.https.onRequest(app);


  "name": "functions",
  "description": "Cloud Functions for Firebase",
  "scripts": {
    "lint": "eslint .",
    "serve": "firebase serve --only functions",
    "shell": "firebase functions:shell",
    "start": "npm run shell",
    "deploy": "firebase deploy --only functions",
    "logs": "firebase functions:log"
  "engines": {
    "node": "10"
  "dependencies": {
    "actions-on-google": "^2.12.0",
    "firebase-admin": "~7.0.0",
    "firebase-functions": "^3.3.0"
  "devDependencies": {
    "eslint": "^5.12.0",
    "eslint-plugin-promise": "^4.0.1",
    "firebase-functions-test": "^0.1.6"
  "private": true

Now head back to your intents, go to Default Welcome Intent, and scroll down to fulfillment, make sure ‘Enable webhook call for this intent’ is checked for any intents your wish to fulfill with javascript. Hit Save.

(Large preview)

Setting Up AoG

We are getting close to the finish line now. Head over to the Integrations Tab, and click Integration Settings in the Google Assistant Option at the top. This will open a modal, so let’s click test, which will get your Dialogflow integrated with Google, and open up a test window on Actions on Google.

On the test window, we can click Talk to my test app (We will change this in a second), and voila, we have the message from our javascript showing on a google assistant test.

We can change the name of the assistant in the Develop tab, up at the top.

So What’s Happening In The Fulfillment JS?

First off, we are using two npm packages, actions-on-google which provides all the fulfillment that both AoG and Dialogflow need, and secondly firebase-functions, which you guessed it, contains helpers for firebase.

We then create the ‘app’ which is an object that contains all of our intents.

Each intent that is created passed ‘conv’ which is the conversation object Actions On Google sends. We can use the content of conv to detect information about previous interactions with the user (such as their ID and information about their session with us).

We return a ‘conv.ask object’, which contains our return message to the user, ready for them to respond with another intent. We could use ‘conv.close’ to end the conversation if we wanted to end the conversation there.

Finally, we wrap everything up in a firebase HTTPS function, that deals with the server-side request-response logic for us.

Again, if we look at the response that is generated:


  "payload": {

    "google": {

      "expectUserResponse": true,

      "richResponse": {

        "items": [


            "simpleResponse": {

              "textToSpeech": "Welcome to a firebase fulfillment"








We can see that conv.ask has had its text injected into the textToSpeech area. If we had chosen conv.close the expectUserResponse would be set to false and the conversation would close after the message had been delivered.

Third-Party Voice Builders

Much like the app industry, as voice gains traction, 3rd party tools have started popping up in an attempt to alleviate the load on developers, allowing them to build once deploy twice.

Jovo and Voiceflow are currently the two most popular, especially since PullString’s acquisition by Apple. Each platform offers a different level of abstraction, so It really just depends on how simplified you’re like your interface.

Extending Your Skill

Now that you have gotten your head around building a basic ‘Hello World’ skill, there are bells and whistles aplenty that can be added to your skill. These are the cherry on top of the cake of Voice Assistants and will give your users a lot of extra value, leading to repeat custom, and potential commercial opportunity.


SSML stands for speech synthesis markup language and operates with a similar syntax to HTML, the key difference being that you are building up a spoken response, not content on a webpage.

‘SSML’ as a term is a little misleading, it can do so much more than speech synthesis! You can have voices going in parallel, you can include ambiance noises, speechcons (worth a listen to in their own right, think emojis for famous phrases), and music.

When Should I Use SSML?

SSML is great; it makes a much more engaging experience for the user, but what is also does, is reduce the flexibility of the audio output. I recommend using it for more static areas of speech. You can use variables in it for names etc, but unless you intend on building an SSML generator, most SSML is going to be pretty static.

Start with simple speech in your skill, and once it is complete, enhance areas which are more static with SSML, but get your core right before moving on to the bells and whistles. That being said, a recent report says 71% of users prefer a human (real) voice over a synthesized one, so if you have the facility to do so, go out and do it!

(Large preview)

In Skill Purchases

In-skill purchases (or ISP) are similar to the concept of in-app purchases. Skills tend to be free, but some allow for the purchase of ‘premium’ content/subscriptions within the app, these can enhance the experience for a user, unlock new levels on games, or allow access to paywalled content.


Multimodal responses cover so much more than voice, this is where voice assistants can really shine with complementary visuals on devices that support them. The definition of multimodal experiences is much broader and essentially means multiple inputs (Keyboard, Mouse, Touchscreen, Voice, and so on.).

Multimodal skills are intended to complement the core voice experience, providing extra complementary information to boost the UX. When building a multimodal experience, remember that voice is the primary carrier of information. Many devices don’t have a screen, so your skill still needs to work without one, so make sure to test with multiple device types; either for real or in the simulator.

(Large preview)


Multilingual skills are skills that work in multiple languages and open up your skills to multiple markets.

The complexity of making your skill multilingual is down to how dynamic your responses are. Skills with relatively static responses, e.g. returning the same phrase every time, or only using a small bucket of phrases, are much easier to make multilingual than sprawling dynamic skills.

The trick with multilingual is to have a trustworthy translation partner, whether that is through an agency or a translator on Fiverr. You need to be able to trust the translations provided, especially if you don’t understand the language being translated into. Google translate will not cut the mustard here!


If there was ever a time to get into the voice industry, it would be now. Both in its prime and infancy, as well as the big nine, are plowing billions into growing it and bringing voice assistants into everybody’s homes and daily routines.

Choosing which platform to use can be tricky, but based on what you intend to build, the platform to use should shine through or, failing that, utilize a third-party tool to hedge your bets and build on multiple platforms, especially if your skill is less complicated with fewer moving parts.

I, for one, am excited about the future of voice as it becomes ubiquitous; screen reliance will reduce and customers will be able to interact naturally with their assistant. But first, it’s up to us to build the skills that people will want from their assistant.

Smashing Editorial
(dm, il)

Source: Smashing Magazine, Creating Voice Skills For Google Assistant And Amazon Alexa

Smashing Monthly Roundup: What’s New?

dreamt up by webguru in Uncategorized | Comments Off on Smashing Monthly Roundup: What’s New?

Smashing Monthly Roundup: What’s New?

Smashing Monthly Roundup: What’s New?

Iris Lješnjanin

With the year slowly coming to an end, now is probably a great time to slow down and be mindful. Look back, reflect, breathe. It’s been a long year for all of us, so why not make yourself a good cuppa coffee or tea (whatever your preference is, there are other options, of course), and think about what your personal highlights were and set out some hopes and goals for the upcoming year to come.

Advent calendarsWe enjoyed counting down the days of 2019 with a good number of creative advent calendars that were brought to life by some quite talented folks. Some are publishing traditional articles while others have thought of a challenge for each day of the month of December. You can follow the lovely projects via their RSS feeds (if available) and Twitter accounts to make it easy for you to keep track of your favorites.

With the holidays coming up, why not get yourself cozy and catch up with a few talks? We have a whole lot of videos that you may like watching and listening to:

Photo of Sara SoueidanSara Soueidan presented a talk on Applied Accessibility in SmashingConf NYC, and Marcy Sutton spoke about Garbage Components. In case you’d like to follow along more closely, you’ll find the talk slides and some helpful links on the SmashingConf website, as well as some lovely snapshots of the event.

If you’re already planning which events to attend next year, we have an oveview of upcoming conferences around the globe that you may want to check out, and if you’re eager not to miss out on one of our SmashingConfs, then super early-bird SmashingConf tickets are already available! Just sayin’! 😉

What’s New At Smashing?

Smashing Podcast moderated by Drew McLellanIn case you missed it, we launched the Smashing Podcast just a few weeks ago — a bi-weekly podcast that is moderated by our dear friend and colleague, Drew McLellan. There are already 5 podcasts to listen to, so join him as he chats to Jina Anne about design tokens, Heydon Pickering on inclusive components, and Jason Pamental on all things variable fonts. You can subscribe and tune into any podcast player of your choice!

Inclusive Components book cover

Also, we officially released the “Inclusive Components” book, and the response has been overwhelmingly positive! Ari Stiles collected some of the book reviews we’ve received so far, with more coming in each day! Grab your own copy of Heydon’s book, and let us know what you think — we’d love to hear from you!

We publish a new article every day, and so if you’re not subscribed to our RSS feed or follow us on social media, you may miss out on some brilliant articles! Here are some that our readers seemed to enjoy and recommend further:

Best Picks From Our Newsletter

We’ll be honest: Every second week, we struggle with keeping the Smashing Newsletter issues at a moderate length — there are just so many talented folks out there working on brilliant projects! So, without wanting to make this monthly update too long either, we’re shining the spotlight on the following projects:

Note: A thank you to Cosima Mielke for writing and preparing these posts!

Web Almanac 2019

Take data processed from nearly 6 million websites and 85 people volunteering countless hours planning, researching, and writing — that’s what it took to create the 2019 edition of the Web Almanac, HTTP Archive’s annual state of the web report.

Illustration showing little characters made up of geometrical forms painting a website.


The report consists of 20 chapters spanning aspects of page content, user experience, publishing, and distribution to shine a light on the current state of the ever-evolving network of technology that the open web is. A great resource to become more aware of current best practices.

How To Read A WebPage Test Waterfall Chart

Do you have difficulties reading WebPageTest waterfall charts? You’re not alone, it can be quite a challenge to remember the details and what they all mean. To freshen up your knowledge, Matt Hobbs collected all the many bits of information in a single blog post that we all can refer to.

WebPageTest timeline and chart


The post explains the basic layout of the waterfall chart, what each of the colored vertical lines means, and what metrics the horizontal blocks refer to. It also lists common patterns that you might stumble upon in a waterfall chart. One for the bookmarks.

Open-Source Illustrations Kit

100-day challenges are a wonderful opportunity to dive deep into a topic or craft and evolve and improve with each day. Back in 2016, Vijay Verma spent almost two hours a day for 100 days designing, illustrating, and experimenting to get himself to the next level of illustration.

A screenshot of open-source illustrations available


After living on a harddrive untouched since then, Vijay now decided to release the illustrations as a free open-source illustrations kit so you can use them for your landing pages, mobile apps, presentations, or whatever else comes to your mind. Available in AI, SVG, PNG, and EPS formats. Thank you, Vijay, for sharing!

30 Days Of Code Tidbits

Who doesn’t love a bite-sized tip? One that doesn’t take long to swallow but teaches you something new to instantly ease your life as a developer? Using the hashtag #codetidbits30 on Twitter, Samantha Ming posts a new coding tidbit every day in December.

Code tidbit explaining how to merge arrays


Three ways to remove array duplicates, a little trick to style elements that have no children or text at all, and a solution for displaying your data in your browser dev tools, these are only some of the tips in the series. Covering JavaScript, HTML, and CSS snippets, #codetidbits30 is a true treasure chest of front-end goodies. Be sure to follow along.

Scaling SVGs Made Simple

Scaling <svg> elements can be a daunting task, since they act very differently than normal images. Amelia Wattenberger came up with an ingenious comparison to help us make sense of SVGs and their special features: “The <svg> element is a telescope into another world.”

A person looking through a telescope watching a star shape


Based on the idea of the telescope, Amelia explains how to use the viewBox property to zoom in or out with your “telescope”, and, thus, change the size of your <svg>. A small tip that works wonders.

Recreating Print Layouts With CSS

When it comes to creative layouts, magazines are an endless source of inspiration. And thanks to CSS Grid, there’s nothing to hold you back from bringing more sophisticated layouts to the web, too.

Layout for an article abou the Dutch soccer player Virgil Van Dijk


Inspired by magazine layouts, their use of typography and their structures, Dan Davies took on the challenge to recreate some of the print work he liked on the web. The result is an awe-inspiring collection of nine layouts that use the potential of CSS Grid to its fullest. Beautifully art-directed and responsive, they are great examples of pushing the limits of what’s possible on the web layout-wise.

Web Performance Vs. User Engagement

It’s no secret that performance can have a positive impact on user engagement and, in effect, improve conversion. To find out how performance correlates to conversion for their product, the team at Vrbo implemented an automated process that shows the connection between business events and performance data.

A screenshot of the holy grail dashboard created at Vrbo


Carlos Moro from Vrbo now shares a case study in which he gives more insights into the approach, as well as handy tips for measuring site performance, user engagement, and putting the two into relation to one another. Interesting.

Time-Travel-Debugging For The Web

An early Firefox DevTools experiment that is worth keeping an eye on is Web Replay. Web Replay records your actions so you can track bugs down faster and understand your code better — a collaborative time-travel debugging instrument, so to say.

Replay in Firefox DevTools


The replaying process preserves all the same JS behavior, DOM structures, graphical updates, and most other behavior that occurred while recording. Want to give it a try? Replay is already available in Firefox Nightly for macOS (still disabled by default until it is more stable, but you can turn it on manually). Handy!

Commit-Message-Driven Development

Have you ever considered to write the commit message before you start writing the code? Sven Hofmann does it this way, and now he explains why you could give it a try, too.

Bash functions incorporating commit-message-driven development into a developer’s workflow.


We all know those vague and messy commit messages like “bugfixes and minor improvements” that aren’t helpful in the long term — especially if you’re working with a team or on an open-source project. The commit-message-driven workflow that Sven suggests could help change that: first, you write the commit message, then the code, then you commit. Having the scope of the task nailed down in advance, gives each commit a precise goal that you can focus on and that makes it easier to review your commits later on. Clever!

Dealing With Ads In 2020

Ads are a two-sided sword: nobody really likes them but a lot of sites depend on them to generate revenue. Working for a news company that is dependent on ads, Christian Schaefer wanted to find ways to minimize their impact and make them less annoying. Now he summarized his approach in a comprehensive blog post.

Screenshot from the “Dealing with Ads in 2020” blog post


The post shares valuable insights into how Christian and his team developed a generic solution to transform and combine mobile and desktop ad code into one responsive ad loading code, how they improved performance by lazy loading the ads, what they did to prevent the ads from breaking the site’s layout, and some other things that add up to bringing the front end into a much better position when dealing with ads. Great tips for everyone who finds themselves wrangling ads.

If you don’t get our newsletter yet, then sign up here to receive useful techniques and goodies (including a free eBook on accessibility)!

From Smashing With Love

A month can be a long time to stay on top of things, so please do subscribe to our bi-weekly newsletter and our podcast if you still haven’t. Each and every issue is written and edited with love and care. No third-party mailings or hidden advertising — promise!

You can also tune into our very own Smashing TV, and follow us on Twitter, Facebook as well as LinkedIn. Please do always feel free to reach out and share your projects with us! We love hearing from you!

On behalf of the entire team, we wish you all the best for 2020! Stay smashing! 😉

Smashing Editorial
(cm, vf, ra, il)

Source: Smashing Magazine, Smashing Monthly Roundup: What’s New?