{"rowid": 13, "title": "Data-driven Design with an Annual Survey", "contents": "Too often, we base designs on assumptions that don\u2019t match customer perspectives. Why? Because the data we need to make informed decisions isn\u2019t available.\n\nImagine starting off the year with a treasure trove of user data that can be filtered, sliced, and diced to inform new UI designs, help you discover where users struggle the most, and expose emerging trends in your customers\u2019 needs that could lead to new features. Why, that would be useful indeed. And it\u2019s easy to obtain by conducting an annual survey.\n\nAnnual surveys may seem as exciting as receiving socks and undies for Christmas, but they\u2019re the gift that keeps on giving all year long (just like fresh socks and undies). I\u2019m not ashamed to admit it: I love surveys! Each time my design research team runs a survey, we learn so much about customer motivations, interests, and behaviors. \n\nSurveys provide an aggregate snapshot of your users that can\u2019t easily be obtained by other research methods, and they can be conducted quickly too. You can build a survey in a few hours, run a pilot test in a day, and have real results streaming in the following day. Speed is essential if design research is going to keep pace with a busy product release schedule. \n\nSurveys are also an invaluable springboard for customer interviews, which provide deep perspectives on user behavior. If you play your cards right as you construct your survey, you can capture a user ID and an email address for each respondent, making it easy to get in touch with customers whose feedback is particularly intriguing. No more recruiting customers for your research via Twitter or through a recruiting company charging a small fortune. You can filter survey responses and isolate the exact customers to talk with in moments, not months.\n\nI love this connected process of sending targeted surveys, filtering the results, and then \u2014 with surgical precision \u2014 selecting just the right customers to interview. Not only is it fast and cheap, but it lets design researchers do quantitative and qualitative research in a coordinated way. Aggregate survey responses help you quantify the perspectives of different user segments, and interviews help you get into the heads of your customers.\n\nAn annual survey can give your team the data needed to make more informed designs in the new year. It all starts with a plan.\n\nPlanning your survey\n\nBefore you start jotting down questions to ask users, spend some time thinking about the work your team will be doing in the coming year. Are you planning new mobile apps or a responsive redesign? Then questions about devices used and behaviors around mobile devices might be in order. Rethinking your content strategy? Then you might want to ask a few questions about how your customers consume content.\n\nYou can\u2019t predict all of the projects you\u2019ll be working on in the coming year, but tuck a couple of sections in your survey about the projects you\u2019re certain about. This will give you the research you need to start new projects with solid foundational data.\n\nGoogle Drive is a great place to start collaboratively building survey questions with colleagues. Questions that seem crystal clear in your head get challenged, refined, or even expanded quickly when the entire team can chime in. \n\nAs you craft your survey, try to consider how you\u2019ll filter it once all of the data is compiled. Do you need to see responses by industry, by age of an account, by devices used, or by size of company? Adding the right filter questions can help you discover fascinating patterns in user segments. Filtering on responses to a few questions can surface insights like: customers in non-profit companies with more than 100 employees are 17% more likely to use an Android phone and are most attracted to features A, D, and F. A designer working on the landing page for a non-profit would love to have concrete information like this. Filter questions are key, so consider them carefully. But don\u2019t go overboard \u2014 too many of them and you\u2019ll start to hurt your survey response rate.\n\nMultiple choice questions are the heart of most surveys because respondents can complete them quickly, which increases response rate, and researchers can analyze them without a lot of manual categorization. Open text field questions are valuable too, but be careful not to add too many to your survey. You\u2019ll hate yourself after the survey\u2019s done and you have to sort through and tag thousands of open responses so patterns become visible. Oy vey!\n\nAn open-ended question works well towards the end of the survey. At this point respondents have a lot of topics swirling around in their head and tend to say weird things that will pique your interest. This is where you\u2019ll find the outliers who are using your product. They\u2019ll be fascinating to interview, and on occasion will help you see your work in a brand new way.\n\nConclude your survey with a question asking permission to get in touch for a followup interview so you don\u2019t pester people who want to be left alone. \n\nWith your questions nailed down, it\u2019s time to build out that survey and get it ready for sending!\n\nBuilding your survey\n\nThere are dozens of apps you could use to build your survey, but SurveyMonkey is the one that I prefer. It lets you pass in variables for each respondent such as user ID and email address. Metadata about respondents is essential if you\u2019re going to do any follow-up interviews with your customers in the coming year. SurveyMonkey also makes it easy to set up question logic, showing questions to customers only if they responded in a certain way to a prior question. This helps you avoid asking irrelevant questions to some respondents.\n\nDetermining survey recipients\n\nOnce you\u2019ve chosen a survey tool and entered all of your questions, you need to gather a list of recipients. Your first instinct will be to send it to everyone. You might say, \u201cI need maximum response and metric shit tons of data!\u201d But this is rarely the best approach \u2014 broad distribution almost always leads to lower response rates, increased noise, and decreased signal in your data. Are there subsets of customers you could send to, like only those who are active, those who are paying, or have been with you for a certain length of time? Talk to the keepers of your customer database and see how they can segment it so you can be certain you\u2019re talking to just the people who will have the most relevant responses for your needs. \n\nIf you want to get super nerdy when finding the right customer sample to survey, use a [sample size calculator]. Sampling is a deep subject best explored in other articles. \n\nCrafting your survey email\n\nAfter focusing your energies on writing and building your survey, the email asking your customers to respond seems almost trivial, but it will greatly influence your response rate. Take great care when writing your subject line and the body of the email. If you can pull it off, A/B testing subject lines can greatly improve the open rate of your email and click-through to your survey. My design research team has seen a ~10% increase in open and click rates when we A/B tested. We\u2019ve found that personalizing subject lines and greetings with the recipients name (ie. \u201cHey, Aarron. How can we make our app work better for you?\u201d) gave us the best response rates. Your mileage may vary.\n\nThe tone of your email is important \u2014 be friendly, honest, and to the point. Those that are passionate about your product will be happy to share their perspective. Writing a survey email that people will actually respond to ain\u2019t easy \u2014 in fact, they\u2019re almost always annoying. But Ben Chestnut found a non-annoying way to send a survey email and improve response rates.\n\nThe email sent for the 2013 MailChimp survey let customers know what we\u2019d been up to in the previous year, and invited feedback on what we should work on in the coming year.\n\nThe link to your survey should be a clear call to action. A big button with a label like \u201cAnswer a few questions\u201d generally does the trick. The URL linking to the survey will need to include some variables like user ID and email. It might look something like this if you\u2019re using SurveyMonkey:\n\nhttp://surveymonkey.com/s/somesurveyid/?uid=*|UID|*&email=*|email|*\n\nAs each email is sent, the proper data will be populated in the variables, passing it on to the survey app for inclusion in each response. This is the magic that will help you pinpoint customers to interview down the road, so take special care to test that all is working before sending to all recipients. How you construct the survey link will vary depending on what survey tool and email service provider you use, so don\u2019t take my example as gospel. You\u2019ll need to read the documentation for your survey and email apps to set things up properly.\n\nPilot before sending\n\nBy now, you\u2019ve whipped yourself into a fever pitch over your brilliant survey and the data you hope to collect. Your finger is on the send button, poised for action, but there\u2019s one very important thing to do before you send to the entire list of customers: send a pilot email. How do you know if your questions are clear, your form logic is sound, and you\u2019re passing variables from the email to the survey properly? You won\u2019t, unless you send to a small segment of your recipients first. \n\nThe data collected in your pilot will make plain where your survey needs refinement. This data won\u2019t be used in your final analysis, as you\u2019re probably going to make a few changes to your questions.\n\nSend the pilot survey to enough people that you can really stress test the clarity of the questions and data you\u2019re gathering, while considering how much data can you comfortably throw out. If you\u2019re sending your final survey to a few thousand people, you might find a couple of hundred recipients for your pilot will give you enough insight into what to improve while leaving the vast majority of the recipients for your final survey.\n\nAfter you\u2019ve sent your pilot, made your survey adjustments, and ensured the variables are being passed from your email into the survey app, you\u2019re ready to send to the remainder of your customers. This is your moment of glory!\n\nAnalyzing your results\n\nAfter a couple of weeks you can probably safely close the survey so no other responses come in as you transition from data gathering to data analysis. Any survey app worth its salt will chart responses to your multiple choice questions. Reviewing these charts is a great place to start your analysis. Is there anything particularly interesting that stands out? Jot down some of your observations. I like to print screenshots of the charts for each question, highlighting areas of interest. These prints become a particularly handy reference point for the next step in your analysis. \n\nPrinting results from a survey makes comparing different customers easy.\n\nViewing aggregate data about all responses is interesting, but the deltas between different types of customers are where the real revelations happen. Remember those filter questions you added to your survey? They\u2019re the tool that\u2019ll help you compare customer segments.\n\nMost survey apps will let you filter the data based on response to a question. If the one you\u2019re using doesn\u2019t, you can always export your data and create pivot tables in Excel. Try filtering your data based on one of your filter questions, such as industry, company size, or devices used. Now compare those printed screenshots of baseline responses to the filtered data. Chances are you\u2019ll see some significant differences in how each group responded to your questions, giving you clues about the variance in interests and motivations in customer segments and a leg up as you work on future design projects. \n\nOpen-ended responses are equally interesting, but much more time-consuming to analyze. Yes, you need to read through thousands of responses, some of which are constructive and some of which are not. Taking the time to tag each open response will help you see trends and filter out the responses that are unhelpful.\n\nUnlike questions with predefined answers, open-ended responses let users express unique ideas and use cases you may not be looking for. The tedium of reading thousands of response is always cut by eureka moments when users tell you something fascinating that changes your perspective on your app. These are the folks you want to pull out for follow-up interviews. Because you\u2019ve already captured their email addresses when you set up your survey and your email, getting in touch will be a piece of cake.\n\nFilter, compare, interview, and summarize; then share your findings with your colleagues. Reports are great for head honchos, but if you want to really inform and inspire, create a video, a poster series, or even a comic to communicate what you\u2019ve learned. Want to get really fancy? Store your survey results in a centrally accessible location so anyone in your company can research and discover the insights they need to make more informed designs. \n\nGood design researchers discover valuable insights. Great design researchers turn those insights into stories.\n\nConclusion\n\nAs we enter the new year, it\u2019s a great time to reflect on the work we\u2019ve done in the past and how we can do better in the future. Without a doubt, designers working with a foundation of insights about customers can make more effective UIs. But designers aren\u2019t the only ones who stand to gain from the data collected in an annual survey\u2014anyone who makes things for or communicates with customers will find themselves empowered to do better work when they know more about the people they serve. The data you collect with your survey is a fantastic holiday gift to your colleagues, one that they\u2019ll appreciate throughout the year.", "year": "2013", "author": "Aarron Walter", "author_slug": "aarronwalter", "published": "2013-12-13T00:00:00+00:00", "url": "https://24ways.org/2013/data-driven-design-with-an-annual-survey/", "topic": "design"}
{"rowid": 193, "title": "Web Content Accessibility Guidelines\u2014for People Who Haven't Read Them", "contents": "I\u2019ve been a huge fan of the Web Content Accessibility Guidelines 2.0 since the World Wide Web Consortium (W3C) published them, nine years ago. I\u2019ve found them practical and future-proof, and I\u2019ve found that they can save a huge amount of time for designers and developers. You can apply them to anything that you can open in a browser. My favourite part is when I use the guidelines to make a website accessible, and then attend user-testing and see someone with a disability easily using that website.\nToday, the United Nations International Day of Persons with Disabilities, seems like a good time to re-read Laura Kalbag\u2019s explanation of why we should bother with accessibility. That should motivate you to devour this article.\nIf you haven\u2019t read the Web Content Accessibility Guidelines 2.0, you might find them a bit off-putting at first. The editors needed to create a single standard that countries around the world could refer to in legislation, and so some of the language in the guidelines reads like legalese. The editors also needed to future-proof the guidelines, and so some terminology\u2014such as \u201ctime-based media\u201d and \u201cprogrammatically determined\u201d\u2014can sound ambiguous. The guidelines can seem lengthy, too: printing the guidelines, the Understanding WCAG 2.0 document, and the Techniques for WCAG 2.0 document would take 1,200 printed pages.\nThis festive season, let\u2019s rip off that legalese and ambiguous terminology like wrapping paper, and see\u2014in a single article\u2014what gifts the Web Content Accessibility Guidelines 2.0 editors have bestowed upon us.\nCan your users perceive the information on your website?\nThe first guideline has criteria that help you prevent your users from asking \u201cWhat the **** is this thing here supposed to be?\u201d\n1.1.1 Text is the most accessible format for information. Screen readers\u2014such as the \u201cVoiceOver\u201d setting on your iPhone or the \u201cTalkBack\u201d app on your Android phone\u2014understand text better than any other format. The same applies for other assistive technology, such as translation apps and Braille displays. So, if you have anything on your webpage that\u2019s not text, you must add some text that gives your user the same information. You probably know how to do this already; for example:\n\nfor images in webpages, put some alternative text in an alt attribute to tell your user what the image conveys to the user;\nfor photos in tweets, add a description to make the images accessible;\nfor Instagram posts, write a caption that conveys the photo\u2019s information.\n\nThe alternative text should allow the user to get the same information as someone who can see the image. For websites that have too many images for someone to add alternative text to, consider how machine learning and Dynamically Generated Alt Text might\u2014might\u2014be appropriate.\nYou can probably think of a few exceptions where providing text to describe an image might not make sense. Remember I described these guidelines as \u201cpractical\u201d? They cover all those exceptions:\n\nUser interface controls such as buttons and text inputs must have names or labels to tell your user what they do.\nIf your webpage has video or audio (more about these later on!), you must\u2014at least\u2014have text to tell the user what they are.\nMaybe your webpage has a test where your user has to answer a question about an image or some audio, and alternative text would give away the answer. In that case, just describe the test in text so your users know what it is.\nIf your webpage features a work of art, tell your user the experience it evokes.\nIf you have to include a Captcha on your webpage\u2014and please avoid Captchas if at all possible, because some users cannot get past them\u2014you must include text to tell your user what it is, and make sure that it doesn\u2019t rely on only one sense, such as vision.\nIf you\u2019ve included something just as decoration, you must make sure that your user\u2019s assistive technology can ignore it. Again, you probably know how to do this. For example, you could use CSS instead of HTML to include decorative images, or you could add an empty alt attribute to the img element. (Please avoid that recent trend where developers add empty alt attributes to all images in a webpage just to make the HTML validate. You\u2019re better than that.)\n\n(Notice that the guidelines allow you to choose how to conform to them, with whatever technology you choose. To make your website conform to a guideline, you can either choose one of the techniques for WCAG 2.0 for that guideline or come up with your own. Choosing a tried-and-tested technique usually saves time!)\n1.2.1 If your website includes a podcast episode, speech, lecture, or any other recorded audio without video, you must include a transcription or some other text to give your user the same information. In a lot of cases, you might find this easier than you expect: professional transcription services can prove relatively inexpensive and fast, and sometimes a speaker or lecturer can provide the speech or lecture notes that they read out word-for-word. Just make sure that all your users can get the same information and the same results, whether they can hear the audio or not. For example, David Smith and Marco Arment always publish episode transcripts for their Under the Radar podcast. \nSimilarly, if your website includes recorded video without audio\u2014such as an animation or a promotional video\u2014you must either use text to detail what happens in the video or include an audio version. Again, this might work out easier then you perhaps fear: for example, you could check to see whether the animation started life as a list of instructions, or whether the promotional video conveys the same information as the \u201cAbout Us\u201d webpage. You want to make sure that all your users can get the same information and the same results, whether they can see that video or not.\n1.2.2 If your website includes recorded videos with audio, you must add captions to those videos for users who can\u2019t hear the audio. Professional transcription services can provide you with time-stamped text in caption formats that YouTube supports, such as .srt and .sbv. You can upload those to YouTube, so captions appear on your videos there. YouTube can auto-generate captions, but the quality varies from impressively accurate to comically inaccurate. If you have a text version of what the people in the video said\u2014such as the speech that a politician read or the bedtime story that an actor read\u2014you can create a transcript file in .txt format, without timestamps. YouTube then creates captions for your video by synchronising that text to the audio in the video. If you host your own videos, you can ask a professional transcription service to give you .vtt files that you can add to a video element\u2019s track element\u2014or you can handcraft your own. (A quick aside: if your website has more videos than you can caption in a reasonable amount of time, prioritise the most popular videos, the most important videos, and the videos most relevant to people with disabilities. Then make sure your users know how to ask you to caption other videos as they encounter them.)\n1.2.3 If your website has recorded videos that have audio, you must add an \u201caudio description\u201d narration to the video to describe important visual details, or add text to the webpage to detail what happens in the video for users who cannot see the videos. (I like to add audio files from videos to my Huffduffer account so that I can listen to them while commuting.) Maybe your home page has a video where someone says, \u201cI\u2019d like to explain our new TPS reports\u201d while \u201cBill Lumbergh, division Vice President of Initech\u201d appears on the bottom of the screen. In that case, you should add an audio description to the video that announces \u201cBill Lumbergh, division Vice President of Initech\u201d, just before Bill starts speaking. As always, you can make life easier for yourself by considering all of your users, before the event: in this example, you could ask the speaker to begin by saying, \u201cI\u2019m Bill Lumbergh, division Vice President of Initech, and I\u2019d like to explain our new TPS reports\u201d\u2014so you won\u2019t need to spend time adding an audio description afterwards. \n1.2.4 If your website has live videos that have some audio, you should get a stenographer to provide real-time captions that you can include with the video. I\u2019ll be honest: this can prove tricky nowadays. The Web Content Accessibility Guidelines 2.0 predate YouTube Live, Instagram live Stories, Periscope, and other such services. If your organisation creates a lot of live videos, you might not have enough resources to provide real-time captions for each one. In that case, if you know the contents of the audio beforehand, publish the contents during the live video\u2014or failing that, publish a transcription as soon as possible.\n1.2.5 Remember what I said about the recorded videos that have audio? If you can choose to either add an audio description or add text to the webpage to detail what happens in the video, you should go with the audio description.\n1.2.6 If your website has recorded videos that include audio information, you could provide a sign language version of the audio information; some people understand sign language better than written language. (You don\u2019t need to caption a video of a sign language version of audio information.)\n1.2.7 If your website has recorded videos that have audio, and you need to add an audio description, but the audio doesn\u2019t have enough pauses for you to add an \u201caudio description\u201d narration, you could provide a separate version of that video where you have added pauses to fit the audio description into.\n1.2.8 Let\u2019s go back to the recorded videos that have audio once more! You could add text to the webpage to detail what happens in the video, so that people who can neither read captions nor hear dialogue and audio description can use braille displays to understand your video.\n1.2.9 If your website has live audio, you could get a stenographer to provide real-time captions. Again, if you know the contents of the audio beforehand, publish the contents during the live audio or publish a transcription as soon as possible.\n(Congratulations on making it this far! I know that seems like a lot to remember, but keep in mind that we\u2019ve covered a complex area: helping your users to understand multimedia information that they can\u2019t see and/or hear. Grab a mince pie to celebrate, and let\u2019s keep going.)\n1.3.1 You must mark up your website\u2019s content so that your user\u2019s browser, and any assistive technology they use, can understand the hierarchy of the information and how each piece of information relates to the rest. Once again, you probably know how to do this: use the most appropriate HTML element for each piece of information. Mark up headings, lists, buttons, radio buttons, checkboxes, and links with the most appropriate HTML element. If you\u2019re looking for something to do to keep you busy this Christmas, scroll through the list of the elements of HTML. Do you notice any elements that you didn\u2019t know, or that you\u2019ve never used? Do you notice any elements that you could use on your current projects, to mark up the content more accurately? Also, revise HTML table advanced features and accessibility, how to structure an HTML form, and how to use the native form widgets\u2014you might be surprised at how much you can do with just HTML! Once you\u2019ve mastered those, you can make your website much more usable for your all of your users.\n1.3.2 If your webpage includes information that your user has to read in a certain order, you must make sure that their browser and assistive technology can present the information in that order. Don\u2019t rely on CSS or whitespace to create that order visually. Check that the order of the information makes sense when CSS and whitespace aren\u2019t formatting it. Also, try using the Tab key to move the focus through the links and form widgets on your webpage. Does the focus go where you expect it to? Keep this in mind when using order in CSS Grid or Flexbox.\n1.3.3 You must not presume that your users can identify sensory characteristics of things on your webpage. Some users can\u2019t tell what you\u2019ve positioned where on the screen. For example, instead of asking your users to \u201cChoose one of the options on the left\u201d, you could ask them to \u201cChoose one of our new products\u201d and link to that section of the webpage.\n1.4.1 You must not rely on colour as the only way to convey something to your users. Some of your users can\u2019t see, and some of your users can\u2019t distinguish between colours. For example, if your webpage uses green to highlight the products that your shop has in stock, you could add some text to identify those products, or you could group them under a sub-heading.\n1.4.2  If your webpage automatically plays a sound for more than 3 seconds, you must make sure your users can stop the sound or change its volume. Don\u2019t rely on your user turning down the volume on their computer; some users need to hear the screen reader on their computer, and some users just want to keep listening to whatever they were listening before your webpage interrupted them!\n1.4.3 You should make sure that your text contrasts enough with its background, so that your users can read it. Bookmark Lea Verou\u2019s Contrast Ratio calculator now. You can enter the text colour and background colour as named colours, or as RGB, RGBa, HSL, or HSLa values. You should make sure that:\n\nnormal text that set at 24px or larger has a ratio of at least 3:1;\nbold text that set at 18.75px or larger has a ratio of at least 3:1;\nall other text has a ratio of at least 4\u00bd:1.\n\nYou don\u2019t have to do this for disabled form controls, decorative stuff, or logos\u2014but you could!\n1.4.4 You should make sure your users can resize the text on your website up to 200% without using their assistive technology\u2014and still access all your content and functionality. You don\u2019t have to do this for subtitles or images of text.\n1.4.5 You should avoid using images of text and just use text instead. In 1998, Jeffrey Veen\u2019s first Hot Design Tip said, \u201cText is text. Graphics are graphics. Don\u2019t confuse them.\u201d Now that you can apply powerful CSS text-styling properties, use CSS Grid to precisely position text, and choose from thousands of web fonts (Jeffrey co-founded Typekit to help with this), you pretty much never need to use images of text. The guidelines say you can use images of text if you let your users specify the font, size, colour, and background of the text in the image of text\u2014but I\u2019ve never seen that on a real website. Also, this doesn\u2019t apply to logos.\n1.4.6 Let\u2019s go back to colour contrast for a second. You could make your text contrast even more with its background, so that even more of your users can read it. To do that, use Lea Verou\u2019s Contrast Ratio calculator to make sure that:\n\nnormal text that is 24px or larger has a ratio of at least 4\u00bd:1;\nbold text that 18.75px or larger has a ratio of at least 4\u00bd:1;\nall other text has a ratio of at least 7:1.\n\n1.4.7 If your website has recorded speech, you could make sure there are no background sounds, or that your users can turn off any background sounds. If that\u2019s not possible, you could make sure that any background sounds that last longer than a couple of seconds are at least four times quieter than the speech. This doesn\u2019t apply to audio Captchas, audio logos, singing, or rapping. (Yes, these guidelines mention rapping!)\n1.4.8 You could make sure that your users can reformat blocks of text on your website so they can read them better. To do this, make sure that your users can:\n\nspecify the colours of the text and the background, and\nmake the blocks of text less than 80-characters wide, and \nalign text to the left (or right for right-to-left languages), and \nset the line height to 150%, and \nset the vertical distance between paragraphs to 1\u00bd times the line height of the text, and \nresize the text (without using their assistive technology) up to 200% and still not have to scroll horizontally to read it.\n\nBy the way, when you specify a colour for text, always specify a colour for its background too. Don\u2019t rely on default background colours!\n1.4.9 Let\u2019s return to images of text for a second. You could make sure that you use them only for decoration and logos.\nCan users operate the controls and links on your website?\nThe second guideline has criteria that help you prevent your users from asking, \u201cHow the **** does this thing work?\u201d\n2.1.1 You must make sure that you users can carry out all of your website\u2019s activities with just their keyboard, without time limits for pressing keys. (This doesn\u2019t apply to drawing or anything else that requires a pointing device such as a mouse.) Again, if you use the most appropriate HTML element for each piece of information and for each form element, this should prove easy.\n2.1.2 You must make sure that when the user uses the keyboard to focus on some part of your website, they can then move the focus to some other part of your webpage without needing to use a mouse or touch the screen. If your website needs them to do something complex before they can move the focus elsewhere, explain that to your user. These \u201ckeyboard traps\u201d have become rare, but beware of forms that move focus from one text box to another as soon as they receive the correct number of characters.\n2.1.3 Let\u2019s revisit making sure that you users can carry out all of your website\u2019s activities with just their keyboard, without time limits for pressing keys. You could make sure that your user can do absolutely everything on your website with just the keyboard.\n2.2.1 Sometimes people need more time than you might expect to complete a task on your website. If any part of your website imposes a time limit on a task, you must do at least one of these: \n\nlet your users turn off the time limit before they encounter it; or\nlet your users increase the time limit to at least 10 times the default time limit before they encounter it; or\nwarn your users before the time limit expires and give them at least 20 seconds to extend it, and let them extend it at least 10 times.\n\nRemember: these guidelines are practical. They allow you to enforce time limits for real-time events such as auctions and ticket sales, where increasing or extending time limits wouldn\u2019t make sense. Also, the guidelines allow you to enforce a maximum time limit of 20 hours. The editors chose 20 hours because people need to go to sleep at some stage. See? Practical!\n2.2.2 In my experience, this criterion remains the least well-known\u2014even though some users can only use websites that conform to it. If your website presents content alongside other content that can distract users by automatically moving, blinking, scrolling, or updating, you must make sure that your users can:\n\npause, stop, or hide the other content if it\u2019s not essential and lasts more than 5 seconds; and\npause, stop, hide, or control the frequency of the other content if it automatically updates.\n\nIt\u2019s OK if your users miss live information such as stock price updates or football scores; you can\u2019t do anything about that! Also, this doesn\u2019t apply to animations such as progress bars that you put on a website to let all users know that the webpage isn\u2019t frozen.\n(If this one sounds complex, just add a pause button to anything that might distract your users.)\n2.2.3 Let\u2019s go back to time limits on tasks on your website. You could   make your website even easier to use by removing all time limits except those on real-time events such as auctions and ticket sales. That would mean your user wouldn\u2019t need to interact with a timer at all.\n2.2.4 You could let your users turn off all interruptions\u2014server updates, promotions, and so on\u2014apart from any emergency information.\n2.2.5 This is possibly my favourite of these criteria! After your website logs your user out, you could make sure that when they log in again, they can continue from where they were without having lost any information. Do that, and you\u2019ll be on everyone\u2019s Nice List this Christmas.\n2.3.1 You must make sure that nothing flashes more than three times a second on your website, unless you can make sure that the flashes remain below the acceptable general flash and red flash thresholds\u2026\n2.3.2 \u2026or you could just make sure that nothing flashes more than three times per second on your website. This is usually an easier goal.\n2.4.1 You must make sure that your users can jump past any blocks of content, such as navigation menus, that are repeated throughout your website. You know the drill here: using HTML\u2019s sectioning elements such as header, nav, main, aside, and footer allows users with assistive technology to go straight to the content they need, and adding \u201cSkip Navigation\u201d links allows everyone to get to your main content faster.\n2.4.2 You must add a proper title to describe each webpage\u2019s topic. Your webpage won\u2019t even validate without a title element, so make it a useful one.\n2.4.3 If your users can focus on links and native form widgets, you must make sure that they can focus on elements in an order that makes sense.\n2.4.4 You must make sure that your users can understand the purpose of a link when they read:\n\nthe text of the link; or\nthe text of the paragraph, list item, table cell, or table header for the cell that contains the link; or\nthe heading above the link.\n\nYou don\u2019t have to do that for games and quizzes.\n2.4.5 You should give your users multiple ways to find any webpage within a set of webpages. Add site-wide search and a site map and you\u2019re done!\nThis doesn\u2019t apply for a webpage that is part of a series of actions (like a shopping cart and checkout flow) or to a webpage that is a result of a series of actions (like a webpage confirming that the user has bought what was in the shopping cart).\n2.4.6 You should help your users to understand your content by providing:\n\nheadings that describe the topics of you content;\nlabels that describe the purpose of the native form widgets on the webpage.\n\n2.4.7 You should make sure that users can see which element they have focussed on. Next time you use your website, try hitting the Tab key repeatedly. Does it visually highlight each item as it moves focus to it? If it doesn\u2019t, search your CSS to see whether you\u2019ve applied outline: 0; to all elements\u2014that\u2019s usually the culprit. Use the :focus pseudo-element to define how elements should appear when they have focus.\n2.4.8 You could help your user to understand where the current webpage is located within your website. Add \u201cbreadcrumb navigation\u201d and/or a site map and you\u2019re done.\n2.4.9 You could make links even easier to understand, by making sure that your users can understand the purpose of a link when they read the text of the link. Again, you don\u2019t have to do that for games and quizzes.\n2.4.10 You could use headings to organise your content by topic. \nCan users understand your content?\nThe third guideline has criteria that help you prevent your users from asking, \u201cWhat the **** does this mean?\u201d\n3.1.1 Let\u2019s start this section with the criterion that possibly takes the least time to implement; you must make sure that the user\u2019s browser can identify the main language that your webpage\u2019s content is written in. For a webpage that has mainly English content, use <html lang=\"en\">. \n3.1.2 You  must specify when content in another language appears in your webpage, like so: <q>I wish you a <span lang=\"fr\">Joyeux No\u00ebl</span>.</q>. You don\u2019t have to do this for proper names, technical terms, or words that you can\u2019t identify a language for. You also don\u2019t have to do it for words from a different language that people consider part of the language around those words; for example, <q>Come to our Christmas rendezvous!</q> is OK.\n3.1.3 You could make sure that your users can find out the meaning of any unusual words or phrases, including idioms like \u201cstocking filler\u201d or \u201cBah! Humbug!\u201d and jargon such as \u201cVoiceOver\u201d and \u201cTalkBack\u201d. Provide a glossary or link to a dictionary.\n3.1.4 You could make sure that your users can find out the meaning of any    abbreviation. For example, VoiceOver pronounces \u201cXmas\u201d as \u201cSmas\u201d instead of \u201cChristmas\u201d. Using the abbr element and linking to a glossary can help. (Interestingly, VoiceOver pronounces \u201cabbr\u201d as \u201cabbreviation\u201d!)\n3.1.5 Do your users need to be able to read better than a typically educated nine-year-old, to read your content (apart from proper names and titles)? If so, you could provide a version that doesn\u2019t require that level of reading ability, or you could provide images, videos, or audio to explain your content. (You don\u2019t have to add captions or audio description to those videos.)\n3.1.6 You could make sure that your users can access the pronunciation of any word in your content if that word\u2019s meaning depends on its pronunciation. For example, the word \u201cclose\u201d could have one of two meanings, depending on pronunciation, in a phrase such as, \u201cReady for Christmas? Close now!\u201d\n3.2.1 Some users need to focus on elements to access information about them. You must make sure that focusing on an element doesn\u2019t trigger any major changes, such as opening a new window, focusing on another element, or submitting a form.\n3.2.2 Webpages are easier for users when the controls do what they\u2019re supposed to do. Unless you have warned your users about it, you must make sure that changing the value of a control such as a text box, checkbox, or drop-down list doesn\u2019t trigger any major changes, such as opening a new window, focusing on another element, or submitting a form.\n3.2.3 To help your users to find the content they want on each webpage, you should put your navigation elements in the same place on each webpage. (This doesn\u2019t apply when your user has changed their preferences or when they use assistive technology to change how your content appears.) \n3.2.4 When a set of webpages includes things that have the same functionality on different webpages, you should name those things consistently. For example, don\u2019t use the word \u201cSearch\u201d for the search box on one webpage and \u201cFind\u201d for the search box on another webpage within that set of webpages.\n3.2.5 Let\u2019s go back to major changes, such as a new window opening, another element taking focus, or a form being submitted. You could make sure that they only happen when users deliberately make them happen, or when you have warned users about them first. For example, you could give the user a button for updating some content instead of automatically updating that content. Also, if a link will open in a new window, you could add the words \u201copens in new window\u201d to the link text.\n3.3.1 Users make mistakes when filling in forms. Your website must identify each mistake to your user, and must describe the mistake to your users in text so that the user can fix it. One way to identify mistakes reliably to your users is to set the aria-invalid attribute to true in the element that has a mistake. That makes sure that users with assistive technology will be alerted about the mistake. Of course, you can then use the [aria-invalid=\"true\"] attribute selector in your CSS to visually highlight any such mistakes. Also, look into how certain attributes of the input element such as required, type, and list can help prevent and highlight mistakes.\n3.3.2 You must include labels or instructions (and possibly examples) in your website\u2019s forms, to help your users to avoid making mistakes. \n3.3.3 When your user makes a mistake when filling in a form, your webpage should suggest ways to fix that mistake, if possible. This doesn\u2019t apply in scenarios where those suggestions could affect the security of the content.\n3.3.4 Whenever your user submits information that:\n\nhas legal or financial consequences; or\naffects information that they have previously saved in your website; or\nis part of a test\n\n\u2026you should make sure that they can:\n\nundo it; or\ncorrect any mistakes, after your webpage checks their information; or\nreview, confirm, and correct the information before they finally submit it.\n\n3.3.5 You could help prevent your users from making mistakes by providing obvious, specific help, such as examples, animations, spell-checking, or extra instructions.\n3.3.6 Whenever your user submits any information, you could make sure that they can:\n\nundo it; or\ncorrect any mistakes, after your webpage checks their information; or\nreview, confirm, and correct the information before they finally submit it.\n\nHave you made your website robust enough to work on your users\u2019 browsers and assistive technologies?\nThe fourth and final guideline has criteria that help you prevent your users from asking, \u201cWhy the **** doesn\u2019t this work on my device?\u201d\n4.1.1 You must make sure that your website works as well as possible with current and future browsers and assistive technology. Prioritise  complying with web standards instead of relying on the capabilities of currently popular devices and browsers. Web developers didn\u2019t expect their users to be unwrapping the Wii U Browser five years ago\u2014who knows what browsers and assistive technologies our users will be unwrapping in five years\u2019 time? Avoid hacks, and use the W3C Markup Validation Service to make sure that your HTML has no errors.\n4.1.2 If you develop your own user interface components, you must make their name, role, state, properties, and values available to your user\u2019s browsers and assistive technologies. That should make them almost as accessible as standard HTML elements such as links, buttons, and checkboxes.\n\u201c\u2026and a partridge in a pear tree!\u201d\n\u2026as that very long Christmas song goes. We\u2019ve covered a lot in this article\u2014because your users have a lot of different levels of ability. Hopefully this has demystified the Web Content Accessibility Guidelines 2.0 for you. Hopefully you spotted a few situations that could arise for users on your website, and you now know how to tackle them. \nTo start applying what we\u2019ve covered, you might like to look at Sarah Horton and Whitney Quesenbery\u2019s personas for Accessible UX. Discuss the personas, get into their heads, and think about which aspects of your website might cause problems for them. See if you can apply what we\u2019ve covered today, to help users like them to do what they need to do on your website.\nHow to know when your website is perfectly accessible for everyone\nLOL! There will never be a time when your website becomes perfectly accessible for everyone. Don\u2019t aim for that. Instead, aim for regularly testing and making your website more accessible.\nWeb Content Accessibility Guidelines (WCAG) 2.1\nThe W3C hope to release the Web Content Accessibility Guidelines (WCAG) 2.1 as a \u201crecommendation\u201d (that\u2019s what the W3C call something that we should start using) by the middle of next year. Ten years may seem like a long time to move from version 2.0 to version 2.1, but consider the scale of the task: the editors have to update the guidelines to cover all the new ways that people interact with new technologies, while keeping the guidelines backwards-compatible. Keep an eye out for 2.1!\nYou\u2019ll go down in history\nOne last point: I\u2019ve met a surprising number of web designers and developers who do great work to make their websites more accessible without ever telling their users about it. Some of your potential customers have possibly tried and failed to use your website in the past. They probably won\u2019t try again unless you let them know that things have improved. A quick Twitter search for your website\u2019s name alongside phrases like \u201cassistive technology\u201d, \u201cdoesn\u2019t work\u201d, or \u201c#fail\u201d can let you find frustrated users\u2014so you can tell them about how you\u2019re making your website more accessible. Start making your websites work better for everyone\u2014and please, let everyone know.", "year": "2017", "author": "Alan Dalton", "author_slug": "alandalton", "published": "2017-12-03T00:00:00+00:00", "url": "https://24ways.org/2017/wcag-for-people-who-havent-read-them/", "topic": "code"}
{"rowid": 245, "title": "Web Content Accessibility Guidelines 2.1\u2014for People Who Haven\u2019t Read the Update", "contents": "Happy United Nations International Day of Persons with Disabilities 2018! The United Nations chose \u201cEmpowering persons with disabilities and ensuring inclusiveness and equality\u201d as this year\u2019s theme. We\u2019ve seen great examples of that in 2018; for example, Paul Robert Lloyd has detailed how he improved the accessibility of this very website. \nOn social media, US Congressmember-Elect Alexandria Ocasio-Cortez started using the Clipomatic app to add live captions to her Instagram live stories, conforming to success criterion 1.2.4, \u201cCaptions (Live)\u201d of the Web Content Accessibility Guidelines (figure 1) \u2026and British Vogue Contributing Editor Sin\u00e9ad Burke has used the split-screen feature of Instagram live stories to invite an interpreter to provide live Sign Language interpretation, going above and beyond success criterion 1.2.6, \u201cSign Language (Prerecorded)\u201d of the Web Content Accessibility Guidelines (figure 2).\n\nFigure 1: Screenshot of Alexandria Ocasio-Cortez\u2019s Instagram story with live captionsFigure 2: Screenshot of Sin\u00e9ad Burke\u2019s Instagram story with Sign Language Interpretation\nThat theme chimes with this year\u2019s publication of the World Wide Web Consortium (W3C)\u2019s Web Content Accessibility Guidelines (WCAG) 2.1. In last year\u2019s \u201cWeb Content Accessibility Guidelines\u2014for People Who Haven\u2019t Read Them\u201d, I mentioned the scale of the project to produce this update during 2018: \u201cthe editors have to update the guidelines to cover all the new ways that people interact with new technologies, while keeping the guidelines backwards-compatible\u201d. \nThe WCAG working group have added 17 success criteria to the 61 that they released way back in 2008\u2014for context, that was 1\u00bd years before Apple released their first iPad! These new criteria make it easier than ever for us web geeks to produce work that is more accessible to people using mobile devices and touchscreens, people with low vision, and people with cognitive and learning disabilities. \nOnce again, let\u2019s rip off all the legalese and ambiguous terminology like wrapping paper, and get up to date.\nCan your users perceive the information on your website?\nThe first guideline has criteria that help you prevent your users from asking, \u201cWhat the **** is this thing here supposed to be?\u201d We\u2019ve seven new criteria for this guideline.\n1.3.4 Some people can\u2019t easily change the orientation of the device that they use to browse the web, and so you should make sure that your users can use your website in portrait orientation and in landscape orientation. Consider how people slowly twirl presents that they have plucked from under the Christmas tree, to find the appropriate orientation\u2014and expect your users to do likewise with your websites and apps. We\u2019ve had 18\u00bd years since John Allsopp\u2019s revelatory Dao of Web Design enlightened us to \u201cembrace the fact that the web doesn\u2019t have the same constraints\u201d as printed pages, and to \u201cdesign for this flexibility\u201d. So, even though this guideline doesn\u2019t apply to websites where \u201ca specific display orientation is essential,\u201d such as a piano tutorial, always ask yourself, \u201cWhat would John Allsopp do?\u201d\n1.3.5 You should help the user\u2019s browser to automatically complete\u2013or not complete\u2013form fields, to save the user some time and effort. The surprisingly powerful and flexible autocomplete attribute for input elements should prove most useful here. If you\u2019ve used microformats or microdata to mark up information about a person, the autocomplete attribute\u2019s range of values should seem familiar. I like how the W3\u2019s \u201cUsing HTML 5.2 autocomplete attributes\u201d says that autocompleted values in forms help \u201cthose with dexterity disabilities who have trouble typing, those who may need more time, and anyone who wishes to reduce effort to fill out a form\u201d (emphasis mine). Um\u2026\ud83d\ude4b\u200d\u2642\ufe0f\n1.3.6 I like this one a lot, because it can help a huge audience to overcome difficulties that might prevent them from ever using the web. Some people have cognitive difficulties that affect their memory, focus, attention, language processing, and/or decision-making. Those users often rely on assistive technologies that present information through proprietary symbols, summaries of content, and keyboard shortcuts. You could use ARIA landmarks to identify the regions of each webpage. You could also keep an eye on the W3C\u2019s ongoing work on Personalisation Semantics.\n1.4.10 If you were to find a Nintendo Switch and \u201cSuper Mario Odyssey\u201d under your Christmas tree, you would have many hours of enjoyably scrolling horizontally and vertically to play the game. On the other hand, if you had to zoom a webpage to 400% so that you could read the content, you might have many hours of frustratedly scrolling horizontally and vertically to read the content. Learned reader, I assume you understand the purpose and the core techniques of Responsive Web Design. I also assume you\u2019re getting up to speed with the new Grid, Flexbox, and Box Alignment techniques for layout, and overflow-wrap. Using those skills, you should make sure that all content and functionality remain available when the browser is 320px wide, without your user needing to scroll horizontally. (For vertical text, you should make sure that all content and functionality remain available when the browser is 256px high, without your user needing to scroll vertically.) You don\u2019t have to do this for anything that would lose meaning if you restructured it into one narrow column. That includes some images, maps, diagrams, video, games, presentations, and data tables. Remember to check how your media queries affect font size: your user might find that text becomes smaller as they zoom into the webpage. So, test this one on real devices, or\u2014better yet\u2014test it with real users.\n1.4.11 In \u201cWeb Content Accessibility Guidelines\u2014for People Who Haven\u2019t Read Them\u201d, I recommended bookmarking Lea Verou\u2019s Contrast Ratio calculator for checking that text contrasts enough with its background (for success criteria 1.4.3 and 1.4.6), so that more people can read it more easily. For this update, you should make sure that form elements and their focus states have a 3:1 contrast ratio with the colour around them. This doesn\u2019t apply to controls that use the browser\u2019s default styling. Also, you should make sure that graphics that convey information have a 3:1 contrast ratio with the colour around them.\n1.4.12 Some people, due to low vision or dyslexia, might need to modify the typography that you agonised over. Research indicates that you should make sure that all content and functionality would remain available if a user were to set:\n\nline height to at least 1\u00bd \u00d7 the font size;\nspace below paragraphs to at least 2 \u00d7 the font size;\nletter spacing to at least 0.12 \u00d7 the font size;\nword spacing to at least 0.16 \u00d7 the font size.\n\nTo test this, check for text overlapping, text hiding behind other elements, or text disappearing.\n1.4.13 Sometimes when visiting a website, you hover over\u2014or tab on to\u2014something that unleashes a newsletter subscription pop-up, some suggested \u201crelated content\u201d, and/or a GDPR-related pop-up. On a well-designed website, you can press the Esc key on your keyboard or click a prominent \u201cClose\u201d button or \u201cX\u201d button to vanquish such intrusions. If the Esc key fails you, or if you either can\u2019t see or can\u2019t click the \u201cClose\u201d button\u2026well, you\u2019ll probably just close that browser tab. This situation can prove even more infuriating for users with low vision or cognitive disabilities. So, if new content appears when your user hovers over or tabs on to some element, you should make sure that:\n\nyour user can dismiss that content without needing to move their pointer or tab on to some other element (this doesn\u2019t apply to error warnings, or well-behaved content that doesn\u2019t obscure or replace other content);\nthe new content remains visible while your user moves their cursor over it;\nthe new content remains visible as long as the user hovers over that element or dismisses that content\u2014or until the new content is no longer valid.\n\nThis doesn\u2019t apply to situations such as hovering over an element\u2019s title attribute, where the user\u2019s browser controls the display of the content that appears.\nCan users operate the controls and links on your website?\nThe second guideline has criteria that help you prevent your users from asking, \u201cHow the **** does this thing work?\u201d We\u2019ve nine new criteria for this guideline.\n2.1.4 Some websites offer keyboard shortcuts for users. For example, the keyboard shortcuts for Gmail allow the user to press the \u21e7 key and u to mark a message as unread. Usually, shortcuts on websites include modifier keys, such as Ctrl, along with a letter, number, or punctuation symbol. Unfortunately, users who have dexterity challenges sometimes trigger those shortcuts by accident, and that can make a website impossible to use. Also, speech input technology can sometimes trigger those shortcuts. If your website offers single-character keyboard shortcuts, you must allow your user to turn off or remap those shortcuts. This doesn\u2019t apply to single-character keyboard shortcuts that only work when a control, such as drop-down list, has focus.\n2.2.6 If your website uses a timeout for some process, you could store the user\u2019s data for at least 20 hours, so that users with cognitive disabilities can take a break or take longer than usual to complete the process without losing their place or losing their data. Alternatively, you could warn the user, at the start of the process, about that the website will timeout after whatever amount of time you have chosen. \n2.3.3 If your website has some non-essential animation (such as parallax scrolling) that starts when the user does some particular action, you could allow the user to turn off that animation so that you avoid harming users with vestibular disorders. The prefers-reduced-motion media query currently has limited browser support, but you can start using it now to avoid showing animations to users who select the \u201cReduce Motion\u201d setting (or equivalent) in their device\u2019s operating system:\n@media (prefers-reduced-motion: reduce) {\n  .MrFancyPants {\n    animation: none;\n  }\n}\n2.5.1 Some websites let users use multi-touch gestures on touchscreen devices. For example, Google Maps allows users to pinch with two fingers to zoom out and \u201cunpinch\u201d with two fingers to zoom in. Also, some websites allow users to drag a finger to do some action, such as changing the value on an input element with type=\"range\", or swiping sideways to the next photograph in a gallery. Some users with dexterity challenges, and some users who use a head pointer, an eye-gaze system, or speech-controlled mouse emulation, might find multi-touch gestures or dragging impossible. You must make sure that your website supports single-tap alternatives to any multi-touch gestures or dragging actions that it provides. For example, if your website lets someone pinch and unpinch a map to zoom in and out, you must also provide buttons that a user can tap to zoom in and out.\n2.5.2 This might be my favourite accessibility criterion ever! Did you ever touch or press a \u201cSend\u201d button but then immediately realise that you really didn\u2019t want to send the message, and so move your finger or cursor away from the \u201cSend\u201d button before lifting your finger?! Imagine how many arguments that functionality has prevented. \ud83d\ude0c You must make sure that touching or pressing does not cause anything to happen before the user raises their finger or cursor, or make sure that the user can move their finger or cursor away to prevent the action. In JavaScript, prefer onclick to onmousedown, unless your website has actions that need onmousedown. Also, this doesn\u2019t apply to actions that need to happen as soon as the user clicks or touches. For example, a user playing a \u201cWhac-A-Mole\u201d game or a piano emulator needs the action to happen as soon as they click or touch the screen.\n2.5.3 Recently, entrepreneur and social media guru Gary Vaynerchuk has emphasised the rise of audio and voice as output and input. He quotes a Google statistic that says one in five search queries use voice input. Once again, users with disabilities have been ahead of the curve here, having used screen readers and/or dictation software for many years. You must make sure that the text that appears on a form control or image matches how your HTML identifies that form control or image. Use proper semantic HTML to achieve this:\n\nuse the label element to pair text with the corresponding input element;\nuse an alt attribute value that exactly matches any text that appears in an image;\nuse an aria-labelledby attribute value that exactly matches the text that appears in any complex component.\n\n2.5.4 Modern Web APIs allow web developers to specify how their website will react to the user shaking, tilting, or gesturing towards their device. Some users might find those actions difficult, impossible, or embarrassing to perform. If you make any functionality available when the user shakes, tilts, or gestures towards their device, you must provide form controls that make that same functionality available. As usual, this doesn\u2019t apply to websites that require shaking, tilting, or gesturing; this includes some games and music programmes. John Gruber describes the iPhone\u2019s \u201cShake to Undo\u201d gesture as \u201cdreadful \u2014 impossible to discover through exploration of the on-screen [user interface], bad for accessibility, and risks your phone flying out of your hand\u201d. This accessibility criterion seems to empathise with John: you must make sure that your user can prevent your website from responding to shaking, tilting and/or gesturing towards their device.\n2.5.5 Homer Simpson\u2019s telephone famously complained, \u201cThe fingers you have used to dial are too fat.\u201d I think we\u2019ve all felt like that when using phones and tablets, particularly when trying to dismiss pop-ups and ads. You could make interactive elements at least 44px wide \u00d7 44px high. Apple\u2019s \u201cHuman Interface Guidelines\u201d agree: \u201cProvide ample touch targets for interactive elements. Try to maintain a minimum tappable area of 44pt x 44pt for all controls.\u201d This doesn\u2019t apply to links within inline text, or to unsoiled elements.\n2.5.6 Expect your users to use a variety of input devices they want, and to change from one to another whenever they please. For example, a user with a tablet and keyboard might jab icons on the screen while typing on the keyboard, or a user might dictate text while alone and then type on a keyboard when a colleague arrives. You could make sure that your website allows your users to use whichever available input modality they choose. Once again, this doesn\u2019t apply to websites that require a specific modality; this includes typing tutors and music programmes.\nCan users understand your content?\nThe third guideline has criteria that help you prevent your users from asking, \u201cWhat the **** does this mean?\u201d We\u2019ve no new criteria for this guideline. \nHave you made your website robust enough to work on your users\u2019 browsers and assistive technologies?\nThe fourth and final guideline has criteria that help you prevent your users from asking, \u201cWhy the **** doesn\u2019t this work on my device?\u201d We\u2019ve one new criterion for this guideline.\n4.1.3 Sometimes you need to let your user know the status of something: \u201cDid it work OK? What was the error? How far through it are we?\u201d However, you should avoid making your user lose their place on the webpage, and so you should let them know the status without opening a new window, focusing on another element, or submitting a form. To do this properly for assistive technology users, choose the appropriate ARIA role for the new content; for example:  \n\nif your user needs to know, \u201cDid it work OK?\u201d, add role=\"status\u201d;\nif your user needs to know, \u201cWhat was the error?\u201d, add role=\"alert\u201d;\nif you user needs to know, \u201cHow far through it are we?\u201d, add role=\"log\" (for a chat window) or role=\"progressbar\" (for, well, a progress bar).\n\nBetter design for humans\nMy favourite of Luke Wroblewski\u2019s collection of Design Quotes is, \u201cDesign is the art of gradually applying constraints until only one solution remains,\u201d   from that most prolific author, \u201cUnknown\u201d. I\u2019ve always viewed the Web Content Accessibility Guidelines as people-based constraints, and liked how they help the design process. With these 17 new web content accessibility criteria, go forth and create solutions that more people than ever before can use.\nSpending those book vouchers you got for Christmas\nWhat next? If you\u2019re looking for something to do to keep you busy this Christmas, I thoroughly recommend these four books for increasing your accessibility expertise:\n\n\u201cPro HTML5 Accessibility\u201d by Joshue O Connor (Head of Accessibility (Interim) at the UK Government Digital Service, Director of InterAccess, and one of the editors of the Web Content Accessibility Guidelines 2.1): Although this book is six years old\u2014a long time in web design\u2014I find it an excellent go-to resource. It begins by explaining how people with disabilities use the web, and then expertly explains modern HTML in that context.\n\u201cA Web for Everyone\u2014Designing Accessible User Experiences\u201d by Sarah Horton (the Paciello Group\u2019s UX Strategy Lead) and Whitney Quesenbery (the Center for Civic Design\u2019s co-director): This book covers the Web Content Accessibility Guidelines 2.0, the principles of Universal Design, and design thinking. Its personas for Accessible UX and its profiles of well-known industry figures\u2014including some 24ways authors\u2014keep its content practical and relevant throughout.\n\u201cAccessibility For Everyone\u201d by Laura Kalbag (Ind.ie\u2019s co-founder and designer, and 24ways author): This book is just over a year old, and so serves as a great resource for up-to-date coverage of guidelines, laws, and accessibility features of operating systems\u2014as well as content, design, coding, and testing. The audiobook, which Laura narrates, can help you and your colleagues go from having little or no understanding of web accessibility, to becoming familiar with all aspects of web accessibility\u2014in less than four hours.\n\u201cJust Ask: Integrating Accessibility Throughout Design\u201d by Shawn Lawton Henry (the World Wide Web Consortium (W3C)\u2019s Web Accessibility Initiative (WAI)\u2019s Outreach Coordinator): Although this book is 11\u00bd years old, the way it presents accessibility as part of the User-Centered Design process is timeless. I found its section on Usability Testing with people with disabilities particularly useful.", "year": "2018", "author": "Alan Dalton", "author_slug": "alandalton", "published": "2018-12-03T00:00:00+00:00", "url": "https://24ways.org/2018/wcag-for-people-who-havent-read-the-update/", "topic": "ux"}
{"rowid": 275, "title": "Context First: Web Strategy in Four Handy Ws", "contents": "Many, many years ago, before web design became my proper job, I trained and worked as a journalist. I studied publishing in London and spent three fun years learning how to take a few little nuggets of information and turn them into a story. I learned a bunch of stuff that has all been a huge help to my design career. Flatplanning, layout, typographic theory. All of these disciplines have since translated really well to web design, but without doubt the most useful thing I learned was how to ask difficult questions.\n\nPretty much from day one of journalism school they hammer into you the importance of the Five Ws. Five disarmingly simple lines of enquiry that eloquently manage to provide the meat of any decent story. And with alliteration thrown in too. For a young journo, it\u2019s almost too good to be true.\n\nWho? What? Where? When? Why? It seems so obvious to almost be trite but, fundamentally, any story that manages to answer those questions for the reader is doing a pretty good job. You\u2019ll probably have noticed feeling underwhelmed by certain news pieces in the past \u2013 disappointed, like something was missing. Some irritating oversight that really lets the story down. No doubt it was one of the Ws \u2013 those innocuous little suckers are generally only noticeable by their absence, but they sure get missed when they\u2019re not there. \n\nQuestion everything\n\nI\u2019ve always been curious. An inveterate tinkerer with things and asker of dopey questions, often to the point of abject annoyance for anyone unfortunate enough to have ended up in my line of fire. So, naturally, the Five Ws started drifting into other areas of my life. I\u2019d scrutinize everything, trying to justify or explain my rationale using these Ws, but I\u2019d also find myself ripping apart the stuff that clearly couldn\u2019t justify itself against the same criteria.\n\nSo when I started working as a designer I applied the same logic and, sure enough, the Ws pretty much mapped to the exact same needs we had for gathering requirements at the start of a project. It seemed so obvious, such a simple way to establish the purpose of a product. What was it for? Why we were making it? And, of course, who were we making it for? It forced clients to stop and think, when really what they wanted was to get going and see something shiny. Sometimes that was a tricky conversation to have, but it\u2019s no coincidence that those who got it also understood the value of strategy and went on to have good solid products, while those that didn\u2019t often ended up with arrogantly insular and very shiny but ultimately unsatisfying and expendable products. Empty vessels make the most noise and all that\u2026\n\nContent first\n\nI was both surprised and pleased when the whole content first idea started to rear its head a couple of years back. Pleased, because without doubt it\u2019s absolutely the right way to work. And surprised, because personally it\u2019s always been the way I\u2019ve done it \u2013 I wasn\u2019t aware there was even an alternative way. Content in some form or another is the whole reason we were making the things we were making. I can\u2019t even imagine how you\u2019d start figuring out what a site needs to do, how it should be structured, or how it should look without a really good idea of what that content might be. It baffles me still that this was somehow news to a lot of people. What on earth were they doing? Design without purpose is just folly, surely?\n\nIt\u2019s great to see the idea gaining momentum but, having watched it unfold, it occurred to me recently that although it\u2019s fantastic to see a tangible shift in thinking \u2013 away from those bleak times, where making things up was somehow deemed an appropriate way to do things \u2013 there\u2019s now a new bad guy in town.\n\nWith any buzzword solution of the moment, there\u2019s always a catch, and it seems like some have taken the content first approach a little too literally. By which I mean, it\u2019s literally the first thing they do. The project starts, there\u2019s a very cursory nod towards gathering requirements, and off they go, cranking content. Writing copy, making video, commissioning illustrations.\n\nAll that\u2019s happened is that the \u2018making stuff up\u2019 part has shifted along the line, away from layout and UI, back to the content. \n\nStarting is too easy\n\nI can\u2019t remember where I first heard that phrase, but it\u2019s a great sentiment which applies to so much of what we do on the web. The medium is so accessible and to an extent disposable; throwing things together quickly carries far less burden than in any other industry. We\u2019re used to tweaking as we go, changing bits, iterating things into shape. The ubiquitous beta tag has become the ultimate caveat, and has made the unfinished and unpolished acceptable. Of course, that can work brilliantly in some circumstances. Occasionally, a product offers such a paradigm shift it\u2019s beyond the level of deep planning and prelaunch finessing we\u2019d ideally like. But, in the main, for most client sites we work on, there really is no excuse not to do things properly. To ask the tricky questions, to challenge preconceptions and really understand the Ws behind the products we\u2019re making before we even start. \n\nThe four Ws\n\nFor product definition, only four of the five Ws really apply, although there\u2019s a lot of discussion around the idea of when being an influencing factor. For example, the context of a user\u2019s engagement with your product is something you can make a call on depending on the specifics of the project.\n\nSo, here\u2019s my take on the four essential Ws. I\u2019ll point out here that, of course, these are not intended to be autocratic dictums. Your needs may differ, your clients\u2019 needs may differ, but these four starting points will get you pretty close to where you need to be.\n\nWho \n\nIt\u2019s surprising just how many projects start without a real understanding of the intended audience. Many clients think they have an idea, but without really knowing \u2013 it\u2019s presumptive at best, and we all know what presumption is the mother of, right? Of course, we can\u2019t know our audiences in the same way a small shop owner might know their customers. But we can at least strive to find out what type of people are likely to be using the product. I\u2019m not talking about deep user research. That should come later.\n\nThese are the absolute basics. What\u2019s the context for their visit? How informed are they? What\u2019s their level of comprehension? Are they able to self-identify and relate to categories you have created? I could go on, and it changes on a per-project basis. You\u2019ll only find this out by speaking to them, if not in person, then indirectly through surveys, questionnaires or polls. The mechanism is less important than actually reaching out and engaging with them, because without that understanding it\u2019s impossible to start to design with any empathy.\n\nWhat\n\nOnce you become deeply involved directly with a product or service, it\u2019s notoriously difficult to see things as an outsider would. You learn the thing inside and out, you develop shortcuts and internal phraseology. Colloquialisms creep in. You become too close. So it\u2019s no surprise when clients sometimes struggle to explain what it is their product actually does in a way that others can understand.\n\nOften products are complex but, really, the core reasons behind someone wanting to use that product are very simple. There\u2019s a value proposition for the customer and, if they choose to engage with it, there\u2019s a value exchange. If that proposition or exchange isn\u2019t transparent, then people become confused and will likely go elsewhere. Make sure both your client and you really understand what that proposition is and, in turn, what the expected exchange should be. In a nutshell: what is the intended outcome of that engagement? Often the best way to do this is strip everything back to nothing. Verbosity is rife on the web. Just because it\u2019s easy to create content, that shouldn\u2019t be a reason to do so. Figure out what the value proposition is and then reintroduce content elements that genuinely help explain or present that to a level that is appropriate for the audience. \n\nWhy \n\nIn advertising, they talk about the truths behind a product or service. Truths can be both tangible or abstract, but the most important part is the resonance those truths hit with a customer. In a digital product or service those truths are often exposed as benefits. Why is this what I need? Why will it work for me? Why should I trust you? The why is one of the more fluffy Ws, yet it\u2019s such an important one to nail. Clients can get prickly when you ask them to justify the why behind their product, but it\u2019s a fantastic way to make sure the value proposition is clear, realistic and meets with the expectations of both client and customer.\n\nIt\u2019s our job as designers to question things: we\u2019re not just a pair of hands for clients. Just recently I spoke to a potential client about a site for his business. I asked him why people would use his product and also why his product seemed so fractured in its direction. He couldnt answer that question so, instead of ploughing on regardless, he went back to his directors and is now re-evaluating that business. It was awkward but he thanked me and hopefully he\u2019ll have a better product as a result.\n\nWhere\n\nIn this instance, where is not so much a geographical thing, although in some cases that level of context may indeed become a influencing factor\u2026 The where we\u2019re talking about here is the position of the product in relation to others around it. By looking at competitors or similar services around the one you are designing, you can start to get a sense for many of the things that are otherwise hard to pin down or have yet to be defined. For example, in a collection of sites all selling cars, where does yours fit most closely? Where are the overlaps? How are they communicating to their customers? How is the product range presented or categorized?\n\nIt\u2019s good to look around and see how others are doing it. Not in a quest for homogeneity but more to reference or to avoid certain patterns that may or may not make sense for your own particular product. Clients often strive to be different for the sake of it. They feel they need to provide distinction by going against the flow a bit. We know different. We know users love convention. They embrace familiar mental models. They\u2019re comfortable with things that they\u2019ve experienced elsewhere. By showing your client that position is a vital part of their strategy, you can help shape their product into something great. \n\nTo conclude\n\nSo there we have it \u2013 the four Ws. Each part tells a different and vital part of the story you need to be able to make a really good product. It might sound like a lot of work, particularly when the client is breathing down your neck expecting to see things, but without those pieces in place, the story you\u2019re building your product on, and the content that you\u2019re creating to form that product can only ever fit into one genre. Fiction.", "year": "2011", "author": "Alex Morris", "author_slug": "alexmorris", "published": "2011-12-10T00:00:00+00:00", "url": "https://24ways.org/2011/context-first/", "topic": "content"}
{"rowid": 293, "title": "A Favor for Your Future Self", "contents": "We tend to think about the future when we build things. What might we want to be able to add later? How can we refactor this down the road? Will this be easy to maintain in six months, a year, two years? As best we can, we try to think about the what-ifs, and build our websites, systems, and applications with this lens. \nWe comment our code to explain what we knew at the time and how that impacted how we built something. We add to-dos to the things we want to change. These are all great things! Whether or not we come back to those to-dos, refactor that one thing, or add new features, we put in a bit of effort up front just in case to give us a bit of safety later.\nI want to talk about a situation that Past Alicia and Team couldn\u2019t even foresee or plan for. Recently, the startup I was a part of had to remove large sections of our website. Not just content, but entire pages and functionality. It wasn\u2019t a very pleasant experience, not only for the reason why we had to remove so much of what we had built, but also because it\u2019s the ultimate \u201cI really hope this doesn\u2019t break something else\u201d situation. It was a stressful and tedious effort of triple checking that the things we were removing weren\u2019t dependencies elsewhere. To be honest, we wouldn\u2019t have been able to do this with any amount of success or confidence without our test suite.\nWriting tests for code is one of those things that developers really, really don\u2019t want to do. It\u2019s one of the easiest things to cut in the development process, and there\u2019s often a struggle to have developers start writing tests in the first place. One of the best lessons the web has taught us is that we can\u2019t, in good faith, trust the happy path. We must make sure ourselves, and our users, aren\u2019t in a tough spot later on because we only thought of the best case scenarios.\nJavaScript\nRegardless of your opinion on whether or not everything needs to be built primarily with JavaScript, if you\u2019re choosing to build a JavaScript heavy app, you absolutely should be writing some combination of unit and integration tests.\nUnit tests are for testing extremely isolated and small pieces of code, which we refer to as the units themselves. Great for reused functions and small, scoped areas, this is the closest you examine your code with the testing microscope. For example, if we were to build a calculator, the most minute piece we could test could be the basic operations.\n/*\n * This example uses a test framework called Jasmine\n */\n\ndescribe(\"Calculator Operations\", function () {\n\n    it(\"Should add two numbers\", function () {\n\n    // Say we have a calculator\n        Calculator.init();\n\n    // We can run the function that does our addition calculation...\n        var result = Calculator.addNumbers(7,3);\n\n    // ...and ensure we're getting the right output\n        expect(result).toBe(10);\n\n    });\n});\nEven though these teeny bits work in isolation, we should ensure that connecting the large pieces work, as well. This is where integration tests excel. These tests ensure that two or more different areas of code, that may not directly know about each other, still behave in expected ways. Let\u2019s build upon our calculator - we may want the operations to be saved in memory after a calculation runs. This isn\u2019t as suited for a unit test because there are a few other moving pieces involved in the process (the calculations, checking if the result was an error, etc.).\n    it(\u201cShould remember the last calculation\u201d, function () {\n\n    // Run an operation\n        Calculator.addNumbers(7,10);\n\n    // Expect something else to have happened as a result\n        expect(Calculator.updateCurrentValue).toHaveBeenCalled();\n        expect(Calculator.currentValue).toBe(17);\n    });\nUnit and integration tests provide assurance that your hand-rolled JavaScript should, for the most part, never fail in a grand fashion. Although it still might happen, you could be able to catch problems way sooner than without a test suite, and hopefully never push those failures to your production environment.\nInterfaces\nRegardless of how you\u2019re building something, it most definitely has some kind of interface. Whether you\u2019re using a very barebones structure, or you\u2019re leveraging a whole design system, these things can be tested as well.\nAcceptance testing helps us ensure that users can get from point A to point B within our web things, which can provide assurance that major features are always functioning properly. By simulating user input and data entry, we can go through whole user workflows to test for both success and failure scenarios. These are not necessarily for simulating edge-case scenarios, but rather ensuring that our core offerings are stable.\nFor example, if your site requires signup, you want to make sure the workflow is behaving as expected - allowing valid information to go through signup, while invalid information does not let you progress.\n/*\n * This example uses Jasmine along with an add-on called jasmine-integration\n */\n\ndescribe(\"Acceptance tests\", function () {\n\n  // Go to our signup page\n  var page = visit(\"/signup\");\n\n  // Fill our signup form with invalid information\n  page.fill_in(\"input[name='email']\", \"Not An Email\");\n  page.fill_in(\"input[name='name']\", \"Alicia\");\n  page.click(\"button[type=submit]\");\n\n  // Check that we get an expected error message\n  it(\"Shouldn't allow signup with invalid information\", function () {\n    expect(page.find(\"#signupError\").hasClass(\"hidden\")).toBeFalsy();\n  });\n\n  // Now, fill our signup form with valid information\n  page.fill_in(\"input[name='email']\", \"thisismyemail@gmail.com\");\n  page.fill_in(\"input[name='name']\", \"Gerry\");\n  page.click(\"button[type=submit]\");\n\n  // Check that we get an expected success message and the error message is hidden\n  it(\"Should allow signup with valid information\", function () {\n    expect(page.find(\"#signupError\").hasClass(\"hidden\")).toBeTruthy();\n    expect(page.find(\"#thankYouMessage\").hasClass(\"hidden\")).toBeFalsy();\n  });\n});\nIn terms of visual design, we\u2019re now able to take snapshots of what our interfaces look like before and after any code changes to see what has changed. We call this visual regression testing. Rather than being a pass or fail test like our other examples thus far, this is more of an awareness test, intended to inform developers of all the visual differences that have occurred, intentional or not. Developers may accidentally introduce a styling change or fix that has unintended side effects on other areas of a website - visual regression testing helps us catch these sooner rather than later. These do require a bit more consistent grooming than other tests, but can be valuable in major CSS refactors or if your CSS is generally a bit like Jenga.\nTools like PhantomCSS will take screenshots of your pages, and do a visual comparison to check what has changed between two sets of images. The code would look something like this:\n/*\n * This example uses PhantomCSS\n */\n\ncasper.start(\"/home\").then(function(){\n\n  // Initial state of form\n  phantomcss.screenshot(\"#signUpForm\", \"sign up form\");\n\n  // Hit the sign up button (should trigger error)\n  casper.click(\"button#signUp\");\n\n  // Take a screenshot of the UI component\n  phantomcss.screenshot(\"#signUpForm\", \"sign up form error\");\n\n  // Fill in form by name attributes & submit\n  casper.fill(\"#signUpForm\", {\n    name: \"Alicia Sedlock\",\n    email: \"alicia@example.com\"\n  }, true);\n\n  // Take a second screenshot of success state\n  phantomcss.screenshot(\"#signUpForm\", \"sign up form success\");\n});\nYou run this code before starting any development, to create your baseline set of screen captures. After you\u2019ve completed a batch of work, you run PhantomCSS again. This will create a second batch of screenshots, which are then put through an image comparison tool to display any differences that occurred. Say you changed your margins on our form elements \u2013 your image diff would look something like this:\n\nThis is a great tool for ensuring not just your site retains its expected styling, but it\u2019s also great for ensuring nothing accidentally changes in the living style guide or modular components you may have developed. It\u2019s hard to keep eagle eyes on every visual aspect of your site or app, so visual regression testing helps to keep these things monitored.\nConclusion\nThe shape and size of what you\u2019re testing for your site or app will vary. You may not need lots of unit or integration tests if you don\u2019t write a lot of JavaScript. You may not need visual regression testing for a one page site. It\u2019s important to assess your codebase to see which tests would provide the most benefit for you and your team.\nWriting tests isn\u2019t a joy for most developers, myself included. But I end up thanking Past Alicia a lot when there are tests, because otherwise I would have introduced a lot of issues into codebases. Shipping code that\u2019s broken breaks trust with our users, and it\u2019s our responsibility as developers to make sure that trust isn\u2019t broken. Testing shouldn\u2019t be considered a \u201cnice to have\u201d - it should be an integral piece of our workflow and our day-to-day job.", "year": "2016", "author": "Alicia Sedlock", "author_slug": "aliciasedlock", "published": "2016-12-03T00:00:00+00:00", "url": "https://24ways.org/2016/a-favor-for-your-future-self/", "topic": "code"}
{"rowid": 304, "title": "Five Lessons From My First 18 Months as a Dev", "contents": "I recently moved from Sydney to London to start a dream job with Twitter as a software engineer. A software engineer! Who would have thought.\nHaving started my career as a journalist, the title \u2018engineer\u2019 is very strange to me. The notion of writing in first person is also very strange. Journalists are taught to be objective, invisible, to keep yourself out of the story. And here I am writing about myself on a public platform. Cringe.\nSince I started learning to code I\u2019ve often felt compelled to write about my experience. I want to share my excitement and struggles with the world! But as a junior I\u2019ve been held back by thoughts like \u2018whatever you have to say won\u2019t be technical enough\u2019, \u2018any time spent writing a blog would be better spent writing code\u2019, \u2018blogging is narcissistic\u2019, etc.\u00a0\nWell, I\u2019ve been told that your thirties are the years where you stop caring so much about what other people think. And I\u2019m almost 30. So here goes!\nThese are five key lessons from my first year and a half in tech:\nDeployments should delight, not dread \n\nLesson #1: Making your deployment process as simple as possible is worth the investment.\n\nIn my first dev job, I dreaded deployments. We would deploy every Sunday night at 8pm. Preparation would begin the Friday before. A nominated deployment manager would spend half a day tagging master, generating scripts, writing documentation and raising JIRAs. The only fun part was choosing a train gif to post in HipChat: \u2018All aboard! The deployment train leaves in 3, 2, 1\u2026\u201d\n\nWhen Sunday night came around, at least one person from every squad would need to be online to conduct smoke tests. Most times, the deployments would succeed. Other times they would fail. Regardless, deployments ate into people\u2019s weekend time\u200a\u2014\u200aand they were intense. Devs would rush to have their code approved before the Friday cutoff. Deployment managers who were new to the process would fear making a mistake.\u00a0\nThe team knew deployments were a problem. They were constantly striving to improve them. And what I\u2019ve learnt from Twitter is that when they do, their lives will be bliss.\nTweetDeck\u2019s deployment process fills me with joy and delight. It\u2019s quick, easy and stress free. In fact, it\u2019s so easy I deployed code on my first day in the job! Anyone can deploy, at any time of day, with a single command. Rollbacks are just as simple. There\u2019s no rush to make the deployment train. No manual preparation. No fuss. Value\u200a\u2014\u200awhether in the form of big new features, simple UI improvements or even production bug fixes\u200a\u2014\u200acan be shipped in an instant. The team assures me the process wasn\u2019t always like this. They invested lots of time in making their deployments better. And it\u2019s clearly paid off.\nCode reviews need love, time and acceptance \n\nLesson #2: Code reviews are a three-way gift. Every time I review someone else\u2019s code, I help them, the team and myself.\n\nCode reviews were another pain point in my previous job. And to be honest, I was part of the problem. I would raise code reviews that were far too big. They would take days, sometimes weeks, to get merged. One of my reviews had 96 comments! I would rarely review other people\u2019s code because I felt too junior, like my review didn\u2019t carry any weight.\u00a0\nThe review process itself was also tiring, and was often raised in retrospectives as being slow. In order for code to be merged it needed to have ticks of approval from two developers and a third tick from a peer tester. It was the responsibility of the author to assign the reviewers and tester. It was felt that if it was left to team members to assign themselves to reviews, the \u201csomeone else will do it\u201d mentality would kick in, and nothing would get done.\nAt TweetDeck, no-one is specifically assigned to reviews. Instead, when a review is raised, the entire team is notified. Without fail, someone will jump on it. Reviews are seen as blocking. They\u2019re seen to be equally, if not more important, than your own work. I haven\u2019t seen a review sit for longer than a few hours without comments.\u00a0\nWe also don\u2019t work on branches. We push single commits for review, which are then merged to master. This forces the team to work in small, incremental changes. If a review is too big, or if it\u2019s going to take up more than an hour of someone\u2019s time, it will be sent back.\nWhat I\u2019ve learnt so far at Twitter is that code reviews must be small. They must take priority. And they must be a team effort. Being a new starter is no \u201cget out of jail free card\u201d. In fact, it\u2019s even more of a reason to be reviewing code. Reviews are a great way to learn, get across the product and see different programming styles. If you\u2019re like me, and find code reviews daunting,  ask to pair with a senior until you feel more confident. I recently paired with my mentor at Twitter and found it really helpful.\nGet friendly with feature flagging \n\nLesson #3: Feature flagging gives you complete control over how you build and release a project.\n\nSay you\u2019re implementing a new feature. It\u2019s going to take a few weeks to complete. You\u2019ll complete the feature in small, incremental changes. At what point do these changes get merged to master? At what point do they get deployed? Do you start at the back end and finish with the UI, so the user won\u2019t see the changes until they\u2019re ready? With feature flagging\u200a\u2014\u200ait doesn\u2019t matter. In fact, with feature flagging, by the time you are ready to release your feature, it\u2019s already deployed, sitting happily in master with the rest of your codebase.\u00a0\nA feature flag is a boolean value that gets wrapped around the code relating to the thing you\u2019re working on. The code will only be executed if the value is true.\nif (TD.decider.get(\u2018new_feature\u2019)) {\n    //code for new feature goes here\n}\nIn my first dev job, I deployed a navigation link to the feature I\u2019d been working on, making it visible in the product, even though the feature wasn\u2019t ready. \u201cWhy didn\u2019t you use a feature flag?\u201d a senior dev asked me. An honest response would have been: \u201cBecause they\u2019re confusing to implement and I don\u2019t understand the benefits of using them.\u201d The fix had to wait until the next deployment.\nThe best thing about feature flagging at TweetDeck is that there is no need to deploy to turn on or off a feature. We set the status of the feature via an interface called Deckcider, and the code makes regular API requests to get the status.\u00a0\nAt TweetDeck we are also able to roll our features out progressively. The first rollout might be to a staging environment. Then to employees only. Then to 10 per cent of users, 20 per cent, 30 per cent, and so on. A gradual rollout allows you to monitor for bugs and unexpected behaviour, before releasing the feature to the entire user base.\nSometimes a piece of work requires changes to existing business logic. So the code might look more like this:\nif (TD.decider.get(\u2018change_to_existing_feature\u2019)) {\n    //new logic goes here\n} else {\n    //old logic goes here\n}\nThis seems messy, right? Riddling your code with if else statements to determine which path of logic should be executed, or which version of the UI should be displayed. But at Twitter, this is embraced. You can always clean up the code once a feature is turned on. This isn\u2019t essential, though. At least not in the early days. When a cheeky bug is discovered, having the flag in place allows the feature to be very quickly turned off again. \nLet data and experimentation drive development \n\nLesson #4: Use data to determine the direction of your product and measure its success.\n\nThe first company I worked for placed a huge amount of emphasis on data-driven decision making. If we had an idea, or if we wanted to make a change, we were encouraged to \u201cbring data\u201d to show why it was necessary. \u201cWithout data, you\u2019re just another person with an opinion,\u201d the chief data scientist would say. This attitude helped to ensure we were building the right things for our customers. Instead of just plucking a new feature out of thin air, it was chosen based on data that reflected its need.\nBut how do you design that feature? How do you know that the design you choose will have the desired impact? That\u2019s where experiments come into play.\u00a0\nAt TweetDeck we make UI changes that we hope will delight our users. But the assumptions we make about our users are often wrong. Our front-end team recently sat in a room and tried to guess which UIs from A/B tests had produced better results. Half the room guessed incorrectly every time.\nWe can\u2019t assume a change we want to make will have the impact we expect. So we run an experiment. Here\u2019s how it works. Users are placed into buckets. One bucket of users will have access to the new feature, the other won\u2019t. We hypothesise that the bucket exposed to the new feature will have better results. The beauty of running an experiment is that we\u2019ll know for sure. Instead of blindly releasing the feature to all users without knowing its impact, once the experiment has run its course, we\u2019ll have the data to make decisions accordingly.\nHire the developer, not the degree\n\nLesson #5: Testing candidates on real world problems will allow applicants from all backgrounds to shine.\n\nSurely, a company like Twitter would give their applicants insanely difficult code tests, and the toughest technical questions, that only the cleverest CS graduates could pass, I told myself when applying for the job. Lucky for me, this wasn\u2019t the case. The process was insanely difficult\u2014don\u2019t get me wrong\u2014but the team at TweetDeck gave me real world problems to solve.\nThe first code test involved bug fixes, performance and testing. The second involved DOM traversal and manipulation. Instead of being put on the spot in a room with a whiteboard and pen I was given a task, access to the internet, and time to work on it. Similarly, in my technical interviews, I was asked to pair program on real world problems that I was likely to face on the job.\nIn one of my phone screenings I was told Twitter wanted to increase diversity in its teams. Not just gender diversity, but also diversity of experience and background. Six months later, with a bunch of new hires, team lead Tom Ashworth says TweetDeck has the most diverse team it\u2019s ever had. \u201cWe designed an interview process that gave us a way to simulate the actual job,\u201d he said. \u201cIt\u2019s not about testing whether you learnt an algorithm in school.\u201d\nIs this lowering the bar? No. The bar is whether a candidate has the ability to solve problems they are likely to face on the job. I recently spoke to a longstanding Atlassian engineer who said they hadn\u2019t seen an algorithm in their seven years at the company.\nThese days, only about 50 per cent of developers have computer science degrees. The majority of developers are self taught, learn on the job or via online courses. If you want to increase diversity in your engineering team, ensure your interview process isn\u2019t excluding these people.", "year": "2016", "author": "Amy Simmons", "author_slug": "amysimmons", "published": "2016-12-20T00:00:00+00:00", "url": "https://24ways.org/2016/my-first-18-months-as-a-dev/", "topic": "process"}
{"rowid": 163, "title": "Get To Grips with Slippy Maps", "contents": "Online mapping has definitely hit mainstream. Google Maps made \u2018slippy maps\u2019 popular and made it easy for any developer to quickly add a dynamic map to his or her website. You can now find maps for store locations, friends nearby, upcoming events, and embedded in blogs. \n\nIn this tutorial we\u2019ll show you how to easily add a map to your site using the Mapstraction mapping library. There are many map providers available to choose from, each with slightly different functionality, design, and terms of service. Mapstraction makes deciding which provider to use easy by allowing you to write your mapping code once, and then easily switch providers.\n\nAssemble the pieces\n\nUtilizing any of the mapping library typically consists of similar overall steps:\n\n\n\tCreate an HTML div to hold the map\n\tInclude the Javascript libraries\n\tCreate the Javascript Map element\n\tSet the initial map center and zoom level\n\tAdd markers, lines, overlays and more\n\n\nCreate the Map Div\n\nThe HTML div is where the map will actually show up on your page. It needs to have a unique id, because we\u2019ll refer to that later to actually put the map here. This also lets you have multiple maps on a page, by creating individual divs and Javascript map elements. The size of the div also sets the height and width of the map. You set the size using CSS, either inline with the element, or via a CSS reference to the element id or class. For this example, we\u2019ll use inline styling.\n\n<div id=\"map\" style=\"width: 400px; height: 400px;\"></div>\n\nInclude Javascript libraries\n\nA mapping library is like any Javascript library. You need to include the library in your page before you use the methods of that library. For our tutorial, we\u2019ll need to include at least two libraries: Mapstraction, and the mapping API(s) we want to display. Our first example we\u2019ll use the ubiquitous Google Maps library. However, you can just as easily include Yahoo, MapQuest, or any of the other supported libraries.\n\nAnother important aspect of the mapping libraries is that many of them require an API key. You will need to agree to the terms of service, and get an API key these.\n\n<script src=\"http://maps.google.com/maps?file=api&v=2&key=YOUR_KEY\" type=\"text/javascript\"></script>\n<script type=\"text/javascript\" src=\"http://mapstraction.com/src/mapstraction.js\"></script>\n\nCreate the Map\n\nGreat, we\u2019ve now put in all the pieces we need to start actually creating our map. This is as simple as creating a new Mapstraction object with the id of the HTML div we created earlier, and the name of the mapping provider we want to use for this map. \n\nWith several of the mapping libraries you will need to set the map center and zoom level before the map will appear. The map centering actually triggers the initialization of the map. \n\nvar mapstraction = new Mapstraction('map','google');\nvar myPoint = new LatLonPoint(37.404,-122.008);\nmapstraction.setCenterAndZoom(myPoint, 10);\n\nA note about zoom levels. The setCenterAndZoom function takes two parameters, the center as a LatLonPoint, and a zoom level that has been defined by mapping libraries. The current usage is for zoom level 1 to be \u201czoomed out\u201d, or view the entire earth \u2013 and increasing the zoom level as you zoom in. Typically 17 is the maximum zoom, which is about the size of a house. \n\nDifferent mapping providers have different quality of zoomed in maps over different parts of the world. This is a perfect reason why using a library like Mapstraction is very useful, because you can quickly change mapping providers to accommodate users in areas that have bad coverage with some maps. \n\nTo switch providers, you just need to include the Javascript library, and then change the second parameter in the Mapstraction creation. Or, you can call the switch method to dynamically switch the provider.\n\nSo for Yahoo Maps  (demo):\n\nvar mapstraction = new Mapstraction('map','yahoo');\n\nor Microsoft Maps (demo):\n\nvar mapstraction = new Mapstraction('map','microsoft');\n\nwant a 3D globe in your browser? try FreeEarth (demo):\n\nvar mapstraction = new Mapstraction('map','freeearth');\n\nor even OpenStreetMap (free your data!)  (demo):\n\nvar mapstraction = new Mapstraction('map','openstreetmap');\n\nVisit the Mapstraction multiple map demo page for an example of how easy it is to have many maps on your page, each with a different provider. \n\nAdding Markers\n\nWhile adding your first map is fun, and you can probably spend hours just sliding around, the point of adding a map to your site is usually to show the location of something. So now you want to add some markers. There are a couple of ways to add to your map.\n\nThe simplest is directly creating markers. You could either hard code this into a rather static page, or dynamically generate these using whatever tools your site is built on.\n\nvar marker = new Marker( new LatLonPoint(37.404,-122.008) );\nmarker.setInfoBubble(\"It's easy to add maps to your site\");\nmapstraction.addMarker( marker );\n\nThere is a lot more you can do with markers, including changing the icon, adding timestamps, automatically opening the bubble, or making them draggable. \n\nWhile it is straight-forward to create markers one by one, there is a much easier way to create a large set of markers. And chances are, you can make it very easy by extending some data you already are sharing: RSS. \n\nSpecifically, using GeoRSS you can easily add a large set of markers directly to a map. GeoRSS is a community built standard (like Microformats) that added geographic markup to RSS and Atom entries. It\u2019s as simple as adding <georss:point>42 -83</georss:point> to your feeds to share items via GeoRSS. Once you\u2019ve done that, you can add that feed as an \u2018overlay\u2019 to your map using the function:\n\nmapstraction.addOverlay(\"http://api.flickr.com/services/feeds/groups_pool.gne?id=322338@N20&format=rss_200&georss=1\");\n\nMapstraction also supports KML for many of the mapping providers. So it\u2019s easy to add various data sources together with your own data. Check out Mapufacture for a growing index of available GeoRSS feeds and KML documents. \n\nPlay with your new toys\n\nMapstraction offers a lot more functionality you can utilize for demonstrating a lot of geographic data on your website. It also includes geocoding and routing abstraction layers for making sure your users know where to go. You can see more on the Mapstraction website: http://mapstraction.com.", "year": "2007", "author": "Andrew Turner", "author_slug": "andrewturner", "published": "2007-12-02T00:00:00+00:00", "url": "https://24ways.org/2007/get-to-grips-with-slippy-maps/", "topic": "code"}
{"rowid": 247, "title": "Managing Flow and Rhythm with CSS Custom Properties", "contents": "An important part of designing user interfaces is creating consistent vertical rhythm between elements. Creating consistent, predictable space doesn\u2019t just make your web pages and views look better, but it can also improve the scan-ability. \nBrowsers ship with default CSS and these styles often create consistent rhythm for flow elements out of the box. The problem is though that we often reset these styles with a reset. Elements such as <div> and <section> also have no default margin or padding associated with them. \nI\u2019ve tried all sorts of weird and wonderful techniques to find a balance between using inherited CSS while also levelling the playing field for component driven front-ends with very little success. This experimentation is how I landed on the flow utility, though and I\u2019m going to show you how it works. Let\u2019s dive in!\nThe Flow utility\nWith the ever-growing number of folks working with component libraries and design systems, we could benefit from a utility that creates space for us, only when it\u2019s appropriate to do so. The problem with my previous attempts at fixing this is that the spacing values were very rigid. \nThat\u2019s fine for 90% of contexts, but sometimes, it\u2019s handy to be able to tweak the values based on the exact context of your component. This is where CSS Custom Properties come in handy.\nThe code\n.flow {\n  --flow-space: 1em;\n}  \n\n.flow > * + * { \n  margin-top: var(--flow-space);\n}\nWhat this code does is enable you to add a class of flow to an element which will then add margin-top to sibling elements within that element. We use the lobotomised owl selector to select these siblings. This approach enables an almost anonymous and automatic system which is ideal for component library based front-ends where components probably don\u2019t have any idea what surrounds them. \nThe other important part of this utility is the usage of the --flow-space custom property. We define it in the .flow component and each element within it will be spaced by --flow-space, by default. The beauty about setting this as a custom property is that custom properties also participate in the cascade, so we can utilise specificity to change it if we need it. Pretty cool, right? Let\u2019s look at some examples.\nA basic example\nSee the Pen CSS Flow Utility: Basic implementation by Andy Bell (@hankchizljaw) on CodePen.\nhttps://codepen.io/hankchizljaw/pen/LXqerj\nWhat we\u2019ve got in this example is some basic HTML content that has a class of flow on the parent article element. Because there\u2019s a very heavy-handed reset added as a dependency, all of the content would have been squished together without the flow utility. \nBecause our --flow-space custom property is set to 1em, the space between elements is 1X the font size of the element in question. This means that a <h2> in this context has a calculated margin-top value of 28.8px, because it has an assigned font size of 1.8rem. If we were to globally change the --flow-space value to 1.1em for example, we\u2019d affect everything because margin values would be calculated as 1.1X the font size. \nThis example looks great because using font size as the basis of rhythm works really well. What if we wanted to to tweak certain elements within this article, though? \nSee the Pen CSS Flow Utility: Tweaked Basic implementation by Andy Bell (@hankchizljaw) on CodePen.\nhttps://codepen.io/hankchizljaw/pen/qQgxaY\nI like lots of whitespace with my article layouts, so the 1em space isn\u2019t going to cut it for all elements. I like to provide plenty of space between headed sections, so I increase the --flow-space in these instances:\nh2 {\n  --flow-space: 3rem;\n}\nNotice also how I also switch over to using rem units? I want to make sure that these overrides are always based on the root font size. This is a personal preference of mine and you can use whatever units you want. Just be aware that it\u2019s better for accessibility to use flexible units like em, rem and %, so that a user\u2019s font size preferences are honoured. \nA more advanced example\nAlthough the flow utility is super useful for a plethora of contexts, it really shines when working with a few unrelated components. Instead of having to write specific layout CSS just for your particular context, you can use flow and --flow-space to create predictable and contextual space.\nSee the Pen CSS Flow Utility: Unrelated components by Andy Bell (@hankchizljaw) on CodePen.\nhttps://codepen.io/hankchizljaw/pen/ZmPGyL\nIn this example, we\u2019ve got ourselves a little prototype layout that features a media element, followed by a grid of features. By using flow, it was really quick and easy to generate space between those two main elements. It was also easy to create space within the components. For example, I added it to the .media__content element, so that the article\u2019s content would space itself:\n<article class=\"media__content flow\">\n  ...\n</article>\nSomething to remember though: the custom properties cascade in the same way that other CSS values do, so you\u2019ve got to keep that in mind. We\u2019ve got a great example of that in this example where because we\u2019ve got the flow utility on our .features component, which has a --flow-space override: the child elements of .features will inherit that value, so we\u2019ve had to set another value on the .features__list element.\n\u201cBut what about old browsers?\u201d, I hear you cry\nWe\u2019re using CSS Custom Properties that at the time of writing, have about 88% support. One thing we can do to remedy the other 12% of browsers is to set a default, traditional margin-top value of 1em, so it calculates itself based on the element\u2019s font-size:\n.flow {\n  --flow-space: 1em;\n}\n\n.flow > * + * { \n  margin-top: 1em;\n  margin-top: var(--flow-space);\n}\nThanks to the cascading and declarative nature of CSS, we can set that default margin-top value and then immediately set it to use the custom property instead. Browsers that understand Custom Properties will automatically apply them\u2014those that don\u2019t will ignore them. Yay for the cascade and progressive enhancement! \nWrapping up\nThis tiny little utility can bring great power for when you want to consistently space elements, vertically. It also\u2014thanks to the power of the modern web\u2014allows us to create contextual overrides without creating modifier classes or shame CSS. \nIf you\u2019ve got other methods of doing this sort of work, please let me know on Twitter. I\u2019d love to see what you\u2019re working on!", "year": "2018", "author": "Andy Bell", "author_slug": "andybell", "published": "2018-12-07T00:00:00+00:00", "url": "https://24ways.org/2018/managing-flow-and-rhythm-with-css-custom-properties/", "topic": "code"}
{"rowid": 138, "title": "Rounded Corner Boxes the CSS3 Way", "contents": "If you\u2019ve been doing CSS for a while you\u2019ll know that there are approximately 3,762 ways to create a rounded corner box. The simplest techniques rely on the addition of extra mark-up directly to your page, while the more complicated ones add the mark-up though DOM manipulation. While these techniques are all very interesting, they do seem somewhat of a kludge. The goal of CSS is to separate structure from presentation, yet here we are adding superfluous mark-up to our code in order to create a visual effect. The reason we are doing this is simple. CSS2.1 only allows a single background image per element.\n\nThankfully this looks set to change with the addition of multiple background images into the CSS3 specification. With CSS3 you\u2019ll be able to add not one, not four, but eight background images to a single element. This means you\u2019ll be able to create all kinds of interesting effects without the need of those additional elements.\n\nWhile the CSS working group still seem to be arguing over the exact syntax, Dave Hyatt went ahead and implemented the currently suggested mechanism into Safari. The technique is fiendishly simple, and I think we\u2019ll all be a lot better off once the W3C stop arguing over the details and allow browser vendors to get on and provide the tools we need to build better websites.\n\nTo create a CSS3 rounded corner box, simply start with your box element and apply your 4 corner images, separated by commas.\n\n.box {\n\tbackground-image: url(top-left.gif), url(top-right.gif), url(bottom-left.gif), url(bottom-right.gif);\n}\n\nWe don\u2019t want these background images to repeat, which is the normal behaviour, so lets set all their background-repeat properties to no-repeat.\n\n.box {\n\tbackground-image: url(top-left.gif), url(top-right.gif), url(bottom-left.gif), url(bottom-right.gif);\n\tbackground-repeat: no-repeat, no-repeat, no-repeat, no-repeat;\n}\n\nLastly, we need to define the positioning of each corner image.\n\n.box {\n\tbackground-image: url(top-left.gif), url(top-right.gif), url(bottom-left.gif), url(bottom-right.gif);\n\tbackground-repeat: no-repeat, no-repeat, no-repeat, no-repeat;\n\tbackground-position: top left, top right, bottom left, bottom right;\n}\n\nAnd there we have it, a simple rounded corner box with no additional mark-up.\n\nAs well as using multiple background images, CSS3 also has the ability to create rounded corners without the need of any images at all. You can do this by setting the border-radius property to your desired value as seen in the next example.\n\n.box {\n\tborder-radius: 1.6em;\n}\n\nThis technique currently works in Firefox/Camino and creates a nice, if somewhat jagged rounded corner. If you want to create a box that works in both Mozilla and WebKit based browsers, why not combine both techniques and see what happens.", "year": "2006", "author": "Andy Budd", "author_slug": "andybudd", "published": "2006-12-04T00:00:00+00:00", "url": "https://24ways.org/2006/rounded-corner-boxes-the-css3-way/", "topic": "code"}
{"rowid": 333, "title": "The Attribute Selector for Fun and (no ad) Profit", "contents": "If I had a favourite CSS selector, it would undoubtedly be the attribute selector (Ed: You really need to get out more). For those of you not familiar with the attribute selector, it allows you to style an element based on the existence, value or partial value of a specific attribute.\n\nAt it\u2019s very basic level you could use this selector to style an element with particular attribute, such as a title attribute.\n\n<abbr title=\"Cascading Style Sheets\">CSS</abbr>\n\nIn this example I\u2019m going to make all <abbr> elements with a title attribute grey. I am also going to give them a dotted bottom border that changes to a solid border on hover. Finally, for that extra bit of feedback, I will change the cursor to a question mark on hover as well. \n\nabbr[title] {\n     color: #666;\n     border-bottom: 1px dotted #666;\n }\n\n abbr[title]:hover {\n     border-bottom-style: solid;\n     cursor: help;\n }\n\nThis provides a nice way to show your site users that <abbr> elements with title tags are special, as they contain extra, hidden information.\n\nMost modern browsers such as Firefox, Safari and Opera support the attribute selector. Unfortunately Internet Explorer 6 and below does not support the attribute selector, but that shouldn\u2019t stop you from adding nice usability embellishments to more modern browsers.\n\nInternet Explorer 7 looks set to implement this CSS2.1 selector, so expect to see it become more common over the next few years.\n\nStyling an element based on the existence of an attribute is all well and good, but it is still pretty limited. Where attribute selectors come into their own is their ability to target the value of an attribute. You can use this for a variety of interesting effects such as styling VoteLinks.\n\nVoteWhats?\n\nIf you haven\u2019t heard of VoteLinks, it is a microformat that allows people to show their approval or disapproval of a links destination by adding a pre-defined keyword to the rev attribute.\n\nFor instance, if you had a particularly bad meal at a restaurant, you could signify your dissaproval by adding a rev attribute with a value of vote-against.\n\n<a href=\"http://www.mommacherri.co.uk/\" rev=\"vote-against\">Momma Cherri's</a>\n\nYou could then highlight these links by adding an image to the right of these links.\n\na[rev=\"vote-against\"]{\n     padding-right: 20px;\n     background: url(images/vote-against.png) no-repeat right top;\n}\n\nThis is a useful technique, but it will only highlight VoteLinks on sites you control. This is where user stylesheets come into effect. If you create a user stylesheet containing this rule, every site you visit that uses VoteLinks will receive your new style.\n\nCool huh?\n\nHowever my absolute favourite use for attribute selectors is as a lightweight form of ad blocking. Most online adverts conform to industry-defined sizes. So if you wanted to block all banner-ad sized images, you could simply add this line of code to your user stylesheet.\n\nimg[width=\"468\"][height=\"60\"],\nimg[width=\"468px\"][height=\"60px\"]  {\n     display: none !important;\n}\n\nTo hide any banner-ad sized element, such as flash movies, applets or iFrames, simply apply the above rule to every element using the universal selector.\n\n*[width=\"468\"][height=\"60\"], *[width=\"468px\"][height=\"60px\"]  {\n     display: none !important;\n}\n\nJust bare in mind when using this technique that you may accidentally hide something that isn\u2019t actually an advert; it just happens to be the same size.\n\nThe Interactive Advertising Bureau lists a number of common ad sizes. Using these dimensions, you can create stylesheet that blocks all the popular ad formats. Apply this as a user stylesheet and you never need to suffer another advert again.\n\nHere\u2019s wishing you a Merry, ad-free Christmas.", "year": "2005", "author": "Andy Budd", "author_slug": "andybudd", "published": "2005-12-11T00:00:00+00:00", "url": "https://24ways.org/2005/the-attribute-selector-for-fun-and-no-ad-profit/", "topic": "code"}
{"rowid": 14, "title": "The Command Position Principle", "contents": "Living where I do, in a small village in rural North Wales, getting anywhere means driving along narrow country roads. Most of these are just about passable when two cars meet. \n\nIf you\u2019re driving too close to the centre of the road, when two drivers meet you stop, glare at each other and no one goes anywhere. Drive too close to your nearside and in summer you\u2019ll probably scratch your paintwork on the hedgerows, or in winter you\u2019ll sink your wheels into mud. \n\nDriving these lanes requires a balance between caring for your own vehicle and consideration for someone else\u2019s, but all too often, I\u2019ve seen drivers pushed towards the hedgerows and mud when someone who\u2019s inconsiderate drives too wide because they don\u2019t want to risk scratching their own paintwork or getting their wheels dirty.\n\nIf you learn to ride a motorcycle,\u00a0you\u2019ll be taught about the command position:\n\n\n\tApproximate central position, or any position from which the rider can exert control over invitation space either side.\n\n\nThe command position helps motorcyclists stay safe, because when they ride in the centre of their lane it prevents other people, usually car drivers, from driving alongside, either forcing them into the curb or potentially dangerously close to oncoming traffic. \n\nTaking the command position isn\u2019t about motorcyclists being aggressive, it\u2019s about them being confident. It\u2019s them knowing their rightful place on the road and communicating that through how they ride.\n\nI\u2019ve recently been trying to take that command position when driving my car on our lanes. When I see someone coming in the opposite direction, instead of instinctively moving closer to my nearside \u2014 and in so doing subconsciously invite them into my space on the road \u2014 I hold both my nerve and a central position in my lane. Since I done this I\u2019ve noticed that other drivers more often than not stay in their lane or pull closer to their nearside so we occupy equal space on the road. Although we both still need to watch our wing mirrors, neither of us gets our paint scratched or our wheels muddy.\n\nWe can apply this principle to business too, in particular to negotiations and the way we sell. Here\u2019s how we might do that.\n\nCommanding negotiations\n\nWhen a customer\u2019s been sold to well \u2014\u00a0more on that in just a moment \u2014 and they\u2019ve made the decision to buy, the thing that usually stands in the way of us doing business is a negotiation over price. Some people treat negotiations as the equivalent of driving wide. They act offensively, because their aim is to force the other person into getting less, usually in return for giving more.\n\nIn encounters like this, it\u2019s easy for us to act defensively. We might lack confidence in the price we ask for, or the value of the product or service we offer. We might compromise too early because of that. When that happens, there\u2019s a pretty good chance that we\u2019ll drive away with less than we deserve unless we use the command position principle to help us.\n\nBefore we start any negotiation it\u2019s important to know that both sides ultimately want to reach an agreement. This isn\u2019t always obvious. If one side isn\u2019t already committed, at least in principle, then it\u2019s not a negotiation at that point, it\u2019s something else. \n\nFor example, a prospective customer may be looking to learn our lowest price so that they can compare it to our competitors. When that\u2019s the case, we\u2019ve probably failed to qualify that prospect properly as, after all, who wants to be chosen simply because they\u2019re the cheapest? In this situation, negotiating is a waste of time since we don\u2019t yet know that it will result in us making a deal. We should enter into a negotiation only when we know where we stand. So ask confidently: \u201cAre you looking to [make a decision]?\u201d\n\nWhen that\u2019s been confirmed, it\u2019s down to everyone to compromise until a deal\u2019s been reached. That\u2019s because good negotiations aren\u2019t about one side beating the other, they\u2019re about achieving a good deal for both. Using the command position principle helps us to maintain control over our negotiating space and affords us the opportunity to give ground only if we need to and only when we\u2019re ready. It can also ensure that the person we\u2019re negotiating with gives up some of their space.\n\nCommanding sales\n\nIt\u2019s not always necessary to negotiate when we\u2019re doing a business deal, but we should always be prepared to sell. One of the most important parts of our sales process should be controlling when and how we tell someone our price. \n\nUnless it\u2019s impossible to avoid, don\u2019t work out a price for someone on the spot. When we do that we lose control over the time and place for presenting our price alongside the value factors that will contribute to the prospective customer accepting that price. For the same reason, never give a ballpark or, worse, a guesstimate figure. If the question of price comes up before we\u2019re fully prepared, we should say politely that we need more time to work out a meaningful cost. \n\nWhen we are ready, we shouldn\u2019t email a price for our prospective customer to read unaccompanied. Instead, create an opportunity to talk a prospect through our figures, demonstrate how we arrived at them and, most importantly, explain the value of what we\u2019re selling to their business. Agree a time and place to do this and, if possible, do it all face-to-face.  \n\nWe shouldn\u2019t hesitate when we give someone a price. When we sound even the slightest bit unsure or apologetic, we give the impression that we\u2019ll be flexible in our position before negotiations have even begun.\n\nThink about the command position principle, know the price and present it confidently. That way we send a clear signal that we know our business and how we deal with people. The command position principle isn\u2019t about being cocky, it\u2019s about showing other people respect, asking for it in return and showing it to ourselves.\n\n \n\nEarlier, I mentioned selling well, because we sometimes hear people say that they dislike being sold to. In my experience, it\u2019s not that people dislike the sales process, it\u2019s that we dislike it done badly.\n\nTaking part in a good sales process, either by selling or being sold to, can be a pleasurable experience. Try to be confident \u2014 after all, we understand how our skills will benefit a customer better than anyone else. Our confidence will inspire confidence in others. \n\nSelf-confidence isn\u2019t the same as arrogance, just as the command position isn\u2019t the same as riding without consideration for others. The command position principle preserves others\u2019 space as well as our own. By the same token, we should be considerate of others\u2019 time and not waste it and our own by attempting to force them into buying something that\u2019s inappropriate.\n\nTo prevent this from happening, evaluate them well to ensure that they\u2019re the right customer for us. If they\u2019re not, let them go on their way. They\u2019ll thank us for it and may well become customers the next time we meet.\n\nThe business of closing a deal can be made an enjoyable experience for everyone if we take control by guiding someone through the sales process by asking the right questions to uncover their concerns, then allaying them by being knowledgeable and confident. This is riding in the command position.\n\nJust like demonstrating we know our rightful position on the road, knowing our rightful place in a business relationship and communicating that through how we deal with people will help everyone achieve an equitable balance. When that happens in business, as well as on the road, no one gets their paintwork scratched or their wheels muddy.", "year": "2013", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2013-12-23T00:00:00+00:00", "url": "https://24ways.org/2013/the-command-position-principle/", "topic": "business"}
{"rowid": 44, "title": "Taglines and Truisms", "contents": "To bring her good luck, \u201cwhite rabbits\u201d was the first thing that my grandmother said out loud on the first day of every month. We all need a little luck, but we shouldn\u2019t rely on it, especially when it comes to attracting new clients.\n\nThe first thing we say to a prospective client when they visit our website for the first time helps them to understand not only what we do but why we do it. We can also help them understand why they should choose to work with us over one of our competitors.\n\nTake a minute or two to look at your competitors\u2019 websites. What\u2019s the first thing that they say about themselves? Do they say that they \u201cdesign delightful digital experiences,\u201d \u201ccraft beautiful experiences\u201d or \u201ccreate remarkable digital experiences?\u201d\n\nIt\u2019s easy to find companies who introduce themselves with what they do, their proposition, but what a company does is only part of their story. Their beliefs and values, what they stand for why they do what they do are also important. \n\nWhen someone visits our websites for the first time, we have only a brief moment to help them understand us. To help us we can learn from the advertising industry, where the job of a tagline is to communicate a concept, deliver a message and sell a product, often using only a few words.\n\nWhen an advertising campaign is effective, its tagline stays with you, sometimes long after that campaign is over. For example, can you remember which company or brand these taglines help to sell? (Answers at the bottom of the article:)\n\n\nThe Ultimate Driving Machine\nJust Do It\nDon\u2019t Leave Home Without It\n\n\nA clever tagline isn\u2019t just a play on words, although it can include one. A tagline does far more than help make your company memorable. Used well, it brings together notions of what makes your company and what you offer special. Then it expresses those notions in a few words or possibly a short sentence. \n\nI\u2019m sure that everyone can find examples of company slogans written in the type of language that should stay within the walls of a marketing department. We can also find taglines where the meaning is buried so deep that the tag itself becomes effectively meaningless.\n\nA meaningful tagline supports our ideas about who we are and what we offer, and provides a platform for different executions of them, sometimes over a period of time. For a tagline to work well, it must allow for current and future ideas about a brand.\n\nIt must also be meaningful to our brand and describe a truism, a truth that need not be a fact or statistic, but something that\u2019s true about us, who we are, what we do and why that\u2019s distinctive. It can be obvious, funny, serious or specific but above all it must be true. It should also be difficult to argue with, making your messages difficult to argue with too.\n\nI doubt that I need remind you who this tagline belongs to:\n\n\n\tThere are some things money can\u2019t buy. For everything else there\u2019s MasterCard.\n\n\nThat tagline was launched in 1997 by McCann-Erickson along with the \u201cPriceless\u201d campaign and it helped establish MasterCard as a friendlier credit card company, one with a sense of humour. \n\nMasterCard\u2019s truism is that the things which really matter in life can\u2019t be bought. They are worth more than anything that a monetary value can be applied to. In expressing that truism through the tagline, MasterCard\u2019s advertising tells people to use not just any credit card, but their MasterCard, to pay for everything they buy.\n\n\u201cGuinness is good for you\u201d may have been a stretch, but \u201cGood things come to those who wait\u201d builds on the truism that patience is a virtue and therefore a good pint of Guinness takes time to pour (119.5 seconds. I know you were wondering.)\n\nThe fact that British Airways flies to more destinations than any other airline is their truism, and led their advertisers to the now famous tagline, \u201cThe world\u2019s favourite airline.\u201d\n\n\n\nAt my company, Stuff & Nonsense, we\u2019ve been thinking about taglines as we think about our position within an industry that seems full of companies who \u201cdesign\u201d, \u201ccraft\u201d, and \u201ccreate\u201d \u201cdelightful\u201d, \u201cbeautiful\u201d, \u201cremarkable digital experiences\u201d.\n\nMuch of what made us different has changed along with the type of work we\u2019re interested in doing. Our work\u2019s expanded beyond websites and now includes design for mobile and other media. It\u2019s true we can\u2019t know how or where it will be seen. The ways that we make it are flexible too as we\u2019re careful not to become tied to particular tools or approaches. \n\nIt\u2019s also true that we\u2019re a small team. One that\u2019s flexible enough to travel around the world to work alongside our clients. We join their in-house teams and we collaborate with them in ways that other agencies often find more difficult. We know that our clients appreciate our flexibility and have derived enormous value from it. We know that we\u2019ve won business because of it and that it\u2019s now a big part of our proposition.\n\nOur truism is that we\u2019re flexible, \u201cFabulously flexible\u201d as our tagline now expresses. And although we know that there may be other agencies who can be similarly flexible \u2013 after all, being flexible is not a unique selling proposition \u2013 only we do it so fabulously.\n\n\n\nAs the old year rolls into the new, how will your company describe what you do in 2015? More importantly, how will you tell prospective clients why you do it, what matters to you and why they should work with you?\n\nStart by writing a list of truisms about your company. Write as many as you can, but then whittle that list down to just one, the most important truth. Work on that truism to create a tagline that\u2019s meaningful, difficult to be argue with and, above all, uniquely yours.\n\nAnswers\n\n\nThe Ultimate Driving Machine (BMW)\nJust Do It (Nike)\nDon\u2019t Leave Home Without It (American Express)", "year": "2014", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2014-12-23T00:00:00+00:00", "url": "https://24ways.org/2014/taglines-and-truisms/", "topic": "business"}
{"rowid": 51, "title": "Blow Your Own Trumpet", "contents": "Even if your own trumpet\u2019s tiny and fell out of a Christmas cracker, blowing it isn\u2019t something that everyone\u2019s good at. Some people find selling themselves and what they do difficult. But, you know what? Boo hoo hoo. If you want people to buy something, the reality is you\u2019d better get good at selling, especially if that something is you.\nFor web professionals, the best place to tell potential business customers or possible employers about what you do is on your own website. You can write what you want and how you want, but that doesn\u2019t make knowing what to write any easier. As a matter of fact, writing for yourself often proves harder than writing for someone else.\nI spent this autumn thinking about what I wanted to say about  Stuff & Nonsense on the website we relaunched recently. While I did that, I spoke to other designers about how they struggled to write about their businesses.\nIf you struggle to write well, don\u2019t worry. You\u2019re not on your own. Here are five ways to hit the right notes when writing about yourself and your work.\nBe genuine about who you are\nI\u2019ve known plenty of talented people who run a successful business pretty much single-handed. Somehow they still feel awkward presenting themselves as individuals. They wonder whether describing themselves as a company will give them extra credibility. They especially agonise over using \u201cwe\u201d rather than \u201cI\u201d when describing what they do. These choices get harder when you\u2019re a one-man band trading as a limited company or LLC business entity.\nIf you mainly work alone, don\u2019t describe yourself as anything other than \u201cI\u201d. You might think that saying \u201cwe\u201d makes you appear larger and will give you a better chance of landing bigger and better work, but the moment a prospective client asks, \u201cHow many people are you?\u201d you\u2019ll have some uncomfortable explaining to do. This will distract them from talking about your work and derail your sales process. There\u2019s no need to be anything other than genuine about how you describe yourself. You should be proud to say \u201cI\u201d because working alone isn\u2019t something that many people have the ability, business acumen or talent to do.\nExplain what you actually do\nHow many people do precisely the same job as you? Hundreds? Thousands? The same goes for companies. If yours is a design studio, development team or UX consultancy, there are countless others saying exactly what you\u2019re saying about what you do. Simply stating that you code, design or \u2013 God help me \u2013 \u201chandcraft digital experiences\u201d isn\u2019t enough to make your business sound different from everyone else. Anyone can and usually does say that, but people buy more than deliverables. They buy something that\u2019s unique about you and your business.\nPotentially thousands of companies deliver code and designs the same way as Stuff & Nonsense, but our clients don\u2019t just buy page designs, prototypes and websites from us. They buy our taste for typography, colour and layout, summed up by our \u201cIt\u2019s the taste\u201d tagline and bowler hat tip to the PG Tips chimps. We hope that potential clients will understand what\u2019s unique about us. Think beyond your deliverables to what people actually buy, and sell the uniqueness of that.\nDescribe work in progress\nIt\u2019s sad that current design trends have made it almost impossible to tell one website from another. So many designers now demonstrate finished responsive website designs by pasting them onto iMac, MacBook, iPad and iPhone screens that their portfolios don\u2019t fare much better. Every designer brings their own experience, perspective and process to a project. In my experience, it\u2019s understanding those differences which forms a big part of how a prospective client makes a decision about who to work with. Don\u2019t simply show a prospective client the end result of a previous project; explain your process, the development of your thinking and even the wrong turns you took.\nTraditional case studies, like the one I\u2019ve just written about Stuff & Nonsense\u2019s work for WWF UK, can take a lot of time. That\u2019s probably why many portfolios get out of date very quickly. Designers make new work all the time, so there must be a better way to show more of it more often, to give prospective clients a clearer understanding of what we do. At Stuff & Nonsense our solution was to create a feed where we could post fragments of design work throughout a project. This also meant rewriting our Contract Killer to give us permission to publish work before someone signs it off.\nOutline a client\u2019s experience\nRecently a client took me to one side and offered some valuable advice. She told me that our website hadn\u2019t described anything about the experience she\u2019d had while working with us. She said that knowing more about how we work would\u2019ve helped her make her buying decision.\nWhen a client chooses your business, they\u2019re hoping for more than a successful outcome. They want their project to run smoothly. They want to feel that they made a correct decision when they chose you. If they work for an organisation, they\u2019ll want their good judgement to be recognised too. Our client didn\u2019t recognise her experience because we hadn\u2019t made our own website part of it. Remember, the challenge of creating a memorable user experience starts with selling to the people paying you for it.\nAddress your ideal client\nIt\u2019s important to understand that a portfolio\u2019s job isn\u2019t to document your work, it\u2019s to attract new work from clients you want. Make sure that work you show reflects the work you want, because what you include in your portfolio often leads to more of the same.\nWhen you\u2019re writing for your portfolio and elsewhere on your website, imagine that you\u2019re addressing your ideal client. Picture them sitting opposite and answer the questions they\u2019d ask as you would in conversation. Be direct, funny if that\u2019s appropriate and serious when it\u2019s not. If it helps, ask a friend to read the questions aloud and record what you say in response. This will help make what you write sound natural. I\u2019ve found this technique helps clients write copy too.\nToot your own horn\nSome people confuse expressing confidence in yourself and your work as boastfulness, but in a competitive world the reality is that if you are to succeed, you need to show confidence so that others can show their confidence in you. If you want people to hear you, pick up your trumpet and blow it.", "year": "2015", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2015-12-23T00:00:00+00:00", "url": "https://24ways.org/2015/blow-your-own-trumpet/", "topic": "business"}
{"rowid": 90, "title": "Monkey Business", "contents": "\u201cToo expensive.\u201d \u201cOver-priced.\u201d \u201cA bit rich.\u201d\n\nThey all mean the same thing.\n\nWhen you say that something\u2019s too expensive, you\u2019re doing much more than commenting on a price. You\u2019re questioning the explicit or implicit value of a product or a service. You\u2019re asking, \u201cWill I get out of it what you want me to pay for it?\u201d You\u2019re questioning the competency, judgement and possibly even integrity of the individual or company that gave you that price, even though you don\u2019t realise it. You might not be saying it explicitly, but what you\u2019re implying is, \u201cHave you made a mistake?\u201d, \u201cAm I getting the best deal?\u201d, \u201cAre you being honest with me?\u201d, \u201cCould I get this cheaper?\u201d\n\nFinally, you\u2019re being dishonest, because deep down you know all too well that there\u2019s no such thing as too expensive. \n\nWhy? \n\nIt doesn\u2019t matter what you\u2019re questioning the price of. It could be a product, a service or the cost of an hour, day or week of someone\u2019s time. Whatever you\u2019re buying, too expensive is always an excuse. Saying it shifts acceptability of a price back to the person who gave it. What you should say, but are too afraid to admit, is:\n\n\n\t\u201cIt\u2019s more money than I wanted to pay.\u201d\n\t\u201cIt\u2019s more than I estimated it would cost.\u201d\n\t\u201cIt\u2019s more than I can afford.\u201d\n\n\nEveryone who\u2019s given a price for a product or service will have been told at some point that it\u2019s too expensive. It\u2019s never comfortable to hear that. Thoughts come thick and fast: \u201cWhat do I do?\u201d \u201cHow do I react?\u201d \u201cDo I really want the business?\u201d \u201cAm I prepared to negotiate?\u201d \u201cHow much am I willing to compromise?\u201d\n\nIt\u2019s easy to be defensive when someone questions a price, but before you react, stay calm and remember that if someone says what you\u2019re offering is too expensive, they\u2019re saying more about themselves and their situation than they are about your price. Learn to read that situation and how to follow up with the right questions.\n\nImagine you\u2019ve quoted someone for a week of your time. \u201cThat\u2019s too expensive,\u201d they respond. How should you handle that? Think about what they might otherwise be saying.\n\n\n\n\u201cIt\u2019s more money than I want to pay\u201d may mean that they don\u2019t understand the value of your service. How could you respond?\n\nStart by asking what similar projects they\u2019ve worked on and the type of people they worked with. Find out what they paid and what they got for their money, because it\u2019s possible what you offer is different from what they had before. Ask if they saw a return on that previous investment. Maybe their problem isn\u2019t with your headline price, but the value they think they\u2019ll receive. Put the emphasis on value and shift the conversation to what they\u2019ll gain, rather than what they\u2019ll spend.\n\nIt\u2019s also possible they can\u2019t distinguish your service from those of your competitors, so now would be a great time to explain the differences. Do you work faster? Explain how that could help them launch faster, get customers faster, make money faster. Do you include more? Emphasise that, and how unique the experience of working with you will be.\n\n\n\n\u201cIt\u2019s more than I estimated it would cost\u201d could mean that your customer hasn\u2019t done their research properly. You\u2019d never suggest that to them, of course, but you should ask how they\u2019ve arrived at their estimate. Did they base it on work they\u2019ve purchased previously? How long ago was that? Does it come from comparable work or from a different sector?\n\nHelp your customer by explaining how you arrived at your estimate. Break down each element and while you\u2019re doing that, emphasise the parts of your process that you know will appeal to them. If you know that they\u2019ve had difficulty with something in the past, explain how your approach will benefit them. People almost always value a positive experience more than the money they\u2019ll save.\n\n\n\n\u201cIt\u2019s more than I can afford\u201d could mean they can\u2019t afford what you offer at all, but it could also mean they can\u2019t afford it right now or all at once. So ask if they could afford what you\u2019re asking if they spread payment over a longer period? Ask, \u201cWould that mean you\u2019ll give me the business?\u201d\n\nIt\u2019s possible they\u2019re asking for too much for what they can afford to pay. Will they compromise? Can you reach an agreement on something less? Ask, \u201cIf we can agree what\u2019s in and what\u2019s out, will you give me the business?\u201d\n\nWhat can they afford? When you know, you\u2019re in a good position to decide if the deal makes good business sense, for both of you. Ask, \u201cIf I can match that price, will you give me the business?\u201d\n\nThere\u2019s no such thing as \u201ca bit rich\u201d, only ways for you to get to know your customer better. There\u2019s no such thing as \u201cover-priced\u201d,\u00a0only opportunities for you to explain yourself better. You should relish those opportunities. There\u2019s really also no such thing as \u201ctoo expensive\u201d, just ways to set the tone for your relationship and help you develop that relationship to a point where money will be less of a deciding factor.\n\nUnfinished Business\n\nJoin me and my co-host Anna Debenham next year for Unfinished Business, a new discussion show about the business end of working in web, design and creative industries.", "year": "2012", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2012-12-23T00:00:00+00:00", "url": "https://24ways.org/2012/monkey-business/", "topic": "business"}
{"rowid": 105, "title": "Contract Killer", "contents": "When times get tough, it can often feel like there are no good people left in the world, only people who haven\u2019t yet turned bad. These bad people will go back on their word, welch on a deal, put themselves first. You owe it to yourself to stay on top. You owe it to yourself to ensure that no matter how bad things get, you\u2019ll come away clean. You owe it yourself and your business not to be the guy lying bleeding in an alley with a slug in your gut.\n\nBut you\u2019re a professional, right? Nothing bad is going to happen to you.\n\nYou\u2019re a good guy. You do good work for good people.\n\nThink again chump.\n\nMaybe you\u2019re a gun for hire, a one man army with your back to the wall and nothing standing between you and the line at a soup kitchen but your wits. Maybe you work for the agency, or like me you run one of your own. Either way, when times get tough and people get nasty, you\u2019ll need more than a killer smile to save you. You\u2019ll need a killer contract too.\n\nIt was exactly ten years ago today that I first opened my doors for business. In that time I\u2019ve thumbed through enough contracts to fill a filing cabinet. I\u2019ve signed more contracts than I can remember, many so complicated that I should have hired a lawyer (or detective) to make sense of their complicated jargon and solve their cross-reference puzzles. These documents had not been written to be understood on first reading but to spin me around enough times so as to give the other player the upper-hand.\n\n\nIf signing a contract I didn\u2019t fully understand made me a stupid son-of-a-bitch, not asking my customers to sign one just makes me plain dumb. I\u2019ve not always been so careful about asking my customers to sign contracts with me as I am now. Somehow in the past I felt that insisting on a contract went against the friendly, trusting relationship that I like to build with my customers. Most of the time the game went my way. On rare the occasions when a fight broke out, I ended up bruised and bloodied. I learned that asking my customers to sign a contract matters to both sides, but what also matters to me is that these contracts should be more meaningful, understandable and less complicated than any of those that I have ever autographed.\n\n\nWriting a killer contract\n\nIf you are writing a contract between you and your customers it doesn\u2019t have to conform to the seemingly standard format of jargon and complicated legalese. You can be creative. A killer contract will clarify what is expected of both sides and it can also help you to communicate your approach to doing business. It will back-up your brand values and help you to build a great relationship between you and your customers. In other words, a creative contract can be a killer contract.\n\n\nYour killer contract should cover:\n\n\n\tA simple overview of who is hiring who, what they are being hired to do, when and for how much\n\tWhat both parties agree to do and what their respective responsibilities are\n\tThe specifics of the deal and what is or isn\u2019t included in the scope\n\tWhat happens when people change their minds (as they almost always do)\n\tA simple overview of liabilities and other legal matters\n\tYou might even include a few jokes\n\n\nTo help you along, I will illustrate those bullet points by pointing both barrels at the contract that I wrote and have been using at Stiffs & Nonsense for the past year. My contract has been worth its weight in lead and you are welcome to take all or any part of it to use for yourself. It\u2019s packing a creative-commons attribution share-a-like license. That means you are free to re-distribute it, translate it and otherwise re-use it in ways I never considered. In return I only ask you mention my name and link back to this article. As I am only an amateur detective, you should have it examined thoroughly by your own, trusted legal people if you use it.\n\nNB: The specific details of this killer contract work for me and my customers. That doesn\u2019t mean that they will work for you and yours. The ways that I handle design revisions, testing, copyright ownership and other specifics are not the main focus of this article. That you handle each of them carefully when you write your own killer contract is.\n\nKiss Me, Deadly\n\nSetting a tone and laying foundations for agreement\n\nThe first few paragraphs of a killer contract are the most important. Just like a well thought-out web page, these first few words should be simple, concise and include the key points in your contract. As this is the part of the contract that people absorb most easily, it is important that you make it count. Start by setting the overall tone and explaining how your killer contract is structured and why it is different.\n\n\n\n\tWe will always do our best to fulfill your needs and meet your goals, but sometimes it is best to have a few simple things written down so that we both know what is what, who should do what and what happens if stuff goes wrong. In this contract you won\u2019t find complicated legal terms or large passages of unreadable text. We have no desire to trick you into signing something that you might later regret. We do want what\u2019s best for the safety of both parties, now and in the future.\n\n\tIn short\n\n\tYou ([customer name]) are hiring us ([company name]) located at [address] to [design and develop a web site] for the estimated total price of [total] as outlined in our previous correspondence. Of course it\u2019s a little more complicated, but we\u2019ll get to that.\n\n\nThe Big Kill\n\nWhat both parties agree to do\n\nHave you ever done work on a project in good faith for a junior member of a customer\u2019s team, only to find out later that their spending hadn\u2019t been authorized? To make damn sure that does not happen to you,  you should ask your customer to confirm that not only are they authorized to enter into your contract but that they will fulfill all of their obligations to help you meet yours. This will help you to avoid any gunfire if, as deadline day approaches, you have fulfilled your side of the bargain but your customer has not come up with the goods.\n\n\n\n\tAs our customer, you have the power and ability to enter into this contract on behalf of your company or organization. You agree to provide us with everything that we need to complete the project including text, images and other information as and when we need it, and in the format that we ask for. You agree to review our work, provide feedback and sign-off approval in a timely manner too. Deadlines work two ways and you will also be bound by any dates that we set together. You also agree to stick to the payment schedule set out at the end of this contract.\n\n\tWe have the experience and ability to perform the services you need from us and we will carry them out in a professional and timely manner. Along the way we will endeavor to meet all the deadlines set but we can\u2019t be responsible for a missed launch date or a deadline if you have been late in supplying materials or have not approved or signed off our work on-time at any stage. On top of this we will also maintain the confidentiality of any information that you give us.\n\n\nMy Gun Is Quick\n\nGetting down to the nitty gritty\n\nWhat appear at first to be a straight-forward projects can sometimes turn long and complicated and unless you play it straight from the beginning your relationship with your customer can suffer under the strain. Customers do, and should have the opportunity to, change their minds and give you new assignments. After-all, projects should be flexible and few customers know from the get-go exactly what they want to see. If you handle this well from the beginning you will help to keep yourself and your customers from becoming frustrated. You will also help yourself to dodge bullets in the event of a fire-fight.\n\n\n\n\tWe will create designs for the look-and-feel, layout and functionality of your web site. This contract includes one main design plus the opportunity for you to make up to two rounds of revisions. If you\u2019re not happy with the designs at this stage, you will pay us in full for all of the work that we have produced until that point and you may either cancel this contract or continue to commission us to make further design revisions at the daily rate set out in our original estimate.\n\n\tWe know from plenty of experience that fixed-price contracts are rarely beneficial to you, as they often limit you to your first idea about how something should look, or how it might work. We don\u2019t want to limit  either your options or your opportunities to change your mind.\n\n\tThe estimate/quotation prices at the beginning of this document are based on the number of days that we estimate we\u2019ll need to accomplish everything that you have told us you want to achieve. If you do want to change your mind, add extra pages or templates or even add new functionality, that won\u2019t be a problem. You will be charged the daily rate set out in the estimate we gave you. Along the way we might ask you to put requests in writing so we can keep track of changes.\n\n\nAs I like to push my luck when it comes to CSS, it never hurts to head off the potential issue of progressive enrichment right from the start. You should do this too. But don\u2019t forget that when it comes to technical matters your customers may have different expectations or understanding, so be clear about what you will and won\u2019t do.\n\n\n\n\tIf the project includes XHTML or HTML markup and CSS templates, we will develop these using valid XHTML 1.0 Strict markup and CSS2.1 + 3 for styling. We will test all our markup and CSS in current versions of all major browsers including those made by Apple, Microsoft, Mozilla and Opera. We will also test to ensure that pages will display visually in a \u2018similar\u2019, albeit not necessarily an identical way, in Microsoft Internet Explorer 6 for Windows as this browser is now past it\u2019s sell-by date.\n\n\tWe will not test these templates in old or abandoned browsers, for example Microsoft Internet Explorer 5 or 5.5 for Windows or Mac, previous versions of Apple\u2019s Safari, Mozilla Firefox or Opera unless otherwise specified. If you need to show the same or similar visual design to visitors using these older browsers, we will charge you at the daily rate set out in our original estimate for any necessary additional code and its testing.\n\n\nThe Twisted Thing\n\nIt is not unheard of for customers to pass off stolen goods as their own. If this happens, make sure that you are not the one left holding the baby. You should also make it clear who owns the work that you make as customers often believe that because they pay for your time, that they own everything that you produce.\n\n\nCopyrights\n\n\n\tYou guarantee to us that any elements of text, graphics, photos, designs, trademarks, or other artwork that you provide us for inclusion in the web site are either owned by your good selfs, or that you have permission to use them. When we receive your final payment, copyright is automatically assigned as follows:\n\n\tYou own the graphics and other visual elements that we create for you for this project. We will give you a copy of all files and you should store them really safely as we are not required to keep them or provide any native source files that we used in making them.\n\n\tYou also own text content, photographs and other data you provided, unless someone else owns them. We own the XHTML markup, CSS and other code and we license it to you for use on only this project.\n\n\nVengeance Is Mine!\n\nThe fine print\n\nUnless your work is pro-bono, you should make sure that your customers keep you in shoe leather. It is important that your customers know from the outset that they must pay you on time if they want to stay on good terms.\n\n\n\tWe are sure you understand how important it is as a small business that you pay the invoices that we send you promptly.  As we\u2019re also sure you\u2019ll want to stay friends, you agree to stick tight to the following payment schedule.\n\n\t[Payment schedule]\n\n\nNo killer contract would be complete without you making sure that you are watching your own back. Before you ask your customers to sign, make it clear-cut what your obligations are and what will happen if any part of your killer contract finds itself laying face down in the dirt.\n\n\n\n\tWe can\u2019t guarantee that the functions contained in any web page templates or in a completed web site will always be error-free and so we can\u2019t be liable to you or any third party for damages, including lost profits, lost savings or other incidental, consequential or special damages arising out of the operation of or inability to operate this web site and any other web pages, even if you have advised us of the possibilities of such damages.\n\n\tJust like a parking ticket, you cannot transfer this contract to anyone else without our permission. This contract stays in place and need not be renewed.  If any provision of this agreement shall be unlawful, void, or for any reason unenforceable, then that provision shall be deemed severable from this agreement and shall not affect the validity and enforceability of any remaining provisions.\n\n\tPhew.\n\n\tAlthough the language is simple, the intentions are serious and this contract is a legal document under exclusive jurisdiction of [English] courts. Oh and don\u2019t forget those men with big dogs.\n\n\nSurvival\u2026 Zero!\n\nTake it from me, packing a killer contract will help to keep you safe when times get tough, but you must still keep your wits about you and stay on the right side of the law.\n\nDon\u2019t be a turkey this Christmas.\n\nBe a contract killer.\n\nUpdate, May 2010: For a follow-on to this article see Contract Killer: The Next Hit", "year": "2008", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2008-12-23T00:00:00+00:00", "url": "https://24ways.org/2008/contract-killer/", "topic": "business"}
{"rowid": 122, "title": "A Message To You, Rudy - CSS Production Notes", "contents": "When more than one designer or developer work together on coding an XHTML/CSS template, there are several ways to make collaboration effective. Some prefer to comment their code, leaving a trail of bread-crumbs for their co-workers to follow. Others use accompanying files that contain their working notes or communicate via Basecamp.\n\nFor this year\u2019s 24ways I wanted to share a technique that I has been effective at Stuff and Nonsense; one that unfortunately did not make it into the final draft of Transcending CSS. This technique, CSS production notes, places your page production notes in one convenient place within an XHTML document and uses nothing more than meaningful markup and CSS.\n\nLet\u2019s start with the basics; a conversation between a group of people. In the absence of notes or conversation elements in XHTML you need to make an XHTML compound that will effectively add meaning to the conversation between designers and developers. As each person speaks, you have two elements right there to describe what has been said and who has spoken: <blockquote> and its cite attribute. \n\n<blockquote cite=\"andy\"> \n\t<p>This project will use XHTML1.0 Strict, CSS2.1 and all that malarkey.</p>\n</blockquote>\n\nWith more than one person speaking, you need to establish a temporal order for the conversation. Once again, the element to do just that is already there in XHTML; the humble ordered list.\n\n<ol id=\"notes\">\n\t<li>\n\t\t<blockquote cite=\"andy\"> \n\t\t\t<p>This project will use XHTML1.0 Strict, CSS2.1 and all that malarkey.</p>\n\t\t</blockquote> \n\t</li>\n\t<li>\n\t\t<blockquote cite=\"dan\"> \n\t\t\t<p>Those bits are simple and bulletproof.</p>\n\t\t</blockquote> \n\t</li>\n</ol>\n\nAdding a new note is as simple as adding a new item to list, and if you prefer to add more information to each note, such as the date or time that the note was written, go right ahead. Place your note list at the bottom of the source order of your document, right before the closing <body> tag. One advantage of this approach over using conventional comments in your code is that all the notes are unobtrusive and are grouped together in one place, rather than being spread throughout your document.\n\nBasic CSS styling\n\nFor the first stage you are going to add some basic styling to the notes area, starting with the ordered list. For this design I am basing the look and feel on an instant messenger window.\n\n\n\nol#notes {\n\twidth : 300px; \n\theight : 320px; \n\tpadding : .5em 0; \n\tbackground : url(im.png) repeat; \n\tborder : 1px solid #333; \n\tborder-bottom-width : 2px; \n\t-moz-border-radius : 6px; /* Will not validate */\n\tcolor : #000; \n\toverflow : auto; \n}\nol#notes li { \n\tmargin : .5em; \n\tpadding : 10px 0 5px; \n\tbackground-color : #fff; \n\tborder : 1px solid #666; \n\t-moz-border-radius : 6px; /* Will not validate */ \n}\nol#notes blockquote { \n\tmargin : 0; \n\tpadding : 0; \n}\nol#notes p { \n\tmargin : 0 20px .75em;\n\tpadding : 0; \n}\nol#notes p.date { \n\tfont-size : 92%;\n\tcolor : #666; \n\ttext-transform : uppercase; \n}\n\nTake a gander at the first example.\n\nYou could stop right there, but without seeing who has left the note, there is little context. So next, extract the name of the commenter from the <blockquote>\u2019s cite attribute and display it before each note by using generated content.\n\nol#notes blockquote:before { \n\tcontent : \" \"attr(cite)\" said: \"; \n\tmargin-left : 20px; \n\tfont-weight : bold; \n}\n\nFun with more detailed styling\n\nNow, with all of the information and basic styling in place, it\u2019s time to have some fun with some more detailed styling to spruce up your notes. Let\u2019s start by adding an icon for each person, once again based on their cite. First, all of the first paragraphs of a <blockquote>\u2019s that includes a cite attribute are given common styles.\n\nol#notes blockquote[cite] p:first-child {\n\tmin-height : 34px;\n\tpadding-left : 40px; \n}\n\nFollowed by an individual background-image.\n\nol#notes blockquote[cite=\"Andy\"] p:first-child { \n\tbackground : url(malarkey.png) no-repeat 5px 5px; \n} \n\nIf you prefer a little more interactivity, add a :hover state to each <blockquote> and perhaps highlight the most recent comment.\n\nol#notes blockquote:hover { \n\tbackground-color : #faf8eb; \n\tborder-top : 1px solid #fff; \n\tborder-bottom : 1px solid #333; \n}\nol#notes li:last-child blockquote { \n\tbackground-color : #f1efe2; \n}\n\n\n\nYou could also adjust the style for each comment based on the department that the person works in, for example:\n\n<li>\n\t<blockquote cite=\"andy\" class=\"designer\"> \n\t\t<p>This project will use XHTML1.0 Strict, CSS2.1 and all that malarkey.</p>\n\t</blockquote> \n</li>\n<li>\n\t<blockquote cite=\"dan\"> \n\t\t<p>Those bits are simple and bulletproof.</p>\n\t</blockquote> \n</li>\nol#notes blockquote.designer { border-color : #600; }\n\nTake a look at the results of the second stage.\n\nShow and hide the notes using CSS positioning\n\nWith your notes now dressed in their finest, it is time to tuck them away above the top of your working XHTML/CSS prototype so that you can reveal them when you need them, no JavaScript required. Start by moving the ordered list of notes off the top of the viewport leaving only a few pixels in view. It is also a good idea to make them semi-transparent by using the opacity property for browsers that have implemented it.\n\nol#notes { \n\tposition : absolute; \n\topacity : .25;\n\tz-index : 2000;  \n\ttop : -305px; \n\tleft : 20px; \n}\n\nYour last step is to add :hover and :focus dynamic pseudo-classes to reposition the list at the top of the viewport and restore full opacity to display them in their full glory when needed.\n\nol#notes:hover, ol#notes:focus {\n\ttop : 0; \n\topacity : 1; \n}\n\n\n\nNow it\u2019s time to sit back, pour yourself a long drink and bask in the glory of the final result. Your notes are all stored in one handy place at the bottom of your document rather than being spread around your code. When your templates are complete, simply dive straight to the bottom and pull out the notes.\n\nA Message To You, Rudy\n\nThank-you to everybody for making this a really great year for web standards. Have a wonderful holiday season.\n\nBuy Andy Clarke\u2019s book Transcending CSS from Amazon.com", "year": "2006", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2006-12-15T00:00:00+00:00", "url": "https://24ways.org/2006/css-production-notes/", "topic": "process"}
{"rowid": 149, "title": "Underpants Over My Trousers", "contents": "With Christmas approaching faster than a speeding bullet, this is the perfect time for you to think about that last minute present to buy for the web geek in your life. If you\u2019re stuck for ideas for that special someone, forget about that svelte iPhone case carved from solid mahogany and head instead to your nearest comic-book shop and pick up a selection of comics or graphic novels. (I\u2019ll be using some of my personal favourite comic books as examples throughout). \n\nTrust me, whether your nearest and dearest has been reading comics for a while or has never peered inside this four-colour world, they\u2019ll thank-you for it.\n\nAside from indulging their superhero fantasies, comic books can provide web designers with a rich vein of inspiring ideas and material to help them create shirt button popping, trouser bursting work for the web. I know from my own personal experience, that looking at aspects of comic book design, layout and conventions and thinking about the ways that they can inform web design has taken my design work in often-unexpected directions. \n\nThere are far too many fascinating facets of comic book design that provide web designers with inspiration to cover in the time that it takes to pull your underpants over your trousers. So I\u2019m going to concentrate on one muscle bound aspect of comic design, one that will make you think differently about how you lay out the content of your pages in panels. \n\nA suitcase full of Kryptonite\n\nNow, to the uninitiated onlooker, the panels of a comic book may appear to perform a similar function to still frames from a movie. But inside the pages of a comic, panels must work harder to help the reader understand the timing of a story. It is this method for conveying narrative timing to a reader that I believe can be highly useful to designers who work on the web as timing, drama and suspense are as important in the web world as they are in worlds occupied by costumed crime fighters and superheroes.\n\nI\u2019d like you to start by closing your eyes and thinking about your own process for laying out panels of content on a page. OK, you\u2019ll actually be better off with your eyes open if you\u2019re going to carry on reading.\n\nI\u2019ll bet you a suitcase full of Kryptonite that you often, if not always, structure your page layouts, and decide on the dimensions of those panels according to either:\n\n\n\tThe base grid that you are working to\n\tThe Golden Ratio or another mathematical schema\n\n\nMore likely, I bet that you decide on the size and the number of your panels based on the amount of content that will be going into them. From today, I\u2019d like you to think about taking a different approach. This approach not only addresses horizontal and vertical space, but also adds the dimension of time to your designs.\n\nSlowing down the action\n\nA comic book panel not only acts as a container for its content but also indicates to a reader how much time passes within the panel and as a result, how much time the reader should focus their attention on that one panel. \n\nSmaller panels create swift eye movement and shorter bursts of attention. Larger panels give the perception of more time elapsing in the story and subconsciously demands that a reader devotes more time to focus on it. \n\nConcrete by Paul Chadwick (Dark Horse Comics)\n\nThis use of panel dimensions to control timing can also be useful for web designers in designing the reading/user experience. Imagine a page full of information about a product or service. You\u2019ll naturally want the reader to focus for longer on the key benefits of your offering rather than perhaps its technical specifications.\n\nNow take a look at this spread of pages from Watchmen by Alan Moore and Dave Gibbons.\n\nWatchmen by Alan Moore and Dave Gibbons (Diamond Comic Distributors 2004)\n\nThroughout this series of (originally) twelve editions, artist Dave Gibbons stuck rigidly to his 3\u00d73 panels per page design and deviated from it only for dramatic moments within the narrative. \n\nIn particular during the last few pages of chapter eleven, Gibbons adds weight to the impending doom by slowing down the action by using larger panels and forces the reader to think longer about what was coming next. The action then speeds up through twelve smaller panels until the final panel: nothing more than white space and yet one of the most iconic and thought provoking in the entire twelve book series.\n\nWatchmen by Alan Moore and Dave Gibbons (Diamond Comic Distributors 2004)\n\nOn the web it is common for clients to ask designers to fill every pixel of screen space with content, perhaps not understanding the drama that can be added by nothing more than white space.\n\nIn the final chapter, Gibbons emphasises the carnage that has taken place (unseen between chapters eleven and twelve) by presenting the reader with six full pages containing only single, large panels. \n\nWatchmen by Alan Moore and Dave Gibbons (Diamond Comic Distributors 2004)\n\nThis drama, created by the artist\u2019s use of panel dimensions to control timing, is a technique that web designers can also usefully employ when emphasising important areas of content.\n\nThink back for a moment to the home page of Apple Inc., during the launch of their iconic iPhone, where the page contained nothing more than a large image and the phrase \u201cSay hello to iPhone\u201d. Rather than fill the page with sales messages, Apple\u2019s designers allowed the space itself to tell the story and created a real sense of suspense and expectation among their readers.\n\nBorders\n\nWhereas on the web, panel borders are commonly used to add emphasis to particular areas of content, in comic books they take on a different and sometimes opposite role. \n\nIn the examples so far, borders have contained all of the action. Removing a border can have the opposite effect to what you might at first think. Rather than taking emphasis away from their content, in comics, borderless panels allow the reader\u2019s eyes to linger for longer on the content adding even stronger emphasis.\n\nConcrete by Paul Chadwick (Dark Horse Comics)\n\nThis effect is amplified when the borderless content is allowed to bleed to the edges of a page. Because the content is no longer confined, except by the edges of the page (both comic and web) the reader\u2019s eye is left to wander out into open space. \n\nConcrete by Paul Chadwick (Dark Horse Comics)\n\nThis type of open, borderless content panel can be highly useful in placing emphasis on the most important content on a page in exactly the very opposite way that we commonly employ on the web today. \n\nSo why is time an important dimension to think about when designing your web pages? On one level, we are often already concerned with the short attention spans of visitors to our pages and should work hard to allow them to quickly and easily find and read the content that both they and we think is important. Learning lessons from comic book timing can only help us improve that experience.\n\nOn another: timing, suspense and drama are already everyday parts of the web browsing experience. Will a reader see what they expect when they click from one page to the next? Or are they in for a surprise? \n\nMost importantly, I believe that the web, like comics, is about story telling: often the story of the experiences that a customer will have when they use our product or service or interact with our organisation. It is this element of story telling than can be greatly improved by learning from comics.\n\nIt is exactly this kind of learning and adapting from older, more established and at first glance unrelated media that you will find can make a real distinctive difference to the design work that you create.\n\nFill your stockings\n\nIf you\u2019re a visual designer or developer and are not a regular reader of comics, from the moment that you pick up your first title, I know that you will find them inspiring. \n\nI will be writing more, and speaking about comic design applied to the web at several (to be announced) events this coming year. I hope you\u2019ll be slipping your underpants over your trousers and joining me then. In the meantime, here is some further reading to pick up on your next visit to a comic book or regular bookshop and slip into your stockings:\n\n\n\tComics and Sequential Art by Will Eisner (Northern Light Books 2001)\n\tUnderstanding Comics: The Invisible Art by Scott McCloud (Harper Collins 1994)\n\n\nHave a happy superhero season.\n\n(I would like to thank all of the talented artists, writers and publishers whose work I have used as examples in this article and the hundreds more who inspire me every day with their tall tales and talent.)", "year": "2007", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2007-12-14T00:00:00+00:00", "url": "https://24ways.org/2007/underpants-over-my-trousers/", "topic": "design"}
{"rowid": 189, "title": "Ignorance Is Bliss", "contents": "This is a true story.\n\nMeet Mike \n\nMike\u2019s a smart guy. He knows a great browser when he sees one. He uses Firefox on his Windows PC at work and Safari on his Mac at home. Mike asked us to design a Web site for his business. So we did.\n\nWe wanted to make the best Web site for Mike that we could, so we used all of the CSS tools that are available today. That meant using RGBa colour to layer elements, border-radius to add subtle rounded corners and (possibly most experimental of all new CSS), generated gradients.\n\n The home page Mike sees in Safari on his Mac\n\nMike loves what he sees.\n\nMeet Sam\n\nSam works with Mike. She uses Internet Explorer 7 because it came on the Windows laptop that the company bought her when she joined. \n\n The home page Sam sees in Internet Explorer 7 on her PC\n\nSam loves the new Web site too.\n\nHow could both of them be happy when they experienced the Web site differently?\n\nThe new WYSIWYG\n\nWhen I first presented my designs to Mike and Sam, I showed them a Web page made with HTML and CSS in their respective browsers and not a picture of a Web page. By showing neither a static image of my design, I set none of the false expectations that, by definition, a static Photoshop or Fireworks visual would have established.\n\nMike saw rounded corners and subtle shadows in Firefox and Safari. Sam saw something equally as nice, just a little different, in Internet Explorer. Both were very happy because they saw something that they liked.\n\nNeither knew, or needed to know, about the subtle differences between browsers. Their users don\u2019t need to know either.\n\nThat\u2019s because in the real world, people using the Web don\u2019t find a Web site that they like, then open up another browser to check that it looks they same. They simply buy what they came to buy, read what what they came to read, do what they came to do, then get on with their lives in blissful ignorance of what they might be seeing in another browser.\n\nOften when I talk or write about using progressive CSS, people ask me, \u201cHow do you convince clients to let you work that way? What\u2019s your secret?\u201d Secret? I tell them what they need to know, on a need-to-know basis.\n\nEpilogue\n\nSam has a new iPhone that Mike bought for her as a reward for achieving her sales targets. She loves her iPhone and was surprised at just how fast and good-looking the company Web site appears on that. So she asked,\n\n\n\t\u201cAndy, I didn\u2019t know you optimised our site for mobile. I don\u2019t remember seeing an invoice for that.\u201d\n\n\nI smiled.\n\n\n\t\u201cThat one was on the house.\u201d", "year": "2009", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2009-12-23T00:00:00+00:00", "url": "https://24ways.org/2009/ignorance-is-bliss/", "topic": "business"}
{"rowid": 206, "title": "Getting Hardboiled with CSS Custom Properties", "contents": "Custom Properties are a fabulous new feature of CSS and have widespread support in contemporary browsers. But how do we handle browsers without support for CSS Custom Properties? Do we wait until those browsers are lying dead in a ditch before we use them? Do we tool up and prop up our CSS using a post-processor? Or do we get tough? Do we get hardboiled?\nPreviously only pre-processing tools like LESS and Sass enabled developers to use variables in their stylesheets, but now Custom Properties have brought variables natively to CSS.\nHow do you write a custom property? It\u2019s hardly a mystery. Simply add two dashes to the start of a style rule. Like this:\n--color-text-default : black;\nIf you\u2019re more the underscore type, try this:\n--color_text_default : black;\nHyphens or underscores are allowed in property names, but don\u2019t be a chump and try to use spaces. \nCustom property names are also case-sensitive, so --color-text-default and --Color_Text_Default are two distinct properties.\nTo use a custom property in your style rules, var() tells a browser to retrieve the value of a property. In the next example, the browser retrieves the black colour from the color-text-default variable and applies it to the body element:\nbody {\n    color : var(--color-text-default); \n}\nLike variables in LESS or Sass, CSS Custom Properties mean you don\u2019t have to be a dumb mug and repeat colour, font, or size values multiple times in your stylesheets. Unlike a preprocessor variable though, CSS Custom Properties use the cascade, can be modified by media queries and other state changes, and can also be manipulated by Javascript.\n(Serg Hospodarets wrote a fabulous primer on CSS Custom Properties where he dives deeper into the code and possible applications.)\nBrowser support\nNow it\u2019s about this time that people normally mention browser support. So what about support for CSS Custom Properties? Current versions of Chrome, Edge, Firefox, Opera, and Safari are all good. Internet Explorer 11 and before? Opera Mini? Nasty.\nSound familiar?\n\n  Can I Use css-variables? Data on support for the css-variables feature across the major browsers from caniuse.com.\n\nNot to worry, we can manually check for Custom Property support in a browser by using an @support directive, like this:\n--color-text-default : black;\n\nbody {\n    color : black;  \n}\n\n@supports ((--foo : bar)) {\n    body {\n        color : var(--color-text-default); \n    }\n}\nIn that example we first set body element text to black and then override that colour with a Custom Property value when the browser supports our fictitious foo bar variable.\nSubstitutions\nIf we reference a variable that hasn\u2019t been defined, that won\u2019t be a problem as browsers are smart enough to ignore the value altogether. If we need a cast iron alibi, use substitutions to specify a fall-back value.\nbody {\n    color : var(--color-text-default, black); \n}\nSubstitutions are similar to font stacks in that they contain a comma separated list of values. If there\u2019s no value associated with a property, a browser will ignore it and move onto the next value in the list.\nPost-processing\nOf course we could use a post-processor plugin to turn Custom Properties into plain CSS, but hang on one goddam minute kiddo.\nHaven\u2019t we been down this road before? Didn\u2019t we engineer elaborate workarounds to enable us to use \u2018advanced\u2019 CSS3 properties like border-radius, CSS columns, and Flexbox in the past? We did what we had to do to get the job done, but came away feeling dirty.\nI think there\u2019s a better way, one that allows us to enjoy the benefits of CSS Custom Properties in browsers that support them, while providing an appropriate, but not identical experience, for people who use less capable browsers. Guess what, I\u2019ve been down this road before too. \n2Tone Stuff & Nonsense\nWhen Internet Explorer 6 was the big dumb browser everyone hated, I served two different designs on my website. \nFor the modern browsers of the time, mod arrows and targets were everywhere in glorious red, white, and blue, and I implemented all of them using CSS attribute selectors which were considered advanced at the time:\n[class=\"banner\"] {\n    background-colour : red; \n}\nInternet Explorer 6 ignored any selectors it didn\u2019t understand, so people using that browser saw a simpler black and white, 2Tone-based design that I\u2019d implemented for them using class selectors:\n.banner {\n    background-colour : black; \n}\n\n[class=\"banner\"] {\n    background-colour : red; \n}\n\nYou don\u2019t have to be a detective to find out that most people thought I\u2019d lost my wits, but Microsoft even used my website as a reference when they tested attribute selectors in Internet Explorer 7. They did, as I suggested, \u201cStomp to da betta browser.\u201d\nDumb browsers look the other way\nSo how does this approach relate to tackling any lack of support for CSS Custom Properties? How can we take advantage of them without worrying about browsers with no support and having to implement complex workarounds, or spending hours specifying fallbacks that perfectly match our designs?\nTurns out, the answer is built into CSS, and always has been, because when browsers don\u2019t know what they\u2019re looking at, they look away. \nAll we have to do is first specify values for a simpler design first, and then follow that up with the values in our CSS Custom Properties:\nbody {\n    color : black;\n    color : var(--color-text-default, black); \n}\nAll browsers understand the first value (black,) and if they\u2018re smart enough to understand the second (var(--color-text-default)), they\u2019ll use it and override the first. If they\u2019re too damn stupid to understand the custom property value, they\u2019ll ignore it. Nobody dies.\nRepeat this for every style that contains a variable, baking an alternative, perhaps simpler design into your stylesheets for people who use less capable browsers, just like I did with Stuff & Nonsense.\nConclusion\nI doubt that anyone agrees with presenting a design that looks broken or unloved\u2014and I\u2019m not advocating for that\u2014but websites need not look the same in every browser. We can use substitutions to present a simpler design to people using less capable browsers.\nThe decision when to start using new CSS properties isn\u2018t always a technical one. Sometimes a change in attitude about browser support is all that\u2019s required. So get tough with dumb browsers and benefit from all the advantages that CSS Custom Properties offer. Get hardboiled.\nResources:\n\nIt\u2019s Time To Start Using CSS Custom Properties\u2014Smashing Magazine\nUsing CSS variables correctly\u2014Mike Riethmuller\nDeveloping Inspired Guides with CSS Custom Properties (variables)\u2014Andy Clarke", "year": "2017", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2017-12-13T00:00:00+00:00", "url": "https://24ways.org/2017/getting-hardboiled-with-css-custom-properties/", "topic": "code"}
{"rowid": 237, "title": "Circles of Confusion", "contents": "Long before I worked on the web, I specialised in training photographers how to use large format,  5\u00d74\u2033 and 10\u00d78\u2033 view cameras \u2013 film cameras with swing and tilt movements, bellows and upside down, back to front images viewed on dim, ground glass screens. It\u2019s been fifteen years since I clicked a shutter on a view camera, but some things have stayed with me from those years.\n\nIn photography, even the best lenses don\u2019t focus light onto a point (infinitely small in size) but onto \u2018spots\u2019 or circles in the \u2018film/image plane\u2019. These circles of light have dimensions, despite being microscopically small. They\u2019re known as \u2018circles of confusion\u2019.\n\nAs circles of light become larger, the more unsharp parts of a photograph appear. On the flip side, when circles are smaller, an image looks sharper and more in focus. This is the basis for photographic depth of field and with that comes the knowledge that no photograph can be perfectly focused, never truly sharp. Instead, photographs can only be \u2018acceptably unsharp\u2019. \n\nAcceptable unsharpness is now a concept that\u2019s relevant to the work we make for the web, because often \u2013 unless we compromise \u2013 websites cannot look or be experienced exactly the same across browsers, devices or platforms. Accepting that fact, and learning to look upon these natural differences as creative opportunities instead of imperfections, can be tough. Deciding which aspects of a design must remain consistent and, therefore, possibly require more time, effort or compromises can be tougher. Circles of confusion can help us, our bosses and our customers make better, more informed decisions.\n\nAcceptable unsharpness\n\nMany clients still demand that every aspect of a design should be \u2018sharp\u2019 \u2013 that every user must see rounded boxes, gradients and shadows \u2013 without regard for the implications. I believe that this stems largely from the fact that they have previously been shown designs \u2013 and asked for sign-off \u2013 using static images.\n\nIt\u2019s also true that in the past, organisations have invested heavily in style guides which, while maybe still useful in offline media, have a strictness that often fails to allow for the flexibility that we need to create experiences that are appropriate to a user\u2019s browser or device capabilities.\n\nWe live in an era where web browsers and devices have wide-ranging capabilities, and websites can rarely look or be experienced exactly the same across them. Is a particular typeface vital to a user\u2019s experience of a brand? How important are gradients or shadows? Are rounded corners really that necessary? These decisions determine how \u2018sharp\u2019 an element should be across browsers with different capabilities and, therefore, how much time, effort or extra code and images we devote to achieving consistency between them. To help our clients make those decisions, we can use circles of confusion.\n\nCircles of confusion\n\nUsing circles of confusion involves plotting aspects of a visual design into a series of concentric circles, starting at the centre with elements that demand the most consistency. Then, work outwards, placing elements in order of their priority so that they become progressively \u2018softer\u2019, more defocused as they\u2019re plotted into outer rings.\n\nIf layout and typography must remain consistent, place them in the centre circle as they\u2019re aspects of a design that must remain \u2018sharp\u2019.\n\nWhen gradients are important \u2013 but not vital \u2013 to a user\u2019s experience of a brand, plot them close to, but not in the centre. This makes everyone aware that to achieve consistency, you\u2019ll need to carve out extra images for browsers that don\u2019t support CSS gradients.\n\nIf achieving rounded corners or shadows in all browsers isn\u2019t important, place them into outer circles, allowing you to save time by not creating images or employing JavaScript workarounds.\n\nI\u2019ve found plotting aspects of a visual design into circles of confusion is a useful technique when explaining the natural differences between browsers to clients. It sets more realistic expectations and creates an environment for more meaningful discussions about progressive and emerging technologies. Best of all, it enables everyone to make better and more informed decisions about design implementation priorities.\n\nInvolving clients allows the implications of the decisions they make more transparent. For me, this has sometimes meant shifting deadlines or it has allowed me to more easily justify an increase in fees. Most important of all, circles of confusion have helped the people that I work with move beyond yesterday\u2019s one-size-fits-all thinking about visual design, towards accepting the rich diversity of today\u2019s web.", "year": "2010", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2010-12-23T00:00:00+00:00", "url": "https://24ways.org/2010/circles-of-confusion/", "topic": "process"}
{"rowid": 246, "title": "Designing Your Site Like It\u2019s 1998", "contents": "It\u2019s 20 years to the day since my wife and I started Stuff & Nonsense, our little studio and my outlet for creative ideas on the web. To celebrate this anniversary\u2014and my fourteenth contribution to 24 ways\u2014 I\u2019d like to explain how I would\u2019ve developed a design for Planes, Trains and Automobiles, one of my favourite Christmas films.\nMy design for Planes, Trains and Automobiles is fixed at 800px wide.\nDeveloping a <frameset> framework\nI\u2019ll start by using frames to set up the framework for this new website. Frames are individual pages\u2014one for navigation, the other for my content\u2014pulled together to form a frameset. Space is limited on lower-resolution screens, so by using frames I can ensure my navigation always remains visible. I can include any number of frames inside a <frameset> element.\nI add two rows to my <frameset>; the first is for my navigation and is 50px tall, the second is for my content and will resize to fill any available space. As I don\u2019t want frame borders or any space between my frames, I set frameborder and framespacing attributes to 0:\n<frameset frameborder=\"0\" framespacing=\"0\" rows=\"50,*\">\n[\u2026]\n</frameset>\nNext I add the source of my two frame documents. I don\u2019t want people to be able to resize or scroll my navigation, so I add the noresize attribute to that frame:\n<frameset frameborder=\"0\" framespacing=\"0\" rows=\"50,*\">\n<frame noresize scrolling=\"no\" src=\"nav.html\">\n<frame src=\"content.html\">\n</frameset>\nI do want links from my navigation to open in the content frame, so I give each <frame> a name so I can specify where I want links to open:\n<frameset frameborder=\"0\" framespacing=\"0\" rows=\"50,*\">\n<frame name=\"navigation\" noresize scrolling=\"no\" src=\"nav.html\">\n<frame name=\"content\" src=\"content.html\">\n</frameset>\nThe framework for this website is simple as it contains only two horizontal rows. Should I need a more complex layout, I can nest as many framesets\u2014and as many individual documents\u2014as I need:\n<frameset rows=\"50,*\">\n <frame name=\"navigation\">\n <frameset cols=\"25%,*\">\n  <frame name=\"sidebar\">\n  <frame name=\"content\">\n </frameset>\n</frameset>\nLetterbox framesets were common way to deal with multiple screen sizes. In a letterbox, the central frameset had a fixed height and width, while the frames on the top, right, bottom, and left expanded to fill any remaining space.\nHandling older browsers\nSadly not every browser supports frames, so I should send a helpful message to people who use older browsers asking them to upgrade. Happily, I can do that using noframes content:\n<noframes>\n<body>\n<p>This page uses frames, but your browser doesn\u2019t support them. \n    Please upgrade your browser.</p>\n</body>\n</noframes>\nForcing someone back into a frame\nSometimes, someone may follow a link to a page from a portal or search engine, or they might attempt to open it in a new window or tab. If that page properly belongs inside a <frameset>, people could easily miss out on other parts of a design. This short script will prevent this happening and because it\u2019s vanilla Javascript, it doesn\u2019t require a library such as jQuery:\n<script type=\"text/javascript\">\nif (top == self) {\n  location = 'frameset.html';\n}\n</script>\n\nLaying out my page\nBefore starting my layout, I add a few basic background and colour styles. I must include these attributes in every page on my website:\n<body background=\"img/container.jpg\" bgcolor=\"#fef7fb\" \n    link=\"#245eab\" alink=\"#245eab\" vlink=\"#3c146e\" text=\"#000000\">\nI want absolute control over how people experience my design and don\u2019t want to allow it to stretch, so I first need a <table> which limits the width of my layout to 800px. The align attribute will keep this <table> in the centre of someone\u2019s screen:\n<table width=\"800\" align=\"center\">\n <tr>\n  <td>[\u2026]</td>\n </tr>\n</table>\nAlthough they were developed for displaying tabular information, the cells and rows which make up the <table> element make it ideal for the precise implementation of a design. I need several tables\u2014often nested inside each other\u2014to implement my design. These include tables for a banner and three rows of content:\n<table width=\"800\" align=\"center\">\n <table>[\u2026]</table>\n <table>\n  <table>\n   <table>[\u2026]</table>\n  </table>\n </table>\n <table>[\u2026]</table>\n <table>[\u2026]</table>\n</table>\nThe width of the first table\u2014used for my banner\u2014is fixed to match the logo it contains. As I don\u2019t need borders, padding, or spacing between these cells, I use attributes to remove them:\n<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" width=\"587\" align=\"center\">\n <tr>\n  <td><img src=\"logo.gif\" border=\"0\" width=\"587\" alt=\"Logo\"></td>\n </tr>\n</table>\nThe next table\u2014which contains the largest image, introduction, and a call-to-action\u2014is one of the most complex parts of my design, so I need to ensure its layout is pixel perfect. To do that I add an extra row at the top of this table and fill each of its cells with tiny transparent images:\n<tr>\n <td><img src=\"spacer.gif\" width=\"593\" height=\"1\"></td>\n <td><img src=\"spacer.gif\" width=\"207\" height=\"1\"></td>\n</tr>\nThe height and width of these \u201cshims\u201d or \u201cspacers\u201d is only 1px but they will stretch to any size without increasing their weight on the page. This makes them perfect for performant website development.\nFor the hero of this design, I splice up the large image into three separate files and apply each slice as a background to the table cells. I also match the height of those cells to the background images:\n<tr>\n <td background=\"slice-1.jpg\" height=\"473\">\u00a0</td>\n <td background=\"slice-2.jpg\" height=\"473\">[\u2026]</td>\n</tr>\n\n<tr>\n <td background=\"slice-3.jpg\" height=\"388\">\u00a0</td>\n</tr>\nI use tables and spacer images throughout the rest of this design to lay out the various types of content with perfect precision. For example, to add a single-pixel border around my two columns of content, I first apply a blue background to an outer table along with 1px of cellspacing, then simply nest an inner table\u2014this time with a white background\u2014inside it:\n<table border=\"0\" cellpadding=\"1\" cellspacing=\"0\">\n <tr>\n  <td>\n   <table bgcolor=\"#ffffff\" border=\"0\" cellpadding=\"0\" cellspacing=\"0\">\n[\u2026]\n   </table>\n  </td>\n </tr>\n</table>\nAdding details\nTables are fabulous tools for laying out a page, but they\u2019re also useful for implementing details on those pages. I can use a table to add a gradient background, rounded corners, and a shadow to the button which forms my \u201cBuy the DVD\u201d call-to-action. First, I splice my button graphic into three slices; two fixed-width rounded ends, plus a narrow gradient which stretches and makes this button responsive. Then, I add those images as backgrounds and use spacers to perfectly size my button:\n<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">\n <tr>\n  <td background=\"btn-1.jpg\" border=\"0\" height=\"48\" width=\"30\"><img src=\"spacer.gif\" width=\"30\" height=\"1\"></td>\n\n  <td background=\"btn-2.jpg\" border=\"0\" height=\"48\">\n   <center>\n    <a href=\"\" target=\"_blank\"><b>Buy the DVD</b></a>\n   </center>\n  </td>\n\n  <td background=\"btn-3.jpg\" border=\"0\" height=\"48\" width=\"30\"><img src=\"spacer.gif\" width=\"30\" height=\"1\"></td>\n </tr>\n</table>\nI use those same elements to add details to headlines and lists too. Adding a \u201cbullet\u201d to each item in a list needs only two additional table cells, a circular graphic, and a spacer:\n<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">\n <tr>\n  <td width=\"10\"><img src=\"li.gif\" border=\"0\" width=\"8\" height=\"8\">\u00a0</td>\n  <td><img src=\"spacer.gif\" width=\"10\" height=\"1\">\u00a0</td>\n  <td>Directed by John Hughes</td>\n </tr>\n</table>\nImplementing a typographic hierarchy\nSo far I\u2019ve explained how to use frames, tables, and spacers to develop a layout for my content, but what about styling that content? I use <font> elements to change the typeface from the browser\u2019s default to any font installed on someone\u2019s device:\n<font face=\"Arial\">Planes, Trains and Automobiles is a comedy film [\u2026]</font>\nTo adjust the size of those fonts, I use the size attribute and a value between the smallest (1) and the largest (7) where 3 is the browser\u2019s default. I use a size of 4 for this headline and 2 for the text which follows:\n<font face=\"Arial\" size=\"4\"><b>Steve Martin</b></font>\n\n<font face=\"Arial\" size=\"2\">An American actor, comedian, writer, producer, and musician.</font>\nWhen I need to change the typeface, perhaps from a sans-serif like Arial to a serif like Times New Roman, I must change the value of the face attribute on every element on all pages on my website.\nNB: I use as many <br> elements as needed to create space between headlines and paragraphs.\nView the final result (and especially the source.)\nMy modern day design for Planes, Trains and Automobiles.\nI can imagine many people reading this and thinking \u201cThis is terrible advice because we don\u2019t develop websites like this in 2018.\u201d That\u2019s true.\nWe have the ability to embed any number of web fonts into our products and websites and have far more control over type features, leading, ligatures, and sizes:\nfont-variant-caps: titling-caps;\nfont-variant-ligatures: common-ligatures;\nfont-variant-numeric: oldstyle-nums;\nGrid has simplified the implementation of even the most complex compound grid down to just a few lines of CSS:\nbody {\n  display: grid;\n  grid-template-columns: 3fr 1fr 2fr 2fr 1fr 3fr;\n  grid-template-rows: auto;\n  grid-column-gap: 2vw;\n  grid-row-gap: 1vh;\n}\nFlexbox has made it easy to develop flexible components such as navigation links:\nnav ul { display: flex; }\nnav li { flex: 1; }\nJust one line of CSS can create multiple columns of fluid type:\nmain { column-width: 12em; }\nCSS Shapes enable text to flow around irregular shapes including polygons:\n[src*=\"main-img\"] {\n  float: left;\n  shape-outside: polygon(\u2026);\n}\nToday, we wouldn\u2019t dream of using images and a table to add a gradient, rounded corners, and a shadow to a button or link, preferring instead:\n.btn {\n  background: linear-gradient(#8B1212, #DD3A3C);\n  border-radius: 1em;\n  box-shadow: 0 2px 4px 0 rgba(0,0,0,0.50), inset 0 -1px 1px 0 rgba(0,0,0,0.50);\n}\nCSS Custom Properties, feature and media queries, filters, pseudo-elements, and SVG; the list of advances in HTML, CSS, and other technologies goes on. So does our understanding of how best to use them by separating content, structure, presentation, and behaviour. As 2018 draws to a close, we\u2019re certain we know how to design and develop products and websites better than we did at the end of 1998.\nStrange as it might seem looking back, in 1998 we were also certain our techniques and technologies were the best for the job. That\u2019s why it\u2019s dangerous to believe with absolute certainty that the frameworks and tools we increasingly rely on today\u2014tools like Bootstrap, Bower, and Brunch, Grunt, Gulp, Node, Require, React, and Sass\u2014will be any more relevant in the future than <font> elements, frames, layout tables, and spacer images are today.\nI have no prediction for what the web will be like twenty years from now. However, I want to believe we\u2019ll build on what we\u2019ve learned during these past two decades about the importance of accessibility, flexibility, and usability, and that the mistakes we made while infatuated by technologies won\u2019t be repeated.\n\nHead over to my website if you\u2019d like to read about how I\u2019d implement my design for \u2018Planes, Trains and Automobiles\u2019 today.", "year": "2018", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2018-12-23T00:00:00+00:00", "url": "https://24ways.org/2018/designing-your-site-like-its-1998/", "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": 311, "title": "Designing Imaginative Style Guides", "contents": "(Living) style guides and (atomic) patterns libraries are \u201call the rage,\u201d as my dear old Nana would\u2019ve said. If articles and conference talks are to be believed, making and using them has become incredibly popular. I think there are plenty of ways we can improve how style guides look and make them better at communicating design information to creatives without it getting in the way of information that technical people need.\nGuides to libraries of patterns\nMost of my consulting work and a good deal of my creative projects now involve designing style guides. I\u2019ve amassed a huge collection of brand guidelines and identity manuals as well as, more recently, guides to libraries of patterns intended to help designers and developers make digital products and websites.\nTwo pages from one of my Purposeful style guide packs. Designs \u00a9 Stuff & Nonsense.\n\u201cStyle guide\u201d is an umbrella term for several types of design documentation. Sometimes we\u2019re referring to static style or visual identity guides, other times voice and tone. We might mean front-end code guidelines or component/pattern libraries. These all offer something different but more often than not they have something in common. They look ugly enough to have been designed by someone who enjoys configuring a router.\nOK, that was mean, not everyone\u2019s going to think an unimaginative style guide design is a problem. After all, as long as a style guide contains information people need, how it looks shouldn\u2019t matter, should it?\nInspiring not encyclopaedic\nWell here\u2019s the thing. Not everyone needs to take the same information away from a style guide. If you\u2019re looking for markup and styles to code a \u2018media\u2019 component, you\u2019re probably going to be the technical type, whereas if you need to understand the balance of sizes across a typographic hierarchy, you\u2019re more likely to be a creative. What you need from a style guide is different.\nSure, some people1 need rules:\n\n\u201cDo this (responsive pattern)\u201d or \u201cdon\u2019t do that (auto-playing video.)\u201d \n\nThose people probably also want facts:\n\n\u201cUse this (hexadecimal value)\u201d and not that inaccessible colour combination.\u201d\n\nStyle guides need to do more than list facts and rules. They should demonstrate a design, not just document its parts. The best style guides are inspiring not encyclopaedic. I\u2019ll explain by showing how many style guides currently present information about colour. \nColours communicate\nI\u2019m sure you\u2019ll agree that alongside typography, colour\u2019s one of the most important ingredients in a design. Colour communicates personality, creates mood and is vital to an easily understandable interactive vocabulary. So you\u2019d think that an average style guide would describe all this in any number of imaginative ways. Well, you\u2019d be disappointed, because the most inspiring you\u2019ll find looks like a collection of chips from a paint chart.\n\nLonely Planet\u2019s Rizzo does a great job of separating its Design Elements from UI Components, and while its \u2018Click to copy\u2019\u00a0colour values are a thoughtful touch, you\u2019ll struggle to get a feeling for Lonely Planet\u2019s design by looking at their colour chips.\nLonely Planet\u2019s Rizzo style guide.\nLonely Planet approach is a common way to display colour information and it\u2019s one that you\u2019ll also find at Greenpeace, Sky, The Times and on countless more style guides.\n\n\n\n\n\nGreenpeace, Sky and The Times style guides.\nGOV.UK\u2014not a website known for its creative flair\u2014varies this approach by using circles, which I find  strange as circles don\u2019t feature anywhere else in its branding or design. On the plus side though, their designers have provided some context by categorising colours by usage such as text, links, backgrounds and more.\nGOV.UK style guide.\nGoogle\u2019s Material Design offers an embarrassment of colours but most helpfully it also advises how to combine its primary and accent colours into usable palettes.\nGoogle\u2019s Material Design.\nWhile the ability to copy colour values from a reference might be all a technical person needs, designers need to understand why particular colours were chosen as well as how to use them. \nInspiration not documentation\nFew style guides offer any explanation and even less by way of inspiring examples. Most are extremely vague when they describe colour:\n\n\u201cUse colour as a presentation element for either decorative purposes or to convey information.\u201d\n\nThe Government of Canada\u2019s Web Experience Toolkit states, rather obviously.\n\n\u201cCertain colors have inherent meaning for a large majority of users, although we recognize that cultural differences are plentiful.\u201d\n\nSalesforce tell us, without actually mentioning any of those plentiful differences. \nI\u2019m also unsure what makes the Draft U.S. Web Design Standards colours a \u201cdistinctly American palette\u201d but it will have to work extremely hard to achieve its goal of communicating \u201cwarmth and trustworthiness\u201d now. \nIn Canada, \u201cbold and vibrant\u201d colours reflect Alberta\u2019s \u201cdiverse landscape.\u201d \nAdding more colours to their palette has made Adobe \u201crich, dynamic, and multi-dimensional\u201d and at Skype, colours are \u201cbold, colourful (obviously) and confident\u201d although their style guide doesn\u2019t actually provide information on how to use them.\nThe University of Oxford, on the other hand, is much more helpful by explaining how and why to use their colours:\n\n\u201cThe (dark) Oxford blue is used primarily in general page furniture such as the backgrounds on the header and footer. This makes for a strong brand presence throughout the site. Because it features so strongly in these areas, it is not recommended to use it in large areas elsewhere. However it is used more sparingly in smaller elements such as in event date icons and search/filtering bars.\u201d\n\nOpenTable style guide.\nThe designers at OpenTable have cleverly considered how to explain the hierarchy of their brand colours by presenting them and their supporting colours in various size chips. It\u2019s also obvious from OpenTable\u2019s design which colours are primary, supporting, accent or neutral without them having to say so.\nArt directing style guides\nFor the style guides I design for my clients, I go beyond simply documenting their colour palette and type styles and describe visually what these mean for them and their brand. I work to find distinctive ways to present colour to better represent the brand and also to inspire designers. \nFor example, on a recent project for SunLife, I described their palette of colours and how to use them across a series of art directed pages that reflect the lively personality of the SunLife brand. Information about HEX and RGB values, Sass variables and when to use their colours for branding, interaction and messaging is all there, but in a format that can appeal to both creative and technical people.\nSunLife style guide. Designs \u00a9 Stuff & Nonsense.\nPurposeful style guides\nIf you want to improve how you present colour information in your style guides, there\u2019s plenty you can do.\nFor a start, you needn\u2019t confine colour information to the palette page in your style guide. Find imaginative ways to display colour across several pages to show it in context with other parts of your design. Here are two CSS gradient filled \u2018cover\u2019 pages from my Purposeful style sheets.\nColour impacts other elements too, including typography, so make sure you include colour information on those pages, and vice-versa.\nPurposeful. Designs \u00a9 Stuff & Nonsense.\nA visual hierarchy can be easier to understand than labelling colours as \u2018primary,\u2019 \u2018supporting,\u2019 or \u2018accent,\u2019 so find creative ways to present that hierarchy. You might use panels of different sizes or arrange boxes on a modular grid to fill a page with colour.\nDon\u2019t limit yourself to rectangular colour chips, use circles or other shapes created using only CSS. If irregular shapes are a part of your brand, fill SVG silhouettes with CSS and then wrap text around them using CSS shapes. \nPurposeful. Designs \u00a9 Stuff & Nonsense.\nSumming up\nIn many ways I\u2019m as frustrated with style guide design as I am with the general state of design on the web. Style guides and pattern libraries needn\u2019t be dull in order to be functional. In fact, they\u2019re the perfect place for you to try out new ideas and technologies. There\u2019s nowhere better to experiment with new properties like CSS Grid than on your style guide.\nThe best style guide designs showcase new approaches and possibilities, and don\u2019t simply document the old ones. Be as creative with your style guide designs as you are with any public-facing part of your website.\n\nPurposeful are HTML and CSS style guides templates designed to help you develop creative style guides and pattern libraries for your business or clients. Save time while impressing your clients by using easily customisable HTML and CSS files that have been designed and coded to the highest standards. Twenty pages covering all common style guide components including colour, typography, buttons, form elements, and tables, plus popular pattern library components. Purposeful style guides will be available to buy online in January.\n\n\n\n\nBoring people\u00a0\u21a9", "year": "2016", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2016-12-13T00:00:00+00:00", "url": "https://24ways.org/2016/designing-imaginative-style-guides/", "topic": "design"}
{"rowid": 325, "title": "\"Z's not dead baby, Z's not dead\"", "contents": "While Mr. Moll and Mr. Budd have pipped me to the post with their predictions for 2006, I\u2019m sure they won\u2019t mind if I sneak in another. The use of positioning together with z-index will be one of next year\u2019s hot techniques \n\nBoth has been a little out of favour recently. For many, positioned layouts made way for the flexibility of floats. Developers I speak to often associate z-index with Dreamweaver\u2019s layers feature. But in combination with alpha transparency support for PNG images in IE7 and full implementation of position property values, the stacking of elements with z-index is going to be big. I\u2019m going to cover the basics of z-index and how it can be used to create designs which \u2018break out of the box\u2019.\n\nNo positioning? No Z!\n\nRemember geometry? The x axis represents the horizontal, the y axis represents the vertical. The z axis, which is where we get the z-index, represents /depth/. Elements which are stacked using z-index are stacked from front to back and z-index is only applied to elements which have their position property set to relative or absolute. No positioning, no z-index. Z-index values can be either negative or positive and it is the element with the highest z-index value appears closest to the viewer, regardless of its order in the source. Furthermore, if more than one element are given the same z-index, the element which comes last in source order comes out top of the pile. \n\nLet\u2019s take three <div>s.\n\n<div id=\"one\"></div>\n <div id=\"two\"></div>\n <div id=\"three\"></div>\n\n #one { \n     position: relative; \n     z-index: 3;\n }\n\n #two { \n     position: relative; \n     z-index: 1;\n }\n\n #three {\n     position: relative; \n     z-index: 2;\n }\n\n\n\nAs you can see, the <div> with the z-index of 3 will appear closest, even though it comes before its siblings in the source order. As these three <div>s have no defined positioning context in the form of a positioned parent such as a <div>, their stacking order is defined from the root element <html>. Simple stuff, but these building blocks are the basis on which we can create interesting interfaces (particularly when used in combination with image replacement and transparent PNGs).\n\nBrand building\n\nNow let\u2019s take three more basic elements, an <h1>, <blockquote> and <p>, all inside a branding <div> which acts a new positioning context. By enclosing them inside a positioned parent, we establish a new stacking order which is independent of either the root element or other positioning contexts on the page.\n\n<div id=\"branding\">\n     <h1>Worrysome.com</h1>\n     <blockquote><p>Don' worry 'bout a thing...</p></blockquote>\n     <p>Take the weight of the world off your shoulders.</p>\n </div>\n\nApplying a little positioning and z-index magic we can both set the position of these elements inside their positioning context and their stacking order. As we are going to use background images made from transparent PNGs, each element will allow another further down the stacking order to show through. This makes for some novel effects, particularly in liquid layouts.\n\n(Ed: We\u2019re using n below to represent whatever values you require for your specific design.) \n\n#branding {\n    position: relative;\n    width: n;\n    height: n;\n    background-image: url(n);\n }\n\n #branding>h1 {\n    position: absolute;\n    left: n;\n    top: n;\n    width: n;\n    height: n;\n    background-image: url(h1.png);\n    text-indent: n;\n }\n\n #branding>blockquote {\n    position: absolute;\n    left: n;\n    top: n;\n    width: n;\n    height: n;\n    background-image: url(bq.png);\n    text-indent: n;\n\n }\n\n #branding>p {\n    position: absolute;\n    right: n;\n    top: n;\n    width: n;\n    height: n;\n    background-image: url(p.png);\n    text-indent: n;\n }\n\nNext we can begin to see how the three elements build upon each other.\n\n\n1. Elements outlined\n\n\n2. Positioned elements overlayed to show context\n\n\n3. Our final result\n\nMultiple stacking orders\n\nNot only can elements within a positioning context be given a z-index, but those positioning contexts themselves can also be stacked.\n\n\nTwo positioning contexts, each with their own stacking order\n\nInterestingly each stacking order is independent of that of either the root element or its siblings and we can exploit this to make complex layouts from just a few semantic elements. This technique was used heavily on my recent redesign of Karova.com.\n\nDissecting part of Karova.com\n\nFirst the XHTML. The default template markup used for the site places <div id=\"nav_main\"> and <div id=\"content\"> as siblings inside their container.\n\n<div id=\"container\">\n     <div id=\"content\">\n          <h2></h2>\n          <p></p>\n     </div>\n     <div id=\"nav_main\"></div>\n </div>\n\nBy giving the navigation <div> a lower z-index than the content <div> we can ensure that the positioned content elements will always appear closest to the viewer, despite the fact that the navigation comes after the content in the source.\n\n#content { \n     position: relative; \n     z-index: 2; \n }\n\n #nav_main { \n     position: absolute; \n     z-index: 1; \n }\n\nNow applying absolute positioning with a negative top value to the <h2> and a higher z-index value than the following <p> ensures that the header sits not only on top of the navigation but also the styled paragraph which follows it.\n\nh2 {\n     position: absolute;\n     z-index: 200;\n     top: -n;\n }\n\n h2+p {\n     position: absolute;\n     z-index: 100;\n     margin-top: -n;\n     padding-top: n;\n }\n\n\nDissecting part of Karova.com\n\nYou can see the full effect in the wild on the Karova.com site.\n\nHave a great holiday season!", "year": "2005", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2005-12-16T00:00:00+00:00", "url": "https://24ways.org/2005/zs-not-dead-baby-zs-not-dead/", "topic": "design"}
{"rowid": 7, "title": "Get Started With GitHub Pages (Plus Bonus Jekyll)", "contents": "After several failed attempts at getting set up with GitHub Pages, I vowed that if I ever figured out how to do it, I\u2019d write it up. Fortunately, I did eventually figure it out, so here is my write-up.\n\nWhy I think GitHub Pages is cool\n\nNormally when you host stuff on GitHub, you\u2019re just storing your files there. If you push site files, what you\u2019re storing is the code, and when you view a file, you\u2019re viewing the code rather than the output. What GitHub Pages lets you do is store those files, and if they\u2019re HTML files, you can view them like any other website, so there\u2019s no need to host them separately yourself.\n\nGitHub Pages accepts static HTML but can\u2019t execute languages like PHP, or use a database in the way you\u2019re probably used to, so you\u2019ll need to output static HTML files. This is where templating tools such as Jekyll come in, which I\u2019ll talk about later.\n\nThe main benefit of GitHub Pages is ease of collaboration. Changes you make in the repository are automatically synced, so if your site\u2019s hosted on GitHub, it\u2019s as up-to-date as your GitHub repository. This really appeals to me because when I just want to quickly get something set up, I don\u2019t want to mess around with hosting; and when people submit a pull request, I want that change to be visible as soon as I merge it without having to set up web hooks.\n\nBefore you get started\n\nIf you\u2019ve used GitHub before, already have an account and know the basics like how to set up a repository and clone it to your computer, you\u2019re good to go. If not, I recommend getting familiar with that first. The GitHub site has extensive documentation on getting started, and if you\u2019re not a fan of using the command line, the official GitHub apps for Mac and Windows are great.\n\nI also found this tutorial about GitHub Pages by Thinkful really useful, and it contains details on how to turn an existing repository into a GitHub Pages site.\n\nAlthough this involves a bit of using the command line, it\u2019s minimal, and I\u2019ll guide you through the basics.\n\nSetting up GitHub Pages\n\nFor this demo we\u2019re going to build a Christmas recipe site \u2014 nothing complex, just a place to store recipes so we can share them with people, and they can fork or suggest changes to ones they like. My GitHub username is maban, and the project I\u2019ve set up is called christmas-recipes, so once I\u2019ve set up GitHub Pages, the site can be found here: http://maban.github.io/christmas-recipes/\n\nYou can set up a custom domain, but by default, the URL for your GitHub Pages site is your-username.github.io/your-project-name.\n\nSet up the repository\n\nThe first thing we\u2019re going to do is create a new GitHub repository, in exactly the same way as normal, and clone it to the computer. Let\u2019s give it the name christmas-recipes. There\u2019s nothing in it at the moment, but that\u2019s OK.\n\n\n\nAfter setting up the repository on the GitHub website, I cloned it to my computer in my Sites folder using the GitHub app (you can clone it somewhere else, if you want), and now I have a local repository synced with the remote one on GitHub.\n\nNavigate to the repository\n\nNow let\u2019s open up the command line and navigate to the local repository. The easiest way to do this in Terminal is by typing cd  and dragging and dropping the folder into the terminal window and pressing Return. You can refer to Chris Coyier\u2019s GIF illustrating this very same thing, from last week\u2019s 24 ways article \u201cGrunt for People Who Think Things Like Grunt are Weird and Hard\u201d (which is excellent).\n\nSo, for me, that\u2019s\u2026\n\ncd /Users/Anna/Sites/christmas-recipes \n\nCreate a special GitHub Pages branch\n\nSo far we haven\u2019t done anything different from setting up a regular repository, but here\u2019s where things change.\n\nNow we\u2019re in the right place, let\u2019s create a gh-pages branch. This tells GitHub that this is a special branch, and to treat the contents of it differently.\n\nMake sure you\u2019re still in the christmas-recipes directory, and type this command to create the gh-pages branch:\n\ngit checkout --orphan gh-pages\n\nThat --orphan option might be new to you. An orphaned branch is an empty branch that\u2019s disconnected from the branch it was created off, and it starts with no commits, making it a special standalone branch. checkout switches us from the branch we were on to that branch.\n\nIf all\u2019s gone well, we\u2019ll get a message saying Switched to a new branch \u2018gh-pages\u2019.\n\nYou may get an error message saying you don\u2019t have admin privileges, in which case you\u2019ll need to type sudo at the start of that command.\n\nMake gh-pages your default branch (optional)\n\nThe gh-pages branch is separate to the master branch, but by default, the master branch is what will show up if we go to our repository\u2019s URL on GitHub. To change this, go to the repository settings and select gh-pages as the default branch.\n\n\n\nIf, like me, you only want the one branch, you can delete the master branch by following Oli Studholme\u2019s tutorial. It\u2019s actually really easy to do, and means you only have to worry about keeping one branch up to date.\n\nIf you prefer to work from master but push updates to the gh-pages branch, Lea Verou has written up a quick tutorial on how to do this, and it basically involves working from the master branch, and using git rebase to bring one branch up to date with another.\n\nAt the moment, we\u2019ve only got that branch on the local machine, and it\u2019s empty, so to be able to see something at our special GitHub Pages URL, we\u2019ll need to create a page and push it to the remote repository.\n\nMake a page\n\nOpen up your favourite text editor, create a file called index.html in your christmas-recipes folder, and put some exciting text in it. Don\u2019t worry about the markup: all we need is text because right now we\u2019re just checking it works.\n\n\n\nNow, let\u2019s commit and push our changes. You can do that in the command line if you\u2019re comfortable with that, or you can do it via the GitHub app. Don\u2019t forget to add a useful commit message.\n\n\n\nNow we\u2019re ready to see our gorgeous new site! Go to your-username.github.io/your-project-name and, hopefully, you\u2019ll see your first GitHub Pages site. If not, don\u2019t panic, it can take up to ten minutes to publish, so you could make a quick cake in a cup while you wait.\n\nAfter a short wait, our page should be live! Hopefully that wasn\u2019t too traumatic. Now we know it works, we can add some proper markup and CSS and even some more pages.\n\nIf you\u2019re feeling brave, how about we take it to the next level\u2026\n\nSetting up Jekyll\n\nSince GitHub Pages can\u2019t execute languages like PHP, we need to give it static HTML files. This is fine if there are only a few pages, but soon we\u2019ll start to miss things like PHP includes for content that\u2019s the same on every page, like headers and footers.\n\nJekyll helps set up templates and turn them into static HTML. It separates markup from content, and makes it a lot easier for people to edit pages collaboratively. With our recipe site, we want to make it really easy for people to fix typos or add notes, without having to understand PHP. Also, there\u2019s the added benefit that static HTML pages load really fast.\n\nJekyll isn\u2019t officially supported on Windows, but it is still possible to run it if you\u2019re prepared to get your hands dirty.\n\nInstall Jekyll\n\nBack in Terminal, we\u2019re going to install Jekyll\u2026\n\ngem install jekyll\n\n\u2026and wait for the script to run. This might take a few moments. It might take so long that you get worried its broken, but resist the urge to start mashing your keyboard like I did.\n\nGet Jekyll to run on the repository\n\nFingers crossed nothing has gone wrong so far. If something did go wrong, don\u2019t give up! Check this helpful post by Andy Taylor \u2013 you probably just need to install something else first. \n\nNow we\u2019re going to tell Jekyll to set up a new project in the repository, which is in my Sites folder (yours may be in a different place). Remember, we can drag the directory into the terminal window after the command.\n\njekyll new /Users/Anna/Sites/christmas-recipes\n\nIf everything went as expected, we should get this error message: Conflict: /Users/Anna/Sites/christmas-recipes exists and is not empty.\n\nBut that\u2019s OK. It\u2019s just upset because we\u2019ve got that index.html file and possibly also a README.md in there that we made earlier. So move those onto your desktop for the moment and run the command again.\n\njekyll new /Users/Anna/Sites/christmas-recipes\n\nIt should say that the site has installed.\n\nCheck you\u2019re in the repository, and if you\u2019re not, navigate to it by typing cd , drag the christmas-recipes directory into terminal\u2026\n\njekyll cd /Users/Anna/Sites/christmas-recipes\n\n\u2026and type this command to tell Jekyll to run:\n\njekyll serve --watch\n\nBy adding --watch at the end, we\u2019re forcing Jekyll to rebuild the site every time we hit Save, so we don\u2019t have to keep telling it to update every time we want to view the changes. We\u2019ll need to run this every time we start work on the project, otherwise changes won\u2019t be applied. For now, wait while it does its thing. \n\nUpdate the config file\n\nWhen it\u2019s finished, we\u2019ll see the text press ctrl-c to stop. Don\u2019t do that, though. Instead, open up the directory. You\u2019ll notice some new files and folders in there. There\u2019s one called _site, and that\u2019s where all the site files are saved when they\u2019re turned into static HTML. Don\u2019t touch the files in here \u2014 they\u2019re the generated files and will get overwritten every time we make changes to pages and layouts.\n\nThere\u2019s a file in our directory called _config.yml. This has some settings we can change, one of them being what our base URL is. GitHub Pages will assume the base URL is above the project repository, so changing the settings here will help further down the line when setting up navigation links.\n\nReplace the contents of the _config.yml file with this:\n\nname: Christmas Recipes\nmarkdown: redcarpet\npygments: true\nbaseurl: /christmas-recipes\n\nSet up your files\n\nOverwrite the index.html file in the root with the one we made earlier (you might want to pop the README.md back in there, too). \n\nDelete the files in the css folder \u2014 we\u2019ll add our own later.\n\nView the Jekyll site\n\nOpen up your favourite browser and type http://localhost:4000/christmas-recipes in the address bar.\n\n\n\nCheck it out, that\u2019s your site! But it could do with a bit more love.\n\nSet up the _includes files\n\nIt\u2019s always useful to be able to pull in snippets of content onto pages, such as the header and footer, so they only need to be updated in one place. That\u2019s what an _includes folder is for in Jekyll. Create a folder in the root called _includes, and within it add two files: head.html and foot.html. \n\nIn head.html, paste the following:\n\n<!DOCTYPE html>\n<html>\n    <head>\n        <meta charset=\"utf-8\">\n        <title>{{ page.title }}</title>\n        <link rel=\"stylesheet\" href=\"{{ site.baseurl }}/css/main.css\" >\n    </head>\n    <body>\n\nand in foot.html:\n\n</body>\n</html>\n\nWhenever we want to pull in something from the _includes folder, we can use {% include filename.html %} in the layout file \u2014 I\u2019ll show you how to set that up in next step.\n\nMaking layouts\n\nIn our directory, there\u2019s a folder called _layouts and this lets us create a reusable template for pages. Inside that is a default.html file. \n\nDelete everything in default.html and paste in this instead:\n\n{% include head.html %}\n\n    <h1>{{ page.title }}</h1>\n\n    {{ content }}\n\n{% include foot.html %}\n\nThat\u2019s a very basic page with a header, footer, page title and some content. To apply this template to a page, go back into the index.html page and add this snippet to the very top of the file:\n\n---\nlayout: default\ntitle: Home\n---\n\nNow save the index.html file and hit Refresh in the browser. We should see a heading where {{ page.title }} was in the layout, which matches what comes after title: on the page itself (in this case, Home). So, if we wanted a subheading to appear on every page, we could add {{ page.subheading }} to where we want it to appear in our layout file, and a line that says subheading: This is a subheading in between the dashes at the top of the page itself.\n\nUsing Markdown for templates\n\nAnything on a page that sits under the closing dashes is output where {{ content }} appears in the template file. At the moment, this is being output as HTML, but we can use Markdown instead, and Jekyll will convert that into HTML. For this recipe site, we want to make it as easy as possible for people to be able to collaborate, and also have the markup separate from the content, so let\u2019s use Markdown instead of HTML for the recipes.\n\nTelling a page to use Markdown instead of HTML is incredibly simple. All we need to do is change the filename from .html to .md, so let\u2019s rename the index.html to index.md. Now we can use Markdown, and Jekyll will output that as HTML.\n\nCreate a new layout\n\nWe\u2019re going to create a new layout called recipe which is going to be the template for any recipe page we create. Let\u2019s keep it super simple.\n\nIn the _layouts folder, create a file called recipe.html and paste in this:\n\n{% include head.html %}\n\n\t<main>\n\n    \t<h1>{{ page.title }}</h1>\n\n    \t{{ content }}\n\n    \t<p>Recipe by <a href=\"{{ page.recipe-attribution-link }}\">{{ page.recipe-attribution }}</a>.</p>\n\n\t</main>\n\n\t{% include nav.html %}\n\n{% include foot.html %}\n\nThat\u2019s our template. The content that goes on the recipe layout includes a page title, the recipe content, a recipe attribution and a recipe attribution link.\n\nAdding some recipe pages\n\nCreate a new file in the root of the christmas-recipes folder and call it gingerbread.md. Paste the following into it:\n\n---\nlayout: recipe\ntitle: Gingerbread\nrecipe-attribution: HungryJenny\nrecipe-attribution-link: http://www.opensourcefood.com/people/HungryJenny/recipes/soft-christmas-gingerbread-cookies\n---\nMakes about 15 small cookies.\n\n## Ingredients\n\n* 175g plain flour\n* 90g brown sugar\n* 50g unsalted butter, diced, at room temperature\n* 2 tbsp golden syrup\n* 1 egg, beaten\n* 1 tsp ground ginger\n* 1 tsp cinnamon\n* 1 tsp bicarbonate of soda\n* Icing sugar to dust\n\n## Method\n\n1. Sift the flour, ginger, cinnamon and bicarbonate of soda into a large mixing bowl.\n2. Use your fingers to rub in the diced butter. Mix in the sugar.\n3. Mix the egg with the syrup then pour into the flour mixture. Fold in well to form a dough.\n4. Tip some flour onto the work surface and knead the dough until smooth.\n5. Preheat the oven to 180\u00b0C.\n6. Roll the dough out flat and use a shaped cutter to make as many cookies as you like.\n7. Transfer the cookies to a tray and bake in the oven for 15 minutes. Lightly dust the cookies with icing sugar.\n\nThe content is in Markdown, and when we hit Save, it\u2019ll be converted into HTML in the _site folder. Save the file, and go to http://localhost:4000/christmas-recipes/gingerbread.html in your favourite browser.\n\n \n\nAs you can see, the Markdown content has been converted into HTML, and the attribution text and link has been inserted in the right place.\n\n\nAdd some navigation\n\nIn your _includes folder, create a new file called nav.html. Here is some code that will generate your navigation:\n\n<nav class=\"nav-primary\" role=\"navigation\" >\n    <ul>\n        {% for p in site.pages %}\n        <li>\n        \t<a {% if p.url == page.url %}class=\"active\"{% endif %} href=\"{{ site.baseurl }}{{ p.url }}\">{{ p.title }}</a>\n        </li>\n        {% endfor %}\n    </ul>\n</nav>\n\nThis is going to look for all pages and generate a list of them, and give the navigation item that is currently active a class of active so we can style it differently.\n\nNow we need to include that navigation snippet in our layout. Paste {% include nav.html %} in default.html file, under {{ content }}.\n\nPush the changes to GitHub Pages\n\nNow we\u2019ve got a couple of pages, it\u2019s time to push our changes to GitHub. We can do this in exactly the same way as before. Check your special GitHub URL (your-username.github.io/your-project-name) and you should see your site up and running.\n\nIf you quit Terminal, don\u2019t forget to run jekyll serve --watch from within the directory the next time you want to work on the files.\n\nNext steps\n\nNow we know the basics of creating Jekyll templates and publishing them as GitHub Pages, we can have some fun adding more pages and styling them up.\n\n \n \n Here\u2019s one I made earlier\n\n\nI\u2019ve only been using Jekyll for a matter of weeks, mainly for prototyping. It\u2019s really good as a content management system for blogs, and a lot of people host their Jekyll blogs on GitHub, such as Harry Roberts\n\n\n\tBy hosting the code so openly it will make me take more pride in it and allow me to work on it much more easily; no excuses now!\n\n\nOverall, the documentation for Jekyll feels a little sparse and geared more towards blogs than other sites, but as more people discover the benefits of it, I\u2019m sure this will improve over time.\n\nIf you\u2019re interested in poking about with some code, all the files from this tutorial are available on GitHub.", "year": "2013", "author": "Anna Debenham", "author_slug": "annadebenham", "published": "2013-12-18T00:00:00+00:00", "url": "https://24ways.org/2013/get-started-with-github-pages/", "topic": null}
{"rowid": 96, "title": "Unwrapping the Wii U Browser", "contents": "The Wii U was released on 18 November 2012 in the US, and 30 November in the UK. It\u2019s the first eighth generation home console, the first mainstream second-screen device, and it has some really impressive browser specs.\n\nConsoles are not just for games now: they\u2019re marketed as complete entertainment solutions. Internet connectivity and browser functionality have gone from a nice-to-have feature in game consoles to a selling point. In Nintendo\u2019s case, they see it as a challenge to design an experience that\u2019s better than browsing on a desktop.\n\n\n\tLet\u2019s make a browser that users can use on a daily basis, something that can really handle everything we\u2019ve come to expect from a browser and do it more naturally.\nSasaki \u2013 Iwata Asks on Nintendo.com\n\n\nWith 11% of people using console browsers to visit websites, it\u2019s important to consider these devices right from the start of projects. Browsing the web on a TV or handheld console is a very different experience to browsing on a desktop or a mobile phone, and has many usability implications.\n\nConsole browser testing\n\nWhen I\u2019m testing a console browser, one of the first things I do is run Niels Leenheer\u2019s HTML5 test and Lea Verou\u2019s CSS3 test. I use these benchmarks as a rough comparison of the standards each browser supports.\n\nIn October, IE9 came out for the Xbox 360, scoring 120/500 in the HTML5 test and 32% in the CSS3 test. The PS Vita also had an update to its browser in recent weeks, jumping from 58/500 to 243/500 in the HTML5 test, and 32% to 55% in the CSS3 test. Manufacturers have been stepping up their game, trying to make their browsing experiences better.\n\nTo give you an idea of how the Wii U currently compares to other devices, here are the test results of the other TV consoles I\u2019ve tested. I\u2019ve written more in-depth notes on TV and portable console browsers separately.\n\n\nYear of releaseHTML5 scoreCSS3 scoreNotes\nWii U2012258/50048%Runs a Netfront browser (WebKit).\nWii200689/500Wouldn\u2019t runRuns an Opera browser.\nPS3200668/50038%Runs a Netfront browser (WebKit).\nXbox 3602005120/50032%A browser for the Xbox (IE9) was only recently released in October 2012. The Kinect provides voice and gesture support. There\u2019s also SmartGlass, a second-screen app for platforms including Android and iOS.\n\n\nThe Wii U browser is Nintendo\u2019s fifth attempt at a console browser. Based on these tests, it\u2019s already looking promising.\n\nWhy console browsers used to suck\n\nIt takes a lot of system memory to run a good browser, and the problem of older consoles is that they don\u2019t have much memory available. The original Nintendo DS needs a memory expansion pack just to run the browser, because the 4MB it has on board isn\u2019t enough. I noticed that even on newer devices, some sites fail to load because the system runs out of memory.\n\nThe Wii came out six years ago with an Opera browser. Still being used today and with such low resources available, the latest browser features can\u2019t reasonably be supported. There\u2019s also pressure to add features such as tabs, and enable gamers to use the browser while a game is paused. Nintendo\u2019s browser team have the advantage of higher specs to play with on their new console (1GB of memory dedicated to games, 1GB for the system), which makes it easier to support the latest standards. But it\u2019s still a challenge to fit everything in.\n\n\n\t\u2026even though we have more memory, the amount of memory we can use for the browser is limited compared to a PC, so we\u2019ve worked in ways that efficiently allocates the available memory per tab. To work on this, the experience working on the browser for the Nintendo 3DS system under a limited memory constraint helped us greatly.\nSasaki \u2013 Iwata Asks on Nintendo.com\n\n\nIn the box\n\nThe Wii U consists of a console unit which plugs into a TV (the first to support HD), and a wireless controller known as a gamepad. The gamepad is a lot bigger than typical TV console controllers, and it has a touchscreen on the front. The touchscreen is resistive, responding to pressure rather than electrical current. It\u2019s intended to be used with a stylus (provided) but fingers can be used.\n\nIt might look a bit like one, but the gamepad isn\u2019t a portable console designed to be taken out like the PS Vita. The gamepad can be used as a standalone screen with the TV switched off, as long as it\u2019s within range of the console unit \u2013 it basically piggybacks off it.\n\n\n\nIt\u2019s surprisingly lightweight for its size. It has a wealth of detectors including 9-axis control. Sensors wake the device from sleep when it\u2019s picked up. There\u2019s also a camera on the front, and a headphone port and speakers, with audio coming through both the TV and the gamepad giving a surround sound feel.\n\nUp to six tabs can be opened at once, and the browser can be used while games are paused. There\u2019s a really nice little feature here \u2013 the current game\u2019s name is saved as a search option, so it\u2019s really quick to look up contextual content such as walk-throughs.\n\nControls\n\nOnly one gamepad can be used to control the browser, but if there are Wiimotes connected, they can be used as pointers. This doesn\u2019t let the user do anything except point (they each get a little hand icon with a number on it displayed on the screen), but it\u2019s interesting that multiple people can be interacting with a site at once.\n\n\n\nSee a bigger version\n\nThe gamepad can also be used as a simple TV remote control, with basic functions such as bringing up the programme guide, adjusting volume and changing channel. I found the simplified interface much more usable than a full-featured remote control.\n\n\n\nI\u2019m used to scrolling being sluggish on consoles, but the Wii U feels almost as snappy as a desktop browser. Sites load considerably faster compared with others I\u2019ve tested.\n\nTilt-scroll\n\nHolding down ZL and ZR while tilting the screen activates an Instapaper-style tilt to scroll for going up and down the page quickly, useful for navigating very long pages.\n\nSecond screen\n\nThe TV mirrors most of what\u2019s on the gamepad, although the TV screen just displays the contents of the browser window, while the gamepad displays the site along with the browser toolbar.\n\nWhen the user with the gamepad is typing, the keyboard is hidden from the TV screen \u2013 there\u2019s just a bit of text at the top indicating what\u2019s happening on the gamepad.\n\nPressing X draws an on-screen curtain over the TV, hiding the content that\u2019s on the gamepad from the TV. Pressing X again opens the curtains, revealing what\u2019s on the gamepad. Holding the button down plays a drumroll before it\u2019s released and the curtains are opened. I can imagine this being used in meetings as a fun presentation tool.\n\n\n\n\n\tIn a sense, browsing is a personal activity, but you get the idea that people will be coming and going through the room. When I first saw the curtain function, it made a huge impression on me. I walked around with it all over the company saying, \u201cThey\u2019ve really come up with something amazing!\u201d\nIwata \u2013 Iwata Asks on Nintendo.com\n\n\nText\n\nWriting text\n\nUnlike the capacitive screens on smartphones, the Wii U\u2019s resistive screen needs to be pressed harder than you\u2019re probably used to for registering a touch event. The gamepad screen is big, which makes it much easier to type on this device than other handheld consoles, even without the stylus. It\u2019s still more fiddly than a full-sized keyboard though. When you\u2019re designing forms, consider the extra difficulty console users experience.\n\n\n\nAlthough TV screens are physically big, they are typically viewed from further away than desktop screens. This makes readability an issue, so Nintendo have provided not one, but four ways to zoom in and out:\n\n\n\tDouble-tapping on the screen.\n\tTapping the on-screen zoom icons in the browser toolbar.\n\tPressing the + and - buttons on the device.\n\tMoving the right analogue stick up and down.\n\n\nAs well as making it easy to zoom in and out, Nintendo have done a few other things to improve the reading experience on the TV.\n\nSystem font\n\nOne thing you\u2019ll notice pretty quickly is that the browser lacks all the fonts we\u2019re used to falling back to. Serif fonts are replaced with the system\u2019s sans-serif font. I couldn\u2019t get Typekit\u2019s font loading method to work but Fontdeck, which works slightly differently, does display custom fonts.\n\n The system font has been optimised for reading at a distance and is easy to distinguish because the lowercase e has a quirky little tilt.\n\nDon\u2019t lose :focus\n\nUsing the D-pad to navigate is similar to using a keyboard. Individual links are focused on, with a blue outline drawn around them.\n\nThe recently redesigned An Event Apart site is an example that improves the experience for keyboard and D-pad users. They\u2019ve added a yellow background colour to links on focus. It feels nicer than the default blue outline on its own.\n\n\n\nMedia\n\nThis year, television overtook PCs as the primary way to watch online video content. TV is the natural environment for video, and 42% of online TVs in the US are connected to the internet via a console. Unfortunately, the <video> tag isn\u2019t supported in most console browsers, and those that have Flash installed often have such an old version that the video won\u2019t play.\n\nI suspect this has been a big driver in getting console browsers to support web standards. The Wii U is designed with video content in mind. It doesn\u2019t support Flash but it does support the HTML5 <video> tag.\n\nSome video formats can\u2019t be played, but those that are supported bring up an optimised interface with a custom scrub bar. This is where the device switches from mirroring the TV to being a second screen. The full-screen video is displayed on the TV, and the interface on the gamepad.\n\nThe really clever bit is that while a video is playing, the gamepad user can keep the video playing on the TV screen while searching for another video or browsing the web. This is the same for images too.\n\nOn the left, the video is being shown full-screen on the TV and gamepad. Only the gamepad gets the scrub bar. Clicking the slide up/down button (circled) lets the gamepad user browse the web while the video on the TV continues to play full-screen, as shown in the image on the right.\n\nThere\u2019s support for SVG images, and they look great on a high-definition TV screen. However, there\u2019s currently no way to save or download files.\n\nPreparing for console users\n\nI wasn\u2019t expecting to be quite as impressed as I am by this browser. It\u2019s encouraging to see console makers investing time into improving the experience as well as the standards support. In the same way there was an explosion in mobile browser use as the experience got better, I\u2019m sure we\u2019ll see the same with console browsers as the experience improves.\n\nThe value of detection\n\nConsoles offer a range of inputs including gesture, voice and controller buttons. That means we have to think about more diverse methods of input than just touch and click.\n\nThis is where I could tell you to add some detection methods such as user agent string sniffing to target a different experience for console users. But the majority of the time, that really isn\u2019t necessary. TV console browsers are getting a lot better at compensating for the living room environment, and they\u2019re designed to work with websites that haven\u2019t been optimised for this context.\n\nRather than tighten our grip on optimising experiences for every device out there, we\u2019ve got to be pragmatic. There are so many new devices coming out every week, our designs need to be future-proof rather than fixed to a particular device in time.\n\nEven fuzzy device detection isn\u2019t reliable \u2013 the PS Vita declares itself to be mobile, a mobile device and a Kindle Fire tablet, while the two DS devices state they\u2019re neither mobile nor mobile phones nor tablets, but computers. They\u2019re weird outliers, but they\u2019re still important devices to consider.\n\nThinking broadly about how our designs will be interacted with and viewed on a TV screen can help improve that experience for everyone. This is about accessibility. Considering how someone uses a site with a D-pad, we can improve the experience for keyboard users. When we think about colour contrast and text legibility on TV screens, we can apply that for anyone who reads content on the web. So why just offer this to the TV users?\n\nPlaying with the browser\n\n\n\t\u2026we want to prove to them through this Wii U Internet Browser that browsing itself can be an entertainment.\nIwata \u2013 Iwata Asks on Nintendo.com\n\n\nAlthough I\u2019m cautious about designing experiences for specific devices, it\u2019s fun to experiment with the technology available. Nintendo have promised web developers access to the Wii U\u2019s buttons and sensors. There\u2019s already some JavaScript documentation, and a demo for you to try.\n\nIf you\u2019re interested in making your own games, thanks to web standards, a lot of HTML5 games work already on the device. Matt Hackett wrote up his experience of testing the game he built, and he talks about some of features the browser lacks. There\u2019s certainly an incentive there for console manufacturers to improve their HTML5 support so more games can be played in their browser.\n\nWhat excites me about consoles is that it\u2019s like looking at what might be available to us in future browsers. As well as thinking about how our sites work on small screens, we should also consider big screens. We\u2019re already figuring out how images should work at different screen widths and connection speeds, but we\u2019ve also got some interesting challenges ahead of us catering for second screen experiences and 3D-enabled devices. \n\nSo, this Christmas, if you\u2019re huddled round the game console or a smart TV, give the browser in it a try.", "year": "2012", "author": "Anna Debenham", "author_slug": "annadebenham", "published": "2012-12-22T00:00:00+00:00", "url": "https://24ways.org/2012/unwrapping-the-wii-u-browser/", "topic": "ux"}
{"rowid": 215, "title": "Teach the CLI to Talk Back", "contents": "The CLI is a daunting tool. It\u2019s quick, powerful, but it\u2019s also incredibly easy to screw things up in \u2013 either with a mistyped command, or a correctly typed command used at the wrong moment. This puts a lot of people off using it, but it doesn\u2019t have to be this way.\nIf you\u2019ve ever interacted with Slack\u2019s Slackbot to set a reminder or ask a question, you\u2019re basically using a command line interface, but it feels more like having a conversation. (My favourite Slack app is Lunch Train which helps with the thankless task of herding colleagues to a particular lunch venue on time.)\nSame goes with voice-operated assistants like Alexa, Siri and Google Home. There are even games, like Lifeline, where you interact with a stranded astronaut via pseudo SMS, and KOMRAD where you chat with a Soviet AI.\nI\u2019m not aiming to build an AI here \u2013 my aspirations are a little more down to earth. What I\u2019d like is to make the CLI a friendlier, more forgiving, and more intuitive tool for new or reluctant users. I want to teach it to talk back.\nInteractive command lines in the wild\nIf you\u2019ve used dev tools in the command line, you\u2019ve probably already used an interactive prompt \u2013 something that asks you questions and responds based on your answers. Here are some examples:\nYeoman\nIf you have Yeoman globally installed, running yo will start a command prompt.\n\nThe prompt asks you what you\u2019d like to do, and gives you options with how to proceed. Seasoned users will run specific commands for these options rather than go through this prompt, but it\u2019s a nice way to start someone off with using the tool.\nnpm\nIf you\u2019re a Node.js developer, you\u2019re probably familiar with typing npm init to initialise a project. This brings up prompts that will populate a package.json manifest file for that project.\n\nThe alternative would be to expect the user to craft their own package.json, which is more error-prone since it\u2019s in JSON format, so something as trivial as an extraneous comma can throw an error.\nSnyk\nSnyk is a dev tool that checks for known vulnerabilities in your dependencies. Running snyk wizard in the CLI brings up a list of all the known vulnerabilities, and gives you options on how to deal with it \u2013 such as patching the issue, applying a fix by upgrading the problematic dependency, or ignoring the issue (you are then prompted for a reason).\n\nThese decisions get mapped to the manifest and a .snyk file, and committed into the repo so that the settings are the same for everyone who uses that project.\nI work at Snyk, and running the wizard is what made me think about building my own personal assistant in the command line to help me with some boring, repetitive tasks.\nWriting your own\nSomething I do a lot is add bookmarks to styleguides.io \u2013 I pull down the entire repo, copy and paste a template YAML file, and edit to contents. Sometimes I get it wrong and break the site. So I\u2019ve been putting together a tool to help me add bookmarks.\nIt\u2019s called bookmarkbot \u2013 it\u2019s a personal assistant squirrel called Mark who will collect and bury your bookmarks for safekeeping.*\n\n*Fortunately, this metaphor also gives me a charming excuse for any situation where bookmarks sometimes get lost \u2013 it\u2019s not my poorly-written code, honest, it\u2019s just being realistic because sometimes squirrels forget where they buried things!\nWhen you run bookmarkbot, it will ask you for some information, and save that information as a Markdown file in YAML format.\nFor this demo, I\u2019m going to use a Node.js package called inquirer, which is a well supported tool for creating command line prompts. I like it because it has a bunch of different question types; from input, which asks for some text back, confirm which expects a yes/no response, or a list which gives you a set of options to choose from. You can even nest questions, Choose Your Own Adventure style.\nPrerequisites\n\nNode.js\nnpm\nRubyGems (Only if you want to go as far as serving a static site for your bookmarks, and you want to use Jekyll for it)\n\nDisclaimer\nBear in mind that this is a really simplified walkthrough. It doesn\u2019t have any error states, and it doesn\u2019t handle the situation where we save a file with the same name. But it gets you in a good place to start building out your tool.\nLet\u2019s go!\nCreate a new folder wherever you keep your projects, and give it an awesome name (I\u2019ve called mine bookmarks and put it in the Sites directory because I\u2019m unimaginative). Now cd to that directory. \ncd Sites/bookmarks\nLet\u2019s use that example I gave earlier, the trusty npm init.\nnpm init\nPop in the information you\u2019d like to provide, or hit ENTER to skip through and save the defaults. Your directory should now have a package.json file in it. Now let\u2019s install some of the dependencies we\u2019ll need.\nnpm install --save inquirer\nnpm install --save slugify\nNext, add the following snippet to your package.json to tell it to run this file when you run npm start.\n\"scripts\": {\n  \u2026\n  \"start\": \"node index.js\"\n}\nThat index.js file doesn\u2019t exist yet, so let\u2019s create it in the root of our folder, and add the following:\n// Packages we need\nvar fs = require('fs'); // Creates our file (part of Node.js so doesn't need installing)\nvar inquirer = require('inquirer'); // The engine for our questions prompt\nvar slugify = require('slugify'); // Will turn a string into a usable filename\n\n// The questions\nvar questions = [\n  {\n    type: 'input',\n    name: 'name',\n    message: 'What is your name?',\n  },\n];\n\n// The questions prompt\nfunction askQuestions() {\n\n  // Ask questions\n  inquirer.prompt(questions).then(answers => {\n\n    // Things we'll need to generate the output\n    var name = answers.name;\n\n    // Finished asking questions, show the output\n    console.log('Hello ' + name + '!');\n\n  });\n\n}\n\n// Kick off the questions prompt\naskQuestions();\nThis is just some barebones where we\u2019re including the inquirer package we installed earlier. I\u2019ve stored the questions in a variable, and the askQuestions function will prompt the user for their name, and then print \u201cHello <your name>\u201d in the console.\nEnough setup, let\u2019s see some magic. Save the file, go back to the command line and run npm start.\n\nExtending what we\u2019ve learnt\nAt the moment, we\u2019re just saving a name to a file, which isn\u2019t really achieving our goal of saving bookmarks. We don\u2019t want our tool to forget our information every time we talk to it \u2013 we need to save it somewhere. So I\u2019m going to add a little function to write the output to a file.\nSaving to a file\nCreate a folder in your project\u2019s directory called _bookmarks. This is where the bookmarks will be saved.\nI\u2019ve replaced my questions array, and instead of asking for a name, I\u2019ve extended out the questions, asking to be provided with a link and title (as a regular input type), a list of tags (using inquirer\u2019s checkbox type), and finally a description, again, using the input type.\nSo this is how my code looks now:\n// Packages we need\nvar fs = require('fs'); // Creates our file\nvar inquirer = require('inquirer'); // The engine for our questions prompt\nvar slugify = require('slugify'); // Will turn a string into a usable filename\n\n// The questions\nvar questions = [\n  {\n    type: 'input',\n    name: 'link',\n    message: 'What is the url?',\n  },\n  {\n    type: 'input',\n    name: 'title',\n    message: 'What is the title?',\n  },\n  {\n    type: 'checkbox',\n    name: 'tags',\n    message: 'Would you like me to add any tags?',\n    choices: [\n      { name: 'frontend' },\n      { name: 'backend' },\n      { name: 'security' },\n      { name: 'design' },\n      { name: 'process' },\n      { name: 'business' },\n    ],\n  },\n  {\n    type: 'input',\n    name: 'description',\n    message: 'How about a description?',\n  },\n];\n\n// The questions prompt\nfunction askQuestions() {\n\n  // Say hello\n  console.log('\ud83d\udc3f  Oh, hello! Found something you want me to bookmark?\\n');\n\n  // Ask questions\n  inquirer.prompt(questions).then((answers) => {\n\n    // Things we'll need to generate the output\n    var title = answers.title;\n    var link = answers.link;\n    var tags = answers.tags + '';\n    var description = answers.description;\n    var output = '---\\n' +\n                 'title: \"' + title + '\"\\n' +\n                 'link: \"' + link + '\"\\n' +\n                 'tags: [' + tags + ']\\n' +\n                 '---\\n' + description + '\\n';\n\n    // Finished asking questions, show the output\n    console.log('\\n\ud83d\udc3f  All done! Here is what I\\'ve written down:\\n');\n    console.log(output);\n\n    // Things we'll need to generate the filename\n    var slug = slugify(title);\n    var filename = '_bookmarks/' + slug + '.md';\n\n    // Write the file\n    fs.writeFile(filename, output, function () {\n      console.log('\\n\ud83d\udc3f  Great! I have saved your bookmark to ' + filename);\n    });\n\n  });\n\n}\n\n// Kick off the questions prompt\naskQuestions();\nThe output is formatted into YAML metadata as a Markdown file, which will allow us to turn it into a static HTML file using a build tool later. Run npm start again and have a look at the file it outputs.\n\nGetting confirmation\nBefore the user makes critical changes, it\u2019s good to verify those changes first. We\u2019re going to add a confirmation step to our tool, before writing the file. More seasoned CLI users may favour speed over a \u201chey, can you wait a sec and just check this is all ok\u201d step, but I always think it\u2019s worth adding one so you can occasionally save someone\u2019s butt.\nSo, underneath our questions array, let\u2019s add a confirmation array.\n// Packages we need\n\u2026\n// The questions\n\u2026\n\n// Confirmation questions\nvar confirm = [\n  {\n    type: 'confirm',\n    name: 'confirm',\n    message: 'Does this look good?',\n  },\n];\n\n// The questions prompt\n\u2026\n\nAs we\u2019re adding the confirm step before the file gets written, we\u2019ll need to add the following inside the askQuestions function:\n// The questions prompt\nfunction askQuestions() {\n  // Say hello\n  \u2026\n  // Ask questions\n  inquirer.prompt(questions).then((answers) => {\n    \u2026\n    // Things we'll need to generate the output\n    \u2026\n    // Finished asking questions, show the output\n    \u2026\n\n    // Confirm output is correct\n    inquirer.prompt(confirm).then(answers => {\n\n      // Things we'll need to generate the filename\n      var slug = slugify(title);\n      var filename = '_bookmarks/' + slug + '.md';\n\n      if (answers.confirm) {\n        // Save output into file\n        fs.writeFile(filename, output, function () {\n          console.log('\\n\ud83d\udc3f  Great! I have saved your bookmark to ' +\n          filename);\n        });\n      } else {\n        // Ask the questions again\n        console.log('\\n\ud83d\udc3f  Oops, let\\'s try again!\\n');\n        askQuestions();\n      }\n\n    });\n\n  });\n}\n\n// Kick off the questions prompt\naskQuestions();\nNow run npm start and give it a go!\n\nTyping y will write the file, and n will take you back to the start. Ideally, I\u2019d store the answers already given as defaults so the user doesn\u2019t have to start from scratch, but I want to keep this demo simple.\nServing the files\nNow that your bookmarking tool is successfully saving formatted Markdown files to a folder, the next step is to serve those files in a way that lets you share them online. The easiest way to do this is to use a static-site generator to convert your YAML files into HTML, and pop them all on one page. Now, you\u2019ve got a few options here and I don\u2019t want to force you down any particular path, as there are plenty out there \u2013 it\u2019s just a case of using the one you\u2019re most comfortable with.\nI personally favour Jekyll because of its tight integration with GitHub Pages \u2013 I don\u2019t want to mess around with hosting and deployment, so it\u2019s really handy to have my bookmarks publish themselves on my site as soon as I commit and push them using Git.\nI\u2019ll give you a very brief run-through of how I\u2019m doing this with bookmarkbot, but I recommend you read my Get Started With GitHub Pages (Plus Bonus Jekyll) guide if you\u2019re unfamiliar with them, because I\u2019ll be glossing over some bits that are already covered in there.\nSetting up a build tool\nIf you haven\u2019t already, install Jekyll and Bundler globally through RubyGems. Jekyll is our static-site generator, and Bundler is what we use to install Ruby dependencies.\ngem install jekyll bundler\nIn my project folder, I\u2019m going to run the following which will install the Jekyll files we\u2019ll need to build our listing page. I\u2019m using --force, otherwise it will complain that the directory isn\u2019t empty.\njekyll new . --force\nIf you check your project folder, you\u2019ll see a bunch of new files. Now run the following to start the server:\nbundle exec jekyll serve\nThis will build a new directory called _site. This is where your static HTML files have been generated. Don\u2019t touch anything in this folder because it will get overwritten the next time you build.\nNow that serve is running, go to http://127.0.0.1:4000/ and you\u2019ll see the default Jekyll page and know that things are set up right. Now, instead, we want to see our list of bookmarks that are saved in the _bookmarks directory (make sure you\u2019ve got a few saved). So let\u2019s get that set up next.\nOpen up the _config.yml file that Jekyll added earlier. In here, we\u2019re going to tell it about our bookmarks. Replace everything in your _config.yml file with the following:\ntitle: My Bookmarks\ndescription: These are some of my favourite articles about the web.\nmarkdown: kramdown\nbaseurl: /bookmarks # This needs to be the same name as whatever you call your repo on GitHub.\ncollections:\n  - bookmarks\nThis will make Jekyll aware of our _bookmarks folder so that we can call it later. Next, create a new directory and file at _layouts/home.html and paste in the following.\n<!doctype html>\n<html lang=\"en\">\n<head>\n  <meta charset=\"UTF-8\" />\n  <title>{{site.title}}</title>\n  <meta name=\"description\" content=\"{{site.description}}\">\n</head>\n\n<body>\n\n  <h1>{{site.title}}</h1>\n  <p>{{site.description}}</p>\n\n  <ul>\n    {% for bookmark in site.bookmarks %}\n    <li>\n      <a href=\"{{bookmark.link}}\">\n        <h2>{{bookmark.title}}</h2>\n      </a>\n      {{bookmark.content}}\n      {% if bookmark.tags %}\n      <ul>\n        {% for tags in bookmark.tags %}<li>{{tags}}</li>{% endfor %}\n      </ul>\n      {% endif %}\n    </li>\n    {% endfor %}\n  </ul>\n\n</body>\n\n</html>\nRestart Jekyll for your config changes to kick in, and go to the url it provides you (probably http://127.0.0.1:4000/bookmarks, unless you gave something different as your baseurl).\n\nIt\u2019s a decent start \u2013 there\u2019s a lot more we can do in this area but now we\u2019ve got a nice list of all our bookmarks, let\u2019s get it online!\nIf you want to use GitHub Pages to host your files, your first step is to push your project to GitHub. Go to your repository and click \u201csettings\u201d. Scroll down to the section labelled \u201cGitHub Pages\u201d, and from here you can enable it. Select your master branch, and it will provide you with a url to view your published pages.\n\nWhat next?\nNow that you\u2019ve got a framework in place for publishing bookmarks, you can really go to town on your listing page and make it your own. First thing you\u2019ll probably want to do is add some CSS, then when you\u2019ve added a bunch of bookmarks, you\u2019ll probably want to have some filtering in place for the tags, perhaps extend the types of questions that you ask to include an image (if you\u2019re feeling extra-fancy, you could just ask for a url and pull in metadata from the site itself). Maybe you\u2019ve got an idea that doesn\u2019t involve bookmarks at all.\nYou could use what you\u2019ve learnt to build a place where you can share quotes, a list of your favourite restaurants, or even Christmas gift ideas.\nHere\u2019s one I made earlier\n\nMy demo, bookmarkbot, is on GitHub, and I\u2019ve reused a lot of the code from styleguides.io. Feel free to grab bits of code from there, and do share what you end up making!", "year": "2017", "author": "Anna Debenham", "author_slug": "annadebenham", "published": "2017-12-11T00:00:00+00:00", "url": "https://24ways.org/2017/teach-the-cli-to-talk-back/", "topic": "code"}
{"rowid": 244, "title": "It\u2019s Beginning to Look a Lot Like XSSmas", "contents": "I dread the office Secret Santa. I have a knack for choosing well-meaning but inappropriate presents, like a bottle of port for a teetotaller, a cheese-tasting experience for a vegan, or heaven forbid, Spurs socks for an Arsenal supporter. Ok, the last one was intentional.\nIt\u2019s the same with gifting code. Once, I made a pattern library for A List Apart which I open sourced, and a few weeks later, a glaring security vulnerability was found in it. My gift was so generous that it enabled unrestricted access to any file on any public-facing server that hosted it.\nWith platforms like GitHub and npm, giving the gift of code is so easy it\u2019s practically a no-brainer. This giant, open source yankee swap helps us do our jobs without starting from scratch with every project. But like any gift-giving, it\u2019s also risky.\nVulnerabilities and Open Source\nOpen source code is not inherently more or less vulnerable than closed-source code. What makes it higher risk is that the same piece of code gets reused in lots of places, meaning a hacker can use the same exploit mechanism on the same vulnerable code in different apps.\nGraph showing the number of open source vulnerabilities published per year, from the State of Open Source Security 2017\nIn the first 24 ways article this year, Katie referenced a few different types of vulnerability:\n\nCross-site Request Forgery (also known as CSRF)\nSQL Injection\nCross-site Scripting (also known as XSS)\n\nThere are many more types of vulnerability, and those that live under the same category share similarities. \nFor example, my favourite \u2013 is it weird to have a favourite vulnerability? \u2013 is Cross Site Scripting (XSS), which allows for the injection of scripts into web pages. This is a really common vulnerability often unwittingly added by developers. OWASP (the Open Web Application Security Project) wrote a great article about how to prevent opening the door to XSS attacks \u2013 share it generously with your colleagues.\nMost vulnerabilities like this are not added intentionally \u2013 they\u2019re doors left ajar due to the way something has been scripted, like the over-generous code in my pattern library. \nOthers, though, are added intentionally. A few months ago, a hacker, disguised as a helpful elf, offered to take over the maintenance of a popular npm package that had been unmaintained for a couple of years. The owner had moved onto other projects, and was keen to see it continue to be maintained by someone else, so transferred ownership. Fast-forward 3 months, it was discovered that the individual had quietly added a malicious package to the codebase, and the obfuscated code in it had been unwittingly installed onto thousands of apps. The code added was designed to harvest Bitcoin if it was run alongside another application. It was only spotted due to a developer\u2019s curiosity.\nAnother tactic to get developers to unwittingly install malicious packages into their codebase is \u201ctyposquatting\u201d \u2013 back in August last year, npm reported that a user had been publishing packages with very similar names to popular packages (for example, crossenv instead of cross-env). \nThis is a big wakeup call for open source maintainers. Techniques like this are likely to be used more as the maintenance of open source libraries becomes an increasing burden to their owners. After all, starting a new project often has a greater reward than maintaining an existing one, but remember, an open source library is for life, not just for Christmas.\nSanta\u2019s on his sleigh\nIf you use open source libraries, chances are that these libraries also use open source libraries. Your app may only have a handful of dependencies, but tucked in the back of that sleigh may be a whole extra sack of dependencies known as deep dependencies (ones that you didn\u2019t directly install, but are dependencies of that dependency), and these can contain vulnerabilities too.\nLet\u2019s look at the npm package santa as an example. santa has 8 direct dependencies listed on npm. That seems pretty manageable. But that\u2019s just the tip of the iceberg \u2013 have a look at the full dependency tree which contains 109 dependencies \u2013 more dependencies than there are Christmas puns in this article. Only one of these direct dependencies has a vulnerability (at the time of writing), but there are actually 13 other known vulnerabilities in santa, which have been introduced through its deeper dependencies.\nFixing vulnerabilities \u2013 the ultimate christmas gift\nIf you\u2019re a maintainer of open source libraries, taking good care of them is the ultimate gift you can give. Keep your dependencies up to date, use a security tool to monitor and alert you when new vulnerabilities are found in your code, and fix or patch them promptly. This will help keep the whole open source ecosystem healthy.\nWhen you find out about a new vulnerability, you have some options:\nFix the vulnerability via an upgrade\nYou can often fix a vulnerability by upgrading the library to the latest version. Make sure you\u2019re using software that monitors your dependencies for new security issues and lets you know when a fix is ready, otherwise you may be unwittingly using a vulnerable version.\nPatch the vulnerable code\nSometimes, a fix for a vulnerable library isn\u2019t possible. This is often the case when a library is no longer being maintained, or the version of the library being used might be so out of date that upgrading it would cause a breaking change. Patches are bits of code that will fix that particular issue, but won\u2019t change anything else.\nSwitch to a different library\nIf the library you\u2019re using has no fix or patch, you may be better of switching it out for another one, particularly if it looks like it\u2019s being unmaintained.\nResponsibly disclosing vulnerabilities\nKnowing how to responsibly disclose vulnerabilities is something I\u2019m ashamed to admit that I didn\u2019t know about before I joined a security company. But it\u2019s so important! On discovering a new vulnerability, a developer has a few options: \n\nA malicious developer will exploit that vulnerability for their own gain. \nA reckless (or inexperienced) developer will disclose that vulnerability to the world without following a responsible disclosure process. This opens the door to an unethical developer exploiting the vulnerability. At Snyk, we monitor social media for mentions of newly found vulnerabilities so we can add them to our database and share fixes before they get exploited.\nAn ethical and aware developer will follow what\u2019s known as a \u201cresponsible disclosure process\u201d. They will contact the maintainer of the code privately, allowing reasonable time for them to release a fix for the issue and to give others who use that vulnerable code a chance to fix it too.\n\nIt\u2019s important to understand this process if you\u2019re a maintainer or contributor of code. It can be daunting when a report comes in, but understanding and following the right steps will help reduce the risk to the people who use that code.\nSo what does responsible disclosure look like? I\u2019ll take Node.js\u2019s security disclosure policy as an example. They ask that all security issues that are found in Node.js are reported there. (There\u2019s a separate process for bug found in third-party npm packages). Once you\u2019ve reported a vulnerability, they promise to acknowledge it within 24 hours, and to give a more detailed response within 48 hours. If they find that the issue is indeed a security bug, they\u2019ll give you regular updates about the progress they\u2019re making towards fixing it. As part of this, they\u2019ll figure out which versions are affected, and prepare fixes for them. They\u2019ll assign the vulnerability a CVE (Common Vulnerabilities and Exposures) ID and decide on an embargo date for public disclosure. On the date of the embargo, they announce the vulnerability in their Node.js security mailing list and deploy fixes to nodejs.org.\nTim Kadlec published an in-depth article about responsible disclosures if you\u2019re interested in knowing more. It has some interesting horror stories of what happened when the disclosure process was not followed.\nEncourage responsible disclosure\nAdd a SECURITY.md file to your project so someone who wants to message you about a vulnerability can do so without having to hunt around for contact details. Last year, Snyk published a State of Open Source Security report that found 79.5% of maintainers do not have a public disclosure policy. Those that did were considerably more likely to get notified privately about a vulnerability \u2013 73% of maintainers who had one had been notified, vs 21% of maintainers who hadn\u2019t published one one.\nStats from the State of Open Source Security 2017\nBug bounties\nSome companies run bug bounties to encourage the responsible disclosure of vulnerabilities. By offering a reward for finding and safely disclosing a vulnerability, it also reduces the enticement of exploiting a vulnerability over reporting it and getting a quick cash reward. Hackerone is a community of ethical hackers who pentest apps that have signed up for the scheme and get paid when they find a new vulnerability. Wordpress is one such participant, and you can see the long list of vulnerabilities that have been disclosed as part of that program.\nIf you don\u2019t have such a bounty, be prepared to get the odd vulnerability extortion email. Scott Helme, who founded securityheaders.com and report-uri.com, wrote a post about some of the requests he gets for a report about a critical vulnerability in exchange for money. \n\nOn one hand, I want to be as responsible as possible and if my users are at risk then I need to know and patch this issue to protect them. On the other hand this is such irresponsible and unethical behaviour that interacting with this person seems out of the question.\n\nA gift worth giving\nIt\u2019s time to brush the dust off those old gifts that we shared and forgot about. Practice good hygiene and run them through your favourite security tool \u2013 I\u2019m just a little biased towards Snyk, but as Katie mentioned, there\u2019s also npm audit if you use Node.js, and most source code managers like GitHub and GitLab have basic vulnerability alert capabilities.\nStats from the State of Open Source Security 2017\nMost importantly, patch or upgrade away those vulnerabilities away, and if you want to share that Christmas spirit, open fixes for your favourite open source projects, too.", "year": "2018", "author": "Anna Debenham", "author_slug": "annadebenham", "published": "2018-12-17T00:00:00+00:00", "url": "https://24ways.org/2018/its-beginning-to-look-a-lot-like-xssmas/", "topic": "code"}
{"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": 73, "title": "How to Make Your Site Look Half-Decent in Half an Hour", "contents": "Programmers like me are often intimidated by design \u2013 but a little effort can give a huge return on investment. Here are one coder\u2019s tips for making any site quickly look more professional. \n\nI am a programmer. I am not a designer. I have a degree in computer science, and I don\u2019t mind Comic Sans. (It looks cheerful. Move on.)\n\nBut although I am a programmer, I want to make my sites look attractive. This is partly out of vanity, and partly realism. Vanity because I want people to think my work is good, and realism because the research shows that people won\u2019t think a site is credible unless it also looks attractive.\n\nFor a very long time after I became a programmer, I was scared of design. Design seemed to consist of complicated rules that weren\u2019t written down anywhere, plus an unlearnable sense of taste, possessed only by a black-clad elite. \n\nBut a little while ago, I decided to do my best to hack what it took to make my own projects look vaguely attractive. And although this doesn\u2019t come close to the effect a professional designer could achieve, gathering these resources for improving a site\u2019s look and feel has been really helpful. \n\nIf I hadn\u2019t figured out some basic design shortcuts, it\u2019s unlikely that a weekend hack of mine would have ended up on page three of the Daily Mail. And too often now, I see excellent programming projects that don\u2019t reach the audience they deserve, simply because their design doesn\u2019t match their execution. \n\nSo, if you are a developer, my Christmas present to you is this: my own collection of hacks that, used rightly, can make your personal programming projects look professional, quickly. None are hard to learn, most are free, and they let you focus on writing code.\n\nOne thing to note about these tips, though. They are a personal, pragmatic compilation. They are suggestions, not a definitive guide. You will definitely get better results by working with a professional designer, and by studying design more deeply. \n\nIf you are a designer, I would love to hear your suggestions for the best tools that I\u2019ve missed, and I\u2019d love to know how we programmers can do things better.\n\nWith that, on to the tools\u2026\n\n1. Use Bootstrap\n\nIf you\u2019re not already using Bootstrap, start now. I really think that Bootstrap is one of the most significant technical achievements of the last few years: it democratizes the whole process of web design. \n\nEssentially, Bootstrap is a a grid system, with a bunch of common elements. So you can lay your site out how you want, drop in simple elements like forms and tables, and get a good-looking, consistent result, without spending hours fiddling with CSS. You just need HTML. \n\nAnother massive upside is that it makes it easy to make any site responsive, so you don\u2019t have to worry about writing media queries. Go, get Bootstrap and check out the examples. To keep your site lightweight, you can customize your download to include only the elements you want.  \n\nIf you have more time, then Mark Otto\u2019s article on why and how Bootstrap was created at Twitter is well worth a read. \n\n2. Pimp Bootstrap\n\nUsing Bootstrap is already a significant advance on not using Bootstrap, and massively reduces the tedium of front-end development. But you also run the risk of creating Yet Another Bootstrap Site, or Hack Day Design, as it\u2019s known. \n\nIf you\u2019re really pressed for time, you could buy a theme from Wrap Bootstrap. These are usually created by professional designers, and will give a polish that we can\u2019t achieve ourselves. Your site won\u2019t be unique, but it will look good quickly. \n\nLuckily, it\u2019s pretty easy to make Bootstrap not look too much like Bootstrap \u2013 using fonts, CSS effects, background images, colour schemes and so on. Most of the rest of this article covers different ways to achieve this. \n\nWe are going to customize this Bootstrap example page.\n\nThis already has some custom CSS in the <head>. We\u2019ll pull it all out, and create a new CSS file, custom.css. Then we add a reference to it in the header. Now we\u2019re ready to start customizing things.\n\n\n\n3. Fonts\n\nWeb fonts are one of the quickest ways to make your site look distinctive, modern, and less Bootstrappy, so we\u2019ll start there. \n\nFirst, we can add some sweet fonts, from Google Web Fonts. The intimidating bit is choosing fonts that look nice together. Luckily, there are plenty of suggestions around the web: we\u2019re going to use one of DesignShack\u2019s suggested free Google Fonts pairings. Our fonts are Corben (for headings) and Nobile (for body copy). \n\nThen we add these files to our <head>. \n\n<link href=\"http://fonts.googleapis.com/css?family=Corben:bold\" rel=\"stylesheet\" type=\"text/css\">\n <link href=\"http://fonts.googleapis.com/css?family=Nobile\" rel=\"stylesheet\" type=\"text/css\">\n\n\u2026and this to custom.css: \n\nh1, h2, h3, h4, h5, h6 {\n    font-family: 'Corben', Georgia, Times, serif;\n}\np, div {\n    font-family: 'Nobile', Helvetica, Arial, sans-serif;\n}\n\nNow our example looks like this. It\u2019s not going to win any design awards, but it\u2019s immediately better:\n\n\n\nI also recommend the web font services Fontdeck, or Typekit \u2013 these have a wider selection of fonts, and are worth the investment if you regularly need to make sites look good. For more font combinations, Just My Type suggests appealing pairings from Typekit. Finally, you can experiment with type pairing ideas at Type Connection. For the design background on pairing fonts, Typekit\u2019s post is worth a read. \n\n4. Textures\n\nAn instant way to make a site look classy is to use textures. You know the grey, stripy, indefinably elegant background on 24ways.org? That.\n\nIf only there was a superb resource listing attractive, free, ready-to-use textures\u2026 Oh wait, there\u2019s Atle Mo\u2019s Subtle Patterns. \n\nWe\u2019re going to use Cream Dust, for an effect that can only be described as subtle. We download the file to a new /img/ directory, then add this to the CSS file:\n\nbody { \n    background: url(/img/cream_dust.png) repeat 0 0;\n}\n\nBang:\n\n\n\nFor some design background on patterns, I recommend reading through Smashing Magazine\u2019s guidelines on textures. (TL;DR version: use textures to enhance beauty, and clarify the information architecture of your site; but don\u2019t overdo it, or inadvertently obscure your text.)\n\nStill more to do, though. Onwards. \n\n5. Icons\n\nLast year\u2019s 24 ways taught us to use icon fonts for our site icons. \n\nThis is great for the time-pressed coder, because icon fonts don\u2019t just cut down on HTTP requests \u2013 they\u2019re a lot quicker to set up than image-based icons, too. \n\nBootstrap ships with an extensive, free for commercial use icon set in the shape of Font Awesome. Its icons are safe for screen readers, and can even be made to work in IE7 if needed (we\u2019re not going to bother here). \n\nTo start using these icons, just download Font Awesome, and add the /fonts/ directory to your site and the font-awesome.css file into your /css/ directory. Then add a reference to the CSS file in your header:\n\n<link rel=\"stylesheet\" href=\"/css/font-awesome.css\">\n\nFinally, we\u2019ll add a truck icon to the main action button, as follows. Why a truck? Why not?\n\n<a class=\"btn btn-large btn-success\" href=\"#\"><i class=\"icon-truck\"></i> Sign up today</a>\n\nWe\u2019ll also tweak our CSS file to stop the icon nudging up against the button text:\n\n.jumbotron .btn i { \n    margin-right: 8px;  \n}\n\nAnd this is how it looks:\n\n\n\nNot the most exciting change ever, but it livens up the page a bit. The licence is CC-BY-3.0, so we also include a mention of Font Awesome and its URL in the source code. \n\nIf you\u2019d like something a little more distinctive, Shifticons lets you pay a few cents for individual icons, with the bonus that you only have to serve the icons you actually use, which is more efficient. Its icons are also friendly to screen readers, but won\u2019t work in IE7. \n\n6. CSS3\n\nThe next thing you could do is add some CSS3 goodness. It can really help the key elements of the site stand out. \n\nIf you are pressed for time, just adding box-shadow and text-shadow to emphasize headings and standouts can be useful: \n\nh1 { \n    text-shadow: 1px 1px 1px #ccc;\n}\n.div-that-you want-to-stand-out { \n    box-shadow: 0 0 1em 1em #ccc;\n}\n\nWe have a little more time though, so we\u2019re going to do something more subtle. We\u2019ll add a radial gradient behind the main heading, using an online gradient editor. \n\nThe output is hefty, but you can see it in the CSS. Note that we also need to add the following to our HTML, for IE9 support: \n\n<!--[if gte IE 9]>\n  <style type=\"text/css\">\n    .gradient {\n       filter: none;\n    }\n  </style>\n<![endif]-->\n\nAnd the effect \u2013 I don\u2019t know what a designer would think, but I like the way it makes the heading pop.\n\n\n\nFor a crash course in useful modern CSS effects, I highly recommend CodeSchool\u2019s online course in Functional HTM5 and CSS3. It costs money ($25 a month to subscribe), but it\u2019s worth it for the time you\u2019ll save. As a bonus, you also get access to some excellent JavaScript, Ruby and GitHub courses. \n\n(Incidentally, if you find yourself fighting with basic float and display attributes in CSS \u2013 and there\u2019s no shame in it, CSS layout is not intuitive \u2013 I recommend the CSS Cross-Country course at CodeSchool.)\n\n7. Add a twist\n\nWe could leave it there, but we\u2019re going to add a background image, and give the site some personality. \n\nThis is the area of design that I think many programmers find most intimidating. How do we create the graphics and photographs that a designer would use? The answer is iStockPhoto and its competitors \u2013 online image libraries where you can find and pay for images. They won\u2019t be unique, but for our purposes, that\u2019s fine. \n\nWe\u2019re going to use a Christmassy image. For a twist, we\u2019re going to use Backstretch to make it responsive. \n\nWe must pay for the image, then download it to our /img/ directory. Then, we set it as our <body>\u2019s background-image, by including a JavaScript file with just the following line: \n\n$.backstretch(\"/img/winter.jpg\");\n\nWe also reset the subtle pattern to become the background for our container image. It would look much better transparent, so we can use this technique in GIMP to make it see-through:\n\n.container-narrow {\n    background: url(/img/cream_dust_transparent.png) repeat 0 0;\n}\n\nWe also fiddle with the padding on body and .container-narrow a bit, and this is the result: \n\n\n\n(Aside: If this were a real site, I\u2019d want to buy images in multiple sizes and ensure that Backstretch chose the most appropriately sized image for our screen, perhaps using responsive images.)\n\nHow to find the effects that make a site interesting? I keep a set of bookmarks for interesting JavaScript and CSS effects I might want to use someday, from realistic shadows to animating grids. The JavaScript Weekly newsletter is a great source of ideas. \n\n8. Colour schemes\n\nWe\u2019re just about getting there \u2013 though we\u2019re probably past half an hour now \u2013 but that button and that menu still both look awfully Bootstrappy. \n\nReal sites, with real designers, have a colour palette, carefully chosen to harmonize and match the brand profile. For our purposes, we\u2019re just going to borrow some colours from the image. We use Gimp\u2019s colour picker tool to identify the hex values of the blue of the snow. Then we can use Color Scheme Designer to find contrasting, but complementary, colours. \n\nFinally, we use those colours for our central button. There are lots of tools to help us do this, such as Bootstrap Buttons. The new HTML is quite long, so I won\u2019t paste it all here, but you can find it in the CSS file. \n\nWe also reset the colour of the pills in the navigation menu, which is a bit easier: \n\n.nav-pills > .active > a, .nav-pills > .active > a:hover {\n    background-color: #FF9473;\n}\n\nI\u2019m not sure if the result is great to be honest, but at least we\u2019ve lost those Bootstrap-blue buttons:\n\n\n\nAnother way to do it, if you didn\u2019t have an image to match, would be to borrow an attractive colour scheme. Colourlovers is a community where people create and share ready-made colour palettes. \n\nThe key thing is to find a palette with an open licence, so you can legitimately use it. Unfortunately, you can\u2019t search for palettes by licence type, but many do have open licences. Here\u2019s a popular palette with a CC-BY-SA licence that allows reuse with attribution.  \n\nAs above, you can use the hex values from the palette in your custom CSS, and bask in the newly colourful results.\n\n9. Read on\n\nWith the above techniques, you can make a site that is starting to look slightly more professional, pretty quickly. \n\nIf you have the time to invest, it\u2019s well worth learning some design principles, if only so that design seems less intimidating and more like fun. As part of my design learning, I read a few introductory design books aimed at coders. The best I found was David Kadavy\u2019s Design for Hackers: Reverse-Engineering Beauty, which explains the basic principles behind choosing colours, fonts, typefaces and layout.\n\nIn the introduction to his book, David writes: \n\n\n\tNo group stands to gain more from design literacy than hackers do\u2026 The one subject that is exceedingly frustrating for hackers to try to learn is design. Hackers know that in order to compete against corporate behemoths with just a few lines of code, they need to have good, clear design, but the resources with which to learn design are simply hard to find.\n\n\nWell said. If you have half a day to invest, rather than half an hour, I recommend getting hold of David\u2019s book.\n\nAnd the journey is over. Perhaps that took slightly more than half an hour, but with practice, using the above techniques can become second nature. What useful tools have I missed? Designers, how would you improve on the above? I would love to know, so please give me your views in the comments.", "year": "2012", "author": "Anna Powell-Smith", "author_slug": "annapowellsmith", "published": "2012-12-16T00:00:00+00:00", "url": "https://24ways.org/2012/how-to-make-your-site-look-half-decent/", "topic": "design"}
{"rowid": 254, "title": "What I Learned in Six Years at GDS", "contents": "When I joined the Government Digital Service in April 2012, GOV.UK was just going into public beta. GDS was a completely new organisation, part of the Cabinet Office, with a mission to stop wasting government money on over-complicated and underperforming big IT projects and instead deliver simple, useful services for the public.\nLots of people who were experts in their fields were drawn in by this inspiring mission, and I learned loads from working with some true leaders. Here are three of the main things I learned.\n1. What is the user need?\n\u2028The main discipline I learned from my time at GDS was to always ask \u2018what is the user need?\u2019 It\u2019s very easy to build something that seems like a good idea, but until you\u2019ve identified what problem you are solving for the user, you can\u2019t be sure that you are building something that is going to help solve an actual problem.\nA really good example of this is GOV.UK Notify. This service was originally conceived of as a status tracker; a \u201cwhere\u2019s my stuff\u201d for government services. For example, if you apply for a passport online, it can take up to six weeks to arrive. After a few weeks, you might feel anxious and phone the Home Office to ask what\u2019s happening. The idea of the status tracker was to allow you to get this information online, saving your time and saving government money on call centres.\nThe project started, as all GDS projects do, with a discovery. The main purpose of a discovery is to identify the users\u2019 needs. At the end of this discovery, the team realised that a status tracker wasn\u2019t the way to address the problem. As they wrote in this blog post: \n\nStatus tracking tools are often just \u2018channel shift\u2019 for anxiety. They solve the symptom and not the problem. They do make it more convenient for people to reduce their anxiety, but they still require them to get anxious enough to request an update in the first place.\n\nWhat would actually address the user need would be to give you the information before you get anxious about where your passport is. For example, when your application is received, email you to let you know when to expect it, and perhaps text you at various points in the process to let you know how it\u2019s going. So instead of a status tracker, the team built GOV.UK Notify, to make it easy for government services to incorporate text, email and even letter notifications into their processes.\nMaking sure you know your user\nAt GDS user needs were taken very seriously. We had a user research lab on site and everyone was required to spend two hours observing user research every six weeks. Ideally you\u2019d observe users working with things you\u2019d built, but even if they weren\u2019t, it was an incredibly valuable experience, and something you should seek out if you are able to.\nEven if we think we understand our users very well, it is very enlightening to see how users actually use your stuff. Partly because in technology we tend to be power users and the average user doesn\u2019t use technology the same way we do. But even if you are building things for other developers, someone who is unfamiliar with it will interact with it in a way that may be very different to what you have envisaged.\nUser needs is not just about building things\nAsking the question \u201cwhat is the user need?\u201d really helps focus on why you are doing what you are doing. It keeps things on track, and helps the team think about what the actual desired end goal is (and should be). \nThinking about user needs has helped me with lots of things, not just building services. For example, you are raising a pull request. What\u2019s the user need? The reviewer needs to be able to easily understand what the change you are proposing is, why you are proposing that change and any areas you need particular help on with the review. \nOr you are writing an email to a colleague. What\u2019s the user need? What are you hoping the reader will learn, understand or do as a result of your email?\n2. Make things open: it makes things better\nThe second important thing I learned at GDS was \u2018make things open: it makes things better\u2019. This works on many levels: being open about your strategy, blogging about what you are doing and what you\u2019ve learned (including mistakes), and \u2013 the part that I got most involved in \u2013 coding in the open.\nTalking about your work helps clarify it\nOne thing we did really well at GDS was blogging \u2013 a lot \u2013 about what we were working on. Blogging about what you are working on is is really valuable for the writer because it forces you to think logically about what you are doing in order to tell a good story. If you are blogging about upcoming work, it makes you think clearly about why you\u2019re doing it; and it also means that people can comment on the blog post. Often people had really useful suggestions or clarifying questions.\nIt\u2019s also really valuable to blog about what you\u2019ve learned, especially if you\u2019ve made a mistake. It makes sure you\u2019ve learned the lesson and helps others avoid making the same mistakes. As well as blogging about lessons learned, GOV.UK also publishes incident reports when there is an outage or service degradation. Being open about things like this really engenders an atmosphere of trust and safe learning; which helps make things better.\nCoding in the open has a lot of benefits\nIn my last year at GDS I was the Open Source Lead, and one of the things I focused on was the requirement that all new government source code should be open. From the start, GDS coded in the open (the GitHub organisation still has the non-intuitive name alphagov, because it was created by the team doing the original Alpha of GOV.UK, before GDS was even formed).\nWhen I first joined GDS I was a little nervous about the fact that anyone could see my code. I worried about people seeing my mistakes, or receiving critical code reviews. (Setting people\u2019s mind at rest about these things is why it\u2019s crucial to have good standards around communication and positive behaviour - even a critical code review should be considerately given). \nBut I quickly realised there were huge advantages to coding in the open. In the same way as blogging your decisions makes you think carefully about whether they are good ones and what evidence you have, the fact that anyone in the world could see your code (even if, in practice, they probably won\u2019t be looking) makes everyone raise their game slightly. The very fact that you know it\u2019s open, makes you make it a bit better.\nIt helps with lots of other things as well, for example it makes it easier to collaborate with people and share your work. And now that I\u2019ve left GDS, it\u2019s so useful to be able to look back at code I worked on to remember how things worked.\nShare what you learn\nIt\u2019s sometimes hard to know where to start with being open about things, but it gets easier and becomes more natural as you practice. It helps you clarify your thoughts and follow through on what you\u2019ve decided to do. Working at GDS when this was a very important principle really helped me learn how to do this well.\n3. Do the hard work to make it simple (tech edition)\n\u2018Start with user needs\u2019 and \u2018Make things open: it makes things better\u2019 are two of the excellent government design principles. They are all good, but the third thing that I want to talk about is number 4: \u2018Do the hard work to make it simple\u2019, and specifically, how this manifests itself in the way we build technology.\nAt GDS, we worked very hard to do the hard work to make the code, systems and technology we built simple for those who came after us. For example, writing good commit messages is taken very seriously. There is commit message guidance, and it was not unusual for a pull request review to ask for a commit message to be rewritten to make a commit message clearer.\nWe worked very hard on making pull requests good, keeping the reviewer in mind and making it clear to the user how best to review it.\nReviewing others\u2019 pull requests is the highest priority so that no-one is blocked, and teams have screens showing the status of open pull requests (using fourth wall) and we even had a \u2018pull request seal\u2019, a bot that publishes pull requests to Slack and gets angry if they are uncommented on for more than two days.\nMaking it easier for developers to support the site\nAnother example of doing the hard work to make it simple was the opsmanual. I spent two years on the web operations team on GOV.UK, and one of the things I loved about that team was the huge efforts everyone went to to be open and inclusive to developers.\nThe team had some people who were really expert in web ops, but they were all incredibly helpful when bringing me on board as a developer with no previous experience of web ops, and also patiently explaining things whenever other devs in similar positions came with questions. \nThe main artefact of this was the opsmanual, which contained write-ups of how to do lots of things. One of the best things was that every alert that might lead to someone being woken up in the middle of the night had a link to documentation on the opsmanual which detailed what the alert meant and some suggested actions that could be taken to address it.\nThis was important because most of the devs on GOV.UK were on the on-call rota, so if they were woken at 3am by an alert they\u2019d never seen before, the opsmanual information might give them everything they needed to solve it, without the years of web ops training and the deep familiarity with the GOV.UK infrastructure that came with working on it every day.\nDevelopers are users too\nDoing the hard work to make it simple means that users can do what they need to do, and this applies even when the users are your developer peers. At GDS I really learned how to focus on simplicity for the user, and how much better this makes things work.\nThese three principles help us make great things\nI learned so much more in my six years at GDS. For example, the civil service has a very fair way of interviewing. I learned about the importance of good comms, working late, responsibly and the value of content design.\nAnd the real heart of what I learned, the guiding principles that help us deliver great products, is encapsulated by the three things I\u2019ve talked about here: think about the user need, make things open, and do the hard work to make it simple.", "year": "2018", "author": "Anna Shipman", "author_slug": "annashipman", "published": "2018-12-08T00:00:00+00:00", "url": "https://24ways.org/2018/what-i-learned-in-six-years-at-gds/", "topic": "business"}
{"rowid": 292, "title": "Watch Your Language!", "contents": "I\u2019m bilingual. My first language is French. I learned English in my early 20s. Learning a new language later in life meant that I was able to observe my thought processes changing over time. It made me realize that some concepts can\u2019t be expressed in some languages, while other languages express these concepts with ease.\nIt also helped me understand the way we label languages. English: business. French: romance. Here\u2019s an example of how words, or the absence thereof, can affect the way we think:\nIn French we love everything. There\u2019s no straightforward way to say we like something, so we just end up loving everything. I love my sisters, I love broccoli, I love programming, I love my partner, I love doing laundry (this is a lie), I love my mom (this is not a lie). I love, I love, I love. It\u2019s no wonder French is considered romantic. When I first learned English I used the word love rather than like because I hadn\u2019t grasped the difference. Needless to say, I\u2019ve scared away plenty of first dates!\nLearning another language made me realize the limitations of my native language and revealed concepts I didn\u2019t know existed. Without the nuances a given language provides, we fail to express what we really think. The absence of words in our vocabulary gets in the way of effectively communicating and considering ideas.\nWhen I lived in Montr\u00e9al, most people in my circle spoke both French and English. I could switch between them when I could more easily express an idea in one language or the other. I liked (or should I say loved?) those conversations. They were meaningful. They were efficient.\n\nI\u2019m quadrilingual. I code in Ruby, HTML/CSS, JavaScript, Python. In the past couple of years I have been lucky enough to write code in these languages at a massive scale. In learning Ruby, much like learning English, I discovered the strengths and limitations of not only the languages I knew but the language I was learning. It taught me to choose the right tool for the job.\nWhen I started working at Shopify, making a change to a view involved copy/pasting HTML and ERB from one view to another. The CSS was roughly structured into modules, but those modules were not responsive to different screen sizes. Our HTML was complete mayhem, and we didn\u2019t consider accessibility. All this made editing views a laborious process.\nGrep. Replace all. Test. Ship it. Repeat.\nThis wasn\u2019t sustainable at Shopify\u2019s scale, so the newly-formed front end team was given two missions:\n\nMake the app responsive (AKA Let\u2019s Make This Thing Responsive ASAP)\nMake the view layer scalable and maintainable (AKA Let\u2019s Build a Pattern Library\u2026 in Ruby)\n\nLet\u2019s make this thing responsive ASAP\nThe year was 2015. The Shopify admin wasn\u2019t mobile friendly. Our browser support was set to IE10. We had the wind in our sails. We wanted to achieve complete responsiveness in the shortest amount of time. Our answer: container queries.\nIt seemed like the obvious decision at the time. We would be able to set rules for each component in isolation and the component would know how to lay itself out on the page regardless of where it was rendered. It would save us a ton of development time since we wouldn\u2019t need to change our markup, it would scale well, and we would achieve complete component autonomy by not having to worry about page layout. By siloing our components, we were going to unlock the ultimate goal of componentization, cutting the tie to external dependencies. We were cool.\nWriting the JavaScript handling container queries was my first contribution to Shopify. It was a satisfying project to work on. We could drop our components in anywhere and they would magically look good. It took us less than a couple weeks to push this to production and make our app mostly responsive.\nBut with time, it became increasingly obvious that this was not as performant as we had hoped. It wasn\u2019t performant at all. Components would jarringly jump around the page before settling in on first paint.\nIt was only when we started using the flex-wrap: wrap CSS property to build new components that we realized we were not using the right language for the job. So we swapped out JavaScript container queries for CSS flex-wrapping. Even though flex wasn\u2019t yet as powerful as we wanted it to be, it was still a good compromise. Our components stayed independent of the window size but took much less time to render. Best of all: they used CSS instead of relying on JavaScript for layout.\nIn other words: we were using the wrong language to express our layout to the browser, when another language could do it much more simply and elegantly.\nLet\u2019s build a pattern library\u2026 in Ruby\nIn order to make our view layer maintainable, we chose to build a comprehensive library of helpers. This library would generate our markup from a single source of truth, allowing us to make changes system-wide, in one place. No. More. Grepping.\nWhen I joined Shopify it was a Rails shop freshly wounded by a JavaScript framework (See: Batman.js). JavaScript was like Voldemort, the language that could not be named. Because of this baggage, the only way for us to build a pattern library that would get buyin from our developers was to use Rails view helpers. And for many reasons using Ruby was the right choice for us. The time spent ramping developers up on the new UI Components would be negligible since the Ruby API felt familiar. The transition would be simple since we didn\u2019t have to introduce any new technology to the stack. The components would be fast since they would be rendered on the server. We had a plan.\nWe put in place a set of Rails tools to make it easy to build components, then wrote a bunch of sweet, sweet components using our shiny new tools. To document our design, content and front end patterns we put together an interactive styleguide to demonstrate how every component works. Our research and development department loved it (and still do)! We continue to roll out new components, and generally the project has been successful, though it has had its drawbacks.\nSince the Shopify admin is mostly made up of a huge number of forms, most of the content is static. For this reason, using server-rendered components didn\u2019t seem like a problem at the time. With new app features increasing the amount of DOM manipulation needed on the client side, our early design decisions mean making requests to the server for each re-paint. This isn\u2019t going to cut it.\nI don\u2019t know the end of this story, because we haven\u2019t written it yet. We\u2019ve been exploring alternatives to our current system to facilitate the rendering of our components on the client, including React, Vue.js, and Web Components, but we haven\u2019t determined the winner yet. Only time (and data gathering) will tell.\nRuby is great but it doesn\u2019t speak the browser\u2019s language efficiently. It was not the right language for the job.\n\nLearning a new spoken language has had an impact on how I write code. It has taught me that you don\u2019t know what you don\u2019t know until you have the language to express it. Understanding the strengths and limitations of any programming language is fundamental to making good design decisions. At the end of the day, you make the best choices with the information you have. But if you still feel like you\u2019re unable to express your thoughts to the fullest with what you know, it might be time to learn a new language.", "year": "2016", "author": "Annie-Claude C\u00f4t\u00e9", "author_slug": "annieclaudecote", "published": "2016-12-10T00:00:00+00:00", "url": "https://24ways.org/2016/watch-your-language/", "topic": "code"}
{"rowid": 152, "title": "CSS for Accessibility", "contents": "CSS is magical stuff. In the right hands, it can transform the plainest of (well-structured) documents into a visual feast. But it\u2019s not all fur coat and nae knickers (as my granny used to say). Here are some simple ways you can use CSS to improve the usability and accessibility of your site. \n\nEven better, no sexy visuals will be harmed by the use of these techniques. Promise.\n\nNae knickers\n\nThis is less of an accessibility tip, and more of a reminder to check that you\u2019ve got your body background colour specified.\n\nIf you\u2019re sitting there wondering why I\u2019m mentioning this, because it\u2019s a really basic thing, then you might be as surprised as I was to discover that from a sample of over 200 sites checked last year, 35% of UK local authority websites were missing their body background colour.\n\nForgetting to specify your body background colour can lead to embarrassing gaps in coverage, which are not only unsightly, but can prevent your users reading the text on your site if they use a different operating system colour scheme.\n\nAll it needs is the following line to be added to your CSS file:\n\nbody {background-color: #fff;}\n\nIf you pair it with \n\ncolor: #000;\n\n\u2026 you\u2019ll be assured of maintaining contrast for any areas you inadvertently forget to specify, no matter what colour scheme your user needs or prefers.\n\nEven better, if you\u2019ve got standard reset CSS you use, make sure that default colours for background and text are specified in it, so you\u2019ll never be caught with your pants down. At the very least, you\u2019ll have a white background and black text that\u2019ll prompt you to change them to your chosen colours.\n\nElbow room\n\nPaying attention to your typography is important, but it\u2019s not just about making it look nice. \n\nCareful use of the line-height property can make your text more readable, which helps everyone, but is particularly helpful for those with dyslexia, who use screen magnification or simply find it uncomfortable to read lots of text online. \n\nWhen lines of text are too close together, it can cause the eye to skip down lines when reading, making it difficult to keep track of what you\u2019re reading across. \n\nSo, a bit of room is good.\n\nThat said, when lines of text are too far apart, it can be just as bad, because the eye has to jump to find the next line. That not only breaks up the reading rhythm, but can make it much more difficult for those using Screen Magnification (especially at high levels of magnification) to find the beginning of the next line which follows on from the end of the line they\u2019ve just read.\n\nUsing a line height of between 1.2 and 1.6 times normal can improve readability, and using unit-less line heights help take care of any pesky browser calculation problems.\n\nFor example: \n\np {\n\tfont-family: \"Lucida Grande\", Lucida, Verdana, Helvetica, sans-serif;\n\tfont-size: 1em;\n\tline-height: 1.3;\n}\n\nor if you want to use the shorthand version:\n\np {\n\tfont: 1em/1.3 \"Lucida Grande\", Lucida, Verdana, Helvetica, sans-serif;\n}\n\nView some examples of different line-heights, based on default text size of 100%/1em.\n\nFurther reading on Unitless line-heights from Eric Meyer.\n\nTransformers: Initial case in disguise\n\nNobody wants to shout at their users, but there are some occasions when you might legitimately want to use uppercase on your site.\n\nAvoid screen-reader pronunciation weirdness (where, for example, CONTACT US would be read out as Contact U S, which is not the same thing \u2013 unless you really are offering your users the chance to contact the United States) caused by using uppercase by using title case for your text and using the often neglected text-transform property to fake uppercase.\n\nFor example:\n\n.uppercase {\n\ttext-transform: uppercase\n}    \n\nDon\u2019t overdo it though, as uppercase text is harder to read than normal text, not to mention the whole SHOUTING thing.\n\nLinky love\n\nWhen it comes to accessibility, keyboard only users (which includes those who use voice recognition software) who can see just fine are often forgotten about in favour of screen reader users.\n\nThis Christmas, share the accessibility love and light up those links so all of your users can easily find their way around your site.\n\nThe link outline\n\nAKA: the focus ring, or that dotted box that goes around links to show users where they are on the site.\n\nThe techniques below are intended to supplement this, not take the place of it. You may think it\u2019s ugly and want to get rid of it, especially since you\u2019re going to the effort of tarting up your links.\n\nDon\u2019t. \n\nJust don\u2019t.\n\nThe non-underlined underline\n\nIf you listen to Jacob Nielsen, every link on your site should be underlined so users know it\u2019s a link.\n\nYou might disagree with him on this (I know I do), but if you are choosing to go with underlined links, in whatever state, then remove the default underline and replacing it with a border that\u2019s a couple of pixels away from the text. \n\nThe underline is still there, but it\u2019s no longer cutting off the bottom of letters with descenders (e.g., g and y) which makes it easier to read.\n\nThis is illustrated in Examples 1 and 2.\n\nYou can modify the three lines of code below to suit your own colour and border style preferences, and add it to whichever link state you like.\n\ntext-decoration: none;\nborder-bottom: 1px #000 solid;\npadding-bottom: 2px;\n\nStanding out from the crowd\n\nWhatever way you choose to do it, you should be making sure your links stand out from the crowd of normal text which surrounds them when in their default state, and especially in their hover or focus states.\n\nA good way of doing this is to reverse the colours when on hover or focus.\n\nWell-focused\n\nEveryone knows that you can use the :hover pseudo class to change the look of a link when you mouse over it, but, somewhat ironically, people who can see and use a mouse are the group who least need this extra visual clue, since the cursor handily (sorry) changes from an arrow to a hand.\n\nSo spare a thought for the non-pointing device users that visit your site and take the time to duplicate that hover look by using the :focus pseudo class.\n\nOf course, the internets being what they are, it\u2019s not quite that simple, and predictably, Internet Explorer is the culprit once more with it\u2019s frustrating lack of support for :focus. Instead it applies the :active pseudo class whenever an anchor has focus.\n\nWhat this means in practice is that if you want to make your links change on focus as well as on hover, you need to specify focus, hover and active.\n\nEven better, since the look and feel necessarily has to be the same for the last three states, you can combine them into one rule.\n\nSo if you wanted to do a simple reverse of colours for a link, and put it together with the non-underline underlines from before, the code might look like this:\n\na:link {\n\tbackground: #fff;\n\tcolor: #000;\n\tfont-weight: bold;\n\ttext-decoration: none; \n\tborder-bottom: 1px #000 solid; \n\tpadding-bottom: 2px;\n}\na:visited {\n\tbackground: #fff;\n\tcolor: #800080;\n\tfont-weight: bold;\n\ttext-decoration: none; \n\tborder-bottom: 1px #000 solid; \n\tpadding-bottom: 2px;\n}\na:focus, a:hover, a:active {\n\tbackground: #000;\n\tcolor: #fff;\n\tfont-weight: bold;\n\ttext-decoration: none; \n\tborder-bottom: 1px #000 solid; \n\tpadding-bottom: 2px;\n}\n\nExample 3 shows what this looks like in practice.\n\nLocation, Location, Location\n\nTo take this example to it\u2019s natural conclusion, you can add an id of current (or something similar) in appropriate places in your navigation, specify a full set of link styles for current, and have a navigation which, at a glance, lets users know which page or section they\u2019re currently in.\n\nExample navigation using location indicators.\n\nand the source code\n\nConclusion\n\nAll the examples here are intended to illustrate the concepts, and should not be taken as the absolute best way to format links or style navigation bars \u2013 that\u2019s up to you and whatever visual design you\u2019re using at the time.\n\nThey\u2019re also not the only things you should be doing to make your site accessible. \n\nAbove all, remember that accessibility is for life, not just for Christmas.", "year": "2007", "author": "Ann McMeekin", "author_slug": "annmcmeekin", "published": "2007-12-13T00:00:00+00:00", "url": "https://24ways.org/2007/css-for-accessibility/", "topic": "design"}
{"rowid": 2, "title": "Levelling Up", "contents": "Hello, 24 ways. I\u2019m Ashley and I sell property insurance. I\u2019m interrupting your Christmas countdown with an article about rental property software and a guy, Pete, who selflessly encouraged me to build my first web app. It doesn\u2019t sound at all festive, or \u2014 considering I\u2019ve used both \u201cinsurance\u201d and \u201crental property\u201d \u2014 interesting, but do stick with me. There\u2019s eggnog at the end.\n\nI run a property insurance business, Brokers Direct. It\u2019s a small operation, but well established. We\u2019ve been selling landlord insurance on the web for over thirteen years, for twelve of which we have provided our clients with third-party software for managing their rental property portfolios. Free. Of. Charge.\n\nIt sounds like a sweet deal for our customers, but it isn\u2019t. At least, not any more. The third-party software is victim to years of neglect by its vendor. Its questionable interface, garish visuals and, ahem, clip art icons have suffered from a lack of updates. While it was never a contender for software of the year, I\u2019ve steadily grown too embarrassed to associate my business with it.\n\n The third-party rental property software we distributed\n\nI wanted to offer my customers a simple, clean and lightweight alternative. In an industry that\u2019s dominated by dated and bloated software, it seemed only logical that I should build my own rental property tool.\n\nThe long learning-to-code slog\n\nLearning a programming language is daunting, the source of my frustration stemming from a non-programming background. Generally, tutorials assume a degree of familiarity with programming, whether it be tools, conventions or basic skills. I had none and, at the time, there was nothing on the web really geared towards a novice. I reached the point where I genuinely thought I was just not cut out for coding. Surrendering to my feelings of self-doubt and frustration, I sourced a local Rails developer, Pete, to build it for me.\n\nPete brought a pack of index cards to our meeting. Index cards that would represent each feature the rental property software would launch with.\n\n \n\n\u201cOK,\u201d he began. \u201cWe\u2019ll need a user model, tenant model, authentication, tenant and property relationships\u2026\u201d A dozen index cards with a dozen features lined the coffee table in a grid-like format. Logical, comprehensible, achievable. Seeing the app laid out in a digestible manner made it seem surmountable. Maybe I could do this.\n\n\u201cI\u2019ve been trying to learn Rails\u2026\u201d, I piped up.\n\nI don\u2019t know why I said it. I was fully prepared to hire Pete to do the hard work for me. But Pete, unprompted, gathered the index cards and neatly stacked them together, coasting them across the table towards me. \u201cYou should build this\u201d.\n\nPete, a full-time freelance developer at the time, was turning down a paying job in favour of encouraging me to learn to code. Looking back, I didn\u2019t realise how significant this moment was.\n\nThat evening, I took Pete\u2019s index cards home to make a start on my app, slowly evolving each of the cards into a working feature. Building the app solo, I turned to Stack Overflow to solve the inevitable coding hurdles I encountered, as well as calling on a supportive Rails community. Whether they provided direct solutions to my programming woes, or simply planted a seed on how to solve a problem, I kept coding. Many months later, and after several more doubtful moments, Lodger was born.\n\n Property overview of my app, Lodger.\n\nIf I can do it, so can you\n\nI misspent a lot of time building Twitter and blogging applications (apparently, all Rails tutorials centre around Twitter and blogging). If I could rewind and impart some advice to myself, this is what I\u2019d say.\n\nThere\u2019s no magic formula\n\n\u201cI haven\u2019t quite grasped Rails routing. I should tackle another tutorial.\u201d \n\nMaking excuses \u2014 or procrastination \u2014 is something we are all guilty of. I was waiting for a programming book that would magically deposit a grasp of the entire Ruby syntax in my head. I kept buying books thinking each one would be the one where it all clicked. I now have a bookshelf full of Ruby material, all of which I\u2019ve barely read, and none of which got me any closer to launching my web app. Put simply, there\u2019s no magic formula.\n\nBreak it down\n\nWhatever it is you want to build, break it down into digestible chunks. Taking Pete\u2019s method as an example, having an index card represent an individual feature helped me tremendously. Tackle one at a time. Even if each feature takes you a month to build, and you have eight features to launch with, after eight months you\u2019ll have your MVP. Remember, if you do nothing each day, it adds up to nothing.\n\nHave a tangible product to build\n\nI have a wonderful habit of writing down personal notes, usually to express my feelings at the time or to log an idea, only to uncover them months or years down the line, long after I forgot I had written them. I made a timely discovery while writing this article, discovering this gem while flicking through a battered Moleskine:\n\n\n\t\u201cI don\u2019t seem to be making good progress with learning Rails, but development still excites me. I should maybe stop doing tutorials and work towards building a specific app.\u201d\n\n\nHaving a real product to work on, like I did with Lodger, means you have something tangible to apply the techniques you are learning. I found this prevented me from flitting aimlessly between tutorials and books, which is an easy area to accidentally remain in.\n\nTeam up\n\nIf possible, team up with a designer and create something together. Designers are great at presenting features in a way you\u2019d never have considered. You will learn a lot from making their designs come to life.\n\nYour homework for the holiday\n\nDespite having a web app under my belt, I am not a programmer. I tinker with code, piecing enough bits of it together to make something functional. And that\u2019s OK! I\u2019m not excusing sloppiness, but if we aimed for perfection every time, we\u2019d never execute any of our ideas.\n\nAs the holidays approach and you\u2019ve exhausted yet another viewing of The Muppet Christmas Carol (or is that just my guilty pleasure at Christmas?), you may have time on your hands. Time to explore an idea you\u2019ve been sitting on, but \u2014 plagued with procrastination and doubt \u2014 have yet to bring to life. This holiday, I am here to say to you what Pete said to me.\n\nYou should build this.\n\nYou don\u2019t need to be the next Mark Zuckerberg or Larry Page. You just have to learn enough to get it done.\n\nPS: I lied about the eggnogg, but try capturing somebody\u2019s attention when you tell them you sell property insurance!", "year": "2013", "author": "Ashley Baxter", "author_slug": "ashleybaxter", "published": "2013-12-06T00:00:00+00:00", "url": "https://24ways.org/2013/levelling-up/", "topic": "business"}
{"rowid": 272, "title": "Crafting the Front-end", "contents": "Much has been spoken and written recently about the virtues of craftsmanship in the context of web design and development. It seems that we as fabricators of the web are finally tiring of seeking out parallels between ourselves and architects, and are turning instead to the fabled specialist artisans.\n\nIdentifying oneself as a craftsman or craftswoman (let\u2019s just say craftsperson from here onward) will likely be a trend of early 2012. In this pre-emptive strike, I\u2019d like to expound on this movement as I feel it pertains to front-end development, and encourage care and understanding of the true qualities of craftsmanship (craftspersonship).\n\nThe core values\n\nI\u2019ll begin by defining craftspersonship. What distinguishes a craftsperson from a technician? Dictionaries tend to define a craftsperson as one who possesses great skill in a chosen field. The badge of a craftsperson for me, though, is a very special label that should be revered and used sparingly, only where it is truly deserved. A genuine craftsperson encompasses a few other key traits, far beyond raw skill, each of which must be learned and mastered.\n\nA craftsperson has: \n\n\n\tAn appreciation of good work, in both the work of others and their own. And not just good as in \u2018hey, that\u2019s pretty neat\u2019, I mean a goodness like a shining purity \u2013 the kind of good that feels right when you see it.\n\tA belief in quality at every level: every facet of the craftsperson\u2019s product is as crucial as any other, without exception, even those normally hidden from view.\n\tVision: an ability to visualize their path ahead, pre-empting the obstacles that may be encountered to plan a route around them.\n\tA preference for simplicity: an almost Bauhausesque devotion to undecorated functionality, with no unjustifiable parts included.\n\tSincerity: producing work that speaks directly to its purpose with flawless clarity.\n\n\nOnly when you become a custodian of such values in your work can you consider calling yourself a craftsperson. Now let\u2019s take a look at some steps we front-end developers can take on our journey of enlightenment toward craftspersonhood.\n\n Speaking of the craftsman\u2019s journey, be sure to watch out for the video of The Standardistas\u2019 stellar talk at the Build 2011 conference titled The Journey, which should be online sometime soon.\n\nBuilding your own toolbox\n\nMy grandfather was a carpenter and trained as a young apprentice under a master. After observing and practising the many foundation theories, principles and techniques of carpentry, he was tasked with creating his own set of woodworking tools, which he would use and maintain throughout his career. By going through the process of having to create his own tools, he would be connected at the most direct level with every piece of wood he touched, his tools being his own creations and extensions of his own skilled hands. The depth of his knowledge of these tools must have surpassed the intricate as he fathered, used, cleaned and repaired them, day in and day out over many years.\n\nAnd so it should be, ideally, with all crafts. We must understand our tools right down to the most fundamental level. I firmly believe that a level of true craftsmanship cannot be reached while there exists a layer that remains not wholly understood between a creator and his canvas. Of course, our tools as front-end developers are somewhat more complex than those of other crafts \u2013 it may seem reasonable to require that a carpenter create his or her own set of chisels, but somewhat less so to ask a front-end developer to code their own CSS preprocessor, or design their own computer.\n\nHowever, it is still vitally important that you understand how your tools work. This is particularly critical when it comes to things like preprocessors, libraries and frameworks which aim to save you time by automating common processes and functions. For the most part, anything that saves you time is a Good Thing\u2122 but it cannot be stressed enough that using tools like these in earnest should be avoided until you understand exactly what they are doing for you (and, to an extent, how they are doing it). \n\nIn particular, you must understand any drawbacks to using your tools, and any shortcuts they may be taking on your behalf. I\u2019m not suggesting that you steer clear of paid work until you\u2019ve studied each of jQuery\u2019s 9,266 lines of JavaScript source code but, all levity aside, it will further you on your journey to look at interesting or relevant bits of jQuery, and any other libraries you might want to use. Such libraries often directly link to corresponding sections of their source code on sites like GitHub from their official documentation. Better yet, they\u2019re almost always written in high level languages (easy to read), so there\u2019s no excuse not to don your pith helmet and go on something of an exploration. Any kind of tangential learning like this will drive you further toward becoming a true craftsperson, so keep an open mind and always be ready to step out of your comfort zone.\n\nDowntime and tool honing\n\nWith any craft, it is essential to keep your tools in good condition, and a good idea to stay up-to-date with the latest equipment. This is especially true on the web, which, as we like to tell anyone who is still awake more than a minute after asking what it is that we do, advances at a phenomenal pace. A tool or technique that could be considered best practice this week might be the subject of haughty derision in a comment thread within six months.\n\nI have little doubt that you already spend a chunk of time each day keeping up with the latest material from our industry\u2019s finest Interblogs and Twittertubes, but do you honestly put aside time to collect bookmarks and code snippets from things you read into a slowly evolving toolbox? At @media in 2009, Simon Collison delivered a candid talk on his \u2018Ultimate Package\u2019. Those of us who didn\u2019t flee the room anticipating a newfound and unwelcome intimacy with the contents of his trousers were shown how he maintained his own toolkit \u2013 a collection of files and folders all set up and ready to go for a new project. By maintaining a toolkit in this way, he has consistency across projects and a dependable base upon which to learn and improve.\n\nThe assembly and maintenance of such a personalized and familiar toolkit is probably as close as we will get to emulating the tool making stage of more traditional craft trades. Keep a master copy of your toolkit somewhere safe, making copies of it for new projects. When you learn of a way in which part of it can be improved, make changes to the master copy.\n\nSimplicity through modularity\n\nI believe that the user interfaces of all web applications should be thought of as being made up primarily of modular components. Modules in this context are patterns in design that appear repeatedly throughout the app. These can be small collections of elements, like a user profile summary box (profile picture, username, meta data), as well as atomic elements such as headings and list items.\n\nWell-crafted front-end architectures have the ability to support this kind of repeating pattern as modules, with as close to no repetition of CSS (or JavaScript) as possible, and as close to no variations in HTML between instances as possible.\n\nOne of the most fundamental and well known tenets of software engineering is the DRY rule \u2013 don\u2019t repeat yourself. It requires that \u201cevery piece of knowledge must have a single, unambiguous, authoritative representation within a system.\u201d \n\nAs craftspeople, we must hold this rule dear and apply it to the modules we have identified in our site designs. The moment you commit a second style definition for a module, the quality of your output (the front-end code) takes a huge hit. There should only ever be one base style definition for each distinct module or component. Keep these in a separate, sacred place in your CSS. I use a _modules.scss Sass include file, imported near the top of my main CSS files.\n\nBe sure, of course, to avoid making changes to this file lightly, as the smallest adjustment can affect multiple pages (hint: keep a structure list of which modules are used on which pages). Avoid the inevitable temptation to duplicate code late in the project. Sticking to this rule becomes more important the more complex the codebase becomes.\n\nIf you can stick to this rule, using sensible class names and consistent HTML, you can reach a joyous, self-fulfilling plateau stage in each project where you are assembling each interface from your own set of carefully crafted building blocks.\n\nOld school markup\n\nLet\u2019s take a step back. Before we fret about creating a divinely pure modular CSS framework, we need to know the site\u2019s design and what it is made of. The best way to gain this knowledge is to go old school. Print out every comp, mockup, wireframe, sketch or whatever you have. If there are sections of pages that are hidden until some user action takes place, or if the page has multiple states, be sure that you have everything that could become visible to the user on paper.\n\nOnce you have your wedge of paper designs, lay out all the pages on the floor, or stick them to the wall if you can, arranging them logically according to the site hierarchy, by user journey, or whatever guidelines make most sense to you. Once you have the site laid out before you, study it for a while, familiarizing yourself with every part of every interface. This will eliminate nasty surprises late in the project when you realize you\u2019ve duplicated something, or left an interface on the drawing board altogether.\n\nNow that you know the site like it\u2019s your best friend, get out your pens or pencils of choice and attack it. Mark it up like there\u2019s no tomorrow. Pretend you\u2019re a spy trying to identify communications from an enemy network hiding their messages in newspapers. Look for patterns and similarities, drawing circles around them. These are your modules. Start also highlighting the differences between each instance of these modules, working out which is the most basic or common type that will become the base definition from which all other representations are extended.\n\nThis simple but empowering exercise will equip you for your task of actually crafting, instead of just building, the front-end. Without the knowledge gained from this kind of research phase, you will be blundering forward, improvising as best you can, but ultimately making quality-compromising mistakes that could have been avoided.\n\nFor more on this theme, read Anna Debenham\u2019s Front-end Style Guides which recommends a similar process, and the sublime idea of extending this into a guide to refer to during development and beyond.\n\nDesign homogeneity\n\nMoving forward again, you now have your modules defined and things are looking good. I mentioned that many instances of these modules will carry minor differences. These differences must be given significant thinking time, and discussion time with your designer(s).\n\nIt should be common knowledge by now that successful software projects are not the product of distinct design and build phases with little or no bidirectional feedback. The crucial nature of the designer-developer relationship has been covered in depth this year by Paul Robert Lloyd, and a joint effort from both teams throughout the project lifecycle is pivotal to your ability to craft and ship successful products.\n\nThis relationship comes into play when you\u2019re well into the development of the site, and you start noticing these differences between instances of modules (they\u2019ll start to stand out very clearly to you and your carefully regimented modular CSS system). Before you start overriding your base styles, question the differences with the designer to work out why they exist. Perhaps they are required and are important to their context, but perhaps they were oversights from earlier design revisions, or simple mistakes.\n\nThe craftsperson\u2019s gland\n\nAs you grow towards the levels of expertise and experience where you can proudly and honestly consider yourself a craftsperson, you will find that you steadily develop what initially feels like a kind of sixth sense. I think of it more as a new hormonal gland, secreting into your bloodstream a powerful messenger chemical that can either reward or punish your brain. This gland is connected directly to your core understanding of what good quality work looks and feels like, an understanding that itself improves with experience. \n\nThis gland will make itself known to you in two ways. First, when you solve a problem in a beautifully elegant way with clean and unobtrusive code that looks good and just feels right, your craftsperson\u2019s gland will ooze something delicious that makes your brain and soul glow from the inside out. You will beam triumphantly at the succinct lines of code on your computer display before bounding outside with a spring in your step to swim up glittering rainbows and kiss soft fluffy puppies.\n\nThe second way that you may become aware of your craftsperson\u2019s gland, though, is somewhat less pleasurable. In an alternate reality, your parallel self is faced with the same problem, but decides to take a shortcut and get around it by some dubious means \u2013 the kind of technical method that the words hack, kludge and bodge are reserved for. As soon as you have done this, or even as you are doing it, your craftsperson\u2019s gland will damn well let you know that you took the wrong fork in the road. As your craftsperson\u2019s gland begins to secrete a toxic pus, you will at first become entranced into a vacant stare at the monstrous mess you are considering unleashing upon your site\u2019s visitors, before writhing in the horrible agony of an itch that can never be scratched, and a feeling of being coated with the devil\u2019s own deep and penetrating filth that no shower will ever cleanse.\n\nPerhaps I exaggerate slightly, but it is no overstatement to suggest that you will find yourself being guided by proverbial angels and demons perched on opposite shoulders, or a whispering voice inside your head. If you harness this sense, sharpening it as if it were another tool in your kit and letting it guide or at least advise your decision making, you will transcend the rocky realm of random trial and error when faced with problems, and tend toward the right answers instinctively.\n\nThis gland can also empower your ability to assess your own work, becoming a judge before whom all your work is cross-examined. A good craftsperson regularly takes a step back from their work, and questions every facet of their product for its precise alignment with their core values of quality and sincerity, and even the very necessity of each component.\n\nThe wrapping\n\nBy now, you may be thinking that I take this kind of thing far too seriously, but to terrify you further, I haven\u2019t even shared the half of it. Hopefully, though, this gives you an idea of the kind of levels of professionalism and dedication that it should take to get you on your way to becoming a craftsperson. It\u2019s a level of accomplishment and ability toward which we all should strive, both for our personal fulfilment and the betterment of the products we use daily. I look forward to seeing your finely crafted work throughout 2012.", "year": "2011", "author": "Ben Bodien", "author_slug": "benbodien", "published": "2011-12-24T00:00:00+00:00", "url": "https://24ways.org/2011/crafting-the-front-end/", "topic": "process"}
{"rowid": 209, "title": "Feeding the Audio Graph", "contents": "In 2004, I was given an iPod.\nI count this as one of the most intuitive pieces of technology I\u2019ve ever owned.  It wasn\u2019t because of the the snazzy (colour!) menus or circular touchpad.  I loved how smoothly it fitted into my life. I could plug in my headphones and listen to music while I was walking around town.  Then when I got home, I could plug it into an amplifier and carry on listening there.\nThere was no faff. It didn\u2019t matter if I could find my favourite mix tape, or if my WiFi was flakey - it was all just there.\nNowadays, when I\u2019m trying to pair my phone with some Bluetooth speakers, or can\u2019t find my USB-to-headphone jack, or even access any music because I don\u2019t have cellular reception; I really miss this simplicity.\nThe Web Audio API\nI think the Web Audio API feels kind of like my iPod did.\nIt\u2019s different from most browser APIs - rather than throwing around data, or updating DOM elements - you plug together a graph of audio nodes, which the browser uses to generate, process, and play sounds.\nThe thing I like about it is that you can totally plug it into whatever you want, and it\u2019ll mostly just work.\nSo, let\u2019s get started. First of all we want an audio source.\n<audio src=\"night-owl.mp3\" controls />\n\n(Song - Night Owl by Broke For Free)\nThis totally works. However, it\u2019s not using the Web Audio API, so we can\u2019t access or modify the sound it makes.\nTo hook this up to our audio graph, we can use an AudioSourceNode.  This captures the sound from the element, and lets us connect to other nodes in a graph.\nconst audioCtx = new AudioContext()\n\nconst audio = document.querySelector('audio')\nconst input = audioCtx.createAudioSourceNode(audio)\n\ninput.connect(audioCtx.destination)\n\nGreat. We\u2019ve made something that looks and sounds exactly the same as it did before. Go us.\nGain\nLet\u2019s plug in a GainNode - this allows you to alter the amplitude (volume) of an an audio stream.\nWe can hook this node up to an <input> element by setting the gain property of the node.  (The syntax for this is kind of weird because it\u2019s an AudioParam which has options to set values at precise intervals).\nconst node = audioCtx.createGain()\n\nconst input = document.querySelector('input')\ninput.oninput = () => node.gain.value = parseFloat(input.value)\n\ninput.connect(node)\nnode.connect(audioCtx.destination)\n\nYou can now see a range input, which can be dragged to update the state of our graph. This input could be any kind of element, so now you\u2019ll be free to build the volume control of your dreams.\nThere\u2019s a number of nodes that let you modify/filter an audio stream in more interesting ways.  Head over to the MDN Web Audio page for a list of them.\nAnalysers\nSomething else we can add to our graph is an AnalyserNode. This doesn\u2019t modify the audio at all, but allows us to inspect the sounds that are flowing through it. We can put this into our graph between our AudioSourceNode and the GainNode.\nconst analyser = audioCtx.createAnalyser()\n\ninput.connect(analyser)\nanalyser.connect(gain)\ngain.connect(audioCtx.destination)\nAnd now we have an analyser. We can access it from elsewhere to drive any kind of visuals.  For instance, if we wanted to draw lines on a canvas we could totally do that:\nconst waveform = new Uint8Array(analyser.fftSize)\nconst frequencies = new Uint8Array(analyser.frequencyBinCount)\nconst ctx = canvas.getContext('2d')\n\nconst loop = () => {\n    requestAnimationFrame(loop)\n    analyser.getByteTimeDomainData(waveform)\n    analyser.getByteFrequencyData(frequencies)\n\n    ctx.beginPath()\n    waveform.forEach((f, i) => ctx.lineTo(i, f))\n    ctx.lineTo(0,255)\n    frequencies.forEach((f, i) => ctx.lineTo(i, 255-f))\n    ctx.stroke()\n}\nloop()\n\nYou can see that we have two arrays of data available (I added colours for clarity):\n\nThe waveform - the raw samples of the audio being played.\nThe frequencies - a fourier transform of the audio passing through the node.\n\nWhat\u2019s cool about this is that you\u2019re not tied to any specific functionality of the Web Audio API.  If it\u2019s possible for you to update something with an array of numbers, then you can just apply it to the output of the analyser node.\nFor instance, if we wanted to, we could definitely animate a list of emoji in time with our music.\nspans.forEach(\n  (s, i) => s.style.transform = `scale(${1 + (frequencies[i]/100)})`\n)\n\n\ud83d\udd08\ud83c\udfa4\ud83c\udfa4\ud83c\udfa4\ud83c\udfba\ud83c\udfb7\ud83d\udcef\ud83c\udfb6\ud83d\udd0a\ud83c\udfb8\ud83c\udfba\ud83c\udfa4\ud83c\udfb8\ud83c\udfbc\ud83c\udfb7\ud83c\udfba\ud83c\udfbb\ud83c\udfb8\ud83c\udfbb\ud83c\udfba\ud83c\udfb8\ud83c\udfb6\ud83e\udd41\ud83c\udfb6\ud83c\udfb5\ud83c\udfb5\ud83c\udfb7\ud83d\udcef\ud83c\udfb8\ud83c\udfb9\ud83c\udfa4\ud83c\udfb7\ud83c\udfbb\ud83c\udfb7\ud83d\udd08\ud83d\udd0a\ud83d\udcef\ud83c\udfbc\ud83c\udfa4\ud83c\udfb5\ud83c\udfbc\ud83d\udcef\ud83e\udd41\ud83c\udfbb\ud83c\udfbb\ud83c\udfa4\ud83d\udd09\ud83c\udfb5\ud83c\udfb9\ud83c\udfb8\ud83c\udfb7\ud83d\udd09\ud83d\udd08\ud83d\udd09\ud83c\udfb7\ud83c\udfb6\ud83d\udd08\ud83c\udfb8\ud83c\udfb8\ud83c\udfbb\ud83c\udfa4\ud83e\udd41\ud83c\udfbc\ud83d\udcef\ud83c\udfb8\ud83c\udfb8\ud83c\udfbc\ud83c\udfb8\ud83e\udd41\ud83c\udfbc\ud83c\udfb6\ud83c\udfb6\ud83e\udd41\ud83c\udfa4\ud83d\udd0a\ud83c\udfb7\ud83d\udd0a\ud83d\udd08\ud83c\udfba\ud83d\udd0a\ud83c\udfbb\ud83c\udfb5\ud83c\udfbb\ud83c\udfb8\ud83c\udfb5\ud83c\udfba\ud83c\udfa4\ud83c\udfb7\ud83c\udfb8\ud83c\udfb6\ud83c\udfbc\ud83d\udcef\ud83d\udd08\ud83c\udfba\ud83c\udfa4\ud83c\udfb5\ud83c\udfb8\ud83c\udfb8\ud83d\udd0a\ud83c\udfb6\ud83c\udfa4\ud83e\udd41\ud83c\udfb5\ud83c\udfb9\ud83c\udfb8\ud83d\udd08\ud83c\udfbb\ud83d\udd09\ud83e\udd41\ud83d\udd09\ud83c\udfba\ud83d\udd0a\ud83c\udfb9\ud83e\udd41\ud83c\udfb7\ud83d\udcef\ud83c\udfb7\ud83c\udfb7\ud83c\udfa4\ud83c\udfb8\ud83d\udd09\ud83c\udfb9\ud83c\udfb7\ud83c\udfb8\ud83c\udfba\ud83c\udfbc\ud83c\udfa4\ud83c\udfbc\ud83c\udfb6\ud83c\udfb7\ud83c\udfa4\ud83c\udfb7\ud83d\udcef\ud83d\udcef\ud83c\udfbb\ud83c\udfa4\ud83c\udfb7\ud83d\udcef\ud83c\udfb9\ud83d\udd08\ud83c\udfb5\ud83c\udfb9\ud83c\udfbc\ud83d\udd0a\ud83d\udd09\ud83d\udd09\ud83d\udd08\ud83c\udfb6\ud83c\udfb8\ud83e\udd41\ud83c\udfba\ud83d\udd08\ud83c\udfb7\ud83c\udfb5\ud83d\udd09\ud83e\udd41\ud83c\udfb7\ud83c\udfb9\ud83c\udfb7\ud83d\udd0a\ud83c\udfa4\ud83c\udfa4\ud83d\udd0a\ud83c\udfa4\ud83c\udfa4\ud83c\udfb9\ud83c\udfb8\ud83c\udfb9\ud83d\udd09\ud83c\udfb7\n\n\nGenerating Audio\nSo far, we\u2019ve been using the <audio> element as a source of sound.\nThere\u2019s a few other sources of audio that we can use.  We\u2019ll look at the AudioBufferNode - which allows you to manually generate a sound sample, and then connect it to our graph.\nFirst we have to create an AudioBuffer, which holds our raw data, then we pass that to an AudioBufferNode which we can then treat just like our AudioSource node. This can get a bit boring, so we\u2019ll use a helper method that makes it simpler to generate sounds.\nconst generator = (audioCtx, target) => (seconds, fn) => {\n  const { sampleRate } = audioCtx\n\n  const buffer = audioCtx.createBuffer(\n      1, sampleRate * seconds, sampleRate\n  )\n  const data = buffer.getChannelData(0)\n\n  for (var i = 0; i < data.length; i++) {\n    data[i] = fn(i / sampleRate, seconds)\n  }\n\n  return () => {\n    const source = audioCtx.createBufferSource()\n    source.buffer = audioBuffer\n\n    source.connect(target || audioCtx.destination)\n    source.start()  \n  }\n}\n\nconst sound = generator(audioCtx, gain)\nOur wrapper will let us provide a function that maps time (in seconds) to a sample (between 1 and -1). This generates a waveform, like we saw before with the analyser node.\nFor example, the following will generate 0.75 seconds of white noise at 20% volume.\nconst noise = sound(0.75, t => Math.random() * 0.2)\n\nbutton.onclick = noise\n\nNoise\n\n\nNow we\u2019ve got a noisy button! Handy.\nRather than having a static set of audio nodes, each time we click the button, we add a new node to our graph. Although this feels inefficient, it\u2019s not actually too bad - the browser can do a good job of cleaning up old nodes once they\u2019ve played.\nAn interesting property of defining sounds as functions is that we can combine multiple function to generate new sounds. So if we wanted to fade our noise in and out, we could write a higher order function that does that.\nconst ease = fn => (t, s) =>\n  fn(t) * Math.sin((t / s) * Math.PI)\n\nconst noise = sound(0.75, ease(t => Math.random() * 0.2))\n\nease(noise)\n\n\nAnd we can do more than just white noise - if we use Math.sin, we can generate some nice pure tones.\n// Math.sin with period of 0..1\nconst wave = v => Math.sin(Math.PI * 2 * v)\nconst hz = f => t => wave(t * f)\n\nconst _440hz = sound(0.75, ease(hz(440)))\nconst _880hz = sound(0.75, ease(hz(880)))\n\n440Hz\n880Hz\n\n\nWe can also make our functions more complex. Below we\u2019re combining several frequencies to make a richer sounding tone.\nconst harmony = f => [4, 3, 2, 1].reduce(\n    (v, h, i) => (sin(f * h) * (i+1) ) + v\n)\n\nconst a440 = sound(0.75, ease(harmony(440)))\n\n440Hz\n880Hz\n\n\nCool.\nWe\u2019re still not using any audio-specific functionality, so we can repurpose anything that does an operation on data. For example, we can use d3.js - usually used for interactive data visualisations - to generate a triangular waveform.\nconst triangle = d3.scaleLinear()\n    .domain([0, .5,  1])\n    .range([-1,  1, -1])\n\nconst wave = t => triangle(t % 1)\n\nconst a440 = sound(0.75, ease(harmony(440)))\n\n440Hz\n880Hz\n\n\nIt\u2019s pretty interesting to play around with different functions. I\u2019ve plonked everything in jsbin if you want to have a play yourself.\nA departure from best practice\nWe\u2019ve been generating our audio from scratch, but most of what we\u2019ve looked at can be implemented by a series of native Web Audio nodes. This would be way performant (because it\u2019s not happening on the main thread), and more flexible in some ways (because you can set timings dynamically whilst the note is playing). But we\u2019re going to stay with this approach because it\u2019s fun, and sometimes the fun thing to do might not technically be the best thing to do.\nMaking a keyboard\nHaving a button that makes a sound is totally great, but how about lots of buttons that make lots of sounds?  Yup, totally greater-er.\nThe first thing we need to know is the frequency of each note. I thought this would be awkward because pianos were invented more than 250 years before the Hz unit was defined, so surely there wouldn\u2019t be a simple mapping between the two?\nconst freq = note => 27.5 * Math.pow(2, (note - 21) / 12)\nThis equation blows my mind; I\u2019d never really figured how tightly music and maths fit together.  When you see a chord or melody, you can directly map it back to a mathematical pattern.\nOur keyboard is actually an SVG picture of a keyboard, so we can traverse the elements of it and map each element to a sound generated by one of the functions that we came up with before.\nArray.from(svg.querySelector('rect'))\n  .sort((a, b) => + a.x - b.x)\n  .forEach((key, i) =>\n    key.addEventListener('touchstart',\n      sound(0.75, ease(harmony(freq(i + 48))))\n    )\n  )\n\nrect {stroke: #ddd;}\nrect:hover {opacity: 0.8; stroke: #000}\n\nEt voil\u00e0. We have a keyboard.\nWhat I like about this is that it\u2019s completely pure - there\u2019s no lookup tables or hardcoded attributes; we\u2019ve just defined a mapping from SVG elements to the sound they should probably make.\nDoing better in the future\nAs I mentioned before, this could be implemented more performantly with Web Audio nodes, or even better - use something like Tone.js to be performant for you.\nWeb Audio has been around for a while, though we\u2019re getting new challenges with immersive WebXR experiences, where spatial audio becomes really important. There\u2019s also always support and API improvements (if you like AudioBufferNode, you\u2019re going to love AudioWorklet)\nConclusion\nAnd that\u2019s about it. Web Audio isn\u2019t some black box, you can easily link it with whatever framework, or UI that you\u2019ve built (whether you should is an entirely different question).\nIf anyone ever asks you \u201ccould you turn this SVG into a musical instrument?\u201d you don\u2019t have to stare blankly at them any more.\n(function(a,c){var b=a.createElement(\"script\");if(!(\"noModule\"in b)&&\"on\"+c in b){var d=!1;a.addEventListener(c,function(a){if(a.target===b)d=!0;else if(!a.target.hasAttribute(\"nomodule\")||!d)return;a.preventDefault()},!0);b.type=\"module\";b.src=\".\";a.head.appendChild(b);b.remove()}})(document,\"beforeload\");", "year": "2017", "author": "Ben Foxall", "author_slug": "benfoxall", "published": "2017-12-17T00:00:00+00:00", "url": "https://24ways.org/2017/feeding-the-audio-graph/", "topic": "code"}
{"rowid": 109, "title": "Geotag Everywhere with Fire Eagle", "contents": "A note from the editors:  Since this article was written Yahoo! has retired the Fire Eagle service.\n                \n                \n                      \n                Location, they say, is everywhere. Everyone has one, all of the time. But on the web, it\u2019s taken until this year to see the emergence of location in the applications we use and build.\n\nThe possibilities are broad. Increasingly, mobile phones provide SDKs to approximate your location wherever you are, browser extensions such as Loki and Mozilla\u2019s Geode provide browser-level APIs to establish your location from the proximity of wireless networks to your laptop. Yahoo\u2019s Brickhouse group launched Fire Eagle, an ambitious location broker enabling people to take their location from any of these devices or sources, and provide it to a plethora of web services. It enables you to take the location information that only your iPhone knows about and use it anywhere on the web.\n\nThat said, this is still a time of location as an emerging technology. Fire Eagle stores your location on the web (protected by application-specific access controls), but to try and give an idea of how useful and powerful your location can be \u2014 regardless of the services you use now \u2014 today\u2019s 24ways is going to build a bookmarklet to call up your location on demand, in any web application.\n\nLocation Support on the Web\n\nOver the past year, the number of applications implementing location features has increased dramatically. Plazes and Brightkite are both full featured social networks based around where you are, whilst Pownce rolled in Fire Eagle support to allow geotagging of all the content you post to their microblogging service. Dipity\u2019s beautiful timeline shows for you moving from place to place and Six Apart\u2019s activity stream for Movable Type started exposing your movements.\n\nThe number of services that hook into Fire Eagle will increase as location awareness spreads through the developer community, but you can use your location on other sites indirectly too.\n\nConsider Flickr. Now world renowned for their incredible mapping and places features, geotagging on Flickr started out as a grassroots extension of regular tagging. That same technique can be used to start rolling geotagging in any publishing platform you come across, for any kind of content. Machine-tags (geo:lat= and geo:lon=) and the adr and geo microformats can be used to enhance anything you write with location information.\n\nA crash course in avian inflammability\n\nFire Eagle is a location store. A broker between services and devices which provide location and those which consume it. It\u2019s a switchboard that controls which pieces of your location different applications can see and use, and keeps hidden anything you want kept private. A blog widget that displays your current location in public can be restricted to display just your current city, whilst a service that provides you with a list of the nearest ATMs will operate better with a precise street address. \n\nEven if your iPhone tells Fire Eagle exactly where you are, consuming applications only see what you want them to see. That\u2019s important for users to realise that they\u2019re in control, but also important for application developers to remember that you cannot rely on having super-accurate information available all the time. You need to build location aware applications which degrade gracefully, because users will provide fuzzier information \u2014 either through choice, or through less accurate sources.\n\nApplication specific permissions are controlled through an OAuth API. Each application has a unique key, used to request a second, user-specific key that permits access to that user\u2019s information. You store that user key and it remains valid until such a time as the user revokes your application\u2019s access. Unlike with passwords, these keys are unique per application, so revoking the access rights of one application doesn\u2019t break all the others.\n\nBuilding your first Fire Eagle app; Geomarklet\n\nFire Eagle\u2019s developer documentation can take you through examples of writing simple applications using server side technologies (PHP, Python). Here, we\u2019re going to write a client-side bookmarklet to make your location available in every site you use. It\u2019s designed to fast-track the experience of  having location available everywhere on web, and show you how that can be really handy. Hopefully, this will set you thinking about how location can enhance the new applications you build in 2009.\n\nAn oddity of bookmarklets\n\nBookmarklets (or \u2018favlets\u2019, for those of an MSIE persuasion) are a strange environment to program in. Critically, you have no persistent storage available. As such, using token-auth APIs in a static environment requires you to build you application in a slightly strange way; authing yourself in advance and then hardcoding the keys into your script.\n\nGet started\n\nBefore you do anything else, go to http://fireeagle.com and log in, get set up if you need to and by all means take a look around. Take a look at the mobile updaters section of the application gallery and perhaps pick out an app that will update Fire Eagle from your phone or laptop.\n\nOnce that\u2019s done, you need to register for an application key in the developer section. Head straight to /developer/create and complete the form. Since you\u2019re building a standalone application, choose \u2018Auth for desktop applications\u2019 (rather than web applications), and select that you\u2019ll be \u2018accessing location\u2019, not updating.\n\nAt the end of this process, you\u2019ll have two application keys, a \u2018Consumer Key\u2019 and a \u2018Consumer Secret\u2019, which look like these:\n\n \n    Consumer Key\n    luKrM9U1pMnu\n    Consumer Secret\n    ZZl9YXXoJX5KLiKyVrMZffNEaBnxnd6M\n \n\nThese keys combined allow your application to make requests to Fire Eagle.\n\nNext up, you need to auth yourself; granting your new application permission to use your location. Because bookmarklets don\u2019t have local storage, you can\u2019t integrate the auth process into the bookmarklet itself \u2014 it would have no way of storing the returned key. Instead, I\u2019ve put together a simple web frontend through which you can auth with your application.\n\nHead to Auth me, Amadeus!, enter the application keys you just generated and hit \u2018Authorize with Fire Eagle\u2019. You\u2019ll be taken to the Fire Eagle website, just as in regular Fire Eagle applications, and after granting access to your app, be redirected back to Amadeus which will provide you your user tokens. These tokens are used in subsequent requests to read your location.\n\nAnd, skip to the end\u2026\n\nThe process of building the bookmarklet, making requests to Fire Eagle, rendering it to the page and so forth follows, but if you\u2019re the impatient type, you might like to try this out right now. Take your four API keys from above, and drag the following link to your Bookmarks Toolbar; it contains all the code described below. Before you can use it, you need to edit in your own API keys. Open your browser\u2019s bookmark editor and where you find text like \u2018YOUR_CONSUMER_KEY_HERE\u2019, swap in the corresponding key you just generated.\n\nGet Location\n\nBookmarklet Basics\n\nTo start on the bookmarklet code, set out a basic JavaScript module-pattern structure:\n\nvar Geomarklet = function() {\n\treturn ({\n\t\tcallback: function(json) {},\n\t\trun: function() {}\n\t});\n};\nGeomarklet.run();\n\nNext we\u2019ll add the keys obtained in the setup step, and also some basic Fire Eagle support objects:\n\nvar Geomarklet = function() {\n\tvar Keys = {\n\t\t\tconsumer_key: 'IuKrJUHU1pMnu',\n\t\t\tconsumer_secret: 'ZZl9YXXoJX5KLiKyVEERTfNEaBnxnd6M',\n\t\t\tuser_token: 'xxxxxxxxxxxx',\n\t\t\tuser_secret: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'\n\t};\n\tvar LocationDetail = {\n\t\t\tEXACT: 0,\n\t\t\tPOSTAL: 1,\n\t\t\tNEIGHBORHOOD: 2,\n\t\t\tCITY: 3,\n\t\t\tREGION: 4,\n\t\t\tSTATE: 5,\n\t\t\tCOUNTRY: 6\n\t};\n\tvar index_offset;\n\treturn ({\n\t\tcallback: function(json) {},\n\t\trun: function() {}\n\t});\n};\nGeomarklet.run();\n\nThe Location Hierarchy\n\nA successful Fire Eagle query returns an object called the \u2018location hierarchy\u2019. Depending on the level of detail shared, the index of a particular piece of information in the array will vary. The LocationDetail object maps the array indices of each level in the hierarchy to something comprehensible, whilst the index_offset variable is an adjustment based on the detail of the result returned.\n\nThe location hierarchy object looks like this, providing a granular breakdown of a location, in human consumable and machine-friendly forms.\n\n\"user\": {\n\t\t\"location_hierarchy\": [{\n\t\t\t\"level\": 0,\n\t\t\t\"level_name\": \"exact\",\n\t\t\t\"name\": \"707 19th St, San Francisco, CA\",\n\t\t\t\"normal_name\": \"94123\",\n\t\t\t\"geometry\": {\n\t\t\t\t\t\"type\": \"Point\",\n\t\t\t\t\t\"coordinates\": [ - 0.2347530752, 67.232323]\n\t\t\t},\n\t\t\t\"label\": null,\n\t\t\t\"best_guess\": true,\n\t\t\t\"id\": ,\n\t\t\t\"located_at\": \"2008-12-18T00:49:58-08:00\",\n\t\t\t\"query\": \"q=707%2019th%20Street,%20Sf\"\n\t\t},\n\t\t{\n\t\t\t\t\"level\": 1,\n\t\t\t\t\"level_name\": \"postal\",\n\t\t\t\t\"name\": \"San Francisco, CA 94114\",\n\t\t\t\t\"normal_name\": \"12345\",\n\t\t\t\t\"woeid\": ,\n\t\t\t\t\"place_id\": \"\",\n\t\t\t\t\"geometry\": {\n\t\t\t\t\t\t\"type\": \"Polygon\",\n\t\t\t\t\t\t\"coordinates\": [],\n\t\t\t\t\t\t\"bbox\": []\n\t\t\t\t},\n\t\t\t\t\"label\": null,\n\t\t\t\t\"best_guess\": false,\n\t\t\t\t\"id\": 59358791,\n\t\t\t\t\"located_at\": \"2008-12-18T00:49:58-08:00\"\n\t\t},\n\t\t{\n\t\t\t\t\"level\": 2,\n\t\t\t\t\"level_name\": \"neighborhood\",\n\t\t\t\t\"name\": \"The Mission, San Francisco, CA\",\n\t\t\t\t\"normal_name\": \"The Mission\",\n\t\t\t\t\"woeid\": 23512048,\n\t\t\t\t\"place_id\": \"Y12JWsKbApmnSQpbQg\",\n\t\t\t\t\"geometry\": {\n\t\t\t\t\t\t\"type\": \"Polygon\",\n\t\t\t\t\t\t\"coordinates\": [],\n\t\t\t\t\t\t\"bbox\": []\n\t\t\t\t},\n\t\t\t\t\"label\": null,\n\t\t\t\t\"best_guess\": false,\n\t\t\t\t\"id\": 59358801,\n\t\t\t\t\"located_at\": \"2008-12-18T00:49:58-08:00\"\n\t\t\t},\n\t\t}\n\nIn this case the first object has a level of 0, so the index_offset is also 0.\n\nPrerequisites\n\nTo query Fire Eagle we call in some existing libraries to handle the OAuth layer and the Fire Eagle API call. Your bookmarklet will need to add the following scripts into the page:\n\n\n\tThe SHA1 encryption algorithm\n\tThe OAuth wrapper\n\tAn extension for the OAuth wrapper\n\tThe Fire Eagle wrapper itself\n\n\nWhen the bookmarklet is first run, we\u2019ll insert these scripts into the document. We\u2019re also inserting a stylesheet to dress up the UI that will be generated.\n\nIf you want to follow along any of the more mundane parts of the bookmarklet, you can  download the full source code.\n\nRendering\n\nThis bookmarklet can be extended to support any formatting of your location you like, but for sake of example I\u2019m going to build three common formatters that you\u2019ll find useful for common location scenarios: Sites which already ask for your location; and in publishing systems that accept tags or HTML mark-up.\n\nAll the rendering functions are items in a renderers object, so they can be iterated through easily, making it trivial to add new formatting functions as your find new use cases (just add another function to the object).\n\nvar renderers = {\ngeotag: function(user) {\n\tif(LocationDetail.EXACT !== index_offset) {\n\t\t\treturn false;\n\t}\n\telse {\n\t\tvar coords =\n\t\t\tuser.location_hierarchy[LocationDetail.EXACT].geometry.coordinates;\n\t\treturn \"geo:lat=\" + coords[0] + \", geo:lon=\" + coords[1];\n\t}\n},\ncity: function(user) {\n\tif(LocationDetail.CITY < index_offset) {\n\t\treturn false;\n\t}\n\telse {\n\t\treturn user.location_hierarchy[LocationDetail.CITY - index_offset].name; \n\t}\t\t\t\t\t\t \n}\n\nYou should always fail gracefully, and in line with catering to users who choose not to share their location precisely, always check that the location has been returned at the level you require. Geotags are expected to be precise, so if an exact location is unavailable, returning false will tell the rendering aspect of the bookmarklet to ignore the function altogether.\n\nThese first two are quite simple, geotag returns geo:lat=-0.2347530752, geo:lon=67.232323 and city returns San Francisco, CA.\n\nThis final renderer creates a chunk of HTML using the adr and geo microformats, using all available aspects of the location hierarchy, and can be used to geotag any content you write on your blog or in comments:\n\nhtml: function(user) {\n\tvar geostring = '';\n\tvar adrstring = '';\n\tvar adr = [];\t\t \n\tadr.push('<p class=\"adr\">');\n\t// city\n\tif(LocationDetail.CITY >= index_offset) {\n\t\tadr.push(\n\t\t\t'\\n\t\t <span class=\"locality\">'\n\t\t+ user.location_hierarchy[LocationDetail.CITY-index_offset].normal_name\n\t\t+ '</span>,'\n\t\t);\n\t}\n\t// county\n\tif(LocationDetail.REGION >= index_offset) {\n\t\tadr.push(\n\t\t\t'\\n\t\t <span class=\"region\">' \n\t\t+ user.location_hierarchy[LocationDetail.REGION-index_offset].normal_name\n\t\t+ '</span>,'\n\t\t\t);\n\t}\n\t// locality\n\tif(LocationDetail.STATE >= index_offset) {\n\t\tadr.push(\n\t\t\t'\\n\t\t <span class=\"region\">'\n\t\t+ user.location_hierarchy[LocationDetail.STATE-index_offset].normal_name\n\t\t+ '</span>,'\n\t\t);\n\t}\n\t// country\n\tif(LocationDetail.COUNTRY >= index_offset) {\n\t\tadr.push(\n\t\t\t'\\n\t\t <span class=\"country-name\">'\n\t\t+ user.location_hierarchy[LocationDetail.COUNTRY-index_offset].normal_name\n\t\t+ '</span>'\n\t\t);\n\t}\n\t// postal\n\tif(LocationDetail.POSTAL >= index_offset) {\n\t\tadr.push(\n\t\t\t'\\n\t\t <span class=\"postal-code\">'\n\t\t+ user.location_hierarchy[LocationDetail.POSTAL-index_offset].normal_name\n\t\t+ '</span>,'\n\t\t);\n\t}\n\tadr.push('\\n</p>\\n');\n\tadrstring = adr.join('');\n\tif(LocationDetail.EXACT === index_offset) {\n\t\tvar coords = \n\t\t\tuser.location_hierarchy[LocationDetail.EXACT].geometry.coordinates;\n\t\tgeostring = '<p class=\"geo\">'\n\t\t\t+'\\n\t\t<span class=\"latitude\">'\n\t\t\t+ coords[0]\n\t\t\t+ '</span>;'\n\t\t\t+ '\\n\t\t <span class=\"longitude\">'\n\t\t\t+ coords[1]\n\t\t\t+ '</span>\\n</p>\\n';\n\t}\n\treturn (adrstring + geostring);\n}\n\nHere we check the availability of every level of location and build it into the adr and geo patterns as appropriate. Just as for the geotag function, if there\u2019s no exact location the geo markup won\u2019t be returned.\n\nFinally, there\u2019s a rendering method which creates a container for all this data, renders all the applicable location formats and then displays them in the page for a user to copy and paste. You can throw this together with DOM methods and some simple styling, or roll in some components from YUI or JQuery to handle drawing full featured overlays.\n\nYou can see this simple implementation for rendering in the full source code.\n\nMake the call\n\nWith a framework in place to render Fire Eagle\u2019s location hierarchy, the only thing that remains is to actually request your location. Having already authed through Amadeus earlier, that\u2019s as simple as instantiating the Fire Eagle JavaScript wrapper and making a single function call. It\u2019s a big deal that whilst a lot of new technologies like OAuth add some complexity and require new knowledge to work with, APIs like Fire Eagle are really very simple indeed.\n\nreturn {\n\trun: function() {\n\t\tinsert_prerequisites();\n\t\tsetTimeout(\n\t\t\tfunction() {\n\t\t\t\tvar fe = new FireEagle(\n\t\t\t\t\tKeys.consumer_key,\n\t\t\t\t\tKeys.consumer_secret,\n\t\t\t\t\tKeys.user_token,\n\t\t\t\t\tKeys.user_secret\n\t\t\t\t);\n\t\t\t\tvar script = document.createElement('script');\n\t\t\t\tscript.type = 'text/javascript';\n\t\t\t\tscript.src = fe.getUserUrl(\n\t\t\t\t\tFireEagle.RESPONSE_FORMAT.json,\n\t\t\t\t\t'Geomarklet.callback'\n\t\t\t\t);\n\t\t\t\tdocument.body.appendChild(script);\n\t\t\t},\n\t\t\t2000\n\t\t);\n\t},\n\tcallback: function(json) {\n\t\tif(json.rsp && 'fail' == json.rsp.stat) {\n\t\t\talert('Error ' + json.rsp.code + \": \" + json.rsp.message);\n\t\t}\n\t\telse {\n\t\t\tindex_offset = json.user.location_hierarchy[0].level;\t\t\t\t\t\t \n\t\t\tdraw_selector(json);\n\t\t}\n\t}\n};\n\nWe first insert the prerequisite scripts required for the Fire Eagle request to function, and to prevent trying to instantiate the FireEagle object before it\u2019s been loaded over the wire, the remaining instantiation and request is wrapped inside a setTimeout delay.\n\nWe then create the request URL, referencing the Geomarklet.callback callback function and then append the script to the document body \u2014 allowing a cross-domain request.\n\nThe callback itself is quite simple. Check for the presence and value of rsp.status to test for errors, and display them as required. If the request is successful set the index_offset \u2014 to adjust for the granularity of the location hierarchy \u2014 and then pass the object to the renderer.\n\nThe result? When Geomarklet.run() is called, your location from Fire Eagle is read, and each renderer displayed on the page in an easily copy and pasteable form, ready to be used however you need.\n\nDeploy\n\nThe final step is to convert this code into a long string for use as a bookmarklet. Easiest for Mac users is the JavaScript bundle in TextMate \u2014 choose Bundles: JavaScript: Copy as Bookmarklet to Clipboard. Then create a new \u2018Get Location\u2019 bookmark in your browser of choice and paste in.\n\nThose without TextMate can shrink their code down into a single line by first running their code through the JSLint tool (to ensure the code is free from errors and has all the required semi-colons) and then use a find-and-replace tool to remove line breaks from your code (or even run your code through JSMin to shrink it down).\n\nWith the bookmarklet created and added to your bookmarks bar, you can now call up your location on any page at all. Get a feel for a web where your location is just another reliable part of the browsing experience.\n\nWhere next?\n\nSo, the Geomarklet you\u2019ve been guided through is a pretty simple premise and pretty simple output. But from this base you can start to extend: Add code that will insert each of the location renderings directly into form fields, perhaps, or how about site-specific handlers to add your location tags into the correct form field in Wordpress or Tumblr? Paste in your current location to Google Maps? Or Flickr?\n\nGeomarklet gives you a base to start experimenting with location on your own pages and the sites you browse daily.\n\nThe introduction of consumer accessible geo to the web is an adventure of discovery; not so much discovering new locations, but discovering location itself.", "year": "2008", "author": "Ben Ward", "author_slug": "benward", "published": "2008-12-21T00:00:00+00:00", "url": "https://24ways.org/2008/geotag-everywhere-with-fire-eagle/", "topic": "code"}
{"rowid": 85, "title": "Starting Your Project on the Right Foot (and Keeping It There)", "contents": "I\u2019m not sure if anything is as terrifying as beginning a new design project. I often spend hours trying to find the best initial footing in a design, so I\u2019ve been working hard to improve my process, particularly for the earliest stages of a project. I want\u00a0to smooth out the bumps that disrupt my creative momentum and focus on the emotional highs and lows I experience, and then try to minimize the lows and ride the highs as long as possible. \n\nDesign is often a struggle broken up by blissful moments of creative clarity that provide valuable force to move your work forward. Momentum is a powerful tool in creative work, and it\u2019s something we don\u2019t always maximize when we\u2019re working because of the hectic nature of our field.\u00a0Obviously, every designer is going to have a different process, but I thought I\u2019d share some of the methods I\u2019ve begun to adopt. I hope this will spark a conversation among designers who are interested in looking at process in a new way.\n\nJump-starting a project\n\nI cannot overstate the importance of immersing yourself in design and collecting ample amounts of inspiration when beginning a project. I make it a daily practice to visit a handful of sites (Dribbble, Graphic Exchange, Web Creme, siteInspire, Designspiration, and others) and save any examples of design that I like. I then sort them into general categories (publication design, illustration, typography, web design, and so on). Enjoying a bit of fresh design every day helps me absorb it and analyze why it\u2019s effective instead of just imitating it.\u00a0\n\nMany designers are afraid to look at too much design for fear that they\u2019ll be tempted to copy it, but I feel a steady influx of design inspiration reduces that possibility. You\u2019re much more likely to take the easy way out and rip off a design if you\u2019re scrambling for inspiration after getting stuck. If you are immersed in design from a variety of mediums, you\u2019ll engage your creative brain on multiple levels and have an easier time creating something unique for your project. Looking at good design will not make you a good designer but it will make you a better designer.\n\nDesign is design\n\nTry not to limit your visual research to the medium you\u2019re working in. Websites, books, posters and packaging all have their own unique limitations and challenges, and any one of those characteristics could be useful to you. Posters need to grab the viewer and pass on a small tidbit of information; packaging needs to encourage physical interaction; and websites need to encourage exploration. If you know the challenges you\u2019ll be facing, you will know where to look for design that tackles those same problems.\n\nI find it refreshing to look at design from the turn of the nineteenth century, when type was laid out on objects without thought to aesthetics. Many vintage packages break all sorts of modern design rules, and looking at that kind of work is a great way to spark your creativity. Pulling yourself out of the box and away from the rules of what you\u2019re working on can reveal solutions that are innovative and unique.\u00a0After a little finessing, the warning label text from a 1940s hazardous chemical box from could have the exact type and icon arrangement you need for your project.\u00a0There\u2019s a massive pool of design to pull from that doesn\u2019t have the limitations the web has, and exploring those design worlds will help you grow your own repertoire.\n\nIf all else fails, start with the footer\n\nThe very beginning of a project is the most frustrating point in a project for me. I\u2019m trying to figure out typeface combinations, colors and the overall voice of the design, and until I find the right solutions, I\u2019m a wreck. I\u2019ve found often that my frustration stems from trying to solve too many problems at once. The beginning of a project has a lot of moving targets, nearly endless possible solutions, and constantly changing variables. You\u2019ll knock out one problem only to discover your solution doesn\u2019t jive with something you worked out earlier \u2014 you end up designing in circles.\n\nIf you find yourself getting stuck at the beginning of a website design, try working out one specific element of the site and see what emerges. I\u2019m going to recommend the footer. Why? Footers can easily be ignored in a design or become a dumping ground for items that couldn\u2019t be worked into the main layout. But, at the start of most projects, the minimum content requirements for the footer are usually established. There needs to be a certain number of links, social media buttons, copyright details, a search bar, and so on. It\u2019s a self-contained item within the design that has a specific purpose, and that\u2019s a great element to focus on when you\u2019re stuck in a design. Colors, typefaces, link styles, input fields and buttons can all be sketched out from just the footer. It\u2019s a very flexible element that can be as prominent or subtle as you want, and it\u2019s a solid starting point for setting the tone and style of a site.\n\nSave the details\n\nDesigners love details. I love details. But don\u2019t let nitpicking early on in your process kill your creative momentum.\u00a0Design is an emotional process, and being frustrated or defeated by a tricky problem or a graphical detail you just can\u2019t nail down can deflate your creative energies. If you hit a roadblock, set it aside and tackle another piece of the project. As you spend time engaged in a design, the style you develop will evolve according to the needs of the content, and you might arrive naturally at a solution that will work perfectly for the problem that had you stuck before.\u00a0\n\nIf I find myself working on one particular element for more than a half an hour without any clear movement, I shelve it. Designers often wear their obsessive detail-oriented tendencies as a badge of honor, but there\u2019s a difference between making the design better and wasting time. If you\u2019ve spent hours nudging elements around pixel by pixel and can\u2019t settle on something, it probably means what you\u2019re doing isn\u2019t making a huge improvement on the design. Don\u2019t be afraid to let it lie and come at it again with fresh eyes. You will be better equipped to tackle the finer points of a project once you\u2019ve got the broad strokes defined.\n\nHave a plan when you start and stop designing\n\nWe all know that creativity isn\u2019t something you can turn on effortlessly, and it\u2019s easy to forget the emotional process that goes along with design.\u00a0If you leave a project in a place of frustration, it\u2019s going to stay with you in your free time and affect you negatively, like a dark cloud of impending disaster. Try to end each design session with a victory, a small bit of definable progress that you can take with you in your downtime. Even something as small as finding the right opacity for the interior shadow on the search bar in the header of the site is a win.\u00a0Likewise, when you return to a project after a break, it can be difficult to get the ball rolling on the design again if you set it down without a clear path for the next steps. I find that I work on details best when I\u2019m returning from downtime, when I\u2019m fresh and re-energized and ready to dig in again. Try to pick out at least one element you\u2019d like to fine-tune when you are winding down in a design session and use it to kick-start your next session.\n\nContent is king\n\nI would argue there is nothing more crucial to the success of a design than having the content defined from the outset.\u00a0Designing without content is similar to designing without an audience, and designing with vague ideas of content types and character limits is going to result in a muted design that doesn\u2019t reach its full potential. Images and language go hand in hand with design, and can take a design from functional to outstanding if you have them available from the outset. We don\u2019t always have the luxury of having content to build a design around, but fight for it whenever you can. For example, if the site you are designing is full of technical jargon, your paragraphs might need a longer line length to accommodate the longer words being used.\u00a0\n\nOften, working with content will lead to design solutions you wouldn\u2019t have come to otherwise.\u00a0Design speaks to content, and content speaks to design. Lorem ipsum doesn\u2019t speak to anyone (unless you know Latin, in which case, congratulations!).\n\nEvery project has its own set of needs, and every designer has his or her own method of working. There\u2019s obviously no perfect process to design, and being dogmatic about process can be just as harmful as not having one. Exposing yourself to new design and new ways of designing is an easy way to test your skills and grow. When things are hard and you can\u2019t get any momentum going on a design, this is when your skill set is truly challenged. We all hope to get wonderful projects with great assets and ample creative possibilities, but you won\u2019t always be so blessed, and this is when the quality of your process is really going to shine.", "year": "2012", "author": "Bethany Heck", "author_slug": "bethanyheck", "published": "2012-12-02T00:00:00+00:00", "url": "https://24ways.org/2012/starting-your-project-on-the-right-foot/", "topic": "process"}
{"rowid": 3, "title": "Project Hubs: A Home Base for Design Projects", "contents": "SCENE: A design review meeting. Laptop screens. Coffee cups.\n\nProject manager: Hey, did you get my email with the assets we\u2019ll be discussing? \n\nClient: I got an email from you, but it looks like there\u2019s no attachment.\n\nPM: Whoops! OK. I\u2019m resending the files with the attachments. Check again?\n\nClient: OK, I see them. It\u2019s homepage_v3_brian-edits_FINAL_for-review.pdf, right? \n\nPM: Yeah, that\u2019s the one.\n\nClient: OK, hang on, Bill\u2019s going to print them out. (3-minute pause. Small talk ensues.)\n\nClient: Alright, Bill\u2019s back. We\u2019re good to start. \n\nBrian: Oh, actually those homepage edits we talked about last time are in the homepage_v4_brian_FINAL_v2.pdf document that I posted to Basecamp earlier today.\n\nClient: Oh, OK. What message thread was that in? \n\nBrian: Uh, I\u2019m pretty sure it\u2019s in \u201cHomepage Edits and Holiday Schedule.\u201d\n\nClient: Alright, I see them. Bill\u2019s going back to the printer. Hang on a sec\u2026\n\n\n\nThis is only a slightly exaggerated version of my experience in design review meetings. \n\nThe design project dance is a sloppy one. It involves a slew of email attachments, PDFs, PSDs, revisions, GitHub repos, staging environments, and more. And while tools like Basecamp can help manage all these moving parts, it can still be incredibly challenging to extract only the important bits, juggle deliverables, and see how your project is progressing.\n\nEnter project hubs. \n\nProject hubs\n\nA project hub consolidates all the key design and development materials onto a single webpage presented in reverse chronological order. The timeline lives online (either publicly available or password protected), so that everyone involved in the team has easy access to it.\n\n A project hub.\n\nI was introduced to project hubs after seeing Dan Mall\u2019s open redesign of Reading Is Fundamental. Thankfully, I had a chance to work with Dan on two projects where I got to see firsthand how beneficial a project hub can be. Here\u2019s what makes a project hub great:\n\n\n\tServes as a centralized home base for the project\n\tTrains clients and teams to decide in the browser\n\tEasily and visually view project\u2019s progress\n\tProvides an archive for project artifacts\n\n\nA home base\n\nYour clients and colleagues can expect to get the latest and greatest updates to your project when visiting the project hub, the same way you\u2019d expect to get the latest information on a requested topic when you visit a Wikipedia page. That\u2019s the beauty of URIs that don\u2019t change. \n\nCreating a project hub reduces a ton of email volley nonsense, and eliminates the need to produce files and directories with staggeringly ridiculous names like design/12.13.13/team/brian/for_review/_FINAL/styletile_121313_brian-edits-final_v2_FINAL.pdf. The team can simply visit the project hub\u2019s URL and click the link to whatever artifact they need. Need to make an update? Simply update the link on the project hub. No more email tango and silly file names. \n\nDeciding in the browser\n\n\n\tLet\u2019s change the phrase \u201cdesigning in the browser\u201d to \u201cdeciding in the browser.\u201d\nDan Mall\n\n\nWe make websites, but all too often we find ourselves looking at web design artifacts in abstractions. We email PDFs to each other, glance at mockup JPGs on our desktops, and of course kill trees in order to print out designs so that we can scribble in the margins. All of these practices subtly take everyone further and further away from the design\u2019s eventual final resting place: the browser.\n\nBecause a project hub is just a simple webpage, reviewing designs is as easy as clicking some links, which keep your clients and teams in the browser. \n\nYou can keep people in the browser with yet another clever trick from the wily Dan Mall: instead of sending clients PDFs or JPGs, he created a simple webpage and tossed his static visuals into the template (you can view an example here). This forces clients to review web design work in the browser rather than launching a PDF viewer or Preview. \n\nNow this all might sound trivial to you (\u201cOf course my client knows that we\u2019re designing a website!\u201d), but keeping the design artifacts in the browser subconsciously helps remind everyone of the medium for which you\u2019re designing, which helps everyone focus on the right aspects of the design and have the right conversations. \n\nProgress over time\n\nWhen you\u2019re in the trenches, it\u2019s often hard to visualize how a project is progressing. Tools like Basecamp include discussions, files, to-dos, and more, which are all great tools but also make things a bit noisy. Project hubs provide you and your clients a quick and easy way to see at a glance how things are coming along. Teams can rest assured they\u2019re viewing the most current versions of designs, and managers can share progress with stakeholders simply by providing a link to the project hub. \n\nOver time, a project hub becomes an easily accessible archive of all the design decisions, which makes it easy to compare and contrast different versions of designs and prototypes.\n\nSetting up a project hub\n\nSetting up your own project hub is pretty simple. Simply create a webpage with some basic styles and branding. I\u2019ve created a project hub template that\u2019s available on GitHub if you want a jump-start.\n\nPublish the webpage to a URL somewhere that makes sense (we\u2019ve found that a subdomain of your site works quite well) and share it with everyone involved in the project. Bookmark it. Let everyone know that this is where design updates will be shared, and that they can always come back to the project hub to track the project\u2019s progress.\n\nWhen it comes time to share new updates, simply add a new node to the timeline and republish the webpage. Simple FTPing works just fine, but it might make sense to keep track of changes using version control. Our project hub for our open redesign of the Pittsburgh Food Bank is managed on GitHub, which means that I can make edits to the hub right from GitHub. Thanks to the magical wizardry of webhooks, I can automatically deploy the project hub so that everything stays in sync. That\u2019s the fancy-pants way to do it, and is certainly not a requirement. As long as you\u2019re able to easily make edits and keep your project hub up to date, you\u2019re good to go. \n\nSo that\u2019s the hubbub\n\nProject hubs can help tame the chaos of the design process by providing a home base for all key design and development materials. Keep the design artifacts in the browser and give clients and colleagues quick insight into your project\u2019s progress.\n\nHappy hubbing!", "year": "2013", "author": "Brad Frost", "author_slug": "bradfrost", "published": "2013-12-17T00:00:00+00:00", "url": "https://24ways.org/2013/project-hubs/", "topic": "process"}
{"rowid": 83, "title": "Cut Copy Paste", "contents": "Long before I got into this design thing, I was heavily into making my own music inspired by the likes of Coldcut and Steinski. I would scour local second-hand record shops in search of obscure beats, loops and bits of dialogue in the hope of finding that killer sample I could then splice together with other things to make a huge hit that everyone would love. While it did eventually lead to a record contract and getting to release a few 12\u2033 singles, ultimately I knew I\u2019d have to look for something else to pay the bills.\n\nI may not make my own records any more, but the approach I took back then \u2013 finding (even stealing) things, cutting and pasting them into interesting combinations \u2013 is still at the centre of how I work, only these days it\u2019s pretty much bits of code rather than bits of vinyl. Over the years I\u2019ve stored these little bits of code (some I\u2019ve found, some I\u2019ve created myself) in Evernote, ready to be dialled up whenever I need them. \n\nSo when Drew got in touch and asked if I\u2019d like to do something for this year\u2019s 24 ways I thought it might be kind of cool to share with you a few of these snippets that I find really useful. Think of these as a kind of coding mix tape; but remember \u2013 don\u2019t just copy as is: play around, combine and remix them into other wonderful things. \n\nSome of this stuff is dirty; some of it will make hardcore programmers feel ill. For those people, remember this \u2013 while you were complaining about the syntax, I made something.\n\nCreate unique colours\n\nLet\u2019s start right away with something I stole. Well, actually it was given away at the time by Matt Biddulph who was then at Dopplr before Nokia destroyed it. Imagine you have thousands of words and you want to assign each one a unique colour. Well, Matt came up with a crazily simple but effective way to do that using an MD5 hash. Just encode said word using an MD5 hash, then take the first six characters of the string you get back to create a hexadecimal colour representation. \n\nI can\u2019t guarantee that it will be a harmonious colour palette, but it\u2019s still really useful. The thing I love the most about this technique is the left-field thinking of using an encryption system to create colours! Here\u2019s an example using JavaScript:\n\n// requires the MD5 library available at http://pajhome.org.uk/crypt/md5\n\n  function MD5Hex(str){\n    result = MD5.hex(str).substring(0, 6);\n    return result;\n  }\n\nMake something breathe using a sine wave\n\nI never paid attention in school, especially during double maths. As a matter of fact, the only time I received corporal punishment \u2013 several strokes of the ruler \u2013 was in maths class. Anyway, if they had shown me then how beautiful mathematics actually is, I might have paid more attention. Here\u2019s a little example of how a sine wave can be used to make something appear to breathe. \n\nI recently used this on an Arduino project where an LED ring surrounding a button would gently breathe. Because of that it felt much more inviting. I love mathematics.\n\nfor(int i = 0; i<360; i++){    \n  float rad = DEG_TO_RAD * i;\n  int sinOut = constrain((sin(rad) * 128) + 128, 0, 255);\n  analogWrite(LED, sinOut);\n  delay(10);   \n}\n\nSnap position to grid\n\nThis is so elegant I love it, and it was shown to me by Gary Burgess, or Boom Boom as myself and others like to call him. It snaps a position, in this case the X-position, to a grid. Just define your grid size (say, twenty pixels) and you\u2019re good.\n\nsnappedXpos = floor( xPos / gridSize) * gridSize;\n\nCalculate the distance between two objects\n\nFor me, interaction design is about the relationship between two objects: you and another object; you and another person; or simply one object to another. How close these two things are to each other can be a handy thing to know, allowing you to react to that information within your design. Here\u2019s how to calculate the distance between two objects in a 2-D plane:\n\ndeltaX = round(p2.x-p1.x);\ndeltaY = round(p2.y-p1.y);\ndiff = round(sqrt((deltaX*deltaX)+(deltaY*deltaY)));\n\nFind the X- and Y-position between two objects\n\nWhat if you have two objects and you want to place something in-between them? A little bit of interruption and disruption can be a good thing. This small piece of code will allow you to place an object in-between two other objects:\n\n// set the position: 0.5 = half-way\t\n\nfloat position = 0.5;\nfloat x = x1 + (x2 - x1) *position;  \nfloat y = y1 + (y2 - y1) *position;  \n\nDistribute objects equally around a circle \t\n\nMore fun with maths, this time adding cosine to our friend sine. Let\u2019s say you want to create a circular navigation of arbitrary elements (yeah, Jakob, you heard), or you want to place images around a circle. Well, this piece of code will do just that. You can adjust the size of the circle by changing the distance variable and alter the number of objects with the numberOfObjects variable. Example below is for use in Processing.\n\n// Example for Processing available for free download at processing.org\n\nvoid setup() {\n\n  size(800,800);\n  int numberOfObjects = 12;\n  int distance = 100;\n  float inc = (TWO_PI)/numberOfObjects;\n  float x,y;\n  float a = 0;\n\n  for (int i=0; i < numberOfObjects; i++) {\n    x = (width/2) + sin(a)*distance;\n    y = (height/2) + cos(a)*distance;\n    ellipse(x,y,10,10);\n    a += inc;\n\n  }\n}\n\nUse modulus to make a grid\n\nThe modulus operator, represented by %, returns the remainder of a division. Fallen into a coma yet? Hold on a minute \u2013 this seemingly simple function is very powerful in lots of ways. At a simple level, you can use it to determine if a number is odd or even, great for creating alternate row colours in a table for instance:\n\nboolean checkForEven(numberToCheck) {\n  if (numberToCheck % 2 == 0) \n    return true;\n  } else {\n    return false; \n  }\n}\n\nThat\u2019s all well and good, but here\u2019s a use of modulus that might very well blow your mind. Construct a grid with only a few lines of code. Again the example is in Processing but can easily be ported to any other language.\n\nvoid setup() {\n\nsize(600,600);\nint numItems = 120;\nint numOfColumns = 12;\nint xSpacing = 40;\nint ySpacing = 40;\nint totalWidth = xSpacing*numOfColumns;\n\nfor (int i=0; i < numItems; i++) {\n\nellipse(floor((i*xSpacing)%totalWidth),floor((i*xSpacing)/totalWidth)*ySpacing,10,10);\n\n}\n}\n\nNot all the bits of code I keep around are for actual graphical output. I also have things that are very utilitarian, but which I still consider part of the design process. Here\u2019s a couple of things that I\u2019ve found really handy lately in my design workflow. They may be a little specific, but I hope they demonstrate that it\u2019s not about working harder, it\u2019s about working smarter. \n\nMerge CSV files into one file\n\nRecently, I\u2019ve had to work with huge \u2013 about 1GB \u2013 CSV text files that I then needed to combine into one master CSV file so I could then process the data. Opening up each text file and then copying and pasting just seemed really dumb, not to mention slow, so I thought there must be a better way. After some Googling I found this command line script that would combine .txt files into one file and add a new line after each:  \n\nawk 1 *.txt > finalfile.txt\n\nBut that wasn\u2019t what I was ideally after. I wanted to merge the CSV files, keeping the first row of the first file (the column headings) and then ignore the first row of subsequent files. Sure enough I found the answer after some Googling and it worked like a charm. Apologies to the original author but I can\u2019t remember where I found it, but you, sir or madam, are awesome. Save this as a shell script:\n\nFIRST=\n\nfor FILE in *.csv\n  do\n    exec 5<\"$FILE\" # Open file\n    read LINE <&5 # Read first line\n      [ -z \"$FIRST\" ] && echo \"$LINE\" # Print it only from first file\n      FIRST=\"no\"\n\n      cat <&5 # Print the rest directly to standard output\n      exec 5<&- # Close file\n      # Redirect stdout for this section into file.out \n\ndone > file.out\n\nCreate a symbolic link to another file or folder\n\nOftentimes, I\u2019ll find myself hunting through a load of directories to load a file to be processed, like a CSV file. Use a symbolic link (in the Terminal) to place a link on your desktop or wherever is most convenient and it\u2019ll save you loads of time. Especially great if you\u2019re going through a Java file dialogue box in Processing or something that doesn\u2019t allow the normal Mac dialog box or aliases.\n\ncd /DirectoryYouWantShortcutToLiveIn\nln -s /Directory/You/Want/ShortcutTo/ TheShortcut\n\nYou can do it, in the mix\n\nI hope you\u2019ve found some of the above useful and that they\u2019ve inspired a few ideas here and there. Feel free to tell me better ways of doing things or offer up any other handy pieces of code. Most of all though, collect, remix and combine the things you discover to make lovely new things.", "year": "2012", "author": "Brendan Dawes", "author_slug": "brendandawes", "published": "2012-12-17T00:00:00+00:00", "url": "https://24ways.org/2012/cut-copy-paste/", "topic": "code"}
{"rowid": 156, "title": "Mobile 2.0", "contents": "Thinking 2.0\n\nAs web geeks, we have a thick skin towards jargon. We all know that \u201cWeb 2.0\u201d has been done to death. At Blue Flavor we even have a jargon bucket to penalize those who utter such painfully overused jargon with a cash deposit. But Web 2.0 is a term that has lodged itself into the conscience of the masses. This is actually a good thing.\n\nThe 2.0 suffix was able to succinctly summarize all that was wrong with the Web during the dot-com era as well as the next evolution of an evolving media. While the core technologies actually stayed basically the same, the principles, concepts, interactions and contexts were radically different.\n\nWith that in mind, this Christmas I want to introduce to you the concept of Mobile 2.0. While not exactly a new concept in the mobile community, it is relatively unknown in the web community. And since the foundation of Mobile 2.0 is the web, I figured it was about time for you to get to know each other.\n\nIt\u2019s the Carriers\u2019 world. We just live in it.\n\nBefore getting into Mobile 2.0, I thought first I should introduce you to its older brother. You know the kind, the kid with emotional problems that likes to beat up on you and your friends for absolutely no reason. That is the mobile of today.\n\nThe mobile ecosystem is a very complicated space often and incorrectly compared to the Web. If the Web was a freewheeling hippie \u2014 believing in freedom of information and the unity of man through communities \u2014 then Mobile is the cutthroat capitalist \u2014 out to pillage and plunder for the sake of the almighty dollar. Where the Web is relatively easy to publish to and ultimately make a buck, Mobile is wrought with layers of complexity, politics and obstacles. \n\nI can think of no better way to summarize these challenges than the testimony of Jason Devitt to the United States Congress in what is now being referred to as the \u201ciPhone Hearing.\u201d Jason is the co-founder and CEO of SkyDeck a new wireless startup and former CEO of Vindigo an early pioneer in mobile content.\n\n\n\nAs Jason points out, the mobile ecosystem is a closed door environment controlled by the carriers, forcing the independent publisher to compete or succumb to the will of corporate behemoths.\n\nBut that is all about to change.\n\nIntroducing Mobile 2.0\n\nMobile 2.0 is term used by the mobile community to describe the current revolution happening in mobile. It describes the convergence of mobile and web services, adding portability, ubiquitous connectivity and location-aware services to add physical context to information found on the Web.\n\nIt\u2019s an important term that looks toward the future. Allowing us to imagine the possibilities that mobile technology has long promised but has yet to deliver. It imagines a world where developers can publish mobile content without the current constraints of the mobile ecosystem.\n\nLike the transition from Web 1.0 to 2.0, it signifies the shift away from corporate or brand-centered experiences to user-centered experiences. A focus on richer interactions, driven by user goals. Moving away from proprietary technologies to more open and standard ones, more akin to the Web. And most importantly (from our perspective as web geeks) a shift away from kludgy one-off mobile applications toward using the Web as a platform for content and services.\n\nThis means the world of the Web and the world of Mobile are coming together faster than you can say ARPU (Average Revenue Per User, a staple mobile term to you webbies). And this couldn\u2019t come at a better time. The importance of understanding and addressing user context is quickly becoming a crucial consideration to every interactive experience as the number of ways we access information on the Web increases.\n\nMobile enables the power of the Web, the collective information of millions of people, inherit payment channels and access to just about every other mass media to literally be overlaid on top of the physical world, in context to the person viewing it. \n\nAnyone who can\u2019t imagine how the influence of mobile technology can\u2019t transform how we perform even the simplest of daily tasks needs to get away from their desktop and see the new evolution of information.\n\nThe Instigators\n\nBut what will make Mobile 2.0 move from idillic concept to a hardened market reality in 2008 will be four key technologies. Its my guess that you know each them already.\n\n1. Opera\n\nOpera is like the little train that could. They have been a driving force on moving the Web as we know it on to mobile handsets. Opera technology has proven itself to be highly adaptable, finding itself preloaded on over 40 million handsets, available on televisions sets through Nintendo Wii or via the Nintendo DS.\n\n2. WebKit\n\nMany were surprised when Apple chose to use KHTML instead of Gecko (the guts of Firefox) to power their Safari rendering engine. But WebKit has quickly evolved to be a powerful and flexible browser in the mobile context. WebKit has been in Nokia smartphones for a few years now, is the technology behind Mobile Safari in the iPhone and the iPod Touch and is the default web technology in Google\u2019s open mobile platform effort, Android.\n\n3. The iPhone\n\nThe iPhone has finally brought the concepts and principles of Mobile 2.0 into the forefront of consumers minds and therefore developers\u2019 minds as well. Over 500 web applications have been written specifically for the iPhone since its launch. It\u2019s completely unheard of to see so many applications built for the mobile context in such a short period of time.\n\n4. CSS & Javascript\n\nWeb 2.0 could not exist without the rich interactions offered by CSS and Javascript, and Mobile 2.0 is no different. CSS and Javascript support across multiple phones historically has been, well\u2026 to put it positively\u2026 utter crap.\n\nJavascript finally allows developers to create interesting interactions that support user goals and the mobile context. Specially, AJAX allows us to finally shed the days of bloated Java applications and focus on portable and flexible web applications. While CSS \u2014 namely CSS3 \u2014 allows us to create designs that are as beautiful as they are economical with bandwidth and load times.\n\nWith Leaflets, a collection of iPhone optimized web apps we created, we heavily relied on CSS3 to cache and reuse design elements over and over, minimizing download times while providing an elegant and user-centered design.\n\n\n\nIn Conclusion\n\nIt is the combination of all these instigators that is significantly decreasing the bar to mobile publishing. The market as Jason Devitt describes it, will begin to fade into the background. And maybe the world of mobile will finally start looking more like the Web that we all know and love.\n\nSo after the merriment and celebration of the holiday is over and you look toward the new year to refresh and renew, I hope that you take a seriously consider the mobile medium. \n\nBy this time next year, it is predicted that one-third of humanity will be using mobile devices to access the Web.", "year": "2007", "author": "Brian Fling", "author_slug": "brianfling", "published": "2007-12-21T00:00:00+00:00", "url": "https://24ways.org/2007/mobile-2-0/", "topic": "business"}
{"rowid": 150, "title": "A Gift Idea For Your Users: Respect, Yo", "contents": "If, indeed, it is the thought that counts, maybe we should pledge to make more thoughtful design decisions.  In addition to wowing people who use the Web sites we build with novel features, nuanced aesthetics and the new new thing, maybe we should also thread some subtle things throughout our work that let folks know:  hey, I\u2019m feeling ya.  We\u2019re simpatico.  I hear you loud and clear.\n\nIt\u2019s not just holiday spirit that moves me to talk this way.  As good as people are, we need more than the horizon of karma to overcome that invisible demon, inertia.  Makers of the Web, respectful design practices aren\u2019t just the right thing, they are good for business.  Even if your site is the one and only place to get experience x, y or zed, you don\u2019t rub someone\u2019s face in it.  You keep it free flowing, you honor the possible back and forth of a healthy transaction, you are Johnny Appleseed with the humane design cues.  You make it clear that you are in it for the long haul.\n\nA peek back:\n\n\n\nThink back to what search (and  strategy) was like before Google launched a super clean page with \u201cI\u2019m Feeling Lucky\u201d button.  Aggregation was the order of the day (just go back and review all the \u2018strategic alliances\u2019 that were announced daily.)  Yet the GOOG comes along with this zen layout (nope, we\u2019re not going to try to make you look at one of our media properties) and a bold, brash, teleport-me-straight-to-the-first-search-result button.  It could have been titled \u201cWe\u2019re Feeling Cocky\u201d.  These were radical design decisions that reset how people thought about search services.  Oh, you mean I can just find what I want and get on with it?\n\nIt\u2019s maybe even more impressive today, after the GOOG has figured out how to monetize attention better than anyone.  \u201cI\u2019m Feeling Lucky\u201d is still there.  No doubt, it costs the company millions.  But by leaving a little money on the table, they keep the basic bargain they started to strike in 1997.  We\u2019re going to get you where you want to go as quickly as possible.\n\nWhere are the places we might make the same kind of impact in our work?  Here are a few ideas:\n\nRespect People\u2019s Time\n\nAs more services become more integrated with our lives, this will only become more important.  How can you make it clear that you respect the time a user has granted you?\n\nUser-Oriented Defaults\n\nDefault design may be the psionic tool in your belt.  Unseen, yet pow-er-ful.  Look at your defaults.  Who are they set up to benefit?  Are you depending on users not checking off boxes so you can feel ok about sending them email they really don\u2019t want?  Are you depending on users not checking off boxes so you tilt privacy values in ways most beneficial for your SERPs?  Are you making it a little too easy for 3rd party applications to run buckwild through your system?\n\nThere\u2019s being right and then there\u2019s being awesome.  Design to the spirit of the agreement and not the letter.\n\nSee this?\n\n\n\nMake sure that\u2019s really the experience you think people want.  Whenever I see a service that defaults to not opting me in their newsletter just because I bought a t shirt from them, you can be sure that I trust them that much more.  And they are likely to see me again.\n\nReduce, Reuse\n\nIt\u2019s likely that people using your service will have data and profile credentials elsewhere.  You should really think hard about how you can let them repurpose some of that work within your system.  Can you let them reduce the number of logins/passwords they have to manage by supporting OpenID?  Can you let them reuse profile information from another service by slurping in (or even subscribing) to hCards?  Can you give them a leg up by reusing a friends list they make available to you?  (Note:  please avoid the anti-pattern of inviting your user to upload all her credential data from 3rd party sites into your system.)\n\nThis is a much larger issue, and if you\u2019d like to get involved, have a look at the wiki, and dive in.\n\nMake it simple to leave\n\nOh, this drives me bonkers.  Again, the more simple you make it to increase or decrease involvement in your site, or to just opt-out altogether, the better.  This example from Basecamp is instructive:\n\n\n\nAt a glance, I can see what the implications are of choosing a different type of account.  I can also move between account levels with one click.  Finally, I can cancel the service easily.  No hoop jumping.  Also, it should be simple for users to take data with them or delete it.\n\nLet Them Have Fun\n\nDon\u2019t overlook opportunities for pleasure.  Even the most mundane tasks can be made more enjoyable.  Check out one of my favorite pieces of interaction design from this past year:\n\n\n\nHoly knob fiddling, Batman!  What a great way to get people to play with preference settings:  an equalizer metaphor.  Those of a certain age will recall how fun it was to make patterns with your uncle\u2019s stereo EQ.  I think this is a delightful way to encourage people to optimize their own experience of the news feed feature.  Given the killer nature of this feature, it was important for Facebook to make it easy to fine tune.\n\nI\u2019d also point you to Flickr\u2019s Talk Like A Pirate Day Easter egg as another example of design that delights.  What a huge amount of work for a one-off, totally optional way to experience the site.  And what fun.  And how true to its brand persona.  Brill.\n\nAnti-hype\n\nDon\u2019t talk so much.  Rather, ship and sample.  Release code, tell the right users.  See what happens.   Make changes.  Extend the circle a bit by showing some other folks.  Repeat.\n\nThe more you hype coming features, the more you talk about what isn\u2019t yet, the more you build unrealistic expectations.  Your genius can\u2019t possibly match our collective dreaming.  Disappointment is inevitable.  Yet, if you craft the right melody and make it simple for people to hum your tune, it will spread.  Give it time.  Listen.\n\nSpeak the Language of the Tribe\n\nIt\u2019s respectful to speak in a human way.  Not that you have to get all zOMGWTFBBQ!!1 in your messaging.  People respond when you speak to them in a way that sounds natural.  Natural will, of course, vary according to context.  Again, listen in and people will signal the speech that works in that group for those tasks.  Reveal those cues in your interface work and you\u2019ll have powerful proof that actual people are working on your Web site.\n\nThis example of Pownce\u2018s gender selector is the kind of thing I\u2019m talking about:\n\n\n\nNow, this doesn\u2019t mean you should mimic the lingo on some cool kidz site.  Your service doesn\u2019t need to have a massage when it\u2019s down.  Think about what works for you and your tribe.  Excellent advice here from Feedburner\u2019s Dick Costolo on finding a voice for your service.  Also, Mule Design\u2019s Erika Hall has an excellent talk on improving your word fu.\n\nPass the mic, yo\n\nHere is a crazy idea:  you could ask your users what they want.  Maybe you could even use this input to figure out what they really want.  Tools abound.  Comments, wikis, forums, surveys.  Embed the sexy new Get Satisfaction widget and have a dynamic FAQ running.\n\nThe point is that you make it clear to people that they have a means of shaping the service with you.  And you must showcase in some way that you are listening, evaluating and taking action against some of that user input.\n\nYou get my drift.  There are any number of ways we can show respect to those who gift us with their time, data, feedback, attention, evangelism, money.  Big things are in the offing.  I can feel the love already.", "year": "2007", "author": "Brian Oberkirch", "author_slug": "brianoberkirch", "published": "2007-12-23T00:00:00+00:00", "url": "https://24ways.org/2007/a-gift-idea-for-your-users-respect-yo/", "topic": "ux"}
{"rowid": 23, "title": "Animating Vectors with SVG", "contents": "It is almost 2014 and fifteen years ago the W3C started to develop a web-based scalable vector graphics (SVG) format. As web technologies go, this one is pretty old and well entrenched. \n\nSee the Pen yJflC by Drew McLellan (@drewm) on CodePen\n\n\nEmbed not working on your device? Try direct. \n\nUnlike rasterized images, SVG files will stay crisp and sharp at any resolution. With high-DPI phones, tablets and monitors, all those rasterized icons are starting to look a bit old and blocky. There are several options to get simpler, decorative pieces to render smoothly and respond to various device widths, shapes and sizes. Symbol fonts are one option; the other is SVG.\n\nI\u2019m a big fan of SVG. SVG is an XML format, which means it is possible to write by hand or to script. The most common way to create an SVG file is through the use of various drawing applications like Illustrator, Inkscape or Sketch. All of them open and save the SVG format.\n\nBut, if SVG is so great, why doesn\u2019t it get more attention?\n\nThe simple answer is that for a long time it wasn\u2019t well supported, so no one touched the technology. SVG\u2019s adoption has always been hampered by browser support, but that\u2019s not the case any more. Every modern browser (at least three versions back) supports SVG. Even IE9. \n\nAlthough the browsers support SVG, it is implemented in many different ways.\n\nSVG in HTML\n\nSome browsers allow you to embed SVG right in the HTML: the <svg> element. Treating SVG as a first-class citizen works \u2014 sometimes. Another way to embed SVG is via the <img> element; using the src attribute, you can refer to an SVG file. Again, this only works sometimes and leaves you in a tight space if you need to have a fallback for older browsers. The most common solution is to use the <object> element, with the data attribute referencing the SVG file. When a browser does not support this, it falls back to the content inside the <object>. This could be a rasterized fallback <img>. This method gets you the best of both worlds: a nice vector image with an alternative rasterized image for browsers that don\u2019t support SVG. The downside is that you need to manage both formats, and some browsers will download both the SVG and the rasterized version, becoming a performance problem.\n\nAlexey Ten came up with a brilliant little trick that uses inline SVG combined with an SVG <image> element. This has an SVG href pointing to the vector SVG representation and a src attribute to the rasterized version. Older browsers will rewrite the <image> element as <img> and use the rasterized src attribute, but modern browsers will show the vector SVG.\n\n<svg width=\"96\" height=\"96\">\n    <image xlink:href=\"svg.svg\" src=\"svg.png\" width=\"96\" height=\"96\"/>\n</svg>\n\nIt is a great workaround for most situations. You will have to determine the browsers you want or need to support and consider performance issues to decide which method is best for you.\n\nSo it can be used in HTML. Why?\n\nThere are two compelling reasons why vector graphics in the form of icons and symbols are going to be important on the web. With higher resolution screens, going from 72dpi to 200, 300, even over 400dpi, your rasterized icons are looking a little too blocky. As we zoom and print, we expect the visuals on the site to also stay smooth and crisp.\n\nThe other main reason vector graphics are useful is scaling. As responsive websites become the norm, we need a way to dynamically readjust the heights, widths and styles of various elements. SVG handles this perfectly, since vectors remain smooth when changing size.\n\nSVG files are text-based, so they\u2019re small and can be gzipped nicely. There are also techniques for creating SVG sprites to further squeeze out performance gains. But SVG really shines when you begin to couple it with JavaScript. Since SVG elements are part of the DOM, they can be interacted with just like any other element you are used to.\n\nThe folks at Vox Media had an ingenious little trick with their SVG for a Playstation and Xbox One reviews. I\u2019ve used the same technique for the 24 ways example. Vox Media spent a lot of time creating SVG line art of the two consoles, but once in place the artwork scaled and resized beautifully. \n\nThey still had another trick up their sleeves. In their example, they knew each console was line art, so they used SVG\u2019s line dash property to simulate the lines being drawn by animating the growth of the line by small percentage increments until the lines were complete.\n\nThis is a great example of a situation where the alternatives wouldn\u2019t be as straightforward to implement. Using an animated GIF would create a heavy file since it would need to contain all the frames of the animation at a large size to permit scaling; even then, smooth aliasing would be lost. canvas and plenty of JavaScript would be another alternative, but this is a rasterized format. It would need be redrawn at each scale, which is certainly possible, but smoothness would be lost when zooming or printing.\n\nThe HTML, SVG and JavaScript for this example is less than 4KB! Let\u2019s have a quick look at the code:\n\n<script>\nvar current_frame = 0;\nvar total_frames = 60;\nvar path = new Array();\nvar length = new Array();\nfor(var i=0; i<4;i++){\n\tpath[i] = document.getElementById('i'+i);\n\tl = path[i].getTotalLength();\n\tlength[i] = l;\n\tpath[i].style.strokeDasharray = l + ' ' + l; \n\tpath[i].style.strokeDashoffset = l;\n}\nvar handle = 0;\n\nvar draw = function() {\n   var progress = current_frame/total_frames;\n   if (progress > 1) {\n     window.cancelAnimationFrame(handle);\n   } else {\n     current_frame++;\n     for(var j=0; j<path.length;j++){\n\t     path[j].style.strokeDashoffset = Math.floor(length[j] * (1 - progress));\n     }\n     handle = window.requestAnimationFrame(draw);\n   }\n};\ndraw();\n</script>\n\nFirst, we need to initialize a few variables to set the current frame, the number of frames, how fast the animation will run, and we get each of the paths based on their IDs. With those paths, we set the dash and dash offset.\n\npath[i].style.strokeDasharray = l + ' ' + l; \npath[i].style.strokeDashoffset = l;\n\nWe start the line as a dash, which effectively makes it blank or invisible.\n\nNext, we move to the draw() function. This is where the magic happens. We want to increment the frame to move us forward in the animation and check it\u2019s not finished. If it continues, we then take a percentage of the distance based on the frame and then set the dash offset to this new percentage. This gives the illusion that the line is being drawn. Then we have an animation callback, which starts the draw process over again.\n\nThat\u2019s it! It will work with any SVG <path> element that you can draw.\n\nLibraries to get you started\n\nIf you aren\u2019t sure where to start with SVG, there are several libraries out there to help. They also abstract all browser compatibility issues to make your life easier.\n\n\n\tRapha\u00ebl\n\tSnap.svg\n\tsvg.js\n\n\nYou can also get most vector applications to export SVG. This means that you can continue your normal workflows, but instead of flattening the image as a PNG or bringing it over to Photoshop to rasterize, you can keep all your hard work as vectors and reap the benefits of SVG.", "year": "2013", "author": "Brian Suda", "author_slug": "briansuda", "published": "2013-12-07T00:00:00+00:00", "url": "https://24ways.org/2013/animating-vectors-with-svg/", "topic": null}
{"rowid": 89, "title": "Direction, Distance and Destinations", "contents": "With all these new smartphones in the hands of lost and confused owners, we need a better way to represent distances and directions to destinations. The immediate examples that jump to mind are augmented reality apps which let you see another world through your phone\u2019s camera. While this is interesting, there is a simpler way: letting people know how far away they are and if they are getting warmer or colder. \n\nIn the app world, you can easily tap into the phone\u2019s array of sensors such as the GPS and compass, but what people rarely know is that you can do the same with HTML. The native versus web app debate will never subside, but at least we can show you how to replicate some of the functionality progressively in HTML and JavaScript.\n\nIn this tutorial, we\u2019ll walk through how to create a simple webpage listing distances and directions of a few popular locations around the world. We\u2019ll use JavaScript to access the device\u2019s geolocation API and also attempt to access the compass to get a heading. Both of these APIs are documented, to be included in the W3C geolocation API specification, and can be used on both desktop and mobile devices today.\n\nTo get started, we need a list of a few locations around the world. I have chosen the highest mountain peak on each continent so you can see a diverse set of distances and directions. \n\n\n\t\t\n\t\t\tMountain \n\t\t\t\u00b0Latitude \n\t\t\t\u00b0Longitude \n\t\t\n\t\t\n\t\t\tKilimanjaro\n\t\t\t-3.075833\n\t\t\t37.353333\n\t\t\n\t\t\n\t\t\tVinson Massif\n\t\t\t-78.525483\n\t\t\t-85.617147\n\t\t\n\t\t\n\t\t\tPuncak Jaya\n\t\t\t-4.078889\n\t\t\t137.158333\n\t\t\n\t\t\n\t\t\tEverest\n\t\t\t27.988056\n\t\t\t86.925278\n\t\t\n\t\t\n\t\t\tElbrus\n\t\t\t43.355\n\t\t\t42.439167\n\t\t\n\t\t\n\t\t\tMount McKinley\n\t\t\t63.0695\n\t\t\t-151.0074\n\t\t\n\t\t\n\t\t\tAconcagua\n\t\t\t-32.653431\n\t\t\t-70.011083\n\t\t\n\n\nSource: Wikipedia \n\nWe can put those into an HTML list to be styled and accessed by JavaScript to create some distance and directions calculations.\n\nThe next thing we need to do is check to see if the browser and operating system have geolocation support. To do this we test to see if the function is available or not using a single JavaScript if statement.\n\n<script>\n// If this is true, then the method is supported and we can try to access the location\nif (navigator.geolocation) {\n\tnavigator.geolocation.getCurrentPosition(geo_success, geo_error);\n}\n</script>\n\nThe if statement will be false if geolocation support is not present, and then it is up to you to do something else instead as a fallback. For this example, we\u2019ll do nothing since our page should work as is and only get progressively better if more functionality is available. \n\nThe if statement will be true if there is support and therefore will continue inside the curly brackets to try to get the location. This should prompt the reader to accept or deny the request to get their location. If they say no, the second function callback is processed, in this case a function called geo_error; whereas if the location is available, it fires the geo_success function callback.\n\nThe function geo_error(){ } isn\u2019t that exciting. You can handle this in any way you see fit. The success function is more interesting. We get a position object passed into the function which contains a series of exciting attributes, namely the latitude and longitude of the device\u2019s current location.\n\nfunction geo_success(position){\n\tgLat = position.coords.latitude;\n\tgLon = position.coords.longitude;\n}\n\nNow, in the variables gLat and gLon we have the user\u2019s approximate geographical position. We can use this information to start to calculate some distances between where they are and all the destinations.\n\nAt the time of writing, you can also get position.coords.heading, but on Windows and iOS devices this returned NULL. In the future, if and when this is supported, this is also where you can easily grab the compass information.\n\nInside the geo_success function, we want to loop through the HTML to get all of the mountain peaks\u2019 latitudes and longitudes and compute the distance.\n\n...\n$('.geo').each(function(){\n\t// Get the lat/lon from the HTML\n\ttLat = $(this).find('.lat').html()\n\ttLon = $(this).find('.lon').html()\n\n\t// compute the distances between the current location and this points location\n\tdist = distance(tLat,tLon,gLat,gLon);\n\n\t// set the return values into something useful\n\td = parseInt(dist[0]*10)/10;\n\ta = parseFloat(dist[1]);\n\n\t// display the value in the HTML and style the arrow\n\t$(this).find('.distance').html(d+' km away');\n\t$(this).find('.direction').css('-webkit-transform','rotate(-' + a + 'deg)');\n\n\t// store the arc for later use if compass is available\n\t$(this).attr('data-arc',a);\n}\n\nIn the variable d we have the distance between the current location and the location of the mountain peak based on the Haversine Formula. The variable a is the arc, which has a value from 0 to 359.99. This will be useful later if we have compass support. Given these two values we have a distance and a heading to style the HTML.\n\nThe next thing we want to do is check to see if the device has a compass and then get access to the the current heading. As we\u2019ll see, there are several ways to do this, some of which work on certain devices but not others. The W3C geolocation spec says that, along with the coordinates, there are several other attributes: accuracy; altitude; and heading. Heading is the direction to true north, which is different than magnetic north! WebKit and Windows return NULL for the heading value, but WebKit has an experimental method to fetch the heading. If you get into accessing these sensors, you\u2019ll have to try to catch a few of these methods to finally get a value. Assuming you do, we can move on to the more interesting display opportunities.\n\nIn an ideal world, this would succeed and set a variable we\u2019ll call compassHeading to get a value between 0 and 359.99 degrees. Now we know which direction north is, we also know the direction relative to north of the path to our destination, so we can can subtract the two values to get an arrow to display on the screen. But we\u2019re not finished yet: we also need to get the device\u2019s orientation (landscape or portrait) and subtract the correct amount from the angle for the arrow. Once we have a value, we can use CSS to rotate the arrow the correct number of degrees.\n\n-webkit-transform: rotate(-180deg)\n\nNot all devices support a standard way to access compass information, so in the meantime we need to use a work around. On iOS, you can use the experimental event method e.webkitCompassHeading. We want the compass to update in real time as the device is moved around, so we\u2019ll put this inside an event listener.\n\nwindow.addEventListener('deviceorientation', function(e) {\n\t// Loop through all the locations on the page\n\t$('.geo').each(function(){\n\t\t// get the arc value from north we computed and stored earlier\n\t\tdestination_arc = parseInt($(this).attr('data-arc'))\n\t\tcompassHeading = e.webkitCompassHeading + window.orientation + destination_arc;\n\t\t// find the arrow element and rotate it accordingly\n\t\t$(this).find('.direction').css('-webkit-transform','rotate(-' + compassHeading + 'deg)');\t\t\n\t}\n}\n\nAs the device is rotated, the compass arrow will constantly be updated. If you want to see an example, you can have a look at this page which shows the distances to all the peaks on each continent.\n\nWith progressive enhancement, we slowly layer on additional functionality as we go. The reader will first see the list of locations with a latitude and longitude. If the device is capable and permissions allow, it will then compute the distance. If a compass is available, with the correct permissions it will then add the final layer which is direction.\n\nYou should consider this code a stub for your projects. If you are making a hyperlocal webpage with restaurant locations, for example, then consider adding these features. Knowing not only how far away a place is, but also the direction can be hugely important, and since the compass is always active, it acts as a guide to the location. \n\nFuture developments\n\nImprovements to this could include setting a timer and recalling the navigator.geolocation.getCurrentPosition() function and updating the distances. I chose very distant mountains so kilometres made sense, but you can divide again by 1,000 to convert to metres if you are dealing with much nearer places. Walking or driving would change the distances so the ability to refresh would be important. \n\nIt is outside the scope of this article, but if you manage to get this HTML to work offline, then you can make a nice web app which sits on your devices\u2019 homescreens and works even without an internet connection. This could be ideal for travellers in an unknown city looking for your destination. Just with offline storage, base64 encoding and data URIs, it is possible to embed plenty of design and functionality into a small offline webpage.\n\nNow you know how to use JavaScript to look up a destination\u2019s location and figure out the distance and direction \u2013 never get lost again.", "year": "2012", "author": "Brian Suda", "author_slug": "briansuda", "published": "2012-12-19T00:00:00+00:00", "url": "https://24ways.org/2012/direction-distance-and-destinations/", "topic": "code"}
{"rowid": 100, "title": "Moo'y Christmas", "contents": "A note from the editors:  Moo has changed their API since this article was written.\n                \n                \n                      \n                As the web matures, it is less and less just about the virtual world. It is becoming entangled with our world and it is harder to tell what is virtual and what is real. There are several companies who are blurring this line and make the virtual just an extension of the physical. Moo is one such company. \n\nMoo offers simple print on demand services. You can print business cards, moo mini cards, stickers, postcards and more. They give you the ability to upload your images, customize them, then have them sent to your door. Many companies allow this sort of digital to physical interaction, but Moo has taken it one step further and has built an API. \n\nPrintable stocking stuffers \n\nThe Moo API consists of a simple XML file that is sent to their servers. It describes all the information needed to dynamically assemble and print your object. This is very helpful, not just for when you want to print your own stickers, but when you want to offer them to your customers, friends, organization or community with no hassle. Moo handles the check-out and shipping, all you need to do is what you do best, create! \n\nNow using an API sounds complicated, but it is actually very easy. I am going to walk you through the options so you can easily be printing in no time. \n\nBefore you can begin sending data to the Moo API, you need to register and get an API key. This is important, because it allows Moo to track usage and to credit you. To register, visit http://www.moo.com/api/ and click \u201cRequest an API key\u201d. \n\nIn the following examples, I will use {YOUR API KEY HERE} as a place holder, replace that with your API key and everything will work fine. \n\nFirst thing you need to do is to create an XML file to describe the check-out basket. Open any text-editor and start with some XML basics. Don\u2019t worry, this is pretty simple and Moo gives you a few tools to check your XML for errors before you order. \n\n<?xml version=\"1.0\" encoding=\"UTF-8\"?> \n<moo xsi:noNamespaceSchemaLocation=\"http://www.moo.com/xsd/api_0.7.xsd\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"> \n\t <request>\n\t\t <version>0.7</version>\n\t\t <api_key>{YOUR API KEY HERE}</api_key>\n\t\t <call>build</call>\n\t\t <return_to>http://www.example.com/return.html</return_to>\n\t\t <fail_to>http://www.example.com/fail.html</fail_to>\n\t </request>\n\t <payload>\n\t ...\n\t </payload>\n</moo>\n\nMuch like HTML\u2019s <head> and <body>, Moo has created <request> and <payload> elements all wrapped in a <moo> element. \n\nThe <request> element contains a few pieces of information that is the same across all the API calls. The <version> element describes which version of the API is being used. This is more important for Moo than for you, so just stick with \u201c0.7\u201d for now. \n\nThe <api_key> allows Moo to track sales, referrers and credit your account. \n\nThe <call> element can only take \u201cbuild\u201d so that is pretty straight forward. The <return_to> and <fail_to> elements are URLs. These are optional and are the URLs the customer is redirected to if there is an error, or when the check out process is complete. This allows for some basic branding and a custom \u201cthank you\u201d page which is under your control. That\u2019s it for the <request> element, pretty easy so far! \n\nNext up is the <payload> element. What goes inside here describes what is to be printed. There are two possible elements, we can put <chooser> or we can put <products> directly inside <payload>. They work in a similar ways, but they drop the customer into different parts of the Moo checkout process. \n\nIf you specify <products> then you send the customer straight to the Moo payment process. If you specify <chooser> then you send the customer one-step earlier where they are allowed to pick and choose some images, remove the ones they don\u2019t like, adjust the crop, etc. The example here will use <chooser> but with a little bit of homework you can easily adjust to <products> if you desire. \n\n... \n<chooser> \n\t <product_type>sticker</product_type> \n\t <images> \n\t\t <url>http://example.com/images/christmas1.jpg</url> \n\t </images> \n</chooser> \n...\n\nInside the <chooser> element, we can see there are two basic piece of information. The type of product we want to print, and the images that are to be printed. The <product_type> element can take one of five options and is required! The possibilities are: minicard, notecard, sticker, postcard or greetingcard. We\u2019ll now look at two of these more closely. \n\nMoo Stickers \n\nIn the Moo sticker books you get 90 small squarish stickers in a small little booklet. \n\n\n\nThe simplest XML you could send would be something like the following payload:\n\n...\n<payload>\n\t<chooser>\n\t\t<product_type>sticker</product_type>\n\t\t<images>\n\t\t\t<url>http://example.com/image1.jpg</url>\n\t\t</images>\n\t\t<images>\n\t\t\t<url>http://example.com/image2.jpg</url>\n\t\t</images>\n\t\t<images>\n\t\t\t<url>http://example.com/image3.jpg</url>\n\t\t</images>\n\t</chooser>\n</payload>\n...\n\nThis creates a sticker book with only 3 unique images, but 30 copies of each image. The Sticker books always print 90 stickers in multiples of the images you uploaded. That example only has 3 <images> elements, but you can easily duplicate the XML and send up to 90. The <url> should be the full path to your image and the image needs to be a minimum of 300 pixels by 300 pixels.\n\nYou can add more XML to describe cropping, but the simplest option is to either, let your customers choose or to pre-crop all your images square so there are no issues.\n\nThe full XML you would post to the Moo API to print sticker books would look like this:\n\n<?xml version=\"1.0\" encoding=\"UTF-8\"?> \n<moo xsi:noNamespaceSchemaLocation=\"http://www.moo.com/xsd/api_0.7.xsd\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"> \n\t<request>\n\t\t<version>0.7</version>\n\t\t<api_key>{YOUR API KEY HERE}</api_key>\n\t\t<call>build</call>\n\t\t<return_to>http://www.example.com/return.html</return_to>\n\t\t<fail_to>http://www.example.com/fail.html</fail_to>\n\t</request>\n\t<payload>\n\t\t<chooser>\n\t\t\t<product_type>sticker</product_type>\n\t\t\t<images>\n\t\t\t\t<url>http://example.com/image1.jpg</url>\n\t\t\t</images>\n\t\t\t<images>\n\t\t\t\t<url>http://example.com/image2.jpg</url>\n\t\t\t</images>\n\t\t\t<images>\n\t\t\t\t<url>http://example.com/image3.jpg</url>\n\t\t\t</images>\n\t\t</chooser>\n\t</payload> \n</moo>\n\nMini-cards \n\nThe mini-cards are the small cute business cards in 14\u00d735 dimensions and come in packs of 100. \n\n\n\nSince the mini-cards are print on demand, this allows you to have 100 unique images on the back of the cards.\n\nJust like the stickers example, we need the same XML setup. The <moo> element and <request> elements will be the same as before. The part you will focus on is the <payload> section. \n\nSince you are sending along specific information, we can\u2019t use the <chooser> option any more. Switch this to <products> which has a child of <product>, which in turn has a <product_type> and <designs>. This might seem like a lot of work, but once you have it set up you won\u2019t need to change it.\n\n...\n<payload>\n\t<products>\n\t\t<product>\n\t\t\t<product_type>minicard</product_type>\n\t\t\t<designs>\n\t\t\t\t...\n\t\t\t</designs>\n\t\t</product>\n\t</products>\n</payload>\n...\n\nSo now that we have the basic framework, we can talk about the information specific to minicards. Inside the <designs> element, you will have one <design> for each card. Much like before, this contains a way to describe the image. Note that this time the element is called <image>, not images plural. \n\nInside the <image> element you have a <url> which points to where the image lives and a <type>. The <type> should just be set to \u2018variable\u2019. You can pass crop information here instead, but we\u2019re going to keep it simple for this tutorial. If you are interested in how that works, you should refer to the official API documentation.\n\n...\n<design>\n\t<image>\n\t\t<url>http://example.com/image1.jpg</url>\n\t\t<type>variable</type>\n\t</image>\n</design>\n...\n\nSo far, we have managed to build a pack of 100 Moo mini-cards with the same image on the front. If you wanted 100 different images, you just need to replicate this snippit, 99 more times.\n\nThat describes the front design, but the flip-side of your mini-cards can contain 6 lines of text, which is customizable in a variety of colors, fonts and styles.\n\nThe API allows you to create different text on the back of each mini-card, something the web interface doesn\u2019t implement. To describe the text on the mini-card we need to add a <text_collection> element inside the <design> element. If you skip this element, the back of your mini-card will just be blank, but that\u2019s not very festive!\n\nInside the <text_collection> element, we need to describe the type of text we want to format, so we add a <minicard> element, which in turn contains all the lines of text. Each of Moo\u2019s printed products take different numbers of lines of text, so if you are not planning on making mini-cards, be sure to consult the documentation.\n\nFor mini-cards, we can have 6 distinct lines, each with their own style and layout. Each line is represented by an element <text_line> which has several optional children. The <id> tells which line of the 6 to print the text one. The <string> is the text you want to print and it must be shorter than 38 characters. The <bold> element is false by default, but if you want your text bolded, then add this and set it to true. \n\nThe <align> element is also optional. By default it is set to align left. You can also set this to right or center if you desirer. The <font> element takes one of 3 types, modern, traditional or typewriter. The default is modern. Finally, you can set the <colour>, yes that\u2019s color with a \u2018u\u2019, Moo is a British company, so they get to make the rules. When you start a print on demand company, you can spell it however you want. The <colour> element takes a 6 character hex value with a leading #.\n\n<design>\n\t...\n\t<text_collection>\n\t\t<minicard>\n\t\t\t<text_line>\n\t\t\t\t<id>(1-6)</id>\n\t\t\t\t<string>String, I must be less than 38 chars!</string>\n\t\t\t\t<bold>true</bold>\n\t\t\t\t<align>left</align>\n\t\t\t\t<font>modern</font>\n\t\t\t\t<colour>#ff0000</colour> \n\t\t\t</text_line>\n\t\t</minicard>\n\t</text_collection>\n</design>\n\nIf you combine all of this into a mini-card request you\u2019d get this example:\n\n<?xml version=\"1.0\" encoding=\"UTF-8\"?> \n<moo xsi:noNamespaceSchemaLocation=\"http://www.moo.com/xsd/api_0.7.xsd\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"> \n\t<request>\n\t\t<version>0.7</version>\n\t\t<api_key>{YOUR API KEY HERE}</api_key>\n\t\t<call>build</call>\n\t\t<return_to>http://www.example.com/return.html</return_to>\n\t\t<fail_to>http://www.example.com/fail.html</fail_to>\n\t</request>\n\t<payload>\n\t\t<products>\n\t\t\t<product>\n\t\t\t\t<product_type>minicard</product_type>\n\t\t\t\t<designs>\n\t\t\t\t\t<design>\n\t\t\t\t\t\t<image>\n\t\t\t\t\t\t\t<url>http://example.com/image1.jpg</url>\n\t\t\t\t\t\t\t<type>variable</type>\n\t\t\t\t\t\t</image>\n\t\t\t\t\t\t<text_collection>\n\t\t\t\t\t\t\t<minicard>\n\t\t\t\t\t\t\t\t<text_line>\n\t\t\t\t\t\t\t\t<id>1</id>\n\t\t\t\t\t\t\t\t<string>String, I must be less than 38 chars!</string>\n\t\t\t\t\t\t\t\t<bold>true</bold>\n\t\t\t\t\t\t\t\t<align>left</align>\n\t\t\t\t\t\t\t\t<font>modern</font>\n\t\t\t\t\t\t\t\t<colour>#ff0000</colour> \n\t\t\t\t\t\t\t\t</text_line>\n\t\t\t\t\t\t\t</minicard>\n\t\t\t\t\t\t</text_collection>\n\t\t\t\t\t</design>\n\t\t\t\t</designs>\n\t\t\t</product>\n\t\t</products>\n\t</payload> \n</moo>\n\nNow you know how to construct the XML that describes what to print. Next, you need to know how to send it to Moo to make it happen!\n\nPosting to the API\n\nSo your XML is file ready to go. First thing we need to do is check it to make sure it\u2019s valid. Moo has created a simple validator where you paste in your XML, and it alerts you to problems.\n\nWhen you have a fully valid XML file, you\u2019ll want to send that to the Moo API. There are a few ways to do this, but the simplest is with an HTML form. \n\nThis is the sample code for an HTML form with a big \u201cBuy My Stickers\u201d button. Once you know that it is working, you can use all your existing HTML knowledge to style it up any way you like.\n\n<form method=\"POST\" action=\"http://www.moo.com/api/api.php\">\n\t<input type=\"hidden\" name=\"xml\" value=\"<?xml version=\"1.0\" encoding=\"UTF-8\"?> <moo xsi:noNamespaceSchemaLocation=\"http://www.moo.com/xsd/api_0.7.xsd\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"> <request>....</request> <payload>...</payload> </moo> \"> \n\t<input type=\"submit\" name=\"submit\" value=\"Buy My Stickers\"/>\n</form>\n\nThis is just a basic <form> element that submits to the Moo API, http://www.moo.com/api/api.php, when someone clicks the button. There is a hidden input called \u201cxml\u201d which contains the value the XML file we created previously.\n\nFor those of you who need to \u201cview source\u201d to fully understand what\u2019s happening can see a working version and peek under the hood.\n\nUsing the API has advantages over uploading the images directly yourself. The images and text that you send via the API can be dynamic. Some companies, like Dopplr, have taken user profiles and dynamic data that changes every minute to generate customer stickers of places that you\u2019ve travelled to or mini-cards with a world map of all the cities you have visited. Every single customer has different travel plans and therefore different sets of stickers and mini-card maps. The API allows for the utmost current information to be printed, on demand, in real-time.\n\nGo forth and Moo\u2019ltiply\n\nSee, making an API call wasn\u2019t that hard was it? You are now 90% of the way to creating anything with the Moo API. With a bit of reading, you can learn that extra 10% and print any Moo product. Be on the lookout in 2009 for the official release of the 1.0 API with improvements and some extras that were not available when this article was written.\n\nThis article is released under the creative-commons attribution share-a-like license. That means you are free to re-distribute it, mash it up, translate it and otherwise re-using it ways the author never considered, in return he only asks you mention his name.\n\n\nThis work by Brian Suda is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.", "year": "2008", "author": "Brian Suda", "author_slug": "briansuda", "published": "2008-12-19T00:00:00+00:00", "url": "https://24ways.org/2008/mooy-christmas/", "topic": "code"}
{"rowid": 160, "title": "Tracking Christmas Cheer with Google Charts", "contents": "A note from the editors:  Since this article was written Google has retired the Charts API.\n                \n                \n                      \n                Let\u2019s get something out in the open: I love statistics. As an informatician I can\u2019t get enough graphs, charts, and numbers. So you can imagine when Google released their Charts API I thought Christmas had come early. I immediately began to draw up graphs for the holiday season using the new API; and using my new found chart-making skills I\u2019ll show you what you can and can\u2019t do with Google Charts.\n\nMummy, it\u2019s my first chart\n\nThe Google Charts API allows you to send data to Google; in return they give you back a nicely-rendered graph. All the hard work is done on Google\u2019s servers \u2014 you need only reference an image in your HTML. You pass along the data \u2014 the numbers for the charts, axis labels, and so on \u2014 in the query string of the image\u2019s URL. If you want to add charts to your blog or web site, there\u2019s probably no quicker way to get started.\n\nHere\u2019s a simple example: if we add the following line to an HTML page:\n\n<img src=\"http://chart.apis.google.com/chart?cht=lc&chs=200x125&chd=s:ZreelPuevfgznf2008\" />\n\nThen we\u2019ll see the line graph in Figure 1 appear in our page. That graph is hosted on Google\u2019s own server1: http://chart.apis.google.com/.\n\nFigure 1: A simple example of a line graph created with Google Charts.\n\nIf you look at the URL used in the example you\u2019ll notice we\u2019re passing some parameters along in the query string (the bit after the question mark). The query string looks like this:\n\ncht=lc&chs=200x125&chd=s:ZreelPuevfgznf2008\n\nIt\u2019s contains everything Google Charts needs to draw the graph.  There are three parameters in the query string:\n\n\n\tcht; this specifies the type of chart Google Charts will generate (in this case, lc is a line chart).\n\tchs, the value of which is 200x125; this defines the chart\u2019s size (200 pixels wide by 125 pixels high).\n\tchd, the value of which is s:ZreelPuevfgznf2008; this is the actual chart data, which we\u2019ll discuss in more detail later.\n\n\nThese three parameters are the minimum you need to send to Google Charts in order to create a chart.  There are lots more parameters you can send too (giving you more choice over how a chart is displayed), but you have to include at least these three before a chart can be created. Using these three parameters you can create pie charts, scatter plots, Venn diagrams, bar charts (and more) up to 1,000 pixels wide or 1,000 pixels high (but no more than 300,000 pixels in total).\n\nChristmas pie\n\nAfter I discovered the option to create a pie chart I instantly thought of graphing all the types of food and beverages that I\u2019ll consume at this year\u2019s Christmas feast. I can represent each item as a percentage of all the food on a pie chart (just thinking about that makes me hungry).\n\nBy changing the value of the cht parameter in the image\u2019s query string I can change the chart type from a line chart to a pie chart. Google Charts offers two different types of pie chart: a fancy three-dimensional version and a two-dimensional overhead version. I want to stick with the latter, so I need to change cht=lc to cht=p (the p telling Google Charts to create a pie chart; if you want the three-dimensional version, use cht=p3). As a pie chart is circular I also need to adjust the size of the chart to make it square. Finally, it would be nice to add a title to the graph. I can do this by adding the optional parameter, chtt, to the end of the image URL. I end up with the chart you see in Figure 2.\n\nFigure 2: Pie chart with a title.\n\nTo add this chart to your own page, you include the following (notice that you can\u2019t include spaces in URLs, so you need to encode them as plus-signs.):\n\n<img src=\"http://chart.apis.google.com/chart?chtt=Food+and+Drink+Consumed+Christmas+2007&cht=p&chs=300x300&chd=s:ZreelPuevfgznf2008\" />\n\nOk, that\u2019s great, but there are still two things I want to do before I can call this pie chart complete. First I want to label each slice of the pie. And second I want to include the proper data (at the moment the slices are meaningless). If 2007 is anything like 2006, the break down will be roughly as follows:\n\n\n\t\t\n\t\t\tEgg nog\n\t\t\t10%\n\t\t\n\t\t\n\t\t\tChristmas Ham\n\t\t\t20%\n\t\t\n\t\t\n\t\t\tMilk (not including egg nog)\n\t\t\t8%\n\t\t\n\t\t\n\t\t\tCookies\n\t\t\t25%\n\t\t\n\t\t\n\t\t\tRoasted Chestnuts\n\t\t\t5%\n\t\t\n\t\t\n\t\t\tChocolate\n\t\t\t3%\n\t\t\n\t\t\n\t\t\tVarious Other Beverages\n\t\t\t15%\n\t\t\n\t\t\n\t\t\tVarious Other Foods\n\t\t\t9%\n\t\t\n\t\t\n\t\t\tSnacks\n\t\t\t5%\n\t\t\n\n\nI have nine categories of food and drink to be tracked, so I need nine slice labels. To add these to the chart, I use the chl parameter. All nine labels are sent in one value; I use the vertical-pipe character, |,  to separate them. So I need to append the following to the query string:\n\nchl=Egg+nog|Christmas+Ham|Milk+(not+including+egg+nog)|Cookies|Roast+Chestnuts|Chocolate|Various+Other+Beverages|Various+Other+Foods|Snacks\n\nNext I need to add the corresponding percentage values to the chart labels. Encoding the chart data is the trickiest part of the Google Charts API \u2014 but by no means complicated. There are three different ways to encode your data on a chart. As I\u2019m only dealing with small numbers, I\u2019m going to use what Google calls simple encoding.\n\nSimple encoding offers a sixty-two value spectrum in which to represent data. Remember the mandatory option, chd, from the first example? The value for this is split into two parts: the type of encoding and the graph data itself.  These two parts are separated with a colon.  To use simple encoding, the first character of the chd option must be a lower case s. Follow this with a colon and everything after it is considered data for the graph.\n\nIn simple encoding, you have sixty-two values to represent your data. These values are lowercase and uppercase letters from the Latin alphabet (fifty-two characters in total) and the digits 0 to 9. Each letter of the alphabet represents a single number: A equals 0, B equals 1, and so on up to Z, which equals 25; a equals 26, b equals 27, and so on up to z, which equals 51. The ten digits represent the numbers 52 to 61: 0 equals 52, 1 equals 53, and 9 equals 61.\n\nIn the previous two examples we used the string ZreelPuevfgznf2008 as our chart data; the Z is equal to 25, the r is equal to 42, the e is equal to 30, and so on. I want to encode the percentage values 10, 20, 8, 25, 5, 3, 15, 9 and 5, so in simple encoding I would use the string KUIZFDPJF.\n\nIf you think figuring this out for each chart may make your head explode, don\u2019t worry: help is out there.\n\nDo you remember I said I needed to change the image dimensions to be square, to accommodate the pie chart? Well now I\u2019m including labels I need even more room. And as I\u2019m in a Christmassy mood I\u2019m going to add some festive colours too.\n\nThe optional chco parameter is used to change the chart color. You set this using the same hexadecimal (\u201chex\u201d) notation found in CSS. So let\u2019s make our pie chart green by adding chco=00AF33 (don\u2019t start it with a hash character as in CSS) to the image URL. If we only specify one hex colour for the pie chart Google Charts will use shades of that colour for each of the slices. To choose your own colours, pass a comma separated list of colours. The \u201cMilk\u201d and \u201cCookies\u201d slices were consumed together, so we can make those two slices more of a redish colour.  I\u2019ll use shades of green for the other slices. My chco parameter now looks like this:\n\nchco=00AF33,4BB74C,EE2C2C,CC3232,33FF33,66FF66,9AFF9A,C1FFC1,CCFFCC.\n\nAfter all this, I\u2019m left with the following URL:\n\nhttp://chart.apis.google.com/chart?chco=00AF33,4BB74C,EE2C2C,CC3232,33FF33,66FF66,9AFF9A,C1FFC1,CCFFCC&chl=Egg+nog|Christmas+Ham|Milk+(not+including+egg+nog)|Cookies|Roast+Chestnuts|Chocolate|Various+Other+Beverages|Various+Other+Foods|Snacks&chtt=Food+and+Drink+Consumed+Christmas+2007&cht=p&chs=600x300&chd=s:KUIZFDPJF\n\nWhat does that give us?  I\u2019m glad you asked.  I have the rather beautiful 600-pixel wide pie chart you see in Figure 3.\n\nFigure 3: A Christmassy pie chart with labels.\n\nBut I don\u2019t like pie charts\n\nThe pie chart was invented by the Scottish polymath William Playfair in 1801.  But not everyone is as excited by pie charts as wee Billy, so if you\u2019re an anti-pie-chartist, what can you do?\n\nYou can easily reuse the same data but display it as a bar graph in a snap. The first thing we need to do is change the value of the cht parameter from p to bhg. This creates a horizontal bar graph (you can request a vertical bar graph using bvg). The data and labels all remain the same, but we need to decide where the labels will appear. I\u2019ll talk more about how to do all this in the next section. \n\nIn Figure 4 you\u2019ll see the newly-converted bar graph. The URL for the graph is:\n\nhttp://chart.apis.google.com/chart?cht=bhg&chs=600x300&chd=s:KUIZFDPJF&chxt=x,y&chtt=Food+and+Drink+Consumed+Christmas+2007&chxl=1:|Egg+nog|Christmas+Ham|Milk+(not+including+egg+nog)|Cookies|Roast+Chestnuts|Chocolate|Various+Other+Beverages|Various+Other+Foods|Snacks&chco=00AF33\n\nFigure 4: The pie chart from Figure 3 represented as a bar chart.\n\nTwo lines, one graph\n\nPie charts and bar charts are interesting, but what if I want to compare last year\u2019s Christmas cheer with this year\u2019s? That sounds like I\u2019ll need two lines on one graph.\n\nThe code is much the same as the previous examples; the most obvious difference is I need to set up the chart as a line graph. Creating some dummy values for the required parameters, I end up with:\n\n<img src=\"http://chart.apis.google.com/chart?chs=800x300&cht=lxy&chd=t:0,100|0,100\" />\n\nThe chs=800x300 sets the dimensions of the new chart, while cht=lxy describes the type of chart we are using (in this case a line chart with x and y co-ordinates). For the chart data I\u2019m going to demostrate a different encoding, text encoding. To use this I start the value of the chd parameter with \u201ct:\u201d  instead of \u201cs:\u201d, and follow it with a list of x coordinates, a vertical pipe, |, and a list of y coordinates. Given the URL above, Google Charts will render the chart shown in Figure 5.\n\nFigure 5: A simple line graph with x and y co-ordinates.\n\nTo make this graph a little more pleasing to the eye, I can add much the same as I did to the pie chart. I\u2019ll add a chart title. Maybe something like \u201cProjected Christmas Cheer for 2007\u201d. Just as before I would add a chtt parameter to the image URL:\n\n&chtt=Projected+Christmas+Cheer+for+2007\n\nNext, let\u2019s add some labels on the y axis to represent a scale from 0 to 100. On the x axis let\u2019s label for the most important days of December. To do this I need to use the chart axis type parameter, chxt. This allows us to specify the axes and associate some labels with them. As I\u2019m only interested in the y-axis (to the left of the chart) and the x-axis (below the chart), we add chxt=x,y to our image URL.\n\nNow I need my label data. This is slightly more tricky because I want the data evenly spaced without labelling every item. The parameter for labels is chxl, the chart axis label. You match a label to an axis by using a number. So 0:Label1 is the zero index of chxt \u2014 in this case the x-axis. 1:Label2 is the first index of chxt \u2014 the y-axis. The order of these parameters or labels doesn\u2019t matter as long as you associate them to their chxt correctly.\n\nThe next thing to know about chxl is that you can add an empty label. Labels are separated by vertical pipe; if you don\u2019t put any text in a label, you just leave the two vertical pipes empty (\u201c||\u201d) and Google Charts will allocate space but no label.\n\nFor our vertical y axis, we want to label only 50% and 100% on the graph and plot them in their respective places. Since the y-axis is the second item, 1: (remember to start counting at zero), we add ten spaces to our image URL, chxl=1:||||||50|||||100 This will output the 50 halfway and the 100 at the top; all the other spaces will be empty.\n\nWe can do the same thing to get specific dates along the x-axis as well. Let\u2019s add the 1st of December, St. Nick\u2019s Day (the 6th), Christmas Day, Boxing Day (a holiday common in the UK and the Commonwealth, on the 26th), and the final day of the month, the 31st.  Since this is the x-axis I\u2019ll use 0: as a reference in the chxt parameter tell Google Charts which axis to label. In full, the chxl parameter now looks like:\n\nchxl=1:||||||50|||||100|0:|Dec+1st|||||6th||||10th|||||15th|||||20th|||||25th|26th|||||Dec+31st\n\nThat\u2019s pretty.\n\nBefore we begin to graph our data, I\u2019ll do one last thing: add some grid lines to the chart so to better connect the data to the labels. The parameter for this is chg, short for chart grid lines. The parameter takes four comma-separated arguments. The first is the x-axis spacing for the grid. I have thirty-one days, so I need thirty vertical lines. The chart is 100% wide, so 3.33 (100 divided by 30) is the required spacing.\n\nAs for the y-axis: the axis goes up to 100% but we probably only need to have a horizontal line every 10%, so the required spacing is 10 (100 divided by 10). That is the second argument.\n\nThe last two arguments control the dash-style of the grid-lines. The first number is the length of the line dash and the second is the space between the dashes. So 6,3 would mean a six-unit dash with a three-unit space. I like a ratio of 1,3 but you can change this as you wish. Now that I have the four arguments, the chg parameter looks like:\n\nchg=3.333,10,1,3\n\nIf I add that to the chart URL I end up with:\n\nhttp://chart.apis.google.com/chart?chs=800x300&cht=lxy&chd=t:0,100|0,100&chtt=Projected+Christmas+Cheer+for+2007&chxt=x,y&chxl=0:|Dec+1st|||||6th|||||||||||||||||||25th|26th|||||Dec+31st|1:||||||50|||||100&chg=3.3333,10,1,3\n\nWhich results in the chart shown in Figure 6.\n\nFigure 6: Chart ready to receive the Christmas cheer values.\n\nReal data\n\nNow the chart is ready I can add historical data from 2006 and current data from 2007.\n\nHaving a look at last year\u2019s cheer levels we find some highs and lows through-out the month:\n\n\n\t\t\n\t\t\tDec 1st\n\t\t\tAdvent starts; life is good\n\t\t\t30%\n\t\t\n\t\t\n\t\t\tDec 6th\n\t\t\tSt. Nick\u2019s Day, awake to find good things in my shoes\n\t\t\t45%\n\t\t\n\t\t\n\t\t\tDec 8th\n\t\t\tWent Christmas carolling, nearly froze\n\t\t\t20%\n\t\t\n\t\t\n\t\t\tDec 10th\n\t\t\tChristmas party at work, very nice dinner\n\t\t\t50%\n\t\t\n\t\t\n\t\t\tDec 18th\n\t\t\tPanic Christmas shopping, hate rude people\n\t\t\t15%\n\t\t\n\t\t\n\t\t\tDec 23rd\n\t\t\tOff Work, home eating holiday food\n\t\t\t80%\n\t\t\n\t\t\n\t\t\tDec 25th\n\t\t\tOpened presents, good year, but got socks again from Grandma\n\t\t\t60%\n\t\t\n\t\t\n\t\t\tDec 26th\n\t\t\tBoxing Day; we\u2019re off and no one knows why\n\t\t\t70%\n\t\t\n\t\t\n\t\t\tDec 28th\n\t\t\tThird day of left overs\n\t\t\t40%\n\t\t\n\t\t\n\t\t\tDec 29th\n\t\t\tProcured some fireworks for new years\n\t\t\t55%\n\t\t\n\t\t\n\t\t\tDec 31st\n\t\t\tNew Year\u2019s Eve\n\t\t\t80%\n\t\t\n\n\nSince I\u2019m plotting data for 2006 and 2007 on the same graph I\u2019ll need two different colours \u2014 one for each year\u2019s line \u2014 and a key to denote what each colour represents. The key is controlled by the chdl (chart data legend) parameter. Again, each part of the parameter is separated by a vertical pipe, so for two labels I\u2019ll use chdl=2006|2007. I also want to colour-code them, so I\u2019ll need to add the chco as I did for the pie chart. I want a red line and a green line, so I\u2019ll use chco=458B00,CD2626 and add this to the image URL.\n\nLet\u2019s begin to plot the 2006 data on the Chart, replacing our dummy data of chd=t:0,100|0,100 with the correct information. The chd works by first listing all the x coordinates (each separated by a comma), then a vertical pipe, and then all the y coordinates (also comma-separated). The chart is 100% wide, so I need to convert the days into a percentage of the month.\n\nThe 1st of December is 0 and the 31st is 100. Everything else is somewhere in between. Our formula is:\n\n(d \u2013 1) \u00d7 100 \u00f7 (31 \u2013 1)\n\nWhere d is the day of the month. The formula states that each day will be printed every 3.333 units; so the 6th of December will be printed at 16.665 units. I can repeat the process for the other dates listed to get the following x coordinates: 0,16.7,23.3,33.3,60,76.7,83.3,86.7,93.3,96.7. The y axis coordinates are easy because our scale is 100%, just like our rating, so we can simply copy them across as 30,45,20,50,15,80,60,70,40,55,80. This gives us a final chd value of:\n\nchd=t:0,16.7,23.3,33.3,60,76.7,83.3,86.7,93.3,96.7,100|30,45,20,50,15,80,60,70,40,55,80\n\nOnto 2007: I can put the data for the month so far to see how we are trending.\n\n\n\t\t\n\t\t\tDec 1st\n\t\t\tChristmas shopping finished already\n\t\t\t50%\n\t\t\n\t\t\n\t\t\tDec 4th\n\t\t\tComputer hard disk drive crashed (not Christmas related accident, but put me in a bad mood)\n\t\t\t10%\n\t\t\n\t\t\n\t\t\tDec 6th\n\t\t\tMissed St. Nick\u2019s Day completely due to travelling\n\t\t\t30%\n\t\t\n\t\t\n\t\t\tDec 9th\n\t\t\tDinner with friends before they travel\n\t\t\t55%\n\t\t\n\t\t\n\t\t\tDec 11th\n\t\t\t24ways article goes live\n\t\t\t60%\n\t\t\n\n\nUsing the same system we did for 2006, I can take the five data points and plot them on the chart. The new x axis values will be 0,10,16.7,26.7 and the new y axis 50,10,30,65. We incorporate those into the image URL by appending these values onto the chd parameter we already have, which then becomes:\n\nchd=t:0,16.7,23.3,33.3,60,76.7,83.3,86.7,93.3,96.7,100|30,45,20,50,15,80,60,70,40,55,80|0,10,16.7,26.7,33.3|50,10,30,55,60\n\nPassing this to Google Charts results in Figure 7.\n\nhttp://chart.apis.google.com/chart?chs=800x300&cht=lxy&chd=t:0,100|0,100&chtt=Projected+Christmas+Cheer+for+2007&chxt=x,y&chxl=0:|Dec+1st|||||6th|||||||||||||||||||25th|26th|||||Dec+31st|1:||||||50|||||100&chg=3.3333,10,1,3&chd=t:0,16.7,23.3,33.3,60,76.7,83.3,86.7,93.3,96.7,100|30,45,20,50,15,80,60,70,40,55,80|0,10,16.7,26.7,33.3|50,10,30,55,60&chco=458B00,CD2626&chdl=2006|2007\n\nFigure 7: Projected Christmas cheer for 2006 and 2007.\n\nDid someone mention Edward Tufte?\n\nGoogle Charts are a robust set of chart types that you can create easily and freely using their API. As you can see, you can graph just about anything you want using the line graph, bar charts, scatter plots, venn diagrams and pie charts. One type of chart conspicuously missing from the API is sparklines.  Sparklines were proposed by Edward Tufte as \u201csmall, high resolution graphics embedded in a context of words, numbers, images\u201d.  They can be extremely useful, but can you create them in Google Charts?\n\nThe answer is: \u201cYes, but it\u2019s an undocumented feature\u201d. (The usual disclaimer about undocumented features applies.)\n\nIf we take our original line graph example, and change the value of the cht parameter from lc (line chart) to lfi (financial line chart) the axis-lines are removed. This allows you to make a chart \u2014 a sparkline \u2014 small enough to fit into a sentence. Google uses the lfi type all throughout the their financial site, but it\u2019s not yet part of the official API.\n\n\n\t\t\n\t\t\tMerryChristmas\n\t\t\t\n\t\t\thttp://chart.apis.google.com/chart?cht=lfi&chs=100x15&chd=s:MerryChristmas\n\t\t\n\t\t\n\t\t\t24ways\n\t\t\t\n\t\t\thttp://chart.apis.google.com/chart?cht=lfi&chs=100x15&chd=s:24ways&chco=999999\n\t\t\n\t\t\n\t\t\tHappyHolidays\n\t\t\t\n\t\t\thttp://chart.apis.google.com/chart?cht=lfi&chs=100x15&chd=s:HappyHolidays&chco=ff0000\n\t\t\n\t\t\n\t\t\tHappyNewYear\n\t\t\t\n\t\t\thttp://chart.apis.google.com/chart?cht=lfi&chs=100x15&chd=s:HappyNewYear&chco=0000ff\n\t\t\n\n\nSummary\n\nThe new Google Charts API is a powerful method for creating charts and graphs of all types. If you apply a little bit of technical skill you can create pie charts, bar graphs, and even sparklines as and when you need them. Now you\u2019ve finished ready the article I hope you waste no more time: go forth and chart!\n\nFurther reading\n\n\n\tGoogle Charts API\n\tMore on Google Charts\n\tHow to handle negative numbers\n\t12 Days of Christmas Pie Chart\n\n\n1 In order to remain within the 50,000 requests a day limit the Google Charts API imposes, chart images on this page have been cached and are being served from our own servers. But the URLs work \u2013 try them!", "year": "2007", "author": "Brian Suda", "author_slug": "briansuda", "published": "2007-12-11T00:00:00+00:00", "url": "https://24ways.org/2007/tracking-christmas-cheer-with-google-charts/", "topic": "ux"}
{"rowid": 223, "title": "Calculating Color Contrast", "contents": "Some websites and services allow you to customize your profile by uploading pictures, changing the background color or other aspects of the design. As a customer, this personalization turns a web app into your little nest where you store your data. As a designer, letting your customers have free rein over the layout and design is a scary prospect. So what happens to all the stock text and images that are designed to work on nice white backgrounds? Even the Mac only lets you choose between two colors for the OS, blue or graphite! Opening up the ability to customize your site\u2019s color scheme can be a recipe for disaster unless you are flexible and understand how to find maximum color contrasts.\n\nIn this article I will walk you through two simple equations to determine if you should be using white or black text depending on the color of the background. The equations are both easy to implement and produce similar results. It isn\u2019t a matter of which is better, but more the fact that you are using one at all! That way, even with the craziest of Geocities color schemes that your customers choose, at least your text will still be readable.\n\nLet\u2019s have a look at a range of various possible colors. Maybe these are pre-made color schemes, corporate colors, or plucked from an image.\n\n\n\nNow that we have these potential background colors and their hex values, we need to find out whether the corresponding text should be in white or black, based on which has a higher contrast, therefore affording the best readability. This can be done at runtime with JavaScript or in the back-end before the HTML is served up.\n\nThere are two functions I want to compare. The first, I call \u201950%\u2019. It takes the hex value and compares it to the value halfway between pure black and pure white. If the hex value is less than half, meaning it is on the darker side of the spectrum, it returns white as the text color. If the result is greater than half, it\u2019s on the lighter side of the spectrum and returns black as the text value.\n\nIn PHP:\n\nfunction getContrast50($hexcolor){\n    return (hexdec($hexcolor) > 0xffffff/2) ? 'black':'white';\n}\n\nIn JavaScript:\n\nfunction getContrast50(hexcolor){\n    return (parseInt(hexcolor, 16) > 0xffffff/2) ? 'black':'white';\n}\n\nIt doesn\u2019t get much simpler than that! The function converts the six-character hex color into an integer and compares that to one half the integer value of pure white. The function is easy to remember, but is naive when it comes to understanding how we perceive parts of the spectrum. Different wavelengths have greater or lesser impact on the contrast.\n\nThe second equation is called \u2018YIQ\u2019 because it converts the RGB color space into YIQ, which takes into account the different impacts of its constituent parts. Again, the equation returns white or black and it\u2019s also very easy to implement.\n\nIn PHP:\n\nfunction getContrastYIQ($hexcolor){\n\t$r = hexdec(substr($hexcolor,0,2));\n\t$g = hexdec(substr($hexcolor,2,2));\n\t$b = hexdec(substr($hexcolor,4,2));\n\t$yiq = (($r*299)+($g*587)+($b*114))/1000;\n\treturn ($yiq >= 128) ? 'black' : 'white';\n}\n\nIn JavaScript:\n\nfunction getContrastYIQ(hexcolor){\n\tvar r = parseInt(hexcolor.substr(0,2),16);\n\tvar g = parseInt(hexcolor.substr(2,2),16);\n\tvar b = parseInt(hexcolor.substr(4,2),16);\n\tvar yiq = ((r*299)+(g*587)+(b*114))/1000;\n\treturn (yiq >= 128) ? 'black' : 'white';\n}\n\nYou\u2019ll notice first that we have broken down the hex value into separate RGB values. This is important because each of these channels is scaled in accordance to its visual impact. Once everything is scaled and normalized, it will be in a range between zero and 255. Much like the previous \u201950%\u2019 function, we now need to check if the input is above or below halfway. Depending on where that value is, we\u2019ll return the corresponding highest contrasting color.\n\nThat\u2019s it: two simple contrast equations which work really well to determine the best readability.\n\nIf you are interested in learning more, the W3C has a few documents about color contrast and how to determine if there is enough contrast between any two colors. This is important for accessibility to make sure there is enough contrast between your text and link colors and the background.\n\nThere is also a great article by Kevin Hale on Particletree about his experience with choosing light or dark themes. To round it out, Jonathan Snook created a color contrast picker which allows you to play with RGB sliders to get values for YIQ, contrast and others. That way you can quickly fiddle with the knobs to find the right balance.\n\nComparing results\n\nLet\u2019s revisit our color schemes and see which text color is recommended for maximum contrast based on these two equations.\n\n\n\nIf we use the simple \u201950%\u2019 contrast function, we can see that it recommends black against all the colors except the dark green and purple on the second row. In general, the equation feels the colors are light and that black is a better choice for the text.\n\n\n\nThe more complex \u2018YIQ\u2019 function, with its weighted colors, has slightly different suggestions. White text is still recommended for the very dark colors, but there are some surprises. The red and pink values show white text rather than black. This equation takes into account the weight of the red value and determines that the hue is dark enough for white text to show the most contrast.\n\nAs you can see, the two contrast algorithms agree most of the time. There are some instances where they conflict, but overall you can use the equation that you prefer. I don\u2019t think it is a major issue if some edge-case colors get one contrast over another, they are still very readable.\n\nNow let\u2019s look at some common colors and then see how the two functions compare. You can quickly see that they do pretty well across the whole spectrum.\n\n\n\nIn the first few shades of grey, the white and black contrasts make sense, but as we test other colors in the spectrum, we do get some unexpected deviation. Pure red #FF0000 has a flip-flop. This is due to how the \u2018YIQ\u2019 function weights the RGB parts. While you might have a personal preference for one style over another, both are justifiable.\n\n\n\nIn this second round of colors, we go deeper into the spectrum, off the beaten track. Again, most of the time the contrasting algorithms are in sync, but every once in a while they disagree. You can select which you prefer, neither of which is unreadable.\n\nConclusion\n\nContrast in color is important, especially if you cede all control and take a hands-off approach to the design. It is important to select smart defaults by making the contrast between colors as high as possible. This makes it easier for your customers to read, increases accessibility and is generally just easier on the eyes. \n\nSure, there are plenty of other equations out there to determine contrast; what is most important is that you pick one and implement it into your system.\n\nSo, go ahead and experiment with color in your design. You now know how easy it is to guarantee that your text will be the most readable in any circumstance.", "year": "2010", "author": "Brian Suda", "author_slug": "briansuda", "published": "2010-12-24T00:00:00+00:00", "url": "https://24ways.org/2010/calculating-color-contrast/", "topic": "code"}
{"rowid": 177, "title": "HTML5: Tool of Satan, or Yule of Santa?", "contents": "It would lead to unseasonal arguments to discuss the title of this piece here, and the arguments are as indigestible as the fourth turkey curry of the season, so we\u2019ll restrict our article to the practical rather than the philosophical: what HTML5 can you reasonably expect to be able to use reliably cross-browser in the early months of 2010?\n\nThe answer is that you can use more than you might think, due to the seasonal tinsel of feature-detection and using the sparkly pixie-dust of IE-only VML (but used in a way that won\u2019t damage your Elf).\n\nCanvas\n\ncanvas is a 2D drawing API that defines a blank area of the screen of arbitrary size, and allows you to draw on it using JavaScript. The pictures can be animated, such as in this canvas mashup of Wolfenstein 3D and Flickr. (The difference between canvas and SVG is that SVG uses vector graphics, so is infinitely scalable. It also keeps a DOM, whereas canvas is just pixels so you have to do all your own book-keeping yourself in JavaScript if you want to know where aliens are on screen, or do collision detection.)\n\nPreviously, you needed to do this using Adobe Flash or Java applets, requiring plugins and potentially compromising keyboard accessibility. Canvas drawing is supported now in Opera, Safari, Chrome and Firefox. The reindeer in the corner is, of course, Internet Explorer, which currently has zero support for canvas (or SVG, come to that).\n\nNow, don\u2019t pull a face like all you\u2019ve found in your Yuletide stocking is a mouldy satsuma and a couple of nuts\u2014that\u2019s not the end of the story. Canvas was originally an Apple proprietary technology, and Internet Explorer had a similar one called Vector Markup Language which was submitted to the W3C for standardisation in 1998 but which, unlike canvas, was not blessed with retrospective standardisation.\n\nWhat you need, then, is some way for Internet Explorer to translate canvas to VML on-the-fly, while leaving the other, more standards-compliant browsers to use the HTML5. And such a way exists\u2014it\u2019s a JavaScript library called excanvas. It\u2019s downloadable from http://code.google.com/p/explorercanvas/ and it\u2019s simple to include it via a conditional comment in the head for IE:\n\n<!--[if IE]>\n<script src=\"excanvas.js\"></script>\n<![endif]-->\n\nSimply include this, and your canvas will be natively supported in the modern browsers (and the library won\u2019t even be downloaded) whereas IE will suddenly render your canvas using its own VML engine. Be sure, however, to check it carefully, as the IE JavaScript engine isn\u2019t so fast and you\u2019ll need to be sure that performance isn\u2019t too degraded to use.\n\nForms\n\nSince the beginning of the Web, developers have been coding forms, and then writing JavaScript to check whether an input is a correctly formed email address, URL, credit card number or conforms to some other pattern. The cumulative labour of the world\u2019s developers over the last 15 years makes whizzing round in a sleigh and delivering presents seem like popping to the corner shop in comparison.\n\nWith HTML5, that\u2019s all about to change. As Yaili began to explore on Day 3, a host of new attributes to the input element provide built-in validation for email address formats (input type=email), URLs (input type=url), any pattern that can be expressed with a JavaScript-syntax regex (pattern=\"[0-9][A-Z]{3}\") and the like. New attributes such as required, autofocus, input type=number min=3 max=50 remove much of the tedious JavaScript from form validation.\n\nOther, really exciting input types are available (see all input types). The datalist is reminiscent of a select box, but allows the user to enter their own text if they don\u2019t want to choose one of the pre-defined options. input type=range is rendered as a slider, while input type=date pops up a date picker, all natively in the browser with no JavaScript required at all.\n\nCurrently, support is most complete in an experimental implementation in Opera and a number of the new attributes in Webkit-based browsers. But don\u2019t let that stop you! The clever thing about the specification of the new Web Forms is that all the new input types are attributes (rather than elements). input defaults to input type=text, so if a browser doesn\u2019t understand a new HTML5 type, it gracefully degrades to a plain text input.\n\nSo where does that leave validation in those browsers that don\u2019t support Web Forms? The answer is that you don\u2019t retire your pre-existing JavaScript validation just yet, but you leave it as a fallback after doing some feature detection. To detect whether (say) input type=email is supported, you make a new input type=email with JavaScript but don\u2019t add it to the page. Then, you interrogate your new element to find out what its type attribute is. If it\u2019s reported back as \u201cemail\u201d, then the browser supports the new feature, so let it do its work and don\u2019t bring in any JavaScript validation. If it\u2019s reported back as \u201ctext\u201d, it\u2019s fallen back to the default, indicating that it\u2019s not supported, so your code should branch to your old validation routines. Alternatively, use the small (7K) Modernizr library which will do this work for you and give you JavaScript booleans like Modernizr.inputtypes[email] set to true or false.\n\nSo what does this buy you? Well, first and foremost, you\u2019re future-proofing your code for that time when all browsers support these hugely useful additions to forms. Secondly, you buy a usability and accessibility win. Although it\u2019s tempting to style the stuffing out of your form fields (which can, incidentally, lead to madness), whatever your branding people say, it\u2019s better to leave forms as close to the browser defaults as possible. A browser\u2019s slider and date pickers will be the same across different sites, making it much more comprehensible to users. And, by using native controls rather than faking sliders and date pickers with JavaScript, your forms are much more likely to be accessible to users of assistive technology.\n\nHTML5 DOCTYPE\n\nYou can use the new DOCTYPE !doctype html now and \u2013 hey presto \u2013 you\u2019re writing HTML5, as it\u2019s pretty much a superset of HTML4. There are some useful advantages to doing this. The first is that the HTML5 validator (I use http://html5.validator.nu) also validates ARIA information, whereas the HTML4 validator doesn\u2019t, as ARIA is a new spec developed after HTML4. (Actually, it\u2019s more accurate to say that it doesn\u2019t validate your ARIA attributes, but it doesn\u2019t automatically report them as an error.)\n\nAnother advantage is that HTML5 allows tabindex as a global attribute (that is, on any element). Although originally designed as an accessibility bolt-on, I ordinarily advise you don\u2019t use it; a well-structured page should provide a logical tab order through links and form fields already.\n\nHowever, tabindex=\"-1\" is a legal value in HTML5 as it allows for the element to be programmatically focussable by JavaScript. It\u2019s also very useful for correcting a bug in Internet Explorer when used with a keyboard; in-page links go nowhere if the destination doesn\u2019t have a proprietary property called hasLayout set or a tabindex of -1.\n\nSo, whether it is the tool of Satan or yule of Santa, HTML5 is just around the corner. Some you can use now, and by the end of 2010 I predict you\u2019ll be able to use a whole lot more as new browser versions are released.", "year": "2009", "author": "Bruce Lawson", "author_slug": "brucelawson", "published": "2009-12-05T00:00:00+00:00", "url": "https://24ways.org/2009/html5-tool-of-satan-or-yule-of-santa/", "topic": "code"}
{"rowid": 216, "title": "Styling Components - Typed CSS With Stylable", "contents": "There\u2019s been a lot of debate recently about how best to style components for web apps so that styles don\u2019t accidentally \u2018leak\u2019 out of the component they\u2019re meant for, or clash with other styles on the page.\nElaborate CSS conventions have sprung up, such as OOCSS, SMACSS, BEM, ITCSS, and ECSS. These work well, but they are methodologies, and require everyone in the team to know them and follow them, which can be a difficult undertaking across large or distributed teams.\nOthers just give up on CSS and put all their styles in JavaScript. Now, I\u2019m not bashing JS, especially so close to its 22nd birthday, but CSS-in-JS has problems of its own. Browsers have 20 years experience in optimising their CSS engines, so JavaScript won\u2019t be as fast as using real CSS, and in any case, this requires waiting for JS to download, parse, execute then render the styles.\nThere\u2019s another problem with CSS-in-JS, too. Since Responsive Web Design hit the streets, most designers no longer make comps in Photoshop or its equivalents; instead, they write CSS. Why hire an expensive design professional and require them to learn a new way of doing their job? \nA recent thread on Twitter asked \u201cWhat\u2019s your biggest gripe with CSS-in-JS?\u201d, and the replies were illuminating: \u201cAlways having to remember to camelCase properties then spending 10min pulling hair out when you do forget\u201d, \u201cthe cryptic domain-specific languages that each of the frameworks do just ever so slightly differently\u201d, \u201cWhen I test look and feel in browser, then I copy paste from inspector, only to have to re-write it as a JSON object\u201d, \u201cLack of linting, autocomplete, and css plug-ins for colors/ incrementing/ etc\u201d. \nIf you\u2019re a developer, and you\u2019re still unconvinced, I challenge you to let designers change the font in your IDE to Zapf Chancery and choose a new colour scheme, simply because they like it better. Does that sound like fun? Will that boost your productivity? Thought not.\nSome chums at Wix Engineering and I wanted to see if we could square this circle. Wix-hosted sites have always used CSS-in-JS (the concept isn\u2019t new; it was in Netscape 4!) but that was causing performance problems. Could we somehow devise a method of extending CSS (like SASS and LESS do) that gives us styles that are guaranteed not to leak or clash, that is compatible with code editors\u2019 autocompletion, and which could be pre-processed at build time to valid, cross-browser, static CSS?\nAfter a few months and a few proofs of concept later (drumroll), yes \u2013 we could! We call it Stylable.\nIntroducing Stylable\nStylable is a CSS pre-processor, like SASS or LESS. It uses CSS syntax so all your development tools will work. At build time, the Stylable CSS extensions are transpiled to flat, valid, cross-browser vanilla CSS for maximum performance. There\u2019s quite a bit to it, and this is a short article, so let\u2019s look at the basic concepts.\nComponents all the way down\nStylable is designed for component-based systems. Imagine you have a Gallery component. Within that, there is a Navigation component (for example, containing a \u2018next\u2019, \u2018previous\u2019, \u2018show all thumbnails\u2019, and \u2018show all albums\u2019 controls), and within that there are NavButton components. Each component is discrete, used elsewhere in the system in different contexts, perhaps maintained by different team members or even different organisations \u2014 you can use Stylable to add a typed interface to non-Stylable component libraries, as well as using it to build an app from scratch.\nFirstly, Stylable will automatically namespace styles so they only apply inside that component, by rewriting them at build time with a unique (but human-readable) prefix. So, for example,\n<div className=\"jingle bells\" /> might be re-written as <div class=\"header183--jingle header183--bells\"></div>. \nSo far, so BEM-like (albeit without the headache of remembering a convention). But what else can it do?\nCustom pseudo-elements\nAn important feature of Stylable is the ability to reach into a component and style it from the outside, without having to know about its internal structure. Let\u2019s see the guts of a simple JSX button component in the file button.jsx:\nrender () {\n    return (\n        <button>\n            <span className=\"icon\" />\n            <span className=\"label\">Submit</span>\n        </button>\n    );\n}\n(Note:className is the JSX way of setting a class on an element; this example uses React, but Stylable itself is framework-agnostic.)\nI style it using a Stylable stylesheet (the .st.css suffix tells the preprocessor to process this file):\n/* button.st.css */\n\n/* note that the root class is automatically placed on the root HTML \nelement by Stylable React integration */\n.root {\n  background: #b0e0e6;\n}\n\n.icon {\n  display: block; \n  height: 2em;\n  background-image: url('./assets/btnIcon.svg');\n}\n\n.label {\n  font-size: 1.2em;\n  color: rgba(81, 12, 68, 1.0);\n}\nNote that Stylable allows all the CSS that you know and love to be included. As Drew Powers wrote in his review:\n\nwith Stylable, you get CSS, and every part of CSS. This seems like a \u201cduh\u201d observation, but this is significant if you\u2019ve ever battled with a CSS-in-JS framework over a lost or \u201chacky\u201d implementation of a basic CSS feature.\n\nI can import my Button component into another component - this time, panel.jsx:\n/* panel.jsx */\nimport * as React from 'react';\nimport {properties, stylable} from 'wix-react-tools';\nimport {Button} from '../button';\nimport style from './panel.st.css';\n\nexport const Panel = stylable(style)(() => (\n    <div>\n        <Button className=\"cancelBtn\" />\n    </div>\n));\nIn panel.st.css: \n/* panel.st.css */\n:import {\n  -st-from: './button.st.css';\n  -st-default: Button;\n}\n\n/* cancelBtn is of type Button */\n.cancelBtn {\n  -st-extends: Button;\n  background: cornflowerblue;\n}\n\n/* targets the label of <Button className=\"cancelBtn\" /> */\n.cancelBtn::label {\n  color: honeydew;\n  font-weight: bold;\n}\nHere, we\u2019re reaching into the Button component from the Panel component. Buttons that are not inside a Panel won\u2019t be affected.\nWe do this by extending the CSS concept of pseudo-elements. As MDN says \u201cA CSS pseudo-element is a keyword added to a selector that lets you style a specific part of the selected element(s)\u201d. We don\u2019t use a descendant selector because the label isn\u2019t part of the Panel component, it\u2019s part of the Button component. \nThis syntax allows us three important features: \nPiercing the Shadow Boundary\nBecause, like a Matroshka doll of code, you can have components inside components inside components, you can chain pseudo-elements. In Stylable, Gallery::NavigationPanel::Button::Icon is a legitimate selector. We were worried by this (even though all Stylable CSS is transpiled to flat, valid CSS) because it\u2019s not allowed in CSS, albeit with the note \u201cA future version of this specification may allow multiple pseudo-elements per selector\u201d. So I asked the CSS Working Group and was told \u201cwe intend to only allow specific combinations\u201d, so we feel this extension to CSS is in the spirit of the language.\nWhile we\u2019re on the subject of those pesky Web Standards, note that the proposed ::part and ::theme pseudo-elements are meant to fulfil the same function. However, those are coming in two years (YouTube link) and, when they do, Stylable will support them.\nStructure-agnostic\nThe second totez-groovy\u2122 feature of Stylable\u2019s pseudo-element syntax is that you don\u2019t have to care about the internal structure of the component whose boundary you\u2019re piercing. Any element with a class attribute is exposed as a pseudo-element to any component that imports it. It acts as an interface on any component, whether written in-house or by a third party.\nCode completion\nWhen we started writing Stylable, our objective was to do for CSS what TypeScript does for JavaScript. Wikipedia says\n\nChallenges with dealing with complex JavaScript code led to demand for custom tooling to ease developing of components in the language. TypeScript developers sought a solution that would not break compatibility with the standard and its cross-platform support \u2026 [with]  static typing that enables static language analysis, which facilitates tooling and IDE support.\n\nSimilarly, because Stylable knows about components, their stylable parts and states, and how they inter-relate, we can develop language services like code completion and validation. That means we can see our errors at build time or even while working in our IDE. Wave goodbye to silent run-time breakage misery, with the Stylable Intelligence VS Code extension !\nAn action replay of Visual Studio Code offering code completion etc, filmed in super StyloVision.\nPseudo-classes for state\nStylable makes it easy to apply styles to custom states (as well as the usual :active, :checked, :visited etc) by extending the CSS pseudo-class syntax. \nWe do this by declaring the possible custom states on the component:\n/* Gallery.st.css */\n.root {\n  -st-states: toggled, loading;\n}\n\n.root:toggled {\n  color: red;\n}\n\n.root:loading {\n  color: green;\n}\n\n.root:loading:toggled {\n  color: blue;\n}\nThe -st-states \u201cproperty\u201d is actually a directive for the transpiler, so Stylable knows about possible pseudo-elements and can offer code completion etc. It looks like a vendor prefix by design, because it\u2019s therefore valid CSS syntax and IDEs won\u2019t flag it as an error, but is removed at build time. Remember, Stylable resolves to flat, valid, cross-browser CSS.\nAs with plain CSS, it can\u2019t set a state, but can only react to states set externally. In the case of custom pseudo-classes, your JavaScript logic is responsible for maintaining state \u2014 by default, by setting a data-* attribute.\nAnd there\u2019s more!\nHopefully, I\u2019ve shown you how Stylable extends CSS to allow you to style components and sub-components without worrying about that styles will leak, or knowing too much about internal structure. There isn\u2019t time to tell you about mixins (CSS macros in JavaScript), variables or our theming capabilities, because I have wine to wrap and presents to mull.\nWe made Stylable because we \u2665 CSS. But there\u2019s a practical reason, too. As James Kyle, a core team member of Yarn, Babel and TC39 (the JavaScript Standards Technical Committee), said of Styable \u201cpretty sure all the CSS-in-JS libraries just died for me\u201d,\nexplaining\n\nCSS could be perfectly static if given the right tools, that\u2019s exactly what stylable does. It gives you the tools you need in CSS so that you don\u2019t need to do a bunch of dynamic shit in JS.\nMaking it static is a huge performance win.\n\nWix is currently battle-testing Stylable in its back-office systems, before rolling it out to power Wix-hosted sites to make them more performant. There are 110 million Wix-hosted sites, so there will be a lot of Stylable on the web in a few months. And it\u2019s open-sourced so you, dear Reader, can try it out and use it too. There\u2019s a Stylable boilerplate based on create-react-app to get you started (more integrations are in the pipeline).\nHappy Hols \u2018n\u2019 Hugz from the Stylable team: Bruce, Arnon, Tom, Ido.\n\nRead more\n\nStylable documentation centre\nStylable on Twitter\nA nice picture of a hedgehog", "year": "2017", "author": "Bruce Lawson", "author_slug": "brucelawson", "published": "2017-12-09T00:00:00+00:00", "url": "https://24ways.org/2017/styling-components-typed-css-with-stylable/", "topic": "code"}
{"rowid": 32, "title": "Cohesive UX", "contents": "With Yosemite, Apple users can answer iPhone calls on their MacBooks. This is weird. And yet it\u2019s representative of a greater trend toward cohesion.\n\nShortly after upgrading to Yosemite, a call came in on my iPhone and my MacBook \u201crang\u201d in parallel. And I was all, like, \u201cWut?\u201d This was a new feature in Yosemite, and honestly it was a little bizarre at first.\n\n Apple promotional image showing a phone call ringing simultaneously on multiple devices.\n\nHowever, I had just spoken at a conference on the very topic you\u2019re reading about now, and therefore I appreciated the underlying concept: the cohesion of user experience, the cohesion of screens.\n\nThis is just one of many examples I\u2019ve encountered since beginning to speak about this topic months ago. But before we get ahead of ourselves, let\u2019s look back at the past few years, specifically the role of responsive web design.\n\nRWD != cohesive experience\n\nI needn\u2019t expound on the virtues of responsive web design (RWD). You\u2019ve likely already encountered more than a career\u2019s worth on the topic. This is a good thing. Count me in as one of its biggest fans.\n\nHowever, if we are to sing the praises of RWD, we must also acknowledge its shortcomings. One of these is that RWD ends where the browser ends. For all its goodness, RWD really has no bearing on native apps or any other experiences that take place outside the browser. This makes it challenging, therefore, to create cohesion for multi-screen users if RWD is the only response to \u201clet\u2019s make it work everywhere.\u201d\n\nWe need something that incorporates the spirit of RWD while unifying all touchpoints for the entire user experience\u2014single device or several devices, in browser or sans browser, native app or otherwise.\n\nI call this cohesive UX, and I believe it\u2019s the next era of successful user experiences.\n\nToward a unified whole\n\nSimply put, the goal of cohesive UX is to deliver a consistent, unified user experience regardless of where the experience begins, continues, and ends.\n\nTwo facets are vital to cohesive UX:\n\n\n\tFunction and form\n\tData symmetry\n\n\nLet\u2019s examine each of these.\n\nFunction AND form\n\nFunction over form, of course. Right? Not so fast, kiddo.\n\nConsider Bruce Lawson\u2019s dad. After receiving an Android phone for Christmas and thumbing through his favorite sites, he was puzzled why some looked different from their counterparts on the desktop. \u201cWhen a site looked radically different,\u201d Bruce observed, \u201che\u2019d check the URL bar to ensure that he\u2019d typed in the right address. In short, he found RWD to be confusing and it meant he didn\u2019t trust the site.\u201d A lack of cohesive form led to a jarring experience for Bruce\u2019s dad.\n\nNow, if I appear to be suggesting websites must look the same in every browser\u2014you already learned they needn\u2019t\u2014know that I recognize the importance of context, especially in regards to mobile. I made a case for this more than seven years ago.\n\nRather, cohesive UX suggests that form deserves the same respect as function when crafting user experiences that span multiple screens or devices. And users are increasingly comfortable traversing media. For example, more than 40% of adults in the U.S. owning more than one device start an activity on one screen and finish it on another, according to a study commissioned by Facebook. I suspect that percentage will only increase in 2015, and I suspect the tech-affluent readers of 24 ways are among the 40%.\n\nThere are countless examples of cohesive form and function. Consider Gmail, which displays email conversations visually as a stack that can be expanded and collapsed like the bellows of an accordion. This visual metaphor has been consistent in virtually any instance of Gmail\u2014website or app\u2014since at least 2007 when I captured this screenshot on my Nokia 6680:\n\n Screenshot captured while authoring Mobile Web Design (2007). Back then we didn\u2019t call this an app, but rather a \u2018smart client\u2019.\n\nWhen the holistic experience is cohesive as it is with Gmail, users\u2019 mental models and even muscle memory are preserved.1 Functionality and aesthetics align with the expectations users have for how things should function and what they should look like. In other words, the experience is roughly the same across screens.\n\nBut don\u2019t be ridiculous, peoples. Note that I said \u201croughly.\u201d It\u2019s important to avoid mindless replication of aesthetics and functionality for the sake of cohesion. Again, the goal is a unified whole, not a carbon copy. Affordances and concessions should be made as context and intuition require. For example, while Facebook users are accustomed to top-aligned navigation in the browser, they encounter bottom-aligned navigation in the iOS app as justified by user testing:\n\nThe iOS app model has held up despite many attempts to better it: http://t.co/rSMSAqeh9m pic.twitter.com/mBp36lAEgc\u2014 Luke Wroblewski (@lukew) December 10, 2014\n\n\nDespite the (rather minor) lack of consistency in navigation placement, other elements such as icons, labels, and color theme work in tandem to produce a unified, holistic whole.\n\nData symmetry\n\nData symmetry involves the repetition, continuity, or synchronicity of data across screens, devices, and platforms. As regards cohesive UX, data includes not just the material (such as an article you\u2019re writing on Medium) but also the actions that can be performed on or with that material (such as Medium\u2019s authoring tools). That is to say, \u201csync verbs, not just nouns\u201d (Josh Clark).\n\nIn my estimation, Amazon is an archetype of data symmetry, as is Rdio. When logged in, data is shared across virtually any device of any kind, irrespective of using a browser or native app. Add a product to your Amazon cart from your phone during the morning commute, and finish the transaction at work on your laptop. Easy peasy.\n\nAmazon\u2019s aesthetics are crazy cohesive, to boot:\n\n Amazon web (left) and native app (right).\n\nWith Rdio, not only are playlists and listening history synced across screens as you would expect, but the cohesion goes even further. Rdio\u2019s remote control feature allows you to control music playing on one device using another device, all in real time.\n\n Rdio\u2019s remote control feature, as viewed on my MacBook while music plays on my iMac.\n\nAt my office I often work from my couch using my MacBook, but my speakers are connected to my iMac. When signed in to Rdio on both devices, my MacBook serves as proxy for controlling Rdio on my iMac, much the same as any Yosemite-enabled device can serve as proxy for an incoming iPhone call.\n\n Me, in my office. Note the iMac and speakers at far right.\n\nThis is a brilliant example of cohesive design, and it\u2019s executed entirely via the cloud.\n\nThings to consider\n\nConsider the following when crafting cohesive experiences:\n\n\n\tInventory the elements that comprise your product experience, and cohesify them.2\nConsider things such as copy, tone, typography, iconography, imagery, flow, placement, brand identification, account data, session data, user preferences, and so on. Then, create cohesion among these elements to the greatest extent possible, while adapting to context as needed.\n\tStore session data in the cloud rather than locally.\nFor example, avoid using browser cookies to store shopping cart data, as cookies are specific to a single browser on a single device. Instead, store this data in the cloud so it can be accessed from other devices, as well as beyond the browser.\n\tConsider using web views when developing your native app.\n\u201cYou\u2019re already using web apps in native wrappers without even noticing it,\u201d Lukas Mathis contends. \u201cThe fact that nobody even notices, the fact that this isn\u2019t a story, shows that, when it comes to user experience, web vs. native doesn\u2019t matter anymore.\u201d Web views essentially allow you to display HTML content inside a native wrapper. This can reduce the time and effort needed to make the overall experience cohesive. So whereas the navigation bar may be rendered by the app, for example, the remaining page display may be rendered via the web. There\u2019s readily accessible documentation for using web views in C++, iOS, Android, and so forth.\n\n\nNature is calling\n\nReturning to the example of Yosemite and sychronized phone calls, is it really that bizarre in light of cohesive UX? Perhaps at first. But I suspect that, over time, Yosemite\u2019s cohesiveness \u2014 and the cohesiveness of other examples like the ones we\u2019ve discussed here \u2014 will become not only more natural but more commonplace, too.\n\n\n\n1 I browse Flipboard on my iPad nearly every morning as part of my breakfast routine. Swiping horizontally advances to the next page. Countless times I\u2019ve done the same gesture in Flipboard for iPhone only to have it do nothing. This is because the gesture for advancing is vertical on phones. I\u2019m so conditioned to the horizontal swipe that I often fail to make the switch to vertical swipe, and apparently others suffer from the same muscle memory, too.\n\n2 Cohesify isn\u2019t a thing. But chances are you understood what I meant. Yay neologism!", "year": "2014", "author": "Cameron Moll", "author_slug": "cameronmoll", "published": "2014-12-24T00:00:00+00:00", "url": "https://24ways.org/2014/cohesive-ux/", "topic": "ux"}
{"rowid": 144, "title": "The Mobile Web, Simplified", "contents": "A note from the editors:  although eye-opening in 2006, this article is no longer relevant to today\u2019s mobile web.\n                \n                \n                      \n                Considering a foray into mobile web development? Following are four things you need to know before making the leap.\n\n1. 4 billion mobile subscribers expected by 2010\n\nFancy that. Coupled with the UN prediction of 6.8 billion humans by 2010, 4 billion mobile subscribers (source) is an astounding 59% of the planet. Just how many of those subscribers will have data plans and web-enabled phones is still in question, but inevitably this all means one thing for you and me: A ton of potential eyes to view our web content on a mobile device.\n\n2. Context is king\n\nYour content is of little value to users if it ignores the context in which it is viewed. Consider how you access data on your mobile device.  You might be holding a bottle of water or gripping a handle on the subway/tube. You\u2019re probably seeking specific data such as directions or show times, rather than the plethora of data at your disposal via a desktop PC.\n\nThe mobile web, a phrase often used to indicate \u201caccessing the web on a mobile device\u201d,  is very much a context-, content-, and component-specific environment. Expressed in terms of your potential target audience, access to web content on a mobile device is largely influenced by surrounding circumstances and conditions, information relevant to being mobile, and the feature set of the device being used. Ask yourself, What is relevant to my users and the tasks, problems, and needs they may encounter while being mobile? Answer that question and you\u2019ll be off to a great start.\n\n3. WAP 2.0 is an XHTML environment\n\nIn a nutshell, here are a few fundamental tenets of mobile internet technology:\n\n\n\tWireless Application Protocol (WAP) is the protocol for enabling mobile access to internet content.\n\tWireless Markup Language (WML) was the language of choice for WAP 1.0.\n\tNearly all devices sold today are WAP 2.0 devices.\n\tWith the introduction of WAP 2.0, XHTML Mobile Profile (XHTML-MP) became the preferred markup language.\n\tXHTML-MP will be familiar to anyone experienced with XHTML Transitional or Strict.\n\n\nSummary? The mobile web is rapidly becoming an XHTML environment, and thus you and I can apply our existing \u201cdesktop web\u201d skills to understand how to develop content for it. With WML on the decline, the learning curve is much smaller today than it was several years ago. I\u2019m generalizing things gratuitously, but the point remains: Get off yo\u2019 lazy butt and begin to take mobile seriously.\n\nI\u2019ll even pass you a few tips for getting started. First, the DOCTYPE for XHTML-MP is as follows:\n\n<!DOCTYPE html PUBLIC \"-//WAPFORUM//DTD XHTML Mobile 1.0//EN\"\n\"http://www.openmobilealliance.org/tech/DTD/xhtml-mobile10.dtd\">\n\nAs for MIME type, Open Mobile Alliance (OMA) specifies using the MIME type application/vnd.wap.xhtml+xml, but ultimately you need to ensure the server delivering your mobile content is configured properly for the MIME type you choose to use, as there are other options (see Setting up WAP Servers).\n\nOnce you\u2019ve made it to the body, the XHTML-MP markup is not unlike what you\u2019re already used to. A few resources worth skimming:\n\n\n\tDevelopers Home XHTML-MP Tutorial \u2013 An impressively replete resource for all things XHTML-MP\n\tXHTML-MP Tags List \u2013 A complete list of XHTML-MP elements and accompanying attributes\n\n\nAnd last but certainly not least, CSS. There exists WAP CSS, which is essentially a subset of CSS2 with WAP-specific extensions. For all intents and purposes, much of the CSS you\u2019re already comfortable using will be transferrable to mobile. As for including CSS in your pages, your options are the same as for desktop sites: external, embedded, and inline. Some experts will argue embedded or inline over external in favor of reducing the number of HTTP connections per page request, yet many popular mobilized sites and apps employ external linking without issue.\n\nStocking stuffers: Flickr Mobile, Fandango Mobile, and Popurls Mobile. A few sites with whom you can do the View Source song and dance for further study.\n\n4. \u201cCell phone\u201d is so DynaTAC\n\nIf you\u2019re a U.S. resident, listen up: You must rid your vocabulary of the term \u201ccell phone\u201d. We\u2019re one of the few economies on the planet to refer to a mobile phone accordingly. If you care to find yourself in any of the worthwhile mobile development circles, begin using terms more widely accepted: \u201cmobile\u201d or \u201cmobile phone\u201d or \u201chandset\u201d or \u201chandy\u201d. If you\u2019re not sure which, go for \u201cmobile\u201d. Such as, \u201cYo dog, check out my new mobile.\u201d\n\nMore importantly, however, is overcoming the mentality that access to the mobile web can be done only with a phone. Instead, \u201cdevice\u201d encourages us to think phone, handheld computer, watch, Nintendo DS, car, you name it.\n\nSimple enough?", "year": "2006", "author": "Cameron Moll", "author_slug": "cameronmoll", "published": "2006-12-19T00:00:00+00:00", "url": "https://24ways.org/2006/the-mobile-web-simplified/", "topic": "ux"}
{"rowid": 40, "title": "Don\u2019t Push Through the Pain", "contents": "In 2004, I lost my web career. In a single day, it was gone. I was in too much pain to use a keyboard, a Wacom tablet (I couldn\u2019t even click the pen), or a trackball. Switching my mouse to use my left (non-dominant) hand only helped a bit; then that hand went, too. I tried all the easy-to-find equipment out there, except for expensive gizmos with foot pedals. I had tingling in my fingers\u2014which, when I was away from the computer, would rhythmically move as if some other being controlled them. I worried about Parkinson\u2019s because the movements were so dramatic. Pen on paper was painful. Finally, I discovered one day that I couldn\u2019t even turn a doorknob.\n\nThe only highlight was that I couldn\u2019t dust, scrub, or vacuum. We were forced to hire someone to come in once a week for an hour to whip through the house. You can imagine my disappointment. \n\nMy injuries had gradually slithered into my life without notice. I\u2019d occasionally have sore elbows, or my wrist might ache for a day, or my shoulders feel tight. But nothing to keyboard home about. That\u2019s the critical bit of news. One day, you\u2019re pretty fine. The next day, you don\u2019t have your job\u2014or any job that requires the use of your hands and wrists. \n\nI had to walk away from the computer for over four months\u2014and partially for several months more. That\u2019s right: no income. If I hadn\u2019t found a gifted massage therapist, the right book of stretches, the equipment I should have been using all along, and learned how to pay attention to my body\u2014even just a little bit more\u2014I quite possibly wouldn\u2019t be writing this article today. I wouldn\u2019t be writing anything, anywhere. \n\nMost of us have heard of (and even claimed to have read all of) Mihaly Csikszentmihalyi, author of Flow: The Psychology of Optimal Experience, who describes the state of flow\u2014the place our minds go when we are fully engaged and in our element. This lovely state of highly focused activity is deeply satisfying, often creative, and quite familiar to many of us on the web who just can\u2019t quit until the copy sings or the code is untangled or we get our highest score yet in Angry Birds. Our minds may enter that flow, but too often as our brains take flight, all else recedes. And we leave something very important behind. \n\nOur bodies. \n\nMy body wasn\u2019t made to make the same minute movements thousands of times a day, most days of the year, for decades, and neither was yours. The wear and tear sneaks up on you, especially if you\u2019re the obsessive perfectionist that we all pretend not to be. Oh? You\u2019re not obsessed? I wasn\u2019t like this all the time, but I remember sitting across from my husband, eating dinner, and I didn\u2019t hear a word he said. I\u2019d left my brain upstairs in my office, where it was wrestling in a death match with the box model or, God help us all, IE 5.2. I was a writer, too, and I was having my first inkling that I was a content strategist. Work was exciting. I could sit up late, in the flow, fingers flying at warp speed. I could sit until those wretched birds outside mocked me with their damn, cheerful \u201cHurray, it\u2019s morning!\u201d songs. Suddenly, while, say, washing dishes, the one magical phrase that captured the essence of a voice or idea would pop up, and I would have mowed down small animals and toddlers to get to my computer and hammer out that website or article, to capture that thought before it escaped. Note my use of the word hammer. Sound at all familiar? \n\nBut where was my body during my work? Jaw jutting forward to see the screen, feet oddly positioned\u2014and then left in place like chunks of marble\u2014back unsupported, fingers pounding the keys, wrists and arms permanently twisted in unnatural angles that we thought were natural. And clicking. Clicking, clicking, clicking that mouse. Thumbing tiny keyboards on phones. A lethal little gesture for tiny little tendons. Though I was fine from, say 1997 to 2004, by the end of 2004 this behavior culminated in disaster. I had repetitive stress injuries, aka repetitive motion injuries. As the Apple site says, \u201cA brief exposure to these conditions would not cause harm. But a prolonged exposure may, in some people, result in reduced ability to function.\u201d I\u2019ll say. \n\nI frantically turned to people on lists and forums. \u201cTry a track ball.\u201d Already did that. \u201cTry a tablet.\u201d Worse. One person wrote, \u201cI still come here once in a while and can type a couple sentences, but I\u2019ve permanently got thoracic outlet syndrome and I\u2019ll never work again.\u201d Oh, beauteous web, oh, long-distance friends, farewell.    \n\nThe Wrist Bone\u2019s Connected to the Brain Bone\n\nThat variation on the old song tells part of the story. Most people (and many of their physicians) believe that tingling fingers and aching wrists MUST be carpel tunnel syndrome. Nope. If your neck juts forward, it tenses and stays tense the entire time you work in that position. Remember how your muscles felt after holding a landline phone with your neck tilted to one side for a long client meeting? Regrettable. Tensing your shoulders because your chair\u2019s not designed properly puts you at risk for thoracic outlet syndrome, a career-killer if ever there was one. The nerves and tendons in your neck and shoulder refer down your arms, and muscles swell around nerves, causing pain and dysfunction. Your elbows have a tendon that is especially vulnerable to repetitive movements (think tennis elbow). Your wrists are performing something akin to a circus act with one thousand shows a day. \n\nSo, all the fine tendons and ligaments in your fingers have problems that may not start at your wrists at all. Though some people truly do have carpal tunnel syndrome, my finger and wrist problems weren\u2019t solved by heavily massaging my fingers (though, that was helpful, too) or my wrists. They were fixed by work on my neck, upper back, shoulders, arms, and elbows. This explains why many people have surgery for carpal tunnel syndrome and just months later say, \u201cWhat?! How can I possibly have it again? I had an operation!\u201d Well, fellow buckaroo, you may never have had carpel tunnel syndrome. You may have had\u2014or perhaps will have\u2014one long disaster area from your neck to your fingertips. \n\nHow to Crawl Back \n\nBefore trying extreme measures, you may be able to function again even if you feel hopeless. I managed to heal, and so have others, but I\u2019ll always be at risk. \n\nAs Jen Simmons, of The Web Ahead podcast and other projects told me, \u201cIt took a long time to injure myself. It took a long time to get back to where I was. My right arm between my elbow and wrist would start aching intermittently. Eventually, my arm even ached at night. I started each day with yesterday\u2019s pain.\u201d Simple measures, used consistently, helped her back. \n\n1. Massage therapy\n\nI don\u2019t remember what the rest of the world is like, but in Portland, Oregon, we have more than one massage therapy college. (Of course we do.) I saw a former teacher at the most respected school. This is not your \u201cIt was all so soothing. Why, I fell asleep!\u201d massage. This is \u201cHoly crap, he\u2019s grinding his elbow into my armpit!\u201c massage therapy, with the emphasis on therapy. I owe him everything. Make sure you have someone who really knows what they\u2019re doing. Get many referrals. Try a question, \u201cDoes my psoas muscle affect my back?\u201d If they can\u2019t answer it, flee. Regularly see the one you choose and after a while, depending on how injured you are, you may be able to taper off. \n\n2. Change your equipment\n\nYou may need to be hands-on with several pieces of equipment before you find the ones that don\u2019t cause more pain. Many companies have restocking fees, charges to ship the equipment you want to return, and other retail atrocities. Always be sure to ask what the return policies are at any company before purchasing.\n\nMice \n\nYou may have more success than I did with equipment such as the Wacom tablet. Mine came with a pen, and it hurt to repetitively click it. Trackballs are another option but, for many, they are better at prevention than recovery. But let\u2019s get to the really effective stuff. One of the biggest sources of pain is using your mouse. One major reason is that your hand and wrist are in a perpetually unnatural position and you\u2019re also moving your arm quite a bit. Each time you move the mouse, it is placing stress on your neck, shoulders and arms, because you need to lift them slightly in order to move the mouse and you need to angle your wrist. You may also be too injured to use the trackpad all the time, and this mouse, the vertical mouse is a dandy preventative measure, too. Shaking up your patterns is a wise move. I have long fingers, not especially thin, yet the small size works best for me. (They have larger choices available.) What?! A sideways mouse? Yep. All the weight of your hand will be resting on it in the handshake position. Your forearms aren\u2019t constantly twisting over hill and dale. You aren\u2019t using any muscles in your wrist or hand. They are relaxing. You\u2019ll adapt in a day, and oh, oh, what a relief it is. \n\nKeyboards\n\nI really liked doing business with the people at Kinesis-Ergo. (I\u2019m not affiliated with them in any way.) They have the vertical mouse and a number of keyboards. The one that felt the most natural to me, and, once again, it only takes a day to adapt, is the Freestyle2 for the Mac. They have several options. I kept the keyboard halves attached to each other at first, and then spread them apart a little more. I recommend choosing one that slants and can separate. You can adjust the angle. For a little extra, they\u2019ll make sure it\u2019s all set up and ready to go for you. I\u2019m guessing that some Googling will find you similar equipment, wherever you live. \n\nWarning: if you use the ergonomic keyboards, you may have fewer USB ports. The laptop will be too far away to see unless you find a satisfactory setup using a stand. This is the perfect excuse for purchasing a humongous display. \n\nYou may not look cool while jetting coast to coast in your skinny jeans and what appears to be the old-time orthopedic shoe version of computing gear. But once you have rested and used many of these suggestions consistently, you may be able to use your laptop or other device in all its lovely sleekness during the trip. \n\nOther doohickies\n\nThe Kinesis site and The Human Solution have a wide selection of ergonomic products: standing desks, ergonomically correct chairs, and, yes, even things with foot pedals. Explore! \n\n3. Stop clicking, at least for a while\n\nUse keyboard shortcuts, but use them slowly. This is not the time to show off your skillz. You\u2019ll be sort of like a recovering alcoholic, in that you\u2019ll be a recovering repetitive stress survivor for the rest of your life, once you really injure yourself. Always be vigilant. There\u2019s also a bit of software sold by The Human Solution and other places, and it was my salvation. It\u2019s called the McNib for Macs, and the Nib for PCs. (I\u2019ve only used the McNib.) It\u2019s for click-free mousing. I found it tricky to use when writing markup and code, but you may become quite adept at it. A little rectangle pops up on your screen, you mouse over it and choose, let\u2019s say, \u201cDouble-click.\u201d Until you change that choice, if you mouse over a link or anything else, it will double-click it for you. All you do is glide your mouse around. Awkward for a day or two, but you\u2019ll pick it up quickly. Though you can use it all day for work, even if you just use this for browsing LOLcats or Gary Vaynerchuk\u2019s YouTube videos, it will help you by giving your fingers a sweet break. \n\nBut here\u2019s the sad news. The developer who invented this died a few years ago. (Yes, I used to speak to him on the phone.) While it is for sale, it isn\u2019t compatible with Mac OS X Lion or anything subsequent. PowerPC strikes again. His site is still up. Demos for use with older software can be downloaded free at his old site, or at The Human Solution. Perhaps an enterprising developer can invent something that would provide this help, without interfering with patents. Rumor has it among ergonomic retailers (yes, I\u2019m like a police dog sniffing my way to a criminal once I head down a trail) that his company was purchased by a company in China, with no update in sight. \n\n4. Use built-in features\n\nThat little microphone icon that comes up alongside the keyboard on your iPhone allows you to speak your message instead of incessantly thumbing it. I believe it works in any program that uses the keyboard. It\u2019s not Siri. She\u2019s for other things, like having a personal relationship with an inanimate object. Apple even has a good section on ergonomics. You think I\u2019m intense about this subject? To improve your repetitive stress, Apple doesn\u2019t want you to use oral contraceptives, alcohol, or tobacco, to which I say, \u201cHave as much sex, bacon, and chocolate as possible to make up for it.\u201d \n\nApple\u2019s info even has illustrations of things like a faucet dripping into what is labeled a bucket full of \u201cTRAUMA.\u201d Sounds like upgrading to Yosemite, but I digress.  \n\n5. Take breaks \n\nIf it\u2019s a game or other non-essential activity, take a break for a month. Fine, now that I\u2019ve called games non-essential, I suppose you\u2019ll all unfollow me on Twitter. \n\n6. Whether you are sore or not, do stretches throughout the day \n\nThis is a big one. Really big. The best book on the subject of repetitive stress injuries is Conquering Carpal Tunnel Syndrome and Other Repetitive Strain Injuries: A Self-Care Program by Sharon J. Butler. Don\u2019t worry, most of it is illustrations. Pretend it\u2019s a graphic novel. \n\nI\u2019m notorious for never reading instructions, and who on earth reads the introduction of a book, unless they wrote it? I wrote a book a long time ago, and I bet my house, husband, and life savings that my own parents never read the intro. Well, I did read the intro to this book, and you should, too. Stretching correctly, in a way that doesn\u2019t further hurt you, that keeps you flexible if you aren\u2019t injured, that actually heals you, calls for precision. Read and you\u2019ll see. The key is to stretch just until you start to feel the stretch, even if that\u2019s merely a tiny movement. Don\u2019t force anything past that point. Kindly nurse yourself back to health, or nurture your still-healthy body by stretching. Over the following days, weeks, months, you\u2019ll be moving well past that initial stretch point.   \n\nThe book is brimming with examples. You only have to pick a few stretches, if this is too much to handle. Do it every single day. I can tell you some of the best ones for me, but it depends on the person. You\u2019ll also discover in Butler\u2019s book that areas that you think are the problem are sometimes actually adjacent to the muscle or tendon that is the source of the problem. Add a few stretches or two for that area, too.  \n\nBut please follow the instructions in the introduction. If you overdo it, or perform some other crazy-ass hijinks, as I would be tempted to do, I am not responsible for your outcome. I give you fair warning that I am not a healthcare provider. I\u2019m just telling you as a friend, an untrained one, at that, who has been through this experience. \n\n7. Follow good habits\n\nDevelop habits like drinking lots of water (which helps with lactic acid buildup in muscles), looking away from the computer for twenty seconds every twenty to thirty minutes, eating right, and probably doing everything else your mother told you to do. Maybe this is a good time to bring up flossing your teeth, and going outside to play instead of watching TV. As your mom would say, \u201cIt\u2019s a beautiful day outside, what are you kids doing in here?\u201d \n\n8. Speak instead of writing, if you can \n\nAmber Simmons, who is very smart and funny, once tweeted in front of the whole world that, \u201c@carywood is a Skype whore.\u201d I was always asking people on Twitter if we could Skype instead of using iChat or exchanging emails. (I prefer the audio version so I don\u2019t have to, you know, do something drastic like comb my hair.) Keyboarding is tough on hands, whether you notice it or not at the time, and when doing rapid-fire back-and-forthing with people, you tend to speed up your typing and not take any breaks. This is a hand-killer. Voice chats have made such a difference for me that I am still a rabid Skype whore. Wait, did I say that out loud? \n\nSpeak your text or emails, using Dragon Dictate or other software. In about 2005, accessibility and user experience design expert, Derek Featherstone, in Canada, and I, at home, chatted over the internet, each of us using a different voice-to-text program. The programs made so many mistakes communicating with each other that we began that sort of endless, tearful laughing that makes you think someone may need to call an ambulance. This type of software has improved quite a bit over the years, thank goodness. Lack of accessibility of any kind isn\u2019t funny to Derek or me or to anyone who can\u2019t use the web without pain. \n\n9. Watch your position \n\nFor example, if you lift up your arms to use the computer, or stare down at your laptop, you\u2019ll need to rearrange your equipment. The internet has a lot of information about ideal ergonomic work areas. Please use a keyboard drawer. Be sure to measure the height carefully so that even a tented keyboard, like the one I recommend, will fit. I also recommend getting the version of the Freestyle with palm supports. Just these two measures did much to help both Jen Simmons and me. \n\n10. If you need to take anti-inflammatories, stop working\n\nIf you are all drugged up on ibuprofen, and pounding and clicking like mad, your body will not know when you are tired or injuring yourself. I don\u2019t recommend taking these while using your computing devices. Perhaps just take it at night, though I\u2019m not a fan of that category of medications. Check with your healthcare provider. At least ibuprofen is an anti-inflammatory, which may help you. In contrast, acetaminophen (paracetamol) only makes your body think it\u2019s not in pain. Ice is great, as is switching back and forth between ice and heat. But again, if you need ice and ibuprofen you really need to take a major break. \n\n11. Don\u2019t forget the rest of your body\n\nI\u2019ve zeroed in on my personal area of knowledge and experience, but you may be setting yourself up for problems in other areas of your body. There\u2019s what is known to bad writers as \u201ca veritable cornucopia\u201d of information on the web about how to help the rest of your body. A wee bit of research on the web and you\u2019ll discover simple exercises and stretches for the rest of your potential catastrophic areas: your upper back, your lower back, your legs, ankles, and eyes. Do gentle stretches, three or four times a day, rather than powering your way through. Ease into new equipment such as standing desks. Stretch those newly challenged areas until your body adapts. Pay attention to your body, even though I too often forget mine. \n\n12. Remember the children\n\nKids are using equipment to play highly addictive games or to explore amazing software, and if these call for repetitive motions, children are being set up for future injuries. They\u2019ll grab hold of something, as parents out there know, and play it 3,742 times. That afternoon. Perhaps by the time they are adults, everything will just be holograms and mind-reading, but adult fingers and hands are used for most things in life, not just computing devices and phones with keyboards sized for baby chipmunks. \n\nI\u2019ll be watching you\n\nQuickly now, while I (possibly) have your attention. Don\u2019t move a muscle. Is your neck tense? Are you unconsciously lifting your shoulders up? How long since you stopped staring at the screen? How bright is your screen? Are you slumping (c\u2019mon now, \u2018fess up) and inviting sciatica problems? Do you have to turn your hands at an angle relative to your wrist in order to type? Uh-oh. That\u2019s a bad one. Your hands, wrists, and forearms should be one straight line while keyboarding. Future you is begging you to change your ways. Don\u2019t let your #ThrowbackThursday in 2020 say, \u201cHere\u2019s a photo from when I used to be able to do so many wonderful things that I can\u2019t do now.\u201d And, whatever you do, don\u2019t try for even a nanosecond to push through the pain, or the next thing you know, you\u2019ll be an unpaid extra in The Expendables 7.", "year": "2014", "author": "Carolyn Wood", "author_slug": "carolynwood", "published": "2014-12-06T00:00:00+00:00", "url": "https://24ways.org/2014/dont-push-through-the-pain/", "topic": "business"}
{"rowid": 228, "title": "The Great Unveiling", "contents": "The moment of unveiling our designs should be among our proudest, but it never seems to work out that way. Instead of a chance to show how we can bring our clients\u2019 visions to life, critique can be a tense, worrying ordeal. And yes, the stakes are high: a superb design is only superb if it goes live. Mismanage the feedback process and your research, creativity and hard work can be wasted, and your client may wonder whether you\u2019ve been worth the investment.\n\nThe great unveiling is a pivotal part of the design process, but it needn\u2019t be a negative one. Just as usability testing teaches us whether our designs meet user needs, presenting our work to clients tells us whether we\u2019ve met important business goals. So how can we turn the tide to make presenting designs a constructive experience, and to give good designs a chance to shine through?\n\nTiming is everything\n\nFirst, consider when you should seek others\u2019 opinions. Your personal style will influence whether you show early sketches or wait to demonstrate something more complete. Some designers thrive at low fidelity, sketching out ideas that, despite their rudimentary nature, easily spark debate. Other designers take time to create more fully-realised versions. Some even argue that the great unveiling should be eliminated altogether by working directly alongside the client throughout, collaborating on the design to reach its full potential. \n\nWhatever your individual preference, you\u2019ll rarely have the chance to do it entirely your own way. Contracts, clients, and deadlines will affect how early and often you share your work. However, try to avoid the trap of presenting too late and at too high fidelity. My experience has taught me that skilled designers tend to present their work earlier and allow longer for iteration than novices do. More aware of the potential flaws in their solutions, these designers cling less tightly to their initial efforts. Working roughly and seeking early feedback gives you the flexibility to respond more fully to nuances you may have missed until now.\n\nPlanning design reviews\n\nPresent design ideas face-to-face, or at least via video conference. Asynchronous methods like e-mail and Basecamp are slow, easily ignored, and deny you the opportunity to guide your colleagues through your work. In person, you profit from both the well-known benefits of non-verbal communication, and the chance to immediately respond to questions and elaborate on rationale.\n\nBe sure to watch the numbers at your design review sessions, however. Any more than a handful of attendees and the meeting could quickly spiral into fruitless debate. Ask your project sponsor to appoint a representative to speak on behalf of each business function, rather than inviting too many cooks.\n\nWhere possible, show your work in its native format. Photocopy hand-drawn sketches to reinforce their disposability (the defining quality of a sketch) and encourage others to scribble their own thoughts on top. Show digital deliverables \u2013 wireframes, design concepts, rich interactions \u2013 on screen. The experience of a design is very different on screen than on paper. A monitor has appropriate dimensions and viewport size, presenting an accurate picture of the design\u2019s visual hierarchy, and putting interactive elements in the right context. On paper, a link is merely underlined text. On screen, it is another step along the user\u2019s journey.\n\nDon\u2019t waste time presenting multiple concepts. Not only is it costly to work up multiple concepts to the level required for fair appraisal, but the practice demonstrates a sorry abdication of responsibility. Designers should be custodians of design. Asking for feedback on multiple designs turns the critique process into a beauty pageant, relinquishing a designer\u2019s authority. Instead of rational choices that meet genuine user and business needs, you may be stuck with a Frankensteinian monstrosity, assembled from incompatible parts: \u201cThis header plus the whizzy bit from Version C\u201d.\n\nThis isn\u2019t to say that you shouldn\u2019t explore lots of ideas yourself. Divergent thinking early in the design process is the only way to break free of the clich\u00e9d patterns and fads that so often litter mediocre sites. But you must act as a design curator, choosing the best of your work and explaining its rationale clearly and succinctly. Attitude, then, is central to successful critique. It can be difficult to tread the fine line between the harmful extremes of doormat passivity and prima donna arrogance. Remember that you are the professional, but be mindful that even experts make mistakes, particularly when \u2013 as with all design projects \u2013 they don\u2019t possess all the relevant information in advance. Present your case with open-minded confidence, while accepting that positive critique will make your design (and ultimately your skills) stronger.\n\nThe courage of your convictions\n\nUltimately, your success in the feedback process, and indeed in the entire design process, hinges upon the rationale you provide for your work. Ideally, you should be able to refer to your research \u2013 personas, usability test findings, analytics \u2013 to support your decisions. To keep this evidence in mind, print it out to share at the design review, or include it in your presentation. Explain the rationale behind the most important decisions before showing the design, so that you can be sure of the full attention of your audience.\n\nOnce you\u2019ve covered these points, display your design and walk through the specific features of the page. A little honesty goes a long way here: state your case as strongly as your rationale demands. Sure of your reasoning? Be strong. Speculating an approach based on a hunch? Say so, and encourage your colleagues to explore the idea with you and see where it leads.\n\nOf course, none of these approaches should be sacrosanct. A proficient designer must be able to bend his or her way of working to suit the situation at hand. So sometimes you\u2019ll want to ignore these rules of thumb and explore your own hunches as required. More power to you. As long as you think as clearly about the feedback process as you have about the design itself, you\u2019ll be able to enjoy the great unveiling as a moment to be savoured, not feared.", "year": "2010", "author": "Cennydd Bowles", "author_slug": "cennyddbowles", "published": "2010-12-12T00:00:00+00:00", "url": "https://24ways.org/2010/the-great-unveiling/", "topic": "business"}
{"rowid": 8, "title": "Coding Towards Accessibility", "contents": "\u201cCan we make it AAA-compliant?\u201d \u2013 does this question strike fear into your heart? Maybe for no other reason than because you will soon have to wade through the impenetrable WCAG documentation once again, to find out exactly what AAA-compliant means?\n\nI\u2019m not here to talk about that.\n\nThe Web Content Accessibility Guidelines are a comprehensive and peer-reviewed resource which we\u2019re lucky to have at our fingertips. But they are also a pig to read, and they may have contributed to the sense of mystery and dread with which some developers associate the word accessibility.\n\nThis Christmas, I want to share with you some thoughts and some practical tips for building accessible interfaces which you can start using today, without having to do a ton of reading or changing your tools and workflow.\n\nBut first, let\u2019s clear up a couple of misconceptions.\n\nDreary, flat experiences\n\nI recently built a front-end framework for the Post Office. This was a great gig for a developer, but when I found out about my client\u2019s stringent accessibility requirements I was concerned that I\u2019d have to scale back what was quite a complex set of visual designs.\n\nSites like Jakob Neilsen\u2019s old workhorse useit.com and even the pioneering GOV.UK may have to shoulder some of the blame for this. They put a premium on usability and accessibility over visual flourish. (Although, in fairness to Mr Neilsen, his new site nngroup.com is really quite a snazzy affair, comparatively.)\n\nOf course, there are other reasons for these sites\u2019 aesthetics \u2014 and it\u2019s not because of the limitations of the form. You can make an accessible site look as glossy or as plain as you want it to look. It\u2019s always our own ingenuity and attention to detail that are going to be the limiting factors.\n\nSynecdoche\n\nWe must always guard against the tendency to assume that catering to screen readers means we have the whole accessibility ballgame covered. \n\nThere\u2019s so much more to accessibility than assistive technology, as you know. And within the field of assistive technology there are plenty of other devices for us to consider.\n\nPlanning to accommodate all these users and devices can be daunting. When I first started working in this field I thought that the breadth of technology was prohibitive. I didn\u2019t even know what a screen reader looked like. (I assumed they were big and heavy, perhaps like an old typewriter, and certainly they would be expensive and difficult to fathom.) This is nonsense, of course. Screen reader emulators are readily available as browser extensions and can be activated in seconds. Chromevox and Fangs are both excellent and you should download one or the other right now.\n\nBut the really good news is that you can emulate many other types of assistive technology without downloading a byte. And this is where we move from misconceptions into some (hopefully) useful advice.\n\nThe mouse trap\n\nThe simplest and most effective way to improve your abilities as a developer of accessible interfaces is to unplug your mouse.\n\nKeyboard operation has its own WCAG chapter, because most users of assistive technology are navigating the web using only their keyboards. You can go some way towards putting yourself into their shoes so easily \u2014 just by ditching a peripheral.\n\nLearning this was a lightbulb moment for me. When I build interfaces I am constantly flicking between code and the browser, testing or viewing the changes I have made. Now, instead of checking a new element once, I check it twice: once with my mouse and then again without.\n\nDon\u2019t just :hover\n\nThe reality is that when you first start doing this you can find your site becomes unusable straightaway. It\u2019s easy to lose track of which element is in focus as you hit the tab key repeatedly.\n\nOne of the easiest changes you can make to your coding practice is to add :focus and :active pseudo-classes to every hover state that you write. I\u2019m still amazed at how many sites fail to provide a decent focus state for links (and despite previous 24 ways authors in 2007 and 2009 writing on this same issue!).\n\nYou may find that in some cases it makes sense to have something other than, or in addition to, the hover state on focus, but start with the hover state that your designer has taken the time to provide you with. It\u2019s a tiny change and there is no downside. So instead of this:\n\n.my-cool-link:hover {\n\tbackground-color: MistyRose ;\t\n}\n\n\u2026try writing this:\n\n.my-cool-link:hover,\n.my-cool-link:focus,\n.my-cool-link:active {\n\tbackground-color: MistyRose ;\t\n}\n\nI\u2019ve toyed with the idea of making a Sass mixin to take care of this for me, but I haven\u2019t yet. I worry that people reading my code won\u2019t see that I\u2019m explicitly defining my focus and active states so I take the hit and write my hover rules out longhand.\n\nJavaScript can play, too\n\nThis was another revelation for me. Keyboard-only navigation doesn\u2019t necessitate a JavaScript-free experience, and up-to-date screen readers can execute JavaScript. So we\u2019re able to create complex JavaScript-driven interfaces which all users can interact with.\n\nSome of the hard work has already been done for us. First, there are already conventions around keyboard-driven interfaces. Think about the last time you viewed a photo album on Facebook. You can use the arrow keys to switch between photos, and the escape key closes whichever lightbox-y UI thing Facebook is showing its photos in this week. Arrow keys (up/down as well as left/right) for progression through content; Escape to back out of something; Enter or space bar to indicate a positive intention \u2014 these are established keyboard conventions which we can apply to our interfaces to improve their accessiblity. \n\nOf course, by doing so we are improving our interfaces in general, giving all users the option to switch between keyboard and mouse actions as and when it suits them.\n\nSecond, this guy wants to help you out. Hans Hillen is a developer who has done a great deal of work around accessibility and JavaScript-powered interfaces. Along with The Paciello Group he has created a version of the jQuery UI library which has been fully optimised for keyboard navigation and screen reader use. It\u2019s a fantastic reference which I revisit all the time \n\nI\u2019m not a huge fan of the jQuery UI library. It\u2019s a pain to style and the code is a bit bloated. So I\u2019ve not used this demo as a code resource to copy wholesale. I use it by playing with the various components and seeing how they react to keyboard controls. Each component is also fully marked up with the relevant ARIA roles to improve screen reader announcement where possible (more on this below).\n\nCoding for accessibility promotes good habits\n\nThis is a another observation around accessibility and JavaScript. I noticed an improvement in the structure and abstraction of my code when I started adding keyboard controls to my interface elements. \n\nYour code has to become more modular and event-driven, because any number of events could trigger the same interaction. A mouse-click, the Enter key and the space bar could all conceivably trigger the same open function on a collapsed accordion element. (And you want to keep things DRY, don\u2019t you?) \n\nIf you aren\u2019t already in the habit of separating out your interface functionality into discrete functions, you will be soon.\n\nvar doSomethingCool = function(){\n\t// Do something cool here.\n}\n\n// Bind function to a button click - pretty vanilla\n$('.myCoolButton').on('click', function(){\n\tdoSomethingCool();\n\treturn false;\n});\n\n// Bind the same function to a range of keypresses\n$(document).keyup(function(e){\n\tswitch(e.keyCode) {\n\t\tcase 13: // enter\n\t\tcase 32: // spacebar\n\t\t\tdoSomethingCool();\n\t\t\tbreak;\n\t\tcase 27: // escape\n\t\t\tdoSomethingElse();\n\t\t\tbreak;\n\t}\n});\n\nTo be honest, if you\u2019re doing complex UI stuff with JavaScript these days, or if you\u2019ve been building any responsive interfaces which rely on JavaScript, then you are most likely working with an application framework such as Backbone, Angular or Ember, so an abstraced and event-driven application structure will be familar to you. It should be super easy for you to start helping out your keyboard-only users if you aren\u2019t already \u2014 just add a few more event bindings into your UI layer!\n\nManipulating the tab order\n\nSo, you\u2019ve adjusted your mindset and now you test every change to your codebase using a keyboard as well as a mouse. You\u2019ve applied all your hover states to :focus and :active so you can see where you\u2019re tabbing on the page, and your interactive components react seamlessly to a mixture of mouse and keyboard commands. Feels good, right?\n\nThere\u2019s another level of optimisation to consider: manipulating the tab order. Certain DOM elements are naturally part of the tab order, and others are excluded. Links and input elements are the main elements included in the tab order, and static elements like paragraphs and headings are excluded. What if you want to make a static element \u2018tabbable\u2019? \n\nA good example would be in an expandable accordion component. Each section of the accordion should be separated by a heading, and there\u2019s no reason to make that heading into a link simply because it\u2019s interactive.\n\n<div class=\"accordion-widget\">\n\t<h3>Tyrannosaurus</h3>\n\t<p>Tyrannosaurus; meaning \"tyrant lizard\"...<p>\n\n\t<h3>Utahraptor</h3>\n\t<p>Utahraptor is a genus of theropod dinosaurs...<p>\n\n\t<h3>Dromiceiomimus</h3>\n\t<p>Ornithomimus is a genus of ornithomimid dinosaurs...<p>\n</div>\n\nAdding the heading elements to the tab order is trivial. We just set their tabindex attribute to zero. You could do this on the server or the client. I prefer to do it with JavaScript as part of the accordion setup and initialisation process.\n\n$('.accordion-widget h3').attr('tabindex', '0');\n\nYou can apply this trick in reverse and take elements out of the tab order by setting their tabindex attribute to \u22121, or change the tab order completely by using other integers. This should be done with great care, if at all. You have to be sure that the markup you remove from the tab order comes out because it genuinely improves the keyboard interaction experience. This is hard to validate without user testing. The danger is that developers will try to sweep complicated parts of the UI under the carpet by taking them out of the tab order. This would be considered a dark pattern \u2014 at least on my team!\n\nA farewell ARIA\n\nThis is where things can get complex, and I\u2019m no expert on the ARIA specification: I feel like I\u2019ve only dipped my toe into this aspect of coding for accessibility. But, as with WCAG, I\u2019d like to demystify things a little bit to encourage you to look into this area further yourself.\n\nARIA roles are of most benefit to screen reader users, because they modify and augment screen reader announcements. \n\nLet\u2019s take our dinosaur accordion from the previous section. The markup is semantic, so a screen reader that can\u2019t handle JavaScript will announce all the content within the accordion, no problem.\n\nBut modern screen readers can deal with JavaScript, and this means that all the lovely dino information beneath each heading has probably been hidden on document.ready, when the accordion initialised. It might have been hidden using display:none, which prevents a screen reader from announcing content. If that\u2019s as far as you have gone, then you\u2019ve committed an accessibility sin by hiding content from screen readers. Your user will hear a set of headings being announced, with no content in between. It would sound something like this if you were using Chromevox:\n\n> Tyrannosaurus. Heading Three.\n> Utahraptor. Heading Three.\n> Dromiceiomimus. Heading Three.\n\nWe can add some ARIA magic to the markup to improve this, using the tablist role. Start by adding a role of tablist to the widget, and roles of tab and tabpanel to the headings and paragraphs respectively. Set boolean values for aria-selected, aria-hidden and aria-expanded. The markup could end up looking something like this.\n\n<div class=\"accordion-widget\" role=\"tablist\">\n\t<!-- T-rex -->\t\n\t<h3 role=\"tab\" \n\t\ttabindex=\"0\" \n\t\tid=\"tab-2\" \n\t\taria-controls=\"panel-2\" \n\t\taria-selected=\"false\">Utahraptor</h3>\n\t<p\trole=\"tabpanel\" \n\t\tid=\"panel-2\" \n\t\taria-labelledby=\"tab-2\" \n\t\taria-expanded=\"false\" \n\t\taria-hidden=\"true\">Utahraptor is a genus of theropod dinosaurs...</p>\n\t<!-- Dromiceiomimus -->\t\n</div>\n\nNow, if a screen reader user encounters this markup they will hear the following:\n\n> Tyrannosaurus. Tab not selected; one of three.\n> Utahraptor. Tab not selected; two of three.\n> Dromiceiomimus. Tab not selected; three of three.\n\nYou could add arrow key events to help the user browse up and down the tab list items until they find one they like. \n\nYour accordion open() function should update the ARIA boolean values as well as adding whatever classes and animations you have built in as standard. Your users know that unselected tabs are meant to be interacted with, so if a user triggers the open function (say, by hitting Enter or the space bar on the second item) they will hear this:\n\n> Utahraptor. Selected; two of three.\n\nThe paragraph element for the expanded item will not be hidden by your CSS, which means it will be announced as normal by the screen reader.\n\nThis kind of thing makes so much more sense when you have a working example to play with. Again, I refer you to the fantastic resource that Hans Hillen has put together: this is his take on an accessible accordion, on which much of my example is based.\n\nConclusion\n\nGetting complex interfaces right for all of your users can be difficult \u2014 there\u2019s no point pretending otherwise. And there\u2019s no substitute for user testing with real users who navigate the web using assistive technology every day. This kind of testing can be time-consuming to recruit for and to conduct. On top of this, we now have accessibility on mobile devices to contend with. That\u2019s a huge area in itself, and it\u2019s one which I have not yet had a chance to research properly.\n\nSo, there\u2019s lots to learn, and there\u2019s lots to do to get it right. But don\u2019t be disheartened. If you have read this far then I\u2019ll leave you with one final piece of advice: don\u2019t wait.\n\nDon\u2019t wait until you\u2019re building a site which mandates AAA-compliance to try this stuff out. Don\u2019t wait for a client with the will or the budget to conduct the full spectrum of user testing to come along. Unplug your mouse, and start playing with your interfaces in a new way. You\u2019ll be surprised at the things that you learn and the issues you uncover. \n\nAnd the next time an true accessibility project comes along, you will be way ahead of the game.", "year": "2013", "author": "Charlie Perrins", "author_slug": "charlieperrins", "published": "2013-12-03T00:00:00+00:00", "url": "https://24ways.org/2013/coding-towards-accessibility/", "topic": "code"}
{"rowid": 45, "title": "Is Agile Harder for Agencies?", "contents": "I once sat in a pitch meeting and watched a new business exec tell a potential client that his agency followed an agile workflow process at all times. The potential client nodded wisely, and they both agreed that agile was indeed the way to go.\n\nThe meeting progressed and they signed off on a contract for a massive project, to be delivered in a standard waterfall fashion, with all manner of phases and key deliverables.\n\nOf course both of them left the meeting perfectly happy, because neither of them knew nor cared what an agile workflow process might be.\n\nThat was about five years ago. As 2015 heaves into view I think it\u2019s fair to say that attitudes have changed. Perhaps the same number of people claim to do Agile\u2122 now as in 2010, but I think more of them are telling the truth.\n\nAs a developer in an agency that works primarily with larger organisations, this year I have started to see a shift from agencies pushing agile methodologies with their clients, to clients requesting and even demanding agile practices from their agencies. Only a couple of years ago this would have been unusual behaviour.\n\nSo what\u2019s the problem?\n\nWe should be happy then, no? Those of us in agencies will get to spend more time delivering great products, and less time arguing over out-of-date functional specs or battling through an adversarial change management procedure because somebody had a good idea during development rather than planning. We get to be a little bit more like our brothers and sisters in vaunted teams like the Government Digital Service, which is using agile approaches to great effect on projects that have a real benefit to their users.\n\nAlmost. Unfortunately, it seems to be the case that adhering to an agile framework such as scrum is more difficult within an agency/client structure than it is for an in-house development team.\n\nThis is no surprise. The Agile Manifesto was written in 2001 by a group of software developers for their own use. Many of the underlying principles of a framework like Scrum assume the existence of an in-house team, working on a highly technical project, and working for the business that employs them. The agency/client model must to some extent be retrofitted into agile frameworks. It can be done though, and there are plenty of agencies out there doing it well.\n\nThis article isn\u2019t meant to be another introduction to agile techniques \u2013 there are too many of those online already. This article is for people just dipping their toes into this way of working. I\u2019ve laid out a few of the key reasons why adopting a more fully agile approach seems difficult, at least initially, for those of us working in agencies.\n\n1. Agile asks more of your clients\n\nWhen a team adopts Scrum everyone has to get used to a number of unfamiliar roles and rituals. Few team members have a steeper learning curve than the person designated as the product owner.\n\nThe product owner carries a lot of weight on their shoulders. They have to uphold the overall vision for the project. They are also meant to be the primary author of the project\u2019s user stories (short atomic descriptions of project features which are testable and relate to a real business need). They should own this list of stories (called a backlog) and should be able to prioritise the order in which the stories are developed, to ensure that the project is delivering real value to the business early and often.\n\nWhen a burst of work is completed (bursts of work in Scrum are called sprints), the product owner leads a review or show-and-tell session with the wider project stakeholders. The product owner needs to understand the work that has been completed, and must champion it to the business. Finally, and most importantly, the product owner is responsible for managing the feedback and requests from stakeholders in such a way that they don\u2019t derail the project team\u2019s agreed workload for any given sprint, without upsetting or offending any of the stakeholders \u2013 some of whom may outrank the product owner.\n\nIf you follow that spec, this is a job for a superhuman in any organisational context. And within the agency/client structure this superhuman needs to be client-side for the process to be at its most effective.\n\nSo your client, who in the past might have briefed a project to an agency team and then had the work presented back to them every few weeks, is now asked to be involved with the team on a daily basis; to fight on behalf of the team when new or difficult requests come in from senior figures within their organisation; and to present the agency\u2019s work to their own colleagues after each sprint. It\u2019s a big change if all that gets dropped into someone\u2019s lap without warning.\n\nThere are several ways agencies can mitigate this issue. The ScrumAlliance suggests some alternative ways to structure the product owner role. The approach I have taken in the past is simply to start slow, and gradually move more of the product owner role over to the client side as and when they feel comfortable with it. If you\u2019re working together long-term on a project, and you both see tangible improvements in the quality of the work after adopting an agile process, then your client is more likely to be open to further changes as the partnership progresses.\n\n2. My client wants fixed costs, fixed deadlines and a fixed scope\n\nI know. Mine too. Of course they do \u2013 it is the way that agencies and clients have agreed to work in digital and other creative service industries for a very long time. On both sides of the fence we\u2019re used to thinking about projects in this way.\n\nOf the three, fixing scope is the one that agile purists would rail hardest against. The more time we spend working on digital projects, the less sense it makes. James Archer, CEO of UI/UX design agency Forty puts it like this:\n\n\n\tFor me, the Agile approach is really about acknowledging that disturbing truth that every project manager knows, but has trouble admitting. The truth that the project plan is wrong. Scope creep. Change orders. Shifting priorities. New directions. We act shocked and appalled when those things happen during our carefully planned project, even though they happen on every project ever.\n\n\nSuccessful relationships require trust and honesty, and we shouldn\u2019t be afraid of discussing this aspect of project management. If you do move away from a fixed scope of work, then the other two items (costs and timings) can be fixed \u2013 more or less. If you can get your clients to buy into this from a standing start then you are doing well. In fact you probably deserve a promotion. For most of us this is a continual discussion.\n\nAnyway, as soon as you\u2019ve made headway on the argument that it makes little or no sense to try and fix the scope of a digital project, you usually run into a related concern, which we\u2019ll look at next.\n\n3. Fear of uncontrolled costs\n\nWe all know that a dog is for life, not just for Christmas. At this time of year perhaps we should reiterate to everyone that digital products and services also need support and love once we have taken the decision to bring them into the world.\n\nMore organisations are realising that their investment in digital platforms should be viewed as an operational expenditure rather than a capital expenditure. But from time to time we will find ourselves working on projects for people who have a finite amount of money to invest in a product at a given point in time. When agencies start talking about these projects as rolling investments those responsible can understandably worry about their costs running out of control.\n\nThere\u2019s another factor at play here. Agile, on the whole, prefers to derive a cost for services from the hours a team spends working on a project. In other industries this is referred to as charging for time and materials, and there seems to be an ingrained distrust in this approach among people in general. See, for example, the Citizens Advice Bureau\u2019s \u201cTop tips for employing a builder\u201d:\n\n\n\t\u201cBear in mind that if you pay a daily rate, this makes it easier for a builder to string the work out and get more money so agree what you will do if the job takes longer than expected.\u201d\n\n\nIt\u2019s hard not to feel stung if you are in the builder\u2019s shoes here, as we are when we\u2019re talking about our role as an agency. But if you\u2019ve ever haggled with a builder over time and materials, and also moaned about your clients misunderstanding agile methods, take a moment to reflect on the similarities from your client\u2019s point of view.\n\nAgain, there are some things we can do to mitigate this issue. Some agencies put in place a service level agreement around their team\u2019s velocity (an agile-related term related to how much work a team delivers in any given sprint) and this can help.\n\nAs the industry moves further towards a long-term approach to investment in digital I hope this fear will subside. But that shift in approach leads to the final concern I want to address.\n\n4. Agency structures need shaking up\n\nIf you work for a company that has spent many years developing a business model around the waterfall process, you may have to break through many layers of entrenched thinking in order to establish new practices and effect organisational change.\n\nThere are consultancies that exist specifically to help agencies through their own agile transformation. One of these companies, AgencyAgile, provides a helpful list of common pitfalls. They emphasise the need to look at your whole agency\u2019s structure, rather than simply encouraging project teams to adopt new workflows.\n\n\n\tEven awesomely run Agile projects can have a limited impact on the overall organization.\n\n\nIf you\u2019re serious about changing the way your company approaches projects then try talking to people who sit outside the usual project delivery team. Speak to the finance department if you have one, and try to convince your senior management team if they\u2019re not already on board. And definitely speak to your new business people, who go out there and win the projects you get to work on.\n\nIt\u2019s these people who need to understand the potential business benefits of working in a new way, and also which of their existing habits and behaviours they might need to change to accommodate a new approach.\n\nOtherwise you\u2019ll find yourself with a team of designers, developers and project managers who are ready and waiting to deliver work in an iterative and collaborative way, but by the time they get hold of the project a cost has already been agreed, a deadline has been imposed, and a functional requirements document has been painstakingly put together. Nobody wins in this situation.\n\nConclusion\n\nSo where should we go from here? I certainly don\u2019t have hard and fast answers \u2013 I\u2019m not sure that they exist in a one-size-fits-all approach for agencies.\n\nThere are plenty of smart people thinking about this problem. It\u2019s a hot topic right now. Earlier in the year a London-based meetup was established called Agile for Agencies. If you\u2019re in the capital and want to discuss these issues with your peers it\u2019s a great opportunity to do so.\n\nI\u2019ve mentioned James Archer and Forty already. Both James and Paul Boag have written in the last twelve months on this subject. They both come out on the side of the argument that suggests you adopt agile principles, but don\u2019t have to worry about the rituals if they don\u2019t fit in with your practices.\n\nPersonally, I think the rituals and the discipline mandated by an agile framework like Scrum can provide a great deal of value to your team, even it if is hard to implement within an agency culture that has traditionally structured its work and its services in another way.\n\nIn whatever way you figure out the details, when your teams collaborate with your clients rather than work for them at arm\u2019s length, and when everyone prioritises frequent delivery, reflection and iteration over exhaustive scoping and planning, I believe you\u2019ll see a tangible difference in the quality of the work that you create.", "year": "2014", "author": "Charlie Perrins", "author_slug": "charlieperrins", "published": "2014-12-12T00:00:00+00:00", "url": "https://24ways.org/2014/is-agile-harder-for-agencies/", "topic": "process"}
{"rowid": 204, "title": "Cascading Web Design with Feature Queries", "contents": "Feature queries, also known as the @supports rule, were introduced as an extension to the CSS2 as part of the CSS Conditional Rules Module Level 3, which was first published as a working draft in 2011. It is a conditional group rule that tests if the browser\u2019s user agent supports CSS property:value pairs, and arbitrary conjunctions (and), disjunctions (or), and negations (not) of them.\nThe motivation behind this feature was to allow authors to write styles using new features when they were supported but degrade gracefully in browsers where they are not. Even though the nature of CSS already allows for graceful degradation, for example, by ignoring unsupported properties or values without disrupting other styles in the stylesheet, sometimes we need a bit more than that.\nCSS is ultimately a holistic technology, in that, even though you can use properties in isolation, the full power of CSS shines through when used in combination. This is especially evident when it comes to building web layouts. Having native feature detection in CSS makes it much more convenient to build with cutting-edge CSS for the latest browsers while supporting older browsers at the same time.\nBrowser support\nOpera first implemented feature queries in November 2012, both Chrome and Firefox had it since May 2013. There have been several articles about feature queries written over the years, however, it seems that awareness of its broad support isn\u2019t that well-known. Much of the earlier coverage on feature queries was not written in English, and perhaps that was a limiting factor.\n\n@supports \u2015 CSS\u306eFeature Queries by Masataka Yakura, August 8 2012\nNative CSS Feature Detection via the @supports Rule by Chris Mills, December 21 2012\nCSS @supports by David Walsh, April 3 2013\nResponsive typography with CSS Feature Queries by Aral Balkan, April 9 2013\nHow to use the @supports rule in your CSS by Lea Verou, January 31 2014\nCSS Feature Queries by Amit Tal, June 2 2014\nComing Soon: CSS Feature Queries by Adobe Web Platform Team, August 21 2014\nCSS feature queries mittels @supports by Daniel Erlinger, November 27 2014\n\nAs of December 2017, all current major browsers and their previous 2 versions support feature queries. Feature queries are also supported on Opera Mini, UC Browser and Samsung Internet. The only browsers that do not support feature queries are Internet Explorer and Blackberry Mobile, but that may be less of an issue than you might think.\n\n  Can I Use css-featurequeries? Data on support for the css-featurequeries feature across the major browsers from caniuse.com.\n\nGranted, there is still a significant number of organisations that require support of Internet Explorer. Microsoft still continues to support IE11 for the life-cycle of Windows 7, 8 and 10. They have, however, stopped supporting older versions since January 12, 2016. It is inevitable that there will be organisations that, for some reason or another, make it mandatory to support IE, but as time goes on, this number will continue to shrink.\nJen Simmons wrote an extensive article called Using Feature Queries in CSS which discussed a matrix of potential situations when it comes to the usage of feature queries. The following image is a summary of the aforementioned matrix.\n\nThe most tricky situation we have to deal with is the box in the top-left corner, which are \u201cbrowsers that don\u2019t support feature queries, yet do support the feature in question\u201d. For cases like those, it really depends on the specific CSS feature you want to use and a subsequent evaluation of the pros and cons of not including that feature in spite of the fact the browser (most likely Internet Explorer) supports it.\nThe basics of feature queries\nAs with any conditional, feature queries operate on boolean logic, in other words, if the query resolves to true, apply the CSS properties within the block, or else just ignore the entire block altogether. The syntax of a simple feature query is as follows:\n.selector {\n  /* Styles that are supported in old browsers */\n}\n\n@supports (property:value) {\n  .selector {\n    /* Styles for browsers that support the specified property */\n  }\n}\nNote that the parentheses around the property:value pair are mandatory and the rule is invalid without them. Styles that apply to older browsers, i.e. fallback styles, should come first, followed by the newer properties, which are contained within the @supports conditional. Because of the cascade, fallback styles will be overridden by the newer properties in the modern browsers that support them.\nmain {\n  background-color: red;\n}\n\n@supports (display:grid) {\n  main {\n    background-color: green;\n  }\n}\nIn this example, browsers that support CSS grid will have a main element with a green background colour because the conditional resolves to true, while browsers that do not support grid will have a main element with a red background colour.\nThe implication of such behaviour means that we can layer on enhanced styles based on the features we want to use and these styles will show up in browsers that support them. But for those that do not, they will get a more basic look that still works anyway. And that will be our approach moving forward.\nBoolean operators for feature queries\nThe and operator allows us to test for support of multiple properties within a single conditional. This would be useful for cases where the desired output requires multiple cutting-edge features to be supported at the same time to work. All the property:value pairs listed in the conditional must resolve to true for the styles within the rule to be applied.\n@supports (transform: rotate(45deg)) and\n          (writing-mode: vertical-rl) {\n  /* Some CSS styles */\n}\nThe or operator allows us to list multiple property:value pairs in the conditional and as long as one of them resolves to true, the styles within the block will be applied. A relevant use-case would be for properties with vendor-prefixes.\n@supports (background: -webkit-gradient(linear, left top, left bottom, from(white), to(black))) or\n          (background: -o-linear-gradient(top, white, black)) or\n          (background: linear-gradient(to bottom, white, black)) {\n  /* Some CSS styles */\n}\nThe not operator negates the resolution of the property:value pair in the conditional, resolving to false when the property is supported and vice versa. This is useful when there are two distinct sets of styles to be applied depending on the support of a specific feature. However, we do need to keep in mind the case where a browser does not support feature queries, and handle the styles for those browsers accordingly.\n@supports not (shape-outside: polygon(100% 80%,20% 0,100% 0)) {\n  /* Some CSS styles */\n}\nTo avoid confusion between and and or, these operators must be explicitly declared as opposed to using commas or spaces. To prevent confusion caused by precedence rules, and, or and not operators cannot be mixed without a layer of parentheses.\nThis rule is not valid and the styles within the block will be ignored.\n@supports (transition-property: background-color) or\n          (animation-name: fade) and\n          (transform: scale(1.5)) {\n  /* Some CSS styles */\n}\nTo make it work, parentheses must be added either around the two properties adjacent to the or or the and operator like so:\n@supports ((transition-property: background-color) or\n          (animation-name: fade)) and\n          (transform: scale(1.5)) {\n  /* Some CSS styles */\n}\n@supports (transition-property: background-color) or\n          ((animation-name: fade) and\n          (transform: scale(1.5))) {\n  /* Some CSS styles */\n}\nThe current specification states that whitespace is required after a not and on both sides of an and or or, but this may change in a future version of the specification. It is acceptable to add extra parentheses even when they are not needed, but omission of parentheses is considered invalid.\nCascading web design\nI\u2019d like to introduce the concept of cascading web design, an approach made possible with feature queries. Browser update cycles are much shorter these days, so new features and bug fixes are being pushed out a lot more frequently as compared to the early days of the web.\nWith the maturation of web standards, browser behaviour is less unpredictable than before, but each browser will still have their respective quirks. Chances are, the latest features will not ship across all browsers at the same time. But you know what? That\u2019s perfectly fine. If we accept this as a feature of the web, instead of a bug, we\u2019ve just opened up a lot more web design possibilities.\nThe following example is a basic, responsive grid layout of items laid out with flexbox, as viewed on IE11.\n\nWe can add a block of styles within an @supports rule to apply CSS grid properties for browsers that support them to enhance this layout, like so:\n\nThe web is not a static medium. It is dynamic and interactive and we manipulate this medium by writing code to tell the browser what we want it to do. Rather than micromanaging the pixels in our designs, maybe it\u2019s time we cede control of our designs to the browsers that render them. This means being okay with your designs looking different across browsers and devices.\nAs mentioned earlier, CSS works best when various properties are combined. It\u2019s one of those things whose whole is greater than the sum of its parts. So feature queries, when combined with media queries, allow us to design layouts that are most effective in the environment they have to perform in.\nSuch an approach requires interpolative thinking, on multiple levels. As web designers and developers, we don\u2019t just think in one fixed dimension, we get to think about how our design will morph on a narrow screen, or on an older browser, in addition to how it will appear on a browser with the latest features.\nIn the following example, the layout on the left is what IE11 users will see, the one in the middle is what Firefox users will see, because Firefox doesn\u2019t support CSS shapes yet, but once it does, it will then look like the layout on the right, which is what Chrome users see now.\n\nWith the release of CSS Grid this year, we\u2019ve hit another milestone in the evolution of the web as a medium. The beauty of the web is its backwards compatibility and generous fault tolerance. Browser features are largely additive, holding onto the good parts and building on top of them, while deprecating the bits that didn\u2019t work well.\nFeature queries allow us to progressively enhance our CSS, establishing a basic level of user experience across the widest range of browsers, while building in more advanced functionality for browsers who can use them. And hopefully, this will allow more of us to create designs that truly embrace the nature of the web.", "year": "2017", "author": "Chen Hui Jing", "author_slug": "chenhuijing", "published": "2017-12-01T00:00:00+00:00", "url": "https://24ways.org/2017/cascading-web-design/", "topic": "code"}
{"rowid": 18, "title": "Grunt for People Who Think Things Like Grunt are Weird and Hard", "contents": "Front-end developers are often told to do certain things:\n\n\n\tWork in as small chunks of CSS and JavaScript as makes sense to you, then concatenate them together for the production website.\n\tCompress your CSS and minify your JavaScript to make their file sizes as small as possible for your production website.\n\tOptimize your images to reduce their file size without affecting quality.\n\tUse Sass for CSS authoring because of all the useful abstraction it allows.\n\n\nThat\u2019s not a comprehensive list of course, but those are the kind of things we need to do. You might call them tasks.\n\nI bet you\u2019ve heard of Grunt. Well, Grunt is a task runner. Grunt can do all of those things for you. Once you\u2019ve got it set up, which isn\u2019t particularly difficult, those things can happen automatically without you having to think about them again.\n\nBut let\u2019s face it: Grunt is one of those fancy newfangled things that all the cool kids seem to be using but at first glance feels strange and intimidating. I hear you. This article is for you.\n\nLet\u2019s nip some misconceptions in the bud right away\n\nPerhaps you\u2019ve heard of Grunt, but haven\u2019t done anything with it. I\u2019m sure that applies to many of you. Maybe one of the following hang-ups applies to you.\n\nI don\u2019t need the things Grunt does\n\nYou probably do, actually. Check out that list up top. Those things aren\u2019t nice-to-haves. They are pretty vital parts of website development these days. If you already do all of them, that\u2019s awesome. Perhaps you use a variety of different tools to accomplish them. Grunt can help bring them under one roof, so to speak. If you don\u2019t already do all of them, you probably should and Grunt can help. Then, once you are doing those, you can keep using Grunt to do more for you, which will basically make you better at doing your job.\n\nGrunt runs on Node.js \u2014 I don\u2019t know Node\n\nYou don\u2019t have to know Node. Just like you don\u2019t have to know Ruby to use Sass. Or PHP to use WordPress. Or C++ to use Microsoft Word.\n\nI have other ways to do the things Grunt could do for me\n\nAre they all organized in one place, configured to run automatically when needed, and shared among every single person working on that project? Unlikely, I\u2019d venture.\n\nGrunt is a command line tool \u2014 I\u2019m just a designer\n\nI\u2019m a designer too. I prefer native apps with graphical interfaces when I can get them. But I don\u2019t think that\u2019s going to happen with Grunt1.\n\nThe extent to which you need to use the command line is:\n\n\n\tNavigate to your project\u2019s directory.\n\tType grunt and press Return.\n\n\nAfter set-up, that is, which again isn\u2019t particularly difficult.\n\nOK. Let\u2019s get Grunt installed\n\nNode is indeed a prerequisite for Grunt. If you don\u2019t have Node installed, don\u2019t worry, it\u2019s very easy. You literally download an installer and run it. Click the big Install button on the Node website.\n\nYou install Grunt on a per-project basis. Go to your project\u2019s folder. It needs a file there named package.json at the root level. You can just create one and put it there.\n\n package.json at root\n\nThe contents of that file should be this:\n\n{\n  \"name\": \"example-project\",\n  \"version\": \"0.1.0\",\n  \"devDependencies\": {\n    \"grunt\": \"~0.4.1\"\n  }\n}\n\nFeel free to change the name of the project and the version, but the devDependencies thing needs to be in there just like that.\n\nThis is how Node does dependencies. Node has a package manager called NPM (Node packaged modules) for managing Node dependencies (like a gem for Ruby if you\u2019re familiar with that). You could even think of it a bit like a plug-in for WordPress.\n\nOnce that package.json file is in place, go to the terminal and navigate to your folder. Terminal rubes like me do it like this:\n\n Terminal rube changing directories\n\nThen run the command:\n\nnpm install\n\nAfter you\u2019ve run that command, a new folder called node_modules will show up in your project.\n\n Example of node_modules folder\n\nThe other files you see there, README.md and LICENSE are there because I\u2019m going to put this project on GitHub and that\u2019s just standard fare there.\n\nThe last installation step is to install the Grunt CLI (command line interface). That\u2019s what makes the grunt command in the terminal work. Without it, typing grunt will net you a \u201cCommand Not Found\u201d-style error. It is a separate installation for efficiency reasons. Otherwise, if you had ten projects you\u2019d have ten copies of Grunt CLI.\n\nThis is a one-liner again. Just run this command in the terminal:\n\nnpm install -g grunt-cli\n\nYou should close and reopen the terminal as well. That\u2019s a generic good practice to make sure things are working right. Kinda like restarting your computer after you install a new application was in the olden days.\n\nLet\u2019s make Grunt concatenate some files\n\nPerhaps in our project there are three separate JavaScript files:\n\n\n\tjquery.js \u2013 The library we are using.\n\tcarousel.js \u2013 A jQuery plug-in we are using.\n\tglobal.js \u2013 Our authored JavaScript file where we configure and call the plug-in.\n\n\nIn production, we would concatenate all those files together for performance reasons (one request is better than three). We need to tell Grunt to do this for us.\n\nBut wait. Grunt actually doesn\u2019t do anything all by itself. Remember Grunt is a task runner. The tasks themselves we will need to add. We actually haven\u2019t set up Grunt to do anything yet, so let\u2019s do that.\n\nThe official Grunt plug-in for concatenating files is grunt-contrib-concat. You can read about it on GitHub if you want, but all you have to do to use it on your project is to run this command from the terminal (it will henceforth go without saying that you need to run the given commands from your project\u2019s root folder):\n\nnpm install grunt-contrib-concat --save-dev\n\nA neat thing about doing it this way: your package.json file will automatically be updated to include this new dependency. Open it up and check it out. You\u2019ll see a new line:\n\n\"grunt-contrib-concat\": \"~0.3.0\"\n\nNow we\u2019re ready to use it. To use it we need to start configuring Grunt and telling it what to do.\n\nYou tell Grunt what to do via a configuration file named Gruntfile.js2\n\nJust like our package.json file, our Gruntfile.js has a very special format that must be just right. I wouldn\u2019t worry about what every word of this means. Just check out the format:\n\nmodule.exports = function(grunt) {\n\n    // 1. All configuration goes here \n    grunt.initConfig({\n        pkg: grunt.file.readJSON('package.json'),\n\n        concat: {\n            // 2. Configuration for concatinating files goes here.\n        }\n\n    });\n\n    // 3. Where we tell Grunt we plan to use this plug-in.\n    grunt.loadNpmTasks('grunt-contrib-concat');\n\n    // 4. Where we tell Grunt what to do when we type \"grunt\" into the terminal.\n    grunt.registerTask('default', ['concat']);\n\n};\n\nNow we need to create that configuration. The documentation can be overwhelming. Let\u2019s focus just on the very simple usage example.\n\nRemember, we have three JavaScript files we\u2019re trying to concatenate. We\u2019ll list file paths to them under src in an array of file paths (as quoted strings) and then we\u2019ll list a destination file as dest. The destination file doesn\u2019t have to exist yet. It will be created when this task runs and squishes all the files together.\n\nBoth our jquery.js and carousel.js files are libraries. We most likely won\u2019t be touching them. So, for organization, we\u2019ll keep them in a /js/libs/ folder. Our global.js file is where we write our own code, so that will be right in the /js/ folder. Now let\u2019s tell Grunt to find all those files and squish them together into a single file named production.js, named that way to indicate it is for use on our real live website.\n\nconcat: {   \n    dist: {\n        src: [\n            'js/libs/*.js', // All JS in the libs folder\n            'js/global.js'  // This specific file\n        ],\n        dest: 'js/build/production.js',\n    }\n}\n\nNote: throughout this article there will be little chunks of configuration code like above. The intention is to focus in on the important bits, but it can be confusing at first to see how a particular chunk fits into the larger file. If you ever get confused and need more context, refer to the complete file.\n\nWith that concat configuration in place, head over to the terminal, run the command:\n\ngrunt\n\nand watch it happen! production.js will be created and will be a perfect concatenation of our three files. This was a big aha! moment for me. Feel the power course through your veins. Let\u2019s do more things!\n\nLet\u2019s make Grunt minify that JavaScript\n\nWe have so much prep work done now, adding new tasks for Grunt to run is relatively easy. We just need to:\n\n\n\tFind a Grunt plug-in to do what we want\n\tLearn the configuration style of that plug-in\n\tWrite that configuration to work with our project\n\n\nThe official plug-in for minifying code is grunt-contrib-uglify. Just like we did last time, we just run an NPM command to install it:\n\nnpm install grunt-contrib-uglify --save-dev\n\nThen we alter our Gruntfile.js to load the plug-in:\n\ngrunt.loadNpmTasks('grunt-contrib-uglify');\n\nThen we configure it:\n\nuglify: {\n    build: {\n        src: 'js/build/production.js',\n        dest: 'js/build/production.min.js'\n    }\n}\n\nLet\u2019s update that default task to also run minification:\n\ngrunt.registerTask('default', ['concat', 'uglify']);\n\nSuper-similar to the concatenation set-up, right?\n\nRun grunt at the terminal and you\u2019ll get some deliciously minified JavaScript:\n\n Minified JavaScript\n\nThat production.min.js file is what we would load up for use in our index.html file.\n\nLet\u2019s make Grunt optimize our images\n\nWe\u2019ve got this down pat now. Let\u2019s just go through the motions. The official image minification plug-in for Grunt is grunt-contrib-imagemin. Install it:\n\nnpm install grunt-contrib-imagemin --save-dev\n\nRegister it in the Gruntfile.js:\n\ngrunt.loadNpmTasks('grunt-contrib-imagemin');\n\nConfigure it:\n\nimagemin: {\n    dynamic: {\n        files: [{\n            expand: true,\n            cwd: 'images/',\n            src: ['**/*.{png,jpg,gif}'],\n            dest: 'images/build/'\n        }]\n    }\n}\n\nMake sure it runs:\n\ngrunt.registerTask('default', ['concat', 'uglify', 'imagemin']);\n\nRun grunt and watch that gorgeous squishification happen:\n\n Squished images\n\nGotta love performance increases for nearly zero effort.\n\nLet\u2019s get a little bit smarter and automate\n\nWhat we\u2019ve done so far is awesome and incredibly useful. But there are a couple of things we can get smarter on and make things easier on ourselves, as well as Grunt:\n\n\n\tRun these tasks automatically when they should\n\tRun only the tasks needed at the time\n\n\nFor instance:\n\n\n\tConcatenate and minify JavaScript when JavaScript changes\n\tOptimize images when a new image is added or an existing one changes\n\n\nWe can do this by watching files. We can tell Grunt to keep an eye out for changes to specific places and, when changes happen in those places, run specific tasks. Watching happens through the official grunt-contrib-watch plugin.\n\nI\u2019ll let you install it. It is exactly the same process as the last few plug-ins we installed. We configure it by giving watch specific files (or folders, or both) to watch. By watch, I mean monitor for file changes, file deletions or file additions. Then we tell it what tasks we want to run when it detects a change.\n\nWe want to run our concatenation and minification when anything in the /js/ folder changes. When it does, we should run the JavaScript-related tasks. And when things happen elsewhere, we should not run the JavaScript-related tasks, because that would be irrelevant. So:\n\nwatch: {\n    scripts: {\n        files: ['js/*.js'],\n        tasks: ['concat', 'uglify'],\n        options: {\n            spawn: false,\n        },\n    } \n}\n\nFeels pretty comfortable at this point, hey? The only weird bit there is the spawn thing. And you know what? I don\u2019t even really know what that does. From what I understand from the documentation it is the smart default. That\u2019s real-world development. Just leave it alone if it\u2019s working and if it\u2019s not, learn more.\n\nNote: Isn\u2019t it frustrating when something that looks so easy in a tutorial doesn\u2019t seem to work for you? If you can\u2019t get Grunt to run after making a change, it\u2019s very likely to be a syntax error in your Gruntfile.js. That might look like this in the terminal:\n\n Errors running Grunt\n\nUsually Grunt is pretty good about letting you know what happened, so be sure to read the error message. In this case, a syntax error in the form of a missing comma foiled me. Adding the comma allowed it to run.\n\nLet\u2019s make Grunt do our preprocessing\n\nThe last thing on our list from the top of the article is using Sass \u2014 yet another task Grunt is well-suited to run for us. But wait? Isn\u2019t Sass technically in Ruby? Indeed it is. There is a version of Sass that will run in Node and thus not add an additional dependency to our project, but it\u2019s not quite up-to-snuff with the main Ruby project. So, we\u2019ll use the official grunt-contrib-sass plug-in which just assumes you have Sass installed on your machine. If you don\u2019t, follow the command line instructions.\n\nWhat\u2019s neat about Sass is that it can do concatenation and minification all by itself. So for our little project we can just have it compile our main global.scss file:\n\nsass: {\n    dist: {\n        options: {\n            style: 'compressed'\n        },\n        files: {\n            'css/build/global.css': 'css/global.scss'\n        }\n    } \n}\n\nWe wouldn\u2019t want to manually run this task. We already have the watch plug-in installed, so let\u2019s use it! Within the watch configuration, we\u2019ll add another subtask:\n\ncss: {\n    files: ['css/*.scss'],\n    tasks: ['sass'],\n    options: {\n        spawn: false,\n    }\n}\n\nThat\u2019ll do it. Now, every time we change any of our Sass files, the CSS will automaticaly be updated.\n\nLet\u2019s take this one step further (it\u2019s absolutely worth it) and add LiveReload. With LiveReload, you won\u2019t have to go back to your browser and refresh the page. Page refreshes happen automatically and in the case of CSS, new styles are injected without a page refresh (handy for heavily state-based websites).\n\nIt\u2019s very easy to set up, since the LiveReload ability is built into the watch plug-in. We just need to:\n\n\nInstall the browser plug-in\nAdd to the top of the watch configuration:\n. watch: {\n    options: {\n        livereload: true,\n    },\n    scripts: {   \n    /* etc */\n\nRestart the browser and click the LiveReload icon to activate it.\nUpdate some Sass and watch it change the page automatically.\n\n\n Live reloading browser\n\nYum.\n\nPrefer a video?\n\nIf you\u2019re the type that likes to learn by watching, I\u2019ve made a screencast to accompany this article that I\u2019ve published over on CSS-Tricks: First Moments with Grunt\n\nLeveling up\n\nAs you might imagine, there is a lot of leveling up you can do with your build process. It surely could be a full time job in some organizations.\n\nSome hardcore devops nerds might scoff at the simplistic setup we have going here. But I\u2019d advise them to slow their roll. Even what we have done so far is tremendously valuable. And don\u2019t forget this is all free and open source, which is amazing.\n\nYou might level up by adding more useful tasks:\n\n\n\tRunning your CSS through Autoprefixer (A+ Would recommend) instead of a preprocessor add-ons.\n\tWriting and running JavaScript unit tests (example: Jasmine).\n\tBuild your image sprites and SVG icons automatically (example: Grunticon).\n\tStart a server, so you can link to assets with proper file paths and use services that require a real URL like TypeKit and such, as well as remove the need for other tools that do this, like MAMP.\n\tCheck for code problems with HTML-Inspector, CSS Lint, or JS Hint.\n\tHave new CSS be automatically injected into the browser when it ever changes.\n\tHelp you commit or push to a version control repository like GitHub.\n\tAdd version numbers to your assets (cache busting).\n\tHelp you deploy to a staging or production environment (example: DPLOY).\n\n\nYou might level up by simply understanding more about Grunt itself:\n\n\n\tRead Grunt Boilerplate by Mark McDonnell.\n\tRead Grunt Tips and Tricks by Nicolas Bevacqua.\n\tOrganize your Gruntfile.js by splitting it up into smaller files.\n\tCheck out other people\u2019s and projects\u2019 Gruntfile.js.\n\tLearn more about Grunt by digging into its source and learning about its API.\n\n\nLet\u2019s share\n\nI think some group sharing would be a nice way to wrap this up. If you are installing Grunt for the first time (or remember doing that), be especially mindful of little frustrating things you experience(d) but work(ed) through. Those are the things we should share in the comments here. That way we have this safe place and useful resource for working through those confusing moments without the embarrassment. We\u2019re all in this thing together!\n\n \n\n1 Maybe someday someone will make a beautiful Grunt app for your operating system of choice. But I\u2019m not sure that day will come. The configuration of the plug-ins is the important part of using Grunt. Each plug-in is a bit different, depending on what it does. That means a uniquely considered UI for every single plug-in, which is a long shot.\n\nPerhaps a decent middleground is this Grunt DevTools Chrome add-on.\n\n2 Gruntfile.js is often referred to as Gruntfile in documentation and examples. Don\u2019t literally name it Gruntfile \u2014 it won\u2019t work.", "year": "2013", "author": "Chris Coyier", "author_slug": "chriscoyier", "published": "2013-12-11T00:00:00+00:00", "url": "https://24ways.org/2013/grunt-is-not-weird-and-hard/", "topic": "code"}
{"rowid": 104, "title": "Sitewide Search On A Shoe String", "contents": "One of the questions I got a lot when I was building web sites for smaller businesses was if I could create a search engine for their site. Visitors should be able to search only this site and find things without the maintainer having to put \u201crelated articles\u201d  or \u201cfeatured content\u201d links on every page by hand. \n\nBack when this was all fields this wasn\u2019t easy as you either had to write your own scraping tool, use ht://dig or a paid service from providers like Yahoo, Altavista or later on Google. In the former case you had to swallow the bitter pill of computing and indexing all your content and storing it in a database for quick access and in the latter it hurt your wallet.\n\nTimes have moved on and nowadays you can have the same functionality for free using Yahoo\u2019s \u201cBuild your own search service\u201d \u2013 BOSS. The cool thing about BOSS is that it allows for a massive amount of hits a day and you can mash up the returned data in any format you want. Another good feature of it is that it comes with JSON-P as an output format which makes it possible to use it without any server-side component!\n\nStarting with a working HTML form\n\nIn order to add a search to your site, you start with a simple HTML form which you can use without JavaScript. Most search engines will allow you to filter results by domain. In this case we will search \u201cbbc.co.uk\u201d. If you use Yahoo as your standard search, this could be: \n\n<form id=\"customsearch\" action=\"http://search.yahoo.com/search\">\n\t<div>\n\t\t<label for=\"p\">Search this site:</label>\n\t\t<input type=\"text\" name=\"p\" id=\"term\">\n\t\t<input type=\"hidden\" name=\"vs\" id=\"site\" value=\"bbc.co.uk\">\n\t\t<input type=\"submit\" value=\"go\">\n\t</div>\n</form>\n\nThe Google equivalent is:\n\n<form id=\"customsearch\" action=\"http://www.google.co.uk/search\">\n\t<div>\n\t\t<label for=\"p\">Search this site:</label>\n\t\t<input type=\"text\" name=\"as_q\" id=\"term\">\n\t\t<input type=\"hidden\" name=\"as_sitesearch\" id=\"site\" value=\"bbc.co.uk\">\n\t\t<input type=\"submit\" value=\"go\">\n\t</div>\n</form>\n\nIn any case make sure to use the ID term for the search term and site for the site, as this is what we are going to use for the script. To make things easier, also have an ID called customsearch on the form.\n\nTo use BOSS, you should get your own developer API for BOSS and replace the one in the demo code. There is click tracking on the search results to see how successful your app is, so you should make it your own.\n\nAdding the BOSS magic\n\nBOSS is a REST API, meaning you can use it in any HTTP request or in a browser by simply adding the right parameters to a URL. Say for example you want to search \u201cbbc.co.uk\u201d for \u201cchristmas\u201d all you need to do is open the following URL:\n\nhttp://boss.yahooapis.com/ysearch/web/v1/christmas?sites=bbc.co.uk&format=xml&appid=YOUR-APPLICATION-ID\n\nTry it out and click it to see the results in XML. We don\u2019t want XML though, which is why we get rid of the format=xml parameter which gives us the same information in JSON:\n\nhttp://boss.yahooapis.com/ysearch/web/v1/christmas?sites=bbc.co.uk&appid=YOUR-APPLICATION-ID\n\nJSON makes most sense when you can send the output to a function and immediately use it. For this to happen all you need is to add a callback parameter and the JSON will be wrapped in a function call. Say for example we want to call SITESEARCH.found() when the data was retrieved we can do it this way:\n\nhttp://boss.yahooapis.com/ysearch/web/v1/christmas?sites=bbc.co.uk&callback=SITESEARCH.found&appid=YOUR-APPLICATION-ID\n\nYou can use this immediately in a script node if you want to. The following code would display the total amount of search results for the term christmas on bbc.co.uk as an alert:\n\n<script type=\"text/javascript\">\n\tvar SITESEARCH = {};\n\tSITESEARCH.found = function(o){\n\t\talert(o.ysearchresponse.totalhits);\n\t}\n</script>\n<script type=\"text/javascript\" src=\"http://boss.yahooapis.com/ysearch/web/v1/christmas?sites=bbc.co.uk&callback=SITESEARCH.found&appid=Kzv_lcHV34HIybw0GjVkQNnw4AEXeyJ9Rb1gCZSGxSRNrcif_HdMT9qTE1y9LdI-\">\n</script>\n\nHowever, for our example, we need to be a bit more clever with this.\n\nEnhancing the search form\n\n\n\n\nHere\u2019s the script that enhances a search form to show results below it.\n\nSITESEARCH = function(){\n\tvar config = {\n\t\tIDs:{\n\t\t\tsearchForm:'customsearch',\n\t\t\tterm:'term',\n\t\t\tsite:'site'\n\t\t},\n\t\tloading:'Loading results...',\n\t\tnoresults:'No results found.',\n\t\tappID:'YOUR-APP-ID',\n\t\tresults:20\n\t};\n\tvar form;\n\tvar out;\n\tfunction init(){\n\t\tif(config.appID === 'YOUR-APP-ID'){\n\t\t\talert('Please get a real application ID!');\n\t\t} else {\n\t\t\tform = document.getElementById(config.IDs.searchForm);\n\t\t\tif(form){\n\t\t\t\tform.onsubmit = function(){\n\t\t\t\t\tvar site = document.getElementById(config.IDs.site).value;\n\t\t\t\t\tvar term = document.getElementById(config.IDs.term).value;\n\t\t\t\t\tif(typeof site === 'string' && typeof term === 'string'){\n\t\t\t\t\t\tif(typeof out !== 'undefined'){\n\t\t\t\t\t\t\tout.parentNode.removeChild(out);\n\t\t\t\t\t\t}\n\t\t\t\t\t\tout = document.createElement('p');\n\t\t\t\t\t\tout.appendChild(document.createTextNode(config.loading));\n\t\t\t\t\t\tform.appendChild(out);\n\t\t\t\t\t\tvar APIurl = 'http://boss.yahooapis.com/ysearch/web/v1/' + \n\t\t\t\t\t\t\t\t\t\t\t\t\tterm + '?callback=SITESEARCH.found&sites=' + \n\t\t\t\t\t\t\t\t\t\t\t\t\tsite + '&count=' + config.results + \n\t\t\t\t\t\t\t\t\t\t\t\t\t'&appid=' + config.appID;\n\t\t\t\t\t\tvar s = document.createElement('script');\n\t\t\t\t\t\ts.setAttribute('src',APIurl);\n\t\t\t\t\t\ts.setAttribute('type','text/javascript');\n\t\t\t\t\t\tdocument.getElementsByTagName('head')[0].appendChild(s);\n\t\t\t\t\t\treturn false;\n\t\t\t\t\t}\n\t\t\t\t};\n\t\t\t}\n\t\t}\n\t};\n\tfunction found(o){\n\t\tvar list = document.createElement('ul');\n\t\tvar results = o.ysearchresponse.resultset_web;\n\t\tif(results){\n\t\t\tvar item,link,description;\n\t\t\tfor(var i=0,j=results.length;i<j;i++){\n\t\t\t\titem = document.createElement('li');\n\t\t\t\tlink = document.createElement('a');\n\t\t\t\tlink.setAttribute('href',results[i].clickurl);\n\t\t\t\tlink.innerHTML = results[i].title;\n\t\t\t\titem.appendChild(link);\n\t\t\t\tdescription = document.createElement('p');\n\t\t\t\tdescription.innerHTML = results[i]['abstract'];\n\t\t\t\titem.appendChild(description);\n\t\t\t\tlist.appendChild(item);\n\t\t\t}\n\t\t} else {\n\t\t\tlist = document.createElement('p');\n\t\t\tlist.appendChild(document.createTextNode(config.noresults));\n\t\t}\n\t\tform.replaceChild(list,out);\n\t\tout = list;\n\t};\n\treturn{\n\t\tconfig:config,\n\t\tinit:init,\n\t\tfound:found\n\t};\n}();\n\nOooohhhh scary code! Let\u2019s go through this one bit at a time:\n\nWe start by creating a module called SITESEARCH and give it an configuration object: \n\nSITESEARCH = function(){\n\tvar config = {\n\t\tIDs:{\n\t\t\tsearchForm:'customsearch',\n\t\t\tterm:'term',\n\t\t\tsite:'site'\n\t\t},\n\t\tloading:'Loading results...',\n\t\tappID:'YOUR-APP-ID',\n\t\tresults:20\n\t}\n\nConfiguration objects are a great idea to make your code easy to change and also to override. In this case you can define different IDs than the one agreed upon earlier, define a message to show when the results are loading, when there aren\u2019t any results, the application ID and the number of results that should be displayed.\n\nNote: you need to replace \u201cYOUR-APP-ID\u201d with the real ID you retrieved from BOSS, otherwise the script will complain! \n\nvar form;\nvar out;\nfunction init(){\n\tif(config.appID === 'YOUR-APP-ID'){\n\t\talert('Please get a real application ID!');\n\t} else {\n\nWe define form and out as variables to make sure that all the methods in the module have access to them. We then check if there was a real application ID defined. If there wasn\u2019t, the script complains and that\u2019s that.      \n\nform = document.getElementById(config.IDs.searchForm);\nif(form){\n\tform.onsubmit = function(){\n\t\tvar site = document.getElementById(config.IDs.site).value;\n\t\tvar term = document.getElementById(config.IDs.term).value;\n\t\tif(typeof site === 'string' && typeof term === 'string'){      \n\nIf the application ID was a winner, we check if the form with the provided ID exists and apply an onsubmit event handler. The first thing we get is the values of the site we want to search in and the term that was entered and check that those are strings.\n\nif(typeof out !== 'undefined'){\n\tout.parentNode.removeChild(out);\n}\nout = document.createElement('p');\nout.appendChild(document.createTextNode(config.loading));\nform.appendChild(out);  \n\nIf both are strings we check of out is undefined. We will create a loading message and subsequently the list of search results later on and store them in this variable. So if out is defined, it\u2019ll be an old version of a search (as users will re-submit the form over and over again)  and we need to remove that old version.\n\nWe then create a paragraph with the loading message and append it to the form.\n\nvar APIurl = 'http://boss.yahooapis.com/ysearch/web/v1/' + \n\t\t\t\t\t\t\t\t\t\t\t\tterm + '?callback=SITESEARCH.found&sites=' + \n\t\t\t\t\t\t\t\t\t\t\t\tsite + '&count=' + config.results + \n\t\t\t\t\t\t\t\t\t\t\t\t'&appid=' + config.appID;\n\t\t\t\t\tvar s = document.createElement('script');\n\t\t\t\t\ts.setAttribute('src',APIurl);\n\t\t\t\t\ts.setAttribute('type','text/javascript');\n\t\t\t\t\tdocument.getElementsByTagName('head')[0].appendChild(s);\n\t\t\t\t\treturn false;\n\t\t\t\t}\n\t\t\t};\n\t\t}\n\t}\n};\n\nNow it is time to call the BOSS API by assembling a correct REST URL, create a script node and apply it to the head of the document. We return false to ensure the form does not get submitted as we want to stay on the page.\n\nNotice that we are using SITESEARCH.found as the callback method, which means that we need to define this one to deal with the data returned by the API.\n\nfunction found(o){\n\tvar list = document.createElement('ul');\n\tvar results = o.ysearchresponse.resultset_web;\n\tif(results){\n\t\tvar item,link,description;\n\nWe create a new list and then get the resultset_web array from the data returned from the API. If there aren\u2019t any results returned, this array will not exist which is why we need to check for it. Once we done that we can define three variables to repeatedly store the item title we want to display, the link to point to and the description of the link.\n\nfor(var i=0,j=results.length;i<j;i++){\n\titem = document.createElement('li');\n\tlink = document.createElement('a');\n\tlink.setAttribute('href',results[i].clickurl);\n\tlink.innerHTML = results[i].title;\n\titem.appendChild(link);\n\tdescription = document.createElement('p');\n\tdescription.innerHTML = results[i]['abstract'];\n\titem.appendChild(description);\n\tlist.appendChild(item);\n}\n\nWe then loop over the results array and assemble a list of results with the titles in links and paragraphs with the abstract of the site. Notice the bracket notation for abstract as abstract is a reserved word in JavaScript2 :).\n\n} else {\n\t\tlist = document.createElement('p');\n\t\tlist.appendChild(document.createTextNode(config.noresults));\n\t}\n\tform.replaceChild(list,out);\n\tout = list;\n};      \n\nIf there aren\u2019t any results, we define a paragraph with the no results message as list. In any case we replace the old out (the loading message) with the list and re-define out as the list.  \n\nreturn{\n\t\tconfig:config,\n\t\tinit:init,\n\t\tfound:found\n\t};\n}();\n\nAll that is left to do is return the properties and methods we want to make public. In this case found needs to be public as it is accessed by the API return. We return init to make it accessible and config to allow implementers to override any of the properties.\n\nUsing the script\n\n\nIn order to use this script, all you need to do is to add it after the form in the document, override the API key with your own and call init():\n\n<form id=\"customsearch\" action=\"http://search.yahoo.com/search\">\n\t<div>\n\t\t<label for=\"p\">Search this site:</label>\n\t\t<input type=\"text\" name=\"p\" id=\"term\">\n\t\t<input type=\"hidden\" name=\"vs\" id=\"site\" value=\"bbc.co.uk\">\n\t\t<input type=\"submit\" value=\"go\">\n\t</div>\n</form>\n<script type=\"text/javascript\" src=\"boss-site-search.js\"></script>\n<script type=\"text/javascript\">\n\tSITESEARCH.config.appID = 'copy-the-id-you-know-to-get-where';\n\tSITESEARCH.init();\n</script>\n\nWhere to go from here\n\nThis is just a very simple example of what you can do with BOSS. You can define languages and regions, retrieve and display images and news and mix the results with other data sources before displaying them. One very cool feature is that by adding a view=keyterms parameter to the URL you can get the keywords of each of the results to drill deeper into the search. An example for this written in PHP is available on the YDN blog. For JavaScript solutions there is a handy wrapper called yboss available to help you go nuts.", "year": "2008", "author": "Christian Heilmann", "author_slug": "chrisheilmann", "published": "2008-12-04T00:00:00+00:00", "url": "https://24ways.org/2008/sitewide-search-on-a-shoestring/", "topic": "code"}
{"rowid": 139, "title": "Flickr Photos On Demand with getFlickr", "contents": "In case you don\u2019t know it yet, Flickr is great. It is a lot of fun to upload, tag and caption photos and it is really handy to get a vast network of contacts through it. \n\nUsing Flickr photos outside of it is a bit of a problem though. There is a Flickr API, and you can get almost every page as an RSS feed, but in general it is a bit tricky to use Flickr photos inside your blog posts or web sites. You might not want to get into the whole API game or use a server side proxy script as you cannot retrieve RSS with Ajax because of the cross-domain security settings.\n\nHowever, Flickr also provides an undocumented JSON  output, that can be used to hack your own solutions in JavaScript without having to use a server side script.\n\n\n\tIf you enter the URL http://flickr.com/photos/tags/panda you get to the flickr page with photos tagged \u201cpanda\u201d.\n\tIf you enter the URL http://api.flickr.com/services/feeds/photos_public.gne?tags=panda&format=rss_200 you get the same page as an RSS feed.\n\tIf you enter the URL http://api.flickr.com/services/feeds/photos_public.gne?tags=panda&format=json you get a JavaScript function called jsonFlickrFeed with a parameter that contains the same data in JSON format\n\n\nYou can use this to easily hack together your own output by just providing a function with the same name. I wanted to make it easier for you, which is why I created the helper getFlickr for you to download and use.\n\ngetFlickr for Non-Scripters\n\nSimply include the javascript file getflickr.js and the style getflickr.css in the head of your document:\n\n<script type=\"text/javascript\" src=\"getflickr.js\"></script>\n<link rel=\"stylesheet\" href=\"getflickr.css\" type=\"text/css\">\n\nOnce this is done you can add links to Flickr pages anywhere in your document, and when you give them the CSS class getflickrphotos they get turned into gallery links. When a visitor clicks these links they turn into loading messages and show a \u201cpopup\u201d gallery with the connected photos once they were loaded. As the JSON returned is very small it won\u2019t take long. You can close the gallery, or click any of the thumbnails to view a photo. Clicking the photo makes it disappear and go back to the thumbnails.\n\nCheck out the example page and click the different gallery links to see the results.\n\nNotice that getFlickr works with Unobtrusive JavaScript as when scripting is disabled the links still get to the photos on Flickr.\n\ngetFlickr for JavaScript Hackers\n\nIf you want to use getFlickr with your own JavaScripts you can use its main method leech():\n\ngetFlickr.leech(sTag, sCallback);\n\n \n\tsTag\n\tthe tag you are looking for\n\tsCallback\n\tan optional function to call when the data was retrieved.\n \n\nAfter you called the leech() method you have two strings to use:\n\n \n\tgetFlickr.html[sTag]\n\tcontains an HTML list (without the outer UL element) of all the images linked to the correct pages at flickr. The images are the medium size, you can easily change that by replacing _m.jpg with _s.jpg for thumbnails.\n\tgetFlickr.tags[sTag]\n\tcontains a string of all the other tags flickr users added with the tag you searched for(space separated)\n \n\nYou can call getFlickr.leech() several times when the page has loaded to cache several result feeds before the page gets loaded. This\u2019ll make the photos quicker for the end user to show up. If you want to offer a form for people to search for flickr photos and display them immediately you can use the following HTML:\n\n<form onsubmit=\"getFlickr.leech(document.getElementById('tag').value, 'populate');return false\">\n  <label for=\"tag\">Enter Tag</label>\n  <input type=\"text\" id=\"tag\" name=\"tag\" />\n  <input type=\"submit\" value=\"energize\" />\n  <h3>Tags:</h3><div id=\"tags\"></div>\n  <h3>Photos:</h3><ul id=\"photos\"></ul>\n</form>\n\nAll the JavaScript you\u2019ll need (for a basic display) is this:\n\nfunction populate(){\n  var tag = document.getElementById('tag').value;\n  document.getElementById('photos').innerHTML = getFlickr.html[tag].replace(/_m\\.jpg/g,'_s.jpg');\n  document.getElementById('tags').innerHTML = getFlickr.tags[tag];\n  return false;\n}\n\nEasy as pie, enjoy!\n\nCheck out the example page and try the form to see the results.", "year": "2006", "author": "Christian Heilmann", "author_slug": "chrisheilmann", "published": "2006-12-03T00:00:00+00:00", "url": "https://24ways.org/2006/flickr-photos-on-demand/", "topic": "code"}
{"rowid": 161, "title": "Keeping JavaScript Dependencies At Bay", "contents": "As we are writing more and more complex JavaScript applications we run into issues that have hitherto (god I love that word) not been an issue. The first decision we have to make is what to do when planning our app: one big massive JS file or a lot of smaller, specialised files separated by task. \n\nPersonally, I tend to favour the latter, mainly because it allows you to work on components in parallel with other developers without lots of clashes in your version control. It also means that your application will be more lightweight as you only include components on demand.\n\nStarting with a global object\n\nThis is why it is a good plan to start your app with one single object that also becomes the namespace for the whole application, say for example myAwesomeApp:\n\nvar myAwesomeApp = {};\n\nYou can nest any necessary components into this one and also make sure that you check for dependencies like DOM support right up front.\n\nAdding the components\n\nThe other thing to add to this main object is a components object, which defines all the components that are there and their file names.\n\nvar myAwesomeApp = {\n\tcomponents :{\n\t\tformcheck:{\n\t\t\turl:'formcheck.js',\n\t\t\tloaded:false\n\t\t},\n\t\tdynamicnav:{\n\t\t\turl:'dynamicnav.js',\n\t\t\tloaded:false\n\t\t},\n\t\tgallery:{\n\t\t\turl:'gallery.js',\n\t\t\tloaded:false\n\t\t},\n\t\tlightbox:{\n\t\t\turl:'lightbox.js',\n\t\t\tloaded:false\n\t\t}\n\t}\n};\n\nTechnically you can also omit the loaded properties, but it is cleaner this way. The next thing to add is an addComponent function that can load your components on demand by adding new SCRIPT elements to the head of the documents when they are needed.\n\nvar myAwesomeApp = {\n\tcomponents :{\n\t\tformcheck:{\n\t\t\turl:'formcheck.js',\n\t\t\tloaded:false\n\t\t},\n\t\tdynamicnav:{\n\t\t\turl:'dynamicnav.js',\n\t\t\tloaded:false\n\t\t},\n\t\tgallery:{\n\t\t\turl:'gallery.js',\n\t\t\tloaded:false\n\t\t},\n\t\tlightbox:{\n\t\t\turl:'lightbox.js',\n\t\t\tloaded:false\n\t\t}\n\t},\n\taddComponent:function(component){\n\t\tvar c = this.components[component];\n\t\tif(c && c.loaded === false){\n\t\t\tvar s = document.createElement('script');\n\t\t\ts.setAttribute('type', 'text/javascript');\n\t\t\ts.setAttribute('src',c.url);\n\t\t\tdocument.getElementsByTagName('head')[0].appendChild(s);\n\t\t}\n\t}\n};\n\nThis allows you to add new components on the fly when they are not defined:\n\nif(!myAwesomeApp.components.gallery.loaded){\n\tmyAwesomeApp.addComponent('gallery');\n};\n\nVerifying that components have been loaded\n\nHowever, this is not safe as the file might not be available. To make the dynamic adding of components safer each of the components should have a callback at the end of them that notifies the main object that they indeed have been loaded:\n\nvar myAwesomeApp = {\n\tcomponents :{\n\t\tformcheck:{\n\t\t\turl:'formcheck.js',\n\t\t\tloaded:false\n\t\t},\n\t\tdynamicnav:{\n\t\t\turl:'dynamicnav.js',\n\t\t\tloaded:false\n\t\t},\n\t\tgallery:{\n\t\t\turl:'gallery.js',\n\t\t\tloaded:false\n\t\t},\n\t\tlightbox:{\n\t\t\turl:'lightbox.js',\n\t\t\tloaded:false\n\t\t}\n\t},\n\taddComponent:function(component){\n\t\tvar c = this.components[component];\n\t\tif(c && c.loaded === false){\n\t\t\tvar s = document.createElement('script');\n\t\t\ts.setAttribute('type', 'text/javascript');\n\t\t\ts.setAttribute('src',c.url);\n\t\t\tdocument.getElementsByTagName('head')[0].appendChild(s);\n\t\t}\n\t},\n\tcomponentAvailable:function(component){\n\t\tthis.components[component].loaded = true;\n\t}\n}\n\nFor example the gallery.js file should call this notification as a last line:\n\nmyAwesomeApp.gallery = function(){\n\t// [... other code ...]\n}();\nmyAwesomeApp.componentAvailable('gallery');\n\nTelling the implementers when components are available\n\nThe last thing to add (actually as a courtesy measure for debugging and implementers) is to offer a listener function that gets notified when the component has been loaded:\n\nvar myAwesomeApp = {\n\tcomponents :{\n\t\tformcheck:{\n\t\t\turl:'formcheck.js',\n\t\t\tloaded:false\n\t\t},\n\t\tdynamicnav:{\n\t\t\turl:'dynamicnav.js',\n\t\t\tloaded:false\n\t\t},\n\t\tgallery:{\n\t\t\turl:'gallery.js',\n\t\t\tloaded:false\n\t\t},\n\t\tlightbox:{\n\t\t\turl:'lightbox.js',\n\t\t\tloaded:false\n\t\t}\n\t},\n\taddComponent:function(component){\n\t\tvar c = this.components[component];\n\t\tif(c && c.loaded === false){\n\t\t\tvar s = document.createElement('script');\n\t\t\ts.setAttribute('type', 'text/javascript');\n\t\t\ts.setAttribute('src',c.url);\n\t\t\tdocument.getElementsByTagName('head')[0].appendChild(s);\n\t\t}\n\t},\n\tcomponentAvailable:function(component){\n\t\tthis.components[component].loaded = true;\n\t\tif(this.listener){\n\t\t\tthis.listener(component);\n\t\t};\n\t}\n};\n\nThis allows you to write a main listener function that acts when certain components have been loaded, for example:\n\nmyAwesomeApp.listener = function(component){\n\tif(component === 'gallery'){\n\t   showGallery();\n\t}\n};\n\nExtending with other components\n\nAs the main object is public, other developers can extend the components object with own components and use the listener function to load dependent components. Say you have a bespoke component with data and labels in extra files:\n\nmyAwesomeApp.listener = function(component){\n\tif(component === 'bespokecomponent'){\n\t\tmyAwesomeApp.addComponent('bespokelabels');\n\t};\n\tif(component === 'bespokelabels'){\n\t\tmyAwesomeApp.addComponent('bespokedata');\n\t};\n\tif(component === 'bespokedata'){\n\t\tmyAwesomeApp,bespokecomponent.init();\n\t};\n};\nmyAwesomeApp.components.bespokecomponent = {\n\turl:'bespoke.js',\n\tloaded:false\n};\nmyAwesomeApp.components.bespokelabels = {\n\turl:'bespokelabels.js',\n\tloaded:false\n};\nmyAwesomeApp.components.bespokedata = {\n\turl:'bespokedata.js',\n\tloaded:false\n};\nmyAwesomeApp.addComponent('bespokecomponent');\n\nFollowing this practice you can write pretty complex apps and still have full control over what is available when. You can also extend this to allow for CSS files to be added on demand.\n\nInfluences\n\nIf you like this idea and wondered if someone already uses it, take a look at the Yahoo! User Interface library, and especially at the YAHOO_config option of the global YAHOO.js object.", "year": "2007", "author": "Christian Heilmann", "author_slug": "chrisheilmann", "published": "2007-12-18T00:00:00+00:00", "url": "https://24ways.org/2007/keeping-javascript-dependencies-at-bay/", "topic": "code"}
{"rowid": 186, "title": "The Web Is Your CMS", "contents": "It is amazing what you can do these days with the services offered on the web. Flickr stores terabytes of photos for us and converts them automatically to all kind of sizes, finds people in them and even allows us to edit them online. YouTube does almost the same complete job with videos, LinkedIn allows us to maintain our CV, Delicious our bookmarks and so on.\n\nWe don\u2019t have to do these tasks ourselves any more, as all of these systems also come with ways to use the data in the form of Application Programming Interfaces, or APIs for short. APIs give us raw data when we send requests telling the system what we want to get back.\n\nThe problem is that every API has a different idea of what is a simple way of accessing this data and in which format to give it back.\n\nMaking it easier to access APIs\n\nWhat we need is a way to abstract the pains of different data formats and authentication formats away from the developer \u2014 and this is the purpose of the Yahoo Query Language, or YQL for short. \n\nLibraries like jQuery and YUI make it easy and reliable to use JavaScript in browsers (yes, even IE6) and YQL allows us to access web services and even the data embedded in web documents in a simple fashion \u2013 SQL style.\n\nSelect * from the web and filter it the way I want\n\nYQL is a web service that takes a few inputs itself:\n\n\n\tA query that tells it what to get, update or access\n\tAn output format \u2013 XML, JSON, JSON-P or JSON-P-X\n\tA callback function (if you defined JSON-P or JSON-P-X)\n\n\nYou can try it out yourself \u2013 check out this link to get back Flickr photos for the search term \u2018santa\u2019*%20from%20flickr.photos.search%20where%20text%3D%22santa%22&format=xml in XML format. The YQL query for this is \n\nselect * from flickr.photos.search where text=\"santa\"\n\nThe easiest way to take your first steps with YQL is to look at the console. There you get sample queries, access to all the data sources available to you and you can easily put together complex queries. In this article, however, let\u2019s use PHP to put together a web page that pulls in Flickr photos, blog posts, Videos from YouTube and latest bookmarks from Delicious.\n\nCheck out the demo and get the source code on GitHub.\n\n<?php\n  /* YouTube RSS */\n  $query = 'select description from rss(5) where url=\"http://gdata.youtube.com/feeds/base/users/chrisheilmann/uploads?alt=rss&v=2&orderby=published&client=ytapi-youtube-profile\";';\n  /* Flickr search by user id */\n  $query .= 'select farm,id,owner,secret,server,title from flickr.photos.search where user_id=\"11414938@N00\";';\n  /* Delicious RSS */\n  $query .= 'select title,link from rss where url=\"http://feeds.delicious.com/v2/rss/codepo8?count=10\";';\n  /* Blog RSS */\n  $query .= 'select title,link from rss where url=\"http://feeds.feedburner.com/wait-till-i/gwZf\"';\n  /* The YQL web service root with JSON as the output */\n  $root = 'http://query.yahooapis.com/v1/public/yql?format=json&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys';\n  /* Assemble the query */\n  $query = \"select * from query.multi where queries='\".$query.\"'\";\n  $url = $root . '&q=' . urlencode($query);\n  /* Do the curl call (access the data just like a browser would) */\n  $ch = curl_init(); \n  curl_setopt($ch, CURLOPT_URL, $url); \n  curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); \n  curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);\n  curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);\n  $output = curl_exec($ch); \n  curl_close($ch);\n  $data = json_decode($output);\n  $results = $data->query->results->results;\n  /* YouTube output */\n  $youtube = '<ul id=\"youtube\">';\n  foreach($results[0]->item as $r){\n\t$cleanHTML = undoYouTubeMarkupCrimes($r->description);\n\t$youtube .= '<li>'.$cleanHTML.'</li>';\n  }\n  $youtube .= '</ul>';\n  /* Flickr output */\n  $flickr = '<ul id=\"flickr\">';\n  foreach($results[1]->photo as $r){\n\t$flickr .= '<li>'.\n\t\t\t   '<a href=\"http://www.flickr.com/photos/codepo8/'.$r->id.'/\">'.\n\t\t\t   '<img src=\"http://farm' .$r->farm . '.static.flickr.com/'.\n\t\t\t   $r->server . '/' . $r->id . '_' . $r->secret . \n\t\t\t   '_s.jpg\" alt=\"'.$r->title.'\"></a></li>';\n  }\n  $flickr .= '</ul>';\n  /* Delicious output */\n  $delicious = '<ul id=\"delicious\">';\n  foreach($results[2]->item as $r){\n\t$delicious .= '<li><a href=\"'.$r->link.'\">'.$r->title.'</a></li>';\n  }\n  $delicious .= '</ul>';\n  /* Blog output */\n  $blog = '<ul id=\"blog\">';\n  foreach($results[3]->item as $r){\n\t$blog .= '<li><a href=\"'.$r->link.'\">'.$r->title.'</a></li>';\n  }\n  $blog .= '</ul>';\n  function undoYouTubeMarkupCrimes($str){\n\t$cleaner = preg_replace('/555px/','100%',$str);\n\t$cleaner = preg_replace('/width=\"[^\"]+\"/','',$cleaner);\n\t$cleaner = preg_replace('/<tbody>/','<colgroup><col width=\"20%\"><col width=\"50%\"><col width=\"30%\"></colgroup><tbody>',$cleaner);\n\treturn $cleaner;\n  }\n?>\n\nWhat we are doing here is create a few different YQL statements and queue them together with the query.multi table. Each of these can be run inside YQL itself. Check out the YouTube, Flickr, Delicious and Blog example in the console if you don\u2019t believe me. The benefit of using this table is that we don\u2019t make individual requests for each query but we get all the data in one single request \u2013 which means a much better performing solution as the YQL server farm is faster on the web than our servers.\n\nWe point the query to the YQL web service end point and get the resulting data using cURL. All that we need to do then is to convert the returned data to HTML lists that can be printed out inside an HTML template.\n\nMixing, matching and using HTML as a data source\n\nThis was a simple example of what YQL can do for you. Where it gets really powerful however is by mixing and matching different APIs. YQL is also a good tool to get information from HTML documents. By using the html table you can load the content of an HTML document (which gets fixed automatically by HTMLTidy) and use XPATH to filter down results to what you need. Take the following example which takes headlines from the news.bbc.co.uk homepage and runs the results through Yahoo\u2019s Term Extractor API to give you a list of currently hot topics.\n\nselect * from search.termextract where context in (\n  select content from html where url=\"http://news.bbc.co.uk\" and xpath=\"//table[@width=800]//a\"\n)\n\nTry it out in the console or see the results here. In English, this means:\n\n\n\tGo to http://news.bbc.co.uk and get me the HTML\n\tRun it through HTML Tidy to clean it up.\n\tGet me only the links inside the table with an attribute of width and the value 800\n\tGet only the content of the link and for each of the links\n\t\n\t\tTake the content and send it as context to the Yahoo Term Extractor API\n\t\n\t\n\nIf we choose JSON-P as the output format we can use the outcome directly in JavaScript (see this demo or see its source):\n\n<ul id=\"hottopics\"></ul>\n<script type=\"text/javascript\">\nfunction hottopics(o){\n  var res = o.query.results.Result,\n\t  all = res.length,\n\t  topics = {},\n\t  out = [],\n\t  html = '',\n\t  i=0;\n  /* create hash from topics to prevent repetition */\t \n  for(i=0;i<all;i++){\n\ttopics[res[i]] = res[i];\n  };\n  for(i in topics){\n\tout.push(i);\n  };\n  html = '<li>' + out.join('</li><li>') + '</li>';\n  document.getElementById('hottopics').innerHTML = html;\n};\n</script>\n<script type=\"text/javascript\" src=\"http://query.yahooapis.com/v1/public/yql?q=select%20content%20from%20search.termextract%20where %20context%20in%20(select%20content%20from%20html%20where%20url%3D%22http%3A%2F%2Fnews.bbc.co.uk%22%20and%20xpath%3D%22%2F%2Ftable%5B%40width%3D800%5D%2F%2Fa%22)&format=json&callback=hottopics\"></script>\n\nUsing JSON, we can also use PHP which means the demo works for everybody \u2013 not only those with JavaScript enabled (see this demo or see its source):\n\n<ul id=\"hottopics\"><li>\n<?php\n$url = 'http://query.yahooapis.com/v1/public/yql?q=select%20content'.\n\t   '%20from%20search.termextract%20where%20context%20in'.\n\t   '%20(select%20content%20from%20html%20where%20url%3D%22'.\n\t   'http%3A%2F%2Fnews.bbc.co.uk%22%20and%20xpath%3D%22%2F%2F'.\n\t   'table%5B%40width%3D800%5D%2F%2Fa%22)&format=json';\n$ch = curl_init(); \ncurl_setopt($ch, CURLOPT_URL, $url); \ncurl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); \ncurl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);\ncurl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);\n$output = curl_exec($ch); \ncurl_close($ch);\n$data = json_decode($output);\n$topics = array_unique($data->query->results->Result);\necho join('</li><li>',$topics);\n?>\n</li></ul>\n\nSummary\n\nThis article could only scratch the surface of YQL. You have not only read access to the web but you can also write to web services. For example you can update Twitter, post to your WordPress blog or shorten a URL with bit.ly. Using Open Tables you can add any web service to the YQL interface and you can even run server-side JavaScript which is for example useful to return Flickr photos as HTML or get the HTML content from a document that needs POST data.\n\nThe web of data is already here, and using YQL you don\u2019t have to be a web services expert to use it and be part of it.", "year": "2009", "author": "Christian Heilmann", "author_slug": "chrisheilmann", "published": "2009-12-17T00:00:00+00:00", "url": "https://24ways.org/2009/the-web-is-your-cms/", "topic": "code"}
{"rowid": 233, "title": "Wrapping Things Nicely with HTML5 Local Storage", "contents": "HTML5 is here to turn the web from a web of hacks into a web of applications \u2013 and we are well on the way to this goal. The coming year will be totally and utterly awesome if you are excited about web technologies.\n\nThis year the HTML5 revolution started and there is no stopping it. For the first time all the browser vendors are rallying together to make a technology work. The new browser war is fought over implementation of the HTML5 standard and not over random additions. We live in exciting times.\n\nStarting with a bang\n\nAs with every revolution there is a lot of noise with bangs and explosions, and that\u2019s the stage we\u2019re at right now. HTML5 showcases are often CSS3 showcases, web font playgrounds, or video and canvas examples.\n\nThis is great, as it gets people excited and it gives the media something to show. There is much more to HTML5, though. Let\u2019s take a look at one of the less sexy, but amazingly useful features of HTML5 (it was in the HTML5 specs, but grew at such an alarming rate that it warranted its own spec): storing information on the client-side.\n\nWhy store data on the client-side?\n\nStoring information in people\u2019s browsers affords us a few options that every application should have:\n\n\n\tYou can retain the state of an application \u2013 when the user comes back after closing the browser, everything will be as she left it. That\u2019s how \u2018real\u2019 applications work and this is how the web ones should, too.\n\tYou can cache data \u2013 if something doesn\u2019t change then there is no point in loading it over the Internet if local access is so much faster\n\tYou can store user preferences \u2013 without needing to keep that data on your server at all.\n\n\nIn the past, storing local data wasn\u2019t much fun.\n\nThe pain of hacky browser solutions\n\nIn the past, all we had were cookies. I don\u2019t mean the yummy things you get with your coffee, endorsed by the blue, furry junkie in Sesame Street, but the other, digital ones. Cookies suck \u2013 it isn\u2019t fun to have an unencrypted HTTP overhead on every server request for storing four kilobytes of data in a cryptic format. It was OK for 1994, but really neither an easy nor a beautiful solution for the task of storing data on the client.\n\nThen came a plethora of solutions by different vendors \u2013 from Microsoft\u2019s userdata to Flash\u2019s LSO, and from Silverlight isolated storage to Google\u2019s Gears. If you want to know just how many crazy and convoluted ways there are to store a bit of information, check out Samy\u2019s evercookie.\n\nClearly, we needed an easier and standardised way of storing local data.\n\nKeeping it simple \u2013 local storage\n\nAnd, lo and behold, we have one. The local storage API (or session storage, with the only difference being that session data is lost when the window is closed) is ridiculously easy to use. All you do is call a few methods on the window.localStorage object \u2013 or even just set the properties directly using the square bracket notation:\n\nif('localStorage' in window && window['localStorage'] !== null){\n\tvar store = window.localStorage;\n\n\t// valid, API way\n\t\tstore.setItem(\u2018cow\u2019,\u2018moo\u2019);\n\t\tconsole.log(\n\t\tstore.getItem(\u2018cow\u2019)\n\t); // => \u2018moo\u2019\n\n\t// shorthand, breaks at keys with spaces\n\t\tstore.sheep = \u2018baa\u2019 \n\t\tconsole.log(\n\t\tstore.sheep \n\t); // \u2018baa\u2019\n\n\t// shorthand for all\n\t\tstore[\u2018dog\u2019] = \u2018bark\u2019\n\t\tconsole.log(\n\t\tstore[\u2018dog\u2019]\n\t); // => \u2018bark\u2019\n\n}\n\nBrowser support is actually pretty good: Chrome 4+; Firefox 3.5+; IE8+; Opera 10.5+; Safari 4+; plus iPhone 2.0+; and Android 2.0+. That should cover most of your needs. Of course, you should check for support first (or use a wrapper library like YUI Storage Utility or YUI Storage Lite).\n\nThe data is stored on a per domain basis and you can store up to five megabytes of data in localStorage for each domain.\n\nStrings attached\n\nBy default, localStorage only supports strings as storage formats. You can\u2019t store results of JavaScript computations that are arrays or objects, and every number is stored as a string. This means that long, floating point numbers eat into the available memory much more quickly than if they were stored as numbers.\n\nvar cowdesc = \"the cow is of the bovine ilk, \"+\n\t\t\"one end is for the moo, the \"+\n\t\t\"other for the milk\";\n\nvar cowdef = {\n\tilk\u201cbovine\u201d,\n\tlegs,\n\tudders,\n\tpurposes\n\t\tfront\u201cmoo\u201d,\n\t\tend\u201cmilk\u201d\n\t}\n};\n\nwindow.localStorage.setItem(\u2018describecow\u2019,cowdesc);\nconsole.log(\n\twindow.localStorage.getItem(\u2018describecow\u2019)\n); // => the cow is of the bovine\u2026 \n\nwindow.localStorage.setItem(\u2018definecow\u2019,cowdef);\nconsole.log(\n\twindow.localStorage.getItem(\u2018definecow\u2019)\n); // => [object Object] = bad!\n\nThis limits what you can store quite heavily, which is why it makes sense to use JSON to encode and decode the data you store:\n\nvar cowdef = {\n\t\"ilk\":\"bovine\",\n\t\"legs\":4,\n\t\"udders\":4,\n\t\"purposes\":{\n\t\"front\":\"moo\",\n\t\"end\":\"milk\"\n\t}\n};\n\nwindow.localStorage.setItem(\u2018describecow\u2019,JSON.stringify(cowdef));\nconsole.log(\n\tJSON.parse(\n\t\twindow.localStorage.getItem(\u2018describecow\u2019)\n\t)\n); // =>  Object { ilk=\u201cbovine\u201d,  more\u2026}\n\nYou can also come up with your own formatting solutions like CSV, or pipe | or tilde ~ separated formats, but JSON is very terse and has native browser support.\n\nSome use case examples\n\nThe simplest use of localStorage is, of course, storing some data: the current state of a game; how far through a multi-form sign-up process a user is; and other things we traditionally stored in cookies. Using JSON, though, we can do cooler things.\n\nSpeeding up web service use and avoiding exceeding the quota\n\nA lot of web services only allow you a certain amount of hits per hour or day, and can be very slow. By using localStorage with a time stamp, you can cache results of web services locally and only access them after a certain time to refresh the data.\n\nI used this technique in my An Event Apart 10K entry, World Info, to only load the massive dataset of all the world information once, and allow for much faster subsequent visits to the site. The following screencast shows the difference:\n\n\n\nFor use with YQL (remember last year\u2019s 24 ways entry?), I\u2019ve built a small script called YQL localcache that wraps localStorage around the YQL data call. An example would be the following:\n\nyqlcache.get({\n\tyql: 'select * from flickr.photos.search where text=\"santa\"',\n\tid: 'myphotos',\n\tcacheage: ( 60*60*1000 ),\n\tcallback: function(data) {\n\t\tconsole.log(data);\n\t}\n});\n\nThis loads photos of Santa from Flickr and stores them for an hour in the key myphotos of localStorage. If you call the function at various times, you receive an object back with the YQL results in a data property and a type property which defines where the data came from \u2013 live is live data, cached means it comes from cache, and freshcache indicates that it was called for the first time and a new cache was primed. The cache will work for an hour (60\u00d760\u00d71,000 milliseconds) and then be refreshed. So, instead of hitting the YQL endpoint over and over again, you hit it once per hour.\n\nCaching a full interface\n\nAnother use case I found was to retain the state of a whole interface of an application by caching the innerHTML once it has been rendered. I use this in the Yahoo Firehose search interface, and you can get the full story about local storage and how it is used in this screencast:\n\n\n\nThe stripped down code is incredibly simple (JavaScript with PHP embed):\n\n// test for localStorage support\nif(('localStorage' in window) && window['localStorage'] !== null){\n\nvar f = document.getElementById(\u2018mainform\u2019);\n// test with PHP if the form was sent (the submit button has the name \u201csent\u201d)\n\n\n\t// get the HTML of the form and cache it in the property \u201cstate\u201d\n\tlocalStorage.setItem(\u2018state\u2019,f.innerHTML);\n\n// if the form hasn\u2019t been sent\u2026\n\n\n\t// check if a state property exists and write back the HTML cache\n\tif(\u2018state\u2019 in localStorage){\n\t\tf.innerHTML = localStorage.getItem(\u2018state\u2019);  \n\t}\n\n\t\n\n}\n\nOther ideas\n\nIn essence, you can use local storage every time you need to speed up access. For example, you could store image sprites in base-64 encoded datasets instead of loading them from a server. Or you could store CSS and JavaScript libraries on the client. Anything goes \u2013 have a play.\n\nIssues with local and session storage\n\nOf course, not all is rainbows and unicorns with the localStorage API. There are a few niggles that need ironing out. As with anything, this needs people to use the technology and raise issues. Here are some of the problems:\n\n\n\tInadequate information about storage quota \u2013 if you try to add more content to an already full store, you get a QUOTA_EXCEEDED_ERR and that\u2019s it. There\u2019s a great explanation and test suite for localStorage quota available.\n\tLack of automatically expiring storage \u2013 a feature that cookies came with. Pamela Fox has a solution (also available as a demo and source code)\n\tLack of encrypted storage \u2013 right now, everything is stored in readable strings in the browser.\n\n\nBigger, better, faster, more!\n\nAs cool as the local and session storage APIs are, they are not quite ready for extensive adoption \u2013 the storage limits might get in your way, and if you really want to go to town with accessing, filtering and sorting data, real databases are what you\u2019ll need. And, as we live in a world of client-side development, people are moving from heavy server-side databases like MySQL to NoSQL environments.\n\nOn the web, there is also a lot of work going on, with Ian Hickson of Google proposing the Web SQL database, and Nikunj Mehta, Jonas Sicking (Mozilla), Eliot Graff (Microsoft) and Andrei Popescu (Google) taking the idea beyond simply replicating MySQL and instead offering Indexed DB as an even faster alternative.\n\nOn the mobile front, a really important feature is to be able to store data to use when you are offline (mobile coverage and roaming data plans anybody?) and you can use the Offline Webapps API for that.\n\nAs I mentioned at the beginning, we have a very exciting time ahead \u2013 let\u2019s make this web work faster and more reliably by using what browsers offer us. For more on local storage, check out the chapter on Dive into HTML5.", "year": "2010", "author": "Christian Heilmann", "author_slug": "chrisheilmann", "published": "2010-12-06T00:00:00+00:00", "url": "https://24ways.org/2010/html5-local-storage/", "topic": "code"}
{"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": 5, "title": "Managing a Mind", "contents": "On 21 May 2013, I woke in a hospital bed feeling exhausted, disorientated and ashamed. The day before, I had tried to kill myself.\n\nIt\u2019s very hard to write about this and share it. It feels like I\u2019m opening up the deepest recesses of my soul and laying everything bare, but I think it\u2019s important we share this as a community. Since starting tentatively to write about my experience, I\u2019ve had many conversations about this: sharing with others; others sharing with me. I\u2019ve been surprised to discover how many people are suffering similarly, thinking that they\u2019re alone. They\u2019re not.\n\nDue to an insane schedule of teaching, writing, speaking, designing and just generally trying to keep up, I reached a point where my buffers completely overflowed. I was working so hard on so many things that I was struggling to maintain control. I was living life on fast-forward and my grasp on everything was slowly slipping.\n\nOn that day, I reached a low point \u2013 the lowest point of my life \u2013 and in that moment I could see only one way out. I surrendered. I can\u2019t really describe that moment. I\u2019m still grappling with it. All I know is that I couldn\u2019t take it any more and I gave up.\n\nI very nearly died.\n\nI\u2019m very fortunate to have survived. I was admitted to hospital, taken there unconscious in an ambulance. On waking, I felt overwhelmed with shame and overcome with remorse, but I was resolved to grasp the situation and address it. The experience has forced me to confront a great deal of issues in my life; it has also encouraged me to seek a deeper understanding of my situation and, in particular, the mechanics of the mind.\n\nThe relentless pace of change\n\nWe work in a fast-paced industry: few others, if any, confront the daily challenges we face. The landscape we work within is characterised by constant flux. It\u2019s changing and evolving at a rate we have never experienced before. Few industries reinvent themselves yearly, monthly, weekly\u2026 Ours is one of these industries. Technology accelerates at an alarming rate and keeping abreast of this change is challenging, to say the least.\n\nAs designers it can be difficult to maintain a knowledge bank that is relevant and fit for purpose. We\u2019re on a constant rollercoaster of endless learning, trying to maintain the pace as, daily, new ideas and innovations emerge \u2014 in some cases fundamentally changing our medium.\n\nUnder the pressure of client work or product design and development, it can be difficult to find the time to focus on learning the new skills we need to remain relevant and functionally competent. The result, all too often, is that the edges of our days have eroded. We no longer work nine to five; instead we work eight to six, and after the working day is over we regroup to spend our evenings learning. It\u2019s an unsustainable situation.\n\nFrom the workshop to the web\n\nAdded to this pressure to keep up, our work is now undertaken under a global gaze, conducted under an ever-present spotlight. Tools like Dribbble, Twitter and others, while incredibly powerful, have an unfortunate side effect, that of unfolding your ideas in public. This shift, from workshop to web, brings with it additional pressure.\n\nIn the past, the early stages of creativity took place within the relative safety of the workshop, an environment where one could take risks and gather feedback from a trusted few. We had space to make and space to break. No more. Our industry\u2019s focus (and society\u2019s focus) on sharing, leads us now to play out our decisions in public. This shift has changed us culturally, slowly but surely easing every aspect of our process \u2013 and lives \u2013 from private to public. This is at once liberating and debilitating.\n\nIf you\u2019re not careful, an addiction to followers, likes, retweets, page views and other forms of measurement can overwhelm you. When you release your work into the wild and all it\u2019s greeted with is silence, it can cripple you.\n\nReflecting on this, in an insightful article titled Derailed, Rogie King asks, \u201cCan social popularity take us off the course of growth and where we were intended to go?\u201d He makes a powerful point, that perhaps we might focus on what really matters, setting aside statistics. He concludes that to grow as practitioners we might be best served by seeking out critique through other avenues, away from the social spotlight.\n\nOn status anxiety and impostor syndrome\n\nFollowing my experience I embarked on a period of self-reflection. I wanted to discover what had driven me to take the course of action I had. I wanted to ensure it never happened again. I wanted to understand how the mind works and, in so doing, learn a little more about myself.\n\nI\u2019ve only begun this journey, but two things I discovered resonated with me: the twin pressures of status anxiety and impostor syndrome.\n\nIn his excellent book Status Anxiety, the philosopher Alain de Botton explores a growing concern with status anxiety, a worry about how others perceive us and how this shapes our relationship with the world. He states:\n\n\n\tWe all worry about what others think of us. We all long to succeed and fear failure. We all suffer \u2013 to a greater or lesser degree, usually privately and with embarrassment \u2013 from status anxiety. [\u2026] This is an almost universal anxiety that rarely gets mentioned directly: an anxiety about what others think of us; about whether we\u2019re judged a success or a failure, a winner or a loser.\n\n\nWe see these pressures played out and amplified in the social sphere we all inhabit. We are social animals and we cannot help but react to the landscape we live and work within. Even if your work receives the public praise you so secretly desire, you find yourself questioning this praise.\n\nA psychological phenomenon in which sufferers are unable to internalise their accomplishments, impostor syndrome is far more widespread than you\u2019d imagine. The author Leigh Buchanan describes it as \u201cA fear that one is not as smart or capable as others think.\u201d As she puts it, \u201cPeople who feel like frauds chalk up their accomplishments to external factors such as luck and timing, or worry they are coasting on charm and personality rather than on talent.\u201d\n\nAt the bottom, this was all I could see. I felt overwhelmed by others\u2019 perception of me. Was I a success or a failure? Would I be discovered as the fraud I\u2019d convinced myself that I was? These twin pressures \u2013 that I was unconscious of at the time \u2013 had lead me to a place of crippling self-doubt, questioning my very existence.\n\nThe act of discovery, of investigating how the mind functions, led me to a deeper understanding of myself. Developing an awareness of psychology and learning about conditions like status anxiety and impostor syndrome helped me to understand and recognise how my mind worked, enabling me to manage it more effectively.\n\n\n\nMake it count\n\nReflecting upon my experience, I began to regroup, to focus on what really mattered. I\u2019d taken on too much \u2014 as I believe many of us do. I was guilty of wanting to do all the things. I started to introduce pauses. Before blindly saying yes to everything, I forced myself to pause and ask: \u201cIs this important?\u201d\n\nOur community offers us huge benefits, but an always-on culture in which we\u2019re bombarded daily by opportunity places temptation in our paths. It\u2019s easy to get sucked in to a vortex of wanting to be a part of everything. It\u2019s important, however, to focus. As Simon Collison puts it:\n\n\n\tI cull and surrender topics. Then I focus on my strengths, mastering my core skills.\n\n\nWe only have so much time and we can only do so much. It\u2019s impossible, indeed futile, to try to do everything. Sometimes we need to step back a little and just enjoy life, enjoy others\u2019 achievements, without feeling the need to be actively involved ourselves.\n\nAs Mahatma Ghandi put it:\n\nA \u2018no\u2019 uttered from deepest conviction is better and greater than a \u2018yes\u2019 merely uttered to please, or what is worse, to avoid trouble.\nYoung India, volume 9, 1927\n\n\nWe need to learn to say no a little more often. We need to focus on the work that matters. This, coupled with an understanding of the mind and how it works, can help us achieve a happier balance between work and life.\n\nDon\u2019t waste your time. You only have one life. Make it count.", "year": "2013", "author": "Christopher Murphy", "author_slug": "christophermurphy", "published": "2013-12-21T00:00:00+00:00", "url": "https://24ways.org/2013/managing-a-mind/", "topic": "process"}
{"rowid": 259, "title": "Designing Your Future", "contents": "I\u2019ve had the pleasure of working for a variety of clients \u2013 both large and small \u2013 over the last 25 years. In addition to my work as a design consultant, I\u2019ve worked as an educator, leading the Interaction Design team at Belfast School of Art, for the last 15 years.\nIn July, 2018 \u2013 frustrated with formal education, not least the ever-present hand of \u2018austerity\u2019 that has ravaged universities in the UK for almost a decade \u2013 I formally reduced my teaching commitment, moving from a full-time role to a half-time role.\nMaking the move from a (healthy!) monthly salary towards a position as a freelance consultant is not without its challenges: one month your salary\u2019s arriving in your bank account (and promptly disappearing to pay all of your bills); the next month, that salary\u2019s been drastically reduced. That can be a shock to the system.\nIn this article, I\u2019ll explore the challenges encountered when taking a life-changing leap of faith. To help you confront \u2018the fear\u2019 \u2013 the nervousness, the sleepless nights and the ever-present worry about paying the bills \u2013 I\u2019ll provide a set of tools that will enable you to take a leap of faith and pursue what deep down drives you.\nIn short: I\u2019ll bare my soul and share everything I\u2019m currently working on to \u2013 once and for all \u2013 make a final bid for freedom.\nThis isn\u2019t easy. I\u2019m sharing my innermost hopes and aspirations, and I might open myself up to ridicule, but I believe that by doing so, I might help others, by providing them with tools to help them make their own leap of faith.\nThe power of visualisation\nAs designers we have skills that we use day in, day out to imagine future possibilities, which we then give form. In our day-to-day work, we use those abilities to design products and services, but I also believe we can use those skills to design something every bit as important: ourselves.\nIn this article I\u2019ll explore three tools that you can use to design your future:\n\nProduct DNA\nArtefacts From the Future\nTomorrow Clients\n\nEach of these tools is designed to help you visualise your future. By giving that future form, and providing a concrete goal to aim for, you put the pieces in place to make that future a reality.\nBrian Eno \u2013 the noted musician, producer and thinker \u2013 states, \u201cHumans are capable of a unique trick: creating realities by first imagining them, by experiencing them in their minds.\u201d Eno helpfully provides a powerful example:\n\nWhen Martin Luther King said, \u201cI have a dream,\u201d he was inviting others to dream that dream with him. Once a dream becomes shared in that way, current reality gets measured against it and then modified towards it.\nThe dream becomes an invisible force which pulls us  forward. By this process it starts to come true. The act of imagining something makes it real.\n\nWhen you imagine your future \u2013 designing an alternate, imagined reality in your mind \u2013 you begin the process of making that future real.\nProduct DNA\nThe first tool, which I use regularly \u2013 for myself and for client work \u2013 is a tool called Product DNA. The intention of this tool is to identify beacons from which you can learn, helping you to visualise your future.\nWe all have heroes \u2013 individuals or organisations \u2013 that we look up to. Ask yourself, \u201cWho are your heroes?\u201d If you had to pick three, who would they be and what could you learn from them? (You probably have more than three, but distilling down to three is an exercise in itself.)\nEarlier this year, when I was putting the pieces in place for a change in career direction, I started with my heroes. I chose three individuals that inspired me:\n\nAlan Moore: the author of \u2018Do Design: Why Beauty is Key to Everything\u2019;\nMark Shayler: the founder of Ape, a strategic consultancy; and\nSeth Godin: a writer and educator I\u2019ve admired and followed for many years.\n\nLooking at each of these individuals, I \u2018borrowed\u2019 a little DNA from each of them. That DNA helped me to paint a picture of the kind of work I wanted to do and the direction I wanted to travel.\n\nMoore\u2019s book - \u2018Do Design\u2019 \u2013 had a powerful influence on me, but the primary inspiration I drew from him was the sense of gravitas he conveyed in his work. Moore\u2019s mission is an important one and he conveys that with an appropriate weight of expression.\nShayler\u2019s work appealed to me for its focus on equipping big businesses with a startup mindset. As he puts it: \u201cI believe that you can do the things that you do better.\u201d That sense \u2013 of helping others to be their best selves \u2013 appealed to me.\nFinally, the words Godin uses to describe himself \u2013 \u201cAn Author, Entrepreneur and Most of All, a Teacher\u201d \u2013 resonated with me. The way he positions himself, as, \u201cmost of all, a teacher,\u201d gave me the belief I needed that I could work as an educator, but beyond the ivory tower of academia.\nI\u2019ve been exploring each of these individuals in depth, learning from them and applying what I learn to my practice. They don\u2019t all know it, but they are all \u2018mentors from afar\u2019.\nIn a moment of serendipity \u2013 and largely, I believe, because I\u2019d used this tool to explore his work \u2013 I was recently invited by Alan Moore to help him develop a leadership programme built around his book.\nThe key lesson here is that not only has this exercise helped me to design my future and give it tangible form, it\u2019s also led to a fantastic opportunity to work with Alan Moore, a thinker who I respect greatly.\nArtefacts From the Future\nThe second tool, which I also use regularly, is a tool called \u2018Artefacts From the Future\u2019. These artefacts \u2013 especially when designed as \u2018finished\u2019 pieces \u2013 are useful for creating provocations to help you see the future more clearly.\n\u2018Artefacts From the Future\u2019 can take many forms: they might be imagined magazine articles, news items, or other manifestations of success. By imagining these end points and giving them form, you clarify your goals, establishing something concrete to aim for.\nEarlier this year I revisited this tool to create a provocation for myself. I\u2019d just finished Alla Kholmatova\u2019s excellent book on \u2018Design Systems\u2019, which I would recommend highly. The book wasn\u2019t just filled with valuable insights, it was also beautifully designed.\nOnce I\u2019d finished reading Kholmatova\u2019s book, I started thinking: \u201cPerhaps it\u2019s time for me to write a new book?\u201d Using the magic of \u2018Inspect Element\u2019, I created a fictitious page for a new book I wanted to write: \u2018Designing Delightful Experiences\u2019.\nI wrote a description for the book, considering how I\u2019d pitch it.\n\nThis imagined page was just what I needed to paint a picture in my mind of a possible new book. I contacted the team at Smashing Magazine and pitched the idea to them. I\u2019m happy to say that I\u2019m now working on that book, which is due to be published in 2019.\nWithout this fictional promotional page from the future, the book would have remained as an idea \u2013 loosely defined \u2013 rolling around my mind. By spending some time, turning that idea into something \u2018real\u2019, I had everything I needed to tell the story of the book, sharing it with the publishing team at Smashing Magazine.\nOf course, they could have politely informed me that they weren\u2019t interested, but I\u2019d have lost nothing \u2013 truly \u2013 in the process.\nAs designers, creating these imaginary \u2018Artefacts From the Future\u2019 is firmly within our grasp. All we need to do is let go a little and allow our imaginations to wander.\nIn my experience, working with clients and \u2013 to a lesser extent, students \u2013 it\u2019s the \u2018letting go\u2019 part that\u2019s the hard part. It can be difficult to let down your guard and share a weighty goal, but I\u2019d encourage you to do so. At the end of the day, you have nothing to lose.\nThe key lesson here is that your \u2018Artefacts From the Future\u2019 will focus your mind. They\u2019ll transform your unformed ideas into \u2018tangible evidence\u2019 of future possibilities, which you can use as discussion points and provocations, helping you to shape your future reality.\nTomorrow Clients\nThe third tool, which I developed more recently, is a tool called \u2018Tomorrow Clients\u2019. This tool is designed to help you identify a list of clients that you aspire to work with.\nThe goal is to pinpoint who you would like to work with \u2013 in an ideal world \u2013 and define how you\u2019d position yourself to win them over. Again, this involves \u2018letting go\u2019 and allowing your mind to imagine the possibilities, asking, \u201cWhat if\u2026?\u201d\nBefore I embarked upon the design of my new website, I put together a \u2018soul searching\u2019 document that acted as a focal point for my thinking. I contacted a number of designers for a second opinion to see if my thinking was sound.\nOne of my graduates \u2013 Chris Armstrong, the founder of Niice \u2013 replied with the following: \u201cMight it be useful to consider five to ten companies you\u2019d love to work for, and consider how you\u2019d pitch yourself to them?\u201d\nThis was just the provocation I needed. To add a little focus, I reduced the list to three, asking: \u201cWho would my top three clients be?\u201d\n\nBy distilling the list down I focused on who I\u2019d like to work for and how I\u2019d position myself to entice them to work with me. My list included: IDEO, Adobe and IBM. All are companies I admire and I believed each would be interesting to work for.\nThis exercise might \u2013 on the surface \u2013 appear a little like indulging in fantasy, but I believe it helps you to clarify exactly what it is you are good at and, just as importantly, put that in to words.\nFor each company, I wrote a short pitch outlining why I admired them and what I thought I could add to their already existing skillset.\nFocusing first on Adobe, I suggested establishing an emphasis on educational resources, designed to help those using Adobe\u2019s creative tools to get the most out of them.\nA few weeks ago, I signed a contract with the team working on Adobe XD to create a series of \u2018capsule courses\u2019, focused on UX design. The first of these courses \u2013 exploring UI design \u2013 will be out in 2019.\nI believe that Armstrong\u2019s provocation \u2013 asking me to shift my focus from clients I have worked for in the past to clients I aspire to work for in the future \u2013 made all the difference.\nThe key lesson here is that this exercise encouraged me to raise the bar and look to the future, not the past. In short, it enabled me to proactively design my future.\nIn closing\u2026\nI hope these three tools will prove a welcome addition to your toolset. I use them when working with clients, I also use them when working with myself.\nI passionately believe that you can design your future. I also firmly believe that you\u2019re more likely to make that future a reality if you put some thought into defining what it looks like.\nAs I say to my students and the clients I work with: It\u2019s not enough to want to be a success, the word \u2018success\u2019 is too vague to be a destination. A far better approach is to define exactly what success looks like.\nThe secret is to visualise your future in as much detail as possible. With that future vision in hand as a map, you give yourself something tangible to translate into a reality.", "year": "2018", "author": "Christopher Murphy", "author_slug": "christophermurphy", "published": "2018-12-15T00:00:00+00:00", "url": "https://24ways.org/2018/designing-your-future/", "topic": "process"}
{"rowid": 301, "title": "Stretching Time", "contents": "Time is valuable. It\u2019s a precious commodity that, if we\u2019re not too careful, can slip effortlessly through our fingers. When we think about the resources at our disposal we\u2019re often guilty of forgetting the most valuable resource we have to hand: time.\nWe are all given an allocation of time from the time bank. 86,400 seconds a day to be precise, not a second more, not a second less.\nIt doesn\u2019t matter if we\u2019re rich or we\u2019re poor, no one can buy more time (and no one can save it). We are all, in this regard, equals. We all have the same opportunity to spend our time and use it to maximum effect. As such, we need to use our time wisely.\nI believe we can \u2018stretch\u2019 time, ensuring we make the most of every second and maximising the opportunities that time affords us.\nThrough a combination of \u2018Structured Procrastination\u2019 and \u2018Focused Finishing\u2019 we can open our eyes to all of the opportunities in the world around us, whilst ensuring that we deliver our best work precisely when it\u2019s required. A win win, I\u2019m sure you\u2019ll agree.\nStructured Procrastination\nI\u2019m a terrible procrastinator. I used to think that was a curse  \u2013 \u201cWhy didn\u2019t I just get started earlier?\u201d \u2013 over time, however, I\u2019ve started to see procrastination as a valuable tool if it is used in a structured manner.\nDon Norman refers to procrastination as \u2018late binding\u2019 (a term I\u2019ve happily hijacked). As he argues, in Why Procrastination Is Good, late binding (delay, or procrastination) offers many benefits:\n\nDelaying decisions until the time for action is beneficial\u2026 it provides the maximum amount of time to think, plan, and determine alternatives.\n\nWe live in a world that is constantly changing and evolving, as such the best time to execute is often \u2018just in time\u2019. By delaying decisions until the last possible moment we can arrive at solutions that address the current reality more effectively, resulting in better outcomes.\nProcrastination isn\u2019t just useful from a project management perspective, however. It can also be useful for allowing your mind the space to wander, make new discoveries and find creative connections. By embracing structured procrastination we can \u2018prime the brain\u2019.\nAs James Webb Young argues, in A Technique for Producing Ideas, all ideas are made of other ideas and the more we fill our minds with other stimuli, the greater the number of creative opportunities we can uncover and bring to life.\nBy late binding, and availing of a lack of time pressure, you allow the mind space to breathe, enabling you to uncover elements that are important to the problem you\u2019re working on and, perhaps, discover other elements that will serve you well in future tasks.\nWhen setting forth upon the process of writing this article I consciously set aside time to explore. I allowed myself the opportunity to read, taking in new material, safe in the knowledge that what I discovered \u2013 if not useful for this article \u2013 would serve me well in the future. \nRon Burgundy summarises this neatly:\n\nProcrastinator? No. I just wait until the last second to do my work because I will be older, therefore wiser.\n\nAn \u2018older, therefore wiser\u2019 mind is a good thing. We\u2019re incredibly fortunate to live in a world where we have a wealth of information at our fingertips. Don\u2019t waste the opportunity to learn, rather embrace that opportunity. Make the most of every second to fill your mind with new material, the rewards will be ample.\nDeadlines are deadlines, however, and deadlines offer us the opportunity to focus our minds, bringing together the pieces of the puzzle we found during our structured procrastination.\nLike everyone I\u2019ll hear a tiny, but insistent voice in my head that starts to rise when the deadline is approaching. The older you get, the closer to the deadline that voice starts to chirp up.\nAt this point we need to focus.\nFocused Finishing\nWe live in an age of constant distraction. Smartphones are both a blessing and a curse, they keep us connected, but if we\u2019re not careful the constant connection they provide can interrupt our flow.\nWhen a deadline is accelerating towards us it\u2019s important to set aside the distractions and carve out a space where we can work in a clear and focused manner.\nWhen it\u2019s time to finish, it\u2019s important to avoid context switching and focus. All those micro-interactions throughout the day \u2013 triaging your emails, checking social media and browsing the web \u2013 can get in the way of you hitting your deadline. At this point, they\u2019re distractions.\nChunking tasks and managing when they\u2019re scheduled can improve your productivity by a surprising order of magnitude. At this point it\u2019s important to remove distractions which result in \u2018attention residue\u2019, where your mind is unable to focus on the current task, due to the mental residue of other, unrelated tasks.\nBy focusing on a single task in a focused manner, it\u2019s possible to minimise the negative impact of attention residue, allowing you to maximise your performance on the task at hand.\nCal Newport explores this in his excellent book, Deep Work, which I would highly recommend reading. As he puts it:\n\nEfforts to deepen your focus will struggle if you don\u2019t simultaneously wean your mind from a dependence on distraction.\n\nTo help you focus on finishing it\u2019s helpful to set up a work-focused environment that is purposefully free from distractions. There\u2019s a time and a place for structured procrastination, but \u2013 equally \u2013 there\u2019s a time and a place for focused finishing.\nThe French term \u2018mise en place\u2019 is drawn from the world of fine cuisine \u2013 I discovered it when I was procrastinating \u2013 and it\u2019s applicable in this context. The term translates as \u2018putting in place\u2019 or \u2018everything in its place\u2019 and it refers to the process of getting the workplace ready before cooking.\nJust like a professional chef organises their utensils and arranges their ingredients, so too can you.\nThanks to the magic of multiple users on computers, it\u2019s possible to create a separate user on your computer \u2013 without access to email and other social tools \u2013 so that you can switch to that account when you need to focus and hit the deadline.\nAnother, less technical way of achieving the same result \u2013 depending, of course, upon your line of work \u2013 is to close your computer and find some non-digital, unconnected space to work in.\nThe goal is to carve out time to focus so you can finish. As Newport states:\n\nIf you don\u2019t produce, you won\u2019t thrive \u2013 no matter how skilled or talented you are.\n\nProcrastination is fine, but only if it\u2019s accompanied by finishing. Create the space to finish and you\u2019ll enjoy the best of both worlds.\nIn closing\u2026\nThere is a time and a place for everything: there is a time to procrastinate, and a time to focus. To truly reap the rewards of time, the mind needs both.\nBy combining the processes of \u2018Structured Procrastination\u2019 and \u2018Focused Finishing\u2019 we can make the most of our 86,400 seconds a day, ensuring we are constantly primed to make new discoveries, but just as importantly, ensuring we hit the all-important deadlines.\nMake the most of your time, you only get so much. Use every second productively and you\u2019ll be thankful that you did. Don\u2019t waste your time, once it\u2019s gone, it\u2019s gone\u2026 and you can never get it back.", "year": "2016", "author": "Christopher Murphy", "author_slug": "christophermurphy", "published": "2016-12-21T00:00:00+00:00", "url": "https://24ways.org/2016/stretching-time/", "topic": "process"}
{"rowid": 133, "title": "Gravity-Defying Page Corners", "contents": "While working on Stikkit, a \u201cpage curl\u201d came to be.\nNot being as crafty as Veerle, you see.\nI fired up Photoshop to see what could be.\n\u201cAnother copy is running on the network\u201c \u2026 oopsie.\n\nWith license issues sorted out and a concept in mind\nI set out to create something flexible and refined.\nOne background image and code that is sure to be lean.\nA simple solution for lazy people like me.\n\nThe curl I\u2019ll be showing isn\u2019t a curl at all.\nIt\u2019s simply a gradient that\u2019s 18 pixels tall.\nWith a fade to the left that\u2019s diagonally aligned\nand a small fade on the right that keeps the illusion defined.\n\n\n\nCreate a selection with the marquee tool (keeping in mind a reasonable minimum width) and drag a gradient (black to transparent) from top to bottom.\n\n\n\nNow drag a gradient (the background color of the page to transparent) from the bottom left corner to the top right corner.\n\n\n\nFinally, drag another gradient from the right edge towards the center, about 20 pixels or so.\n\nBut the top is flat and can be positioned precisely\njust under the bottom right edge very nicely.\nAnd there it will sit, never ever to be busted\nby varying sizes of text when adjusted.\n\n<div id=\"page\">\n\t<div id=\"page-contents\">\n\t\t<h2>Gravity-Defying!</h2>\n\t\t<p>Lorem ipsum dolor ...</p>\n\t</div>\n</div>\n\nLet\u2019s dive into code and in the markup you\u2019ll see\n\u201cis that an extra div?\u201d \u2026 please don\u2019t kill me?\nThe #page div sets the width and bottom padding\nwhose height is equal to the shadow we\u2019re adding.\n\n\n\nThe #page-contents div will set padding in ems\nto scale with the text size the user intends.\nThe background color will be added here too\nbut not overlapping the shadow where #page\u2019s padding makes room.\n\nA simple technique that you may find amusing\nis to substitute a PNG for the GIF I was using.\nFor that would be crafty and future-proof, too.\nThe page curl could sit on any background hue.\n\nI hope you\u2019ve enjoyed this easy little trick.\nIt\u2019s hardly earth-shattering, and arguably slick.\nBut it could come in handy, you just never know.\nHappy Holidays! And pleasant dreams of web three point oh.", "year": "2006", "author": "Dan Cederholm", "author_slug": "dancederholm", "published": "2006-12-24T00:00:00+00:00", "url": "https://24ways.org/2006/gravity-defying-page-corners/", "topic": "design"}
{"rowid": 74, "title": "Should We Be Reactive?", "contents": "Evolution\n\nLooking at the evolution of the web and the devices we use should help remind us that the times we\u2019re adjusting to are just another step on a journey. These times seem to be telling us that we need to embrace flexibility.\n\nImagine an HTML file containing nothing but text. It\u2019s viewable on any web-capable device and reasonably readable: the notion of the universality of the web was very much a founding principle. Right from the beginning, browser vendors understood that we\u2019d want text to reflow (why wouldn\u2019t we?), so I consider the first websites to have been fluid. \n\nAs we attempted to exert more control through our designs in the early days of the web, debates about whether we should produce fixed or fluid sites raged. We could create fluid designs using tables, but what we didn\u2019t have then was a wide range of web capable devices or the ability to control this fluidity. The biggest changes occurred when stats showed enough people using a different screen resolution we could cater for.\n\nTo me, the techniques of responsive web design provide the control we were missing. Combining new approaches to layout and images with media queries empowered us to learn how to embrace the inherent flexibility of the web in ways to suit our work and the devices used by our audience.\n\nPerhaps another kind of flexibility might be found in how we use context to affect how we present our content; to consider how we might use the information we can access from people, browsers and devices to provide web experiences \u2013 effectively creating sites that react to initial or changing circumstances in the relationship between people and our content.\n\nEmbracing flexibility\n\nSo what is context? Put simply, you could think of it as a secondary piece of information that helps clarify the meaning of the first. It helps set a scene or describe circumstances. I think that Cennydd Bowles has summed it up really well through talks he\u2019s given recently, in which he\u2019s arrived at the acronym DETAILS (Device, Environment, Time, Activity, Individual, Location, Social) \u2013 I encourage you to keep an eye out for his next book due in the new year where he\u2019ll explore this idea much further. This clarity over what context could mean in terms of what we do on the web is fundamental, directing us towards ways we might use it.\n\nWhen you stop to think about it, we\u2019ve been using some basic pieces of this information right from the beginning, like bits of JavaScript or Java applets that serve an appropriate greeting to your site\u2019s visitors, or show their location, or even local weather. But what if we think of this from the beginning of our projects?\n\nWe should think about our content first. Once we know this and have a direction, perhaps then we can think about what context, or even multiple contexts, might help us to communicate more effectively.\n\nThe real world\n\nThere\u2019s always been a disconnect between the real world and the web, which is to be expected. But the world around us is a sea of data; every fundamental building block: people, places, events and things have information waiting to be explored. \n\nFor sites based around physical objects or locations, this divide is really apparent. We don\u2019t ordinarily take the time to describe in code the properties of a place, or consider whether your relationship to the place in the real world should have any impact on your relationship with a site about it.\n\nWhen I think about local businesses, they have such rich properties to draw on and yet we don\u2019t really explore them in any meaningful way, even through something as simple as opening hours.\n\nNow we have data\u2026\n\nWe\u2019ve long had access to the current time both on server- and client-sides. The use of geolocation is easier than ever, but when we look at the range of information we could glean to help us make some choices, maybe there\u2019s some help on the horizon from projects like the W3C Device APIs Working Group. This might prove useful to help make us aware of network and battery conditions of a device, along with the potential to gain data from other sensors, which could tell us about lighting conditions, ambient noise levels and temperature depending on the capabilities of the device.\n\nIt may be that our sites have some form of login or access to your profile from another site. Along with data from our devices and browsers, this should give us a sense of how best to talk to our audience in certain situations. We don\u2019t necessarily need to know any personal details, just enough to make decisions about how to present our sites.\n\nThe reactive web?\n\nSo why reactive web design? I\u2019m hoping that a name might help us to have a common vocabulary not only about what we mean when we talk about context, but how it could be considered through our projects, right from the early stages. How could this manifest itself?\n\nA simple example might be a location-aware panel on your site. Perhaps the space is a little down in your content hierarchy but serves a perfectly valid purpose by default. To visitors outside the country perhaps this works fine, but within your country maybe this panel could be used to communicate more effectively. Further still, if we knew the visitors were in the vicinity, we could talk to them more directly. \n\nWhat if both time and location were relevant? This space could work as before but you could consider how time could intersect with your local audience. If you know they\u2019re local and it\u2019s a certain time of day, you could communicate directly with them.\n\nThis example isn\u2019t beyond what banner ads often do and uses easily accessible information. There are more unusual combinations we may be able to find, such as movement and presence. Perhaps a site that tells a story, which changes design and content based on whether you\u2019re moving, how long you\u2019ve been on the site and how far you\u2019ve travelled. This isn\u2019t what we typically expect from websites, but we should bear in mind that what websites are now will not be what they become in the future.\n\nYou could do much of this contextual presentation through native apps, of course. The Silent History, an app novel written and designed for iPad and iPhone, uses an exploration element, providing \u201chundreds of location-based stories across the U.S. and around the world. These can be read only when your device\u2019s GPS matches the coordinates of the specified location.\u201d But considering the universality of the web, we could redefine what web-based experiences should be like. Not all methods would work well on the web, but that\u2019s a decision that has to be made for a specific project.\n\nBy thinking more broadly about any web-capable device, we can use what we know to provide relevant experiences for our site\u2019s visitors. We need to be sure what we mean by relevant, of course!\n\nReality bites\n\nWhile there are incredible possibilities, from a simple panel on a site to something bordering on living sites that evolve and change with our circumstances, we need to act with a degree of pragmatism and understand how much of what we could do is based on assumptions and the bias of our own experiences.\n\nWe could go wild with changing the way our content is presented based on contextual information, but if we\u2019re not careful what we end up with confuses and could provide a very fractured experience. As much as possible we need to think more ethnographically, observe and question people in the situations we think may be relevant, and test our assumptions as early as we can. Even on small projects, there may be ways we can validate our assumptions and test with our audience. The key to applying contextual content or cues is not to break the experience between contextual views (as I think we now wouldn\u2019t when hiding content on a mobile view). \n\nIt\u2019s another instance of progressive enhancement \u2013 as we know certain pieces of information, we can enhance the experience. Also, if you do change content, how can you not make a more cumbersome experience for your visitors?\n\nIt\u2019s all about communication\n\nContent is at the core of what we do, but if we consider context we need to understand the impact on that. The effect could be as subtle as an altered hierarchy, involve swapping out panels of content, or in extreme instances perhaps all of your content might change. In some ways, this extends the notion of adaptive content that Karen McGrane has been talking about, to how we write and store the content we create. Thinking about the the impact of context may require us to re-evaluate our site structure, too. Whatever we decide, we have to be clear what will happen and manage the expectations of our users.\n\nThe bottom line\n\nWhat I\u2019m proposing isn\u2019t that we go crazy and end up with a confused, disjointed set of experiences across the web. What I hope is that starting right from the beginning of a project, we think about what context is and could be, and see what relevance it might have to what we\u2019re trying to communicate. This strategic process leads us to think about design.\n\nWe are slowly adapting to what it means to be flexible through responsive and adaptive processes. What does thinking about contextual states mean to us (or designing for state in general)? Does this highlight again how difficult it\u2019ll be for our tools to keep up with our processes and output?\n\nIn terms of code, the vast majority of this data comes from the client-side through JavaScript. While we can progressively enhance, this could lead to a lot of code bloat through feature or capability detection, and potentially a lot of conditional loading of scripts. It\u2019s a real shame we don\u2019t get much we can rely on from the server-side \u2013 we know how unreliable user agents are!\n\nWe need to understand why we\u2019d do this. Are we trying to communicate well and be useful, or doing it to show off? Underneath it all, what do we base our decisions on? Do we have actual insight or are we proceeding from our assumptions and the bias of our own experiences? Scott Jenson summed it up best for me: (to paraphrase) the pain we put people through has to be greatly outweighed by the value we offer.\n\nI see that this could be another potential step in our evolution on the web; continuing this exploration of the flexibility the web allows us. It\u2019s amazing we can do such incredible things from what is essentially a set of disparate, linked documents.", "year": "2012", "author": "Dan Donald", "author_slug": "dandonald", "published": "2012-12-09T00:00:00+00:00", "url": "https://24ways.org/2012/should-we-be-reactive/", "topic": "design"}
{"rowid": 174, "title": "Type-Inspired Interfaces", "contents": "One of the things that terrifies me most about a new project is the starting point. How is the content laid out? What colors do I pick? Once things like that are decided, it becomes significantly easier to continue design, but it\u2019s the blank page where I spend the most time.\n\nTo that end, I often start by choosing type. I don\u2019t need to worry about colors or layout or anything else\u2026 just the right typefaces that support the art direction. (This article won\u2019t focus on how to choose a typeface, but there are some really great resources if you interested in that sort of thing.)\n\nAnd just like that, all your work is done. \u201cHold it just a second,\u201d you might say. \u201cAll I\u2019ve done is pick type. I still have to do the rest!\u201d\n\nTo which I would reply, \u201cSilly rabbit. You already have!\u201d You see, picking the right typeface gets you farther than you might think. Here are a few tips on taking cues from type to design interfaces and interface elements.\n\nPerfecting Web 2.0\n\nIf you\u2019re going for that beloved rounded corner look, you might class it up a bit by choosing the wonderful Omnes Pro by Joshua Darden. As the typeface already has a rounded aesthetic, making buttons that fit the style should be pretty easy.\n\nI\u2019ve found that using multiples helps to keep your interfaces looking balanced and proportional. Noticing that the top left edge of the letter \u201cP\u201d has about an 12px corner radius, let\u2019s choose a 24px radius for our button (a multiple of 2), so that we get proper rounded corners. By taking mathematical measurements from the typeface, our button looks more thought out than just \u201cplace arbitrary text on arbitrarily-sized button.\u201d Pretty easy, eh?\n\n\n\nWhat\u2019s in a name(plate)?\n\nRounded buttons are pretty popular buttons nowadays, so let\u2019s try something a bit more stylized.\n\nHave a gander at Brothers, a sturdy face from Emigre. The chiseled edges give us a perfect cue for a stylized button. Using the same slope, you can make plated-looking buttons that fit a different kind of style.\n\n\n\nHeadlining\n\nYou might even take some cues from the style of the typeface itself. Didone serifs are known for their lack of brackets\u30fcthat is, a gradual transition from the stem to the serif. Instead, they typically connect at a right angle. Another common characteristic is the high contrast in the strokes: very thick stems, very thin serifs.\n\nSo, when using a high contrast typeface, you can use it to your advantage to enhance hierarchy. Following our \u201cmultiples\u201d guideline, a 12px measurement from the stems helps us create a top rule with a height of 24px (a multiple of 2). We can take the exact 1px measurement from the serif\u2014a multiple of 1\u2014to create the bottom rule. Voil\u00e0! I use this technique a lot.\n\n\n\nSwashbucklers\n\nAnd don\u2019t forget the importance of visual \u201cspeed bumps\u201d to break up long passages of text. A beautiful face like Alejandro Paul\u2019s Ministry Script has over a thousand characters that can be manipulated or even combined to create elegant interface elements. Altering the partial differential character (\u2202) creates a delightful ornament that can help to guide the eye through content.\n\n\n\nStagger & Swagger\n\nWhat about layout? How can we use typography to inform how our content is displayed?\n\nLet\u2019s take a typeface like Assembler. We might use this for a design that needs to feel uneasy or uncomfortable. In design terms, that might translate into using irregular shapes and asymmetry. Using the proportional distances and degrees from the perpendiculars, we could easily create a multi-column layout that jives with the general tone. And for all you skeptics that don\u2019t think a layout like this is doable on the web, stranger things have happened.\n\n Background texture generously offered by Bittbox.\n\nOverall Design Direction\n\nFinally, your typography could impact the entire look of the site, from the navigation to the interaction and everything in between. Check out how the (now-defunct) Nike Free site\u2019s typography echoes the product itself, and in turn influences the navigation.\n\n\n\nFind Your Type\n\nWith thousands of fonts to choose from, the possibilities are ridiculously open. From angles to radii to color to weight, you\u2019ve got endless fodder before you. Great type designers spent countless hours slaving over these detailed letterforms; take advantage of it! Don\u2019t feel like you have to limit yourself to the same old Helvetica and wet floors\u2026 unless your design calls for it. \n\nHappy hunting!", "year": "2009", "author": "Dan Mall", "author_slug": "danmall", "published": "2009-12-07T00:00:00+00:00", "url": "https://24ways.org/2009/type-inspired-interfaces/", "topic": "design"}
{"rowid": 235, "title": "Real Animation Using JavaScript, CSS3, and HTML5 Video", "contents": "When I was in school to be a 3-D animator, I read a book called Timing for Animation. Though only 152 pages long, it\u2019s essentially the bible for anyone looking to be a great animator. In fact, Pixar chief creative officer John Lasseter used the first edition as a reference when he was an animator at Walt Disney Studios in the early 1980s.\n\nIn the book, authors John Halas and Harold Whitaker advise:\n\n\n\tTiming is the part of animation which gives meaning to movement. Movement can easily be achieved by drawing the same thing in two different positions and inserting a number of other drawings between the two. The result on the screen will be movement; but it will not be animation.\n\n\nBut that\u2019s exactly what we\u2019re doing with CSS3 and JavaScript: we\u2019re moving elements, not animating them. We\u2019re constantly specifying beginning and end states and allowing the technology to interpolate between the two. And yet, it\u2019s the nuances within those middle frames that create the sense of life we\u2019re looking for.\n\nAs bandwidth increases and browser rendering grows more consistent, we can create interactions in different ways than we\u2019ve been able to before. We\u2019re encountering motion more and more on sites we\u2019d generally label \u2018static.\u2019 However, this motion is mostly just movement, not animation. It\u2019s the manipulation of an element\u2019s properties, most commonly width, height, x- and y-coordinates, and opacity.\n\nSo how do we create real animation?\n\nThe metaphor\n\nIn my experience, animation is most believable when it simulates, exaggerates, or defies the real world. A bowling ball falls differently than a racquetball. They each have different weights and sizes, which affect the way they land, bounce, and impact other objects.\n\nThis is a major reason that JavaScript animation frequently feels mechanical; it doesn\u2019t complete a metaphor. Expanding and collapsing a <div> feels very different than a opening a door or unfolding a piece of paper, but it often shouldn\u2019t. The interaction itself should tie directly to the art direction of a page.\n\nPhysics\n\nUnderstanding the physics of a situation is key to creating convincing animation, even if your animation seeks to defy conventional physics. Isaac Newton\u2019s first law of motion\u2019s_laws_of_motion states, \u201cEvery body remains in a state of rest or uniform motion (constant velocity) unless it is acted upon by an external unbalanced force.\u201d Once a force acts upon an object, the object\u2019s shape can change accordingly, depending on the strength of the force and the mass of the object. Another nugget of wisdom from Halas and Whitaker:\n\n\n\tAll objects in nature have their own weight, construction, and degree of flexibility, and therefore each behaves in its own individual way when a force acts upon it. This behavior, a combination of position and timing, is the basis of animation. The basic question which an animator is continually asking himself is this: \u201cWhat will happen to this object when a force acts upon it?\u201d And the success of his animation largely depends on how well he answers this question.\n\n\nIn animating with CSS3 and JavaScript, keep physics in mind. How \u2018heavy\u2019 is the element you\u2019re interacting with? What kind of force created the action? A gentle nudge? A forceful shove? These subtleties will add a sense of realism to your animations and make them much more believable to your users.\n\nMisdirection\n\nMagicians often use misdirection to get their audience to focus on one thing rather than another. They fool us into thinking something happened that actually didn\u2019t.\n\nAnimation is the same, especially on a screen. By changing the arrangement of pixels on screen at a fast enough rate, your eyes fool your mind into thinking an object is actually in motion. \n\nAnother important component of misdirecting in animation is the use of multiple objects. Try to recall a cartoon where a character vanishes. More often, the character makes some sort of exaggerated motion (this is called anticipation) then disappears, and a puff a smoke follows. That smoke is an extra element, but it goes a long way into make you believe that character actually disappeared.\n\nVery rarely does a vanishing character\u2019s opacity simply go from one hundred per cent to zero. That\u2019s not believable. So why do we do it with <div>s?\n\nArmed with the ammunition of metaphors and misdirection, let\u2019s code an example.\n\nShake, rattle, and roll\n\n(These demos require at least a basic understanding of jQuery and CSS3. Run away if your\u2019re afraid, or brush up on CSS animation and resources for learning jQuery. Also, these demos use WebKit-specific features and are best viewed in the latest version of Safari, so performance in other browsers may vary.)\n\nWe often see the design pattern of clicking a link to reveal content. Our \u201cfirst demo\u201d:\u201d/examples/2010/real-animation/demo1/ shows us exactly that. It uses jQuery\u2019s \u201c slideDown()\u201d:http://api.jquery.com/slideDown/ method, as many instances do.\n\nBut what force acted on the <div> that caused it to open? Did pressing the button unlatch some imaginary hook? Did it activate an unlocking sequence with some gears?\n\nTake 2\n\nOur second demo is more explicit about what happens: the button fell on the <div> and shook its content loose. Here\u2019s how it\u2019s done. \n\nfunction clickHandler(){\n\t$('#button').addClass('animate');\n\treturn false;\n}\n\nClicking the link adds a class of animate to our button. That class has the following CSS associated with it:\n\n<style>\n\t.animate {\n\t\t-webkit-animation-name: ANIMATE;\n\t\t-webkit-animation-duration: 0.25s;\n\t\t-webkit-animation-iteration-count: 1;\n\t\t-webkit-animation-timing-function: ease-in;\n\t}\n\t@-webkit-keyframes ANIMATE {\n\t\tfrom {\n\t\ttop: 72px;\n\t\t}\n\t\tto {\n\t\t\ttop: 112px;\n\t\t}\n\t}\n</style>\n\nIn our keyframe definition, we\u2019ve specified from and to states. This is great, because we can be explicit about how an object starts and finishes moving. \n\nWhat\u2019s also extra handy is that these CSS keyframes broadcast events that you can react to with JavaScript. In this example, we\u2019re listening to the webkitAnimationEnd event and opening the <div> only when the sequence is complete. Here\u2019s that code.\n\nfunction attachAnimationEventHandlers(){\n\tvar wrap = document.getElementById('wrap');\n\twrap.addEventListener('webkitAnimationEnd', function($e) {\n\t\tswitch($e.animationName){\n\t\t\tcase \"ANIMATE\" :\n\t\t\topenMain();\n\t\t\tbreak;\n\t\t\tdefault:\n\t\t}\n\t}, false);\n}\nfunction openMain(){\n\t$('#main .inner').slideDown('slow');\n}\n\n(For more info on handling animation events, check out the documentation at the Safari Reference Library.)\n\nTake 3\n\nThe problem with the previous demo is that the subtleties of timing aren\u2019t evident. It still feels a bit choppy.\n\nFor our third demo, we\u2019ll use percentages instead of keywords so that we can insert as many points as we need to communicate more realistic timing. The percentages allow us to add the keys to well-timed animation: anticipation, hold, release, and reaction. \n\n<style>\n\t@-webkit-keyframes ANIMATE {\n\t\t0% {\n\t\t\ttop: 72px;\n\t\t}\n\t\t40% { /* anticipation */\n\t\t\ttop: 57px;\n\t\t}\n\t\t70% { /* hold */\n\t\t\ttop: 56px;\n\t\t}\n\t\t80% { /* release */\n\t\t\ttop: 112px;\n\t\t}\n\t\t100% { /* return */\n\t\t\ttop: 72px;\n\t\t}\n\t}\n</style>\n\nTake 4\n\nThe button animation is starting to feel much better, but the reaction of the <div> opening seems a bit slow.\n\nThis fourth demo uses jQuery\u2019s delay() method to time the opening precisely when we want it. Since we know the button\u2019s animation is one second long and its reaction starts at eighty per cent of that, that puts our delay at 800ms (eighty per cent of one second). However, here\u2019s a little pro tip: let\u2019s start the opening at 750ms instead. The extra fifty milliseconds makes it feel more like the opening is a reaction to the exact hit of the button. Instead of listening for the webkitAnimationEnd event, we can start the opening as soon as the button is clicked, and the movement plays on the specified delay.\n\nfunction clickHandler(){\n\t$('#button').addClass('animate');\n\topenMain();\n\treturn false;\n}\nfunction openMain(){\n\t$('#main .inner').delay(750).slideDown('slow');\n}\n\nTake 5\n\nWe can tweak the timing of that previous animation forever, but that\u2019s probably as close as we\u2019re going to get to realistic animation with CSS and JavaScript. However, for some extra sauce, we could relegate the whole animation in our final demo to a video sequence which includes more nuances and extra elements for misdirection.\n\nHere\u2019s the basis of video replacement. Add a <video> element to the page and adjust its opacity to zero. Once the button is clicked, fade the button out and start playing the video. Once the video is finished playing, fade it out and bring the button back.\n\nfunction clickHandler(){\n\tif($('#main .inner').is(':hidden')){\n\t\t$('#button').fadeTo(100, 0);\n\t\t$('#clickVideo').fadeTo(100, 1, function(){\n\t\t\tvar clickVideo = document.getElementById('clickVideo');\n\t\t\tclickVideo.play();\n\t\t\tsetTimeout(removeVideo, 2400);\n\t\t\topenMain();\n\t\t});\n\t}\n\treturn false;\n}\nfunction removeVideo(){\n\t$('#button').fadeTo(500, 1);\n\t$('#clickVideo').fadeOut('slow');\n}\nfunction openMain(){\n\t$('#main .inner').delay(1100).slideDown('slow');\n}\n\nWrapping up\n\nI\u2019m no JavaScript expert by any stretch. I\u2019m sure a lot of you scripting wizards out there could write much cleaner and more efficient code, but I hope this gives you an idea of the theory behind more realistic motion with the technology we\u2019re using most. This is just one model of creating more convincing animation, but you can create countless variations of this, including\u2026\n\n\n\tExporting <video> animations in 3-D animation tools or 2-D animation tools like Flash or After Effects\n\tUsing <canvas> or SVG instead of <video>\n\tEmploying specific JavaScript animation frameworks\n\tMaking use of all the powerful properties of CSS Transforms and CSS Animation\n\tTrying out emerging CSS3 animation tools like Sencha Animator\n\n\nIf it wasn\u2019t already apparent, these demos show an exaggerated example and probably aren\u2019t practical in a lot of environments. However, there are a handful of great sites out there that honor animation techniques\u2014metaphor, physics, and misdirection, among others\u2014like Benjamin De Cock\u2019s vCard, 20 Things I Learned About Browsers and the Web by Fantasy Interactive, and the Nike Snowboarding site by Ian Coyle and HEGA. They\u2019re wonderful testaments to what you can do to aid interaction for users.\n\nMy goal was to show you the \u2018why\u2019 and the \u2018how.\u2019 Your charge is to discern the \u2018where\u2019 and the \u2018when.\u2019 Happy animating!", "year": "2010", "author": "Dan Mall", "author_slug": "danmall", "published": "2010-12-15T00:00:00+00:00", "url": "https://24ways.org/2010/real-animation-using-javascript-css3-and-html5-video/", "topic": "code"}
{"rowid": 98, "title": "Absolute Columns", "contents": "CSS layouts have come quite a long way since the dark ages of web publishing, with all sorts of creative applications of floats, negative margins, and even background images employed in order to give us that most basic building block, the column. As the title implies, we are indeed going to be discussing columns today\u2014more to the point, a handy little application of absolute positioning that may be exactly what you\u2019ve been looking for\u2026\n\nCare for a nightcap?\n\nIf you\u2019ve been developing for the web for long enough, you may be familiar with this little children\u2019s fable, passed down from wizened Shaolin monks sitting atop the great Mt. Geocities: \u201cOnce upon a time, multiple columns of the same height could be easily created using TABLES.\u201d Now, though we\u2019re all comfortably seated on the standards train (and let\u2019s be honest: even if you like to think you\u2019ve fallen off, if you\u2019ve given up using tables for layout, rest assured your sleeper car is still reserved), this particular\u2014and as page layout goes, quite basic\u2014trick is still a thorn in our CSSides compared to the ease of achieving the same effect using said Tables of Evil\u2122.\n\nSee, the orange juice masks the flavor\u2026\n\nCreative solutions such as Dan Cederholm\u2019s  Faux Columns do a good job of making it appear as though adjacent columns maintain equal height as content expands, using a background image to fill the space that the columns cannot.\n\nNow, the Holy Grail of CSS columns behaving exactly how they would as table cells\u2014or more to the point, as columns\u2014still eludes us (cough CSS3 Multi-column layout module cough), but sometimes you just need, for example, a secondary column (say, a sidebar) to match the height of a primary column, without involving the creation of images. This is where a little absolute positioning can save you time, while possibly giving your layout a little more flexibility.\n\nShaken, not stirred\n\nYou\u2019re probably familiar by now with the concept of Making the Absolute, Relative as set forth long ago by Doug Bowman, but let\u2019s quickly review just in case: an element set to position:absolute will position itself relative to its nearest ancestor set to position:relative, rather than the browser window (see Figure 1).\n\n Figure 1.\n\nHowever, what you may not know is that we can anchor more than two sides of an absolutely positioned element. Yes, that\u2019s right, all four sides (top, right, bottom, left) can be set, though in this example we\u2019re only going to require the services of three sides (see Figure 2 for the end result).\n\n Figure 2.\n\nTrust me, this will make you feel better\n\nOur requirements are essentially the same as the standard \u201cabsolute-relative\u201d trick\u2014a container <div> set to position:relative, and our sidebar <div> set to position:absolute \u2014 plus another <div> that will serve as our main content column. We\u2019ll also add a few other common layout elements (wrapper, header, and footer) so our example markup looks more like a real layout and less like a test case:\n\n<div id=\"wrapper\">\n\t<div id=\"header\">\n\t\t<h2>#header</h2>\n\t</div>\n\t<div id=\"container\">\n\t\t<div id=\"column-left\">\n\t\t\t<h2>#left</h2>\n\t\t\t<p>Lorem ipsum dolor sit amet\u2026</p>\n\t\t</div>\n\t\t<div id=\"column-right\">\n\t\t\t<h2>#right</h2>\n\t\t</div>\n\t</div>\n\t<div id=\"footer\">\n\t\t<h2>#footer</h2>\n\t</div>\n</div>\n\nIn this example, our main column (#column-left) is only being given a width to fit within the context of the layout, and is otherwise untouched (though we\u2019re using pixels here, this trick will of course work with fluid layouts as well), and our right keeping our styles nice and minimal:\n\n#container {\n\tposition: relative;\n}\n#column-left {\n\twidth: 480px;\n}\n#column-right {\n\tposition: absolute;\n\ttop: 10px;\n\tright: 10px;\n\tbottom: 10px;\n\twidth: 250px;\n}\n\nThe trick is a simple one: the #container <div> will expand vertically to fit the content within #column-left. By telling our sidebar <div> (#column-right) to attach itself not only to the top and right edges of #container, but also to the bottom, it too will expand and contract to match the height of the left column (duplicate the \u201clorem ipsum\u201d paragraph a few times to see it in action).\n\n Figure 3.\n\nOn the rocks\n\n\u201cBut wait!\u201d I hear you exclaim, \u201cwhen the right column has more content than the left column, it doesn\u2019t expand! My text runneth over!\u201d Sure enough, that\u2019s exactly what happens, and what\u2019s more, it\u2019s supposed to: Absolutely positioned elements do exactly what you tell them to do, and unfortunately aren\u2019t very good at thinking outside the box (get it? sigh\u2026). \n\nHowever, this needn\u2019t get your spirits down, because there\u2019s an easy way to address the issue: by adding overflow:auto to #column-right, a scrollbar will automatically appear if and when needed:\n\n#column-right {\n\tposition: absolute;\n\ttop: 10px;\n\tright: 10px;\n\tbottom: 10px;\n\twidth: 250px;\n\toverflow: auto;\n}\n\nWhile this may limit the trick\u2019s usefulness to situations where the primary column will almost always have more content than the secondary column\u2014or where the secondary column\u2019s content can scroll with wild abandon\u2014a little prior planning will make it easy to incorporate into your designs.\n\nDriving us to drink\n\nIt just wouldn\u2019t be right to have a friendly, festive holiday tutorial without inviting IE6, though in this particular instance there will be no shaming that old browser into admitting it has a problem, nor an intervention and subsequent 12-step program. That\u2019s right my friends, this tutorial has abstained from IE6-abuse now for 30 days, thanks to the wizard Dean Edwards and his amazingly talented IE7 Javascript library.\n\nSimply drop the Conditional Comment and <script> element into the <head> of your document, along with one tiny CSS hack that only IE6 (and below) will ever see, and that browser will be back on the straight and narrow:\n\n<!--[if lt IE 7]>\n<script src=\"http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE7.js\" type=\"text/javascript\"></script>\n<style type=\"text/css\" media=\"screen\">\n\t#container {\n\t\tzoom:1; /* helps fix IE6 by initiating hasLayout */\n\t}\n</style>\n<![endif]-->\n\nEggnog is supposed to be spiked, right?\n\nOf course, this is one simple example of what can be a much more powerful technique, depending on your needs and creativity. Just don\u2019t go coding up your wildest fantasies until you\u2019ve had a chance to sleep off the Christmas turkey and whatever tasty liquids you happen to imbibe along the way\u2026", "year": "2008", "author": "Dan Rubin", "author_slug": "danrubin", "published": "2008-12-22T00:00:00+00:00", "url": "https://24ways.org/2008/absolute-columns/", "topic": "code"}
{"rowid": 253, "title": "Clip Paths Know No Bounds", "contents": "CSS Shapes are getting a lot of attention as browser support has increased for properties like shape-outside and clip-path. There are a few ways that we can use CSS Shapes, in particular with the clip-path property, that are not necessarily evident at first glance.\nThe basics of a clip path\nBefore we dig into specific techniques to expand on clip paths, we should first take a look at a basic shape and clip-path. Clip paths can apply a CSS Shape such as a circle(), ellipse(), inset(), or the flexible polygon() to any element. Everywhere in the element that is not within the bounds of our shape will be visually removed.\nUsing the polygon shape function, for example, we can create triangles, stars, or other straight-edged shapes as on Bennett Feely\u2019s Clippy. While fixed units like pixels can be used when defining vertices/points (where the sides meet), percentages will give more flexibility to adapt to the element\u2019s dimensions.\nSee the Pen Clip Path Box by Dan Wilson (@danwilson) on CodePen.\n\nSo for an octagon, we can set eight x, y pairs of percentages to define those points. In this case we start 30% into the width of the box for the first x and at the top of the box for the y and go clockwise. The visible area becomes the interior of the shape made by connecting these points with straight lines.\nclip-path: polygon(\n  30% 0%,\n  70% 0%,\n  100% 30%,\n  100% 70%,\n  70% 100%,\n  30% 100%,\n  0% 70%,\n  0% 30%\n);\nA shape with less vertices than the eye can see\nIt\u2019s reasonable to look at the polygon() function and assume that we need to have one pair of x, y coordinates for every point in our shape. However, we gain some flexibility by thinking outside the box \u2014 or more specifically when we think outside the range of 0% - 100%.\nOur element\u2019s box model will be the ultimate boundary for a clip-path, but we can still define points that exist beyond that natural box for an element.\nSee the Pen CSS Shapes Know No Bounds by Dan Wilson (@danwilson) on CodePen.\n\nBy going beyond the 0% - 100% range we can turn a polygon with three points into a quadrilateral, a pentagon, or a hexagon. In this example the shapes used are all similar triangles defining three points, but due to exceeding the bounds for our element box we visually see one triangle and two pentagons.\nOur earlier octagon can similarly be made with only four points.\nSee the Pen Octagon with four points by Dan Wilson (@danwilson) on CodePen.\n\nMultiple shapes, one clip path\nWe can lean on this power of going beyond the bounds of our element to also create more than one visual shape with a single polygon().\nSee the Pen Multiple shapes from one clip-path by Dan Wilson (@danwilson) on CodePen.\n\nDepending on how we lay it out we can make each shape directly, but since we know we can move around in the space beyond the element\u2019s box, we can draw extra lines to help us get where we need to go next as needed.\nIt can also help us in slicing an element. Combined with CSS Variables, we can work with overlapping elements and clip each one into alternating strips. This example is two elements, each divided into a few rectangles.\nSee the Pen 24w: Sliced Icon by Dan Wilson (@danwilson) on CodePen.\n\nDifferent shapes with fill rules\nA polygon() is not just a collection of points. There is one more key piece to its puzzle according to the specification \u2014 the Fill Rule. The default value we have been using so far is nonzero, and the second option is evenodd. These two values help determine what is considered inside and outside the shape.\nSee the Pen A Star Multiways by Dan Wilson (@danwilson) on CodePen.\n\nAs lines intersect we can get into situations where pieces seemingly on the inside can be considered outside the shape boundary. When using the evenodd fill rule, we can determine if a given point is inside or outside the boundary by drawing a ray from the point in any direction. If the ray crosses an even number of the clip path\u2019s lines, the point is considered outside, and if it crosses an odd number the point is inside.\nOrder of operations\nIt is important to note that there are many CSS properties that affect the final composited appearance of an element via CSS Filters, Blend Modes, and more.\nThese compositing effects are applied in the order:\n\nCSS Filters (e.g. filter: blur(2px))\nClipping (e.g. what this article is about)\nMasking (Clipping\u2019s cousin)\nBlend Modes (e.g. mix-blend-mode: multiply)\nOpacity\n\nThis means if we want to have a star shape and blur it, the blur will happen before the clip. And since blurs are most noticeable around the edge of an element box, the effect might be completely lost since we have clipped away the element\u2019s box edges.\nSee the Pen Order of Filter + Clip by Dan Wilson (@danwilson) on CodePen.\n\nIf we want the edges of the star to be blurred, we do have the option to wrap our clipped element in a blurred parent element. The inner element will be rendered first (with its star clip) and then the parent will blur its contents normally.\nRevealing content with animation\nCSS Shapes can be transitioned and animated, allowing us to animate the visual area of our element without affecting the content within. For example, we can start with visually hidden content (fully clipped) and grow the clip path to reveal the content within. The important caveat for polygon() is that the number of points need to be the same for each keyframe, as well as the fill rule. Otherwise the browser will not have enough information to interpolate the intermediate values. \nSee the Pen Clip Path Shape Reveal by Dan Wilson (@danwilson) on CodePen.\n\nDon\u2019t keep CSS Shapes in a box\nClip paths give us some interesting new possibilities, especially when we think of them as more than just basic shapes. We may be heavily modifying the visual representation of our elements with clip-path, but the underlying content remains unchanged and accessible which makes this property fairly powerful.", "year": "2018", "author": "Dan Wilson", "author_slug": "danwilson", "published": "2018-12-20T00:00:00+00:00", "url": "https://24ways.org/2018/clip-paths-know-no-bounds/", "topic": "code"}
{"rowid": 41, "title": "What Is Vagrant and Why Should I Care?", "contents": "If you run a web server, a database server and your scripting language(s) of choice on your main machine and you have not yet switched to using virtualisation in your workflow then this essay may be of some value to you.\n\nI know you exist because I bump into you daily: freelancers coming in to work on our projects; internet friends complaining about reinstalling a development environment because of an operating system upgrade; fellow agency owners who struggle to brief external help when getting a particular project up and running; or even hardcore back-end developers who \u201cdon\u2019t do ops\u201d and prefer to run their development stack of choice locally.\n\nThere are many perfectly reasonable arguments as to why you may not have already made the switch, from being simply too busy, all the way through to a distrust of the new. I\u2019ll admit that there are many new technologies or workflows that I hear of daily and instantly disregard because I have tool overload, that feeling I get when I hear about a new shiny thing and think \u201cWell, what I do now works \u2013 I\u2019ll leave it for others to play with.\u201d If that\u2019s you when it comes to Vagrant then I hope you\u2019ll hear me out. The business case is compelling enough for you to make that switch; as a bonus it\u2019s also really easy to get going.\n\nIn this article we\u2019ll start off by going through the high level, the tools available and how it all fits together. Then we\u2019ll touch on the justification for making the switch, providing a few use cases that might resonate with you. Finally, I\u2019ll provide a very simple example that you can follow to get yourself up and running.\n\nWhat?\n\nYou already know what virtualisation is. You use the ability to run an operating system within another operating system every day. Whether that\u2019s Parallels or VMware on your laptop or similar server-based tools that drive the \u2018cloud\u2019, squeezing lots of machines on to physical hardware and making it really easy to copy servers and even clusters of servers from one place to another. It\u2019s an amazing technology which has changed the face of the internet over the past fifteen years.\n\nSimply put, Vagrant makes it really easy to work with virtual machines. According to the Vagrant docs:\n\n\n\tIf you\u2019re a designer, Vagrant will automatically set everything up that is required for that web app in order for you to focus on doing what you do best: design. Once a developer configures Vagrant, you don\u2019t need to worry about how to get that app running ever again. No more bothering other developers to help you fix your environment so you can test designs. Just check out the code, vagrant up, and start designing.\n\n\nWhile I\u2019m not sure I agree with the implication that all designers would get others to do the configuring, I think you\u2019ll agree that the \u201cJust check out the code\u2026 and start designing\u201d premise is very compelling.\n\nYou don\u2019t need Vagrant to develop your web applications on virtual machines. All you need is a virtualisation software package, something like VMware Workstation or VirtualBox, and some code. Download the half-gigabyte operating system image that you want and install it. Then download and configure the stack you\u2019ll be working with: let\u2019s say Apache, MySQL, PHP. Then install some libraries, CuRL and ImageMagick maybe, and finally configure the ability to easily copy files from your machine to the new virtual one, something like Samba, or install an FTP server. Once this is all done, copy the code over, import the database, configure Apache\u2019s virtual host, restart and cross your fingers.\n\nIf you\u2019re a bit weird like me then the above is pretty easy to do and secretly quite fun. Indeed, the amount of traffic to one of my more popular blog posts proves that a lot of people have been building themselves development servers from scratch for some time (or at least trying to anyway), whether that\u2019s on virtual or physical hardware.\n\nOr you could use Vagrant. It allows you, or someone else, to specify in plain text how the machine\u2019s virtual hardware should be configured and what should be installed on it. It also makes it insanely easy to get the code on the server. You check out your project, type vagrant up and start work.\n\nWhy?\n\nIt\u2019s worth labouring the point that Vagrant makes it really easy; I mean look-no-tangle-of-wires-or-using-vim-and-loads-of-annoying-command-line-stuff easy to run a development environment.\n\nThat\u2019s all well and good, I hear you say, but there\u2019s a steep learning curve, an overhead to switch. You\u2019re busy and this all sounds great but you need to get on; you\u2019ve got a career to build or a business to run and you don\u2019t have time to learn new stuff right now.\n\nIn short, what\u2019s the business case?\n\nThe business case involves saved time, a very low barrier to entry and the ability to give the exact same environment to somebody else.\n\nGetting your first development virtual machine running will take minutes, not counting download time. Seriously, use pre-built Vagrant files and provisioners (we\u2019ll touch on this below) and you can start developing immediately.\n\nOnce you\u2019ve finished developing you can check in your changes, ask a colleague or freelancer to check them out, and then they run the code on the exact same machine \u2013 even if they are on the other side of the world and regardless of whether they are on Windows, Linux or Apple OS X.\n\nThe configuration to build the machine isn\u2019t a huge binary disk image that\u2019ll take ages to download from Git; it\u2019s two small text files that can be version controlled too, so you can see any changes made to the config and roll back if needed.\n\nNo more \u2018It works for me\u2019 reports; no \u2018Oh, I was using PHP 5.3.3, not PHP 5.3.11\u2019 \u2013 you\u2019re both working on exact same copies of the development environment. With a tested and verified provisioning file you\u2019ll have the confidence that when you brief your next freelancer in to your team there won\u2019t be that painful to and fro of getting the system up and running, where you\u2019re on a Skype call and they are uttering the immortal words, \u2018It still doesn\u2019t work\u2019. You know it works because you can run it too.\n\nThis portability becomes even more important when you\u2019re working on larger sites and systems. Need a load balancer? Multiple front-end servers and a clustered database back-end? No problem. Add each server into the same Vagrant file and a single command will build all of them. As you\u2019ll know if you work on larger, business critical systems, keeping the operating systems in sync is a real problem: one server with a slightly different library causing sporadic and hard to trace issues is a genuine time black hole. Well, the good news is that you can use the same provisioning files to keep test and production machines in sync using your current build workflow.\n\nLet\u2019s also not forget the most simple use case: a single developer with multiple websites running on a single machine. If that\u2019s you and you switch to using Vagrant-managed virtual machines then the next time you upgrade your operating system or do a fresh install there\u2019s no chance that things will all stop working. The server config is all tucked away in version control with your code. Just pull it down and carry on coding.\n\nOK, got it. Show me already\n\nIf you want to try this out you\u2019ll need to install the latest VirtualBox and Vagrant for your platform. If you already have VMware Workstation or another supported virtualisation package installed you can use that instead but you may need to tweak my Vagrant file below. Depending on your operating system, a reboot might also be wise.\n\nNote: the commands below were executed on my MacBook, but should also work on Windows and Linux. If you\u2019re using Windows make sure to run the command prompt as Administrator or it\u2019ll fall over when trying to update the hosts file.\n\nAs a quick sanity check let\u2019s just make sure that we have the vagrant command in our path, so fire up a terminal and check the version number:\n\n$ vagrant -v\nVagrant 1.6.5\n\nWe\u2019ve one final thing to install and that\u2019s the vagrant-hostsupdater plugin. Once again, in your terminal:\n\n$ vagrant plugin install vagrant-hostsupdater\nInstalling the 'vagrant-hostsupdater' plugin. This can take a few minutes...\nInstalled the plugin 'vagrant-hostsupdater (0.0.11)'!\n\nHopefully that wasn\u2019t too painful for you.\n\nThere are two things that you need to manage a virtual machine with Vagrant:\n\n\n\ta Vagrant file: this tells Vagrant what hardware to spin up\n\ta provisioning file: this tells Vagrant what to do on the machine\n\n\nTo save you copying and pasting I\u2019ve supplied you with a simple example (ZIP) containing both of these. Unzip it somewhere sensible and in your terminal make sure you are inside the Vagrant folder:\n\n$ cd where/you/placed/it/24ways\n\n$ ls -l\n-rw-r--r--@  1 bealers  staff  11055  9 Nov 09:16 bealers-24ways.md\n-rw-r--r--@  1 bealers  staff  118152 9 Nov 10:08 it-works.png\ndrwxr-xr-x   5 bealers  staff  170    8 Nov 22:54 vagrant\n\n$ cd vagrant/\n\n$ ls -l\n-rw-r--r--@ 1 bealers  staff  1661  8 Nov 21:50 Vagrantfile\n-rwxr-xr-x@ 1 bealers  staff  3841  9 Nov 08:00 provision.sh\n\nThe Vagrant file tells Vagrant how to configure the virtual hardware of your development machine. Skipping over some of the finer details, here\u2019s what\u2019s in that Vagrant file:\n\nwww.vm.box = \"ubuntu/trusty64\"  \n\nUse Ubuntu 14.04 for the VM\u2019s OS. Vagrant will only download this once. If another project uses the same OS, Vagrant will use a cached version.\n\nwww.vm.hostname = \"bealers-24ways.dev\"     \n\nSet the machine\u2019s hostname. If, like us, you\u2019re using the vagrant-hostsupdater plugin, this will also get added to your hosts file, pointing to the virtual machine\u2019s IP address.\n\nwww.vm.provider :virtualbox do |vb|\n    vb.customize [\"modifyvm\", :id, \"--cpus\", \"2\" ]\nend\n\nHere\u2019s an example of configuring the virtual machine\u2019s hardware on the fly. In this case we want two virtual processors.\n\nNote: this is specific for the VirtualBox provider, but you could also have a section for VMware or other supported virtualisation software.\n\nwww.vm.network \"private_network\", ip: \"192.168.13.37\"   \n\nThis specifies that we want a private networking link between your computer and the virtual machine. It\u2019s probably best to use a reserved private subnet like 192.168.0.0/16 or 10.0.0.0/8\n\nwww.vm.synced_folder \"../\", \"/var/www/24ways\",\n        owner: \"www-data\", group: \"www-data\"\n\nA particularly handy bit of Vagrant magic. This maps your local 24ways parent folder to /var/www/24ways on the virtual machine. This means the virtual machine already has direct access to your code and so do you. There\u2019s no messy copying or synchronisation \u2013 just edit your files and immediately run them on the server.\n\nwww.vm.provision :shell, :path => \"provision.sh\"\n\nThis is where we specify the provisioner, the script that will be executed on the machine.\n\nIf you open up the provisioner you\u2019ll see it\u2019s a bash script that does things like:\n\n\n\tinstall Apache, PHP, MySQL and related libraries\n\tconfigure the libraries: set permissions, enable logging\n\tcreate a database and grant some access rights\n\tset up some code for us to develop on; in this case, fire up a vanilla WordPress installation\n\n\nTo get this all up and running you simply need to run Vagrant from within the vagrant folder:\n\n$ vagrant up\n\nYou should now get a Matrix-like stream of stuff shooting up the screen. If this is the first time Vagrant has used this particular operating system image \u2013 remember we\u2019ve specified the latest version of Ubuntu \u2013 it\u2019ll download the disc image and cache it for future reuse. Then all the packages are downloaded and installed and finally all our configuration steps occur incluing the download and configuration of WordPress.\n\nHalfway through proceedings it\u2019s likely that the process will halt at a prompt something like this:\n\n==> www: adding to (/etc/hosts) : 192.168.13.37  bealers-24ways.dev  # VAGRANT: 2dbfbced1b1e79d2a0942728a0a57ece (www) / 899bd80d-4251-4f6f-91a0-d30f2d9918cc\nPassword:\n\nYou need to enter your password to give vagrant sudo rights to add the IP address and hostname mapping to your local hosts file.\n\nOnce finished, fire up your browser and go to http://bealers-24ways.dev. You should see a default WordPress installation. The username for wp-admin is admin and the password is 24ways.\n\n\n\nIf you take a look at your local filesystem the 24ways folder should now look like:\n\n$ cd ../\n\n$ ls -l\n\n-rw-r--r--@  1 bealers  staff    13074  9 Nov 10:14 bealers-24ways.md\ndrwxr-xr-x  21 bealers  staff      714  9 Nov 10:06 code\ndrwxr-xr-x   3 bealers  staff      102  9 Nov 10:06 etc\n-rw-r--r--@  1 bealers  staff   118152  9 Nov 10:08 it-works.png\ndrwxr-xr-x   5 bealers  staff      170  9 Nov 10:03 vagrant\n-rwxr-xr-x   1 bealers  staff  1315849  9 Nov 10:06 wp-cli\n\n$ cd vagrant/\n\n$ ls -l\n-rw-r--r--@ 1 bealers  staff  1661  9 Nov 09:41 Vagrantfile\n-rwxr-xr-x@ 1 bealers  staff  3836  9 Nov 10:06 provision.sh\n\nThe code folder contains all the WordPress files. You can edit these directly and refresh that page to see your changes instantly.\n\nStaying in the vagrant folder, we\u2019ll now SSH to the machine and have a quick poke around.\n\n$ vagrant ssh\nWelcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-39-generic x86_64)\n\n* Documentation:  https://help.ubuntu.com/\n\nSystem information as of Sun Nov  9 10:03:38 UTC 2014\n\nSystem load:  1.35              Processes:           102\nUsage of /:   2.7% of 39.34GB   Users logged in:     0\nMemory usage: 16%               IP address for eth0: 10.0.2.15\nSwap usage:   0%\n\nGraph this data and manage this system at:\nhttps://landscape.canonical.com/\n\nGet cloud support with Ubuntu Advantage Cloud Guest:\nhttp://www.ubuntu.com/business/services/cloud\n\n0 packages can be updated.\n0 updates are security updates.\n\nvagrant@bealers-24ways:~$\n\nYou\u2019re now logged in as the Vagrant user; if you want to become root this is easy:\n\nvagrant@bealers-24ways:~$ sudo su -\nroot@bealers-24ways:~# \n\nOr you could become the webserver user, which is a good idea if you\u2019re editing the web files directly on the server:\n\nroot@bealers-24ways:~# su - www-data\nwww-data@bealers-24ways:~$\n\nwww-data\u2019s home directory is /var/www so we should be able to see our magically mapped files:\n\nwww-data@bealers-24ways:~$ ls -l\ntotal 4\ndrwxr-xr-x 1 www-data www-data  306 Nov  9 10:09 24ways\ndrwxr-xr-x 2 root     root     4096 Nov  9 10:05 html\n\nwww-data@bealers-24ways:~$ cd 24ways/\n\nwww-data@bealers-24ways:~/24ways$ ls -l\ntotal 1420\n-rw-r--r-- 1 www-data www-data   13682 Nov  9 10:19 bealers-24ways.md\ndrwxr-xr-x 1 www-data www-data     714 Nov  9 10:06 code\ndrwxr-xr-x 1 www-data www-data     102 Nov  9 10:06 etc\n-rw-r--r-- 1 www-data www-data  118152 Nov  9 10:08 it-works.png\ndrwxr-xr-x 1 www-data www-data     170 Nov  9 10:03 vagrant\n-rwxr-xr-x 1 www-data www-data 1315849 Nov  9 10:06 wp-cli\n\nWe can also see some of our bespoke configurations:\n\nwww-data@bealers-24ways:~/24ways$ cat /etc/php5/mods-available/siftware.ini \nupload_max_filesize = 15M\nlog_errors = On\ndisplay_errors = On\ndisplay_startup_errors = On\nerror_log = /var/log/apache2/php.log\nmemory_limit = 1024M\ndate.timezone = Europe/London\n\nwww-data@bealers-24ways:~/24ways$ ls -l /etc/apache2/sites-enabled/\ntotal 0\nlrwxrwxrwx 1 root root 43 Nov  9 10:06 bealers-24ways.dev.conf -> /var/www/24ways/etc/bealers-24ways.dev.conf\n\nIf you want to leave the server, simply type Ctrl+D a few times and you\u2019ll be back where you started.\n\nwww-data@bealers-24ways:~/24ways$ logout\nroot@bealers-24ways:~# logout\nvagrant@bealers-24ways:~$ logout\nConnection to 127.0.0.1 closed.\n$ \n\nYou can now halt the machine:\n\n$ vagrant halt\n==> www: Attempting graceful shutdown of VM...\n==> www: Removing hosts\n\nBonus level\n\nThe example I\u2019ve provided isn\u2019t very realistic. In the real world I\u2019d expect the Vagrant file and provisioner to be included with the project and for it not to create the directory structure, which should already exist in your project. The same goes for the Apache VirtualHost file. You\u2019ll also probably have a default SQL script to populate the database.\n\nAs you work with Vagrant you might start to find bash provisioning to be quite limiting, especially if you are working on larger projects which use more than one server. In that case I would suggest you take a look at Ansible, Puppet or Chef. We use Ansible because we like YAML but they all do the same sort of thing. The main benefit is being able to use the same Vagrant provisioning scripts to also provision test, staging and production environments using your build workflows.\n\nHaving to supply a password so the hosts file can be updated gets annoying very quicky so you can give Vagrant sudo rights:\n\n$ sudo visudo\n\nAdd these lines to the bottom (Shift+G then i then Ctrl+V then Esc then :wq)\n\nCmnd_Alias VAGRANT_HOSTS_ADD = /bin/sh -c echo \"*\" >> /etc/hosts\nCmnd_Alias VAGRANT_HOSTS_REMOVE = /usr/bin/sed -i -e /*/ d /etc/hosts\n%staff ALL=(root) NOPASSWD: VAGRANT_HOSTS_ADD, VAGRANT_HOSTS_REMOVE\n\nVagrant caches the operating system images that you download but it\u2019ll download the installed software packages every time. You can get around this by using a plugin like vagrant-cachier or, if you\u2019re really keen, maintain local Apt repositories (or whatever the equivalent is for your server architecture).\n\nAt some point you might start getting a large number of virtual machines running on your poor hardware all at the same time, especially if you\u2019re switching between projects a lot and each of those projects use lots of servers. We\u2019re just getting to that stage now, so are considering a medium-term move to a containerised option like Docker, which seems to be maturing now.\n\nIf you are keen not to use any command line tools whatsoever and you\u2019re on OS X then you could check out Vagrant Manager as it looks quite shiny.\n\nFinally, there are a huge amount of resources to give you pre-built Vagrant machines from the likes of VVV for Wordpress, something similar for Perch, PuPHPet for generating various configurations, and a long list of pre-built operating systems at VagrantBox.es.\n\nWrapping up\n\nHopefully you can now see why it might be worthwhile to add Vagrant to your development workflow. Whether you\u2019re an agency drafting in freelancers or a one-person band running lots of sites on your laptop using MAMP or something similar.\n\nVagrant makes it easy to launch exact copies of the same machine in a repeatable and version controlled way. The learning curve isn\u2019t too steep and, once configured, you can forget about it and focus on getting your work done.", "year": "2014", "author": "Darren Beale", "author_slug": "darrenbeale", "published": "2014-12-05T00:00:00+00:00", "url": "https://24ways.org/2014/what-is-vagrant-and-why-should-i-care/", "topic": "process"}
{"rowid": 35, "title": "SEO in 2015 (and Why You Should Care)", "contents": "If your business is healthy, you can always find plenty of reasons to leave SEO on your to-do list in perpetuity. After all, SEO is technical, complicated, time-consuming and potentially dangerous. The SEO industry is full of self-proclaimed gurus whose lack of knowledge can be deadly. There\u2019s the terrifying fact that even if you dabble in SEO in the most gentle and innocent way, you might actually end up in a worse state than you were to begin with.\n\nTo make matters worse, Google keeps changing the rules. There have been a bewildering number of major updates, which despite their cuddly names have had a horrific impact on website owners worldwide.\n\nFear aside, there\u2019s also the issue of time. It\u2019s probably tricky enough to find the time to read this article. Setting up, planning and executing an SEO campaign might well seem like an insurmountable obstacle.\n\nSo why should you care enough about SEO to do it anyway?\n\nThe main reason is that you probably already see between 30% and 60% of your website traffic come from the search engines. That might make you think that you don\u2019t need to bother, because you\u2019re already doing so well. But you\u2019re almost certainly wrong.\n\nIf you have a look through the keyword data in your Google Webmaster Tools account, you\u2019ll probably see that around 30\u201350% of the keywords used to find your website are brand names \u2013 the names of your products or companies. These are searches carried out by people who already know about you. But the people who don\u2019t know who you are but are searching for what you sell aren\u2019t finding you right now. This is your opportunity.\n\nIf a person goes looking for a company or product by name, Google will steer them towards what they\u2019re looking for. Their intelligence does have limits, however, and even though they know your name they won\u2019t be completely clear about what you sell. That\u2019s where SEO would come in.\n\nStill need more convincing? How about the fact that the seeming complexities of SEO mean that your competition are almost certainly neglecting it too. They have the same reservations as you about complexity, time and danger, and hopefully they aren\u2019t reading this article and so are none the wiser of the well-kept secret: that 70% of SEO is easy.\n\nI\u2019m going to lead you through what you need to do to tap into that stream of people looking for what you sell right now.\n\nWhat is real SEO?\n\nReal SEO is all about helping Google understand the content of your website. It\u2019s about steering, guiding and assisting Google. Not manipulating it.\n\nIt\u2019s easy to assume that Google already understands the content and relevance of each and every page on your website, but the fact is that it needs a fair amount of hand-holding. Fortunately, helping Google along really isn\u2019t very difficult at all.\n\nRest assured that real SEO has nothing to do with keyword stuffing, keyword density, hacks, tricks or cunning techniques. If you hear any of these terms from your SEO advisor, run away from them as quickly as you can.\n\nUnderstanding your current situation \u2013 Google Analytics\n\nBefore you can do anything to improve your SEO status, you need to get an idea of how you\u2019re already doing. Below is a very quick and easy way of doing so.\n\n1. Open up your Google Analytics account.\n\n2. Click on the date range selector on the top-right of the interface and change the year of the first date to last year. So 12 Dec 2014 will become 12 Dec 2013. Then click on Apply.\n\n3. Click on the All Sessions rectangle towards the top-left, click once on Organic Traffic and click Apply.\n\n4. Click the little black-and-white squares icon that has now appeared under the date selector on the top-right, and drag the slider all the way over to Higher Precision.\n\n5. Change the interval buttons on the top-right of the graph to Week to make this easier to digest.\n\nAt this point your graph should look something like this:\n\n\n\nIt\u2019s worth noting the approximate proportion of your visitors that currently come from organic sources.\n\n6. Click the little downwards arrow to the right of the All Sessions rectangle and choose Remove, so that we\u2019re only looking at the organic traffic on its own.\n\n7. Click on Select a metric next to the Sessions button above the graph and select Pages / Session. You should then see something like this:\n\n\n\nIn the example above we can see that the quantity of traffic has been increasing since the middle of August, but the quality of the traffic (as measured by the number of pages per session) has fallen significantly. \n\nHow you choose to view this is down to your own graph, recent history and interpretation of events, but this should give you an indication of how things stand at the present time. Trends are often much more revealing than a snapshot of a brief moment in time.\n\nYour Google Webmaster Tools data\n\nIf you\u2019re not very familiar with your Google Webmaster Tools account, it\u2019s really worth taking ten to fifteen minutes to see what\u2019s on offer. I can\u2019t recommend this enough. From the point of view of an SEO health check, I\u2019d advise you to look into the HTML Improvements, Crawl Errors and Crawl Stats, and most importantly the Search Queries.\n\nFrom what you see here and the trends shown in your Analytics data, you should now have a good idea of your current status. If you want to explore further, I recommend Screaming Frog as a good diagnostics tool, or Botify if your website is large or unusually complex.\n\nCombining the data into something useful\n\nYour Google Analytics session will have shown you how you\u2019re doing from an SEO point of view in terms of the quantity and, to some extent, the quality of your visitors. But it\u2019s only showing you what is already working. In other words: the people who are finding you on the search engines, and clicking on your links.\n\nThe Google Webmaster Tools search query data, on the other hand, will give you a better idea of what isn\u2019t working. It will show you the keyword searches that are getting you listed in the results, but which aren\u2019t necessarily getting clicked. And it doesn\u2019t take much by the way of expertise to see why.\n\nFor example, if you see your targeted keyword, which you feel is extremely relevant, has generated over 2,000 impressions in the last month but produced only two clicks, you\u2019ll probably find a very low average position. Bear in mind that an average position of fourteen will mean being around halfway down the second page of results. Think about how rarely you go beyond the first two or three listings, never mind to the second page of results, and you\u2019ll understand why the click-through rate is so low.\n\nSo now you have an idea of what you\u2019re being found for at the present time. But what about the other terms?\n\nWhat would you like to be found for?\n\nThis is one of the more common SEO mistakes, on a number of different levels. \n\nMany businesses assume that they don\u2019t need to worry about keyword research. They think they know what terms people use to find what they sell, and they also assume that Google understands the content on their website. This is incorrect on all counts.\n\nA better starting point is to brainstorm a small number of your most obvious keywords, then run them through Google\u2019s Keyword Planner. Ignore the information in the Ad group ideas tab, and instead go straight to the Keyword ideas tab. Rather than wade through the very unfriendly interface, I recommend downloading the data as a spreadsheet, in which not only is more detail included, but you can also slice, dice, sort and report the data as required.\n\nFrom there you can delete all the irrelevant columns, and start working your way through the list, deleting any irrelevant keywords as you go along.\n\nIt\u2019s around this stage that you may hit a problem in terms of where to focus your efforts. The number of reported searches for a given keyword is of course important, but so is the level of competition. Ideally, you\u2019d like keywords with plenty of searches but not too much competition.\n\nI personally like to factor both together by adding a column that simply divides the number of searches squared by the level of competition:\n\n(number of searches \u00d7 number of searches) \u00f7 competition\n\nThere are plenty of alternatives to this basic formula, but I like it for ease of use and simplicity. Once I\u2019ve added this column, I then sort the data by this value (largest to smallest) and I then only usually need ten to fifteen keywords at most to give me plenty of ideas to work with.\n\nThis is a slightly involved but effective methodology for keyword research, as what you\u2019re left with is a list of keywords that both Google and you consider to be relevant to the content of your website. And relevance is an important concept in SEO.\n\nReal SEO keyword research is about making sure that your customers, website and Google are all in agreement and alignment over the content of your website. Other sources of inspiration and ideas include having a look at what terms your competition are targeting, Google Trends and, of course, Google Suggest. If you\u2019re not sure where to find these things, you can probably work out where to search for them!\n\nIf you want to dive further into understanding your current search engine status, search for some of the better keywords that you just discovered and see where you rank compared to your competition. Note that it\u2019s vital to avoid Google serving up personalised results, so either use the privacy, incognito or anonymous mode of your browser for the searches, or use a browser that you don\u2019t normally use. I hope this is Internet Explorer. If what you find isn\u2019t great, don\u2019t despair: everything in SEO is fixable (terms and conditions may apply).\n\nPutting it all together\n\nYou should now have a good idea of where things stand with your current search engine traffic, and a solid list of keywords that you\u2019re not getting visitors for but very much want.\n\nAll that\u2019s left now is to work out how to use these keywords. But before we do, let\u2019s take a quick step back.\n\nIf you have in any way kept up with what\u2019s been happening in SEO over the last couple of years, you\u2019ll have probably heard about Google updates with names like Panda, Hummingbird, Phantom, Pirate and more.\n\nI won\u2019t go into the technical details of what Google is doing, but it is important to understand why they\u2019re trying to do it. At the most basic level, Google understands that there\u2019s a very real problem with people who are trying manipulate its index. In response to this, Google is trying to clean up its results. They don\u2019t want people getting fed up with bad results and considering other options \u2013 have you even tried Bing?\n\nThis is extremely important. Remember earlier when I said that 70% of SEO was easy? That rule still applies. So, for example, if you have a list of keywords that you know are relevant to what you sell, then all you need to do is create great content for them. Incredibly, that\u2019s all there is to it (terms and conditions apply again, unfortunately \u2013 see below).\n\nThere is, however, one simple rule to be consistently followed without exception: that the content you create should not only be good quality and completely original, but it should also be written primarily for the human visitor and not the search engine spider.\n\nIn other words, if you create some fantastic content for a keyword like \u201cchoosing a small business HR service\u201d, then the article should not only make perfect sense if read out loud (as opposed to the same phrase being repeated fifteen times), but also provide real value to the person reading it.\n\nSo the process is simple:\n\n\n\tChoose your keywords\n\tCreate spectacular content\n\n\nWait. Is it really that simple?\n\nUnfortunately there\u2019s a lot more to the other 30% of SEO than just creating great content and waiting for the visitors. There are issues like helping Google understand the content on your pages and website, incoming links, page authority, domain authority, usage patterns, spam factors, canonical issues and much more.\n\nBut there\u2019s the often overlooked fact about Google: it actually does a reasonable job of working out what\u2019s on your website and (to some extent) understanding the gist of it. If you\u2019ve never done any SEO on your website but still get some traffic from Google, this is why.\n\nEven without dabbling in the other 30% of SEO, by creating the right content for the right visitors using the precise language and terminology that your potential customers are using, you\u2019re significantly better off than your competition. And you can only gain from this.\n\nWhen you\u2019ve checked this off your to-do list and made it an ingrained part of your content creation process, then you\u2019re ready to delve into the other 30% of SEO. The not-so-easy side.\n\nUntil then, work on understanding your current situation, exploring the opportunities, creating a list of good keywords, creating the right content for them, and starting 2015 with a little bit of smart, safe and real SEO.", "year": "2014", "author": "Dave Collins", "author_slug": "davecollins", "published": "2014-12-15T00:00:00+00:00", "url": "https://24ways.org/2014/seo-in-2015-and-why-you-should-care/", "topic": "business"}
{"rowid": 134, "title": "Photographic Palettes", "contents": "How many times have you seen a colour combination that just worked, a match so perfect that it just seems obvious? \n\nNow, how many times do you come up with those in your own work? A perfect palette looks easy when it\u2019s done right, but it\u2019s often maddeningly difficult and time-consuming to accomplish.\n\nChoosing effective colour schemes will always be more art than science, but there are things you can do that will make coming up with that oh-so-smooth palette just a little a bit easier. A simple trick that can lead to incredibly gratifying results lies in finding a strong photograph and sampling out particularly harmonious colours.\n\nPhoto Selection\n\nNot all photos are created equal. You certainly want to start with imagery that fits the eventual tone you\u2019re attempting to create. A well-lit photo of flowers might lead to a poor colour scheme for a funeral parlour\u2019s web site, for example. It\u2019s worth thinking about what you\u2019re trying to say in advance, and finding a photo that lends itself to your message.\n\nAs a general rule of thumb, photos that have a lot of neutral or de-saturated tones with one or two strong colours make for the best palette; bright and multi-coloured photos are harder to derive pleasing results from. Let\u2019s start with a relatively neutral image.\n\nSampling\n\n\n\nIn the above example, I\u2019ve surrounded the photo with three different background colours directly sampled from the photo itself. Moving from left to right, you can see how each of the sampled colours is from an area of increasingly smaller coverage within the photo, and yet there\u2019s still a strong harmony between the photo and the background image. I don\u2019t really need to pick the big obvious colours from the photo to create that match, I can easily concentrate on more interesting colours that might work better for what I intend.\n\nUsing a similar palette, let\u2019s apply those colour choices to a more interesting layout:\n\n\n\nIn this mini-layout, I\u2019ve re-used the same tan colour from the previous middle image as a background, and sampled out a nicely matching colour for the top and bottom overlays, as well as the two different text colours. Because these colours all fall within a narrow range, the overall balance is harmonious.\n\nWhat if I want to try something a little more daring? I have a photo of stacked chairs of all different colours, and I\u2019d like to use a few more of those. No problem, provided I watch my colour contrast:\n\n\n\nThough it uses varying shades of red, green, and yellow, this palette actually works because the values are even, and the colours muted. Placing red on top of green is usually a hideous combination of death, but if the green is drab enough and the red contrasts well enough, the result can actually be quite pleasing. I\u2019ve chosen red as my loudest colour in this palette, and left green and yellow to play the quiet supporting roles.\n\nObviously, there are no hard and fast rules here. You might not want to sample absolutely every colour in your scheme from a photo. There are times where you\u2019ll need a variation that\u2019s just a little bit lighter, or a blue that\u2019s not in the photo. You might decide to start from a photo base and tweak, or add in colours of your own. That\u2019s okay too.\n\nTonal Variations\n\nI\u2019ll leave you with a final trick I\u2019ve been using lately, a way to bring a bit more of a formula into the equation and save some steps.\n\n\n\nStarting with the same base palette I sampled from the chairs, in the above image I\u2019ve added a pair of overlaying squares that produce tonal variations of each primary. The lighter variation is simply a solid white square set to 40% opacity, the darker one is a black square at 20%. That gives me a highlight and shadow for each colour, which would prove handy if I had to adapt this colour scheme to a larger layout.\n\nI could add a few more squares of varying opacities, or adjust the layer blending modes for different effects, but as this looks like a great place to end, I\u2019ll leave that up to your experimental whims. Happy colouring!", "year": "2006", "author": "Dave Shea", "author_slug": "daveshea", "published": "2006-12-22T00:00:00+00:00", "url": "https://24ways.org/2006/photographic-palettes/", "topic": "design"}
{"rowid": 151, "title": "Get In Shape", "contents": "Pop quiz: what\u2019s wrong with the following navigation?\n\n\n\nMaybe nothing. But then again, maybe there\u2019s something bugging you about the way it comes together, something you can\u2019t quite put your finger on. It seems well-designed, but it also seems a little\u2026 off.\n\nThe design decisions that led to this eventual form were no doubt well-considered:\n\n\n\tClient: The top level needs to have a \u201ccurrent page\u201d status indicator of some sort.\n\tDesigner: How about a white tab?\n\tClient: Great! The second level needs to show up underneath the first level though\u2026\n\tDesigner: Okay, but that white tab I just added makes it hard to visually connect the bottom nav to the top.\n\tClient: Too late, we\u2019ve seen the white tab and we love it. Try and make it work.\n\tDesigner: Right. So I placed the second level in its own box.\n\tClient: Hmm. They seem too separated. I can\u2019t tell that the yellow nav is the second level of the first.\n\tDesigner: How about an indicator arrow?\n\tClient: Brilliant!\n\n\nThe problem is that the end result feels awkward and forced. During the design process, little decisions were made that ultimately affect the overall shape of the navigation. What started out as a neatly contained rounded rectangle ended up as an ambiguous double shape that looks funny, though it\u2019s often hard to pinpoint precisely why.\n\nThe Shape of Things\n\nWell the why in this case is because seemingly unrelated elements in a design still end up visually interacting. Adding a new item to a page impacts everything surrounding it. In this navigation example, we\u2019re looking at two individual objects that are close enough to each other that they form a relationship; if we reduce them to strictly their outlines, it\u2019s a little easier to see that this particular combination registers oddly.\n\n\n\nThe two shapes float with nothing really grounding them. If they were connected, perhaps it would be a different story. The white tab divides the top shape in half, leaving a gap in the middle of it. There\u2019s very little balance in this pairing because the overall shape of the navigation wasn\u2019t considered during the design process.\n\nHere\u2019s another example: Gmail. Great email client, but did you ever closely look at what\u2019s going on in that left hand navigation? The continuous blue bar around the message area spills out into the navigation. If we remove all text, we\u2019re left with this odd configuration:\n\n\n\nThough the reasoning for anchoring the navigation highlight against the message area might be sound, the result is an irregular shape that doesn\u2019t correspond with anything in reality. You may never consciously notice it, but once you do it\u2019s hard to miss. One other example courtesy of last.fm:\n\n\n\nThe two header areas are the same shade of pink so they appear to be closely connected. When reduced to their outlines it\u2019s easy to see that this combination is off-balance: the edges don\u2019t align, the sharp corners of the top shape aren\u2019t consistent with the rounded corners of the bottom, and the part jutting out on the right of the bottom one seems fairly random. The result is a duo of oddly mis-matched shapes.\n\nDesign Strategies\n\nOur minds tend to pick out familiar patterns. A clever designer can exploit this by creating references in his or her work to shapes and combinations with which viewers are already familiar. There are a few simple ideas that can be employed to help you achieve this: consistency, balance, and completion.\n\nConsistency\n\nA fairly simple way to unify the various disparate shapes on a page is by designing them with a certain amount of internal consistency. You don\u2019t need to apply an identical size, colour, border, or corner treatment to every single shape; devolving a design into boring repetition isn\u2019t what we\u2019re after here. But it certainly doesn\u2019t hurt to apply a set of common rules to most shapes within your work.\n\n\n\nConsider purevolume and its multiple rounded-corner panels. From the bottom of the site\u2019s main navigation to the grey \u201cExtras\u201d panels halfway down the page (shown above), multiple shapes use a common border radius for unity. Different colours, different sizes, different content, but the consistent outlines create a strong sense of similarity. Not that every shape on the site follows this rule; they break the pattern right at the top with a darker sharp-cornered header, and again with the thumbnails below. But the design remains unified, nonetheless.\n\nBalance\n\nArguably the biggest problem with the last.fm example earlier is one of balance. The area poking out of the bottom shape created a fairly obvious imbalance for no apparent reason. The right hand side is visually emphasized due to the greater area of pink coverage, but with the white gap left beside it, the emphasis seems unwarranted. It\u2019s possible to create tension in your design by mismatching shapes and throwing off the balance, but when that happens unintentionally it can look like a mistake.\n\n\n\nAbove are a few examples of design elements in balanced and unbalanced configurations. The examples in the top row are undeniably more pleasing to the eye than those in the bottom row. If these were fleshed out into full designs, those derived from the templates in the top row would naturally result in stronger work.\n\nTake a look at the header on 9Rules for a study in well-considered balance. On the left you\u2019ll see a couple of paragraphs of text, on the right you have floating navigational items, and both flank the site\u2019s logo. This unusual layout combines multiple design elements that look nothing alike, and places them together in a way that anchors each so that no one weighs down the header.\n\nCompletion\n\nAnd finally we come to the idea of completion. Shapes don\u2019t necessarily need hard outlines to be read visually as shapes, which can be exploited for various purposes. Notice how Zend\u2019s mid-page \u201cBusiness Topics\u201d and \u201cNews\u201d items (below) fade out to the right and bottom, but the placement of two of these side-by-side creates an impression of two panels rather than three disparate floating columns. By allowing the viewer\u2019s eye to complete the shapes, they\u2019ve lightened up the design of the page and removed inessential lines. In a busy design this technique could prove quite handy.\n\n\n\nAlong the same lines, the individual shapes within your design may also be combined visually to form outlines of larger shapes. The differently-coloured header and main content/sidebar shapes on Veerle\u2019s blog come together to form a single central panel, further emphasized by the slight drop shadow to the right.\n\nImplementation\n\nStudying how shape can be used effectively in design is simply a starting point. As with all things design-related, there are no hard and fast rules here; ultimately you may choose to bring these principles into your work more often, or break them for effect. But understanding how shapes interact within a page, and how that effect is ultimately perceived by viewers, is a key design principle you can use to impress your friends.", "year": "2007", "author": "Dave Shea", "author_slug": "daveshea", "published": "2007-12-16T00:00:00+00:00", "url": "https://24ways.org/2007/get-in-shape/", "topic": "design"}
{"rowid": 234, "title": "An Introduction to CSS 3-D Transforms", "contents": "Ladies and gentlemen, it is the second decade of the third millennium and we are still kicking around the same 2-D interface we got three decades ago. Sure, Apple debuted a few apps for OSX 10.7 that have a couple more 3-D flourishes, and Microsoft has had that Flip 3D for a while. But c\u2019mon \u2013 2011 is right around the corner. That\u2019s Twenty Eleven, folks. Where is our 3-D virtual reality? By now, we should be zipping around the Metaverse on super-sonic motorbikes.\n\nGranted, the capability of rendering complex 3-D environments has been present for years. On the web, there are already several solutions: Flash; three.js in <canvas>; and, eventually, WebGL. Finally, we meagre front-end developers have our own three-dimensional jewel: CSS 3-D transforms!\n\nRationale\n\nLike a beautiful jewel, 3-D transforms can be dazzling, a true spectacle to behold. But before we start tacking 3-D diamonds and rubies to our compositions like Liberace\u2018s tailor, we owe it to our users to ask how they can benefit from this awesome feature. \n\nAn entire application should not take advantage of 3-D transforms. CSS was built to style documents, not generate explorable environments. I fail to find a benefit to completing a web form that can be accessed by swivelling my viewport to the Sign-Up Room (although there have been proposals to make the web just that). Nevertheless, there are plenty of opportunities to use 3-D transforms in between interactions with the interface, via transitions.\n\nTake, for instance, the Weather App on the iPhone. The application uses two views: a details view; and an options view. Switching between these two views is done with a 3-D flip transition. This informs the user that the interface has two \u2013 and only two \u2013 views, as they can exist only on either side of the same plane.\n\n Flipping from details view to options view via a 3-D transition\n\nAlso, consider slide shows. When you\u2019re looking at the last slide, what cues tip you off that advancing will restart the cycle at the first slide? A better paradigm might be achieved with a 3-D transform, placing the slides side-by-side in a circle (carousel) in three-dimensional space; in that arrangement, the last slide obviously comes before the first.\n\n3-D transforms are more than just eye candy. We can also use them to solve dilemmas and make our applications more intuitive. \n\nCurrent support\n\nThe CSS 3D Transforms module has been out in the wild for over a year now. Currently, only Safari supports the specification \u2013 which includes Safari on Mac OS X and Mobile Safari on iOS. \n\nThe support roadmap for other browsers varies. The Mozilla team has taken some initial steps towards implementing the module. Mike Taylor tells me that the Opera team is keeping a close eye on CSS transforms, and is waiting until the specification is fleshed out. And our best friend Internet Explorer still needs to catch up to 2-D transforms before we can talk about the 3-D variety.\n\nTo make matters more perplexing, Safari\u2019s WebKit cousin Chrome currently accepts 3-D transform declarations, but renders them in 2-D space. Chrome team member Paul Irish, says that 3-D transforms are on the horizon, perhaps in one of the next 8.0 releases.\n\nThis all adds up to a bit of a challenge for those of us excited by 3-D transforms. I\u2019ll give it to you straight: missing the dimension of depth can make degradation a bit ungraceful. Unless the transform is relatively simple and holds up in non-3D-supporting browsers, you\u2019ll most likely have to design another solution. But what\u2019s another hurdle in a steeplechase? We web folk have had our mettle tested for years. We\u2019re prepared to devise multiple solutions.\n\nHere\u2019s the part of the article where I mention Modernizr, and you brush over it because you\u2019ve read this part of an article hundreds of times before. But seriously, it\u2019s the best way to test for CSS 3-D transform support. Use it.\n\nEven with these difficulties mounting up, trying out 3-D transforms today is the right move. The CSS 3-D transforms module was developed by the same team at Apple that produced the CSS 2D Transforms and Animation modules. Both specifications have since been adopted by Mozilla and Opera. Transforming in three-dimensions now will guarantee you\u2019ll be ahead of the game when the other browsers catch up.\n\nThe choice is yours. You can make excuses and pooh-pooh 3-D transforms because they\u2019re too hard and only snobby Apple fans will see them today. Or, with a tip of the fedora to Mr Andy Clarke, you can get hard-boiled and start designing with the best features out there right this instant.\n\nSo, I bid you, in the words of the eternal Optimus Prime\u2026\n\n\n\tTransform and roll out.\n\n\nLet\u2019s get coding.\n\nPerspective\n\nTo activate 3-D space, an element needs perspective. This can be applied in two ways: using the transform property, with the perspective as a functional notation:\n\n-webkit-transform: perspective(600);\n\nor using the perspective property: \n\n-webkit-perspective: 600;\n\nSee example: Perspective 1.\n\n\n\n The red element on the left uses transform: perspective() functional notation; the blue element on the right uses the perspective property\n\n\n\nThese two formats both trigger a 3-D space, but there is a difference. The first, functional notation is convenient for directly applying a 3-D transform on a single element (in the previous example, I use it in conjunction with a rotateY transform). But when used on multiple elements, the transformed elements don\u2019t line up as expected. If you use the same transform across elements with different positions, each element will have its own vanishing point. To remedy this, use the perspective property on a parent element, so each child shares the same 3-D space.\n\nSee Example: Perspective 2.\n\n\n\n Each red box on the left has its own vanishing point within the parent container; the blue boxes on the right share the vanishing point of the parent container\n\n\n\nThe value of perspective determines the intensity of the 3-D effect. Think of it as a distance from the viewer to the object. The greater the value, the further the distance, so the less intense the visual effect. perspective: 2000; yields a subtle 3-D effect, as if we were viewing an object from far away. perspective: 100; produces a tremendous 3-D effect, like a tiny insect viewing a massive object.\n\nBy default, the vanishing point for a 3-D space is positioned at its centre. You can change the position of the vanishing point with perspective-origin property.\n\n-webkit-perspective-origin: 25% 75%;\n\nSee Example: Perspective 3.\n\n\n\n\n\n\n\n3-D transform functions\n\nAs a web designer, you\u2019re probably well acquainted with working in two dimensions, X and Y, positioning items horizontally and vertically. With a 3-D space initialised with perspective, we can now transform elements in all three glorious spatial dimensions, including the third Z dimension, depth. \n\n3-D transforms use the same transform property used for 2-D transforms. If you\u2019re familiar with 2-D transforms, you\u2019ll find the basic 3D transform functions fairly similar. \n\n\n\trotateX(angle)\n\trotateY(angle)\n\trotateZ(angle)\n\ttranslateZ(tz)\n\tscaleZ(sz)\n\n\nWhereas translateX() positions an element along the horizontal X-axis, translateZ() positions it along the Z-axis, which runs front to back in 3-D space. Positive values position the element closer to the viewer, negative values further away.\n\nThe rotate functions rotate the element around the corresponding axis. This is somewhat counter-intuitive at first, as you might imagine that rotateX will spin an object left to right. Instead, using rotateX(45deg) rotates an element around the horizontal X-axis, so the top of the element angles back and away, and the bottom gets closer to the viewer.\n\nSee Example: Transforms 1.\n\n\n\n3-D rotate() and translate() functions around each axis\n\n\n\nThere are also several shorthand transform functions that require values for all three dimensions:\n\n\n\ttranslate3d(tx,ty,tz)\n\tscale3d(sx,sy,sz)\n\trotate3d(rx,ry,rz,angle)\n\n\nPro-tip: These foo3d() transform functions also have the benefit of triggering hardware acceleration in Safari. Dean Jackson, CSS 3-D transform spec author and main WebKit dude, writes (to Thomas Fuchs):\n\n\n\tIn essence, any transform that has a 3D operation as one of its functions will trigger hardware compositing, even when the actual transform is 2D, or not doing anything at all (such as translate3d(0,0,0)). Note this is just current behaviour, and could change in the future (which is why we don\u2019t document or encourage it). But it is very helpful in some situations and can significantly improve redraw performance.\n\n\nFor the sake of simplicity, my demos will use the basic transform functions, but if you\u2019re writing production-ready CSS for iOS or Safari-only, make sure to use the foo3d() functions to get the best rendering performance.\n\nCard flip\n\nWe now have all the tools to start making 3-D objects. Let\u2019s get started with something simple: flipping a card.\n\nHere\u2019s the basic markup we\u2019ll need:\n\n<section class=\"container\">\n  <div id=\"card\">\n    <figure class=\"front\">1</figure>\n    <figure class=\"back\">2</figure>\n  </div>\n</section>\n\nThe .container will house the 3-D space. The #card acts as a wrapper for the 3-D object. Each face of the card has a separate element: .front; and .back. Even for such a simple object, I recommend using this same pattern for any 3-D transform. Keeping the 3-D space element and the object element(s) separate establishes a pattern that is simple to understand and easier to style.\n\nWe\u2019re ready for some 3-D stylin\u2019. First, apply the necessary perspective to the parent 3-D space, along with any size or positioning styles.\n\n.container { \n  width: 200px;\n  height: 260px;\n  position: relative;\n  -webkit-perspective: 800;\n}\n\nNow the #card element can be transformed in its parent\u2019s 3-D space. We\u2019re combining absolute and relative positioning so the 3-D object is removed from the flow of the document. We\u2019ll also add width: 100%;  and height: 100%;. This ensures the object\u2019s transform-origin will occur in the centre of .container. More on transform-origin later. \n\nLet\u2019s add a CSS3 transition so users can see the transform take effect. \n\n#card {\n  width: 100%;\n  height: 100%;\n  position: absolute;\n  -webkit-transform-style: preserve-3d;\n  -webkit-transition: -webkit-transform 1s;\n}\n\nThe .container\u2019s perspective only applies to direct descendant children, in this case #card. In order for subsequent children to inherit a parent\u2019s perspective, and live in the same 3-D space, the parent can pass along its perspective with transform-style: preserve-3d. Without 3-D transform-style, the faces of the card would be flattened with its parents and the back face\u2019s rotation would be nullified. \n\nTo position the faces in 3-D space, we\u2019ll need to reset their positions in 2-D with position: absolute. In order to hide the reverse sides of the faces when they are faced away from the viewer, we use backface-visibility: hidden. \n\n#card figure {\n  display: block;\n  position: absolute;\n  width: 100%;\n  height: 100%;\n  -webkit-backface-visibility: hidden;\n}\n\nTo flip the .back face, we add a basic 3-D transform of rotateY(180deg). \n\n#card .front {\n  background: red;\n}\n#card .back {\n  background: blue;\n  -webkit-transform: rotateY(180deg);\n}\n\nWith the faces in place, the #card requires a corresponding style for when it is flipped.\n\n#card.flipped {\n  -webkit-transform: rotateY(180deg);\n}\n\nNow we have a working 3-D object. To flip the card, we can toggle the flipped class. When .flipped, the #card will rotate 180 degrees, thus exposing the .back face.\n\nSee Example: Card 1.\n\n\n\nFlipping a card in three dimensions\n\n\n\nSlide-flip\n\nTake another look at the Weather App 3-D transition. You\u2019ll notice that it\u2019s not quite the same effect as our previous demo. If you follow the right edge of the card, you\u2019ll find that its corners stay within the container. Instead of pivoting from the horizontal centre, it pivots on that right edge. But the transition is not just a rotation \u2013 the edge moves horizontally from right to left. We can reproduce this transition just by modifying a couple of lines of CSS from our original card flip demo.\n\nThe pivot point for the rotation occurs at the right side of the card. By default, the transform-origin of an element is at its horizontal and vertical centre (50% 50% or center center). Let\u2019s change it to the right side:\n\n#card { -webkit-transform-origin: right center; }\n\nThat flip now needs some horizontal movement with translateX. We\u2019ll set the rotation to -180deg so it flips right side out.\n\n#card.flipped {\n  -webkit-transform: translateX(-100%) rotateY(-180deg);\n}\n\nSee Example: Card 2.\n\n\n\nCreating a slide-flip from the right edge of the card\n\n\n\nCube\n\nCreating 3-D card objects is a good way to get started with 3-D transforms. But once you\u2019ve mastered them, you\u2019ll be hungry to push it further and create some true 3-D objects: prisms. We\u2019ll start out by making a cube.\n\nThe markup for the cube is similar to the card. This time, however, we need six child elements for all six faces of the cube:\n\n<section class=\"container\">\n  <div id=\"cube\">\n    <figure class=\"front\">1</figure>\n    <figure class=\"back\">2</figure>\n    <figure class=\"right\">3</figure>\n    <figure class=\"left\">4</figure>\n    <figure class=\"top\">5</figure>\n    <figure class=\"bottom\">6</figure>\n  </div>\n</section>\n\nBasic position and size styles set the six faces on top of one another in the container.\n\n.container {\n  width: 200px;\n  height: 200px;\n  position: relative;\n  -webkit-perspective: 1000;\n}\n#cube {\n  width: 100%;\n  height: 100%;\n  position: absolute;\n  -webkit-transform-style: preserve-3d;\n}\n#cube figure {\n  width: 196px;\n  height: 196px;\n  display: block;\n  position: absolute;\n  border: 2px solid black;\n}\n\nWith the card, we only had to rotate its back face. The cube, however, requires that five of the six faces to be rotated. Faces 1 and 2 will be the front and back. Faces 3 and 4 will be the sides. Faces 5 and 6 will be the top and bottom.\n\n#cube .front { -webkit-transform: rotateY(0deg); }\n#cube .back { -webkit-transform: rotateX(180deg); }\n#cube .right { -webkit-transform: rotateY(90deg); }\n#cube .left { -webkit-transform: rotateY(-90deg); }\n#cube .top { -webkit-transform: rotateX(90deg); }\n#cube .bottom { -webkit-transform: rotateX(-90deg); }\n\nWe could remove the first #cube .front style declaration, as this transform has no effect, but let\u2019s leave it in to keep our code consistent.\n\nNow each face is rotated, and only the front face is visible. The four side faces are all perpendicular to the viewer, so they appear invisible. To push them out to their appropriate sides, they need to be translated out from the centre of their positions. Each side of the cube is 200 pixels wide. From the cube\u2019s centre they\u2019ll need to be translated out half that distance, 100px.\n\n#cube .front { -webkit-transform: rotateY(0deg) translateZ(100px); }\n#cube .back { -webkit-transform: rotateX(180deg) translateZ(100px); }\n#cube .right { -webkit-transform: rotateY(90deg) translateZ(100px); }\n#cube .left { -webkit-transform: rotateY(-90deg) translateZ(100px); }\n#cube .top { -webkit-transform: rotateX(90deg) translateZ(100px); }\n#cube .bottom { -webkit-transform: rotateX(-90deg) translateZ(100px); }\n\nNote here that the translateZ function comes after the rotate. The order of transform functions is important. Take a moment and soak this up. Each face is first rotated towards its position, then translated outward in a separate vector.\n\nWe have a working cube, but we\u2019re not done yet.\n\nReturning to the Z-axis origin\n\nFor the sake of our users, our 3-D transforms should not distort the interface when the active panel is at its resting position. But once we start pushing elements off their Z-axis origin, distortion is inevitable. \n\nIn order to keep 3-D transforms snappy, Safari composites the element, then applies the transform. Consequently, anti-aliasing on text will remain whatever it was before the transform was applied. When transformed forward in 3-D space, significant pixelation can occur. \n\nSee Example: Transforms 2.\n\n\n\n\n\n\n\nLooking back at the Perspective 3 demo, note that no matter how small the perspective value is, or wherever the transform-origin may be, the panel number 1 always returns to its original position, as if all those funky 3-D transforms didn\u2019t even matter.\n\nTo resolve the distortion and restore pixel perfection to our #cube, we can push the 3-D object back, so that the front face will be positioned back to the Z-axis origin.\n\n#cube { -webkit-transform: translateZ(-100px); }\n\nSee Example: Cube 1.\n\n\n\nRestoring the front face to the original position on the Z-axis\n\n\n\nRotating the cube\n\nTo expose any face of the cube, we\u2019ll need a style that rotates the cube to expose any face. The transform values are the opposite of those for the corresponding face. We toggle the necessary class on the #box to apply the appropriate transform.\n\n#cube.show-front { -webkit-transform: translateZ(-100px) rotateY(0deg); }\n#cube.show-back { -webkit-transform: translateZ(-100px) rotateX(-180deg); }\n#cube.show-right { -webkit-transform: translateZ(-100px) rotateY(-90deg); }\n#cube.show-left { -webkit-transform: translateZ(-100px) rotateY(90deg); }\n#cube.show-top { -webkit-transform: translateZ(-100px) rotateX(-90deg); }\n#cube.show-bottom { -webkit-transform: translateZ(-100px) rotateX(90deg); }\n\nNotice how the order of the transform functions has reversed. First, we push the object back with translateZ, then we rotate it.\n\nFinishing up, we can add a transition to animate the rotation between states. \n\n#cube { -webkit-transition: -webkit-transform 1s; }\n\nSee Example: Cube 2.\n\n\n\nRotating the cube with a CSS transition\n\n\n\nRectangular prism\n\nCubes are easy enough to generate, as we only have to worry about one measurement. But how would we handle a non-regular rectangular prism? Let\u2019s try to make one that\u2019s 300 pixels wide, 200 pixels high, and 100 pixels deep. \n\nThe markup remains the same as the #cube, but we\u2019ll switch the cube id for #box. The container styles remain mostly the same:\n\n.container {\n  width: 300px;\n  height: 200px;\n  position: relative;\n  -webkit-perspective: 1000;\n}\n#box {\n  width: 100%;\n  height: 100%;\n  position: absolute;\n  -webkit-transform-style: preserve-3d;\n}\n\nNow to position the faces. Each set of faces will need their own sizes. The smaller faces (left, right, top and bottom) need to be positioned in the centre of the container, where they can be easily rotated and then shifted outward. The thinner left and right faces get positioned left: 100px ((300\u2009\u2212\u2009100)\u2009\u00f7\u20092), The stouter top and bottom faces get positioned top: 50px ((200\u2009\u2212\u2009100)\u2009\u00f7\u20092).\n\n#box figure {\n  display: block;\n  position: absolute;\n  border: 2px solid black;\n}\n#box .front,\n#box .back {\n  width: 296px;\n  height: 196px;\n}\n#box .right,\n#box .left {\n  width: 96px;\n  height: 196px;\n  left: 100px;\n}\n#box .top,\n#box .bottom {\n  width: 296px;\n  height: 96px;\n  top: 50px;\n}\n\nThe rotate values can all remain the same as the cube example, but for this rectangular prism, the translate values do differ. The front and back faces are each shifted out 50 pixels since the #box is 100 pixels deep. The translate value for the left and right faces is 150 pixels for their 300 pixels width. Top and bottom panels take 100 pixels for their 200 pixels height:\n\n#box .front { -webkit-transform: rotateY(0deg) translateZ(50px); }\n#box .back { -webkit-transform: rotateX(180deg) translateZ(50px); }\n#box .right { -webkit-transform: rotateY(90deg) translateZ(150px); }\n#box .left { -webkit-transform: rotateY(-90deg) translateZ(150px); }\n#box .top { -webkit-transform: rotateX(90deg) translateZ(100px); }\n#box .bottom { -webkit-transform: rotateX(-90deg) translateZ(100px); }\n\nSee Example: Box 1.\n\n\n\n\n\n\n\nJust like the cube example, to expose a face, the #box needs to have a style to reverse that face\u2019s transform. Both the translateZ and rotate values are the opposites of the corresponding face.\n\n#box.show-front { -webkit-transform: translateZ(-50px) rotateY(0deg); }\n#box.show-back { -webkit-transform: translateZ(-50px) rotateX(-180deg); }\n#box.show-right { -webkit-transform: translateZ(-150px) rotateY(-90deg); }\n#box.show-left { -webkit-transform: translateZ(-150px) rotateY(90deg); }\n#box.show-top { -webkit-transform: translateZ(-100px) rotateX(-90deg); }\n#box.show-bottom { -webkit-transform: translateZ(-100px) rotateX(90deg); }\n\nSee Example: Box 2.\n\n\n\nRotating the rectangular box with a CSS transition\n\n\n\nCarousel\n\nFront-end developers have a myriad of choices when it comes to content carousels. Now that we have 3-D capabilities in our browsers, why not take a shot at creating an actual 3-D carousel?\n\nThe markup for this demo takes the same form as the box, cube and card. Let\u2019s make it interesting and have a carousel with nine panels.\n\n<div class=\"container\">\n  <div id=\"carousel\">\n    <figure>1</figure>\n    <figure>2</figure>\n    <figure>3</figure>\n    <figure>4</figure>\n    <figure>5</figure>\n    <figure>6</figure>\n    <figure>7</figure>\n    <figure>8</figure>\n    <figure>9</figure>\n  </div>\n</div>\n\nNow, apply basic layout styles. Let\u2019s give each panel of the #carousel 20 pixel gaps between one another, done here with left: 10px; and top: 10px;. The effective width of each panel is 210 pixels.\n\n.container {\n  width: 210px;\n  height: 140px;\n  position: relative;\n  -webkit-perspective: 1000;\n}\n#carousel {\n  width: 100%;\n  height: 100%;\n  position: absolute;\n  -webkit-transform-style: preserve-3d;\n}\n#carousel figure {\n  display: block;\n  position: absolute;\n  width: 186px;\n  height: 116px;\n  left: 10px;\n  top: 10px;\n  border: 2px solid black;\n}\n\nNext up: rotating the faces. This #carousel has nine panels. If each panel gets an equal distribution on the carousel, each panel would be rotated forty degrees from its neighbour (360\u2009\u00f7\u20099).\n\n#carousel figure:nth-child(1) { -webkit-transform: rotateY(0deg); }\n#carousel figure:nth-child(2) { -webkit-transform: rotateY(40deg); }\n#carousel figure:nth-child(3) { -webkit-transform: rotateY(80deg); }\n#carousel figure:nth-child(4) { -webkit-transform: rotateY(120deg); }\n#carousel figure:nth-child(5) { -webkit-transform: rotateY(160deg); }\n#carousel figure:nth-child(6) { -webkit-transform: rotateY(200deg); }\n#carousel figure:nth-child(7) { -webkit-transform: rotateY(240deg); }\n#carousel figure:nth-child(8) { -webkit-transform: rotateY(280deg); }\n#carousel figure:nth-child(9) { -webkit-transform: rotateY(320deg); }\n\nNow, the outward shift. Back when we were creating the cube and box, the translate value was simple to calculate, as it was equal to one half the width, height or depth of the object. With this carousel, there is no size we can automatically use as a reference. We\u2019ll have to calculate the distance of the shift by other means.\n\n\n\nDrawing a diagram of the carousel, we can see that we know only two things: the width of each panel is 210 pixels; and the each panel is rotated forty degrees from the next. If we split one of these segments down its centre, we get a right-angled triangle, perfect for some trigonometry.\n\nWe can determine the length of r in this diagram with a basic tangent equation:\n\n\n\nThere you have it: the panels need to be translated 288 pixels in 3-D space. \n\n#carousel figure:nth-child(1) { -webkit-transform: rotateY(0deg) translateZ(288px); }\n#carousel figure:nth-child(2) { -webkit-transform: rotateY(40deg) translateZ(288px); }\n#carousel figure:nth-child(3) { -webkit-transform: rotateY(80deg) translateZ(288px); }\n#carousel figure:nth-child(4) { -webkit-transform: rotateY(120deg) translateZ(288px); }\n#carousel figure:nth-child(5) { -webkit-transform: rotateY(160deg) translateZ(288px); }\n#carousel figure:nth-child(6) { -webkit-transform: rotateY(200deg) translateZ(288px); }\n#carousel figure:nth-child(7) { -webkit-transform: rotateY(240deg) translateZ(288px); }\n#carousel figure:nth-child(8) { -webkit-transform: rotateY(280deg) translateZ(288px); }\n#carousel figure:nth-child(9) { -webkit-transform: rotateY(320deg) translateZ(288px); }\n\nIf we decide to change the width of the panel or the number of panels, we only need to plug in those two variables into our equation to get the appropriate translateZ value. In JavaScript terms, that equation would be:\n\nvar tz = Math.round( ( panelSize / 2 ) / \n  Math.tan( ( ( Math.PI * 2 ) / numberOfPanels ) / 2 ) );\n// or simplified to\nvar tz = Math.round( ( panelSize / 2 ) / \n  Math.tan( Math.PI / numberOfPanels ) );\n\nJust like our previous 3-D objects, to show any one panel we need only apply the reverse transform on the carousel. Here\u2019s the style to show the fifth panel:\n\n-webkit-transform: translateZ(-288px) rotateY(-160deg);\n\nSee Example: Carousel 1.\n\n\n\n\n\n\n\nBy now, you probably have two thoughts: \n\n\n\tRewriting transform styles for each panel looks tedious.\n\tWhy bother doing high school maths? Aren\u2019t robots supposed to be doing all this work for us?\n\n\nAnd you\u2019re absolutely right. The repetitive nature of 3-D objects lends itself to scripting. We can offload all the monotonous transform styles to our dynamic script, which, if done correctly, will be more flexible than the hard-coded version.\n\nSee Example: Carousel 2.\n\nConclusion\n\n3-D transforms change the way we think about the blank canvas of web design. Better yet, they change the canvas itself, trading in the flat surface for voluminous depth.\n\nMy hope is that you took at least one peak at a demo and were intrigued. We web designers, who have rejoiced for border-radius, box-shadow and background gradients, now have an incredible tool at our disposal in 3-D transforms. They deserve just the same enthusiasm, research and experimentation we have seen on other CSS3 features. Now is the perfect time to take the plunge and start thinking about how to use three dimensions to elevate our craft. I\u2019m breathless waiting for what\u2019s to come. \n\nSee you on the flip side.", "year": "2010", "author": "David DeSandro", "author_slug": "daviddesandro", "published": "2010-12-14T00:00:00+00:00", "url": "https://24ways.org/2010/intro-to-css-3d-transforms/", "topic": "code"}
{"rowid": 171, "title": "Rock Solid HTML Emails", "contents": "At some stage in your career, it\u2019s likely you\u2019ll be asked by a client to design a HTML email. Before you rush to explain that all the cool kids are using social media, keep in mind that when done correctly, email is still one of the best ways to promote you and your clients online. In fact, a recent survey showed that every dollar spent on email marketing this year generated more than $40 in return. That\u2019s more than any other marketing channel, including the cool ones.\n\nThere are a whole host of ingredients that contribute to a good email marketing campaign. Permission, relevance, timeliness and engaging content are all important. Even so, the biggest challenge for designers still remains building an email that renders well across all the popular email clients.\n\nSame same, but different\n\nBefore getting into the details, there are some uncomfortable facts that those new to HTML email should be aware of. Building an email is not like building for the web. While web browsers continue their onward march towards standards, many email clients have stubbornly stayed put. Some have even gone backwards. In 2007, Microsoft switched the Outlook rendering engine from Internet Explorer to Word. Yes, as in the word processor. Add to this the quirks of the major web-based email clients like Gmail and Hotmail, sprinkle in a little Lotus Notes and you\u2019ll soon realize how different the email game is.\n\nWhile it\u2019s not without its challenges, rest assured it can be done. In my experience the key is to focus on three things. First, you should keep it simple. The more complex your email design, the more likely is it to choke on one of the popular clients with poor standards support. Second, you need to take your coding skills back a good decade. That often means nesting tables, bringing CSS inline and following the coding guidelines I\u2019ll outline below. Finally, you need to test your designs regularly. Just because a template looks nice in Hotmail now, doesn\u2019t mean it will next week.\n\nSetting your lowest common denominator\n\nTo maintain your sanity, it\u2019s a good idea to decide exactly which email clients you plan on supporting when building a HTML email. While general research is helpful, the email clients your subscribers are using can vary significantly from list to list. If you have the time there are a number of tools that can tell you specifically which email clients your subscribers are using. Trust me, if the testing shows almost none of them are using a client like Lotus Notes, save yourself some frustration and ignore it altogether. \n\nKnowing which email clients you\u2019re targeting not only makes the building process easier, it can save you lots of time in the testing phase too. For the purpose of this article, I\u2019ll be sharing techniques that give the best results across all of the popular clients, including the notorious ones like Gmail, Lotus Notes 6 and Outlook 2007. Just remember that pixel perfection in all email clients is a pipe dream.\n\nLet\u2019s get started.\n\nUse tables for layout\n\nBecause clients like Gmail and Outlook 2007 have poor support for float, margin and padding, you\u2019ll need to use tables as the framework of your email. While nested tables are widely supported, consistent treatment of width, margin and padding within table cells is not. For the best results, keep the following in mind when coding your table structure.\n\nSet the width in each cell, not the table\n\nWhen you combine table widths, td widths, td padding and CSS padding into an email, the final result is different in almost every email client. The most reliable way to set the width of your table is to set a width for each cell, not for the table itself.\n\n<table cellspacing=\"0\" cellpadding=\"10\" border=\"0\">\n\t<tr>\n\t\t<td width=\"80\"></td>\n\t\t<td width=\"280\"></td>\n\t</tr>\n</table>\n\nNever assume that if you don\u2019t specify a cell width the email client will figure it out. It won\u2019t.  Also avoid using percentage based widths. Clients like Outlook 2007 don\u2019t respect them, especially for nested tables. Stick to pixels. If you want to add padding to each cell, use either the cellpadding attribute of the table or CSS padding for each cell, but never combine the two.\n\nErr toward nesting\n\nTable nesting is far more reliable than setting left and right margins or padding for table cells. If you can achieve the same effect by table nesting, that will always give you the best result across the buggier email clients.\n\nUse a container table for body background colors\n\nMany email clients ignore background colors specified in your CSS or the <body> tag. To work around this, wrap your entire email with a 100% width table and give that a background color.\n\n<table cellspacing=\"0\" cellpadding=\"0\" border=\"0\" width=\"100%\">\n\t<tr>\n\t\t<td bgcolor=\u201d#000000\u201d>\n\t\t\tYour email code goes here.\n\t\t</td>\n\t</tr>\n</table>\n\nYou can use the same approach for background images too. Just remember that some email clients don\u2019t support them, so always provide a fallback color.\n\nAvoid unnecessary whitespace in table cells\n\nWhere possible, avoid whitespace between your <td> tags. Some email clients (ahem, Yahoo! and Hotmail) can add additional padding above or below the cell contents in some scenarios, breaking your design for no apparent reason.\n\nCSS and general font formatting\n\nWhile some email designers do their best to avoid CSS altogether and rely on the dreaded <font> tag, the truth is many CSS properties are well supported by most email clients. See this comprehensive list of CSS support across the major clients for a good idea of the safe properties and those that should be avoided. \n\nAlways move your CSS inline\n\nGmail is the culprit for this one. By stripping the CSS from the <head> and <body> of any email, we\u2019re left with no choice but to move all CSS inline. The good news is this is something you can almost completely automate. Free services like Premailer will move all CSS inline with the click of a button. I recommend leaving this step to the end of your build process so you can utilize all the benefits of CSS.\n\nAvoid shorthand for fonts and hex notation\n\nA number of email clients reject CSS shorthand for the font property. For example, never set your font styles like this.\n\np {\n\tfont:bold 1em/1.2em georgia,times,serif;\n}\n\nInstead, declare the properties individually like this.\n\np {\n\tfont-weight: bold;\n\tfont-size: 1em;\n\tline-height: 1.2em;\n\tfont-family: georgia,times,serif;\n}\n\nWhile we\u2019re on the topic of fonts, I recently tested every conceivable variation of @font-face across the major email clients. The results were dismal, so unfortunately it\u2019s web-safe fonts in email for the foreseeable future.\n\nWhen declaring the color property in your CSS, some email clients don\u2019t support shorthand hexadecimal colors like color:#f60; instead of color:#ff6600;. Stick to the longhand approach for the best results.\n\nParagraphs\n\nJust like table cell spacing, paragraph spacing can be tricky to get a consistent result across the board. I\u2019ve seen many designers revert to using double <br /> or DIVs with inline CSS margins to work around these shortfalls, but recent testing showed that paragraph support is now reliable enough to use in most cases (there was a time when Yahoo! didn\u2019t support the paragraph tag at all).\n\nThe best approach is to set the margin inline via CSS for every paragraph in your email, like so:\n\np {\n\tmargin: 0 0 1.6em 0;\n}\n\nAgain, do this via CSS in the head when building your email, then use Premailer to bring it inline for each paragraph later.\n\nIf part of your design is height-sensitive and calls for pixel perfection, I recommend avoiding paragraphs altogether and setting the text formatting inline in the table cell. You might need to use table nesting or cellpadding / CSS to get the desired result. Here\u2019s an example:\n\n<td width=\"200\" style=\"font-weight:bold; font-size:1em; line-height:1.2em; font-family:georgia,'times',serif;\">your height sensitive text</td>\n\nLinks\n\nSome email clients will overwrite your link colors with their defaults, and you can avoid this by taking two steps. First, set a default color for each link inline like so:\n\n<a href=\"http://somesite.com/\" style=\"color:#ff00ff\">this is a link</a>\n\nNext, add a redundant span inside the a tag.\n\n<a href=\"http://somesite.com/\" style=\"color:#ff00ff\"><span style=\"color:#ff00ff\">this is a link</span></a>\n\nTo some this may be overkill, but if link color is important to your design then a superfluous span is the best way to achieve consistency.\n\nImages in HTML emails\n\nThe most important thing to remember about images in email is that they won\u2019t be visible by default for many subscribers. If you start your design with that assumption, it forces you to keep things simple and ensure no important content is suppressed by image blocking.\n\nWith this in mind, here are the essentials to remember when using images in HTML email:\n\nAvoid spacer images\n\nWhile the combination of spacer images and nested tables was popular on the web ten years ago, image blocking in many email clients has ruled it out as a reliable technique today. Most clients replace images with an empty placeholder in the same dimensions, others strip the image altogether. Given image blocking is on by default in most email clients, this can lead to a poor first impression for many of your subscribers. Stick to fixed cell widths to keep your formatting in place with or without images.\n\nAlways include the dimensions of your image\n\nIf you forget to set the dimensions for each image, a number of clients will invent their own sizes when images are blocked and break your layout. Also, ensure that any images are correctly sized before adding them to your email. Some email clients will ignore the dimensions specified in code and rely on the true dimensions of your image. \n\nAvoid PNGs\n\nLotus Notes 6 and 7 don\u2019t support 8-bit or 24-bit PNG images, so stick with the GIF or JPG formats for all images, even if it means some additional file size.\n\nProvide fallback colors for background images\n\nOutlook 2007 has no support for background images (aside from this hack to get full page background images working). If you want to use a background image in your design, always provide a background color the email client can fall back on. This solves both the image blocking and Outlook 2007 problem simultaneously.\n\nDon\u2019t forget alt text\n\nLack of standards support means email clients have long destroyed the chances of a semantic and accessible HTML email. Even still, providing alt text is important from an image blocking perspective. Even with images suppressed by default, many email clients will display the provided alt text instead. Just remember that some email clients like Outlook 2007, Hotmail and Apple Mail don\u2019t support alt text at all when images are blocked.\n\nUse the display hack for Hotmail\n\nFor some inexplicable reason, Windows Live Hotmail adds a few pixels of additional padding below images. A workaround is to set the display property like so.\n\nimg {display:block;}\n\nThis removes the padding in Hotmail and still gives you the predicable result in other email clients.\n\nDon\u2019t use floats\n\nBoth Outlook 2007 and earlier versions of Notes offer no support for the float property. Instead, use the align attribute of the img tag to float images in your email.\n\n<img src=\"image.jpg\" align=\"right\">\n\nIf you\u2019re seeing strange image behavior in Yahoo! Mail, adding align=\u201ctop\u201d to your images can often solve this problem.\n\nVideo in email\n\nWith no support for JavaScript or the object tag, video in email (if you can call it that) has long been limited to animated gifs. However, some recent research I did into the HTML5 video tag in email showed some promising results.\n\nTurns out HTML5 video does work in many email clients right now, including Apple Mail, Entourage 2008, MobileMe and the iPhone. The real benefit of this approach is that if the video isn\u2019t supported, you can provide reliable fallback content such as an animated GIF or a clickable image linking to the video in the browser.\n\nOf course, the question of whether you should add video to email is another issue altogether. If you lean toward the \u201cyes\u201d side check out the technique with code samples.\n\nWhat about mobile email?\n\nThe mobile email landscape was a huge mess until recently. With the advent of the iPhone, Android and big improvements from Palm and RIM, it\u2019s becoming less important to think of mobile as a different email platform altogether.\n\nThat said, there are a few key pointers to keep in mind when coding your emails to get a decent result for your more mobile subscribers.\n\nKeep the width less than 600 pixels\n\nBecause of email client preview panes, this rule was important long before mobile email clients came of age. In truth, the iPhone and Pre have a viewport of 320 pixels, the Droid 480 pixels and the Blackberry models hover around 360 pixels. Sticking to a maximum of 600 pixels wide ensures your design should still be readable when scaled down for each device. This width also gives good results in desktop and web-based preview panes.\n\nBe aware of automatic text resizing\n\nIn what is almost always a good feature, email clients using webkit (such as the iPhone, Pre and Android) can automatically adjust font sizes to increase readability. If testing shows this feature is doing more harm than good to your design, you can always disable it with the following CSS rule:\n\n-webkit-text-size-adjust: none;\n\nDon\u2019t forget to test\n\nWhile standards support in email clients hasn\u2019t made much progress in the last few years, there has been continual change (for better or worse) in some email clients. Web-based providers like Yahoo!, Hotmail and Gmail are notorious for this. On countless occasions I\u2019ve seen a proven design suddenly stop working without explanation.\n\nFor this reason alone it\u2019s important to retest your email designs on a regular basis. I find a quick test every month or so does the trick, especially in the web-based clients. The good news is that after designing and testing a few HTML email campaigns, you will find that order will emerge from the chaos. Many of these pitfalls will become quite predictable and your inbox-friendly designs will take shape with them in mind.\n\nLooking ahead\n\nDesigning HTML email can be a tough pill for new designers and standardistas to swallow, especially given the fickle and retrospective nature of email clients today. With HTML5 just around the corner we are entering a new, uncertain phase. Will email client developers take the opportunity to repent on past mistakes and bring email clients into the present? The aim of groups such as the Email Standards Project is to make much of the above advice as redundant as the long-forgotten <blink> and <marquee> tags, however, only time will tell if this is to become a reality.\n\nAlthough not the most compliant (or fashionable) medium, the results speak for themselves \u2013 email is, and will continue to be one of the most successful and targeted marketing channels available to you. As a designer with HTML email design skills in your arsenal, you have the opportunity to not only broaden your service offering, but gain a unique appreciation of how vital standards are.\n\nNext steps\n\nReady to get started? There are a number of HTML email design galleries to provide ideas and inspiration for your own designs. \n\n\n\thttp://www.campaignmonitor.com/gallery/\n\thttp://htmlemailgallery.com/\n\thttp://inboxaward.com/\n\n\nEnjoy!", "year": "2009", "author": "David Greiner", "author_slug": "davidgreiner", "published": "2009-12-13T00:00:00+00:00", "url": "https://24ways.org/2009/rock-solid-html-emails/", "topic": "code"}
{"rowid": 257, "title": "The (Switch)-Case for State Machines in User Interfaces", "contents": "You\u2019re tasked with creating a login form. Email, password, submit button, done.\n\u201cThis will be easy,\u201d you think to yourself.\nLogin form by Selecto\nYou\u2019ve made similar forms many times in the past; it\u2019s essentially muscle memory at this point. You\u2019re working closely with a designer, who gives you a beautiful, detailed mockup of a login form. Sure, you\u2019ll have to translate the pixels to meaningful, responsive CSS values, but that\u2019s the least of your problems.\nAs you\u2019re writing up the HTML structure and CSS layout and styles for this form, you realize that you don\u2019t know what the successful \u201clogged in\u201d page looks like. You remind the designer, who readily gives it to you. But then you start thinking more and more about how the login form is supposed to work.\n\nWhat if login fails? Where do those errors show up?\nShould we show errors differently if the user forgot to enter their email, or password, or both?\nOr should the submit button be disabled?\nShould we validate the email field?\nWhen should we show validation errors \u2013 as they\u2019re typing their email, or when they move to the password field, or when they click submit? (Note: many, many login forms are guilty of this.)\nWhen should the errors disappear?\nWhat do we show during the login process? Some loading spinner?\nWhat if loading takes too long, or a server error occurs?\n\nMany more questions come up, and you (and your designer) are understandably frustrated. The lack of upfront specification opens the door to scope creep, which readily finds itself at home in all the unexplored edge cases.\nModeling Behavior\nDescribing all the possible user flows and business logic of an application can become tricky. Ironically, user stories might not tell the whole story \u2013 they often leave out potential edge-cases or small yet important bits of information.\nHowever, one important (and very old) mathematical model of computation can be used for describing the behavior and all possible states of a user interface: the finite state machine.\nThe general idea, as it applies to user interfaces, is that all of our applications can be described (at some level of abstraction) as being in one, and only one, of a finite number of states at any given time. For example, we can describe our login form above in these states:\n\nstart - not submitted yet\nloading - submitted and logging in\nsuccess - successfully logged in\nerror - login failed\n\nAdditionally, we can describe an application as accepting a finite number of events \u2013 that is, all the possible events that can be \u201csent\u201d to the application, either from the user or some other external entity:\n\nSUBMIT - pressing the submit button\nRESOLVE - the server responds, indicating that login is successful\nREJECT - the server responds, indicating that login failed\n\nThen, we can combine these states and events to describe the transitions between them. That is, when the application is in one state, an an event occurs, we can specify what the next state should be:\n\nFrom the start state, when the SUBMIT event occurs, the app should be in the loading state.\nFrom the loading state, when the RESOLVE event occurs, login succeeded and the app should be in the success state.\nIf login fails from the loading state (i.e., when the REJECT event occurs), the app should be in the error state.\nFrom the error state, the user should be able to retry login: when the SUBMIT event occurs here, the app should go to the loading state.\nOtherwise, if any other event occurs, don\u2019t do anything and stay in the same state.\n\nThat\u2019s a pretty thorough description, similar to a user story! It\u2019s also a bit more symbolic than a user story (e.g., \u201cwhen the SUBMIT event occurs\u201d instead of \u201cwhen the user presses the submit button\u201d), and that\u2019s for a reason. By representing states, events, and transitions symbolically, we can visualize what this state machine looks like:\n\nEvery state is represented by a box, and every event is connected to a transition arrow that connects two states. This makes it intuitive to follow the flow and understand what the next state should be given the current state and an event.\nFrom Visuals to Code\nDrawing a state machine doesn\u2019t require any special software; in fact, using paper and pencil (in case anything changes!) does the job quite nicely. However, one common problem is handoff: it doesn\u2019t matter how detailed a user story or how well-designed a visualization is, it eventually has to be coded in order for it to become part of a real application.\nWith the state machine model described above, the same visual description can be mapped directly to code. Traditionally, and as the title suggests, this is done using switch/case statements:\nfunction loginMachine(state, event) {\n    switch (state) {\n        case 'start':\n            if (event === 'SUBMIT') {\n                return 'loading';\n            }\n            break;\n        case 'loading':\n            if (event === 'RESOLVE') {\n                return 'success';\n            } else if (event === 'REJECT') {\n                return 'error';\n            }\n            break;\n        case 'success':\n            // Accept no further events\n            break;\n        case 'error':\n            if (event === 'SUBMIT') {\n                return 'loading';\n            }\n            break;\n        default:\n            // This should never occur\n            return undefined;\n    }\n}\n\nconsole.log(loginMachine('start', 'SUBMIT'));\n// => 'loading'\nThis is fine (I suppose) but personally, I find it much easier to use objects:\nconst loginMachine = {\n  initial: \"start\",\n  states: {\n    start: {\n      on: { SUBMIT: 'loading' }\n    },\n    loading: {\n      on: {\n        REJECT: 'error',\n        RESOLVE: 'success'\n      }\n    },\n    error: {\n      on: {\n        SUBMIT: 'loading'\n      }\n    },\n    success: {}\n  }\n};\n\nfunction transition(state, event) {\n  return machine\n    .states[state] // Look up the state\n    .on[event]     // Look up the next state based on the event\n    || state;      // If not found, return the current state\n}\n\nconsole.log(transition('start', 'SUBMIT'));\nAs you might have noticed, the loginMachine is a plain JS object, and can be written in JSON. This is important because it allows the machine to be visualized by a 3rd-party tool, as demonstrated here:\n\nA Common Language Between Designers and Developers\nAlthough finite state machines are a fundamental part of computer science, they have an amazing potential to bridge the application specification gap between designers and developers, as well as project managers, stakeholders, and more. By designing a state machine visually and with code, designers and developers alike can:\n\nidentify all possible states, and potentially missing states\ndescribe exactly what should happen when an event occurs on a given state, and prevent that event from having unintended side-effects in other states (ever click a submit button more than once?)\neliminate impossible states and identify states that are \u201cunreachable\u201d (have no entry transition) or \u201csunken\u201d (have no exit transition)\nadd features with full confidence of knowing what other states it might affect\nsimplify redundant states or complex user flows\ncreate test paths for almost every possible user flow, and easily identify edge cases\ncollaborate better by understanding the entire application model equally.\n\nNot a New Idea\nI\u2019m not the first to suggest that state machines can help bridge the gap between design and development.\n\nVince MingPu Shao wrote an article about designing UI states and communicating with developers effectively with finite state machines\nUser flow diagrams, which visually describe the paths that a user can take through an app to achieve certain goals, are essentially state machines. Numerous tools, from Sketch plugins to standalone apps, exist for creating them.\nIn 1999, Ian Horrocks wrote a book titled \u201cConstructing the User Interface with Statecharts\u201d, which takes state machines to the next level and describes the inherent difficulties (and solutions) with creating complex UIs. The ideas in the book are still relevant today.\nMore than a decade earlier, David Harel published \u201cStatecharts: A Visual Formalism for Complex Systems\u201d, in which the statechart - an extended hierarchical state machine model - is born.\n\nState machines and statecharts have been used for complex systems and user interfaces, both physical and digital, for decades, and are especially prevalent in other industries, such as game development and embedded electronic systems. Even NASA uses statecharts for the Curiosity Rover and more, citing many benefits:\n\nVisualized modeling\nPrecise diagrams\nAutomatic code generation\nComprehensive test coverage\nAccommodation of late-breaking requirements changes\n\nMoving Forward\nIt\u2019s time that we improve how we communicate between designers and developers, much less improve the way we develop UIs to deliver the best, bug-free, optimal user experience. There is so much more to state machines and statecharts than just being a different way of designing and coding. For more resources:\n\nThe World of Statecharts is a comprehensive guide by Erik Mogensen in using statecharts in your applications\nThe Statechart Community on Spectrum is always full of interesting ideas and questions related to state machines, statecharts, and software modeling\nI gave a talk at React Rally over a year ago about how state machines (finite automata) can improve the way we develop applications. The latest one is from Reactive Conf, where I demonstrate how statecharts can be used to automatically generate test cases.\nI have also been working on XState, which is a library for \u201cstate machines and statecharts for the modern web\u201d. You can create and visualize statecharts in JavaScript, and use them in any framework (and soon enough, multiple different languages).\n\nI\u2019m excited about the future of developing web and mobile applications with statecharts, especially with regard to faster design/development cycles, auto-generated testing, better error prevention, comprehensive analytics, and even the use of model-based reinforcement learning and artificial intelligence to greatly improve the user experience.", "year": "2018", "author": "David Khourshid", "author_slug": "davidkhourshid", "published": "2018-12-12T00:00:00+00:00", "url": "https://24ways.org/2018/state-machines-in-user-interfaces/", "topic": "code"}
{"rowid": 195, "title": "Levelling Up for Junior Developers", "contents": "If you are a junior developer starting out in the web industry, things can often seem a little daunting. There are so many things to learn, and as soon as you\u2019ve learnt one framework or tool, there seems to be something new out there.\nI am lucky enough to lead a team of developers building applications for the web. During a recent One to One meeting with one of our junior developers, he asked me about a learning path and the basic fundamentals that every developer should know. After a bit of digging around, I managed to come up with a (not so exhaustive) list of principles that was shared with him.\n\nIn this article, I will share the list with you, and hopefully help you level up from junior developer and become a better developer all round. This list doesn\u2019t focus on an particular programming language, but rather coding concepts as a whole. The idea behind this list is that whether you are a front-end developer, back-end developer, full stack developer or just a curious one, these principles apply to everyone that writes code. \nI have tried to be technology agnostic, so that you can use these tips to guide you, whatever your tech stack might be.\nWithout any further ado and in no particular order, let\u2019s get started.\nRefactoring code like a boss\nThe Boy Scouts have a rule that goes \u201calways leave the campground cleaner than you found it.\u201d This rule can be applied to code too and ensures that you leave code cleaner than you found it. As a junior developer, it\u2019s almost certain that you will either create or come across older code that could be improved. The resources below are a guide that will help point you in the right direction.\n\nMy favourite book on this subject has to be Clean Code by Robert C. Martin. It\u2019s a must read for anyone writing code as it helps you identify bad code and shows you techniques that you can use to improve existing code.\nIf you find that in your day to day work you deal with a lot of legacy code, Improving Existing Technology through Refactoring is another useful read.\nDesign Patterns are a general repeatable solution to a commonly occurring problem in software design. My friend and colleague Ranj Abass likes to refer to them as a \u201ccommon language\u201d that helps developers discuss the way that we write code as a pattern. My favourite book on this subject is Head First Design Patterns which goes right back to the basics. Another great read on this topic is Refactoring to Patterns.\nWorking Effectively With Legacy Code is another one that I found really valuable.\n\nImproving your debugging skills\nA solid understanding of how to debug code is a must for any developer. Whether you write code for the web or purely back-end code, the ability to debug will save you time and help you really understand what is going on under the hood.\n\nIf you write front-end code for the web, one of my favourite resources to help you understand how to debug code in Chrome can be found on the Chrome Dev Tools website. While some of the tips are specific to Chrome, these techniques apply to any modern browser of your choice.\nAt Settled, we use Node.js for much of our server side code. Without a doubt, our most trusted IDE has to be Visual Studio Code and the built-in debuggers are amazing. Regardless of whether you use Node.js or not, there are a number of plugins and debuggers that you can use in the IDE. I recommend reading the website of your favourite IDE for more information. \nAs a side note, it is worth mentioning that Chrome Developer Tools actually has functionality that allows you to debug Node.js code too. This makes it a seamless transition from front-end code to server-side code debugging.\nThe Debugging Mindset is an informative online article by Devon H. O\u2019Dell and discusses the the psychology of learning strategies that lead to effective problem-solving skills. \n\nA good understanding of relational databases and NoSQL databases\nAlmost all developers will need to persist data at some point in their career. Even if you don\u2019t write SQL queries in your day to day job, a solid understanding of how they work will help you become a better developer.\n\nIf you are a complete newbie when it comes to databases, I recommend checking out Code Academy. They offer a free online course that can help you get your head around how relational databases work. The course is quite basic, but is a useful hands-on approach to learning this topic.\nThis article provides a great explainer for the difference between the SQL and NoSQL databases, and this  Stackoverflow answer goes a little deeper into the subject of the two database types.\nIf you\u2019d like to learn more about NoSQL queries, I would recommend starting with this article on MongoDB queries. Unfortunately, there isn\u2019t one overall course as most NoSQL databases have their own syntax. \n\nYou may also have noticed that I haven\u2019t included other types of databases such as Graph or In-memory; it\u2019s worth focussing on the basics before going any deeper.\nPerformance on the web\nIf you build for the web today, it is important to understand how the browser receives and renders the content that you send it. I am pretty passionate about Web Performance, and hope that everyone can learn how to make websites faster and more efficient. It can be fun at the same time!\n\nSteve Souders High Performance Websites is the godfather of web performance books. While it was created a few years ago and many of the techniques might have changed slightly, it is the original book on the subject and set up many of the ground rules that we know about web performance today.\nA free online resource on this topic is the Google Developers website. The site is an up to date guide on the best web performance techniques for your site. It is definitely worth a read.\nThe network plays a key role in delivering data to your users, and it plays a big role in performance on the web. A fantastic book on this topic is Ilya Grigorik\u2019s High Performance Browser Networking. It is also available to read online at hpbn.co.\n\nUnderstand the end to end architecture of your software project\nI find that one of the best ways to improve my knowledge is to learn about the architecture of the software at the company I work at. It gives you a good understanding as to why things are designed the way they are, why certain decisions were made, and gives you an understanding of how you might do things differently with hindsight.\nTry and find someone more senior, such as a Technical Lead or Software Architect, at your company and ask them to explain the overall architecture and draw a few high-level diagrams for you. Not to mention that they will be impressed with your willingness to learn.\n\nI recommend reading Clean Architecture: A Craftsman\u2019s Guide to Software Structure and Design for more detail on this subject.\nFar too often, software projects can be over-engineered and over-architected, it is worth reading Just Enough Software Architecture. The book helps developers understand how the smallest of changes can affect the outcome of your software architecture.\n\nHow are things deployed\nA big part of creating software is actually shipping it! How is the software at your company released into the wild? Does your company do Continuous Integration? Continuous Deployment?\n\nEven if you answered no to any of these questions, it is worth finding someone with the knowledge in your company to explain these things to you. If it is not already documented, perhaps you could start a wiki to document everything you\u2019re learning about the system - this is a great way to level up and be appreciated and invaluable.\nA streamlined deployment process is a beautiful thing, and understanding how they work can help you grow your knowledge as a developer. \nContinuous Integration is a practical read on the ins and outs of implementing this deployment technique.\nDocker is another great tool to use when it comes to software deployment. It can be tricky at first to wrap your head around, but it is definitely worth learning about this great technology. The documentation on the website will teach and guide you on how to get started using Docker.\n\nWriting Tests\nTesting is an essential tool in the developer bag of skills. They help you to make big refactoring changes to your code, and feel a lot more confident knowing that your changes haven\u2019t broken anything. There are so many benefits to testing, which make it so important for developers at every level to become acquainted with it/them.\n\nThe book that started it all for me was Roy Osherove\u2019s The Art of Unit Testing. The code in the book is written in C#, but the principles apply to every language. It\u2019s a great, easy-to-understand read.\nAnother great read is How Google Tests Software and covers exactly what it says on the tin. It covers many different testing techniques such as exploratory, black box, white box, and acceptance testing and really helps you understand how large organisations test their code.\n\nSoft skills\nWhilst reading through this article, you\u2019ve probably noticed that a large chunk of it focusses on code and technical ability. Without a doubt, I\u2019d say that it is even more important to be a good teammate. If you look up the definition of soft skills in the dictionary, it is defined as \u201cpersonal attributes that enable someone to interact effectively and harmoniously with other people\u201d and I think that it sums this up perfectly. Working on your \u201csoft skills\u201d is something that can truly help you level up in your career. You may be the world\u2019s greatest coder, but if you colleagues can\u2019t get along with you, your coding skills won\u2019t matter!\nWhile you may not learn how to become the perfect co-worker overnight, I really try and live by the motto \u201cdon\u2019t be an arsehole\u201d. Think about how you like to be treated and then try and treat your co-workers with the same courtesy and respect. The next time you need to make a decision at work, ask yourself \u201cis this something an arsehole would do\u201d? If you answered yes to that question, you probably shouldn\u2019t do it!\nSummary\nLevelling up as a junior developer doesn\u2019t have to be scary. Focus on the fundamentals and they should hold you in good stead, regardless of the new things that come along. Software engineering is built on these great principles that have stood the test of time.\nWhilst researching for this article, I came across a useful Github repo that is worth mentioning. Things Every Programmer Should Know is packed with useful information. I have to admit, I didn\u2019t know everything on there!\nI hope that you have found this list helpful. Some of the topics I have mentioned might not be relevant for you at this stage in your career, but should give a nudge in the right direction. After all, knowledge is power!\nIf you are a junior developer reading this article, what would you add to it?", "year": "2017", "author": "Dean Hume", "author_slug": "deanhume", "published": "2017-12-05T00:00:00+00:00", "url": "https://24ways.org/2017/levelling-up-for-junior-developers/", "topic": "code"}
{"rowid": 309, "title": "HTTP/2 Server Push and Service Workers: The Perfect Partnership", "contents": "Being a web developer today is exciting! The web has come a long way since its early days and there are so many great technologies that enable us to build faster, better experiences for our users. One of these technologies is HTTP/2 which has a killer feature known as HTTP/2 Server Push.\nDuring this year\u2019s Chrome Developer Summit, I watched a really informative talk by Sam Saccone, a Software Engineer on the Google Chrome team. He gave a talk entitled Planning for Performance, and one of the topics that he covered immediately piqued my interest; the idea that HTTP/2 Server Push and Service Workers were the perfect web performance combination.\n\nIf you\u2019ve never heard of HTTP/2 Server Push before, fear not - it\u2019s not as scary as it sounds. HTTP/2 Server Push simply allows the server to send data to the browser without having to wait for the browser to explicitly request it first. In this article, I am going to run through the basics of HTTP/2 Server Push and show you how, when combined with Service Workers, you can deliver the ultimate in web performance to your users.\nWhat is HTTP/2 Server Push?\nWhen a user navigates to a URL, a browser will make an HTTP request for the underlying web page. The browser will then scan the contents of the HTML document for any assets that it may need to retrieve such as CSS, JavaScript or images. Once it finds any assets that it needs, it will then make multiple HTTP requests for each resource that it needs and begin downloading one by one. While this approach works well, the problem is that each HTTP request means more round trips to the server before any data arrives at the browser. These extra round trips take time and can make your web pages load slower. \nBefore we go any further, let\u2019s see what this might look like when your browser makes a request for a web page. If you were to view this in the developer tools of your browser, it might look a little something like this:\n\nAs you can see from the image above, once the HTML file has been downloaded and parsed, the browser then makes HTTP requests for any assets that it needs. \nThis is where HTTP/2 Server Push comes in. The idea behind HTTP/2 Server Push is that when the browser requests a web page from the server, the server already knows about all the assets that are needed for the web page and \u201cpushes\u201d it to browser. This happens when the first HTTP request for the web page takes place and it eliminates an extra round trip, making your site faster. \nUsing the same example above, let\u2019s \u201cpush\u201d the JavaScript and CSS files instead of waiting for the browser to request them. The image below gives you an idea of what this might look like.\n\nWhoa, that looks different - let\u2019s break it down a little. Firstly, you can see that the JavaScript and CSS files appear earlier in the waterfall chart. You might also notice that the loading times for the files are extremely quick. The browser doesn\u2019t need to make an extra HTTP request to the server, instead it receives the critical files it needs all at once. Much better! \nThere are a number of different approaches when it comes to implementing HTTP/2 Server Push. Adoption is growing and many commercial CDNs such as Akamai and Cloudflare already offer support for Server Push. You can even roll your own implementation depending on your environment. I\u2019ve also previously blogged about building a basic HTTP/2 Server Push example using Node.js. In this post, I\u2019m not going to dive into how to implement HTTP/2 Server Push as that is an entire post in itself! However, I do recommend reading this article to find out more about the inner workings.\nHTTP/2 Server Push is awesome, but it isn\u2019t a magic bullet. It is fantastic for improving the load time of a web page when it first loads for a user, but it isn\u2019t that great when they request the same web page again. The reason for this is that HTTP/2 Server Push is not cache \u201caware\u201d. This means that the server isn\u2019t aware about the state of your client. If you\u2019ve visited a web page before, the server isn\u2019t aware of this and will push the resource again anyway, regardless of whether or not you need it. HTTP/2 Server Push effectively tells the browser that it knows better and that the browser should receive the resources whether it needs them or not. In theory browsers can cancel HTTP/2 Server Push requests if they\u2019re already got something in cache but unfortunately no browsers currently support it. The other issue is that the server will have already started to send some of the resource to the browser by the time the cancellation occurs.\nHTTP/2 Server Push & Service Workers\nSo where do Service Workers fit in? Believe it or not, when combined together HTTP/2 Server Push and Service Workers can be the perfect web performance partnership. If you\u2019ve not heard of Service Workers before, they are worker scripts that run in the background of your website. Simply put, they act as middleman between the client and the browser and enable you to intercept any network requests that come and go from the browser. They are packed with useful features such as caching, push notifications, and background sync. Best of all, they are written in JavaScript, making it easy for web developers to understand.\nUsing Service Workers, you can easily cache assets on a user\u2019s device. This means when a browser makes an HTTP request for an asset, the Service Worker is able to intercept the request and first check if the asset already exists in cache on the users device. If it does, then it can simply return and serve them directly from the device instead of ever hitting the server.\nLet\u2019s stop for a second and analyse what that means. Using HTTP/2 Server Push, you are able to push critical assets to the browser before the browser requests them. Then, using Service Workers you are able to cache these resources so that the browser never needs to make a request to the server again. That means a super fast first load and an even faster second load!\nLet\u2019s put this into action. The following HTML code is a basic web page that retrieves a few images and two JavaScript files.\n<!DOCTYPE html>\n<html>\n<head>\n  <meta charset=\"UTF-8\">\n  <title>HTTP2 Push Demo</title>\n</head>\n<body>\n  <h1>HTTP2 Push</h1>\n  <img src=\"./images/beer-1.png\" width=\"200\" height=\"200\" />\n  <img src=\"./images/beer-2.png\" width=\"200\" height=\"200\" />\n  <br>\n  <br>\n  <img src=\"./images/beer-3.png\" width=\"200\" height=\"200\" />\n  <img src=\"./images/beer-4.png\" width=\"200\" height=\"200\" />\n  <!-- Scripts -->\n  <script async src=\"./js/promise.min.js\"></script>\n  <script async src=\"./js/fetch.js\"></script>\n  <script>\n  // Register the service worker\n  if ('serviceWorker' in navigator) {\n    navigator.serviceWorker.register('./service-worker.js').then(function(registration) {\n      // Registration was successful\n      console.log('ServiceWorker registration successful with scope: ', registration.scope);\n    }).catch(function(err) {\n      // registration failed :(\n      console.log('ServiceWorker registration failed: ', err);\n    });\n  }\n  </script>\n</body>\n</html>\nIn the HTML code above, I am registering a Service Worker file named service-worker.js. In order to start caching assets, I am going to use the Service Worker toolbox . It is a lightweight helper library to help you get started creating your own Service Workers. Using this library, we can actually cache the base web page with the path /push.\nThe Service Worker Toolbox comes with a built-in routing system which is based on the same routing as Express. With just a few lines of code, you can start building powerful caching patterns.\nI\u2019ve add the following code to the service-worker.js file.\n(global => {\n  'use strict';\n\n  // Load the sw-toolbox library.\n  importScripts('/js/sw-toolbox/sw-toolbox.js');\n\n  // The route for any requests\n  toolbox.router.get('/push', global.toolbox.fastest);\n\n  toolbox.router.get('/images/(.*)', global.toolbox.fastest);\n\n  toolbox.router.get('/js/(.*)', global.toolbox.fastest);\n\n  // Ensure that our service worker takes control of the page as soon as possible.\n  global.addEventListener('install', event => event.waitUntil(global.skipWaiting()));\n  global.addEventListener('activate', event => event.waitUntil(global.clients.claim()));\n})(self);\nLet\u2019s break this code down further. Around line 4, I am importing the Service Worker toolbox. Next, I am specifying a route that will listen to any requests that match the URL /push. Because I am also interested in caching the images and JavaScript for that page, I\u2019ve told the toolbox to listen to these routes too.\nThe best thing about the code above is that if any of the assets exist in cache, we will instantly return the cached version instead of waiting for it to download. If the asset doesn\u2019t exist in cache, the code above will add it into cache so that we can retrieve it when it\u2019s needed again.\nYou may also notice the code global.toolbox.fastest - this is important because gives you the compromise of fulfilling from the cache immediately, while firing off an additional HTTP request updating the cache for the next visit.\nBut what does this mean when combined with HTTP/2 Server Push? Well, it means that on the first load of the web page, you are able to \u201cpush\u201d everything to the user at once before the browser has even requested it. The Service Worker activates and starts caching the assets on the users device. The next time a user visits the page, the Service Worker will intercept the request and serve the asset directly from cache. Amazing! \nUsing this technique, the waterfall chart for a repeat visit should look like the image below.\n\nIf you look closely at the image above, you\u2019ll notice that the web page returns almost instantly without ever making an HTTP request over the network. Using the Service Worker library, we cached the base page for the route /push, which allowed us to retrieve this directly from cache.\nWhether used on their own or combined together, the best thing about these two features is that they are the perfect progressive enhancement. If your user\u2019s browser doesn\u2019t support them, they will simply fall back to HTTP/1.1 without Service Workers. Your users may not experience as fast a load time as they would with these two techniques, but it would be no different from their normal experience. HTTP/2 Server Push and Service Workers are really the perfect partners when it comes to web performance.\nSummary\nWhen used correctly, HTTP/2 Server Push and Service Workers can have a positive impact on your site\u2019s load times. Together they mean super fast first load times and even faster repeat views to a web page. Whilst this technique is really effective, it\u2019s worth noting that HTTP/2 push is not a magic bullet. Think about the situations where it might make sense to use it and don\u2019t just simply \u201cpush\u201d everything; it could actually lead to having slower page load times. If you\u2019d like to learn more about the rules of thumb for HTTP/2 Server Push, I recommend reading this article for more information. \nAll of the code in this example is available on my Github repo - if you have any questions, please submit an issue and I\u2019ll get back to you as soon as possible. \nIf you\u2019d like to learn more about this technique and others relating to HTTP/2, I highly recommend watching Sam Saccone\u2019s talk at this years Chrome Developer Summit. \nI\u2019d also like to say a massive thank you to Robin Osborne, Andy Davies and Jeffrey Posnick for helping me review this article before putting it live!", "year": "2016", "author": "Dean Hume", "author_slug": "deanhume", "published": "2016-12-15T00:00:00+00:00", "url": "https://24ways.org/2016/http2-server-push-and-service-workers/", "topic": "code"}
{"rowid": 207, "title": "Want to Break Out of Comparison Syndrome? Do a Media Detox", "contents": "\u201cComparison is the thief of joy.\u201d\n\u2014Theodore Roosevelt\n\nI grew up in an environment of perpetual creativity and inventiveness. My father Dennis built and flew experimental aircraft as a hobby. During my entire childhood, there was an airplane fuselage in the garage instead of a car. My mother Deloria was a self-taught master artisan who could quickly acquire any skills that it took to work with fabric and weaving. She could sew any garment she desired, and was able to weave intricate wall hangings just by looking at a black and white photos in magazines. My older sister Diane blossomed into a consummate fine artist who drew portraits with uncanny likeness, painted murals, and studied art and architecture. In addition, she loved good food and had a genius for cooking and baking, which converged in her creating remarkable art pieces out of cake that were incredibly delicious to boot. Yes. This was the household in which I grew up.\nWhile there were countless positives to being surrounded by people who were compelled to create, there was also a downside to it. I incessantly compared myself to my parents and older sister and always found myself lacking.\nIt wasn\u2019t a fair comparison, but tell that to a sensitive kid who wanted to fit in to her family by being creative as well. From my early years throughout my teens, I convinced myself that I would never understand how to build an airplane or at least be as proficient with tools as my father, the aeronautical engineer. Even though my sister was six years older than I was, I lamented that I would never be as good a visual artist as she was. And I marveled at my mother\u2019s seemingly magical ability to make and tailor clothes and was certain that I would never attain her level of mastery.\nThis habit of comparing myself to others grew over the years, continuing to subtly and effectively undermine my sense of self. I had almost reached an uneasy truce with my comparison habit when social media happened.\nAs an early adopter of Twitter, I loved staying connected to people I met at tech conferences. However, as I began to realize my aspirations of being an author and a speaker, Twitter became a dreaded hall of mirrors where I only saw distorted reflections of my lack of achievement in other people\u2019s success. Every person announcing a publishing deal caused me to drown under waves of envy over the imagined size of her or his book advance as I struggled to pay my mortgage. Every announcement I read of someone speaking at a conference led to thoughts of, \u201cI wish I were speaking at that conference \u2013 I must not be good enough to be invited.\u201d Twitter was fertile ground for my Inner Critic to run rampant.\nOne day in 2011, my comparisons to people who I didn\u2019t even know rose to a fever pitch. I saw a series of tweets that sparked a wave of self-loathing so profound that I spent the day sobbing and despondent, as I chastised myself for being a failure. I had fallen into the deep pit of Comparison Syndrome, and to return to anything close to being productive took a day or two of painstakingly clawing my way out.\nComparison Syndrome Takes Deficiency Anxiety to Eleven\nDo any of these scenarios ring true?\n\nYou frequently feel like a failure when viewing the success of others.\nYou feel dispirited and paralyzed in moving forward with your own work because it will never measure up to what others have done.\nYou discount your ideas because you fear that they aren\u2019t as good as those of your colleagues or industry peers.\n\nAre you making yourself miserable by thinking thoughts like these?\n\n\u201cI\u2019m surrounded by people who are so good at what they do, how can I possibly measure up?\u201d\n\u201cCompared to my partner, my musical ability is childish \u2013 and music is no longer fun.\u201d\n\u201cWhy haven\u2019t I accomplished more by now? My peers are so much more successful than I am.\u201d\n\nUnenviable Envy\nMany people use the terms envy and jealousy interchangeably, but they are two distinct emotions. Jealousy is the fear of losing someone to a perceived rival: a threat to an important relationship and the parts of the self that are served by that relationship. Jealousy is always about the relationship between three people. Envy is wanting what another has because of a perceived shortcoming on your part. Envy is always based on a social comparison to another.1\nEnvy is a reaction to the feeling of lacking something. Envy always reflects something we feel about ourselves, about how we are somehow deficient in qualities, possessions, or success.2 It\u2019s based on a scarcity mentality: the idea that there is only so much to go around, and another person got something that should rightfully be yours.3\nA syndrome is a condition characterized by a set of associated symptoms. I call it Comparison Syndrome because a perceived deficiency of some sort \u2013 in talent, accomplishments, success, skills, etc. \u2013 is what initially sparks it. While at the beginning you may merely feel inadequate, the onset of the syndrome will bring additional symptoms. Lack of self-trust and feelings of low self-worth will fuel increased thoughts of not-enoughness and blindness to your unique brilliance. If left unchecked, Deficiency Anxieties can escalate to full-blown Comparison Syndrome: a form of the Inner Critic in which we experience despair from envy and define ourselves as failures in light of another\u2019s success.\nThe irony is that when we focus so much on what we lack, we can\u2019t see what we have in abundance that the other person doesn\u2019t have. And in doing so, we block what is our birthright: our creative expression. Envy shackles our creativity, keeps us trapped in place, and prevents forward movement. The Inner Critic in the form of Comparison Syndrome caused by envy blocks us from utilizing our gifts, seeing our path clearly, and reveling in our creative power.\nIn order to keep a grip on reality and not fall into the abyss of Comparison Syndrome, we\u2019ll quell the compulsion to compare before it happens: we will free the mental bandwidth to turn our focus inward so we can start to see ourselves clearly. \nBreak the Compulsion to Compare\n\n\u201cWhy compare yourself with others? No one in the entire world can do a better job of being you than you.\u201d\n\u2014 Krystal Volney, poet and author\n\nAt some point in time, many of us succumb to moments of feeling that we are lacking and comparing ourselves unfavorably to others. As social animals, much of our self-definition comes from comparison with others. This is how our personalities develop. We learn this behavior as children, and we grow up being compared to siblings, peers, and kids in the media. Because of this, the belief that somehow, someway, we aren\u2019t good enough becomes deeply ingrained. The problem is that whenever we deem ourselves to be \u201cless than,\u201d our self-esteem suffers. This creates a negative feedback loop where negative thoughts produce strong emotions that result in self-defeating behaviors that beget more negative thoughts.\nCouple this cycle with the messages we get from society that only \u201cgifted\u201d people are creative, and it\u2019s no wonder that many of us will fall down the rabbit hole of Comparison Syndrome like I did on that fated day while reading tweets. Comparing ourselves to others is worse than a zero-sum game, it\u2019s a negative-sum game. No one wins, our self-esteem deteriorates, and our creative spark dies out.\nWith effort, we can break the compulsion to compare and stop the decline into Comparison Syndrome by turning the focus of comparison inward to ourselves and appreciating who we\u2019ve become. But first, we need to remove some of the instances that trigger our comparisons in the first place.\nArrest: Stop the Triggers\n\n\u201cRight discipline consists, not in external compulsion, but in the habits of mind which lead spontaneously to desirable rather than undesirable activities.\u201d\n\u2014 Bertrand Russell, philosopher\n\nAfter my Twitter post meltdown, I knew had to make a change. While bolstering my sense of self was clearly a priority, I also knew that my ingrained comparison habit was too strong to resist and that I needed to instill discipline. I decided then and there to establish boundaries with social media.\nFirst, to maintain my sanity, I took this on as my mantra:\n\u201cI will not compare myself to strangers on the Internet or acquaintances on Facebook.\u201d\nIf you find yourself sliding down the slippery slope of social media comparison, you can do the same: repeat this mantra to yourself to help put on the brakes.\nSecond, in order to reduce my triggers, I stopped reading the tweets of the people I followed. However, I continued to be active on Twitter through sharing information, responding to mentions, crowdsourcing, and direct messaging people. It worked! The only time I\u2019d start to slip into darkness were the rare instances when I would break my rules and look at my Twitstream.\nBut we can do even more than calm ourselves with helpful mantras. Just like my example of modifying my use of Twitter, and more recently, of separating myself from Facebook, you can get some distance from the media that activates your comparison reflex and start creating the space for other habits that are more supportive to your being to take its place.\nCreative Dose: Trigger-free and Happy\nPurpose: To stop comparison triggers in their tracks\nMindfulness is a wonderful tool, but sometimes you have to get hardcore and do as much as you can to eliminate distractions so that you can first hear your own thoughts in order to know which ones you need to focus on.\nHere are four steps to becoming trigger-free and happier.\nStep 1: Make a List\nPay attention when you get the most triggered and hooked.\nIs it on Twitter, Facebook, Instagram, or Snapchat?\nIs it YouTube, TV shows, or magazines?\nMake list of your top triggers.\nMy primary trigger is:______________________________________\nMy second trigger is:______________________________________\nMy third trigger is:______________________________________\nNow that you have your list, you need to get an idea just how often you\u2019re getting triggered.\nStep 2: Monitor\nIt\u2019s easy to think that we should track our activity on the computer, but these days, it\u2019s no longer our computer use that is the culprit: most of us access social media and news from our phones. Fortunately, there are apps that will track the usage for both.\nSeeing just how much you consume media from either or both will show you how much of an accomplice the use of devices is to your comparison syndrome, and how much you need to modify your behavior accordingly.\nFor tracking both computer use and tablet use, this app works great:\n\nRescueTime.com tracks app usage and sends a productivity report at the end of the week via email.\n\nFor your phone, there are many for either platform.4 Although I recommend fully researching what is available and will work for you best, here are a few recommendations:\n\nFor both platforms: Offtime, Breakfree, Checky\nFor Android only: Flipd, AppDetox, QualityTime, Stay On Task\nFor iOS only: Moment\n\nInstall your app of choice, and see what you find. How much time are you spending on sites or apps that compel you to compare?\nStep 3: Just Say No\nNow that you know what your triggers are and how much you\u2019re exposing yourself to them, it\u2019s time to say No.\nPut yourself on a partial social media and/or media detox for a specified period of time; consider even going for a full media detox.5 I recommend starting with one month.\nTo help you to fully commit, I recommend writing this down and posting it where you can see it.\nI, ___________________, commit to avoiding my comparison triggers \nof ___________________, ___________________, and ___________________ \nfor the period of ___________________, \nstarting on ___________________ and ending on ___________________ .\nTo help you out, I\u2019ve created a social media detox commitment sheet for you.\nStep 4: Block\nWhen I decided to reduce my use of Twitter and Facebook to break my comparison habit, initially I tried to rely solely on self-discipline, which was only moderately successful. Then I realized that I could use the power of technology to help. Don\u2019t think you have to rely upon sheer willpower to block, or at least limit, your exposure to known triggers. If your primary access to the items that cause you to compare yourself to others is via computers and other digitalia, use these devices to help maintain your mental equilibrium.\nHere are some apps and browser extensions that you can use during your media detox to help keep yourself sane and stay away from sites that could throw you into a comparison tailspin.\nThese apps are installed onto your computer:\n\nRescueTime.com works on both computer and mobile devices, and does a lot more than just prevent you from going to sites that will ruin your concentration, it will also track your apps usage and give you a productivity report at the end of the week.\nFocus and SelfControl (Mac-only)\n\nTo go right to the source and prevent you from visiting sites through your browser, there are browser extensions.\nNot only can you put in the list of the URLs that are your points of weakness, but you can also usually set the times of the day you need the self-control the most.\n\nGoogle Chrome: StayFocusd, Strict Workflow, and Website Blocker\nFirefox: Idderall and Leechblock\nSafari: WasteNoTime and MindfulBrowsing\nEdge (or Explorer): Unfortunately, there are currently no website blocking extensions for these browsers.\n\nI currently use a browser extension to block me from using Facebook between 9:00am \u2013 6:00pm. It\u2019s been a boon for my sanity: I compare tons less. A bonus is that it\u2019s been terrific for my productivity as well. \nWhich tool will you use for your media detox time? Explore them all and then settle upon the one(s) that will work the best for you. Install it and put it to work.\nDespite the tool, you will still need to exercise discipline. Resist the urge to browse Instagram or Facebook while waiting for your morning train. You can do it!\nStep 5: Relax\nInstead of panicking from FOMO (Fear of Missing Out), take comfort from this thought: what you don\u2019t know won\u2019t affect you. Start embracing JOMO (Joy of Missing Out), and the process of rebuilding and maintaining your sanity.\nWhat will you do instead of consuming the media that compels you to\ncompare? Here are some ideas:\n\nRead a book \nGo for a walk \nHave dinner with a friend \nGo watch a movie \nLearn how to play the harmonica \nTake an improv class\n\nReally, you could do anything. And depending on how much of your time and attention you\u2019ve devoted to media, you could be recapturing a lot of lost moments, minutes, hours, and days.\nStep 6: Reconnect\nUse your recovered time and attention to focus on your life and reconnect with your true value-driven goals, higher aspirations, and activities that you\u2019ve always wanted to do.\n\nThis article is an excerpt from the book Banish Your Inner Critic by Denise Jacobs, and has been reprinted with permission. If you\u2019d like to read more, you can find the book on Amazon.\n\n\n\n\nShane Parrish, \u201cMental Model: Bias from Envy and Jealousy,\u201d Farnam Street, accessed February 9, 2017.\u00a0\u21a9\n\n\nParrish, \u201cMental Model: Bias from Envy and Jealousy.\u201d\u00a0\u21a9\n\n\nHenrik Edberg, \u201cHow to Overcome Envy: 5 Effective Tips,\u201d Practical Happiness Advice That Works | The Positivity Blog, accessed February 9, 2017.\u00a0\u21a9\n\n\nJeremy Golden, \u201c6 Apps to Stop Your Smartphone Addiction,\u201d Inc.com, accessed February 10, 2017.\u00a0\u21a9\n\n\nEmily Nickerson, \u201cHow to Silence the Voice of Doubt,\u201d The Muse, accessed February 8, 2017.\u00a0\u21a9", "year": "2017", "author": "Denise Jacobs", "author_slug": "denisejacobs", "published": "2017-12-19T00:00:00+00:00", "url": "https://24ways.org/2017/do-a-media-detox/", "topic": "process"}
{"rowid": 135, "title": "A Scripting Carol", "contents": "We all know the stories of the Ghost of Scripting Past \u2013 a time when the web was young and littered with nefarious scripting, designed to bestow ultimate control upon the developer, to pollute markup with event handler after event handler, and to entrench advertising in the minds of all that gazed upon her.\n\nAnd so it came to be that JavaScript became a dirty word, thrown out of solutions by many a Scrooge without regard to the enhancements that JavaScript could bring to any web page. JavaScript, as it was, was dead as a door-nail.\n\nWith the arrival of our core philosophy that all standardistas hold to be true: \u201cseparate your concerns \u2013 content, presentation and behaviour,\u201d we are in a new era of responsible development the Web Standards Way\u2122. Or are we? Have we learned from the Ghosts of Scripting Past? Or are we now faced with new problems that come with new ways of implementing our solutions?\n\nThe Ghost of Scripting Past\n\nIf the Ghost of Scripting Past were with us it would probably say: \n\n\n\tYou must remember your roots and where you came from, and realize the misguided nature of your early attempts for control. That person you see down there, is real and they are the reason you exist in the first place\u2026 without them, you are nothing.\n\n\nIn many ways we\u2019ve moved beyond the era of control and we do take into account the user, or at least much more so than we used to. Sadly \u2013 there is one advantage that old school inline event handlers had where we assigned and reassigned CSS style property values on the fly \u2013 we knew that if JavaScript wasn\u2019t supported, the styles wouldn\u2019t be added because we ended up doing them at the same time.\n\nIf anything, we need to have learned from the past that just because it works for us doesn\u2019t mean it is going to work for anyone else \u2013 we need to test more scenarios than ever to observe the multitude of browsing arrangements we\u2019ll observe: CSS on with JavaScript off, CSS off/overridden with JavaScript on, both on, both off/not supported. It is a situation that is ripe for conflict.\n\nThis may shock some of you, but there was a time when testing was actually easier: back in the day when Netscape 4 was king. Yes, that\u2019s right. I actually kind of enjoyed Netscape 4 (hear me out, please). With NS4\u2019s CSS implementation known as JavaScript Style Sheets, you knew that if JavaScript was off the styles were off too.\n\nThe Ghost of Scripting Present\n\nWith current best practice \u2013 we keep our CSS and JavaScript separate from each other. So what happens when some of our fancy, unobtrusive DOM Scripting doesn\u2019t play nicely with our wonderfully defined style rules?\n\nLets look at one example of a collapsing and expanding menu to illustrate where we are now:\n\nSimple Collapsing/Expanding Menu Example\n\nWe\u2019re using some simple JavaScript (I\u2019m using jquery in this case) to toggle between a CSS state for expanded and not expanded:\n\nJavaScript\n\n$(document).ready(function(){\n\tTWOFOURWAYS.enableTree();\n});\nvar TWOFOURWAYS = new Object();\nTWOFOURWAYS.enableTree = function ()\n{\n\t$(\"ul li a\").toggle(function(){\n\t\t$(this.parentNode).addClass(\"expanded\");\n\t}, function() {\n\t\t$(this.parentNode).removeClass(\"expanded\");\n\t});\n\treturn false;\t\n}\n\nCSS\n\nul li ul {\n\tdisplay: none;\n}\nul li.expanded ul {\n\tdisplay: block;\n}\n\nAt this point we\u2019ve separated our presentation from our content and behaviour, and all is well, right?\n\nNot quite.\n\nHere\u2019s where I typically see failures in the assessment work that I do on web sites and applications (Yes, call me Scrooge \u2013 I don\u2019t care!). We know our page needs to work with or without scripting, and we know it needs to work with or without CSS. All too often the testing scenarios don\u2019t take into account combinations.\n\nTesting it out\n\nSo what happens when we test this? Make sure you test with:\n\n\n\tCSS off\n\tJavaScript off\n\n\nUse the simple example again.\n\nWith CSS off, we revert to a simple nested list of links and all functionality is maintained. With JavaScript off, however, we run into a problem \u2013 we have now removed the ability to expand the menu using the JavaScript triggered CSS change.\n\nHopefully you see the problem \u2013 we have a JavaScript and CSS dependency that is critical to the functionality of the page. Unobtrusive scripting and binary on/off tests aren\u2019t enough. We need more.\n\nThis Ghost of Scripting Present sighting is seen all too often.\n\nLets examine the JavaScript off scenario a bit further \u2013 if we require JavaScript to expand/show the branch of the tree we should use JavaScript to hide them in the first place. That way we guarantee functionality in all scenarios, and have achieved our baseline level of interoperability. \n\nTo revise this then, we\u2019ll start with the sub items expanded, use JavaScript to collapse them, and then use the same JavaScript to expand them.\n\nHTML\n\n<ul>\n\t<li><a href=\"#\">Main Item</a>\n\t\t<ul class=\"collapseme\">\n\t\t\t<li><a href=\"#\">Sub item 1</a></li>\n\t\t\t<li><a href=\"#\">Sub item 2</a></li>\n\t\t\t<li><a href=\"#\">Sub item 3</a></li>\n\t\t</ul>\n\t</li>\n</ul>\n\nCSS\n\n/* initial style is expanded */\nul li ul.collapseme {\n\tdisplay: block;\n}\n\nJavaScript\n\n// remove the class collapseme after the page loads\n$(\"ul ul.collapseme\").removeClass(\"collapseme\");\n\nAnd there you have it \u2013 a revised example with better interoperability.\n\nThis isn\u2019t rocket surgery by any means. It is a simple solution to a ghostly problem that is too easily overlooked (and often is).\n\nThe Ghost of Scripting Future\n\nWell, I\u2019m not so sure about this one, but I\u2019m guessing that in a few years\u2019 time, we\u2019ll all have seen a few more apparitions and have a few more tales to tell. And hopefully we\u2019ll be able to share them on 24 ways.\n\nThanks to Drew for the invitation to contribute and thanks to everyone else out there for making this a great (and haunting) year on the web!", "year": "2006", "author": "Derek Featherstone", "author_slug": "derekfeatherstone", "published": "2006-12-21T00:00:00+00:00", "url": "https://24ways.org/2006/a-scripting-carol/", "topic": "code"}
{"rowid": 335, "title": "Naughty or Nice? CSS Background Images", "contents": "Web Standards based development involves many things \u2013 using semantically sound HTML to provide structure to our documents or web applications, using CSS for presentation and layout, using JavaScript responsibly, and of course, ensuring that all that we do is accessible and interoperable to as many people and user agents as we can.\n\nThis we understand to be good. \n\nAnd it is good. \n\nExcept when we don\u2019t clearly think through the full implications of using those techniques.\n\nWhich often happens when time is short and we need to get things done.\n\nHere are some naughty examples of CSS background images with their nicer, more accessible counterparts.\n\nTransaction related messages\n\nI\u2019m as guilty of this as others (or, perhaps, I\u2019m the only one that has done this, in which case this can serve as my holiday season confessional)  We use lovely little icons to show status messages for a transaction to indicate if the action was successful, or was there a warning or error? For example:\n\n\u201cYour postal/zip code was not in the correct format.\u201d\n\nNotice that we place a nice little icon there, and use background colours and borders to convey a specific message: there was a problem that needs to be fixed. Notice that all of this visual information is now contained in the CSS rules for that div:\n\n<div class=\"error\">\n     <p>Your postal/zip code was not in the correct format.</p>\n </div>\n\n div.error {\n     background: #ffcccc url(../images/error_small.png) no-repeat 5px 4px;\n     color: #900;\n     border-top: 1px solid #c00;\n     border-bottom: 1px solid #c00;\n     padding: 0.25em 0.5em 0.25em 2.5em;\n     font-weight: bold;\n }\n\nUsing this approach also makes it very easy to create a div.success and div.warning CSS rules meaning we have less to change in our HTML.\n\nNice, right?\n\nNo. Naughty. \n\nVisual design communicates\n\nThe CSS is being used to convey very specific information. The choice of icon, the choice of background colour and borders tell us visually that there is something wrong. \n\nWith the icon as a background image \u2013 there is no way to specify any alt text for the icon, and significant meaning is lost. A screen reader user, for example, misses the fact that it is an \u201cerror.\u201d \n\nThe solution? Ask yourself: what is the bare minimum needed to indicate there was an error? Currently in the absence of CSS there will be no icon \u2013 which (I\u2019m hoping you agree) is critical to communicating there was an error.\n\nThe icon should be considered content and not simply presentational.\n\nThe borders and background colour are certainly much less critical \u2013 they belong in the CSS.\n\nLets change the code to place the image directly in the HTML and using appropriate alt text to better communicate the meaning of the icon to all users:\n\n<div class=\"bettererror\">\n     <img src=\"images/error_small.png\" alt=\"Error\" />\n     <p>Your postal/zip code was not in the correct format.</p>\n </div>\n\n div.bettererror {\n     background-color: #ffcccc;\n     color: #900;\n     border-top: 1px solid #c00;\n     border-bottom: 1px solid #c00;\n     padding: 0.25em 0.5em 0.25em 2.5em;\n     font-weight: bold;\n     position: relative;\n     min-height: 1.25em;\n }\n\n div.bettererror img {\n     display: block;\n     position: absolute;\n     left: 0.25em;\n     top: 0.25em;\n     padding: 0;\n     margin: 0;\n }\n\n div.bettererror p {\n     position: absolute;\n     left: 2.5em;\n     padding: 0;\n     margin: 0;\n }\n\nCompare these two examples of transactional messages\n\nStatus of a Record\n\nThis example is pretty straightforward. Consider the following: a real estate listing on a web site. There are three \u201cstates\u201d for a listing: new, normal, and sold. Here\u2019s how they look:\n\nExample of a New Listing\n\nExample of A Sold Listing\n\nIf we (forgive the pun) blindly apply the \u201cuse a CSS background image\u201d technique we clearly run into problems with the new and sold images \u2013 they actually contain content with no way to specify an alternative when placed in the CSS.\n\nIn this case of the \u201cnew\u201d image, we can use the same strategy as we used in the first example (the transaction result). The \u201cnew\u201d image should be considered content and is placed in the HTML as part of the <h2>...</h2> that identifies the listing.\n\nHowever when considering the \u201csold\u201d listing, there are less changes to be made to keep the same look by leaving the \u201cSOLD\u201d image as a background image and providing the equivalent information elsewhere in the listing \u2013 namely, right in the heading.\n\nFor those that can\u2019t see the background image, the status is communicated clearly and right away. A screen reader user that is navigating by heading or viewing a listing will know right away that a particular property is sold.\n\nOf note here is that in both cases (new and sold) placing the status near the beginning of the record helps with a zoom layout as well.\n\nBetter Example of A Sold Listing\n\nSummary\n\nRemember: in the holiday season, its what you give that counts!! Using CSS background images is easy and saves time for you but think of the children. And everyone else for that matter\u2026 \n\nCSS background images should only be used for presentational images, not for those that contain content (unless that content is already represented and readily available elsewhere).", "year": "2005", "author": "Derek Featherstone", "author_slug": "derekfeatherstone", "published": "2005-12-20T00:00:00+00:00", "url": "https://24ways.org/2005/naughty-or-nice-css-background-images/", "topic": "code"}
{"rowid": 59, "title": "Animating Your Brand", "contents": "Let\u2019s talk about how we add animation to our designs, in a way that\u2019s consistent with other aspects of our brand, such as fonts, colours, layouts and everything else.\nAnimating is fun. Adding animation to our designs can bring them to life and make our designs stand out. Animations can show how the pieces of our designs fit together. They provide context and help people use our products.\nAll too often animation is something we tack on at the end. We put a transition on a modal window or sliding menu and we often don\u2019t think about whether that animation is consistent with our overall design.\nStyle guides to the rescue\nA style guide is a document that establishes and enforces style to improve communication. It can cover anything from typography and writing style to ethics and other, broader goals. It might be a static visual document showing every kind of UI, like in the Codecademy.com redesign shown below.\nUI toolkit from \u201cReimagining Codecademy.com\u201d by @mslima\nIt might be a technical reference with code examples. CodePen\u2019s new design patterns and style guide is a great example of this, showing all the components used throughout the website as live code.\nCodePen\u2019s design patterns and style guide\nA style guide gives a wide view of your project, it maintains consistency when adding new content, and we can use our style guide to present animations.\nLiving documents\nStyle guides don\u2019t need to be static. We can use them to show movement. We can share CSS keyframe animations or transitions that can then go into production. We can also explain why animation is there in the first place.\nJust as a style guide might explain why we chose a certain font or layout, we can use style guides to explain the intent behind animation. This means that if someone else wants to create a new component, they will know why animation applies.\nIf you haven\u2019t yet set up a style guide, you might want to take a look at Pattern Lab. It\u2019s a great tool for setting up your own style guide and includes loads of design patterns to get started.\nThere are many style guide articles linked from the excellent, open sourced, Website Style Guide Resources. Anna Debenham also has an excellent pocket book on the subject.\nAdding animation\nBefore you begin throwing animation at all the things, establish the character you want to convey.\nAndrex Puppy (British TV ad from 1994)\nList some words that describe the character you\u2019re aiming for. If it was the Andrex brand, they might have gone for: fun, playful, soft, comforting.\nPerhaps you\u2019re aiming for something more serious, credible and authoritative. Or maybe exciting and intense, or relaxing and meditative. For each scenario, the animations that best represent these words will be different.\nIn the example below, two animations both take the same length of time, but use different timing functions. One eases, and the other bounces around. Either might be good, depending on your needs.\nTiming functions (CodePen)\nExample: Kitman Labs\nWorking with Kitman Labs, we spent a little time working out what words best reflected the brand and came up with the following:\n\nScientific\nPrecise\nFast\nSolid\nDependable\nHelpful\nConsistent\nClear\n\nWith such a list of words in hand, we design animation that fits. We might prefer a tween that moves quickly to its destination over one that drifts slowly or bounces.\nWe can use the list when justifying our use of animation, such as when it helps our customers understand the context of data on the page. Or we may even choose not to animate, when that might make the message inconsistent.\nCreate guidelines\nIf you already have a style guide, adding animation could begin with creating an overview section.\nOne approach is to create a local website and share it within your organisation. We recently set up a local site for this purpose. \nA recent project\u2019s introduction to the topic of animation\nThis document becomes a reference when adding animation to components. Include links to related resources or examples of animation to help demonstrate the animation style you want.\nPrototyping\nYou can explain the intent of your animation style guide with live animations. This doesn\u2019t just mean waving our hands around. We can show animation through prototypes.\nThere are so many prototype tools right now. You could use Invision, Principle, Floid, or even HTML and CSS as embedded CodePens.\nA login flow prototype created in Principle\nThese tools help when trying out ideas and working through several approaches. Create videos, animated GIFs or online demos to share with others. Experiment. Find what works for you and work with whatever lets you get the most ideas out of your head fastest. Iterate and refine an animation before it gets anywhere near production.\nBuild up a collection\nBuild up your guide, one animation at a time.\nSome people prefer to loosely structure a guide with places to put things as they are discovered or invented; others might build it one page at a time \u2013 it doesn\u2019t matter. The main thing is that you collect animations like you would trading cards. Or Pokemon. Keep them ready to play and deliver that explosive result.\nYou could include animated GIFs, or link to videos or even live webpages as examples of animation. The use of animation to help user experience is also covered nicely in Val Head\u2019s UI animation and UX article on A List Apart.\nWhat matters is that you create an organised place for them to be found. Here are some ideas to get started.\nLogos and brandmarks\nMany sites include some subtle form of animation in their logos. This can draw the eye, add some character, or bring a little liveliness to an otherwise static page. Yahoo and Google have been experimenting with animation on their logos. Even a simple bouncing animation, such as the logo on Hop.ie, can add character.\nThe CSS-animated bouncer from Hop.ie\nContent transitions\nAdding content, removing content, showing and hiding messages are all opportunities to use animation. Careful and deliberate use of animation helps convey what\u2019s changing on screen.\nAnimating list items with CSS (CSSAnimation.rocks)\nFor more detail on this, I also recommend \u201cTransitional Interfaces\u201d by Pasquale D\u2019Silva.\nPage transitions\nOn a larger scale than the changes to content, full-page transitions can smooth the flow between sections of a site. Medium\u2019s article transitions are a good example of this.\nMedium-style page transition (Tympanus.net)\nPreparing a layout before the content arrives\nWe can use animation to draw a page before the content is ready, such as when a page calls a server for data before showing it.\nOptimistic loading grid (CodePen)\nSometimes it\u2019s good to show something to let the user know that everything\u2019s going well. A short animation could cover just enough time to load the initial content and make the loading transition feel seamless.\nInteractions\nHover effects, dropdown menus, slide-in menus and active states on buttons and forms are all opportunities. Look for ways you can remove the sudden changes and help make the experience of using your UI feel smoother.\nForm placeholder animation (Studio MDS)\nKeep animation visible\nIt takes continuous effort to maintain a style guide and keep it up to date, but it\u2019s worth it. Make it easy to include animation and related design decisions in your documentation and you\u2019ll be more likely to do so. If you can make it fun, and be proud of the result, better still.\nWhen updating your style guide, be sure to show the animations at the same time. This might mean animated GIFs, videos or live embedded examples of your components.\nBy doing this you can make animation integral to your design process and make sure it stays relevant.\nInspiration and resources\nThere are loads of great resources online to help you get started. One of my favourites is IBM\u2019s design language site.\nIBM\u2019s design language:\u200aanimation design guidelines\nIBM describes how animation principles apply to its UI work and components. They break down the animations into five categories of animations and explain how they apply to each example.\nThe site also includes an animation library with example videos of animations and links to source code.\nExample component from IBM\u2019s component library\nThe way IBM sets out its aims and methods is helpful not only for their existing designers and developers, but also helps new hires. Furthermore, it\u2019s a good way to show the world that IBM cares about these details.\nAnother popular animation resource is Google\u2019s material design.\nGoogle\u2019s material design documentation\nGoogle\u2019s guidelines cover everything from understanding easing through to creating engaging and useful mobile UI.\nThis approach is visible across many of Google\u2019s apps and software, and has influenced design across much of the web. The site is helpful both for learning about animation and as an showcase of how to illustrate examples.\nFrameworks\nIf you don\u2019t want to create everything from scratch, there are resources you can use to start using animation in your UI. One such resource is Salesforce\u2019s Lightning design system.\nThe system goes further than most guides. It includes a downloadable framework for adding animation to your projects. It has some interesting concepts, such as elevation settings to handle positioning on the z-axis.\nExample of elevation from Salesforce\u2019s Lightning design system\nYou should also check out Animate.css.\n\u201cJust add water\u201d\u200a\u2014\u200aAnimate.css\nAnimate.css gives you a set of predesigned animations you can apply to page elements using classes. If you use JavaScript to add or remove classes, you can then trigger complex animations. It also plays well with scroll-triggering, and tools such as WOW.js.\nLearn, evolve and make it your own\nThere\u2019s a wealth online of information and guides we can use to better understand animation. They can inspire and kick-start our own visual and animation styles. So let\u2019s think of the design of animations just as we do fonts, colours and layouts. Let\u2019s choose animation deliberately, making it part of our style guides.\nMany thanks to Val Head for taking the time to proofread and offer great suggestions for this article.", "year": "2015", "author": "Donovan Hutchinson", "author_slug": "donovanhutchinson", "published": "2015-12-01T00:00:00+00:00", "url": "https://24ways.org/2015/animating-your-brand/", "topic": "design"}
{"rowid": 16, "title": "URL Rewriting for the Fearful", "contents": "I think it was Marilyn Monroe who said, \u201cIf you can\u2019t handle me at my worst, please just fix these rewrite rules, I\u2019m getting an internal server error.\u201d Even the blonde bombshell hated configuring URL rewrites on her website, and I think most of us know where she was coming from.\n\nThe majority of website projects I work on require some amount of URL rewriting, and I find it mildly enjoyable \u2014 I quite like a good rewrite rule. I suspect you may not share my glee, so in this article we\u2019re going to go back to basics to try to make the whole rigmarole more understandable.\n\nWhen we think about URL rewriting, usually that means adding some rules to an .htaccess file for an Apache web server. As that\u2019s the most common case, that\u2019s what I\u2019ll be sticking to here. If you work with a different server, there\u2019s often documentation specifically for translating from Apache\u2019s mod_rewrite rules. I even found an automatic converter for nginx.\n\nThis isn\u2019t going to be a comprehensive guide to every URL rewriting problem you might ever have. That would take us until Christmas. If you consider yourself a trial-and-error dabbler in the HTTP 500-infested waters of URL rewriting, then hopefully this will provide a little bit more of a basis to help you figure out what you\u2019re doing. If you\u2019ve ever found yourself staring at the white screen of death after screwing up your .htaccess file, don\u2019t worry. As Michael Jackson once insipidly whined, you are not alone.\n\nThe basics\n\nRewrite rules form part of the Apache web server\u2019s configuration for a website, and can be placed in a number of different locations as part of your virtual host configuration. By far the simplest and most portable option is to use an .htaccess file in your website root. Provided your server has mod_rewrite available, all you need to do to kick things off in your .htaccess file is:\n\nRewriteEngine on\n\nThe general formula for a rewrite rule is:\n\nRewriteRule URL/to/match URL/to/use/if/it/matches [options]\n\nWhen we talk about URL rewriting, we\u2019re normally talking about one of two things: redirecting the browser to a different URL; or rewriting the URL internally to use a particular file. We\u2019ll look at those in turn.\n\nRedirects\n\nRedirects match an incoming URL, and then redirect the user\u2019s browser to a different address. These can be useful for maintaining legacy URLs if content changes location as part of a site redesign. Redirecting the old URL to the new location makes sure that any incoming links, such as those from search engines, continue to work. \n\nIn 1998, Sir Tim Berners-Lee wrote that Cool URIs don\u2019t change, encouraging us all to go the extra mile to make sure links keep working forever. I think that sometimes it\u2019s fine to move things around \u2014 especially to correct bad URL design choices of the past \u2014 provided that you can do so while keeping those old URLs working. That\u2019s where redirects can help.\n\nA redirect might look like this\n\nRewriteRule ^article/used/to/be/here.php$ /article/now/lives/here/ [R=301,L]\n\nRewriting\n\nBy default, web servers closely map page URLs to the files in your site. On receiving a request for http://example.com/about/history.html the server goes to the configured folder for the example.com website, and then goes into the about folder and returns the history.html file.\n\nA rewrite rule changes that process by breaking the direct relationship between the URL and the file system. \u201cWhen there\u2019s a request for /about/history.html\u201d a rewrite rule might say, \u201cuse the file /about_section.php instead.\u201d\n\nThis opens up lots of possibilities for creative ways to map URLs to the files that know how to serve up the page. Most MVC frameworks will have a single rule to rewrite all page URLs to one single file. That file will be a script which kicks off the framework to figure out what to do to serve the page.\n\nRewriteRule ^for/this/url/$ /use/this/file.php [L] \n\nMatching patterns\n\nBy now you\u2019ll have noted the weird ^ and $ characters wrapped around the URL we\u2019re trying to match. That\u2019s because what we\u2019re actually using here is a pattern. Technically, it is what\u2019s called a Perl Compatible Regular Expression (PCRE) or simply a regex or regexp. We\u2019ll call it a pattern because we\u2019re not animals.\n\nWhat are these patterns? If I asked you to enter your credit card expiry date as MM/YY then chances are you\u2019d wonder what I wanted your credit card details for, but you\u2019d know that I wanted a two-digit month, a slash, and a two-digit year. That\u2019s not a regular expression, but it\u2019s the same idea: using some placeholder characters to define the pattern of the input you\u2019re trying to match.\n\nWe\u2019ve already met two regexp characters.\n\n\n\t^\n\tMatches the beginning of a string\n\t$\n\tMatches the end of a string\n\n\nWhen a pattern starts with ^ and ends with $ it\u2019s to make sure we match the complete URL start to finish, not just part of it. There are lots of other ways to match, too:\n\n\n\t[0-9]\n\tMatches a number, 0\u20139. [2-4] would match numbers 2 to 4 inclusive.\n\t[a-z]\n\tMatches lowercase letters a\u2013z\n\t[A-Z]\n\tMatches uppercase letters A\u2013Z\n\t[a-z0-9]\n\tCombining some of these, this matches letters a\u2013z and numbers 0\u20139\n\n\nThese are what we call character groups. The square brackets basically tell the server to match from the selection of characters within them. You can put any specific characters you\u2019re looking for within the brackets, as well as the ranges shown above. \n\nHowever, all these just match one single character. [0-9] would match 8 but not 84 \u2014 to match 84 we\u2019d need to use [0-9] twice.\n\n[0-9][0-9]\n\nSo, if we wanted to match 1984 we could to do this:\n\n[0-9][0-9][0-9][0-9] \n\n\u2026but that\u2019s getting silly. Instead, we can do this:\n\n[0-9]{4}\n\nThat means any character between 0 and 9, four times. If we wanted to match a number, but didn\u2019t know how long it might be (for example, a database ID in the URL) we could use the + symbol, which means one or more.\n\n[0-9]+\n\nThis now matches 1, 123 and 1234567.\n\nPutting it into practice\n\nLet\u2019s say we need to write a rule to match article URLs for this website, and to rewrite them to use /article.php under the hood. The articles all have URLs like this:\n\n2013/article-title/\n\nThey start with a year (from 2005 up to 2013, currently), a slash, and then have a URL-safe version of the article title (a slug), ending in a slash. We\u2019d match it like this:\n\n^[0-9]{4}/[a-z0-9-]+/$\n\nIf that looks frightening, don\u2019t worry. Breaking it down, from the start of the URL (^) we\u2019re looking for four numbers ([0-9]{4}). Then a slash \u2014 that\u2019s just literal \u2014 and then anything lowercase a\u2013z or 0\u20139 or a dash ([a-z0-9-]) one or more times (+), ending in a slash (/$).\n\nPutting that into a rewrite rule, we end up with this:\n\nRewriteRule ^[0-9]{4}/[a-z0-9-]+/$ /article.php\n\nWe\u2019re getting close now. We can match the article URLs and rewrite them to use article.php. Now we just need to make sure that article.php knows which article it\u2019s supposed to display.\n\nCapturing groups, and replacements\n\nWhen rewriting URLs you\u2019ll often want to take important parts of the URL you\u2019re matching and pass them along to the script that handles the request. That\u2019s usually done by adding those parts of the URL on as query string arguments. For our example, we want to make sure that article.php knows the year and the article title we\u2019re looking for. That means we need to call it like this:\n\n/article.php?year=2013&slug=article-title\n\nTo do this, we need to mark which parts of the pattern we want to reuse in the destination. We do this with round brackets or parentheses. By placing parentheses around parts of the pattern we want to reuse, we create what\u2019s called a capturing group. To capture an important part of the source URL to use in the destination, surround it in parentheses.\n\nOur pattern now looks like this, with parentheses around the parts that match the year and slug, but ignoring the slashes:\n\n^([0-9]{4})/([a-z0-9-]+)/$ \n\nTo use the capturing groups in the destination URL, we use the dollar sign and the number of the group we want to use. So, the first capturing group is $1, the second is $2 and so on. (The $ is unrelated to the end-of-pattern $ we used before.)\n\nRewriteRule ^([0-9]{4})/([a-z0-9-]+)/$ /article.php?year=$1&slug=$2 \n\nThe value of the year capturing group gets used as $1 and the article title slug is $2. Had there been a third group, that would be $3 and so on. In regexp parlance, these are called back-references as they refer back to the pattern.\n\nOptions\n\nSeveral brain-taxing minutes ago, I mentioned some options as the final part of a rewrite rule. There are lots of options (or flags) you can set to change how the rule is processed. The most useful (to my mind) are:\n\n\n\tR=301\n\tPerform an HTTP 301 redirect to send the user\u2019s browser to the new URL. A status of 301 means a resource has moved permanently and so it\u2019s a good way of both redirecting the user to the new URL, and letting search engines know to update their indexes.\n\tL\n\tLast. If this rule matches, don\u2019t bother processing the following rules.\n\n\nOptions are set in square brackets at the end of the rule. You can set multiple options by separating them with commas:\n\nRewriteRule ^([0-9]{4})/([a-z0-9-]+)/$ /article.php?year=$1&slug=$2 [L]\n\nor\n\nRewriteRule ^about/([a-z0-9-]+).jsp/$ /about/$1/ [R=301,L] \n\nCommon pitfalls\n\nOnce you\u2019ve built up a few rewrite rules, things can start to go wrong. You may have been there: a rule which looks perfectly good is somehow not matching. One common reason for this is hidden behind that [L] flag. \n\nL for Last is a useful option to tell the rewrite engine to stop once the rule has been matched. This is what it does \u2014 the remaining rules in the .htaccess file are then ignored. However, once a URL has been rewritten, the entire set of rules are then run again on the new URL. If the new URL matches any of the rules, that too will be rewritten and on it goes. \n\nOne way to avoid this problem is to keep your \u2018real\u2019 pages under a folder path that will never match one of your rules, or that you can exclude from the rewrite rules.\n\nUseful snippets\n\nI find myself reusing the same few rules over and over again, just with minor changes. Here are some useful examples to refer back to.\n\nExcluding a directory\n\nAs mentioned above, if you\u2019re rewriting lots of fancy URLs to a collection of real files it can be helpful to put those files in a folder and exclude it from rewrite rules. This helps solve the issue of rewrite rules reapplying to your newly rewritten URL. To exclude a directory, put a rule like this at the top of your file, before your other rules. Our files are in a folder called _source, the dash in the rule means do nothing, and the L flag means the following rules won\u2019t be applied.\n\nRewriteRule ^_source - [L]\n\nThis is also useful for excluding things like CMS folders from your website\u2019s rewrite rules\n\nRewriteRule ^perch - [L] \n\nAdding or removing www from the domain\n\nSome folk like to use a www and others don\u2019t. Usually, it\u2019s best to pick one and go with it, and redirect the one you don\u2019t want. On this site, we don\u2019t use www.24ways.org so we redirect those requests to 24ways.org.\n\nThis uses a RewriteCond which is like an if for a rewrite rule: \u201cIf this condition matches, then apply the following rule.\u201d In this case, it\u2019s if the HTTP HOST (or domain name, basically) matches this pattern, then redirect everything:\n\nRewriteCond %{HTTP_HOST} ^www.24ways.org$ [NC]\nRewriteRule ^(.*)$ http://24ways.org/$1 [R=301,L]\n\nThe [NC] flag means \u2018no case\u2019 \u2014 the match is case-insensitive. The dots in the domain are escaped with a backslash, as a dot is a regular expression character which means match anything, so we escape it because we literally mean a dot in this instance.\n\nRemoving file extensions\n\nSometimes all you need to do to tidy up a URL is strip off the technology-specific file extension, so that /about/history.php becomes /about/history. This is easily achieved with the help of some more rewrite conditions.\n\nRewriteCond %{REQUEST_FILENAME} !-f\nRewriteCond %{REQUEST_FILENAME} !-d\nRewriteCond %{REQUEST_FILENAME}.php -f\nRewriteRule ^(.+)$ $1.php [L,QSA]\n\nThis says if the file being asked for isn\u2019t a file (!-f) and if it isn\u2019t a directory (!-d) and if the file name plus .php is an actual file (-f) then rewrite by adding .php on the end. The QSA flag means \u2018query string append\u2019: append the existing query string onto the rewritten URL.\n\nIt\u2019s these sorts of more generic catch-all rules that you need to watch out for when your .htaccess gets rerun after a successful match. Without care they can easily rematch the newly rewritten URL.\n\nLogging for when it all goes wrong\n\nAlthough not possible within your .htaccess file, if you have access to your Apache configuration files you can enable rewrite logging. This can be useful to track down where a rule is going wrong, if it\u2019s matching incorrectly or failing to match. It also gives you an overview of the amount of work being done by the rewrite engine, enabling you to rearrange your rules and maximise performance.\n\nRewriteEngine On\nRewriteLog \"/full/system/path/to/rewrite.log\"\nRewriteLogLevel 5\n\nTo be doubly clear: this will not work from an .htaccess file \u2014 it needs to be added to the main Apache configuration files. (I sometimes work using MAMP PRO locally on my Mac, and this can be pasted into the snappily named Customized virtual host general settings box in the Advanced tab for your site.)\n\nThe white screen of death\n\nOne of the most frustrating things when working with rewrite rules is that when you make a mistake it can result in the server returning an HTTP 500 Internal Server Error. This in itself isn\u2019t an error message, of course. It\u2019s more of a notification that an error has occurred. The real error message can usually be found in your Apache error log.\n\nIf you have access to your server logs, check the Apache error log and you\u2019ll usually find a much more descriptive error message, pointing you towards your mistake. (Again, if using MAMP PRO, go to Server, Apache and the View Log button.)\n\nIn conclusion\n\nRewriting URLs can be a bear, but the advantages are clear. Keeping a tidy URL structure, disconnected from the technology or file structure of your site can result in URLs that are easier to use and easier to maintain into the future.\n\nIf you\u2019re redesigning a site, remember that cool URIs don\u2019t change, so budget some time to make sure that any content you move has a rewrite rule associated with it to keep any links working.\n\nFurther reading\n\nTo find out more about URL rewriting and perhaps even learn more about regular expressions, I can recommend the following resources.\n\n\n\tFrom the horse\u2019s mouth, the Apache mod_rewrite documentation\n\tParticularly useful with that documentation is the RewriteRule Flags listing\n\tYou may wish to don sunglasses to follow the otherwise comprehensive Regular-Expressions.info tutorial\n\tFriend of 24 ways, Neil Crosby has a mod_rewrite Beginner\u2019s Guide which I\u2019ve found handy over the years.\n\n\nAs noted at the start, this isn\u2019t a fully comprehensive guide, but I hope it\u2019s useful in finding your feet with a powerful but sometimes annoying technology. Do you have useful snippets you often use on projects? Feel free to share them in the comments.", "year": "2013", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2013-12-01T00:00:00+00:00", "url": "https://24ways.org/2013/url-rewriting-for-the-fearful/", "topic": "code"}
{"rowid": 29, "title": "What It Takes to Build a Website", "contents": "In 1994 we lost Kurt Cobain and got the world wide web as a weird consolation prize. In the years that followed, if you\u2019d asked me if I knew how to build a website I\u2019d have said yes, I know HTML, so I know how to build a website. If you\u2019d then asked me what it takes to build a website, I\u2019d have had to admit that HTML would hardly feature.\n\nAmong the design nerdery and dev geekery it\u2019s easy to think that the nuts and bolts of building a page just need to be multiplied up and Ta-da! There\u2019s your website. That can certainly be true with weekend projects and hackery for fun. It works for throwing something together on GitHub or experimenting with ideas on your personal site. But what about working professionally on client projects?\n\nThe web is important, so we need to build it right.\n\nIt\u2019s 2015 \u2013 your job involves people paying you money for building websites. What does it take to build a website and to do it right? What practices should we adopt to make really great, successful and professional web projects in 2015? I put that question to some friends and 24 ways authors to see what they thought.\n\nGetting the tech right\n\nInevitably, it all starts with the technology. We work in a technical medium, after all. From Notepad and WinFTP through to continuous integration and deployment \u2013 how do you build sites?\n\nCreate a stable development environment\n\nThere\u2019s little more likely to send a web developer into a wild panic and a client into a wild rage than making a new site live and things just not working. That\u2019s why it\u2019s important to have realistic development and staging environments that mimic the live server as closely as possible.\n\nAre you in the habit of developing new sites right on the client\u2019s server? Or maybe in a subfolder on your local machine? It\u2019s time to reconsider.\n\nCharlie Perrins writes:\n\n\n\tDon\u2019t work on a live server \u2013 this feels like one of those gear-changing moments for a developer\u2019s growth. Build something that works just as well locally on your own machine as it does on a live server, and capture the differences in the code between the local and live version in a single config file. Ultimately, if you can get all the differences between environments down to a config level then you\u2019ll be in a really good position to automate the deployment process at some point in the future.\n\n\nAnything that creates a significant difference between the development and the live environments has the potential to cause problems you won\u2019t know about until the site goes live \u2013 and at that point the problems are very public and very embarrassing, not to mention unprofessional.\n\nA reasonable solution is to use a tool like MAMP PRO which enables you to set up an individual local website for each project you work on. Importantly, individual sites give you both consistency of paths between development and live, but also the ability to configure server options (like PHP versions and configuration, for example) to match the live site.\n\nBetter yet is to use a virtual machine, managed with a tool such as Vagrant. If you\u2019re interested in learning more about that, we have an article on that subject later in the series.\n\nUse source control\n\nTrent Walton writes:\n\n\n\tWe use source control, and it\u2019s become the centerpiece for how we handle collaboration, enhancements, and issues. It drives our process.\n\n\nI\u2019m hoping by now that you\u2019re either using source control for all your work, or feeling a nagging guilt that you should be. Be it Git, Mercurial, Subversion (name your poison), a revision control system enables you to keep track of changes, revert anything that breaks, and keep rolling backups of your project.\n\nThe benefits only start there, and Charlie Perrins recommends using source control \u201cnot just as a personal backup of your code, but as a way to play nicely with other developers.\u201c\n\nNoting the benefits when collaborating with other developers, he adds:\n\n\n\tGraduating from being the sole architect of your codebase to contributing to a shared codebase is a huge leap for a developer. Perhaps a practical way for people who tend to work on their own to do that would be to submit a pull request or a patch to an open source project or plugin.\u201d\n\n\nRichard Rutter of Clearleft sees clear advantages for the client, too. He recommends using source control \u201cpreferably in some sort of collaborative environment that you can open up or hand over to the client\u201d \u2013 a feature found with hosted services such as GitHub.\n\nIf you\u2019d like to hone your Git skills, Emma Jane Westby wrote Git for Grown-ups in last year\u2019s 24 ways.\n\nDon\u2019t repeat, automate!\n\nTim Kadlec is a big proponent of automating your build process:\n\n\n\tI\u2019ve been hammering that home to every client I\u2019ve had this year. It\u2019s amazing how many companies don\u2019t really have a formal build/deployment process in place. So many issues on the web (performance, accessibility, etc.) can be greatly improved just by having a layer of automation involved.\n\n\tFor example, graphic editing software spits out ridiculously bloated images. Very frequently, that\u2019s what ends up getting put on a site. If you have a build process, you can have the compression automated and start seeing immediate gains for no effort. On a recent project, they were able to shave around 1.5MB from their site weight simply by automating compression.\n\n\nOnce you have your code in source control, some of that automation can be made easier. Brian Suda writes:\n\n\n\tWe have a few bash scripts that run on git commit: they compile the less, jslint and remove white-space, basically the 3 Cs, Compress, Concatenate, Combine. This is now part of our workflow without even realising it.\n\n\nOne great way to get started with a build process is to use a tool like Grunt, and a great way to get started with Grunt is to read Chris Coyier\u2019s Grunt for People Who Think Things Like Grunt are Weird and Hard.\n\nTim reinforces:\n\n\n\tIssues like [image compression]  \u2014  or simple accessibility issues like alt tags on images  \u2014  should never be able to hit a live server. If you can detect it, you can automate it. And if you can automate it, you can free up time for designers and developers to focus on more challenging \u2014 and interesting \u2014 problems.\n\n\nA clear call to arms to tighten up and formalise development and deployment practices. The less that has to be done manually or is susceptible to change, the less that can go wrong when a site is built and deployed. Any procedures that are automated are no longer dependant on a single person\u2019s knowledge, making it easier to build your team or just cope when someone important is out of the office or leaves.\n\nIf you\u2019re interested in kicking the FTP habit and automating your site deployments, we have an article later in the series just for you.\n\nBuild systems, not sites\n\nOne big theme arising this year was that of building websites as systems, not as individual pages.\n\nBrad Frost:\n\n\n\tFor me, teams making websites in 2015 shouldn\u2019t be working on just-another-redesign redesign. People are realizing that in order to make stable, future-friendly, scalable, extensible web experiences they\u2019re going to need to think more systematically. That means crafting deliberate and thoughtful design systems. That means establishing front-end style guides. That means killing the out-dated, siloed, assembly-line waterfall process and getting cross-disciplinary teams working together in meaningful ways. That means treating development as design. That means treating performance as design. That means taking the time out of the day to establish the big picture, rather than aimlessly crawling along quarter by quarter.\n\n\nDesigner and developer Jina Bolton also advocates the use of style guides, and recommends making the guide a project deliverable:\n\n\n\tConsider adding on a style guide/UI library to your project as a deliverable for maintainability and thinking through all UI elements and components.\n\n\nVal Head agrees: \u201cbuild and maintain a style guide for each project\u201d she wrote. On the subject of approaching a redesign, she added:\n\n\n\tA UI inventory goes a long way to helping get your head around what a design system needs in the early stages of a redesign project.\n\n\nSo what about that old chestnut, responsive web design? Should we be making sites responsive by default? How about mobile first?\n\nRichard Rutter:\n\n\n\tThink mobile first unless you have a very good reason not to. Remember to take the client with you on this principle, otherwise it won\u2019t work as a convincing piece of design.\n\n\nTrent Walton adds:\n\n\n\tThe more you can test and sort of skew your perception for what is typical on the web, the better. 4k displays hooked up to 100Mbps connections can make one extremely unsympathetic.\n\n\nThe value of testing with real devices is something Ruth John appreciates. She wrote:\n\n\n\tI still have my own small device lab at home, even though I work permanently for a well-established company (which has a LOT of devices at its disposal) \u2013 it just means I can get a good overview of how things are looking during development.\n\n\nAnd speaking of systems, Mark Norman Francis recommends the use of measuring tools to aid the design process; \u201c[U]se analytics and make decisions from actual data\u201d he suggests, rather than relying totally on intuition.\n\nTim Kadlec adds a word on performance planning:\n\n\n\tI think having a performance budget in place should now be a given on any project. We\u2019ve proven pretty conclusively through a hundred and one case studies that performance matters. And over the last year or so, we\u2019ve really seen a lot of great tools emerge to help track and enforce performance budgets. There\u2019s not really a good excuse for not using one any more.\n\n\nIt\u2019s clear that in the four years since Ethan Marcotte\u2019s Responsive Web Design article the diversity of screen sizes, network connection speeds and input methods has only increased. New web projects should presume visitors will be using anything from a watch up to a big screen desktop display, and from being offline, through to GPRS, 3G and fast broadband.\n\nWill it take more time to design and build for those constraints? Yes, it most likely will. If Internet Explorer is brave enough to ask to be your default browser, you can be brave enough to tell your client they need to build responsively.\n\nWorking collaboratively\n\nA big part of delivering a successful website project is how we work together, both as a design team and a wider project team with the client.\n\nVal Head recommends an open line of communication:\n\n\n\tKeep conversations going. With clients, with teammates. Talking is so important with the way we work now. A good team conversation place, like Slack, is slowly becoming invaluable for me too.\n\n\nRuth John agrees:\n\n\n\tWe\u2019ve recently opened up our lines of communication by using Slack. It has transformed the way we work. We\u2019re easily more productive and collaborative on projects, as well as making it a lot easier for us all to work remotely (including freelancers).\n\n\nShe goes on to point out how tools can be combined to ease team communication without adding further complications:\n\n\n\tWe have a private GitHub organisation (which everyone who works with us is granted access to), which not only holds all our project code but also a team wiki. This has lots of information to get you set up within the team, as well as coding guidelines and best practices and other admin info, like contact numbers/emails for the team.\n\n\nSmall-A agile is also the theme of the day, with Mark Norman Francis suggesting an approach of \u201csmall iterations with constant feedback around individual features, not spec-it-all-first\u201d. He also encourages you to review as you go, at each stage of the project:\n\n\n\tAlways reflect on what went well and what went badly, and how you can learn from that, even if not Doing Agile\u2122. Ultimately \u201cbest practices\u201d should come from learning lessons (both good and bad).\n\n\nRichard Rutter echoes this, warning against working in isolation from the client for too long:\n\n\n\tAvoid big reveals. Your engagement with the client should be participatory. In business no one likes surprises.\n\n\nThis experience rings true for Ruth John who recommends involving real users in the feedback loop, not just the client:\n\n\n\tWe also try and get feedback on what we\u2019re building as soon and as often as we can with our stakeholders/clients and real users.\n\n\nWe should also remember that our role is to serve the client\u2019s needs, not just bill them for whatever we can. Brian Suda adds:\n\n\n\tDon\u2019t sell clients on things they don\u2019t need. We can spout a lot of jargon and scare clients into thinking you are a god. We can do things few can now, but you can\u2019t rip people off because they are unknowledgeable.\n\n\nBut do clients know what they\u2019re getting, even when they see it? Trent Walton has an interesting take:\n\n\n\tWe focus on prototypes over image-based comps at all costs, especially when meetings are involved. It\u2019s much easier to assess a prototype, and too often with image-based comps, discussions devolve into how something might feel when actually live, or how a layout could change to fit a given viewport.\n\n\nVal Head also likes to get work into the browser:\n\n\n\tSketch design ideas with any software you like, but get to the browser as soon as possible.\n\n\nBeyond your immediate team, Emma Jane Westby has advice for looking further afield:\n\n\n\tInvest time into building relationships within your (technical) community. You never know when you might be able to lend a hand; or benefit from someone who\u2019s able to lend theirs.\n\n\nAnd when things don\u2019t go according to plan, Brian Suda has the following advice:\n\n\n\tIf something doesn\u2019t work out, be professional and don\u2019t burn bridges. It will always come back to you.\n\n\nThe best work comes from working collaboratively, not just as a team within an agency or department, but with the client and stakeholders too. If doing your job and chucking it over the fence ever worked, it certainly doesn\u2019t fly any more. You can work in isolation, but doing really great work requires collaboration.\n\nThe business end\n\nWhen you\u2019re building sites professionally, every team member has to think about the business aspects. Estimating time, setting billing rates, and establishing deliverables are all part of the job.\n\nIn 2008, Andrew Clarke gave us the Contract Killer sample contract we could use to establish a working agreement for a web design project. Richard Rutter agrees that contracts are still an essential part of business:\n\n\n\tThey are there for both parties\u2019 protection. Make sure you know what will happen if you decide you don\u2019t want to work with the client any more (it happens) and, of course, what circumstances mean they can stop taking your services.\n\n\nHaving a contract is one thing, but does it adequately protect both you and the client? Emma Jane Westby adds:\n\n\n\tFind a good IP lawyer/legal counsel. I routinely had an IP lawyer read all of my contracts to find loopholes I wouldn\u2019t have noticed. I didn\u2019t always change the contract, but at least I knew what might come back to bite me.\n\n\nSo, you have a contract in place, and know what the project is. Brian Suda recommends keeping track of time and making sure you bill fairly for the hours the project costs you:\n\n\n\tIf I go to a meeting and they are 15 minutes late, the billing clock has already started. They can\u2019t expect me to be in the 1h meeting and not bill for the extra 15\u201330 minutes they wasted. It goes both ways too. You need to do your best to respect their deadlines and time frame \u2013 this is always hard to get right.\n\n\nAs ever, it\u2019s good business to do good business. Perhaps we can at last shed the old image of web designers being snowboarding layabouts and demonstrate to clients that we care as much about conducting professional business as they do.\n\nTime to review\n\nIt\u2019s a lot to take in. Some of these ideas and practices will be familiar, others new and yet to be evaluated. The web moves at a fast pace, and we need to be constantly reexamining our tools, techniques and working practices. The most important thing is not to blindly adopt any and all suggestions, but to carefully look at what the benefits might be and decide how they apply to your work.\n\nCould you benefit from more formalised development and deployment procedures? Would your design projects run more smoothly and have a longer maintainable life if you approached the solution as a componentised system rather than a series of pages? Are your teams structured in a way that enables the most fluid communication, or are there changes you could make? Are your billing procedures and business agreements serving you and your clients in the best way possible?\n\nThe new year is a good time to look at your working practices and see what can be improved, and maybe this time next year you\u2019ll look back and think \u201cthank goodness we don\u2019t work like that any more\u201d.", "year": "2014", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2014-12-01T00:00:00+00:00", "url": "https://24ways.org/2014/what-it-takes-to-build-a-website/", "topic": "business"}
{"rowid": 66, "title": "Solve the Hard Problems", "contents": "So, here we find ourselves on the cusp of 2016. We\u2019ve had a good year \u2013 the web is still alive, no one has switched it off yet. Clients still have websites, teenagers still have phone apps, and there continue to be plenty of online brands to meaningfully engage with each day. Good job team, high fives all round.\nAs it\u2019s the time to make resolutions, I wanted to share three small ideas to take into the new year.\nGet good at what you do\n\u201cHow do you get to Carnegie Hall?\u201d the old joke goes. \u201cPractise, practise, practise.\u201d \nWe work in an industry where there is an awful lot to learn. There\u2019s a lot to learn to get started and then once you do, there\u2019s a lot more to learn to keep your skills current. Just when you think you\u2019ve mastered something, it changes.\nThis is true of many industries, of course, but the sheer pace of change for us makes learning not an annual activity, but daily. Learning takes time, and while I\u2019m not convinced that every skill takes the fabled ten thousand hours to master, there is certainly no escaping that to remain current we must reinvest time in keeping our skills up to date.\nPicking where to spend your time\nOne of the hardest aspects of this thing of ours is just choosing what to learn. If you, like me, invested any time in learning the Less CSS preprocessor over the last few years, you\u2019ll probably now be spending your time relearning Sass instead. If you spent time learning Grunt, chances are you\u2019ll now be thinking about whether you should switch to Gulp. It\u2019s not just that there are new types of tools, there are new tools and frameworks to do the things you\u2019re already doing, but, well, differently.\nDeciding what to learn is hard and the costs of backing the wrong horse can seriously mount up; so much so that by the time you\u2019ve learned and then relearned the tools everyone says you need for your job, there\u2019s rarely enough time to spend really getting to know how best to use them.\n\u00a0Practise, practise, practise\nDo you know how you don\u2019t get to Carnegie Hall? By learning a new instrument each week. It takes time and experience to really learn something well. That goes for a new JavaScript framework as much as a violin. If you flit from one shiny new thing to another, you\u2019re destined to produce amateurish work forever.\nLearn the new thing, but then stick with it long enough to get really good at it \u2013 even if Twitter trolls try to convince you it\u2019s not cool. What\u2019s really not cool is living as a forevernoob. \nIf you\u2019re still not sure what to learn, go back to basics. Considering a new CSS or JavaScript framework? Invest that time in learning the underlying CSS or JavaScript really well instead. Those skills will stand the test of time.\nAudience and purpose\nBack when I was in school, my English teacher (a nice Welsh lady, who I appreciate more now than I did back then) used to love to remind us that every piece of writing should have an audience and a purpose. So much so that audience and purpose almost became her catch phrase. For every essay, article or letter, we were reminded to consider who we were writing it for and what we were trying to achieve. \nIt\u2019s something I think about a lot; certainly when writing, but also in almost every other creative endeavour. Asking who is this for and what am I trying to achieve applies equally to designing a logo or website, through to composing music or writing software.\nBeing productive\nIt seems like everyone wants to have a product these days. As someone who used to do client services work and now has a product company, I often talk with people who are interested in taking something they\u2019ve built in-house and turning it into a product. You know the sort of thing: a design agency with its own CMS or project management web app; the very logical thought process of: if this helps our business, maybe others will find it valuable too; the question that inevitably follows: could we turn this into a product?\nWhether consciously or not, the audience and purpose influence nearly every aspect of your creative process. Once written or designed or developed or created, revising a work to change the audience and purpose can be quite a challenge. No matter how much you want to turn the tension-building, atmospheric music for a horror film into a catchy chart hit, it\u2019s going to be a struggle. Yes, it\u2019s music, but that\u2019s neither the audience nor purpose for which it was created.\nThe same is absolutely true for your in-house tools \u2013 those were also designed for a specific audience and purpose. Your in-house CMS would have been designed with an audience of your own development team, who are busy implementing sites for clients. The purpose is to make that team more productive overall, taking into account considerations of maintaining multiple sites on a common codebase, training clients, a more mature and stable platform and all the other benefits of reusing the same code for each project. The audience is your team and the purpose increased productivity.\nThat\u2019s very different from a customer who wants to buy a polished system to use off-the-shelf. If their needs perfectly aligned with yours then they wouldn\u2019t be in the market for your product \u2013 they would have built their own.\nSometimes you hear the advice to \u201cscratch your own itch\u201d when it comes to product design. I don\u2019t completely agree. Got an itch? Great. Find other itchy people and sell them a backscratcher.\nBuilding a product, like designing a website, is a lot of work. It requires knowing your audience and purpose inside out. You can\u2019t fudge it and you can\u2019t just hope you\u2019ll find an audience for some old thing you have lying around.\nAlways consider the audience and purpose for everything you create. It\u2019s often the difference between success and failure.\nSolve the hard problems\nHuman beings have a natural tendency to avoid hard problems. In digital design (websites, software, whatever) the received wisdom is often that we can get 80% of the way towards doing the hard thing by doing something that\u2019s not very hard.\nDo you know what you get at the end of it? Paid. But nothing really great ever happens that way.\nI worked on a client project a while back where one of the big challenges was making full use of the massive image library they had built up over the years. The client had tens of thousands of photographs, along with a fair amount of video and a large MP3 audio library too. If it wasn\u2019t managed carefully, storage sizes would get out of control, content would go unattributed, and everything would get very messy very quickly.\nI could tell from the outset that this aspect of the project was going to be a constant problem. So we tackled it head-on. We designed and built a media management system to hold and process all the assets, and added an API so the content management system could talk to it. Every time the site needed a photo at a new size, it made an API request to the system and everything was handled seamlessly.\nIt was a daunting job to invest all the time and effort in building that dedicated system and API, but it really paid off. Instead of having the constant troubles of a vast library of media, it became one of the strongest parts of the project.\nTurn your hardest problems into your biggest strengths\nThere\u2019s a funny thing about hard problems. The hardest problems are the most fun to solve and have the biggest impact.\nMaybe you\u2019re the sort of person who clocks in for work, does their job and clocks out at 5pm without another thought. But I don\u2019t think you are, because you\u2019re here reading this. If you really love what you do, I don\u2019t think you can be satisfied in your work unless you\u2019re seeking out and working on those hard problems. That\u2019s where the magic is.\n\nThe new year is a helpful time to think about breaking bad habits. Whether it\u2019s smoking a bit less, or going to the gym a bit more, the ticking over of the calendar can provide the motivation for a new start. I have some suggestions for you.\n\nGet good at what you do. Practise your skills and don\u2019t just flit from one shiny thing to the next.\nRemember who you\u2019re doing it for and why. Consider the audience and purpose for everything you create.\nSolve the hard problems. It\u2019s more interesting, more satisfying, and has a greater impact.\n\nAs we move into 2016, these are the things I\u2019m going to continue to work on. Maybe you\u2019d like to join me.", "year": "2015", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2015-12-24T00:00:00+00:00", "url": "https://24ways.org/2015/solve-the-hard-problems/", "topic": "process"}
{"rowid": 80, "title": "HTML5 Video Bumpers", "contents": "Video is a bigger part of the web experience than ever before. With native browser support for HTML5 video elements freeing us from the tyranny of plugins, and the availability of faster internet connections to the workplace, home and mobile networks, it\u2019s now pretty straightforward to publish video in a way that can be consumed in all sorts of ways on all sorts of different web devices.\n\nI recently worked on a project where the client had shot some dedicated video shorts to publish on their site. They also had some five-second motion graphics produced to top and tail the videos with context and branding. This pretty common requirement is a great idea on the web, where a user might land at your video having followed a link and be viewing a page without much context.\n\nKnown as bumpers, these short introduction clips help brand a video and make it look a lot more professional.\n\n\n\nAdding bumpers to a video\n\nThe simplest way to add bumpers to a video would be to edit them on to the start and end of the video file itself. Cooking the bumpers into the video file is easy, but should you ever want to update them it can become a real headache. If the branding needs updating, for example, you\u2019d need to re-edit and re-encode all your videos. Not a fun task.\n\nWhat if the bumpers could be added dynamically? That would enable you to use the same bumper for multiple videos (decreasing download time for users who might watch more than one) and to update the bumpers whenever you wanted. You could change them seasonally, update them for special promotions, run different advertising slots, perform multivariate testing, or even target different bumpers to different users.\n\nThe trade-off, of course, is that if you dynamically add your bumpers, there\u2019s a chance that a user in a given circumstance might not see the bumper. For example, if the main video feature was uploaded to YouTube, you\u2019d have no way to control the playback. As always, you need to weigh up the pros and cons and make your choice.\n\nHTML5 bumpers\n\nIf you wanted to dynamically add bumpers to your HTML5 video, how would you go about it? That was the question I found myself needing to answer for this particular client project.\n\nMy initial thought was to treat it just like an image slideshow. If I were building a slideshow that moved between images, I\u2019d use CSS absolute positioning with z-index to stack the images up on top of each other in a pile, with the first image on top. To transition to the second image, I\u2019d use JavaScript to fade the top image out, revealing the second image beneath it.\n\n\n\nNow that video is just a native object in the DOM, just like an image, why not do the same? Stack the videos up with the opening bumper on top, listen for the video\u2019s onended event, and fade it out to reveal the main feature behind. Good idea, right?\n\nWrong\n\nRemember that this is the web. It\u2019s never going to be that easy. The problem here is that many non-desktop devices use native, dedicated video players. Think about watching a video on a mobile phone \u2013 when you play the video, the phone often goes full-screen in its native player, leaving the web page behind. There\u2019s no opportunity to fade or switch z-index, as the video isn\u2019t being viewed in the page. Your page is left powerless. Powerless!\n\n\n\nSo what can we do? What can we control?\n\nThose of us with particularly long memories might recall a time before CSS, when we\u2019d have to use JavaScript to perform image rollovers. As CSS background images weren\u2019t a practical reality, we would use lots of <img> elements, and perform a rollover by modifying the src attribute of the image. \n\nTurns out, this old trick of modifying the source can help us out with video, too. In most cases, modifying the src attribute of a <video> element, or perhaps more likely the src attribute of a source element, will swap from one video to another.\n\nSwappin\u2019 it\n\nLet\u2019s take a deliberately simple example of a super-basic video tag:\n\n<video src=\"mycat.webm\" controls>no fallback coz i is lame, innit.</video>\n\nWe could very simply write a script to find all video tags and give them a new src to show our bumper.\n\n<script>\n\tvar videos, i, l;\n\tvideos = document.getElementsByTagName('video');\n\tfor(i=0, l=videos.length; i<l; i++) {\n\t\tvideos[i].setAttribute('src', 'bumper-in.webm');\n\t}\n</script>\n\nView the example in a browser with WebM support. You\u2019ll see that the video is swapped out for the opening bumper. Great!\n\nBeefing it up\n\nOf course, we can\u2019t just publish video in one format. In practical use, you need a <video> element with multiple <source> elements containing your different source formats.\n\n<video controls>\n    <source src=\"mycat.mp4\" type=\"video/mp4\" />\n    <source src=\"mycat.webm\" type=\"video/webm\" />\n    <source src=\"mycat.ogv\" type=\"video/ogg\" />\n</video>\n\nThis time, our script needs to loop through the sources, not the videos. We\u2019ll use a regular expression replacement to swap out the file name while maintaining the correct file extension.\n\n<script>\n    var sources, i, l, orig;\n    sources = document.getElementsByTagName('source');\n    for(i=0, l=sources.length; i<l; i++) {\n        orig = sources[i].getAttribute('src');\n        sources[i].setAttribute('src', orig.replace(/(w+).(w+)/, 'bumper-in.$2'));\n        // reload the video\n        sources[i].parentNode.load();\n    }\n</script>\n\nThe difference this time is that when changing the src of a <source> we need to call the .load() method on the video to get it to acknowledge the change.\n\nSee the code in action, this time in a wider range of browsers.\n\nBut, my video!\n\nI guess we should get the original video playing again. Keeping the same markup, we need to modify the script to do two things:\n\n\n\tStore the original src in a data- attribute so we can access it later\n\tAdd an event listener so we can detect the end of the bumper playing, and load the original video back in\n\n\nAs we need to loop through the videos this time to add the event listener, I\u2019ve moved the .load() call into that loop. It\u2019s a bit more efficient to call it only once after modifying all the video\u2019s sources.\n\n<script>\nvar videos, sources, i, l, orig;\nsources = document.getElementsByTagName('source');\nfor(i=0, l=sources.length; i<l; i++) {\n    orig = sources[i].getAttribute('src');\n    sources[i].setAttribute('data-orig', orig);\n    sources[i].setAttribute('src', orig.replace(/(w+).(w+)/, 'bumper-in.$2'));\n}\nvideos = document.getElementsByTagName('video');\nfor(i=0, l=videos.length; i<l; i++) {\n    videos[i].load();\n    videos[i].addEventListener('ended', function(){\n        sources = this.getElementsByTagName('source');\n        for(i=0, l=sources.length; i<l; i++) {\n            orig = sources[i].getAttribute('data-orig');\n            if (orig) {\n                sources[i].setAttribute('src', orig);\n            }\n            sources[i].setAttribute('data-orig','');\n        }\n        this.load();\n        this.play();\n    });\n}\n</script>\n\nAgain, view the example to see the bumper play, followed by our spectacular main feature. (That\u2019s my cat, Widget. His interests include sleeping and internet marketing.)\n\nTidying things up\n\nThe final thing to do is add our closing bumper after the main video has played. This involves the following changes:\n\n\n\tWe need to keep track of whether the src has been changed, so we only play the video if it\u2019s changed. I\u2019ve added the modified variable to track this, and it stops us getting into a situation where the video just loops forever.\n\tAdd an else to the event listener, for when the orig is false (so the main feature has been playing) to load in the end bumper. We also check that we\u2019re not already playing the end bumper. Because looping.\n\n\n<script>\nvar videos, sources, i, l, orig, current, modified;\nsources = document.getElementsByTagName('source');\nfor(i=0, l=sources.length; i<l; i++) {\n   orig = sources[i].getAttribute('src');\n   sources[i].setAttribute('data-orig', orig);\n   sources[i].setAttribute('src', orig.replace(/(w+).(w+)/, 'bumper-in.$2'));\n}\nvideos = document.getElementsByTagName('video');\nfor(i=0, l=videos.length; i<l; i++) {\n   videos[i].load();\n   modified = false;\n   videos[i].addEventListener('ended', function(){\n      sources = this.getElementsByTagName('source');\n      for(i=0, l=sources.length; i<l; i++) {\n         orig = sources[i].getAttribute('data-orig');\n         if (orig) {\n            sources[i].setAttribute('src', orig);\n            modified = true;\n         }else{\n            current = sources[i].getAttribute('src');\n            if (current.indexOf('bumper-out')==-1) {\n               sources[i].setAttribute('src', current.replace(/([w]+).(w+)/, 'bumper-out.$2'));\n               modified = true;\n            }else{\n               this.pause();\n               modified = false;\n            }\n         }\n         sources[i].setAttribute('data-orig','');\n      }\n      if (modified) {\n         this.load();\n         this.play();\n      }\n   });\n}\n</script>\n\nYo ho ho, that\u2019s a lot of JavaScript. See it in action \u2013 you should get a bumper, the cat video, and an end bumper.\n\nOf course, this code works fine for demonstrating the principle, but it\u2019s very procedural. Nothing wrong with that, but to do something similar in production, you\u2019d probably want to make the code more modular to ease maintainability. Besides, you may want to use a framework, rather than basic JavaScript. \n\nThe end credits\n\nOne really important principle here is that of progressive enhancement. If the browser doesn\u2019t support JavaScript, the user won\u2019t see your bumper, but they will get the main video. If the browser supports JavaScript but doesn\u2019t allow you to modify the src (as was the case with older versions of iOS), the user won\u2019t see your bumper, but they will get the main video.\n\nIf a search engine or social media bot grabs your page and looks for content, they won\u2019t see your bumper, but they will get the main video \u2013 which is absolutely what you want.\n\nThis means that if the bumper is absolutely crucial, you may still need to cook it into the video. However, for many applications, running it dynamically can work quite well.\n\nAs always, it comes down to three things:\n\n\n\tMeasure your audience: know how people access your site\n\tTest the solution: make sure it works for your audience\n\tPlan for failure: it\u2019s the web and that\u2019s how things work \u2018round these parts\n\n\nBut most of all play around with it, have fun and build something awesome.", "year": "2012", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2012-12-01T00:00:00+00:00", "url": "https://24ways.org/2012/html5-video-bumpers/", "topic": "code"}
{"rowid": 101, "title": "Easing The Path from Design to Development", "contents": "As a web developer, I have the pleasure of working with a lot of different designers. There has been a lot of industry discussion of late about designers and developers, focusing on how different we sometimes are and how the interface between our respective phases of a project (that is to say moving from a design phase into production) can sometimes become a battleground.\n\nI don\u2019t believe it has to be a battleground. It\u2019s actually more like being a dance partner \u2013 our steps are different, but as long as we know our own part and have a little knowledge of our partner\u2019s steps, it all goes together to form a cohesive dance. Albeit with less spandex and fewer sequins (although that may depend on the project in question).\n\nAs the process usually flows from design towards development, it\u2019s most important that designers have a little knowledge of how the site is going to be built. At the specialist web development agency I\u2019m part of, we find that designs that have been well considered from a technical perspective help to keep the project on track and on budget.\n\nBased on that experience, I\u2019ve put together my checklist of things that designers should consider before handing their work over to a developer to build.\n\nLayout\n\nOne rookie mistake made by traditionally trained designers transferring to the web is to forget a web browser is not a fixed medium. Unlike designing a magazine layout or a piece of packaging, there are lots of available options to consider. Should the layout be fluid and resize with the window, or should it be set to a fixed width? If it\u2019s fluid, which parts expand and which not? If it\u2019s fixed, should it sit in the middle of the window or to one side?\n\nIf any part of the layout is going to be flexible (get wider and narrower as required), consider how any graphics are affected. Images don\u2019t usually look good if displayed at anything other that their original size, so should they behave? If a column is going to get wider than it\u2019s shown in the Photoshop comp, it may be necessary to provide separate wider versions of any background images.\n\nText size and content volume\n\nA related issue is considering how the layout behaves with both different sizes of text and different volumes of content. Whilst text zooming rather than text resizing is becoming more commonplace as the default behaviour in browsers, it\u2019s still a fundamentally important principal of web design that we are suggesting and not dictating how something should look. Designs must allow for a little give and take in the text size, and how this affects the design needs to be taken into consideration.\n\nKeep in mind that the same font can display differently in different places and platforms. Something as simple as Times will display wider on a Mac than on Windows. However, the main impact of text resizing is the change in how much vertical space copy takes up. This is particularly important where space is limited by the design (making text bigger causes many more problems than making text smaller). Each element from headings to box-outs to navigation items and buttons needs to be able to expand at least vertically, if not horizontally as well. This may require some thought about how elements on the page may wrap onto new lines, as well as again making sure to provide extended versions of any graphical elements.\n\nSimilarly, it\u2019s rare theses days to know exactly what content you\u2019re working with when a site is designed. Many, if not most sites are designed as a series of templates for some kind of content management system, and so designs cannot be tweaked around any specific item of content. Designs must be able to cope with both much greater and much lesser volumes of content that might be thrown in at the lorem ipsum phase.\n\nParticular things to watch out for are things like headings (how do they wrap onto multiple lines) and any user-generated items like usernames. It can be very easy to forget that whilst you might expect something like a username to be 8-12 characters, if the systems powering your site allow for 255 characters they\u2019ll always be someone who\u2019ll go there. Expect them to do so.\n\nAgain, if your site is content managed or not, consider the possibility that the structure might be expanded in the future. Consider how additional items might be added to each level of navigation. Whilst it\u2019s rarely desirable to make significant changes without revisiting the site\u2019s information architecture more thoroughly, it\u2019s an inevitable fact of life that the structure needs a little bit of flexibility to change over time.\n\nInteractions with and without JavaScript\n\nA great number of sites now make good use of JavaScript to streamline the user interface and make everything just that touch more usable. Remember, though, that any developer worth their salt will start by building the interface without JavaScript, get it all working, and then layer that JavaScript on top. This is to allow for users viewing the site without JavaScript available or enabled in their browser.\n\nDesigners need to consider both states of any feature they\u2019re designing \u2013 how it looks and functions with and without JavaScript. If the feature does something fancy with Ajax, consider how the same can be achieved with basic HTML forms, links and intermediary pages. These all need to be designed, because this is how some of your users will interact with the site.\n\nLogged in and logged out states\n\nWhen designing any type of web application or site that has a membership system \u2013 that is to say users can create an account and log into the site \u2013 the design will need to consider how any element is presented in both logged in and logged out states. For some items there\u2019ll be no difference, whereas for others there may be considerable differences.\n\nShould an item be hidden completely not logged out users? Should it look different in some way? Perhaps it should look the same, but prompt the user to log in when they interact with it. If so, what form should that prompt take on and how does the user progress through the authentication process to arrive back at the task they were originally trying to complete?\n\nCouple logged in and logged out states with the possible absence of JavaScript, and every feature needs to be designed in four different states:\n\n\n\tLogged out with JavaScript available\n\tLogged in with JavaScript available\n\tLogged out without JavaScript available\n\tLogged in without JavaScript available\n\n\nFonts\n\nThere are three main causes of war in this world; religions, politics and fonts. I\u2019ve said publicly before that I believe the responsibility for this falls squarely at the feet of Adobe Photoshop. Photoshop, like a mistress at a brothel, parades a vast array of ropey, yet strangely enticing typefaces past the eyes of weak, lily-livered designers, who can\u2019t help but crumble to their curvy charms.\n\nYet, on the web, we have to be a little more restrained in our choice of typefaces. The purest solution is always to make the best use of the available fonts, but this isn\u2019t always the most desirable solution from a design point of view. There are several technical solutions such as techniques that utilise Flash (like sIFR), dynamically generated images and even canvas in newer browsers. Discuss the best approach with your developer, as every different technique has different trade-offs, and this may impact the design in other ways.\n\nMessaging\n\nAny site that has interactive elements, from a simple contact form through to fully featured online software application, involves some kind of user messaging. By this I mean the error messages when something goes wrong and the success and thank-you messages when something goes right. These typically appear as the result of an interaction, so are easy to forget and miss off a Photoshop comp.\n\nFor every form, consider what gets displayed to the user if they make a mistake or miss something out, and also what gets displayed back when the interaction is successful. What do they see and where do the go next?\n\nWith Ajax interactions, the user doesn\u2019t get any visual feedback of the site waiting for a response from the server unless you design it that way. Consider using a \u2018waiting\u2019 or \u2018in progress\u2019 spinner to give the user some visual feedback of any background processes. How should these look? How do they animate?\n\nSimilarly, also consider the big error pages like a 404. With luck, these won\u2019t often be seen, but it\u2019s at the point that they are when careful design matters the most.\n\nForm fields\n\nDepending on the visual style of your site, the look of a browser\u2019s default form fields and buttons can sometimes jar. It\u2019s understandable that many a designer wants to change the way they look. Depending on the browser in question, various things can be done to style form fields and their buttons (although it\u2019s not as flexible as most would like).\n\nA common request is to replace the default buttons with a graphical button. This is usually achievable in most cases, although it\u2019s not easy to get a consistent result across all browsers \u2013 particularly when it comes to vertical positioning and the space surrounding the button. If the layout is very precise, or if space is at a premium, it\u2019s always best to try and live with the browser\u2019s default form controls.\n\nWhichever way you go, it\u2019s important to remember that in general, each form field should have a label, and each form should have a submit button. If you find that your form breaks either of those rules, you should double check.\n\nPractical tips for handing files over\n\nThere are a couple of basic steps that a design can carry out to make sure that the developer has the best chance of implementing the design exactly as envisioned.\n\nIf working with Photoshop of Fireworks or similar comping tool, it helps to group and label layers to make it easy for a developer to see which need to be turned on and off to get to isolate parts of the page and different states of the design. Also, if you don\u2019t work in the same office as your developer (and so they can\u2019t quickly check with you), provide a PDF of each page and state so that your developer can see how each page should look aside from any confusion with quick layers are switched on or off. These also act as a handy quick reference that can be used without firing up Photoshop (which can kill both productivity and your machine).\n\nFinally, provide a colour reference showing the RGB values of all the key colours used throughout the design. Without this, the developer will end up colour-picking from the comps, and could potentially end up with different colours to those you intended. Remember, for a lot of developers, working in a tool like Photoshop is like presenting a designer with an SSH terminal into a web server. It\u2019s unfamiliar ground and easy to get things wrong. Be the expert of your own domain and help your colleagues out when they\u2019re out of their comfort zone. That goes both ways.\n\nIn conclusion\n\nWhen asked the question of how to smooth hand-over between design and development, almost everyone who has experienced this situation could come up with their own list. This one is mine, based on some of the more common experiences we have at edgeofmyseat.com. So in bullet point form, here\u2019s my checklist for handing a design over.\n\n\n\tIs the layout fixed, or fluid?\n\tDoes each element cope with expanding for larger text and more content?\n\tAre all the graphics large enough to cope with an area expanding?\n\tDoes each interactive element have a state for with and without JavaScript?\n\tDoes each element have a state for logged in and logged out users?\n\tHow are any custom fonts being displayed? (and does the developer have the font to use?)\n\tDoes each interactive element have error and success messages designed?\n\tDo all form fields have a label and each form a submit button?\n\tIs your Photoshop comp document well organised?\n\tHave you provided flat PDFs of each state?\n\tHave you provided a colour reference?\n\tAre we having fun yet?", "year": "2008", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2008-12-01T00:00:00+00:00", "url": "https://24ways.org/2008/easing-the-path-from-design-to-development/", "topic": "process"}
{"rowid": 124, "title": "Writing Responsible JavaScript", "contents": "Without a doubt, JavaScript has been making something of a comeback in the last year. If you\u2019re involved in client-side development in any way at all, chances are that you\u2019re finding yourself writing more JavaScript now than you have in a long time.\n\nIf you learned most of your JavaScript back when DHTML was all the rage and before DOM Scripting was in vogue, there have been some big shifts in the way scripts are written. Most of these are in the way event handlers are assigned and functions declared. Both of these changes are driven by the desire to write scripts that are responsible page citizens, both in not tying behaviour to content and in taking care not to conflict with other scripts. I thought it may be useful to look at some of these more responsible approaches to learn how to best write scripts that are independent of the page content and are safely portable between different applications.\n\nEvent Handling\n\nBack in the heady days of Web 1.0, if you wanted to have an object on the page react to something like a click, you would simply go ahead and attach an onclick attribute. This was easy and understandable, but much like the font tag or the style attribute, it has the downside of mixing behaviour or presentation in with our content. As we\u2019re learned with CSS, there are big benefits in keeping those layers separate. Hey, if it works for CSS, it should work for JavaScript too.\n\nJust like with CSS, instead of adding an attribute to our element within the document, the more responsible way to do that is to look for the item from your script (like CSS does with a selector) and then assign the behaviour to it. To give an example, take this oldskool onclick use case:\n\n<a id=\"anim-link\" href=\"#\" onclick=\"playAnimation()\">Play the animation</a>\n\nThis could be rewritten by removing the onclick attribute, and instead doing the following from within your JavaScript.\n\ndocument.getElementById('anim-link').onclick = playAnimation;\n\nIt\u2019s all in the timing\n\nOf course, it\u2019s never quite that easy. To be able to attach that onclick, the element you\u2019re targeting has to exist in the page, and the page has to have finished loading for the DOM to be available. This is where the onload event is handy, as it fires once everything has finished loading. Common practise is to have a function called something like init() (short for initialise) that sets up all these event handlers as soon as the page is ready.\n\nBack in the day we would have used the onload attibute on the <body> element to do this, but of course what we really want is:\n\nwindow.onload = init;\n\nAs an interesting side note, we\u2019re using init here rather than init() so that the function is assigned to the event. If we used the parentheses, the init function would have been run at that moment, and the result of running the function (rather than the function itself) would be assigned to the event. Subtle, but important.\n\nAs is becoming apparent, nothing is ever simple, and we can\u2019t just go around assigning our initialisation function to window.onload. What if we\u2019re using other scripts in the page that might also want to listen out for that event? Whichever script got there last would overwrite everything that came before it. To manage this, we need a script that checks for any existing event handlers, and adds the new handler to it. Most of the JavaScript libraries have their own systems for doing this. If you\u2019re not using a library, Simon Willison has a good stand-alone example\n\nfunction addLoadEvent(func) {\n\tvar oldonload = window.onload;\n\tif (typeof window.onload != 'function') {\n\t\twindow.onload = func;\n\t} else {\n\t\twindow.onload = function() {\n\t\t\tif (oldonload) {\n\t\t\t\toldonload();\n\t\t\t}\n\t\t\tfunc();\n\t\t}\n\t}\n}\n\nObviously this is just a toe in the events model\u2019s complex waters. Some good further reading is PPK\u2019s Introduction to Events.\n\nCarving out your own space\n\nAnother problem that rears its ugly head when combining multiple scripts on a single page is that of making sure that the scripts don\u2019t conflict. One big part of that is ensuring that no two scripts are trying to create functions or variables with the same names. Reusing a name in JavaScript just over-writes whatever was there before it.\n\nWhen you create a function in JavaScript, you\u2019ll be familiar with doing something like this.\n\nfunction foo() {\n\t... goodness ...\n}\n\nThis is actually just creating a variable called foo and assigning a function to it. It\u2019s essentially the same as the following.\n\nvar foo = function() {\n\t... goodness ...\n}\n\nThis name foo is by default created in what\u2019s known as the \u2018global namespace\u2019 \u2013 the general pool of variables within the page. You can quickly see that if two scripts use foo as a name, they will conflict because they\u2019re both creating those variables in the global namespace.\n\nA good solution to this problem is to add just one name into the global namespace, make that one item either a function or an object, and then add everything else you need inside that. This takes advantage of JavaScript\u2019s variable scoping to contain you mess and stop it interfering with anyone else.\n\nCreating An Object\n\nSay I was wanting to write a bunch of functions specifically for using on a site called \u2018Foo Online\u2019. I\u2019d want to create my own object with a name I think is likely to be unique to me.\n\nvar FOOONLINE = {};\n\nWe can then start assigning functions are variables to it like so:\n\nFOOONLINE.message = 'Merry Christmas!';\nFOOONLINE.showMessage = function() {\n\talert(this.message);\n};\n\nCalling FOOONLINE.showMessage() in this example would alert out our seasonal greeting. The exact same thing could also be expressed in the following way, using the object literal syntax.\n\nvar FOOONLINE = {\n\tmessage: 'Merry Christmas!',\n\tshowMessage: function() {\n\t\talert(this.message);\n\t}\n};\n\nCreating A Function to Create An Object\n\nWe can extend this idea bit further by using a function that we run in place to return an object. The end result is the same, but this time we can use closures to give us something like private methods and properties of our object.\n\nvar FOOONLINE = function(){\n\tvar message = 'Merry Christmas!';\n\treturn {\n\t\tshowMessage: function(){\n\t\t\talert(message);\n\t\t}\n\t}\n}();\n\nThere are two important things to note here. The first is the parentheses at the end of line 10. Just as we saw earlier, this runs the function in place and causes its result to be assigned. In this case the result of our function is the object that is returned at line 4.\n\nThe second important thing to note is the use of the var keyword on line 2. This ensures that the message variable is created inside the scope of the function and not in the global namespace. Because of the way closure works (which if you\u2019re not familiar with, just suspend your disbelief for a moment) that message variable is visible to everything inside the function but not outside. Trying to read FOOONLINE.message from the page would return undefined.\n\nThis is useful for simulating the concept of private class methods and properties that exist in other programming languages. I like to take the approach of making everything private unless I know it\u2019s going to be needed from outside, as it makes the interface into your code a lot clearer for someone else to read. \n\nAll Change, Please\n\nSo that was just a whistle-stop tour of a couple of the bigger changes that can help to make your scripts better page citizens. I hope it makes useful Sunday reading, but obviously this is only the tip of the iceberg when it comes to designing modular, reusable code.\n\nFor some, this is all familiar ground already. If that\u2019s the case, I encourage you to perhaps submit a comment with any useful resources you\u2019ve found that might help others get up to speed. Ultimately it\u2019s in all of our interests to make sure that all our JavaScript interoperates well \u2013 share your tips.", "year": "2006", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2006-12-10T00:00:00+00:00", "url": "https://24ways.org/2006/writing-responsible-javascript/", "topic": "code"}
{"rowid": 132, "title": "Tasty Text Trimmer", "contents": "In most cases, when designing a user interface it\u2019s best to make a decision about how data is best displayed and stick with it. Failing to make a decision ultimately leads to too many user options, which in turn can be taxing on the poor old user. \n\nUnder some circumstances, however, it\u2019s good to give the user freedom in customising their workspace. One good example of this is the \u2018Article Length\u2019 tool in Apple\u2019s Safari RSS reader. Sliding a slider left of right dynamically changes the length of each article shown. It\u2019s that kind of awesomey magic stuff that\u2019s enough to keep you from sleeping. Let\u2019s build one.\n\nThe Setup\n\nLet\u2019s take a page that has lots of long text items, a bit like a news page or like Safari\u2019s RSS items view. If we were to attach a class name to each element we wanted to resize, that would give us something to hook onto from the JavaScript. \n\nExample 1: The basic page.\n\nAs you can see, I\u2019ve wrapped my items in a DIV and added a class name of chunk to them. It\u2019s these chunks that we\u2019ll be finding with the JavaScript. Speaking of which \u2026\n\nOur Core Functions\n\nThere are two main tasks that need performing in our script. The first is to find the chunks we\u2019re going to be resizing and store their original contents away somewhere safe. We\u2019ll need this so that if we trim the text down we\u2019ll know what it was if the user decides they want it back again. We\u2019ll call this loadChunks. \n\nvar loadChunks = function(){\n\tvar everything = document.getElementsByTagName('*');\n\tvar i, l;\n\tchunks\t= [];\n\tfor (i=0, l=everything.length; i<l; i++){\n\t\tif (everything[i].className.indexOf(chunkClass) > -1){\n\t\t\tchunks.push({\n\t\t\t\tref: everything[i],\n\t\t\t\toriginal: everything[i].innerHTML\n\t\t\t});\n\t\t}\n\t}\n};\n\nThe variable chunks is stored outside of this function so that we can access it from our next core function, which is doTrim.\n\nvar doTrim = function(interval) {\n\tif (!chunks) loadChunks();\n\tvar i, l;\n\tfor (i=0, l=chunks.length; i<l; i++){\n\t\tvar a = chunks[i].original.split(' ');\n\t\ta = a.slice(0, interval);\n\t\tchunks[i].ref.innerHTML\t= a.join(' ');\n\t}\n};\n\nThe first thing that needs to be done is to call loadChunks if the chunks variable isn\u2019t set. This should only happen the first time doTrim is called, as from that point the chunks will be loaded.\n\nThen all we do is loop through the chunks and trim them. The trimming itself (lines 6-8) is very simple. We split the text into an array of words (line 6), then select only a portion from the beginning of the array up until the number we want (line 7). Finally the words are glued back together (line 8).\n\nIn essense, that\u2019s it, but it leaves us needing to know how to get the number into this function in the first place, and how that number is generated by the user. Let\u2019s look at the latter case first.\n\nThe YUI Slider Widget\n\nThere are lots of JavaScript libraries available at the moment. A fair few of those are really good. I use the Yahoo! User Interface Library professionally, but have only recently played with their pre-build slider widget. Turns out, it\u2019s pretty good and perfect for this task. \n\nOnce you have the library files linked in (check the docs linked above) it\u2019s fairly straightforward to create yourself a slider.\n\nslider = YAHOO.widget.Slider.getHorizSlider(\"sliderbg\", \"sliderthumb\", 0, 100, 5); \nslider.setValue(50);\nslider.subscribe(\"change\", doTrim);\n\nAll that\u2019s needed then is some CSS to make the slider look like a slider, and of course a few bits of HTML. We\u2019ll see those later.\n\nSee It Working!\n\nRather than spell out all the nuts and bolts of implementing this fairly simple script, let\u2019s just look at in it action and then pick on some interesting bits I\u2019ve added.\n\nExample 2: Try the Tasty Text Trimmer.\n\nAt the top of the JavaScript file I\u2019ve added a small number of settings.\n\nvar chunkClass\t= 'chunk';\nvar minValue\t= 10;\nvar maxValue\t= 100;\nvar multiplier\t= 5;\n\nObvious candidates for configuration are the class name used to find the chunks, and also the some minimum and maximum values. The minValue is the fewest number of words we wish to display when the slider is all the way down. The maxValue is the length of the slider, in this case 100.\n\nMoving the slider makes a call to our doTrim function with the current value of the slider. For a slider 100 pixels long, this is going to be in the range of 0-100. That might be okay for some things, but for longer items of text you\u2019ll want to allow for displaying more than 100 words. I\u2019ve accounted for this by adding in a multiplier \u2013 in my code I\u2019m multiplying the value by 5, so a slider value of 50 shows 250 words. You\u2019ll probably want to tailor the multiplier to the type of content you\u2019re using.\n\nKeeping it Accessible \n\nThis effect isn\u2019t something we can really achieve without JavaScript, but even so we must make sure that this functionality has no adverse impact on the page when JavaScript isn\u2019t available. This is achieved by adding the slider markup to the page from within the insertSliderHTML function.\n\nvar insertSliderHTML = function(){\n\tvar s = '<a id=\"slider-less\" href=\"#less\"><img src=\"icon_min.gif\" width=\"10\" height=\"10\" alt=\"Less text\" class=\"first\" /></a>';\n\ts +=' <div id=\"sliderbg\"><div id=\"sliderthumb\"><img src=\"sliderthumbimg.gif\" /></div></div>';\n\ts +=' <a id=\"slider-more\" href=\"#more\"><img src=\"icon_max.gif\" width=\"10\" height=\"10\" alt=\"More text\" /></a>';\n\tdocument.getElementById('slider').innerHTML = s;\n}\n\nThe other important factor to consider is that a slider can be tricky to use unless you have good eyesight and pretty well controlled motor skills. Therefore we should provide a method of changing the value by the keyboard.\n\nI\u2019ve done this by making the icons at either end of the slider links so they can be tabbed to. Clicking on either icon fires the appropriate JavaScript function to show more or less of the text.\n\nIn Conclusion\n\nThe upshot of all this is that without JavaScript the page just shows all the text as it normally would. With JavaScript we have a slider for trimming the text excepts that can be controlled with the mouse or with a keyboard.\n\nIf you\u2019re like me and have just scrolled to the bottom to find the working demo, here it is again:\n\nTry the Tasty Text Trimmer\n\nTrimmer for Christmas? Don\u2019t say I never give you anything!", "year": "2006", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2006-12-01T00:00:00+00:00", "url": "https://24ways.org/2006/tasty-text-trimmer/", "topic": "code"}
{"rowid": 165, "title": "Transparent PNGs in Internet Explorer 6", "contents": "Newer breeds of browser such as Firefox and Safari have offered support for PNG images with full alpha channel transparency for a few years. With the use of hacks, support has been available in Internet Explorer 5.5 and 6, but the hacks are non-ideal and have been tricky to use. With IE7 winning masses of users from earlier versions over the last year, full PNG alpha-channel transparency is becoming more of a reality for day-to-day use.\n\nHowever, there are still numbers of IE6 users out there who we can\u2019t leave out in the cold this Christmas, so in this article I\u2019m going to look what we can do to support IE6 users whilst taking full advantage of transparency for the majority of a site\u2019s visitors.\n\nSo what\u2019s alpha channel transparency?\n\nCast your minds back to the Ghost of Christmas Past, the humble GIF. Images in GIF format offer transparency, but that transparency is either on or off for any given pixel. Each pixel\u2019s either fully transparent, or a solid colour. In GIF, transparency is effectively just a special colour you can chose for a pixel.\n\nThe PNG format tackles the problem rather differently. As well as having any colour you chose, each pixel also carries a separate channel of information detailing how transparent it is. This alpha channel enables a pixel to be fully transparent, fully opaque, or critically, any step in between.\n\nThis enables designers to produce images that can have, for example, soft edges without any of the \u2018halo effect\u2019 traditionally associated with GIF transparency. If you\u2019ve ever worked on a site that has different colour schemes and therefore requires multiple versions of each graphic against a different colour, you\u2019ll immediately see the benefit. \n\nWhat\u2019s perhaps more interesting than that, however, is the extra creative freedom this gives designers in creating beautiful sites that can remain web-like in their ability to adjust, scale and reflow.\n\nThe Internet Explorer problem\n\nUp until IE7, there has been no fully native support for PNG alpha channel transparency in Internet Explorer. However, since IE5.5 there has been some support in the form of proprietary filter called the AlphaImageLoader. Internet Explorer filters can be applied directly in your CSS (for both inline and background images), or by setting the same CSS property with JavaScript. \n\nCSS:\n\nimg {\n\tfilter: progid:DXImageTransform.Microsoft.AlphaImageLoader(...);\n}\n\nJavaScript:\n\nimg.style.filter = \"progid:DXImageTransform.Microsoft.AlphaImageLoader(...)\";\n\nThat may sound like a problem solved, but all is not as it may appear. Firstly, as you may realise, there\u2019s no CSS property called filter in the W3C CSS spec. It\u2019s a proprietary extension added by Microsoft that could potentially cause other browsers to reject your entire CSS rule. \n\nSecondly, AlphaImageLoader does not magically add full PNG transparency support so that a PNG in the page will just start working. Instead, when applied to an element in the page, it draws a new rendering surface in the same space that element occupies and loads a PNG into it. If that sounds weird, it\u2019s because that\u2019s precisely what it is. However, by and large the result is that PNGs with an alpha channel can be accommodated.\n\nThe pitfalls\n\nSo, whilst support for PNG transparency in IE5.5 and 6 is possible, it\u2019s not without its problems.\n\nBackground images cannot be positioned or repeated\n\nThe AlphaImageLoader does work for background images, but only for the simplest of cases. If your design requires the image to be tiled (background-repeat) or positioned (background-position) you\u2019re out of luck. The AlphaImageLoader allows you to set a sizingMethod to either crop the image (if necessary) or to scale it to fit. Not massively useful, but something at least.\n\nDelayed loading and resource use\n\nThe AlphaImageLoader can be quite slow to load, and appears to consume more resources than a standard image when applied. Typically, you\u2019d need to add thousands of GIFs or JPEGs to a page before you saw any noticeable impact on the browser, but with the AlphaImageLoader filter applied Internet Explorer can become sluggish after just a handful of alpha channel PNGs.\n\nThe other noticeable effect is that as more instances of the AlphaImageLoader are applied, the longer it takes to render the PNGs with their transparency. The user sees the PNG load in its original non-supported state (with black or grey areas where transparency should be) before one by one the filter kicks in and makes them properly transparent.\n\nBoth the issue of sluggish behaviour and delayed load only really manifest themselves with volume and size of image. Use just a couple of instances and it\u2019s fine, but be careful adding more than five or six. As ever, test, test, test.\n\nLinks become unclickable, forms unfocusable \n\nThis is a big one. There\u2019s a bug/weirdness with AlphaImageLoader that sometimes prevents interaction with links and forms when a PNG background image is used. This is sometimes reported as a z-index issue, but I don\u2019t believe it is. Rather, it\u2019s an artefact of that weird way the filter gets applied to the document almost outside of the normal render process. \n\nOften this can be solved by giving the links or form elements hasLayout using position: relative; where possible. However, this doesn\u2019t always work and the non-interaction problem cannot always be solved. You may find yourself having to go back to the drawing board.\n\nSidestepping the danger zones\n\nFrankly, it\u2019s pretty bad news if you design a site, have that design signed off by your client, build it and then find out only at the end (because you don\u2019t know what might trigger a problem) that your search field can\u2019t be focused in IE6. That\u2019s an absolute nightmare, and whilst it\u2019s not likely to happen, it\u2019s possible that it might. It\u2019s happened to me. So what can you do?\n\nThe best approach I\u2019ve found to this scenario is\n\n\n\tIsolate the PNG or PNGs that are causing the problem. Step through the PNGs in your page, commenting them out one by one and retesting. Typically it\u2019ll be the nearest PNG to the problem, so try there first. Keep going until you can click your links or focus your form fields.\n\tThis is where you really need luck on your side, because you\u2019re going to have to fake it. This will depend on the design of the site, but some way or other create a replacement GIF or JPEG image that will give you an acceptable result. Then use conditional comments to serve that image to only users of IE older than version 7.\n\n\nA hack, you say? Well, you started it chum.\n\nApplying AlphaImageLoader\n\nBecause the filter property is invalid CSS, the safest pragmatic approach is to apply it selectively with JavaScript for only Internet Explorer versions 5.5 and 6. This helps ensure that by default you\u2019re serving standard CSS to browsers that support both the CSS and PNG standards correct, and then selectively patching up only the browsers that need it. \n\nSeveral years ago, Aaron Boodman wrote and released a script called sleight for doing just that. However, sleight dealt only with images in the page, and not background images applied with CSS. Building on top of Aaron\u2019s work, I hacked sleight and came up with bgsleight for applying the filter to background images instead. That was in 2003, and over the years I\u2019ve made a couple of improvements here and there to keep it ticking over and to resolve conflicts between sleight and bgsleight when used together. However, with alpha channel PNGs becoming much more widespread, it\u2019s time for a new version.\n\nIntroducing SuperSleight\n\nSuperSleight adds a number of new and useful features that have come from the day-to-day needs of working with PNGs.\n\n\n\tWorks with both inline and background images, replacing the need for both sleight and bgsleight\n\tWill automatically apply position: relative to links and form fields if they don\u2019t already have position set. (Can be disabled.)\n\tCan be run on the entire document, or just a selected part where you know the PNGs are. This is better for performance.\n\tDetects background images set to no-repeat and sets the scaleMode to crop rather than scale.\n\tCan be re-applied by any other JavaScript in the page \u2013 useful if new content has been loaded by an Ajax request.\n\n\n  Download SuperSleight \n\nImplementation\n\nGetting SuperSleight running on a page is quite straightforward, you just need to link the supplied JavaScript file (or the minified version if you prefer) into your document inside conditional comments so that it is delivered to only Internet Explorer 6 or older.\n\n<!--[if lte IE 6]>\n\t<script type=\"text/javascript\" src=\"supersleight-min.js\"></script>\n<![endif]-->\n\nSupplied with the JavaScript is a simple transparent GIF file. The script replaces the existing PNG with this before re-layering the PNG over the top using AlphaImageLoaded. You can change the name or path of the image in the top of the JavaScript file, where you\u2019ll also find the option to turn off the adding of position: relative to links and fields if you don\u2019t want that.\n\nThe script is kicked off with a call to supersleight.init() at the bottom. The scope of the script can be limited to just one part of the page by passing an ID of an element to supersleight.limitTo(). And that\u2019s all there is to it.\n\nUpdate March 2008: a version of this script as a jQuery plugin is also now available.", "year": "2007", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2007-12-01T00:00:00+00:00", "url": "https://24ways.org/2007/supersleight-transparent-png-in-ie6/", "topic": "code"}
{"rowid": 166, "title": "Performance On A Shoe String", "contents": "Back in the summer, I happened to notice the official Wimbledon All England Tennis Club site had jumped to the top of Alexa\u2019s Movers & Shakers list \u2014 a list that tracks sites that have had the biggest upturn or downturn in traffic. The lawn tennis championships were underway, and so traffic had leapt from almost nothing to crazy-busy in a no time at all. \n\nMany sites have similar peaks in traffic, especially when they\u2019re based around scheduled events. No one cares about the site for most of the year, and then all of a sudden \u2013 wham! \u2013 things start getting warm in the data centre. Whilst the thought of chestnuts roasting on an open server has a certain appeal, it\u2019s less attractive if you care about your site being available to visitors. Take a look at this Alexa traffic graph showing traffic patterns for superbowl.com at the beginning of each year, and wimbledon.org in the month of July.\n\nTraffic graph from Alexa.com \n\nWhilst not on the same scale or with such dramatic peaks, we have a similar pattern of traffic here at 24ways.org. Over the last three years we\u2019ve seen a dramatic pick up in traffic over the month of December (as would be expected) and then a much lower, although steady load throughout the year. What we do have, however, is the luxury of knowing when the peaks will be. For a normal site, be that a blog, small scale web app, or even a small corporate site, you often just cannot predict when you might get slashdotted, end up on the front page of Digg or linked to from a similarly high-profile site. You just don\u2019t know when the peaks will be.\n\nIf you\u2019re a big commercial enterprise like the Super Bowl, scaling up for that traffic is simply a cost of doing business. But for most of us, we can\u2019t afford to have massive capacity sat there unused for 90% of the year. What you have to do instead is work out how to deal with as much traffic as possible with the modest resources you have.\n\nIn this article I\u2019m going to talk about some of the things we\u2019ve learned about keeping 24 ways running throughout December, whilst not spending a fortune on hosting we don\u2019t need for 11 months of each year. We\u2019ve not always got it right, but we\u2019ve learned a lot along the way.\n\nThe Problem\n\nTo know how to deal with high traffic, you need to have a basic idea of what happens when a request comes into a web server. 24 ways is hosted on a single small virtual dedicated server with a great little hosting company in the UK. We run Apache with PHP and MySQL all on that one server. When a request comes in a new Apache process is started to deal with the request (or assigned if there\u2019s one available not doing anything). Each process takes a bunch of memory, so there\u2019s a finite number of processes that you can run, and therefore a finite number of pages you can serve at once before your server runs out of memory.\n\nWith our budget based on whatever is left over after beer, we need to get best performance we can out of the resources available. As the goal is to serve as many pages as quickly as possible, there are several approaches we can take:\n\n\n\tReducing the amount of memory needed by each Apache process\n\tReducing the amount of time each process is needed\n\tReducing the number of requests made to the server\n\n\nYahoo! have published some information on what they call Exceptional Performance, which is well worth reading, and compliments many of my examples here. The Yahoo! guidelines very much look at things from a user perspective, which is always important.\n\nServer tweaking\n\nIf you\u2019re in the position of being able to change your server configuration (our set-up gives us root access to what is effectively a virtual machine) there are some basic steps you can take to maximise the available memory and reduce the memory footprint. Without getting too boring and technical (whole books have been written on this) there are a couple of things to watch out for.\n\nFirstly, check what processes you have running that you might not need. Every megabyte of memory that you free up might equate to several thousand extra requests being served each day, so take a look at top and see what\u2019s using up your resources. Quite often a machine configured as a web server will have some kind of mail server running by default. If your site doesn\u2019t use mail (ours doesn\u2019t) make sure it\u2019s shut down and not using resources.\n\nSecondly, have a look at your Apache configuration and particularly what modules are loaded. The method for doing this varies between versions of Apache, but again, every module loaded increases the amount of memory that each Apache process requires and therefore limits the number of simultaneous requests you can deal with.\n\nThe final thing to check is that Apache isn\u2019t configured to start more servers than you have memory for. This is usually done by setting the MaxClients directive. When that limit is reached, your site is going to stop responding to further requests. However, if all else goes well that threshold won\u2019t be reached, and if it does it will at least stop the weight of the traffic taking the entire server down to a point where you can\u2019t even log in to sort it out.\n\nThose are the main tidbits I\u2019ve found useful for this site, although it\u2019s worth repeating that entire books have been written on this subject alone.\n\nCaching\n\nAlthough the site is generated with PHP and MySQL, the majority of pages served don\u2019t come from the database. The process of compiling a page on-the-fly involves quite a few trips to the database for content, templates, configuration settings and so on, and so can be slow and require a lot of CPU. Unless a new article or comment is published, the site doesn\u2019t actually change between requests and so it makes sense to generate each page once, save it to a file and then just serve all following requests from that file.\n\nWe use QuickCache (or rather a plugin based on it) for this. The plugin integrates with our publishing system (Textpattern) to make sure the cache is cleared when something on the site changes. A similar plugin called WP-Cache is available for WordPress, but of course this could be done any number of ways, and with any back-end technology.\n\nThe important principal here is to reduce the time it takes to serve a page by compiling the page once and serving that cached result to subsequent visitors. Keep away from your database if you can.\n\nOutsource your feeds\n\nWe get around 36,000 requests for our feed each day. That really only works out at about 7,000 subscribers averaging five-and-a-bit requests a day, but it\u2019s still 36,000 requests we could easily do without. Each request uses resources and particularly during December, all those requests can add up. \n\nThe simple solution here was to switch our feed over to using FeedBurner. We publish the address of the FeedBurner version of our feed here, so those 36,000 requests a day hit FeedBurner\u2019s servers rather than ours. In addition, we get pretty graphs showing how the subscriber-base is building.\n\n\n\nOff-load big files\n\nLarger files like images or downloads pose a problem not in bandwidth, but in the time it takes them to transfer. A typical page request is very quick, a few seconds at the most, resulting in the connection being freed up promptly. Anything that keeps a connection open for a long time is going to start killing performance very quickly.\n\nThis year, we started serving most of the images for articles from a subdomain \u2013 media.24ways.org. Rather than pointing to our own server, this subdomain points to an Amazon S3 account where the files are held. It\u2019s easy to pigeon-hole S3 as merely an online backup solution, and whilst not a fully fledged CDN, S3 works very nicely for serving larger media files. The roughly 20GB of files served this month have cost around $5 in Amazon S3 charges. That\u2019s so affordable it may not be worth even taking the files back off S3 once December has passed.\n\nI found this article on Scalable Media Hosting with Amazon S3 to be really useful in getting started. I upload the files via a Firefox plugin (mentioned in the article) and then edit the ACL to allow public access to the files. The way S3 enables you to point DNS directly at it means that you\u2019re not tied to always using the service, and that it can be transparent to your users.\n\nIf your site uses photographs, consider uploading them to a service like Flickr and serving them directly from there. Many photo sharing sites are happy for you to link to images in this way, but do check the acceptable use policies in case you need to provide a credit or link back.\n\nOff-load small files\n\nYou\u2019ll have noticed the pattern by now \u2013 get rid of as much traffic as possible. When an article has a lot of comments and each of those comments has an avatar along with it, a great many requests are needed to fetch each of those images. In 2006 we started using Gravatar for avatars, but their servers were slow and were holding up page loads. To get around this we started caching the images on our server, but along with that came the burden of furnishing all the image requests.\n\nEarlier this year Gravatar changed hands and is now run by the same team behind WordPress.com. Those guys clearly know what they\u2019re doing when it comes to high performance, so this year we went back to serving avatars directly from them.\n\nIf your site uses avatars, it really makes sense to use a service like Gravatar where your users probably already have an account, and where the image requests are going to be dealt with for you. \n\nKnow what you\u2019re paying for\n\nThe server account we use for 24 ways was opened in November 2005. When we first hit the front page of Digg in December of that year, we upgraded the server with a bit more memory, but other than that we were still running on that 2005 spec for two years. Of course, the world of technology has moved on in those years, prices have dropped and specs have improved. For the same amount we were paying for that 2005 spec server, we could have an account with twice the CPU, memory and disk space.\n\nSo in November of this year I took out a new account and transferred the site from the old server to the new. In that single step we were prepared for dealing with twice the amount of traffic, and because of a special offer at the time I didn\u2019t even have to pay the setup cost on the new server. So it really pays to know what you\u2019re paying for and keep an eye out of ways you can make improvements without needing to spend more money.\n\nFurther steps\n\nThere\u2019s nearly always more that can be done. For example, there are some media files (particularly for older articles) that are not on S3. We also serve our CSS directly and it\u2019s not minified or compressed. But by tackling the big problems first we\u2019ve managed to reduce load on the server and at the same time make sure that the load being placed on the server can be dealt with in the most frugal way.\n\nOver the last 24 days we\u2019ve served up articles to more than 350,000 visitors without breaking a sweat. On a busy day, that\u2019s been nearly 20,000 visitors in just 24 hours. While in the grand scheme of things that\u2019s not a huge amount of traffic, it can be a lot if you\u2019re not prepared for it. However, with a little planning for the peaks you can help ensure that when the traffic arrives you\u2019re ready to capitalise on it.\n\nOf course, people only visit 24 ways for the wealth of knowledge and experience that\u2019s tied up in the articles here. Therefore I\u2019d like to take the opportunity to thank all our authors this year who have given their time as a gift to the community, and to wish you all a very happy Christmas.", "year": "2007", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2007-12-24T00:00:00+00:00", "url": "https://24ways.org/2007/performance-on-a-shoe-string/", "topic": "ux"}
{"rowid": 181, "title": "Working With RGBA Colour", "contents": "When Tim and I were discussing the redesign of this site last year, one of the clear goals was to have a graphical style without making the pages heavy with a lot of images. When we launched, a lot of people were surprised that the design wasn\u2019t built with PNGs. Instead we\u2019d used RGBA colour values, which is part of the CSS3 specification.\n\nWhat is RGBA Colour?\n\nWe\u2019re all familiar with specifying colours in CSS using by defining the mix of red, green and blue light required to achieve our tone. This is fine and dandy, but whatever values we specify have one thing in common \u2014 the colours are all solid, flat, and well, a bit boring.\n\n Flat RGB colours\n\nCSS3 introduces a couple of new ways to specify colours, and one of those is RGBA. The A stands for Alpha, which refers to the level of opacity of the colour, or to put it another way, the amount of transparency. This means that we can set not only the red, green and blue values, but also control how much of what\u2019s behind the colour shows through. Like with layers in Photoshop.\n\nDon\u2019t We Have Opacity Already?\n\nThe ability to set the opacity on a colour differs subtly from setting the opacity on an element using the CSS opacity property. Let\u2019s look at an example.\n\nHere we have an H1 with foreground and background colours set against a page with a patterned background.\n\n Heading with no transparency applied\n\nh1 {\n\tcolor: rgb(0, 0, 0);\n\tbackground-color: rgb(255, 255, 255);\n}\n\nBy setting the CSS opacity property, we can adjust the transparency of the entire element and its contents:\n\n Heading with 50% opacity on the element\n\nh1 {\n\tcolor: rgb(0, 0, 0);\n\tbackground-color: rgb(255, 255, 255);\n\topacity: 0.5;\n}\n\nRGBA colour gives us something different \u2013 the ability to control the opacity of the individual colours rather than the entire element. So we can set the opacity on just the background:\n\n 50% opacity on just the background colour\n\nh1 {\n\tcolor: rgb(0, 0, 0);\n\tbackground-color: rgba(255, 255, 255, 0.5);\n}\n\nOr leave the background solid and change the opacity on just the text:\n\n 50% opacity on just the foreground colour\n\nh1 {\n\tcolor: rgba(0, 0, 0, 0.5);\n\tbackground-color: rgb(255, 255, 255);\n}\n\nThe How-To\n\nYou\u2019ll notice that above I\u2019ve been using the rgb() syntax for specifying colours. This is a bit less common than the usual hex codes (like #FFF) but it makes sense when starting to use RGBA. As there\u2019s no way to specify opacity with hex codes, we use rgba() like so:\n\ncolor: rgba(255, 255, 255, 0.5);\n\nJust like rgb() the first three values are red, green and blue. You can specify these 0-255 or 0%-100%. The fourth value is the opacity level from 0 (completely transparent) to 1 (completely opaque).\n\nYou can use this anywhere you\u2019d normally set a colour in CSS \u2014 so it\u2019s good for foregrounds and background, borders, outlines and so on. All the transparency effects on this site\u2019s current design are achieved this way.\n\nSupporting All Browsers\n\nLike a lot of the features we\u2019ll be looking at in this year\u2019s 24 ways, RGBA colour is supported by a lot of the newest browsers, but not the rest. Firefox, Safari, Chrome and Opera browsers all support RGBA, but Internet Explorer does not.\n\nFortunately, due to the robust design of CSS as a language, we can specify RGBA colours for browsers that support it and an alternative for browsers that do not.\n\nFalling back to solid colour\n\nThe simplest technique is to allow the browser to fall back to using a solid colour when opacity isn\u2019t available. The CSS parsing rules specify that any unrecognised value should be ignored. We can make use of this because a browser without RGBA support will treat a colour value specified with rgba() as unrecognised and discard it.\n\nSo if we specify the colour first using rgb() for all browsers, we can then overwrite it with an rgba() colour for browsers that understand RGBA.\n\nh1 {\n\tcolor: rgb(127, 127, 127);\n\tcolor: rgba(0, 0, 0, 0.5);\n}\n\nFalling back to a PNG\n\nIn cases where you\u2019re using transparency on a background-color (although not on borders or text) it\u2019s possible to fall back to using a PNG with alpha channel to get the same effect. This is less flexible than using CSS as you\u2019ll need to create a new PNG for each level of transparency required, but it can be a useful solution.\n\nUsing the same principal as before, we can specify the background in a style that all browsers will understand, and then overwrite it in a way that browsers without RGBA support will ignore.\n\nh1 {\n\tbackground: transparent url(black50.png);\n\tbackground: rgba(0, 0, 0, 0.5) none;\n}\n\nIt\u2019s important to note that this works because we\u2019re using the background shorthand property, enabling us to set both the background colour and background image in a single declaration. It\u2019s this that enables us to rely on the browser ignoring the second declaration when it encounters the unknown rgba() value.\n\nNext Steps\n\nThe really great thing about RGBA colour is that it gives us the ability to create far more graphically rich designs without the need to use images. Not only does that make for faster and lighter pages, but sites which are easier and quicker to build and maintain. CSS values can also be changed in response to user interaction or even manipulated with JavaScript in a way that\u2019s just not so easy using images.\n\n Opacity can be changed on :hover or manipulated with JavaScript\n\ndiv {\n\tcolor: rgba(255, 255, 255, 0.8);\n\tbackground-color: rgba(142, 213, 87, 0.3);\n}\ndiv:hover {\n\tcolor: rgba(255, 255, 255, 1);\n\tbackground-color: rgba(142, 213, 87, 0.6);\n}\n\nClever use of transparency in border colours can help ease the transition between overlay items and the page behind.\n\n Borders can receive the RGBA treatment, too\n\ndiv {\n\tcolor: rgb(0, 0, 0);\n\tbackground-color: rgb(255, 255, 255);\n\tborder: 10px solid rgba(255, 255, 255, 0.3);\n}\n\nIn Conclusion\n\n\nThat\u2019s a brief insight into RGBA colour, what it\u2019s good for and how it can be used whilst providing support for older browsers. With the current lack of support in Internet Explorer, it\u2019s probably not a technique that commercial designs will want to heavily rely on right away \u2013 simply because of the overhead of needing to think about fallback all the time. \n\nIt is, however, a useful tool to have for those smaller, less critical touches that can really help to finesse a design. As browser support becomes more mainstream, you\u2019ll already be familiar and practised with RGBA and ready to go.", "year": "2009", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2009-12-01T00:00:00+00:00", "url": "https://24ways.org/2009/working-with-rgba-colour/", "topic": "code"}
{"rowid": 208, "title": "All That Glisters", "contents": "Tradition has it that at this time of year, families gather together, sit, eat and share stories. It\u2019s an opportunity for the wisdom of the elders to be passed down to the younger members of the tribe. Tradition also has it that we should chase cheese downhill and dunk the nice lady to prove she\u2019s a witch, so maybe let\u2019s not put too much stock in that.\nI\u2019ve been building things on the web professionally for about twenty years, and although the web has changed immeasurably, it\u2019s probably not changed as much as I have. While I can happily say I\u2019m not the young (always right, always arrogant) developer that I once was, unfortunately I\u2019m now an approaching-middle-age developer who thinks he\u2019s always right and on top of it is extremely pompous. What can you do? Nature has devised this system with the distinct advantage of allowing us to always be right, and only ever wrong in the future or in the past. So let\u2019s roll with it.\nIncreasingly, there seems to be a sense of fatigue within our industry. Just when you think you\u2019ve got a handle on whatever the latest tool or technology is, something new comes out to replace it. Suddenly you find that you\u2019ve invested precious time learning something new and it\u2019s already old hat. The pace of change is so rapid, that new developers don\u2019t know where to start, and experienced developers don\u2019t know where it ends. With that in mind, here\u2019s some fireside thoughts from a pompous old developer, that I hope might bring some Christmas comfort.\nReliable and boring beats shiny and new\nThere are so many new tools, frameworks, techniques, styles and libraries to learn. You know what? You don\u2019t have to use them. You\u2019re not a bad developer if you use Grunt even though others have switched to Gulp or Brunch or Webpack or Banana Sandwich. It\u2019s probably misguided to spend lots of project time messing around with build tool fashions when your so last year build tool is already doing what you need.\nJust a little reminder that it\u2019s about 100 times more important what you build than how you build it.\u2014 Chris Coyier (@chriscoyier) December 10, 2017\n\nI think it helps if we understand why so many new solutions exist. Most developers are predisposed to enjoy creating new things more than improving established systems. It\u2019s natural, because it\u2019s actually much easier and more exciting to create something new that works exactly how you think it should be than to improve an existing, imperfect solution. Improving and refactoring a system is hard, and it takes real chops, much more than just building something new.\nThe consequence of this is that new tools appear all the time. A developer will get a fresh new idea of how to tackle a problem \u2013 usually out of dissatisfaction with an existing solution, and figure the best way to implement that idea is to build something new around it. Often, that something new will do the same job as something old that already exists; it will just do it in a different way. Sometimes in a better way. Sometimes, just different.\nxkcd: Standards\nThat\u2019s not to say new tools are bad, and it\u2019s not bad that they exist. We shouldn\u2019t be crushing new ideas, and it\u2019s not wrong to adopt a new solution over an old one, but you know what? There\u2019s no imperative to switch right away. The next time you hit a pain point with your current solution, or have time to re-evaluate, check out what\u2019s new and see how the latest generation of tools and technologies can help. There\u2019s no prize for solving problems you don\u2019t have yet, and heading further into the desert in search of water is a survival tactic, not an aspiration.\nNew is better, but also worse\nSoftware, much like people, is born with a whole lot of potential and not much utility. Newborns \u2014 both digital and meaty \u2014 are exciting and cute but they also lead to sleepless nights and pools of vomit.\nNew technology contains lots of useful new features, but it\u2019s also more likely to contain bugs and be subject to more rapid change. Jumping on a new framework is great, right until there are API changes and you need to refactor your entire project to be able to update. More mature solutions have a higher weight of existing projects on their shoulders, and so the need to maintain backward compatibility is stronger. Things still move forward, but in a more controlled way.\nSo how do we balance the need to move technology forward with the need to provide mature and stable solutions for the projects we work on? I think there\u2019s a couple of good ways to do that.\nGet personal\nUse all the new shiny tools on your side-projects, personal projects, seasonal throw-aways and anywhere where the stakes are low. If you know you can patch around problems without much consequence, go for it. Build your personal blog on a CMS that stores data in the woven bark of a silver birch. Find where it breaks. Find where it excels. Find yourself if you like. When it comes to high-stakes projects, you\u2019ll hopefully have enough experience to know what you\u2019re getting into.\nFocus on the unique problem\nThat\u2019s not to say you should never risk using a new technology for \u2018real\u2019 work. Instead, distinguish the areas of your project where a new technology solves a specifically identified, measurable business objective, verses those where it won\u2019t. \nA brand new web application framework might be fun to use, but are you in the business of solving a web application framework problem?  That new web server made of taffeta might increase static file throughput slightly, but are you in the business of serving static assets, or would it be better to just run up nginx and never have to think about that problem again. (Clue: it\u2019s the nginx one.)\nBut when it comes to building that live sports interface for keeping fans up to date with the blow-by-blow of the big game, that\u2019s where it might make sense to take a risk on an amazing-looking new JavaScript realtime interface framework. That\u2019s the time to run up a breakthrough new message queue server that can deliver jobs to workers via extrasensory perception and keep the score updates flowing instantaneously. \nThose are the risks worth taking, as those new technologies have the potential to help you solve your core problems in a markedly improved way. Unproven technology is worth the risk if it solves a specific business objective. If it doesn\u2019t, don\u2019t make work for yourself - use something mature and stable.\nPick the right tools\nOur job as developers is to solve problems using code, and do so in an effective and responsible way. You\u2019ve been hired to use your expertise in picking the right tools for the job, and a big part of that is weighing up the risk verse the reward of each part of the system. The best tools for the job might be something cutting edge, but \u2018best\u2019 can also mean most stable, reliable or easy-to-hire-for.\nGo out and learn (and create!) new tools and experiment with them. Understand what problems they solve and what the pitfalls are. Use them in production for low-stakes projects to get real experience, and then once you really know their character, then think about using them when the stakes are higher.\nThe rest of the time? The tools you\u2019re using now are solid and proven and you know their capabilities and pitfalls well. They might not always be the fashionable candidate, but they often make for a very solid choice.", "year": "2017", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2017-12-24T00:00:00+00:00", "url": "https://24ways.org/2017/all-that-glisters/", "topic": "business"}
{"rowid": 220, "title": "Finding Your Way with Static Maps", "contents": "Since the introduction of the Google Maps service in 2005, online maps have taken off in a way not really possible before the invention of slippy map interaction. Although quickly followed by a plethora of similar services from both commercial and non-commercial parties, Google\u2019s first-mover advantage, and easy-to-use developer API saw Google Maps become pretty much the de facto mapping service.\n\n\n\nIt\u2019s now so easy to add a map to a web page, there\u2019s no reason not to. Dropping an iframe map into your page is as simple as embedding a YouTube video.\n\nBut there\u2019s one crucial drawback to both the solution Google provides for you to drop into your page and the code developers typically implement themselves \u2013 they don\u2019t work without JavaScript.\n\nA bit about JavaScript\n\nBack in October of this year, The Yahoo! Developer Network blog ran some tests to measure how many visitors to the Yahoo! home page didn\u2019t have JavaScript available or enabled in their browser. It\u2019s an interesting test when you consider that the audience for the Yahoo! home page (one of the most visited pages on the web) represents about as mainstream a sample as you\u2019ll find. If there\u2019s any such thing as an \u2018average Web user\u2019 then this is them.\n\nThe results surprised me. It varied from region to region, but at most just two per cent of visitors didn\u2019t have JavaScript running. To be honest, I was expecting it to be higher, but this quote from the article caught my attention:\n\n\n\tWhile the percentage of visitors with JavaScript disabled seems like a low number, keep in mind that small percentages of big numbers are also big numbers.\n\n\nThat\u2019s right, of course, and it got me thinking about what that two per cent means. For many sites, two per cent is the number of visitors using the Opera web browser, using IE6, or using Mobile Safari. \n\nSo, although a small percentage of the total, users without JavaScript can\u2019t just be forgotten about, and catering for them is at the very heart of how the web is supposed to work.\n\nStarting with content in HTML, we layer on presentation with CSS and then enhance interactivity with JavaScript. If anything fails along the way or the network craps out, or a browser just doesn\u2019t support one of the technologies, the user still gets something they can work with. \n\nIt\u2019s progressive enhancement \u2013 also known as doing our jobs properly.\n\nSorry, wasn\u2019t this about maps?\n\nAs I was saying, the default code Google provides, and the example code it gives to developers (which typically just gets followed \u2018as is\u2019) doesn\u2019t account for users without JavaScript. No JavaScript, no content.\n\nWhen adding the ability to publish maps to our small content management system Perch, I didn\u2019t want to provide a solution that only worked with JavaScript. I had to go looking for a way to provide maps without JavaScript, too.\n\nThere\u2019s a simple solution, fortunately, in the form of static map tiles. All the various slippy map services use a JavaScript interface on top of what are basically rendered map image tiles. Dragging the map loads in more image tiles in the direction you want to view. If you\u2019ve used a slippy map on a slow connection, you\u2019ll be familiar with seeing these tiles load in one by one.\n\nThe Static Map API\n\nThe good news is that these tiles (or tiles just like them) can be used as regular images on your site. Google has a Static Map API which not only gives you a handy interface to retrieve a tile for the exact area you need, but also allows you to place pins, and zoom and centre the tile so that the image looks just so. \n\nThis means that you can create a static, non-JavaScript version of your slippy map\u2019s initial (or ideal) state to load into your page as a regular image, and then have the JavaScript map hijack the image and make it slippy.\n\nClearly, that\u2019s not going to be a perfect solution for every map\u2019s requirements. It doesn\u2019t allow for panning, zooming or interrogation without JavaScript. However, for the majority of straightforward map uses online, a static map makes a great alternative for those visitors without JavaScript.\n\n\n\nHere\u2019s the how\n\nRetrieving a static map tile is staggeringly easy \u2013 it\u2019s just a case of forming a URL with the correct arguments and then using that as the src of an image tag.\n\n<img src=\"http://maps.google.com/maps/api/staticmap\n\t?center=Bethlehem+Israel\n\t&zoom=5\n\t&size=540x280\n\t&maptype=satellite\n\t&markers=color:red|31.4211,35.1144\n\t&sensor=false\" \n\twidth=\"540\" height=\"280\" alt=\"Map of Bethlehem, Israel\" />\n\nAs you can see, there are a few key options that we pass along to the base URL. All of these should be familiar to anyone who\u2019s worked with the JavaScript API.\n\n\n\tcenter determines the point on which the map is centred. This can be latitude and longitude values, or simply an address which is then geocoded.\n\tzoom sets the zoom level.\n\tsize is the pixel dimensions of the image you require.\n\tmaptype can be roadmap, satellite, terrain or hybrid.\n\tmarkers sets one or more pin locations. Markers can be labelled, have different colours, and so on \u2013 there\u2019s quite a lot of control available.\n\tsensor states whether you are using a sensor to determine the user\u2019s location. When just embedding a map in a web page, set this to false.\n\n\nThere are many options, including plotting paths and setting the image format, which can all be found in the straightforward documentation.\n\nAdding to your page\n\nIf you\u2019ve worked with the JavaScript API, you\u2019ll know that it needs a container element which you inject the map into:\n\n<div id=\"map\"></div>\n\nAll you need to do is put your static image inside that container:\n\n<div id=\"map\">\n   <img src=\"http://maps.google.com/maps/api/staticmap[...]\" />\n </div>\n\nAnd then, in your JavaScript, find the image and remove it. For example, with jQuery you\u2019d simply use:\n\n$('#map img').remove();\n\nWhy not use a <noscript> element around the image? You could, and that would certainly work fine for browsers that do not support JavaScript. What that won\u2019t cover, however, is the situation where the browser has JavaScript support but, for whatever reason, the JavaScript doesn\u2019t run. This could be due to network issues, an aggressive corporate firewall, or even just a bug in your code. So for that reason, we put the image in for all browsers that show images, and then remove it when the JavaScript is  successfully running.\n\nSee an example in action\n\nAbout rate limits\n\nThe Google Static Map API limits the requests per site viewer \u2013 currently at one thousand distinct maps per day per viewer. So, for most sites you really don\u2019t need to worry about the rate limit. Requests for the same tile aren\u2019t normally counted, as the tile has already been generated and is cached. You can embed the images direct from Google and let it worry about the distribution and caching.\n\nIn conclusion\n\nAs you can see, adding a static map alongside your dynamic map for those users without JavaScript is very easy indeed. There may not be a huge percentage of web visitors browsing without JavaScript but, as we\u2019ve seen, a small percentage of a big number is still a big number. When it\u2019s so easy to add a static map, can you really justify not doing it?", "year": "2010", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2010-12-01T00:00:00+00:00", "url": "https://24ways.org/2010/finding-your-way-with-static-maps/", "topic": "code"}
{"rowid": 264, "title": "Dynamic Social Sharing Images", "contents": "Way back when social media was new, you could be pretty sure that whatever you posted would be read by those who follow you. If you\u2019d written a blog post and you wanted to share it with those who follow you, you could post a link and your followers would see it in their streams. Oh heady days! \nWith so many social channels and a proliferation of content and promotions flying past in everyone\u2019s streams, it\u2019s no longer enough to share content on social media, you have to actively sell it if you want it to be seen. You really need to make the most of every opportunity to catch a reader\u2019s attention if you\u2019re trying to get as many eyes as possible on that sweet, sweet social content.\nOne of the best ways to grab attention with your posts or tweets is to include an image. There\u2019s heaps of research that says that having images in your posts helps them stand out to followers. Reports I found showed figures from anything from 35% to 150% improvement from just having image in a post. Unfortunately, the details were surrounded with gross words like engagement and visual marketing assets and so I had to close the page before I started to hate myself too much.\nSo without hard stats to quote, we\u2019ll call it a rule of thumb. The rule of thumb is that posts with images will grab more attention than those without, so it makes sense that when adding pages to a website, you should make sure that they have social media sharing images associated with them.\nAdding sharing images\nThe process for declaring an image to be used in places like Facebook and Twitter is very simple, and at this point is familiar to many of us. You add a meta tag to the head of the page to point to the location of the image to use. When a link to the page is added to a post, the social network will fetch the page, look for the meta tag and then use the image you specified.\n<meta property=\"og:image\" content=\"https://example.com/my_image.jpg\">\nThere\u2019s a good post on this over at CSS-Tricks if you need to bone up on the details of this and other similar meta tags for social media sharing.\nThis is all fine and well for content that has a very obvious choice of image to go along with it, but what if you don\u2019t necessarily have an image? One approach is to use stock photography, but that\u2019s not going to be right for every situation.\nThis was something we faced with 24 ways in 2017. We wanted to add images to the tweets we post each day announcing a new article. Some articles have images, but not all, and there tended not to be any consistency in terms of imagery from one article to the next. We always have an author photograph, but those don\u2019t usually lend themselves directly to being the main \u2018hero\u2019 image for an article.\nPutting his thinking cap on, Paul came up with a design for an image that used the author photo along with a quote extracted from the article.\nOne of the hand-made sharing images from 2017\nEach day we would pick a quote from the article, and Paul would manually compose an image to be uploaded to the site. The results were great, but the whole process was a bit too labour intensive and relied on an individual (Paul) being available each day to do the work. I thought we could probably improve this.\nHatching a new plan\nOne initial idea I came up with was to script the image editor to dynamically build a new image by pulling content from our database. Sketch has plugins available to pull JSON content into a design, and our CMS can easily output JSON data, so that was one possibility.\nThe more I thought about this and how much I wish graphic design tools worked just a little bit more like CSS, the obvious solution hit me. We should just build it with CSS!\nIn fact, as the author name and image already exist in our CMS, and the visual styling is based on the design of the website, couldn\u2019t this just be another page on the site generated by the CMS?\nBreaking it down, I figured the steps needed would be something like:\n\nCreate the CSS to lay out a component that could be turned into an image\nAdd a new field to articles in the CMS to hold a handpicked quote\nBuild a new article template in the CMS to output the author name and quote dynamically for any article\n\u2026 um \u2026 screenshot?\n\nI thought I\u2019d get cracking and see if I could figure out the final steps later.\nBuilding the page\nThe first thing to tackle was the basic HTML and CSS to lay out the components for our image. That bit was really easy, as I just asked Paul to do it. Everyone should have a Paul.\nPaul\u2019s code uses a fixed dimension container in the HTML, set to 600 \u00d7 315px. This is to make it the correct aspect ratio for Facebook\u2019s recommended image size. It\u2019s useful to remember here that it doesn\u2019t need to be responsive or robust, as the page only needs to lay out correctly for a screenshot and a fixed size in a known browser.\nWith the markup and CSS in place, I turned this into a new template. Our CMS can easily display content through any number of templates, so I created a version of the article template that was totally stripped down. It only included the author details and the quote, along with Paul\u2019s markup.\nI also added the quote as a new field on the article in the CMS, so each \u2018image\u2019 could be quickly and easily customised in the editing process.\nI added a new field to the article template to capture the quote.\nWith very little effort, we quickly had a page to dynamically generate our \u2018image\u2019 right from the CMS. You can see any of them by adding /sharing onto the end of an article URL for any 2018 article.\nOur automatically generated layout direct from the CMS\nIt soon became clear that the elusive Step 4 was going to be the tricky part. I can create a small page on the site that looks like an image, but how should I go about turning it into one? An obvious route is to screenshot the page by hand, but that\u2019s going back to some of the manual steps I was trying to eliminate, and also opens up a possibility for errors to be made. But it did lead me to the thought\u2026 how could I automatically take a screenshot?\nEnter Puppeteer\nPuppeteer is a Node.js library that provides a nice API onto Headless Chrome. What is Headless Chrome, you ask? It\u2019s just a version of the Chrome browser than runs from the command line without ever drawing anything to a user interface window. It loads pages, renders CSS, runs JavaScript, pretty much every normal thing that Chrome on the desktop does, but without a clicky user interface.\nHeadless Chrome can be used for all sorts of things such as running automated tests on front-end code after making changes, or\u2026 get this\u2026 rendering pages that can be used for screenshots. The actual process of writing some code to control Chrome and to take the screenshot is where Puppeteer comes in. Puppeteer puts a friendly layer in front of big old scary Chrome to enable us to interact with it using simple JavaScript code running in Node.\nUsing Puppeteer, I can write a small script that will repeatably turn a URL into an image. So simple is it to do this, that\u2019s it\u2019s actually Puppeteer\u2019s \u2018hello world\u2019 example.\nFirst you install Puppeteer. It downloads a compatible headless browser (actually Chromium) as a dependancy, so you don\u2019t need to worry about installing that. At the command line:\nnpm i puppeteer\nThen save a new file as example.js with this code:\nconst puppeteer = require('puppeteer');\n\n(async () => {\n  const browser = await puppeteer.launch();\n  const page = await browser.newPage();\n  await page.goto('https://example.com');\n  await page.screenshot({path: 'example.png'});\n  await browser.close();\n})();\nand then run it using Node:\nnode example.js\nThis will output an image file example.png to disk, which contains a screenshot of, in this case https://example.com. The logic of the code is reasonably easy to follow:\n\nLaunch a browser\nOpen up a new page\nGoto a URL\nTake a screenshot\nClose the browser\n\nThe async function and await keywords are a way to have the script pause and wait for normally asynchronous code to return before proceeding. That\u2019s useful with actions like loading a web page that might take some time to complete. They\u2019re used with Promises, and the effect is to make asynchronous code behave as if it\u2019s synchronous. You can read more about async and await at MDN if you\u2019re interested.\nThat\u2019s a good proof-of-concept using the basic Puppeteer example. I can take a screenshot of a URL! But what happens if I put the URL of my new special page in there?\nOur content is up in the corner of the image with lots of empty space.\nThat\u2019s not great. It\u2019s okay, but not great. It looks like that, by default, Puppeteer takes a screenshot with a resolution of 800 \u00d7 600, so we need to find out how to adjust that. Fortunately, the docs aren\u2019t the worst and I was able to find the page.setViewport() method pretty easily.\nconst puppeteer = require('puppeteer');\n\n(async () => {\n  const browser = await puppeteer.launch();\n  const page = await browser.newPage();\n  await page.goto('https://24ways.org/2018/clip-paths-know-no-bounds/sharing');\n  await page.setViewport({\n    width: 600,\n    height: 315\n  });\n  await page.screenshot({path: 'example.png'});\n  await browser.close();\n})();\nThis worked! The screenshot is now 600 \u00d7 315 as expected. That\u2019s exactly what we asked for. Trouble is, that\u2019s a bit low res and it is nearly 2019 after all. While in those docs, I noticed the deviceScaleFactor option that can be passed to page.setViewport(). Setting that to 2 gives us an image of the same area of the screen, but with twice as many pixels.\n  await page.setViewport({\n    width: 600,\n    height: 315,\n    deviceScaleFactor: 2\n  });\nPerfect! We now have a programmatic way of turning a URL into an image.\nImproving the script\nRather than having a script with a fixed URL in it that outputs an image called example.png, the next step is to make that a bit more dynamic. The aim here is to have a script that we can run with a URL as an argument and have it output an image for that one page. That way we can run it manually, or hook it into part of our site\u2019s build process to automate the generation of the image.\nOur goal is to call the script like this:\nnode shoot-sharing-image.js https://24ways.org/2018/clip-paths-know-no-bounds/\nAnd I want the image to come out with the name clip-paths-know-no-bounds.png. To do that, I need to have my script look for command arguments, and then to split the URL up to grab the slug from it.\n// Get the URL and the slug segment from it\nconst url = process.argv[2];\nconst segments = url.split('/');\n// Get the second-to-last segment (the slug)\nconst slug = segments[segments.length-2];\nWe can then use these variables later in the script, remembering to add sharing back onto the end of the URL to get our dedicated page.\n(async () => {\n  const browser = await puppeteer.launch();\n  const page = await browser.newPage();\n  await page.goto(url + 'sharing');\n  await page.setViewport({\n    width: 600,\n    height: 315,\n    deviceScaleFactor: 2\n  });\n  await page.screenshot({path: slug + '.png'});\n  await browser.close();\n})();\nOnce you\u2019re generating the image with Node, there\u2019s all sorts of things you can do with it. An obvious step is to move it to the correct location within your site or project.\nYou can also run optimisations on the file. I\u2019m using imagemin with pngquant to reduce the file size a little.\nconst imagemin = require('imagemin');\nconst imageminPngquant = require('imagemin-pngquant');\n\nawait imagemin([slug + '.png'], 'build', {\n  plugins: [\n    imageminPngquant({quality: '75-90'})\n  ]\n});\n\nYou can see the completed example as a gist.\nIntegrating it with your CMS\nSo we now have a command we can run to take a URL and generate a custom image for that URL. It\u2019s in a format that can be called by any sort of build script, or triggered from a publishing hook in a CMS. Exactly how you do that is going to depend on the way your site is built and the technology stack you\u2019re using, but it\u2019s likely not too hard as long as you can run a command as part of the process.\nFor 24 ways this year, I\u2019ve been running the script by hand once each article is ready. My script adds the file to a git repo and pushes to a deployment remote that is configured to automatically deploy static assets to our server. Along with our theme of making incremental improvements, next year I\u2019ll look to automate this one step further.\nWe may also look at having a few slightly different layouts to choose from, so that each day isn\u2019t exactly the same as the last. Interestingly, we could even try some A/B tests to see if there\u2019s any particular format of image or type of quote that does a better job of grabbing attention. There are lots of possibilities!\n\nBy using a bit of ingenuity, some custom CMS templates, and the very useful Puppeteer project, we\u2019ve been able to reliably produce dynamic social media sharing images for all of our articles. In doing so, we reduced the dependancy on any individual for producing those images, and opened up a world of possibilities in how we use those images.\nI hope you\u2019ll give it a try!", "year": "2018", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2018-12-24T00:00:00+00:00", "url": "https://24ways.org/2018/dynamic-social-sharing-images/", "topic": "code"}
{"rowid": 271, "title": "Creating Custom Font Stacks with Unicode-Range", "contents": "Any web designer or front-end developer worth their salt will be familiar with the CSS @font-face rule used for embedding fonts in a web page. We\u2019ve all used it \u2014 either directly in our code ourselves, or via one of the web font services like Fontdeck, Typekit or Google Fonts.\n\nIf you\u2019re like me, however, you\u2019ll be used to just copying and pasting in a specific incantation of lines designed to get different formats of fonts working in different browsers, and may not have really explored all the capabilities of @font-face properties as defined by the spec.\n\nOne such property \u2014 the unicode-range descriptor \u2014 sounds pretty dull and is easily overlooked. It does, however, have some fairly interesting possibilities when put to use in creative ways.\n\nUnicode-range\n\nThe unicode-range descriptor is designed to help when using fonts that don\u2019t have full coverage of the characters used in a page. By adding a unicode-range property to a @font-face rule it is possible to specify the range of characters the font covers. \n\n@font-face {\n    font-family: BBCBengali;\n    src: url(fonts/BBCBengali.ttf) format(\"opentype\");\n    unicode-range: U+00-FF;\n}\n\nIn this example, the font is to be used for characters in the range of U+00 to U+FF which runs from the unexciting control characters at the start of the Unicode table (symbols like the exclamation mark start at U+21) right through to \u00ff at U+FF \u2013 the extent of the Basic Latin character range.\n\nBy adding multiple @font-face rules for the same family but with different ranges, you can build up complete coverage of the characters your page uses by using different fonts.\n\nWhen I say that it\u2019s possible to specify the range of characters the font covers, that\u2019s true, but what you\u2019re really doing with the unicode-range property is declaring which characters the font should be used for. This becomes interesting, because instead of merely working with the technical constraints of available characters in a given font, we can start picking and choosing characters to use and selectively mix fonts together.\n\nThe best available ampersand\n\nA few years back, Dan Cederholm wrote a post encouraging designers to use the best available ampersand. Dan went on to outline how this can be achieved by wrapping our ampersands in a <span> element with a class applied:\n\n<span class=\"amp\">&</span>\n\nA CSS rule can then be written to select the <span> and apply a different font:\n\nspan.amp {\n    font-family: Baskerville, Palatino, \"Book Antiqua\", serif;\n}\n\nThat\u2019s a perfectly serviceable technique, but the drawbacks are clear \u2014 you have to add extra markup which is borderline presentational, and you also have to be able to add that markup, which isn\u2019t always possible when working with a CMS.\n\nPerhaps we could do this with unicode-range.\n\nA better best available ampersand\n\nThe Unicode code point for an ampersand is U+26, so the ampersand font stack above can be created like so:\n\n@font-face {\n    font-family: 'Ampersand';\n    src: local('Baskerville'), local('Palatino'), local('Book Antiqua');\n    unicode-range: U+26;\n}\n\nWhat we\u2019ve done here is specify a new family called Ampersand and created a font stack for it with the user\u2019s locally installed copies of Baskerville, Palatino or Book Antiqua. We\u2019ve then limited it to a single character range \u2014 the ampersand. Of course, those don\u2019t need to be local fonts \u2014 they could be web font files, too. If you have a font with a really snazzy ampersand, go for your life.\n\nWe can then use that new family in a regular font stack.\n\nh1 {\n    font-family: Ampersand, Arial, sans-serif;\n}\n\nWith this in place, any <h1> elements in our page will use the Ampersand family (Baskerville, Palatino or Book Antiqua) for ampersands, and Arial for all other characters. If the user doesn\u2019t have any of the Ampersand family fonts available, the ampersand will fall back to the next item in the font stack, Arial.\n\nYou didn\u2019t think it was that easy, did you?\n\nOh, if only it were so. The problem comes, as ever, with the issue of browser support. The unicode-range property has good support in WebKit browsers (like Safari and Chrome, and the browsers on most popular smartphone platforms) and in recent versions of Internet Explorer. The big stumbling block comes in the form of Firefox, which has no support at all.\n\nIf you\u2019re familiar with how CSS works when it comes to unsupported properties, you\u2019ll know that if a browser encounters a property it doesn\u2019t implement, it just skips that declaration and moves on to the next. That works perfectly for things like border-radius \u2014 if the browser can\u2019t round off the corners, the declaration is skipped and the user sees square corners instead. Perfect.\n\nLess perfect when it comes to unicode-range, because if no range is specified then the default is that the font is applied for all characters \u2014 the whole range. If you\u2019re using a fancy font for flamboyant ampersands, you probably don\u2019t want that applied to all your text if unicode-range isn\u2019t supported. That would be bad. Really bad.\n\nEnsuring good fallbacks\n\nAs ever, the trick is to make sure that there\u2019s a sensible fallback in place if a browser doesn\u2019t have support for whatever technology you\u2019re trying to use. This is where being a super nerd about understanding the spec you\u2019re working with really pays off.\n\nWe can make use of the rules of the CSS cascade to make sure that if unicode-range isn\u2019t supported we get a sensible fallback font. What would be ideal is if we were able to follow up the @font-face rule with a second rule to override it if Unicode ranges aren\u2019t implemented.\n\n@font-face {\n    font-family: 'Ampersand';\n    src: local('Baskerville'), local('Palatino'), local('Book Antiqua');\n    unicode-range: U+26;\n}\n@font-face {\n    font-family: 'Ampersand';\n    src: local('Arial');\n}\n\nIn theory, this code should make sense for all browsers. For those that support unicode-range the two rules become cumulative. They specify different ranges for the same family, and in WebKit browsers this has the expected result of using Arial for most characters, but Baskerville and friends for the ampersand. For browsers that don\u2019t have support, the second rule should just supersede the first, setting the font to Arial. \n\nUnfortunately, this code causes current versions of Firefox to freak out and use the first rule, applying Baskerville to the entire range. That\u2019s both unexpected and unfortunate. Bad Firefox. On your rug.\n\nIf that doesn\u2019t work, what can we do? Well, we know that if given a unicode-range Firefox will ignore the range and apply the font to all characters. That\u2019s really what we\u2019re trying to achieve. So what if we specified a range for the fallback font, but made sure it only covers some obscure high-value Unicode character we\u2019re never going to use in our page? Then it wouldn\u2019t affect the outcome for browsers that do support ranges.\n\n@font-face {\n    font-family: 'Ampersand';\n    src: local('Baskerville'), local('Palatino'), local('Book Antiqua');\n    unicode-range: U+26;\n}\n@font-face {\n    /* Ampersand fallback font */\n    font-family: 'Ampersand';\n    src: local('Arial');\n    unicode-range: U+270C;\n}\n\nBy specifying a range on the fallback font, Firefox appears to correctly override the first based on the cascade sort order. Browsers that do support ranges take the second rule in addition, and apply Arial for that obscure character we\u2019re not using in any of our pages \u2014 U+270C.\n\nSo we get our nice ampersands in browsers that support unicode-range and, thanks to our styling of an obscure Unicode character, the font falls back to a perfectly acceptable Arial in browsers that do not offer support. Perfect!\n\nThat obscure character, my friends, is what Unicode defines as the VICTORY HAND.\n\n\u270c\n\nSo, how can we use this?\n\nAmpersands are a neat trick, and it works well in browsers that support ranges, but that\u2019s not really the point of all this. Styling ampersands is fun, but they\u2019re only really scratching the surface. Consider more involved examples, such as substituting a different font for numerals, or symbols, or even caps. Things certainly begin to get a bit more interesting.\n\nHow do you know what the codes are for different characters? Richard Ishida has a handy online conversion tool available where you can type in the characters and get the Unicode code points out the other end.\n\nOf course, the fact remains that browser support for unicode-range is currently limited, so any application needs to have fallbacks that you\u2019re still happy for a significant proportion of your visitors to see. In some cases, such as dedicated pages for mobile devices in an HTML-based phone app, this is immediately useful as support in WebKit browsers is already very good. In other cases, you\u2019ll have to use your own best judgement based on your needs and audience.\n\nOne thing to keep in mind is that if you\u2019re using web fonts, the entire font will be downloaded even if only one character is used. That said, the font shouldn\u2019t be downloaded if none of the characters within the Unicode range are present in a given page.\n\nAs ever, there are pros and cons to using unicode-range as well as varied but increasing support in browsers. It remains a useful tool to understand and have in your toolkit for when the right moment comes along.", "year": "2011", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2011-12-01T00:00:00+00:00", "url": "https://24ways.org/2011/creating-custom-font-stacks-with-unicode-range/", "topic": "code"}
{"rowid": 300, "title": "Taking Device Orientation for a Spin", "contents": "When The Police sang \u201cDon\u2019t Stand So Close To Me\u201d they weren\u2019t talking about using a smartphone to view a panoramic image on Facebook, but they could have been. For years, technology has driven relentlessly towards devices we can carry around in our pockets, and now that we\u2019re there, we\u2019re expected to take the thing out of our pocket and wave it around in front of our faces like a psychotic donkey in search of its own dangly carrot.\nBut if you can\u2019t beat them, join them.\nA brave new world\nA couple of years back all sorts of specs for new HTML5 APIs sprang up much to our collective glee. Emboldened, we ran a few tests and found they basically didn\u2019t work in anything and went off disheartened into the corner for a bit of a sob.\nTurns out, while we were all busy boohooing, those browser boffins have actually being doing some work, and lo and behold, some of these APIs are even half usable. Mostly literally half usable\u2014we\u2019re still talking about browsers, after all.\nNow, of course they\u2019re all a bit JavaScripty and are going to involve complex methods and maths and science and probably about a thousand dependancies from Github that will fall out of fashion while we\u2019re still trying to locate the documentation, right? Well, no! \nSo what if we actually wanted to use one of these APIs, say to impress our friends with our ability to make them wave their phones in front of their faces (because no one enjoys looking hapless more than the easily-technologically-impressed), how could we do something like that? Let\u2019s find out.\nThe Device Orientation API\nThe phone-wavy API is more formally known as the DeviceOrientation Event Specification. It does a bunch of stuff that basically doesn\u2019t work, but also gives us three values that represent orientation of a device (a phone, a tablet, probably not a desktop computer) around its x, y and z axes. You might think of it as pitch, roll and yaw if you like to spend your weekends wearing goggles and a leather hat.\nThe main way we access these values is through an event listener, which can inform our code every time the value changes. Which is constantly, because you try and hold a phone still and then try and hold the Earth still too.\nThe API calls those pitch, roll and yaw values alpha, beta and gamma. Chocks away:\nwindow.addEventListener('deviceorientation', function(e) {\n    console.log(e.alpha);\n    console.log(e.beta);\n    console.log(e.gamma);\n});\nIf you look at this test page on your phone, you should be able to see the numbers change as you twirl the thing around your body like the dance partner you never had. Wrist strap recommended.\nOne important note\nLike may of these newfangled APIs, Device Orientation is only available over HTTPS. We\u2019re not allowed to have too much fun without protection, so make sure that you\u2019re working on a secure line. I\u2019ve found a quick and easy way to share my local dev environment over TLS with my devices is to use an ngrok tunnel.\nngrok http -host-header=rewrite mylocaldevsite.dev:80\nngrok will then set up a tunnel to your dev site with both HTTP and HTTPS URL options. You, of course, want the HTTPS option.\nRight, where were we?\nMake something to look at\nIt\u2019s all well and good having a bunch of numbers, but they\u2019re no use unless we do something with them. Something creative. Something to inspire the generations. Or we could just build that Facebook panoramic image viewer thing (because most of us are familiar with it and we\u2019re not trying to be too clever here). Yeah, let\u2019s just build one of those.\nOur basic framework is going to be similar to that used for an image carousel. We have a container, constrained in size, and CSS overflow property set to hidden. Into this we place our wide content and use positioning to move the content back and  forth behind the \u2018window\u2019 so that the part we want to show is visible.\nHere it is mocked up with a slider to set the position. When you release the slider, the position updates. (This actually tests best on desktop with your window slightly narrowed.)\nThe details of the slider aren\u2019t important (we\u2019re about to replace it with phone-wavy goodness) but the crucial part is that moving the slider results in a function call to position the image. This takes a percentage value (0-100) with 0 being far left and 100 being far right (or \u2018alt-nazi\u2019 or whatever).\nvar position_image = function(percent) {\n    var pos = (img_W / 100)*percent;\n    img.style.transform = 'translate(-'+pos+'px)'; \n};\nAll this does is figure out what that percentage means in terms of the image width, and set the transform: translate(\u2026); CSS property to move the image. (We use translate because it might be a bit faster to animate than left/right positioning.)\nOk. We can now read the orientation values from our device, and we can programatically position the image. What we need to do is figure out how to convert those raw orientation values into a nice tidy percentage to pass to our function and we\u2019re done. (We\u2019re so not done.)\nThe maths bit\nIf we go back to our raw values test page and make-believe that we have a fascinating panoramic image of some far-off beach or historic monument to look at, you\u2019ll note that the main value that is changing as we swing back and forth is the \u2018alpha\u2019 value. That\u2019s the one we want to track.\nAs our goal here is hey, these APIs are interesting and fun and not let\u2019s build the world\u2019s best panoramic image viewer, we\u2019ll start by making a few assumptions and simplifications:\n\nWhen the image loads, we\u2019ll centre the image and take the current nose-forward orientation reading as the middle.\nMoving left, we\u2019ll track to the left of the image (lower percentage).\nMoving right, we\u2019ll track to the right (higher percentage).\nIf the user spins round, does cartwheels or loads the page then hops on a plane and switches earthly hemispheres, they\u2019re on their own.\n\nNose-forward\nWhen the page loads, the initial value of alpha gives us our nose-forward position. In Safari on iOS, this is normalised to always be 0, whereas most everywhere else it tends to be bound to pointy-uppy north. That doesn\u2019t really matter to us, as we don\u2019t know which direction the user might be facing in anyway \u2014 we just need to record that initial state and then use it to compare any new readings.\nvar initial_position = null;\n\nwindow.addEventListener('deviceorientation', function(e) {\n    if (initial_position === null) {\n        initial_position = Math.floor(e.alpha);\n    };\n\n    var current_position = initial_position - Math.floor(e.alpha);\n});\n(I\u2019m rounding down the values with Math.floor() to make debugging easier - we\u2019ll take out the rounding later.)\nWe get our initial position if it\u2019s not yet been set, and then calculate the current position as a difference between the new value and the stored one.\nThese values are weird\nOne thing you need to know about these values, is that they range from 0 to 360 but then you also get weird left-of-zero values like -2 and whatever. And they wrap past 360 back to zero as you\u2019d expect if you do a forward roll.\nWhat I\u2019m interested in is working out my rotation. If 0 is my nose-forward position, I want a positive value as I turn right, and a negative value as I turn left. That puts the awkward 360-tipping point right behind the user where they can\u2019t see it.\nvar rotation  = current_position;\nif (current_position > 180) rotation = current_position-360;\nWhich way up?\nSince we\u2019re talking about orientation, we need to remember that the values are going to be different if the device is held in portrait on landscape mode. See for yourself - wiggle it like a steering wheel and you get different values. That\u2019s easy to account for when you know which way up the device is, but in true browser style, the API for that bit isn\u2019t well supported. The best I can come up with is:\nvar screen_portrait = false;\nif (window.innerWidth < window.innerHeight) {\n    screen_portrait = true;\n}\nIt works. Then we can use screen_portrait to branch our code:\nif (screen_portrait) {\n        if (current_position > 180) rotation = current_position-360;\n} else {\n        if (current_position < -180) rotation = 360+current_position;\n}\nHere\u2019s the code in action so you can see the values for yourself. If you change screen orientation you\u2019ll need to refresh the page (it\u2019s a demo!).\nLimiting rotation\nNow, while the youth of today are rarely seen without a phone in their hands, it would still be unreasonable to ask them to spin through 360\u00b0 to view a photo. Instead, we need to limit the range of movement to something like 60\u00b0-from-nose in either direction and normalise our values to pan the entire image across that 120\u00b0 range. -60 would be full-left (0%) and 60 would be full-right (100%).\nIf we set max_rotation = 60, that code ends up looking like this:\nif (rotation > max_rotation) rotation = max_rotation;\nif (rotation < (0-max_rotation)) rotation = 0-max_rotation;\n\nvar percent = Math.floor(((rotation + max_rotation)/(max_rotation*2))*100);\nWe should now be able to get a rotation from -60\u00b0 to +60\u00b0 expressed as a percentage. Try it for yourself.\nThe big reveal\nAll that\u2019s left to do is pass that percentage to our image positioning function and would you believe it, it might actually work.\nposition_image(percent);\nYou can see the final result and take it for a spin. Literally.\nSo what have we made here? Have we built some highly technical panoramic image viewer to aid surgeons during life-saving operations using only JavaScript and some slightly questionable mathematics? No, my friends, we have not. Far from it. \nWhat we have made is progress. We\u2019ve taken a relatively newly available hardware API and a bit of simple JavaScript and paired it with existing CSS knowledge and made something that we didn\u2019t have this morning. Something we probably didn\u2019t even want this morning. Something that if you take a couple of steps back and squint a bit might be a prototype for something vaguely interesting. But more importantly, we\u2019ve learned that our browsers are just a little bit more capable than we thought.\nThe web platform is maturing rapidly. There are new, relatively unexplored APIs for doing all sorts of crazy thing that are often dismissed as the preserve of native apps. Like some sort of app marmalade. Poppycock. \nThe web is an amazing, exciting place to create things. All it takes is some base knowledge of the fundamentals, a creative mind and a willingness to learn. We have those! So let\u2019s create things.", "year": "2016", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2016-12-24T00:00:00+00:00", "url": "https://24ways.org/2016/taking-device-orientation-for-a-spin/", "topic": "code"}