{"rowid": 208, "title": "All That Glisters", "contents": "Tradition has it that at this time of year, families gather together, sit, eat and share stories. It\u2019s an opportunity for the wisdom of the elders to be passed down to the younger members of the tribe. Tradition also has it that we should chase cheese downhill and dunk the nice lady to prove she\u2019s a witch, so maybe let\u2019s not put too much stock in that.\nI\u2019ve been building things on the web professionally for about twenty years, and although the web has changed immeasurably, it\u2019s probably not changed as much as I have. While I can happily say I\u2019m not the young (always right, always arrogant) developer that I once was, unfortunately I\u2019m now an approaching-middle-age developer who thinks he\u2019s always right and on top of it is extremely pompous. What can you do? Nature has devised this system with the distinct advantage of allowing us to always be right, and only ever wrong in the future or in the past. So let\u2019s roll with it.\nIncreasingly, there seems to be a sense of fatigue within our industry. Just when you think you\u2019ve got a handle on whatever the latest tool or technology is, something new comes out to replace it. Suddenly you find that you\u2019ve invested precious time learning something new and it\u2019s already old hat. The pace of change is so rapid, that new developers don\u2019t know where to start, and experienced developers don\u2019t know where it ends. With that in mind, here\u2019s some fireside thoughts from a pompous old developer, that I hope might bring some Christmas comfort.\nReliable and boring beats shiny and new\nThere are so many new tools, frameworks, techniques, styles and libraries to learn. You know what? You don\u2019t have to use them. You\u2019re not a bad developer if you use Grunt even though others have switched to Gulp or Brunch or Webpack or Banana Sandwich. It\u2019s probably misguided to spend lots of project time messing around with build tool fashions when your so last year build tool is already doing what you need.\nJust a little reminder that it\u2019s about 100 times more important what you build than how you build it.\u2014 Chris Coyier (@chriscoyier) December 10, 2017\n\nI think it helps if we understand why so many new solutions exist. Most developers are predisposed to enjoy creating new things more than improving established systems. It\u2019s natural, because it\u2019s actually much easier and more exciting to create something new that works exactly how you think it should be than to improve an existing, imperfect solution. Improving and refactoring a system is hard, and it takes real chops, much more than just building something new.\nThe consequence of this is that new tools appear all the time. A developer will get a fresh new idea of how to tackle a problem \u2013 usually out of dissatisfaction with an existing solution, and figure the best way to implement that idea is to build something new around it. Often, that something new will do the same job as something old that already exists; it will just do it in a different way. Sometimes in a better way. Sometimes, just different.\nxkcd: Standards\nThat\u2019s not to say new tools are bad, and it\u2019s not bad that they exist. We shouldn\u2019t be crushing new ideas, and it\u2019s not wrong to adopt a new solution over an old one, but you know what? There\u2019s no imperative to switch right away. The next time you hit a pain point with your current solution, or have time to re-evaluate, check out what\u2019s new and see how the latest generation of tools and technologies can help. There\u2019s no prize for solving problems you don\u2019t have yet, and heading further into the desert in search of water is a survival tactic, not an aspiration.\nNew is better, but also worse\nSoftware, much like people, is born with a whole lot of potential and not much utility. Newborns \u2014 both digital and meaty \u2014 are exciting and cute but they also lead to sleepless nights and pools of vomit.\nNew technology contains lots of useful new features, but it\u2019s also more likely to contain bugs and be subject to more rapid change. Jumping on a new framework is great, right until there are API changes and you need to refactor your entire project to be able to update. More mature solutions have a higher weight of existing projects on their shoulders, and so the need to maintain backward compatibility is stronger. Things still move forward, but in a more controlled way.\nSo how do we balance the need to move technology forward with the need to provide mature and stable solutions for the projects we work on? I think there\u2019s a couple of good ways to do that.\nGet personal\nUse all the new shiny tools on your side-projects, personal projects, seasonal throw-aways and anywhere where the stakes are low. If you know you can patch around problems without much consequence, go for it. Build your personal blog on a CMS that stores data in the woven bark of a silver birch. Find where it breaks. Find where it excels. Find yourself if you like. When it comes to high-stakes projects, you\u2019ll hopefully have enough experience to know what you\u2019re getting into.\nFocus on the unique problem\nThat\u2019s not to say you should never risk using a new technology for \u2018real\u2019 work. Instead, distinguish the areas of your project where a new technology solves a specifically identified, measurable business objective, verses those where it won\u2019t. \nA brand new web application framework might be fun to use, but are you in the business of solving a web application framework problem? That new web server made of taffeta might increase static file throughput slightly, but are you in the business of serving static assets, or would it be better to just run up nginx and never have to think about that problem again. (Clue: it\u2019s the nginx one.)\nBut when it comes to building that live sports interface for keeping fans up to date with the blow-by-blow of the big game, that\u2019s where it might make sense to take a risk on an amazing-looking new JavaScript realtime interface framework. That\u2019s the time to run up a breakthrough new message queue server that can deliver jobs to workers via extrasensory perception and keep the score updates flowing instantaneously. \nThose are the risks worth taking, as those new technologies have the potential to help you solve your core problems in a markedly improved way. Unproven technology is worth the risk if it solves a specific business objective. If it doesn\u2019t, don\u2019t make work for yourself - use something mature and stable.\nPick the right tools\nOur job as developers is to solve problems using code, and do so in an effective and responsible way. You\u2019ve been hired to use your expertise in picking the right tools for the job, and a big part of that is weighing up the risk verse the reward of each part of the system. The best tools for the job might be something cutting edge, but \u2018best\u2019 can also mean most stable, reliable or easy-to-hire-for.\nGo out and learn (and create!) new tools and experiment with them. Understand what problems they solve and what the pitfalls are. Use them in production for low-stakes projects to get real experience, and then once you really know their character, then think about using them when the stakes are higher.\nThe rest of the time? The tools you\u2019re using now are solid and proven and you know their capabilities and pitfalls well. They might not always be the fashionable candidate, but they often make for a very solid choice.", "year": "2017", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2017-12-24T00:00:00+00:00", "url": "https://24ways.org/2017/all-that-glisters/", "topic": "business"} {"rowid": 212, "title": "Refactoring Your Way to a Design System", "contents": "I love refactoring code. Absolutely love it. There\u2019s something about taking a piece of UI or a bit of code and reworking it in a way that is simpler, modular, and reusable that makes me incredibly happy.\nI also love design systems work. It gives hybrids like me a home. It seems like everyone is talking about design systems right now. Design systems teams are perfect for those who enjoy doing architectural work and who straddle the line between designer and developer. \nUna Kravets recently identified some of the reasons that design systems fail, and chief among them are lack of buy-in, underlying architecture, and communication. While it\u2019s definitely easier to establish these before project work begins, that doesn\u2019t mean it is the only path to success. \nIt\u2019s a privilege to work on a greenfield project, and one that is not afforded to many. Companies with complex and/or legacy codebases may not be able to support a full rewrite of their product. In addition, many people feel overwhelmed at the thought of creating a complete system and are at a loss of how or where to even begin the process. \nThis is where refactoring comes into play.\nAccording to Martin Fowler, \u201crefactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.\u201d It\u2019s largely invisible work, and if you do it right, the end user will never know the difference. What it will do is provide a decent foundation to begin more systematic work.\nBuild a solid foundation\nWhen I was first asked to create Pantsuit, the design system for Hillary for America, I was tasked with changing our codebase to be more modular and scalable, without changing the behavior or visual design of the UI. We needed a system in place that would allow for the rapid creation of new projects while maintaining a consistent visual language. In essence, I was asked to refactor our code into a design system.\nDuring that refactor, I focused the majority of my efforts on creating a scalable architecture based on the UI components in a single workflow. Since I needed to maintain a 1:1 parity with production, the only changes I could create were under-the-hood. I started with writing coding standards and deciding on a CSS architecture that I would then use as I rewrote sections of the codebase. \nIf you already have these in place, great! If not, then this is an excellent place to start. Even if your dream of a design system is never fully realized, having a coding philosophy and architecture in place will still have far-reaching benefits and implications.\nI want to note that if your refactor includes creating new coding standards or a CSS architecture, don\u2019t try to switch everything over right away. Instead, focus on a single new feature and isolate/encapsulate your work from the rest of the codebase.\nFocus on the features\n\nThe key principle to cleaning up a complex codebase is to always refactor in the service of a feature. \n\u2014 Max Kanat-Alexander\n\nRefactoring for the sake of refactoring can easily lead to accusations of misused time and lack of results. Another danger of refactoring is that it can turn into yak-shaving if you aren\u2019t disciplined in your approach. To that end, tying your refactored components to feature work is a great way to limit scope and reduce the rest of unintended changes.\nFor example, the initial work on Pantsuit focused only on components related to the donations flow. Every line of code I wrote was in service to improving the maintainability and modularity of that UI. Because we didn\u2019t have any standards in place, I started with those. From there, I identified all the components present in every step of the donations flow, which included some type styles, buttons, form inputs and error states. Then came the refactor of each individual component. Finally, I reintegrated the newly refactored components into the existing donations flow and tested it against production, checking for visual and behavioral diffs. At the end of this process, I had the beginning of a design system that would grow to serve over 50 applications, and a case study to demonstrate its effectiveness.\nIdeally, you\u2019ll want to get buy-in from your stakeholders and product owners before you begin any design systems work. However, in the absence of buy-in, linking your work to new feature development is a good way to both limit the scope of your refactor and jump start component creation.\nIn addition, if you\u2019re still trying to convince your team of the benefits of a design system, starting small and using the newly refactored, feature-driven work as a case study is one way showcase a design systems\u2019 value. By providing a concrete example of how working towards a design system contributed to the project\u2019s success, you\u2019re gathering the data necessary to secure buy-in for a larger-scale effort. It\u2019s a great way to show value, rather than just talking about it.\nShow, don\u2019t tell\nPerhaps the most important thing you can do for any design system is to document it. The key is to create a frictionless way to keep the documentation up-to-date, otherwise no one will contribute to it, and in turn, it will become obsolete and useless. \nThere are lots of tools out there to help you get started documenting your new system. One of my favorites is KSS, which parses comments in the code and uses them to generate a style guide. For Pantsuit, I used the node version of KSS, along with a template to quickly spin up a documentation site.\nI\u2019ve listed just a few tools below; for even more, check out the tools sections of styleguides.io.\n\nFractal\nPattern Lab\nDrizzle\nFabricator\nAstrum\nCatalog\n\nRegardless of what tool you settle on, it needs to integrate well with your current workflow. \nConclusion: always be refactoring\nIf you\u2019re not lucky enough to be able to start a new design system from scratch, you can start small and work on a single feature or component. With each new project comes a new opportunity to flesh out a new part of the system, and another potential case study to secure buy-in and showcase its value. Make sure to carefully and thoroughly document each new portion of the system as it\u2019s built. After a few projects, you\u2019ll find yourself with a decent start to a design system. \nGood luck, and happy holidays!\nFurther reading:\n\nWhy Design Systems Fail\nCSS Architecture for Design Systems\nRefactoring: Improving the Design of Existing Code\nRefactoring CSS: The Three I\u2019s\nRefactoring is About Features", "year": "2017", "author": "Mina Markham", "author_slug": "minamarkham", "published": "2017-12-23T00:00:00+00:00", "url": "https://24ways.org/2017/refactoring-your-way-to-a-design-system/", "topic": "code"} {"rowid": 194, "title": "Design Systems and Hybrids", "contents": "The other day on Twitter, I saw a thread started by Dorian Taylor about why design systems are so hot right now. In the thread, he made the case that they\u2019ve been around for ages and some folks were just slow to catch up. It was an interesting thread, and not the first time I\u2019ve seen folks discuss this. \u201cDesign systems are so hot right now\u201d was even used recently\u00a0in this very publication.\nAnd yes it\u2019s true that they\u2019ve been around for ages. Design artefact collectors\u2019 obsession with reprints of old graphic standards manuals of the past\u00a0are a reminder. Sometimes old things become new again, either through a rediscovery or awakening (wow, that sounds really deep). But I think that\u2019s definitely what happened here.\nSome very opinionated answers that come to mind for me are:\n\nThe need for them has increased with the needs of software development. With the increasing number of devices (phones, tablets, watches, etc.), scaling design has required the need to double down on systems thinking and processes.\nInvestments with huge cost-saving returns. The time investment it takes to onboard new people as you staff up large teams (and the time it takes to fix bugs and inconsistencies) could be better spent building up a system that lets you ship at a faster pace. It also gives you more time to focus on the bigger picture instead of what color a button border is.\nIf you do\u00a0have to onboard new designers, the design system is a great educational resource to get up to speed quickly on your organization\u2019s design principles, materials/tools, and methods.\n\n\n\u201cHere\u2019s the simple truth: you can\u2019t innovate on products without first innovating the way you build them.\u201d\n\u2014 Alex Schleifer, The Way We Build\n\nThese are just some of the reasons. But there is another answer, and a personal conclusion that I\u2019ve reached. It relates to the way I work and what I love working on, but I don\u2019t see it talked about much.\nHybrids Have a Home\nI\u2019m a hybrid designer. I code in HTML & CSS (with a preference for Sass). But I don\u2019t call myself a frontend developer. I used to back in the day (I was a UI frontend developer at Apple over a decade ago, but all I wrote was HTML & CSS). I identify with designer because that\u2019s my training and interest, but the ideas of what a frontend developer can do has changed quite a ton over the years. Setting things up in build tools and processes are not my skill. And I know a lot of designers who share this experience with me.\nThere are also hybrid developers who identify as developers, but have excellent design skills. Buddies like my pal Brandon Ferrua\u00a0who was on my team at Salesforce is a great example of this. And we worked fantastically together.\nSometimes, companies don\u2019t know how to deal with hybrids. I\u2019ve been told to choose a side, and have even been made to join a development team simply because I could code my designs (and then when I couldn\u2019t deliver the same type of code my teammates could, and I felt like I wasn\u2019t able to use my talents in the most effective way).\nThere are a lot more folks out there I know of who identify as a hybrid, and many have found ourselves working on design systems. Una Kravets recently had a thread discussing this as well. At Clarity, this came up a lot in hallway conversations, breaks, and the after parties. I think that this job is a haven for folks who often find themselves in the middle.\nFor companies that get it, these people find joy in getting to use a wider variety of skills and being bridges; advocates that can speak to designers and developers, helping bring \u2028unity to an organization. They can wireframe, throw together a prototype, create color systems, architect naming conventions for design tokens. Design systems are their perfect home. I think this has contributed to the uptick in discussions and interest on this subject (in addition to the team- and company-focused reasons).\nKeep Design Systems Teams Cross-Functional\nSpeaking of teams, something some larger companies fall prey to is creating walls and silos where they need not be. If you place all your visual designers in one place, all your coders in another, and so on, you\u2019re not doing yourselves any favors. Meanwhile, your hybrids are caught in the middle not knowing exactly where they belong. Design systems teams should have representatives (whether on a core team, or a virtual/federated team) that bring different skillsets. Design, code, writing, accessibility, product management, and so on. You\u2019ll have a stronger vision on where to take your design system and to make it succeed. Siloing defeats the whole purpose of what design systems are meant for.\nHappy holidays, and may the force be with you.\nFurther Reading\n\nWhy Design Systems Fail\nDesign Systems are for People\nDesign Systems Handbook", "year": "2017", "author": "Jina Anne", "author_slug": "jina", "published": "2017-12-22T00:00:00+00:00", "url": "https://24ways.org/2017/design-systems-and-hybrids/", "topic": "process"} {"rowid": 199, "title": "Knowing the Future - Tips for a Happy Launch Day", "contents": "You\u2019ve chosen your frameworks and libraries. You\u2019ve learned how to write code which satisfies the buzzword and performance gods. Now you need to serve it to a global audience, and make things easy to preview, to test, to sign-off, and to evolve.\nBut infrastructure design is difficult and boring for most of us. We just want to get our work out into the wild.\nIf only we had tools which would let us go, \u201cOh yeah! It all deploys perfectly every time\u201d and shout, \u201cYou need another release? BAM! What\u2019s next?\u201d\nA truth that can be hard to admit is that very often, the production environment and its associated deployment processes are poorly defined until late into a project. This can be a problem.\nIt makes my palms sweaty just thinking about it.\nIf like me, you have spent time building things for clients, you\u2019ll probably have found yourself working with a variety of technical partners and customers who bring different constraints and opportunities to your projects. Knowing and proving the environments and the deployment processes is often very difficult, but can be a factor which profoundly impacts our ability to deliver what we promised. To say nothing of our ability to sleep at night or leave our fingernails un-chewed.\nLet\u2019s look at this a little, and see if we can\u2019t set you up for a good night\u2019s sleep, with dry palms and tidy fingernails.\nA familiar problem\nYou\u2019ve been here too, right? The project development was tough, but you\u2019re pleased with what you are running in your local development environments. Now you need to get the client to see and approve your build, and hopefully indicate with a cheery thumbs up that it can \u201cgo live\u201d.\n\nChances are that we have a staging environment where the client can see the build. But be honest, is this exactly the same as the production environment? It should be, but often it\u2019s not. Often the staging environment is nothing more than a visible server with none of the optimisations, security, load balancing, caching, and other vital bits of machinery that we\u2019ll need (and need to test) in \u201cprod\u201d.\nOften the production environment is still being \u201cset up\u201d and you\u2019ll have to wait and see.\nIn development, \u201cwait and see\u201d is the enemy.\nInstead of waiting to see, we need to make the provisioning of, and deployment to our different environments one of the very first jobs of our project. I\u2019ve often needed to be the unpopular voice in the room who makes a big fuss when this is delayed. I\u2019ve described it as being a \u201ccritical blocker\u201d during project meetings and suggested that everything should halt until it is fixed. \nIt is that important.\nClients don\u2019t often like hearing a wary, disruptive voice saying \u201cwhoa there Nelly!\u201d, because the development should be able to continue while the production environment gets sorted out, right? \nSure. But if it is not seen as a blocker, it is seen as something that can just happen later. And if it happens later, all the ugly surprises and unknowns surface later too. And later is when we\u2019ll need to be thinking about other things. Not the plumbing. Trust me, it pays to face up to the issue right away rather than press on optimistically. The client will thank you later.\nAttitudes and expectations\nWe should, I think, exhibit these four attitudes towards production deployment:\n\nMake it scripted\nMake it automated\nMake it real\nMake it first\n\nMake it scripted\nLet\u2019s face it, we are going to need to deploy more than once over the course of the project. We are not going to get things perfect on our first shot. Nor should we expect to. And if we are going to repeat something, we want to be able to do it identically and predictably every time without needing to rely on our memories.\nDevelopers are great at scripting things which they would otherwise need to repeat. It makes us faster and it also helps us keep track of the steps we need to take.\nI\u2019m not crazy enough to try suggest the best technology to script your builds or deployments (holy wars lie down that path). A lot will depend on your languages and your tastes. Some will like Fabric, others will prefer Gulp, you might prefer Make or NPM. It doesn\u2019t really matter as long as you can script the process of building, packaging and deploying your project.\nWait. Won\u2019t we need to know everything about the build from the start in order to do this? Aren\u2019t our dependencies likely to change over time?\nYes. That would be ideal. But it\u2019s ok. Like our code, our deployment script will evolve over the life of a project. So evolve it. Start by scripting what is needed to support the first iteration of the project, and then maintain that script. It will become a valuable \u201csource of truth\u201d, providing a form of documentation of what your project needs for a successful deployment. Another bonus.\nMake it automated\nIf we have a scripted deployment which we can run by executing a single command, then we are in great shape to automate that process by triggering the build and deployment via suitable events.\nAgain, I prefer not to offer one single suggestion of when this should occur. That will depend on your approach to the project, how your development team is organised, and how your QA team operate. You can tune this to suit.\nFor one project I worked on, we chose to trigger the build and deployment to our production environment every time we used Git to tag the master branch of our version control repository. There were a few moving parts, and we needed to do some upfront work to get everything working, but that upfront effort was repaid many fold as we deployed time and time again, and exposed some issues with our environment long before we got to \u201claunch day\u201d.\nWith a scripted and automated process, we can make deployments \u201ccheap\u201d. This is our goal. When there are minimal cognitive or time overheads associated with deploying, we\u2019re likely to do it all the more often and become more confident that it will behave as expected.\nMake it real\nAlright, we have written scripts to build and deploy our projects. Anyone tagging our repo will trigger things to happen as if by magic, but where are we pushing things to? We need to target a real environment if this is to have any value.\nA useful pattern is to have all activity on our develop branch trigger deployments to our staging server. Meanwhile tagging master will deploy a version to the production environment. How we organise this will depend on our git branching approach. (I\u2019ve seen as many ways of approaching Git Flow as I have seen ways of approaching \u201cAgile\u201d).\nIt\u2019s vital though, that we ensure that we are deploying to, and testing against, our real infrastructure. We want to see real results. That\u2019s the best way to learn real lessons.\nMake it first\nBuilding our site to run in an environment not yet fully defined or available to test is like climbing without ropes \u2013 it\u2019s possible, but we put ourselves at risk. And the higher we climb the greater the risk. So it is important to do this as early as we possibly can.\nDon\u2019t have a certificate for our HTTPS yet? Fine, but let\u2019s still deploy to this evolving production environment and introduce HTTPS as soon as we can.\nBefore we know it we\u2019ll be proving that this is set up correctly and we\u2019ll not be surprised by mixed security alerts or other nasties further down the line.\n\nMailchimp perfectly capture the anxiety of sending emails to gazillions of people for a campaign. But we\u2019re lucky. Launching a site doesn\u2019t need to be like performing a mailshot. We can do things to banish that sweaty hand.\nDoing preparation work upfront means that by the time we need to launch the site into the wild, we have exercised the deployment mechanics, and tested the production environment so rigorously that this task will be boring.\n(It won\u2019t be boring. Launching should always be exciting because the world will finally get to see our beautiful, painstaking work. But nor should it be terrifying. Especially as a result of not knowing for certain if our processes and environments are going to work or burst into flames on the big day.)\nWhat tools exist?\nWell this all sounds lovely. But how should we tackle this? Where are the tools for us to use? As it happens, there are many service and tools that we can use to work this way.\nHosting\nAll of the big players like Amazon, Azure and Google offer tools which can help us here. Google for example, can host multiple deployed versions of your project in parallel and you can manage them via their App Engine console. Each build receives its own URL which you can use to access any deployed version of your site.\nHaving immutable deployments which stick around in perpetuity (or until you bin them) is a key feature which unlocks the ability to confidently direct your traffic to any version of your site. With that comes the capacity to test any version or feature in its real environment, and then promote a version, or rollback to a previous version whenever you want.\nA liberating power to have.\nContinuous integration\nIn order to create all of those different versions, we\u2019ll need somewhere to run our build and deployment scripts. Jenkins has been a popular Continuous Integration (CI) option for some time, and can be configured to perform all sorts of tasks, giving you extensive control over your deployment pipeline.\nYou need to host Jenkins yourself, but it provides some simple ways to do that.\nThe landscape for CI is getting richer and richer. With many hosted services like Circle CI providing this kind of automation up in the cloud.\nOne stop shop\nNetlify combines both hosting and continuous integration services. It monitors your git repositories and automatically runs your build in a container on its servers when it finds changes. Each branch and pull request in your git repository will result in an immutable version of your site with its own URL.\nNetlify is unlike Google Cloud, AWS or Azure in that it cannot host a dynamic server-side application for you. Instead it specialises in hosting static, or so called JAMstack sites.\nPersonally, I find that its simplicity makes it an approachable option, and a good place to learn and adopt some of these valuable habits.\nFull disclosure: I\u2019m a Netlify employee. But before I was, I was an avid customer, and it was through using Netlify that I first encountered some of these principles in practice.\nConclusion. It\u2019s all about the approach\nNo matter what tools or services you use (and there are many which can support these practices), the most important thing is to adopt an approach which lets you prove your environments as quickly as possible.\nFront-loading this effort will cast light onto the issues that you\u2019ll need to address early and often, leaving no infrastructure surprises to spoil things for you on launch day.\nAutomating the process will mean that when you do find things that you need to fix or to improve later (and you will), issuing another release will be trivial. It is a lovely feeling when you have confidence that releasing v1.0.0 will be no more stressful v0.0.1. In fact it should actually be less stressful, as you\u2019ll have been down this road many times by then. Fixing the potholes and smoothing the way as you went.\nFrom here, it should be a smooth ride.", "year": "2017", "author": "Phil Hawksworth", "author_slug": "philhawksworth", "published": "2017-12-21T00:00:00+00:00", "url": "https://24ways.org/2017/knowing-the-future/", "topic": "process"} {"rowid": 198, "title": "Is Your Website Accidentally Sexist?", "contents": "Women make up 51% of the world\u2019s population. More importantly, women make 85% of all purchasing decisions about consumer goods, 75% of the decisions about buying new homes, and 81% of decisions about groceries. The chances are, you want your website to be as attractive to women as it is to men. But we are all steeped in a male-dominated culture that subtly influences the design and content decisions we make, and some of those decisions can result in a website that isn\u2019t as welcoming to women as it could be. \nTypography tells a story\nStudies show that we make consistent judgements about whether a typeface is masculine or feminine: Masculine typography has a square or geometric form with hard corners and edges, and is emphatically either blunt or spiky. Serif fonts are also considered masculine, as is bold type and capitals.\nFeminine typography favours slim lines, curling or flowing shapes with a lot of ornamentation and embellishment, and slanted letters. Sans-serif, cursive and script fonts are seen as feminine, as are lower case letters. \nThe effect can be so subtle that even choosing between bold and regular styles within a single font family can be enough to indicate masculinity or femininity.\nIf you want to appeal to both men and women, search for fonts that are gender neutral, or at least not too masculine. When you\u2019re choosing groups of fonts that need to work harmoniously together, consider which fonts you are prioritising in your design. Is the biggest word on the page in a masculine or feminine font? What about the smallest words? Is there an imbalance between the prominence of masculine and feminine fonts, and what does this imply? \nTypography is a language in and of itself, so be careful what you say with it. \nColour me unsurprised\nColour also has an obvious gender bias. We associate pinks and purples, especially in combination, with girls and women, and a soft pink has become especially strongly related to breast cancer awareness campaigns. On the other hand, pale blue is strongly associated with boys and men, despite the fact that pastels are usually thought of as more feminine. \nThese associations are getting stronger and stronger as more and more marketers use them to define products as \u201cfor girls\u201d and \u201cfor boys\u201d, setting expectations from an incredibly young age \u2014 children as young as four understand gender stereotypes. It should be obvious that using these highly gender-associated colours sends an incredibly strong message to your visitors about who you think your target audience is. If you want to appeal to both men and women, then avoid pinks and pale blues.\nBut men and women also have different colour preferences. Men tend to prefer intense primary colours and deeper colours (shades), and tolerate greys better, whilst women prefer pastels (tints). When choosing colours, consider not just the hue itself, but also tint, tone and shade.\nSlightly counterintuitively, everyone likes blue, but no one seems to particularly like brown or orange. \nA picture is worth a thousand words, or none\nStock photos are the quickest and easiest way to add a little humanity to your website, directly illustrating the kind of people you believe are in your audience. But the wrong photo can put a woman off before she\u2019s even read your text. \nA website about a retirement home will, for example, obviously include photos of older people, and a baby clothes retailer will obviously show photos of babies. But, in the latter case, should they also show only photographs of mothers with their children, or should they include fathers too? It\u2019s true that women take on the majority of childcare responsibilities, but that\u2019s a cultural holdover from a previous era, rather than some rule of law. We are seeing increasing number of stay at home dads as well as single dads, so showing only photographs of women both enforces the stereotype that only women can care, as well as marginalising male carers. \nEqually, featuring prominent photographs of women on sites about male-dominated topics such as science, technology or engineering help women feel welcomed and appreciated in those fields. Photos really do speak volumes, so make sure that you also represent other marginalised groups, especially ethnic groups. If people do not see themselves represented on your site, they are not going to engage with it as much as they might. \nAnother form of picture that we often ignore is the icon. When you do use icons, make sure that they are gender neutral. For example, avoid using a icon of a man to denote engineers, or of a woman to denote nurses. Avoid overly masculine or feminine metaphors, such as a hammer to denote DIY or a flower to denote gardens. Not only are these gendered, they\u2019re also trite and unappealing, so come up with more exciting and novel metaphors. \nUse gender-neutral language\nLast, but not least, be very careful in your use of gender in language. \nPronouns are an obvious pitfall. A lot of web content is written in the second person, using the cleary gender neutral \u2018you\u2019, but if you have to write in the third person, which uses \u2018she\u2019, \u2018he\u2019, \u2018it\u2019, and \u2018they\u2019, then be very careful which pronouns you use. The singular \u2018they\u2019 is becoming more widely acceptable, and is a useful gender-neutral option. If you must use generic \u2018he\u2019 and \u2018she\u2019, (as opposed to talking about a specific person), then vary the order that they come in, so don\u2019t always put the male pronoun first. \nWhen you are talking about people, make sure that you use the same level of formality for both men and women. The tendency is to refer to men by their surname and women by their first name so, for example, when people are talking about Ada Lovelace and Charles Babbage, they often talk about \u201cAda and Babbage\u201d, rather than \u201cLovelace and Babbage\u201d or \u201cAda and Charles\u201d. As a rule, it\u2019s best to use people\u2019s surnames in formal and semi-formal writing, and their first names only in very informal writing. \nIt\u2019s also very important to make sure that you respect people\u2019s honorifics, especially academic titles such as Dr or Professor, and that you use titles consistently. Studies show that women and people of colour are the most likely to have their honorifics dropped, which is not only disrespectful, it gives readers the idea that women and people of colour are less qualified than white men.\nIf you mention job titles, avoid old-fashioned gendered titles such as \u2018chairman\u2019, and instead look for a neutral version, like \u2018chair\u2019 or \u2018chairperson\u2019. Where neutral terms have strong gender associations, such as nurse or engineer, take special care that the surrounding text, especially pronouns, is diverse and/or neutral. Do not assume engineers are male and nurses female. \nMore subtle intimations of gender can be found in the descriptors people use. Military metaphors and phrases, out-sized claims, competitive words, and superlatives are masculine, such as \u2018ground-breaking\u2019, \u2018best\u2019, \u2018genius\u2019, \u2018world-beating\u2019, or \u2018killer\u2019. Excessive unnecessary factual detail is also very masculine. \nWomen tend to relate to more cooperative, non-competitive, future-focused, and warmer language, paired with more general information. Women\u2019s language includes word like \u2019global\u2019, \u2018responsive\u2019, \u2018support\u2019, \u2018include\u2019, \u2018engage\u2019 and \u2018imagine\u2019. Focus more on the kind of relationship you can build with your customers, how you can help make their lives easier, and less on your company or product\u2019s status. \nSmash the patriarchy, one assumption at a time\nWe\u2019re all brought up in a cultural stew that prioritises men\u2019s needs, feelings and assumptions over women\u2019s. This is the patriarchy, and it\u2019s been around for thousands of years. But given women\u2019s purchasing power, adhering to the patriarchy\u2019s norms is unlikely to be good for your business. If you want to tap into the female market, pay attention to the details of your design and content, and make sure that you\u2019re not inadvertently putting women off. A gender neutral website that designs away gender stereotypes will attract both men and women, expanding your market and helping your business flourish.", "year": "2017", "author": "Suw Charman-Anderson", "author_slug": "suwcharmananderson", "published": "2017-12-20T00:00:00+00:00", "url": "https://24ways.org/2017/is-your-website-accidentally-sexist/", "topic": "content"} {"rowid": 207, "title": "Want to Break Out of Comparison Syndrome? Do a Media Detox", "contents": "\u201cComparison is the thief of joy.\u201d\n\u2014Theodore Roosevelt\n\nI grew up in an environment of perpetual creativity and inventiveness. My father Dennis built and flew experimental aircraft as a hobby. During my entire childhood, there was an airplane fuselage in the garage instead of a car. My mother Deloria was a self-taught master artisan who could quickly acquire any skills that it took to work with fabric and weaving. She could sew any garment she desired, and was able to weave intricate wall hangings just by looking at a black and white photos in magazines. My older sister Diane blossomed into a consummate fine artist who drew portraits with uncanny likeness, painted murals, and studied art and architecture. In addition, she loved good food and had a genius for cooking and baking, which converged in her creating remarkable art pieces out of cake that were incredibly delicious to boot. Yes. This was the household in which I grew up.\nWhile there were countless positives to being surrounded by people who were compelled to create, there was also a downside to it. I incessantly compared myself to my parents and older sister and always found myself lacking.\nIt wasn\u2019t a fair comparison, but tell that to a sensitive kid who wanted to fit in to her family by being creative as well. From my early years throughout my teens, I convinced myself that I would never understand how to build an airplane or at least be as proficient with tools as my father, the aeronautical engineer. Even though my sister was six years older than I was, I lamented that I would never be as good a visual artist as she was. And I marveled at my mother\u2019s seemingly magical ability to make and tailor clothes and was certain that I would never attain her level of mastery.\nThis habit of comparing myself to others grew over the years, continuing to subtly and effectively undermine my sense of self. I had almost reached an uneasy truce with my comparison habit when social media happened.\nAs an early adopter of Twitter, I loved staying connected to people I met at tech conferences. However, as I began to realize my aspirations of being an author and a speaker, Twitter became a dreaded hall of mirrors where I only saw distorted reflections of my lack of achievement in other people\u2019s success. Every person announcing a publishing deal caused me to drown under waves of envy over the imagined size of her or his book advance as I struggled to pay my mortgage. Every announcement I read of someone speaking at a conference led to thoughts of, \u201cI wish I were speaking at that conference \u2013 I must not be good enough to be invited.\u201d Twitter was fertile ground for my Inner Critic to run rampant.\nOne day in 2011, my comparisons to people who I didn\u2019t even know rose to a fever pitch. I saw a series of tweets that sparked a wave of self-loathing so profound that I spent the day sobbing and despondent, as I chastised myself for being a failure. I had fallen into the deep pit of Comparison Syndrome, and to return to anything close to being productive took a day or two of painstakingly clawing my way out.\nComparison Syndrome Takes Deficiency Anxiety to Eleven\nDo any of these scenarios ring true?\n\nYou frequently feel like a failure when viewing the success of others.\nYou feel dispirited and paralyzed in moving forward with your own work because it will never measure up to what others have done.\nYou discount your ideas because you fear that they aren\u2019t as good as those of your colleagues or industry peers.\n\nAre you making yourself miserable by thinking thoughts like these?\n\n\u201cI\u2019m surrounded by people who are so good at what they do, how can I possibly measure up?\u201d\n\u201cCompared to my partner, my musical ability is childish \u2013 and music is no longer fun.\u201d\n\u201cWhy haven\u2019t I accomplished more by now? My peers are so much more successful than I am.\u201d\n\nUnenviable Envy\nMany people use the terms envy and jealousy interchangeably, but they are two distinct emotions. Jealousy is the fear of losing someone to a perceived rival: a threat to an important relationship and the parts of the self that are served by that relationship. Jealousy is always about the relationship between three people. Envy is wanting what another has because of a perceived shortcoming on your part. Envy is always based on a social comparison to another.1\nEnvy is a reaction to the feeling of lacking something. Envy always reflects something we feel about ourselves, about how we are somehow deficient in qualities, possessions, or success.2 It\u2019s based on a scarcity mentality: the idea that there is only so much to go around, and another person got something that should rightfully be yours.3\nA syndrome is a condition characterized by a set of associated symptoms. I call it Comparison Syndrome because a perceived deficiency of some sort \u2013 in talent, accomplishments, success, skills, etc. \u2013 is what initially sparks it. While at the beginning you may merely feel inadequate, the onset of the syndrome will bring additional symptoms. Lack of self-trust and feelings of low self-worth will fuel increased thoughts of not-enoughness and blindness to your unique brilliance. If left unchecked, Deficiency Anxieties can escalate to full-blown Comparison Syndrome: a form of the Inner Critic in which we experience despair from envy and define ourselves as failures in light of another\u2019s success.\nThe irony is that when we focus so much on what we lack, we can\u2019t see what we have in abundance that the other person doesn\u2019t have. And in doing so, we block what is our birthright: our creative expression. Envy shackles our creativity, keeps us trapped in place, and prevents forward movement. The Inner Critic in the form of Comparison Syndrome caused by envy blocks us from utilizing our gifts, seeing our path clearly, and reveling in our creative power.\nIn order to keep a grip on reality and not fall into the abyss of Comparison Syndrome, we\u2019ll quell the compulsion to compare before it happens: we will free the mental bandwidth to turn our focus inward so we can start to see ourselves clearly. \nBreak the Compulsion to Compare\n\n\u201cWhy compare yourself with others? No one in the entire world can do a better job of being you than you.\u201d\n\u2014 Krystal Volney, poet and author\n\nAt some point in time, many of us succumb to moments of feeling that we are lacking and comparing ourselves unfavorably to others. As social animals, much of our self-definition comes from comparison with others. This is how our personalities develop. We learn this behavior as children, and we grow up being compared to siblings, peers, and kids in the media. Because of this, the belief that somehow, someway, we aren\u2019t good enough becomes deeply ingrained. The problem is that whenever we deem ourselves to be \u201cless than,\u201d our self-esteem suffers. This creates a negative feedback loop where negative thoughts produce strong emotions that result in self-defeating behaviors that beget more negative thoughts.\nCouple this cycle with the messages we get from society that only \u201cgifted\u201d people are creative, and it\u2019s no wonder that many of us will fall down the rabbit hole of Comparison Syndrome like I did on that fated day while reading tweets. Comparing ourselves to others is worse than a zero-sum game, it\u2019s a negative-sum game. No one wins, our self-esteem deteriorates, and our creative spark dies out.\nWith effort, we can break the compulsion to compare and stop the decline into Comparison Syndrome by turning the focus of comparison inward to ourselves and appreciating who we\u2019ve become. But first, we need to remove some of the instances that trigger our comparisons in the first place.\nArrest: Stop the Triggers\n\n\u201cRight discipline consists, not in external compulsion, but in the habits of mind which lead spontaneously to desirable rather than undesirable activities.\u201d\n\u2014 Bertrand Russell, philosopher\n\nAfter my Twitter post meltdown, I knew had to make a change. While bolstering my sense of self was clearly a priority, I also knew that my ingrained comparison habit was too strong to resist and that I needed to instill discipline. I decided then and there to establish boundaries with social media.\nFirst, to maintain my sanity, I took this on as my mantra:\n\u201cI will not compare myself to strangers on the Internet or acquaintances on Facebook.\u201d\nIf you find yourself sliding down the slippery slope of social media comparison, you can do the same: repeat this mantra to yourself to help put on the brakes.\nSecond, in order to reduce my triggers, I stopped reading the tweets of the people I followed. However, I continued to be active on Twitter through sharing information, responding to mentions, crowdsourcing, and direct messaging people. It worked! The only time I\u2019d start to slip into darkness were the rare instances when I would break my rules and look at my Twitstream.\nBut we can do even more than calm ourselves with helpful mantras. Just like my example of modifying my use of Twitter, and more recently, of separating myself from Facebook, you can get some distance from the media that activates your comparison reflex and start creating the space for other habits that are more supportive to your being to take its place.\nCreative Dose: Trigger-free and Happy\nPurpose: To stop comparison triggers in their tracks\nMindfulness is a wonderful tool, but sometimes you have to get hardcore and do as much as you can to eliminate distractions so that you can first hear your own thoughts in order to know which ones you need to focus on.\nHere are four steps to becoming trigger-free and happier.\nStep 1: Make a List\nPay attention when you get the most triggered and hooked.\nIs it on Twitter, Facebook, Instagram, or Snapchat?\nIs it YouTube, TV shows, or magazines?\nMake list of your top triggers.\nMy primary trigger is:______________________________________\nMy second trigger is:______________________________________\nMy third trigger is:______________________________________\nNow that you have your list, you need to get an idea just how often you\u2019re getting triggered.\nStep 2: Monitor\nIt\u2019s easy to think that we should track our activity on the computer, but these days, it\u2019s no longer our computer use that is the culprit: most of us access social media and news from our phones. Fortunately, there are apps that will track the usage for both.\nSeeing just how much you consume media from either or both will show you how much of an accomplice the use of devices is to your comparison syndrome, and how much you need to modify your behavior accordingly.\nFor tracking both computer use and tablet use, this app works great:\n\nRescueTime.com tracks app usage and sends a productivity report at the end of the week via email.\n\nFor your phone, there are many for either platform.4 Although I recommend fully researching what is available and will work for you best, here are a few recommendations:\n\nFor both platforms: Offtime, Breakfree, Checky\nFor Android only: Flipd, AppDetox, QualityTime, Stay On Task\nFor iOS only: Moment\n\nInstall your app of choice, and see what you find. How much time are you spending on sites or apps that compel you to compare?\nStep 3: Just Say No\nNow that you know what your triggers are and how much you\u2019re exposing yourself to them, it\u2019s time to say No.\nPut yourself on a partial social media and/or media detox for a specified period of time; consider even going for a full media detox.5 I recommend starting with one month.\nTo help you to fully commit, I recommend writing this down and posting it where you can see it.\nI, ___________________, commit to avoiding my comparison triggers \nof ___________________, ___________________, and ___________________ \nfor the period of ___________________, \nstarting on ___________________ and ending on ___________________ .\nTo help you out, I\u2019ve created a social media detox commitment sheet for you.\nStep 4: Block\nWhen I decided to reduce my use of Twitter and Facebook to break my comparison habit, initially I tried to rely solely on self-discipline, which was only moderately successful. Then I realized that I could use the power of technology to help. Don\u2019t think you have to rely upon sheer willpower to block, or at least limit, your exposure to known triggers. If your primary access to the items that cause you to compare yourself to others is via computers and other digitalia, use these devices to help maintain your mental equilibrium.\nHere are some apps and browser extensions that you can use during your media detox to help keep yourself sane and stay away from sites that could throw you into a comparison tailspin.\nThese apps are installed onto your computer:\n\nRescueTime.com works on both computer and mobile devices, and does a lot more than just prevent you from going to sites that will ruin your concentration, it will also track your apps usage and give you a productivity report at the end of the week.\nFocus and SelfControl (Mac-only)\n\nTo go right to the source and prevent you from visiting sites through your browser, there are browser extensions.\nNot only can you put in the list of the URLs that are your points of weakness, but you can also usually set the times of the day you need the self-control the most.\n\nGoogle Chrome: StayFocusd, Strict Workflow, and Website Blocker\nFirefox: Idderall and Leechblock\nSafari: WasteNoTime and MindfulBrowsing\nEdge (or Explorer): Unfortunately, there are currently no website blocking extensions for these browsers.\n\nI currently use a browser extension to block me from using Facebook between 9:00am \u2013 6:00pm. It\u2019s been a boon for my sanity: I compare tons less. A bonus is that it\u2019s been terrific for my productivity as well. \nWhich tool will you use for your media detox time? Explore them all and then settle upon the one(s) that will work the best for you. Install it and put it to work.\nDespite the tool, you will still need to exercise discipline. Resist the urge to browse Instagram or Facebook while waiting for your morning train. You can do it!\nStep 5: Relax\nInstead of panicking from FOMO (Fear of Missing Out), take comfort from this thought: what you don\u2019t know won\u2019t affect you. Start embracing JOMO (Joy of Missing Out), and the process of rebuilding and maintaining your sanity.\nWhat will you do instead of consuming the media that compels you to\ncompare? Here are some ideas:\n\nRead a book \nGo for a walk \nHave dinner with a friend \nGo watch a movie \nLearn how to play the harmonica \nTake an improv class\n\nReally, you could do anything. And depending on how much of your time and attention you\u2019ve devoted to media, you could be recapturing a lot of lost moments, minutes, hours, and days.\nStep 6: Reconnect\nUse your recovered time and attention to focus on your life and reconnect with your true value-driven goals, higher aspirations, and activities that you\u2019ve always wanted to do.\n\nThis article is an excerpt from the book Banish Your Inner Critic by Denise Jacobs, and has been reprinted with permission. If you\u2019d like to read more, you can find the book on Amazon.\n\n\n\n\nShane Parrish, \u201cMental Model: Bias from Envy and Jealousy,\u201d Farnam Street, accessed February 9, 2017.\u00a0\u21a9\n\n\nParrish, \u201cMental Model: Bias from Envy and Jealousy.\u201d\u00a0\u21a9\n\n\nHenrik Edberg, \u201cHow to Overcome Envy: 5 Effective Tips,\u201d Practical Happiness Advice That Works | The Positivity Blog, accessed February 9, 2017.\u00a0\u21a9\n\n\nJeremy Golden, \u201c6 Apps to Stop Your Smartphone Addiction,\u201d Inc.com, accessed February 10, 2017.\u00a0\u21a9\n\n\nEmily Nickerson, \u201cHow to Silence the Voice of Doubt,\u201d The Muse, accessed February 8, 2017.\u00a0\u21a9", "year": "2017", "author": "Denise Jacobs", "author_slug": "denisejacobs", "published": "2017-12-19T00:00:00+00:00", "url": "https://24ways.org/2017/do-a-media-detox/", "topic": "process"} {"rowid": 197, "title": "Designing for Mobile Performance", "contents": "Last year, some colleagues at Google ran a research study titled \u201cThe Need for Mobile Speed\u201d to find out what the impact of performance and perception of speed had on the way people use the web on their mobile devices. \nThat\u2019s not a trivial distinction; when considering performance, how fast something feels is often more important than how fast it actually is. When dealing with sometimes underpowered mobile devices and slow mobile networks, designing experiences that feel fast is exceptionally important.\nOne of the most startling numbers we found in the study was that 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load.\nWe wanted to find out more, so following on from this study, we conducted research to define what the crucial elements of speed are. We took into consideration the user experience (UX), overall perception of speed, and how differing contexts the user finds themselves in can alter how fast a user thinks something loaded.\nTo understand speed and load times first we must understand that user mobile web behaviour is broken down into three buckets;\n\nIntention\nLocation\nState of mind\n\nLet\u2019s look at each of those in turn.\nIntention\nUsers browse sites on a mobile device for many different reasons. To be able to effectively design a performant user experience for them, it\u2019s important to understand what those reasons might be. When asked to describe their reason for visiting a site, approximately 30% of people asked by the study claimed that they were simply browsing without a particular purpose in mind. Looking deeper, we found that this number increased slightly (34%) for retail sites. 30% said they were just there to find out some information for a future task or action, such as booking a flight.\nInterestingly, the research shows that users are actually window shopping using their mobile browser. Only 29% actually said they had a specific goal or intent in mind, and this number increases significantly for financial services like banking sites (57%). This goes against a traditionally held view of users wanting to perform simple actions efficiently on their mobile device. Sure, some users are absolutely doing that, but many are just browsing around without a goal in mind, just like they would on a desktop browser.\nThis gives great insight into the user\u2019s intentions. It tells us that users are actively using sites on their mobile, but a large majority do not intend to do anything instantly. There\u2019s no goal they\u2019re under pressure to achieve. If a site\u2019s performance is lousy or janky, this will only reaffirm to the user to that they can hold off on completing a task, so they might just give up. \nHowever, if a site is quick to load, sophisticated in expressing its value proposition quickly, and enables the user to perform their actions seamlessly, then turning that \u201cbrowsing user\u201d into a \u201cbuying user\u201d becomes all that much easier. When the user has no goal, there\u2019s more opportunity to convert, and you stand a greater chance of doing that if the performance is good enough so they stick around.\nLocation\nObviously, mobile devices by their nature can be used in many different locations. This is an interesting consideration, because it\u2019s not something we traditionally need to take into account designing experiences for static platforms like desktop computers.\nThe in the study, we found that 82% of users browse the web on their mobile phone while in their home. In contrast, only 7% do the same while at work. This might come across as a bit of a shock, but when you look at mobile usage \u2013 in particular app usage \u2013 most of the apps being used are either a social network or some sort of entertainment or media app. Due to the unreliability of network connections, users will often alternate between these two types of apps.\nThe consequence being that if a site doesn\u2019t work offline, or otherwise compensate for bad network connectivity in some way by providing opportunities to allow users to browse their site, then it becomes a self-fulfilling prophecy as to why users mostly view the mobile web from the comfort of their homes where there is a strong WiFi connection. They\u2019re using mobile devices, but they\u2019re not actually mobile themselves.\nAnother thing to bear in mind is how users alternate between devices, a study by comScore found that 80% of transactions take place on desktop while 69% of the browsing takes place on mobile. Any given user might access from more than one location - they might visit one day from a bus queue on their phone, and then next day from a laptop at home.\nState of mind\nOne more thing we need to take into consideration is the user\u2019s state of mind. Whilst browsing at home, users tend to be more relaxed, and in the research 76% stated they were generally calmer at home. The user\u2019s state of mind can have quite a big impact on how they perceive things. The calmer they are, the quicker a site might appear to load. If the user is anxious and impatiently drumming their fingers on the table, things seem to take longer, and even a small wait can feel like an eternity.\nThis is quite key. Over 40% of sites take longer than 4 seconds to load for users who are are out and about and using a mobile data connection. Coupled with our perception, and amplified by a potentially less-than-calm state of mind, this can seem like an age.\nWhat does this all mean?\nI think we can all agree that users prefer strong, steady connections and comfort when completing transactions. It seems like common sense when we say it out loud. Recreating these feelings and sensations of comfort and predictability under all circumstances therefore becomes paramount. Equally, when asked in the study, users all claimed that speed was the most important factor impacting their mobile web usage. Over 40%, in fact, said it was the most important UX feature of a site, and nobody asked considered it to be of no importance at all.\n\nThe meaning of speed\nWhen it comes to performance, speed is measured in two ways \u2013 real speed; as measured on a clock, and perceived speed; how responsive an interaction feels. We can, of course, improve how quickly a site loads by simply making files smaller. Even then, the study showed that 32% of users felt a site can feel slow even when it loads in less than 4 seconds. This gets even worse when you look at it by age group, with 50% if young people (18-24 year olds) thinking a site was slower than it actually was. When you add to the mix that users think a site loaded faster when they are sitting compared to when they are standing up, then you are in a world of trouble if your site doesn\u2019t have any clear indicators to let the user know the loading state of you website or app.\nSo what can we do about this to improve our designs?\nHow to fix / hack user perception\nThere are some golden rules of speed, the first thing is hacking response time. If a page takes more than 3 seconds to load, you will certainly start to lose your users. However, if that slowness is part of a UX flow such as processing information, the user understands it might take a little time. Under those circumstances, a load time of under 5 seconds is acceptable, but even then, you should take caution. Anything above 8 seconds and you are in very real danger of losing your audience completely. \n\n\n\nLoad time\nUser impression\n\n\n\n\n200 ms\nFeels instant\n\n\n1 s\nFeels it is performing smoothly\n\n\n5 s\nPart of user flow\n\n\n8 s\nLose attention\n\n\n\nRemove the tap delay\nMobile browsers often use a 300-350ms delay between the triggering of the touchend and click events. This delay was added so the browser could determine if there was going to be a double-tap triggered or not, since double-tap is a common gesture used to zoom into text. This delay can have the side effect of making interactions feel laggy, and therefore giving the user the impression that the site is slow, even if it\u2019s their own browser causing the problem.\nFortunately there\u2019s a way to remove the delay. Add following in the of your page, and the delay no longer takes effect:\n\nYou can also use touch-action: manipulation in newer browsers to eliminate click delay. For old browsers, FastClick by FT Labs uses touch events to trigger clicks faster and remove the double-tap gesture.\nMake use of Skeleton Screens\nA skeleton layout is a wireframe version of your app that displays while content is being loaded. This demonstrates to the user that content is about to be loaded, giving the impression that something is happening more quickly than it really is. Consider also using a preloader UI as well, with a text label informing the user that the app is loading. One example would be to pulsate the wireframe content giving the app the feeling that it is alive and loading. This reassures the user that something is happening and helps prevent resubmissions or refreshes of your app. Razvan Caliman created a Codepen example of how to create this effect in purely CSS. \nOne thing to consider though, if data doesn\u2019t load then you might need to create a fallback 404 or error page to let the user know what happened. \n\nExample by Owen-Campbell Moore\nResponsive Touch Feedback\nCarefully designing the process by which items load is one aspect of increasing the perceived speed of your page, but reassuring the user that an action they have taken is in process is another. At Google we use something called a Ripple, which is is animating dot that expands or ripples in order to confirm to the user that their input has been triggered. This happens immediately, expanding outward from the point of touch. This reaffirms to the user that their input has been received and is being acted on, even before the site has had a chance to process or respond to the action. From the user\u2019s point of view, they\u2019ve tapped and the page has responded immediately, so it feels really quick and satisfying.\nYou can mimic this same behavior using our Material Design Components Web GitHub repo.\n\nProgress bars\nThese UI elements have existed for a very long time, but research conducted by Chris Harrison and published in New Scientist found that the style of a progress bar can alter the perception of speed drastically. As a matter of fact, progress bars with ripples that animate towards the left appear like they are loading faster by at least 11% percent. So when including them in your site, take into consideration that ripples and progress bars that pulsate faster as they get to the end will make your sites seem quicker.\n\n \n \n Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations\nNavigation\nThe speed with which a user can locate navigational items or call to actions adds to their perceived performance of a site. If the user\u2019s next action is quick to spot on the screen, they don\u2019t spend time hunting around the interface with their eyes and fingers. So no matter how quickly your code runs, hiding items behind a nav bar will make a site feel slower than it actually is. \nFacebook found that switching to using bottom navigation saw an increase in engagement, satisfaction, revenue, speed, and importantly, perception of speed. If the user sees the navigation items they\u2019re looking for quickly, the interaction feels fast. What\u2019s more, end-to-end task completion is quicker too, as the interface not only feels quicker, but actually measures quicker as well. Similar reactions were found with Spotify and Redbooth.\nLuke Wroblewski gave a talk last year in Ireland titled \u201cObvious Always Wins\u201d which he demonstrated through the work he did with Google+. Luke\u2019s message is that by making the core features of your app obvious to your user, you will see engagement go up. This again seems obvious, right? However, it is important to note that adding bottom navigation doesn\u2019t just mean a black bar at the bottom of your screen like some kind of performance magic bullet. The goal is to make the items clear to the user so they know what they need to be doing, and how you achieve that could be different from one interface to the next. Google keeps experimenting with different navigation styles, but finally settled with the below when they conducted user research and testing.\n\nConclusion\nBy utilizing a collection of UI patterns and speed optimisation techniques, you can improve not only the actual speed of a site, but the perception of how quickly a user thinks your site is loading. It is critical to remember that users will not always be using your site in a calm and relaxed manner and that even their age can impact how they will use or not use your site. By improving your site\u2019s stability, you increase the likelihood of positive user engagement and task completion.\nYou can learn more about techniques to hack user perception and improve user speed by taking a look at an E-Book we published with Awwwards.com called Speed Matters: Design for Mobile Performance.", "year": "2017", "author": "Mustafa Kurtuldu", "author_slug": "mustafakurtuldu", "published": "2017-12-18T00:00:00+00:00", "url": "https://24ways.org/2017/designing-for-mobile-performance/", "topic": "ux"} {"rowid": 209, "title": "Feeding the Audio Graph", "contents": "In 2004, I was given an iPod.\nI count this as one of the most intuitive pieces of technology I\u2019ve ever owned. It wasn\u2019t because of the the snazzy (colour!) menus or circular touchpad. I loved how smoothly it fitted into my life. I could plug in my headphones and listen to music while I was walking around town. Then when I got home, I could plug it into an amplifier and carry on listening there.\nThere was no faff. It didn\u2019t matter if I could find my favourite mix tape, or if my WiFi was flakey - it was all just there.\nNowadays, when I\u2019m trying to pair my phone with some Bluetooth speakers, or can\u2019t find my USB-to-headphone jack, or even access any music because I don\u2019t have cellular reception; I really miss this simplicity.\nThe Web Audio API\nI think the Web Audio API feels kind of like my iPod did.\nIt\u2019s different from most browser APIs - rather than throwing around data, or updating DOM elements - you plug together a graph of audio nodes, which the browser uses to generate, process, and play sounds.\nThe thing I like about it is that you can totally plug it into whatever you want, and it\u2019ll mostly just work.\nSo, let\u2019s get started. First of all we want an audio source.\n