{"rowid": 276, "title": "Your jQuery: Now With 67% Less Suck", "contents": "Fun fact: more websites are now using jQuery than Flash.\n\njQuery is an amazing tool that\u2019s made JavaScript accessible to developers and designers of all levels of experience. However, as Spiderman taught us, \u201cwith great power comes great responsibility.\u201d The unfortunate downside to jQuery is that while it makes it easy to write JavaScript, it makes it easy to write really really f*ing bad JavaScript. Scripts that slow down page load, unresponsive user interfaces, and spaghetti code knotted so deep that it should come with a bottle of whiskey for the next sucker developer that has to work on it. \n\nThis becomes more important for those of us who have yet to move into the magical fairy wonderland where none of our clients or users view our pages in Internet Explorer. The IE JavaScript engine moves at the speed of an advancing glacier compared to more modern browsers, so optimizing our code for performance takes on an even higher level of urgency.\n\nThankfully, there are a few very simple things anyone can add into their jQuery workflow that can clear up a lot of basic problems. When undertaking code reviews, three of the areas where I consistently see the biggest problems are: inefficient selectors; poor event delegation; and clunky DOM manipulation. We\u2019ll tackle all three of these and hopefully you\u2019ll walk away with some new jQuery batarangs to toss around in your next project.\n\nSelector optimization\n\nSelector speed: fast or slow?\n\nSaying that the power behind jQuery comes from its ability to select DOM elements and act on them is like saying that Photoshop is a really good tool for selecting pixels on screen and making them change color \u2013 it\u2019s a bit of a gross oversimplification, but the fact remains that jQuery gives us a ton of ways to choose which element or elements in a page we want to work with. However, a surprising number of web developers are unaware that all selectors are not created equal; in fact, it\u2019s incredible just how drastic the performance difference can be between two selectors that, at first glance, appear nearly identical. For instance, consider these two ways of selecting all paragraph tags inside a
with an ID.\n\n$(\"#id p\");\n\n$(\"#id\").find(\"p\");\n\nWould it surprise you to learn that the second way can be more than twice as fast as the first? Knowing which selectors outperform others (and why) is a pretty key building block in making sure your code runs well and doesn\u2019t frustrate your users waiting for things to happen.\n\nThere are many different ways to select elements using jQuery, but the most common ways can be basically broken down into five different methods. In order, roughly, from fastest to slowest, these are:\n\n\n\t$(\"#id\"); \nThis is without a doubt the fastest selector jQuery provides because it maps directly to the native document.getElementbyId() JavaScript method. If possible, the selectors listed below should be prefaced with an ID selector in conjunction with jQuery\u2019s .find() method to limit the scope of the page that has to be searched (as in the $(\"#id\").find(\"p\") example shown above).\n\t$(\"p\");, $(\"input\");, $(\"form\"); and so on\nSelecting elements by tag name is also fast, since it maps directly to the native document.getElementsByTagname() method.\n\t$(\".class\"); \nSelecting by class name is a little trickier. While still performing very well in modern browsers, it can cause some pretty significant slowdowns in IE8 and below. Why? IE9 was the first IE version to support the native document.getElementsByClassName() JavaScript method. Older browsers have to resort to using much slower DOM-scraping methods that can really impact performance.\n\t$(\"[attribute=value]\");\nThere is no native JavaScript method for this selector to use, so the only way that jQuery can perform the search is by crawling the entire DOM looking for matches. Modern browsers that support the querySelectorAll() method will perform better in certain cases (Opera, especially, runs these searches much faster than any other browser) but, generally speaking, this type of selector is Slowey McSlowersons.\n\t$(\":hidden\");\nLike attribute selectors, there is no native JavaScript method for this one to use. Pseudo-selectors can be painfully slow since the selector has to be run against every element in your search space. Again, modern browsers with querySelectorAll() will perform slightly better here, but try to avoid these if at all possible. If you must use one, try to limit the search space to a specific portion of the page: $(\"#list\").find(\":hidden\");\n\n\nBut, hey, proof is in the performance testing, right? It just so happens that said proof is sitting right here. Be sure to notice the class selector numbers beside IE7 and 8 compared to other browsers and then wonder how the people on the IE team at Microsoft manage to sleep at night. Yikes.\n\nChaining\n\nAlmost all jQuery methods return a jQuery object. This means that when a method is run, its results are returned and you can continue executing more methods on them. Rather than writing out the same selector multiple times over, just making a selection once allows multiple actions to be run on it.\n\nWithout chaining\n\n$(\"#object\").addClass(\"active\");\n$(\"#object\").css(\"color\",\"#f0f\");\n$(\"#object\").height(300);\n\nWith chaining\n\n$(\"#object\").addClass(\"active\").css(\"color\", \"#f0f\").height(300);\n\nThis has the dual effect of making your code shorter and faster. Chained methods will be slightly faster than multiple methods made on a cached selector, and both ways will be much faster than multiple methods made on non-cached selectors. Wait\u2026 \u201ccached selector\u201d? What is this new devilry? \n\nCaching\n\nAnother easy way to speed up your code that seems to be a mystery to developers is the idea of caching your selectors. Think of how many times you end up writing the same selector over and over again in any project. Every $(\".element\") selector has to search the entire DOM each time, regardless of whether or not that selector had been previously run. Running the selection once and then storing the results in a variable means that the DOM only has to be searched once. Once the results of a selector have been cached, you can do anything with them.\n\nFirst, run your search (here we\u2019re selecting all of the
elements inside
): \n\nvar blocks = $(\"#blocks\").find(\"li\");\n\nNow, you can use the blocks variable wherever you want without having to search the DOM every time.\n\n$(\"#hideBlocks\").click(function() {\n blocks.fadeOut();\n});\n$(\"#showBlocks\").click(function() {\n blocks.fadeIn();\n});\n\nMy advice? Any selector that gets run more than once should be cached. This jsperf test shows just how much faster a cached selector runs compared to a non-cached one (and even throws some chaining love in to boot).\n\nEvent delegation\n\nEvent listeners cost memory. In complex websites and apps it\u2019s not uncommon to have a lot of event listeners floating around, and thankfully jQuery provides some really easy methods for handling event listeners efficiently through delegation.\n\nIn a bit of an extreme example, imagine a situation where a 10\u00d710 cell table needs to have an event listener on each cell; let\u2019s say that clicking on a cell adds or removes a class that defines the cell\u2019s background color. A typical way that this might be written (and something I\u2019ve often seen during code reviews) is like so:\n\n$('table').find('td').click(function() {\n $(this).toggleClass('active');\n});\n\njQuery 1.7 has provided us with a new event listener method, .on(). It acts as a utility that wraps all of jQuery\u2019s previous event listeners into one convenient method, and the way you write it determines how it behaves. To rewrite the above .click() example using .on(), we\u2019d simply do the following:\n\n$('table').find('td').on('click',function() {\n $(this).toggleClass('active');\n});\n\nSimple enough, right? Sure, but the problem here is that we\u2019re still binding one hundred event listeners to our page, one to each individual table cell. A far better way to do things is to create one event listener on the table itself that listens for events inside it. Since the majority of events bubble up the DOM tree, we can bind a single event listener to one element (in this case, the
) and wait for events to bubble up from its children. The way to do this using the .on() method requires only one change from our code above:\n\n$('table').on('click','td',function() {\n $(this).toggleClass('active');\n});\n\nAll we\u2019ve done is moved the td selector to an argument inside the .on() method. Providing a selector to .on() switches it into delegation mode, and the event is only fired for descendants of the bound element (table) that match the selector (td). With that one simple change, we\u2019ve gone from having to bind one hundred event listeners to just one. You might think that the browser having to do one hundred times less work would be a good thing and you\u2019d be completely right. The difference between the two examples above is staggering.\n\n(Note that if your site is using a version of jQuery earlier than 1.7, you can accomplish the very same thing using the .delegate() method. The syntax of how you write the function differs slightly; if you\u2019ve never used it before, it\u2019s worth checking the API docs for that page to see how it works.)\n\nDOM manipulation\n\njQuery makes it very easy to manipulate the DOM. It\u2019s trivial to create new nodes, insert them, remove other ones, move things around, and so on. While the code to do this is simple to write, every time the DOM is manipulated, the browser has to repaint and reflow content which can be extremely costly. This is no more evident than in a long loop, whether it be a standard for() loop, while() loop, or jQuery $.each() loop.\n\nIn this case, let\u2019s say we\u2019ve just received an array full of image URLs from a database or Ajax call or wherever, and we want to put all of those images in an unordered list. Commonly, you\u2019ll see code like this to pull this off:\n\nvar arr = [reallyLongArrayOfImageURLs]; \n $.each(arr, function(count, item) {\n var newImg = '';\n $('#imgList').append(newImg);\n });\n\nThere are a couple of problems with this. For one (which you should have already noticed if you\u2019ve read the earlier part of this article), we\u2019re making the $(\"#imgList\") selection once for each iteration of our loop. The other problem here is that each time the loop iterates, it\u2019s adding a new
to the DOM. Each of those insertions is going to be costly, and if our array is quite large then this could lead to a massive slowdown or even the dreaded \u2018A script is causing this page to run slowly\u2019 warning.\n\nvar arr = [reallyLongArrayOfImageURLs],\n tmp = ''; \n$.each(arr, function(count, item) {\n tmp += '
';\n});\n$('#imgList').append(tmp);\n\nAll we\u2019ve done here is create a tmp variable that each
is added to as it\u2019s created. Once our loop has finished iterating, that tmp variable will contain all of our list items in memory, and can be appended to our
all in one go. Browsers work much faster when working with objects in memory rather than on screen, so this is a much faster, more CPU-cycle-friendly method of building a list.\n\nWrapping up\n\nThese are far from being the only ways to make your jQuery code run better, but they are among the simplest ones to implement. Though each individual change may only make a few milliseconds of difference, it doesn\u2019t take long for those milliseconds to add up. Studies have shown that the human eye can discern delays of as few as 100ms, so simply making a few changes sprinkled throughout your code can very easily have a noticeable effect on how well your website or app performs. Do you have other jQuery optimization tips to share? Leave them in the comments and help make us all better.\n\nNow go forth and make awesome!", "year": "2011", "author": "Scott Kosman", "author_slug": "scottkosman", "published": "2011-12-13T00:00:00+00:00", "url": "https://24ways.org/2011/your-jquery-now-with-less-suck/", "topic": "code"}
{"rowid": 273, "title": "There\u2019s No Formula for Great Designs", "contents": "Before he combined them with fluid images and CSS3 media queries to coin responsive design, Ethan Marcotte described fluid grids \u2014 one of the most enjoyable parts of responsive design. Enjoyable that is, if you like working with math(s). But fluid grids aren\u2019t perfect and, unless we\u2019re careful when applying them, they can sometimes result in a design that feels disconnected.\n\nRecapping fluid grids\n\nIf you haven\u2019t read Ethan\u2019s Fluid Grids, now would be a good time to do that. It centres around a simple formula for converting pixel widths to percentages:\n\n(target \u00f7 context) \u00d7 100 = result\n\nHow does that work in practice? Well, take that Fireworks or Photoshop comp you\u2019re working on (I call them static design visuals, or just visuals.) Of course, everything on that visual \u2014 column divisions, inline images, navigation elements, everything \u2014 is measured in pixels. Now:\n\n\n\tPick something in the visual and measure its width. That\u2019s our target.\n\tTake that target measurement and divide it by the width of its parent (context).\n\tMultiply what you\u2019ve got by 100 (shift two decimal places).\n\tWhat you\u2019re left with is a percentage width to drop into your style sheets.\n\n\nFor example, divide this 300px wide sidebar division by its 948px parent and then multiply by 100: your original 300px is neatly converted to 31.646%.\n\n.content-sub {\nwidth : 31.646%; /* 300px \u00f7 948px = .31646 */ }\n\nThat formula makes it surprisingly simple for even die-hard fixed width aficionados to convert their visuals to percentage-based, fluid layouts.\n\nIt\u2019s a handy formula for those who still design using static visuals, and downright essential for those situations where one person in an organization designs in Fireworks or Photoshop and another develops with CSS. Why?\n\nWell, although I think that designing in a browser makes the best sense \u2014 particularly when designing for multiple devices \u2014 I\u2019ll wager most designers still make visuals in Fireworks or Photoshop and use them for demonstrations and get feedback and sign-off. That\u2019s OK. If you haven\u2019t made the transition to content-out designing in a browser yet, the fluid grids formula helps you carry on pushing pixels a while longer.\n\nYou can carry on moving pixel width measurements from your visuals to your style sheets, too, in the same way you always have. You can be precise to the pixel and even apply a grid image as a CSS background to help you keep everything lined up perfectly.\n\nOnce you\u2019re done, and the fixed width layout in the browser matches your visual, loop back through your style sheets and convert those pixels to percentages using the fluid grids formula. With very little extra work, you\u2019ll have a fluid implementation of your fixed width layout.\n\nThe fluid grids formula is simple and incredibly effective, but not long after I started working responsively I realized that the formula shouldn\u2019t (always) be a one-fix, set-and-forget calculation. I noticed that unless we compensate for problems it sometimes creates, the result can be a disconnected design.\n\nStaying connected\n\nGood design relies on connectedness, a feeling of natural balance between elements and the grid they\u2019re placed on. Give an element greater prominence or position in a visual hierarchy and you can fundamentally alter the balance and sometimes the meaning of a design.\n\nDifferent from a browser\u2019s page zooming feature \u2014 where images, text and overall layout change size by the same ratio \u2014 fluid grids flex a layout in response to a window or device width. Columns expand and contract, and within them fluid media (images and videos) can also change size. This can be one of the most impressive demonstrations of responsive design.\n\nBut not every element within a fluid grid can change size along with the window or device width. For example, type size and leading won\u2019t change along with a column\u2019s width.\n\nWhen columns and elements within them change width, all too easily a visual hierarchy can be broken and along with it the relationship between element sizes and the outer window or viewport. This can happen quickly if you make just one set of fluid grid calculations and use those percentages across every screen width, from smartphones through tablets and up to large desktops.\n\nThe answer? Make several sets of fluid grids calculations, each one at a significant window or device width breakpoint. Then apply those new percentages, when needed, to help keep elements in proportion and maintain balance and connectedness. Here\u2019s how I work.\n\nAvoiding disconnection\n\nI\u2019ve never been entirely happy with grid frameworks such as the 960 Grid System, so I start almost every project by creating a custom grid to inform my layout decisions. Here\u2019s a plain version of a grid from a recent project that I\u2019ll use as an illustration.\n\nThis project\u2019s grid comprises 84px columns and 24px gutters. This creates an odd number of columns at common tablet and desktop widths, and allows for 300px fixed width assets \u2014 useful when I need to fit advertising into a desktop layout\u2019s sidebar.\n\n Showing common advertising sizes (Larger image)\n\nFor this project I chose three 320 and Up breakpoints above 320px and, after placing as many columns as would fit those breakpoint widths, I derived three content widths:\n\n\n\t\t\n\t\t\tBreakpoint \n\t\t\tColumns \n\t\t\tContent width \n\t\t\n\t\t\n\t\t\t768px \n\t\t\t 7 \n\t\t\t 732px \n\t\t\n\t\t\n\t\t\t992px \n\t\t\t 9 \n\t\t\t 948px \n\t\t\n\t\t\n\t\t\t1,382px \n\t\t\t 13 \n\t\t\t 1,380px \n\t\t\n\n\nHere\u2019s my grid again, this time with pixel measurements and breakpoints overlaid.\n\n Showing pixel measurements and breakpoints (Larger image)\n\nNow cast your mind back to the fluid grids calculation I made earlier. I divided a 300px element by 948px and arrived at 31.646%. For some elements it\u2019s possible to use that percentage across all screen widths, but others will feel too small in relation to a narrower 768px and too large inside 1,380px.\n\nTo help maintain connectedness, I make a set of fluid grids calculations based on each of the content widths I established earlier. Now I can shift an element\u2019s percentage width up or down when I switch to a new breakpoint and content width. For example:\n\n\n\t300px is 40.984% of 732px\n\t300px is 31.646% of 948px\n\t300px is 21.739% of 1,380px\n\n\nI\u2019ll add all those fluid grid percentages to my grid image and save it for quick reference.\n\n Showing percentages at all breakpoints (Larger image)\n\nThen I can apply those different percentage widths to elements at each breakpoint using CSS3 media queries. For example, that sidebar division again:\n\n/* 732px, 7-column width */\n\n@media only screen and (min-width: 768px) {\n\n .content-sub {\n width : 40.983%; /* 300px \u00f7 732px = .40983 */ }\n\n}\n\n/* 948px, 9-column width */\n@media only screen and (min-width: 992px) {\n\n .content-sub {\n width : 31.645%; /* 300px \u00f7 948px = .31645 */ }\n\n}\n\n/* 1380px, 13-column width */\n@media only screen and (min-width: 1382px) {\n\n .content-sub {\n width : 21.739%; /* 300px \u00f7 1380px = .21739 */ }\n\n}\n\nThe number of changes you make to a layout at different breakpoints will, of course, depend on the specifics of the design you\u2019re working on. Yes, this is additional work, but the result will be a layout that feels better balanced and within which elements remain in harmony with each other while they respond to new screen or device widths.\n\nPutting the design in responsive web design\n\nUntil now, many of the conversations around responsive web design have been about aspects of technical implementation, rather than design. I believe we\u2019re only beginning to understand what\u2019s involved in designing responsively. In future, we\u2019ll likely be making design decisions not just about proportions but also about responsive typography. We\u2019ll also need to learn how to adapt our designs to device characteristics such as touch targets and more.\n\nSometimes we\u2019ll make decisions to improve function, other times because they make a design \u2018feel\u2019 right. You\u2019ll know when you\u2019ve made a right decision. You\u2019ll feel it.\n\nAfter all, there really is no formula for making great designs.", "year": "2011", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2011-12-23T00:00:00+00:00", "url": "https://24ways.org/2011/theres-no-formula-for-great-designs/", "topic": "ux"}
{"rowid": 267, "title": "Taming Complexity", "contents": "I\u2019m going to step into my UX trousers for this one. I wouldn\u2019t usually wear them in public, but it\u2019s Christmas, so there\u2019s nothing wrong with looking silly.\n\nAnyway, to business. Wherever I roam, I hear the familiar call for simplicity and the denouncement of complexity. I read often that the simpler something is, the more usable it will be. We understand that simple is hard to achieve, but we push for it nonetheless, convinced it will make what we build easier to use. Simple is better, right?\n\nWell, I\u2019ll try to explore that. Much of what follows will not be revelatory to some but, like all good lessons, I think this serves as a welcome reminder that as we live in a complex world it\u2019s OK to sometimes reflect that complexity in the products we build.\n\nMyths and legends\n\nLess is more, we\u2019ve been told, ever since master of poetic verse Robert Browning used the phrase in 1855. Well, I\u2019ve conducted some research, and it appears he knew nothing of web design. Neither did modernist architect Ludwig Mies van der Rohe, a later pedlar of this worthy yet contradictory notion. Broad is narrow. Tall is short. Eggs are chips. See: anyone can come up with this stuff.\n\nTo paraphrase Einstein, simple doesn\u2019t have to be simpler. In other words, simple doesn\u2019t dictate that we remove the complexity. Complex doesn\u2019t have to be confusing; it can be beautiful and elegant. On the web, complex can be necessary and powerful. A website that simplifies the lives of its users by offering them everything they need in one site or screen is powerful. For some, the greater the density of information, the more useful the site.\n\nIn our decision-making process, principles such as Occam\u2019s razor\u2019s_razor (in a nutshell: simple is better than complex) are useful, but simple is for the user to determine through their initial impression and subsequent engagement. What appears simple to me or you might appear very complex to someone else, based on their own mental model or needs. We can aim to deliver simple, but they\u2019ll be the judge.\n\nAs a designer, developer, content alchemist, user experience discombobulator, or whatever you call yourself, you\u2019re often wrestling with a wealth of material, a huge number of features, and numerous objectives. In many cases, much of that stuff is extraneous, and goes in the dustbin. However, it can be just as likely that there\u2019s a truckload of suggested features and content because it all needs to be there. Don\u2019t be afraid of that weight.\n\nIn the right hands, less can indeed mean more, but it\u2019s just as likely that less can very often lead to, well\u2026 less.\n\nComplexity is powerful\n\nSimple is the ability to offer a powerful experience without overwhelming the audience or inducing information anxiety. Giving them everything they need, without having them ferret off all over a site to get things done, is important.\n\nIt\u2019s useful to ask throughout a site\u2019s lifespan, \u201cdoes the user have everything they need?\u201d It\u2019s so easy to let our designer egos get in the way and chop stuff out, reduce down to only the things we want to see. That benefits us in the short term, but compromises the audience long-term.\n\nThe trick is not to be afraid of complexity in itself, but to avoid creating the perception of complexity. Give a user a flight simulator and they\u2019ll crash the plane or jump out. Give them everything they need and more, but make it feel simple, and you\u2019re building a relationship, empowering people.\n\nThis can be achieved carefully with what some call gradual engagement, and often the sensible thing might be to unleash complexity in carefully orchestrated phases, initially setting manageable levels of engagement and interaction, gradually increasing the inherent power of the product and fostering an empowered community.\n\nThe design aesthetic\n\nHere\u2019s a familiar scenario: the client or project lead gets overexcited and skips most of the important decision-making, instead barrelling straight into a bout of creative direction Tourette\u2019s. Visually, the design needs to be minimal, white, crisp, full of white space, have big buttons, and quite likely be \u201cclean\u201d. Of course, we all like our websites to be clean as that\u2019s more hygienic.\n\nBut what do these words even mean, really? Early in a project they\u2019re abstract distractions, unnecessary constraints. This premature narrowing forces us to think much more about throwing stuff out rather than acknowledging that what we\u2019re building is complex, and many of the components perhaps necessary.\n\nSimple is not a formula. It cannot be achieved just by using a white background, by throwing things away, or by breathing a bellowsful of air in between every element and having it all float around in space. Simple is not a design treatment. Simple is hard. Simple requires deep investigation, a thorough understanding of every aspect of a project, in line with the needs and expectations of the audience.\n\nRecognizing this helps us empathize a little more with those most vocal of UX practitioners. They usually appreciate that our successes depend on a thorough understanding of the user\u2019s mental models and expected outcomes. I personally still consider UX people to be web designers like the rest of us (mainly to wind them up), but they\u2019re web designers that design every decision, and by putting the user experience at the heart of their process, they have a greater chance of finding simplicity in complexity. The visual design aesthetic \u2014 the fa\u00e7ade \u2014 is only a part of that.\n\nDivide and conquer\n\nI\u2019m currently working on an app that\u2019s complex in architecture, and complex in ambition. We\u2019ll be releasing in carefully orchestrated private phases, gradually introducing more complexity in line with the unavoidably complex nature of the objective, but my job is to design the whole, the complete system as it will be when it\u2019s out of beta and beyond.\n\nI\u2019ve noticed that I\u2019m not throwing much out; most of it needs to be there. Therefore, my responsibility is to consider interesting and appropriate methods of navigation and bring everything together logically.\n\nI\u2019m using things like smart defaults, graphical timelines and colour keys to make sense of the complexity, techniques that are sympathetic to the content. They act as familiar points of navigation and reference, yet are malleable enough to change subtly to remain relevant to the information they connect. It\u2019s really OK to have a lot of stuff, so long as we make each component work smartly.\n\nIt\u2019s a divide and conquer approach. By finding simplicity and logic in each content bucket, I\u2019ve made more sense of the whole, allowing me to create key layouts where most of the simplified buckets are collated and sometimes combined, providing everything the user needs and expects in the appropriate places.\n\nI\u2019m also making sure I don\u2019t reduce the app\u2019s power. I need to reflect the scale of opportunity, and provide access to or knowledge of the more advanced tools and features for everyone: a window into what they can do and how they can help. I know it\u2019s the minority who will be actively building the content, but the power is in providing those opportunities for all.\n\nMuch of this will be familiar to the responsible practitioners who build websites for government, local authorities, utility companies, newspapers, magazines, banking, and we-sell-everything-ever-made online shops. Across the web, there are sites and tools that thrive on complexity.\n\nAlas, the majority of such sites have done little to make navigation intuitive, or empower audiences. Where we can make a difference is by striving to make our UIs feel simple, look wonderful, not intimidating \u2014 even if they\u2019re mind-meltingly complex behind that fa\u00e7ade.\n\nEmbrace, empathize and tame\n\nSo, there are loads of ways to exploit complexity, and make it seem simple. I\u2019ve hinted at some methods above, and we\u2019ve already looked at gradual engagement as a way to make sense of complexity, so that\u2019s a big thumbs-up for a release cycle that increases audience power.\n\nPrior to each and every release, it\u2019s also useful to rest on the finished thing for a while and use it yourself, even if you\u2019re itching to release. \u2018Ready\u2019 often isn\u2019t, and \u2018finished\u2019 never is, and the more time you spend browsing around the sites you build, the more you learn what to question, where to add, or subtract. It\u2019s definitely worth building in some contingency time for sitting on your work, so to speak.\n\nOne thing I always do is squint at my layouts. By squinting, I get a sort of abstract idea of the overall composition, and general feel for the thing. It makes my face look stupid, but helps me see how various buckets fit together, and how simple or complex the site feels overall.\n\nI mentioned the need to put our design egos to one side and not throw out anything useful, and I think that\u2019s vital. I\u2019m a big believer in economy, reduction, and removing the extraneous, but I\u2019m usually referring to decoration, bells and whistles, and fluff. I wouldn\u2019t ever advocate the complete removal of powerful content from a project roadmap.\n\nAbove all, don\u2019t fear complexity. Embrace and tame it. Work hard to empathize with audience needs, and you can create elegant, playful, risky, surprising, emotive, delightful, and ultimately simple things.", "year": "2011", "author": "Simon Collison", "author_slug": "simoncollison", "published": "2011-12-21T00:00:00+00:00", "url": "https://24ways.org/2011/taming-complexity/", "topic": "ux"}
{"rowid": 284, "title": "Subliminal User Experience", "contents": "The term \u2018user experience\u2019 is often used vaguely to quantify common elements of the interaction design process: wireframing, sitemapping and so on. UX undoubtedly involves all of these principles to some degree, but there really is a lot more to it than that.\n\nGood UX is characterized by providing the user with constant feedback as they step through your interface. It means thinking about and providing fallbacks and error resolutions in even the rarest of scenarios. It\u2019s about omitting clutter to make way for the necessary, and using the most fundamental of design tools to influence a user\u2019s path. It means making no assumptions, designing right down to the most distinct details and going one step further every single time. In many cases, good UX is completely subliminal.\n\nThere are simple tools and subtleties we can build into our products to enhance the overall experience but, in order to do so, we really have to step beyond where we usually draw the line on what to design.\n\nThe purpose of this article is not to provide technical how-tos, as the functionality is, in most cases, quite simple and could be implemented in a myriad of ways. Rather, it will present a handful of ideas for enhancing the experience of an interface at a deeper level of design without relying on the container.\n\nWe\u2019ll cover three elements that should get you thinking in the right mindset:\n\n\n\tprogress activity and post-active states\n\tpseudo-class preloading\n\tbuttons and their (mis)behaviour\n\n\nProgress activity and the post-active state\n\nWe\u2019ve long established that we can\u2019t control the devices our products are viewed on, which browser they\u2019ll run in or what connection speed will be used to access them. We accept this all as factual, so why is it so often left to the browser to provide feedback to the user when an event is triggered or an error encountered? The browser isn\u2019t part of the interface \u2014 it\u2019s merely a container. A simple, visual recognition of your users\u2019 activity may be all it takes to make or break the product.\n\nLet\u2019s begin with a commonly overlooked case: progress activity.\n\nA user moves their cursor over a hyperlink or button, which is clearly defined as one by the visual language of your content. Upon doing so, they trigger the :hover state to confirm this element is indeed interactive. So far, so good. What happens next is where it starts to fall apart: the user hits this link, presumably triggering an :active state, which is then returned to the normal state upon release. And then what?\n\n\n\nFrom this point on, your user is in limbo. The link has fallen back to either its regular or :visited state. You\u2019ve effectively abandoned them and are relying entirely on the browser they\u2019re using to communicate that something is happening. This poses quite a few problems:\n\n\n\tThe user may lose focus of what they were doing.\n\tThere is little consistency between progress indication in browsers.\n\tThe user may not even notice that their action has been acknowledged.\n\n\nHow many times have one or more of these events happened to you due to a lack of communication from the interface?\n\nThink about the differences between Safari and Chrome in this area \u2014 two browsers that, when compared to each other, are relatively similar in nature, though this basic feature differs in execution.\n\n\n\nLike all aspects of designing the user experience, there is no one true way to fix this problem, but we can introduce details that many users will unconsciously appreciate.\n\nConsider the basic loading indicator. It\u2019s nothing new \u2014 in fact, some would argue it\u2019s quite a clich\u00e9. However, whether using a spinning wheel or a progress bar, a gif or JavaScript, or something more sophisticated, these simple tools create an illusion of movement, progress and activity. Depending on the implementation, progress indication graphics can significantly increase a user\u2019s perception of the speed in which an event is taking place. Combine this with a cursor change and a lock over the element to prevent double-clicking or reloading, and your chances of keeping your user\u2019s valuable attention have significantly increased.\n\nDemo: Progress activity and the post-active state\n\nThis same logic applies to all aspects of defaulting in a browser, from micro-elements like this up to something as simple as a 404 page. The difference in a user\u2019s reaction to hitting the default Apache 404 and a hand-crafted, branded page are phenomenal and there are no prizes for guessing which one they\u2019re more likely to exit from.\n\nPseudo-class preloading\n\nAnother detail that it pays well to look after is the use and abuse of the :hover element and, more importantly, the content revealed by it. Chances are you\u2019re using the :hover pseudo-class somewhere in almost every screen you create. If content is being revealed on :hover and that content takes some time to load, there will inevitably be a delay the first time it is initiated. It appears tacky and half-finished when a tooltip or drop-down loads instantly, only to have its background or supporting elements follow through a second or two later. So, let\u2019s preload the elements we know we\u2019ll need.\n\nA very simple application of this would be to load each file into the default state of a visible element and offset them by a large number. This ensures our elements have loaded and are ready if and when they need to be displayed.\n\nelement {\n background: url(path/to/image.jpg) -9999em -9999em no-repeat;\n }\nelement .tooltip {\n display: none;\n }\nelement:hover .tooltip {\n display: block;\n background: url(path/to/image.jpg) 0 0;\n }\n\nBackground images are just one example. Of course, the same logic can apply to any form of revealed content. Using a sprite graphic can also be a clever \u2014 albeit tedious \u2014 method for achieving the same goal, so if you\u2019re using a sprite, preloading in this way may not be necessary\n\nThe differences between preloading and not can only be visualized properly with an actual demonstration.\n\nDemo: Preloading revealed content\n\nButtons and their (mis)behaviour\n\nAlmost all of the time, a button serves just one purpose: to be clicked (or tapped). When a button\u2019s pressed, therefore, if anything other than triggering the desired event occurs, a user naturally becomes frustrated. I often get funny looks when talking about this, but designing the details of a button is something I consider essential.\n\nIt goes without saying that a button should always visually recognise :hover and :active states. We can take that one step further and disable some actions that get in the way of pressing the button.\n\nIt\u2019s rare that a user would ever want to select and use the text on a button, so let\u2019s cleanly disable it:\n\nelement {\n -moz-user-select: -moz-none;\n -webkit-user-select: none;\n user-select: none;\n }\n\nIf the button is image-based or contains an image, we could also disable user dragging to make sure the image element stays locked to the button:\n\nelement {\n -moz-user-drag: -moz-none;\n -webkit-user-drag: none;\n user-drag: none;\n }\n\nDemo: A more usable button\n\nDisabling global features like this should be done with utmost caution as it\u2019s very easy to cross the line between enhancement and friction. Cases where this is acceptable are very rare, but it\u2019s a good trick to keep in mind nevertheless. Both Apple\u2019s iCloud and Metalab\u2019s Flow applications use these tools appropriately and to great extent.\n\nYou could argue that the visual feedback of having the text selected or image dragged when a user mis-hits the button is actually a positive effect, informing the user that their desired action did not work. However, covering for human error should be a designer\u2019s job, not that of our users. We can (almost) ensure it does work for them by accommodating for errors like this in most cases.\n\nFinal thoughts\n\nDesigning to this level of detail can seem obsessive, but as a designer and user of many interfaces and applications, I believe it can be the difference between a good user experience and a great one.\n\nThe samples you\u2019ve just seen are only a fraction of the detail we can design for. Keep in mind that the demonstrations, code and methods above outline just one way to do this. You may not agree with all of these processes or have the time and desire to consider them, but one fact remains: it\u2019s not the technology, or the way it\u2019s done that\u2019s important \u2014 it\u2019s the logic and the concept of designing everything.", "year": "2011", "author": "Chris Sealey", "author_slug": "chrissealey", "published": "2011-12-03T00:00:00+00:00", "url": "https://24ways.org/2011/subliminal-user-experience/", "topic": "ux"}
{"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": 281, "title": "Nine Things I've Learned", "contents": "I\u2019ve been a professional graphic designer for fourteen years and for just under four of those a professional web designer. Like most designers I\u2019ve learned a lot in my time, both from a design point of view and in business as freelance designer. A few of the things I\u2019ve learned stick out in my mind, so I thought I\u2019d share them with you. They\u2019re pretty random and in no particular order.\n\n1. Becoming the designer you want to be\n\nWhen I started out as a young graphic designer, I wanted to design posters and record sleeves, pretty much like every other young graphic designer. The problem is that the reality of the world means that when you get your first job you\u2019re designing the back of a paracetamol packet or something equally weird. I recently saw a tweet that went something like this: \u201cYou\u2019ll never become the designer you always dreamt of being by doing the work you never wanted to do\u201d. This is so true; to become the designer you want to be, you need to be designing the things you\u2019re passionate about designing. This probably this means working in the evenings and weekends for little or no money, but it\u2019s time well spent. Doing this will build up your portfolio with the work that really shows what you can do! Soon, someone will ask you to design something based on having seen this work. From this point, you\u2019re carving your own path in the direction of becoming the designer you always wanted to be.\n\n2. Compete on your own terms\n\nAs well as all being friends, we are also competitors. In order to win new work we need a selling point, preferably a unique selling point. Web design is a combination of design disciplines \u2013 user experience design, user interface Design, visual design, development, and so on. Some companies will sell themselves as UX specialists, which is fine, but everyone who designs a website from scratch does some sort of UX, so it\u2019s not really a unique selling point. Of course, some people do it better than others.\n\nOne area of web design that clients have a strong opinion on, and will judge you by, is visual design. It\u2019s an area in which it\u2019s definitely possible to have a unique selling point. Designing the visual aesthetic for a website is a combination of logical decision making and a certain amount of personal style. If you can create a unique visual style to your work, it can become a selling point that\u2019s unique to you.\n\n3. How much to charge and staying motivated\n\nWhen you\u2019re a freelance designer one of the hardest things to do is put a price on your work and skills. Finding the right amount to charge is a fine balance between supplying value to your customer and also charging enough to stay motivated to do a great job. It\u2019s always tempting to offer a low price to win work, but it\u2019s often not the best approach: not just for yourself but for the client as well.\n\nA client once asked me if I could reduce my fee by \u00a31,000 and still be motivated enough to do a good job. In this case the answer was yes, but it was the question that resonated with me. I realized I could use this as a gauge to help me price projects. Before I send out a quote I now always ask myself the question \u201cIs the amount I\u2019ve quoted enough to make me feel motivated to do my best on this project?\u201d I never send out a quote unless the answer is yes. In my mind there\u2019s no point in doing any project half-heartedly, as every project is an opportunity to build your reputation and expand your portfolio to show potential clients what you can do. Offering a client a good price but not being prepared to put everything you have into it, isn\u2019t value for money. \n\n4. Supplying the right design\n\nWhen I started out as a graphic designer it seemed to be the done thing to supply clients with a ton of options for their logo or brochure designs. In a talk given by Dan Rubin, he mentioned that this was a legacy of agencies competing with each other in a bid to create the illusion of offering more value for money. Over the years, I\u2019ve realized that offering more than one solution makes no sense. The reason a client comes to you as a designer is because you\u2019re the person than can get it right. If I were to supply three options, I\u2019d be knowingly offering my client at least two options that I didn\u2019t think worked.\n\nTo this day I still get asked how many homepage design options I\u2019ll supply for the quoted amount. The answer is one. Of course, I\u2019m more than happy to iterate upon the design to fine-tune it and, on the odd occasion, I do revisit a design concept if I just didn\u2019t nail the design first time around. Your time is much better spent refining the right design option than rushing out three substandard designs in the same amount of time.\n\n5. Colour is key\n\nThere are many contributing factors that go into making a good visual design, but one of the simplest ways to do this is through the use of colour. The colour palette used in a design can have such a profound effect on a visual design that it almost feels like you\u2019re cheating. It\u2019s easy to add more and more subtle shades of colour to add a sense of sophistication and complexity to a design, but it dilutes the overall visual impact. When I design, I almost have a rule that only allows me to use a very limited colour palette. I don\u2019t always stick to it, but it\u2019s always in mind and something I\u2019m constantly reviewing through my design process.\n\n6. Creative thinking is central to good or boundary-pushing web design\n\nWhen we think of creativity in web design we often link this to the visual design, as there is an obvious opportunity to be creative in this area if the brief allows it. Something that I\u2019ve learnt in my time as a web designer is that there\u2019s a massive need for creative thinking in the more technical aspects of web design. The tools we use for building websites are there to be manipulated and used in creative ways to design exciting and engaging user experiences. Great developers are constantly using their creativity to push the boundaries of what can be done with CSS, jQuery and JavaScript. \n\nBeing creative and creative thinking are things we should embrace as an industry and they are qualities that can be found in anyone, whether they be a visual designer or Rails developer.\n\n7. Creative block: don\u2019t be afraid to get things wrong\n\nCreative block can be a killer when designing. It\u2019s often applied to visual design, which is more subjective. I suffer from creative block on a regular basis. It\u2019s hugely frustrating and can screw up your schedule. Having thought about what creative block actually is, I\u2019ve come to the conclusion that it\u2019s actually more of a lack of direction than a lack of ideas. You have ideas and solutions in mind but don\u2019t feel committed to any of them. You\u2019re scared that whatever direction you take, it\u2019ll turn out to be wrong. I\u2019ve found that the best remedy for this is to work through this barrier. It\u2019s a bit like designing with a blindfold on \u2013 you don\u2019t really know where you\u2019re going. If you stick to your guns and keep pressing forward I find that, nine times out of ten, this process leads to a solution. As the page begins to fill, the direction you\u2019re looking for slowly begins to take shape.\n\n8. You get better at designing by designing\n\nI often get emails asking me what books someone can read to help them become a better designer. There are a lot of good books on subjects like HTML5, CSS, responsive web design and the like, that will really help improve anyone\u2019s web design skills. But, when it comes to visual design, the best way to get better is to design as much as possible. You can\u2019t follow instructions for these things because design isn\u2019t following instructions. A large part of web design is definitely applying a set of widely held conventions, but there\u2019s another part to it that is invention and the only way to get better at this is to do it as much as possible.\n\n9. Self-belief is overrated\n\nThroughout our lives we\u2019re told to have self-belief. Self-belief and confidence in what we do, whatever that may be. The problem is that some people find it easier than others to believe in themselves. I\u2019ve spent years trying to convince myself to believe in what I do but have always found it difficult to have complete confidence in my design skills. Self-doubt always creeps in.\n\nI\u2019ve realized that it\u2019s ok to doubt myself and I think it might even be a good thing! I\u2019ve realized that it\u2019s my self-doubt that propels me forward and makes me work harder to achieve the best results. The reason I\u2019m sharing this is because I know I\u2019m not the only designer that feels this way. You can spend a lot of time fighting self-doubt only to discover that it\u2019s your body\u2019s natural mechanism to help you do the best job possible.", "year": "2011", "author": "Mike Kus", "author_slug": "mikekus", "published": "2011-12-11T00:00:00+00:00", "url": "https://24ways.org/2011/nine-things-ive-learned/", "topic": "business"}
{"rowid": 278, "title": "Going Both Ways", "contents": "It\u2019s that time of the year again: Santa is getting ready to travel the world. Up until now, girls and boys from all over have sent in letters asking for what they want. I hope that Santa and his elves have\u2014unlike me\u2014learned more than just English.\n\nOn the Internet, those girls and boys want to participate in sharing their stories and videos of opening presents and of being with friends and family. Ah, yes, the wonders of user generated content. But more than that, people also want to be able to use sites in the language they know.\n\nWhile you and I might expect the text to read from left to right, not all languages do. Some go from right to left, such as Arabic and Hebrew. (Some also go from top to bottom, but for now, let\u2019s just worry about those first two directions!)\n\nIf we were building a site for girls and boys to send their letters to Santa, we need to consider having the interface in the language and direction that they prefer. On the elves\u2019 side, they may be viewing the site in one direction but reading the user generated content in the other direction. We need to build a site that supports bidirectional (or bidi) text.\n\nLet\u2019s take a look at some things to be aware of when it comes to building bidi interfaces.\n\nSetting the direction of the interface\n\nRight off the bat, we need to tell the browser what direction the text should be going in. To do this, we add the dir attribute to an HTML element and set it to either LTR (for left to right) or RTL (for right to left).\n\n\n\nYou can add the dir attribute to any element and it will set or change the direction for the content within that element. \n\n\n Here is English Content.\n
\u0627\u0644\u0645\u0648\u0636\u0648\u0639
\n\n\nYou can also set the direction via CSS.\n\n.rtl {\n direction: rtl;\n }\n\nIt\u2019s generally recommended that you don\u2019t use CSS to set the direction of the text. Text direction is an important part of the content that should be retained even in environments where the CSS may not be available or fails to load.\n\nHow things change with the direction attribute\n\nJust adding the dir attribute tells the browser to render the content within it differently. \n\n\n\nThe text aligns to the right of the page and, interestingly, punctuation appears at the left of the sentence. (We\u2019ll get to that in a little bit.) \n\nScrollbars in most browsers will appear on the left instead of the right. Webkit is the notable exception here which always shows the scrollbar on the right, no matter what the text direction is. Avoid having a design that has an expectation that the scrollbar will be in a specific place (and a specific size).\n\nChanging the order of text mid-way\n\nAs we saw in that previous example, the punctuation appeared at the beginning of the sentence instead of the end, even though the text was English. At Yahoo!, we have an interesting dilemma where the company name has punctuation in it. Therefore, when the name appears in the middle of (for example) Arabic text, the exclamation mark appears at the beginning of the word instead of the end.\n\n\n\nThere are two ways in which this problem can be solved:\n\n1. Use HTML around the left-to-right content, or\n\nTo solve the problem of the Yahoo! name in the midst of Arabic text, we can wrap a span around it and change the direction on that element.\n\n\n\n2. Use a text direction mark in the content.\n\nUnicode has two marks, U+200E and U+200F, that tell the browser that the text is in a particular direction. Placing this right after the punctuation will correct the placement.\n\nUsing the HTML entity:\nYahoo!\u200e\n\nTables\n\nThankfully, the cells of a data table also get reordered from right to left. Equally as nice, if you\u2019re using display:table, the content will still get reordered.\n\n\n\nCSS\n\nSo far, we\u2019ve seen that the dir attribute does a pretty decent job of getting content flowing in the direction that we need it. Unfortunately, there are huge swaths of design that is handled by CSS that the handy dir attribute has zero effect over.\n\nMany properties, like float or absolute positioning with left and right values, are unaffected and must be handled manually. Elements that were floated left must now by floated right. Left margins and paddings must now move to the right and the right margins and paddings must now move to the left.\n\nSince the browser won\u2019t handle this for us, we have a couple approaches that we can use:\n\nCSS Only\n\nWe can take advantage of the attribute selector to target CSS to apply in one direction or another.\n\n[dir=ltr] .module {\n\tfloat: left;\n\tmargin: 0 0 0 20px;\n}\n\n[dir=rtl] .module {\n\tfloat: right;\n\tmargin: 0 20px 0 0;\n}\n\nAs you can see from this example, both of the properties have been modified for the flipped interface. If your interface is rather complicated, you will have to create a lot of duplicate rules to have the site looking good in both directions while serving up a single stylesheet.\n\nCSSJanus\n\nGoogle has a tool called CSSJanus. It\u2019s a Python script that runs over the LTR versions of your CSS files and generates RTL versions. For the RTL version of the site, just serve up those CSS files instead of the LTR versions.\n\nThe script looks for keywords and value combinations and automatically swaps them so you don\u2019t have to. \n\nAt Yahoo!, CSSJanus was a huge help in speeding up our development of a bidi interface. We\u2019ve also made a number of improvements to the script to better handle border radius, background positioning, and gradients. We will be pushing those changes back into the CSSJanus project. \n\n\n\nBackground Images\n\nBackground images, especially for things like CSS sprites, also raise an interesting dilemma. Background images are positioned relative to the left of the element. In a flipped interface, however, we need to position it relative to the right. An icon that would be to the left of some text will now need to appear on the right.\n\n\n\nIf the x position of the background is percentage-based, then it\u2019s fairly easy to swap the values. 0 becomes 100%, 10% becomes 90% and so on. If the x position is pixel-based, then we\u2019re in a bit of a pickle. There\u2019s no way to say that the image should be a certain number of pixels from the right.\n\nTherefore, you\u2019ll need to ensure that any background image that needs to be swapped should be percentage-based. (99.9% of the the time, the background position will need to be 0 so that it can be changed to 100% for RTL.)\n\nIf you\u2019re taking an existing implementation, background positioning will likely be the biggest hurdle you\u2019ll have to overcome in swapping your interface around. If you make sure your x position is always percentage-based from the beginning, you\u2019ll have a much smoother process ahead of you!\n\nFlipping Images\n\nThis is a more subtle point and one where you\u2019ll really want an expert with the region to weigh in on. In RTL interfaces, users may expect certain icons to also be flipped. Pencil icons that skew to the right in LTR interfaces might need to be swapped to skew to the left, instead. Chat bubbles that come from the left will need to come from the right.\n\nThe easiest way to handle this is to create new images. Name the LTR versions with -ltr in the name and name the RTL versions with -rtl in the name. CSSJanus will automatically rename all file references from -ltr to -rtl.\n\nThe Future\n\nThankfully, those within the W3C recognize that CSS should be more agnostic. As a result, they\u2019ve begun introducing new properties that allow the browser to manage the swapping from left to right for us.\n\nThe CSS3 specification for backgrounds allows for the background-position to be relative to other corners other than the top left by specifying keywords before each position.\n\nThis will position the background 5px from the bottom right of the element.\n\nbackground-position: right 5px bottom 5px;\n\nOpera 11.60 is currently the only browser that supports this syntax.\n\nFor margin and padding, we have margin-start and margin-end. In LTR interfaces, margin-start would be the same as margin-left and in RTL interfaces, margin-start would be the same as margin-right. \n\nFirefox and Webkit support these but with vendor prefixes right now:\n\n-webkit-margin-start: 20px;\n-moz-margin-start: 20px;\n\nIn the CSS3 Images working draft specification, there\u2019s an image() property that allows us to specify image fallbacks and whether those fallbacks are for LTR or RTL interfaces.\n\nbackground: image('sprite.png' ltr, 'sprite-rtl.png' rtl);\n\nUnfortunately, no browser supports this yet but it\u2019s nice to be able to dream of how much easier this will be in the future!\n\nHo Ho Ho\n\nHopefully, after all of this, you\u2019re full of cheer knowing that you\u2019re well on your way to creating interfaces that can go both ways!", "year": "2011", "author": "Jonathan Snook", "author_slug": "jonathansnook", "published": "2011-12-19T00:00:00+00:00", "url": "https://24ways.org/2011/going-both-ways/", "topic": "ux"}
{"rowid": 268, "title": "Getting the Most Out of Google Analytics", "contents": "Something a bit different for today\u2019s 24 ways article. For starters, I\u2019m not a designer or a developer. I\u2019m an evil man who sells things to people on the internet. Second, this article will likely be a little more nebulous than you\u2019re used to, since it covers quite a number of points in a relatively short space. \n\nThis isn\u2019t going to be the complete Google Analytics Conversion University IQ course compressed into a single article, obviously. What it will be, however, is a primer on setting up and using Google Analytics in real life, and a great deal of what I\u2019ve learned using Google Analytics nearly every working day for the past six (crikey!) years.\n\nAlso, to be clear, I\u2019ll be referencing new Google Analytics here; old Google Analytics is for loooosers (and those who want reliable e-commerce conversion data per site search term, natch).\n\nYou may have been running your Analytics account for several years now, dipping in and out, checking traffic levels, seeing what\u2019s popular\u2026 and that\u2019s about it. Google Analytics provides so much more than that, but the number of reports available can often intimidate users, and documentation and case studies on their use are minimal at best. \n\nLet\u2019s start! Setting up your Analytics profile\n\nBefore we plough on, I just want to run through a quick checklist that some basic settings have been enabled for your profile. If you haven\u2019t clicked it, click the big cog on the top-right of Google Analytics and we\u2019ll have a poke about.\n\n\n\tIf you have an e-commerce site, e-commerce tracking has been enabled\u2028\n\tIf your site has a search function, site search tracking has been enabled.\n\tQuery string parameters that you do not want tracked as separate pages have been excluded (for example, any parameters needed for your platform to function, otherwise you\u2019ll get multiple entries for the same page appearing in your reports)\n\tFilters have been enabled on your main profile to exclude your office IP address and any IPs of people who frequently access the site for work purposes. In decent numbers they tend to throw data off a tad.\u2028\n\tYou may also find the need to set up multiple profiles prefiltered for specific audience segments. For example, at Lovehoney we have seventeen separate profiles that allow me quick access to certain countries, devices and traffic sources without having to segment first. You\u2019ll also find load time for any complex reports much improved. Use the same filter screen as above to set up a series of profiles that only include, say, mobile visits, or UK visitors, so you can quickly analyse important segments.\n\n\nMatt, what\u2019s a segment?\n\nA segment is a subsection of your visitor base, which you define and then call on in reports to see specific data for that subsection. For example, in this report I\u2019ve defined two segments, the first for IE6 users and the second for IE7.\n\n\n\nSegments are easily created by clicking the Advanced Segments tabs at the top of any report and clicking +New Custom Segment.\n\n\n\nWhat does your site do?\n\nUnderstanding the goals of your site is an oft-covered topic, but it\u2019s necessary not just to form a better understand of your business and prioritize your time. Understanding what you wish visitors to do on your site translates well into a goal-driven analytics package like Google Analytics. \n\nEvery site exists essentially to sell something, either financially through e-commerce, or to sell an idea or impart information, get people to download a CV or enquire about service, or to sell space on that website to advertisers. If the site did not provide a positive benefit to its owners, it would not have a reason for being. \n\nOnce you have understood the reason why you have a site, you can map that reason on to one of the three goal types Google Analytics provides. \n\nE-commerce \n\nThis conversion type registers transactions as part of a sales process which requires a monetary value, what products have been bought, an SKU (stock keeping unit), affiliation (if you\u2019re then attributing the sale to a third party or franchise) and so on.\n\nThe benefit of e-commerce tracking is not only assigning non-arbitrary monetary value to behaviour of visitors on your site, as well as being able to see ancillary costs such as shipping, but seeing product-level information, like which products are preferred from various channels, popular categories, and so on.\n\n\n\nHowever, I find the e-commerce tracking options also useful for non-e-commerce sites. For example, if you\u2019re offering downloads or subscriptions and having an email address or user\u2019s details is worth something to you, you can set up e-commerce tracking to understand how much value your site is bringing. For example, an email address might be worth 20p to you, but if it also includes a name it\u2019s worth 50p. A contact telephone number is worth \u00a32, and so on.\n\nPage goals\n\nPage goals, unsurprisingly, track a visit to a page (often with a sequence of pages leading up to that page). This is what\u2019s referred to as a goal funnel, and is generally used to track how visitors behave in a multistep checkout. \n\n\n\nInterestingly, the page doesn\u2019t have to actually exist. For example, if you have a single page checkout, you can register virtual page views using trackPageview() when a visitor clicks into a particular section of the checkout or other form. If your site is geared towards getting someone to a particular page, but where there isn\u2019t a transaction (for example, a subscription page) this is for you.\n\nThere are also behavioural goals, such as time on site and number of pages viewed, which are geared towards sites that make money from advertising.\n\nBut, going back to the page goals, these can be abstracted using regular expressions, meaning that you can define a funnel based on page type rather than having to set individual folders.\n\n\n\nIn this example, I\u2019ve created regexes for the main page types on my site, so I can create a wide funnel that captures visitors from where they enter through to checkout.\n\nEvents\n\nEvent tracking registers a predefined event, such as playing a video, or some interaction that can trigger JavaScript, such as a Tweet This button. Events can then be triggered using the trackEvent() call. If you want someone to complete watching a video, you would code your player to fire trackEvent() upon completion. \n\nWhile I don\u2019t use events as goals, I use events elsewhere to see how well a video play aids to conversion. This not only helps me justify the additional spend on creating video content, but also quickly highlights which videos are underperforming as sales tools.\n\n\n\nWhat a visitor can tell you\n\n\u2028Now you have some proper goals set up, we can start to see how changes in content (on-site and external) affect those goals. \n\nUltimately, when a visitor comes to your site, they bring information with them:\n\n\n\twhere they came from (a search engine \u2013 including: keyword searched for; a referral; direct; affiliate; or ad campaign)\n\tdemographics (country; whether they\u2019re new or returning, within thirty days)\n\ttechnical information (browser; screen size; device; bandwidth)\n\tsite-specific information (landing page; next click; previous values assigned to them as custom variables*)\n\n\n * A note about custom variables. There\u2019s no hope in hell that I can cover custom variables in this article. Go research them. Custom variables are the single best way to hack Google Analytics and bend it to your will. Custom variables allow you to record anything you want about a visitor, which that visitor will then carry around with them between visits. It\u2019s also great for plugging other services into Google Analytics (as shown by the marvelous way Visual Website Optimizer allows you to track and segment tests within the GA interface). Just make sure not to breach the terms of service, eh?\n\nCSI your website\n\nPolice procedural TV shows are all the same: the investigators are called to a crime and come across a clue; there\u2019s then an autopsy; new evidence leads them to a new location; they find a new clue; they put two and two together; they solve the mystery.\n\nThis is your life now. Exciting!\n\nSo, now you\u2019re gathering a wealth of information about what sort of people visit your site, what they do when they\u2019re there, and what eventually gets them to drive value to you. It\u2019s now your job to investigate all these little clues to see which types of people drive the most value, and what you can change to improve it.\n\nMaybe not that exciting.\n\nHowever, Google Analytics comes pre-armed with extensive reports for you to delve into. As an e-commerce guy (as opposed to a page goal guy) my day pretty much follows the pattern below.\n\n\n\tLook at e-commerce conversion rate by traffic source compared to the same day in the previous week and previous month. As ours is an e-commerce site, we have weekly and monthly trends. A big spike on Sundays and Mondays, and payday towards the end of the month is always good; on the third week of a month there tends to be a lull. Spend time letting your Google Analytics data brew, understand your own trends and patterns, and you\u2019ll start to get a feel for when something isn\u2019t quite right.\n\t\n\t\tTraffic Sources \u2192 Sources \u2192 All Traffic\n\t\n\tLook at the conversion rate by landing page for any traffic source that feels significantly different to what\u2019s expected. Check bounce rates, drill down to likely landing pages and check search keyword or referral site to see if it\u2019s a particular subset of visitor. You can do this by clicking Secondary Dimension and choosing Keyword or Source. If it\u2019s direct, choose Visitor Type to break down by new or returning visitor.\n\t\n\t\tContent \u2192 Site Content \u2192 Landing Pages\n\t\n\tI then tend to flip into Content Drilldown to see what the next clicks were from those landing pages, and whether they changed significantly to the date I\u2019m comparing with. If they have, that\u2019s usually an indicator of changed content (or its relevancy). Remember, if a bunch of people have found their way to your page via a method you\u2019re not expecting (such as a mention on a Spanish radio station \u2013 this actually happened to me once), while the content hasn\u2019t changed, the relevancy of it to the audience may have.\n\t\n\t\tContent \u2192 Site Content \u2192 Content Drilldown\n\t\n\tOnce I have an idea of what content was consumed, and whether it was relevant to the user, I then look at the visitor specifics, such as browser or demographic data, to see again whether the change was limited to a specific subset. Site speed, for example, is normally a good factor towards bounce rate, so compare that with previous data as well.\n\n\nNow, to be investigating at this level you still need a serious amount of data, in order to tell what\u2019s a significant change or not. If you\u2019re struggling with a small number of visitors, you might find reporting on a weekly or fortnightly basis more appropriate. \n\nHowever, once you\u2019ve looked into the basics of why changes happen to the value of your site, you\u2019ll soon find yourself limited by the reports offered in Standard Reporting. So, it\u2019s time to build your own. Hooray!\n\nCustom reporting\n\nGoogle Analytics provides the tools to build reports specific to the types of investigations you frequently perform. \n\n\n\nWelcome to my world.\n\nCustom reports are quite simple to build: first, you determine the metric you want the report to cover (number of visitors, bounce rate, conversion rate, and so on), then choose a set of dimensions that you\u2019d like to segment the report by (say, the source of the traffic, and whether they were new or returning users). You can filter the report, including or excluding particular dimension values, and you can assign the report to any of the profiles you created earlier. \n\nIn the example below, I\u2019ve created a report that shows me visits and conversion rate for any Google traffic that landed directly only on a product page. I can then drill down on each product page to see the complete phrases use to search. I can use this information in two ways:\n\n\n\tI can see which products aren\u2019t converting, which shows me where I need to work harder on merchandising.\n\tI can give this information to my content team, showing them the actual phrases visitors used to reach our product content, helping them write better targeted product descriptions.\n\n\n\n\nThe possibilities here are nearly endless, but here are a few examples of reports I find useful:\n\n\n\tNon-brand inbound search\nBy creating a report that shows inbound search traffic which doesn\u2019t include your brand, you can see more clearly the behaviour of visitors most likely to be unfamiliar with your site and brand values, without having to rely on the clumsy new or returning demographic date.\n\tTraffic/conversion/sales by hour\nThis is pure stats porn, but actually more useful than real-time data. By seeing this data broken down at an hourly level, you can not only compare the current day to previous days, but also see the best performing times for email broadcasts and tweets.\n\tVisits, load time, conversion and sales by page and browser\nPage speed can often kill conversion rates, but it\u2019s difficult to prove the value of focusing on speed in monetary terms. Having this report to hand helps me drive Operation Greenbelt, our effort to get into the sub-1.5 second band in Google Webmaster Tools.\n\n\nUseful things you can\u2019t do in custom reporting\n\nIf you have a search function on your website, then Conversion Rate and Products Bought by Site Search Term is an incredibly useful report that allows you to measure the effectiveness of your site\u2019s search engine at returning products and content related to the search term used. By including the products actually bought by visitors who searched for each term, you can use this information to better searchandise these results, escalating high propensity and high value products to the top of the results.\n\nHowever, it\u2019s not possible to get this information out of new Google Analytics. \n\nTry it, select the following in the report builder:\n\n\n\tMetrics: total unique searches; e-commerce or goal conversion rate\n\tDimensions: search term; product\n\n\nYou\u2019ll see that the data returned is a little nonsensical, though a 2,000% conversion rate would be nice. However, you can get more accurate information using advanced segments. By creating individual segments to define users who have searched for a particular term, you can run the sales performance and product performance reports as normal. It\u2019s laborious, but it teaches a good lesson: data that seems inaccessible can normally be found another way!\n\nReporting infrastructure\n\nNow that you have a series of reports that you can refer to on a daily or weekly basis, it\u2019s time to put together a regular reporting infrastructure. \n\nEven if you\u2019re not reporting to someone, having a set of key performance indicators that you can use to see how your performance is improving over time allows you to set yourself business goals on a monthly and annual basis.\n\nFor my own reporting, I take some high-level metrics (such as visitors, conversion rate and average order value), and segment them by traffic source and, separately, landing page. These statistics I record weekly and report:\n\n\n\tcurrent week compared with previous week\n\tsame week previous year (if available)\n\t4 week average\n\t13 week average\n\t52 week average (if available)\n\n\nThis takes into account weekly, monthly, seasonal and annual trends, and gives you a much clearer view of your performance.\n\nGetting data in other ways\n\nIf you\u2019re using Google Analytics frequently, with any large site you\u2019ll come to a couple of conclusions:\n\n\n\tDoing any kind of practical comparative analysis is unwieldy.\n\tBoy, Google Analytics is slow!\n\n\nAs you work with bigger datasets and put together more complex queries, you\u2019ll see the loading graphic more than you\u2019ll see actual data. So when you reach that level, there are ways to completely bypass the Google Analytics interface altogether, and get data into your own spreadsheet application for manipulation.\n\nData Feed Query Explorer\n\nIf you just want to pull down some quick statistics but still use complex filters and exotic metric and dimension combinations, the Data Feed Query Explorer is the quickest way of doing so. Authenticate with your Google Analytics account, select a profile, and you can start selecting metrics and dimensions to be generated in a handy, selectable tabulated format.\n\nGoogle Analytics API\n\nIf you\u2019re feeling clever, you can bypass having to copy and paste data by pulling in directly into Excel, Google Docs or your own application using the Google Analytics API. There are several scripts and plugins available to do this. I use Automate Analytics Google Docs code (there\u2019s also a paid version that simplifies setup and creates some handy reports for you).\n\nNew shiny things\n\nWell, now that that\u2019s over, I can show you some cool stuff. Well, at least it\u2019s cool to me. Google Analytics is being constantly improved and new functionality is introduced nearly every month. Here are a couple of my favourites.\n\nMultichannel attribution\n\nNot every visitor converts on your site on the first visit. They may not even do so on the second visit, or third. If they convert on the fourth visit, but each time they visit they do so via a different channel (for example, Search PPC, Search Organic, Direct, Email), which channel do you attribute the conversion to? The last channel, or the first? Dilemma! \n\nGoogle now has a Multichannel Attribution report, available in the Conversion category, which shows how each channel assists in converting, the overlap between channels, and where in the process that channel was important. \n\n\n\nFor example, you may have analysed your blog traffic from Twitter and become disheartened that not many people were subscribing after visiting from Twitter links, but instead your high-value subscribers were coming from natural search. On the face of it, you\u2019d spend less time tweeting, but a multichannel report may tell you that visitors first arrived via a Twitter link and didn\u2019t subscribe, but then came back later after searching for your blog name on Google, after which they did. Don\u2019t pack Twitter in yet!\n\nVisitor and goal flow\n\nVisitor and goal flow are amazing reports that help you visualize the flow of traffic through your site and, ultimately, into your checkout funnel or similar goal path. Flow reports are perfect for understanding drop-off points in your process, as well as what the big draws are on each page. \n\n\n\nPreviously, if you wanted to visualize this data you had to set up several abstracted microgoals and chain them together in custom reports. Frankly, it was a pain in the arse and burned through your precious and limited goal allocation.\n\nVisitor flow bypasses all that and produces the report in an interactive flow diagram. While it doesn\u2019t show you the holy grail of conversion likelihood by each path, you can segment visitor flow so that you can see very specifically how different segments of your visitor base behave.\n\nGo play with it now!", "year": "2011", "author": "Matt Curry", "author_slug": "mattcurry", "published": "2011-12-18T00:00:00+00:00", "url": "https://24ways.org/2011/getting-the-most-out-of-google-analytics/", "topic": "business"}
{"rowid": 282, "title": "Front-end Style Guides", "contents": "We all know that feeling: some time after we launch a site, new designers and developers come in and make adjustments. They add styles that don\u2019t fit with the content, use typefaces that make us cringe, or chuck in bloated code. But if we didn\u2019t leave behind any documentation, we can\u2019t really blame them for messing up our hard work.\n\nTo counter this problem, graphic designers are often commissioned to produce style guides as part of a rebranding project. A style guide provides details such as how much white space should surround a logo, which typefaces and colours a brand uses, along with when and where it is appropriate to use them.\n\nDesign guidelines\n\nSome design guidelines focus on visual branding and identity. The UK National Health Service (NHS) refer to theirs as \u201cbrand guidelines\u201d. They help any designer create something such as a trustworthy leaflet for an NHS doctor\u2019s surgery. Similarly, Transport for London\u2019s \u201cdesign standards\u201d ensure the correct logos and typefaces are used in communications, and that they comply with the Disability Discrimination Act.\n\nSome guidelines go further, encompassing a whole experience, from the visual branding to the messaging, and the icon sets used. The BBC calls its guidelines a \u201cGlobal Experience Language\u201d or GEL. It\u2019s essential for maintaining coherence across multiple sites under the same BBC brand.\n\n\nThe BBC\u2019s Global Experience Language.\n\nDesign guidelines may be brief and loose to promote creativity, like Mozilla\u2019s \u201cbrand toolkit\u201d, or be precise and run to many pages to encourage greater conformity, such as Apple\u2019s \u201cHuman Interface Guidelines\u201d.\n\nWhatever name or form they\u2019re given, documenting reusable styles is invaluable when maintaining a brand identity over time, particularly when more than one person (who may not be a designer) is producing material.\n\nCode standards documents\n\nWe can make a similar argument for code. For example, in open source projects, where hundreds of developers are submitting code, it makes sense to set some standards. Drupal and Wordpress have written standards that make editing code less confusing for users, and more maintainable for contributors.\n\nEach community has nuances: Drupal requests that developers indent with two spaces, while Wordpress stipulates a tab. Whatever the rules, good code standards documents also explain why they make their recommendations.\n\nThe front-end developer\u2019s style guide\n\nDesign style guides and code standards documents have been a successful way of ensuring brand and code consistency, but in between the code and the design examples, web-based style guides are emerging. These are maintained by front-end developers, and are more dynamic than visual design guidelines, documenting every component and its code on the site in one place.\n\nHere are a few examples I\u2019ve seen in the wild:\n\nNatalie Downe\u2019s pattern portfolio\n\nNatalie created the pattern portfolio system while working at Clearleft. The phrase describes a single HTML page containing all the site\u2019s components and styles that can act as a deliverable.\n\n\nPattern portfolio by Natalie Downe for St Paul\u2019s School, kept up to date when new components are added. The entire page is about four times the length shown.\n\nEach different item within a pattern portfolio is a building block or module. The components are decoupled from the layout, and linearized so they can slot into anywhere on a page.\n\n\n\tThe pattern portfolio expresses every component and layout structure in the smallest number of documents. It sets out how the markup and CSS should be, and is used to illustrate the project\u2019s shared vocabulary.\n\n\tNatalie Downe\n\n\nBy developing a system, rather than individual pages, the result is flexible when the client wants to add more pages later on.\n\nPaul Lloyd\u2019s style guide\n\nPaul Lloyd has written an extremely comprehensive style guide for his site. Not only does it feature every plausible element, but it also explains in detail when it\u2019s appropriate to use each one.\n\n\nPaul\u2019s style guide is also great educational material for people learning to write code.\n\nOli Studholme\u2019s style guide\n\nEven though Oli\u2019s style guide is specific to his site, he\u2019s written it as though it\u2019s for someone else. It\u2019s exhaustive and gives justifications for all his decisions. In some places, he links to browser bug tickets and makes recommendations for cross-browser compatibility.\n\n\nOli has released his style guide under a Creative Commons Attribution Share-alike license, and encourages others to create their own versions.\n\nJeremy Keith\u2019s pattern primer\n\nFront-end style guides may have comments written in the code, annotations that appear on the page, or they may list components alongside their code, like Jeremy\u2019s pattern primer.\n\n\nYou can watch or fork Jeremy\u2019s pattern primer on Github.\n\n\n\nLinearizing components like this resembles a kind of mobile first approach to development, which Jeremy talks about on the 5by5 podcast: The Web Ahead 3.\n\nThe benefits of maintaining a front-end style guide\n\nIf you still need convincing that producing documentation like this for every project is worth the effort, here are a few nice side-effects to working this way:\n\nEasier to test\n\nA unified style guide makes it easier to spot where your design breaks. It\u2019s simple to check how components adapt to different screen widths, test for browser bugs and develop print style sheets when everything is on the same page. When I worked with Natalie, she\u2019d resize the browser window and bump the text size up and down during development to see if anything would break.\n\nBetter workflow\n\nThe approach also forces you to think how something works in relation to the whole site, rather than just a specific page, making it easier to add more pages later on. Starting development by creating a style guide makes a lot more sense than developing on a page-by-page basis.\n\nShared vocabulary\n\nNatalie\u2019s pattern portfolio in particular creates a shared vocabulary of names for components (teaser, global navigation, carousel\u2026), so a team can refer to different regions of the site and have a shared understanding of its meaning.\n\nUseful reference\n\nA combined style guide also helps designers and writers to see the elements that will be incorporated in the site and, therefore, which need to be designed or populated. A boilerplate list of components for every project can act as a reminder of things that may get missed in the design, such as button states or error messages. \n\nCreating your front-end style guide\n\nAs you\u2019ve seen, there are plenty of variations on the web style guide. Which method is best depends on your project and workflow. Let\u2019s say you want to show your content team how blockquotes and asides look, when it\u2019s appropriate to use them, and how to create them within the CMS. In this case, a combination of Jeremy\u2019s pattern primer and Paul\u2019s descriptive style guide \u2013 with the styled component alongside a code snippet and a description of when to use it \u2013 may be ideal. \n\nStart work on your style guide as soon as you can, preferably during the design stage:\n\n\n\tSimply presenting flat image comps is by no means enough\u2009-\u2009it\u2019s only the start\u2026 As layouts become more adaptable, flexible and context-specific, so individual components will become the focus of our design. It is therefore essential to get the foundational aspects of our designs right, and style guides allow us to do that.\n\n\tPaul Lloyd on Style guides for the Web \n\n\n\n\tPrint out the designs and label the unique elements and components you\u2019ll need to add to your style guide. Make a note of the purpose of each component. While you\u2019re doing this, identify the main colours used for things like links, headings and buttons.\nI draw over the print-outs on to tracing paper so I can make more annotations. Here, I\u2019ve started annotating the widths from the designer\u2019s mockup so I can translate these into percentages.\n\tStart developing your style guide with base styles that target core elements: headings, links, tables, blockquotes, ordered lists, unordered lists and forms. For these elements, you could maintain a standard document to reuse for every project.\n\tNext, add the components that override the base styles, like search boxes, breadcrumbs, feedback messages and blog comments. Include interaction styles, such as hover, focus and visited state on links, and hover, focus and active states on buttons.\n\tNow start adding layout and begin slotting the components into place. You may want to present each layout as a separate document, or you could have them all on the same page stacked beneath one another.\n\n\nDocument code practices\n\nCode can look messy when people use different conventions, so note down a standard approach alongside your style guide. For example, Paul Stanton has documented how he writes CSS.\n\nThe gift wrapping\n\nPresenting this documentation to your client may be a little overwhelming so, to be really helpful, create a simple page that links together all your files and explains what each of them do.\n\n\nThis is an example of a contents page that Clearleft produce for their clients. They\u2019ve added date stamps, subversion revision numbers and written notes for each file.\n\nEncourage participation\n\nThere\u2019s always a risk that the person you\u2019re writing the style guide for will ignore it completely, so make your documentation as user-friendly as possible. Justify why you do things a certain way to make it more approachable and encourage similar behaviour.\n\nAs always, good communication helps. Working with the designer to put together this document will improve the site. It\u2019s often not practical for designers to provide a style for everything, so drafting a web style guide and asking for feedback gives designers a chance to make sure any default styles fit in.\n\nIf you work in a team with other developers, documenting your code and development decisions will not only be useful as a deliverable, but will also force you to think about why you do things a certain way.\n\nFuture-friendly\n\nThe roles of designer and developer are increasingly blurred, yet all too often we work in isolation. Working side-by-side with designers on web style guides can vastly improve the quality of our work, and the collaborative approach can spark discussions like \u201chow would this work on a smaller screen?\u201d\n\nSometimes we can be so focused on getting the site ready and live, that we lose sight of what happens after it\u2019s launched, and how it\u2019s going to be maintained. A simple web style guide can make all the difference.\n\nIf you make your own style guide, I\u2019d love to add it to my stash of examples so please share a link to it in the comments.", "year": "2011", "author": "Anna Debenham", "author_slug": "annadebenham", "published": "2011-12-07T00:00:00+00:00", "url": "https://24ways.org/2011/front-end-style-guides/", "topic": "process"}
{"rowid": 270, "title": "From Side Project to Not So Side Project", "contents": "In the last article I wrote for 24 ways, back in 2009, I enthused about the benefits of having a pet project, suggesting that we should all have at least one so that we could collaborate with our friends, escape our day jobs, fulfil our own needs, help others out, raise our profiles, make money, and \u2014 most importantly \u2014 have fun. I don\u2019t think I need to offer any further persuasions: it seems that designers and developers are launching their own pet projects left, right and centre. This makes me very happy.\n\nHowever, there still seems to be something of a disconnect between having a side project and turning it into something that is moderately successful; in particular, the challenge of making enough money to sustain the project and perhaps even elevating it from the sidelines so that it becomes something not so on the side at all.\n\nBefore we even begin this, let\u2019s spend a moment talking about money, also known as\u2026\n\nEvil, nasty, filthy money\n\nOver the last couple of years, I\u2019ve started referring to myself as an accidental businessman. I say accidental because my view of the typical businessman is someone who is driven by money, and I usually can\u2019t stand such people. Those who are motivated by profit, obsessed with growth, and take an active interest in the world\u2019s financial systems don\u2019t tend to be folks with whom I share a beer, unless it\u2019s to pour it over them. Especially if they\u2019re wearing pinstriped suits.\n\nThat said, we all want to make money, don\u2019t we? And most of us want to make a relatively decent amount, too. I don\u2019t think there\u2019s any harm in admitting that, is there? Hello, I\u2019m Elliot and I\u2019m a capitalist.\n\nThe key is making money from doing what we love. For most people I know in our community, we\u2019ve already achieved that \u2014 I\u2019m hard-pressed to think of anyone who isn\u2019t extremely passionate about working in our industry and I think it\u2019s one of the most positive, unifying benefits we enjoy as a group of like-minded people \u2014 but side projects usually arise from another kind of passion: a passion for something other than what we do as our day jobs. Perhaps it\u2019s because your clients are driving you mental and you need a break; perhaps it\u2019s because you want to create something that is truly your own; perhaps it\u2019s because you\u2019re sick of seeing your online work disappear so fast and you want to try your hand at print in order to make a more permanent mark.\n\nThe three factors I listed there led me to create 8 Faces, a printed magazine about typography that started as a side project and is now a very significant part of my yearly output and income.\n\nLike many things that prove fruitful, 8 Faces\u2019 success was something of an accident, too. For a start, the magazine was never meant to be profitable; its only purpose at all was to scratch my own itch. Then, after the first issue took off and I realized how much time I needed to spend in order to make the next one decent, it became clear that I would have to cover more than just the production costs: I\u2019d have to take time out from client work as well. Doing this meant I\u2019d have to earn some money. Probably not enough to equate to the exact amount of time lost when I could be doing client work (not that you could ever describe time as being lost when you work on something you love), but enough to survive; for me to feel that I was getting paid while doing all of the work that 8 Faces entailed. The answer was to raise money through partnerships with some cool companies who were happy to be associated with my little project.\n\nA sustainable business model\n\nBusiness model! I can\u2019t believe I just wrote those words! But a business model is really just a loose plan for how not to screw up. And all that stuff I wrote in the paragraph above about partnering with companies so I could get some money in while I put the magazine together? Well, that\u2019s my business model. \n\nIf you\u2019re making any product that has some sort of production cost, whether that\u2019s physical print run expenses or up-front dev work to get an app built, covering those costs before you even release your product means that you\u2019ll be in profit from the first copy you sell. This is no small point: production expenses are pretty much the only cost you\u2019ll ever need to recoup, so having them covered before you launch anything is pretty much the best possible position in which you could place yourself. Happy days, as Jamie Oliver would say.\n\nObtaining these initial funds through partnerships has another benefit. Sure, it\u2019s a form of advertising but, done right, your partners can potentially provide you with great content, too. In the case of 8 Faces, the ads look as nice as the rest of the magazine, and a couple of our partners also provide proper articles: genuinely meaningful, relevant, reader-pleasing articles at that. You\u2019d be amazed at how many companies are willing to become partners and, as the old adage goes, if you don\u2019t ask, you don\u2019t get.\n\nWith profit comes responsibility\n\nDon\u2019t forget about the responsibility you have to your audience if you engage in a relationship with a partner or any type of advertiser: although I may have freely admitted my capitalist leanings, I\u2019m still essentially a hairy hippy, and I feel that any partnership should be good for me as a publisher, good for the partner and \u2014 most importantly \u2014 good for the reader. Really, the key word here is relevance, and that\u2019s where 99.9% of advertising fails abysmally. \n\n(99.9% is not a scientific figure, but you know what I\u2019m on about.)\n\nThe main grey area when a side project becomes profitable is how you share that profit, partly because \u2014 in my opinion, at least \u2014 the transition from non-profitable side project to relatively successful source of income can be a little blurred. Asking for help for nothing when there\u2019s no money to be had is pretty normal, but sometimes it\u2019s easy to get used to that free help even once you start making money. I believe the best approach is to ask for help with the promise that it will always be rewarded as soon as there\u2019s money available. (Oh, god: this sounds like one of those nightmarish client proposals. It\u2019s not, honest.) If you\u2019re making something cool, people won\u2019t mind helping out while you find your feet.\n\nEvents often think that they\u2019re exempt from sharing profit. Perhaps that\u2019s because many event organizers think they\u2019re doing the speakers a favour rather than the other way around (that\u2019s a whole separate article), but it\u2019s shocking to see how many people seem to think they can profit from content-makers \u2014 speakers, for example \u2014 and yet not pay for that content. It was for this reason that Keir and I paid all of our speakers for our Insites: The Tour side project, which we ran back in July. We probably could\u2019ve got away without paying them, especially as the gig was so informal, but it was the right thing to do.\n\nIn conclusion: money as a by-product\n\nLet\u2019s conclude by returning to the slightly problematic nature of money, because it\u2019s the pivot on which your side project\u2019s success can swing, regardless of whether you measure success by monetary gain. I would argue that success has nothing to do with profit \u2014 it\u2019s about you being able to spend the time you want on the project. Unfortunately, that is almost always linked to money: money to pay yourself while you work on your dream idea; money to pay for more servers when your web app hits the big time; money to pay for efforts to get the word out there. The key, then, is to judge success on your own terms, and seek to generate as much money as you see fit, whether it\u2019s purely to cover your running costs, or enough to buy a small country. There\u2019s nothing wrong with profit, as long as you\u2019re ethical about it. (Pro tip: if you\u2019ve earned enough to buy a small country, you\u2019ve probably been unethical along the way.)\n\nThe point at which individuals and companies fail \u2014 in the moral sense, for sure, but often in the competitive sense, too \u2014 is when money is the primary motivation. It should never be the primary motivation. If you\u2019re not passionate enough about something to do it as an unprofitable side project, you shouldn\u2019t be doing it all. \n\nEarning money should be a by-product of doing what you love. And who doesn\u2019t want to spend their life doing what they love?", "year": "2011", "author": "Elliot Jay Stocks", "author_slug": "elliotjaystocks", "published": "2011-12-22T00:00:00+00:00", "url": "https://24ways.org/2011/from-side-project-to-not-so-side-project/", "topic": "business"}
{"rowid": 287, "title": "Extracting the Content", "contents": "As we throw away our canvas in approaches and yearn for a content-out process, there remains a pain point: the Content. It is spoken of in the hushed tones usually reserved for Lord Voldemort. The-thing-that-someone-else-is-responsible-for-that-must-not-be-named.\n\nDesigners and developers have been burned before by not knowing what the Content is, how long it is, what style it is and when the hell it\u2019s actually going to be delivered, in internet eons past. Warily, they ask clients for it. But clients don\u2019t know what to make, or what is good, because no one taught them this in business school. Designers struggle to describe what they need and when, so the conversation gets put off until it\u2019s almost too late, and then everyone is relieved that they can take the cop-out of putting up a blog and maybe some product descriptions from the brochure.\n\nThe Content in content out.\n\nI\u2019m guessing, as a smart, sophisticated, and, may I say, nicely-scented reader of the honourable and venerable tradition of 24 ways, that you sense something better is out there. Bunches of boxes to fill in just don\u2019t cut it any more in a responsive web design world. The first question is, how are you going to design something to ensure users have the easiest access to the best Content, if you haven\u2019t defined at the beginning what that Content is? Of course, it\u2019s more than possible that your clients have done lots of user research before approaching you to start this project, and have a plethora of finely tuned Content for you to design with.\n\nHave you finished laughing yet? Alright then. Let\u2019s just assume that, for whatever reason of gross oversight, this hasn\u2019t happened. What next?\n\nBringing up Content for the first time with a client is like discussing contraception when you\u2019re in a new relationship. It might be awkward and either party would probably rather be doing something else, but it needs to be broached before any action happens (that, and it\u2019s disastrous to assume the other party has the matter in hand). If we can\u2019t talk about it, how can we expect people to be doing it right and not making stupid mistakes? That being the case, how do we talk about Content? Let\u2019s start by finding a way to talk about it without blushing and scuffing our shoes. And there\u2019s a reason I\u2019ve been treating Content as a Proper Noun. \n\nThe first step, and I mean really-first-step-way-back-at-the-beginning-of-the-project-while-you-are-still-scoping-out-what-the-hell-you-might-do-for-each-other-and-it\u2019s-still-all-a-bit-awkward-like-a-first-date, is for you to explain to the client how important it is that you, together, work out what is important to your users as part of the user experience design, so that your users get the best user experience. The trouble is that, in most cases, this would lead to blank stares, possibly followed by a light cough and a query about using Comic Sans because it seems friendly.\n\nLet\u2019s start by ensuring your clients understand the task ahead. You see, all the time we talk about the Content we do our clients a big disservice. Content is poorly defined. It looms over a project completion point like an unscalable (in the sense of a dozen stacked Kilimanjaros), seething, massive, singular entity. The Content.\n\nDefining the problem. \n\nWe should really be thinking of the Content as \u2018contents\u2019; as many parts that come together to form a mighty experience, like hit 90s kids\u2019 TV show Mighty Morphin Power Rangers*.\n\n*For those of you who might have missed the Power Rangers, they were five teenagers with attitude, each given crazy mad individual skillz and a coloured lycra suit from an alien overlord. In return, they had to fight a new monster of the week using their abilities and weaponry in sync (even if the audio was not) and then, finally, in thrilling combination as a Humongous Mechanoid Machine of Awesome. They literally joined their individual selves, accessories and vehicles into a big robot. It was a toy manufacturer\u2019s wet dream.\n\nSo, why do I say Content is like the Power Rangers? Because Content is not just a humongous mecha. It is a combination of well-crafted pieces of contents that come together to form a well-crafted humongous mecha. Of Content.\n\nThe Red Power Ranger was always the leader. You can imagine your text contents, found on about pages, product descriptions, blog articles, and so on, as being your Red Power Ranger.\n\nMaybe your pictures are your Yellow Power Ranger; video is Blue (not used as much as the others, but really impressive when given a good storyline); maybe Pink is your infographics (it\u2019s wrong to find it sexier than the other equally important Rangers, but you kind of do anyway). And so on. \n\nThese bits of content \u2013 Red Text Ranger, Yellow Picture Ranger and others \u2013 often join together on a page, like they are teaming up to fight the bad guy in an action scene, and when they all come together (your standard workaday huge mecha) in a launched site, that\u2019s when Content becomes an entity.\n\nWhile you might have a vision for the whole site, Content rarely works that way. Of course, you keep your eye on the bigger prize, the completion of your mega robot, but to get there you need to assemble your working parts, the cogs and springs of contents that will mesh together to finally create your Humongous Mecha of Content. You create parts and join them to form a whole. (It\u2019s rarely seamless; often we need to adjust as we go, but we can create our Mecha\u2019s blueprint by making sure we have all the requisite parts.)\n\nThe point here is the order these parts were created. No alien overlord plans a Humongous Mechanoid and then thinks, \u201cGee, how can I split this into smaller fighting units powered by teenagers in snazzy shiny suits?\u201d No toy manufacturer goes into production of a mega robot, made up of model mecha vehicles with detachable arsenal, without thinking how they will easily fit back together to form the \u2018Buy all five now to create the mega robot\u2019 set. No good contents are created as a singular entity and chunked up to be slotted in to place any which way, into the body of a site.\n\nThink contents, not the Content. Think of contents as smaller units, or as a plural. The Content is what you have at the end. The contents are what you are creating and they are easy to break down. You are no longer scaling the unscalable. You can draw the map and plot the path, page by page, section by section.\n\nThe page table is your friend\n\nTo do this, I use a page table. A page table is a simple table template you can create in the word processor of your choice, that you use to tell you everything about the contents of a page \u2013 everything except the contents itself. \n\nHere\u2019s a page table I created for an employee\u2019s guide to redundancy in the alpha.gov.uk website:\n\n \n\nGuide to redundancy for employees\n\n\n\tPage objective: Provide specific information for employees who are facing redundancy about the process, their options and next steps.\n\tSource content: directgov page on Redundancy.\n\tScope: In scope\n\n\n\n\t\t\n\t\t\tPage title \n\t\t\t An employee\u2019s guide to redundancy \n\t\t\n\t\t\n\t\t\tPriority content \n\t\t\t Message: You have rights as an employee facing redundancy\nMethod: A guide written in plain English, with links to appropriate additional content.\nA video guide (out of scope).\nCovers the stages of redundancy and rights for those in trade unions and not in trade unions. Glossary of unfamiliar terms.\nCall to action: Read full guide, act to explore redundancy actions, benefits or new employment.\nAssets: link to redundancy calculator. \n\t\t\n\t\t\n\t\t\tSecondary \n\t\t\t Related items, or popular additional links. \nAdditional tools, such as search and suggestions.\n\n\n\n\tlocation set v not set states\n\tmicrocopy encouraging location set where location may make a difference to the content \u2013 ie, Scotland/Northern Ireland.\n\n\t\t\n\t\t\n\t\t\tTertiary \n\t\t\t Footer and standard links. \n\t\t\n\n\n\n\tContent creation: Content exists but was created within the constraints of the previous CMS. Review, correct and edit where necessary.\n\tMaintenance: should be flagged for review upon advice from Department of Work and Pensions, and annually.\n\tTechnology/Publishing/Policy implications: Should be reviewed once the glossary styles have been decided. No video guide in scope at this time, so languages should be simple and screen reader friendly.\n\tReliance on third parties: None, all content and source exists in house.\n\tOutstanding questions: None.\n\n\n \n\nDownload a copy of this page table\n\nThis particular page table template owes a lot to Brain Traffic\u2019s version found in Kristina Halvorson\u2019s book Content Strategy for the Web. With smaller clients than, say, the government, I might use something a bit more casual. With clients who like timescales and deadlines, I might turn it into a covering sheet, with signatures and agreements from two departments who have to work together to get the piece done on time.\n\nI use page tables, and the process of working through them, to reassure clients that I understand the task they face and that I can help them break it down section by section, page stack to page, down to product descriptions and interaction copy. About 80% of my clients break into relieved smiles. Most clients want to work with you to produce something good, they just don\u2019t understand how, and they want you to show them the mountain path on the map. With page tables, clients can understand that with baby steps they can break down their content requirements and commission content they need in time for the designers to work with it (as opposed to around it). If I was Santa, these clients would be on my nice list for sure.\n\nMy own special brand of Voldemort-content-evilness comes in how I wield my page tables for the other 20%. Page tables are not always thrilling, I\u2019ll admit. Sometimes they get ignored in favour of other things, yet they are crucial to the continual growth and maintenance of a truly content-led site. For these naughty list clients who, even when given the gift of the page table, continually say \u201cOoh, yes. Content. Right\u201d, I have a special gift. I have a stack of recycled paper under my desk and a cheap black and white laser printer. And I print a blank page table for every conceivable page I can find on the planned redesign. If I\u2019m feeling extra nice, I hole punch them and put them in a fat binder. \n\nThere is nothing like saying, \u201cThis is all the contents you need to have in hand for launch\u201d, and the satisfying thud the binder makes as it hits the table top, to galvanize even the naughtiest clients to start working with you to create the content you need to really create in a content-out way.", "year": "2011", "author": "Relly Annett-Baker", "author_slug": "rellyannettbaker", "published": "2011-12-15T00:00:00+00:00", "url": "https://24ways.org/2011/extracting-the-content/", "topic": "content"}
{"rowid": 288, "title": "Displaying Icons with Fonts and Data- Attributes", "contents": "Traditionally, bitmap formats such as PNG have been the standard way of delivering iconography on websites. They\u2019re quick and easy, and it also ensures they\u2019re as pixel crisp as possible. Bitmaps have two drawbacks, however: multiple HTTP requests, affecting the page\u2019s loading performance; and a lack of scalability, noticeable when the page is zoomed or viewed on a screen with a high pixel density, such as the iPhone 4 and 4S.\n\nThe requests problem is normally solved by using CSS sprites, combining the icon set into one (physically) large image file and showing the relevant portion via background-position. While this works well, it can get a bit fiddly to specify all the positions. In particular, scalability is still an issue. A vector-based format such as SVG sounds ideal to solve this, but browser support is still patchy.\n\n\n\nThe rise and adoption of web fonts have given us another alternative. By their very nature, they\u2019re not only scalable, but resolution-independent too. No need to specify higher resolution graphics for high resolution screens! \n\nThat\u2019s not all though:\n\n\n\tBrowser support: Unlike a lot of new shiny techniques, they have been supported by Internet Explorer since version 4, and, of course, by all modern browsers. We do need several different formats, however!\n\tDesign on the fly: The font contains the basic graphic, which can then be coloured easily with CSS \u2013 changing colours for themes or :hover and :focus styles is done with one line of CSS, rather than requiring a new graphic. You can also use CSS3 properties such as text-shadow to add further effects. Using -webkit-background-clip: text;, it\u2019s possible to use gradient and inset shadow effects, although this creates a bitmap mask which spoils the scalability.\n\tSmall file size: specially designed icon fonts, such as Drew Wilson\u2019s Pictos font, can be as little as 12Kb for the .woff font. This is because they contain fewer characters than a fully fledged font. You can see Pictos being used in the wild on sites like Garrett Murray\u2019s Maniacal Rage.\n\n\nAs with all formats though, it\u2019s not without its disadvantages: \n\n\n\tIcons can only be rendered in monochrome or with a gradient fill in browsers that are capable of rendering CSS3 gradients. Specific parts of the icon can\u2019t be a different colour.\n\tIt\u2019s only appropriate when there is an accompanying text to provide meaning. This can be alleviated by wrapping the text label in a tag (I like to use rather than , due to the fact that it\u2019s smaller and isn\u2019 t being used elsewhere) and then hiding it from view with text-indent:-999em.\n\tCreating an icon font can be a complex and time-consuming process. While font editors can carry out hinting automatically, the best results are achieved manually.\n\tUnless you\u2019re adept at creating your own fonts, you\u2019re restricted to what is available in the font. However, fonts like Pictos will cover the most common needs, and icons are most effective when they\u2019re using familiar conventions.\n\n\nThe main complaint about using fonts for icons is that it can mean adding a meaningless character to our markup. The good news is that we can overcome this by using one of two methods \u2013 CSS generated content or the data-icon attribute \u2013 in combination with the :before and :after pseudo-selectors, to keep our markup minimal and meaningful. \n\nOur simple markup looks like this:\n\nView Basket\n\nNote the multiple class attributes. Next, we\u2019ll import the Pictos font using the @font-face web fonts property in CSS:\n\n@font-face {\n font-family: 'Pictos';\n src: url('pictos-web.eot');\n src: local('\u263a'), \n url('pictos-web.woff') format('woff'), \n url('pictos-web.ttf') format('truetype'),\n url('pictos-web.svg#webfontIyfZbseF') format('svg');\n}\n\nThis rather complicated looking set of rules is (at the time of writing) the most bulletproof way of ensuring as many browsers as possible load the font we want. We\u2019ll now use the content property applied to the :before pseudo-class selector to generate our icon. Once again, we\u2019ll use those multiple class attribute values to set common icon styles, then specific styles for .basket. This helps us avoid repeating styles:\n\n.icon {\n font-family: 'Pictos';\n font-size: 22px:\n}\n\n.basket:before {\n content: \"$\";\n}\n\nWhat does the :before pseudo-class do? It generates the dollar character in a browser, even when it\u2019s not present in the markup. Using the generated content approach means our markup stays simple, but we\u2019ll need a new line of CSS, defining what letter to apply to each class attribute for every icon we add.\n\ndata-icon is a new alternative approach that uses the HTML5 data- attribute in combination with CSS attribute selectors. This new attribute lets us add our own metadata to elements, as long as its prefixed by data- and doesn\u2019t contain any uppercase letters. In this case, we want to use it to provide the letter value for the icon. Look closely at this markup and you\u2019ll see the data-icon attribute.\n\nView Basket\n\n\n\nWe could add others, in fact as many as we like.\n\nFavourites\nHistory\nLocation\n\n\n\nThen, we need just one CSS attribute selector to style all our icons in one go:\n\n.icon:before {\n content: attr(data-icon);\n /* Insert your fancy colours here */\n }\n\nBy placing our custom attribute data-icon in the selector in this way, we can enable CSS to read the value of that attribute and display it before the element (in this case, the anchor tag). It saves writing a lot of CSS rules. I can imagine that some may not like the extra attribute, but it does keep it out of the actual content \u2013 generated or not.\n\n\n\n\n\nThis could be used for all manner of tasks, including a media player and large simple illustrations. See the demo for live examples. Go ahead and zoom the page, and the icons will be crisp, with the exception of the examples that use -webkit-background-clip: text as mentioned earlier.\n\nFinally, it\u2019s worth pointing out that with both generated content and the data-icon method, the letter will be announced to people using screen readers. For example, with the shopping basket icon above, the reader will say \u201cdollar sign view basket\u201d. As accessibility issues go, it\u2019s not exactly the worst, but could be confusing. You would need to decide whether this method is appropriate for the audience. Despite the disadvantages, icon fonts have huge potential.", "year": "2011", "author": "Jon Hicks", "author_slug": "jonhicks", "published": "2011-12-12T00:00:00+00:00", "url": "https://24ways.org/2011/displaying-icons-with-fonts-and-data-attributes/", "topic": "code"}
{"rowid": 265, "title": "Designing for Perfection", "contents": "Hello, 24 ways readers. I hope you\u2019re having a nice run up to Christmas. This holiday season I thought I\u2019d share a few things with you that have been particularly meaningful in my work over the last year or so. They may not make you wet your santa pants with new-idea-excitement, but in the context of 24 ways I think they may serve as a nice lesson and a useful seasonal reminder going into the New Year. Enjoy!\n\nStory\n\nDespite being a largely scruffy individual for most of my life, I had some interesting experiences regarding kitchen tidiness during my third year at university. \n\nAs a kid, my room had always been pretty tidy, and as a teenager I used to enjoy reordering my CDs regularly (by artist, label, colour of spine \u2013 you get the picture); but by the time I was twenty I\u2019d left most of these traits behind me, mainly due to a fear that I was turning into my mother. The one remaining anally retentive part of me that remained however, lived in the kitchen. For some reason, I couldn\u2019t let all the pots and crockery be strewn across the surfaces after cooking. I didn\u2019t care if they were washed up or not, I just needed them tidied. The surfaces needed to be continually free of grated cheese, breadcrumbs and ketchup spills. Also, the sink always needed to be clear. Always. Even a lone teabag, discarded casually into the sink hours previously, would give me what I used to refer to as \u201ckitchen rage\u201d.\n\nWhilst this behaviour didn\u2019t cause any direct conflicts, it did often create weirdness. We would be happily enjoying a few pre-night out beverages (Jack Daniels and Red Bull \u2013 nice) when I\u2019d notice the state of the kitchen following our round of customized 49p Tesco pizzas. Kitchen rage would ensue, and I\u2019d have to blitz the kitchen, which usually resulted in me having to catch everyone up at the bar afterwards.\n\nOne evening as we were just about to go out, I was stood there, in front of the shithole that was our kitchen with the intention of cleaning it all up, when a realization popped into my head. In hindsight, it was a pretty obvious one, but it went along the lines of \u201cWhat the fuck are you doing? Sort your life out\u201d. I sodded the washing up, rolled out with my friends, and had a badass evening of partying.\n\nAfter this point, whenever I got the urge to clean the kitchen, I repeated that same realization in my head. My tidy kitchen obsession strived for a level of perfection that my housemates just didn\u2019t share, so it was ultimately pointless. It didn\u2019t make me feel that good, either; it was like having a cigarette after months of restraint \u2013 initially joyous but soon slightly shameful.\n\nLesson\n\nNow, around seven years later, I\u2019m a designer on the web and my life is chaotic. It features no planning for significant events, no day-to-day routine or structure, no thought about anything remotely long-term, and I like to think I do precisely what I want. It seems my days at striving for something ordered and tidy, in most parts of my life, are long gone.\n\nFor much of my time as a designer, though, it\u2019s been a different story. I relished industry-standard terms such as \u2018pixel perfection\u2019 and \u2018polished PSDs\u2019, taking them into my stride as I strove to design everything that was put on my plate perfectly. Even down to grids and guidelines, all design elements would be painstakingly aligned to a five-pixel grid. There were no seven-pixel margins or gutters to be found in my design work, that\u2019s for sure. I put too much pride and, inadvertently, too much ego into my work. Things took too long to create, and because of the amount of effort put into the work, significant changes, based on client feedback for example, were more difficult to stomach.\n\nOver the last eighteen months I\u2019ve made a conscious effort to change the way I approach designing for the web. Working on applications has probably helped with this; they seem to have a more organic development than rigid content-based websites. Mostly though, a realization similar to my kitchen rage one came about when I had to make significant changes to a painstakingly crafted Photoshop document I had created. The changes shouldn\u2019t have been difficult or time-consuming to implement, but they were turning out to be. One day, frustrated with how long it was taking, the refrain \u201cWhat the fuck are you doing? Sort your life out\u201d again entered my head. I blazed the rest of the work, not rushing or doing scruffy work, but just not adhering to the insane levels of perfection I had previously set for myself. When the changes were presented, everything went down swimmingly. The client in this case (and I\u2019d argue most cases) cared more about the ideas than the perfect way in which they had been implemented. I had taken myself and my ego out of the creative side of the work, and it had been easier to succeed.\n\nArgument\n\nI know many other designers who work on the web share such aspirations to perfection. I think it\u2019s a common part of the designer DNA, but I\u2019m not sure it really has a place when designing for the web.\n\nFirst, there\u2019s the environment. The landscape in which we work is continually shifting and evolving. The inherent imperfection of the medium itself makes attempts to create perfect work for it redundant. Whether you consider it a positive or negative point, the products we make are never complete. They\u2019re always scaling and changing. \n\nLike many aspects of web design, this striving for perfection in our design work is a way of thinking borrowed from other design industries where it\u2019s more suited. A physical product cannot be as easily altered or developed after it has been manufactured, so the need to achieve perfection when designing is more apt.\n\nDesigners who can relate to anything I\u2019ve talked about can easily let go of that anal retentiveness if given the right reasons to do so. Striving for perfection isn\u2019t a bad thing, but I simply don\u2019t think it can be achieved in such a fast-moving, unique industry. I think design for the web works better when it begins with quick and simple, followed by iteration and polish over time. \n\nTo let go of ego and to publish something that you\u2019re not completely happy with is perhaps the most difficult part of the job for designers like us, but it\u2019s followed by a satisfaction of knowing your product is alive and breathing, whereas others (possibly even competitors) may still be sitting in Photoshop, agonizing over whether a margin should be twenty or forty pixels.\n\nI keep telling myself to stop sitting on those two hundred ideas that are all half-finished. Publish them, clean them up and iterate over time. I\u2019ve been telling myself this for months and, hopefully, writing this article will give me the kick in the arse I need. Hopefully, it will also give someone else the same kick.", "year": "2011", "author": "Greg Wood", "author_slug": "gregwood", "published": "2011-12-17T00:00:00+00:00", "url": "https://24ways.org/2011/designing-for-perfection/", "topic": "process"}
{"rowid": 279, "title": "Design the Invisible to Tell Better Stories on the Web", "contents": "For design to be meaningful we need to tell stories. We need to design the invisible, the cues, the messages and the extra detail hidden beneath the aesthetics. It\u2019s all about the story.\n\n\n\nFrom verbal exchanges around the campfire to books, the web and everything in between, storytelling allows us to share, organize and process information more efficiently. It helps us understand our surroundings and make emotional connections to people, places and experiences.\n\nWeb design lends itself perfectly to the conventions of storytelling, a universal process. However, the stories vary because they\u2019re defined by culture, society, politics and religion. All of which need considering if you are to design stories that are relevant to your target audience.\n\nThe benefits of approaching design with storytelling in mind from the very start of the project is that we are creating considered design that allows users to quickly gather meaning from the website. They do this by reading between the lines and drawing on the wealth of knowledge they have acquired about the associations between colours, typyefaces and signs.\n\nWith so much recognition and analysis happening subconsciously you have to consider how design communicates on this level. This invisible layer has a significant impact on what you say, how you say it and who you say it to.\n\nHow can we design something that\u2019s invisible?\n\nBy researching and making conscious decisions about exactly what you are communicating, you can make the invisible visible. As is often quoted, good design is like air, you only notice it when it\u2019s bad. So by designing the invisible the aim is to design stories that the audience receive subliminally, so that they go somewhat unnoticed, like good air.\n\nStorytelling strands\n\nTo share these stories through design, you can break it down into several strands. Each strand tells a story on its own, but when combined they may start to tell a different story altogether. These strands are colour, typefaces, branding, tone of voice and symbols. All are literal and visible but the invisible element is the meaning behind them \u2013 meaning that you can extract and share. In this article I want to focus on colour, typefaces and tone of voice and on how combining story strands can change the meaning.\n\nColour\n\nLet\u2019s start with colour. Red represents emotions such as love but can also signify war. Green is commonly used for all things environmental and purple is a colour that connotes wealth and royalty. These associations between colour and emotion or value have been learned over time and are continually reinforced through media and culture. \n\n\n\nWith this knowledge come expectations from your users. For example, they will expect Valentine\u2019s Day sites to be red and kids\u2019 sites to be bright and colourful. This is true in the same way audiences have expectations of certain genres of film or music. These conventions help savvy audiences decode texts and read between the lines or, rather, to draw meaning from the invisible. It\u2019s practically an innate skill. This is why you need to design the invisible: because users will quickly deduce meaning from your site and fill in the story\u2019s gaps, it\u2019s important to give them as much of that story to begin with. A story relevant to their culture.\n\n\n\nOf all the ways you can tell stories through web design, colour is the most fascinating and important. Not only does it evoke emotions in users but its meaning varies significantly between cultures. In the west, for example, white is a colour associated with weddings, and black is the colour of mourning. This is signified by the traditions of brides wearing white and those in mourning wearing black. In other cultures the meanings are reversed, as black is a colour that represents good luck and white is a colour that signifies mourning. If you assume the same values are true in all cultures then you risk offending the very people you are targeting.\n\nWhen colours combine, the story being told can change. If you design using red, white and blue then it\u2019s going to be difficult to shake off patriotic connotations because this colour combination is so ingrained as being American or British or French thanks largely to their flags. This extends to politics too. Each party has its own representative colour. In the UK, the Conservatives are blue and Labour is red so it would be inappropriate storytelling to design a Labour-related website in blue as there would be a conflict between the content and the design, a conflict that would result in a poor user experience.\n\nConflicts become more of an issue when you start to combine story strands. I once saw a No VAT advert use the symbol on the left:\n\n\n\nThere\u2019s a complete conflict in storytelling here between the sign and its colour. The prohibition sign was used over the word VAT to mean no VAT; that makes sense. But this is a symbol that is used to communicate to people that something is being prohibited or prevented, it mustn\u2019t continue. So to use green contradicts the message of the sign itself; green is used as a colour to say yes, go, proceed, enter. The same would be true if we had a tick in red and a cross in green. Bad design here means the story is flawed and the user experience is compromised.\n\nTypefaces\n\nTypefaces also tell stories. They are so much more than the words that are written with them because they connote different values. Here are a few:\n\n\n\nSerif fonts are more formal and are associated with tradition, sophistication and high-end values. Sans serif fonts, on the other hand, are synonymous with modernity, informality and friendliness. These perceptions are again reinforced through more traditional media such as newspaper mastheads, where the serious news-focused broadsheets have serif titles, and the showbiz and gossip-led tabloids have sans serif titles. This translates to the web as well. With these associations already familiar to users, they may see copy and focus on the words, but if the way that copy is displayed jars with the context then we are back to having conflicting stories like the No VAT sign earlier.\n\nLet\u2019s take official institutions, for example. The White House, the monarchy, 10 Downing Street and other government departments are formal, traditional and important organisations. If the copy on their websites were written in a typeface like Cooper Black, it would erase any authority and respect that they were due. They need people to take them seriously and trust them, and part of the way to do this is to have a typeface that represents those values.\n\nIt works both ways though. If Innocent, Threadless or other fun companies used traditional typefaces, they wouldn\u2019t be accurate reflections of their core values, brand and personality. They are better positioned to use friendly, informal and modern typefaces. But still never Comic Sans.\n\nTone of voice\n\nClosely tied to this is tone of voice, my absolute bugbear on the web. Tone of voice isn\u2019t what is said but, rather, how it is said. When we interact with others in person we don\u2019t just listen to the words they say, but we also draw meaning from their body language, and pitch and tone of voice. Just because the web removes that face-to-face interaction with your audience it doesn\u2019t mean you can\u2019t have a tone of voice. \n\n\n\nInnocent pioneered the informal chatty tone of voice that so many others have since emulated, but unless it is representative of your company, then it\u2019s not appropriate. It works for Innocent because the tone of voice is consistent across all the company\u2019s materials, both online and offline. Ben and Jerry\u2019s takes the same approach, as does Threadless, but maybe you need a more formal or corporate tone of voice. It really depends on what your business or service is and who it is for, and that is why I think LoveFilm has it all wrong. \n\nLoveFilm offers a film and game rental service, something fun for people in their downtime. While they aren\u2019t particularly stuffy, neither is their tone of voice very friendly or informal, which is what I would expect from a service like theirs. The reason they have it wrong is in the language they use and the way their sentences are constructed.\n\nThis is the first time we\u2019ve discussed language because, on the whole, designing the invisible isn\u2019t concerned with language at all. But that doesn\u2019t mean that these strands can\u2019t still elicit an emotional response in users. Jon Tan quoted Dr Mazviita Chirimuuta in his New Adventures in Web Design talk in January 2011:\n\n\n\tAlthough there is no absolute separation between language and emotion, there will still be countless instances where you have emotional response without verbal input or linguistic cognition. In general language is not necessary for emotion.\n\n\nThis is even more pertinent when the emotions evoked are connected to people\u2019s culture, surroundings and way of life. It makes design personal, something that audiences can connect with at more than just face value but, rather, on a subliminal or, indeed, invisible level. \n\nIt also means that when you are asked the inevitable question of why \u2013 why is blue the dominant colour? why have you used that typeface? why don\u2019t we sound like Innocent? \u2013 you will have a rationale behind each design decision that can explain what story you are telling, how you discovered the story and how it is targeted at the core audience.\n\nResearch\n\nThis is where research plays a vital role in the project cycle. If you don\u2019t know and understand your audience then you don\u2019t know what story to design. Every project lends itself to some level of research, but how in-depth and what methods are most appropriate will be dictated by project requirements and budget restrictions \u2013 but do your research. \n\nEven if you think you know your audience, it doesn\u2019t hurt to research and reaffirm that because cultures and society do change, albeit slowly, but they can change. So ask questions at the start of the project during the research phase:\n\n\n\tWhat do different colours mean for your audience\u2019s culture?\n\tDo the typeface and tone of voice appeal to the demographic?\n\tDoes the brand identity represent the values and personality of your service?\n\tAre there any social, political or religious significances associated with your audience that you need to take into consideration so you don\u2019t offend them?\n\n\nAsk questions, understand your audience, design your story based on these insights, and create better user experiences in context that have good, solid storytelling at their heart.\n\nMajor hat tip to Gareth Strange for the beautiful graphics used within this article.", "year": "2011", "author": "Robert Mills", "author_slug": "robertmills", "published": "2011-12-14T00:00:00+00:00", "url": "https://24ways.org/2011/design-the-invisible/", "topic": "design"}
{"rowid": 286, "title": "Defending the Perimeter Against Web Widgets", "contents": "On July 14, 1789, citizens of Paris stormed the Bastille, igniting a revolution that toppled the French monarchy. On July 14 of this year, there was a less dramatic (though more tweeted) takedown: The Deck network, which delivers advertising to some of the most popular web design and culture destinations, was down for about thirty minutes. During this period, most partner sites running ads from The Deck could not be viewed as result.\n\nA few partners were unaffected (aside from not having an ad to display). Fortunately, Dribbble, was one of them. In this article, I\u2019ll discuss outages like this and how to defend against them. But first, a few qualifiers: The Deck has been rock solid \u2013 this is the only downtime we\u2019ve witnessed since joining in June. More importantly, the issues in play are applicable to any web widget you might add to your site to display third-party content.\n\nDown and out\n\nYour defense is only as good as its weakest link. Web pages are filled with links, some of which threaten the ability of your page to load quickly and correctly. If you want your site to work when external resources fail, you need to identify the weak links on your site. In this article, we\u2019ll talk about web widgets as a point of failure and defensive JavaScript techniques for handling them.\n\nWidgets 101\n\nImagine a widget that prints out a Pun of the Day on your site. A simple technique for both widget provider and consumer is for the provider to expose a URL:\n\nhttp://widgetjonesdiary.com/punoftheday.js\n\nwhich returns a JavaScript file like this:\n\ndocument.write(\"
The Pun of the Day
Where do frogs go for beers after work? Hoppy hour!
\");\n\nThe call to document.write() injects the string passed into the document where it is called. So to display the widget on your page, simply add an external script tag where you want it to appear:\n\n
\n \n \n
\n\nThis approach is incredibly easy for both provider and consumer. But there are implications\u2026\n\ndocument.write()\u2026 or wrong?\n\nAs in the example above, scripts may perform a document.write() to inject HTML. Page rendering halts while a script is processed so any output can be inlined into the document. Therefore, page rendering speed depends on how fast the script returns the data. If an external JavaScript widget hangs, so does the page content that follows. It was this scenario that briefly stalled partner sites of The Deck last summer.\n\nThe elegant solution\n\nTo make our web widget more robust, calls to document.write() should be avoided. This can be achieved with a technique called JSONP (AKA JSON with padding). In our example, instead of writing inline with document.write(), a JSONP script passes content to a callback function:\n\npublishPun(\"
Pun of the Day
Where do frogs go for beers after work? Hoppy hour!
\");\n\nThen, it\u2019s up to the widget consumer to implement a callback function responsible for displaying the content. Here\u2019s a simple example where our callback uses jQuery to write the content into a target
:\n\n\n\n\n\u2026\n\n\n \nfunction publishPun(content) {\n $(‘.punoftheday’).html(content); // Writes content display location \n} \n\n\n\n\nView Example 1\n\nEven if the widget content appears at the top of the page, our script can be included at the bottom so it\u2019s non-blocking: a slow response leaves page rendering unaffected. It simply invokes the callback which, in turn, writes the widget content to its display destination.\n\nThe hack\n\nBut what to do if your provider doesn\u2019t support JSONP? This was our case with The Deck. Returning to our example, I\u2019m reminded of computer scientist David Wheeler\u2019s statement, \u201cAll problems in computer science can be solved by another level of indirection\u2026 Except for the problem of too many layers of indirection.\u201d\n\nIn our case, the indirection is to move the widget content into position after writing it to the page. This allows us to place the widget \n
Pun of the Day
\n
Where do frogs go for beers after work? Hoppy hour!
\n
\n\nThe \u2018loading-dock\u2019
now includes the widget content, albeit hidden from view (if we\u2019ve styled the \u2018hidden\u2019 class with display: none). There\u2019s just one more step: move the content to its display destination. This line of jQuery (from above) does the trick:\n\n$('.punoftheday').append($('.loading-dock').children(':gt(0)'));\n\nThis selects all child elements in the \u2018loading-doc\u2019
except the first \u2013 the widget \n\nIf I only want to run that search when there\u2019s room for a sidebar, I can wrap it in an if statement:\n\n\n\nIf the browser is wider than 640 pixels, that will fire off a search for news stories about cats and put the results into the newsresults element in my markup:\n\n
\n \n
\n\nThis works pretty well but I\u2019m making an assumption that people with small-screen devices wouldn\u2019t be interested in seeing that nice-to-have content. You know what they say about assumptions: they make an ass out of you and umptions. I should really try to give everyone at least the option to get to that extra content:\n\n
\n\nSee the result\n\nVisitors with small-screen devices will see that link to the search results; visitors with larger screens will get the search results directly.\n\nI\u2019ve been concentrating on HTML and JavaScript, but this technique has consequences for content strategy and information architecture. Instead of thinking about possible page content in a binary way as either \u2018on the page\u2019 or \u2018not on the page\u2019, conditional loading introduces a third \u2018it\u2019s complicated\u2019 option.\n\nThis was just a simple example but I hope it illustrates that conditional loading could become an important part of the content-first responsive design approach.", "year": "2011", "author": "Jeremy Keith", "author_slug": "jeremykeith", "published": "2011-12-02T00:00:00+00:00", "url": "https://24ways.org/2011/conditional-loading-for-responsive-designs/", "topic": "ux"}
{"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