Smashing Magazine Is Thirteen!

Rachel Andrew

2019-09-06T12:00:59+02:002019-09-07T08:07:12+00:00

This week, Smashing Magazine turned thirteen years old. The web has changed a lot since Vitaly posted his first article back in 2006. The team at Smashing has changed too, as have the things that we bring to our community — with conferences, books, and our membership added to the online magazine.

One thing that hasn’t changed is that we’re a small team — with most of us not working fulltime for Smashing. Many in the team, however, have been involved with the magazine since the early days. You may not know them by name, but you will have enjoyed and benefited from their work. I enjoyed finding out what everyone gets up to outside of Smashing, and also how they came to be involved — I hope that you will, too.

Vitaly Friedman is the person you probably think of when you think of Smashing Magazine, and rightfully so. He posted his first article to the site on September 2nd, 2006. When asked what he likes to do outside of Smashing, he says,

“I’m a big fan of hiking, running, ironing and fruits! For me, ironing shirts is really like meditation — and I also loooooove music festivals (which is something most people don’t know about me as I tend to be quite obscure about that).”

Vitaly has done pretty much everything at Smashing at one time or another — web developer, writer, editor, designer, creative lead and curator. These days, he helps to keep us all on track with his vision for all of the Smashing things, and always has some new ideas! Vitaly (originally from Belarus) travels as much as I do, our company standups usually involve us reporting our current and next location and timezone! As you’ll discover, however, while Smashing Magazine is a German company, the team lives — or has roots — all over the world.

Iris Lješnjanin is our senior editor on the magazine, and does an amazing job maintaining communication between our many authors, editors, and reviewers. She also does the majority of the subediting work on the magazine, trying to maintain the individual voices of our authors while ensuring the articles are easy to read for our worldwide audience. She has been part of Smashing since 2010, helping to develop the brand, mentoring in-house interns, and developing the process for working with authors and editors that keeps our daily publishing schedule rolling!

Iris grew up in Abu Dhabi, UAE, after the Bosnian War broke out, and moved to Germany to pursue her degree in linguistics. As I was gathering information for this article, she explained:

“I grew up multilingual, so it’s difficult for me not to love languages. Everything from the differences in tones, melodies, rhythms and cultural undertones of various languages is what will never cease to amaze me. Since I currently live in Freiburg, German is obviously the predominant language in my daily life alongside my mother tongue (Bosnian), but I try my best to learn new ones by listening to music, reading books and newspapers, watching TV series, and so on. One thing I find funny and interesting about languages is that, at the end of the day, they’re out of our control. Just like you can’t control who you meet in life, you can’t control which languages you learn. You meet them, get to know them, and fall in love with them.”

Unless you write for Smashing, you may never encounter Iris, however, her work is a key part of everything we do — a true behind-the-scenes superstar!

Another person who does a lot of work behind-the-scenes is Cosima Mielke, who joined Smashing in 2012 for a six-month long internship and is still working with us. Cosima is our e-book producer and editor, but gets involved in far more than that. She is behind the posts in the newsletter, and the ever-popular monthly wallpapers post, and many other editorial tasks that crop up.

Cosima loves being outside in nature, riding her bike, and creating things. Her background is not web development, and she told me,

“At Smashing, I’ve gained an entirely new look at the web which I only knew from a user’s perspective before I started working here. What fascinates me most is the strong community sense in the web community, that people are so open to sharing their knowledge and the tools they build to make life easier for everyone else — without asking for anything in return.”

As we cover such a wide range of topics here at Smashing, no one person can be an expert at all of them. Therefore, Iris and I are assisted by our subject-matter editors, some of who have been with us for a very long time.

One such editor is Alma Hoffmann. Originally from Puerto Rico, she moved to the USA to study for her MFA in Graphic Design and now teaches at the University of Alabama. Like so many of our Smashing crew, Alma is bilingual, though I believe she is the only one of the team who can claim to have been a ballroom dancer!

Alma first became involved with Smashing Magazine when she wrote an article in 2010. We perhaps didn’t have the editorial process then that we do now as she got a surprise when her first draft showed up live! She remembers,

“I emailed Vitaly thanking him and since then we have been in touch. He tested the waters by sending me articles to review and in 2013, he and Iris asked me to be the design editor. I wear that title like a badge of honor. Later on, in 2017, I was invited to be a speaker at the conference in Freiburg. I had a blast and met so many interesting people!”

Another of our editors is Michel Bozgounov. Like Alma, he originally became involved with SmashingMag by writing an article. After writing a second article in 2010, Vitaly asked him if he would like to edit a section of the magazine dedicated to Adobe Fireworks. Michel wrote an article when Adobe ultimately ended work on the product, however ,he now edits articles about the newer tools that have filled the gap — such as Sketch and Figma.

In his spare time, Michel loves to draw:

“It all started a few years ago, with a notebook, a fineliner, and a few watercolor pencils that I stole from my wife. Turned out I couldn’t stop drawing and for the last three years or so I imagine and then draw on paper small bits of a strange, but kind of fascinating world that I see in my mind — the world of Monsters & Carrots. For now, this world exists nowhere else but in my notebooks, and I showed only some small parts of it on Twitter.

Michel said that through working for Smashing,

“I learned how to be a better editor, and how to be more careful with words. I consider my experience at Smashing Magazine to be invaluable. I got in touch with so many people from all over the world and developed good online and offline friendships with many of the authors, experts, and editors that I worked with.
Definitely, I can say that my job at Smashing Magazine opened many new doors and changed my life in a good way.”

When it comes to UX-related content, Chui Chui is one of our wonderful editors who works with authors to cover the most up-to-date topics on the magazine. Drew McLellan has recently taken on editing the coding section of the magazine, which includes everything from PHP to HTML, to JavaScript and more! If you write for Smashing Magazine it is likely that your main editorial contact will be with one of these editors, who will work with you to make sure your article is the best it can be.

Yana Kirilenko helps with preparations of articles to be published and talks to all our Smashing TV speakers to arrange the formalities, so they can connect with our wonderful community.

Next, we have Inge Emmler who has been on board since 2011 and keeps us all on track with our expense receipts, and requests to spend money! In addition, she helps out our community when they get in touch. If your book order didn’t show up, then Inge is probably the person who will help you. She loves to be able to make our customers happy and remembers an anecdote from her time at Smashing where she sent a free e-book to one person, brightening their day despite the fact they had just lost their job.

When not helping our the Smashing community and chasing us for our expenses, Inge loves to do things with her hands, be that refurbishing her house, gardening, cooking, and more recently taking photographs of flowers.

Jan Constantin has been part of the team since 2012, between then and now has fulfilled a number of roles — office manager, event manager, junior editor, and fullfillment manager! The nature of a small team is that we all sometimes end up doing something quite different than we originally imagined. Jan enjoys rock climbing, tabletop games and Sci-fi/Fantasy. He confesses that despite working for Smashing all these years he still doesn’t know more than basic HTML.

Ricardo Gimenes is the creator of the Smashing mascot, and therefore is the person we all go to with requests for illustrations of cats involved in a variety of non-catlike activities. Ricardo told he is:

“A half-Brazilian half-Spanish designer who loves graphic and motion. I’ve been a kind of “gypsy” for the past 20 years since I’ve lived in 6 different countries working as a designer (Brazil, Italy, Germany, England, Japan, and now Sweden). I love board games — I have more than 80 games (and counting) in my collection. Every week, we have a board game/beer night with friends here at my home. I’m a big fan of football (and weekend player). I love to play guitar, blues, and rock and roll.”

Ricardo has been with Smashing since 2009, however, he didn’t meet Vitaly or the rest of the team in person for five years as he was based in Brazil. You can see his work all over the magazine and also at our conferences, as he designs each of the conferences to match the location and theme of the event.

I was lucky enough to speak at the very first SmashingConf in Freiburg in 2012. Marc Thiele brought his expertise and knowledge of conference organization to that event. It was a great success and the SmashingConf series has gone from strength to strength, with events happening in Europe, America, and Canada. Marc is still involved with Smashing, offering advice and experience as a friend of the team and also serves on the Smashing Board, helping to shape the direction of the company. He also takes photos at many of our conferences — such as the one above. Marc told me that,

“Working on the Events team, it’s exciting to bring Smashing Conference to all those different places and many people. Creating the Smashing Conference in old town halls, in beautiful theatre and music venues, this is exciting and wonderful to see the outcome and the effect it has on many people attending the event.”

The conference team has grown since those early days. Amanda Annandale joined the team three years ago, and now produces our New York event and has also produced events in London and Toronto. Originally from a theater background, Amanda was a professional stage manager in the USA for ten years.

Producing SmashingConf NY has created a strange turn of events in Amanda’s life,

“For 10 years I was a professional stage manager in New York City, working on musicals, new performance pieces, dance, you name it. One place I worked in was the New World Stages. It was working an event at this venue that I met my husband! Now — nearly 8 years later, I’m back working at the same venue, but this time on the other side when we hold our SmashingConf NY event every year!”

Amanda has the help of Charis Rooda, also an experienced conference organizer outside of Smashing, who runs WebConf.asia and was involved running conferences in The Netherlands before moving to Hong Kong. Charis makes sure that our speakers know where they are supposed to be and when, and also takes care of much of the social media and website content around the conferences. When not working, Charis loves doing art puzzles, and tells me that,

“With 1000 pieces you think you’re never going to finish it, but when you start and keep on going, you will make it. Pretty much like running a conference!”

When asked what surprising thing she had learned while working at Smashing Charis told me,

“I learned how to use em dashes — the punctuation mark which can be used instead of a comma, not to be mistaken for the en dash or hyphen — and my life will never be the same.”

Mariona Cíller was part of the conference team but this year her role is transitioning to more broadly lead the Partnerships and Data side of the business. She has been part of the team since 2015 at SmashingConf Barcelona.

Mariona is a former web designer and developer, and describes herself as, “in love with science and technology, the open web, open-source hardware, and software”. She lives in a laboratory at her grandfather’s 1920’s embroideries factory which she remodeled over the past 5 years. Today, it is a digital fabrication laboratory (FabLab) connected to 1700+ labs from all over the world via the Fab Lab Network and the Center for Bits & Atoms at the Massachusetts Institute of Technology (MIT), where she graduated from the Fab Academy in 2015.

Mariona is currently studying for a Ph.D. in computer science and human-computer interaction at the Open University of Catalonia (UOC). Her research focuses on digital social inclusion programs for the neighborhood youth and community in Barcelona. She manages to find time to be a Mozillian and volunteer her time as a wrangler for MozFest2019!

I’ve learned a lot about many of the Smashing team while researching this piece, however, someone very familiar to me is Bethany Andrew — as she’s my daughter! Bethany has been doing some work for Smashing for a little over a year, first brought in to do some video editing work on the conference video. She still edits many of our videos and has also run a Smashing TV session. A trained dancer and singer, Bethany is part of a gospel choir in London, a true crime nerd, and a lover of Indian food. She said about her time at Smashing,

“It’s so lovely to now be working with everyone at Smashing. So many people have known me since I was a kid through my mum, or she’s always spoken about them. It’s nice now I’m all grown up (or trying to be) that I get to work with this lovely lot and develop my own friendships with them.”

The newest member of our team is Esther Fernández, who has joined Mariona to work on Partnerships and Data, and will be meeting the team for the first time in Freiburg at SmashingConf. I asked Esther to tell me something about her life outside of Smashing, and she said,

“I’m a very curious person. I love the sensation of having learned something new by the end of the day. I get part of that knowledge through books — I’m an eager reader — but also through films and any kind of artistic expression. I have a self-taught knowledge in psychology and I really enjoy hiking, riding my bike, and having conversations with other inquisitive people.”

Then, there is me. Editor in Chief since October 2017, however, I felt part of Smashing long before that. My first Smashing article was published in June 2010 and I was part of the review panel for several years. In addition, I have had chapters in a number of Smashing books, and have spoken and run workshops at SmashingConf since the beginning. Smashing has been part of my own journey as a web developer, speaker, writer, and editor. I love to work with people who are committed to doing the best they can do, dedicated to the web platform and the community who work on it, which is why I’m very proud to be part of this team.

I hope that you, now feel you know us a little better. I certainly found out a lot about my colleagues while writing this. I love how much everyone feels a part of Smashing, whether they work a few hours a month or full time. And, the reason we do this at all? That should be left to Vitaly, who describes best how all of us feel about working on the magazine, conferences and all the other things we do.

“One incredible thing that keeps happening to me all the time is that people come to me and tell stories of how Smashing changed their lives many years ago. Maybe it’s just one article that really nailed it and helped a developer meet the deadline, and sometimes it’s those certain encounters at a conference that simply change your life. I vividly remember stories of people whom I’ve met at conferences when they were students, and who now have companies with dozens of employees. These stories change everything — we don’t hear them most of the time, sitting everywhere in the world and just writing, publishing and curating events, but there is always impact of our work at people around us. And that’s something we shouldn’t take lightly.”

(ra, vf, il)

In this week’s roundup, a handy bookmarklet for inspecting typography, using await to tinker with how JavaScript modules import one another, plus Facebook’s in-app browser is only posing as one. Let’s get into the news!

Check if your content breaks after increasing text spacing

Dylan Barrell from Deque has created a bookmarklet that you can use to check if there are any issues with the content or functionality of your website after increasing the line, paragraph, letter, and word spacing, according to the “Text Spacing” success criterion of the Web Content Accessibility Guidelines.

(via Dylan Barrell)

Using top-level await in JavaScript modules

The proposed top-level await feature is especially useful in JavaScript modules: If module A uses top-level await (e.g., to connect to a database), and module B imports module A — via the import declaration — then the body of B will be evaluated after the body of A (i.e., B will correctly wait for A).

Top-level await enables modules to act as big async functions: With top-level await, ECMAScript Modules (ESM) can await resources, causing other modules who import them to wait before they start evaluating their body.

(via Brian Kardell)

AMP’s new multi-stage loading indicator

AMP has created a new multi-stage loading indicator that has better perceived performance (tested on 2,500 users): It shows nothing until 0.5s, then an intermediate animation until 3.5s, and finally a looping spinner after that.

(via Andrew Watterson)

In other news…

• AMP has released the element which, for the first time, allows AMP pages to add custom JavaScript, with some constraints: The code runs in a separate worker thread and requires a user gesture to change page content (via AMP Project).
• The HTML Standard has made autofocus a global attribute that “applies to all elements, not just to form controls” (e.g., this change enables
  , but no browser supports this yet) (via Kent Tamura).
• Facebook’s in-app browser (powered by Android’s WebView) is not a browser: “Facebook is breaking the web for 20–30% of your traffic because you aren’t demanding they do better” (via Alex Russell).

Read more news in my new, weekly Sunday issue. Visit webplatform.news for more information.

The post Weekly Platform News: Text Spacing Bookmarklet, Top-Level Await, New AMP Loading Indicator appeared first on CSS-Tricks.

A little while back, you might have bumped into this CSS-Tricks article where I described how a mixin can be used to automate responsive font sizes using RFS. In its latest version, v9, RFS is capable of rescaling any value for value for any CSS property with px or rem units, like margin, padding, border-radius or even box-shadow.

Today, we’ll focus on its PostCSS implementation. Read more…

The quality of your sales presentation directly affects the volume of sales you make. The more time, thought, and money you invest in creating a perfect presentation, the more conversions you achieve.

Sales presentations require a creative approach mixed with elements of surprise, personalization, high-quality content, and a bit of humor. Whether you’ve worked on sales presentations before or are tackling the task for the first time, you need some pointers.

We’ve collected the most useful methods of creating a successful sales presentation in this short article. Read on!

1. Pay Special Attention To Relevance

Generic sales presentations are highly ineffective. Don’t make the same mistake your competitors often do. Make sure you focus on the subjects relevant to your potential clients. In order to do that, you have to invest time and money into extensive research.

Your marketing department has probably done part of the work for you defining the parameters of your target audience. Dig a little deeper to answer questions they may have and offer solutions they require.

Since not all your listeners are created equal, you may need to divide the presentation into parts to cater to all of their needs. Your pitch may be generic, but subheadings could be modified to fit each particular group of customers.

According to experts at PresentationGeeks, PowerPoint slides should contain focal points to convey the message to your audience. Stick to one point per slide.

2. Get to the Point Quickly

The attention span of an average consumer today is about eight seconds. Your target audience is likely to be too occupied to listen to lengthy introductions. If you don’t manage to catch their attention quickly, your entire presentation efforts may be in vain.

Identify the key points of your presentation and get to them as quickly as possible. Make sure your listeners understand that you are here to solve their problems rather than overwhelm them with information.

Meanwhile, a strong introduction should exist. It’s an attention catcher, which should make the audience interested in what you are saying next. In fact, the first couple of sentences are one of the most important parts of your sales presentation.

It would be smart to invest a formidable amount of time in them.

3. Know When to Stop

Knowing when to stop talking is extremely important to the success of your sales presentation. At some point, your audience is ready to buy your products. If you continue talking, you may scare them off. Too much information is never too good. So once points are made and questions are answered, hurry to end the presentation.

Your goal is to say on top of your game. Any extra information can push you off the hill. The overall point is to keep the presentation as short as possible. Try to stuff as much useful information as you can into as few words as you can.

You can start by drafting a large sales presentation. Allow your inspiration to work and pour words out. Then start compressing them into shorter sentences and throwing out unnecessary stuff. When you feel that you can’t make the presentation any shorter, cut it in half.

4. Add Q&A Section After Each Point

Many presentations end with a Q&A section. For a sales presentation, you should add such sections after making each point. If you are addressing different problems, which can be solved by your products, failing to answer questions timely could spell disaster.

You can convert a client with the first part of the presentation, but one thing keeping him or her from making a purchase could be a simple question. Hardly anyone is ready to wait for the entire presentation to end to ask something. Most likely, the impulsive wish to buy will disappear. That’s why you have to make sure all questions are answered as soon as they arise.

Always listen to what the customer has to say. Don’t rush to the next point. A client who asks questions is interested in your product. Don’t let such prospective buyers off the hook. Never interrupt the listener or argue with the audience. You should have several phrases in your arsenal to get the presentation back on track.

5. Make It Fun and Energetic

As the attention span decreases so is the desire to listen to something boring. Audiences may be willing to concentrate on information that could bring it money. But when you are trying to get them to spend money, it’s another story.

You have to keep trying to make your presentation fun. Which means you have to dilute your industry-specific information with jokes, images, animation, and the like. Look for relevant media to insert in your presentation. Some companies invest in custom-made videos for promotional purposes. You could borrow a couple of short ones from your marketing team.

Don’t stick to text and voice. Add some diversity to the presentation.

Meanwhile, you should train your voice to sound energetic and full of enthusiasm. Any monotonous presentation is doomed for failure. Run your presentation by friends and family to find out how you sound. Or record it with your smartphone to hear yourself speak.

6. Believe in What You Are Selling

You may be surprised but audiences can feel falsity a mile away. You must believe that what you are selling can solve a problem. You should be ecstatic about your chance to share your products or services with other people.

Be genuine about your desire to help people. With such energy, you can sell virtually anything even if your presentation is not perfect.

To understand whether you are doing a good job convincing clients of your enthusiasm, ask someone who is not in your industry, to listen to you speak.

Meanwhile, make sure your speech doesn’t include “eh”, “ah”, “hmm” and the like. These interjections act as mood killers for the audience. Have several phrases ready to use when you are at a loss of what to say (for example, in a Q&A section).

7. Pay Special Attention to the Format

No matter how amazing your sales presentation sounds, it should also look good as well. That’s why you need to follow several formatting rules.

• Use only classic fonts. For example, Times New Roman, Arial, Helvetica, and Verdana. Anything fancy may make the presentation tough to read.
• Avoid bullet points to simplify the reading process. It’s better to operate with short sentences rather than try to stuff more information into a slide with bullet points.
• Take advantage of new templates. If you use PowerPoint, all the standard, free templates have been seen by your audience several times. Don’t be boring. Use a fresh template.
• Pay special attention to the color. Try not to use more than two colors other than black and white. Otherwise, you could make the presentation too bright and tough to read.
• Limit punctuation. Try to avoid exclamation points. Emphasize the text with your voice rather than symbols.
• Avoid sound effects. Sound effects and bright slide transitions are outdated. It’s better to use a video in a slide.
• Use charts and graphs. They are a great way to illustrate your points with minimum text.

Final Thoughts

A sales presentation should be catchy. Try to avoid too many words or too much text. Your goal is to grab the listeners’ attention and make a conversion. For that, you have to be enthusiastic about the product you sell while following formatting tips.

The quality of your sales presentation directly affects the volume of sales you make. The more time, thought, and money you invest in creating a perfect presentation, the more conversions you achieve.

Sales presentations require a creative approach mixed with elements of surprise, personalization, high-quality content, and a bit of humor. Whether you’ve worked on sales presentations before or are tackling the task for the first time, you need some pointers.

We’ve collected the most useful methods of creating a successful sales presentation in this short article. Read on!

1. Pay Special Attention To Relevance

Generic sales presentations are highly ineffective. Don’t make the same mistake your competitors often do. Make sure you focus on the subjects relevant to your potential clients. In order to do that, you have to invest time and money into extensive research.

Your marketing department has probably done part of the work for you defining the parameters of your target audience. Dig a little deeper to answer questions they may have and offer solutions they require.

Since not all your listeners are created equal, you may need to divide the presentation into parts to cater to all of their needs. Your pitch may be generic, but subheadings could be modified to fit each particular group of customers.

According to experts at PresentationGeeks, PowerPoint slides should contain focal points to convey the message to your audience. Stick to one point per slide.

2. Get to the Point Quickly

The attention span of an average consumer today is about eight seconds. Your target audience is likely to be too occupied to listen to lengthy introductions. If you don’t manage to catch their attention quickly, your entire presentation efforts may be in vain.

Identify the key points of your presentation and get to them as quickly as possible. Make sure your listeners understand that you are here to solve their problems rather than overwhelm them with information.

Meanwhile, a strong introduction should exist. It’s an attention catcher, which should make the audience interested in what you are saying next. In fact, the first couple of sentences are one of the most important parts of your sales presentation.

It would be smart to invest a formidable amount of time in them.

3. Know When to Stop

Knowing when to stop talking is extremely important to the success of your sales presentation. At some point, your audience is ready to buy your products. If you continue talking, you may scare them off. Too much information is never too good. So once points are made and questions are answered, hurry to end the presentation.

Your goal is to say on top of your game. Any extra information can push you off the hill. The overall point is to keep the presentation as short as possible. Try to stuff as much useful information as you can into as few words as you can.

You can start by drafting a large sales presentation. Allow your inspiration to work and pour words out. Then start compressing them into shorter sentences and throwing out unnecessary stuff. When you feel that you can’t make the presentation any shorter, cut it in half.

4. Add Q&A Section After Each Point

Many presentations end with a Q&A section. For a sales presentation, you should add such sections after making each point. If you are addressing different problems, which can be solved by your products, failing to answer questions timely could spell disaster.

You can convert a client with the first part of the presentation, but one thing keeping him or her from making a purchase could be a simple question. Hardly anyone is ready to wait for the entire presentation to end to ask something. Most likely, the impulsive wish to buy will disappear. That’s why you have to make sure all questions are answered as soon as they arise.

Always listen to what the customer has to say. Don’t rush to the next point. A client who asks questions is interested in your product. Don’t let such prospective buyers off the hook. Never interrupt the listener or argue with the audience. You should have several phrases in your arsenal to get the presentation back on track.

5. Make It Fun and Energetic

As the attention span decreases so is the desire to listen to something boring. Audiences may be willing to concentrate on information that could bring it money. But when you are trying to get them to spend money, it’s another story.

You have to keep trying to make your presentation fun. Which means you have to dilute your industry-specific information with jokes, images, animation, and the like. Look for relevant media to insert in your presentation. Some companies invest in custom-made videos for promotional purposes. You could borrow a couple of short ones from your marketing team.

Don’t stick to text and voice. Add some diversity to the presentation.

Meanwhile, you should train your voice to sound energetic and full of enthusiasm. Any monotonous presentation is doomed for failure. Run your presentation by friends and family to find out how you sound. Or record it with your smartphone to hear yourself speak.

6. Believe in What You Are Selling

You may be surprised but audiences can feel falsity a mile away. You must believe that what you are selling can solve a problem. You should be ecstatic about your chance to share your products or services with other people.

Be genuine about your desire to help people. With such energy, you can sell virtually anything even if your presentation is not perfect.

To understand whether you are doing a good job convincing clients of your enthusiasm, ask someone who is not in your industry, to listen to you speak.

Meanwhile, make sure your speech doesn’t include “eh”, “ah”, “hmm” and the like. These interjections act as mood killers for the audience. Have several phrases ready to use when you are at a loss of what to say (for example, in a Q&A section).

7. Pay Special Attention to the Format

No matter how amazing your sales presentation sounds, it should also look good as well. That’s why you need to follow several formatting rules.

• Use only classic fonts. For example, Times New Roman, Arial, Helvetica, and Verdana. Anything fancy may make the presentation tough to read.
• Avoid bullet points to simplify the reading process. It’s better to operate with short sentences rather than try to stuff more information into a slide with bullet points.
• Take advantage of new templates. If you use PowerPoint, all the standard, free templates have been seen by your audience several times. Don’t be boring. Use a fresh template.
• Pay special attention to the color. Try not to use more than two colors other than black and white. Otherwise, you could make the presentation too bright and tough to read.
• Limit punctuation. Try to avoid exclamation points. Emphasize the text with your voice rather than symbols.
• Avoid sound effects. Sound effects and bright slide transitions are outdated. It’s better to use a video in a slide.
• Use charts and graphs. They are a great way to illustrate your points with minimum text.

Final Thoughts

A sales presentation should be catchy. Try to avoid too many words or too much text. Your goal is to grab the listeners’ attention and make a conversion. For that, you have to be enthusiastic about the product you sell while following formatting tips.

<h1 aria-label="Vespa"><svg>…</svg></h1>

<main>
<h2>It looks like a wasp!</h2>
<div>…</div>
</main>

<figure>…</figure>

figure {
display: flex; }

figure {
max-width: 100vw;
overflow-x: scroll; }

<figure>
<div><img src="img-1.svg" alt=""></div>
<div><img src="img-2.svg" alt=""></div>
<div><img src="img-3.svg" alt=""></div>
<div><img src="img-4.svg" alt=""></div>
</figure>

figure div {
flex-grow: 1;
flex-shrink: 0; }

figure div {
flex-basis: 40%;
/* flex: 1 0 40%; */ }

@media screen and (min-width : 48em) {

body {
display: grid;
grid-template-columns: 2fr 1fr 1fr 2fr 2fr 1fr 1fr 2fr;
grid-column-gap: 2vw;
grid-row-gap: 4vh; }
}

h1 {
grid-column: 7;
grid-row: 1;  }

main {
grid-column: 6 / -1;
grid-row: 2;  }

figure {
grid-column: 1 / 6;
grid-row: 1 / 3;  }

@media screen and (min-width : 64em) {

h1 {
grid-column: 8;
grid-row: 1; }

main {
grid-column: 2 / 6;
grid-row: 1; }

figure {
grid-column: 1 / -1;
grid-row: 2; }
}

figure {
grid-template-columns: 1fr 2fr 3fr 4fr;
grid-gap: 0;
align-items: end; }

figure div:nth-of-type(1) {
transform: translate(20px, -20px) rotate(-20deg); }

figure div:nth-of-type(2) {
transform: rotate(-5deg); }

figure div:nth-of-type(3) {
transform: rotate(10deg); }

figure div:nth-of-type(4) {
transform: translate(-60px, -80px) rotate(-20deg); }

<h1 aria-label="Vespa"><img></h1>
<main>…</main>
<aside>…</aside>

aside {
background-color: #ba0e37;
color: #fff; }

@media screen and (min-width : 48em) {

main,
aside {
display: grid;
grid-template-columns: 2fr 1fr 1fr 2fr;
grid-template-rows: 10rem 200px 10rem auto; }
}

main,
aside {
min-height: 100vh; }

main figure {
display: contents; }

main img {
grid-column: 1 / 4;
grid-row: 1 / 5; }

main figcaption {
grid-column: 4 / -1;
grid-row: 3; }

aside img {
grid-column: 2 / -1;
grid-row: 1 / 5; }

aside figcaption {
grid-column: 1;
grid-row: 3;
align-self: center; }

@media screen and (min-width : 64em) {

body {
display: grid;
grid-template-columns: [main] 1fr [aside] 1fr; }

main {
grid-column: main; }

aside {
grid-column: aside; }
}

<h1>
<picture>
<source srcset="logo-2-tone.svg" media="(min-width: 64em)">
<img src="logo.svg" alt="ihatetimvandamme">
</picture>
</h1>

h1 {
position: absolute;
top: 14rem;
left: 50vw;
z-index: 2;
transform: translateX(-95px); }

<header>
<picture>…</picture>
</header>

<main>…</main>

@media screen and (min-width : 64em) {

body {
display: grid;
grid-template-columns: [header] 1fr [main] 1fr;
max-width: 100vw; }

header {
grid-column: header; }

main {
grid-column: main; }
}

main:before {
content: "";
display: block;
float: left;
width: 170px;
height: 800px;
shape-outside: url('mask.svg'); }

<header>
<picture>…</picture>
</header>

<main>…</main>

<img src="shape-1.svg" alt="" aria-hidden="true">
<img src="shape-2.svg" alt="" aria-hidden="true">
<p>…</p>

@media screen and (min-width : 64em) {

body {
display: grid;
grid-template-columns: 2fr 1fr 1fr 2fr 2fr 1fr 1fr 2fr; }

header {
grid-column: 1 / 5; }

main {
grid-column: 5 / 9; }
}

header picture {
transform: rotate(20deg);
transform-origin: 50% 50%; }

[src*="shape-1"],
[src*="shape-2"] {
width: 200px;
height: 100vh; }

[src*="shape-1"] {
float: left;
shape-outside: url('mask-1.svg'); }

[src*="shape-2"] {
float: right;
shape-outside: url('mask-2.svg'); }

<main>…</main>
<aside>…</aside>

<aside>
<div>…</div>
<figure>
<img src="clip-left.svg" alt="">
<img src="clip-center.svg" alt="">
<img src="clip-right.svg" alt="">
</figure>
</aside>

figure {
position: relative; }

figure img {
position: absolute;
top: 0;
left: 0; }

figure img:nth-of-type(1) {
z-index: 2;
clip-path: polygon(0% 0%, 0% 100%, 33.33% 100%, 33.33% 0%); }

figure img:nth-of-type(2) {
z-index: 1;
clip-path: polygon(0% 0%, 100% 0%, 100% 100%, 0% 100%); }

figure img:nth-of-type(3) {
z-index: 2;
clip-path: polygon(100% 0%, 66.66% 0%, 66.66% 100%, 100% 100%); }

@media screen and (min-width : 64em) {

body {
grid-template-columns: 2fr 1fr 1fr 2fr 2fr 1fr 1fr 2fr; 
grid-column-gap: 2vw; } 

main {
grid-column: 1 / 3; }

aside {
grid-column: 3 / -1; }
}

body {
height: 100vh; }

aside {
background-image: linear-gradient(to right, 
#ba0e37 33.33%, 
#fff 33.33%, 
#fff 66.66%, 
#ba0e37 66.66%); }

aside {
display: grid;
grid-template-columns: 1fr 1fr 1fr;
grid-template-rows: 1fr 1fr; }

aside div {
z-index: 2;
grid-column: 2;
grid-row: 1 / 3; }

figure {
z-index: 1;
grid-column: 1 / -1;
grid-row: 2; }

<main>…</main>
<footer>…</footer>

<main>
<h1 aria-label="Vespa"><svg>…</svg></h1>
<img src="vespa.svg" alt="Vespa">
<h2>…</h2>
<p>…</p>
</main>

<footer>
<div>…</div>
<div>…</div>
</footer>

@media screen and (min-width : 48em) {

body {
display: grid;
grid-template-columns: [main] 1fr [footer] 1fr;
min-height: 100vh; }

main {
grid-column: main; }

footer {
grid-column: footer; }
}

@media screen and (min-width : 64em) {

body {
grid-template-columns: [main] 2fr [footer] 3fr; }
}

footer {
background-image: linear-gradient(to right, 
#000 33.33%, 
#fff 33.33%, 
#fff 66.66%, 
#000 66.66%); }

<footer>
<div>
<img src="top-left.svg" alt="">
<img src="top-center.svg" alt="">
<img src="top-right.svg" alt="">
</div>

<div>
<img src="bottom-left.svg" alt="">
<img src="bottom-center.svg" alt="">
<img src="bottom-right.svg" alt="">
</div>
</footer>

footer div:nth-of-type(2) {
display: flex; }

footer div:nth-of-type(2) img {
flex: 1;
max-width: 33%; }

footer div:nth-of-type(1) {
position: relative;
min-height: 300px; }

footer div:nth-of-type(1) img {
position: absolute;
top: 0;
left: 0; }

footer div:nth-of-type(1) img:nth-of-type(1) {
clip-path: polygon(0% 0%, 0% 100%, 33.33% 100%, 33.33% 0%); }

footer div:nth-of-type(1) img:nth-of-type(2) {
clip-path: polygon(0% 0%, 100% 0%, 100% 100%, 0% 100%); }

footer div:nth-of-type(1) img:nth-of-type(3) {
clip-path: polygon(100% 0%, 66.66% 0%, 66.66% 100%, 100% 100%); }

footer div:nth-of-type(1) svg {
position: absolute;
mix-blend-mode: darken; }

Now that we’ve got cross-browser support for the line-clamp property, I expect we’ll see a lot more of that around the web. And as we start to see it more in use, it’s worth the reminder that: Truncation is not a content strategy.

We should at least offer a way to read that that truncated content, right? Paul Bakaus uses the checkbox hack and some other trickery to add a functional button that does exactly that.

See the Pen
truncated text w/ more button (CSS only, with optional JS helper) by Paul Bakaus (@pbakaus)
on CodePen.

Direct Link to Article — Permalink

The post Multiline truncated text with “show more” button appeared first on CSS-Tricks.

Testing applications is crucially important to ensuring that the code is error-free and the logic requirements are met. However, writing tests manually is tedious and prone to human bias and error. Furthermore, maintenance can be a nightmare, especially when features are added or business logic is changed. We’ll learn how model-based testing can eliminate the need to manually write integration and end-to-end tests, by automatically generating full tests that keep up-to-date with an abstract model for any app.

From unit tests to integration tests, end-to-end tests, and more, there are many different testing methods that are important in the development of non-trivial software applications. They all share a common goal, but at different levels: ensure that when anyone uses the application, it behaves exactly as expected without any unintended states, bugs, or worse, crashes.

Kent C. Dodds describes the practical importance of writing these tests in his article, Write tests. Not too many. Mostly integration. Some tests, like static and unit tests, are easy to author, but don’t completely ensure that every unit will work together. Other tests, like integration and end-to-end (E2E) tests, take more time to author, but give you much more confidence that the application will work as the user expects, since they replicate scenarios similar to how a user would use the application in real life.

So why are there never many integration nor E2E in applications nowadays, yet hundreds (if not thousands) of unit tests? The reasons range from not enough resources, not enough time, or not enough understanding of the importance of writing these tests. Furthermore, even if numerous integration/E2E tests are written, if one part of the application changes, most of those long and complicated tests need to be rewritten, and new tests need to be written. Under deadlines, this quickly becomes infeasible.

From Automated to Autogenerated

The status-quo of application testing is:

1. Manual testing, where no automated tests exist, and app features and user flows are tested manually
2. Writing automated tests, which are scripted tests that can be executed automatically by a program, instead of being manually tested by a human
3. Test automation, which is the strategy for executing these automated tests in the development cycle.

Needless to say, test automation saves a lot of time in executing the tests, but the tests still need to be manually written. It would sure be nice to tell some sort of tool: “Here is a description of how the application is supposed to behave. Now generate all the tests, even the edge cases.”

Thankfully, this idea already exists (and has been researched for decades), and it’s called model-based testing. Here’s how it works:

1. An abstract “model” that describes the behavior of your application (in the form of a directed graph) is created
2. Test paths are generated from the directed graph
3. Each “step” in the test path is mapped to a test that can be executed on the application.

Each integration and E2E test is essentially a series of steps that alternate between:

1. Verify that the application looks correct (a state)
2. Simulate some action (to produce an event)
3. Verify that the application looks right after the action (another state)

If you’re familiar with the given-when-then style of behavioral testing, this will look familiar:

1. Given some initial state (precondition)
2. When some action occurs (behavior)
3. Then some new state is expected (postcondition).

A model can describe all the possible states and events, and automatically generate the “paths” needed to get from one state to another, just like Google Maps can generate the possible routes between one location and another. Just like a map route, each path is a collection of steps needed to get from point A to point B.

Integration Testing Without a Model

To better explain this, consider a simple “feedback” application. We can describe it like so:

• A panel appears asking the user, “How was your experience?”
• The user can click “Good” or “Bad”
• When the user clicks “Good,” a screen saying “Thanks for your feedback” appears.
• When the user clicks “Bad,” a form appears, asking for further information.
• The user can optionally fill out the form and submit the feedback.
• When the form is submitted, the thanks screen appears.
• The user can click “Close” or press the Escape key to close the feedback app on any screen.

See the Pen
Untitled by David Khourshid(@davidkpiano)
on CodePen.

Manually Testing the App

The @testing-library/react library makes it straightforward to render React apps in a testing environment with its render() function. This returns useful methods, such as:

• getByText, which identifies DOM elements by the text contained inside of them
• baseElement, which represents the root document.documentElement and will be used to trigger a keyDown event
• queryByText, which will not throw an error if a DOM element containing the specified text is missing (so we can assert that nothing is rendered)

import Feedback from './App';
import { render, fireEvent, cleanup } from 'react-testing-library';

// ...

// Render the feedback app
const {
  getByText,
  getByTitle,
  getByPlaceholderText,
  baseElement,
  queryByText
} = render(<Feedback />);

// ...

More information can be found in the @testing-library/react documentation. Let’s write a couple integration tests for this with Jest (or Mocha) and @testing-library/react:

import { render, fireEvent, cleanup } from '@testing-library/react';

describe('feedback app', () => {
  afterEach(cleanup);

  it('should show the thanks screen when "Good" is clicked', () => {
    const { getByText } = render(<Feedback />);

    // The question screen should be visible at first
    assert.ok(getByText('How was your experience?'));

    // Click the "Good" button
    fireEvent.click(getByText('Good'));

    // Now the thanks screen should be visible
    assert.ok(getByText('Thanks for your feedback.'));
  });

  it('should show the form screen when "Bad" is clicked', () => {
    const { getByText } = render(<Feedback />);

    // The question screen should be visible at first
    assert.ok(getByText('How was your experience?'));

    // Click the "Bad" button
    fireEvent.click(getByText('Bad'));

    // Now the form screen should be visible
    assert.ok(getByText('Care to tell us why?'));
  });
});

Not too bad, but you’ll notice that there’s some repetition going on. At first, this isn’t a big deal (tests shouldn’t necessarily be DRY), but these tests can become less maintainable when:

• Application behavior changes, such as adding a new steps or deleting steps
• User interface elements change, in a way that might not even be a simple component change (such as trading a button for a keyboard shortcut or gesture)
• Edge cases start occurring and need to be accounted for.

Furthermore, E2E tests will test the exact same behavior (albeit in a more realistic testing environment, such as a live browser with Puppeteer or Selenium), yet they cannot reuse the same tests since the code for executing the tests is incompatible with those environments.

The State Machine as an Abstract Model

Remember the informal description of our feedback app above? We can translate that into a model that represents the different states, events, and transitions between states the app can be in; in other words, a finite state machine. A finite state machine is a representation of:

• The finite states in the app (e.g., question, form, thanks, closed)
• An initial state (e.g., question)
• The events that can occur in the app (e.g., CLICK_GOOD, CLICK_BAD for clicking the good/bad buttons, CLOSE for clicking the close button, and SUBMIT for submitting the form)
• Transitions, or how one state transitions to another state due to an event (e.g., when in the question state and the CLICK_GOOD action is performed, the user is now in the thanks state)
• Final states (e.g., closed), if applicable.

The feedback app’s behavior can be represented with these states, events, and transitions in a finite state machine, and looks like this:

A visual representation can be generated from a JSON-like description of the state machine, using XState:

import { Machine } from 'xstate';

const feedbackMachine = Machine({
  id: 'feedback',
  initial: 'question',
  states: {
    question: {
      on: {
        CLICK_GOOD: 'thanks',
        CLICK_BAD: 'form',
        CLOSE: 'closed'
      }
    },
    form: {
      on: {
        SUBMIT: 'thanks',
        CLOSE: 'closed'
      }
    },
    thanks: {
      on: {
        CLOSE: 'closed'
      }
    },
    closed: {
      type: 'final'
    }
  }
});

If you’re interested in diving deeper into XState, you can read the XState docs, or read a great article about using XState with React by Jon Bellah. Note that this finite state machine is used only for testing, and not in our actual application — this is an important principle of model-based testing, because it represents how the user expects the app to behave, and not its actual implementation details. The app doesn’t necessarily need to be created with finite state machines in mind (although it’s a very helpful practice).

Creating a Test Model

The app’s behavior is now described as a directed graph, where the nodes are states and the edges (or arrows) are events that denote the transitions between states. We can use that state machine (the abstract representation of the behavior) to create a test model. The @xstate/graph library contains a createModel function to do that:

import { Machine } from 'xstate';
import { createModel } from '@xstate/test';

const feedbackMachine = Machine({/* ... */});

const feedbackModel = createModel(feedbackMachine);

This test model is an abstract model which represents the desired behavior of the system under test (SUT) — in this example, our app. With this testing model, test plans can be created which we can use to test that the SUT can reach each state in the model. A test plan describes the test paths that can be taken to reach a target state.

Verifying States

Right now, this model is a bit useless. It can generate test paths (as we’ll see in the next section) but to serve its purpose as a model for testing, we need to add a test for each of the states. The @xstate/test package will read these test functions from meta.test:

const feedbackMachine = Machine({
  id: 'feedback',
  initial: 'question',
  states: {
    question: {
      on: {
        CLICK_GOOD: 'thanks',
        CLICK_BAD: 'form',
        CLOSE: 'closed'
      },
      meta: {
        // getByTestId, etc. will be passed into path.test(...) later.
        test: ({ getByTestId }) => {
          assert.ok(getByTestId('question-screen'));
        }
      }
    },
    // ... etc.
  }
});

Notice that these are the same assertions from the manually written tests we’ve created previously with @testing-library/react. The purpose of these tests is to verify the precondition that the SUT is in the given state before executing an event.

Executing Events

To make our test model complete, we need to make each of the events, such as CLICK_GOOD or CLOSE, “real” and executable. That is, we have to map these events to actual actions that will be executed in the SUT. The execution functions for each of these events are specified in createModel(…).withEvents(…):

import { Machine } from 'xstate';
import { createModel } from '@xstate/test';

const feedbackMachine = Machine({/* ... */});

const feedbackModel = createModel(feedbackMachine)
  .withEvents({
    // getByTestId, etc. will be passed into path.test(...) later.
    CLICK_GOOD: ({ getByText }) => {
      fireEvent.click(getByText('Good'));
    },
    CLICK_BAD: ({ getByText }) => {
      fireEvent.click(getByText('Bad'));
    },
    CLOSE: ({ getByTestId }) => {
      fireEvent.click(getByTestId('close-button'));
    },
    SUBMIT: {
      exec: async ({ getByTestId }, event) => {
        fireEvent.change(getByTestId('response-input'), {
          target: { value: event.value }
        });
        fireEvent.click(getByTestId('submit-button'));
      },
      cases: [{ value: 'something' }, { value: '' }]
    }
  });

Notice that you can either specify each event as an execution function, or (in the case of SUBMIT) as an object with the execution function specified in exec and sample event cases specified in cases.

From Model To Test Paths

Take a look at the visualization again and follow the arrows, starting from the initial question state. You’ll notice that there are many possible paths you can take to reach any other state. For example:

• From the question state, the CLICK_GOOD event transitions to…
• the form state, and then the SUBMIT event transitions to…
• the thanks state, and then the CLOSE event transitions to…
• the closed state.

Since the app’s behavior is a directed graph, we can generate all the possible simple paths or shortest paths from the initial state. A simple path is a path where no node is repeated. That is, we’re assuming the user isn’t going to visit a state more than once (although that might be a valid thing to test for in the future). A shortest path is the shortest of these simple paths.

Rather than explaining algorithms for traversing graphs to find shortest paths (Vaidehi Joshi has great articles on graph traversal if you’re interested in that), the test model we created with @xstate/test has a .getSimplePathPlans(…) method that generates test plans.

Each test plan represents a target state and simple paths from the initial state to that target state. Each test path represents a series of steps to get to that target state, with each step including a state (precondition) and an event (action) that is executed after verifying that the app is in the state.

For example, a single test plan can represent reaching the thanks state, and that test plan can have one or more paths for reaching that state, such as question -- CLICK_BAD ? form -- SUBMIT ? thanks, or question -- CLICK_GOOD ? thanks:

testPlans.forEach(plan => {
  describe(plan.description, () => {
    // ...
  });
});

We can then loop over these plans to describe each state. The plan.description is provided by @xstate/test, such as reaches state: "question":

// Get test plans to all states via simple paths
const testPlans = testModel.getSimplePathPlans();

And each path in plan.paths can be tested, also with a provided path.description like via CLICK_GOOD ? CLOSE:

testPlans.forEach(plan => {
  describe(plan.description, () => {
    // Do any cleanup work after testing each path
    afterEach(cleanup);

    plan.paths.forEach(path => {
      it(path.description, async () => {
        // Test setup
        const rendered = render(<Feedback />);

        // Test execution
        await path.test(rendered);
      });
    });
  });
});

Testing a path with path.test(…) involves:

1. Verifying that the app is in some state of a path’s step
2. Executing the action associated with the event of a path’s step
3. Repeating 1. and 2. until there are no more steps
4. Finally, verifying that the app is in the target plan.state.

Finally, we want to ensure that each of the states in our test model were tested. When the tests are run, the test model keeps track of the tested states, and provides a testModel.testCoverage() function which will fail if not all states were covered:

it('coverage', () => {
  testModel.testCoverage();
});

Overall, our test suite looks like this:

import React from 'react';
import Feedback from './App';
import { Machine } from 'xstate';
import { render, fireEvent, cleanup } from '@testing-library/react';
import { assert } from 'chai';
import { createModel } from '@xstate/test';

describe('feedback app', () => {
  const feedbackMachine = Machine({/* ... */});
  const testModel = createModel(feedbackMachine)
    .withEvents({/* ... */});

  const testPlans = testModel.getSimplePathPlans();
  testPlans.forEach(plan => {
    describe(plan.description, () => {
      afterEach(cleanup);
      plan.paths.forEach(path => {
        it(path.description, () => {
          const rendered = render(<Feedback />);
          return path.test(rendered);
        });
      });
    });
  });

  it('coverage', () => {
    testModel.testCoverage();
  });
});

This might seem like a bit of setup, but manually scripted integration tests need to have all of this setup anyway, in a much less abstracted way. One of the major advantages of model-based testing is that you only need to set this up once, whether you have 10 tests or 1,000 tests generated.

Running the Tests

In create-react-app, the tests are ran using Jest via the command npm test (or yarn test). When the tests are ran, assuming they all pass, the output will look something like this:

PASS  src/App.test.js
feedback app
  ✓ coverage
  reaches state: "question" 
    ✓ via  (44ms)
  reaches state: "thanks" 
    ✓ via CLICK_GOOD (17ms)
    ✓ via CLICK_BAD → SUBMIT ({"value":"something"}) (13ms)
  reaches state: "closed" 
    ✓ via CLICK_GOOD → CLOSE (6ms)
    ✓ via CLICK_BAD → SUBMIT ({"value":"something"}) → CLOSE (11ms)
    ✓ via CLICK_BAD → CLOSE (10ms)
    ✓ via CLOSE (4ms)
  reaches state: "form" 
    ✓ via CLICK_BAD (5ms)

Test Suites: 1 passed, 1 total
Tests:       9 passed, 9 total
Snapshots:   0 total
Time:        2.834s

That’s nine tests automatically generated with our finite state machine model of the app! Every single one of those tests asserts that the app is in the correct state and that the proper actions are executed (and validated) to transition to the next state at each step, and finally asserts that the app is in the correct target state.

These tests can quickly grow as your app gets more complex; for instance, if you add a back button to each screen or add some validation logic to the form page (please don’t; be thankful the user is even going through the feedback form in the first place) or add a loading state submitting the form, the number of possible paths will increase.

Advantages of Model-Based Testing

Model-based testing greatly simplifies the creation of integration and E2E tests by autogenerating them based on a model (like a finite state machine), as demonstrated above. Since manually writing full tests is eliminated from the test creation process, adding or removing new features no longer becomes a test maintenance burden. The abstract model only needs to be updated, without touching any other part of the testing code.

For example, if you want to add the feature that the form shows up whether the user clicks the “Good” or “Bad” button, it’s a one-line change in the finite state machine:

// ...
    question: {
      on: {
//      CLICK_GOOD: 'thanks',
        CLICK_GOOD: 'form',
        CLICK_BAD: 'form',
        CLOSE: 'closed',
        ESC: 'closed'
      },
      meta: {/* ... */}
    },
// ...

All tests that are affected by the new behavior will be updated. Test maintenance is reduced to maintaining the model, which saves time and prevents errors that can be made in manually updating tests. This has been shown to improve efficiency in both developing and testing production applications, especially as used at Microsoft on recent customer projects — when new features were added or changes made, the autogenerated tests gave immediate feedback on which parts of the app logic were affected, without needing to manually regression test various flows.

Additionally, since the model is abstract and not tied to implementation details, the exact same model, as well as most of the testing code, can be used to author E2E tests. The only things that would change are the tests for verifying the state and the execution of the actions. For example, if you were using Puppeteer, you can update the state machine:

// ...
question: {
  on: {
    CLICK_GOOD: 'thanks',
    CLICK_BAD: 'form',
    CLOSE: 'closed'
  },
  meta: {
    test: async (page) => {
      await page.waitFor('[data-testid="question-screen"]');
    }
  }
},
// ...

const testModel = createModel(/* ... */)
  .withEvents({
    CLICK_GOOD: async (page) => {
      const goodButton = await page.$('[data-testid="good-button"]');
      await goodButton.click();
    },
    // ...
  });

And then these tests can be run against a live Chromium browser instance:

The tests are autogenerated the same, and this cannot be overstated. Although it just seems like a fancy way to create DRY test code, it goes exponentially further than that — autogenerated tests can exhaustively represent paths that explore all the possible actions a user can do at all possible states in the app, which can readily expose edge-cases that you might not have even imagined.

The code for both the integration tests with @testing-library/react and the E2E tests with Puppeteer can be found in the the XState test demo repository.

Challenges to Model-Based Testing

Since model-based testing shifts the work from manually writing tests to manually writing models, there is a learning curve. Creating the model necessitates the understanding of finite state machines, and possibly even statecharts. Learning these are greatly beneficial for more reasons than just testing, since finite state machines are one of the core principles of computer science, and statecharts make state machines more flexible and scalable for complex app and software development. The World of Statecharts by Erik Mogensen is a great resource for understanding and learning how statecharts work.

Another issue is that the algorithm for traversing the finite state machine can generate exponentially many test paths. This can be considered a good problem to have, since every one of those paths represents a valid way that a user can potentially interact with an app. However, this can also be computationally expensive and result in semi-redundant tests that your team would rather skip to save testing time. There are also ways to limit these test paths, e.g., using shortest paths instead of simple paths, or by refactoring the model. Excessive tests can be a sign of an overly complex model (or even an overly complex app ?).

Write Fewer Tests!

Modeling app behavior is not the easiest thing to do, but there are many benefits of representing your app as a declarative and abstract model, such as a finite state machine or a statechart. Even though the concept of model-based testing is over two decades old, it is still an evolving field. But with the above techniques, you can get started today and take advantage of generating integration and E2E tests instead of manually writing every single one of them.

More resources:

I gave a talk at React Rally 2019 demonstrating model-based testing in React apps:

Slides: Slides: Write Fewer Tests! From Automation to Autogeneration

• Library: @xstate/test
• Community: Statecharts (spectrum.chat)
• Article: The Challenges and Benefits of Model-Based Testing (SauceLabs)

Happy testing!

The post Model-Based Testing in React with State Machines appeared first on CSS-Tricks.

This is super interesting stuff from Mozilla: the most recent update of Firefox will now block cryptominers and third-party tracking scripts by default. In the press release they write:

For today’s release, Enhanced Tracking Protection will automatically be turned on by default for all users worldwide as part of the ‘Standard’ setting in the Firefox browser and will block known “third-party tracking cookies” according to the Disconnect list. We first enabled this default feature for new users in June 2019. As part of this journey we rigorously tested, refined, and ultimately landed on a new approach to anti-tracking that is core to delivering on our promise of privacy and security as central aspects of your Firefox experience.

Compare this to A Vox interview with Mat Marquis discussing Google’s efforts to make Chrome more private:

“Google is an advertising company, not a group of concerned altruists; there aren’t any charts at stakeholder meetings showing what amount they ‘saved the web’ this past quarter. They’re notorious for overstepping and outright abusing users’ personal data in pursuit of, well, making money as an advertising company,” Mat Marquis, a web developer, told Recode. “Their business model — the thing that keeps all these genuinely brilliant, genuinely well-meaning designers and developers employed — depends on convincing a company that they can make their users look at your ads.”

This is yet another reason why Firefox is my browser of choice and why, as concerned web designers and developers, I suggest others consider joining me in making the switch.

Direct Link to Article — Permalink

The post Firefox blocks third-party tracking cookies and cryptominers appeared first on CSS-Tricks.

Creating an efficient marketing strategy always requires using all sources of profit. Integrating support into this strategy is somewhat difficult at first glance.

On the other hand, what place is better for building a positive brand perception? In 2018, 62% of customers contacted support. It is usually what people do the moment they need help. And providing some right away is certainly going to affect your marketing strategy positively.

No matter how much effort you put into writing amazing blog posts, recording engaging podcasts, or publishing awesome Instagram photos; if your support fails to deliver the expected, it’s all in vain.

So, how do you exactly integrate customer service into your marketing strategy? There are some professionally proven tips.

Use Customer Support Automation

Personalization is always the best. However, as the numbers of your customers start growing, you’ll notice the lack of time for demos and calls. For example, being a startup with only 10 people, it’s hard to communicate with every single subscriber.

Just to be clear, we support the idea of customer support being as human as possible. It’s just that if you are not able to keep things that way, automation is a game-changer.

You can craft a long tutorial video and split it into one-minute parts. Then send it to all of your email subscribers once a week. This simple move will help you educate customers and save your support team from the hustle of explaining the same things over and over.As for marketing benefits, customer support automation is perfect. Take the described example of short tutorials. You can create text versions of those and insert calls-to-action (CTA) there. According to Campaign Monitor, a CTA button can help you get 28% more conversion rates. Regarding tutorials, this can mean more large-payment subscriptions.

Educate Your Clients and Let Them Trust You

How hard is it to make a regular subscriber your brand advocate? The answer certainly lies somewhere in the follow-up and customer education phase. As we have mentioned in the previous paragraph, educating your clients helps save time for the support team and increase the number of paid subscriptions.

If your client asks something specific, answer that question immediately. And then send a concise article regarding the issue in a follow-up email. In this way, you will both educate your customers more and show them that you care. In the 21st century, people expect top-notch support and personalized approach.

The most important thing in this regard is planning all those actions and implementing them in your marketing strategy. Content creation, social media posting, and even live events should be deeply integrated into customer service activities. How is it done? Let’s dig deeper!

Use Your Email Campaign the Most

With all the growing numbers of Instagram and TikTok users, people still prefer email communication the most. It is a simple yet boundless way to communicate and share any kind of information. Marketing strategy does involve the usage of the email channel. However, how often does a support team use it to promote the brand?

Customer service is directly involved in email communication. All the support tickets, payment confirmations, or any other kind of messages are sent via email. So, instead of writing plain text, let your support representatives apply more creativity.

Use email templates

In terms of brand awareness promotion, consistency is the key. Thus, create email templates for all the situations. Include your company logo, brand colors, and social media links to it. Make sure your support team always uses these templates. It adds up to your professionalism and increases trust.

Use email signatures

Email signature in modern marketing is much more than simple ‘Best regards.’

HTML allows adding any type of content to your email footer. So, use it for your best. Make sure your customer support team uses similar email signatures that contain the following.

1. Sender’s photo (if you want to increase personalization and trust) or company logo (if you want to promote your brand above all).
2. Sender’s name, phone numbers, email and physical address of the company.
3. Social media icons linked to corresponding corporate profiles.
4. CTAs with links (you can use buttons as well).
5. Promotional banners linked to your website, call schedule tools, webinar bookings, etc.

Of course, it would take a lot of time coding all these with HTML yourself. Even if you have a developers team. One could argue that you can make an email signature with a simple visual editor. But it might make your emails get spam flags, as images are often treated like one.

If you want to make corporate email signatures that look the same and take little time to create/install, use an online email signature generator, like Newoldstamp. It has a simple editor and a powerful dashboard. These allow you to create a master signature with all the described elements (using ready templates from a gallery) and send it to your employees just for inputting their names.

In addition, the Departments feature allows creating different signatures for different teams. Marketers may want to advertise the recent blog post, and your customer team is better to include a demo scheduling banner in their signatures.

So, make sure your support team uses email signatures that clearly represent your brand and let people contact your company ASAP.

Setup live chats

As you should make contacting your support as easy as possible, don’t forget about a live chat on your website. If your visitor finds something on a website difficult, being able to reach out for help from this very page is certainly going to increase customer satisfaction.

Bottom Line

Customer service is the last link between positive brand awareness and clients’ satisfaction. If you set it up wisely, people will love addressing your support team. And your representatives will have an opportunity to promote your company (directly and indirectly). The trick is keeping things comfortable and simple for customers. This is our essential advice. If you follow it, you will be able to use customer service for marketing purposes.