Subscribe: A List Apart
http://www.alistapart.com/rss.xml
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
clients  content  data  design  designers  grid  make  new  people  problem  product  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-04-18T14:00:00+00:00

 



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 you exactly how you need to scale, and direct you toward the right forms of outsourcing and assistance. Before you do anything else, assess your current business model. Outline your entire pro[...]



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 relevant to search terms visitors use Create high quality content that invites re-links and social shares Ensure that time-on-site for the specific piece of content is high. It may feel a bit u[...]



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 20em; } #sitemast { grid-row: 1; grid-column: 1 / span 2; } #search { grid-row: 2; grid-column: 2; } #main { grid-row: 3; grid-column: 1; } #extra { grid-row: 3; [...]



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 commandments: rules that may be applicable to many different kinds of design decisions, and therefore open to interpretation. There’s no industry standard on how to write design principles, so y[...]



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 considerable resources responding to RFPs, and many employ sales staff and account managers. When designers enter more senior-level positions, they eventually face the frustration that more time is spe[...]



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 Brooks provide these definitions of a story in their book Storytelling for User Experience: Stories describe the context of a situation Stories can illustrate problems Stories can be used to help [...]



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 through each feature in the product. There are slideshows with custom fonts and colorful characters that highlight everything new and promising in the release. There are translucent overlays[...]



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 (meaning load times are below this value 95% of the time). What this data tells me is that if I moved my site to HTTP/2 but didn’t optimize for HTTP/2-incompatible browsers, average page load[...]



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% of users globally to support HTTP/2 (at least at the time of this writing). Of course, this is just the big picture, and it isn’t an indicator of what your specific audience looks like. Y[...]



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)



Gaming the System…and Winning

2017-01-24T15:00:00+00:00

Good intentions usually drive the “gamification” of websites—adding points, badges, and leaderboards to make them more engaging. It sounds like a great idea, but borrowing game design elements out of context is a risky way to design experiences, especially experiences intended to bring users back to a site. Not everyone wants to spend more time on your site just to get a badge; some people simply aren’t motivated by such extrinsic rewards. When game designers include elements intended to promote deeper engagement, they look at their users through a very different lens than those of us in web design. Understanding how and why they do this can help us craft more engaging web experiences. A game designer and a web designer looking at the same user research will most likely come up with totally different personas. Talking about many people as though they were one person can be a strength;it gives a clear vision of who we need to serve. But it’s also a limitation because this method of clustering requires us to pick certain axes and disregard others. Web designers cluster people by their needs and abilities, but in doing so, we tend to disregard their personalities. Game designers are more likely to fixate on interaction styles; they embrace personality. Let me show you what I mean. Pokémon Go has seen a meteoric rise in popularity since its release, possibly because of how well it caters to people with different personalities. In Pokémon Go, people who like to compete can “battle” in gyms; those who prefer to collaborate can go on “pokéwalks” together; and anyone with a drive to explore and push boundaries can try to “catch ’em all.” Even if a player enjoys all of these options, they’re likely to find one more motivating than the others. Ensuring that the game caters to each interaction preference enhances its appeal to a wide audience. The same is true of web design. Adding gamification elements to draw in more visitors—but only elements that cater to competitive people—can overlook the wider audience. UX design that doesn’t target a variety of interaction styles is going to be hit-or-miss. Game designers (and educators and psychologists) segment people in ways that complement web design and user experience. I’ve put together this guide to show you how they think and how (and where and why) we can use their models. Along the way, I’ll show how those models might overlap to create one bigger framework that we can use to pinpoint strengths and weaknesses in our designs. Making it fun Emotional design—the practice of moving interfaces beyond merely usable—is a growing field of interest among UX designers. (I highly recommend Designing for Emotion and Seductive Interaction Design.) Unsurprisingly, game designers have a theory of fun, too. A recent study performed a contextual inquiry of hardcore and casual gamers, plus interviews with their friends and family members, identifying four types of fun (PDF) that relate to interaction preference. Hard Fun comes from pursuing a goal—earning rewards according to progress. Easy Fun focuses on something other than winning. It encourages learning and emphasizes feelings of wonder, awe, and mystery. The People Factor caters to interaction with others; the interface becomes a mechanism for social engagement. Altered States attract people to engage in a social context to feel something different (e.g., to gain pleasure from acting upon or inciting those around them). These styles are easy to spot on social networking sites: Competing for likes or followers (as on Twitter) is Hard Fun. Casually browsing to find humorous new posts (as on Tumblr) is Easy Fun. Engaging with a social[...]



This week's sponsor: GatherContent

2017-01-23T05:01:00+00:00

GATHER CONTENT: Stop content delaying website launches with custom collaborative online templates and workflow. Try it free!

(image)



Guerrilla Innovation

2017-01-17T15:00:00+00:00

In a culture like Google’s, having paid time to innovate is celebrated. But most of us don’t work at Google; most of us work at places that are less than thrilled when someone has a bright new idea that will be amazing. After all, who has time to try new things when the things we’re doing now aren’t broken? No one wants to be forced to use another app, to have yet another thing they are expected to log into, only to see it die out in six months. So how do you push an idea through? How can you innovate if you work in a less-than-innovative place? It takes more than a big idea Let’s say you just saw a demo of someone using a prototyping tool like UXPin and you’ve got this big vision of your team incorporating it into your development process. With a tool like this, you realize, you can quickly put some concepts together for a website and make it real enough to do user testing within two days! Seems pretty invaluable. Why haven’t we been using this all along? You create an account and start exploring. It’s pretty damn awesome. You put a demo together to share with your team at your next meeting. Your excitement is completely drained within five minutes. “Seems like a lot of extra work.” “Why would we create a prototype just to rewrite it all in code?” “Let’s just build it Drupal.” Knife. In. Heart. You can see the value in the product, but you didn’t take the necessary steps to frame the problem you want to solve. You didn’t actually use this exciting new tool to build a case around the value it will have for your company. So right now, to your coworkers, this is just another shiny object. In the web development world, a new shiny object comes along every couple seconds. You need to do some legwork upfront to understand the difference between what shiny object is worth your team’s time and what is, well, just another shiny object. Anyone can come up with an idea on the fly or think they’re having an Oprah Aha! Moment, but real innovation takes hours of work, trying and failing over and over, a serious amount of determination, and some stealth guerrilla tactics. Frame the problem The first step in guerilla innovation is making sure you’re solving the right problem. Just because your idea genuinely is amazing doesn’t mean it will provide genuine value. If it doesn’t solve a tangible problem or provide some sort of tangible benefit, you have little or no chance of getting your team and your company to buy into your idea. Coolness alone isn’t enough. And “cool” is always up for interpretation. Framing the problem allows you to look at it from many different angles and see different solutions that may not have occurred to you. By diving deep into the impact and effects your idea will have, you will start to see the larger picture and may even decide your idea wasn’t so amazing after all. Or, this discovery could lead you to a different solution that truly is innovative and life-changing. Start at the end When your idea is implemented and everything goes as planned, what benefit will it provide? Make a list of people who would theoretically benefit from this idea. Write down who they are and how the idea would help them. Let’s go back to our prototyping tool example. Who would benefit from it the most? The end user looking for specific content on your website. Using a prototyping tool would allow you to do more user testing earlier in the process, letting you tweak and iterate your design based on feedback that could improve the overall site experience. An improved experience would, ideally, allow visitors to find the content they are lookin[...]



A Dao of Product Design

2017-01-12T15:00:00+00:00

When a designer or developer sets out to create a new product, the audience is thought of as “the user”: we consider how she might use it, what aspects make it accessible and usable, what emotional interactions make it delightful, and how we can optimize the workflow for her and our benefit. What is rarely considered in the process is the social and societal impact of our product being used by hundreds of thousands—even millions—of people every day. What a product does to people psychologically, or how it has the power to transform our society, is hard to measure but increasingly important. Good products improve how people accomplish tasks; great products improve how society operates. If we don’t practice a more sustainable form of product design, we risk harmful side effects to people and society that could have been avoided. The impact of product design decisions In 1956, President Eisenhower signed the U.S. Interstate Highway Act into law. Inspired by Germany’s Reichsautobahnen, Eisenhower was determined to develop the cross-country highways that lawmakers had been discussing for years. During the design of this interstate network, these “open roads of freedom” were often routed directly through cities, intentionally creating an infrastructural segregation that favored affluent neighborhoods at the expense of poor or minority neighborhoods. Roads became boundaries, subtly isolating residents by socioeconomic status; such increasingly visible distinctions encouraged racist views and ultimately devastated neighborhoods. The segmentation systematically diminished opportunities for those residents, heavily impacting people of color and adversely shaping the racial dynamics of American society. Such widespread negative consequences are not limited to past efforts or malicious intentions. For example, the laudable environmental effort to replace tungsten street lamps with sustainable LEDs is creating a number of significant health and safety problems because the human impact when applied at scale was not thought through sufficiently. In each example, we see evidence of designers who didn’t seriously consider the long-term social and moral impacts their work might have on the very people they were designing for. As a result, people all around suffered significant negative side effects. The ur-discipline Although the process is rarely identified as such, product design is the oldest practiced discipline in human history. It is also one of the most under-examined; only in relatively recent times have we come to explore the ways products exist in the context they impact. Designers often seek to control the experience users have with their product, aiming to polish each interaction and every detail, crafting it to give a positive—even emotional—experience to the individual. But we must be cautious of imbalance; a laser focus on the micro can draw attention and care away from the macro. Retaining a big-picture view of the product can provide meaning, not only for the user’s tasks, but for her as a person, and for her environment. Dieter Rams’s ninth principle says that good design is environmentally friendly; it is sustainable. This is generally interpreted to mean the material resources and costs involved in production, but products also affect the immaterial: the social, economic, and cognitive world the user inhabits while considering and using the product. At a high level, there is an easy way to think about this: your product and your users do not exist in a vacuum. Your algorithms are not fair or neutral. Your careful touch is not pristine. Your lif[...]



This week's sponsor: WEBEDITION

2017-01-09T23:19:00+00:00

WEBEDITION, the best way to craft and deliver issues of your own online magazine. Start now and build an issue for free.

(image)



The Imbalance of Culture Fit

2017-01-03T15:00:00+00:00

When I started Bearded back in 2008, I’d never run a business before. This lack of experience meant I didn’t know how to do many of the things I’d ultimately have to do as a business owner. One of the things I didn’t know how to do yet? Hiring. When it came time to start hiring employees, I thought a lot about what the company needed to advance, what skills it was lacking. I asked friends for advice, and introductions to people they knew and trusted who fit the bill. And I asked myself what felt like a natural question: would I want to hang out with this person all day? Because clearly, I would have to. The trouble with this question is that I like hanging out with people I can talk to easily. One way to make that happen is to hang out with people who know and like the same books, music, movies, and things that I do; people with similar life experiences. It may not surprise you to learn that people who have experienced and enjoy all the same things I do tend to look a whole lot like me. The dreaded culture fit This, my friends, is the sneaky, unintentional danger of “culture fit.” And the only way out I’ve found is to recognize it for what it is–an unhelpful bias–and to consciously correct for it. Besides being discriminatory by unfairly overvaluing people like yourself, hiring for culture fit has at least one other major detriment: it limits perspective. At Bearded, our main focus is problem solving. Whether those are user experience problems, project management problems, user interface problems, or development problems–that’s what we do every day. I’ve found that we arrive at better solutions faster when we collaborate during problem solving. Having two or more people hashing out an issue, suggesting new approaches, spotting flaws in each other’s ideas, or catching things another person missed–this is the heart of good collaboration. And it’s not just about having more than one person, it’s about having different perspectives. Perspective as a skill A simple shortcut to finding two people who look at the world differently is to find two people with varied life experience–different genders, races, religions, sexual orientations, economic backgrounds, or abilities… these factors all affect how we see and experience the world. This means that different perspectives–different cultures–are an asset. Varied perspective can be viewed, then, as a skill. It’s something you can consciously hire for, in addition to more traditional skills and experience. Having diverse teams better reflects our humanity, and it helps us do better work. This isn’t just my experience, either.According to research conducted by Sheen S. Levine and David Stark, groups that included diverse company produced answers to analytical questions that were 58 percent more accurate. When surrounded by people “like ourselves,” we are easily influenced, more likely to fall for wrong ideas. Diversity prompts better, critical thinking. It contributes to error detection. It keeps us from drifting toward miscalculation. Smarter groups and better problem-solving sounds good to me. And so does increased innovation. In her article for Scientific American, Katherine W. Phillips draws on decades of research to arrive at some exciting conclusions. Diversity enhances creativity. It encourages the search for novel information and perspectives, leading to better decision making and problem solving. Diversity can improve the bottom line of companies and lead to unfettered discoveries and breakthrough innovations. Even simply being [...]



Learning from Lego: A Step Forward in Modular Web Design

2016-12-22T15:00:00+00:00

With hundreds of frameworks and UI kits, we are now assembling all kinds of content blocks to make web pages. However, such modularity and versatility hasn’t been achieved on the web element level yet. Learning from Lego, we can push modular web design one step forward. Rethinking the status quo Modular atomic design has been around for a while. Conceptually, we all love it—web components should be versatile and reusable. We should be able to place them like bricks, interlocking them however we want without worrying about changing any code. So far, we have been doing it on the content block level—every block occupies a full row, has a consistent width, and is self-contained. We are now able to assemble different blocks to make web pages without having to consider the styles and elements within each block. That’s a great step forward. And it has led to an explosion of frameworks and UI kits, making web page design more modular and also more accessible to the masses. Achieving similar modularity on the web element level is not as easy. Pattern Lab says we should be able to put UI patterns inside each other like Russian nesting dolls. But thinking about Russian nesting dolls, every layer has its own thickness—the equivalent of padding and margin in web design. When a three-layer doll is put next to a seven-layer doll, the spacing in between is uneven. While it’s not an issue in particular with dolls, on web pages, that could lead to either uneven white space or multilevel CSS overrides. I’ve been using Bootstrap and Foundation for years, and that’s exactly what would happen when I’d try to write complex layouts within those frameworks—rows nested in columns nested in rows, small elements in larger ones, all with paddings and margins of their own like Russian dolls. Then I would account for the nesting issues, take out the excessive padding on first- and last-child, calculate, override, add comments here and there. It was not the prettiest thing I could do to my stylesheets, but it was still tolerable. Then I joined Graphiq, a knowledge company delivering data visualizations across more than 700 different topics. Here, content editors are allowed to put in any data they want, in any format they want, to create the best experience possible for their readers. Such flexibility makes sense for the small startup and we have a drag and drop interface to help organize everything from a single data point to infographics and charts, to columns, blocks, and cards. Content editors can also add logic to the layout of the page. Two similar bar charts right next to each other could end up being in quite different HTML structures. As you can imagine, this level of versatility oftentimes results in a styling hell for the designers and developers. Though a very promising solution—CSS Grid Layout—is on the horizon, it hasn’t made its way to Chrome yet. And it might take years for us to fully adapt to a new display attribute. That led me to thinking if we can change the Russian doll mentality, we can take one step further toward modular design with the tools available. Learning from Lego To find a better metaphor, I went back to Lego—the epitome of modular atomic design. Turns out we don’t ever need to worry about padding and margin when we “nest” a small Lego structure in a large Lego structure, and then in an even larger Lego structure. In fact, there is no such concept as “nesting” in Lego. All the elements appear to live on the same level, not in multiple layers. But what does that m[...]