Оценка на читателите: / 9
Слаба статияОтлична статия 

Новини от света на уеб дизайна и СЕО

Представям Ви синдикирани новини от няколко от водещите сайтове в областта на уеб дизайна и СЕО - оптимизирането за търсачки.

A List Apart: The Full Feed
Articles for people who make web sites.
  • Web Typography: Numerals

    A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Richard Rutter’s new book, Web Typography.

    When it comes to numbers we have just ten digits. Throw in a comma and a period and we’ve got grand total of twelve characters. You might not think that would present much of a challenge to a typographer, but to a professional typesetter (that’s you if you’re a designer) numerals require far more nuance and variation than you might think at first glance. Numbers deserve the same care and attention as text - this excerpt reveals the numerical situations you should be looking out for, and how to tackle them to benefit your reader.

    Use old-style numerals in running text

    In ‘Ligatures and abbreviations’ we established that writing systems based on the Latin alphabet, in addition to Greek and Cyrillic, use a bicameral script, with each letter represented by two different forms – uppercase and lower (or majuscule and minuscule, to use more formal terms). The same is true of numerals. We have at our disposal ‘uppercase’ numbers 0123456789 called lining or titling numerals, and ‘lowercase’ numerals 0123456789 called old-style or text numerals.

    Unlike capital and lowercase letters, different forms of numbers do not convey different meanings; they are, however, an essential component of the typographer’s palette. Just as a string of capital letters in the middle of a sentence SHOUTS at your reader, so numbers set in lining numerals call undue attention to themselves. Are pounds, dollars, dates and quotas really more important than the words and ideas which give them context and meaning?

    Treat numbers as you would letters, making sure they don’t stand out unnecessarily. Do this by using old-style numerals in all your running text. Most modern, professional fonts will include both old-style and lining numerals as OpenType features. One or other of these styles will be used for the default numbers. More often it will be the old-style numerals, but there is no strict rule or consistency, and the choice of default is down to the type designer.

    It’s also the case that the vast majority of fonts are neither modern nor professional, if modern means OpenType-enabled and professional means designed with both sets of numerals. Take Georgia, for example. Designed by Matthew Carter in 1993 as a screen font for Microsoft, it is extremely well put together, elegant and appealing, and one of the most popular and widely distributed fonts in the world. But it is not packaged as an OpenType font and so only contains one set of numbers, in this case old-style numerals. Times New Roman, which is similarly widespread but, again, not as an OpenType font, is packaged only with lining numerals. Georgia and Times New Roman are so widely distributed because they are bundled free of charge with Windows and Mac operating systems. However, both these fonts – like many others – are available to buy in professional versions, which do come as OpenType fonts complete with both sets of numerals, small caps and many other features.

    Graphic showing numerals in Times New Roman and Georgia
    Top: Numerals in Times New Roman Pro.
    Bottom: Numerals in Georgia Pro.

    To specify old-style numerals, set the font-variant-numeric property with a value of oldstyle-nums. If most of what you’re designing on a page is running text, then your best approach is to set old-style numerals so that they are inherited from the <body>.

    body {
        font-variant-numeric: oldstyle-nums;

    For legacy browsers requiring font-feature-settings, use the onum OpenType feature tag. As explained in ‘Ligatures and abbreviations’, you can add an @supports rule to cater for legacy browsers that only support font-feature-settings:

    body {
        font-feature-settings: "onum" 1;
    @supports (font-variant-numeric: oldstyle-nums) {
        body {
            font-feature-settings: normal;
            font-variant-numeric: oldstyle-nums;

    Many sans serif fonts of the early to mid-twentieth century, including Helvetica, were never designed with anything other than lining numerals. This is one of the reasons why Helvetica is rarely your best choice for body text. That said, the lining numerals are less of a problem in Helvetica than they are in some other typefaces. As we saw in ‘Designing paragraphs: line spacing’, Helvetica has a large x-height. A consequence of this is that its lowercase letters are closer in stature to its lining numerals when compared to other sans serif fonts such as Futura and Avenir, which have far smaller x-heights.

    Graphic showing two styles of numerals in Avenir

    Compared with old-style numerals, lining numerals shout loudly in Avenir.

    Clearly Paul Renner and Adrian Frutiger, the designers of Futura and Avenir respectively, recognised the need for old-style numerals in their fonts as both these typefaces were designed with them from the start. Sadly, the versions of Futura and Avenir widely distributed with Apple devices have lining numerals as the default, and do not include old-style numerals as OpenType features (the macOS version of Avenir Next, however, does include them).

    Use lining numerals in headings

    Old-style numerals are your go-to glyphs for making numbers sit well in running text. For the same reason they are at ease with lowercase letters, so old-style numerals feel uncomfortable in close proximity to capital letters. If you set headings in anything other than sentence case, in particular ALL CAPS, or Title Case, then don’t use old-style numerals. Lining numerals will sit far more naturally in the company of uppercase letterforms.

    Graphic showing Lining and Old-Style Numerals

    Lining numerals sit more naturally in headings than old-style numerals.

    On those occasions when numbers are the star attraction, lining numerals are the way to give them the attention they crave. Old-style numerals have a wavy rhythm to them, with some numbers reaching upwards towards the capitals, some squatting at the x-height, and others ducking down below the baseline: 1234567890. This is why they work so well in continuous reading – they replicate the patterns of words in running text. However, if your reader is scanning a sequence of numbers, looking for patterns, making comparisons, or hunting for data in a list, table or other setting, they will find it far easier to do so with the familiarity and evenness of lining numerals. To specify lining numerals, set the font-variant-numeric property with a value of lining-nums:

    h1 {
        font-variant-numeric: lining-nums;

    For legacy browsers requiring font-feature-settings, use the lnum OpenType feature tag.

    Use proper subscripts and superscripts

    Subscripts and superscripts are tiny numerals which are lowered or raised. They are used in chemical and mathematical formulas, as footnote indicators, and other specialist situations. For example: ‘Caffeine1 is C8H10N4O2.’ Mark this up meaningfully in HTML using the <sup> and <sub> elements:

    Caffeine<sup>1</sup> is C<sub>8</sub>H<sub>10</sub>

    Browsers’ default styling for <sup> and <sub> is to take a regular numeral, make it a bit smaller, and raise or lower it accordingly:

    Graphic showing default styling for sub and sup tags

    This works fine up to a point, but the numerals are still a little too big aesthetically and they affect the line spacing, causing unevenness in the rhythm:

    Graphic showing the default styling for sub and sup tags in the context of a paragraph

    Most professional fonts contain properly designed subscripts and superscripts built in as OpenType features. These numerals are smaller and squatter than regular numbers, and because their position relative to other characters is part of their design, the line spacing is unaffected:

    Graphic showing proper sub and sup tags

    To use proper subscripts and superscripts, use the font-variant-position property, like this:

    sub { font-variant-position: sub; }
    sup { font-variant-position: super; }

    Unfortunately, this still leaves us with a problem: the browser’s default styling is still applied. Our special subscript character is being made smaller and it’s getting moved downwards, affecting the line spacing:

    Graphic showing various sub styles

    Top: Default <sub> styling. Middle: Proper subscripts with browser default styling. Bottom: Proper subscripts only.

    The styles the browser applies to our subscript characters are these:

    vertical-align: sub;
    font-size: smaller;

    We need to remove those styles to get the desired effect, so our rule now becomes:

    sub { vertical-align: inherit;
          font-size: inherit;
          font-variant-position: sub; }

    That will work fine for browsers that support OpenType. But browsers that don’t will get C8H10N4O2, a degraded rendering compared with the browser defaults. To address this we can use an @supports rule to check if the browser supports font-variant-position and only override the browser’s default <sub> styling if that’s the case:

    sub { font-variant-position: sub; }
    @supports ( font-variant-position: sub ) {
      sub { vertical-align: inherit;
            font-size: inherit; }

    For legacy browsers requiring font-feature-settings, use the sups OpenType feature tag for superscripts, and subs for subscripts. If we factor these in, we get comprehensive, backwards-compatible style rules, but where two simple properties should have done the job, we now have a far more verbose proposition:


    sub { font-feature-settings: "subs" 1; }
    @supports (font-variant-position: sub) {
        sub { font-feature-settings: normal;
              font-variant-position: sub; }
    @supports ((font-variant-position: sub) or (font-feature-settings: "subs" 1)) {
        sub { vertical-align: inherit;
              font-size: inherit; }


    sup { font-feature-settings: "sups" 1; }
    @supports (font-variant-position: super) {
        sup { font-feature-settings: normal;
              font-variant-position: super; }
    @supports ((font-variant-position: super) or (font-feature-settings: "sups" 1)) {
        sup { vertical-align: inherit;
              font-size: inherit; }

    Reference notes with superscripts

    One particular use of superscripts is for footnotes. When you reference notes using numbers, use true superscripts in the text but full-size numbers in the notes themselves.

    Show footnotes in context

    While we’re on the subject of footnotes, it’s worth making a brief diversion into how the web improves their usability compared with the limitations of paper.

    Many forms of writing, including academic papers, historical novels, detailed journalism and non-fiction books such as this one, contain additional citations, explanations and thoughts referred to within the text itself. A symbol is used to connect the note to the relevant location in the text. The symbols employed as references to annotations are either superscripted numbers or an esoteric series of devices starting with asterisks* and processing through daggers† to double daggers‡ and beyond.

    Since the advent of mass printing in the Victorian era, the notes themselves have typically been positioned either at the bottom of the referring printed page (footnotes), or at the end of a chapter or the entire work (endnotes). However, this approach means the notes are located away from their position within the body of text. This can disturb the reader who wishes to refer to the annotation as they proceed through the text. The connected point in the text may well be halfway through a sentence in the middle of a paragraph at some point higher up the page, or on a different preceding page altogether, and attempting to return to it disrupts the reader’s rhythm.

    An earlier approach by medieval scribes and Renaissance printers placed notes in the margins (side notes) rather than at the bottom of the page. By including notes as marginalia, the annotations are present where needed and can be read with little more than a glance away from the main text.

    A crop of a hand-written document
    A side note in a 9th-century manuscript. Source: Einsiedeln, Stiftsbibliothek, Codex 172(1128)

    Although side notes are an improvement on footnotes, both solutions are designed within the confines of the two-dimensional printed page. The web is an interactive medium and provides us with at least three dimensions in which to work, implying you can use the z-axis to place the note on top of the main text.

    Enable your reader to reveal the note on demand in the very place they are reading. Put simply, link to the footnote using a conventional symbol, but have it pop up in the vicinity of the link, thus providing a thoroughly modern solution impossible within the limitations of a printed page.

    Partial screenshot
    Clicking a superscript could pop up a footnote in situ.

    Want to read more?

    This excerpt from Web Typography will help you get started. Order the full copy today.

    Cover of Web Typography
  • The Right Way to Select Technology, An Excerpt

    A note from the editors: We’re pleased to share an excerpt from Chapter 4 of Tony Byrne and Jarrod Gingras’s new book, The Right Way to Select Technology, available now from Rosenfeld Media.

    After establishing a solid business case, enterprises will typically turn to assembling the oft-dreaded “requirements document”—or more accurately, a set of documents, spreadsheets, and diagrams that compose a multiheaded requirements package.

    Large requirements packages actually provide a false sense of security. Modern digital technology entails real people interacting with screens. Technology selection leaders need to capture those interactive requirements, but also remain realistic at this phase about their inability to fully know what their enterprise really needs and will adopt eventually.

    This section will show how long spreadsheets full of “what” requirements really don’t work, and instead will focus on “how” a solution might work. The best way to reveal key differences among suppliers is to craft narrative “user stories” with “personas” (rough equivalent to use-cases with actors).

    In other words, tell testable stories. Business users have stories; so do customers, partners, developers, sysadmins, designers, auditors, and others.

    This section will lead you through an approach to telling those stories in a way that’s more conducive to differentiating among technology suppliers.

    Capture requirements that don’t suck

    A solid understanding of your organization’s requirements is essential to project success. Getting that understanding will involve information gathering from various stakeholder groups, potentially utilizing a variety of techniques.

    Note that at this stage, your requirements should be business- and user-focused, rather than detailed technical specifications. (We’ll get to those in Chapter 6, “Ask Questions That Really Matter”). The final key step here is to analyze and prioritize your requirements, in order to determine which ones to emphasize in the RFP and subsequent demos and bake-offs.

    How not to articulate requirements

    Whatever you do, avoid “check box” requirements sheets where you ask the vendor: “Can you do this, can you do that?”

    As a practical matter, vendors have seen all these questions and have figured out how to check all the boxes. But what’s worse is that such spreadsheets convert the understanding of what should be a human-centered, interactive activity into a bloodless series of row-by-row activities better suited for robots repeatedly performing rote tasks.

    The typical pitfall here starts like this: a business analyst (BA) goes around interviewing users and other stakeholders, and she ends up with a long wish list of features. Excel allows her to categorize those features, which is handy, but because of the limitless rows, her spreadsheet will tend to emphasize comprehensiveness over business impact.

    To address the challenge of priorities, the typical enterprise process asks stakeholders to rank their needs, perhaps on a scale of 1 to 5, or using MoSCoW (Must Have/Could Have/Should Have/Won’t Have) or some other methodology. Not surprisingly, this generates a scrum where users compete to identify as many rows of “Must Haves” as possible.

    Ultimately, someone will ask the BA to tie back each requirement row to the business case (remember that?), so she then spends several days building new tables and cross-references in Excel. Ultimately, reviewers find exceptions and variants for each feature, so new columns get added. Now the spreadsheet is too big to fit on a standard screen, let alone print out. It’s impressive … and impressively unhelpful.

    The government agency with the massive checklist

    We once advised a major U.S. federal government agency to select a new portal platform as a hub for small business advice. We came late to the process after an initial round of vendor demos had failed to differentiate clearly among the bidders.

    The problem was Excel. Or more specifically, the entire RFP as a 10-tab worksheet, with some sheets going hundreds of rows deeps. Most of the tabs held feature requests—notably categorized by agency department rather than customer persona—with a long series of columns annotating those features. (Our favorite: the ever-beloved “Must be easy to use” requirement.) Nearly all the features were listed as “must have.” They were rigorously cross-tabbed to a long-but vague set of business objectives, but otherwise there was no prioritization.

    The vendors didn’t know what to demo, although several gamely tried. Mostly, they just talked about their (voluminous) proposal responses, most of which consisted of declaring, for each row, “We can do that!”

    Ultimately, we were able to recraft a more user-centered approach, with a narrower scope, that vendors could reasonably demo against.

    Lesson: Stay away from long, feature-based checklists.

    Applying UCD principles

    There’s a different way to do this than torturing your BA— and everyone else—with long spreadsheets, and it revolves around pursuing a user-centered design (UCD) approach that emphasizes narratives, which we’ll call stories here. People will disagree about the tactics of UCD, but we can generalize overall that a user-centered approach is:

    • Holistic to encompass the entire digital experience (and therefore not feature based)
    • Iterative, where you initially sketch light (and therefore imperfect) requirements and refine them over time via iteration
    • Story-based, with an emphasis on user narratives, often called “journeys” or “top tasks”

    There’s much more to UCD, but for our purposes, two key constructs stand out:

    • Personas: User archetypes that guide decisions about technology effectiveness. Personas are useful in the sense that they create a common shared understanding of the user group, but with a human existence to help keep it real.
    • User Stories: A to-be story about the “daily life of” or a journey undertaken by key personas. User stories are exceptionally valuable here because they offer test cases against which you can compare and contrast vendor bidders.

    Information gathering

    You can chose from among numerous well-known methods for eliciting information needed to create personas and user stories.

    • Document reviews: Including existing and prospective systems diagrams, planning documents, and analytics, but also the information that flows through the anticipated technology, like catalog entries for an ecommerce site, or forms in a document management system
    • Questionnaires: Including customer and employee surveys, as well as specialized questions you might want to pose in advance of any in-person meetings
    • Workshops: A useful way to debrief groups of people, as well as experiment with more forward-looking brainstorming; customer focus groups fall into this category as well
    • Interviewing: Debriefing individual stakeholders one-on-one, where they may become more candid
    • Shadowing: Following stakeholders around for a typical duration of time; this sort of contextual inquiry is often the most useful, but also labor intensive
    • Potentially others …

    Different practitioners will take different approaches, and clearly the level of effort here should be commensurate with the anticipated benefits and risks with the new technology.

    At Real Story Group when we’re creating personas and scenarios, we like to take a modified contextual inquiry approach. We gather individuals with similar roles in a conference room and debrief the team as a group. Using a projector, we may ask some members to log in to show specific examples of an incumbent system to the group. When we are gathering requirements for an interactive system, we make the environment as interactive as possible to get the maximum information exchange.

    We’ll send five questions in advance as the agenda for the workshop:

    1. Show us briefly, on the screen, what you do.
    2. What works well in the existing environment (top three only)?
    3. What doesn’t work well or is missing in the existing environment (top three only)?
    4. How is your work/market/environment/customer changing?
    5. What else is important that we haven’t discussed?

    The questions are deliberately open ended, to create as much of an open dialogue as possible. Note the emphasis on “top three”—we don’t want a laundry list of features, but rather the most important problems and opportunities.

    Sometimes, it’s hard for line employees to identify potential future opportunities, so it can be useful to introduce the whole process with an educational workshop describing industry best practices or examples of what other enterprises have done with the technology. This is particularly important when selecting a type of technology that the enterprise has never used before.

    The question still remains of staying aligned with the initial business plan. We like to book half-hour sessions with interested executives to understand the broader business currents and objectives underneath the technology selection effort.

    At this point, a lot of raw material has been accumulated. The next step is to convert it into the two core components of the future RFP: user stories and advanced Q&A.


    • You will need to invest in both information and process analysis, and this will require document analysis as well as contextual inquiry.
    • Avoid long, undifferentiated, spreadsheet-based feature lists in favor of uncovering material necessary to create key personas and scenarios.
    • Start with the user experience and work your way back into enterprise systems.
    • Avoid the temptation to broaden your scope beyond the original charter.
    • You don’t need to be perfect at this (or any other) phase, so focus inquiry into your stakeholders’ most burning problems or intense needs.
  • UX for Lizard Brains

    Technology can make magic happen. In seconds, you can find all the blue sandals in a warehouse of millions of shoes. A million people can read the same article without killing one tree. You can undo, unsend, and even unfriend! But here’s the buzzkill: if unanticipated or unwelcome, the magic of technology is confusing, disorienting, and unintuitive—a UX designer’s worst nightmare.

    So how can we ensure that the magic we create is intuitive? Designers will often say, “If a design is intuitive, it behaves how a user expects it to.” Well, then … what do users expect?

    We want to know the following whenever we find ourselves in a new environment (physical or digital):

    • What are the objects?
    • Where are the objects?
    • How do these objects relate to me?
    • How do these objects relate to each other?
    • What is my role as an object within this environment?

    In physical spaces, these don’t require explicit thought to answer. However, in digital spaces, they often do. That is because our “lizard brains”—the part of the brain involved in motivation, emotion, learning, and memory—evolved alongside the physics of solid objects. Consequently, users may feel unsure when designers flout the perceptual expectations forged in the physical world. Without knowing what and where the objects are, we feel blind. Navigating feels uncomfortable. Taking action might even feel impossible.

    The remainder of this article introduces three ways to design digital objects that “play nice” with our evolved expectations of the physical world. By doing our best to concretize the dematerialized things of our screen-based world, we give our lizard brains better affordances for understanding.

    Lesson one: avoid shapeshifting objects

    The properties of user interfaces need to be consistent for us to learn them well. We hunger for stable landmarks in the often ambiguous maze of digital interfaces.
    Andrew Hinton, Understanding Context

    Objects in the real world don’t usually change form as they change context. When I bring a new toaster home from the store, it doesn’t change into a different toaster. When I remove a vase from the cabinet, it doesn’t turn into a coffee mug. Humans expect object permanence; we are taken aback when objects unexpectedly change shape.

    Why do babies love peekaboo so much? It’s a great way to practice the fundamentals of object permanence, an important lesson in survival (e.g., just because the tiger went behind the rock does not mean it has disappeared). Because babies are still coming to terms with this concept, peekaboo makes for a rollicking good time. So we might assume that if we up the ante on the surprise-factor, the game would be even more fun, right? Nope. Researchers measuring the level of toddlers’ delight during a series of hacked games of peekaboo discovered that the game loses its appeal when a different face pops up after hiding. The older the child, the more this hack kills the game. Evolution seems to be telling us: it’s not cool when objects suddenly change. But all that peekaboo practice is for naught when trying to navigate a digital world of shapeshifting objects.

    For instance, when this article was in the form of a Google Doc, it lived in both the Google Docs and the Google Drive environments. Depending on the environment, the article’s module changed form and function.

    Screenshot showing the same document with different menus in Google Docs (shorter) and Google Drive (longer)
    Different menu options in Google Docs and Google Drive.

    Moving from Docs to Drive, the shape of the document module shifts from about a 3:5 rectangular ratio to a 1:1 square ratio. If I want to see when I last opened a document, I will find that information directly on the module while in Docs; but within Drive, I must look to a disembodied side panel (not shown). Both modules have a menu of actions, but accessing it requires different interactions. (In Docs, I click the “more” icon; in Drive, I right-click the module.) Worst of all, the menu contains almost completely different options in each module! Only “Remove” and “Rename” are found in both menus. Adding insult to injury, even the icons for “Rename” are different.

    Chart and screenshot of the differences in the menus between Google Docs and Google Drive
    The form and behavior of the document module are significantly different on Google Docs than on Google Drive.

    We could chalk up the inconsistencies of Google Drive and Google Docs to siloed teams, but shapeshifting objects are common within products, too. On Meetup.com, the digital representation of my next meetup morphs multiple times across the site. Looking at the homepage, it displays as a big red banner at the top of the screen.

    Screenshot of Meetup.com showing the alert for next meetup.
    Meetup’s next-up module is highlighted in bold red at the top of the homepage when you’re logged in.

    Scrolling down the homepage to the calendar section, the same meetup is displayed as a white box sporting some green accents that signal my relationship with this particular object.

    Screenshot of Meetup's calendar showing the same event
    Meetup’s calendar module makes the same meetup look like a totally different type of thing.

    And finally, within the context of its parent group—in this case Ladies that UX ATL—the meetup object is represented differently yet again. (Let’s not even get started on the ontological ambiguity between Meetup the Group and Meetup the Event.)

    Screenshot of the same event in a different context on Meetup.com
    The meetup module on the Ladies that UX ATL parent page.

    Not only is my lizard brain trying to reconcile all these changes for potential threats, but these inconsistencies are making me work harder in a practical sense. I have to learn three displays for RSVP status, three positions for date and time, and three ways to find the number of people going. Every time the object changes, I have to make adjustments both to recognize it and to interact with it. These adjustments are small, but they add up across the experience. Designers can eliminate this cognitive load simply by creating a canonical object structure and sticking to it.

    Many users don’t log the deltas between modules explicitly. Users furrow their brows and simply do their best to relearn objects and keep track of what’s what. They might harbor a vague feeling that the website or app is “hard to use.” Or worse, they blame themselves for “stupidly” attempting to interact with an object in a way that worked in one context but does not work in their current context.

    Sure, there are complex platforms where it might make sense to re-prioritize object elements depending both on who is viewing it and under what conditions. But if we design screen-by-screen instead of object-by-object, we run the risk of doing this unintentionally and arbitrarily, introducing more shapeshifting than is absolutely necessary.

    Key takeaway

    Image showing a way to consolidate three conflicting styles of a module into one cohesive style.
    In this example, a veterinary portal might have multiple modules that represent “pet.” Instead of designing a different module for each context, design one module that works well for ALL contexts.

    When we move elements around within an object, we need to remember that we are making a sacrifice—we are sacrificing consistency. Sometimes it will be worth it, like perhaps in professional tools used by power users. But often, our users will be happier with a single, rock-solid representation of that object.

    Lesson two: avoid masked objects

    On the flip side of shapeshifters (i.e., various packages for the same object), designers also have a tendency to shove different objects into the same package. With the good intention of designing a system of reusable parts, we’ll often create one-size-fits-all modules. This might seem like a smart simplification strategy, but it actually hinders users from distinguishing various object types. Distinguishing them is critical for the user to understand the system.

    Screenshot showing five slightly different product modules on Amazon
    Modules on Amazon homepage

    Check out this bank of candy-colored modules on my Amazon homepage. Sure they house different colors and content, but they follow the same basic structure. If the text were in Latin (or if the user were skimming rapidly, which we should always assume is true), these modules would translate as the same type of thing. In looking at the first two, PRIME and FRESH, I might get the impression that these modules represent “services.” And indeed, when I click these modules, I enter sort of informational, sale-sy pages describing these services (although they follow completely different templates).

    Screenshot showing how similar modules on Amazon set an expectation of usage
    PRIME and FRESH module link to services

    But when I get to VIDEO, I have to pause. VIDEO…the service? Or does this module represent a TV series? The next module (MUSIC) brings up the same question. And the ALEXA module—will this take me to a service landing page or, perhaps, a product detail page?

    Screenshot showing the final destination of all five similar modules on Amazon
    VIDEO, MUSIC, and ALEXA modules linking to different types of content

    In fact, each module takes me to a different type of place. PRIME and FRESH take me to two separate templates for a “service.” VIDEO takes me to a detail page for The Americans. And MUSIC opens up Amazon Music in a new tab (with no sign of the ill-recommended Eminem album). The ALEXA module takes me to another “snowflake” landing page.

    Like opening identical doors in a game show (but not as fun), I never know what to expect when clicking on one of these tiles. (View a video of my full rant on these Amazon modules.)

    Let’s look at one more example. The Apple App Store leverages a small rectangular thumbnail module that can house apps, curated collections, broad categories, developer-based app suites, and even operating system updates.

    The same module represents various objects in the Apple App Store.

    In both the Amazon and Apple App Store examples, instances of the modules have distinct graphics and labels, but they are the same shape and size and they are grouped together, like apples at the market. As a general rule of thumb in Gestalt psychology, when objects are grouped together, we assume they are the same type of thing, especially if their overall shape is identical. When the same packaging (i.e., the module) turns out to contain various types of things, as in the App Store, users may feel confused or even tricked. This is like taking a sip from your Starbucks coffee cup and getting a mouthful of orange juice: objectively tasty, but if unexpected, you might spew it onto your barista.

    Key takeaway

    Graphic showing how to take similar modules with different purposes and make them distinct
    Continuing with the veterinary portal from lesson one, we have pet, appointment, and medication modules all leveraging the same basic module design. Instead, create distinct modules for distinct objects. Different things deserve different packaging!

    Designing one-size-fits-all modules might seem like a good idea for an efficient modular system, but this practice doesn’t allow users to predict what’s “behind the door.” Instead, design packaging (i.e., modules) that reflects the unique things inside. This way users can learn to recognize and understand the objects in your system, making for a more intuitive environment.

    Lesson three: avoid broken objects

    In the real world, our environments are made of surfaces and clear edges. We rarely have the problem of understanding where one object stops and another begins. If we happen across a tangle of snuggling kittens, our brain might freeze up—not only from cuteness overload, but also because we are compelled to figure out which paws belong to which head. We want objects to be whole; if they are not, our brain does its best to connect the dots. In digital environments, an object might not only shapeshift across screens or mimic other objects, it might also be broken. The information and interaction triggers of broken objects are scattered across their digital environments.

    Winc Wines, a lovely service that delivers algorithmically-recommended wine to your doorstep, prompts customers to rate their wines. Often, I’ll do this 3–4 months after receiving wines. Recently, I decided it would be a great form of procrastination to log into Winc to rate my past wines.

    Screenshot of the ratings tab of Winc.com
    The Ratings tab of Winc.com. These wine modules include the ability to star a wine and add a note, but don’t show the user when the wine was received.

    At a dinner party I hosted in May, we drank a delicious sparkling wine. I think it was Finke’s Widow, but I’m not positive. Hesitating to give it five stars until I am sure, I need to find out when the bottle of Finke’s was delivered. On the “Ratings” tab, I see all my past wines. But delivery dates are not displayed.

    Screenshot of Winc.com's product detail page
    The Winc’s wine detail page displays descriptive information about the wine, but nothing about the user’s past interactions with the wine.

    Clicking into the detail view, I am presented with a generic detail page, the same view of Finke’s Widow that everyone sees. Here I can find information about the wine, but no information about my relationship with the wine—mainly, when it was delivered and how (or if) I rated it.

    As a wild guess, I click the “Hello, Sophia” menu, where I see a link to Order History. Seems promising.

    Screenshot of Winc.com's order history page
    Winc’s Order History is not much more than a table of dates.

    The Order History page gives me a list of orders with no preview of the wines that were included in each order.

    Screenshot of Winc.com's order history detail page
    Winc’s Order History detail view is where I finally find the delivery date of the wine in question.

    After clicking into the April and May orders, I finally find Finke’s Widow. Mystery solved. So, can I rate the wine from here? Nope! I have to navigate back to the Ratings tab and then scroll down to find Finke’s Widow again. In the Winc world, relevant pieces of a bottle (like a customer’s order date, rating, and tasting notes) are scattered about, forcing a user to hop around to piece together the broken object. (Watch a video of this screen-hopping.)

    Key takeaway

    Graphic showing how to consolidate related information in one view
    Avoid scattering an object’s data and actions across settings, buried menu commands, and hierarchical navigation.

    In the Winc world, I have to be in Order History to see a wine’s delivery date and I have to be in Ratings to tell the system how much I liked a bottle of wine. But what if I am browsing wine and one of my past wines shows up in a curated collection? I’ll want to be reminded that this wine was delivered to me six months ago and I gave it 4 stars. Or, if I haven’t rated it yet, but I remember loving it, I’ll want to add my stars then and there. I definitely do not want to navigate over to Ratings, only to have to scroll down to re-find that bottle.

    We need to do our best as designers to encapsulate our digital objects, making them feel whole and directly manipulable, just like in the real world. I might be more likely to use the blender in the kitchen, but it still works just as well in the garage.

    Building a better mind palace

    Humans love to concretize things. Greek orators memorized their long speeches by visualizing the speech as rooms in a palace. Sherlock Holmes himself, a genius at making connections between the most subtle clues, did so by entering his mind palace, a visualized place where bits of information were concretized and manipulable.

    If the internet is the chaotic product of the human genius, this article is a call to action for designers to build a stronger mind palace for it. When we avoid shapeshifting, masking, and breaking digital objects, understanding will emerge more naturally. It’s a simple matter of making our digital environments feel a little more like the real world in which our ancestors evolved.

  • Be a Mentor

    Looking back over my eleven-year career in the web industry, I owe most of my success to two people from early on: Holly and Rebecca. Both were supervisors; but, more importantly, both were mentors. I wouldn’t be where I am today without their mentorship. Three years into my career, I got a promotion and became a supervisor myself. It was so exciting to be in a position to mentor others and give back to the community! I only had one question: how the heck do I do that?

    Mentorship has always been a part of the web industry. One of the first pieces of advice given to young web professionals is to find a mentor, and many experienced web professionals are where they are today because of their mentors. I think most of us would agree that mentoring others is a great thing. But when do you start mentoring? How do you provide good mentorship? How do you find people to mentor? In short, how do you do this?

    The truth I learned is that just about anyone with professional experience has something to offer novice or aspiring web professionals. You don’t have to be a director or an international speaker to be a good mentor—you can start today, and it’s probably easier than you think. You just need to be present, positive, patient, and productive.

    Finding opportunities

    You don’t need to be a supervisor to be a mentor, but if you’re not, finding someone to mentor can be intimidating. You can make this process much easier by having a few things in order and looking in the right spots.

    Before you seek out a mentee, you need to have demonstrable expertise to offer them. Make sure your personal website or portfolio is up to date. Try to build a professional following on Twitter or Medium to showcase your expertise. Answer some questions on StackOverflow or another forum, or write some tutorials. These will all help you in your career, and, when done well, can be mentorship opportunities in their own right.

    Workplaces are usually ripe with opportunities for mentorship. If you hold a manager or senior title, mentorship is an expectation; but even if you don’t, there’s always a need for showing new or younger employees the ropes. Make sure to check with your supervisor first, but there’s usually a strong need for enthusiastic and experienced mentors.

    Outside of work, mentorship opportunities still abound. If you’re experienced and successful in your field, you might talk with the local college (or even high school) about sharing your experience with interested students. Meetup groups are also a great place to meet people in search of an experienced mentor. Even if your area is completely devoid of others in the same field, the internet is not. Browse forums and online user groups—it won’t take long to find someone looking for a mentor.

    Be present

    A while back, I got some personal business cards printed up. I wasn’t looking for work. I meet a lot of people new to the web industry who could use someone to answer a few questions or provide feedback. I gave out about twenty business cards to friends, colleagues, and willing strangers with the explanation that I would answer their questions or review their projects. Want to guess how many used the card to contact me?

    Zero. That’s how many people reached out to me for feedback. The reason? Just like it’s harder to keep up with friends who move away, it’s hard to ask for feedback from someone who doesn’t seem available. People don’t think about it, or they feel bad about bothering you, or they get busy—whatever the reason, it’s a lot harder to reach out to someone who’s not present.

    Being present means creating opportunities for meaningful interaction. This doesn’t just mean proximity, but that’s a big part of it. If your job involves mentoring someone, sitting next to them will make this much easier. If you’re trying to mentor someone outside of work, checking in from time to time will do wonders. Lunch and coffee are amazing catalysts for mentorship. A personal connection (like a phone call or email) will go much further than an impersonal one (like my business cards).

    But even if you sit next to them, if you’re overwhelmed with the other aspects of your life, you’ll have the same problems. Showing that you’re too busy, even if you’re not trying to tell them that, will quickly halt mentorship opportunities. Talking about how stressed out or busy you are, constantly wearing headphones, and putting off someone’s inquiries are surefire ways to do this. Make sure you’re portraying yourself as available and interested in what they have to ask you.

    Asking for mentorship is hard. People don’t like admitting that they don’t know something, nor do they like feeling indebted to or imposing on others. Asking for mentorship triggers these anxieties. That’s why there are so few people asking about mentorship, even though there are so many looking for it. Taking steps to ease these anxieties, like reassuring them that they’re doing well and showing them that you’re happy to help, makes it much easier for the other person to come to you.

    If you’re serious about mentoring, taking the initiative to schedule a check-in or review will improve the relationship greatly. The key word is intentionality. Good mentorship cannot happen by a happy accident—it takes action on your part to make it happen. If you don’t think scheduling a meeting would be appropriate, get their contact information and send a quick email or text. This opens the door for them to talk freely about what’s going on in their life and work.

    If your mentee doesn’t believe that they’re important to you, they’re never going to open up and ask for help. Being present shows them that they matter to you, and that requires some intentional action on your part. Mentorship often doesn’t happen without this. Taking steps to be present in others’ lives is usually a prerequisite to mentorship.

    Be positive

    Mentorship is about enabling positive change in your mentee. While this can be done in many ways, it usually starts with either convincing or inspiring. Convincing is very logical and is based in the present: how should you be thinking? Inspiring is more emotional and is based on the future: what could you become? While both are important, inspiring is usually the most effective way to produce change—people won’t change unless they want to, no matter how logical the argument.

    Inspiring requires a positive outcome to focus on, an end goal that’s enticing enough to sway someone from their current path. This can be concrete, like a better job, or abstract, like better people skills; but it’s always something that the mentee wants for their future.

    Here’s the catch: inspiration isn’t always something a mentee brings into a mentoring relationship. An inexperienced mentee may have no idea what they want for their future, or may have a very skewed view of what’s possible. Sometimes it’s up to the mentor to cast a vision and show the mentee what he or she may not even believe is attainable. This can only happen when you emphasize potential instead of problems, and that starts with positivity.

    It’s been said that attitudes are contagious. There’s actually some science behind that. When we talk to someone we perceive as similar, it’s very common to mimic them unconsciously: particularly their posture, behavior, speech patterns, and mannerisms. And we are very good at picking up on sentiment. A study showed that even non-verbal vocalizations, such as “hmm,” conveyed positive or negative emotions and evoked responses in others.

    Attitudes are contagious because we communicate them and people reflect them without even trying. You broadcast your sentiment to your mentees, and they pick up on it and mirror back to you what you’re feeling, even if you don’t intend to communicate it. So if you don’t focus on what inspires your mentees with your attitude and actions, there’s a good chance that they won’t either, even if your words say otherwise.

    Inspiring doesn’t mean ignoring the negative; it means framing the negative in the larger positive. Instead of saying, “You need to spend less time working on overly-complicated solutions,” you can say, “You can be more efficient and offer more value to your clients if you work on simplifying your approach.” The request is equivalent, but the goal is much greater. Offering a positive outcome is much more motivating than stating the immediate negative, even though the intended outcome is the same.

    Celebrating victories together is another great way to focus on the positive. Checking off big goals is fantastic, but it happens so infrequently that it can’t be counted on to sustain motivation. Celebrating milestones can offer some much needed encouragement along the way. If a junior developer is working toward being able to code an entire site, setting up form validation is a major milestone. If a designer is working toward being a creative director, having a coworker request their feedback can be a big achievement. You don’t have to bake them a cake, but simply acknowledging and praising these little victories can provide great help along the way toward a stronger future.

    Be patient

    Early on in my mentoring relationship with Rebecca, she stressed to me the importance of being more organized. I wish I could say I took this to heart and ran with it and totally changed my life based on that feedback, but honestly, I didn’t. Urgent things kept popping up, and it was easier to continue to deal with them in a way that was comfortable to me. Rebecca never forced me to change—she wanted it to be my decision. Eventually, I found that my methods were failing and—guess what?—I needed to be more organized. If I’d listened to Rebecca when she first gave me the advice, I would have improved much more quickly.

    As a mentor, this sort of thing happens all the time. Sometimes change happens slowly, and sometimes it doesn’t happen at all. What’s going on? Your mentee has come to you because he or she wants to get better—so why resist change?

    Motivational speaker Tony Robbins once said, “Change happens when the pain of staying the same is greater than the pain of change.” As a mentor, you’re going to have a clear view of your mentee’s pain of staying the same. Your mentee is going to have an intimate view of their own pain of changing. Never assume that both of you have a clear understanding of both of those pieces of information.

    If you’re lucky, your mentee will come to you after they’ve decided that they want to change. But many times, your mentee won’t know what change looks like until they work with you for a while. Your mentee may actually be shocked by how different change looks compared to what they imagined it would be. You may have to show your mentee the value of changing while disarming their anxieties.

    Even when the push for positive change has begun, there will be times when it will seem more like a glacier than a flowing river. Your mentee may make mistakes—sometimes the same mistake over and over. They could resist change through an arrogant or stubborn attitude. They could impede it by failing to respond to or take on good opportunities. This can be agonizing for a mentor to watch.

    There’s a story about a traveler who went to visit a particularly wise man to ask him what made him so much smarter than the average guy. The wise man answered, “I have made 10,000 mistakes.” The traveler, perplexed, asked how that’s different than the average guy. The wise man replied, “The average man makes 10 mistakes 1,000 times each.”

    Your job is not to stop your mentee from making any mistakes; it’s to stop them from making the same mistakes over and over. There will be times when you want to jump in and correct their every move. There will be times you want to give up. There will be times you want to tell them they’re not learning. Resist. If your mentee is open to change and is making progress, allowing them to fail and learn their own lessons can be an important part of the learning process. As long as your mentee is making new mistakes and not the same ones repeatedly, progress is happening.

    Your mentee may not be fully aware of the progress they are making. They may not see mistakes as forms of progress, or they may minimize how much they have accomplished. Sometimes, it just takes someone who has been around for longer to identify growth.

    Change can go much slower than you want it to. At times, it may also surprise you by moving faster than anticipated. The important thing to remember is that another person’s change does not happen on your timetable.

    Once change starts happening, it’ll be up to you to keep it moving toward a meaningful goal.

    Be productive

    Good feelings are great, but they don’t mean a thing if there’s no improvement. Your mentee has to work toward real goals for real-world improvement, and that’s not going to happen unless you get specific. Some structure goes a long way in helping your mentee succeed, and figuring that out beforehand can make or break the relationship.

    Have a schedule and stick to it. If you’re scheduling mentoring sessions haphazardly, they’re not going to happen regularly enough and they’ll just stop happening eventually. If neither party has anything for a meeting, you can cancel it, but you’d be surprised how many little things come up in regular sessions that wouldn’t necessitate their own meeting. Also, if you’re only scheduling sessions when they’re needed, there’s a tendency to only schedule sessions when something goes wrong. When that happens, mentoring sessions can feel like a punishment.

    Frequency is going to differ based on a lot of factors—it might be weekly or it might be once a quarter, and it might take a few sessions to figure that out. The rule of thumb is to start with more frequency. If a mentee is at a point where he or she can work independently and still make good progress, you can probably start meeting less frequently.

    Work together with your mentee to define an objective. Why does your mentee want to improve? An objective can be somewhat loosely defined, but it should have a specific outcome tied to the individual’s career. Being a good designer is too loose, but getting an excellent portfolio ready for a first job is much better. Being a great developer is similarly vague, but being a subject matter expert on a niche technology is much more helpful. This can and probably will end up changing as you and your mentee learn more, but it will at least give you a direction to head in.

    Once the objective is defined, create goals to establish milestones. Read up on SMART goals and make sure your mentee knows how to define them. Each goal should help your mentee toward his or her objective and should be a single measurable step. If a goal is not met in the specified time frame, it’s not the end of the world—just set a new one. If goals are consistently not met, you may have to have a hard conversation with your mentee about how realistic the goals are. Just make sure your mentee is constantly moving toward their objective.

    Make a loose agenda for your sessions. There should be some flexibility for urgent topics that come up, but you should know ahead of time what topics you want to discuss or ask about. The agenda should make sense to you and your mentee, so you’ll probably want to craft your own, but here’s one to get you started:

    1. How are you feeling?
    2. What have you been doing?
    3. How are you progressing toward your goals?
    4. How have you succeeded?
    5. What do you want to accomplish in the near future?

    Lastly, don’t forget to write everything down. It doesn’t matter how good your memory is; things will be lost between sessions if you don’t write them down. Write down notes for each section of your agenda, and review them before the next session. By doing this, there will be consistency between sessions, and you’ll often resolve issues that may have otherwise slipped through the cracks.

    Be a mentor

    Remember, you don’t have to be a famous speaker, a renowned expert, or even at the top of the career ladder to be a good mentor—you just have to be able to articulate what what got you where you are today to someone who’s not there yet. If you are willing to do this authentically by being present, positive, patient, and productive, you can be a great mentor today.

  • Using Webfonts

    A note from the editors: We’re pleased to share an excerpt from Chapter 2 (“Using Webfonts") of Bram Stein's new book, Webfont Handbook, available now from A Book Apart.

    Now that you’ve selected a font, let’s put it on your website. Webfonts are defined in CSS through the @font-face rule. If you’re a web developer, you’ve most likely written, copied and pasted, or at the very least seen an @font-face rule. For the sake of completeness, though, let’s quickly run through a basic example:

    @font-face {
        font-family: Elena;
        src: url(elena-regular.woff);

    This creates a new webfont family that can be referenced through the font-family or font shorthand property. But something’s missing here. When referencing a webfont in a font stack, always make sure to include at least one fallback font in case the webfont fails to load. Here, if Elena fails to load, the browser will fall back on the generic serif font family:

    p {
        font-family: Elena, serif;

    We’ll talk more about fallback fonts and how they can be used to make your site appear to load faster in Chapter 3. For now, let’s keep our fallback stack simple by including only the generic serif and sans-serif font families.

    Font Families

    Creating a font family with multiple styles is accomplished by creating an @font-face rule for each style and using the same font-family name. The following @font-face rules create a family with a normal and bold style:

    @font-face {
        font-family: Elena;
        src: url(elena-regular.woff);
        font-weight: normal;
    @font-face {
        font-family: Elena;
        src: url(elena-bold.woff);
        font-weight: bold;

    You can use this font family in your CSS by referencing the family name and weight in your selectors. This applies the regular style to paragraphs and the bold style to strong paragraphs:

    p {
        font-family: Elena, serif;
    p strong {
        font-weight: bold;

    Besides font-weight, @font-face also accepts the font-style and font-stretch property descriptors, which define styles such as italic and condensed. All three property descriptors can be used to create a single font family with multiple styles. Theoretically, this lets you create a family containing 243 individual styles (nine font-weight values × three font-style values × nine font-stretch values). In practice, however, you’re limited to twenty-seven values, since some browsers don’t support font-stretch (Fig 2.1).

    Internet Explorer 8 Internet Explorer 9-11 Edge Chrome Firefox Safari Opera Android System
    No Yes Yes Yes Yes No Yes No

    Fig 2.1: Browser support for font-stretch at time of writing. (Check caniuse.com for current and version-specific browser support.)

    With luck, the remaining browsers will implement the font-stretch property soon, and you will be able to use all 243 font classifications.

    Font Formats

    The src descriptor tells a browser where to get a font file. The previous examples used a single font format, but you’ll often see URLs to multiple font formats combined with format hints, which are appended after the URL using the format("value") syntax. Format hints tell the browser what the format of the font file at a given URL is.

    @font-face {
        font-family: Elena;
        src: url(elena-regular.woff2) format("woff2"),
            url(elena-regular.woff) format("woff");

    If you list multiple formats, modern browsers will pick the first format they support based on the format hint. Therefore, it’s important to list webfont formats in the order of best compression to least. Even though format hints are optional, always include them—they let the browser know about the format without needing to download the font. For example, if a browser does not support WOFF2, but does support WOFF, it can skip the WOFF2 font file based on the format hint.

    Browsers support several webfont formats: OpenType (TrueType), EOT, WOFF, and WOFF2. Some browsers also support SVG fonts, but they’re deprecated and should no longer be used (and should not be confused with the new OpenType-SVG format). EOT, WOFF, and WOFF2 are technically not font formats. They are compressed OpenType files with varying degrees of compression. WOFF2 offers the best compression, followed by WOFF and EOT (Fig 2.2).

    Format Internet Explorer 8 Internet Explorer 9-11 Edge Chrome Firefox Safari Opera Android System
    WOFF2 No No Yes Yes Yes Yes Yes No
    WOFF No Yes Yes Yes Yes Yes Yes Yes
    OpenType No Yes Yes Yes Yes Yes Yes Yes
    EOT Yes Yes No No No No No No

    Fig 2.2: Browser support for font formats at the time of writing. Look for up-to-date and version-specific browser support for font formats at caniuse.com.

    In researching coverage for all browsers, you may have come across something called the bulletproof @font-face syntax by Fontspring. The bulletproof syntax uses EOT, WOFF2, WOFF, raw OpenType, and SVG font files for maximum browser coverage:

    @font-face {
        font-family: Elena;
        src: url(elena.eot?#iefix) format("embedded-opentype"),
             url(elena.woff2) format("woff2"),
             url(elena.woff) format("woff"),
             url(elena.otf) format("opentype"),
             url(elena.svg#elena) format("svg");

    The first URL line might look a little odd to you. Versions of Internet Explorer 8 and below do not support the syntax for multiple font formats, and treat the entire value of the src property as the URL. The bulletproof syntax tricks Internet Explorer 8 and below into thinking that the remaining URLs are part of the fragment identifier of the first URL. Because fragment identifiers are ignored when downloading files, Internet Explorer 8 and below simply use the first URL. Browsers other than Internet Explorer will skip the line because they do not support EOT. The rest of the entries are what you would expect: font formats listed in order of preference.

    But is the bulletproof syntax still relevant? No. In fact, I think it’s harmful. SVG fonts are deprecated and only supported by browsers that are no longer in use. Most websites support Internet Explorer 9 and up, yet the syntax lists EOT as the first preferred font format. Even though Internet Explorer 9 and up support WOFF, those versions will still download the EOT file, simply because it is listed first.

    Because most websites no longer support old browsers, I highly recommend using a simplified syntax. This simplified syntax covers all modern browsers, as well as slightly older ones that are still in active use, such as Android 4.4 and earlier:

    @font-face {
        font-family: Elena;
        src: url(elena.woff2) format("woff2"),
             url(elena.woff) format("woff"),
             url(elena.otf) format("opentype");

    Even though older Android versions are still used, worldwide reliance on these browsers is rapidly dwindling. Soon you will probably be able to drop the raw OpenType format as well, and simplify the syntax even further:

    @font-face {
        font-family: Elena;
        src: url(elena.woff2) format("woff2"),
             url(elena.woff) format("woff");

    In this case, someone running an older browser will simply see your fallback fonts instead of the webfont. That’s fine; they can still read the content in the fallback font. (More on fallback fonts later.)

    There’s another possible value for the src descriptor. The local function takes the name of a local font family. If the font happens to be installed on the system, the browser will use that instead, thereby avoiding an extra download.

    @font-face {
        font-family: Elena;
        src: local("Elena"),
             url(elena-regular.woff2) format("woff2"),
             url(elena-regular.woff) format("woff");

    While this may seem like a great optimization, nothing guarantees that the local font matches your webfont. You may get a different version of the font, a font with different language support, or even an entirely different font. For that reason, I usually recommend not using the local function unless you find these downsides acceptable.

    Want to read more?

    This excerpt from Webfont Handbook will help you get started. Order the full copy today, as well as other excellent titles from A Book Apart.

    Cover from Webfont Handbook
Search Engine Watch
Keep updated with major stories about search engine marketing and search engines as published by Search Engine Watch.
Search Engine Watch
ClickZ News
Breaking news, information, and analysis.
CNN.com - RSS Channel - App Tech Section
CNN.com delivers up-to-the-minute news and information on the latest top stories, weather, entertainment, politics and more.
CNN.com - RSS Channel - App Tech Section
  • Just as we now realize that fast food was "engineered to addict us," says author Franklin Foer, we must recognize the role that Big Tech plays in "shaping our future as a species."
  • One Russian-linked campaign posing as part of the Black Lives Matter movement used Facebook, Instagram, Twitter, YouTube, Tumblr and Pokémon Go and even contacted some reporters in an effort to exploit racial tensions and sow discord among Americans.
  • The Rosetta spacecraft was launched in 2004 and arrived at Comet 67P/Churyumov-Gerasimenko on August 6, 2014, becoming the first probe to rendezvous with a comet. On November 12, Rosetta dropped its Philae lander to the comet's surface -- another first. But Philae bounced and didn't grab onto the comet in its designated landing spot. After three days, the lander's battery died and it went into hibernation. It woke up and briefly communicated with Rosetta in June and July 2015 as the comet came closer to the sun. Mission scientists weren't sure exactly where the probe had ended up. Until now.
  • Digital artist Jan Frojdman spent three weeks shifting through 33,000 images obtained from NASA to create this 3D model of Mars.
  • Members of the Cassini mission say goodbye to the spacecraft, their coworkers and some long-held traditions.

Ако решите, че "как се прави сайт" ръководството може да бъде полезно и за други хора, моля гласувайте за сайта:

+добави в любими.ком Елате в .: BGtop.net :. Топ класацията на българските сайтове и гласувайте за този сайт!!!

Ако желаете да оставите коментар към статията, трябва да се регистрирате.