Design for Real Life

Design for Real Life: An interview with Sara Wachter-Boettcher

A note from the editors: A List Apart’s managing editor Mica McPheeters speaks with Sara Wachter-Boettcher about getting to the heart of users’ deepest needs.

Our users don’t live the tidy little lives we’ve concocted for our personas, with their limited set of problems. Life is messy and unpredictable; some days, terrible. When planning a project, it’s important not to let our excitement lull us into blithely ignoring life’s harsher realities.

Discomfort with others’ burdens has no place in good design. We sat down with coauthor and content strategist Sara Wachter-Boettcher (a past editor-in-chief of ALA), to discuss why she and Eric Meyer became vocal proponents of taking users’ stress cases seriously. Their new book, Design for Real Life, goes to the root of insensitive design decisions that fail to support the very users we’re meant to understand and respect.

First off, would you tell us a bit about how the book came to be? What was the tipping point that led you to take on this topic?

SWB: In early 2015, I started writing about the way forms demand users to reveal themselves—and all the ways that can be alienating and unempathetic. In that article, I talk about a couple personal experiences I had with forms: being asked to check a box about sexual assault, without knowing why or where that data would go, and being at the German consul’s office, filling out paperwork that required me documenting a sibling who had died as an infant.

It’d be easy to call that the tipping point, but to be honest, I didn’t actually feel that way. In fact, I had started writing that article the day I came home from the German consul’s office. But I wasn’t sure there was anything there—or at least, anything more than an emotional anecdote. I set it down for six months. The idea kept sitting in the back of my mind, though, so finally, during some winter downtime, I finished it off and posted it, unsure whether anyone would really care.

Turns out they did. I got an endless stream of tweets, emails, and comments from people who told me how much the piece resonated with them. And I also started hearing other people’s stories—stories of ways that interfaces had triggered past trauma, or demanded someone to claim an identity that made them uncomfortable, or made assumptions that a user found alienating. Forms that couldn’t handle people who identified as biracial, product settings that assumed heterosexuality, pithy copy that failed if a user’s current emotional state was anything less than ideal. The examples went on and on.

One of the people who reached out to me was Eric, whose work I had of course also been reading. And that’s really when it clicked for me—when I realized that this topic had touched a nerve across all kinds of groups. It wasn’t fringe. All of us deal with difficult pasts or current crises. Each scenario might be an edge case on its own, but taken together, they’re universal—they’re about being human. And now we’re all dealing with them online. The more Eric and I talked and compared stories others had shared with us, the more certain we were that we had something.

We’ve been talking about user-centered design for decades. Shouldn’t this sort of “sensitivity blindness” have been dealt with by now?

SWB: I wish, but historically, teams simply have not been trained to imagine their users as different from themselves—not really, not in any sort of deep and empathetic way.

That’s not just an issue on the web, though—because it’s a lot bigger than “sensitivity.” It’s really about inclusion. For example, look at gender in product design: crash-test dummies are all sized to the “average male,” and as a result, car accidents are far more dangerous for women than men. Medical research subjects are nearly always men—despite the fact that women experience illnesses at different rates than men, and respond to treatment differently. Of course we’ve transferred these same biased practices to the web. In this context, it’s not surprising that, say, Apple’s Health app didn’t include a period tracker—one of the most normal bits of data in the world—for an entire year after launch.

Identity issues—gender, race, sexuality, etc.—are huge here, but they’re just one way this lack of inclusivity plays out. Eric’s experience with Facebook’s Year in Review tells that story quite well: Facebook long imagined itself as a place where happy people share their happy updates. After all, it’s a platform that until just the other day literally only offered you one reaction to a post: to like it. The problem was that Facebook’s design mission stayed narrow, even as the reasons its users interacted with the platform became more and more varied.

While the web didn’t create bias in the world, I do think it has the opportunity to start undoing it—and I am starting to see seeds of that sown around the web. Digital communication has made it so much easier for organizations to get close to their audiences—to see them, talk to them, and most importantly, listen to them. If our organizations can do that—look at their audiences as real, multifaceted, complex people, not just marketing segments—then I think we’ll start to see things truly change.

Why do you think it’s hard for designers to keep real people in mind? Is it that we tend to be excited and optimistic about new projects, so we forget about the ways things can go wrong?

SWB: Yeah, I think that is part of it—and I think the reason for that is largely because that’s what organizations have trained design teams to focus on. That is, when a business decides to spend money on a digital product, they do it with positive outcomes in mind. As a result, the team is trained on the positive: “how can we make this delight our users?” If that’s all you’re asking, though, it’s unlikely you’ll catch the scenarios where a product could be alienating or harmful, rather than delightful, because your brain will be focused on examples of the positive.

For example, if you try to write a tweet that’s too long, Twitter has this little bit of UI copy that says, “Your Tweet was over 140 characters. You’ll have to be more clever.” Now, let’s say I just tweeted about the amazing tacos I just ate for lunch. In that scenario, the copy is light and funny. But what if I was trying to figure out how to tell the world that a friend just died—or even something more everyday, but still negative, like that I’d been rejected from a job? All of a sudden, that interface feels rather insulting. It’s alienating. Sure, it’s a small thing, but it’s hurtful and can even be degrading. And if you only ever test that feature with pithy sample tweets, it’s pretty likely you just wouldn’t notice.

What Eric and I are really advocating for, then, is for design teams to build a deep breath into their process—to say, every time they make a decision, “who might be harmed by this? In which circumstances does this feature break down for a user? How can we strengthen our work to avoid that?” There’s even an activity we talk about in the book, the “premortem”—where, instead of sitting down after a project ends to discuss how it went, you sit down beforehand and imagine all the ways it could go wrong.

At one point, you and Eric mention that “compassion isn’t coddling.” In the example with Twitter’s snarky copy, someone might say, “you’re overreacting—it’s just a joke.” How would you respond to that?

SWB: I’ve definitely gotten plenty feedback from people who say that this is all “too sensitive” and that we’ll all be “walking on eggshells.” Their answer is that people should just have a thicker skin. Frankly, that’s BS—that mentality says, “I don’t want to have to think about another person’s feelings.”

Coddling someone means protecting them from the world—shielding them from difficult subjects. That’s not what we’re proposing at all. We’re saying, understand that your users are dealing with difficult subjects all the time, even when using your site or service. Being kind means being respectful of that fact, and avoiding making it worse. Think about the normal things you’d do in person—like if your friend were going through a divorce, you’d probably wait for them to open up to you, rather than ask prying questions, right? If you knew someone had just been traumatically assaulted at a specific bar, you’d probably not suggest meeting there for drinks. You’d be compassionate, and avoid making them feel even more uncomfortable or vulnerable.

Humans learn to be good at this in person, but because we don’t know when or if a user is going to be in a difficult emotional state, we seem to forget about this online. And that’s why niceness isn’t enough. Being nice is easy to reduce to being friendly and welcoming. But compassion is deeper: it’s recognizing that people have all kinds of needs and emotional reactions, and our job is to help them, rather than expect them to fit our narrow ideals.

If a team understands that, and wants to be compassionate, how much do they need to do to account for “edge cases”? Is there a cutoff point?

SWB: This is something we talk about a lot in the book. “Edge case” is a really easy way to write something off—to say, “this is not important enough to care about.” Calling something or someone an edge case pushes them to the margins, quite literally. Instead of treating people who don’t quite fit whatever you thought of as “average” as fringe, though, we think it’s a lot more helpful to think of these as “stress cases”: the challenges that test the strength of your design. Because if your work can hold up against people at their worst, then you can be more confident it will hold up for everyone else, too.

Just like in traditional products. Think about the brand Oxo, which makes ergonomic housewares. People love Oxo products. But they weren’t initially designed to suit the average user. They were initially designed with the founder’s wife, who had arthritis, in mind. But by making something that was better for people with more limited ranges of motion, Oxo ended up making something that was simply more comfortable to use for most people. We have the same opportunity in our interfaces.

Our message, though, is that it takes a bit of a reframe to get there: it’s not about “how many edge cases do I have to support?” but rather, “how well have I vetted my work against the stress of real life?”

But won’t that affect creativity, to constantly plan for limiting factors—many that we can’t anticipate?

SWB: You know, no one complains that designing a car to be safer during an accident limits the engineers’ creativity. So why should we say that about digital products? Of course thinking about users’ varied identities and emotional states creates limiting factors. But that’s what design is: it is a creative solution to a set of problems. We’re redefining which problems are worth solving.

Of course we can’t anticipate every single human issue that might arise. But I can’t imagine not trying to do better. After all, we’re designing for humans. Why wouldn’t we want to be as humane as possible? I don’t think we need to be perfect; humans never are. But our users deserve to have us try.

Pick up your copy of Design for Real Life from A Book Apart.

via planetweb

Microsoft to Allow Native Bash and Linux Command Line on Windows 10

Microsoft announces it is to allow native bash and Linux command line on Windows 10.

via planetweb

E.U. Considering a Tax on Google Showing Snippets

The E.U. is considering a snippets tax on Google for what is described as "neighbouring rights" to publishers.

via planetweb

Google Announces it is to Entirely Redesign AdWords

Google has said it will be entirely redesigning AdWords from now through to 2017...

via planetweb

Opinion: How SEO Best Practices Became Irrelevant

This week's opinion piece is on the topic of, "What You Need to Know to Compete Better in the SERPs."

via planetweb

Microsoft to Give Enterprise Admins Ability to Block Running of Macros

Microsoft has said a method attackers use to compromise computers using macros can now be controlled and turned off by enterprise administrators.

via planetweb

Facebook Impersonation Tool Tested

Facebook is testing a tool to alert users if their name and profile picture is being used by someone else.

via planetweb

French Media Takes a Stance on Adblockers - No ads, no Access

Members of the French media and publishers are taking a stance against ad blocking...

via planetweb

Google AdSense Adds Matched Content For Eligible Publishers

This Allow Ads feature should appear in the Matched content units in the coming months...

via planetweb

Web Animation Past, Present, and Future

What EXACTLY IS The Google Penguin Algorithm?

WebmasterWorld Members discuss exactly what is the Google Penguin algorithm.

via planetweb

Opinion: Google Data Quality Down - Is this now a systemic issue?

This is the first in a weekly series of WebmasterWorld Moderator opinion articles: "I am going to open up on a subject that is affecting my day to day working..."

via planetweb

Google Mobile SERPs Update in May Increasing the Effect of Mobile Ranking Signal

Google will be updating the mobile search results in May 2016 increasing the effect of the ranking signal of mobile friendly sites.

via planetweb

The Problem With SEO "As Usual"

WebmasterWorld Members discuss the problem of SEO as usual, and discusses algorithms, referrals, and the fragility of a single basket of traffic sources.

via planetweb

List of Reasons Why Google AMP is Not Ready

WebmasterWorld Members discuss Google AMP, what's missing from it, and whether it was ready for mainstream.

via planetweb

Aligning Content Work with Agile Processes

As a content strategist, I work on teams with agile developers, user experience designers, user acceptance testers, product managers, and data scientists. A mere decade ago, I would have been called a journalist or an editor. I would have worked with copyeditors, proofreaders, graphic designers, and printers—but times, job titles, and platforms have changed. Content strategists have had to adjust to the rise of development-centric projects focused on products. Big changes challenge traditional content culture and processes.

Agile has the potential to set content strategists free from dated ways of working. And developers and designers can help. How can they better understand content and align their objectives and outputs with content producers?

I’ve identified four areas—iteration, product, people, and communication—where developers and designers can find common ground with their content colleagues and help them adapt to the agile world, while themselves gaining a greater understanding of content culture.

Iteration

Most content producers might think that the concept of iteration doesn’t apply to them—traditionally, at least, things aren’t usually published iteratively. Readers expect the finished article to be just that: finished.

But if content teams take a step back and analyze their work in the context of agile, they will recognize that they are already regularly adapting and adjusting to changing circumstances. The content landscape already has many of the characteristics of an agile environment. Consider these scenarios:

• A story is breaking on social media and you need to get your brand involved as soon as possible.
• A new source emerges with vital information just as you’re about to publish.
• A massive national breaking-news story consigns your lovingly crafted PR campaign to the scrap heap.
• A deadline one month away is pulled forward by two weeks, throwing workflows into chaos.

Requirements and constraints change just as readily in content as in agile development; deadlines can be viewed in the same terms as sprints.

The key to content teams understanding agile iteration is helping them view content like building blocks, where each communication makes up a larger message and that message becomes more honed, focused, and optimized over time. Content folks readily use data to get information on audience, platforms, and engagement so in a sense they are already in the business of iteration.

How can developers encourage this? Well, for example, during a new build, don’t accept lorem ipsum text—politely ask content people to knuckle down and produce a first iteration of the actual content that will appear in the finished product. If you’re using a content-first strategy, this is self-explanatory; even if you’re not, though, early content iteration creates focus and sends a positive signal to stakeholders. It helps them better visualize the end product and, most importantly, gives your team a first draft to build on to challenge those stakeholders—marketing, sales, data scientists—who need to give feedback on the process. Their feedback may be as simple as a bunch of questions.

On a critical conversion page, for example, the stakeholders’ notes might read, “Is this where our super-important CTA is? Have you A/B tested this? Have we benchmarked it against our competitors?!” Or, “Hey data science! Just wondering if you could check the tagging on this page when you get a moment… I’ll need solid tagging to measure its popularity! Thanks.”

View each unit in the content-production process as a single step on the path to your final goal rather than an end in itself. This fosters early and continuous development, frequent delivery, iterative pieces of output, and sustainability, all of which are cornerstones of the agile approach.

Additionally, by using team collaboration or project management software to create, plan, review, edit, and publish content, key stakeholders are given both oversight and readily accessible insight into the fluid, iterative process of content production.

This puts content at the heart of development and UX. Even when other strategies are in play (such as when developers are working to a waterfall model), make sure that content milestones are agreed upon early and allow stakeholders to see exactly what’s going on. This open, documented approach also works great when content isn’t directly feeding into a new build, but is part of an ongoing, business-as-usual workflow. It sets a powerful precedent and showcases how iteration can be easily tracked on both dev and content sides, providing an early focus on regular milestones.

Product

Content strategists should easily be able to recognize how agile principles apply to their output: frequent delivery, sustainable development, attention to detail, good design. More difficult is determining how content should fit into Kristofer Layon’s product-development framework.

My favorite strategy is a content-first approach because it’s bottom-up. The smallest unit of currency in any development or design project is a word, an image, a punctuation mark. Everything grows out of this. While other strategies can be convincing, readers generally don’t visit a website to swoon over a sublime user journey, admire the poetic code, or gaze in awe at the artistry of the design.

They come for content.

Even in waterfall-driven projects, though, a content-first “lite” approach can work very effectively when content output is addressed early and prominently in the requirements-gathering process.

Whether agile, waterfall, or some hybrid thereof, the key is to synchronize UX and content early in the discovery phase and lock that collaboration in so it becomes a cornerstone of the project.

Additionally, a content-first approach doesn’t have to apply solely to new stuff. Existing products can benefit from an overhaul where the content-production cycle is broken down to its smallest components, and then optimized and rebuilt to better effect with, perhaps, optimized calls to action, punchier copy, or more dynamic imagery.

A content-first strategy also creates boundaries, ownership, and a sense of control. It places content at the heart of the agile process from the beginning rather than tacking it on as an afterthought once design and dev work is underway. This gives content managers a more insightful and impactful window into the agile world from which they can adapt their own processes and workflows. I’ve seen projects flounder spectacularly when various business departments go to battle with their own vested interests.

Recently, I was asked to ship a new online product by the print arm of a department I had never worked with before. I was hesitant, but saying no wouldn’t have been a wise move politically. I foresaw problems because of the tight timeline combined with the fact that the company was new to the product-management framework but hey, this was a newspaper with a thriving digital business. What could possibly go wrong with a content-first approach?

The problems quickly escalated as I tried to corral over 40 people (five percent of the entire workforce!) in a half dozen departments, all of whom wanted their say in the transition of the product from print to digital.

In retrospect, this transition would have benefitted from a dedicated project manager who could have streamlined communications and better managed stakeholder expectations. If you’re struggling to pull all the strands together in a project involving complex content and development work, it’s never too late to pull back and take a bird’s-eye view with the product or project manager, head of content, or head of development to try to regain perspective and address any challenges.

Whether your project employs an aggressive content-first strategy or a “lite” version, understanding and embracing content in the context of product instills a sense of ownership and investment on both the development and content side. Both teams will see early dividends from this mutually beneficial approach.

People

Years ago, I developed an admiration for dev teams. They seemed calm under pressure, thoroughly professional, deliberate, focused, and, above all, respectful—pretty much the antithesis of many newsrooms or communications teams I’d been part of. As my career developed, I was fortunate enough to be able to build my own teams. I looked to these qualities (outlined by Jonathan Kahn), as key characteristics I wanted in the people around me.

Whether building a team from scratch or inheriting it, we apportion ownership—and that empowers. That’s the key to building strong, vibrant, successful teams. My preferred strategy for doing this is to confer end-to-end ownership on each piece of content so that its creator also oversees the review, optimization, and publishing process (including working with the developer or designer). Exposing content creators to agile practices through stand-up meetings, discovery and planning meetings, retrospectives and group communications will give them a more holistic, invested view of operations.

Lifecycle ownership motivates and trusts individuals in an agile way. It also has the advantage of giving devs and designers more influence while broadening the skills of content producers through increased exposure. This will ultimately assist the move toward agile self-organization within the team. Self-organization allows teams to create their own opportunities, which builds individual and collective confidence and challenges people to regularly test their limits.

Motivation and trust will blossom in this environment and help ensure the focus will always be on your people. If you get one thing right, make it your people; the rest will fall into place.

Communication

Given that communication is at the core of content, you’d be forgiven for thinking that it would be an obvious area for content producers to put their best foot forward. But unfamiliar language such as dev- or design-speak can be intimidating.

Patience will be its own reward here. Encouraging daily communication between devs and content is an ideal way to immerse each in the challenges the other faces and a great opportunity to highlight how agile can be a positive force within content.

And—even though content folks might not (yet) be accustomed to this—I’ve also found it beneficial to introduce morning stand-ups into my content routine. The opportunity to collectively address challenges for a few minutes each day amplifies both individual ownership and team responsibility.

Even more beneficial is when developers invite relevant members of their content teams along to stand-ups. I’ve always been pleasantly surprised how receptive each side is to the challenges of the other. Encouraging content to attend for the duration of a sprint both allows them to see the beginning, middle, and end of the release cycle and helps align goals.

As a developer, if you commune, share, and consume with your content team, the “us and them” divide soon crumbles. Before you know it, you’re fully exposing content folks to the agile environment.

Good communication is vital, says Inayaili de Leon. The agile principles of daily cooperation and face-to-face communication create regular opportunities to surface and address problems.

Prevention is always better than cure, of course, but in organizations with a multitude of moving parts, communication can break down, particularly in the heat of battle. What to do then?

If things begin to go awry and face-to-face is not enough, you may need to make a more compelling case for communication change. The best route is through rigorously collecting specific examples of the problems your team is having with content. Solutions can lie in the precise documentation of blockers, resource challenges, and impact assessment, particularly if related to return on investment.

Agile communications should always favor the personal over the process, and collaboration over confrontation. And while sometimes we have to revert to the latter when the former proves insufficient, we should always try to remain positive and strive to build on our failures as well as our successes.

A Rallying Cry

Adaptability is hard-coded into our genes. Not only is it essential for survival, but it helps us flourish. As business environments change and roles adjust to new technologies, platforms, tastes, and consumption habits, so we (developers, designers, content strategists) must look for ways to remain at the cutting edge of our disciplines.

Traditionally, content was the message; developers provided the method of delivery. The two coexisted side-by-side, if occasionally a little uneasily. But our mutual dependencies have forced us closer together. I believe that the open, collaborative, people-focused, and change-embracing approach of modern agile development is a framework within which content work can refine itself, test, and learn.

By taking this step on the path to helping content align itself with agile, you may find both your development and content teams energized—maybe even revolutionized.

via planetweb

This week's sponsor: FullStory

FULLSTORY. Solving your site’s user experience woes takes more than charts and graphs. Get FullStory free for 14 days.

via planetweb

Opera For Desktop Gets Native Ad Blocking

Opera's latest version has built-in ad blocking.

via planetweb

New York Times Experiments With Ways to Fight Ad Blocking

WebmasterWorld Members discuss the New York Times experimentations combating ad blocking.

via planetweb

Impulses and Outcomes

A couple of years ago while I was working on a project with Kevin M. Hoffman, he related a story to me about his consulting work with an agency on improving presentations to clients. The story centers around a designer who was asked to change his mode of dress. This designer was fond of the goth look, but the agency considered it inappropriate for some client meetings.

Long story short, Kevin told the staff member that he could wear whatever he wanted to, but to consider the situation in terms of his desired outcomes. Clients’ opinions about clothing and personal expression aside, what was more important to the designer: dressing a certain way, or successfully pitching the design direction he was the most excited to work on? The “what to wear” decision then becomes less about the designer’s pride or interest in retaining control, and more about getting what he wants in the situation; acting in his own self-interest to the best of his ability.

Recently, as I worked on an extended project for a client at Bearded, these ideas started percolating through my brain again, but this time with regard to design. Every designer (and really everyone involved in a design) has tendencies and predilections that, like it or not, will be guiding the design process.

Of course we make our best efforts to ground the creative process in research, interviews, and egalitarian decision-making activities (sticky notes and card sorts, anyone?). But no matter what we do, our entire process is filtered through the very fallible, very subjective minds of people.

Let’s talk about your childhood

For a moment, we’ll zoom in from our mile-high view and consider a single person. Let’s imagine a child who grows up under the care of well-meaning but disorganized parents. The parents’ plans and decisions are unpredictable. The child, never knowing what will happen next, grows into a bright, talented young person with an unresolved longing for structure and order.

We might even imagine that this need to bring order from chaos, to sort out the unpredictable, messy parts of the world, is what draws them into a career as a designer.

Responsible adults

As they find their professional legs, they mature into not so much the David Carson, Stefan Sagmeister, James Victore, anything goes sort of designer — more of an Erik Spiekermann, Willi Kunz, or Sylvia Harris. They’re not out to tear the design world a new one. To the contrary, they’re focused on sorting out the garbled information before them; smoothing over the rough patches, and slowly rotating their subject’s gleaming, flawless, chrome surface towards the world.

And there’s nothing wrong with this orderly sort of design. In fact, it’s very, very useful to the world. Perhaps even necessary.

Likewise there’s nothing wrong with that wild-eyed sort of design, either. One might imagine (as many do) these types of design as poles on a spectrum of useful approaches. Poles between the qualities of Consistency and Variety.

Non-binary systems

As it turns out, every project demands to be somewhere on this scale. And it’s essential during the first part of every project (the research, the interviews, even the sticky notes) to figure out which spot on the spectrum is best suited to the project.

Now the extremes of this range are rarely appropriate for any project. An unwaveringly consistent design approach will often seem generic and boring. On the other hand, a design that is entirely committed to variety will make the audience struggle at every turn to orient themselves and parse the information before them.

So it seems fair to say that most designs benefit from being somewhere in the middle zone, balancing between the unhappy extremes of boredom and chaos.

Advanced calibration

But what happens when our imagined designer – the one who is drawn to systems of order and control – determines through their research that their project requires a design approach that is on the more varied side of center? When the organization, in fact, will benefit from a less rigidly ordered design? This organization, it turns out, needs an approach that may not sing with as much immediate and obvious clarity, but will bring more surprise and thrill to the audience.

And so we find ourselves with a mismatch between impulses (bring order!) and outcomes (show us surprises!). The problem is that the designer’s approach is not in a conversation with the project and its goals; it’s stuck in a very old dialog with the designer’s childhood. If left unaddressed, a successful project outcome will depend on whether or not those old desires happen to match up with the project’s requirements.

If we don’t want to leave things up to chance, this situation requires the identification of both the designer’s impulses and the project’s desired outcomes, and a conscious assessment of their overlap and contradictions.

When I was in a critique at design school, one of my classmates commented on another’s work that they “really seemed to be developing a style.” My professor became suddenly incensed (a rare thing for her), and declared “you’re designers, you don’t have a style! Your style is whatever is appropriate to the project!” In that way design is very different than art. Art stems primarily from the artist’s internal world. But design does not. Design aims to solve problems outside of the designer. Whereas the artist might be seen as a sort of oracle speaking to the world, the designer is more of a tool that is useful in solving problems.

Which is why, in the cases where a designer’s internal impulses and the project’s desired outcomes are not in alignment, the designer must consider adjusting. To be a useful tool, we must recognize that some of our impulses work against the needs of the organization that is employing us, and compensate.

This is no easy task. It’s a process that requires knowing oneself, and questioning our own nature and subjectivity. But it’s only through this sort of rigorous self-assessment and awareness that we can grow beyond our limitations–becoming better designers, and perhaps if we’re lucky, more sensitive and thoughtful people in the process.

via planetweb

Microsoft Makes SQL Server for Linux

Microsoft is bringing SQL server to Linux.

via planetweb

Google Updates and SERP Changes - March 2016

WebmasterWorld's monthly look at Google's SERPs changes.

via planetweb

Google Search Analytics Delays, Yet to be Fixed

Google is working to fix the ongoing analytics delays.

via planetweb

HTTPS Websites Open to DROWN Attack

It's estimated up to 11-million websites could be vulnerable, and updates are on the way.

via planetweb

Defeating Workplace Drama with Emotional Intelligence