{"rowid": 141, "title": "Compose to a Vertical Rhythm", "contents": "\u201cSpace in typography is like time in music. It is infinitely divisible, but a few proportional intervals can be much more useful than a limitless choice of arbitrary quantities.\u201d So says the typographer Robert Bringhurst, and just as regular use of time provides rhythm in music, so regular use of space provides rhythm in typography, and without rhythm the listener, or the reader, becomes disorientated and lost.\n\nOn the Web, vertical rhythm \u2013 the spacing and arrangement of text as the reader descends the page \u2013 is contributed to by three factors: font size, line height and margin or padding. All of these factors must calculated with care in order that the rhythm is maintained. \n\nThe basic unit of vertical space is line height. Establishing a suitable line height that can be applied to all text on the page, be it heading, body copy or sidenote, is the key to a solid dependable vertical rhythm, which will engage and guide the reader down the page. To see this in action, I\u2019ve created an example with headings, footnotes and sidenotes. \n\nEstablishing a suitable line height\n\nThe easiest place to begin determining a basic line height unit is with the font size of the body copy. For the example I\u2019ve chosen 12px. To ensure readability the body text will almost certainly need some leading, that is to say spacing between the lines. A line-height of 1.5em would give 6px spacing between the lines of body copy. This will create a total line height of 18px, which becomes our basic unit. Here\u2019s the CSS to get us to this point:\n\nbody {\n\tfont-size: 75%; \n}\nhtml>body {\n\tfont-size: 12px; \n}\np {\n\tline-height 1.5em; \n}\n\nThere are many ways to size text in CSS and the above approach provides and accessible method of achieving the pixel-precision solid typography requires. By way of explanation, the first font-size reduces the body text from the 16px default (common to most browsers and OS set-ups) down to the 12px we require. This rule is primarily there for Internet Explorer 6 and below on Windows: the percentage value means that the text will scale predictably should a user bump the text size up or down. The second font-size sets the text size specifically and is ignored by IE6, but used by Firefox, Safari, IE7, Opera and other modern browsers which allow users to resize text sized in pixels.\n\nSpacing between paragraphs\n\nWith our rhythmic unit set at 18px we need to ensure that it is maintained throughout the body copy. A common place to lose the rhythm is the gaps set between margins. The default treatment by web browsers of paragraphs is to insert a top- and bottom-margin of 1em. In our case this would give a spacing between the paragraphs of 12px and hence throw the text out of rhythm. If the rhythm of the page is to be maintained, the spacing of paragraphs should be related to the basic line height unit. This is achieved simply by setting top- and bottom-margins equal to the line height.\n\nIn order that typographic integrity is maintained when text is resized by the user we must use ems for all our vertical measurements, including line-height, padding and margins.\n\np {\n\tfont-size:1em;\n\tmargin-top: 1.5em;\n\tmargin-bottom: 1.5em; \n}\n\nBrowsers set margins on all block-level elements (such as headings, lists and blockquotes) so a way of ensuring that typographic attention is paid to all such elements is to reset the margins at the beginning of your style sheet. You could use a rule such as:\n\nbody,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,fieldset,p,blockquote,th,td { \n\tmargin:0; \n\tpadding:0; \n}\n\nAlternatively you could look into using the Yahoo! UI Reset style sheet which removes most default styling, so providing a solid foundation upon which you can explicitly declare your design intentions.\n\nVariations in text size\n\nWhen there is a change in text size, perhaps with a heading or sidenotes, the differing text should also take up a multiple of the basic leading. This means that, in our example, every diversion from the basic text size should take up multiples of 18px. This can be accomplished by adjusting the line-height and margin accordingly, as described following.\n\nHeadings\n\nSubheadings in the example page are set to 14px. In order that the height of each line is 18px, the line-height should be set to 18\u00a0\u00f7\u00a014 =\u00a01.286. Similarly the margins above and below the heading must be adjusted to fit. The temptation is to set heading margins to a simple 1em, but in order to maintain the rhythm, the top and bottom margins should be set at 1.286em so that the spacing is equal to the full 18px unit.\n\nh2 {\n\tfont-size:1.1667em;\n\tline-height: 1.286em;\n\tmargin-top: 1.286em;\n\tmargin-bottom: 1.286em; \n}\n\nOne can also set asymmetrical margins for headings, provided the margins combine to be multiples of the basic line height. In our example, a top margin of 1\u00bd lines is combined with a bottom margin of half a line as follows:\n\nh2 {\n\tfont-size:1.1667em;\n\tline-height: 1.286em;\n\tmargin-top: 1.929em;\n\tmargin-bottom: 0.643em; \n}\n\nAlso in our example, the main heading is given a text size of 18px, therefore the line-height has been set to 1em, as has the margin:\n\nh1 {\n\tfont-size:1.5em;\n\tline-height: 1em;\n\tmargin-top: 0;\n\tmargin-bottom: 1em; \n}\n\nSidenotes\n\nSidenotes (and other supplementary material) are often set at a smaller size to the basic text. To keep the rhythm, this smaller text should still line up with body copy, so a calculation similar to that for headings is required. In our example, the sidenotes are set at 10px and so their line-height must be increased to 18\u00a0\u00f7\u00a010 =\u00a01.8.\n\n.sidenote {\n\tfont-size:0.8333em;\n\tline-height:1.8em; \n}\n\nBorders\n\nOne additional point where vertical rhythm is often lost is with the introduction of horizontal borders. These effectively act as shims pushing the subsequent text downwards, so a two pixel horizontal border will throw out the vertical rhythm by two pixels. A way around this is to specify horizontal lines using background images or, as in our example, specify the width of the border in ems and adjust the padding to take up the slack. \n\nThe design of the footnote in our example requires a 1px horizontal border. The footnote contains 12px text, so 1px in ems is 1\u00a0\u00f7\u00a012 =\u00a00.0833. I have added a margin of 1\u00bd lines above the border (1.5\u00a0\u00d7\u00a018\u00a0\u00f7\u00a012 =\u00a02.5ems), so to maintain the rhythm the border + padding must equal a \u00bd (9px). We know the border is set to 1px, so the padding must be set to 8px. To specify this in ems we use the familiar calculation: 8\u00a0\u00f7\u00a012 =\u00a00.667.\n\nHit me with your rhythm stick\n\nComposing to a vertical rhythm helps engage and guide the reader down the page, but it takes typographic discipline to do so. It may seem like a lot of fiddly maths is involved (a few divisions and multiplications never hurt anyone) but good type setting is all about numbers, and it is this attention to detail which is the key to success.", "year": "2006", "author": "Richard Rutter", "author_slug": "richardrutter", "published": "2006-12-12T00:00:00+00:00", "url": "https://24ways.org/2006/compose-to-a-vertical-rhythm/", "topic": "design"}
{"rowid": 108, "title": "A Festive Type Folly", "contents": "\u2018Tis the season to be jolly, so the carol singers tell us. At 24 ways, we\u2019re keeping alive another British tradition that includes the odd faux-Greco-Roman building dotted around the British countryside, Tower Bridge built in 1894, and your Dad\u2019s Christmas jumper with the dancing reindeer motif. \u2018Tis the season of the folly!\n\n \n 24 Ways to impress your friends\n \n\nThe example is not an image, just text. You may wish to see a screenshot in Safari to compare with your own operating system and browser rendering.\n\nLike all follies this is an embellishment\u200a\u2014\u200aa bit of web typography fun. It\u2019s similar to the masthead text at my place, but it\u2019s also a hyperlink. Unlike the architectural follies of the past, no child labour was used to fund or build it, just some HTML flavoured with CSS, and a heavy dose of Times New Roman. Why Times New Roman, you ask? Well, after a few wasted hours experimenting with heaps of typefaces, seeking an elusive consistency of positioning and rendering across platforms, it proved to be the most consistent. Who\u2019d\u2018a thought? To make things more interesting, I wanted to use a traditional scale and make the whole thing elastic by using relative lengths that would react to a person\u2019s font size. So, to the meat of this festive frippery:\n\nThere are three things we rely on to create this indulgence:\n\n\n\tDescendant selectors\n\tAbsolute positioning\n\tInheritance\n\n\nHTML & Descendant Selectors\n\nThe markup for the folly might seem complex at first glance. To semantics pedants and purists it may seem outrageous. If that\u2019s you, read on at your peril! Here it is with lots of whitespace:\n\n
\n\nWhy so much markup? Well, we want to individually style many of the glyphs. By nesting the elements, we can pick out the bits we need as descendant selectors.\n\nTo retain a smidgen of semantics, the text is wrapped in
\n\n\t\n\t\t 1485 Laperri\u00e8re Avenue \n\t\t Ottawa ON K1Z 7S8 \n\t\tCanada\n\t\n\n\t\n\t\tPhone/Fax: Work: 61 2 9365 5007\n\t\tEmail: info@webdirections.org\n\t\n\n\nWe\u2019ll be using a variation on the now well established \u201csliding doors\u201d technique (if you create a CSS technique, remember it\u2019s very important to give it a memorable name or acronym, and bonus points if you get your name in there!) by Douglas Bowman, enhanced by Scott Schiller (see http://www.schillmania.com/projects/dialog/,) which will give us a design which looks like this\n\n\n\nThe technique, in a nutshell, uses background images on four elements, two at the top, and two at the bottom, to add each rounded corner.\n\nWe are going to make this design \u201cfluid\u201d in the sense that it grows and shrinks in proportion with the size of the font that the text of the element is displayed with. This is sometimes referred to as an \u201cem driven design\u201d (we\u2019ll see why in a moment).\n\nTo see how this works in practice, here\u2019s the same design with the text \u201czoomed\u201d up in size\n\n\n\nand the same design again, when we zoom the text size down\n\n\n\nBy the way, the hCard image comes from Chris Messina, and you can download it and other microformat icons from the microformats wiki.\n\nNow, with CSS3, this whole task would be considerably easier, because we can add multiple background images to an element, and border images for each edge of an element. Safari, version 1.3 up, actually supports multiple background images, but sadly, it\u2019s not supported in Firefox 1.5, or even Firefox 2.0 (let\u2019s not mention IE7 eh?). So it\u2019s probably too little supported to use now. So instead we\u2019ll use a technique that only involves CSS2, and works in pretty much any browser.\n\nVery often, developers add div or span elements as containers for these background images, and in fact, if you visit Scott Shiller\u2019s site, that\u2019s what he has done there. But if at all possible we shouldn\u2019t be adding any HTML simply for presentational purposes, even if the presentation is done via CSS. What we can do is to use the HTML we have already, as much as is possible, to add the style we want. This can take some creative thinking, but once you get the hang of this approach it becomes a more natural way of using HTML compared with simply adding divs and spans at will as hooks for style. Of course, this technique isn\u2019t always simple, and in fact sometimes simply not possible, requiring us to add just a little HTML to provide the \u201chooks\u201d for CSS.\n\nLet\u2019s go to work\n\nThe first step is to add a background image to the whole vCard element.\n\n\n\nWe make this wide enough (for example 1000 or more pixels) and tall enough that no matter how large the content of the vCard grows, it will never overflow this area. We can\u2019t simply repeat the image, because the top left corner will show when the image repeats.\n\nWe add this as the background image of the vCard element using CSS.\n\nWhile we are at it, let\u2019s give the text a sans-serif font, some color so that it will be visible, and stop the image repeating.\n\n.vcard {\n\tbackground-image: url(images/vcardfill.png);\n\tbackground-repeat: no-repeat;\n\tcolor: #666;\n\tfont-family: \"Lucida Grande\", Verdana, Helvetica, Arial, sans-serif;\n}\n\nWhich in a browser, will look something like this.\n\n\n\nNext step we need to add the top right hand corner of the hCard. In keeping with our aim of not adding HTML simply for styling purposes, we want to use the existing structure of the page where possible. Here, we\u2019ll use the paragraph of class fn and org, which is the first child element of the vcard element.\n\n
Web Directions Conference Pty Ltd
\n\nHere\u2019s our CSS for this element\n\n.fn {\n\tbackground-image: url(images/topright.png);\n\tbackground-repeat: no-repeat;\n\tbackground-position: top right;\n\tpadding-top: 2em;\n\tfont-weight: bold;\n\tfont-size: 1.1em;\n}\n\nAgain, we don\u2019t want it to repeat, but this time, we\u2019ve specified a background position for the image. This will make the background image start from the top, but its right edge will be located at the right edge of the element. I also made the font size a little bigger, and the weight bold, to differentiate it from the rest of the text in the hCard.\n\nHere\u2019s the image we are adding as the background to this element.\n\n\n\nSo, putting these two CSS statements together we get\n\n\n\nWe specified a padding-top of 2em to give some space between the content of the fn element and the edge of the fn element. Otherwise the top of the hCard image would be hard against the border. To see this in action, just remove the padding-top: 2em; declaration and preview in a browser.\n\nSo, with just two statements, we are well under way. We\u2019ve not even had to add any HTML so far. Let\u2019s turn to the bottom of the element, and add the bottom border (well, the background image which will serve as that border).\n\nNow, which element are we going to use to add this background image to?\n\nOK, here I have to admit to a little, teensie bit of cheating. If you look at the HTML of the hCard, I\u2019ve grouped the email and telephone properties into a div, with a class of telecommunications. This grouping is not strictly requred for our hCard.\n\n
\n\nNow, I chose that class name because that is what the vCard specification calls this group of properties. And typically, I do tend to group together related elements using divs when I mark up content. I find it makes the page structure more logical and readable. But strictly speaking, this isn\u2019t necessary, so you may consider it cheating. But my lesson in this would be, if you are going to add markup, try to make it as meaningful as possible.\n\nAs you have probably guessed by now, we are going to add one part of the bottom border image to this element. We\u2019re going to add this image as the background-image.\n\n\n\nAgain, it will be a very wide image, like the top left one, so that no matter how wide the element might get, the background image will still be wide enough. Now, we\u2019ll need to make this image sit in the bottom left of the element we attach it to, so we use a backgound position of left bottom (we put the horizontal position before the vertical). Here\u2019s our CSS statement for this\n\n.telecommunications {\n\tbackground-image: url(images/bottom-left.png);\n\tbackground-repeat: no-repeat;\n\tbackground-position: left bottom;\n\tmargin-bottom: 2em;\n}\n\nAnd that will look like this\n\n\n\nNot quite there, but well on the way. Time for the final piece in the puzzle.\n\nOK, I admit, I might have cheated just a little bit more in this step. But like the previous step, all valid, and (hopefully) quite justifiable markup. If we look at the HTML again, you\u2019ll find that our email address is marked up like this\n\n
\n\nTypically, in hCard, the value part of this property isn\u2019t required, and we could get away with\n\ninfo@webdirections.org\n\nThe form I\u2019ve used, with the span of class value is however, perfectly valid hCard markup (hard allows for multiple email addresses of different types, which is where this typically comes in handy). Why have I gone to all this trouble? Well, when it came to styling the hCard, I realized I needed a block element to attach the background image for the bottom right hand corner to. Typically the last block element in the containing element is the ideal choice (and sometimes it\u2019s possible to take an inline element, for example the link here, and use CSS to make it a block element, and attach it to that, but that really doesn\u2019t work with this design).\n\nSo, if we are going to use the paragraph which contains the email link, we need a way to select it exclusively, which means that with CSS2 at least, we need a class or id as a hook for our CSS selector (in CSS3 we could use the last-child selector, which selects the last child element of a specified element, but again, as last child is not widely supported, we won\u2019t rely on it here.)\n\nSo, the least worst thing we could do is take an existing element, and add some reasonably meaningful markup to it. That\u2019s why we gave the paragraph a class of email, and the email address a class of value. Which reminds me a little of a moment in Hamlet\n\n\n\tThe lady doth protest too much, methinks\n\n\nOK, let\u2019s get back to the CSS.\n\nWe add the bottom right corner image, positioning it in the bottom right of the element, and making sure it doesn\u2019t repeat. We also add some padding to the bottom, to balance out the padding we added to the top of the hCard.\n\np.email {\n\tbackground-image: url(images/bottom-right.png);\n\tbackground-position: right bottom;\n\tbackground-repeat: no-repeat;\n\tpadding-bottom: 2em;\n}\n\nWhich all goes to make our hCard look like this\n\n\n\nIt just remains for us to clean up a little.\n\nLet\u2019s start from the top. We\u2019ll float the download image to the right like this\n\n.vcard img {\n\tfloat: right;\n\tpadding-right: 1em;\n\tmargin-top: -1em\n}\n\nSee how we didn\u2019t have to add a class to style the image, we used the fact that the image is a descendent of the vcard element, and a descendent selector. In my experience, the very widely supported, powerful descendent selector is one of the most underused aspects of CSS. So if you don\u2019t use it frequently, look into it in more detail.\n\nWe added some space to the right of the image, and pulled it up a bit closer to the top of the hCard, like this\n\n\n\nWe also want to add some whitespace between the edge of the hCard and the text. We would typically add padding to the left of the containing element, (in this case the vcard element) but this would break our bottom left hand corner, like this\n\n\n\nThat\u2019s because the div element we added this bottom left background image to would be moved in by the padding on its containing element.\n\nSo instead, we add left margin to all the paragraphs in the hCard\n\n.vcard p {\n\tmargin-left: 1em;\n}\n\n(there is the descendent selector again \u2013 it is the swiss army knife of CSS)\n\nNow, we\u2019ve not yet made the width of the hCard a function of the size of the text inside it (or \u201cem driven\u201d as we described it earlier). We do this by giving the hCard a width that is specified in em units. Here we\u2019ll set a width of say 28em, which makes the hCard always roughly as wide as 28 characters (strictly speaking 28 times the width of the letter capital M). \n\nSo the statement for our containing vcard element becomes\n\n.vcard {\n\tbackground-image: url(images/vcardfill.png);\n\tbackground-repeat: no-repeat;\n\tcolor: #666;\n\tfont-family: \"Lucida Grande\", Verdana, Helvetica, Arial, sans-serif;\n\twidth: 28em;\n}\n\nand now our element will look like this\n\n\n\nWe\u2019ve used almost entirely the existing HTML from our original hCard (adding just a little, and trying as much as possible to keep that additional markup meaningful), and just 6 CSS statements.\n\nHoliday Bonus \u2013 a downloadable vCard\n\nDid you notice this part of the HTML\n\n\n \n\nWhat\u2019s with the odd looking url\n\n. 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": 151, "title": "Get In Shape", "contents": "Pop quiz: what\u2019s wrong with the following navigation?\n\n\n\nMaybe nothing. But then again, maybe there\u2019s something bugging you about the way it comes together, something you can\u2019t quite put your finger on. It seems well-designed, but it also seems a little\u2026 off.\n\nThe design decisions that led to this eventual form were no doubt well-considered:\n\n\n\tClient: The top level needs to have a \u201ccurrent page\u201d status indicator of some sort.\n\tDesigner: How about a white tab?\n\tClient: Great! The second level needs to show up underneath the first level though\u2026\n\tDesigner: Okay, but that white tab I just added makes it hard to visually connect the bottom nav to the top.\n\tClient: Too late, we\u2019ve seen the white tab and we love it. Try and make it work.\n\tDesigner: Right. So I placed the second level in its own box.\n\tClient: Hmm. They seem too separated. I can\u2019t tell that the yellow nav is the second level of the first.\n\tDesigner: How about an indicator arrow?\n\tClient: Brilliant!\n\n\nThe problem is that the end result feels awkward and forced. During the design process, little decisions were made that ultimately affect the overall shape of the navigation. What started out as a neatly contained rounded rectangle ended up as an ambiguous double shape that looks funny, though it\u2019s often hard to pinpoint precisely why.\n\nThe Shape of Things\n\nWell the why in this case is because seemingly unrelated elements in a design still end up visually interacting. Adding a new item to a page impacts everything surrounding it. In this navigation example, we\u2019re looking at two individual objects that are close enough to each other that they form a relationship; if we reduce them to strictly their outlines, it\u2019s a little easier to see that this particular combination registers oddly.\n\n\n\nThe two shapes float with nothing really grounding them. If they were connected, perhaps it would be a different story. The white tab divides the top shape in half, leaving a gap in the middle of it. There\u2019s very little balance in this pairing because the overall shape of the navigation wasn\u2019t considered during the design process.\n\nHere\u2019s another example: Gmail. Great email client, but did you ever closely look at what\u2019s going on in that left hand navigation? The continuous blue bar around the message area spills out into the navigation. If we remove all text, we\u2019re left with this odd configuration:\n\n\n\nThough the reasoning for anchoring the navigation highlight against the message area might be sound, the result is an irregular shape that doesn\u2019t correspond with anything in reality. You may never consciously notice it, but once you do it\u2019s hard to miss. One other example courtesy of last.fm:\n\n\n\nThe two header areas are the same shade of pink so they appear to be closely connected. When reduced to their outlines it\u2019s easy to see that this combination is off-balance: the edges don\u2019t align, the sharp corners of the top shape aren\u2019t consistent with the rounded corners of the bottom, and the part jutting out on the right of the bottom one seems fairly random. The result is a duo of oddly mis-matched shapes.\n\nDesign Strategies\n\nOur minds tend to pick out familiar patterns. A clever designer can exploit this by creating references in his or her work to shapes and combinations with which viewers are already familiar. There are a few simple ideas that can be employed to help you achieve this: consistency, balance, and completion.\n\nConsistency\n\nA fairly simple way to unify the various disparate shapes on a page is by designing them with a certain amount of internal consistency. You don\u2019t need to apply an identical size, colour, border, or corner treatment to every single shape; devolving a design into boring repetition isn\u2019t what we\u2019re after here. But it certainly doesn\u2019t hurt to apply a set of common rules to most shapes within your work.\n\n\n\nConsider purevolume and its multiple rounded-corner panels. From the bottom of the site\u2019s main navigation to the grey \u201cExtras\u201d panels halfway down the page (shown above), multiple shapes use a common border radius for unity. Different colours, different sizes, different content, but the consistent outlines create a strong sense of similarity. Not that every shape on the site follows this rule; they break the pattern right at the top with a darker sharp-cornered header, and again with the thumbnails below. But the design remains unified, nonetheless.\n\nBalance\n\nArguably the biggest problem with the last.fm example earlier is one of balance. The area poking out of the bottom shape created a fairly obvious imbalance for no apparent reason. The right hand side is visually emphasized due to the greater area of pink coverage, but with the white gap left beside it, the emphasis seems unwarranted. It\u2019s possible to create tension in your design by mismatching shapes and throwing off the balance, but when that happens unintentionally it can look like a mistake.\n\n\n\nAbove are a few examples of design elements in balanced and unbalanced configurations. The examples in the top row are undeniably more pleasing to the eye than those in the bottom row. If these were fleshed out into full designs, those derived from the templates in the top row would naturally result in stronger work.\n\nTake a look at the header on 9Rules for a study in well-considered balance. On the left you\u2019ll see a couple of paragraphs of text, on the right you have floating navigational items, and both flank the site\u2019s logo. This unusual layout combines multiple design elements that look nothing alike, and places them together in a way that anchors each so that no one weighs down the header.\n\nCompletion\n\nAnd finally we come to the idea of completion. Shapes don\u2019t necessarily need hard outlines to be read visually as shapes, which can be exploited for various purposes. Notice how Zend\u2019s mid-page \u201cBusiness Topics\u201d and \u201cNews\u201d items (below) fade out to the right and bottom, but the placement of two of these side-by-side creates an impression of two panels rather than three disparate floating columns. By allowing the viewer\u2019s eye to complete the shapes, they\u2019ve lightened up the design of the page and removed inessential lines. In a busy design this technique could prove quite handy.\n\n\n\nAlong the same lines, the individual shapes within your design may also be combined visually to form outlines of larger shapes. The differently-coloured header and main content/sidebar shapes on Veerle\u2019s blog come together to form a single central panel, further emphasized by the slight drop shadow to the right.\n\nImplementation\n\nStudying how shape can be used effectively in design is simply a starting point. As with all things design-related, there are no hard and fast rules here; ultimately you may choose to bring these principles into your work more often, or break them for effect. But understanding how shapes interact within a page, and how that effect is ultimately perceived by viewers, is a key design principle you can use to impress your friends.", "year": "2007", "author": "Dave Shea", "author_slug": "daveshea", "published": "2007-12-16T00:00:00+00:00", "url": "https://24ways.org/2007/get-in-shape/", "topic": "design"}
{"rowid": 210, "title": "Stop Leaving Animation to the Last Minute", "contents": "Our design process relies heavily on static mockups as deliverables and this makes it harder than it needs to be to incorporate UI animation in our designs. Talking through animation ideas and dancing out the details of those ideas can be fun; but it\u2019s not always enough to really evaluate or invest in animated design solutions. \nBy including deliverables that encourage discussing animation throughout your design process, you can set yourself (and your team) up for creating meaningful UI animations that feel just as much a part of the design as your colour palette and typeface. You can get out of that \u201crunning out of time to add in the animation\u201d trap by deliberately including animation in the early phases of your design process. This will give you both the space to treat animation as a design tool, and the room to iterate on UI animation ideas to come up with higher quality solutions. Two deliverables that can be especially useful for this are motion comps and animated interactive prototypes. \nMotion comps - an animation deliverable\nMotion comps (also called animatics or motion mock-ups) are usually video representation of UI animations. They are used to explore the details of how a particular animation might play out. And they\u2019re most often made with timeline-based tools like Adobe After Effects, Adobe Animate, or Tumult Hype. \nThe most useful things about motion comps is how they allow designers and developers to share the work of creating animations. (Instead of pushing all the responsibility of animation on one group or the other.) For example, imagine you\u2019re working on a design that has a content panel that can either be open or closed. You might create a mockup like the one below including the two different views: the closed state and the open state. If you\u2019re working with only static deliverables, these two artboards might be exactly what you handoff to developers along with the instruction to animate between the two. \n\nOn the surface that seems pretty straight forward, but even with this relatively simple transition there\u2019s a lot that those two artboards don\u2019t address. There are seven things that change between the closed state and the open state. That\u2019s seven things the developer building this out has to figure out how to move in and out of view, when, and in what order. And all of that is even before starting to write the code to make it work. \nBy providing only static comps, all the logic of the animation falls on the developer. This might go ok if she has the bandwidth and animation knowledge, but that\u2019s making an awful lot of assumptions.\nInstead, if you included a motion mock up like this with your static mock ups, you could share the work of figuring out the logic of the animation between design and development. Designers could work out the logic of the animation in the motion comp, exploring which items move at which times and in which order to create the opening and closing transitions. \n\nThe motion comp can also be used to iterate on different possible animation approaches before any production code has to be committed too. Sharing the work and giving yourself time to explore animation ideas before you\u2019re backed up again the deadline will lead to happier teammates and better design solutions. \nWhen to use motion comps\nI\u2019m not a fan of making more deliverables just for the sake of having more things to make, so I find it helps to narrow down what question I\u2019m trying answer before choosing which sort of deliverable to make to investigate. \nMotion comps can be most helpful for answering questions like: \n\nExactly how should this animation look? \nWhich items should move? Where? And when? \nDo the animation qualities reflect our brand or our voice and tone?\nOne of the added bonuses of creating motion comps to answer these questions is that you\u2019ll have a concrete thing to bring to design critiques or reviews to get others\u2019 input on them as well.\n\nUsing motion comps as handoff\nMotion comps are often used to handoff animation ideas from design to development. They can be super useful for this, but they\u2019re even more useful when you include the details of the motion specs with them. (It\u2019s difficult, if not impossible, to glean these details from playing back a video.)\nMore specifically, you\u2019ll want to include:\n\nDurations and the properties animated for each animation\nEasing curve values or spring values used\nDelay values and repeat counts\n\nIn many cases you\u2019ll have to collect these details up manually. But this isn\u2019t necessarily something that that will take a lot of time. If you take note of them as you\u2019re creating the motion comp, chances are most of these details will already be top of mind. (Also, if you use After Effects for your motion comps, the Inspector Spacetime plugin might be helpful for this task.)\nAnimated prototypes - an interactive deliverable\nMaking prototypes isn\u2019t a new idea for web work by any stretch, but creating prototypes that include animation \u2013 or even creating prototypes specifically to investigate potential animation solutions \u2013 can go a long way towards having higher quality animations in your final product.\nInteractive prototypes are web or app-based, or displayed in a particular tool\u2019s preview window to create a useable version of interactions that might end up in the end product. They\u2019re often made with prototyping apps like Principle, Framer, or coded up in HTML, CSS and JS directly like the example below.\nSee the Pen Prototype example by Val Head (@valhead) on CodePen.\n\nThe biggest different between motion comps and animated prototypes is the interactivity. Prototypes can reposed to taps, drags or gestures, while motion comps can only play back in a linear fashion. Generally speaking, this makes prototypes a bit more of an effort to create, but they can also help you solve different problems. The interactive nature of prototypes can also make them useful for user testing to further evaluate potential solutions. \nWhen to use prototypes\nWhen it comes to testing out animation ideas, animated prototypes can be especially helpful in answering questions like these: \n\nHow will this interaction feel to use? (Interactive animations often have different timing needs than animations that are passively viewed.)\nWhat will the animation be like with real data or real content? \nDoes this animation fit the context of the task at hand? \n\nPrototypes can be used to investigate the same questions that motion comps do if you\u2019re comfortable working in code or your prototyping tool of choice has capabilities to address high fidelity animation details. There are so many different prototyping tools out there at the moment, you\u2019re sure to be able to find one that fits your needs. \nAs a quick side note: If you\u2019re worried that your coding skills might not be up to par to prototype in code, know that prototype code doesn\u2019t have to be production quality code. Animated prototypes\u2019 main concern is working out the animation details. Once you\u2019ve arrived at a combination of animations that works, the animation specifics can be extracted or the prototype can be refactored for production.\nMotion comp or prototype?\nBoth motion comps and prototypes can be extremely useful in the design process and you can use whichever one (or ones) that best fits your team\u2019s style. The key thing that both offer is a way to make animation ideas visible and sharable. When you and your teammate are both looking at the same deliverable, you can be confident you\u2019re talking about the same thing and discuss its pros and cons more easily than just describing the idea verbally. \nMotion comps tend to be more useful earlier in the design process when you want to focus on the motion without worrying about the underlying structure or code yet. Motion comps also be great when you want to try something completely new. Some folks prefer motion comps because the tools for making them feel more familiar to them which means they can work faster. \nPrototypes are most useful for animations that rely heavily on interaction. (Getting the timing right for interactions can be tough without the interaction part sometimes.) Prototypes can also be helpful to investigate and optimize performance if that\u2019s a specific concern.\nGive them a try\nWhichever deliverables you choose to highlight your animation decisions, including them in your design reviews, critiques, or other design discussions will help you make better UI animation choices. More discussion around UI animation ideas during the design phase means greater buy-in, more room for iteration, and higher quality UI animations in your designs. Why not give them a try for your next project?", "year": "2017", "author": "Val Head", "author_slug": "valhead", "published": "2017-12-08T00:00:00+00:00", "url": "https://24ways.org/2017/stop-leaving-animation-to-the-last-minute/", "topic": "design"}
{"rowid": 174, "title": "Type-Inspired Interfaces", "contents": "One of the things that terrifies me most about a new project is the starting point. How is the content laid out? What colors do I pick? Once things like that are decided, it becomes significantly easier to continue design, but it\u2019s the blank page where I spend the most time.\n\nTo that end, I often start by choosing type. I don\u2019t need to worry about colors or layout or anything else\u2026 just the right typefaces that support the art direction. (This article won\u2019t focus on how to choose a typeface, but there are some really great resources if you interested in that sort of thing.)\n\nAnd just like that, all your work is done. \u201cHold it just a second,\u201d you might say. \u201cAll I\u2019ve done is pick type. I still have to do the rest!\u201d\n\nTo which I would reply, \u201cSilly rabbit. You already have!\u201d You see, picking the right typeface gets you farther than you might think. Here are a few tips on taking cues from type to design interfaces and interface elements.\n\nPerfecting Web 2.0\n\nIf you\u2019re going for that beloved rounded corner look, you might class it up a bit by choosing the wonderful Omnes Pro by Joshua Darden. As the typeface already has a rounded aesthetic, making buttons that fit the style should be pretty easy.\n\nI\u2019ve found that using multiples helps to keep your interfaces looking balanced and proportional. Noticing that the top left edge of the letter \u201cP\u201d has about an 12px corner radius, let\u2019s choose a 24px radius for our button (a multiple of 2), so that we get proper rounded corners. By taking mathematical measurements from the typeface, our button looks more thought out than just \u201cplace arbitrary text on arbitrarily-sized button.\u201d Pretty easy, eh?\n\n\n\nWhat\u2019s in a name(plate)?\n\nRounded buttons are pretty popular buttons nowadays, so let\u2019s try something a bit more stylized.\n\nHave a gander at Brothers, a sturdy face from Emigre. The chiseled edges give us a perfect cue for a stylized button. Using the same slope, you can make plated-looking buttons that fit a different kind of style.\n\n\n\nHeadlining\n\nYou might even take some cues from the style of the typeface itself. Didone serifs are known for their lack of brackets\u30fcthat is, a gradual transition from the stem to the serif. Instead, they typically connect at a right angle. Another common characteristic is the high contrast in the strokes: very thick stems, very thin serifs.\n\nSo, when using a high contrast typeface, you can use it to your advantage to enhance hierarchy. Following our \u201cmultiples\u201d guideline, a 12px measurement from the stems helps us create a top rule with a height of 24px (a multiple of 2). We can take the exact 1px measurement from the serif\u2014a multiple of 1\u2014to create the bottom rule. Voil\u00e0! I use this technique a lot.\n\n\n\nSwashbucklers\n\nAnd don\u2019t forget the importance of visual \u201cspeed bumps\u201d to break up long passages of text. A beautiful face like Alejandro Paul\u2019s Ministry Script has over a thousand characters that can be manipulated or even combined to create elegant interface elements. Altering the partial differential character (\u2202) creates a delightful ornament that can help to guide the eye through content.\n\n\n\nStagger & Swagger\n\nWhat about layout? How can we use typography to inform how our content is displayed?\n\nLet\u2019s take a typeface like Assembler. We might use this for a design that needs to feel uneasy or uncomfortable. In design terms, that might translate into using irregular shapes and asymmetry. Using the proportional distances and degrees from the perpendiculars, we could easily create a multi-column layout that jives with the general tone. And for all you skeptics that don\u2019t think a layout like this is doable on the web, stranger things have happened.\n\n Background texture generously offered by Bittbox.\n\nOverall Design Direction\n\nFinally, your typography could impact the entire look of the site, from the navigation to the interaction and everything in between. Check out how the (now-defunct) Nike Free site\u2019s typography echoes the product itself, and in turn influences the navigation.\n\n\n\nFind Your Type\n\nWith thousands of fonts to choose from, the possibilities are ridiculously open. From angles to radii to color to weight, you\u2019ve got endless fodder before you. Great type designers spent countless hours slaving over these detailed letterforms; take advantage of it! Don\u2019t feel like you have to limit yourself to the same old Helvetica and wet floors\u2026 unless your design calls for it. \n\nHappy hunting!", "year": "2009", "author": "Dan Mall", "author_slug": "danmall", "published": "2009-12-07T00:00:00+00:00", "url": "https://24ways.org/2009/type-inspired-interfaces/", "topic": "design"}
{"rowid": 277, "title": "Raising the Bar on Mobile", "contents": "One of the primary challenges of designing for mobile devices is that screen real estate is often in limited supply. Through the advocacy of Luke W and others, we\u2019ve drawn comfort from the idea that this constraint ends up benefiting users and designers alike, from obvious advantages like portability and reach, to influencing our content strategy decisions through focus and restraint. But that doesn\u2019t mean we shouldn\u2019t take advantage of every last pixel of that screen we can snag!\n\nAs anyone who has designed a website for use on a smartphone can attest, there\u2019s an awful lot of space on mobile screens dedicated to browser functions that would be better off toggled out of view. Unfortunately, the visibility of some of these elements is beyond our control, such as the buttons fixed to the bottom of the viewport in iOS\u2019s Safari and the WebOS browser. However, in many devices, the address bar at the top can be manually hidden, and its absence frees up enough pixel room for a large, impactful heading, a critical piece of navigation, or even just a little more white space to air things out.\n\nSo, as my humble contribution to this most festive of web publications, today I\u2019ll dig into the approach I used to hide the address bar in a browser-agnostic fashion for sites like BostonGlobe.com, and the jQuery Mobile framework.\n\nSurveying the land\n\nFirst, let\u2019s assess the chromes of some popular, current mobile browsers. For example purposes, the following screen-captures feature the homepage of the Boston Globe site, without any address-bar-hiding logic in place.\n\nNote: these captures are just mockups \u2013 actual experience on these platforms may vary.\n\n On the left is iOS5\u2019s Safari (running on iPhone), and on the right is Windows Phone 7 (pre-Mango).\n\n BlackBerry 7 (left), and Android 2.3 (right).\n\n WebOS (left), Opera Mini (middle), and Opera Mobile (right).\n\nSome browsers, such the default browsers on WebOS and BlackBerry 5, hide the bar automatically without any developer intervention, but many of them don\u2019t. Of these, we can only manually hide the address bar on iOS Safari and Android (according to Opera Web Opener, Mike Taylor, some discussion is underway for support in Opera Mini and Mobile as well, which would be great!). This is unfortunate, but iOS and Android are incredibly popular, so let\u2019s direct our focus there.\n\nGreat API, or greatest API?\n\nAs it turns out, iOS and Android not only allow you to hide the address bar, they use the same JavaScript method to do so, too (this shouldn\u2019t be surprising, given that they are both WebKit browsers, but nothing expected happens in mobile). However, the method they use is not exactly intuitive. You might set out looking for a JavaScript API dedicated to this purpose, like, say, window.toolbar.hide(), but alas, to hide the address bar you need to use the window.scrollTo method!\n\nwindow.scrollTo(0, 0);\n\nThe scrollTo method is not new, it\u2019s just this particular use of it that is. For the uninitiated, scrollTo is designed to scroll a document to a particular set of coordinates, assuming the document is large enough to scroll to that spot. The method accepts two arguments: a left coordinate; and a top coordinate. It\u2019s both simple and supported well pretty much everywhere. In iOS and Android, these coordinates are calculated from the top of the browser\u2019s viewport, just below the address bar (interestingly, it seems that some platforms like BlackBerry 6 treat the top of the browser chrome as 0 instead, meaning the page content is closer to 20px from the top).\n\nAnyway, by passing the coordinates 0, 0 to the scrollTo method, the browser will jump to the top of the page and pull the address bar out of view! Of course, if a quick call to scrollTo was all we need to do to hide the address bar in iOS and Android, this article would be pretty short, and nothing new. Unfortunately, the first issue we need to deal with is that this method alone will not usually do the trick: it must be called after the page has finished loading.\n\nThe browser gives us a load event for just that purpose, so we\u2019ll wrap our scrollTo method in it and continue on our merry way! We\u2019ll use the standard, addEventListener method to bind the the load event, passing arguments for event name load, and a callback function to execute when the event is triggered.\n\nwindow.addEventListener(\"load\",function() {\n window.scrollTo(0, 0);\n});\n\nFor the sake of preventing errors in those using browsers that don\u2019t support addEventListener, such as Internet Explorer 8 and under, let\u2019s make sure that method exists before we use it:\n\nif( window.addEventListener ){\n window.addEventListener(\"load\",function() {\n window.scrollTo(0, 0);\n });\n}\n\nNow we\u2019re getting somewhere, but we must also call the method after the load event\u2019s default behavior has been applied. For this, we can use the setTimeout method, delaying its execution to after the load event has run its course.\n\nif( window.addEventListener ){\n window.addEventListener(\"load\",function() {\n setTimeout(function(){\n window.scrollTo(0, 0);\n }, 0);\n });\n}\n\nSweet sugar of Christmas! Hit this demo in iOS and watch that address bar drift up and away!\n\nNot so fast\u2026\n\nWe\u2019ve got a little problem: the approach above does work in iOS but, in some cases, it works a little too well. In the process of applying this behavior, we\u2019ve broken one of the primary tenets of responsible web development: don\u2019t break the browser\u2019s default behaviour. This usability rule of thumb is often violated by developers with even the best of intentions, from breaking the browser\u2019s back button through unrecorded Ajax page refreshes, to fancy momentum touch scrolling scripts that can wreak havoc in all but the most sophisticated of devices. In this case, we\u2019ve prevented the browser\u2019s native support of deep-linking to sections of a page (a hash identifier in the URL matching a page element\u2019s id attribute, for example, http://example.com#contact) from working properly, because our script always scrolls to the top.\n\nTo avoid this collision, we\u2019ll need to detect whether a deep link, or hash, is present in the URL before applying our logic. We can do this by ensuring that the location.hash property is falsey:\n\nif( !window.location.hash && window.addEventListener ){\n window.addEventListener( \"load\",function() {\n setTimeout(function(){\n window.scrollTo(0, 0);\n }, 0);\n });\n}\n\nStill works great! And a quick test using a hash-based URL confirms that our script will not execute when a deep anchor is in play. Now iOS is looking sharp, and we\u2019ve added our feature defensively to avoid conflicts.\n\n\n\nNow, on to Android\u2026\n\nWait. You didn\u2019t expect that we could write code for one browser and be finished, right? Of course you didn\u2019t. I mentioned earlier that Android uses the same method for getting rid of the scrollbar, but I left out the fact that the arguments it prefers vary slightly, but significantly, from iOS. Bah!\n\nDifferering from the earlier logic from iOS, to remove the address bar on Android\u2019s default browser, you need to pass a Y coordinate of 1 instead of 0. Aside from being just plain odd, this is particularly unfortunate because to any other browser on the planet, 1px is a very real, however small, distance from the top of the page!\n\nwindow.scrollTo( 0, 1 );\n\nLooks like we\u2019re going to need a fork\u2026\n\nR UA Android?\n\nAt this point, some developers might decide to simply not support this feature in Android, and more determined devs might decide that a quick check of the User Agent string would be a reliable way to determine the browser and tweak the scroll value accordingly. Neither of those decisions would be tragic, but in the spirit of cross-browser and future-friendly development, I\u2019ll propose an alternative.\n\nBy this point, it should be clear that neither of the implementations above offer a particularly intuitive way to hide an address bar. As such, one might be skeptical that these approaches will stick around very long in their present state in either browser. Perhaps at some point, Android will decide to use 0 like iOS, making our lives a little easier, or maybe some new browser will decide to model their address bar hiding method after one of these implementations. In any case, detecting the User Agent only allows us to apply logic based on the known present, and in the world of mobile, let\u2019s face it, the present is already the past.\n\nWriting a check\n\nIn this next step of today\u2019s technique, we\u2019ll apply some logic to quickly determine the behavior model of the browser we\u2019re using, then capitalize on that model \u2013 without caring which browser it happens to come from \u2013 by applying the appropriate scroll distance.\n\nTo do this, we\u2019ll rely on a fortunate side effect of Android\u2019s implementation, which is when you programatically scroll the page to 1 using scrollTo, Android will report that it\u2019s still at 0 because oddly enough, it is! Of course, any other browser in this situation will report a scroll distance of 1. Thus, by scrolling the page to 1, then asking the browser its scroll distance, we can use this artifact of their wacky implementation to our advantage and scroll to the location that makes sense for the browser in play.\n\nGetting the scroll distance\n\nTo pull off our test, we\u2019ll need to ask the browser for its current scroll distance. The methods for getting scroll distance are not entirely standardized across popular browsers, so we\u2019ll need to use some cross-browser logic. The following scroll distance function is similar to what you\u2019d find in a library like jQuery. It checks the few common ways of getting scroll distance before eventually falling back to 0 for safety\u2019s sake (that said, I\u2019m unaware of any browsers that won\u2019t return a numeric value from one of the first three properties).\n\n// scrollTop getter\nfunction getScrollTop(){\n return scrollTop = window.pageYOffset ||\ndocument.compatMode === \"CSS1Compat\" && document.documentElement.scrollTop ||\ndocument.body.scrollTop || 0;\n}\n\nIn order to execute that code above, the body object (referenced here as document.body) will need to be defined already, or we\u2019ll risk an error. To determine that it\u2019s defined, we can run a quick timer to execute code as soon as that object is defined and ready for use.\n\nvar bodycheck = setInterval(function(){\n if( document.body ){\n clearInterval( bodycheck );\n //more logic can go here!!\n } \n}, 15 );\n\nAbove, we\u2019ve defined a 15 millisecond interval called bodycheck that checks if document.body is defined and, if so, clears itself of running again. Within that if statement, we can extend our logic further to run other code, such as our check for the scroll distance, defined via the variable scrollTop below:\n\nvar scrollTop,\n bodycheck = setInterval(function(){\n if( document.body ){\n clearInterval( bodycheck );\n scrollTop = getScrollTop();\n } \n}, 15 );\n\nWith this working, we can immediately scroll to 1, then check the scroll distance when the body is defined. If the distance reports 1, we\u2019re likely in a non-Android browser, so we\u2019ll scroll back to 0 and clean up our mess.\n\nwindow.scrollTo( 0, 1 );\n\nvar scrollTop,\n bodycheck = setInterval(function(){\n if( document.body ){\n clearInterval( bodycheck );\n scrollTop = getScrollTop();\n window.scrollTo( 0, scrollTop === 1 ? 0 : 1 );\n } \n}, 15 );\n\nCashing in\n\nAll of the pieces are written now, so all we need to do is combine them with our previous logic for scrolling when the window is loaded, and we\u2019ll have a cross-browser solution of which John Resig would be proud. Here\u2019s our combined code snippet, with some formatting updates rolled in as well:\n\n(function( win ){\n\tvar doc = win.document;\n\n\t// If there\u2019s a hash, or addEventListener is undefined, stop here\n\tif( !location.hash && win.addEventListener ){\n\t\t//scroll to 1\n\t\twindow.scrollTo( 0, 1 );\n\t\tvar scrollTop = 1,\n\t\t\tgetScrollTop = function(){\n\t\t\t\treturn win.pageYOffset || doc.compatMode = \"CSS1Compat\" && doc.documentElement.scrollTop || doc.body.scrollTop || 0;\n\t\t\t},\n\t\t\t//reset to 0 on bodyready, if needed\n\t\t\tbodycheck = setInterval(function(){\n\t\t\t\tif( doc.body ){\n\t\t\t\t\tclearInterval( bodycheck );\n\t\t\t\t\tscrollTop = getScrollTop();\n\t\t\t\t\twin.scrollTo( 0, scrollTop = 1 ? 0 : 1 );\n\t\t\t\t}\t\n\t\t\t}, 15 );\n\t\twin.addEventListener( \u201cload\u201d, function(){\n\t\t\tsetTimeout(function(){\n\t\t\t\t\t//reset to hide addr bar at onload\n\t\t\t\t\twin.scrollTo( 0, scrollTop === 1 ? 0 : 1 );\n\t\t\t}, 0);\n\t\t} );\n\t}\n})( this );\nView code example\n\nAnd with that, we\u2019ve got a bunch more room to play with on both iOS and Android.\n\n\n\nBreak out the eggnog\n\n\u2026because we\u2019re not done yet! In the spirit of making our script act more defensively, there\u2019s still another use case to consider. It was essential that we used the window\u2019s load event to trigger our scripting, but on pages with a lot of content, its use can come at a cost. Often, a user will begin interacting with a page, scrolling down as they read, before the load event has fired. In those situations, our script will jump the user back to the top of the page, resulting in a jarring experience.\n\nTo prevent this problem from occurring, we\u2019ll need to ensure that the page has not been scrolled beyond a certain amount. We can add a simple check using our getScrollTop function again, this time ensuring that its value is not greater than 20 pixels or so, accounting for a small tolerance.\n\nif( getScrollTop() < 20 ){\n //reset to hide addr bar at onload\n window.scrollTo( 0, scrollTop === 1 ? 0 : 1 );\n}\n\nAnd with that, we\u2019re pretty well protected! Here\u2019s a final demo.\n\nThe completed script can be found on Github (full source: https://gist.github.com/1183357 ). It\u2019s MIT licensed. Feel free to use it anywhere or any way you\u2019d like!\n\nYour thoughts?\n\nI hope this article provides you with a browser-agnostic approach to hiding the address bar that you can use in your own projects today. Perhaps alternatively, the complications involved in this approach convinced you that doing this well is more trouble than it\u2019s worth and, depending on the use case, that could be a fair decision. But at the very least, I hope this demonstrates that there\u2019s a lot of work involved in pulling off this small task in only two major platforms, and that there\u2019s a real need for standardization in this area.\n\nFeel free to leave a comment or criticism and I\u2019ll do my best to answer in a timely fashion.\n\nThanks, everyone!\n\nSome parting notes\n\nI scream, you scream\u2026\n\nAt the time of writing, I was not able to test this method on the latest Android 4.0 (Ice Cream Sandwich) build. According to Sencha Touch\u2019s browser scorecard, the browser in 4.0 may have a different way of managing the address bar, so I\u2019ll post in the comments once I get a chance to dig into it further.\n\nShort pages get no love\n\nToday\u2019s technique only works when the page is as tall, or taller than, the device\u2019s available screen height, so that the address bar may be scrolled out of view. On a short page, you might work around this issue by applying a minimum height to the body element ( body { min-height: 460px; } ), but given the variety of screen sizes out there, not to mention changes in orientation, it\u2019s tough to find a value that makes much sense (unless you manipulate it with JavaScript).", "year": "2011", "author": "Scott Jehl", "author_slug": "scottjehl", "published": "2011-12-20T00:00:00+00:00", "url": "https://24ways.org/2011/raising-the-bar-on-mobile/", "topic": "design"}
{"rowid": 285, "title": "Composing the New Canon: Music, Harmony, Proportion", "contents": "Ohne Musik w\u00e4re das Leben ein Irrtum\n\u2014Friedrich NIETZSCHE, G\u00f6tzen-D\u00e4mmerung, Spr\u00fcche und Pfeile 33, 1889\n\n\nSomehow, music is hardcoded in human beings. It is something we understand and respond to without prior knowledge. Music exercises the emotions and our imaginative reflex, not just our hearing. It behaves so much like our emotions that music can seem to symbolize them, to bear them from one person to another. Not surprisingly, it conjures memories: the word music derives from Greek \u03bc\u03bf\u03c5\u03c3\u03b9\u03ba\u03ae (mousike), art of the Muses, whose mythological mother was Mnemosyne, memory. But it can also summon up the blood, console the bereaved, inspire fanaticism, bolster governments and dissenters alike, help us learn, and make web designers dance. And what would Christmas be without music?\n\nMusic moves us, often in ways we can\u2019t explain. By some kind of alchemy, music frees us from the elaborate nuisance and inadequacy of words. Across the world and throughout recorded history \u2013 and no doubt well before that \u2013 people have listened and made (and made out to) music.\n\n\n\t[I]t appears probable that the progenitors of man, either the males or females or both sexes, before acquiring the power of expressing their mutual love in articulate language, endeavoured to charm each other with musical notes and rhythm.\n\u2014Charles DARWIN, The Descent of Man, and Selection in Relation to Sex, 1871\n\n\nIt\u2019s so integral to humankind, we\u2019ve sent it into space as a totem for who we are. (Who knows? It might be important.) Music is essential, a universal compulsion; as Nietzsche wrote, without music life would be a mistake.\n\nMusic, design and web design\n\nThere are some obvious and notable similarities between music and visual design. Both can convey mood and evoke emotion but, even under close scrutiny, how they do that remains to a great extent mysterious. Each has formal qualities or parts that can be abstracted, analysed and discussed, often using the same terminology: composition, harmony, rhythm, repetition, form, theme; even colour, texture and tone.\n\nA possible reason for these shared aspects is that both visual design and music are means to connect with people in deep and lasting ways. Furthermore, I believe the connections to be made can complement direct emotional appeal. Certain aesthetic qualities in music work on an unconscious and, it could be argued, universal level. Using musical principles in our designs, then, can help provide the connectedness between content, device and user that we now seek as web designers.\n\nYet, when we talk about music and web design, the conversation is almost always about the music designers listen to while working, a theme finding its apotheosis in Designers.MX. Sometimes, articles in that dreary list format seek inspiration from music industry websites. There\u2019s even a service offering pre-templated web designs for bands, and at least one book surveyed the landscape back in 2006. Occasionally, discussions broaden somewhat into whether and how different kinds of music can inspire and influence the design work we produce.\n\nSuch enquiries, it seems to me, are beside the point. Do I really design differently when I listen to Bach rather than Bacharach? Will the barely restrained energy of Count Basie\u2019s The Kid from Red Bank mean I choose a lively colour palette, and rural, autumnal shades when inspired by Fleet Foxes? Mahler means a thirteen-column layout? Gillian Welch leads to distressed black and white photography? While reflecting the importance we place in music and how it seems to help us in our work, surveys on musical taste and lists of favourite artists fail to recognize that some of the fundamental aesthetic characteristics of music can be adapted and incorporated into modern web design.\n\nAntiphonal geometry\n\nOver recent years, web designers have embraced grid systems as powerful tools to help create good-looking and intuitive user experiences. With the advent of responsive design, these grids and their contents must adapt to the different screen sizes and properties of all kinds of user devices. Finding and using grid values that can scale well and retain or enhance their proportions and relationships while making the user experience meaningful in several different contexts is more important than ever.\n\nIn print, this challenge has always started with the dimensions and proportions of the page. Content can thereby be made to belong inside the page and be bound to it. And music has been used for centuries to further this aim. As Robert Bringhurst says in The Elements of Typographical Style:\n\n\n\tIndeed, one of the simplest of all systems of page proportions is based on the familiar intervals of the diatonic scale. Pages that embody these basic musical proportions have been in common use in Europe for more than a thousand years.\n\n\nVery well. But while he goes on to list (from the full chromatic scale, rather than just diatonic) the proportions and the musical intervals they\u2019re based on, Bringhurst fails to mention what they\u2019re ratios of or their potential effects. Shame. In his favour, however, he later touches on how proportions in print might be considered to work:\n\n\n\tThe page is a piece of paper. It is also a visible and tangible proportion, silently sounding the thoroughbass of the book. On it lies the textblock, which must answer to the page. The two together \u2013 page and textblock \u2013 produce an antiphonal geometry. That geometry alone can bond the reader to the book. Or conversely, it can put the reader to sleep, or put the reader\u2019s nerves on edge, or drive the reader away.\n\n\nSo what does Bringhurst mean by antiphonal geometry, a phrase that marries the musical to the spatial? By stating that the textblock \u201cmust answer to the page\u201d, the implication is that the relationship between the proportions of the page and the shape of the textblock printed on it embodies a spatial (geometrical) call-and-response (antiphony) that can be appealing or not.\n\nBoulton\u2019s new canon\n\nBut, as Mark Boulton has pointed out, on the web \u201cthere are no edges. There are no \u2018pages\u2019. We\u2019ve made them up.\u201d So, what is to be done? In January 2011 at the New Adventures in Web Design conference, Boulton presented his vision of a new canon of web design, a set of principles to guide us as we design the web. There are three overlapping tenets:\n\n\n\tdesign from the content out\n\tcreate connectedness between the different content elements\n\tbind the content to the web device\n\n\nRather than design from the edges in, we need to design layout systems from the content out. To this end, Boulton asserts that grid system design should begin with a constraint, and he suggests we use the size of a fixed content element, such as an advertising unit or image, as a starting point for online grid calculations. Khoi Vinh advocates the same approach in his book, Ordering Disorder: Grid Principles for Web Design.\n\nBoulton\u2019s second and third tenets, however, are more complex and overlap significantly with each other. Connecting the different parts of the content and binding the content to the device share many characteristics and solutions:\n\n\n\tadopting ems and percentages as units of size for layout elements\n\taltering text size, line length and line height for different viewport dimensions\n\tproviding higher resolution images for devices with greater pixel densities\n\tfluid layout grids, flexible images and responsive design\n\n\nAll can help relate the presentation of the content to its delivery in a certain context.\n\nBut how do we determine the relationship between one element of a layout and another? How can we avoid making arbitrary decisions about the relative sizes of parts of our designs? What can we use to connect the parts of our design to one another, and how can we bind the presentation of the content to the user\u2019s device?\n\nTim Brown\u2019s application of modular typographic scales hints at an answer. In the very useful tool he created for calculating such scales, Brown includes two musical ratios: the perfect fifth (2:3); and the perfect fourth (3:4). Why? Where do they come from? And what do they mean?\n\nHarmonies musical and visual\n\nFundamental to music are rhythm and harmony.\n\nAs any drummer will tell you, without rhythm there is no music. Even when there\u2019s no regular beat, any tune follows a rhythm, however irregular, simply because a change of note is a point of change in the music. Although rhythm, timing and pacing are all relevant to interaction design, right now it\u2019s harmony we\u2019re interested in.\n\nSometimes harmony is called the vertical aspect of music, and melody the horizontal. But this conceit overlooks the fact that harmony is both vertical and horizontal. A single melodic line, as it is played, implies various sets of harmonies on which it is grounded, whether or not those harmonies are played. So, harmony doesn\u2019t just sit vertically beneath the horizontal melody, but moves horizontally as well, through harmonic progression.\n\nTo stretch this arrangement pixel-thin, we could argue that in onscreen design melody is the content, and the layout and arrangement of the content is the harmony. We sometimes say a design is harmonious when the interplay of different elements of a design is pleasing or balanced or in proportion, and the content (the melody) is set off or conveyed well by or appropriate to the design.\n\nWe seem to know instinctively whether a layout is harmonious\u2026\n\nIn the design of The Great Discontent, the relationships between different elements combine to form a balanced whole.\n\n\u2026or not.\n\nThere\u2019s no harmony in the Department for Education\u2019s website because the different parts of the content don\u2019t feel related to one another.\n\nWhat is it that makes one design harmonious and another dissonant? It\u2019s not just whether things line up, though that\u2019s a start. I believe there are much deeper aesthetic forces at work, forces we can tap into in our onscreen designs. Now, I\u2019m not going start a difficult discussion about aesthetics. For our purposes, we just need to know that it\u2019s the branch of philosophy dealing with the nature of beauty, and the creation and perception of beauty. And among the key components in the perception of beauty are harmony and proportion. These have been part of traditional western aesthetics since Plato (about 2,500 years).\n\nOne of the ways we appreciate the beauty of music is through the harmonic intervals we hear. A musical interval is a combination of two notes and it describes the distance between the two pitches. For example, the distance between C and the G above it (if we take C as the tonic or root) is called a perfect fifth.\n\nLeft: C to G, a perfect fifth. Right: C and G, not a perfect fifth.\n\n \n\nAnd, to get superficially scientific for a moment, each musical interval can be expressed as a ratio of the wavelength frequencies of the notes; for our perfect fifth, with every two wavelengths of C, there are three of G. And what is a ratio, if not a proportion of one thing to another?\n\nSo, simple musical harmony (using what\u2019s known as just intonation1) affords us a set of proportions, expressed as ratios. Where better to apply these ideas of harmony and proportion from music in web design, than grid systems?\n\nA digression: whither \u03c6?\n\nQuite often in our discussions of pure design and aesthetics, we mention the golden ratio and regurgitate the same justifications for its use: roots in antiquity; embodied in classical and Renaissance architecture and art; occurrence in nature; the New Twitter, and so forth (oh, really?).\n\nYet the ratios of musical intervals from just intonation are equally venerable and much more widespread: described by Pythagorus; employed in Palladian architecture, and printing, books and art from the Renaissance onwards; in modern times, film and television dimensions; standard international paper sizes (ISO 216, the A and B series); and, again and again, screen dimensions \u2013 chances are that screen you\u2019re probably looking at right now has the proportions 2:3 (iPhone and iPod Touch), 3:4 (iPad and Kindle), 3:5 (many smartphones), 5:8 or 16:9 (many widescreen monitors), all ratios of musical intervals.\n\nBack to our theme\u2026\n\nMusical interval ratios\n\nLet\u2019s take a look at most of the ratios within a couple of octaves and crunch some numbers to generate some percentages and other values that we can use in our designs. First, the intervals and their ratios in just intonation and expressed as ratios of one:\n\n\n\t\t\n\t\t\tName \n\t\t\tInterval in C \n\t\t\tRatio \n\t\t\tRatio (1:x) \n\t\t\n\t\t\n\t\t\t unison \n\t\t\t C\u2192C \n\t\t\t 1:1 \n\t\t\t 1:1 \n\t\t\n\t\t\n\t\t\t minor second \n\t\t\t C\u2192D\u266d \n\t\t\t 15:16 \n\t\t\t 1:1.067 \n\t\t\n\t\t\n\t\t\t major second \n\t\t\t C\u2192D \n\t\t\t 8:9 \n\t\t\t 1:1.125 \n\t\t\n\t\t\n\t\t\t minor third \n\t\t\t C\u2192E\u266d \n\t\t\t 5:6 \n\t\t\t 1:1.2 \n\t\t\n\t\t\n\t\t\t major third \n\t\t\t C\u2192E \n\t\t\t 4:5 \n\t\t\t 1:1.25 \n\t\t\n\t\t\n\t\t\t perfect fourth \n\t\t\t C\u2192F \n\t\t\t 3:4 \n\t\t\t 1:1.333 \n\t\t\n\t\t\n\t\t\t augmented fourth \nor diminished fifth \n\t\t\t C\u2192F\u266f/G\u266d \n\t\t\t 1:\u221a2 \n\t\t\t 1:1.414 \n\t\t\n\t\t\n\t\t\t perfect fifth \n\t\t\t C\u2192G \n\t\t\t 2:3 \n\t\t\t 1:1.5 \n\t\t\n\t\t\n\t\t\t minor sixth \n\t\t\t C\u2192A\u266d \n\t\t\t 5:8 \n\t\t\t 1:1.6 \n\t\t\n\t\t\n\t\t\t major sixth \n\t\t\t C\u2192A \n\t\t\t 3:5 \n\t\t\t 1:1.667 \n\t\t\n\t\t\n\t\t\t minor seventh \n\t\t\t C\u2192B\u266d \n\t\t\t 9:16 \n\t\t\t 1:1.778 \n\t\t\n\t\t\n\t\t\t major seventh \n\t\t\t C\u2192B \n\t\t\t 8:15 \n\t\t\t 1:1.875 \n\t\t\n\t\t\n\t\t\t octave \n\t\t\t C\u2192C\u2191 \n\t\t\t 1:2 \n\t\t\t 1:2 \n\t\t\n\t\t\n\t\t\t major tenth \n\t\t\t C\u2192E\u2191 \n\t\t\t 2:5 \n\t\t\t 1:2.5 \n\t\t\n\t\t\n\t\t\t major eleventh \n\t\t\t C\u2192F\u2191 \n\t\t\t 3:8 \n\t\t\t 1:2.667 \n\t\t\n\t\t\n\t\t\t major twelfth \n\t\t\t C\u2192G\u2191 \n\t\t\t 1:3 \n\t\t\t 1:3 \n\t\t\n\t\t\n\t\t\t double octave \n\t\t\t C\u2192C\u2191 \n\t\t\t 1:4 \n\t\t\t 1:4 \n\t\t\n\t\t\n\t\t\tName \n\t\t\tInterval in C \n\t\t\tRatio \n\t\t\tRatio (1:x) \n\t\t\n\n\nAnd now as percentages, of both the larger and smaller values in the ratios:\n\n\n\t\t\n\t\t\tName \n\t\t\tRatio \n\t\t\t% of larger value \n\t\t\t% of smaller value \n\t\t\n\t\t\n\t\t\t unison \n\t\t\t 1:1 \n\t\t\t 100% \n\t\t\t 100% \n\t\t\n\t\t\n\t\t\t minor second \n\t\t\t 15:16 \n\t\t\t 93.75% \n\t\t\t 106.667% \n\t\t\n\t\t\n\t\t\t major second \n\t\t\t 8:9 \n\t\t\t 88.889% \n\t\t\t 112.5% \n\t\t\n\t\t\n\t\t\t minor third \n\t\t\t 5:6 \n\t\t\t 83.333% \n\t\t\t 120% \n\t\t\n\t\t\n\t\t\t major third \n\t\t\t 4:5 \n\t\t\t 80% \n\t\t\t 125% \n\t\t\n\t\t\n\t\t\t perfect fourth \n\t\t\t 3:4 \n\t\t\t 75% \n\t\t\t 133.333% \n\t\t\n\t\t\n\t\t\t augmented fourth \nor diminished fifth \n\t\t\t 1:\u221a2 \n\t\t\t 70.711% \n\t\t\t 141.421% \n\t\t\n\t\t\n\t\t\t perfect fifth \n\t\t\t 2:3 \n\t\t\t 66.667% \n\t\t\t 150% \n\t\t\n\t\t\n\t\t\t minor sixth \n\t\t\t 5:8 \n\t\t\t 62.5% \n\t\t\t 160% \n\t\t\n\t\t\n\t\t\t major sixth \n\t\t\t 3:5 \n\t\t\t 60% \n\t\t\t 166.667% \n\t\t\n\t\t\n\t\t\t minor seventh \n\t\t\t 9:16 \n\t\t\t 56.25% \n\t\t\t 177.778% \n\t\t\n\t\t\n\t\t\t major seventh \n\t\t\t 8:15 \n\t\t\t 53.333% \n\t\t\t 187.5% \n\t\t\n\t\t\n\t\t\t octave \n\t\t\t 1:2 \n\t\t\t 50% \n\t\t\t 200% \n\t\t\n\t\t\n\t\t\t major tenth \n\t\t\t 2:5 \n\t\t\t 40% \n\t\t\t 250% \n\t\t\n\t\t\n\t\t\t major eleventh \n\t\t\t 3:8 \n\t\t\t 37.5% \n\t\t\t 266.667% \n\t\t\n\t\t\n\t\t\t major twelfth \n\t\t\t 1:3 \n\t\t\t 33.333% \n\t\t\t 300% \n\t\t\n\t\t\n\t\t\t double octave \n\t\t\t 1:4 \n\t\t\t 25% \n\t\t\t 400% \n\t\t\n\t\t\n\t\t\tName \n\t\t\tRatio \n\t\t\t% of larger value \n\t\t\t% of smaller value \n\t\t\n\n\nAs you can see, the simple musical intervals are expressed as ratios of small whole numbers (integers). We can then normalize them as ratios of one, as well as derive percentage values, both in terms of the smaller value to the larger, and vice versa. These are the numbers we can incorporate into our designs. If you\u2019ve ever written something like body { font: 100%/1.5 \"Museo Sans\", Helvetica, sans-serif; } in your CSS, you\u2019re already using a musical ratio: the perfect fifth.\n\nModular scales allow us to generate a set of numbers based on a musical interval that can be used for all kinds of typographic and layout decisions to create harmony in a visual design for the web. As Tim Brown said at the 2010 Build conference:\n\n\n\tI think that from that most atomic unit \u2013 type \u2013 whole experiences can resonate, whole experiences can be harmonious. And whole experiences can have a purpose suited to our design intentions.\n\n\nOnce more, with feeling: connectedness\n\nAs well as modular scales, there are other methods of incorporating musical interval ratios into our work. Setting the ratio of font size to line height in CSS is one such example. We could also create a typographic hierarchy using the same principle and combining several ratios that we know harmonize well musically in a chord:\n\nbody { font-size: 75%; } /* =12px = base size or tonic */\n\nh1 { font-size: 32px; font-size: 2.667rem; }\n /* =32px = 3:8 = major eleventh (C\u2192F\u2191) */\n\nh2 { font-size: 24px; font-size: 2rem; }\n /* =24px = 1:2 = octave (C\u2192C\u2191) */\n\nh3 { font-size: 20px; font-size: 1.667rem; }\n /* =20px = 3:5 = major sixth (C\u2192A) */\n\nfigcaption, small { font-size: 9px; font-size : 0.75rem }\n /* =9px = 3:4 = perfect fourth (C\u2192F) */\n\nWhoa! Hold your reindeer, Santa! How can we know what interval combinations work well together to form chords? Well, I\u2019m a classically trained musician, so perhaps I have an advantage. To avoid a long, technically complex digression into musical harmony, here are a few basic combinations of intervals that are harmonious in one way or another:\n\n\n\tunison; major third; perfect fifth; octave\n\tunison; perfect fourth; major sixth; octave\n\tunison; minor third; minor sixth; octave\n\tunison; minor third; diminished fifth; major sixth; octave\n\n\nThis isn\u2019t to say that other combinations can\u2019t be used to interesting effect and particular purpose \u2013 they surely can \u2013 but I have to make sure there\u2019s something left for you to experiment with in the wee small hours over the holiday. Bear in mind, though, were I to play you two notes from the same scale to form a minor second, for example, you\u2019d probably say it was dissonant and maybe that quality of the 15:16 ratio would be translated to the design.\n\n \n\nIn the typographic hierarchy above, you\u2019ll notice I used an interval in the higher octave, which affords a broader range of ratios while retaining the harmony. Thus, a perfect fifth (2:3) becomes a major twelfth (1:3), or a major sixth (3:5) becomes a major thirteenth (3:10).\n\nThe harmonic ratios can obviously be used as proportions for layout as well, in several different ways:\n\n\n\timage width and height (for example, 450\u00d7800px = 9:16 = minor seventh)\n\tmain content to page width (67%:100% = 2:3 = perfect fifth)\n\tpage width to viewport width (80%:100% = 4:5 = major third)\n\n\nOne great benefit of using such ratios in web design work is that they can be applied in responsive web design. Proportional values, based on percentages or equivalent em units, will scale with changing viewports, so your layout and image proportions can be maintained or deliberately changed, as we\u2019re about to find out, across devices.\n\nSmall speakers, tall speakers: binding to the device\n\nThe musical interval ratios also provide an opportunity, not only to create connectedness between the parts of a layout, but to bind the content to a device \u2013 that elusive antiphonal geometry. Just as a textblock and page resonate together, so too can web content and the screen. Earlier, I mentioned that several common screen aspect ratios match musical interval ratios. It would seem, then, that we have a set of proportions that we can use in different ways to establish and retain a sense of harmony that can be based on and change with those contexts. Using musical interval ratios, we can bind the display of our content to the device it\u2019s displayed on.\n\nIf you haven\u2019t met already, let me introduce you to the device-aspect-ratio property of CSS media queries.\n\n@media only screen and (device-aspect-ratio: 3/4) { }\n@media only screen and (device-aspect-ratio: 480/640) { }\n@media only screen and (device-aspect-ratio: 600/800) { }\n@media only screen and (device-aspect-ratio: 768/1024) { }\n\nRegardless of the precise pixel values, each of these media queries would apply to devices whose display area has an aspect ratio of 3:4. It works by comparing the device-width with the device-height. (It\u2019s not to be confused with aspect-ratio, which is defined by the width and height of the browser within the device.) The values in the media query are always presented as width/height, with portrait being the default orientation for smartphones and tablets; that is, to match an iPhone screen, you\u2019d use device-aspect-ratio: 2/3, not 3/2, which won\u2019t work.\n\nHere\u2019s a table of the musical intervals with their corresponding screens.\n\n\n\t\t\n\t\t\tName \n\t\t\tdevice-aspect-ratio \n\t\t\tScreens \n\t\t\tCommon resolutions (pixels) \n\t\t\n\t\t\n\t\t\t major third \n\t\t\t 5/4 \n\t\t\t TFT LCD computer screens \n\t\t\t 1,280\u00d71,024 \n\t\t\n\t\t\n\t\t\t perfect fourth \n\t\t\t 3/4 or 4/3 \n\t\t\t iPad, Kindle and other tablets, PDAs \n\t\t\t 320\u00d7240, 768\u00d71,024 \n\t\t\n\t\t\n\t\t\t perfect fifth \n\t\t\t 2/3 \n\t\t\t iPhone, iPod Touch \n\t\t\t 320\u00d7480, 640\u00d7960 \n\t\t\n\t\t\n\t\t\t minor sixth \n\t\t\t 8/5 (16/10) \n\t\t\t Many widescreens \n\t\t\t 1,152\u00d7720, 1,440\u00d7900, 1,920\u00d71,200 \n\t\t\n\t\t\n\t\t\t major sixth \n\t\t\t 3/5 \n\t\t\t Many smartphones \n\t\t\t 240\u00d7400, 480\u00d7800 \n\t\t\n\t\t\n\t\t\t minor seventh \n\t\t\t 16/9 or 9/16 \n\t\t\t Many widescreens and some smartphones \n\t\t\t 720\u00d71,280, 1,366\u00d7768, 1,920\u00d71,080, 2,560\u00d71,440 \n\t\t\n\n\n[You might argue that I\u2019m playing fast and loose with the ratios. I suppose, mathematically speaking, 9:16 is not the same as 16:9: I\u2019m no expert. But let\u2019s not throw the baby out with the bath water, particularly at Christmas.]\n\nWith this in mind, we can begin to write media queries that will influence various typographic and layout values in line with the aspect ratios of specific screens and in combination with em-based min-width queries that work from smaller, mobile screens to larger, desktop screens.\n\nHere\u2019s a very simple demo page with only some text, an image with a caption and a little basic layout: no seasonal overindulgence here.\n\nDemo: Sample page using device-aspect-ratio media queries based on musical interval ratios\n\nOur initial styles for all devices are based on the perfect fifth, with the major third and octave rounding things out into a harmonious whole, whether or not media queries are supported. For example:\n\nhtml { font-size: 100%; line-height: 1.5; }\n /* font-size:line-height = 16:24 = 2:3 = perfect fifth */\n\nh1 { font-size: 32px; font-size: 2rem; line-height: 1.25; }\n /* font-size:line-height = 32:40 = 4:5 = major third\n body:h1 = 16:32 = 1:2 = octave */\n\nWhile we should really consider methods of delivering images appropriate to the screen size, let\u2019s just stick to a single image for all devices. But why don\u2019t we change its aspect ratio from 4:3 to 3:2, to fit with our harmonic scheme? It\u2019s easy enough to do with overflow:hidden on the element to hide a part of the image, and a negative margin fudge:\n\nfigure img { margin: -8.5% 0 0 0; width: 100%; max-width: 100%; }\n\nOur first break point targets devices 320 pixels wide with an aspect ratio of 2:3, namely the iPhone and iPod Touch:\n\n/* 320px = 20\u00d716 */\n@media only screen and (min-width: 20em) and (device-aspect-ratio: 2/3) { }\n\nWe\u2019re actually already there, of course, as the intervals we\u2019ve chosen resonate with this aspect ratio \u2013 the content is already bound to the device.\n\nOur next media query, then, will make some changes to match a different ratio, the major sixth (3:5), which is same as that of many smartphones:\n\n/* 480px = 30\u00d716 */\n@media only screen and (min-width: 30em) and (device-aspect-ratio: 3/5) { }\n\nA different aspect ratio might require a change in harmony. For devices with these proportions, we\u2019ll now use the perfect fourth (3:4) and the major sixth (3:5) along with the octave we already have to create a new resonating harmony. For instance, a slightly wider screen means we can increase the line-height to aid the legibility of longer lines:\n\nhtml { line-height: 1.667; }\n /* font-size:line-height = 16:26.672 = 3:5 = major sixth */\n\nh1 { font-size: 32px; font-size: 2rem; line-height: 1.667; }\n /* font-size:line-height = 32:53.333 = 3:5 = major sixth\n body:h1 = 16:32 = 1:2 = octave */\n\nand we can remove the negative margin to display our 4:3 image in its entirety.\n\nEach screen displays content styled using relationships related to its own proportions. On the left, an iPhone 4 (2:3); on the right, a Samsung Nexus S (3:5). Your mileage may vary.\n\nAnother device, another media query. At 768 pixels, screens are wide enough to add columns. The ratios we\u2019ve used for the 3:5 screens include the perfect fourth (3:4) so we don\u2019t need to change any of the font measurements, but we can base the proportions of the columns on the major sixth interval:\n\narticle { float: left; width: 56%; }\n /* width of main column 3:5 (60% of 100%, major sixth)\n incorporating gutter width */\n\naside { float : right; width : 36%; }\n\nOn devices with a 3:4 aspect ratio, this works even better in landscape orientation.\n\nWhile not every screen over 768 pixels wide will have 3:4 proportions, the range of intervals informing the design ensure harmonious relationships between the different parts of the layout.\n\nFor wide screens proper (break point at 1,280 pixels) we can employ a new set of harmonious intervals. Many laptop and desktop screens have a 16:10 aspect ratio, which boils down to 8:5, equivalent to the minor sixth (5:8). Combined with a minor third (5:6) and the octave (1:2), this creates a new harmony appropriate to these devices. Let\u2019s increase the font size and change the image\u2019s aspect ratio to match:\n\nhtml { font-size: 120%; line-height: 1.6; }\n /* font-size increased for wider screens from 16px to 19.2px\n (5:6 = minor third)\n font-size:line-height = 19.2:30.72 = 5:8 = minor sixth */\n\nfigure img { margin: -12.5% 0 0 ; }\t\n /* using -ve margin combined with overflow:hidden\n on the figure element\n to crop the image from 4:3 to 8:5 = minor sixth */\n\nA wide screen with a 8:5 (16:10) aspect ratio and an image to match.\n\nWith more pixels at our disposal, we can also now use the musical interval ratios to determine the width of the layout, and change the column proportions as well:\n\nsection { margin: 0 auto; width: 83.333%; }\n /* content width:screen width = 5:6 = minor third */\n\narticle { width: 60%; }\n /* width of main column 5:8 (62.5% of 100%, minor sixth)\n incorporating gutter width */\n\naside { width: 35%; }\n\nWith some carefully targeted media queries, we can begin to reach towards fulfilling the second and third tenets of Boulton\u2019s new canon for web design: connecting the parts of content through relationships embodied in the layout design; and binding the content to the devices people use to access it.\n\nCoda\n\nMusical interval ratios and screen aspect ratios reveal more than convenient correspondence. These proportions work on a deep aesthetic level. Much is claimed for the golden ratio \u03c6, but none of the screens pervading our lives use it. Perhaps that\u2019s an accident of technology, but can making screens to \u03c6\u2019s proportions be more difficult or expensive than 2:3 or 3:4 or 16:10? Here, then, is not just one but a set of proportions with a uniquely human focus, originating in nature, recognized in antiquity, fundamental still.\n\nWe find music to be an art steeped with meaning, yet, unlike literary and representational arts, purely instrumental music has no obvious semantic content. It boasts an ability to express emotions while remaining an abstract art in some sense, which makes it very like design. These days, we\u2019re rightly encouraged to design for emotion, to make our users\u2019 experience meaningful, seductive, delightful. Using musical ideas and principles in our designs can help achieve those ends.\n\nLet\u2019s not be na\u00efve, of course; designing web pages is even less like composing music than it\u2019s like designing for print. In visual design, the eye will always be sovereign to the ear; following these principles will only get us so far. We cannot truly claim that a carefully composed web page layout will have the same qualities and effect as any musical patterns that inform it. In music, a set of intervals is always harmonious in relation to other sets of intervals: music rarely stands still. What aspect ratios will future screens take? Already today there is great variation in devices and support for media queries (and within that, support for device-aspect-ratio). And what of non-western musical traditions? Or rhythm, form, tempo and dynamics? What I\u2019ve demonstrated above is only a suggestion, a tentative exploration of one possible way forward.\n\nBut as our discipline matures and we become more articulate about what we do, we must look longer and deeper into areas of human endeavour already rich with value. Music is a fertile ground to explore and has the potential to yield up new approaches for web design.\n\nFootnotes\n\n \n Just intonation is a system of tuning that uses small integers to describe the musical intervals, based initially on the perfect fifth, that most consonant of intervals. Simple instruments such as vibrating strings and natural horns, as well as unaccompanied voices, tend to fall into just intonation naturally.", "year": "2011", "author": "Owen Gregory", "author_slug": "owengregory", "published": "2011-12-09T00:00:00+00:00", "url": "https://24ways.org/2011/composing-the-new-canon/", "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 element that has been so often discussed is another excellent solution if you\u2019re feeling particularly future-oriented. A picture polyfill exists so that you can start using the element now without any worries about support.\n\nConditional loading\n\nDon\u2019t load any more than you absolutely need to. If a script isn\u2019t needed at certain sizes, use the matchMedia polyfill to ensure it only loads when needed. Use eCSSential to do the same for unnecessary CSS files.\n\nLast year on 24 ways, Jeremy Keith wrote an article about conditional loading of content in a responsive design based on the screen width. The technique was later refined by the Filament Group into what they dubbed the Ajax-Include Pattern. It\u2019s a powerful and simple way to lighten the load on small screens as well as reduce clutter.\n\nGo vanilla?\n\nIf you take a look at the HTTP Archive you\u2019ll see that other than image size, JavaScript is the heaviest asset on a page weighing in at 215kb on average. It also boasts the fifth highest correlation to load time as well as the second highest correlation to render time. \n\nMuch of the weight can be attributed to our industry\u2019s increasing reliance on frameworks. This is especially a concern on mobile devices. PPK recently exclaimed that current JavaScript libraries are just \u201ctoo heavy for mobile\u201d. \u201cResearch from Stoyan Stefanov on parse times supports this. On some Android and iOS devices, it can take as long as 200-300ms just to parse jQuery.\n\nThere\u2019s nothing wrong about using a framework, but the problem is that they\u2019ve become the default. Before dropping another framework or plugin into a page, we should stop to consider the value it adds and whether we could accomplish what we need to do using a combination of vanilla JavaScript and CSS instead. (This is a great example of a scenario where a performance budget could help.)\n\nStart thinking beyond visual aesthetics\n\nWe love to tout the web\u2019s universality when discussing the need for responsive design. But that universality is not limited simply to screen size. Networks and hardware capabilities must factor in as well.\n\nThe web is an incredibly dynamic and interactive medium, and designing for it demands that we consider more than just visual aesthetics. Let\u2019s not forget to give those other qualities the attention they deserve.", "year": "2012", "author": "Tim Kadlec", "author_slug": "timkadlec", "published": "2012-12-05T00:00:00+00:00", "url": "https://24ways.org/2012/responsive-responsive-design/", "topic": "design"}
{"rowid": 173, "title": "Real Fonts and Rendering: The New Elephant in the Room", "contents": "My friend, the content strategist Kristina Halvorson, likes to call content \u201cthe elephant in the room\u201d of web design. She means it\u2019s the huge problem that no one on the web development team or client side is willing to acknowledge, face squarely, and plan for. \n\nA typical web project will pass through many helpful phases of research, and numerous beneficial user experience design iterations, while the content\u2014which in most cases is supposed to be the site\u2019s primary focus\u2014gets handled haphazardly at the end. Hence, elephant in the room, and hence also artist Kevin Cornell\u2019s recent use of elephantine imagery to illustrate A List Apart articles on the subject. But I digress.\n\nWithout discounting the primacy of the content problem, we web design folk have now birthed ourselves a second lumbering mammoth, thanks to our interest in \u201creal fonts on the web\u201c (the unfortunate name we\u2019ve chosen for the recent practice of serving web-licensed fonts via CSS\u2019s decade-old @font-face declaration\u2014as if Georgia, Verdana, and Times were somehow unreal). \n\nFor the fact is, even bulletproof and mo\u2019 bulletproofer @font-face CSS syntax aren\u2019t really bulletproof if we care about looks and legibility across browsers and platforms.\n\nHyenas in the Breakfast Nook\n\nThe problem isn\u2019t just that foundries have yet to agree on a standard font format that protects their intellectual property. And that, even when they do, it will be a while before all browsers support that standard\u2014leaving aside the inevitable politics that impede all standardization efforts. Those are problems, but they\u2019re not the elephant. Call them the coyotes in the room, and they\u2019re slowly being tamed.\n\nNor is the problem that workable, scalable business models (of which Typekit\u2018s is the most visible and, so far, the most successful) are still being shaken out and tested. The quality and ease of use of such services, their stability on heavily visited sites (via massively backed-up server clusters), and the fairness and sustainability of their pricing will determine how licensing and serving \u201creal fonts\u201d works in the short and long term for the majority of designer/developers.\n\nNor is our primary problem that developers with no design background may serve ugly or illegible fonts that take forever to load, or fonts that take a long time to download and then display as ordinary system fonts (as happens on, say, about.validator.nu). Ugliness and poor optimization on the web are nothing new. That support for @font-face in Webkit and Mozilla browsers (and for TrueType fonts converted to Embedded OpenType in Internet Explorer) adds deadly weapons to the non-designer\u2019s toolkit is not the technology\u2019s fault. JavaScript and other essential web technologies are equally susceptible to abuse. \n\nBeauty is in the Eye of the Rendering Engine\n\nNo, the real elephant in the room\u2014the thing few web developers and no \u201cweb font\u201d enthusiasts are talking about\u2014has to do with legibility (or lack thereof) and aesthetics (or lack thereof) across browsers and platforms. Put simply, even fonts optimized for web use (which is a whole thing: ask a type designer) will not look good in every browser and OS. That\u2019s because every browser treats hinting differently, as does every OS, and every OS version. \n\nFirefox does its own thing in both Windows and Mac OS, and Microsoft is all over the place because of its need to support multiple generations of Windows and Cleartype and all kinds of hardware simultaneously. Thus \u201creal type\u201d on a single web page can look markedly different, and sometimes very bad, on different computers at the same company. If that web page is your company\u2019s, your opinion of \u201cweb fonts\u201d may suffer, and rightfully. (The advantage of Apple\u2019s closed model, which not everyone likes, is that it allows the company to guarantee the quality and consistency of user experience.) \n\nAs near as my font designer friends and I can make out, Apple\u2019s Webkit in Safari and iPhone ignores hinting and creates its own, which Apple thinks is better, and which many web designers think of as \u201cwhat real type looks like.\u201d The forked version of Webkit in Chrome, Android, and Palm Pre also creates its own hinting, which is close to iPhone\u2019s\u2014close enough that Apple, Palm, and Google could propose it as a standard for use in all browsers and platforms. Whether Firefox would embrace a theoretical Apple and Google standard is open to conjecture, and I somehow have difficulty imagining Microsoft buying in\u2014even though they know the web is more and more mobile, and that means more and more of their customers are viewing web content in some version of Webkit.\n\nThe End of Simple\n\nThere are ways around this ugly type ugliness, but they involve complicated scripting and sniffing\u2014the very nightmares from which web standards and the simplicity of @font-face were supposed to save us. I don\u2019t know that even mighty Typekit has figured out every needed variation yet (although, working with foundries, they probably will). \n\nFor type foundries, the complexity and expense of rethinking classic typefaces to survive in these hostile environments may further delay widespread adoption of web fonts and the resolution of licensing and formatting issues. The complexity may also force designers (even those who prefer to own) to rely on a hosted rental model simply to outsource and stay current with the detection and programming required.\n\nForgive my tears. I stand in a potter\u2019s field of ideas like \u201cKeep it simple,\u201d by a grave whose headstone reads \u201cWrite once, publish everywhere.\u201d", "year": "2009", "author": "Jeffrey Zeldman", "author_slug": "jeffreyzeldman", "published": "2009-12-22T00:00:00+00:00", "url": "https://24ways.org/2009/real-fonts-and-rendering/", "topic": "design"}
{"rowid": 58, "title": "Beyond the Style Guide", "contents": "Much like baking a Christmas cake, designing for the web involves creating an experience in layers. Starting with a solid base that provides the core experience (the fruit cake), we can add further layers, each adding refinement (the marzipan) and delight (the icing).\nDon\u2019t worry, this isn\u2019t a misplaced cake recipe, but an evaluation of modular design and the role style guides can play in acknowledging these different concerns, be they presentational or programmatic.\nThe auteur\u2019s style guide\nAlthough trained as a graphic designer, it was only when I encountered the immediacy of the web that I felt truly empowered as a designer. Given a desire to control every aspect of the resulting experience, I slowly adopted the role of an auteur, exploring every part of the web stack: front-end to back-end, and everything in between. A few years ago, I dreaded using the command line. Today, the terminal is a permanent feature in my Dock.\nIn straddling the realms of graphic design and programming, it\u2019s the point at which they meet that I find most fascinating, with each dicipline valuing the creation of effective systems, be they for communication or code efficiency. Front-end style guides live at this intersection, demonstrating both the modularity of code and the application of visual design.\nPainting by numbers\nIn our rush to build modular systems, design frameworks have grown in popularity. While enabling quick assembly, these come at the cost of originality and creative expression \u2013 perhaps one reason why we\u2019re seeing the homogenisation of web design.\nIn editorial design, layouts should accentuate content and present it in an engaging manner. Yet on the web we see a practice that seeks templated predictability. In \u2018Design Machines\u2019 Travis Gertz argued that (emphasis added):\n\nDesign systems still feel like a novelty in screen-based design. We nerd out over grid systems and modular scales and obsess over style guides and pattern libraries. We\u2019re pretty good at using them to build repeatable components and site-wide standards, but that\u2019s sort of where it ends. [\u2026] But to stop there is to ignore the true purpose and potential of a design system.\n\nUnless we consider how interface patterns fully embrace the design systems they should be built upon, style guides may exacerbate this paint-by-numbers approach, encouraging conformance and suppressing creativity.\nAnatomy of a button\nLet\u2019s take a look at that most canonical of components, the button, and consider what we might wish to document and demonstrate in a style guide.\nThe different layers of our button component.\nContent\nThe most variable aspect of any component. Content guidelines will exert the most influence here, dictating things like tone of voice (whether we should we use stiff, formal language like \u2018Submit form\u2019, or adopt a more friendly tone, perhaps \u2018Send us your message\u2019) and appropriate language. For an internationalised interface, this may also impact word length and text direction or orientation.\nStructure\nHTML provides a limited vocabulary which we can use to structure content and add meaning. For interactive elements, the choice of element can also affect its behaviour, such as whether a button submits form data or links to another page:\n\nButton text\nNote: One of the reasons I prefer to use
![\"download](\"images/vcard-add.png\")
\n\t