Subscribe: A List Apart
http://alistapart.com/rss.xml
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
clients  content  data  design  grid  it’s  make  much  new  people  performance  site  time  user  users  web  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: A List Apart

A List Apart: The Full Feed



Articles for people who make web sites.



Published: 2017-07-10T04:01:00+00:00

 



This week's sponsor: ​Jamf Now

2017-07-10T04:01:00+00:00

JAMF NOW is an on-demand mobile device management solution for your Apple devices at work. Get started for free today!

(image)



Team Conflict: Four Ways to Deflate the Discord that’s Killing Your Team

2017-06-27T14:00:00+00:00

It was supposed to be a simple web project. Our client needed a site that would allow users to create, deploy and review survey results. Aside from some APIs that weren’t done, I wasn’t very worried about the project. I was surprised that my product manager was spending so much time at the client’s office. Then, she explained the problem. It seemed that the leaders of product, UX and engineering didn’t speak to each other and, as a result, she had to walk from office to office getting information and decisions. When two people have a bad interaction, they can work it out or let the conflict grow, spreading it to other team members and their leaders. The conflicts probably started small. One bad interaction, then another, then people don’t like each other, then teams don’t work together well. The small scrape becomes a festering wound that slows things down, limits creativity and lowers morale. Somehow as a kid working my way through school I discovered I had a knack for getting around individuals or groups that were fighting with each other. I simply figured out who I needed to help me accomplish a task, and I learned how to convince, cajole or charm them into doing it. I went on to teach these skills to my teams. That sufficed for a while. But as I became a department head and an adviser to my clients, I realized it’s not enough to make it work. I needed to learn how to make it better. I needed to find a way to stop the infighting I’ve seen plague organizations my entire career. I needed to put aside my tendency to make the quick fix and have hard conversations. It’s messy, awkward and hard for team leaders to resolve conflict but the results are absolutely worth it. You don’t need a big training program, a touchy-feely retreat or an expensive consultant. Team members or team leads don’t have to like each other. What they have to do is find common ground, a measure of respect for one another, and a willingness to work together to benefit the project. Here are four ways to approach the problem. Start talking No matter how it looks at first, it’s always a people problem. Gerald M. Weinberg, The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully Resist the urge to wait for the perfect time to address team conflict. There’s no such thing. There will always be another deadline, another rollout, another challenge to be met. In our office, a UX designer and product manager were having trouble getting along. Rather than take responsibility, they each blamed our “process” and said we needed to clarify roles and procedures. In other words, they each wanted to be deemed “in charge” of the project. Certainly I could have taken that bullet and begun a full-on assessment of our processes and structure. By taking the blame for a bad company framework, I could have dodged some difficult conversations.  But I knew our process wasn’t the problem. First, I coached the product manager to be vulnerable, not an easy thing for him to do. I asked him to share his concerns and his desire to have a more productive relationship with the UX designer. The PM’s willingness to be uncomfortable and open about his concerns lifted the tension. Once he acknowledged the elephant in the room—namely that the UX designer was not happy working with him—the designer became more willing to risk being honest. Eventually, they were able to find a solution to their disagreements on the project, largely because they were willing to give each other a measure of respect. The worst thing I’ve seen is when leaders move people from team to team hoping that they will magically find a group of people that work well together, and work well with them. Sometimes the relocated team members have no idea that their behavior or performance isn’t acceptable. Instead of solving the problem, this just spreads the dissatisfaction. Instead, be clear right from the beginning that you want teams that will be open about challenges, feel safe discuss[...]



Color Accessibility Workflows

2017-06-06T14:00:00+00:00

A note from the editors: We’re pleased to share an excerpt from Chapter 3 of Geri Coady's new book, Color Accessibility Workflows, available now from A Book Apart.The Web Content Accessibility Guidelines (WCAG) 2.0 contain recommendations from the World Wide Web Consortium (W3C) for making the web more accessible to users with disabilities, including color blindness and other vision deficiencies. There are three levels of conformance defined in WCAG 2.0, from lowest to highest: A, AA, and AAA. For text and images of text, AA is the minimum level that must be met. AA compliance requires text and images of text to have a minimum color contrast ratio of 4.5:1. In other words, the lighter color in a pair must have four-and-a-half times as much luminance (an indicator of how bright a color will appear) as the darker color. This contrast ratio is calculated to include people with moderately low vision who don’t need to rely on contrast-enhancing assistive technology, as well as people with color deficiencies. It’s meant to compensate for the loss in contrast sensitivity often experienced by users with 20/40 vision, which is half of normal 20/20 vision. Level AAA compliance requires a contrast ratio of 7:1, which provides compensation for users with 20/80 vision, or a quarter of normal 20/20 vision. People who have a degree of vision loss more than 20/80 generally require assistive technologies with contrast enhancement and magnification capabilities. Text that acts as pure decoration, nonessential text that appears in part of a photograph, and images of company logos do not strictly need to adhere to these rules. Nonessential or decorative text is, by definition, not essential to understanding a page’s content. Logos and wordmarks may contain textual elements that are essential to broadcasting the company’s visual identity, but not to conveying important information. If necessary, the logo may be described by using an alt attribute for the benefit of a person using screen-reader software. To learn more, check out accessibility specialist Julie Grundy’s blog post on Simply Accessible, where she goes into the best practices around describing alt attributes. Text size plays a big role in determining how much contrast is required. Gray text with an RGB value of (150,150,150) on a pure white background passes the AA level of compliance, as long as it’s used in headlines above 18 points. Gray text with an RGB value of (110,110,110) passes the AA level at any text size, and will be AAA compliant if used as a headline above 18 points (Fig 3.1). A font displayed at 14 points may have a different level of legibility compared to another font at 14 points due to the wide diversity of type styles, so keep this in mind, especially when using very thin weights. Fig 3.1: Text size also plays a role when calculating compliance ratios. Personally, I recommend that all body text be AAA compliant, with larger headlines and less important copy meeting AA compliance as a bare minimum. Keep in mind that these ratios refer to solid-colored text over solid-colored backgrounds, where a single color value can be measured. Overlaying text on a gradient, pattern, or photograph may require a higher contrast value or alternative placement, such as over a solid-colored strip, to provide sufficient legibility. These compliance ratios are often what folks mean when they claim that achieving accessible design by “ticking off boxes” can only come at the cost of stifled creativity or restricted color choices. But that simply isn’t true. Experimentation with a color-contrast checker proves that many compliance ratios are quite reasonable and easy to achieve—especially if you are aware of the rules from the beginning. It would be much more frustrating to try to shift poor color choices into something compliant later in the design process, after branding colors have already been chosen. If you fight your battles up front, you’ll find you won’t feel restricted at all. I[...]



The Mindfulness of a Manual Performance Audit

2017-05-30T14:00:00+00:00

As product owners or developers, we probably have a good handle on which core assets we need to make a website work. But rarely is that the whole picture. How well do we know every last thing that loads on our sites? An occasional web performance audit, done by hand, does make us aware of every last thing. What’s so great about that? Well, for starters, the process increases our mindfulness of what we are actually asking of our users. Furthermore, a bit of spreadsheet wizardry lets us shape our findings in a way that has more meaning for stakeholders. It allows us to speak to our web performance in terms of purpose, like so: Want to be able to make something like that? Follow along. Wait, don’t we have computers for this sort of thing? A manual audit may seem like pointless drudgery. Why do this by hand? Can’t we automate this somehow? That’s the whole point. We want to achieve mindfulness—not automate everything away. When we take the time to consider each and every thing that loads on a page, we get a truer picture of our work. It takes a human mind to look at every asset on a page and assign it a purpose. This in turn allows us to shape our data in such a way that it means something to people who don’t know what acronyms like CSS or WOFF mean. Besides, who doesn’t like a nice pie chart? Here’s the process, step by step: Get your performance data in a malleable format. Extract the information necessary. Go item by item, assigning each asset request a purpose. Calculate totals, and modify data into easily understood units. Make fancy pie charts. The audit may take half an hour to an hour the first time you do it this way, but with practice you’ll be able to do it in a few minutes. Let’s go! Gathering your performance data To get started, figure out what URL you want to evaluate. Look at your analytics and try to determine which page type is your most popular. Don’t just default to your home page. For instance, if you have a news site, articles are probably your most popular page type. If you’re analyzing a single-page app, determine what the most commonly accessed view is. You need to get your network activity at that URL into a CSV/spreadsheet format. In my experience, the easiest way to do this is to use WebPagetest, whose premise is simple: give it a URL, and it will do an assessment that tries to measure perceived performance. Head over to WebPagetest and pop your URL in the big field on the homepage. However, before running the test, open the Advanced Settings panel. Make sure you’re only running one test, and set Repeat View to First View Only. This will ensure that you don’t have duplicate requests in your data. Now, let the test run—hit the big “Start Test” button. Once you have a results page, click the link in the top right corner that says “Raw object data”. A CSV file will download with your network requests set out in a spreadsheet that you can manipulate. Navigating & scrubbing the data Now, open the CSV file in your favorite spreadsheet editor: Excel, Numbers, or (my personal favorite) Google Sheets. The rest of this article will be written with Google Sheets in mind, though a similar result is certainly possible with other spreadsheet programs. At first it will probably seem like this file contains an unwieldy amount of information, but we’re only interested in a small amount of this data. These are the three columns we care about: Host (column F) URL (column G) Object Size (column N) The other columns you can just ignore, hide, or delete. Or even better: select those three columns, copy them, and paste them into a new spreadsheet. Auditing each asset request With your pared-down spreadsheet, insert a new first column and label it “Purpose”. You can also include a Description/Comment column, if you wish. Next, go down each row, line by line, and assign each asset request a purpose. I suggest something like the following: Content (e.g., [...]



Web Maintainability Industry Survey: How Do We Maintain?

2017-05-16T16:05:00+00:00

A note from the editors: As a community, we can learn so much from discovering what other developers are doing around the world. We encourage everyone to participate in this very brief survey created by Jens Oliver Meiert. Jens will share the results—and an updated guide to web maintainability based on the findings—in a few weeks.

How often do we consider the maintenance and general maintainability of our websites and apps? What steps do we actively take to make and keep them maintainable? What stands in the way when we maintain our and other people’s projects?

Many of us, as web developers, know very well how to code something. But whether we know just as well how to maintain what we—and others—have written, that is not so clear. Our bosses and clients may not always think about maintenance down the road, either.

As an O’Reilly author and former Googler, I’ve been studying the topic of maintainability since 2008—and we have yet to gather our industry’s views on the subject. To help us all get a better picture of how we maintain and how we can maintain more effectively, I set up a brief, unassuming survey (announcement) and kindly ask for your assistance.

The survey aims to collect specific practices and resources—in other words, your views on current practices (both useful and harmful) and everything you find helpful:

  • What helps maintenance?
  • What prevents maintenance?
  • What resources do developers turn to for improving maintainability?

The outcome of the survey and an updated guide to web maintainability will be published in a few weeks on my website, meiert.com (and noted on my Twitter profile). Thank you for your support.

(image)



Fait Accompli: Agentive Tech Is Here

2017-05-09T14:00:00+00:00

A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Chris Noessel's new book, Designing Agentive Technology, AI That Works for People, available now from Rosenfeld Media. For a limited time, ALA readers can get 20% off Chris's book by using the code 'ALADAT' on the Rosenfeld Media site.Similar to intelligence, agency can be thought of as a spectrum. Some things are more agentive than others. Is a hammer agentive? No. I mean if you want to be indulgently philosophical, you could propose that the metal head is acting on the nail per request by the rich gestural command the user provides to the handle. But the fact that it’s always available to the user’s hand during the task means it’s a tool—that is, part of the user’s attention and ongoing effort. Less philosophically, is an internet search an example of an agent? Certainly the user states a need, and the software rummages through its internal model of the internet to retrieve likely matches. This direct cause-and-effect means that it’s more like the hammer with its practically instantaneous cause-and-effect. Still a tool. But as you saw before, when Google lets you save that search, such that it sits out there, letting you pay attention to other things, and lets you know when new results come in, now you’re talking about something that is much more clearly acting on behalf of its user in a way that is distinct from a tool. It handles tasks so that you can use your limited attention on something else. So this part of “acting on your behalf”—that it does its thing while out of sight and out of mind—is foundational to the notion of what an agent is, why it’s new, and why it’s valuable. It can help you track something you would find tedious, like a particular moment in time, or a special kind of activity on the internet, or security events on a computer network. To do any of that, an agent must monitor some stream of data. It could be something as simple as the date and time, or a temperature reading from a thermometer, or it could be something unbelievably complicated, like watching for changes in the contents of the internet. It could be data that is continuous, like wind speed, or irregular, like incoming photos. As it watches this data stream, it looks for triggers and then runs over some rules and exceptions to determine if and how it should act. Most agents work indefinitely, although they could be set to run for a particular length of time or when any other condition is met. Some agents like a spam filter will just keep doing their job quietly in the background. Others will keep going until they need your attention, and some will need to tell you right away. Nearly all will let you monitor them and the data stream, so you can check up on how they’re doing and see if you need to adjust your instructions. So those are the basics. Agentive technology watches a datastream for triggers and then responds with narrow artificial intelligence to help its user accomplish some goal. In a phrase, it’s a persistent, background assistant. If those are the basics, there are a few advanced features that a sophisticated agent might have. It might infer what you want without your having to tell it explicitly. It might adapt machine learning methods to refine its predictive models. It might gently fade away in smart ways such that the user gains competence. You’ll learn about these in Part II, “Doing,” of this book, but for now it’s enough to know that agents can be much smarter than the basic definition we’ve established here. How Different Are Agents? Since most of the design and development process has been built around building good tools, it’s instructive to compare and contrast them to good agents—because they are different in significant ways. Table 2.1: Comparing Mental Models A Tool-Based Model An Agent-Based Model A good tool lets you do a task well. A[...]



User Research When You Can’t Talk to Your Users

2017-05-02T14:00:00+00:00

It’s not breaking news to say that the core of UX, in a vacuum, is talking to your users to gather insights and then applying that information to your designs. But it’s equally true that UX does not happen in a vacuum. So what happens when you don’t have the budget or the timeline to run user tests, card sorts, or stakeholder interviews? What should you do when your company doesn’t want you bothering the paying customers who use their software? In short, how do you do UX research when you can’t get direct access to your users? While the best methods for gathering user insights entail first-hand research, there are other ways to quickly glean qualitative data about your users’ wants and needs—beyond the usual lightweight guerrilla user testing options. For a start, companies that are new or have a smaller digital footprint can benefit from things like forums or even competitor reviews to get a better sense of the users in their industry vertical. And for more established companies, customer service logs and app reviews can be invaluable for learning what users think about specific products. Let’s check out a few techniques I like to recommend. App reviews When products have a mobile app component, I start looking at reviews posted on the App Store or Google Play. The key, in terms of user research, is to focus on the substance of what the user is saying, as opposed to the rating (i.e., one star to five stars). For instance: Is the user simply disgruntled or are they asking for a tangible feature to be added to the product? Is the user truly thrilled with some aspect of her experience using the app or is she just a brand loyalist? While reviews do tend to be rather partisan, keep in mind that users are most likely to leave feedback when motivated by an emotional reaction to the product. Emotionally-driven reviews—whether positive or negative—tend to be outliers on the bell curve, so the next step is taking all those reviews and distilling them into tangible insights. Let’s face it, when you want to improve the featureset and functionality, a general reaction to the entirety of an app doesn’t tend to be particularly actionable. Here are a few questions I always start with: Are there missing features users want to see? Do users seem confused by aspects of the UI? Are they complaining about bugs or performance issues that are popping up and making the app unusable? Do people really love a hidden feature that was put in as an afterthought with minimal prominence—something we should consider placing more front and center? Does it seem like people understand how to use the app or do they need a tutorial on first open? Also, it’s important to remember that feedback on an iOS app may or may not be applicable to an Android app (or mobile web experience), and vice versa. Customer service logs Customer service and help center personnel are on the front lines with your users, helping them with specific struggles they encounter with the usability of your products. In other words, they’re constantly learning how users see the product and go about using it. Since user information can be sensitive, the first thing to try is asking whether service calls and contacts are being logged. If so, ask whether it’s possible to get access to the records for user research purposes. If there are no logs, or if you are unable to get access to them, see if a few brief stakeholder interviews with customer service team members is an option. Use the interviews to learn which types of problems and complaints they routinely field. Given the nature of customer service and the purpose of help centers, it’s likely that much of the feedback will be negative. Even so, these logs can still provide excellent data. In particular, the feedback can help illuminate policies and business practices that are creating a negative user experience[...]



Focus on What You Do Best and Outsource the Rest

2017-04-18T14:00:00+00:00

With consumer expectations growing year after year, high quality web design and development services are in top demand. If you want to be the one to deliver those high-end results, then you’ll need to focus on playing to your strengths and be comfortable entrusting everything else to others. Like many of us, you’re probably so occupied by managing the day-to-day and maintaining the base of clients you currently have that you don’t have the time or resources to build your web design or development business out to the next level. Why “no pain, no gain” has no place in web design One of the greatest lessons I’ve learned from working as a project and content manager is that there are times when it just doesn’t make sense to take on a task or project that’s not a good fit. For instance: I’ve seen developers struggle with marketing their business when they barely have enough time to complete their own workload. I’ve seen web designers hire on supplemental designers (such as video designers and animators), only to lose those new hires just as quickly as they got them because they couldn’t manage the payroll aspect properly. I’ve even seen administrative assistants given the responsibility of loading content into a CMS and, on top of that, being asked to optimize it for search despite a lack of training. While I’ve seen this problem crop up with management of medium and large-sized businesses, I think it’s much more prevalent with small business owners and independent entrepreneurs. When you think about how much of your life (personally and professionally) is wrapped up in your business, it seems to make sense to think that by consolidating tasks, cutting corners, or just taking it all on yourself, you’ll save money and time. Here’s the problem with that sort of thinking: it’s a dangerous and highly inefficient way to conduct business when you work in web design. No matter the size of our business, we rely on proven processes and techniques to ensure that what we create is always of the highest quality. Let’s face it, we are specialists, and diluting our offering by trying to do everything isn’t fair to our clients or ourselves. My suggestion? Let more qualified people or tools tackle the “stuff” that forces you to slow down, lose productivity, and create something less than what your clients deserve. Sure, it’s scary to think about how much it will cost to outsource your accounting, your SEO, or anything else that isn’t in your wheelhouse. But think about how much momentum and overall quality of work you lose whenever you let that fear take over. I say: focus on what you do best, outsource the rest, and be happily surprised when you see how much your business soars as a result.Follow your strengths In a recent interview about the cost of doing business, Jeremy Goldman of the Firebrand Group argued that in order for business owners (or any entrepreneurs really) to succeed, they must be willing to accept when they’re not great at something. Once you accept that you’re a bad fit for some tasks, you leave yourself more time to pursue the tasks you’re good at (or want to get better at). Outsourcing may result in additional costs upfront, but if you’re handing those tasks over to someone or something that can handle them more efficiently, I’d argue that you’ll save money in the long run. First, because the outsourced party will spend less time completing a task than it would have taken you. And second, because the investment frees you up to succeed at what you do, which, in turn, is where the real revenue-generating opportunities are. The key to embracing this is through understanding your operations thoroughly, so you know what can be streamlined or outsourced. Start with an assessment of where your business currently is and where you want it to go. This will tell yo[...]



Widen Out: Using Your Blog to Attract New Clients

2017-04-04T14:00:00+00:00

Attracting future clients on autopilot—that’s the whole point of your website, right? Most freelancers accept the story that great work attracts leads, but I’m going to be straight with you: clients have no clue you exist. What usually tips the balance isn’t your portfolio—they see plenty of those. Not many people talk about failures they had promoting their products and services. We struggle and we hide it. It’s one of the reasons I hate to read marketing “success stories” and “How to drive traffic and make money!” posts—they seem hollow and vaguely manipulative. They also invariably circle around an answer we already know: The key to attracting non-referral clients is making it easy for them to discover you. Simple as that is, we fail for two reasons: Most freelancer websites are only concerned with showing portfolio work. We haven’t figured out who we want as clients, what makes them tick, or how they solve problems. We’re focused on showing, not serving. Serving hits the ground running—it answers a question, solves a problem, satisfies a curiosity. There’s a difference between saying you will and proving it with a real takeaway during the first impression. Portfolio-focused sites also don’t give Google much content to index and rank, lessening your chances of ever getting high in organic search results, much less on their radar. Designers are “supposed” to do certain things to find clients. Well, I did all that, for years. And I had a pretty depressing success rate, considering how much time I put into it. Then I tried one thing that single-handedly turned around my freelance career. I started blogging with clients in mind. Do it your way Let me tell you about Brian Dean. Brian Dean of Backlinko gets 130,000 monthly uniques. Want know how many articles he has on his blog—in total? 30. That’s right, 30. Readers aren’t coming because he publishes frequently—they’re coming because he writes about what they want to know and because every piece he’s got is the best on that given subject, hands down! He keeps visitors coming back to the same posts because he’s constantly improving the material little by little to ensure it’s always the best that’s out there. As people come across it—web professionals, curious readers, and potential clients—it’s building up his reputation and making it easier for people to find him via search and re-shared content links. You don’t have to write regularly. Or much. And you don’t need an industry-rocking idea. With your expertise, you have what it takes to say something that other people consider valuable. The key to success is making a target, then sticking it out for a few rounds of research + content creation + promotion to start. The more posts/articles you create, the more properties you have on the Monopoly board called Google. Having a few widely shared articles also kicks off a virtuous loop where all your subsequent articles get a jump start from your existing traffic. This approach is repeatable and scaleable. (One quick heads-up: you can also expect your content to attract the “wrong type” of visitors, such as recruiters and people looking to hire someone for low-end, piecemeal work. It’s possible to turn these inquiries into opportunities by politely refusing their offer and asking if they know anyone who is seeking the type of work you do provide.) Pre-planning your content As you know, Google determines how high your page ranks for certain search terms based on factors like: Whether your page content is relevant to the search term How many other quality, relevant sites link to your page How well-made readers think your content is (i.e. how long do people spend reading your content). Translating that, your goals are to: Create content that is rele[...]



Practical CSS Grid: Adding Grid to an Existing Design

2017-03-23T17:30:00+00:00

Understanding and using CSS Grid is easier than you might expect. The day Grid support shipped in Firefox 52, I decided on the spur of the moment to convert the basic layout of my personal site to use Grid. And it was a fairly simple process—five minutes to write the grid styles, then 15-20 spent troubleshooting. Grid allows us to literally define column and row grid lines, and then attach elements to those lines in any order we choose. That may sound like tables, but Grid is so much more than tables ever dreamed.  It means more responsive layouts, far more accessible documents, and far cleaner markup than even floats and positioning ever afforded us. It’s been decades since CSS first emerged, but it’s never contained a system anything like this. And Grid is already supported in both Chrome and Firefox, with Safari coming soon (its Technology Preview releases support Grid as of this writing). A new era in digital design is dawning right now. The way things used to be Before we get to the Grid, allow me to take just a moment to explain the markup structure of meyerweb’s main pages, and the positioning-and-margins approach I’ve been using for, um, about 12 years now. Here’s how the markup is structured:
Some of those IDs are idiosyncratic holdovers from my early-2000s view of layout and naming conventions. #extra, for example, is what most of us would call #sidebar. #sitemast stands in for #masthead. And #footer is from the days before the actual
element The divs (which should probably be sections these days, but never mind that now) are arranged the way they are so that if the CSS fails to load, or a speaking browser is used to browse the site, then the site’s masthead is first, the ability to search the site is second, and the main content of the page is third. After that, extra materials, site navigation, and the footer follow. All of these were stitched together into a layout by absolutely positioning the navigate and search divs. The sitemast was set to be 192px tall, and both the navigate and search divs were given top: 192px; to show up just below it. In order to leave space for them to land, top margins were applied to the main and extra divs. (Fig. 1) Fig. 1: meyerweb’s home page (foreshortened)  Constructing the grid So that’s how things have been laid out since the middle of 2005, more or less. I fiddled with a flexbox layout at one point as an experiment, but never shipped it, because it felt clumsy to be using a one-dimensional layout tool to manage a two-dimensional layout. I probably should have converted the navigation bar to flexbox, but I got distracted by something else and never returned to the effort. Besides, Grid was coming. In the run-up to Grid support being released to the public, I was focused on learning and teaching Grid, creating test cases, and using it to build figures for publication. And then, March 7th, 2017, it shipped to the public in Firefox 52. I tweeted and posted an article and demo I’d put together the night before, and sat back in wonderment that the day had finally come to pass. After 20+ years of CSS, finally, a real layout system, a set of properties and values designed from the outset for that purpose. And then I decided, more or less in that moment, to convert my personal site to use Grid for its main-level layout. It took me less than five minutes to come up with the following: body { display: grid; grid-template-rows: 192px min-content min-content 1fr; grid-template-columns: 1fr 20[...]



This week's sponsor: HIRED

2017-03-20T22:07:00+00:00

HIRED, where companies apply to you. Over 6,000 innovative companies are looking for you on Hired. Get Hired today.

(image)



Practical Design Discovery

2017-03-09T15:00:00+00:00

A note from the editors: We’re pleased to share an excerpt from Chapter 3 of Dan Brown's new book, Practical Design Discovery, available now from A Book Apart.One of the hardest design problems I ever worked on was for a company that helps IT groups manage risk. Their product focused on open-source components—inexpensive and widely supported by an enormous community, but often vulnerable to security flaws. What made this design problem hard was the complexity of the product’s underlying structure, a triangle of interrelated abstract concepts. To work through the problem, we created a series of sketches that helped us understand it. The outcome ended up being a relatively simple prototype, a model of the overall structure of the application. Though we were chartered to create a detailed design, our client later admitted that they knew we wouldn’t get there, but that they highly valued our efforts to solve the underlying structure. Those efforts set the direction for everything else on the product. Direction-setting assertions Much like when we frame problems, we can make assertions that set direction and describe decisions about the design. These decisions will be pretty high-level, meaning they’ll deal with a holistic view of the site or product. Decisions about details come later, though you’ll see that some assertions get pretty specific as a way of clarifying and testing the direction. There are three kinds of assertions you can make about design direction: Principles define what the design should or shouldn’t do. These statements are grounded in research, and may be referred to as implications when you can tie them to research. Concepts establish an overall approach for the product, expressed as a central theme or idea. Models describe the product in an abstract way, showing the underlying architecture, structure, flow, or approach. They offer a sense of how the product will work (without actual functionality). If you try to make tactical decisions too early, you may set a precedent without understanding how it influences what comes next—it’s difficult to trace low-level decisions back to a specific objective or problem statement. Why is the button blue? There’s no project objective in the world that can justify such a decision. Instead, you’ll make a few low-level decisions alongside your assertions, using samples to illustrate, clarify, and demonstrate the application of the high-level decisions. For example, you might arrive at the design principle that the site’s tone should be friendly without being too casual or informal. You would demonstrate that through sample screen designs and content, showing messaging that says “Thanks!” instead of the too-formal “Thank you very much” or too-casual “You rock!” Exploring the big decisions through examples might encourage you to reconsider them, or to find places in the product experience that need variation. Perhaps the color palette is insufficient for everything you need, or the authoritative voice isn’t appropriate for certain pages. By venturing a solution, you’re not just asking, “Will this work?” You’re also asking, “Do I have enough knowledge to know whether this will work?” That is, steps toward solving the problem may trigger additional insights, or questions, about the problem. Great discovery entails providing just enough shape and definition so the team can get aligned behind them as direction for the product. Principles and implications Principles are rules that help designers evaluate their decisions about the design. They provide guidance in the form of absolute statements about what the design should or should not do. That said, no set of principles can be exhaustive. They read, sometimes, as comman[...]



Long-Term Design: Rewriting the Design Sales Pitch

2017-03-02T15:00:00+00:00

We run our client service businesses just like door-to-door salespeople hawking vacuum cleaners. That may seem unfair, but it’s exactly how we sell design. We’re focused on short-term wins—but we’re teaching clients to see our work as disposable. I want to believe we’re better than that. We spend our entire careers knocking on doors and shilling our services. It’s just how we do business. Even if a potential client’s old design is working just fine, we might go for the hard sell. But that’s damaging, both to us and to our clients. This practice perpetuates the idea that design is only valuable when new. Consider the salesperson’s pitch: Your [design/vacuum] is old. Other people have newer ones. You’re going to lose out if you don’t buy a new one. Your family/business might even be unsafe with your current one. We believe that being a designer requires cycling through clients and booking new projects. Instead of talking about dust or maneuverability around furniture legs, the designer’s pitch is more like this: Your current design is not allowing your brand to resonate in the marketplace. It looks dated, and your competitors all recently launched new branding. You could lose market share to competitors without a more modern design. Short-term engagements are bad for our clients We write articles in phenomenal publications like this one about how design isn’t just about aesthetics—design should be a fundamental part of how a business operates, conducts market research, and creates products and services. Design is powerful and important. So we preach the doctrine of Design Thinking. We work to improve accessibility and web standards for the good of all. We preach user advocacy. However, when we pitch design work to clients, so often we’re only selling the aesthetics. And, when we book the gig, we try to ship that design and get that final invoice paid so we can bring in the next client. We designers rarely stick around to see how well the design works. We begin each project with design thinking, but rarely maintain it. And because of that, each client goes shopping for another new design (or succumbs to the pitch of another designer) much sooner than they need to. Design requires time in order to deliver its full value. For example, when a new website launches, we can measure changes in analytics immediately. But that design also carries the potential for further improvements—enhancements that can be unlocked through A/B testing, analysis, and optimization. Unfortunately, the vast majority of sites are never optimized. They launch, sit for a year or two, then get replaced. Our clients aren’t getting the full return on their investments. And if you think about that even further, this “cycle of redesign” makes design less valuable. In other words, if design is only valuable when new, it isn’t very valuable in the first place. New, cheaper solutions are encroaching upon our profession, such as logo-designing software, theming algorithms, and drag & drop design tools. We fear we are being replaced by these alternatives or that the perceived value of design is decreasing. And in the next breath, we tell our clients “Let’s make a fresh, new design for you.” We can’t blame clients for trying affordable new options; we’re the ones who taught them to value “new” design in the first place. Cycling through clients is less lucrative Finding a constant stream of new clients takes a lot of effort and is a constant challenge for many designers and agencies. Freelancers spend countless hours crawling job boards and submitting their portfolios in hopes of getting hired. Agencies spend considerabl[...]



Big Data Visualization with Meaning

2017-02-23T15:00:00+00:00

The web is not the traditional home of data visualization. You might come across a bar chart here or there in your online journey on any given day, but they’ve never been an artifact of web history. It seems like that’s been changing. With the world becoming increasingly data-driven, we’re seeing more and more visualizations make their way onto our web pages and into our design briefs. They help us tell stories that better engage our users, and can even get them to take some kind of meaningful action. The problem is that these datasets—sometimes so large they’re literally called “big data”—can make visualization with meaning difficult. But that’s something we as designers are equipped to tackle. We just have to know what our users are hoping to gain from viewing and interacting with visualizations, and what we have to do to make their effort worthwhile. Data has a very strong power to persuade—powerful enough to change users’ everyday behavior, especially when data is informative, clear, and actionable. We should be putting data visualizations to work on our sites, enhancing our designs to show users how data is in service to the story they’ve come to learn about. Data visualization on the web can be meaningful through allowing people to discover the smaller stories that resonate with them, customizing their user experience instead of putting them on a predetermined path. Users attempting to interact with large and generally disconnected sets of data while navigating a site or trying to access relevant information end up facing a difficult, if not impossible, task. Our sites lose a certain measure of usability if they aren’t well-designed, even though the web is a natural medium for delivering truly interactive data.  As with all design, the approach we take when creating a user-minded visualization is based on the context and the constraints we have to work with. Good data visualizations—those with meaning—need to be accessible and human even though data is rarely described with those words. Telling a story The key to designing visualizations is to focus on something in the dataset that is relatable to and resonates with your users. I stumbled upon this while creating a visualization from the publicly available Open Food Facts dataset, which contains crowd-sourced information on food products from all over the world. Although the dataset covers an extensive range of information (even down to packaging materials and number of additives), I chose to focus on comparing average sugar consumption among different countries (Fig. 1) because I was personally concerned about that topic. It turned out to be a concern for others as well and became the most popular project for the dataset on Kaggle. Fig. 1: Average national sugar consumption Even though I didn’t make extensive use of the dataset in my rough and ugly visualization, what I chose to focus on told a story that resonated with people because most were from the countries listed or had a growing general awareness of high sugar consumption and its effect on health. In retrospect, what’s more personal and important than your health? Selecting data points that strengthen a story with a positive result (whether that’s eating less sugar or reducing large-scale chemical emissions) can be great, but it’s important to present a story that is as unbiased as possible and to make ethical decisions about which parts of the data we want to use while telling the story. But what exactly is a story in the context of a data visualization? We can’t kick it off with “once upon a time,” so we have to approach the idea in a different way. Whitney Quesenbery and Kevin Brook[...]



This week's sponsor: Hotjar

2017-02-20T05:01:00+00:00

Hotjar, see how your visitors are really using your site. Try it free.

(image)



I Don’t Need Help

2017-02-07T16:00:00+00:00

We have no excuse…admit it. UX may brag about intuitive and pretty, but we sure suck at helping people—this one thing that most defines, most embodies great user experience. Throughout history, there’s one recurring theme: people need help. For all we know, the need for assistance might have triggered the development of communication. It could have led to bonding among tribes and our existence today. In the future, it might be the only thing that staves off human extinction and promotes societal evolution. But if so, that begs the question: why do we find it so difficult to ask for help or offer guidance to one another? Do we prefer to figure things out for ourselves? Are we afraid that any request for assistance would be fraught with obligations to reciprocate? Are we worried that we’ll be rejected? Or that we might not get the help we need? People do need help. It’s a given—and a problem in the field of UX. We claim to do so much for users, but treat help as an afterthought. How come it isn’t our primary consideration? A glance at most websites, including those for large and small organizations, suggests that user assistance is treated as a cursory option—often relegated to a question mark symbol tacked onto a corner. The assumptions are: Users won’t need help; the design is intuitive. If users do want help, they’ll look for it (somewhere). Once users figure out where to look, they’ll seek help when they need it. If the same scenario were layered on real-world interactions, it would be analogous to visiting a large museum, with maps, tours, guides, and program schedules hidden in a locker at some end far off the main entrance. Why offer help before it’s requested? Taking the guesswork out of a customer’s experience is beneficial to all involved. Consider that you’re walking into a new casual diner. Initially you may wonder if everything is self-service, and if you are expected to clear your own table. You could just stare at folks around the room and make your move based on what other diners are doing. Or, the franchisee could help you get up to speed right away. Ikea solves the what-do-I-do problem with a “Why should I clear my own table?” sign right at the center of its popular store restaurant. The sign solves two problems—it gives the customer needed information immediately and it promotes Ikea’s aim to cut costs. Designers create user interfaces through careful planning, so one popular conclusion is that if a design has been a success, no explanation—no prominent sign—is required. But help is often sought or needed for a variety of reasons. Help could be required to explain certain fields in a form, to define the meaning of a specific icon, to parse highly technical terms, to identify new features, to illuminate hidden gestures, or to detail policies that are obtuse. A user may immediately understand that a pencil icon opens an editing pop-up. If he doesn’t, he may well figure it out eventually but only after moments wasted in confusion. No matter how smart a design is, unless it is customized to every user’s personality, needs, working conditions, device, domain knowledge, technical expertise, and mood, it will need some explaining. A good designer empathizes with unique concerns and takes users as they are, from practiced online mavens to casual browsers. A good design includes user assistance that is given due consideration.  When help goes wrong Sometimes websites do make dedicated attempts to help. And sometimes those attempts smack of overkill. There are video tours expertly created to take users [...]



This week's sponsor: Hired

2017-02-06T05:01:00+00:00

HIRED, where companies apply to you. Over 6,000 innovative companies are looking for you on Hired. Get Hired today.

(image)



Considering How We Use HTTP/2

2017-02-02T15:00:00+00:00

A note from the editors: This article is part two of a two-part series exploring the new HTTP/2 protocol and using it responsibly. Be sure to read part one, Using HTTP/2 Responsibly: Adapting for Users.It’s important to remember that HTTP/2-specific optimizations may become performance liabilities for HTTP/1 users. In the final part of this series, we’ll talk about the performance implications of such a strategy and how build tools can help you manage HTTP/1- and HTTP/2-specific assets. Our generalized example from the previous article shows how we can adapt delivery of site assets to a user’s connection. Now let’s see how this affects performance in the real world.Observing performance outcomes Developing a testing methodology Low speed mobile connections are quite common in the developing world. Out of curiosity, I wanted to simulate HTTP/1 and HTTP/2 scenarios with my own site on an actual low speed mobile connection. In a strangely fortuitous turn of events, I ran out of high speed mobile data the month I was planning to test. In lieu of extra charges, my provider simply throttles the connection speed to 2G. Perfect timing, so I tethered to my iPhone and got started. To gauge performance in any given scenario, you need a good testing methodology. I wanted to test three distinct scenarios: Site optimized for HTTP/2: This is the site’s default optimization strategy when served using HTTP/2. If the detected protocol is HTTP/2, a higher number of small, granular assets is served. Site not optimized for HTTP/1: This scenario occurs when HTTP/2 isn’t supported by the browser and when delivery of content isn’t adapted in accordance with those limitations. In other words, content and assets are optimized for HTTP/2 delivery, making them suboptimal for HTTP/1 users. Site optimized for HTTP/1: HTTP/2-incompatible browsers are provided with HTTP/1 optimizations after the content delivery strategy adapts to meet the browser’s limitations. The tool I selected for testing was sitespeed.io. sitespeed.io is a nifty command line tool—installable via Node’s package manager (npm)—that’s packed with options for automating performance testing. sitespeed.io collects various page performance metrics each time it finishes a session. To collect performance data in each scenario, I used the following command in the terminal window: sitespeed.io -b chrome -n 200 --browsertime.viewPort 320x480 -c native -d 1 -m 1 https://jeremywagner.me There are plenty of arguments here, but the gist is that I’m testing my site’s URL using Chrome. The test will be run 200 times for each of the three scenarios, and use a viewport size of 320x480. For a full list of sitespeed.io’s runtime options, check out their documentation. The test results We’re tracking three aspects of page performance: the total time it takes for the page to load, the amount of time it takes for the DOMContentLoaded event to fire on the client, and the amount of time it takes for the browser to begin painting the page. First, let’s look at total page load times for each scenario (Fig. 1). Fig. 1: Total Page Load Times test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios. This graph illustrates a trend that you’ll see later on. The scenarios optimized for HTTP/1 and HTTP/2 demonstrate similar levels of performance when running on their respective versions of the protocol. The slowest scenario runs on HTTP/1, yet has been optimized for HTTP/2. In these graphs, we’re plotting two figures: the average and the 95th percentile (m[...]



Using HTTP/2 Responsibly: Adapting for Users

2017-02-02T15:00:00+00:00

A note from the editors: This article is part one of a two-part series exploring the new HTTP/2 protocol and using it responsibly. Be sure to read part two, Considering How We Use HTTP/2.With HTTP/2 ticking up steadily in use, it’s clear that there’s something to this long overdue update to the protocol. Implementing it, however, not only changes how websites are delivered to the user, it demands that we think critically about how we migrate existing sites to the protocol. More importantly, it demands that we consider our users’ capabilities. Whether you’ve already migrated your site to HTTP/2 or you’re bracing yourself to take the plunge, there are challenges when it comes to tuning your site’s front end architecture to be the most performant it can possibly be for all your users. Perhaps you’ve read about what it takes to get your site ready for HTTP/2. Perhaps you haven’t. If the latter describes you best, it’s not worth getting into the weeds here. The gist of it is that HTTP/2 optimization patterns are the opposite of those for HTTP/1. Your site will perform better on HTTP/2 if you avoid practices that combine files, because caching for those resources will be more efficient when they change. In order to cope with the limitations of the aging HTTP/1 protocol, we were more than willing to sacrifice some degree of caching effectiveness for return visitors in order to speed up the initial loading of a site. Thus, techniques like scripts and CSS concatenation, image sprites, and inline assets were embraced. In a world that’s creeping toward HTTP/2, however, we’re told to abandon these practices —and for the most part, rightly so. The reality of the situation can be more complex than we initially thought. While HTTP/2 support on both the server and client side is steadily increasing, browsers that can’t understand the new protocol will linger on for some time yet—and that doesn’t just mean Internet Explorer. It also includes browsers like Safari on older versions of OS X, UC Browser, older versions of Android Browser, and Opera Mini. Sometimes we hurt the ones we love HTTP/2 support is not a one-sided affair. In order for it to work, the server must not only implement it, but the browser must also be capable of understanding the new protocol. When a browser that understands HTTP/2 begins requesting content from an HTTP/2 server, the exchange will predictably occur in, well, HTTP/2. In the case of an older browser like Internet Explorer on Windows 7 (or even a current browser such as Opera Mini), the conversation proceeds in HTTP/1. The underlying mechanism that drives this behavior is nuanced, but it can be considered progressive enhancement in that we’re not breaking the experience for users on platforms that can’t use HTTP/2. They’re merely getting a less optimal experience. Whether you’ve made the jump and optimized your site for HTTP/2 already, considering the jump from HTTP/1, or somewhere in between, it can pay (sometimes quite literally) to understand how these optimizations can impact your site’s users. Depending on your audience’s capabilities, a site optimized for HTTP/2 may well be detrimental for a segment of your audience. HTTP/2 enjoys broad support among users in the global sense. According to the popular feature support index site caniuse.com, HTTP/2 currently enjoys support of roughly 78% of all browsers currently in use. Some fringe browsers such as IE 11 below Windows 10, and Safari on OS X below El Capitan muddle the picture a bit. You can count on at least 72%[...]



This week's sponsor: FullStory

2017-01-30T05:01:00+00:00

FullStory, the CX platform that captures every interaction on your site for pixel-perfect playback. Get it free, forever. For real.

(image)