{"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": 269, "title": "Adaptive Images for Responsive Designs\u2026 Again", "contents": "When I was asked to write an article for 24 ways I jumped at the chance, as I\u2019d been wanting to write about some fun hacks for responsive images and related parsing behaviours. My heart sank a little when Matt Wilcox beat me to the subject, but it floated back up when I realized I disagreed with his method and still had something to write about.\n\nSo, Matt Wilcox, if that is your real name (and I\u2019m pretty sure it is), I disagree. I see your dirty server-based hack and raise you an even dirtier client-side hack. Evil laugh, etc., etc.\n\nYou guys can stomach yet another article about responsive design, right? Right?\n\nHalf the room gets up to leave\n\nWhoa, whoa\u2026 OK, I\u2019ll cut to the chase\u2026\n\nTL;DR\n\nIn a previous episode, we were introduced to Debbie and her responsive cat poetry page. Well, now she\u2019s added some reviews of cat videos and some images of cats. Check out her new page and have a play around with the browser window. At smaller widths, the images change and the design responds. The benefits of this method are:\n\n\n\tit\u2019s entirely client-side\n\timages are still shown to users without JavaScript\n\tyour media queries stay in your CSS file\n\tno repetition of image URLs\n\tno extra downloads per image\n\tit\u2019s fast enough to work on resize\n\tit\u2019s pure filth\n\n\nWhat\u2019s wrong with the server-side solution?\n\nResponsive design is a client-side issue; involving the server creates a boatload of problems.\n\n\n\tIt sets a cookie at the top of the page which is read in subsequent requests. However, the cookie is not guaranteed to be set in time for requests on the same page, so the server may see an old value or no value at all.\n\tServing images via server scripts is much slower than plain old static hosting.\n\tThe URL can only cache with vary: cookie, so the cache breaks when the cookie changes, even if the change is unrelated. Also, far-future caching is out for devices that can change width.\n\tIt depends on detecting screen width, which is rather messy on mobile devices.\n\tResponding to things other than screen width (such as DPI) means packing more information into the cookie, and a more complicated script at the top of each page.\n\n\nSo, why isn\u2019t this straightforward on the client?\n\nClient-side solutions to the problem involve JavaScript testing user agent properties (such as screen width), looping through some images and setting their URLs accordingly. However, by the time JavaScript has sprung into action, the original image source has already started downloading. If you change the source of an image via JavaScript, you\u2019re setting off yet another request.\n\nImages are downloaded as soon as their DOM node is created. They don\u2019t need to be visible, they don\u2019t need to be in the document.\n\nnew Image().src = url\n\nThe above will start an HTTP request for url. This is a handy trick for quick requests and preloading, but also shows the browser\u2019s eagerness to download images.\n\nHere\u2019s an example of that in action. Check out the network tab in Web Inspector (other non-WebKit development aids are available) to see the image requests.\n\nBecause of this, some client-side solutions look like this:\n\n<img src=\"t.gif\" data-src=\"real-image.jpg\" data-bigger-src=\"real-bigger-image.jpg\">\n\nwhere t.gif is a 1\u00d71px tiny transparent GIF.\n\nThis results in no images if JavaScript isn\u2019t available. Dealing with the absence of JavaScript is still important, even on mobile. I was recently asked to make a website work on an old Blackberry 9000. I was able to get most of the way there by preventing that OS parsing any JavaScript, and that was only possible because the site didn\u2019t depend on it.\n\nWe need to delay loading images for JavaScript users, but ensure they load for users without JavaScript. How can we conditionally parse markup depending on JavaScript support?\n\nOh yeah! <noscript>!\n\n<noscript>\n    <img src=\"image.jpg\">\n</noscript>\n\nWhoa! First spacer GIFs and now <noscript>? This really is the future! The image above will only load for users without JavaScript support. Now all we need to do is send JavaScript in there to get the textContent of the <noscript> element, then we can alter the image source before handing it to the DOM for parsing.\n\nHere\u2019s an example of that working \u2026 unless you\u2019re using Internet Explorer.\n\nInternet Explorer doesn\u2019t retain the content of <noscript> elements. As soon as it\u2019s parsed, it considers it an empty element. FANKS INTERNET EXPLORER. This is why some solutions do this:\n\n<noscript data-src=\"image.jpg\">\n    <img src=\"image.jpg\">\n</noscript>\n\nso JavaScript can still get at the URL via the data-src attribute. However, repeating stuff isn\u2019t great. Surely we can do better than that.\n\nA dirty, dirty hack\n\nThankfully, I managed to come up with a solution, and by me, I mean someone cleverer than me. Pornel\u2019s solution uses <noscript>, but surely we don\u2019t need that.\n\nNow, before we look at this, I can\u2019t stress how dirty it is. It\u2019s so dirty that if you\u2019ve seen it, schools will refuse to employ you.\n\n<script>document.write('<' + '!--')</script>\n<img src=\"image.jpg\">\n<!---->\n\nPhwoar! Dirty, isn\u2019t it? I\u2019ll stop for a moment, so you can go have a wash.\n\nDone? Excellent.\n\nWith this, the image is wrapped in a comment only for users with JavaScript. Without JavaScript, we get the image. Unlike the <noscript> example above, we can get the text content of the comment pretty easily.\n\nHurrah! But wait\u2026 Some browsers are sometimes downloading the image, even with JavaScript enabled. Notably Firefox. Huh?\n\nImages are downloaded in comments now? What?\n\nNo. What we\u2019re seeing here is the effect of speculative parsing. Here\u2019s what\u2019s happening:\n\n\n\nWhile the browser is parsing the script, it parses the rest of the document. This is usually a good thing, as it can download subsequent images and scripts without waiting for the script to complete. The problem here is we create an unbalanced tree.\n\n An unbalanced tree, yesterday.\n\nIn this case, the browser must throw away its speculative parsing and reparse from the end of the <script> element, taking our document.write into consideration. Unfortunately, by this stage it may have already discovered the image and sent an HTTP request for it.\n\nA dirty, dirty hack\u2026 that works\n\nPornel was right: we still need the <noscript> element to cater for browsers with speculative parsing.\n\n<script>document.write('<' + '!--')</script><noscript>\n    <img src=\"image.jpg\">\n</noscript -->\n\nAnd there we have it. We can now prevent images loading for users with JavaScript, but we can still get at the markup.\n\nWe\u2019re still creating an unbalanced tree and there\u2019s a performance impact in that. However, the parser won\u2019t have got far by the time our script executes, so the impact is small. Unbalanced trees are more of a concern for external scripts; a lot of parsing can happen by the time the script has downloaded and parsed.\n\nUsing dirtiness to create responsive images\n\nNow all we need to do is give each of our dirty scripts a class name, then JavaScript can pick them up, grab the markup from the comment and decide what to do with the images.\n\nThis technique isn\u2019t exclusively useful for responsive images. It could also be used to delay images loading until they\u2019ve scrolled into view. But to do that you\u2019ll need a bulletproof way of detecting when elements are in view. This involves getting the height of the viewport, which is extremely unreliable on mobile devices.\n\nHere\u2019s a hastily thrown together example showing how it can be used for responsive images.\n\nI adjust the end of the image URLs conditionally depending on the result of media queries. This is done on page load, and on resize.\n\nI\u2019m using regular expressions to alter the URLs. Using regex to deal with HTML is usually a sign of insanity, but parsing it with the browser\u2019s DOM parser would trigger the download of images before we change the URLs. My implementation currently requires double-quoted image URLs, because I\u2019m lazy. Wanna fight about it?\n\nMedia querying via JavaScript\n\nJeremy Keith used document.documentElement.clientWidth in his example, which is great as a proof of concept, but unfortunately is rather unreliable across mobile devices.\n\nThankfully, standards are coming to the rescue with window.matchMedia, which lets us provide a media query string and get a boolean result. There\u2019s even a great polyfill for browsers that don\u2019t support it (as long as they support media queries in CSS).\n\nI didn\u2019t go with that for three reasons:\n\n\n\tI\u2019d like to keep media queries in the CSS file, if possible.\n\tI wanted something a little lighter to keep things speedy while resizing.\n\tIt\u2019s just not dirty enough yet.\n\n\nTo make things ultra-dirty, I add a test element to the page with a specific class, let\u2019s say media-test. Then, I control the width of it using media queries in my CSS file:\n\n@media all and (min-width: 640px) {\n    .media-test {\n        width: 1px;\n    }\n}\n@media all and (min-width: 926px) {\n    .media-test {\n        width: 2px;\n    }\n}\n\nThe JavaScript part changes the URL suffix depending on the width of media-test. I\u2019m using a min-width media query, but you can use others such as pixel-ratio to detect high DPI displays. Basically, it\u2019s a hacky way for CSS to set a value that can be picked up by JavaScript. It means the bit that signals changes to the images sits with the rest of the responsive code, without duplication.\n\nAlso, phwoar, dirty!\n\nThe API\n\nI threw a script together to demonstrate the technique. I\u2019m not particularly attached to it, I\u2019m not even sure I like it, but here\u2019s the API:\n\nresponsiveGallery({\n    // Class name of dirty script element(s) to target\n    scriptClass: 'dirty-gallery-script',\n    // Class name for our test element\n    testClass: 'dirty-gallery-test',\n    // The initial suffix of URLs, the bit that changes.\n    initialSuffix: '-mobile.jpg',\n    // A map of suffixes, for each width of 'dirty-gallery-test'\n    suffixes: {\n        '1': '-desktop.jpg',\n        '2': '-large-desktop.jpg',\n        '3': '-mobile-retina.jpg'\n    }\n});\n\nThe API can cover individual images or multiple galleries at once. In the example I gave at the start of the article I make two calls to the API, one for both galleries, and one for the single image above the video reviews. They\u2019re separate calls because they respond slightly differently.\n\nThe future\n\nHopefully, we\u2019ll get a proper solution to this soon. My favourite suggestion is the <picture> element that Bruce Lawson covers.\n\n<picture alt=\"Angry pirate\">\n    <source src=\"hires.png\" media=\"min-width:800px\">\n    <source src=\"midres.png\" media=\"min-width:480px\">\n    <source src=\"lores.png\">\n    <!-- fallback for browsers without support -->\n    <img src=\"midres.png\" alt=\"Angry pirate\">\n</picture>\n\nUnfortunately, we\u2019re nowhere near that yet, and I\u2019d still rather have my media queries stay in CSS. Perhaps the source elements could be skipped if they\u2019re display:none; then they could have class names and be controlled via CSS. Sigh.\n\nWell, I\u2019m tired of writing now and I\u2019m sure you\u2019re tired of reading. I realize what I\u2019ve presented is a yet another dirty hack to the responsive image problem (perhaps the dirtiest?) and may be completely unfeasible in professional situations. But isn\u2019t that the true spirit of Christmas?\n\nNo.", "year": "2011", "author": "Jake Archibald", "author_slug": "jakearchibald", "published": "2011-12-08T00:00:00+00:00", "url": "https://24ways.org/2011/adaptive-images-for-responsive-designs-again/", "topic": "ux"}
{"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": 274, "title": "Adaptive Images for Responsive Designs", "contents": "So you\u2019ve been building some responsive designs and you\u2019ve been working through your checklist of things to do:\n\n\n\tYou started with the content and designed around it, with mobile in mind first.\n\tYou\u2019ve gone liquid and there\u2019s nary a px value in sight; % is your weapon of choice now.\n\tYou\u2019ve baked in a few media queries to adapt your layout and tweak your design at different window widths.\n\tYou\u2019ve made your images scale to the container width using the fluid Image technique.\n\tYou\u2019ve even done the same for your videos using a nifty bit of JavaScript.\n\n\nYou\u2019ve done a good job so pat yourself on the back. But there\u2019s still a problem and it\u2019s as tricky as it is important: image resolutions.\n\nHTML has an <img> problem\n\nCSS is great at adapting a website design to different window sizes \u2013 it allows you not only to tweak layout but also to send rescaled versions of the design\u2019s images. And you want to do that because, after all, a smartphone does not need a 1,900-pixel background image1.\n\nHTML is less great. In the same way that you don\u2019t want CSS background images to be larger than required, you don\u2019t want that happening with <img>s either. A smartphone only needs a small image but desktop users need a large one. Unfortunately <img>s can\u2019t adapt like CSS, so what do we do?\n\nWell, you could just use a high resolution image and the fluid image technique would scale it down to fit the viewport; but that\u2019s sending an image five or six times the file size that\u2019s really needed, which makes it slow to download and unpleasant to use. Smartphones are pretty impressive devices \u2013 my ancient iPhone 3G is more powerful in every way than my first proper computer \u2013 but they\u2019re still terribly slow in comparison to today\u2019s desktop machines. Sending a massive image means it has to be manipulated in memory and redrawn as you scroll. You\u2019ll find phones rapidly run out of RAM and slow to a crawl.\n\nWell, OK. You went mobile first with everything else so why not put in mobile resolution <img>s too? Because even though mobile devices are rapidly gaining share in your analytics stats, they\u2019re still not likely to be the major share of your user base. I don\u2019t think desktop users would be happy with pokey little mobile resolution images, do you? What we need are adaptive images.\n\nAdaptive image techniques\n\nThere are a number of possible solutions, each with pros and cons, and it\u2019s not as simple to find a graceful solution as you might expect.\n\nYour first thought might be to use JavaScript to trawl through the markup and rewrite the source attribute. That\u2019ll get you the right end result, but it\u2019ll have done it in a way you absolutely don\u2019t want. That\u2019s because of the way browsers load resources. It starts to load the HTML and builds the page on-the-fly; as soon as it finds an <img> element it immediately asks the server for that image. After the HTML has finished loading, the JavaScript will run, change the src attribute, and then the browser will request that new image too. Not instead of, but as well as. Not good: that\u2019s added more bloat instead of cutting it.\n\nPlain JavaScript is out then, which is a problem, because what other tools do we have to work with as web designers? Let\u2019s ignore that for now and I\u2019ll outline another issue with the concept of serving different resolution images for different window widths: a basic file management problem. To request a different image, that image has to exist on the server. How\u2019s it going to get there? That\u2019s not a trivial problem, especially if you have non-technical users that update content through a CMS. Let\u2019s say you solve that \u2013 do you plan on a simple binary switch: big image|little image? Is that really efficient or future-proof? What happens if you have an archive of existing content that needs to behave this way? Can you apply such a solution to existing content or markup?\n\nThere\u2019s a detailed round-up of potential techniques for solving the adaptive images problem over at the Cloud Four blog if you fancy a dig around exploring all the options currently available. But I\u2019m here to show you what I think is the most flexible and easy to implement solution, so here we are.\n\nAdaptive Images\n\nAdaptive Images aims to mitigate most of the issues surrounding the problems of bringing the venerable <img> tag into the 21st century. And it works by leaving that tag completely alone \u2013 just add that desktop resolution image into the markup as you\u2019ve been doing for years now. We\u2019ll fix it using secret magic techniques and bottled pixie dreams. Well, fine: with one .htaccess file, one small PHP file and one line of JavaScript. But you\u2019re killing the mystique with that kind of talk.\n\nSo, what does this solution do?\n\n\n\tIt allows <img>s to adapt to the same break points you use in your media queries, giving granular control in the same way you get with your CSS.\n\tIt installs on your server in five minutes or less and after that is automatic and you don\u2019t need to do anything.\n\tIt generates its own rescaled images on the server and doesn\u2019t require markup changes, so you can apply it to existing web content.\n\tIf you wish, it will make all of your images go mobile-first (just in case that\u2019s what you want if JavaScript and cookies aren\u2019t available).\n\n\nSound good? I hope so. Here\u2019s what you do.\n\nSetting up and rolling out\n\nI\u2019ll assume you have some basic server knowledge along with that wealth of front-end wisdom exploding out of your head: that you know not to overwrite any existing .htaccess file for example, and how to set file permissions on your server. Feeling up to it? Excellent.\n\n\n\tDownload the latest version of Adaptive Images either from the website or from the GitHub repository.\n\tUpload the included .htaccess and adaptive-images.php files into the root folder of your website.\n\tCreate a directory called ai-cache and make sure the server can write to it (CHMOD 755 should do it).\n\tAdd the following line of JavaScript into the <head> of your site:\n\n\n<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+'; path=/\u2018;</script>\n\nThat\u2019s it, unless you want to tweak the default settings. You likely do, but essentially you\u2019re already up and running.\n\nHow it works\n\nAdaptive Images does a number of things depending on the scenario the script has to handle, but here\u2019s a basic overview of what it does when you load a page running it:\n\n\n\tA session cookie is written with the value of the visitor\u2019s screen size in pixels.\n\tThe HTML encounters an <img> tag and sends a request to the server for that image. It also sends the cookie, because that\u2019s how browsers work.\n\tApache sits on the server and receives the request for the image. Apache then has a look in the .htaccess file to see if there are any special instructions for files in the requested URL.\n\tThere are! The .htaccess says \u201cHey, server! Any request you get for a JPG, GIF or PNG file just send to the adaptive-images.php file instead.\u201d\n\tThe PHP file then does some intelligent thinking which can cover a number of scenarios, but I\u2019ll illustrate one path that can happen:\n\n\n\t\n\t\tThe PHP file looks for the cookie and finds out that the user has a maximum screen width of 480px.\n\t\tThe PHP has a look at the available media query sizes that were configured and decides which one matches the user\u2019s device.\n\t\tIt then has a look inside the /ai-cache/480/ folder to see if a rescaled image already exists there.\n\t\tWe\u2019ll pretend it doesn\u2019t \u2013 the PHP then goes to the actual requested URI and finds that the original file does exist.\n\t\tIt has a look to see how wide that image is. If it\u2019s already smaller than the user\u2019s screen width it sends it along and stops there. But, let\u2019s pretend the image is 1,000px wide.\n\t\tThe PHP then resizes the image and saves it into the /ai-cache/480 folder ready for the next time someone needs it.\n\t\n\nIt also does a few other things when needs arise, for example:\n\n\n\tIt sends images with a cache header field that tells proxies not to cache the image, while telling browsers they should. This avoids problems with proxy servers and network caching systems grabbing the wrong image and storing it.\n\tIt handles cases where there isn\u2019t a cookie set, and you can choose whether to then send the mobile version or the largest configured media query size.\n\tIt compares timestamps between the source image and the generated cache image \u2013 to ensure that if the source image gets updated, the old cached file won\u2019t be sent.\n\n\nCustomizing\n\nThere are a few options you can customize if you don\u2019t like the default values. By looking in the PHP\u2019s configuration section at the top of the file, you can:\n\n\n\tSet the resolution breakpoints to match your media query break points.\n\tChange the name and location of the ai-cache folder.\n\tChange the quality level any generated JPG images are saved at.\n\tHave it perform a subtle sharpen on rescaled images to help keep detail.\n\tToggle whether you want it to compare the files in the cache folder with the source ones or not.\n\tSet how long the browser should cache the images for.\n\tSwitch between a mobile-first or desktop-first approach when a cookie isn\u2019t found.\n\n\nMore importantly, you probably want to omit a few folders from the AI behaviour. You don\u2019t need or want it resizing the images you\u2019re using in your CSS, for example. That\u2019s fine \u2013 just open up the .htaccess file and follow the instructions to list any directories you want AI to ignore. Or, if you\u2019re a dab hand at RewriteRules you can remove the exclamation mark at the start of the rule and it\u2019ll only apply AI behaviour to a given list of folders.\n\nCaveats\n\nAs I mentioned, I think this is one of the most flexible, future-proof, retrofittable and easy to use solutions available today. But, there are problems with this approach as there are with all of the ones I\u2019ve seen so far.\n\nThis is a PHP solution\n\nI wish I was smarter and knew some fancy modern languages the cool kids discuss at parties, but I don\u2019t. So, you need PHP on your server. That said, Adaptive Images has a Creative Commons licence2 and I would welcome anyone to contribute a port of the code3. \n\nContent delivery networks\n\nAdaptive Images relies on the server being able to: intercept requests for images; do some logic; and send one of a given number of responses. Content delivery networks are generally dumb caches, and they won\u2019t allow that to happen. Adaptive Images will not work if you\u2019re using a CDN to deliver your website.\n\nA minor but interesting cookie issue.\n\nAs Yoav Weiss pointed out in his article Preloaders, cookies and race conditions, there is no way to guarantee that a cookie will be set before images are requested \u2013 even though the JavaScript that sets the cookie is loaded by the browser before it finds any <img> tags. That could mean images being requested without a cookie being available. Adaptive Images has a two-fold mechanism to avoid this being a problem:\n\n\n\tThe $mobile_first toggle allows you to choose what to send to a browser if a cookie isn\u2019t set. If FALSE then it will send the highest configured resolution; if TRUE it will send the lowest.\n\tEven if set to TRUE, Adaptive Images checks the User Agent String. If it discovers the user is on a desktop environment, it will override $mobile_first and set it to FALSE.\n\n\nThis means that if $mobile_first is set to TRUE and the user was unlucky (their browser didn\u2019t write the cookie fast enough), mobile devices will be supplied with the smallest image, and desktop devices will get the largest.\n\nThe best way to get a cookie written is to use JavaScript as I\u2019ve explained above, because it\u2019s the fastest way. However, for those that want it, there is a JavaScript-free method which uses CSS and a bogus PHP \u2018image\u2019 to set the cookie. A word of caution: because it requests an external file, this method is slower than the JavaScript one, and it is very likely that the cookie won\u2019t be set until after images have been requested.\n\nThe future\n\nFor today, this is a pretty good solution. It works, and as it doesn\u2019t interfere with your markup or source material in any way, the process is non-destructive. If a future solution is superior, you can just remove the Adaptive Images files and you\u2019re good to go \u2013 you\u2019d never know AI had been there.\n\nHowever, this isn\u2019t really a long-term solution, not least because of the intermittent problem of the cookie and image request race condition. What we really need are a number of standardized ways to handle this in the future.\n\nFirst, we could do with browsers sending far more information about the user\u2019s environment along with each HTTP request (device size, connection speed, pixel density, etc.), because the way things work now is no longer fit for purpose. The web now is a much broader entity used on far more diverse devices than when these technologies were dreamed up, and we absolutely require the server to have better knowledge about device capabilities than is currently possible. Relying on cookies to do this job doesn\u2019t cut it, and the User Agent String is a complete mess incapable of fulfilling the various purposes we are forced to hijack it for.\n\nSecondly, we need a W3C-backed markup level solution to supply semantically different content at different resolutions, not just rescaled versions of the same content as Adaptive Images does.\n\nI hope you\u2019ve found this interesting and will find Adaptive Images useful.\n\nFootnotes\n\n1 While I\u2019m talking about preventing smartphones from downloading resources they don\u2019t need: you should be careful of your media query construction if you want to stop WebKit downloading all the images in all of the CSS files.\n\n2 Adaptive Images has a very broad Creative Commons licence and I warmly welcome feedback and community contributions via the GitHub repository. \n\n3 There is a ColdFusion port of an older version of Adaptive Images. I do not have anything to do with ported versions of Adaptive Images.", "year": "2011", "author": "Matt Wilcox", "author_slug": "mattwilcox", "published": "2011-12-04T00:00:00+00:00", "url": "https://24ways.org/2011/adaptive-images-for-responsive-designs/", "topic": "ux"}
{"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<body dir=\"rtl\">\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<body dir=\"ltr\">\n   Here is English Content.\n   <div dir=\"rtl\">\u0627\u0644\u0645\u0648\u0636\u0648\u0639</div>\n</body>\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": 280, "title": "Conditional Loading for Responsive Designs", "contents": "On the eighteenth day of last year\u2019s 24 ways,  Paul Hammond  wrote a great article called Speed Up Your Site with Delayed Content. He outlined a technique for loading some content \u2014 like profile avatars \u2014 after the initial page load. This gives you a nice performance boost.\n\nThere\u2019s another situation where this kind of delayed loading could be really handy: mobile-first responsive design.\n\nResponsive design combines three techniques:\n\n\n\ta fluid grid\n\tflexible images\n\tmedia queries\n\n\nAt first, responsive design was applied to existing desktop-centric websites to allow the layout to adapt to smaller screen sizes. But more recently it has been combined with another innovative approach called mobile first.\n\nRather then starting with the big, bloated desktop site and then scaling down for smaller devices, it makes more sense to start with the constraints of the small screen and then scale up for larger viewports. Using this approach, your layout grid, your large images and your media queries are applied on top of the pre-existing small-screen design. It\u2019s taking progressive enhancement to the next level.\n\nOne of the great advantages of the mobile-first approach is that it forces you to really focus on the core content of your page. It might be more accurate to think of this as a content-first approach. You don\u2019t have the luxury of sidebars or multiple columns to fill up with content that\u2019s just nice to have rather than essential.\n\nBut what happens when you apply your media queries for larger viewports and you do have sidebars and multiple columns? Well, you can load in that nice-to-have content using the same kind of Ajax functionality that Paul described in his article last year. The difference is that you first run a quick test to see if the viewport is wide enough to accommodate the subsidiary content. This is conditional delayed loading.\n\nConsider this situation: I\u2019ve published an article about cats and I\u2019d like to include relevant cat-related news items in the sidebar \u2026but only if there\u2019s enough room on the screen for a sidebar.\n\nI\u2019m going to use Google\u2019s News API to return the search results. This is the ideal time to use delayed loading: I don\u2019t want a third-party service slowing down the rendering of my page so I\u2019m going to fire off the request after my document has loaded.\n\nHere\u2019s an example of the kind of Ajax function that I would write:\n\nvar searchNews = function(searchterm) {\n\tvar elem = document.createElement('script');\n\telem.src = 'http://ajax.googleapis.com/ajax/services/search/news?v=1.0&q='+searchterm+'&callback=displayNews';\n\tdocument.getElementsByTagName('head')[0].appendChild(elem);\n};\n\nI\u2019ve provided a callback function called displayNews that takes the JSON result of that Ajax request and adds it an element on the page with the ID newsresults:\n\nvar displayNews = function(news) {\n\tvar html = '',\n\titems = news.responseData.results,\n\ttotal = items.length;\n\tif (total>0) {\n\t\tfor (var i=0; i<total; i++) {\n\t\t\tvar item = items[i];\n\t\t\thtml+= '<article>';\n\t\t\thtml+= '<a href=\"'+item.unescapedUrl+'\">';\n\t\t\thtml+= '<h3>'+item.titleNoFormatting+'</h3>';\n\t\t\thtml+= '</a>';\n\t\t\thtml+= '<p>';\n\t\t\thtml+= item.content;\n\t\t\thtml+= '</p>';\n\t\t\thtml+= '</article>';\n\t\t}\n\t\tdocument.getElementById('newsresults').innerHTML = html;\n\t}\n};\n\nNow, I can call that function at the bottom of my document:\n\n<script>\n    searchNews('cats');\n</script>\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<script>\nif (document.documentElement.clientWidth > 640) {\n    searchNews('cats');\n}\n</script>\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<div id=\"newsresults\">\n    <!-- search results go here -->\n</div>\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<div id=\"newsresults\">\n    <a href=\"http://www.google.com/search?q=cats&tbm=nws\">Search Google News</a>\n</div>\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": 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"}