Weekly Platform News: Contrast Ratio Range, replaceAll Method, Native File System API

In this week’s roundup: Firefox’s new contrast checker, a simpler way to lasso substrings in a string, and a new experimental API that will let apps fiddle with a user’s local files.

Firefox shows the contrast ratio range for text on a multicolored background

According to Success Criterion 1.4.3 of the Web Content Accessibility Guidelines (WCAG), text should have a contrast ratio of at least 4.5. (A lower contrast ratio is acceptable only if the text is 24px or larger.)

If the background of the text is not a solid color but a color gradient or photograph, you can use the special element picker in Firefox’s Accessibility panel to get a range of contrast ratios based on the element’s actual background.

(via Šime Vidas)

Replacing all instances of a substring in a string

The new JavaScript replaceAll method makes it easier to replace all instances of a substring in a string without having to convert the substring to a regex first, which is “hard to get right since JavaScript doesn’t offer a built-in mechanism to escape regular expression patterns.”

// BEFORE str = str.replace(/foo/g, "bar");  // AFTER str = str.replaceAll("foo", "bar");

This new string method has not yet shipped in browsers, but you can start using it today via Babel (since it’s automatically polyfilled by @babel/preset-env).

(via Mathias Bynens)

Try out the Native File System API in Chrome

The Native File System API, which is experimentally supported in Chrome, allows web apps to read or save changes directly to local files on the person’s computer. The app is granted permission to view and edit files in a specific folder via two separate prompts.

You can try out this new feature by visiting labs.vaadin.com in Chrome on desktop.

(via Thomas Steiner)

More news…


Read more news in my weekly newsletter for web developers. Pledge as little as $ 2 per month to get the latest news from me via email every Monday.

More News →

The post Weekly Platform News: Contrast Ratio Range, replaceAll Method, Native File System API appeared first on CSS-Tricks.


, , , , , , , , , ,

How Building in the Open Can Change Our Industry

I have to admit, I’m a developer who hasn’t built a website. When I first read Chris’s question, I sat in silence for at least a minute. Which technical topic did I want to discuss? A new library, programming language or best practice? Nothing, in particular, came to mind. Is that because I’m a new developer?

I’ve been coding for about one year now and got my first job a month ago. Even though I’ve been coding for that time, I wouldn’t say I’ve built a website. I’ve contributed to a couple of open-source projects whose output was websites, but I’ve spent a lot of time practicing technical tests in order to get into the industry and now I’m writing Kotlin for the Guardian Newspaper’s Android application.

After a couple minutes thinking about this question, I realized I wanted to write about who gets to build websites and how and where we choose to build them in order to welcome new people. I’ve spent this year giving conference talks on this topic because I have first-hand knowledge of what it’s like to become a developer with little time and money. It’s not easy being on the “outside” trying to get into our industry. How can we make it easier for new people to join us here? How can we welcome under-represented groups to the table? In 2020 you can make a huge difference to our industry by welcoming new developers, especially those from under-represented groups.

It’s been five years since the most well-known tech companies first released diversity reports, revealing that workforces were overwhelmingly white or Asian men. Despite their business successes, though, none of these big tech companies have made much progress in diversifying their workforces.

In 2014, Apple, one of the largest tech companies by revenue, had 20% women in its technical staff. This increased to only 23% in 2018 (Apple). At Google, the share of US technical employees who are black was 2.0% in 2014 and only rose to 2.8% in 2018 (Google). At Facebook in the US, there were 3% Hispanic technical staff in 2014. Last year there were 3.1% (Facebook).

Continuing our homogenous engineering community is a risk. We are less likely to build products best for our diverse user groups. For example, there have been numerous reports of facial recognition systems misidentifying black people. A US Government study found a top-performing system misidentified black people 5-10x more than white people. In addition, “according to a 2011 study by the National Institute of Standards and Technologies (Nist), facial recognition software is actually more accurate on Asian faces when it’s created by firms in Asian countries, suggesting that who makes the software strongly affects how it works” (Guardian 2017).

Thankfully, there are a number of things you can do in 2020 to contribute to a more diverse engineering community. Building websites in the open, in ways that welcome new people, can have a hugely positive impact on our industry and on the websites that we as an engineering industry produce.

First, how can building open source websites help us welcome new people? You can help with this by being a great open-source citizen and upholding best practices by giving positive and constructive code reviews, keeping documentation up to date and useful, offering help to new contributors and remote pairing with them if at all possible. Some amazing developers like Suz Hinton (@noopkat) live stream their open source contributions, which is phenomenal.

GitHub’s research has shown that documentation is highly valued, but frequently overlooked. As a new contributor, I really value clear and useful documentation, especially on installation, raising a PR and where to get help if I get stuck. Mozilla found that the most significant barrier to engaging in on-ramping others is unclear communications and unfriendly community. Using positive language in your documentation can really encourage first-time contributors to your project. For example, by expressly indicating that you welcome new contributors with instructions on how they can get involved.

We want to create an engineering community highly attractive to under-represented groups. One of the ways that we can do this is by supporting new developers to get a foothold into the profession. There are so many ways we can do this!

The first thing we can do with new developers is to help them by pairing and giving code reviews. Open source projects are perfect for this! By giving constructive code reviews you can help newbies level up their coding skills. You can also set up a Slack channel for your repo where you can answer technical questions. I have met superstar open source heroes who spent time pairing with me, which, if available to you, is an amazing way to help new people.

The greatest challenge I faced when teaching myself to code was finding a job. You can give new developers an insight into your company or your day to day working life by writing an article on Medium, posting a Twitter thread, or making a YouTube video. Some developers offer their own office hours which they do on a live stream or some offer a few one-off mentoring calls with new developers.

Who we welcome into the room to build websites with us says something about who we are and our values. In 2020, let’s welcome new people, especially those from under-represented groups to join us. We’ve discussed how amazing open-source projects are for this and how we can practically contribute to supporting new people. Let’s challenge ourselves to support at least one person from an under-represented group trying to get into the engineering industry in 2020. Together we can change who has the privilege to build the web.

The post How Building in the Open Can Change Our Industry appeared first on CSS-Tricks.


, , ,

Embrace the Political

The tech industry has long held the belief that technology is apolitical. People are flawed, but the machines? They are neutral. They are pure.

This is ridiculous, of course. People make the machines. We write the algorithms that can’t recognize dark skin tones. We decide to downplay or ignore harassment on our platforms. There are a plethora of examples in books like Weapons of Math Destruction by Cathy O’Neill, Technically Wrong by Sara Wachter-Boettcher, and The Internet of Garbage by Sarah Jeong. Technology is political because people are political.

What excites me is that finally, our industry is starting to admit that yes, our work is political. Our work has repercussions. And we can use our talents for good — not just to line the pockets of our capitalist technocrat overlords. And maybe, just maybe, we have a civic duty to engage with politics.

After the 2016 election, several volunteer organizations popped up with the goal of connecting technologists with progressive candidates, whose tech acumen lags seriously behind that of Republicans. I spend a lot of my spare time volunteering for two such organizations, Tech for Campaigns and Ragtag. We get to support candidates and non-profits trying to introduce gun safety legislation, protect women’s healthcare, act to mitigate climate change, and further many more progressive issues.

These are both huge organizations. TFC boasts over 10,000 volunteers. I’ve personally collaborated with easily a hundred other technologists on political or non-profit websites, and digital advertising for candidates across the country. There are so many volunteers that I get ridiculously excited when I see someone I recognize working on a project. Tech feels like a super small industry sometimes, so getting to meet so many new folks I wouldn’t have otherwise gotten to know? That’s gold.

Working with fellow tech folks on these projects gives me so much hope for the future. Everyone I’ve worked with, regardless of background, job, or experience, has been enthusiastic, kind, and dedicated to making a positive difference. It’s such a different vibe from the “I was just doing my job” discourse I see so often on Twitter.

Getting to work with candidates and their staffers is like a whole new world into how grassroots politics works. I’ve learned a lot just by my small measure of involvement. It’s humbling to see how much technology doesn’t matter sometimes, especially with local campaigns where knocking on doors and talking to people face-to-face can make the biggest difference. Not our usual “tech is the most powerful industry” narrative, eh?

To me, new technology is always fun and interesting. But seeing so many people volunteer to support progressive causes? That lights a fire in my gut. That makes me want to keep trudging forward, step by step. Together, we can make a difference.

The post Embrace the Political appeared first on CSS-Tricks.



What the web still is

Being a pessimist is an easy thing to fall back on, and I’m trying to be better about it. As we close the year out, I thought it would be a good exercise to take stock of the state of the web and count our blessings.


We don’t use the internet to do just one thing. With more than two decades of globally interconnected computers, the web allows us to use it for all manner of activity.

This includes platforms, processes, and products that existed before the web came into being, and also previously unimagined concepts and behaviors. Thanks to the web, we can all order takeout the same way we can all watch two women repair a space station in realtime.


There is still no one single arbiter you need to petition to sign off on the validity of your idea, or one accepted path for going about to make it happen. Any website can link out to, or be linked to, without having to pay a tax or file pre-approval paperwork.

While we have seen a consolidation of the services needed to run more sophisticated web apps, you can still put your ideas out for the entire world to see with nothing more than a static HTML page. This fact was, and still is, historically unprecedented.


The internet has been called the most hostile environment to develop for. Someone who works on the web has to consider multiple browsers, the operating systems they are installed on, and all the popular release versions of both. They also need to consider screen size and quality, variable network conditions, different form factors and input modes, third party scripts, etc. This is to say nothing about serving an unknown amount of unknown users, each with their own thoughts, feelings, goals, abilities, motivations, proficiencies, and device modifications.

If you do it right, you can build a website or a web app so that it can survive a lot of damage before it is rendered completely inoperable. Frankly, the fact that the web works at all is nothing short of miraculous.

The failsafes, guardrails, redundancies, and other considerations built into the platform from the packet level on up allow this to happen. Honoring them honors the thought, care, and planning that went into the web’s foundational principles.


Most websites now make use of media queries to ensure their content reads and works well across a staggeringly large amount of devices. This efficient technology choice is fault-tolerant, has a low barrier of entry, and neatly side-steps the myriad problems you get with approaches such as device-sniffing and/or conditionally serving massive piles of JavaScript.

Responsive Design was, and still is revolutionary. It was the right answer, at the right place and time. It elegantly handled the compounding problem of viewport fragmentation as the web transformed from something new and novel into something that is woven into our everyday lives.


In addition to being responsive, the web works across a huge range of form factors, device capabilities, and specialized browsing modes. The post you are currently reading can show up on a laptop, a phone, a Kindle, a TV, a gas station pump, a video game console, a refrigerator, a car, a billboard, an oscilloscope—heck, even a space shuttle (if you’re reading this from space, please, please, please let me know).

It will work with a reading mode that helps a person focus, dark and high contrast modes that will help a person see, and any number of specialized browser extensions that help people get what they need. I have a friend who inverts her entire display to help prevent triggering migraines, and the web just rolls with it. How great is that?

Web content can be read, translated, spoken aloud, copied, clipped, piped into your terminal, forked, remixed, scraped by a robot, output as Braille, and even played as music. You can increase the size of its text, change its font and color, and block parts you don’t want to deal with—all in the service of making it easier for you to consume. That is revolutionary when compared to the media that came before it.

Furthermore, thanks to things like Progressive Web Apps and Web Platform Features, the web now blends seamlessly into desktops and home screens. These features allow web content to behave like traditional apps and are treated as first-class citizens by the operating systems that support them. You don’t even necessarily need to be online for them to work!


The current landscape of accessibility compliance is a depressing state of affairs. WebAIM’s Million report, and subsequent update, highlights this with a sobering level of detail.

Out of the top one million websites sampled, ~98% of home pages had programmatically detectable Web Content Accessibility Guideline (WCAG) errors. This represents a complete, categorical failure of our industry on every conceivable level, from developers and designers, to framework maintainers, all the way up to those who help steer the future of the platform.

And yet.

In that last stubborn two percent lives a promise of the web. Web accessibility—the ability for someone to use a website or web app regardless of their ability or circumstance—grants autonomy. It represents a rare space where a disabled individual may operate free from the immense amount of bias, misunderstanding, and outright hate that is pervasive throughout much of society. This autonomy represents not only freedom for social activities but also employment opportunities for a population that is routinely discriminated against.

There is a ton of work to do, and we do not have the luxury of defeatism. I’m actually optimistic about digital accessibility’s future. Things like Inclusive Design have shifted the conversation away from remediation into a more holistic, proactive approach to product design.

Accessibility, long viewed as an unglamorous topic, has started to appear as a mainstream, top-level theme in conference and workshop circuits, as well as popular industry blogs. Sophisticated automated accessibility checkers can help prevent you from shipping inaccessible code. Design systems are helping to normalize the practice at scale. And most importantly, accessibility practitioners are speaking openly about ableism.


While the average size of a website continues to rise, the fact remains that you can achieve an incredible amount of functionality with a small amount of code. That’s an important thing to keep in mind.

It has never been more affordable to use the web. In the United States, you can buy an internet-ready smartphone for ~$ 40. Emerging markets are adopting feature phones such as the JioPhone (~$ 15 USD) at an incredible rate. This means that access to the world’s information is available to more people—people who traditionally may have never been able to have such a privilege.

Think about it: owning a desktop computer represented having enough steady income to be able to support permanent housing, as well as consistent power and phone service. This created an implicit barrier to entry during the web’s infancy.

The weakening of this barrier opens up unimaginable amounts of opportunity, and is an excellent reminder that the web really is for everyone. With that in mind, it remains vital to keep our payload sizes down. What might be a reflexive CMD + R for you might be an entire week’s worth of data for someone else.


There are more browsers available than I have fingers and toes to count on. This is a good thing. Like any other category of software, each browser is an app that does the same general thing in the same general way, but with specific design decisions made to prioritize different needs and goals.

My favorite browser, Firefox, puts a lot of its attention towards maintaining the privacy and security of its users. Brave is similar in that regard. Both Edge and Safari are bundled with their respective operating systems, and have interfaces geared towards helping the widest range of users browse web content. Browsers like Opera and Vivaldi are geared towards tinkerers, people who like a highly customized browsing experience. Samsung Internet is an alternative browser for Android devices that can integrate with their proprietary hardware. KaiOS and UC browsers provide access to millions of feature phones, helping them to have smartphone-esque functionality. Chrome helps you receive more personalized ads efficiently debug JavaScript.

Browser engine diversity is important as well, although the ecosystem has been getting disturbingly small as of late. The healthy competition multiple engines generates translates directly to the experience becoming better for the most important people in the room: Those who rely on the web to live their everyday lives.

Speaking of people, let’s discuss the web’s quality of diversity and how it applies to them: Our industry, like many others, has historically been plagued by ills such as misogyny, racism, homophobia, transphobia, and classism. However, the fact remains that the ability to solve problems in the digital space represents a rare form of leverage that allows minoritized groups to have upward economic mobility.

If you can’t be motivated by human decency, it’s no secret that more diverse teams perform better. We’ve made good strides in the past few years towards better representation, but there’s still a lot of work to be done.

Listen to, and signal boost the triumphs, frustrations, and fears of the underrepresented in our industry. Internalize their observations and challenge your preconceived notions and biases. Advocate for their right to be in this space. Educate yourself on our industry’s history. Support things like codes of conduct, which do the hard work of modeling and codifying expectations for behavior. All of this helps to push against a toxic status quo and makes the industry better for everyone.


The web is built by consensus, enabling a radical kind of functionality. This interoperability—the ability for different computer systems to be able to exchange information—is built from a set of standards we have all collectively agreed on.

Chances are good that a web document written two decades ago will still work with the latest version of any major browser. Any web document written by someone else—even someone on the opposite side of the globe—will also work. It will also continue to work on browsers and devices that have yet to be invented. I challenge you to name another file format that supports this level of functionality that has an equivalent lifespan.

This futureproofing by way of standardization also allows for a solid foundation of support for whatever comes next. Remember the principle of versatile: It is important to remember that these standards are also not prescriptive. We’re free to take these building blocks use arrange them in a near-infinite number of ways.


Furthermore, this consensus is transparent. While the process may seem slow sometimes, it is worth highlighting the fact that the process is highly transparent. Anyone who is invested may follow, and contribute to web standards, warts and all.

It’s this openness that helps to prevent things like hidden agendas, privatization, lock-in, and disproportionate influence from consolidating power. Open-source software and protocols and, most importantly, large-scale cooperation also sustain the web platform’s long-term growth and health. Think of web technologies that didn’t make it: Flash, Silverlight, ActiveX, etc. All closed, for-profit, brittle, and private.

It also helps to disincentive more abstract threats, things like adversarial interoperability and failure to disclose vulnerabilities. These kinds of hazards are a good thing to remember any time you find yourself frustrated with the platform.

Make no mistake: I feel a lot of what makes the web great is actively being dismantled, either inadvertently or deliberately. But as I mentioned earlier, cynicism is easy. My wish for next year? That all the qualities mentioned here are still present. My New Year’s resolution? To help ensure it.

The post What the web still is appeared first on CSS-Tricks.



Embracing the Universal Web

There are constantly new features appearing in browsers—from subgrid to variable fonts to better developer tools. It’s a really great time to be re-thinking everything we know about design on the web. Responsive design has served us well over the years, but it’s still rooted in the limitations of the web from 2010. Ten years later, we’re able to create more “Intrinsic” designs (a term coined by Jen Simmons) and hopefully, re-think some “best practices” that are now holding us back.

That’s exciting but even more interesting to me in the context of a universal web. I began my career during the height of the Web Standards Project, CSS Zen Garden, Designing with Web Standards, and A Dao of Web Design—saturated in the philosophy of universally accessible design. CSS was relatively new, and explicitly designed to balance the desires of a web-creator (like me) with the needs of each individual user (also me), on any number of devices. Terms like “progressive enhancement” and “unobtrusive JavaScript” dominated the industry. We were moving away from “only works in X browser” warnings, to embrace an accessible and resilient user-centered medium.

Over the years, some of those concerns have become industry best-practice. CSS is now standard, and responsive design is the norm. But I also see (and build!) more and more apps targeted at a narrow range of modern, evergreen browsers. Or we ignore new features for years in order to support a browser like IE11. We’ve become resigned to a sense that browser support is binary, and we can only use the features that exactly match our “supported” browsers.

There are many reasons for that shift, including excitement around very cool new features. I don’t think it’s surprising for an industry to have these cycles, but I do think it’s time to reflect on where we’re heading. These new features are designed with universal accessibility in mind, and we also have new features for managing browser-support on a continuum, much like viewport-size.

Whatever we want to call it—Intrinsic Design, Resilient CSS, Progressive Enhancement, Universal Accessibility, or something else—I think we’re poised for a new movement and a new era of web creation. It’s time for us to take the lessons we learned from Responsive Web Design, adapting to screen sizes, and expand out: adapting to screen readers, legacy browsers, “smart” speakers, and any number of other interfaces.

I’m interested in new methodologies and conventions that move past managing specificity and cascade, or phones and laptops, to help us all manage accessibility and universal compatibility. I’m interested in finding ways to embrace all that is wonderful and new on the web, without abandoning the beautiful vision of a universal web. We have the tools. Let’s do this.

The post Embracing the Universal Web appeared first on CSS-Tricks.



Create Amazingly Stable Tests Your Way — Coded and Code-Less

Testim’s end-to-end test automation delivers the speed and stability of AI-based codeless tests, with the power of code. You get the flexibility to record or code tests, run on third-party grids, fit your workflow and tools including CI, Git and more. Join the Dev Kit beta to start writing stable tests in code.

About Testim

At Testim, we too are developers and testers, striving to release quality software faster. We built Testim because writing stable end-to-end tests was just too hard. We were the first to build an AI-based functional test automation solution. Since we launched in 2014, we’ve been adding features, improving quality, and proving our solution with customers every day.

Create tests your way

There are two ways to create tests in Testim — record them using the Testim Extension or code them in your IDE. Actually, there’s a third and recommended approach for those who want to code—record the test, export it as code and modify it in your IDE.

When you record a test, each UI action leverages our AI-based platform to analyze the DOM, weigh the attributes associated with an element and create Smart Locators that uniquely identify elements. If attributes such as the color, class, text or location of an element are changed by development, our AI will still be able to uniquely identify the element so that your test doesn’t fail.

Customize tests

Testim has many features built into the visual test editor to help you customize your tests such as validation of text, email, PDFs, or conditions and loops. You can also insert JavaScript into any step so that you can handle nearly any UI situation.

If you are into JavaScript, you can also export your test as code and customize, debug, or refactor it your IDE; the choice is yours.

Execute your cross-browser tests

When your tests are ready, you can run on-demand or schedule a test run within Testim. We also make it really easy to run your test following a CI action. Tests can be parallelized and across all browsers on our test cloud or any Selenium-compatible test cloud.

Report results

Regardless of how your tests were created (code or codeless) when they run, you will see the results in Testim so you can troubleshoot. If you find an application defect, our bug capture tool makes it really easy to create a bug report, complete with screenshots, video and the test steps to recreate it. Pop it into Jira or Trello to submit your report in minutes. Our reporting shows test run history, including managerial reports so you can show all of the great work you’ve been doing and that releases are ready to ship.

Testim is the fastest way to create your most resilient end-to-end tests, your way—codeless, coded or both. For more information go to www.testim.io.

The post Create Amazingly Stable Tests Your Way — Coded and Code-Less appeared first on CSS-Tricks.


, , , , ,

Emcee Tips for a Conference or Meetup

There are some great resources out there to help conference speakers give better talks, but fewer for people who are preparing to take on the role of emcee at meetup or conference.

I’ve been fortunate enough to emcee conferences more than 20 times now, most recently JAMstack_conf which I help organize. I also enjoy hosting smaller, less formal meetups which benefit just as much from having somebody to keep things rolling nicely along.

Since emcee-ing is a rather visible role, I often get asked, “Got any tips for emcee-ing?” I do. At the same time, note that there is no substitute for finding the approach that fits you and lets you be yourself. But I’ve found what works for me, and what I enjoy in an emcee when I’m attending or speaking at a conference.

Here’s my advice:

Biggest tip: Enjoy yourself.

I find that trying to relax (yeah, easy to say) and remembering that the audience want you to succeed really helps. When you remember that you’re not hosting the Oscars (if you are reading this in preparation for hosting the Oscars, please contact me directly. DMs are open), and that people are very happy with you being human and personable, it gives you license to relax and talk to the room as if everyone is your friend. That’s liberating and helps you to be more natural.

The crowd’s view of the stage at Vue.js London. Image copyright www.edtelling.com.

To err is human

While we all want things to run as smoothly as possible, mistakes happen. Don’t panic or let them throw you off too much. I find that owning mistakes and communicating them honestly to the audience can be a feature rather than a bug. It also helps them trust you and be on your side. (I believe that there is only one “side” at a conference anyway. And this can help to establish that.)

Many of the moments I consider highlights have come from some silly mistake I’ve made on stage, like giving the wrong information and being corrected by the audience. It’s fine. We’re in it together. Have a little fun with it.

Technical difficulties

It’s really common for there to be technical difficulties during a conference. They often only take a few moments to resolve, but they can occasionally drag on and become a little uncomfortable.

As a speaker it is horrible to think that you are on your own to fix things while a room full of people impatiently watches on. As an emcee, you can help enormously by being ready to jump in if it looks like things might need some time and concentration from the speaker, or if a helpful member of the audio-visual team is sprinting to the stage.

I like to step back on the stage to provide a little buffer. No need to panic. Often just a little company on stage and some headspace is all that is required. My trick is to keep a little pocket-sized notebook on me all day. I keep a few notes ready, things like news and announcements for the audience. Where will the refreshments be later? Who are the sponsors and where can you find them? What are the details for the social later on? Those kinds of things. You may need them at the start of the next break anyway, but you can buy a little time for the speakers and save time for later by being ready to share that at this “handy opportunity.”

“Me again! We’ll get this fixed in a second. While we have a mo…”

Even when there isn’t a problem, the speaker might still take a little time to plug in their laptop, be certain that they can see their speaker notes, and so on. If the conference does need each speaker to plug in as they come to the stage, I like to invite them up while I introduce them, and then check that they are ready when it looks like they have stopped tinkering with their setup. This doesn’t need to be a secret from the audience. “It looks like Jina is ready to go. Are you all set? Excellent! OK, a big round of applause please, for…”

Longer pauses. Oh this is getting awwwwwkward!

Every once in a while, there is a larger technical issue. The audio-visual team is on it, but you’ve used up all your padding material, pulled a couple of jokes from your back pocket, and now you and the speaker are stranded on stage with nothing to say and that horrible feeling of not knowing where to put your hands so that you look natural. Not to worry. Be honest.

Eventually the audience will start to feel awkward too, so cut this off at the pass. If things look like they really do need a few minutes, tell the audience. A bright and breezy update buys you some time and some good will.

“It looks like we still need a couple more minutes to figure this out, so we’ll step off stage for a moment and then come on again to enjoy a second, bonus round of applause. Don’t go anywhere, we’ll be right back!”

This sort of thing can take the pressure off everyone. Including the audience. And you can milk that second round of applause for the speaker as they return.

Just be honest. Everyone is on your side, remember.

Practice all the names

A mistake that makes me uncomfortable is botching somebody’s name when I introduce them. That is a bit of a fear I still have and I’ve done it many times despite my best efforts. I like to watch YouTube videos of all the speakers that I don’t already know to get a sense of what they’ve spoken about in the past, and also as a chance to listen to how they introduce themselves. I practice them out loud and write them down phonetically if they are tricky.

If you find a name particularly difficult, you can even use the voice recorder on your phone to capture how they pronounce it on YouTube, or your own best try, and then have it ready as a last-minute primer just before you need it.

Know more than the speaker’s bio

Speakers often get introduced by someone reading out their bio. I don’t think this gives the impression that you have enthusiasm for, or awareness of them. Both of which are, I think, valuable for creating trust with the audience and comfort for the speaker. I like to look them up and make some notes based on previous talks, the links on their own sites, or whatever else I can scrounge. I like to have an intro that goes beyond the bio that the attendees all have and will recognize as being read verbatim when they hear it.

Introducing Divya Sasidharan onstage at Vue.js London. Image copyright www.edtelling.com.

Jake has a good thought related to this:

… it shouldn’t matter if the speaker has published 18 books, or if they’re just an intern starting out their career, their talk content is what matters.

Yes! Listing their full resume isn’t the point at all. I personally just like to convey that I know who this is, and that I’m not encountering them for the first time as I read the schedule — and that I’m looking forward to hearing what they have to say, irrespective of how extensive their previous experience or fame may be.

It’s also worth double-checking that the job title and company details you have for somebody are still correct. It’s nice to make sure that you didn’t miss a recent role change.

Another good nugget from Jake is to avoid surprising the speaker. I’ve wandered into this territory before where I’ve enthused about a speaker in their introduction and mentioned a bunch of things that they were planning to say for themselves in their intro. As he says:

Make the speaker aware of the kind of intro they’ll get, so they can adjust their own intro accordingly.

That’s good. Communicating with the speaker ahead of time so that you can tune your own intro is likely to be easier than them adjusting their own content, what with slides and timings, etc.

“No surprises” is probably a good motto for this.

Avoid “in jokes”

When you emcee, you might sometimes be introducing somebody you know. Perhaps it’s a friend, a colleague, or somebody you shared a nice chat and giggle with at the reception or dinner the night before. While I think it’s fine to reference a history or relationship in an intro for context, It’s safer to focus on things that everyone can relate to and not just those who already know you or the speaker.

Private jokes don’t mean anything to the vast majority of the audience, and can even alienate you a little by creating a bit of a clique as Jan thoughtfully mentioned on Twitter.

Don’t assume or rely on “fame”

“This next speaker needs no introduction” is rarely true. Even if it’s likely that a lot of people in the room might already know who a given speaker is, there will be some who don’t.

As Luke observed:

Don’t assume the audience knows who the speaker is.

Each speaker deserves a nice introduction. And there will always be some in the audience thinking “who dis?” Even a little background can be a helpful foundation and give the speaker a nice springboard to get started.

Announce and thank people with vigor

I’ve been introduced quite a few times in ways where I’ve been unsure whether the intro is over or not! I like to be sure that the final thing I say is the name of the speaker. (Not their talk title, although I’ll likely mention that and possibly the themes in my introduction.)

An onstage introduction at Vue.js London. Image copyright www.edtelling.com.

Ending the intro with the speaker’s name seems painfully obvious, but I do this even if I’ve used their name earlier in the intro. It makes the handoff emphatic and acts as an obvious cue for audience applause. Using an intonation which suggests “it’s time to clap right now!” is also helpful. Again, it seems obvious but giving the audience clear cues is important.

Let the speakers give the talks

You might sometimes be opinionated about the topic of the next talk. Maybe you’ve given talks on the same subject yourself. Great, that will come in handy if you need to ask informed questions after the talk. But don’t fall into the temptation to show this off during your intro. The speakers are “the show” — not the emcee. And the person you are introducing is the one invited to share their expertise.

I sometimes show I value the upcoming topic, but I advise against flexing your knowledge muscles during an intro. You might cannibalize the content, or even contradict it. And you’ll never communicate it in an intro as well as the speaker can during the actual talk. You might come off as being cocky.

Don’t step on the speaker’s toes. Let them present the content. This is why everyone is here.

Prep speakers for questions and answers

If there is Q&A that you’ll need to lead or curate, it’s important to know that in advance. It is one of the first things I’ll ask the organizer in the run up to a conference. I like to ask the speakers at the speaker dinner the night before the event or when they are getting mic’d up (but earlier really is better, especially when they have time to think while being relaxed) if there is anything they’d like me to ask or avoid saying altogether. There are often things people can’t include due to time and this can be a chance to squeeze that in and also serve as a nice soft ball question to get things started and let them settle in.

Some speakers might not want to take questions. I like to make sure about that first, and steer the event organizers away from it if somebody prefers not to have it.

Housekeeping is a good boilerplate

At the opening of the day, I usually jump quickly into the various housekeeping stuff of toilets, exits, code of conduct, etc. soon after saying my initial hello and maintain an enthusiastic posture about the day. It doesn’t require much imagination and can help you settle in.

Don’t forget to introduce yourself too!

Ask the organizers what they need

Along the way, there might be a need to mention sponsors, inform people of food, or even other things. I like to check in with the organizers at every break to see if there is anything they need me to announce. Maybe there can be a private Slack channel or Whatsapp group so you can stay in contact with them. That way you can find out if they need to adjust timings or any other odds and ends as you go.

Most of all though, and to repeat my first point a little, allow yourself to enjoy the experience. It’s so much fun when the speakers and audience are enjoying themselves.

Make sure you ride that wave and have fun too!

My checklist

I have this little checklist as a starting point for the events I’ll be emcee-ing. It changes a bit depending on what the conference needs.

Prep speaker intro notes
Prep speaker name pronunciation notes
Confirm format for Q&A with organizers
Prep seed questions for each talk
Share event notes Google Doc with organizers
Access/create emcee slack channel or WhatsApp group
Confirm or create event intro/outro slides if appropriate
Get housekeeping notes from organizers
Get familiar with code of conduct and contact info to share
Confirm event hashtags to share
Get sponsor call-out requirements from organizers
Meet AV team and discuss transition format
Brief speakers on transition format and get ok for questions
Get water / pen / notepad / mic
Breath. Smile. Have fun.

What have I missed? Got any good tips? I’d love to hear them. Feel free to leave thoughts and suggestions in the comments.

The post Emcee Tips for a Conference or Meetup appeared first on CSS-Tricks.


, , ,

Humorous Pixel Art in the Streets by a Swedish Artist


It’s my job, and yours.

The role of ethics in our modern web space has been on my mind for the past few years and I suspect it will occupy my thoughts increasingly as I move forward. With each encounter of a questionable feature or setting on a website, I can’t help but think of all of the people involved and the discussions that may (or may not) have taken place.

Marketing has always straddled the line between promoting a product to an open and willing target audience and outright manipulating those who don’t need it (have you watched toy commercials with a young child lately?). For better or worse, persuasion in marketing has proven to be effective. Fortunately, it is fairly easy to spot an advertisement, even when disguised as sponsored content or product placement. This is what sets marketing apart from some of the more hidden aspects that are built into the apps and sites we use every day.

Many of the discussions surrounding design ethics are focused on privacy, data collection, and analysis by mega-companies and social networks. While there are many unsolved issues in this space, I hope we don’t limit our thoughts and conversations to these global apps. In fact, the smaller the product or company for which you are working, chances are the bigger impact you will have. With that in mind, let’s explore some ways we can be more mindful when creating our next product.

Research and Communication

Fundamental to the design and development of anything we publish is research and communication. Asking yourself or your team a series of questions may help facilitate important conversations and decisions. These may include:

  • Why are we creating this?
  • Who is most affected by this?
  • What outcomes should we consider?
  • Could we do better? How?
  • Could this cause harm?

While unintended consequences are unavoidable by nature, thinking through these questions upfront could help avoid negative impacts later.

Consider Your Team

A team of people with diverse backgrounds and life experiences can contribute to building a more thoughtful product. When creating something for a wide variety of people, it is best to include a wide variety of people throughout that build process. If your team is small (I was a team of 1 for many years), then try to do usability testing and research with people who don’t necessarily have your same background, interests, and career.

Consider Your Role

Ethics in design isn’t only about the things you create, but it is also carried out in the conversations you have. Informing your boss or client that the feature they requested isn’t ideal can be undesirable, but it is your responsibility to tell them why and what, if anything, could be done to make it better. It is almost always easier to complete a list of requests rather than explore options and present a case for why and how something else should be considered. You were hired for your expertise.

What’s Your Legacy?

While not everyone has the luxury of having their dream job or working on an ideal project, it is important for me to be able to look back at the end of the day and be proud of the work I have done. Is your work helping others? Are you creating something that makes this world a better place? If so, I’d love to hear more about it.

So, when asked what about building websites has you interested this year? the role of ethics in the design and development of the things we use every day weighs heavy on my thoughts.

Also, variable fonts.

If you are interested in learning more about Ethic in Design, here are some resources that I recommend:

The post It’s my job, and yours. appeared first on CSS-Tricks.



The future is bright, because the future is static

I’ve been doing this web thing for money for 10 years this year and although I haven’t been around as long as some folks, I feel like I’ve seen a few cycles come and go now, so let’s say that hot new things are often cynically viewed, initially. This milestone of mine has also got me in a retrospective mood, too, and the question “What about building websites has you interested this year?“ has only encouraged that.

When I first came into the industry, I was an out-and-out designer, delivering static comps to developers until after one-too-many poor builds of my work: I decided to get into code myself. Naturally I focused purely on the front-end—specifically HTML and CSS. Yes, I got a bit into JavaScript too (once Flash became fully irrelevant), but markup and styles have always been my favorite things about web technology. I’ve never really been into back-end development, either. Sure, I can do it, but it’s certainly not my strong suit and usually this weakens my offering a touch—especially as a freelance web designer. Well, it did weaken me, until now.

JAMstack: an awful name, but awfully empowering.

I love JAMstack because it empowers people like me, who aren’t very strong with back-end stuff, and the aspect of JAMstack that I like the most—and which I think is the best part—is static site generators (SSGs). I’m talking specifically about SSGs like Eleventy and less-so Gatsby here, for reference.

The biggest reason that I like SSGs like Eleventy is that I can have a completely flexible, component-driven codebase that at build-time, compiles down to nothing but lovely, static HTML. You still get the power of JavaScript too, but instead of forcing it down the pipe, you run it at compile-time. This has enabled me to do some pretty darn complex stuff. Eleventy does all of this at lightning speed, too.

Mix Eleventy with Netlify and in some cases, Heroku, and suddenly you have a powerful development setup which results in a fast, performant website that auto-deploys. It’s perfect setup for me.

This stuff excites me so much that I made an Eleventy starter kit this year called Hylia. I did this for two reasons:

  1. I wanted to test the viability of a content-managed static-site that uses source controlled content. I chose Netlify CMS to do this
  2. I wanted to empower people without tech skills to publish a performant, accessible blog of their own, so they didn’t have to rely on centralised systems

The platform went down really well and I think part of the reason for its success is that even though it’s (optionally) content managed, powered by design tokens and fully componentized, it performs really well because all you get is HTML and CSS with a bit of progressively enhanced JavaScript.

This is the magic of SSGs, because they give us developer experience, but much more importantly, because the output is static and lightweight (unless you prevent that with lots of code), it creates a really solid basis for a good user experience, too! This isn’t just the case for small projects like Hylia, too, because SSGs can even power huge projects like the Duet Design System, for example.

Looking back at the empowerment that SSGs enable, I’ll just list some things that they have enabled me, a web designer, to do this year:

  • Self-publish a book
  • Create rapid, interactive prototypes for clients which has completely transformed the decision making process
  • Build actual, full websites for clients
  • Completely transform my design process to use HTML and CSS as a deliverables, rather than static comps
  • Build and document an incredibly comprehensive, multi-platform design system (WIP)
  • Re-platform my CSS newsletter (WIP)

These are huge things that have had a massive, positive impact on me and next year, SSGs are only going to feature more in my work as I transition into providing educational material, too.

Wrapping up

The future is bright with the JAMstack and SSGs—especially when what is delivered to the end-user is fast, progressively enhanced websites. I honestly think that they are creating a momentum wave towards a bigger focus in performance, too.

If we chuck in some serverless technology: suddenly, designers and front-end developers really are all powerful and this really excites me because suddenly, we give lots of people power to have great ideas that might not have been able to before.

The post The future is bright, because the future is static appeared first on CSS-Tricks.


, , ,