{"rowid": 39, "title": "Meet for Learning", "contents": "\u201cI\u2019ve never worked in a place like this,\u201d said one of my direct reports during our daily stand-up meeting.\n\nAnd with that statement, my mind raced to the most important thing about lawyering that I\u2019ve learned from decades of watching lawyers lawyer on TV: don\u2019t ask a question you don\u2019t know the answer to.\n\nBut I couldn\u2019t stop myself. I wanted to learn more. The thought developed in my mind. The words formed in my mouth. And the vocalization occurred: \u201cA place like this?\u201d\n\n\u201cI\u2019ve never worked where people are so honest and transparent about things.\u201d\n\nDesigning a learning-centered culture\n\nBefore we started Center Centre, Jared Spool and I discussed both the larger goals and the smaller details of this new UX design school. We talked about things like user experience, curriculum, and structure.\n\nWe discussed the pattern we saw in our research. Hiring managers told us time and again that great designers have excellent technical and interpersonal skills. But, more importantly, the best designers are lifelong learners\u2014they are willing and able to learn how to do new things. Learning this led us to ask a critical question: how would we intentionally design a learning-centered experience?\n\nTo craft the experience we were aiming for, we knew we had to create a learning-centered culture for our students and our employees. We knew that our staff would need to model the behaviors our students needed to learn. We knew the best way to shape the culture was to work with our direct reports\u2014our directs\u2014to develop the behaviors we wanted them to exemplify.\n\nTo craft the experience we were aiming for, we knew we had to create a learning-centered culture for our students and our employees. We knew that our staff would need to model the behaviors our students needed to learn.\n\nBuilding a learning team\n\nOur learning-centered culture starts with our staff. We believe in transparency. Transparency builds trust. Effective organizations have effective teams who trust each other as individuals.\n\nOne huge way we build that trust and provide opportunities for transparency is in our meetings. (I know, I know\u2014meetings! Yuck!) But seriously, running and participating in effective meetings is a great opportunity to build a learning-centered culture.\n\nMeetings\u2014when done well\u2014allow individuals time to come together, to share, and to listen. These behaviors, executed on a consistent and regular basis, build honest and trusting relationships.\n\nAn effective meeting is one that achieves the desired outcomes of that meeting. While different meetings aim for different results, at Center Centre all meetings have a secondary goal: meet for learning.\n\nA framework for learning-centered meetings\n\nWe\u2019ve developed a framework for our meetings. We use it for all our meetings, which means attendees know what to expect. It also saves us from reinventing the wheel in each meeting.\n\nThese basic steps help our meetings focus on the valuable face-to-face interaction we\u2019re having, and help us truly begin to learn from one another.\n\n An agenda for a staff meeting.\n\nUse effective meeting basics\n\n\n\tPrepare for the meeting before the meeting.\n\tIf you\u2019re running the meeting, prepare a typed agenda and share it before the meeting. Agendas have start times for each item.\n\tStart the meeting on time. Don\u2019t wait for stragglers.\n\tDefine ground rules. Get input from attendees. Recurring meetings don\u2019t have to do this every time.\n\tKeep to the meeting agenda. Put off-topic questions and ideas in a parking lot, a visual document that everyone can see, so you can address the questions and ideas later.\n\tFinish on time. And if you\u2019ve reached the meeting\u2019s goals, finish early.\n\n\n Parking lots where ideas on sticky notes can be posted for later consideration.\n\nFocus to learn\n\n\n\tHave tech-free meetings: no laptops, no phones, no things with notifications.\n\tBring a notebook and a pen.\n\tTake notes by hand. You\u2019re not taking minutes, you\u2019re writing to learn.\n\n\nCome with a learning mindset\n\n\n\tAsk: what are our goals for this meeting? (Hopefully answered by the meeting agenda.)\n\tAsk: what can I learn overall?\n\tAsk: what can I learn from each of my colleagues?\n\tAsk: what can I share that will help the team learn overall?\n\tAsk: what can I share that will help each of my colleagues learn?\n\n\nInvesting in regularly scheduled learning-centered meetings\n\nAt Center Centre, we have two types of recurring all-staff meetings: daily stand-ups and weekly staff meetings. (We are a small organization, so it makes sense to meet as an entire group.)\n\nYes, that means we spend thirty minutes each day in stand-up, for a total of two and a half hours of stand-up meeting time each week. And, yes, we also have a weekly ninety-minute sit-down staff meeting on top of that. This investment in time is an investment in learning.\n\nWe use these meetings to build our transparency, and, therefore, our trust. The regularity of these meetings helps us maintain ongoing, open sharing about our responsibilities, our successes, and our learning.\n\nFor instance, we answer five questions in our stand-up:\n\n\n\tWhat did I get done since the last stand-up (I reported at)?\n\tWhat is my goal to accomplish before the next stand-up?\n\tWhat\u2019s preventing me from getting these things done, if anything?\n\tWhat\u2019s the highest risk or most unknown thing right now about what I\u2019m trying to get done?\n\tWhat is the most important thing I learned since the last time we met and how will what I learned change the way I approach things in the future?\n\n\nEach person writes out their answers to these questions before the meeting. Each person brings their answers printed on paper to the meeting. And each person brings a pen to jot down notes.\n\n Notes compiled for a stand-up meeting.\n\nDuring the stand-up, each person shares their answers to the five questions. To sustain a learning-centered culture, the fifth question is the most important question to answer. It allows individual reflection focused on learning. Sometimes this isn\u2019t an easy question to answer. It makes us stretch. It makes us think.\n\nBy sharing our individual answers to the fifth question, we open ourselves up to the group. When we honestly share what we\u2019ve learned, we openly admit that we didn\u2019t know something. Sharing like this would be scary (and even risky) if we didn\u2019t have a learning-centered culture.\n\nWe often share the actual process of how we learned something. By listening, each of us is invited to learn more about the topic at hand, consider what more there is to learn about that topic, and even gain insights into other methods of learning\u2014which can be applied to other topics.\n\nSharing the answers to the fifth question also allows opportunities for further conversations. We often take what someone has individually learned and find ways to apply it for our entire team in support of our organization. We are, after all, learning together.\n\nBuilding individual learners\n\nWe strive to grow together as a team at Center Centre, but we don\u2019t lose sight of the importance of the individuals who form our team. As individuals, we bring our goals, dreams, abilities, and prior knowledge to the team.\n\nTo build learning teams, we must build individual learners. A team made up of lifelong learners, who share their learning and learn from each other, is a team that will continually produce better results.\n\nAs a manager, I need to meet each direct where they are with their current abilities and knowledge. Then, I can help them take their skills and knowledge base to the next levels. This process requires each individual direct to engage in professional development.\n\nWe believe effective managers help their directs engage in behaviors that support growth and development. Effective managers encourage and support learning.\n\n\n\nOur weekly one-on-ones\n\nOne way we encourage learning is through weekly one-on-ones. Each of my directs meets with me, individually, for thirty minutes each week. The meeting is their meeting. It is not my meeting.\n\nMy direct sets the agenda. They talk about what they want to talk about. They can talk about work. They can talk about things outside of work. They can talk about their health, their kids, and even their cat. Whatever is important to them is important to me. I listen. I take notes.\n\nAlthough the direct sets the specific agenda, the meeting has three main parts. Approximately ten minutes for them (the direct), ten minutes for me (the manager), and ten minutes for us to talk about their future within\u2014and beyond\u2014our organization.\n\nCoaching for future performance\n\nThe final third of our one-on-one is when I coach my directs. Coaching looks to the direct\u2019s future performance. It focuses on developing the direct\u2019s skills.\n\nCoaching isn\u2019t hard. It doesn\u2019t take much time. For me, it usually takes less than five minutes a week during a one-on-one.\n\nThe first time I coach one of my directs, I ask them to brainstorm about the skills they want to improve. They usually already have an idea about this. It\u2019s often something they\u2019ve wanted to work on for some time, but didn\u2019t think they had the time or the knowhow to improve.\n\nIf a direct doesn\u2019t know what they want to improve, we discuss their job responsibilities\u2014specifically the aspects of the job that concern them.\n\nCoaching provides an opportunity for me to ask, \u201cIn your job, what are the required skills that you feel like you don\u2019t have (or know well enough, or perform effectively, or use with ease)?\u201d\n\nSometimes I have to remind a direct that it\u2019s okay not to know how to do something (even if it\u2019s a required part of their job). After all, our organization is a learning organization. In a learning organization, no one knows everything but everyone is willing to learn anything.\n\nAfter we review the job responsibilities together, I ask my direct what skill they\u2019d like to work to improve. Whatever they choose, we focus on that skill for coaching\u2014I\u2019ve found my directs work better when they\u2019re internally motivated.\n\nSometimes the first time I talk with a direct about coaching, they get a bit anxious. If this happens, I share a personal story about my professional learning journey. I say something like:\n\n\n\tI didn\u2019t know how to make a school before we started to make Center Centre.\n\n\tI didn\u2019t know how to manage an entire team of people\u2014day in and day out\u2014until I started managing a team of people every day.\n\n\tWhen I realized that I was the boss\u2014and that the success of the school would hinge, at least in part, on my skills as a manager\u2014I was a bit terrified. I was missing an important skill set that I needed to know (and I needed to know well).\n\n\tWhen I first understood this, I felt bad\u2014like I should have already known how to be a great manager. But then I realized, I\u2019d never faced this situation. I\u2019d never needed to know how to use this skill set in this way.\n\n\tI worked through my anxiety about feeling inadequate. I decided I\u2019d better learn how to be an effective manager because the school needed me to be one. You needed me to be one.\n\n\tEvery day, I work to improve my management skills. You\u2019ve probably noticed that some days I\u2019m better at it than others. I try not to beat myself up about this, although it\u2019s hard\u2014I\u2019d like to be perfect at it. But I\u2019m not.\n\n\tI know that if I make a conscious, daily effort to learn how to be a better manager, I\u2019ll continue to improve. So that\u2019s what I do.\n\n\tEvery day I learn. I learn by doing. I learn how to be better than I was the day before. That\u2019s what I ask of you.\n\n\nOnce we determine the skill the direct wants to learn, we figure out how they can go about learning it. I ask: \u201cHow could you learn this skill?\u201d\n\nWe brainstorm for two or three minutes about this. We write down every idea that comes to mind, and we write it so both of us can easily see the options (both whiteboards and sticky notes on the wall work well for this exercise).\n\n\n\tRead a book. Research online. Watch a virtual seminar. Listen to a podcast. Talk to a mentor. Reach out to an expert. Attend a conference. Shadow someone else while they do the skill. Join a professional organization.\n\n\nThe goal is to get the direct on a path of self-development. I\u2019m coaching their development, but I\u2019m not the main way my direct will learn this new skill.\n\nI ask my direct which path seems like the best place to start. I let them choose whatever option they want (as long as it works with our budget). They are more likely to follow through if they are in control of this process.\n\nNext, we work to break down the selected path into tasks. We only plan one week\u2019s worth of tasks. The tasks are small, and the deadlines are short. My direct reports when each task is completed.\n\nAt our next one-on-one, I ask my direct about their experience learning this new skill.\n\nRinse. Repeat.\n\nThat\u2019s it. I spend five minutes a week talking with each direct about their individual learning. They develop their professional skills, and together we\u2019re creating a learning-centered culture.\n\nAsking questions I don\u2019t know the answer to\n\nWhen my direct said, \u201cI\u2019ve never worked where people are so honest and transparent about things,\u201d it led me to believe that all this is working. We are building a learning-centered culture.\n\nThis week I was reminded that creating a learning-centered culture starts not just with the staff, but with me. When I challenge myself to learn and then share what I\u2019m currently learning, my directs want to learn more about what I\u2019m learning about.\n\nFor example, I decided I needed to improve my writing skills. A few weeks ago, I realized that I was sorely out of practice and I felt like I had lost my voice. So I started to write. I put words on paper. I felt overwhelmed. I felt like I didn\u2019t know how to write anymore (at least not well or effectively).\n\nI bought some books on writing (mostly Peter Elbow\u2019s books like Writing with Power, Writing Without Teachers, and Vernacular Eloquence), and I read them. I read them all. Reading these books was part of my personal coaching. I used the same steps to coach myself as I use with my directs when I coach them.\n\nIn stand-ups, I started sharing what I accomplished (like I completed one of the books) and what I learned by doing\u2014specific things, like engaging in freewriting and an open-ended writing process.\n\nThis week, I went to lunch with one of my directs. She said, \u201cYou\u2019ve been talking about freewriting a lot. You\u2019re really excited about it. Freewriting seems like it\u2019s helping your writing process. Would you tell me more about it?\u201d\n\nSo I shared the details with her. I shared the reasons why I think freewriting is helping. I\u2019m not focused on perfection. Instead, each day I\u2019m focused on spending ten, uninterrupted minutes writing down whatever comes to my mind. It\u2019s opening my writing mind. It\u2019s allowing my words to flow more freely. And it\u2019s helping me feel less self-conscious about my writing.\n\nShe said, \u201cLeslie, when you say you\u2019re self-conscious about your writing, I laugh. Not because it\u2019s funny. But because when I read what you write, I think, \u2018What is there to improve?\u2019 I think you\u2019re a great writer. It\u2019s interesting to know that you think you can be a better writer. I like learning about your learning process. I think I could do freewriting. I\u2019m going to give it a try.\u201d\n\nThere\u2019s something magical about all of this. I\u2019m not even sure I can eloquently put it into words. I just know that our working environment is something very different. I\u2019ve never experienced anything quite like it. Somehow, by sharing that I don\u2019t know everything and that I\u2019m always working to learn more, I invite my directs to be really open about what they don\u2019t know. And they see it\u2019s possible always to learn and grow.\n\nI\u2019m glad I ignore all the lawyering I\u2019ve learned from watching TV. I\u2019m glad I ask the questions I don\u2019t know the answers to. And I\u2019m glad my directs do the same. When we meet for learning, we accelerate and amplify the learning process\u2014building individual learners and learning teams. Embracing the unknown and working toward understanding is what makes our culture a learning-centered culture.\n\nPhotos by Summer Kohlhorst.", "year": "2014", "author": "Leslie Jensen-Inman", "author_slug": "lesliejenseninman", "published": "2014-12-20T00:00:00+00:00", "url": "https://24ways.org/2014/meet-for-learning/", "topic": "process"} {"rowid": 30, "title": "Making Sites More Responsive, Responsibly", "contents": "With digital projects we\u2019re used to shifting our thinking to align with our target audience. We may undertake research, create personas, identify key tasks, or observe usage patterns, with our findings helping to refine our ongoing creations.\u00a0A product\u2019s overall experience can make or break its success, and when it comes to defining these experiences our development choices play a huge role alongside more traditional user-focused activities.\n\nThe popularisation of responsive web design is a great example of how we are able to shape the web\u2019s direction through using technology to provide better experiences. If we think back to the move from table-based layouts to CSS, initially our clients often didn\u2019t know or care about the difference in these approaches, but\u00a0we\u00a0did. Responsive design was similar in this respect \u2013 momentum grew through the web industry choosing to use an approach that we felt would give a better experience, and which was more future-friendly.\u00a0\n\nWe tend to think of responsive design as a means of displaying content appropriately across a range of devices, but the technology and our implementation of it can facilitate much more. A responsive layout not only helps your content work when the newest smartphone comes out, but it also ensures your layout suitably adapts if a visually impaired user drastically changes the size of the text.\n\n The 24 ways site at 400% on a Retina MacBook Pro displays a layout more typically used for small screens.\n\nWhen we think more broadly, we realise that our technical choices and approaches to implementation can have knock-on effects for the greater good, and beyond our initial target audiences. We can make our experiences more\u00a0responsive to people\u2019s needs, enhancing their usability and accessibility along the way.\n\nBeing responsibly responsive\n\nOf course, when we think about being more responsive, there\u2019s a fine line between creating useful functionality and becoming intrusive and overly complex. In the excellent Responsible Responsive Design, Scott Jehl states that:\n\n\nA responsible responsive design equally considers the following throughout a project:\n\nUsability: The way a website\u2019s user interface is presented to the user, and how that UI responds to browsing conditions and user interactions.\nAccess: The ability for users of all devices, browsers, and assistive technologies to access and understand a site\u2019s features and content.\nSustainability: The ability for the technology driving a site or application to work for devices that exist today and to continue to be usable and accessible to users, devices, and browsers in the future.\nPerformance: The speed at which a site\u2019s features and content are perceived to be delivered to the user and the efficiency with which they operate within the user interface.\n\n\n\nScott\u2019s book covers these ideas in a lot more detail than I\u2019ll be able to here (put it on your Christmas list if it\u2019s not there already), but for now let\u2019s think a bit more about our roles as digital creators\u00a0and the power this gives us.\n\nOur choices around technology and the decisions we have to make can be extremely wide-ranging. Solutions will vary hugely depending on the needs of each project, though we can further explore the concept of making our creations more responsive through the use of humble web technologies.\n\nThe power of the web\n\nWe all know that under the HTML5 umbrella are some great new capabilities, including a number of JavaScript APIs such as geolocation, web audio, the file API and many more. We often use these to enhance the functionality of our sites and apps, to add in new features, or to facilitate device-specific interactions.\n\nYou\u2019ll have seen articles with flashy titles such as \u201cTop 5 JavaScript APIs You\u2019ve Never Heard Of!\u201d, which you\u2019ll probably read, think \u201cThat\u2019s quite cool\u201d, yet never use in any real work.\n\nThere is great potential for technologies like these\u00a0to be misused, but there are also great prospects for them to be used well to enhance experiences. Let\u2019s have a look at a few\u00a0examples you may not have considered.\n\nOffline first\n\nWhen we make websites, many of us follow a process which involves user stories \u2013 standardised snippets of context explaining who needs what, and why.\n\n\u201cAs a student I want to pay online for my course so I don\u2019t have to visit the college in person.\u201d\n\n\u201cAs a retailer I want to generate unique product codes so I can manage my stock.\u201d\n\nWe very often focus heavily on what\u00a0needs doing, but may not consider carefully how it will be done. As in Scott\u2019s list, accessibility is extremely important, not only in terms of providing a great experience to users of assistive technologies, but also to make your creation more accessible in the general sense \u2013 including under different conditions.\n\nOffline first is yet another \u2018first\u2019 methodology (my personal favourite being \u2018tea first\u2019), which encourages us to develop so that connectivity\u00a0itself is an enhancement \u2013 letting\u00a0users continue with tasks even when they\u2019re offline. Despite the rapid growth in public Wi-Fi, if we consider data costs and connectivity in developing countries, our travel habits with planes, underground trains and roaming (or simply if you live in the UK\u2019s signal-barren East Anglian wilderness as I do), then you\u2019ll realise that connectivity isn\u2019t as ubiquitous as our internet-addled brains would make us believe. Take a scenario that I\u2019m sure we\u2019re all familiar with \u2013 the digital conference. Your venue may be in a city served by high-speed networks, but after overloading capacity with a full house of hashtag-hungry attendees, each carrying several devices, then everyone\u2019s likely to be offline after all. Wouldn\u2019t it be better if we could do something like this instead?\n\n\n\tSomeone visits our conference website.\n\tOn this initial run, some assets may be cached for future use: the conference schedule, the site\u2019s CSS, photos of the speakers.\n\tWhen the attendee revisits the site on the day, the page shell loads up from the cache.\n\tIf we have cached content (our session timetable, speaker photos or anything else), we can load it directly from the cache. We might then try to update this, or get some new content from the internet, but the conference attendee already has a base experience to use.\n\tIf we don\u2019t have something cached already, then we can try\u00a0grabbing it online.\n\tIf for any reason our requests for new content fail (we\u2019re offline), then we can display a pre-cached error message from the initial load, perhaps providing our users with alternative suggestions from what is\u00a0cached.\n\n\nThere are a number of ways we can make something like this, including using the application cache (AppCache) if you\u2019re that way inclined. However, you may want to look into service workers\u00a0instead. There are also some great resources on Offline First!\u00a0if you\u2019d like to find out more about this.\n\nBuilding in offline functionality isn\u2019t necessarily about starting offline first, and it\u2019s also perfectly possible to retrofit sites and apps to catch offline scenarios, but this kind of graceful degradation can end up being more complex than if we\u2019d considered it from the start. By treating connectivity as an enhancement, we can improve the experience and provide better performance than we can when waiting to counter failures. Our websites can respond to connectivity and usage scenarios, on top of adapting how we present our content. Thinking in this way can enhance each point in Scott\u2019s criteria.\n\nAs I mentioned, this isn\u2019t necessarily the kind of development choice that our clients will ask us for, but it\u2019s one we may decide is simply the right way to build based on our project, enhancing the experience we provide to people, and making it more responsive to their situation.\n\nEven more accessible\n\nWe\u2019ve looked at accessibility in terms of broadening when we can interact with a website, but what about how? Our user stories and personas are often of limited use. We refer in very general terms to students, retailers, and sometimes just users. What if we have a student whose needs are very different from another student? Can we make our sites even more usable and accessible through our development choices?\n\nAgain using JavaScript to illustrate this concept, we can do a lot more with the ways people interact with our websites, and with the feedback we provide, than simply accepting keyboard, mouse and touch inputs and displaying output on a screen.\n\nInput\n\nAmbient light detection is one of those features that looks great in simple demos, but which we struggle to put to practical use. It\u2019s not new \u2013 many satnav systems automatically change the contrast for driving at night or in tunnels, and our laptops may alter the screen brightness or keyboard backlighting to better adapt to our surroundings. Using web technologies we can adapt our presentation to be better suited to ambient light levels.\n\nIf our device has an appropriate light sensor and runs a browser that supports the API, we can grab the ambient light in units using ambient light events, in JavaScript. We may then change our presentation based on different bandings, perhaps like this:\n\nwindow.addEventListener('devicelight', function(e) {\n var lux = e.value;\n\n if (lux < 50) {\n //Change things for dim light\n }\n if (lux >= 50 && lux <= 10000) {\n //Change things for normal light\n }\n if (lux > 10000) {\n //Change things for bright light\n }\n});\n\nLive demo\u00a0(requires light sensor and supported browser).\n\nSoon we may also be able to do such detection through CSS, with light-level being cited in the Media Queries Level 4 specification. If that becomes the case, it\u2019ll probably look something like this:\n\n@media (light-level: dim) {\n /*Change things for dim light*/\n}\n\n@media (light-level: normal) {\n /*Change things for normal light*/\n}\n\n@media (light-level: washed) {\n /*Change things for bright light*/\n}\n\nWhile we may be quick to dismiss this kind of detection as being a gimmick, it\u2019s important to consider that apps such as Light Detector, listed on Apple\u2019s accessibility page, provide important context around exactly this functionality.\n\n\n\t\u201cIf you are blind, Light Detector helps you to be more independent in many daily activities. At home, point your iPhone towards the ceiling to understand where the light fixtures are and whether they are switched on. In a room, move the device along the wall to check if there is a window and where it is. You can find out whether the shades are drawn by moving the device up and down.\u201d\n\n\teverywaretechnologies.com/apps/lightdetector\n\n\nInput can be about so much more than what we enter through keyboards. Both an ever increasing amount of available sensors and more APIs being supported by the major browsers will allow us to cater for more scenarios and respond to them accordingly. This can be as complex or simple as you need; for instance, while x-webkit-speech has been deprecated, the web speech API is available for a number of browsers, and research into sign language detection is also being performed by organisations such as Microsoft.\n\nOutput\n\nWeb technologies give us some great enhancements around input, allowing us to adapt our experiences accordingly. They also provide us with some nice ways to provide feedback to users.\n\nWhen we play video games, many of our modern consoles come with the ability to have rumble effects on our controller pads. These are a great example of an enhancement, as they provide a level of feedback that is entirely optional, but which can give a great deal of extra information to the player in the right circumstances, and broaden the scope of our comprehension beyond what we\u2019re seeing and hearing.\n\nHaptic feedback is possible on the web as well. We could use this in any number of responsible applications, such as alerting a user to changes or using different patterns as a communication mechanism. If you find yourself in a pickle, here\u2019s how to print out SOS in Morse code through the vibration API. The following code indicates the length of vibration in milliseconds, interspersed by pauses in milliseconds.\n\nnavigator.vibrate([100, 300, 100, 300, 100, 300, 600, 300, 600, 300, 600, 300, 100, 300, 100, 300, 100]);\n\nLive demo\u00a0(requires supported browser)\n\nWith great power\u2026\n\nWhat you\u2019ve no doubt come to realise by now is that these are just more examples of progressive enhancement, whose inclusion will provide a better experience if the capabilities are available, but which we should not rely on. This idea isn\u2019t new, but the most important thing to remember, and what I would like you to take away from this article, is that it is up to us to decide to include these kind of approaches within our projects \u2013 if we don\u2019t root for them, they probably won\u2019t happen. This is where our professional responsibility comes in.\n\nWe won\u2019t necessarily be asked to implement solutions for the scenarios above, but they illustrate how we can help to push the boundaries of experiences. Maybe we\u2019ll have to switch our thinking about how we build, but we can create more usable products for a diverse range of people and usage scenarios through the choices we make around technology. Let\u2019s stop thinking simply in terms of features inside a narrow view of our target users, and work out how we can extend these to cater for a wider set of situations.\n\nWhen you plan your next digital project, consider the power of the web and the enhancements we can use, and try to make your projects even more responsive and responsible.", "year": "2014", "author": "Sally Jenkinson", "author_slug": "sallyjenkinson", "published": "2014-12-10T00:00:00+00:00", "url": "https://24ways.org/2014/making-sites-more-responsive-responsibly/", "topic": "code"} {"rowid": 32, "title": "Cohesive UX", "contents": "With Yosemite, Apple users can answer iPhone calls on their MacBooks. This is weird. And yet it\u2019s representative of a greater trend toward cohesion.\n\nShortly after upgrading to Yosemite, a call came in on my iPhone and my MacBook \u201crang\u201d in parallel. And I was all, like, \u201cWut?\u201d This was a new feature in Yosemite, and honestly it was a little bizarre at first.\n\n Apple promotional image showing a phone call ringing simultaneously on multiple devices.\n\nHowever, I had just spoken at a conference on the very topic you\u2019re reading about now, and therefore I appreciated the underlying concept: the cohesion of user experience, the cohesion of screens.\n\nThis is just one of many examples I\u2019ve encountered since beginning to speak about this topic months ago. But before we get ahead of ourselves, let\u2019s look back at the past few years, specifically the role of responsive web design.\n\nRWD != cohesive experience\n\nI needn\u2019t expound on the virtues of responsive web design (RWD). You\u2019ve likely already encountered more than a career\u2019s worth on the topic. This is a good thing. Count me in as one of its biggest fans.\n\nHowever, if we are to sing the praises of RWD, we must also acknowledge its shortcomings. One of these is that RWD ends where the browser ends. For all its goodness, RWD really has no bearing on native apps or any other experiences that take place outside the browser. This makes it challenging, therefore, to create cohesion for multi-screen users if RWD is the only response to \u201clet\u2019s make it work everywhere.\u201d\n\nWe need something that incorporates the spirit of RWD while unifying all touchpoints for the entire user experience\u2014single device or several devices, in browser or sans browser, native app or otherwise.\n\nI call this cohesive UX, and I believe it\u2019s the next era of successful user experiences.\n\nToward a unified whole\n\nSimply put, the goal of cohesive UX is to deliver a consistent, unified user experience regardless of where the experience begins, continues, and ends.\n\nTwo facets are vital to cohesive UX:\n\n\n\tFunction and form\n\tData symmetry\n\n\nLet\u2019s examine each of these.\n\nFunction AND form\n\nFunction over form, of course. Right? Not so fast, kiddo.\n\nConsider Bruce Lawson\u2019s dad. After receiving an Android phone for Christmas and thumbing through his favorite sites, he was puzzled why some looked different from their counterparts on the desktop. \u201cWhen a site looked radically different,\u201d Bruce observed, \u201che\u2019d check the URL bar to ensure that he\u2019d typed in the right address. In short, he found RWD to be confusing and it meant he didn\u2019t trust the site.\u201d A lack of cohesive form led to a jarring experience for Bruce\u2019s dad.\n\nNow, if I appear to be suggesting websites must look the same in every browser\u2014you already learned they needn\u2019t\u2014know that I recognize the importance of context, especially in regards to mobile. I made a case for this more than seven years ago.\n\nRather, cohesive UX suggests that form deserves the same respect as function when crafting user experiences that span multiple screens or devices. And users are increasingly comfortable traversing media. For example, more than 40% of adults in the U.S. owning more than one device start an activity on one screen and finish it on another, according to a study commissioned by Facebook. I suspect that percentage will only increase in 2015, and I suspect the tech-affluent readers of 24 ways are among the 40%.\n\nThere are countless examples of cohesive form and function. Consider Gmail, which displays email conversations visually as a stack that can be expanded and collapsed like the bellows of an accordion. This visual metaphor has been consistent in virtually any instance of Gmail\u2014website or app\u2014since at least 2007 when I captured this screenshot on my Nokia 6680:\n\n Screenshot captured while authoring Mobile Web Design (2007). Back then we didn\u2019t call this an app, but rather a \u2018smart client\u2019.\n\nWhen the holistic experience is cohesive as it is with Gmail, users\u2019 mental models and even muscle memory are preserved.1 Functionality and aesthetics align with the expectations users have for how things should function and what they should look like. In other words, the experience is roughly the same across screens.\n\nBut don\u2019t be ridiculous, peoples. Note that I said \u201croughly.\u201d It\u2019s important to avoid mindless replication of aesthetics and functionality for the sake of cohesion. Again, the goal is a unified whole, not a carbon copy. Affordances and concessions should be made as context and intuition require. For example, while Facebook users are accustomed to top-aligned navigation in the browser, they encounter bottom-aligned navigation in the iOS app as justified by user testing:\n\nThe iOS app model has held up despite many attempts to better it: http://t.co/rSMSAqeh9m pic.twitter.com/mBp36lAEgc\u2014 Luke Wroblewski (@lukew) December 10, 2014\n\n\nDespite the (rather minor) lack of consistency in navigation placement, other elements such as icons, labels, and color theme work in tandem to produce a unified, holistic whole.\n\nData symmetry\n\nData symmetry involves the repetition, continuity, or synchronicity of data across screens, devices, and platforms. As regards cohesive UX, data includes not just the material (such as an article you\u2019re writing on Medium) but also the actions that can be performed on or with that material (such as Medium\u2019s authoring tools). That is to say, \u201csync verbs, not just nouns\u201d (Josh Clark).\n\nIn my estimation, Amazon is an archetype of data symmetry, as is Rdio. When logged in, data is shared across virtually any device of any kind, irrespective of using a browser or native app. Add a product to your Amazon cart from your phone during the morning commute, and finish the transaction at work on your laptop. Easy peasy.\n\nAmazon\u2019s aesthetics are crazy cohesive, to boot:\n\n Amazon web (left) and native app (right).\n\nWith Rdio, not only are playlists and listening history synced across screens as you would expect, but the cohesion goes even further. Rdio\u2019s remote control feature allows you to control music playing on one device using another device, all in real time.\n\n Rdio\u2019s remote control feature, as viewed on my MacBook while music plays on my iMac.\n\nAt my office I often work from my couch using my MacBook, but my speakers are connected to my iMac. When signed in to Rdio on both devices, my MacBook serves as proxy for controlling Rdio on my iMac, much the same as any Yosemite-enabled device can serve as proxy for an incoming iPhone call.\n\n Me, in my office. Note the iMac and speakers at far right.\n\nThis is a brilliant example of cohesive design, and it\u2019s executed entirely via the cloud.\n\nThings to consider\n\nConsider the following when crafting cohesive experiences:\n\n\n\tInventory the elements that comprise your product experience, and cohesify them.2\nConsider things such as copy, tone, typography, iconography, imagery, flow, placement, brand identification, account data, session data, user preferences, and so on. Then, create cohesion among these elements to the greatest extent possible, while adapting to context as needed.\n\tStore session data in the cloud rather than locally.\nFor example, avoid using browser cookies to store shopping cart data, as cookies are specific to a single browser on a single device. Instead, store this data in the cloud so it can be accessed from other devices, as well as beyond the browser.\n\tConsider using web views when developing your native app.\n\u201cYou\u2019re already using web apps in native wrappers without even noticing it,\u201d Lukas Mathis contends. \u201cThe fact that nobody even notices, the fact that this isn\u2019t a story, shows that, when it comes to user experience, web vs. native doesn\u2019t matter anymore.\u201d Web views essentially allow you to display HTML content inside a native wrapper. This can reduce the time and effort needed to make the overall experience cohesive. So whereas the navigation bar may be rendered by the app, for example, the remaining page display may be rendered via the web. There\u2019s readily accessible documentation for using web views in C++, iOS, Android, and so forth.\n\n\nNature is calling\n\nReturning to the example of Yosemite and sychronized phone calls, is it really that bizarre in light of cohesive UX? Perhaps at first. But I suspect that, over time, Yosemite\u2019s cohesiveness \u2014 and the cohesiveness of other examples like the ones we\u2019ve discussed here \u2014 will become not only more natural but more commonplace, too.\n\n\n\n1 I browse Flipboard on my iPad nearly every morning as part of my breakfast routine. Swiping horizontally advances to the next page. Countless times I\u2019ve done the same gesture in Flipboard for iPhone only to have it do nothing. This is because the gesture for advancing is vertical on phones. I\u2019m so conditioned to the horizontal swipe that I often fail to make the switch to vertical swipe, and apparently others suffer from the same muscle memory, too.\n\n2 Cohesify isn\u2019t a thing. But chances are you understood what I meant. Yay neologism!", "year": "2014", "author": "Cameron Moll", "author_slug": "cameronmoll", "published": "2014-12-24T00:00:00+00:00", "url": "https://24ways.org/2014/cohesive-ux/", "topic": "ux"} {"rowid": 43, "title": "Content Production Planning", "contents": "While everyone agrees that getting the content of a website right is vital to its success, unless you\u2019re lucky enough to have an experienced editor or content strategist on board, planning content production often seems to fall through the cracks. One reason is that, for most of the team, it feels like someone else\u2019s problem. Not necessarily a specific person\u2019s problem. Just someone else\u2019s. It\u2019s only when everyone starts urgently asking when the content is going to be ready, that it becomes clear the answer is, \u201cNot as soon as we\u2019d like it\u201d.\n\nThe good news is that there are some quick and simple things you can do, even if you\u2019re not the official content person on a project, to get everyone on the same content planning page. \n\nContent production planning boils down to answering three deceptively simple questions:\n\n\n\tWhat content do you need?\n\tHow much of it do you need?\n\tWho\u2019s going to make it?\n\n\nEven if it\u2019s not your job to come up with the answers, by asking these questions early enough and agreeing who is going to come up with the answers, you\u2019ll be a long way towards avoiding the last-minute content problems which so often plague projects.\n\nHow much content do we need?\n\nPeople tend to underestimate two crucial things about content: how much content they need, and how long that content takes to produce.\n\nWhen I ask someone how big their website is \u2013 how many pages it contains \u2013 I usually double or triple the answer I get. That\u2019s because almost everyone\u2019s mental model of their website greatly underestimates its true size. You can see the problem for yourself if you look at a site map. Site maps are great at representing a mental model of a website. But because they\u2019re a deliberate simplification they naturally lead us to underestimate how much content is involved in populating them.\n\nSeveral years ago I was asked to help a client create a new microsite (their word) which they wanted ready in two weeks for a conference they were attending. Here\u2019s the site map they had in mind. At first glance it looks like a pretty small website. Maybe twenty to thirty pages?\n\n\n\nThat\u2019s what the client thought.\n\nBut see those boxes which are multiple boxes stacked on top of one another, for product categories, descriptions and supporting material? They\u2019re known as page stacks, and page stacks are the content strategy equivalent of Here Be Dragons. \n\n\n\nSay we have:\n\n\n\tfive product categories\n\teach with five products\n\twhich all have two or three supporting documents\n\n\nThose are still fairly small numbers. But small numbers multiplied by other small numbers tend to lead to big numbers.\n\n\n\n5 categories = 5 category descriptions\n\nplus\n\n5 categories \u00d7 5 products each = 25 product descriptions\n\nplus\n\n25 products \u00d7 2.5 (average) supporting documents = 63 supporting documents\n\nequals\n\n93 pages\n\n\n\nSuddenly our twenty- or thirty-page website is running towards one hundred.\n\nThat\u2019s probably enough to get most project teams to sit up and take notice. But there\u2019s still the danger of underestimating how long it\u2019s going to take to create the content. After all, assuming the supporting documents already exist in some form, there are only about twenty-five to thirty pages of new copy to write.\n\nHow much work is it?\n\nAgain, we have the problem that small numbers when multiplied by other small numbers tend to lead to big numbers. Let\u2019s make a rough guess that it\u2019ll take four hours to write each product category and description page we need. That feels a little conservative if we\u2019re writing stuff from scratch, but assuming the person doing it already knows the products fairly well it\u2019s not unreasonable.\n\n\n\n30 pages \u00d7 4 hours each = 120 hours\n\n120 hours \u00f7 7.5 working hours a day = 16 days\n\n\n\nOuch.\n\nAt this point it\u2019s pretty clear we\u2019re not getting this site launched in two weeks. \n\nThe goal is the conversation\n\nBy breaking down the site into its content components, and putting some rough estimates on how long each might take to produce, the client instantly realised that there was no way they would be ready to launch it in two weeks. Although we still didn\u2019t know exactly when it would be ready, getting to that realisation right at the start of the project was a major win for everybody. Without it, the design agency would have bust a gut to get the design, front-end and CMS all done in double-quick time, only to find it was all for nothing as barely half the content was ready. As it was, an early discussion about content, albeit a brief one, bought everyone time to tackle the project properly, without pulling any long nights or working weekends.\n\nIf you haven\u2019t been able to get people to discuss content plans for the project, these kinds of rough estimates should give you enough evidence to get everyone to start taking it seriously. Your goal is to get everyone on the project to a place where they are ready to talk in detail about who is going to create this content, and how long it\u2019s really going to take them, and to get to those conversations before lack of content becomes a problem.\n\nBe careful though. It\u2019s best to talk in ranges and round numbers when your estimates are this uncertain. And watch those multipliers. Given small numbers multiplied by other small numbers lead to big numbers, changing just one number can greatly change the overall estimate. I like to run a couple of different scenarios to check what things look like if I\u2019ve under- or overestimated either how many pages we\u2019re going to need, or how long they\u2019re going to take to create. For example:\n\n\n\nTop end: 30 pages \u00d7 5 hours = 150 hours, or 20 days\n\nBottom end: 25 pages \u00d7 4 hours = 100 hours, or 13.3 days\n\n\n\nSo rather than say, \u201cI estimate the content will take around sixteen days to produce\u201d, I\u2019m going to say, \u201cI think the content will take about three to four weeks to produce\u201d. Even with qualifiers like estimate and around, sixteen days sounds too precise. Whereas three to four weeks instantly conveys that this is just a rough figure.\n\nWho\u2019s going to make it?\n\nSo, people tend to underestimate two crucial things about content: how much content they need, and how long content takes to write. At this stage, you\u2019re still in danger of the latter, because it\u2019s tempting to simply estimate how much time content takes to write (or record, if we\u2019re talking audio or visual content), and overlook all the other work that needs to goes on around it. \n\nTake 24 ways as an example. In terms of our three deceptively simple questions: what is practical articles about web design; how many is twenty-four, one for each day of Advent; and who are experts working on the web, one to write each article. \n\nBut there\u2019s another who you might not have considered. \n\nSomeone needs to select those authors in the first place, make sure they deliver their articles on time (and find someone to replace them if they don\u2019t), review drafts, copy-edit and proofread final versions, upload them to the site, promote them, keep an eye on the comments and make sure there are still presents under the tree on Christmas morning.\n\nEven if each of those tasks only takes an hour or so, it then needs multiplying by twenty-four (except the presents, obviously). And as we\u2019ve already seen, small numbers multiplied by small numbers quickly turn into much bigger numbers. Just a few hours per article, when multiplied by twenty-four articles, easily multiplies up to days or even weeks of effort.\n\nTo get a more accurate estimate of how long the different kinds of content are going to take, you need to break down the content production work into its constituent stages, starting with planning, moving on through the main work of creation, to reviewing, approvals and finally publishing. You need to think about who needs to be involved at each step, and how much time they\u2019ll need to do their bit. \n\nTaken together, these things make up your content workflow. The workflow will be different for each organisation, but might look something like this:\n\n\n\tEddie the web editor will work out the key messages and objectives for each page, and agree them with Mo the marketing director.\n\tEddie will then get Cal, the copywriter, to write the first draft.\n\tAs part of that, Cal will interview Sam the subject expert to understand the intricacies of the subject and get all the facts straight.\n\tOnce Cal\u2019s done the first draft, it\u2019ll go to Sam to check for accuracy, while Eddie reviews it for style and message.\n\tOnce Cal has incorporated their feedback it\u2019s time to get Mo to have a look at the final draft.\n\tIf Mo\u2019s happy, it\u2019ll get a final proofread, be uploaded to the CMS, and Mo will give the final sign-off and release it for publishing.\n\n\nYou can plot this on a table, with the stages of the content production process down the side, and the key roles or personnel along with top. Then the team can estimate how much time they think each of them needs at each stage.\n\n\n \n \n Mo (marketing director)\n Sam (subject expert)\n Eddie (web editor)\n Cal (copywriter)\n \n \n Outline: define key messages and objectives\n \n \n 30 min\n \n \n \n Review outline\n 15 min\n \n \n \n \n \n First draft\n \n 30 min\n \n 3 hours\n \n \n Review 1st draft\n \n 30 min\n 30 min\n \n \n \n 2nd draft\n \n \n \n 1 hour\n \n \n Review 2nd draft\n 15 min\n 15 min\n 15 min\n \n \n \n Final amendments\n \n \n \n 30 min\n \n \n Proofread\n \n \n 15 min\n \n \n \n Upload\n \n \n \n 15 min\n \n \n Sign-off\n 10 min\n \n \n \n \n \n TOTAL\n 40 min\n 1 hour 15 min\n 1 hour 30 min\n 4 hours 45 min\n \n\n\nYou can then bring out your calculator again, and come up with some more big scary numbers showing how much time it\u2019s going to take for the whole team to get all the content needed not just written, but also planned, reviewed, approved and published.\n\nWith an experienced team you can run this exercise as a group workshop and get some fairly accurate estimates pretty quickly. If this is all a bit new to you, check out Gather Content\u2019s Content Production Planning for Agencies ebook for a useful guide to common content roles, ballpark estimates for how much time each one needs on a typical piece of content, and how to run a process and estimating workshop to dig into them in more detail. \n\nOn a small team, one person might play many roles, but you should still sanity-check your estimates by breaking down the process and putting a rough estimate on each stage. With only a couple of people involved, it\u2019s even easier to only include the core activity like writing or recording in your estimates, and forget to allow time for the planning, reviewing, proofreading, publishing and promoting you\u2019ll still need to do. And even in a team of one, if at all possible you should find at least one other person to act as a second pair of eyes, and give anything you produce a quick once-over and proofread before it\u2019s published.\n\nDepending on the kind of content you\u2019re making, you should also consider what will happen after it\u2019s published. The full content life cycle should include promotion, monitoring and regular reviews to make sure content stays accurate and up to date. Making sure you have the time and resources available to do all those things for each piece of content is essential for creating a sustainable content programme.\n\nThe proof of the pudding\n\nEven after digging into workflow and getting the whole team involved in estimating, you\u2019re still largely in the realm of the guesstimate. The good news, though, is that you can quite quickly start finding out if your guesstimates are right or not. As soon as you can, pilot the production process with some real content. This is a double-win: you start finding out how long it really takes to produce all this fab new content, and you get real content to work with in designs and prototypes.\n\nOnce you\u2019ve run a few things through your process, you\u2019ll be able to refine your estimates, confirm your workflow, and give everyone involved a clear idea of when it will all be ready, and what you need from them.\n\nKeeping it all on track\n\nAt this point I like to pull everything together into the content strategist\u2019s favourite tool: the spreadsheet.\n\nA simple content production checklist is a bit like a content inventory or audit, but for the content you don\u2019t yet have, not the stuff already done. You can grab an example here.\n\nEach piece of content gets its own row, with columns for basic information like page title, ID (which should match the site map), and who\u2019s responsible for making it. You can capture simple details like target audience and key messages here too, though for more complex content, page description tables like those described by Relly Annett-Baker in \u201cExtracting the Content\u201d may be a better tool to use. Just adapt these columns to whatever makes sense for your content.\n\nI then have columns to track where each piece is in the production process. I usually keep this simple, with a column each to mark whether it\u2019s draft, final or uploaded. The status column on the left automatically shows the item\u2019s status, using a simple traffic light colour scheme for whether the item is still to do (red), in draft (amber), or done (green). Seeing the whole thing slowly turn from red to green is a nice motivator.\n\nIf you want to track the workflow in more detail, a kanban board in a tool like Trello is a great way for a team to collaborate on content production, track each item\u2019s progress, and keep an eye out for bottlenecks and delays. \n\nGetting to the content strategy conversation\n\nIt\u2019s a relatively simple exercise, then, to decide not just what kinds of pages you need, but also how many of them: put some rough estimates of effort on the tasks needed to create those pages \u2013 not just the writing, but all the other stages of planning, reviewing, approving, publishing and promoting \u2013 and then multiply all those things together. This will quickly bring some reality to grand visions and overambitious plans. Do it early enough, and even when the final big scary number is a lot bigger and scarier than everyone thought, you\u2019ll still have time to do something about it.\n\nAs well as getting everyone on board for some proper content planning activities, that big scary number is your opportunity to get to the real core questions of content strategy: do we really need all this content? Where can existing content be reused and repurposed? How do we prioritise our efforts? What really matters to our readers and users?\n\nTime and again, case studies show that less content delivers more: more leads, more sales, more self-service support and savings in the call centre. Although that argument is primarily one you should make from a good-for-the-users perspective, it doesn\u2019t hurt to be able to make it from the cheaper-for-the-business perspective as well, and to have some big scary numbers to back that up.", "year": "2014", "author": "Sophie Dennis", "author_slug": "sophiedennis", "published": "2014-12-17T00:00:00+00:00", "url": "https://24ways.org/2014/content-production-planning/", "topic": "content"} {"rowid": 44, "title": "Taglines and Truisms", "contents": "To bring her good luck, \u201cwhite rabbits\u201d was the first thing that my grandmother said out loud on the first day of every month. We all need a little luck, but we shouldn\u2019t rely on it, especially when it comes to attracting new clients.\n\nThe first thing we say to a prospective client when they visit our website for the first time helps them to understand not only what we do but why we do it. We can also help them understand why they should choose to work with us over one of our competitors.\n\nTake a minute or two to look at your competitors\u2019 websites. What\u2019s the first thing that they say about themselves? Do they say that they \u201cdesign delightful digital experiences,\u201d \u201ccraft beautiful experiences\u201d or \u201ccreate remarkable digital experiences?\u201d\n\nIt\u2019s easy to find companies who introduce themselves with what they do, their proposition, but what a company does is only part of their story. Their beliefs and values, what they stand for why they do what they do are also important. \n\nWhen someone visits our websites for the first time, we have only a brief moment to help them understand us. To help us we can learn from the advertising industry, where the job of a tagline is to communicate a concept, deliver a message and sell a product, often using only a few words.\n\nWhen an advertising campaign is effective, its tagline stays with you, sometimes long after that campaign is over. For example, can you remember which company or brand these taglines help to sell? (Answers at the bottom of the article:)\n\n\nThe Ultimate Driving Machine\nJust Do It\nDon\u2019t Leave Home Without It\n\n\nA clever tagline isn\u2019t just a play on words, although it can include one. A tagline does far more than help make your company memorable. Used well, it brings together notions of what makes your company and what you offer special. Then it expresses those notions in a few words or possibly a short sentence. \n\nI\u2019m sure that everyone can find examples of company slogans written in the type of language that should stay within the walls of a marketing department. We can also find taglines where the meaning is buried so deep that the tag itself becomes effectively meaningless.\n\nA meaningful tagline supports our ideas about who we are and what we offer, and provides a platform for different executions of them, sometimes over a period of time. For a tagline to work well, it must allow for current and future ideas about a brand.\n\nIt must also be meaningful to our brand and describe a truism, a truth that need not be a fact or statistic, but something that\u2019s true about us, who we are, what we do and why that\u2019s distinctive. It can be obvious, funny, serious or specific but above all it must be true. It should also be difficult to argue with, making your messages difficult to argue with too.\n\nI doubt that I need remind you who this tagline belongs to:\n\n\n\tThere are some things money can\u2019t buy. For everything else there\u2019s MasterCard.\n\n\nThat tagline was launched in 1997 by McCann-Erickson along with the \u201cPriceless\u201d campaign and it helped establish MasterCard as a friendlier credit card company, one with a sense of humour. \n\nMasterCard\u2019s truism is that the things which really matter in life can\u2019t be bought. They are worth more than anything that a monetary value can be applied to. In expressing that truism through the tagline, MasterCard\u2019s advertising tells people to use not just any credit card, but their MasterCard, to pay for everything they buy.\n\n\u201cGuinness is good for you\u201d may have been a stretch, but \u201cGood things come to those who wait\u201d builds on the truism that patience is a virtue and therefore a good pint of Guinness takes time to pour (119.5 seconds. I know you were wondering.)\n\nThe fact that British Airways flies to more destinations than any other airline is their truism, and led their advertisers to the now famous tagline, \u201cThe world\u2019s favourite airline.\u201d\n\n\n\nAt my company, Stuff & Nonsense, we\u2019ve been thinking about taglines as we think about our position within an industry that seems full of companies who \u201cdesign\u201d, \u201ccraft\u201d, and \u201ccreate\u201d \u201cdelightful\u201d, \u201cbeautiful\u201d, \u201cremarkable digital experiences\u201d.\n\nMuch of what made us different has changed along with the type of work we\u2019re interested in doing. Our work\u2019s expanded beyond websites and now includes design for mobile and other media. It\u2019s true we can\u2019t know how or where it will be seen. The ways that we make it are flexible too as we\u2019re careful not to become tied to particular tools or approaches. \n\nIt\u2019s also true that we\u2019re a small team. One that\u2019s flexible enough to travel around the world to work alongside our clients. We join their in-house teams and we collaborate with them in ways that other agencies often find more difficult. We know that our clients appreciate our flexibility and have derived enormous value from it. We know that we\u2019ve won business because of it and that it\u2019s now a big part of our proposition.\n\nOur truism is that we\u2019re flexible, \u201cFabulously flexible\u201d as our tagline now expresses. And although we know that there may be other agencies who can be similarly flexible \u2013 after all, being flexible is not a unique selling proposition \u2013 only we do it so fabulously.\n\n\n\nAs the old year rolls into the new, how will your company describe what you do in 2015? More importantly, how will you tell prospective clients why you do it, what matters to you and why they should work with you?\n\nStart by writing a list of truisms about your company. Write as many as you can, but then whittle that list down to just one, the most important truth. Work on that truism to create a tagline that\u2019s meaningful, difficult to be argue with and, above all, uniquely yours.\n\nAnswers\n\n\nThe Ultimate Driving Machine (BMW)\nJust Do It (Nike)\nDon\u2019t Leave Home Without It (American Express)", "year": "2014", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2014-12-23T00:00:00+00:00", "url": "https://24ways.org/2014/taglines-and-truisms/", "topic": "business"} {"rowid": 36, "title": "Naming Things", "contents": "There are only two hard things in computer science: cache invalidation and naming things.\nPhil Karlton\n\n\nBeing a professional web developer means taking responsibility for the code you write and ensuring it is comprehensible to others. Having a documented code style is one means of achieving this, although the size and type of project you\u2019re working on will dictate the conventions used and how rigorously they are enforced.\n\nWorking in-house may mean working with multiple developers, perhaps in distributed teams, who are all committing changes \u2013 possibly to a significant codebase \u2013 at the same time. Left unchecked, this codebase can become unwieldy. Coding conventions ensure everyone can contribute, and help build a product that works as a coherent whole.\n\nEven on smaller projects, perhaps working within an agency or by yourself, at some point the resulting product will need to be handed over to a third party. It\u2019s sensible, therefore, to ensure that your code can be understood by those who\u2019ll eventually take ownership of it.\n\nPut simply, code is read more often than it is written or changed. A consistent and predictable naming scheme can make code easier for other developers to understand, improve and maintain, presumably leaving them free to worry about cache invalidation.\n\nLet\u2019s talk about semantics\n\nNames not only allow us to identify objects, but they can also help us describe the objects being identified.\n\nSemantics (the meaning or interpretation of words) is the cornerstone of standards-based web development. Using appropriate HTML elements allows us to create documents and applications that have implicit structural meaning. Thanks to HTML5, the vocabulary we can choose from has grown even larger.\n\nHTML elements provide one level of meaning: a widely accepted description of a document\u2019s underlying structure. It\u2019s only with the mutual agreement of browser vendors and developers that
indicates a paragraph.\n\nYet (with the exception of widely accepted microdata and microformat schemas) only HTML elements convey any meaning that can be parsed consistently by user agents. While using semantic values for class names is a noble endeavour, they provide no additional information to the visitor of a website; take them away and a document will have exactly the same semantic value.\n\nI didn\u2019t always think this was the case, but the real world has a habit of changing your opinion. Much of my thinking around semantics has been informed by the writing of my peers. In \u201cAbout HTML semantics and front-end architecture\u201d, Nicholas Gallagher wrote:\n\n\n\tThe important thing for class name semantics in non-trivial applications is that they be driven by pragmatism and best serve their primary purpose \u2013 providing meaningful, flexible, and reusable presentational/behavioural hooks for developers to use.\n\n\nThese thoughts are echoed by Harry Roberts in his CSS Guidelines:\n\n\n\tThe debate surrounding semantics has raged for years, but it is important that we adopt a more pragmatic, sensible approach to naming things in order to work more efficiently and effectively. Instead of focussing on \u2018semantics\u2019, look more closely at sensibility and longevity \u2013 choose names based on ease of maintenance, not for their perceived meaning.\n\n\nNaming methodologies\n\nFront-end development has undergone a revolution in recent years. As the projects we\u2019ve worked on have grown larger and more important, our development practices have matured. The pros and cons of object-orientated approaches to CSS can be endlessly debated, yet their introduction has highlighted the usefulness of having documented naming schemes.\n\nJonathan Snook\u2019s SMACSS (Scalable and Modular Architecture for CSS) collects style rules into five categories: base, layout, module, state and theme. This grouping makes it clear what each rule does, and is aided by a naming convention:\n\n\n\tBy separating rules into the five categories, naming convention is beneficial for immediately understanding which category a particular style belongs to and its role within the overall scope of the page. On large projects, it is more likely to have styles broken up across multiple files. In these cases, naming convention also makes it easier to find which file a style belongs to.\n\n\tI like to use a prefix to differentiate between layout, state and module rules. For layout, I use l- but layout- would work just as well. Using prefixes like grid- also provide enough clarity to separate layout styles from other styles. For state rules, I like is- as in is-hidden or is-collapsed. This helps describe things in a very readable way.\n\n\nSMACSS is more a set of suggestions than a rigid framework, so its ideas can be incorporated into your own practice. Nicholas Gallagher\u2019s SUIT CSS project is far more strict in its naming conventions:\n\n\n\tSUIT CSS relies on structured class names and meaningful hyphens (i.e., not using hyphens merely to separate words). This helps to work around the current limits of applying CSS to the DOM (i.e., the lack of style encapsulation), and to better communicate the relationships between classes.\n\n\nOver the last year, I\u2019ve favoured a BEM-inspired approach to CSS. BEM stands for block, element, modifier, which describes the three types of rule that contribute to the style of a single component. This means that, given the following markup:\n\n