{{ page.title }}
\n\n \t{{ content }}\n\n \tRecipe by {{ page.recipe-attribution }}.
\n\n\t{"rowid": 17, "title": "Bringing Design and Research Closer Together", "contents": "The \u2018should designers be able to code\u2019 debate has raged for some time, but I\u2019m interested in another debate: should designers be able to research? \n\nAre you a designer who can do research? Good research and the insights you uncover inspire fresh ways of thinking and get your creative juices flowing. Good research brings clarity to a woolly brief. Audience insight helps sharpen your focus on what\u2019s really important. Experimentation through research and design brings a sense of playfulness and curiosity to your work. Good research helps you do good design.\n\nBeing a web designer today is pretty tough, particularly if you\u2019re a freelancer and work on your own. There are so many new ideas, approaches to workflow and trends and tools to keep up with. How do you decide which things to do and which to ignore? A modern web designer needs to be able to consider the needs of the audience, design appropriate IAs and layouts, choose colour palettes, pick appropriate typefaces and type layouts, wrangle with content, style, code, dabble in SEO, and the list goes on and on. Not only that, but today\u2019s web designer also has to keep up with the latest talking points in the industry: responsive design, Agile, accessibility, Sass, Git, lean UX, content first, mobile first, blah blah blah. Any good web designer doesn\u2019t need to be persuaded about the merits of including research in their toolkit, but do you really have time to include research too? \n\nWho is responsible for research?\n\nGenerally, research in the web industry forms part of other disciplines and isn\u2019t so much a discipline in its own right. It\u2019s very often thought of as part of UX, or activities that make up a process such as IA or content strategy. Research is often undertaken by UX designers, information architects or content strategists and isn\u2019t something designers or developers get that involved in. Some people lump all of these activities together and label it design research and have design researchers to do it. Some companies, such as the one I run with my husband Mark, are lucky enough to have someone with specialist research knowledge (yup, that would be me folks) who can lead all or most of the research work undertaken by the company. See also Mule Design, GOV.UK, the BBC, Mailchimp, Facebook and Twitter. \n\nWhat if you\u2019re not lucky enough to have your own researcher or team of researchers? Often research is the kind of thing that\u2019s nice to have, or it can be cut from scope when doing the budget dance with a client. It often forms part of the discovery phase of a project and sometimes just becomes a tick-box exercise. But research isn\u2019t just user testing and it shouldn\u2019t just live in a report on Basecamp that no one reads. I would argue that research and experimentation is a way of working or an approach to how you design. Research can be used during the whole design process and must be a vital part of a designer\u2019s workflow on every project. Even if you work in a small studio, you can still create a culture of audience insight. Even if you work on your own, you can still absorb yourself in as much audience data as you can throughout the project life cycle. Here\u2019s how.\n\nResearch is everyone\u2019s job\n\nThere is a subtle difference between writing a research report and delivering it to a client, and them actually using it and applying the insights to their thought process. In my experience of working in the audiences team at the BBC, research was most effective when the role was embedded in the production team and insights were used as part of the editorial process.\n\nIn this section I\u2019ll talk through some common problems you might encounter in a typical project life cycle and show you ways you can use research to help you. For the sake of this article, let\u2019s imagine that we\u2019re talking about a particular project here and not ongoing product development. The same principles can of course be applied then, but even if you work in-house rather than on the agency side, you\u2019re probably used to working on distinct projects or phases of work.\n\n1. Problem: I want to come up with a new product idea. \n\nSolution: Inspiration through insights.\n\nBefore you begin a new project, a good way of quickly absorbing all the existing knowledge that there maybe about a theme, product type or website is to literally surround yourself with it. This is especially relevant for new ideas or product development. Create an incident room if you can: fill the walls of your meeting room, the walls near your desk, or even just use a pinboard or online pinboard if space is tight or you\u2019re working with a dispersed team. The same process can be used throughout a project\u2019s or product life cycle \u2014 read about how MailChimp has applied this idea. \n\nLet\u2019s take a new product idea as an example. Say you wanted to develop a responsive tool for web designers but you weren\u2019t sure what aspect of responsive design to focus on. First of all, you should pose a hypothesis or problem statement to gather ideas around. For example: \u201cHow to speed up a designer\u2019s responsive workflow.\u201d You would then need to gather insights around this topic. You could run some interviews with freelance designers about how they work responsively. You could shadow a development team for the day to understand their processes. You could observe conversations on Twitter or IRC or wherever your target audience interact to see what people talk about. You could search out industry data and articles currently available.\n\nThe next stage is to comb through this data and extract insights from it. You can use good old Post-it notes and a sharpie: capture one insight or thought per Post-it. If one insight leads into another, use two Post-its. The objective is volume. Try to ensure clarity in each Post-it so you don\u2019t have to go back and reference material again (maybe you could use a key if you think it\u2019ll get confusing).\n\n\n\nAfter this, stick them all up and synthesise the same way you would for any kind of cluster or affinity sort. Organise into broad themes. These themes then become springboards for further exploration and idea generation. You might see a gap or opportunity in one particular area, both from a workflow perspective but also from a business perspective. Bingo. Your insights then become the fuel for ideas generation.\n\nThis method doesn\u2019t just have to be used for new products \u2014 it works particularly well in a discovery phase for new projects or for new features in an existing product. We\u2019re doing something similar for our own responsive tool, Gridset at the moment.\n\nResources:\n\n\n\tSticky Wisdom by Dave Allan, Matt Kingdon, Kris Murrin, Daz Rudkin\n\tThe Science of Serendipity by Matt Kingdon\n\tThe Art of Innovation by Tom Kelley\n\n\n2. Problem: You\u2019re starting a new project and need to know the basics before you get headlong into designing or building. \n\nSolution: Quantitative survey.\n\nCommon questions might be:\n\n\n\tWho are the users?\n\tHow many are there?\n\tWhat are they like?\n\tWhy do they use the site?\n\tWhat do they need from the site?\n\tWhat are their goals?\n\n\nPrint out and stick up what you already know and have in your project space or \u2018incident room\u2019: any reports you have found or been given, analytics graphs, personas, pen portraits, as well as screengrabs of the current website, product or branding. Spend time looking through it all and identify the gaps. \n\nIf you have very little existing audience data, a quick and easy way to get some baseline information is to run a quick user survey on a current website. You can establish basic demographic information, appreciation and views of the website as it stands, as well as delve a little deeper into needs and wants. This is also vital if you want some kind of trackable measures to go back to once you have designed and built your shiny new website for your client \u2014 read more in my article for 24 ways last year.)\n\n\n\nWe use surveys a lot at Mark Boulton Design for our client work. Here\u2019s a screen grab of one we ran in March on http://info.cern.ch before we redesigned the site and did the work on the First Website Project. We repeated the survey after the new website went live and were able to compare the results. Both surveys were a great source of insight to the project team as well as for the project stakeholders who needed to pitch the idea of the hack days and fundraise for them.\n\n\n\nOnce you\u2019ve run your survey, you should always write up a short summary for yourself and your client to refer to. If you\u2019re not a trained researcher, you should try to read up on analysis techniques or data visualisation. It can be easy to misinterpret data and make it bend to the story you are trying to tell. You should be looking for the story in the data and present it without bias. \n\nIf you\u2019re using the \u2018incident room\u2019 method I mentioned earlier on, you can also extract the insights onto post it notes and add them to your growing body of knowledge.\n\nResources: \n\n\n\tUsing Questionnaires for Design Research by Emma Boulton\n\tData-driven Design with an Annual Survey by Aarron Walter\n\tResearch Methods for Product Design by Alex Milton and Paul Rodgers\n\tA Practical Guide to Designing with Data by Brian Suda\n\n\n3. Problem: You have a prototype of a new design and you need some feedback from real users. \n\nSolution: User interviews and task based testing.\n\nInterviewing is a staple research method that every designer should master as it can be used throughout a project life cycle. Erika Hall recently wrote a great article on the basics for A List Apart. From stakeholder interviews in a discovery phase, to initial user research, right through to task based testing and iteration, interviews can be enormously helpful. They are very time-consuming, however, and although speaking to someone is better than speaking to no one, it\u2019s always better to plan to do a few interviews at once, rather than one or two. I generally find that patterns only start to emerge after I\u2019ve spoken to 4 or 5 people. Interviews are another thing we do a lot of at Mark Boulton Design. Most of the interviews we do are remote due to the location of our clients and their users. \n\n\n\nRigour is an important consideration in all research activities and especially if you\u2019re a non-researcher. Interviews particularly can be easily skewed by an inexperienced facilitator, which is why pairing can be a good approach. Building rapport, questioning, time keeping, note taking and thinking on your feet can be difficult to do all at once, so having a colleague take notes while you concentrate on leading the conversation can work really well. It\u2019s important for the note taker to sit in on more than one interview so that they get a more rounded view of the feedback. The same person should also be involved in the analysis of the data. \n\n\n\nInterviews can be analysed and written up in a report or summary as with other types of research. I often use the same kind of collaborative process detailed earlier for deciding on themes, particularly if multiple members of the team have been involved in interviewing. \n\nInterviews are particularly useful for our incident room and can provide much colour and insight to an exploratory process. I often find verbatim quotes to be the most insightful type of data. You might find that an inexperienced researcher (or designer who is used to solving problems) will jump to interpretation too soon and forget to just listen to what the interviewee is saying. Capturing the exact form of words a person uses can help get away from this.\n\nResources: \n\n\n\tInterviewing Humans by Erika Hall\n\tA Pocket Guide to Interviewing for Research by Andrew Travers\n\tInterviewing Users by Steve Portigal\n\n\n4. Problem: How successful have I been with this new design? \n\nSolution: Key performance indicators\n\nOnce your new design has been realised, it\u2019s important to evaluate it. What works, what doesn\u2019t work so well? As well as a straightforward design crit, don\u2019t forget to introduce audience insights into a review meeting or project wash up. \n\n\n\nWork out what your KPIs \u2014 your key performance indicators \u2014 will be beforehand and then you can start to track them over time. For example, number of visits, appreciation of the site, willingness to recommend the site to a friend, number of sales, and number of conversions are all sensible measures to track. Interviews can again be helpful but cold, hard numbers are often better here. Read Corey Vilhauer\u2019s take on this on A List Apart.\n\nConsistency is key here. If you have looked at your analytics and done a survey beforehand, you will have a baseline to start from. Don\u2019t keep changing your measures and questions, or your data will not be comparable. Pick a few key questions or a set of measures, create a survey and then run it once a month, once a quarter, every six months or annually. You\u2019ll start to see changes over time as the design beds in. You may see seasonal trends and spot patterns in the data related to other activities like marketing, promotion and so on. Keeping a record of all of this will increase your understanding of your audience. We\u2019ve created a satisfaction survey for Gridset with a number of measures that we track on an ongoing basis. MailChimp has also created an annual survey with the aim of tracking their audience measures over time\n\nResources:\n\n\n\tSearch Analytics by Louis Rosenfeld\n\tA Primer on A/B Testing by Lara Swanson\n\tLean UX by Jeff Gothelf\n\n\nAnyone can do research\n\nResearch can be brought into the project life cycle at any stage. And of course, anyone can do research \u2014 you don\u2019t need to be a researcher. Some of the main skills most designers possess are also key research skills: inquisitive nature, problem solving, playfulness, empathy, and so on.\n\nWe have a small team at Mark Boulton Design. Most of the team are designers and the rest of us focus on supporting the team and clients both in terms of billable work (research, content strategy, project management) as well as the non-billable things like finance and studio management.\n\nDespite my best intentions, in the past I\u2019ve undertaken research for clients in isolation \u2014 first being briefed by the design lead, carrying out the research and then delivering the findings back, trusting the design team to take the findings on board. This was often due to time and availability of resources.\n\nWe\u2019ve been trying hard to join up our processes and collaborate even more across the team. Undertaking heuristic or design reviews collaboratively; taking part in frequent critiques of our work and the work of others together; pairing a researcher and a designer to run interviews; workshopping results from interviews to come up with recommendations; working closely together on questionnaire design; shadowing each other on tasks that don\u2019t fall within our core skills. A little thing like moving our desks around has also helped us have more conversations that we can all be a part of.\n\n\n\nI\u2019ve come to the conclusion that my role as the research director at Mark Boulton Design is actually a facilitator of research. As well as carrying out research, I am responsible for ensuring that research happens consistently across the team. I am responsible for empowering and training our designers so they feel confident in carrying out their own user, audience or design research for clients. So they know what to look for, when to listen, when to probe and when to take note of something. So they know how to look for themes, how to synthesise insights from research and how to apply them to their work.\n\nBetter research leads to better design\n\nSo, are you a designer who can do research? Are you a researcher who can design? The best designers are a lucky combination of researcher and designer. If you\u2019re not one of those, look at ways of enhancing the skills you lack. Because there\u2019s no doubt in my mind, that becoming a better researcher will make you a better designer.\n\nGeneral resources: \n\n\n\tSeeing the Elephant by Louis Rosenfeld\n\tConnected UX by Aarron Walter\n\tBeyond Usability Testing by Devan Goldstein\n\tJust Enough Research by Erika Hall\n\tThe User Experience Team of One by Leah Buley\n\tUndercover User Experience Design by Cennydd Bowles and James Box\n\tA Pocket Guide to Psychology for Designers by Joe Leech\n\tA Pocket Guide to International User Research by Chui Chui Tan\n\tRemote Research by Nate Bolt and Tony Tulathimutte\n\tA Pocket Guide to Experiments for Designers by Colin McFarland", "year": "2013", "author": "Emma Boulton", "author_slug": "emmaboulton", "published": "2013-12-22T00:00:00+00:00", "url": "https://24ways.org/2013/bringing-design-and-research-closer-together/", "topic": "ux"} {"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": 4, "title": "Credits and Recognition", "contents": "A few weeks ago, I saw a friendly little tweet from a business congratulating a web agency on being nominated for an award. The business was quite happy for them and proud to boot \u2014 they commented on how the same agency designed their website, too.\n\nWhat seemed like a nice little shout-out actually made me feel a little disappointed. Why? In reality, I knew that the web agency didn\u2019t actually design the site \u2014 I did, when I worked at a different agency responsible for the overall branding and identity.\n\nI certainly wasn\u2019t disappointed at the business \u2014 after all, saying that someone designed your site when they were responsible for development is an easy mistake to make. Chances are, the person behind the tweets and status updates might not even know the difference between words like design and development. \n\nWhat really disappointed me was the reminder of how many web workers out there never explain their roles in a project when displaying work in a portfolio. If you\u2019re strictly a developer and market yourself as such, there might be less room for confusion, but things can feel a little deceptive if you offer a wide range of services yet never credit the other players when collaboration is part of the game. Unfortunately, this was the case in this situation. Whatever happened to credit where credit\u2019s due?\n\nAdvertising attribution\n\nHave you ever thumbed through an advertising annual or browsed through the winners of an advertising awards website, like the campaign below from Kopenhagen Chocolate on Advertising Age? If so, it\u2019s likely that you\u2019ve noticed some big differences in how the work is credited.\n\n Everyone involved in a creative advertising project is mentioned.\n\nArt directors, writers, creative directors, photographers, illustrators and, of course, the agency all get a fair shot at fifteen minutes of fame. Why can\u2019t we take this same idea and introduce it to our own showcases?\n\nCrediting on client sites\n\nAh, the good old days of web rings, guestbooks, and under construction GIFs, when slipping in a cheeky \u201cdesigned by\u201d link in the footer of your masterpiece was just another common practice. These days most clients, especially larger companies and corporations, aren\u2019t willing to have any names on their site except their own. \n\nIf you\u2019d still like to leave a little proof of authorship on a website, consider adding a humans.txt file to the root of the site and, if possible, add an author tag in the
of the site:\n\n\n\nIt\u2019s a great way to add more detailed information than just a meta name without being intrusive. The example on the humanstxt.org website serves to act as a guideline, but how much detail you add is completely up to you and your team.\n\n Part of the humans.txt file on humanstxt.org\n\nAlternatively, you can use the HTML5 rel=\"author\" attribute to link to information about the author of the page in the form of a mailto: address, a link to a contact form, or a separate authors page.\n\nCrediting in portfolios\n\nWhile humans.txt is a great approach when you\u2019re authoring a site, it\u2019s even more important to clearly define your role in your own portfolio. \n\nWhile I believe it\u2019s proper etiquette to include the names of folks you collaborated with, sometimes it might not be necessary (or even possible) to list every single person, especially if you\u2019ve worked with a large agency. \n\n\u201cFake it till you make it\u201d is not a term that should apply to your portfolio. Clearly stating your own responsibilities means that nobody else browsing your work samples will assume that you did more than your actual share, and being ambiguous about your role isn\u2019t fair to yourself, or others. \n\nBefore adding any work to your portfolio, ensure that you have permission from your client. Even if you included a clause in your contract about being allowed to post your work online, it\u2019s always best to double-check. Sometimes you might not know if your work has been officially launched, and leaking something before it\u2019s ready is bound to make a client frown.\n\nExamples\n\nThere are plenty of portfolios out there that we can use for inspiration. Here are some examples that I like from other folks in the web industry:\n\nAnna Debenham\n\n In her portfolio, Anna outlines her responsibilities and those of others.\n\nIn the description, Anna clearly explains her duties of doing the HTML and CSS, along with performing research and testing the prototype in schools. She also credits Laura Kalbag for the design work.\n\nNaomi Atkinson Design\n\nThe work portfolio of Naomi Atkinson Design is short and to the point \u2014 they were responsible for the iPhone app design and IA for Artspotter.\n\n The portfolio of Naomi Atkinson Design states clearly what they did.\n\nAmber Weinberg\n\nAmber Weinberg is strictly a developer, but a potential client could see her portfolio and assume she might be a designer as well. To avoid any misunderstandings, she states her roles up front in a section called \u201cWhat I Did,\u201d supported by examples of her code.\n\n Amber Weinberg sets out all her roles in each of her portfolio\u2019s case studies.\n\nWhat if someone doesn\u2019t want to be credited?\n\nLet\u2019s face it \u2014 we\u2019ve all been there. A project, for whatever reason, turns out to be an absolute disaster and we don\u2019t feel like it\u2019s an accurate representation of the quality of our work. \n\nIf you\u2019re crediting someone else but suspect they might rather pretend it never happened, be sure to drop them a line and ask if they\u2019d like to be included. And, if someone contacts you and asks to remove their name, don\u2019t feel offended \u2014 just politely remove it.\n\nGet updating!\n\nNow that the holiday season is almost here, many of you might be planning to set aside some time for personal projects. Grab yourself a gingerbread latte and get those portfolios up to date. Remember, It doesn\u2019t have to be long-winded, just honest. Happy holidays!", "year": "2013", "author": "Geri Coady", "author_slug": "gericoady", "published": "2013-12-16T00:00:00+00:00", "url": "https://24ways.org/2013/credits-and-recognition/", "topic": "process"} {"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": 10, "title": "Home Kanban for Domestic Bliss", "contents": "My wife is an architect. I\u2019m a leader of big technical teams these days, but for many years after I was a dev I was a project/program manager. Our friends and family used to watch Grand Designs and think that we would make the ideal team \u2014 she could design, I could manage the project of building or converting whatever dream home we wanted.\n\nThen we bought a house.\n\nA Victorian terrace in the north-east of England that needed, well, a fair bit of work. The big decisions were actually pretty easy: yes, we should knock through a double doorway from the dining room to the lounge; yes, we should strip out everything from the utility room and redo it; yes, we should roll back the hideous carpet in the bedrooms upstairs and see if we could restore the original wood flooring.\n\nThose could be managed like a project.\n\nWhat couldn\u2019t be was all the other stuff. Incremental improvements are harder to schedule, and in a house that\u2019s over a hundred years old you never know what you\u2019re going to find when you clear away some tiles, or pull up the carpets, or even just spring-clean the kitchen (\u201cErm, hon? The paint seems to be coming off. Actually, so does the plaster\u2026\u201d). A bit like going in to fix bugs in code or upgrade a machine \u2014 sometimes you end up quite far down the rabbit hole.\n\nAnd so, as we tried to fit in those improvements in our evenings and weekends, we found ourselves disagreeing. Arguing, even. We were both trying to do the right thing (make the house better) but since we were fitting it in where we could, we often didn\u2019t get to talk and agree in detail what was needed (exactly how to make the house better). And it\u2019s really frustrating when you stay up late doing something, just to find that your other half didn\u2019t mean that they meant this instead, and so your effort was wasted.\n\nThen I saw this tweet from my friend and colleague Jamie Arnold, who was using the same kanban board approach at home as we had instituted at the UK Government Digital Service to manage our portfolio.\n\nMrs Arnold embraces Kanban wall at home. Disagreements about work in progress and priority significantly reduced.. ;) pic.twitter.com/407brMCH\u2014 Jamie Arnold (@itsallgonewrong) October 27, 2012\n\nAnd despite Jamie\u2019s questionable taste in fancy dress outfits (look closely at that board), he is a proper genius when it comes to processes and particularly agile ones. So I followed his example and instituted a home kanban board.\n\nWhat is this kanban of which you speak?\n\nKanban boards are an artefact from lean manufacturing \u2014 basically a visualisation of a production process. They are used to show you where your bottlenecks are, or where one part of the process is producing components faster than another part of the process can cope. Identifying the bottlenecks leads you to set work in progress (WIP) limits, so that you get an overall more efficient system.\n\nIncreasingly kanban is used as an agile software development approach, too, especially where support work (like fixing bugs) needs to be balanced with incremental enhancement (like adding new features).\n\nI\u2019m a big advocate of kanban when you have a system that needs to be maintained and improved by the same team at the same time. Rather than the sprint-based approach of scrum (where the next sprint\u2019s stories or features to be delivered are agreed up front), kanban lets individuals deal with incidents or problems that need investigation and bug fixing when urgent and important. Then, when someone has capacity, they can just go to the board and pull down the next feature to develop or test.\n\nSo, how did we use it?\n\nOne of the key tenets of kanban is that you visualise your workflow, so we put together a whiteboard with columns: Icebox; To Do Next; In Process; Done; and also a section called Blocked. Then, for each thing that needed to happen in the house, we put it on a Post-it note and initially chucked them all in the Icebox \u2014 a collection with no priority assigned yet.\n\nEach week we looked at the Icebox and pulled out a set of things that we felt should be done next. This was pulled into the To Do Next column, and then each time either of us had some time, we could just pull a new thing over into the In Process column. We agreed to review at the end of each week and move things to Done together, and to talk about whether this kanban approach was working for us or not.\n\nWe quickly learned for ourselves why kanban has WIP limits as a key tenet \u2014 it\u2019s tempting to pull everything into the To Do Next column, but that\u2019s unrealistic. And trying to do more than one or two things each at a given time isn\u2019t terribly productive owing to the cost of task switching. So we tend to limit our To Do Next to about seven items, and our In Process to about four (a max of two each, basically).\n\nWe use the Blocked column when something can\u2019t be completed \u2014 perhaps we can\u2019t fix something because we discovered we don\u2019t have the required tools or supplies, or if we\u2019re waiting for a call back from a plumber. But it\u2019s nice to put it to one side, knowing that it won\u2019t be forgotten.\n\nWhat helped the most?\n\nIt wasn\u2019t so much the visualisation that helped us to see what we needed to do, but the conversation that happened when we were agreeing priorities, moving them to In Process and then on to Done made the biggest difference. Getting clear on the order of importance really is invaluable \u2014 as is getting clear on what Done really means!\n\nThe Blocked column is also great, as it helps us keep track of things we need to do outside the house to make sure we can make progress. We also found it really helpful to examine the process itself and figure out whether it was working for us. For instance, one thing we realised is it\u2019s worth tracking some regular tasks that need time invested in them (like taking recycling that isn\u2019t picked up to the recycling centre) and these used to cycle around and around. So they were moved to Done as part of our weekly review, but then immediately put back in the Icebox to float back to the top again at a relevant time.\n\nBut the best thing of all? That moment where we get to mark something as done! It\u2019s immensely satisfying to review at the end of the week and have a physical marker of the progress you\u2019ve made.\n\nAll in all, a home kanban board turned out to be a very effective way to pull tasks through stages rather than always trying to plan them out in advance, and definitely made collaboration on our home tasks significantly smoother. Give it a try!", "year": "2013", "author": "Meri Williams", "author_slug": "meriwilliams", "published": "2013-12-14T00:00:00+00:00", "url": "https://24ways.org/2013/home-kanban-for-domestic-bliss/", "topic": "process"} {"rowid": 1, "title": "Why Bother with Accessibility?", "contents": "Web accessibility (known in other fields as inclusive design or universal design) is the degree to which a website is available to as many people as possible. Accessibility is most often used to describe how people with disabilities can access the web.\n\nHow we approach accessibility\n\nIn the web community, there\u2019s a surprisingly inconsistent approach to accessibility. There are some who are endlessly dedicated to accessible web design, and there are some who believe it so intrinsic to the web that it shouldn\u2019t be considered a separate topic. Still, of those who are familiar with accessibility, there\u2019s an overwhelming number of designers, developers, clients and bosses who just aren\u2019t that bothered.\n\nOver the last few months I\u2019ve spoken to a lot of people about accessibility, and I\u2019ve heard the same reasons to ignore it over and over again. Let\u2019s take a look at the most common excuses.\n\nExcuse 1: \u201cPeople with disabilities don\u2019t really use the web\u201d\n\nAccessibility will make your site available to more people \u2014 the inclusion case\n\nIn the same way that the accessibility of a building isn\u2019t just about access for wheelchair users, web accessibility isn\u2019t just about blind users and screen readers. We can affect positively the lives of many people by making their access to the web easier.\n\nThere are four main types of disability that affect use of the web:\n\n\n\tVisual\n\tBlindness, low vision and colour-blindness\n\tAuditory\n\tProfoundly deaf and hard of hearing\n\tMotor\n\tThe inability to use a mouse, slow response time, limited fine motor control\n\tCognitive\n\tLearning difficulties, distractibility, the inability to focus on large amounts of information\n\n\nNone of these disabilities are completely black and white\n\nExamining deafness, it\u2019s clear from the medical scale that there are many grey areas between full hearing and total deafness:\n\n\n\tmild\n\tmoderate\n\tmoderately severe\n\tsevere\n\tprofound\n\ttotally deaf\n\n\nFor eyesight, and brain conditions that affect what users see, there is a huge range of conditions and challenges:\n\n\n\tastigmatism\n\tcolour blindness\n\takinetopsia (motion blindness)\n\tscotopic visual sensitivity (visual stress related to light)\n\tvisual agnosia (impaired recognition or identification of objects)\n\n\nWhile we might have medical and government-recognised definitions that tell us what makes a disability, day-to-day life is not so straightforward. People experience varying degrees of different conditions, and often one or more conditions at a time, creating a false divide when you view disability in terms of us and them.\n\nImpairments aren\u2019t always permanent\n\nAs we age, we\u2019re more likely to experience different levels of visual, auditory, motor and cognitive impairments. We might have an accident or illness that affects us temporarily. We might struggle more earlier or later in the day. There are so many little physiological factors that affect the way people interact with the web that we can\u2019t afford to make any assumptions based on our own limited experiences.\n\nImpairments might be somewhere between the user and the website\n\nThere are also impairments that aren\u2019t directly related to the user. Environmental factors have a huge effect on the way people interact with the web. These could be:\n\n\n\tLow bandwidth, or intermittent internet connection\n\tBright light, rain, or other weather-based conditions\n\tNoisy environments, or a location where the user doesn\u2019t want to disturb their neighbours with sound\n\tBrowsing with mobile devices, games consoles and other non-desktop devices\n\tBrowsing with legacy browsers or operating systems\n\n\nSuch environmental factors show that it\u2019s not just those with physical impairments who benefit from more accessible websites. We started designing responsive websites so we could be more future-friendly, and with a shared goal of better optimised experiences, accessibility should be at the core of responsive web design.\n\nExcuse 2: \u201cWe don\u2019t want to affect the experience for the majority of our users\u201d\n\nAccessibility will improve your site for all your users \u2014 the usability case\n\nOn a basic level, the different disability groups, as shown in the inclusion case, equate to simple usability goals:\n\n\n\tVisual \u2013 make it easy to read\n\tAuditory \u2013 make it easy to hear\n\tMotor \u2013 make it easy to interact\n\tCognitive \u2013 make it easy to understand and focus\n\n\nTaking care to ensure good usability in these areas will also have an impact on accessibility. Unless your site is catering specifically to a particular disability, where extreme optimisation is most beneficial, taking care to design with accessibility in mind will rarely negatively affect the experience of your wider audience.\n\nExcuse 3: \u201cWe don\u2019t have the budget for accessibility\u201d\n\nAccessibility will make you money \u2014 the business case\n\nBy reducing your audience through ignoring accessibility, you\u2019re potentially excluding the income from those users. Designing with accessibility in mind from the beginning of a project makes it easier to make small inexpensive optimisations as part of the design and development process, rather than bolting on costly updates to increase your potential audience later on.\n\nThe following are excerpts from a white paper about companies that increased the accessibility of their websites to comply with government regulation.\n\n\n\tImprovements in accessibility doubled Legal and General\u2019s life insurance sales online.\n\n\n\n\tImprovements in accessibility increased Tesco\u2019s grocery home delivery sales by \u00a313 million in 2005\u2026 To their surprise they found that many normal visitors preferred the ease of navigation and improved simplicity of the [parallel] accessible site and switched to use it. Tesco have replaced their \u2018normal\u2019 site with their accessible version and expect a further increase in revenues.\n\n\n\n\tImprovements in accessibility increased Virgin.net sales by 68%.\n\n\nStatistics all from WSI white paper: Improve your website\u2019s usability and accessibility to increase sales (PDF).\n\nExcuse 4: \u201cAccessible websites are ugly\u201d\n\nAccessibility won\u2019t stop your site from being beautiful \u2014 the beauty case\n\nMany people use ugly accessible websites as proof that all accessible websites are ugly. This just isn\u2019t the case. I\u2019ve compiled some examples of beautiful and accessible websites with screenshots of how they look through the Color Oracle simulator and how they perform when run through Webaim\u2019s Wave accessibility checker tool.\n\nWhile automated tools are no substitute for real users, they can help you learn more about good practices, and give you guidance on where your site needs improvements to make it more accessible.\n\nAmazon.co.uk\n\nIt may not be a decorated beauty, but Amazon is often first in functional design. It\u2019s a huge website with a lot of interactive content, but it generates just five errors on the Wave test, and is easy to read under a Color Oracle filter.\n\n Screenshot of Amazon website\n Screenshot of Amazon\u2019s Wave results \u2013 five errors\n Screenshot of Amazon through a Color Oracle filter\n\n24 ways\n\nWhen Tim Van Damme redesigned 24 ways back in 2007, it was a striking and unusual design that showed what could be achieved with CSS and some imagination. Despite the complexity of the design, it gets an outstanding zero errors on the Wave test, and is still readable under a Color Oracle filter.\n\n Screenshot of pre-2013 24 ways website design\n Screenshot of 24 ways Wave results \u2013 zero errors\n Screenshot of 24ways through a Color Oracle filter\n\nOpera\u2019s Shiny Demos\n\nDemos and prototypes are notorious for ignoring accessibility, but Opera\u2019s Shiny Demos site shows how exploring new technologies doesn\u2019t have to exclude anyone. It only gets one error on the Wave test, and looks fine under a Color Oracle filter.\n\n Screenshot of Opera\u2019s Shiny Demos website\n Screenshot of Opera\u2019s Shiny Demos Wave results \u2013 1 error\n Screenshot of Opera\u2019s Shiny Demos through a Color Oracle filter\n\nSoundCloud\n\nWhen a site is more app-like, relying on more interaction from the user, accessibility can be more challenging. However, SoundCloud only gets one error on the Wave test, and the colour contrast holds up well under a Color Oracle filter.\n\n Screenshot of SoundCloud website\n Screenshot of SoundCloud\u2019s Wave results \u2013 one error\n Screenshot of SoundCloud through a Color Oracle filter\n\nEducation and balance\n\nAs with most web design, doing accessibility well is about combining your knowledge of accessibility with your project\u2019s context to create a balance that serves your users\u2019 needs. Your types of content and interactions will dictate one set of constraints. Your users\u2019 needs and goals will dictate another. In broad terms, web design as a practice is finding the equilibrium between these constraints.\n\nAnd then there\u2019s just caring. The web as a platform is open, affordable and available to many. Accessibility is our way to ensure that nobody gets shut out.", "year": "2013", "author": "Laura Kalbag", "author_slug": "laurakalbag", "published": "2013-12-10T00:00:00+00:00", "url": "https://24ways.org/2013/why-bother-with-accessibility/", "topic": "design"} {"rowid": 6, "title": "Run Ragged", "contents": "You care about typography, right? Do you care about words and how they look, read, and are understood? If you pick up a book or magazine, you notice the moment something is out of place: an orphan, rivers within paragraphs of justified prose, or caps masquerading as small caps. So why, I ask you, is your stance any different on the web?\n\nWe\u2019re told time and time again that as a person who makes websites we have to get comfortable with our lack of control. On the web, this is a feature, not a bug. But that doesn\u2019t mean we have to lower our standards, or not strive for the same amount of typographic craft of our print-based cousins. We shouldn\u2019t leave good typesetting at the door because we can\u2019t control the line length.\n\nWhen I typeset books, I\u2019d spend hours manipulating the text to create a pleasurable flow from line to line. A key aspect of this is manicuring the right rag \u2014 the vertical line of words on ranged-left text. Maximising the space available, but ensuring there are no line breaks or orphaned words that disrupt the flow of reading. Setting a right rag relies on a bunch of guidelines \u2014 or as I was first taught to call them, violations! \n\nViolation 1. Never break a line immediately following a preposition\n\nPrepositions are important, frequently used words in English. They link nouns, pronouns and other words together in a sentence. And links should not be broken if you can help it. Ending a line on a preposition breaks the join from one word to another and forces the reader to work harder joining two words over two lines.\n\nFor example: \n\n\n\tThe container is for the butter\n\n\nThe preposition here is for and shows the relationship between the butter and the container. If this were typeset on a line and the line break was after the word for, then the reader would have to carry that through to the next line. The sentence would not flow.\n\nThere are lots of prepositions in English \u2013 about 150 \u2013 but only 70 or so in use.\n\nViolation 2. Never break a line immediately following a dash\n\nA dash \u2014 either an em-dash or en-dash \u2014 can be used as a pause in the reading, or as used here, a point at which you introduce something that is not within the flow of the sentence. Like an aside. Ending with a pause on the end of the line would have the same effect as ending on a preposition. It disrupts the flow of reading.\n\nViolation 3. No small words at the end of a line\n\nDon\u2019t end a line with small words. Most of these will actually be covered by violation \u21161. But there will be exceptions. My general rule of thumb here is not to leave words of two or three letters at the end of a line.\n\nViolation 4. Hyphenation\n\nIn print, hyphens are used at the end of lines to join words broken over a line break. Mostly, this is used in justified body text, and no doubt you will be used to seeing it in newspapers or novels. A good rule of thumb is to not allow more than two consecutive lines to end with a hyphen.\n\nOn the web, of course, we can use the CSS hyphens property. It\u2019s reasonably supported with the exception of Chrome. Of course, it works best when combined with justified text to retain the neat right margin.\n\nViolation 5. Don\u2019t break emphasised phrases of three or fewer words\n\nIf you have a few words emphasised, for example:\n\n\n\tHe calls this problem definition escalation\n\n\n\u2026then try not to break the line among them. It\u2019s important the reader reads through all the words as a group.\n\nHow do we do all of that on the web?\n\nAll of those guidelines are relatively easy to implement in print. But what about the web? Where content is poured into a template from a CMS? Well, there are things we can do. Meet your new friend, the non-breaking space, or as you may know them: \u00a0.\n\nThe guidelines above are all based on one decision for the typesetter: when should the line break? \n\nWe can simply run through a body of text and add the \u00a0 based on these sets of questions:\n\n\n\tAre there any prepositions in the text? If so, add a \u00a0 after them.\n\tAre there any dashes? If so, add a \u00a0 after them.\n\tAre there any words of fewer than three characters that you haven\u2019t already added spaces to? If so, add a \u00a0 after them.\n\tAre there any emphasised groups of words either two or three words long? If so, add a \u00a0 in between them.\n\n\nFor a short piece of text, this isn\u2019t a big problem. But for longer bodies of text, this is a bit arduous. Also, as I said, lots of websites use a CMS and just dump the text into a template. What then? We can\u2019t expect our content creators to manually manicure a right rag based on these guidelines. In this instance, we really need things to be automatic.\n\nThere isn\u2019t any reason why we can\u2019t just pass the question of when to break the line straight to the browser by way of a script which compares the text against a set of rules. In plain English, this script could be to scan the text for:\n\n\n\tPrepositions. If found, add \u00a0 after them.\n\tDashes. If found, add \u00a0 after them.\n\tWords fewer than three characters long that aren\u2019t prepositions. If found, add \u00a0 after them.\n\tEmphasised phrases of up to three words in length. If found, add \u00a0 between all of the words.\n\n\nAnd there we have it.\n\nA note on fluidity\n\nAn important consideration of this script is that it doesn\u2019t scan the text to see what is at the end of a line. It just looks for prepositions, dashes, words fewer than three characters long, and emphasised words within paragraphs and applies the \u00a0 accordingly regardless of where the thing lives. This is because in a fluid layout a word might appear in the beginning, middle or the end of a line depending on the width of the browser. And we want it to behave in the right way when it does find itself at the end.\n\nSee it in action!\n\nMy friend and colleague, Nathan Ford, has written a small JavaScript called Ragadjust that does all of this automatically. The script loops through a webpage, compares the text against the conditions, and then inserts \u00a0 in the places that violate the conditions above.\n\nYou can get the script from GitHub and see it in action on my own website.\n\nSome caveats\n\nAs my friend Jon Tan says, \u201cThere are no rules in typography, just good or bad decisions\u201d, and typesetting the right rag is no different. \n\n\n\tThe guidelines for the violations above are useful for justified text, too. But we need to be careful here. Too stringent adherence to these violations could lead to ugly gaps in our words \u2014 called rivers \u2014 as the browser forces justification.\n\tThe violation regarding short words at the end of sentences is useful for longer line lengths, or measures, of text. When the measure gets shorter, maybe five or six words, then we need to be more forgiving as to what wraps to the next line and what doesn\u2019t. In fact, you can see this happening on my site where I\u2019ve not included a check on the size of the browser window (purposefully, for this demo, of course. Ahem).\n\tThis article is about applying these guidelines to English. Some of them will, no doubt, cross over to other languages quite well. But for those languages, like German for instance, where longer words tend to be in more frequent use, then some of the rules may result in a poor right rag.\n\n\nMarginal gains\n\nIn 2007, I spoke with Richard Rutter at SXSW on web typography. In that talk, Richard and I made a point that good typographic design \u2014 on the web, in print; anywhere, in fact \u2014 relies on small, measurable improvements across an entire body of work. From heading hierarchy to your grid system, every little bit helps. In and of themselves, these little things don\u2019t really mean that much. You may well have read this article, shrugged your shoulders and thought, \u201cHuh. So what?\u201d But these little things, when added up, make a difference. A difference between good typographic design and great typographic design.\n\n \n\nAppendix\n\nPreposition whitelist\n\naboard\nabout\nabove\nacross\nafter\nagainst\nalong\namid\namong\nanti\naround\nas\nat\nbefore\nbehind\nbelow\nbeneath\nbeside\nbesides\nbetween\nbeyond\nbut\nby\nconcerning\nconsidering\ndespite\ndown\nduring\nexcept\nexcepting\nexcluding\nfollowing\nfor\nfrom\nin\ninside\ninto\nlike\nminus\nnear\nof\noff\non\nonto\nopposite\noutside\nover\npast\nper\nplus\nregarding\nround\nsave\nsince\nthan\nthrough\nto\ntoward\ntowards\nunder\nunderneath\nunlike\nuntil\nup\nupon\nversus\nvia\nwith\nwithin\nwithout", "year": "2013", "author": "Mark Boulton", "author_slug": "markboulton", "published": "2013-12-24T00:00:00+00:00", "url": "https://24ways.org/2013/run-ragged/", "topic": "design"} {"rowid": 12, "title": "Untangling Web Typography", "contents": "When I was a carpenter, I noticed how homeowners often had this deer-in-the-headlights look when the contractor I worked for would ask them to make tons of decisions, seemingly all at once.\n\nSquare or subway tile? Glass or ceramic? Traditional or modern trim details? Flat face or picture frame cabinets? Real wood or laminate flooring? Every day the decisions piled up and were usually made in the context of that room, or that part of that room. Rarely did the homeowner have the benefit of taking that particular decision in full view of the larger context of the project. And architectural plans? Sure, they lay out the broad strokes, but there is still so much to decide.\n\nTypography is similar. Designers try to make sites that are easy to use and understand visually. They labour over the details of line height, font size, line length, and font weights. They consider the relative merits of different typographical scales for applications versus content-driven sites. Frequently, designers consider all of this in the context of one page, feature, or view of an application. They are asked to make a million tiny decisions.\n\nSometimes designers just bump up the font size until it looks right.\n\nI don\u2019t see anything wrong with that. Instincts are important. Designing in context is easier. It\u2019s OK to leave the big picture until later. Design a bunch of things, and then look for the patterns. You can\u2019t always know everything up front. How does the current feature relate to all the other features on the site? For a large site, just like for a substantial remodel, the number of decisions you would need to internalize to make that knowable would be prohibitively large.\n\nWhen typography goes awry\n\nI should be honest. I know very little about typography. I struggle to understand vertical rhythm and the math in Tim Ahrens\u2019s talks about the interaction between type design and rendering technology kind of melted my brain. I have an unusual perspective because I\u2019m not the one making the design decisions, but I am the one implementing them and often cleaning up when a project goes off the rails.\n\nI\u2019ve seen projects with thousands of font-size declarations and headings. One project even had over ten thousand margin declarations. So while I appreciate creative exploration, I\u2019m also eager to establish patterns in typography and make sure we aren\u2019t choosing not to choose. Or, choosing all the things.\n\nAnalyzing a site\u2019s typography\n\nMost of my projects start out with an evaluation of the client\u2019s existing CSS. I look for duplication in the CSS by using Grep, though functionality is landing soon in CSS Lint to do the same thing automatically. The goal is to find the underlying missing abstractions that, once in place, would allow developers to create new functionality without needing to write additional CSS. In addition to that, my team and I would comb through each site (generally, around ten pages is enough to get the big picture), and take screenshots of each of the components we found.\n\nIn this way, we could look for subtle visual differences that were unlikely to add value to the user. By correcting these differences, we could help make the design more consistent, and at the same time the code leaner and more performant. Typography is much like a homeowner who chooses to incorporate too many disparate design elements, pairing a mid-century modern sofa with flowered country cottage curtains. Often the typography of a site ends up collecting an endless array of new typefaces as the site\u2019s overall styles evolve. Designers come and go on a project, and eventually no one can remember how the 16px Verdana got into the codebase.\n\nAutomation\n\nWe used to do this work by hand. It was incredibly tedious. We\u2019d go through the site, taking screenshots and meticulously documenting the style information we found. We didn\u2019t have to do that many times before it became incredibly clear that the task needed to be automated. So we built a little tool called the Type-o-matic that could do it for us.\n\nTo try it on your site:\n\n\n\tDownload and install the Firebug extension to Firefox\n\tDownload and install the Type-o-matic extension to Firebug (I know, I fully intend to port it to Chrome)\n\tNow, visit the site you\u2019d like to test\n\tRight click and choose Inspect element with Firebug\n\tNow click on the Typography tab\n\tClick Persist\n\tClick Generate Report\n\tChoose which pages to analyze (we\u2019ve found that ten is a good number to get the big picture, but you can analyze as many as you\u2019d like\u200a\u2014\u200ait will even work on just one page!)\n\tNow navigate to other pages, and on each subsequent page, click Generate Report\n\tThe table of results can be a bit difficult to interact with, so you can always click Copy to clipboard, and copy the results (JSON).\n\n\n \n \nA screenshot of Type-o-matic in action\n\n\nWhat does this data mean?\n\nWhen you\u2019ve analyzed as many pages or different views as you\u2019d like, you\u2019ll start to see some interesting patterns emerge in the data. In the right-hand column, you\u2019ll see examples of how each kind of typography we found has been used in a real context on your site. It is organized by color and then by size so you can easily see how you are using typography.\n\nThe next thing you\u2019ll want to take a look at is in the first column, called \u201cCount\u201d. We\u2019ve counted how many times you\u2019ve used each combination of typographical styles. This can be incredibly helpful when deciding which styles were intentional, versus one-off color pick errors or experiments that never got removed from the code base. If you\u2019ve used one color blue 1,400 times, and another just 23, it\u2019s pretty obvious which is more in line with broader site-wide styles.\n\nConsistency before perfection\n\nIt can be really tempting to try to make everything perfect\u200a\u2014\u200ato try to make every decision final. When you use the data you can collect from this tool, I\u2019d recommend trying to get to consistent before you try to make things perfect. Stop using fifteen different shades of blue type first, and then if you want to change to a new blue, go for it! You\u2019ll be able to make design changes much more easily once you\u2019ve reduced the total number of typographical styles you rely on.\n\nLower the importance of the decisions you are making. Our sites, like ourselves, are always a work in progress. Or, as a carpenter I used to work with said, \u201cYou\u2019re not building a fucking piano.\u201d We\u2019re not building houses. We can choose one typeface today and a different one tomorrow. It is OK to experiment. Be brave.", "year": "2013", "author": "Nicole Sullivan", "author_slug": "nicolesullivan", "published": "2013-12-20T00:00:00+00:00", "url": "https://24ways.org/2013/untangling-web-typography/", "topic": "design"} {"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": 9, "title": "How to Write a Book", "contents": "Were you recently inspired to write a book after reading Owen Gregory\u2019s compendium of author insights? Maybe so inspired to strike out on your own and self-publish? \n\nBased on personal experience, writing a book is hard. It requires a great deal of research, experience, and patience. To be able to consolidate your thoughts and what you\u2019ve learned into a sensible and readable tome is an admirable feat. To decide to self-publish and take on yourself all of the design, printing, distribution, and so much more is tantamount to insanity. Again, based on personal experience.\n\nSo, why might you want to self-publish?\n\nIf you\u2019ve spent many a late night doing cross-browser testing just to know that your site works flawlessly in twenty-four different browsers \u2014 including Mosaic, of course \u2014 then maybe you\u2019ll understand the fun that comes from doing it all.\n\nWorking with a publisher, you\u2019re left to focus on one core thing: writing. That\u2019s a good thing. A good publisher has the right resources to help you get your idea polished and the distribution network to get your book on store shelves around the world. It\u2019s a very proud moment to be able to walk into a book store and see your book sitting there on the shelf.\n\nSelf-publishing can also be a wonderful process as you get to own it from beginning to end. Every decision is yours and if you\u2019re a control freak like me, this can be a very rewarding experience. \n\nWhile there are many aspects to self-publishing, I\u2019m going to speak to just one of them: creating an ebook.\n\nFormats \n\nIn creating an ebook, you first need to decide what formats you wish to support. There are three main formats, each with their own pros and cons:\n\n\n\tPDF\n\tEPUB\n\tMOBI\n\n\nPDFs are supported on almost every device (Windows, Mac, Kindle, iPad, Android, etc.) and can even be a stepping stone to creating a print version of your book. PDFs allow for full typographic and design control, but at the cost of needing to fit things into a predefined page layout. Is it US Letter or A4? Or is it a format that isn\u2019t easily printed by readers on their home printers?\n\nEPUB is a more fluid format that is supported by the Apple iPad, iPhone, and now on the desktop with OS X Mavericks. It\u2019s also supported by Google Play for Android devices. While EPUB is supported on other devices, you\u2019re likely to choose EPUB because you\u2019re targeting your book at the Apple audience. The EPUB format is HTML-based with support for some CSS and even video and interactive elements. You can create very rich and exciting experiences using the EPUB format that just aren\u2019t possible with PDF or MOBI. However, if you decide to support multiple file formats, you\u2019ll likely find \u2014 as I did \u2014 that a consistent experience between all formats is easier to build and maintain, and therefore the extra benefits of interactivity go out the window.\n\nMOBI is a format originally developed for the Mobipocket Reader but more popularly supported by the Amazon Kindle. If you\u2019re looking to attract the Kindle audience or publish to Amazon via the Kindle Direct Publishing platform then the HTML-based MOBI format is the format you\u2019ll want to go with. \n\nDistribution will probably factor in heavily with what format you decide to go with. Many people I know who self-publish go with PDF only due to its ubiquity. \n\nIf you want to garner a wider audience by distributing via Amazon or the iBookstore then you\u2019ll need to think about supporting all three formats (as I did).\n\nWhat tools should I use?\n\nI spent a lot of time figuring out the right toolset and finally got something that suits me just right.\n\nIn the past, when working with a publisher, I was given a Microsoft Word template that was passed back and forth between myself, the editor, and tech reviewer. This template has been the bane of any book writer that I\u2019ve spoken to. Not every publisher is like that, though. Some publishers, like O\u2019Reilly, use DocBook, an XML-based format that can be converted into PDF, EPUB, and MOBI.\n\nPublishers already have a style guide and whether it\u2019s DocBook or a Word template, they have the tools already in place to easily convert your work into multiple formats.\n\nSelf-publishing means that you\u2019ll likely have to do a lot of tweaking to get things looking and working the way you want them to. I tried DocBook and the open source export tools didn\u2019t create HTML to my liking. Fixing even the most mundane things required fiddling with XSL transformations for hours on end. Not the way I like to spend my time. I can only imagine the hoops I would\u2019ve had to go through to get a PDF to look half-decent.\n\nTools like Pages or Scrivener offer up the ability to publish to multiple formats, too, but none offered me the control over the output that I truly desired. Have a mentioned that I\u2019m a control freak?\n\nI ended up writing my book using a technology that I already knew quite well: HTML. By writing in HTML, I already had something that I could post on my website, use for the EPUB and use for the MOBI format. All without having to change a thing. (That\u2019s right: the same HTML that is used on SMACSS.com is used in the EPUB and is used in the MOBI.)\n\nWhat about PDF? I could open up the HTML in a web browser, choose Save as PDF and be done with it but let\u2019s face it: the filename and date attached to every single page doesn\u2019t exactly scream professional. Web browsers actually do a surprisingly poor job with supporting the CSS paged media spec.\n\nI had resorted to copying and pasting the content into Pages and saving as PDF from there. It wasn\u2019t elegant but it worked. However, any changes to my HTML source required redoing those changes in Pages, as well. \n\nThen I met my Prince Charming: Prince XML. It\u2019s pricey but it works incredibly well. It takes HTML and CSS (that very format I\u2019ve been using for all of my other file formats) and will generate a PDF via a command line interface. Prince supports CSS paged media including headers, footers, page counts, and alternating page styles. \n\nFrom one format, HTML, I can now easily publish to PDF, MOBI, and EPUB, and even my website. I use the PDF version to send to the printer along with cover art to be bound and ready to ship around the world. It\u2019s amazing how versatile HTML (and CSS) is.\n\nTo learn more about writing books with HTML and CSS, I recommend reading Building Books with CSS3 over at A List Apart.\n\nCreating an EPUB\n\nLet\u2019s take a step back. Prince gets us from HTML to PDF but how do we make an EPUB out of the HTML? \n\nAn EPUB file is essentially a ZIP file with a renamed extension. There are some core files that you need to start with:\n\nRoot\n META-INF\n container.xml\n mimetype\n content.opf\n toc.ncx\n\nAfter that, you can start adding your content to the project. Be sure to update the toc.ncx (Table of Contents) and content.opf (the ebook manifest) with any changes you make to your project.\n\nYou can learn more about the file formats with the EPUB Format Construction Guide.\n\nOnce all your files are in place, you\u2019ll need to create the EPUB file by running two commands (on OS X, at least):\n\nzip -X0 your-ebook.epub mimetype\nzip -Xur9D your-ebook.epub *\n\nThe mimetype needs to be the first file inside the ZIP file and therefore gets added first. Then, the rest of the files are added. \n\nI\u2019ve added a function to my .bash_profile to make this even easier:\n\nfunction epub()\n{\n zip -q0X $@ mimetype; zip -qXr9D $@ *\n}\n\nThen, within the folder from which I want to create an ebook, I just run epub your-ebook.epub from the Terminal command line and the EPUB file should be ready to go.\n\nCreating the MOBI\n\nWe have our EPUB and we have our PDF. The last step is the MOBI file. For this, I call upon Calibre. Calibre can be used as a reader and as a library but I use it exclusively to export my EPUB files to MOBI. \n\nCalibre includes a command line utility to convert from EPUB to MOBI. (To install the command line tools, go to Preferences > Advanced > Miscellaneous and click Install Command Line Tools.)\n\nebook-convert your-ebook.epub your-ebook.mobi \n\nSpread the joy\n\nNow that you have all of your different file formats, you need to get them into the hands of people who want to (ho-ho-hopefully) buy your book!\n\nThere are a number of marketplaces such as Amazon\u2019s Kindle Direct Publishing, iBookstore, Google Play, and NOOK Press.\n\nSome publishers, like PragProg and O\u2019Reilly will also add self-published books to their roster if they feel it\u2019s a good fit for their audience.\n\nWith any distribution, you\u2019ll have to give up a percentage of your sales\u2014from 30% to 70% of each sale, so consider your options wisely.\n\nOf course, you can always open your own online store and reap as much of the revenue as possible, assuming you can get the traffic to your site. Handling your own distribution allows you to create a deeper one-on-one connection with your customers, something that is impossible with other distribution channels since you don\u2019t get customer information through other services\u2014even though you are giving them a huge chunk of your sales!\n\nGo forth and prosper\n\nThere\u2019s a lot of thought and time that goes into writing a book and just as much thought and time can go into creating, publishing, and marketing your book once you\u2019re done. \n\nIn the end, self-publishing can be a very rewarding process and well worth the time that goes into it.", "year": "2013", "author": "Jonathan Snook", "author_slug": "jonathansnook", "published": "2013-12-19T00:00:00+00:00", "url": "https://24ways.org/2013/how-to-write-a-book/", "topic": "content"} {"rowid": 19, "title": "In Their Own Write: Web Books and their Authors", "contents": "The currency of written communication \u2014 words on the page, words on the screen \u2014 comprises many denominations. To further our ends in web design and development, we freely spend and receive several: tweets aphoristic and trenchant, banal and perfunctory; blog posts and articles that call us to action or reflection; anecdotes, asides, comments, essays, guides, how-tos, manuals, musings, notes, opinions, stories, thoughts, tips pro and not-so-pro. So many, many words.\n\nOur industry (so much more than this, but what on earth are we, collectively?), our community thrives on writing and sharing knowledge and experience. 24 ways is a case in point. Everyone can learn and contribute through reading and writing \u2014 it\u2019s what we\u2019ve always done.\n\nTo web authors and readers seeking greater returns, though, broader culture has vouchsafed an enduring and singular artefact: the book.\n\nLast month I asked a small sample of web book authors if they would be prepared to answer a few questions; most of them kindly agreed. In spirit, the survey was informal: I had neither hypothesis nor unground axe. I work closely with writers \u2014 and yes, I\u2019ve edited or copy-edited books by several of the authors I surveyed \u2014 and wanted to share their thoughts about what it was like to write a book (\u201c\u2026it was challenging to find a coherent narrative\u201d), why they did it (\u201cWho wouldn\u2019t want to?\u201d) and what they learned from the experience (\u201cThat I could!\u201d).\n\nReasons for writing a book\n\nIn web development the connection between authors and readers is unusually close and immediate. Working in our medium precipitates a unity that\u2019s rare elsewhere. Yet writing and publishing a book, even during the current books revolution, is something only a few of us attempt and it remains daunting and a little remote. What spurs an author to try it? For some, it\u2019s a deeply held resistance to prevailing trends:\n\nI felt that designers and developers needed to be shaken out of what seemed to me had been years of stagnation.\n\u2014Andrew Clarke\n\n\nOr even a desire to protect us from ourselves:\n\nI felt that without a book that clearly defined progressive enhancement in a very approachable and succinct fashion, the web was at risk. I was seeing Tim Berners-Lee\u2019s vision of universal availability slip away\u2026\n\u2014Aaron Gustafson\n\n\nSometimes, there\u2019s a knowledge gap to be filled by an author with the requisite excitement and need to communicate. Jon Hicks took his \u201cpet subject\u201d and was \u201centhused enough to want to spend all that time writing\u201d, particularly because:\n\n\n\t\u2026there was a gap in the market for it. No one had done it before, and it\u2019s still on its own out there, with no competition. It felt like I was able to contribute something.\n\n\nCennydd Bowles felt a professional itch at a particular point in his career, understanding that\n\n\n\t[a]s a designer becomes more senior, they start looking for ways to scale the effects of their work. For some, that leads into management. For others, into writing.\n\n\nOften, though, it\u2019s also simply a personal challenge and ambition to explore a subject at length and create something substantial. Anna Debenham describes a motivation shared by several authors:\n\nTo be able to point to something more tangible than an article and be able to say \u201cI did that.\u201d\n\n\nThat sense of a book\u2019s significance, its heft and gravity even, stems partly from the cultural esteem which honours books and their authors. Books have a long history as sources of wisdom, truth and power. Even with more books being published each year than ever before, writing one is still commonly considered a laudable achievement, including in our field.\n\nChallenges of writing a book\n\nReceived wisdom has it that writing online should be brief and chunky and approachable: get to the point; divide it all up; subheadings and lists are our friends; write like you\u2019re talking; no one has time to read. Much of such advice is true. Followed well, it lends our writing punch and pith, vigour and vim. The web is nimble, the web keeps up, and it suits what we write about developing for it. It\u2019s perfect for delivering our observations, queries and investigations into all the various aspects of the work, professional and personal.\n\nYet even for digital natives like web authors, books printed and electronic retain an attractive glister. \n\nIdeas can be developed more fully, their consequences explored to greater depth and extended with more varied examples, and the whole conveyed with more eloquence, more style. Why shouldn\u2019t authors delay their conclusions if the intervening text is apposite, rich with value and helps to flesh out the skeleton of an argument? Conclusions might or might not be reached, of course, but a writer is at greater liberty in a book to digress in tangential and interesting ways.\n\nWriting a book involves committing time, energy, thought and money. As Brian Suda found, it can be tough \u201cgetting the ideas out of my head into a cohesive blob of text.\u201d Some authors end up talking to themselves\u2026\n\nIt helps me to keep a real person in mind, someone who I\u2019m talking to as I write. Sometimes I have the same conversations over and over in my head.\n\u2014Andrew Clarke\n\n\n\u2026while others are thinking ahead, concerned with how their book will be received:\n\nWould anyone want to read it? Would they care? Would it be respected by my peers?\n\u2014Joe Leech\n\n\nChallenges that arose time and again included \u201cstarting\u201d and \u201cgetting words on the page\u201d as well as \u201cknowing when to stop\u201d or \u201cletting go\u201d. Personal organization problems and those caused by publishers were also widely mentioned. Time loomed large. Making time, finding time. Giving up \u201csleep and some sanity\u201d and realizing \u201cit will take you far, far, far longer than you naively assumed\u201d. Importantly, writing time is time away from gainful employment: Aaron Gustafson found the hardest thing about writing a book to be \u201cthe loss of income while I was writing.\u201d\n\nPerils and pleasures of editing\n\nEditing, be it structural, technical or copy editing, is founded on reciprocity. Without openness and a shared belief that the book is worthwhile, work can founder in acrimony and mistrust. Editors are a book\u2019s first and most critical (in every sense) readers. Effective and perceptive editing makes a book as good as it can be, finding the book within the draft like sculpture reveals the statue in the stone.\n\nA good editor calls you out on poor assumptions and challenges you to really clarify your thinking. Whilst it can be difficult during the process to have your thinking challenged, it\u2019s always been worth it \u2014 for me personally \u2014 in the long run. A good editor also reins you in when you\u2019ve perhaps wandered off track or taken a little too long to make a point.\n\u2014Christopher Murphy\n\n\nAndy Croll found editing \u201call positive\u201d and Aaron Gustafson loves \u201cworking with a strong editor [\u2026] I want someone to tell it to me straight.\u201d But it can be a rollercoaster, \u201cboth terrifying and the real moment of elation\u201d. Mixed emotions during the editing process are common:\n\nIt was very uncomfortable! I knew it was making the work stronger, but it was awkward having my inconsistencies and waffle picked apart.\n\u2014Jon Hicks\n\n\nIt can be distressing to have written work looked over by a professional, particularly for first-time book authors whose expertise lies elsewhere:\n\nI was a little nervous because I don\u2019t consider myself a skilled writer \u2014 I never dreamed of becoming an author. I\u2019m a designer, after all.\n\u2014Geri Coady\n\n\nCommunication is key, particularly when it comes to checking or changing the author\u2019s words.\n\nI like a good banter between me and the tech editor \u2014 if we can have a proper argument in Word comments, that\u2019s great.\n\u2014Rachel Andrew\n\n\nBut if handled poorly, small battles can break out. Rachel Andrew again:\n\n\n\tHowever, having had plenty of times where the technical editor has done nothing more than give a cursory glance, I started to leave little issues in for them to spot. If they picked them up I knew they were actually testing the code and I could be sure the work was being properly tech edited. If they didn\u2019t spot them, I\u2019d find someone myself to read through and check it!\n\n\nA major concern for writers is that their voices will be altered, filtered, mangled or otherwise obscured by the editing process. Good copy editing must remain unnoticed while enhancing the author\u2019s voice in print. Donna Spencer appreciated the way her editor \u201ctidied up my work and made it a million times better, but left it sounding exactly like me.\u201d Similarly, Andrew Travers \u201cwas incredibly impressed at how well my editor tightened up my own writing without it feeling like another\u2019s voice\u201d and Val Head sums up the consensus that:\n\n\n\tthe editor was able to help me express what I was trying to say in a better way [\u2026] I want to have editors for everything now.\n\n\nAt the keyboard, keep your friends close, but your editors closer.\n\nPublishing and publishers\n\nConditions ought to militate against the allure of writing a book about web design and development. More books are published each year than ever before, so readerships elude new authors and readers can struggle to find authors to trust in their fields of interest. New spaces for more expansive online writing about working on and with the web are opening up (sites like Contents Magazine and STET), and seminal online web development texts are emerging. Publishing online is simple, far-reaching and immediate.\n\nMuch more so than articles and blog posts, books take time to research, write and read; add the complexity of commissioning, editing, designing, proofreading, printing, marketing and distribution processes, and it can take many months, even years to publish. The ceaseless headlong momentum of the web can leave articles more than a few weeks old whimpering in its wake, but updating them at least is straightforward; printed books about web development can depreciate as rapidly as the technology and techniques they describe, while retaining the \u201cterrifying permanence that print bestows: your opinions will follow you forever\u201d.\n\nSo much moves on, and becomes out of date. Companies featured get bought by larger companies and die, techniques improve and solutions featured become terribly out of date. Unlike a website, which could be updated continuously, a book represents the thinking \u2018at that time\u2019.\n\u2014Jon Hicks\n\n\nPublishers work hard to mitigate these issues, promoting new books and new authors, bringing authors and readers together under a trusted banner. When a publisher packages up and releases a writer\u2019s words, it confers a seal of approval and \u201cbadge of quality\u201d, very important to new authors.\n\nPublishers have other benefits to offer, from expert knowledge:\n\nMy publisher was extraordinarily supportive (and patient). Her expertise in my chosen subject was both a pressure (I didn\u2019t want to let her down) and a reassurance (if she liked it, I knew it was going to be fine).\n\u2014Andrew Travers\n\n\n\u2026to systems and support mechanisms set up specifically to encourage writers and publish books:\n\nWorking as a team means you\u2019re bringing in everyone\u2019s expertise.\n\u2014Chui Chui Tan\n\n\nAs a writer, the best part about writing for a publisher was the writing infrastructure offered.\n\u2014Christopher Murphy\n\n\nThere can be drawbacks, however, and the occasional horror story:\n\nWe were just one small package on a huge conveyor belt. The publisher\u2019s process ruled all.\n\u2014Cennydd Bowles\n\n\nIt\u2019s only looking back I realise how poorly some publishers treat writers \u2014 especially when the work is so poorly remunerated.My worst experience was when a publisher decided, after I had completed the book, that they wanted to push a different take on the subject than the brief I had been given. Instead of talking to me, they rewrote chunks of my words, turning my advice into something that I would never have encouraged. Ultimately, I refused to let the book go out under my name alone, and I also didn\u2019t really promote the book as I would have had to point out the things I did not agree with that had been inserted!\n\u2014Rachel Andrew\n\n\nSelf-publishing is now a realistic option for web authors, and can offers \u201ccomplete control over the end product\u201d as well as the possibility of earning more than a \u201cpathetic author revenue percentage\u201d. There can be substantial barriers, of course, as self-publishing authors must face for themselves the risks and challenges conventional publishers usually bear. Ideally, creating a book is a collaboration between author and publisher. Geri Coady found that \u201cworking with my publisher felt more like working with a partner or co-worker, rather than working for a boss.\u201d\n\nWise words\n\nSo, after meeting the personal costs of writing and publishing a web book \u2014 fear, uncertainty, doubt, typing (so much typing) \u2014 and then smelling the roses of success, what\u2019s left for an author to say? Some words, perhaps, to people thinking of writing a book.\n\nDonna Spencer identifies a stumbling block common to many writers with an insight into the writing process:\n\n\n\tHaving talked to a lot of potential authors, I think most have the problem that they haven\u2019t actually figured out the \u2018answer\u2019 to their premise yet. They feel like they are stuck in the writing, but they are actually stuck in the thinking.\n\n\nFor some no-nonsense, straightforward advice to cut through any anxiety or inadequacy, Rachel Andrew encourages authors to \u201ctreat it like any other work. There is no mystery to writing, you just have to write. Schedule the time, sit down, write words.\u201d Tim Brown notes the importance of the editing process to refine a book and help authors reach their readers:\n\n\n\tHire good editors. Editors are amazing thinkers who can vastly improve the quality and clarity of a piece of writing.\n\n\nWe are too much beholden to the practical demands and challenges of technology, so Aaron Gustafson suggests a writer should \u201cfavor philosophies over techniques and your book will have a longer shelf life.\u201d\n\nMost intimations of renown and recognition are nipped in the bud by Joe Leech\u2019s warning: \u201cDon\u2019t expect fame and fortune.\u201d Although Cennydd Bowles\u2019 bitter experience can be discouraging:\n\n\n\tThe sacrifices required are immense. You probably won\u2019t make it.\n\n\n\u2026he would do things differently for a future book:\n\n\n\tI would approach the book with [\u2026] far more concern about conveying the damn joy of what I do for a living.\n\n\nThe pleasure of writing, not just having written is captured by James Chudley when he recalls:\n\n\n\tHow much I enjoy writing and also how much I enjoy the discipline or having a side project like this. It\u2019s a really good supplement to working life.\n\n\nAnd Jon Hicks has words that any author will find comforting:\n\n\n\tIt will be fine. Everything will be fine. Just get on with it!\n\n\n\n\nAs the web expands effortlessly and ceaselessly to make room for all our words, yet it can also discourage the accumulation of any particular theme in one space, dividing rich seams and scattering knowledge across the web\u2019s surface and into its deepest reaches. How many words become weightless and insubstantial, signals lost in the constant white noise of indistinguishable voices, unloved, unlinked? The web forgets constantly, despite the (somewhat empty) promise of digital preservation: articles and data are sacrificed to expediency, profit and apathy; online attention, acknowledgement and interest wax and wane in days, hours even.\n\nBooks can encourage deeper engagement in readers, and foster faith in an author, particularly if released under the imprint of a recognized publisher within the field. And books are changing. Although still not widely adopted, EPUB3 is the new standard in ebooks, bringing with it new possibilities for interaction and connection: readers with the text; readers with readers; and readers with authors. EPUB3 is built on HTML, CSS and JavaScript \u2014 sound familiar? In the past, we took what we could from the printed page to make the web; now books are rubbing up against what we\u2019ve made.\n\nSo: a book.\n\nEver thought you could write one? Should write one? Would?\n\n\n\nI\u2019d like to thank all the authors who wrote their books and answered my questions.\n\n\n\tRachel Andrew \u00b7 CSS3 Layout Modules, The CSS3 Anthology and more\n\tCennydd Bowles \u00b7 Undercover User Experience Design, with James Box\n\tTim Brown \u00b7 Combining Typefaces\n\tJames Chudley \u00b7 Usability of Web Photos\n\tAndrew Clarke \u00b7 Hardboiled Web Design\n\tGeri Coady \u00b7 Colour Accessibility\n\tAndy Croll \u00b7 HTML Email\n\tAnna Debenham \u00b7 Front-end Style Guides\n\tAaron Gustafson \u00b7 Adaptive Web Design\n\tVal Head \u00b7 CSS Animations\n\tJon Hicks \u00b7 The Icon Handbook\n\tJoe Leech \u00b7 Psychology for Designers\n\tChristopher Murphy \u00b7 The Craft of Words, with Niklas Persson\n\tDonna Spencer \u00b7 Information Architecture, Card Sorting and How to Write Great Copy for the Web\n\tBrian Suda \u00b7 Designing with Data\n\tChui Chui Tan \u00b7 International User Research\n\tAndrew Travers \u00b7 Interviewing for Research", "year": "2013", "author": "Owen Gregory", "author_slug": "owengregory", "published": "2013-12-15T00:00:00+00:00", "url": "https://24ways.org/2013/web-books/", "topic": "content"} {"rowid": 24, "title": "Kill It With Fire! What To Do With Those Dreaded FAQs", "contents": "In the mid-1640s, a man named Matthew Hopkins attempted to rid England of the devil\u2019s influence, primarily by demanding payment for the service of tying women to chairs and tossing them into lakes.\n\nUnsurprisingly, his methods garnered criticism. Hopkins defended himself\u00a0in The Discovery of Witches\u00a0in 1647, subtitled \u201cCertaine Queries answered, which have been and are likely to be objected against MATTHEW HOPKINS, in his way of finding out Witches.\u201d\n\nEach \u201cquerie\u201d was written in the voice of an imagined detractor, and answered in the voice of an imagined defender (always referring to himself as \u201cthe discoverer,\u201d or \u201chim\u201d):\n\n\n\tQuer. 14.\n\n\tAll that the witch-finder doth is to fleece the country of their money, and therefore rides and goes to townes to have imployment, and promiseth them faire promises, and it may be doth nothing for it, and possesseth many men that they have so many wizzards and so many witches in their towne, and so hartens them on to entertaine him.\n\n\tAns.\n\n\tYou doe him a great deale of wrong in every of these particulars.\n\n\nHopkins\u2019 self-defense was an early modern English FAQ.\n\nDigital beginnings\n\nQuestion and answer formatting certainly isn\u2019t new, and stretches back much further than witch-hunt days. But its most modern, most notorious, most reviled incarnation is the internet\u2019s frequently asked questions page.\n\nFAQs began showing up on pre-internet mailing lists\u00a0as a way for list members to answer and pre-empt newcomers\u2019 repetitive questions:\n\n\n\tThe presumption was that new users would download archived past messages through ftp. In practice, this rarely happened and the users tended to post questions to the mailing list instead of searching its archives. Repeating the \u201cright\u201d answers becomes tedious\u2026\n\n\nWhen all the users of a system can hear all the other users, FAQs make a lot of sense: the conversation needs to be managed and manageable. FAQs were a stopgap for the technological limitations of the time.\n\nBut the internet moved past mailing lists. Online information can be stored, searched, filtered, and muted; we choose and control our conversations. New users no longer rely on the established community to answer their questions for them.\n\nAnd yet, FAQs are still around. They\u2019re a content anti-pattern, replicated from site to site to solve a problem we no longer have.\n\nWhat we hate when we hate FAQs\n\nAs someone who creates and structures online content \u2013 always with the goal of making that content as useful as possible to people \u2013 FAQs drive me absolutely batty. Almost universally, FAQs represent the opposite of useful. A brief list of their sins:\n\n\nDouble trouble\nDuplicated content is practically a given with FAQs. They\u2019re written as though they\u2019ll be accessed in a vacuum \u2013 but search results, navigation patterns, and curiosity ensure that users will seek answers throughout the site. Is our goal to split their focus? To make them uncertain of where to look? To divert them to an isolated microcosm of the website? Duplicated content means user confusion (to say nothing of the duplicated workload for maintaining content).\nLeaving the job unfinished\nMany FAQs fail before they\u2019re even out of the gate, presenting a list of questions that\u2019s incomplete (too short and careless to be helpful) or irrelevant (avoiding users\u2019 real concerns in favor of soundbites). Alternately, if the right questions are there, the answers may be convoluted, jargon-heavy, or otherwise difficult to understand.\nLong lists of not-my-question\nGetting a single answer often means sifting through a haystack of questions. For each potential question, the user must read, comprehend, assess, move on, rinse, repeat. That\u2019s a lot of legwork for little reward \u2013 and a lot of opportunity for mistakes. Users may miss their question, or they may fail to recognize a differently worded version of their question, or they may not notice when their sought-after answer appears somewhere they didn\u2019t expect.\nThe ventriloquist act\nFAQs shift the point of view. While websites speak on behalf of the organization (\u201cour products,\u201d \u201cour services,\u201d \u201cyou can call us for assistance,\u201d etc.), FAQs speak as the user \u2013 \u201cI can\u2019t find my password\u201d or \u201cHow do I sign up?\u201d Both voices are written from the first-person perspective, but speak for different entities, which is disorienting: it breaks the tone and messaging across the website. It\u2019s also presumptuous: why do you get to speak for the user?\n\n\nThese all underscore FAQs\u2019 fatal flaw: they are content without context, delivered without regard for the larger experience of the website. You can hear the absurdity in the name itself: if users are asking the same questions so frequently, then there is an obvious gulf between their needs and the site content. (And if not, then we have a labeling problem.)\n\nInstead of sending users to a jumble of maybe-it\u2019s-here-maybe-it\u2019s-not questions, the answers to FAQs should be found naturally throughout a website. They are not separated, not isolated, not other. They are\u00a0the content.\n\nTo present it otherwise is to create a runaround, and users know it. Jay Martel\u2019s parody, \u201cF.A.Q.s about F.A.Q.s\u201d\u00a0captures the silliness and frustration of such a system:\n\n\n\tQ: Why are you so rude?\n\n\tA: For that answer, you would have to consult an F.A.Q.s about F.A.Q.s about F.A.Q.s. But your time might be better served by simply abandoning your search for a magic answer and taking responsibility for your own profound ignorance.\n\n\nFAQs aren\u2019t magic answers. They don\u2019t resolve a content dilemma or even help users. Yet they keep cropping up, defiant, weedy, impossible to eradicate.\n\nWhere are they all coming from?\n\nBlame it on this: writing is hard. When generating content, most of us do whatever it takes to get some words on the screen. And the format of question and answer makes it easy: a reactionary first stab at content development.\n\nAfter all, the point of website content is to answer users\u2019 questions. So this \u2013 to give everyone credit \u2013 is a really good move. Content creators who think in terms of questions and answers are actually thinking of their users, particularly first-time users, trying to anticipate their needs and write towards them.\n\nIt\u2019s a good start. But it\u2019s scaffolding: writing that helps you get to the writing you\u2019re supposed to be doing. It supports you while you write your way to the heart of your content. And once you get there, you have to look back and take the scaffolding down.\n\nLeaving content in the Q&A format that helped you develop it is missing the point. You\u2019re not there to build scaffolding. You have to see your content in its naked purpose and determine the best method for communicating that purpose \u2013 and it usually won\u2019t be what got you there.\n\nThe goal (to borrow a lesson from content management systems) is to separate the content from its presentation, to let the meaning of the content inform its display.\n\nThis is, of course, a nice theory.\n\nAn occasionally necessary evil\n\nI have a lot of clients who adore FAQs. They\u2019ve developed their content over a long period of time. They\u2019ve listened to the questions their users are asking. And they\u2019ve answered them all on a page that I simply cannot get them to part with.\n\nWhich means I\u2019ve had to consider that there may be occasions where an FAQ page is appropriate.\n\nAs an example: one of my clients is a financial office in a large institution. Because this office manages several third-party systems that serve a range of niche audiences, they had developed FAQs that addressed hyper-specific instances of dysfunction within systems for different users \u2013 \u00e0 la \u201cI\u2019m a financial director and my employee submitted an expense report in such-and-such system and it returned such-and-such error. What do I do?\u201d\n\nYes, this content could be removed from the question format and rewritten. But I\u2019m not sure it would be an improvement. It won\u2019t necessarily resolve concerns about length and searchability, and the different audiences may complicate the delivery. And since the work of rewriting it didn\u2019t fit into the client workflow (small team, no writers, pressed for time), I didn\u2019t recommend the change.\n\nI\u2019ve had to make peace with not being to torch all the FAQs on the internet. Some content, like troubleshooting information or complex procedures, may be better in that format. It may be the smartest way for a particular client to handle that particular information.\n\nOf course, this has to be determined on a case-by-case basis, taking into account the amount of content, the subject matter, the skill levels of the content creators, the publishing workflow, and the search habits of the users.\n\nIf you determine that an FAQ page is the only way to go, ask yourself:\n\n\n\tIs there a better label or more specific term for the page (support, troubleshooting, product concerns, etc.)?\n\tIs there way to structure the page, categorize the questions, or otherwise make it easier for users to navigate quickly to the answer they need?\n\tIs a question and answer format absolutely the best way to communicate this information?\n\n\nForm follows function\n\nJust as a question and answer format isn\u2019t necessarily required to deliver the content, neither is it an inappropriate method in and of itself. Content professionals have developed a knee-jerk reaction:\u00a0It\u2019s an FAQ page! Quick, burn it! Buuuuurn it!\n\nBut there\u2019s no inherent evil in questions and answers. Framing content in an interrogatory construct is no more a deal with the devil than subheads and paragraphs, or narrative arcs, or bullet points.\n\nYes, FAQs are riddled with communication snafus. They deserve, more often than not, to be tied to a chair and thrown into a lake. But that wouldn\u2019t fix our content problems. FAQs are a shiny and obvious target for our frustration, but they\u2019re not unique in their flaws. In any format, in any display, in any kind of page, weak content can rear its ugly, poorly written head.\n\nIt\u2019s not the Q&A that\u2019s to blame, it\u2019s bad content. Content without context will always fail users. That\u2019s the real witch in our midst.", "year": "2013", "author": "Lisa Maria Martin", "author_slug": "lisamariamartin", "published": "2013-12-08T00:00:00+00:00", "url": "https://24ways.org/2013/what-to-do-with-faqs/", "topic": "content"} {"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 \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 \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": 11, "title": "JavaScript: Taking Off the Training Wheels", "contents": "JavaScript is the third pillar of front-end web development. Of those pillars, it is both the most powerful and the most complex, so it\u2019s understandable that when 24 ways asked, \u201cWhat one thing do you wish you had more time to learn about?\u201d, a number of you answered \u201cJavaScript!\u201d\n\nThis article aims to help you feel happy writing JavaScript, and maybe even without libraries like jQuery. I can\u2019t comprehensively explain JavaScript itself without writing a book, but I hope this serves as a springboard from which you can jump to other great resources.\n\nWhy learn JavaScript?\n\nSo what\u2019s in it for you? Why take the next step and learn the fundamentals?\n\nConfidence with jQuery\n\nIf nothing else, learning JavaScript will improve your jQuery code; you\u2019ll be comfortable writing jQuery from scratch and feel happy bending others\u2019 code to your own purposes. Writing efficient, fast and bug-free jQuery is also made much easier when you have a good appreciation of JavaScript, because you can look at what jQuery is really doing. Understanding how JavaScript works lets you write better jQuery because you know what it\u2019s doing behind the scenes. When you need to leave the beaten track, you can do so with confidence.\n\nIn fact, you could say that jQuery\u2019s ultimate goal is not to exist: it was invented at a time when web APIs were very inconsistent and hard to work with. That\u2019s slowly changing as new APIs are introduced, and hopefully there will come a time when jQuery isn\u2019t needed.\n\nAn example of one such change is the introduction of the very useful document.querySelectorAll. Like jQuery, it converts a CSS selector into a list of matching elements. Here\u2019s a comparison of some jQuery code and the equivalent without.\n\n$('.counter').each(function (index) {\n $(this).text(index + 1);\n});\n\nvar counters = document.querySelectorAll('.counter');\n[].slice.call(counters).forEach(function (elem, index) {\n elem.textContent = index + 1;\n});\n\nSolving problems no one else has!\n\nWhen you have to go to the internet to solve a problem, you\u2019re forever stuck reusing code other people wrote to solve a slightly different problem to your own. Learning JavaScript will allow you to solve problems in your own way, and begin to do things nobody else ever has.\n\nNode.js\n\nNode.js is a non-browser environment for running JavaScript, and it can do just about anything! But if that sounds daunting, don\u2019t worry: the Node community is thriving, very friendly and willing to help.\n\nI think Node is incredibly exciting. It enables you, with one language, to build complete websites with complex and feature-filled front- and back-ends. Projects that let users log in or need a database are within your grasp, and Node has a great ecosystem of library authors to help you build incredible things. Exciting!\n\nHere\u2019s an example web server written with Node. http is a module that allows you to create servers and, like jQuery\u2019s $.ajax, make requests. It\u2019s a small amount of code to do something complex and, while working with Node is different from writing front-end code, it\u2019s certainly not out of your reach.\n\nvar http = require('http');\nhttp.createServer(function (req, res) {\n res.writeHead(200, {'Content-Type': 'text/plain'});\n res.end('Hello World');\n}).listen(1337);\nconsole.log('Server running at http://localhost:1337/');\n\nGrunt and other website tools\n\nNode has brought in something of a renaissance in tools that run in the command line, like Yeoman and Grunt. Both of these rely heavily on Node, and I\u2019ll talk a little bit about Grunt here.\n\nGrunt is a task runner, and many people use it for compiling Sass or compressing their site\u2019s JavaScript and images. It\u2019s pretty cool. You configure Grunt via the gruntfile.js, so JavaScript skills will come in handy, and since Grunt supports plug-ins built with JavaScript, knowing it unlocks the bucketloads of power Grunt has to offer.\n\nWays to improve your skills\n\nSo you know you want to learn JavaScript, but what are some good ways to learn and improve? I think the answer to that is different for different people, but here are some ideas.\n\nRebuild a jQuery app\n\nConverting a jQuery project to non-jQuery code is a great way to explore how you modify elements on the page and make requests to the server for data. My advice is to focus on making it work in one modern browser initially, and then go cross-browser if you\u2019re feeling adventurous. There are many resources for directly comparing jQuery and non-jQuery code, like Jeffrey Way\u2019s jQuery to JavaScript article.\n\nFind a mentor\n\nIf you think you\u2019d work better on a one-to-one basis then finding yourself a mentor could be a brilliant way to learn. The JavaScript community is very friendly and many people will be more than happy to give you their time. I\u2019d look out for someone who\u2019s active and friendly on Twitter, and does the kind of work you\u2019d like to do. Introduce yourself over Twitter or send them an email. I wouldn\u2019t expect a full tutoring course (although that is another option!) but they\u2019ll be very glad to answer a question and any follow-ups every now and then.\n\nGo to a workshop\n\nMany conferences and local meet-ups run workshops, hosted by experts in a particular field. See if there\u2019s one in your area. Workshops are great because you can ask direct questions, and you\u2019re in an environment where others are learning just like you are \u2014 no need to learn alone!\n\nSet yourself challenges\n\nThis is one way I like to learn new things. I have a new thing that I\u2019m not very good at, so I pick something that I think is just out of my reach and I try to build it. It\u2019s learning by doing and, even if you fail, it can be enormously valuable.\n\nWhere to start?\n\nIf you\u2019ve decided learning JavaScript is an important step for you, your next question may well be where to go from here.\n\nI\u2019ve collected some links to resources I know of or use, with some discussion about why you might want to check a particular site out. I hope this serves as a springboard for you to go out and learn as much as you want.\n\nBeginner\n\nIf you\u2019re just getting started with JavaScript, I\u2019d recommend heading to one of these places. They cover the basics and, in some cases, a little more advanced stuff. They\u2019re all reputable sources (although, I\u2019ve included something I wrote \u2014 you can decide about that one!) and will not lead you astray.\n\n\n\tjQuery\u2019s JavaScript 101 is a great first resource for JavaScript that will give you everything you need to work with jQuery like a pro.\n\tCodecademy\u2019s JavaScript Track is a small but useful JavaScript course. If you like learning interactively, this could be one for you.\n\tHTMLDog\u2019s JavaScript Tutorials take you right through from the basics of code to a brief introduction to newer technology like Node and Angular. [Disclaimer: I wrote this stuff, so it comes with a hazard warning!]\n\tThe tuts+ jQuery to JavaScript mentioned earlier is great for seeing how jQuery code looks when converted to pure JavaScript.\n\n\nGetting in-depth\n\nFor more comprehensive documentation and help I\u2019d recommend adding these places to your list of go-tos.\n\n\n\tMDN: the Mozilla Developer Network is the first place I go for many JavaScript questions. I mostly find myself there via a search, but it\u2019s a great place to just go and browse.\n\tAxel Rauschmayer\u2019s 2ality is a stunning collection of articles that will take you deep into JavaScript. It\u2019s certainly worth looking at.\n\tAddy Osmani\u2019s JavaScript Design Patterns is a comprehensive collection of patterns for writing high quality JavaScript, particularly as you (I hope) start to write bigger and more complex applications.\n\n\nAnd finally\u2026\n\nI think the key to learning anything is curiosity and perseverance. If you have a question, go out and search for the answer, even if you have no idea where to start. Keep going and going and eventually you\u2019ll get there. I bet you\u2019ll learn a whole lot along the way. Good luck!\n\nMany thanks to the people who gave me their time when I was working on this article: Tom Oakley, Jack Franklin, Ben Howdle and Laura Kalbag.", "year": "2013", "author": "Tom Ashworth", "author_slug": "tomashworth", "published": "2013-12-05T00:00:00+00:00", "url": "https://24ways.org/2013/javascript-taking-off-the-training-wheels/", "topic": "code"} {"rowid": 15, "title": "Git for Grown-ups", "contents": "You are a clever and talented person. You create beautiful designs, or perhaps you have architected a system that even my cat could use. Your peers adore you. Your clients love you. But, until now, you haven\u2019t *&^#^! been able to make Git work. It makes you angry inside that you have to ask your co-worker, again, for that *&^#^! command to upload your work.\n\nIt\u2019s not you. It\u2019s Git. Promise.\n\nYes, this is an article about the popular version control system, Git. But unlike just about every other article written about Git, I\u2019m not going to give you the top five commands that you need to memorize; and I\u2019m not going to tell you all your problems would be solved if only you were using this GUI wrapper or that particular workflow. You see, I\u2019ve come to a grand realization: when we teach Git, we\u2019re doing it wrong.\n\nLet me back up for a second and tell you a little bit about the field of adult education. (Bear with me, it gets good and will leave you feeling both empowered and righteous.) Andragogy, unlike pedagogy, is a learner-driven educational experience. There are six main tenets to adult education: \n\n\n\tAdults prefer to know why they are learning something.\n\tThe foundation of the learning activities should include experience.\n\tAdults prefer to be able to plan and evaluate their own instruction.\n\tAdults are more interested in learning things which directly impact their daily activities.\n\tAdults prefer learning to be oriented not towards content, but towards problems.\n\tAdults relate more to their own motivators than to external ones.\n\n\nNowhere in this list does it include \u201cmemorize the five most popular Git commands\u201d. And yet this is how we teach version control: init, add, commit, branch, push. You\u2019re an expert! Sound familiar? In the hierarchy of learning, memorizing commands is the lowest, or most basic, form of learning. At the peak of learning you are able to not just analyze and evaluate a problem space, but create your own understanding in relation to your existing body of knowledge.\n\n\u201cFine,\u201d I can hear you saying to yourself. \u201cBut I\u2019m here to learn about version control.\u201d Right you are! So how can we use this knowledge to master Git? First of all: I give you permission to use Git as a tool. A tool which you control and which you assign tasks to. A tool like a hammer, or a saw. Yes, your mastery of your tools will shape the kinds of interactions you have with your work, and your peers. But it\u2019s yours to control. Git was written by kernel developers for kernel development. The web world has adopted Git, but it is not a tool designed for us and by us. It\u2019s no Sass, y\u2019know? Git wasn\u2019t developed out of our frustration with managing CSS files in an increasingly complex ecosystem of components and atomic design. So, as you work through the next part of this article, give yourself a bit of a break. We\u2019re in this together, and it\u2019s going to be OK.\n\nWe\u2019re going to do a little activity. We\u2019re going to create your perfect Git cheatsheet.\n\nI want you to start by writing down a list of all the people on your code team. This list may include:\n\n\n\tdevelopers\n\tdesigners\n\tproject managers\n\tclients\n\n\nNext, I want you to write down a list of all the ways you interact with your team. Maybe you\u2019re a solo developer and you do all the tasks. Maybe you only do a few things. But I want you to write down a list of all the tasks you\u2019re actually responsible for. For example, my list looks like this:\n\n\n\twriting code\n\treviewing code\n\tpublishing tested code to your server(s)\n\ttroubleshooting broken code\n\n\nThe next list will end up being a series of boxes in a diagram. But to start, I want you to write down a list of your tools and constraints. This list potentially has a lot of noun-like items and verb-like items:\n\n\n\tcode hosting system (Bitbucket? GitHub? Unfuddle? self-hosted?)\n\tserver ecosystem (dev/staging/live)\n\tautomated testing systems or review gates\n\tautomated build systems (that Jenkins dude people keep referring to)\n\n\nBrilliant! Now you\u2019ve got your actors and your actions, it\u2019s time to shuffle them into a diagram. There are many popular workflow patterns. None are inherently right or wrong; rather, some are more or less appropriate for what you are trying to accomplish.\n\nCentralized workflow\n\nEveryone saves to a single place. This workflow may mean no version control, or a very rudimentary version control system which only ever has a single copy of the work available to the team at any point in time.\n\n \n\nBranching workflow\n\nEveryone works from a copy of the same place, merging their changes into the main copy as their work is completed. Think of the branches as a motorcycle sidecar: they\u2019re along for the ride and probably cannot exist in isolation of the main project for long without serious danger coming to the either the driver or sidecar passenger. Branches are a fundamental concept in version control \u2014 they allow you to work on new features, bug fixes, and experimental changes within a single repository, but without forcing the changes onto others working from the same branch.\n\n \n\nForking workflow\n\nEveryone works from their own, independent repository. A fork is an exact duplicate of a repository that a developer can make their own changes to. It can be kept up to date with additional changes made in other repositories, but it cannot force its changes onto another\u2019s repository. A fork is a complete repository which can use its own workflow strategies. If developers wish to merge their work with the main project, they must make a request of some kind (submit a patch, or a pull request) which the project collaborators may choose to adopt or reject. This workflow is popular for open source projects as it enforces a review process.\n\n \n\nGitflow workflow\n\nA specific workflow convention which includes five streams of parallel coding efforts: master, development, feature branches, release branches, and hot fixes. This workflow is often simplified down to a few elements by web teams, but may be used wholesale by software product teams. The original article describing this workflow was written by Vincent Driessen back in January 2010.\n\n \n\nBut these workflows aren\u2019t about you yet, are they? So let\u2019s make the connections.\n\nFrom the list of people on your team you identified earlier, draw a little circle. Give each of these circles some eyes and a smile. Now I want you to draw arrows between each of these people in the direction that code (ideally) flows. Does your designer create responsive prototypes which are pushed to the developer? Draw an arrow to represent this.\n\nChances are high that you don\u2019t just have people on your team, but you also have some kind of infrastructure. Hopefully you wrote about it earlier. For each of the servers and code repositories in your infrastructure, draw a square. Now, add to your diagram the relationships between the people and each of the machines in the infrastructure. Who can deploy code to the live server? How does it really get there? I bet it goes through some kind of code hosting system, such as GitHub. Draw in those arrows.\n\nBut wait!\n\nThe code that\u2019s on your development machine isn\u2019t the same as the live code. This is where we introduce the concept of a branch in version control. In Git, a repository contains all of the code (sort of). A branch is a fragment of the code that has been worked on in isolation to the other branches within a repository. Often branches will have elements in common. When we compare two (or more) branches, we are asking about the difference (or diff) between these two slivers. Often the master branch is used on production, and the development branch is used on our dev server. The difference between these two branches is the untested code that is not yet deployed.\n\nOn your diagram, see if you can colour-code according to the branch names at each of the locations within your infrastructure. You might find it useful to make a few different copies of the diagram to isolate each of the tasks you need to perform. For example: our team has a peer review process that each branch must go through before it is merged into the shared development branch.\n\nFinally, we are ready to add the Git commands necessary to make sense of the arrows in our diagram. If we are bringing code to our own workstation we will issue one of the following commands: clone (the first time we bring code to our workstation) or pull. Remembering that a repository contains all branches, we will issue the command checkout to switch from one branch to another within our own workstation. If we want to share a particular branch with one of our team mates, we will push this branch back to the place we retrieved it from (the origin). Along each of the arrows in your diagram, write the name of the command you are are going to use when you perform that particular task.\n\n \n\nFrom here, it\u2019s up to you to be selfish. Before asking Git what command it would like you to use, sketch the diagram of what you want. Git is your tool, you are not Git\u2019s tool. Draw the diagram. Communicate your tasks with your team as explicitly as you can. Insist on being a selfish adult learner \u2014 demand that others explain to you, in ways that are relevant to you, how to do the things you need to do today.", "year": "2013", "author": "Emma Jane Westby", "author_slug": "emmajanewestby", "published": "2013-12-04T00:00:00+00:00", "url": "https://24ways.org/2013/git-for-grownups/", "topic": "code"} {"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": 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": 20, "title": "Make Your Browser Dance", "contents": "It was a crisp winter\u2019s evening when I pulled up alongside the pier. I stepped out of my car and the bitterly cold sea air hit my face. I walked around to the boot, opened it and heaved out a heavy flight case. I slammed the boot shut, locked the car and started walking towards the venue.\n\nThis was it. My first gig. I thought about all those weeks of preparation: editing video clips, creating 3-D objects, making coloured patterns, then importing them all into software and configuring effects to change as the music did; targeting frequency, beat, velocity, modifying size, colour, starting point; creating playlists of these\u2026 and working out ways to mix them as the music played.\n\nThis was it. This was me VJing.\n\nThis was all a lifetime (well a decade!) ago.\n\nWhen I started web designing, VJing took a back seat. I was more interested in interactive layouts, semantic accessible HTML, learning all the IE bugs and mastering the quirks that CSS has to offer. More recently, I have been excited by background gradients, 3-D transforms, the @keyframe directive, as well as new APIs such as getUserMedia, indexedDB, the Web Audio API\n\nBut wait, have I just come full circle? Could it be possible, with these wonderful new things in technologies I am already familiar with, that I could VJ again, right here, in a browser?\n\nWell, there\u2019s only one thing to do: let\u2019s try it!\n\nLet\u2019s take to the dance floor \n\nOver the past couple of years working in The Lab I have learned to take a much more iterative approach to projects than before. One of my new favourite methods of working is to create a proof of concept to make sure my theory is feasible, before going on to create a full-blown product. So let\u2019s take the same approach here.\n\nThe main VJing functionality I want to recreate is manipulating visuals in relation to sound. So for my POC I need to create a visual, with parameters that can be changed, then get some sound and see if I can analyse that sound to detect some data, which I can then use to manipulate the visual parameters. Easy, right?\n\nSo, let\u2019s start at the beginning: creating a simple visual. For this I\u2019m going to create a CSS animation. It\u2019s just a funky i element with the opacity being changed to make it flash.\n\n See the Pen Creating a light by Rumyra (@Rumyra) on CodePen\n\nA note about prefixes: I\u2019ve left them out of the code examples in this post to make them easier to read. Please be aware that you may need them. I find a great resource to find out if you do is caniuse.com. You can also check out all the code for the examples in this article\n\nStart the music\n\nWell, that\u2019s pretty easy so far. Next up: loading in some sound. For this we\u2019ll use the Web Audio API. The Web Audio API is based around the concept of nodes. You have a source node: the sound you are loading in; a destination node: usually the device\u2019s speakers; and any number of processing nodes in between. All this processing that goes on with the audio is sandboxed within the AudioContext.\n\nSo, let\u2019s start by initialising our audio context.\n\nvar contextClass = window.AudioContext;\nif (contextClass) {\n //web audio api available.\n var audioContext = new contextClass();\n} else {\n //web audio api unavailable\n //warn user to upgrade/change browser\n}\n\nNow let\u2019s load our sound file into the new context we created with an XMLHttpRequest.\n\nfunction loadSound() {\n\t//set audio file url\n\tvar audioFileUrl = '/octave.ogg';\n\t//create new request\n\tvar request = new XMLHttpRequest();\n\trequest.open(\"GET\", audioFileUrl, true);\n\trequest.responseType = \"arraybuffer\";\n\n\trequest.onload = function() {\n\t\t//take from http request and decode into buffer\n\t\tcontext.decodeAudioData(request.response, function(buffer) {\n\t \taudioBuffer = buffer;\n\t });\n\t\t}\n\trequest.send();\n}\n\nPhew! Now we\u2019ve loaded in some sound! There are plenty of things we can do with the Web Audio API: increase volume; add filters; spatialisation. If you want to dig deeper, the O\u2019Reilly Web Audio API book by Boris Smus is available to read online free.\n\nAll we really want to do for this proof of concept, however, is analyse the sound data. To do this we really need to know what data we have.\n\n Learning the steps\n\nLet\u2019s take a minute to step back and remember our school days and science class. I\u2019m sure if I drew a picture of a sound wave, we would all start nodding our heads.\n\n \n\nThe sound you hear is caused by pressure differences in the particles in the air. Sound pushes these particles together, causing vibrations. Amplitude is basically strength of pressure. A simple example of change of amplitude is when you increase the volume on your stereo and the output wave increases in size.\n\nThis is great when everything is analogue, but the waveform varies continuously and it\u2019s not suitable for digital processing: there\u2019s an infinite set of values. For digital processing, we need discrete numbers.\n\nWe have to sample the waveform at set time intervals, and record data such as amplitude and frequency. Luckily for us, just the fact we have a digital sound file means all this hard work is done for us. What we\u2019re doing in the code above is piping that data in the audio context. All we need to do now is access it.\n\nWe can do this with the Web Audio API\u2019s analysing functionality. Just pop in an analysing node before we connect the source to its destination node.\n\nfunction createAnalyser(source) {\n\t//create analyser node\n\tanalyser = audioContext.createAnalyser();\n\t//connect to source\n\tsource.connect(analyzer);\n\t//pipe to speakers\n\tanalyser.connect(audioContext.destination);\n}\n\nThe data I\u2019m really interested in here is frequency. Later we could look into amplitude or time, but for now I\u2019m going to stick with frequency.\n\nThe analyser node gives us frequency data via the getFrequencyByteData method.\n\n Don\u2019t forget to count!\n\nTo collect the data from the getFrequencyByteData method, we need to pass in an empty array (a JavaScript typed array is ideal). But how do we know how many items the array will need when we create it?\n\nThis is really up to us and how high the resolution of frequencies we want to analyse is. Remember we talked about sampling the waveform; this happens at a certain rate (sample rate) which you can find out via the audio context\u2019s sampleRate attribute. This is good to bear in mind when you\u2019re thinking about your resolution of frequencies.\n\nvar sampleRate = audioContext.sampleRate;\n\nLet\u2019s say your file sample rate is 48,000, making the maximum frequency in the file 24,000Hz (thanks to a wonderful theorem from Dr Harry Nyquist, the maximum frequency in the file is always half the sample rate). The analyser array we\u2019re creating will contain frequencies up to this point. This is ideal as the human ear hears the range 0\u201320,000hz.\n\nSo, if we create an array which has 2,400 items, each frequency recorded will be 10Hz apart. However, we are going to create an array which is half the size of the FFT (fast Fourier transform), which in this case is 2,048 which is the default. You can set it via the fftSize property.\n\n//set our FFT size\nanalyzer.fftSize = 2048;\n//create an empty array with 1024 items\nvar frequencyData = new Uint8Array(1024);\n\nSo, with an array of 1,024 items, and a frequency range of 24,000Hz, we know each item is 24,000 \u00f7 1,024 = 23.44Hz apart.\n\nThe thing is, we also want that array to be updated constantly. We could use the setInterval or setTimeout methods for this; however, I prefer the new and shiny requestAnimationFrame.\n\nfunction update() {\n \t//constantly getting feedback from data\n \trequestAnimationFrame(update);\n \tanalyzer.getByteFrequencyData(frequencyData);\n}\n\n Putting it all together\n\nSweet sticks! Now we have an array of frequencies from the sound we loaded, updating as the sound plays. Now we want that data to trigger our animation from earlier.\n\nWe can easily pause and run our CSS animation from JavaScript:\n\nelement.style.webkitAnimationPlayState = \"paused\";\nelement.style.webkitAnimationPlayState = \"running\";\n\nUnfortunately, this may not be ideal as our animation might be a whole heap longer than just a flashing light. We may want to target specific points within that animation to have it stop and start in a visually pleasing way and perhaps not smack bang in the middle.\n\nThere is no really easy way to do this at the moment as Zach Saucier explains in this wonderful article. It takes some jiggery pokery with setInterval to try to ascertain how far through the CSS animation you are in percentage terms.\n\nThis seems a bit much for our proof of concept, so let\u2019s backtrack a little. We know by the animation we\u2019ve created which CSS properties we want to change. This is pretty easy to do directly with JavaScript.\n\nelement.style.opacity = \"1\";\nelement.style.opacity = \"0.2\";\n\nSo let\u2019s start putting it all together. For this example I want to trigger each light as a different frequency plays. For this, I\u2019ll loop through the HTML elements and change the opacity style if the frequency gain goes over a certain threshold.\n\n//get light elements\nvar lights = document.getElementsByTagName('i');\nvar totalLights = lights.length;\n\nfor (var i=0; iRecipe by {{ page.recipe-attribution }}.
\n\n\t