{"rowid": 32, "title": "Cohesive UX", "contents": "With Yosemite, Apple users can answer iPhone calls on their MacBooks. This is weird. And yet it\u2019s representative of a greater trend toward cohesion.\n\nShortly after upgrading to Yosemite, a call came in on my iPhone and my MacBook \u201crang\u201d in parallel. And I was all, like, \u201cWut?\u201d This was a new feature in Yosemite, and honestly it was a little bizarre at first.\n\n Apple promotional image showing a phone call ringing simultaneously on multiple devices.\n\nHowever, I had just spoken at a conference on the very topic you\u2019re reading about now, and therefore I appreciated the underlying concept: the cohesion of user experience, the cohesion of screens.\n\nThis is just one of many examples I\u2019ve encountered since beginning to speak about this topic months ago. But before we get ahead of ourselves, let\u2019s look back at the past few years, specifically the role of responsive web design.\n\nRWD != cohesive experience\n\nI needn\u2019t expound on the virtues of responsive web design (RWD). You\u2019ve likely already encountered more than a career\u2019s worth on the topic. This is a good thing. Count me in as one of its biggest fans.\n\nHowever, if we are to sing the praises of RWD, we must also acknowledge its shortcomings. One of these is that RWD ends where the browser ends. For all its goodness, RWD really has no bearing on native apps or any other experiences that take place outside the browser. This makes it challenging, therefore, to create cohesion for multi-screen users if RWD is the only response to \u201clet\u2019s make it work everywhere.\u201d\n\nWe need something that incorporates the spirit of RWD while unifying all touchpoints for the entire user experience\u2014single device or several devices, in browser or sans browser, native app or otherwise.\n\nI call this cohesive UX, and I believe it\u2019s the next era of successful user experiences.\n\nToward a unified whole\n\nSimply put, the goal of cohesive UX is to deliver a consistent, unified user experience regardless of where the experience begins, continues, and ends.\n\nTwo facets are vital to cohesive UX:\n\n\n\tFunction and form\n\tData symmetry\n\n\nLet\u2019s examine each of these.\n\nFunction AND form\n\nFunction over form, of course. Right? Not so fast, kiddo.\n\nConsider Bruce Lawson\u2019s dad. After receiving an Android phone for Christmas and thumbing through his favorite sites, he was puzzled why some looked different from their counterparts on the desktop. \u201cWhen a site looked radically different,\u201d Bruce observed, \u201che\u2019d check the URL bar to ensure that he\u2019d typed in the right address. In short, he found RWD to be confusing and it meant he didn\u2019t trust the site.\u201d A lack of cohesive form led to a jarring experience for Bruce\u2019s dad.\n\nNow, if I appear to be suggesting websites must look the same in every browser\u2014you already learned they needn\u2019t\u2014know that I recognize the importance of context, especially in regards to mobile. I made a case for this more than seven years ago.\n\nRather, cohesive UX suggests that form deserves the same respect as function when crafting user experiences that span multiple screens or devices. And users are increasingly comfortable traversing media. For example, more than 40% of adults in the U.S. owning more than one device start an activity on one screen and finish it on another, according to a study commissioned by Facebook. I suspect that percentage will only increase in 2015, and I suspect the tech-affluent readers of 24 ways are among the 40%.\n\nThere are countless examples of cohesive form and function. Consider Gmail, which displays email conversations visually as a stack that can be expanded and collapsed like the bellows of an accordion. This visual metaphor has been consistent in virtually any instance of Gmail\u2014website or app\u2014since at least 2007 when I captured this screenshot on my Nokia 6680:\n\n Screenshot captured while authoring Mobile Web Design (2007). Back then we didn\u2019t call this an app, but rather a \u2018smart client\u2019.\n\nWhen the holistic experience is cohesive as it is with Gmail, users\u2019 mental models and even muscle memory are preserved.1 Functionality and aesthetics align with the expectations users have for how things should function and what they should look like. In other words, the experience is roughly the same across screens.\n\nBut don\u2019t be ridiculous, peoples. Note that I said \u201croughly.\u201d It\u2019s important to avoid mindless replication of aesthetics and functionality for the sake of cohesion. Again, the goal is a unified whole, not a carbon copy. Affordances and concessions should be made as context and intuition require. For example, while Facebook users are accustomed to top-aligned navigation in the browser, they encounter bottom-aligned navigation in the iOS app as justified by user testing:\n\nThe iOS app model has held up despite many attempts to better it: http://t.co/rSMSAqeh9m pic.twitter.com/mBp36lAEgc\u2014 Luke Wroblewski (@lukew) December 10, 2014\n\n\nDespite the (rather minor) lack of consistency in navigation placement, other elements such as icons, labels, and color theme work in tandem to produce a unified, holistic whole.\n\nData symmetry\n\nData symmetry involves the repetition, continuity, or synchronicity of data across screens, devices, and platforms. As regards cohesive UX, data includes not just the material (such as an article you\u2019re writing on Medium) but also the actions that can be performed on or with that material (such as Medium\u2019s authoring tools). That is to say, \u201csync verbs, not just nouns\u201d (Josh Clark).\n\nIn my estimation, Amazon is an archetype of data symmetry, as is Rdio. When logged in, data is shared across virtually any device of any kind, irrespective of using a browser or native app. Add a product to your Amazon cart from your phone during the morning commute, and finish the transaction at work on your laptop. Easy peasy.\n\nAmazon\u2019s aesthetics are crazy cohesive, to boot:\n\n Amazon web (left) and native app (right).\n\nWith Rdio, not only are playlists and listening history synced across screens as you would expect, but the cohesion goes even further. Rdio\u2019s remote control feature allows you to control music playing on one device using another device, all in real time.\n\n Rdio\u2019s remote control feature, as viewed on my MacBook while music plays on my iMac.\n\nAt my office I often work from my couch using my MacBook, but my speakers are connected to my iMac. When signed in to Rdio on both devices, my MacBook serves as proxy for controlling Rdio on my iMac, much the same as any Yosemite-enabled device can serve as proxy for an incoming iPhone call.\n\n Me, in my office. Note the iMac and speakers at far right.\n\nThis is a brilliant example of cohesive design, and it\u2019s executed entirely via the cloud.\n\nThings to consider\n\nConsider the following when crafting cohesive experiences:\n\n\n\tInventory the elements that comprise your product experience, and cohesify them.2\nConsider things such as copy, tone, typography, iconography, imagery, flow, placement, brand identification, account data, session data, user preferences, and so on. Then, create cohesion among these elements to the greatest extent possible, while adapting to context as needed.\n\tStore session data in the cloud rather than locally.\nFor example, avoid using browser cookies to store shopping cart data, as cookies are specific to a single browser on a single device. Instead, store this data in the cloud so it can be accessed from other devices, as well as beyond the browser.\n\tConsider using web views when developing your native app.\n\u201cYou\u2019re already using web apps in native wrappers without even noticing it,\u201d Lukas Mathis contends. \u201cThe fact that nobody even notices, the fact that this isn\u2019t a story, shows that, when it comes to user experience, web vs. native doesn\u2019t matter anymore.\u201d Web views essentially allow you to display HTML content inside a native wrapper. This can reduce the time and effort needed to make the overall experience cohesive. So whereas the navigation bar may be rendered by the app, for example, the remaining page display may be rendered via the web. There\u2019s readily accessible documentation for using web views in C++, iOS, Android, and so forth.\n\n\nNature is calling\n\nReturning to the example of Yosemite and sychronized phone calls, is it really that bizarre in light of cohesive UX? Perhaps at first. But I suspect that, over time, Yosemite\u2019s cohesiveness \u2014 and the cohesiveness of other examples like the ones we\u2019ve discussed here \u2014 will become not only more natural but more commonplace, too.\n\n\n\n1 I browse Flipboard on my iPad nearly every morning as part of my breakfast routine. Swiping horizontally advances to the next page. Countless times I\u2019ve done the same gesture in Flipboard for iPhone only to have it do nothing. This is because the gesture for advancing is vertical on phones. I\u2019m so conditioned to the horizontal swipe that I often fail to make the switch to vertical swipe, and apparently others suffer from the same muscle memory, too.\n\n2 Cohesify isn\u2019t a thing. But chances are you understood what I meant. Yay neologism!", "year": "2014", "author": "Cameron Moll", "author_slug": "cameronmoll", "published": "2014-12-24T00:00:00+00:00", "url": "https://24ways.org/2014/cohesive-ux/", "topic": "ux"} {"rowid": 44, "title": "Taglines and Truisms", "contents": "To bring her good luck, \u201cwhite rabbits\u201d was the first thing that my grandmother said out loud on the first day of every month. We all need a little luck, but we shouldn\u2019t rely on it, especially when it comes to attracting new clients.\n\nThe first thing we say to a prospective client when they visit our website for the first time helps them to understand not only what we do but why we do it. We can also help them understand why they should choose to work with us over one of our competitors.\n\nTake a minute or two to look at your competitors\u2019 websites. What\u2019s the first thing that they say about themselves? Do they say that they \u201cdesign delightful digital experiences,\u201d \u201ccraft beautiful experiences\u201d or \u201ccreate remarkable digital experiences?\u201d\n\nIt\u2019s easy to find companies who introduce themselves with what they do, their proposition, but what a company does is only part of their story. Their beliefs and values, what they stand for why they do what they do are also important. \n\nWhen someone visits our websites for the first time, we have only a brief moment to help them understand us. To help us we can learn from the advertising industry, where the job of a tagline is to communicate a concept, deliver a message and sell a product, often using only a few words.\n\nWhen an advertising campaign is effective, its tagline stays with you, sometimes long after that campaign is over. For example, can you remember which company or brand these taglines help to sell? (Answers at the bottom of the article:)\n\n\nThe Ultimate Driving Machine\nJust Do It\nDon\u2019t Leave Home Without It\n\n\nA clever tagline isn\u2019t just a play on words, although it can include one. A tagline does far more than help make your company memorable. Used well, it brings together notions of what makes your company and what you offer special. Then it expresses those notions in a few words or possibly a short sentence. \n\nI\u2019m sure that everyone can find examples of company slogans written in the type of language that should stay within the walls of a marketing department. We can also find taglines where the meaning is buried so deep that the tag itself becomes effectively meaningless.\n\nA meaningful tagline supports our ideas about who we are and what we offer, and provides a platform for different executions of them, sometimes over a period of time. For a tagline to work well, it must allow for current and future ideas about a brand.\n\nIt must also be meaningful to our brand and describe a truism, a truth that need not be a fact or statistic, but something that\u2019s true about us, who we are, what we do and why that\u2019s distinctive. It can be obvious, funny, serious or specific but above all it must be true. It should also be difficult to argue with, making your messages difficult to argue with too.\n\nI doubt that I need remind you who this tagline belongs to:\n\n\n\tThere are some things money can\u2019t buy. For everything else there\u2019s MasterCard.\n\n\nThat tagline was launched in 1997 by McCann-Erickson along with the \u201cPriceless\u201d campaign and it helped establish MasterCard as a friendlier credit card company, one with a sense of humour. \n\nMasterCard\u2019s truism is that the things which really matter in life can\u2019t be bought. They are worth more than anything that a monetary value can be applied to. In expressing that truism through the tagline, MasterCard\u2019s advertising tells people to use not just any credit card, but their MasterCard, to pay for everything they buy.\n\n\u201cGuinness is good for you\u201d may have been a stretch, but \u201cGood things come to those who wait\u201d builds on the truism that patience is a virtue and therefore a good pint of Guinness takes time to pour (119.5 seconds. I know you were wondering.)\n\nThe fact that British Airways flies to more destinations than any other airline is their truism, and led their advertisers to the now famous tagline, \u201cThe world\u2019s favourite airline.\u201d\n\n\n\nAt my company, Stuff & Nonsense, we\u2019ve been thinking about taglines as we think about our position within an industry that seems full of companies who \u201cdesign\u201d, \u201ccraft\u201d, and \u201ccreate\u201d \u201cdelightful\u201d, \u201cbeautiful\u201d, \u201cremarkable digital experiences\u201d.\n\nMuch of what made us different has changed along with the type of work we\u2019re interested in doing. Our work\u2019s expanded beyond websites and now includes design for mobile and other media. It\u2019s true we can\u2019t know how or where it will be seen. The ways that we make it are flexible too as we\u2019re careful not to become tied to particular tools or approaches. \n\nIt\u2019s also true that we\u2019re a small team. One that\u2019s flexible enough to travel around the world to work alongside our clients. We join their in-house teams and we collaborate with them in ways that other agencies often find more difficult. We know that our clients appreciate our flexibility and have derived enormous value from it. We know that we\u2019ve won business because of it and that it\u2019s now a big part of our proposition.\n\nOur truism is that we\u2019re flexible, \u201cFabulously flexible\u201d as our tagline now expresses. And although we know that there may be other agencies who can be similarly flexible \u2013 after all, being flexible is not a unique selling proposition \u2013 only we do it so fabulously.\n\n\n\nAs the old year rolls into the new, how will your company describe what you do in 2015? More importantly, how will you tell prospective clients why you do it, what matters to you and why they should work with you?\n\nStart by writing a list of truisms about your company. Write as many as you can, but then whittle that list down to just one, the most important truth. Work on that truism to create a tagline that\u2019s meaningful, difficult to be argue with and, above all, uniquely yours.\n\nAnswers\n\n\nThe Ultimate Driving Machine (BMW)\nJust Do It (Nike)\nDon\u2019t Leave Home Without It (American Express)", "year": "2014", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2014-12-23T00:00:00+00:00", "url": "https://24ways.org/2014/taglines-and-truisms/", "topic": "business"} {"rowid": 26, "title": "Integrating Contrast Checks in Your Web Workflow", "contents": "It\u2019s nearly Christmas, which means you\u2019ll be sure to find an overload of festive red and green decorating everything in sight\u2014often in the ugliest ways possible. \n\nWhile I\u2019m not here to battle holiday tackiness in today\u2019s 24 ways, it might just be the perfect reminder to step back and consider how we can implement colour schemes in our websites and apps that are not only attractive, but also legible and accessible for folks with various types of visual disabilities.\n\n This simulated photo demonstrates how red and green Christmas baubles could appear to a person affected by protanopia-type colour blindness\u2014not as festive as you might think. Source: Derek Bruff\n\nI\u2019ve been fortunate to work with Simply Accessible to redesign not just their website, but their entire brand. Although the new site won\u2019t be launching until the new year, we\u2019re excited to let you peek under the tree and share a few treats as a case study into how we tackled colour accessibility in our project workflow. Don\u2019t worry\u2014we won\u2019t tell Santa!\n\nCreate a colour game plan\n\nA common misconception about accessibility is that meeting compliance requirements hinders creativity and beautiful design\u2014but we beg to differ. Unfortunately, like many company websites and internal projects, Simply Accessible has spent so much time helping others that they had not spent enough time helping themselves to show the world who they really are. This was the perfect opportunity for them to practise what they preached.\n\nAfter plenty of research and brainstorming, we decided to evolve the existing Simply Accessible brand. Or, rather, salvage what we could. There was no established logo to carry into the new design (it was a stretch to even call it a wordmark), and the Helvetica typography across the site lacked any character. The only recognizable feature left to work with was colour. It was a challenge, for sure: the oranges looked murky and brown, and the blues looked way too corporate for a company like Simply Accessible. We knew we needed to inject a lot of personality.\n\nThe old Simply Accessible website and colour palette.\n\nAfter an audit to round up every colour used throughout the site, we dug in deep and played around with some ideas to bring some new life to this palette. \n\nChoose effective colours\n\nWhether you\u2019re starting from scratch or evolving an existing brand, the first step to having an effective and legible palette begins with your colour choices. While we aren\u2019t going to cover colour message and meaning in this article, it\u2019s important to understand how to choose colours that can be used to create strong contrast\u2014one of the most important ways to create hierarchy, focus, and legibility in your design.\n\nThere are a few methods of creating effective contrast.\n\nLight and dark colours\n\nThe contrast that exists between light and dark colours is the most important attribute when creating effective contrast.\n\nTry not to use colours that have a similar lightness next to each other in a design.\n\n\n\nThe red and green colours on the left share a similar lightness and don\u2019t provide enough contrast on their own without making some adjustments. Removing colour and showing the relationship in greyscale reveals that the version on the right is much more effective. \n\nIt\u2019s important to remember that red and green colour pairs cause difficulty for the majority of colour-blind people, so they should be avoided wherever possible, especially when placed next to each other. \n\nComplementary contrast\n\n\n\nEffective contrast can also be achieved by choosing complementary colours (other than red and green), that are opposite each other on a colour wheel.\n\nThese colour pairs generally work better than choosing adjacent hues on the wheel.\n\nCool and warm contrast\n\nContrast also exists between cool and warm colours on the colour wheel.\n\nImagine a colour wheel divided into cool colours like blues, purples, and greens, and compare them to warm colours like reds, oranges and yellows.\n\n\n\nChoosing a dark shade of a cool colour, paired with a light tint of a warm colour will provide better contrast than two warm colours or two cool colours. \n\nDevelop colour concepts\n\nAfter much experimentation, we settled on a simple, two-colour palette of blue and orange, a cool-warm contrast colour scheme. We added swatches for call-to-action messaging in green, error messaging in red, and body copy and form fields in black and grey. Shades and tints of blue and orange were added to illustrations and other design elements for extra detail and interest.\n\nFirst stab at a new palette.\n\nWe introduced the new palette for the first time on an internal project to test the waters before going full steam ahead with the website. It gave us plenty of time to get a feel for the new design before sharing it with the public.\n\nPutting the test palette into practice with an internal report\n\nIt\u2019s important to be open to changes in your palette as it might need to evolve throughout the design process. Don\u2019t tell your client up front that this palette is set in stone. If you need to tweak the colour of a button later because of legibility issues, the last thing you want is your client pushing back because it\u2019s different from what you promised.\n\nAs it happened, we did tweak the colours after the test run, and we even adjusted the logo\u2014what looked great printed on paper looked a little too light on screens.\n\nConsider how colours might be used\n\nDon\u2019t worry if you haven\u2019t had the opportunity to test your palette in advance. As long as you have some well-considered options, you\u2019ll be ready to think about how the colour might be used on the site or app. \n\nObviously, in such early stages it\u2019s unlikely that you\u2019re going to know every element or feature that will appear on the site at launch time, or even which design elements could be introduced to the site later down the road. There are, of course, plenty of safe places to start.\n\nFor Simply Accessible, I quickly mocked up these examples in Illustrator to get a handle on the elements of a website where contrast and legibility matter the most: text colours and background colours. While it\u2019s less important to consider the contrast of decorative elements that don\u2019t convey essential information, it\u2019s important for a reader to be able to discern elements like button shapes and empty form fields.\n\nA basic list of possible colour combinations that I had in mind for the Simply Accessible website\n\nRun initial tests\n\nOnce these elements were laid out, I manually plugged in the HTML colour code of each foreground colour and background colour on Lea Verou\u2019s Contrast Checker. I added the results from each colour pair test to my document so we could see at a glance which colours needed adjustment or which colours wouldn\u2019t work at all.\n\nNote: Read more about colour accessibility and contrast requirements\n\n\n\n\n\nAs you can see, a few problems were revealed in this test. To meet the minimum AA compliance, we needed to slightly darken the green, blue, and orange background colours for text\u2014an easy fix. A more complicated problem was apparent with the button colours. I had envisioned some buttons appearing over a blue background, but the contrast ratios were well under 3:1. Although there isn\u2019t a guide in WCAG for contrast requirements of two non-text elements, the ISO and ANSI standard for visible contrast is 3:1, which is what we decided to aim for.\n\nWe also checked our colour combinations in Color Oracle, an app that simulates the most extreme forms of colour blindness. It confirmed that coloured buttons over blue backgrounds was simply not going to work. The contrast was much too low, especially for the more common deuteranopia and protanopia-type deficiencies.\n\nHow our proposed colour pairs could look to people with three types of colour blindness\n\nMake adjustments if necessary\n\n\n\nAs a solution, we opted to change all buttons to white when used over dark coloured backgrounds. In addition to increasing contrast, it also gave more consistency to the button design across the site instead of introducing a lot of unnecessary colour variants.\n\nPutting more work into getting compliant contrast ratios at this stage will make the rest of implementation and testing a breeze. When you\u2019ve got those ratios looking good, it\u2019s time to move on to implementation.\n\nImplement colours in style guide and prototype\n\nOnce I was happy with my contrast checks, I created a basic style guide and added all the colour values from my colour exploration files, introduced more tints and shades, and added patterned backgrounds. I created examples of every panel style we were planning to use on the site, with sample text, links, and buttons\u2014all with working hover states. Not only does this make it easier for the developer, it allows you to check in the browser for any further contrast issues.\n\n\n\n\n\nRun a final contrast check\n\nDuring the final stages of testing and before launch, it\u2019s a good idea to do one more check for colour accessibility to ensure nothing\u2019s been lost in translation from design to code. Unless you\u2019ve introduced massive changes to the design in the prototype, it should be fairly easy to fix any issues that arise, particularly if you\u2019ve stayed on top of updating any revisions in the style guide.\n\nOne of the more well-known evaluation tools, WAVE, is web-based and will work in any browser, but I love using Chrome\u2019s Accessibility Tools. Not only are they built right in to the Inspector, but they\u2019ll work if your site is password-protected or private, too.\n\nChrome\u2019s Accessibility Tools audit feature shows that there are no immediate issues with colour contrast in our prototype \n\nThe human touch\n\nFinally, nothing beats a good round of user testing. Even evaluation tools have their flaws. Although they\u2019re great at catching contrast errors for text and backgrounds, they aren\u2019t going to be able to find errors in non-text elements, infographics, or objects placed next to each other where discernible contrast is important. \n\n\n\nOur final palette, compared with our initial ideas, was quite different, but we\u2019re proud to say it\u2019s not just compliant, but shows Simply Accessible\u2019s true personality. Who knows, it may not be final at all\u2014there are so many opportunities down the road to explore and expand it further.\n\n\n\nAccessibility should never be an afterthought in a project. It\u2019s not as simple as adding alt text to images, or running your site through a compliance checker at the last minute and assuming that a pass means everything is okay. Considering how colour will be used during every stage of your project will help avoid massive problems before launch, or worse, launching with serious issues. \n\nIf you find yourself working on a personal project over the Christmas break, try integrating these checks into your workflow and make colour accessibility a part of your New Year\u2019s resolutions.", "year": "2014", "author": "Geri Coady", "author_slug": "gericoady", "published": "2014-12-22T00:00:00+00:00", "url": "https://24ways.org/2014/integrating-contrast-checks-in-your-web-workflow/", "topic": "design"} {"rowid": 36, "title": "Naming Things", "contents": "There are only two hard things in computer science: cache invalidation and naming things.\nPhil Karlton\n\n\nBeing a professional web developer means taking responsibility for the code you write and ensuring it is comprehensible to others. Having a documented code style is one means of achieving this, although the size and type of project you\u2019re working on will dictate the conventions used and how rigorously they are enforced.\n\nWorking in-house may mean working with multiple developers, perhaps in distributed teams, who are all committing changes \u2013 possibly to a significant codebase \u2013 at the same time. Left unchecked, this codebase can become unwieldy. Coding conventions ensure everyone can contribute, and help build a product that works as a coherent whole.\n\nEven on smaller projects, perhaps working within an agency or by yourself, at some point the resulting product will need to be handed over to a third party. It\u2019s sensible, therefore, to ensure that your code can be understood by those who\u2019ll eventually take ownership of it.\n\nPut simply, code is read more often than it is written or changed. A consistent and predictable naming scheme can make code easier for other developers to understand, improve and maintain, presumably leaving them free to worry about cache invalidation.\n\nLet\u2019s talk about semantics\n\nNames not only allow us to identify objects, but they can also help us describe the objects being identified.\n\nSemantics (the meaning or interpretation of words) is the cornerstone of standards-based web development. Using appropriate HTML elements allows us to create documents and applications that have implicit structural meaning. Thanks to HTML5, the vocabulary we can choose from has grown even larger.\n\nHTML elements provide one level of meaning: a widely accepted description of a document\u2019s underlying structure. It\u2019s only with the mutual agreement of browser vendors and developers that
indicates a paragraph.\n\nYet (with the exception of widely accepted microdata and microformat schemas) only HTML elements convey any meaning that can be parsed consistently by user agents. While using semantic values for class names is a noble endeavour, they provide no additional information to the visitor of a website; take them away and a document will have exactly the same semantic value.\n\nI didn\u2019t always think this was the case, but the real world has a habit of changing your opinion. Much of my thinking around semantics has been informed by the writing of my peers. In \u201cAbout HTML semantics and front-end architecture\u201d, Nicholas Gallagher wrote:\n\n\n\tThe important thing for class name semantics in non-trivial applications is that they be driven by pragmatism and best serve their primary purpose \u2013 providing meaningful, flexible, and reusable presentational/behavioural hooks for developers to use.\n\n\nThese thoughts are echoed by Harry Roberts in his CSS Guidelines:\n\n\n\tThe debate surrounding semantics has raged for years, but it is important that we adopt a more pragmatic, sensible approach to naming things in order to work more efficiently and effectively. Instead of focussing on \u2018semantics\u2019, look more closely at sensibility and longevity \u2013 choose names based on ease of maintenance, not for their perceived meaning.\n\n\nNaming methodologies\n\nFront-end development has undergone a revolution in recent years. As the projects we\u2019ve worked on have grown larger and more important, our development practices have matured. The pros and cons of object-orientated approaches to CSS can be endlessly debated, yet their introduction has highlighted the usefulness of having documented naming schemes.\n\nJonathan Snook\u2019s SMACSS (Scalable and Modular Architecture for CSS) collects style rules into five categories: base, layout, module, state and theme. This grouping makes it clear what each rule does, and is aided by a naming convention:\n\n\n\tBy separating rules into the five categories, naming convention is beneficial for immediately understanding which category a particular style belongs to and its role within the overall scope of the page. On large projects, it is more likely to have styles broken up across multiple files. In these cases, naming convention also makes it easier to find which file a style belongs to.\n\n\tI like to use a prefix to differentiate between layout, state and module rules. For layout, I use l- but layout- would work just as well. Using prefixes like grid- also provide enough clarity to separate layout styles from other styles. For state rules, I like is- as in is-hidden or is-collapsed. This helps describe things in a very readable way.\n\n\nSMACSS is more a set of suggestions than a rigid framework, so its ideas can be incorporated into your own practice. Nicholas Gallagher\u2019s SUIT CSS project is far more strict in its naming conventions:\n\n\n\tSUIT CSS relies on structured class names and meaningful hyphens (i.e., not using hyphens merely to separate words). This helps to work around the current limits of applying CSS to the DOM (i.e., the lack of style encapsulation), and to better communicate the relationships between classes.\n\n\nOver the last year, I\u2019ve favoured a BEM-inspired approach to CSS. BEM stands for block, element, modifier, which describes the three types of rule that contribute to the style of a single component. This means that, given the following markup:\n\n