The bigger the design system, the more chances it will have to move across cultures—to go global. With globalization comes the need to adjust content, branding, and design strategy to accommodate new languages, nationalities, and cultures.
This process is called internationalization—designing or updating your websites and products so they don’t contain any cultural-specific attributes. Internationalization (which is sometimes referred to as i18n) does not mean your digital experiences have to become hollow and boring; it means making them as flexible as possible so they can function well across various cultures. Mozilla explains that the process of internationalization
involves identifying the locales that must be supported, designing features which support those locales, and writing code that functions equally well in any of the supported locales. (http://bkaprt.com/ccd/06-01/)
Want to see a glimpse of the scope of work? Go to the Internationalization checker from the W3c and plug in the URL to one of your sites (http://bkaprt.com/ccd/06-02/). It will test your character encoding, language declarations, and Unicode to gauge your level of internationalization-friendliness.
[m]odifying or adapting a software product to fit the requirements of a particular locale. This process includes (but may not be limited to) translating the user interface, documentation and packaging, changing dialog box geometries, customizing features (if necessary), and testing the translated product to ensure that it still works (at least as well as the original). (http://bkaprt.com/ccd/06-01/)
In other words, internationalization is about making sure your product can go anywhere; localization is about preparing it to go somewhere. Localization means changing interface structures, altering stylesheets and layouts, revising copy and language, and adapting and augmenting your site for your specific cross-cultural audience.
Internationalization and localization processes are a lot of work; don’t take them lightly! I have worked on all sorts of localization projects, and it never ceases to amaze me how complicated they get, and how quickly. You need a team with project management experience, designers and content strategists who know what they are doing, structures in place to work with the demands of multilanguage content development, and close coordination with business stakeholders. Oh, and a budget. You’ll definitely need a budget.
Okay. I hope I have scared you a little bit. This chapter goes over just a few of the things you will need to consider when localizing your design systems and digital experiences, such as:
- Designing for second-language speakers
I find it fascinating how so much language has similar, but not quite identical, patterns. All humans, for instance, have names, but their order, complexity, and rules for use can change in every culture. Dates always reference a single point in our annual journey around the sun but may be presented in a different order, called by different names, or measured by different calendars.
When I talk about formatting, I’m highlighting the parts of localization that require you to take that information and change the order, organization, or view of it to make it accessible to different cultures.
- Name order: Which name comes first—the family name or the given name? When I lived in Japan, my given name, Senongo, was often assumed to be my family name, because it is customary for family names to come first; I had to remember to use Akpem first on official documents and in formal situations. Make sure your form fields reflect the name order your audience uses when designing for the web.
- Name letters and lengths: Does your system account for the different characters and lengths of people’s names? My oldest friend in the world, someone I have known since I was eight, is the son of a Yoruba-speaking Nigerian father and an American mother; he has four names with a total of twenty letters. Meanwhile, one of my coworkers has a last name with just two letters. Names may also include letters with accents, tildes, cedillas, and other diacritical marks. As you plan your interface, keep these international variables in mind, and make sure your system accepts them. Check out the Multicultural Names plugin for Sketch, for a cue to how we can automate a bit of that in our design comps (http://bkaprt.com/ccd/06-03).
- Postal codes: Does your UI support the postal codes your target audience uses? For example, postal codes in Bangladesh are four-digit numbers (like 1305), while Canadian codes are a combination of letters and numbers (like N8N 4Y0). Any form or address input should account for these variations.
- Formatting addresses: Do the order and labels on address fields conform to how your audience writes? Both Canadian and Japanese address forms require the same information (like a street address, a postal code, and an addressee name), but the information is requested and displayed in a different order (Fig 6.1).
- State/Region/Provinces: Are things like states and provinces correctly accessible in form fields or in content? Etsy’s shipping form prefills the thirteen Canadian provinces and territories, making the form both more personalized and easier to complete (Fig 6.1).
What comes first in a date? The day, the month, or the year? In “13 tips for making responsive web design multi-lingual,” Tom Maslen, then a developer at the BBC, wrote extensively on localization formatting (http://bkaprt.com/ccd/06-04/). He noted that, for many languages, it’s not just a matter of swapping months and days (Fig 6.2):
- The Chinese date format labels each part of the date [such as] “Day 5 Month 10 Year 2014”. Numerals are used in the Chinese date format because they require fewer characters than the Chinese alternatives. It’s convention to use numerals when displaying Chinese horizontally. When displayed vertically it is convention to use the Chinese characters.
- Though Persian and Pashto use different characters, they display both the Western calendar and the Iranian calendar together.
- Arabic shows two versions of the month name using a forward slash as a divider.
When you have to show multiple date formats on your site, you can start by storing the date in UTC (Coordinated Universal Time), since that can be converted to something readable and localized. UTC will look something like this: 2018-11-04T10:15:06+00:00. You can then take that and reformat it in your page templates, so that it conforms to whatever way your audience reads dates.
- Inauspicious numbers: Certain numbers are unlucky in almost every society. While I lived in Japan, I quickly learned that the number four was inauspicious. One of its pronunciations, shi (四), is the same sound as the word for death, shi (死). In Christian societies, 666 is considered to be the mark of the Devil, so a hotel room with that number or a product with a price of $6.66 tends to be frowned upon.
- Currency presentation: How do you give people the ability to shop or browse using a currency they are familiar with? I really like the way Etsy handles its currency layer—customers have the option to select the country, language, and currency, since those three things can be different (Fig 6.3).
- Multicurrency: How do you show currency? Seeing currency exchange rates is extremely important for people who frequently send money back to their native country to support their family (also known as the global remittance market). For reference, almost three percent of India’s annual GDP is remittances (http://bkaprt.com/ccd/06-05/)! List the exchange rates when designing interfaces that need to show more than one currency, making note of whether the rate displayed is official or calculated by the business. Western Union, the global money-transfer company, clearly lists its exchange rates next to the currency amounts and codes (Fig 6.4). Presented with this information, senders see exactly how much money their family members will receive. (And for people interested in economics, it also acts as a rough measure of the financial health of their home country!)
- Tax/Value-Added Tax (VAT): How are taxes displayed? There are numerous legal and social requirements around taxes, so be intentional with their presentation. For instance, Bahrain charges five percent VAT for digital products. Suddenly getting hit with a new tax after going through the whole checkout process increases the chance that customers will abandon their carts. Clearly displaying that information before checkout will result in a smoother user experience and, therefore, more sales.
One of the biggest layout challenges you will face when localizing your sites and apps is what to do when dealing with right-to-left (RTL) languages such as Arabic and Hebrew. Mustafa Kurtuldu, a senior UX designer at Google, told me that Material Design, Google’s design language and interaction framework, recommends “mirroring” certain UI elements in RTL layouts (Fig 6.5) (http://bkaprt.com/ccd/06-06/). For instance:
- Headers, labels, and text should read from right to left.
- Navigation buttons should be reversed, but icons that don’t indicate direction should not be.
- Checkboxes should appear to the right of their label.
- Progress bars should fill from right to left.
But let’s take a closer look at managing icons and text in RTL layouts.
While the decision to mirror your icons will depend on what you uncover in your research and usability testing, there are a few general rules of thumb:
- Mirror icons that indicate time, motion, or direction. Icons for ideas like calendars (time), email replies (motion), and text justification (direction) all make sense to mirror. Microsoft’s UI Fabric system shows directional icons that will automatically be mirrored in their RTL stylesheet (Fig 6.6) (http://bkaprt.com/ccd/06-07/).
- Don’t mirror video UI. Yes, this is an exception to the last rule, but there is a good reason for it. The LTR video UI has been used for a long time, since the days of portable Walkmans and VCRs, so it’s a known convention in cultures that read RTL. Also, unless you are planning to design and develop your own media player, you will likely be embedding from YouTube or Vimeo, so you have no choice anyway! The BBC’s media player, for example, shows the play/pause, volume, scrubber, and other icons in an LTR configuration, even on an Arabic-language page (Fig 6.7).
- Leave icons that don’t communicate direction as is. It is a waste of your time to flip the orientation on everything, especially if it does not increase comprehension. Icons for a coffee cup or keyboard will not become any clearer to an RTL audience by being reversed. Spend your precious time and attention on other, larger directionality issues.
It’s important to note that your browser knows if a sequence of characters is supposed to be LTR or RTL out of the box. It uses something called the bidi (as in, bidirectional) algorithm (http://bkaprt.com/ccd/06-08/). Luckily, each character in Unicode has an assigned directional property:
- The majority of Unicode characters for a language are defined as strong, meaning they have explicit directionality. They are very opinionated and will always appear LTR or RTL, based on their language’s direction.
- Unicode characters and symbols that can appear in both LTR and RTL scripts, such as punctuation, are defined as weak, meaning they inherit the directionality of the character just before them. They follow the leader.
- Neutral characters, like tabs and new line characters, are happy to go with the crowd and inherit the direction of the characters surrounding them.
dir is a global HTML attribute that sets the base display direction for text. The attribute accepts one of three values:
auto. If you don’t specify a direction for your document or element, it will default to
ltr. If you want your text to respect the strong/weak directionality mentioned above, you should make sure
dir is set to
You can put it on the
html element of a document to control the whole thing, but it’s not strictly a global element. You should add the attribute to specific elements when you need to—for example, when a page is in one language, but a name or phrase is in a different one.
Sometimes, the bidi algorithm makes funny things happen with text, as Spotify discovered when they were localizing for an Arabic audience. The base direction of the page was set as
<html dir=”rtl”>, which takes care of the Arabic, but the directional properties of the Latin text and punctuation were not defined. As a result, some song titles came out a bit funky (Fig 6.8). Tryggvi Gylfason, a software engineer at Spotify, outlined why this happened (http://bkaprt.com/ccd/06-09/).
The browser saw the base direction for the Arabic language page was RTL, and so took “Let It Be (Remastered),” the original text string, and began parsing it from right to left. However, in that reversed song title, the weakly typed “)” came first, so it got flipped to the other side. “Let It Be (Remastered)” became “(Let It Be (Remastered.” In this case, it’s not the end of the world, but it illustrates how picky the bidi algorithm can get when we need text to come together.
In order to prevent things like this in mixed-text situations, try to set the direction on the specific text element in question, such as
<h2 dir=”auto” class=”song-title”>Let It Be (Remastered)</h2>, so that the browser does not have to infer directionality from the page level or the bidi algorithm. You can check out this fork of a CodePen provided by Mat Marquis to see more of how this functions (http://bkaprt.com/ccd/06-10/).
Rwanda is a small but increasingly important country in central Africa, about the same size as Massachusetts or Lebanon. Since a devastating civil war in the early 1990s, where almost one million people were killed in a genocide, the country has worked hard to recover from those atrocities by changing its social dynamics and attracting foreign investment (not aid) (http://bkaprt.com/ccd/06-11/). Almost the entire country speaks Kinyarwanda, and until 1994, the other official languages were French (a holdover from the colonial era) and Swahili. English was added as an official language in 2008.
This means there is a whole generation of Rwandans who have grown up speaking English as a national language; designing digital experiences for young professionals would mean crafting them in English, the language of business. But experiences for earlier generations would likely need to include Kinyarwanda, French, and Swahili. Every language decision for the Rwandan market requires understanding its historical context.
Translation is thoughtful and difficult work. Without knowing a culture’s linguistic history, you run the risk of your project being, at best, ineffective—and, at worst, insulting. There are different levels of complexity in any translation work. As you read on, think about the costs and benefits of each level and what they will mean for your upcoming project.
The costs of translation
Effective translation works across technology, staff, and strategy. The cost of translation multiplies fast.
The technology you use (and its ease of development) is the first cost you will need to consider. Ask yourself if you have the technical skill within your team or if you will need to hire a developer to set up your CMS and backend systems to handle translated content. Then there may be costs to buy plugins, domains, or other licensed software, such as webfonts with special Latin characters or in CJK languages, needed to create the digital experiences.
The second cost is paying for the translated material. Using a professional translator is one option. For context, using the Gengo professional translation platform, translating a single blog post of 7000 words from English to Danish would cost about US$700, and English to Dutch would cost around US$600 (http://bkaprt.com/ccd/06-12/).
The third cost is your team’s time—in coordination, project management, design, quality assurance (QA), and a myriad of other small tasks. As I said, things can add up fast. Let’s take a look at three alternative options, then, for localizing content—from simpler to more complex.
Using the browser’s ability to translate text is one option for translation. I often use the Google Translate feature when I want to quickly understand what a website is about. Machine translation can be useful for giving users an overall understanding of your page content. It doesn’t need to be exact, especially if you’re designing on a budget.
The downside of machine translation is that the computer will inevitably get it wrong, sometimes in embarrassing ways. In 2017, writer Alex Shams posted examples of how Google’s translation algorithm returned gendered results when translating gender-neutral language (http://bkaprt.com/ccd/06-13/). The team behind Google Translate originally decided to provide only one translation for each search query, even if there was a masculine and feminine form of the word. As they designed it, their algorithm was biased toward making words like “doctor” masculine and words like “nurse” feminine. An innocent mistake, of course, which no one ever in the history of language or tech could have foreseen. Ever.
They started fixing this “mistake” in 2018; some languages (French, Italian, Portuguese, and Spanish) began showing both feminine and masculine translations for single words (http://bkaprt.com/ccd/06-14/). Now, typing “o bir doktor” in Turkish will show both “She is a doctor” and “He is a doctor.” (Fig 6.9).
Even if this quick route is acceptable to you, be aware that machine translations will not—by virtue of their simplicity and lack of empathy—be able to replicate the nuance of your brand language or designed experience. There’s also no guarantee that your audience will have the latest version of Chrome installed or that they know to use the browser’s translation tools. If you plan to rely on the browser to translate your content, be aware that there are a number of technical considerations you will need to account for. I won’t get into it here, but there is a wealth of information online to help you get started (http://bkaprt.com/ccd/06-15/).
I recommend doing it the right way—using human translation services.
Simplified translated content
As you can probably tell, I’m a huge fan of culture, history, and art. I got the chance to visit Paris for the first time in 2015, and the only place on my bucket list was the musée du quai Branly–Jacques Chirac. The museum holds 300,000 works from Africa, Asia, Oceania, and the Americas; the place is full of photos, sculpture, textiles, masks, and art spanning the history of the world from the Neolithic age to the twentieth century.
The Branly site takes it a step further when it comes to access for different languages (http://bkaprt.com/ccd/06-16/). They fully translate the site for three major visitor languages: English, French, and Spanish. If you’re not fluent in those languages, you can also access a series of downloadable PDFs in 中国, 日本語, Deutsch, Italiano, Portuguese, and العَرَبِية that include museum information and exhibit descriptions (Fig 6.10).
For a national institution of this size, with shifting exhibits and marketing campaigns, getting accurate information in nine different languages is a real challenge. The simplified content translations are a reasonable stopgap, providing critical content like museum hours in more languages than they would otherwise be able to. That said, I’m not sure that the production process of designing, creating, and uploading forty-one individual PDFs is more efficient than publishing HTML pages.
If you aren’t able to pay for full translation services but want to control translation more than with browser translation, the Branly model could be a good option. Fully translate what is most critical for your audience, if possible; at the very least, localize a simplified version of the content. My strong recommendation would be to do this with a web page instead of a PDF. HTML is inherently more flexible, searchable, and accessible, making it a good solution for a global audience. These simplified page templates need little else besides a header, footer, and a WYSIWYG text editor area to add in text and image. That frees your team up to not worry about using any complex layouts or HTML structures in other parts of your site, and instead just have the bare bones of what you are trying to communicate.
Original localized content
Your third option for translation is to hire professional translators. On the extreme end, that would mean completely translating your entire website, word for word. In other cases, just translating the words on your site won’t be enough. It may be linguistically correct but won’t necessarily take into account cultural or marketing needs. To create a truly localized experience, you may need to write and design new content developed in the target language. This doesn’t need to break the bank. In fact, it can even result in more effective, culturally relevant content for your audience.
In 2018, at ComNet, the annual conference of the Communications Network, I attended a workshop by Danielle M. Reyes and Dr. Selma Caal, executive director and director of research and program development at the Crimsonbridge Foundation (http://bkaprt.com/ccd/06-17/). One of their mission strategies is to give grants to nonprofit organizations to create content explaining their services to Spanish-speaking Americans. They do not pay for quick translation work—they fund the development of original content in Spanish.
For example, Girls on the Run Montgomery County, a nonprofit that sponsors an annual 5K run for girls, wanted to increase participation of girls in the Spanish-speaking community. Instead of funding a full translation of their main site, they created a Spanish-language microsite, targeted at parents (Fig 6.11) (http://bkaprt.com/ccd/06-18/). Not only was the resulting content written in the target language, but it also answered questions about the event that were specific to the concerns of the local Hispanic community, which may not have happened through a full-site translation.
Whatever path you choose, a localization toolkit can help make any translation project more successful. Because localization is such a time-consuming and expensive process, we need some structure to help us plan and deliver content effectively for our audiences. Localization toolkits are the documentation that translators need to be effective and ensure they are focusing on what is most important. They contain:
- A list of languages to be translated. This should include regional specifications as well—the Portuguese spoken in Brazil is different than that in São Tomé and Príncipe.
- Descriptions of your audience, their particular needs, and how to write for them. For example, USA.gov, the official portal for all things American government, offers guidance on the appropriate voice and tone for government websites (Fig 6.12). This kind of style guide would be great to provide as part of your translation toolkit.
- A sitemap listing all pages and content that need to be translated.
- Any existing translation memory, a database that allows translation teams to store and reuse phrases and words that have been previously translated.
- A detailed description of your timeline. Translators will be able to turn around anywhere from 1,500 to 2,500 words a day, so plan accordingly.
- Information on your tech stack, including what your site is built on, and login details for the content management system.
I hope I haven’t scared you away from translation. As you can see, it is a complex task with quite a few pitfalls but also some amazing benefits when you get it right. Whether it’s scoping fully localized and translated sites as part of a site redesign, getting automated translation tools like Google Translate to help you out, or just picking a few key pages to focus on, you’ll have plenty of work.
Sometimes, despite your best efforts, none of these are appropriate options. If that’s the case, you can use other design techniques to assist users in understanding your site, regardless of their native language.
There’s a mismatch between what we perceive as the lingua franca of the web (English) and what languages internet users actually speak. Here are a few surprising stats that begin to illustrate what I mean. Of the top million sites on the web, 54 percent are in English (as of this writing), but native English speakers make up only 25.2 percent of the people online. Over 19 percent of people online are native Chinese speakers, but only 1.6 percent of the top million sites are in Chinese. Almost 8 percent of the people on the web are native Spanish speakers, but only 4.9 percent of the content is (Fig 6.13) (http://bkaprt.com/ccd/06-19/).
It would be easy to assume, based on the percentage of English sites on the web, that the majority of our audience will also be native English speakers. That would be a huge mistake. The reality is much more nuanced. Billions of non-native English speakers use those sites, reading, watching, and communicating in their second (or third or fourth) language. In the spirit of this book, I’ll note once more that language does not equate to nationality—millions of Spanish speakers live throughout the Americas, West Africa, and Europe, for example.
As we saw in the last section, fully translating and localizing our sites and apps is an expensive, mammoth task. If translation is not in the cards or if your project is too far along to do anything about it, there are other steps you can take to make sites accessible for non-native speakers. Simply put, the key is to focus on providing clear language, structured content, and prompts to help users as they navigate the largely English-speaking web.
A lot of what follows will look like basic, good accessibility advice. And it is! I hope you are already doing some accessibility work and building it into your design systems and process, in which case these ideas will feel very familiar. However, I want you to see that work through the lens of what is needed for those billions who are English as a Second Language (ESL) speakers.
Let’s look at a few important steps.
Expose navigation and content structure
Reading on screen can often be disorienting—where am I in this document? How much more content is there, and do I have the stamina to make it through? These are all split-second decisions we make when picking up a print book, but that doesn’t work so well online. As a designer, you need to expose content structure and navigation, allowing second-language learners (and everyone else, frankly) to see what they are getting into with your content.
Some things you can add to your pages to help:
- Tell people how long it will take to go through your page. On Medium, the “~ min read” label can provide context for the amount of content on the page (Fig 6.14). However, be careful to take your audience’s linguistic skills and reading ability into account rather than going strictly by word count to estimate reading time.
- Give people a breakdown of the contents of the page upfront before they begin reading. On GOV.UK, the government portal for the United Kingdom, interior pages include an anchor-linked “Contents” list just below the title (http://bkaprt.com/ccd/06-22/). Each item acts as a jumplink to navigate the content (Fig 6.15). Your readers can scan this list for context and quickly get to the content they are looking for on the page. For longer reports or academic content, these could be one-sentence key takeaways or summaries linked to different sections.
- Offer clear onboarding before people begin using your site in earnest. As non-native speakers download and enter your app or site for the first time, offer a transparent view of functionality or the interface’s organizing principles. This hand-holding at the beginning of the experience shows people exactly what they are getting into, even if your audience doesn’t have a perfect grasp of the language you are using. Duolingo, the language-learning app, provides a great example of how to make onboarding clear. The screens show how much progress you’ve made, while also using large illustrations and plain-language instructions (Fig 6.16).
Make print stylesheets as effective as possible
Yeah, people print stuff out. Count on it. Especially people, like second-language speakers, who want to focus on and review things they don’t immediately understand. So as with many of the other accessibility tips on the web—make your print.css stylesheets actually work!
One technique I find helpful is to add a prominent “Download” button on each page. Then, as part of your design and content strategy process, spend time creating a standardized, nicely organized print.css file. That way, when your ESL audience taps that Download button, they get a nicely formatted PDF.
Only use hyperlinks when necessary
Too many links in a block of text can make collating and synthesizing information difficult. When second-language speakers view digital content, they often feel the need to check the included links for additional context or relevant information. (Native speakers do this too!) There’s a downside: each click takes them farther away from the primary text and content. Freedom to explore also means freedom to get lost, as anyone who’s ever walked around a new city can tell you.
Offer clear access to contextual information
At the same time, however, you do need to offer context, especially when it comes to new or unfamiliar language. When ESL learners encounter new words or phrases online, they almost always choose ways to define the word that takes a minimum of fuss and time. That means searching the web for dictionary definitions where possible or just making an educated guess. In “A Study of ESL Students’ Perceptions of Their Digital Reading,” Dr. John Gilbert, a researcher and language instructor, noted:
[I]t is faster and easier for the language learner to engage in online split-second definitions than thumbing through page upon page of listed words and their meanings in a paper-bound dictionary. (http://bkaprt.com/ccd/06-23/, PDF)
Tooltips next to key content is one way to support these split-second decisions. The Los Angeles Times used this approach in an article about a new California law seeking to decriminalize the sale of home-cooked food (http://bkaprt.com/ccd/06-24/). Because some of the terms in the article, like bánh bột lọc (soup dumplings), may be unfamiliar to their readers, they added a contextual information popup on the article with a photo and a description (Fig 6.17). Small, unobtrusive explanations next to key content can provide that continued layer of help your users need.
Keep your content readable
It is often the case that people charged with content creation and design overestimate how well their ESL audiences can read. Even if that doesn’t seem like a problem you will face, it is good practice to get an objective idea of how complex your copy is. To test this, you can run it through a Flesch-Kincaid Readability Test (http://bkaprt.com/ccd/06-26/). The test measures how difficult it is to understand a passage in English and assigns a score or US-based reading level. You can do this with the “Show readability statistics” tool in Word or by copy-and-pasting your content into one of the many online readability tools.
After you get your score, you can take a few basic steps. First, create a content map—a spreadsheet with all of your content, its location in the site, its current reading level, and perhaps related SEO information. Then, based on your brand and audience needs, decide what reading level you want your content to target. For context, the average American adult reads at a ninth-grade level; American newspapers are written around an eleventh-grade level (http://bkaprt.com/ccd/06-27/). Go through and edit your content on pages with a score that’s too high; then run it through the test again until you are satisfied.
Good interface content is close to a fine art, and one that is tied closely to your brand personality and identity. It’s also content that can trip up your ESL site visitors.
While there are some well-known commands (like “Search”) that I always recommend placing in common spots with recognizable icons, other microcopy, like “Upload image from computer,” might be confusing for non-native speakers. Regardless of their goals online, our responsibility is to provide ESL visitors with simple, standardized commands that are contextual, easily understood, and memorable.
Aligning your microcopy’s readability level with second-language speakers’ reading comprehension level is something you can do now—you don’t need to wait until the future when you have the time and money for a complete overhaul of your digital experience. The benefit, of course, is that these steps will almost certainly help all of your users, whether they are native speakers or not.
A Solid Foundation
We have looked at the many different ways you can create effective, localized digital experiences for a cross-cultural audience. It’s good to dig into those details. Don’t let it overwhelm you or start to feel like a chore. Talking through these particulars now is a great way for you to get a better handle on how people negotiate different cultural environments online.
With careful planning and research, we can make elements like type, code, and icons all work effectively together, giving your audience a unique and authentic view of the web they inhabit.