{"rowid": 77, "title": "Colour Accessibility", "contents": "Here\u2019s a quote from Josef Albers:\n\nIn visual perception a colour is almost never seen as it really is[\u2026] This fact makes colour the most relative medium in art.Josef Albers, Interaction of Color, 1963\n\nAlbers was a German abstract painter and teacher, and published a very famous course on colour theory in 1963. Colour is very relative \u2014 not just in the way that it appears differently across different devices due to screen quality and colour management, but it can also be seen differently by different people \u2014 something we really need to be more mindful of when designing.\n\nWhat is colour blindness?\n\nColour blindness very rarely means that you can\u2019t see any colour at all, or that people see things in greyscale. It\u2019s actually a decreased ability to see colour, or a decreased ability to tell colours apart from one another. \n\nHow does it happen?\n\nInside the typical human retina, there are two types of receptor cells \u2014 rods and cones. Rods are the cells that allow us to see dark and light, and shape and movement. Cones are the cells that allow us to perceive colour. There are three types of cones, each responsible for absorbing blue, red, and green wavelengths in the spectrum.\n\nProblems with colour vision occur when one or more of these types of cones are defective or absent entirely, and these problems can either be inherited through genetics, or acquired through trauma, exposure to ultraviolet light, degeneration with age, an effect of diabetes, or other factors.\n\nColour blindness is a sex-linked trait and it\u2019s much more common in men than in women. The most common type of colour blindness is called deuteranomaly which occurs in 7% of males, but only 0.5% of females. That\u2019s a pretty significant portion of the population if you really stop and think about it \u2014\u00a0we can\u2019t ignore this demographic.\n\nWhat does it look like?\n\nPeople with the most common types of colour blindness, like protanopia and deuteranopia, have difficulty discriminating between red and green hues. There are also forms of colour blindness like tritanopia, which affects perception of blue and yellow hues. Below, you can see what a colour wheel might look like to these different people.\n\n\n\nWhat can we do?\n\nHere are some things you can do to make your websites and apps more accessible to people with all types of colour blindness.\n\nInclude colour names and show examples\n\nOne of the most common annoyances I\u2019ve heard from people who are colour-blind is that they often have difficulty purchasing clothing and they will sometimes need to ask another person for a second opinion on what the colour of the clothing might actually be. While it\u2019s easier to shop online than in a physical store, there are still accessibility issues to consider on shopping websites.\n\nLet\u2019s say you\u2019ve got a website that sells T-shirts. If you only show a photo of the shirt, it may be impossible for a person to tell what colour the shirt really is. For clarification, be sure to reference the name of the colour in the description of the product.\n\n\n\nUnited Pixelworkers does a great job of following this rule. The St. John\u2019s T-shirt has a quirky palette inspired by the unofficial pink, white and green Newfoundland flag, and I can imagine many people not liking it.\n\nAnother common problem occurs when a colour filter has been added to a product search. Here\u2019s an example from a clothing website with unlabelled colour swatches, and how that might look to someone with deuteranopia-type colour blindness.\n\n\n\nThe colour search filter below, from the H&M website, is much better since it uses names instead.\n\n\n\nAt first glance, Urban Outfitters also uses unlabelled colour swatches on product pages (below), but on closer inspection, the colour name is displayed on hover. This isn\u2019t an ideal solution, because although it\u2019ll work on a desktop browser, it won\u2019t work on a touchscreen device where hovering isn\u2019t an option. \n\n\n\nUsing overly fancy colour names, like the ones you might find labelling high-end interior paint can be just as confusing as not using a colour name at all. Names like grape instead of purple don\u2019t really give the viewer any useful information about what the colour actually is on a colour wheel. Is grape supposed to be purple, or could it refer to red grapes or even green? Stick with hue names as much as possible.\n\nAvoid colour-specific instructions\n\nWhen designing forms, avoid labelling required fields only with coloured text. It\u2019s safer to use a symbol cue like the asterisk which is colour-independent. \n\n\n\nA similar example would be directing a user to click a green button to purchase a product. Label your buttons clearly and reference them in the site copy by function, not colour, to avoid confusion.\n\nDon\u2019t rely on colour coding\n\nDesigning accessible maps and infographics can be much more challenging. \n\nDon\u2019t rely on colour coding alone \u2014 try to use a combination of colour and texture or pattern, along with precise labels, and reflect this in the key or legend. Combine a blue background with a crosshatched pattern, or a pink background with a stippled dot \u2014 your users will always have two pieces of information to work with.\n\n\n\nThe map of the London subway system is an iconic image not just in London, but around the world. Unfortunately, it contains some colours that are indistinguishable from each other to a person with a vision problem. This is true not only for the London underground, but also for any other wayfinding system that relies on colour coding as the only key in a legend. \n\n\n\nThere are printable versions of the map available online in black and white, using patterns and shades of black and grey that are distinguishable, but the point is that there would be no need for such a map if it were designed with accessibility in mind from the beginning. And, if you\u2019re a person who has a physical disability as well as a vision problem, the \u201cStep-Free\u201d guide map which shows stations is based on the original coloured map. \n\n\n\nProvide alternatives and customization\n\nWhile it\u2019s best to consider these issues and design your app to be accessible by default, sometimes this might not be possible. Providing alternative styles or allowing users to edit their own colours is a feature to keep in mind.\n\nThe developers of the game Faster Than Light created an alternate colour-blind mode and asked for public feedback to make sure that it passed the test. Not much needed to be done, but you can see they added stripes to the red zones and changed some outlines to blue.\n\n\n\niChat is also a good example. Although by default it uses coloured bubbles to indicate a user\u2019s status (available for chat, away or idle, or busy), included in the preferences is a \u201cUser Shapes to Indicate Status\u201d option, which changes the shape of the standard circles to green circles, yellow triangles and red squares.\n\n\n\nPay attention to contrast \n\nColours that are similar in value but different in hue may be easy to distinguish between for a user with good vision, but a person who suffers from colour blindness may not be able to tell them apart at all. Proofing your work in greyscale is a quick way to tell if there\u2019s enough contrast between the most important information in your design.\n\nCheck with a simulator\n\nThere are many tools out there for simulating different types of colour blindness, and it\u2019s worth checking your design to catch any potential problems up front. \n\nOne is called Sim Daltonism and it\u2019s available for Mac OS X. It\u2019ll show a pop-up preview next to your cursor and you can choose which type of colour blindness you want to test from a drop-down menu. \n\n\n\nYou can also proof for the two most common types of colour blindness right in Photoshop or Illustrator (CS4 and later) while you\u2019re designing. \n\n\n\nThe colour contrast check tool from designer and developer Jonathan Snook gives you the option to enter a colour code for a background, and a colour code for text, and it\u2019ll tell you if the colour contrast ratio meets the Web Content Accessibility Guidelines 2.0. You can use the built-in sliders to adjust your colours until they meet the compliant contrast ratios. This is a great tool to test your palette before going live.\n\n\n\nFor live websites, you can use the accessibility tool called WAVE, which also has a contrast checker. It\u2019s important to keep in mind, though, that while WAVE can identify contrast errors in text, other things can slip through, so a site that passes the test does not automatically mean it\u2019s accessible in reality.\n\nFor example, the contrast checker here doesn\u2019t notice that our red link in the introduction isn\u2019t underlined, and therefore could blend into the surrounding paragraph text. \n\n\n\nI know that once I started getting into the habit of checking my work in a simulator, I became more mindful of any potential problem areas and it was easier to avoid them up front. It\u2019s also made me question everything I see around me and it sends red flags off in my head if I think it\u2019s a serious colour blindness fail. Understanding that colour is relative in the planning stages and following these tips will help us make more accessible design for all.", "year": "2012", "author": "Geri Coady", "author_slug": "gericoady", "published": "2012-12-04T00:00:00+00:00", "url": "https://24ways.org/2012/colour-accessibility/", "topic": "design"} {"rowid": 93, "title": "Design Systems", "contents": "The most important part of responsive web design is that, no matter what the viewport width, the content is accessible in an optimum display. The best responsive designs are those that allow you to go from one optimised display to another, but with the feeling that these experiences are part of a greater product whole.\n\nResponsive design: where we\u2019ve been going wrong\n\nResponsive web design was a shock to my web designer system. Those of us who had already been designing sites for mobile probably had the biggest leap to make. We might have been detecting user agents in order to deliver a mobile-specific site, or using the slightly more familiar Bushido technique to deliver sites optimised for device type and viewport size, but either way our focus was on devices. A site was optimised for either a mobile phone or a desktop.\n\nResponsive web design brought us back to pre-table layout fluid sites that expanded or contracted to fit the viewport. This was a big difference to get our heads around when we were so used to designing for fixed-width layouts. Suddenly, an element could be any width or, at least, we needed to consider its maximum and minimum widths. Pixel perfection, while pretty, became wholly unrealistic, and a whole load of designers who prided themselves in detailed and precise designs got a bit scared.\n\nHanging on to our previous processes and typical deliverables led us to continue to optimise our sites for particular devices and provide pixel-perfect mockups for those device widths.\n\nWith all this we were concentrating on devices, not content, deliverables and not process, and making assumptions about users and their devices based on nothing but the width of the viewport.\n\nI don\u2019t think this is a crime, I think it was inevitable.\n\nWe can be up to date with our principles and ideals, but it\u2019s never as easy in practice. That\u2019s why it\u2019s more important than ever to share our successful techniques and processes. Let\u2019s drag each other into modern web design.\n\nDesign systems: the principles\n\nWhat are design systems?\n\nA visual design system is built out of the core components of typography, layout, shape or form, and colour. When considering the design of a whole product, a design system should also include patterns in user flow, content strategy, copy, and tone of voice. These concepts, design decisions or rules, created around the core components are used consistently across your product to create a cohesive feel, whether it\u2019s from one element to another, page to page, or viewport width to viewport width.\n\nResponsive design is one of the most important considerations in the components of a design system. For each component, you must decide what will unite the design across the viewports to maintain that consistent feel, and what parts of the design will differentiate in order to provide a flexible and optimal experience for different viewport sizes.\n\nComponents you might keep the same across viewports\n\n\n\ttypeface\n\tbase unit\n\tcolour\n\tshape/form\n\n\nComponents you might differentiate across viewports\n\n\n\tgrids\n\tlayout\n\tfont size\n\tmeasure (line length)\n\tleading (line height)\n\n\nContent: it must always be the same\n\nThe focus of a design system is the optimum display of content. As Mark Boulton put it, designing \u201ccontent out, not canvas in.\u201d Chris Armstrong puts the emphasis on not designing for viewports but for content \u2013 \u201cwe need to build on what we do know: content.\u201d In order to do this, we must share the same content across all devices and focus on how best to display and represent content through design system components.\n\nThe practical: core visual components\n\nTypography first\n\nWhen you work with a lot of text content, typography is the easiest way to set the visual tone of the design across all viewport widths. It\u2019s likely that you\u2019ll choose one or two typefaces to use across the whole system, but you might change the most legible font size, balanced with the most comfortable measure, as the viewport width changes.\n\nWhere typography meets layout\n\nThe unit on which you choose to base the grid and layout design, font sizes and leading could be based on the typeface, an optimal reading size, or something more arbitrary. Sometimes I\u2019ll choose a unit based on multiples of ten because it makes the maths in the CSS easier. Tim Brown suggests trying a modular scale. Chris Armstrong suggests basing it on your ideal measure, or the width of a fixed item of content such as an ad unit.\n\nGrids and layouts\n\nSensible grid design can be a flexible yet solid foundation for your design system layout component. But you must be wary in responsive design that a grid might not work across all widths: even four columns could make for very cramped content and one-word measures on smaller screens.\n\nMaybe the grid columns are something you differentiate across widths, but you can keep the concept of the grid consistent. If the content has blocks in groups of three, you might decide on a three-column grid which folds down to one column for narrow viewports. If the grid focuses on the idea of symmetry and has a four-column grid on larger viewports, it might fold down to two columns for narrower viewports. These consistencies may seem subtle, not at all obvious to many except the designer, but it\u2019s all these little constants and patterns across the whole of the design system that makes design decisions easier to make (as they adhere to the guiding concepts of your system), and give the product a uniform feel no matter what the device.\n\nShape or form\n\nThe shape or form components are concepts you already use in fixed-width web design for a strong, consistent look and feel. \n\nSince CSS border-radius became widely supported by browsers, a lot of designs feature circle themes. These are very distinctive and can be used across viewport widths giving them the same united feel, even if they\u2019re not used in the same way. This could also apply to border styles, consistent shadows and any number of decorative details and textures. These are the elements that make up the shape or form of a design system.\n\nColour\n\nColour is the most basic way to reinforce a brand and unite experiences across viewports. The same hex colour used system-wide is instantly recognisable, no matter what the viewport width.\n\nThe process\n\nWhile using a design system isn\u2019t necessarily attached to any particular process, it does lend itself to some process ideals.\n\nDetaching design considerations from viewport widths\n\nA design system allows you to focus separately on the components that make up the system, disconnecting the look and feel from the layout. This helps prevent us getting stuck in the rut of the Apple breakpoints (brilliantly coined by Simon Foster) of mobile, tablet and desktop. It also forces us to design for variation in viewport experiences side by side, not one after the other.\n\nDesign in the browser\n\nI can\u2019t start off designing in the browser \u2013 it just doesn\u2019t seem to bring out my creative side (and I\u2019m incredibly envious of you if you can; I just have to start on paper) \u2013 but static mock-ups aren\u2019t the only alternative. Style guides and style tiles are perfect for expressing the concepts of your design system. Pattern libraries could also work well.\n\nMock-ups and breakpoints\n\nAt some point, whether it\u2019s to test your system ideas, or because a client needs help visualising how your system might work, you may end up producing some static mock-ups. It\u2019s not the end of the world, but you must ensure that these consider all the viewports, not just those of the iDevices, or even the devices currently on the market. You need to decide the breakpoints where the states of your design change. The blocks within your content will always have optimum points for their display (based on their hierarchy, density, width, or type of interaction) and so your breakpoints should be based around these points.\n\nThese are probably the ideal points at which to produce static mockups; treat them as snapshots. They\u2019re not necessarily mock-ups, so much as a way of capturing how your design system would be interpreted when frozen at that particular viewport width.\n\nThe future\n\nCreating design systems will give us the flexibility we need for working with the unknown devices of the future. It may be a change in process, but it shouldn\u2019t be too much of a difference in thinking. The pioneers in responsive design have a hard job. Some of these problems may have already been solved in other technologies or industries, but it\u2019s up to the pioneers to find those connections and help us formulate solutions and standards that will make responsive design the best it can possibly be. We need to keep experimenting and communicating, particularly in the area of design, as good user experiences are the true sign of whether our products are a success.", "year": "2012", "author": "Laura Kalbag", "author_slug": "laurakalbag", "published": "2012-12-12T00:00:00+00:00", "url": "https://24ways.org/2012/design-systems/", "topic": "design"} {"rowid": 73, "title": "How to Make Your Site Look Half-Decent in Half an Hour", "contents": "Programmers like me are often intimidated by design \u2013 but a little effort can give a huge return on investment. Here are one coder\u2019s tips for making any site quickly look more professional. \n\nI am a programmer. I am not a designer. I have a degree in computer science, and I don\u2019t mind Comic Sans. (It looks cheerful. Move on.)\n\nBut although I am a programmer, I want to make my sites look attractive. This is partly out of vanity, and partly realism. Vanity because I want people to think my work is good, and realism because the research shows that people won\u2019t think a site is credible unless it also looks attractive.\n\nFor a very long time after I became a programmer, I was scared of design. Design seemed to consist of complicated rules that weren\u2019t written down anywhere, plus an unlearnable sense of taste, possessed only by a black-clad elite. \n\nBut a little while ago, I decided to do my best to hack what it took to make my own projects look vaguely attractive. And although this doesn\u2019t come close to the effect a professional designer could achieve, gathering these resources for improving a site\u2019s look and feel has been really helpful. \n\nIf I hadn\u2019t figured out some basic design shortcuts, it\u2019s unlikely that a weekend hack of mine would have ended up on page three of the Daily Mail. And too often now, I see excellent programming projects that don\u2019t reach the audience they deserve, simply because their design doesn\u2019t match their execution. \n\nSo, if you are a developer, my Christmas present to you is this: my own collection of hacks that, used rightly, can make your personal programming projects look professional, quickly. None are hard to learn, most are free, and they let you focus on writing code.\n\nOne thing to note about these tips, though. They are a personal, pragmatic compilation. They are suggestions, not a definitive guide. You will definitely get better results by working with a professional designer, and by studying design more deeply. \n\nIf you are a designer, I would love to hear your suggestions for the best tools that I\u2019ve missed, and I\u2019d love to know how we programmers can do things better.\n\nWith that, on to the tools\u2026\n\n1. Use Bootstrap\n\nIf you\u2019re not already using Bootstrap, start now. I really think that Bootstrap is one of the most significant technical achievements of the last few years: it democratizes the whole process of web design. \n\nEssentially, Bootstrap is a a grid system, with a bunch of common elements. So you can lay your site out how you want, drop in simple elements like forms and tables, and get a good-looking, consistent result, without spending hours fiddling with CSS. You just need HTML. \n\nAnother massive upside is that it makes it easy to make any site responsive, so you don\u2019t have to worry about writing media queries. Go, get Bootstrap and check out the examples. To keep your site lightweight, you can customize your download to include only the elements you want. \n\nIf you have more time, then Mark Otto\u2019s article on why and how Bootstrap was created at Twitter is well worth a read. \n\n2. Pimp Bootstrap\n\nUsing Bootstrap is already a significant advance on not using Bootstrap, and massively reduces the tedium of front-end development. But you also run the risk of creating Yet Another Bootstrap Site, or Hack Day Design, as it\u2019s known. \n\nIf you\u2019re really pressed for time, you could buy a theme from Wrap Bootstrap. These are usually created by professional designers, and will give a polish that we can\u2019t achieve ourselves. Your site won\u2019t be unique, but it will look good quickly. \n\nLuckily, it\u2019s pretty easy to make Bootstrap not look too much like Bootstrap \u2013 using fonts, CSS effects, background images, colour schemes and so on. Most of the rest of this article covers different ways to achieve this. \n\nWe are going to customize this Bootstrap example page.\n\nThis already has some custom CSS in the
. We\u2019ll pull it all out, and create a new CSS file, custom.css. Then we add a reference to it in the header. Now we\u2019re ready to start customizing things.\n\n\n\n3. Fonts\n\nWeb fonts are one of the quickest ways to make your site look distinctive, modern, and less Bootstrappy, so we\u2019ll start there. \n\nFirst, we can add some sweet fonts, from Google Web Fonts. The intimidating bit is choosing fonts that look nice together. Luckily, there are plenty of suggestions around the web: we\u2019re going to use one of DesignShack\u2019s suggested free Google Fonts pairings. Our fonts are Corben (for headings) and Nobile (for body copy). \n\nThen we add these files to our . \n\n\n \n\n\u2026and this to custom.css: \n\nh1, h2, h3, h4, h5, h6 {\n font-family: 'Corben', Georgia, Times, serif;\n}\np, div {\n font-family: 'Nobile', Helvetica, Arial, sans-serif;\n}\n\nNow our example looks like this. It\u2019s not going to win any design awards, but it\u2019s immediately better:\n\n\n\nI also recommend the web font services Fontdeck, or Typekit \u2013 these have a wider selection of fonts, and are worth the investment if you regularly need to make sites look good. For more font combinations, Just My Type suggests appealing pairings from Typekit. Finally, you can experiment with type pairing ideas at Type Connection. For the design background on pairing fonts, Typekit\u2019s post is worth a read. \n\n4. Textures\n\nAn instant way to make a site look classy is to use textures. You know the grey, stripy, indefinably elegant background on 24ways.org? That.\n\nIf only there was a superb resource listing attractive, free, ready-to-use textures\u2026 Oh wait, there\u2019s Atle Mo\u2019s Subtle Patterns. \n\nWe\u2019re going to use Cream Dust, for an effect that can only be described as subtle. We download the file to a new /img/ directory, then add this to the CSS file:\n\nbody { \n background: url(/img/cream_dust.png) repeat 0 0;\n}\n\nBang:\n\n\n\nFor some design background on patterns, I recommend reading through Smashing Magazine\u2019s guidelines on textures. (TL;DR version: use textures to enhance beauty, and clarify the information architecture of your site; but don\u2019t overdo it, or inadvertently obscure your text.)\n\nStill more to do, though. Onwards. \n\n5. Icons\n\nLast year\u2019s 24 ways taught us to use icon fonts for our site icons. \n\nThis is great for the time-pressed coder, because icon fonts don\u2019t just cut down on HTTP requests \u2013 they\u2019re a lot quicker to set up than image-based icons, too. \n\nBootstrap ships with an extensive, free for commercial use icon set in the shape of Font Awesome. Its icons are safe for screen readers, and can even be made to work in IE7 if needed (we\u2019re not going to bother here). \n\nTo start using these icons, just download Font Awesome, and add the /fonts/ directory to your site and the font-awesome.css file into your /css/ directory. Then add a reference to the CSS file in your header:\n\n\n\nFinally, we\u2019ll add a truck icon to the main action button, as follows. Why a truck? Why not?\n\n Sign up today\n\nWe\u2019ll also tweak our CSS file to stop the icon nudging up against the button text:\n\n.jumbotron .btn i { \n margin-right: 8px; \n}\n\nAnd this is how it looks:\n\n\n\nNot the most exciting change ever, but it livens up the page a bit. The licence is CC-BY-3.0, so we also include a mention of Font Awesome and its URL in the source code. \n\nIf you\u2019d like something a little more distinctive, Shifticons lets you pay a few cents for individual icons, with the bonus that you only have to serve the icons you actually use, which is more efficient. Its icons are also friendly to screen readers, but won\u2019t work in IE7. \n\n6. CSS3\n\nThe next thing you could do is add some CSS3 goodness. It can really help the key elements of the site stand out. \n\nIf you are pressed for time, just adding box-shadow and text-shadow to emphasize headings and standouts can be useful: \n\nh1 { \n text-shadow: 1px 1px 1px #ccc;\n}\n.div-that-you want-to-stand-out { \n box-shadow: 0 0 1em 1em #ccc;\n}\n\nWe have a little more time though, so we\u2019re going to do something more subtle. We\u2019ll add a radial gradient behind the main heading, using an online gradient editor. \n\nThe output is hefty, but you can see it in the CSS. Note that we also need to add the following to our HTML, for IE9 support: \n\n\n\nAnd the effect \u2013 I don\u2019t know what a designer would think, but I like the way it makes the heading pop.\n\n\n\nFor a crash course in useful modern CSS effects, I highly recommend CodeSchool\u2019s online course in Functional HTM5 and CSS3. It costs money ($25 a month to subscribe), but it\u2019s worth it for the time you\u2019ll save. As a bonus, you also get access to some excellent JavaScript, Ruby and GitHub courses. \n\n(Incidentally, if you find yourself fighting with basic float and display attributes in CSS \u2013 and there\u2019s no shame in it, CSS layout is not intuitive \u2013 I recommend the CSS Cross-Country course at CodeSchool.)\n\n7. Add a twist\n\nWe could leave it there, but we\u2019re going to add a background image, and give the site some personality. \n\nThis is the area of design that I think many programmers find most intimidating. How do we create the graphics and photographs that a designer would use? The answer is iStockPhoto and its competitors \u2013 online image libraries where you can find and pay for images. They won\u2019t be unique, but for our purposes, that\u2019s fine. \n\nWe\u2019re going to use a Christmassy image. For a twist, we\u2019re going to use Backstretch to make it responsive. \n\nWe must pay for the image, then download it to our /img/ directory. Then, we set it as our \u2019s background-image, by including a JavaScript file with just the following line: \n\n$.backstretch(\"/img/winter.jpg\");\n\nWe also reset the subtle pattern to become the background for our container image. It would look much better transparent, so we can use this technique in GIMP to make it see-through:\n\n.container-narrow {\n background: url(/img/cream_dust_transparent.png) repeat 0 0;\n}\n\nWe also fiddle with the padding on body and .container-narrow a bit, and this is the result: \n\n\n\n(Aside: If this were a real site, I\u2019d want to buy images in multiple sizes and ensure that Backstretch chose the most appropriately sized image for our screen, perhaps using responsive images.)\n\nHow to find the effects that make a site interesting? I keep a set of bookmarks for interesting JavaScript and CSS effects I might want to use someday, from realistic shadows to animating grids. The JavaScript Weekly newsletter is a great source of ideas. \n\n8. Colour schemes\n\nWe\u2019re just about getting there \u2013 though we\u2019re probably past half an hour now \u2013 but that button and that menu still both look awfully Bootstrappy. \n\nReal sites, with real designers, have a colour palette, carefully chosen to harmonize and match the brand profile. For our purposes, we\u2019re just going to borrow some colours from the image. We use Gimp\u2019s colour picker tool to identify the hex values of the blue of the snow. Then we can use Color Scheme Designer to find contrasting, but complementary, colours. \n\nFinally, we use those colours for our central button. There are lots of tools to help us do this, such as Bootstrap Buttons. The new HTML is quite long, so I won\u2019t paste it all here, but you can find it in the CSS file. \n\nWe also reset the colour of the pills in the navigation menu, which is a bit easier: \n\n.nav-pills > .active > a, .nav-pills > .active > a:hover {\n background-color: #FF9473;\n}\n\nI\u2019m not sure if the result is great to be honest, but at least we\u2019ve lost those Bootstrap-blue buttons:\n\n\n\nAnother way to do it, if you didn\u2019t have an image to match, would be to borrow an attractive colour scheme. Colourlovers is a community where people create and share ready-made colour palettes. \n\nThe key thing is to find a palette with an open licence, so you can legitimately use it. Unfortunately, you can\u2019t search for palettes by licence type, but many do have open licences. Here\u2019s a popular palette with a CC-BY-SA licence that allows reuse with attribution. \n\nAs above, you can use the hex values from the palette in your custom CSS, and bask in the newly colourful results.\n\n9. Read on\n\nWith the above techniques, you can make a site that is starting to look slightly more professional, pretty quickly. \n\nIf you have the time to invest, it\u2019s well worth learning some design principles, if only so that design seems less intimidating and more like fun. As part of my design learning, I read a few introductory design books aimed at coders. The best I found was David Kadavy\u2019s Design for Hackers: Reverse-Engineering Beauty, which explains the basic principles behind choosing colours, fonts, typefaces and layout.\n\nIn the introduction to his book, David writes: \n\n\n\tNo group stands to gain more from design literacy than hackers do\u2026 The one subject that is exceedingly frustrating for hackers to try to learn is design. Hackers know that in order to compete against corporate behemoths with just a few lines of code, they need to have good, clear design, but the resources with which to learn design are simply hard to find.\n\n\nWell said. If you have half a day to invest, rather than half an hour, I recommend getting hold of David\u2019s book.\n\nAnd the journey is over. Perhaps that took slightly more than half an hour, but with practice, using the above techniques can become second nature. What useful tools have I missed? Designers, how would you improve on the above? I would love to know, so please give me your views in the comments.", "year": "2012", "author": "Anna Powell-Smith", "author_slug": "annapowellsmith", "published": "2012-12-16T00:00:00+00:00", "url": "https://24ways.org/2012/how-to-make-your-site-look-half-decent/", "topic": "design"} {"rowid": 84, "title": "Responsive Responsive Design", "contents": "Now more than ever, we\u2019re designing work meant to be viewed along a gradient of different experiences. Responsive web design offers us a way forward, finally allowing us to \u201cdesign for the ebb and flow of things.\u201d\n\n\nWith those two sentences, Ethan closed the article that introduced the web to responsive design. Since then, responsive design has taken the web by storm. Seemingly every day, some company is touting their new responsive redesign. Large brands such as Microsoft, Time and Disney are getting in on the action, blowing away the once common criticism that responsive design was a technique only fit for small blogs.\n\nCertainly, this is a good thing. As Ethan and John Allsopp before him, were right to point out, the inherent flexibility of the web is a feature, not a bug. The web\u2019s unique ability to be consumed and interacted with on any number of devices, with any number of input methods is something to be embraced.\n\nBut there\u2019s one part of the web\u2019s inherent flexibility that seems to be increasingly overlooked: the ability for the web to be interacted with on any number of networks, with a gradient of bandwidth constraints and latency costs, on devices with varying degrees of hardware power.\n\nA few months back, Stephanie Rieger tweeted\n\n\n\t\u201cShoot me now\u2026responsive design has seemingly become confused with an opportunity to reduce performance rather than improve it.\u201d\n\n\nI would love to disagree, but unfortunately the evidence is damning. Consider the size and number of requests for four highly touted responsive sites that were launched this year:\n\n\n\t74 requests, 1,511kb\n\t114 requests, 1,200kb\n\t99 requests, 1,298kb\n\t105 requests, 5,942kb\n\n\nAnd those numbers were for the small screen versions of each site!\n\nThese sites were praised for their visual design and responsive nature, and rightfully so. They\u2019re very easy on the eyes and a lot of thought went into their appearance. But the numbers above tell an inconvenient truth: for all the time spent ensuring the visual design was airtight, seemingly very little (if any) attention was given to their performance.\n\nIt would be one thing if these were the exceptions, but unfortunately they\u2019re not. Guy Podjarny, who has done a lot of research around responsive performance, discovered that 86% of the responsive sites he tested were either the same size or larger on the small screen as they were on the desktop.\n\nThe reality is that high performance should be a requirement on any web project, not an afterthought. Poor performance has been tied to a decrease in revenue, traffic, conversions, and overall user satisfaction. Case study after case study shows that improving performance, even marginally, will impact the bottom line. The situation is no different on mobile where 71% of people say they expect sites to load as quickly or faster on their phone when compared to the desktop.\n\nThe bottom line: performance is a fundamental component of the user experience.\n\nSo, given it\u2019s extreme importance in the success of any web project, why is it that we\u2019re seeing so many bloated responsive sites?\n\nFirst, I adamantly disagree with the belief that poor performance is inherent to responsive design. That\u2019s not a rule \u2013 it\u2019s a cop-out. It\u2019s an example of blaming the technique when we should be blaming the implementation. This argument also falls flat because it ignores the fact that the trend of fat sites is increasing on the web in general. While some responsive sites are the worst offenders, it\u2019s hardly an issue resigned to one technique.\n\nTo fix the issue, we need to stop making excuses and start making improvements instead. Here, then, are some things we can do to start improving the state of responsive performance, and performance in general, right now.\n\nCreate a culture of performance\n\nIf you understand just how important performance is to the success of a project, the natural next step is to start creating a culture where high performance is a key consideration. \n\nOne of the things you can do is set a baseline. Determine the maximum size and number of requests you are going to allow, and don\u2019t let a page go live if either of those numbers is exceeded. The BBC does this with its responsive mobile site.\n\nA variation of that, which Steve Souders discussed in a recent podcast is to create a performance budget based on those numbers. Once you have that baseline set, if someone comes along and wants to add a something to the page, they have to make sure the page remains under budget. If it exceeds the budget, you have three options:\n\n\n\tOptimize an existing feature or asset on the page\n\tRemove an existing feature or asset from the page\n\tDon\u2019t add the new feature or asset\n\n\nThe idea here is that you make performance part of the process instead of something that may or may not get tacked on at the end.\n\nEmbrace the pain\n\nThis troubling trend of web bloat can be blamed in part on the lack of pain associated with poor performance. Most of us work on high-speed connections with low latency. When we fire up a 4Mb site, it doesn\u2019t feel so bad. \n\nWhen I tested the previously mentioned 5,942kb site on a 3G network, it took over 93 seconds to load. A minute and a half just staring at a white screen. Had anyone working on that project experienced that, you can bet the site wouldn\u2019t have launched in that state.\n\nDon\u2019t just crunch numbers. Fire up your site on a slower network and see what it feels like to wait. If you don\u2019t have access to a slow network, simulate one using a tool like Slowy, Throttle or the Network Conditioner found in Mac OS X 10.7.\n\nWatch for low-hanging fruit\n\nThere are a bunch of general performance improvements that apply to any site (responsive or not) but often aren\u2019t made. A great starting point is to refer to Yahoo!\u2018s list of rules.\n\nSome of this might sound complicated or intimidating, but it doesn\u2019t have to be. You can grab an .htaccess file from HTML 5 Boilerplate or use Sergey Chernyshev\u2019s drop-in .htaccess file. You can use tools like SpriteMe to simplify the creation of sprites, and ImageOptim to compress images.\n\nJust by implementing these simple optimizations you will achieve a noticeable improvement in terms of weight and page load time.\n\nBe careful with images\n\nThe most common offender for poor responsive performance is downloading unnecessarily large images, or worse yet, multiple sizes of the same image. \n\nFor background images, simply being careful with where and how you include the image can ensure you don\u2019t get caught in the trap of multiple background images being downloaded without being used. Don\u2019t count on display:none to help. While it may hide elements from displaying on screen, those images will still be requested and downloaded.\n\nContent images can be a little trickier. Whatever you do, don\u2019t serve a large image that works on a large screen display to small screens. It\u2019s wasteful, not only in terms of adding weight to the page, but also in wasting precious memory. Instead, use a tool like Adaptive Images or src.sencha.io to make sure only appropriately sized images are being downloaded. \n\nThe new