Tag Archives: development

Thumbnail

Website quality assurance: How to make certain your experiments don’t fail before they launch

According to Donald Norman, the user’s final experience of your website is at a reflective level: Was the experience delightful…Read blog postabout:Website quality assurance: How to make certain your experiments don’t fail before they launch

The post Website quality assurance: How to make certain your experiments don’t fail before they launch appeared first on WiderFunnel Conversion Optimization.

Follow this link – 

Website quality assurance: How to make certain your experiments don’t fail before they launch

Thumbnail

Ranking in Search in 2018: A Q&A With SEO Pros Rob Bucci and Cyrus Shepard

If Benjamin Franklin were alive today, he’d say there are only three things certain in life: death, taxes, and Google changes.

As search behaviour evolves and machines get smarter, Google naturally adjusts what it serves up. And these changes are often quick enough to feel a bit overwhelming (we’re right there with ya)! But in light of information we have about what Google actually values these days, we have more to work with than ever before. If we know how to execute.

Two people who know a lot about Google’s ranking factors are Rob Bucci, CEO of STAT Search Analytics and Cyrus Shepard, Partner at Zyppy and former Head of SEO and Content Development at Moz. Both speakers at this August’s Call to Action Conference, they’re bona fide search experts who spend their time demystifying the ways of our ranking overlords for marketers like you and me.

So we peppered them with a few questions we couldn’t wait until August to find out—like what’s changed, stayed the same, and how to best achieve SEO success in 2018. Get the goods below and learn more about their upcoming talks at CTAConf right here.

Want to get incredible insights from Rob and Cyrus in person? Use the code “CTAConfSEO” at checkout to get 15% off all ticket rates for the conference until July 31.

Rob Bucci on local search and getting snippeted

SEO-obsessed Rob founded STAT Search Analytics, a rank tracking and SERP analytics platform, in 2011. Since then, he’s worked with clients like eBay, Pinterest, Cars.com, and Thomas Cook Airlines to understand their unique search opportunities and win more business.

He’s also a frequent speaker on search, data mining, and all things analytics. In his Call to Action Conference talk, What Google Serves Up For Local Searches, he’ll dive into the nooks and crannies of (you guessed it) local intent, local search, and how to adeptly navigate Google’s interpretations of both to get in front of the right audience. Read below for a peek at what he’ll share on stage.

Hayley Mullen: Your talk at CTAConf is all about interpreting how Google handles local search. So, how are they doing?

Rob Bucci: Knowing that, with location tracking, etc., you can’t always rely on searchers to explicitly state when their intent is local, you need to look at keywords where that intent can be implied. The question then—before you can optimize accordingly—is whether Google is actually any good at interpreting that implicit local intent. And is it comparable to stated local intent?

For example: [sushi near me] would indicate that close proximity is essential; [sushi in Vancouver] seems to cast a city-wide net; and just [sushi] is largely ambiguous—are you hungry for knowledge about sushi or actual sushi? And what happens with a query like [best sushi], which indicates that quality takes priority over proximity?

It’s Google deciding what those queries mean, so it’s important to understand that decision. There’s no point in optimizing for something that Google can’t or isn’t doing. What we’ve found is that Google is doing a decent job of it, and that there are definitely different ground rules when it comes to different kinds of local intent.

HM: Knowing what you do about Google’s interpretation of local intent, what is the biggest mistake marketers can make when it comes to localized ads?

RB: This isn’t a mistake that’s been made, rather, a heads up based on findings from the research I’ll be presenting. But something to keep in mind is that ads are more likely to appear when a location is specified in the search query, like the city name or neighbourhood. So, if you’re looking for less paid competition, it’s a good idea to target keywords that aren’t geo-modified.

HM: Should local search be a priority for everyone? When does it matter more than less, depending on a business’ needs?

RB: For Google, every SERP is a localized one. We know that it’s one of the more influential factors that Google filters its search results through. So, even if local isn’t important for your business, it’s still worth tracking a sample of your keywords in specific locations so you can see what your searchers are actually seeing.

HM: Let’s talk featured snippets. You’ve said they’re rising in importance, appearing in just 9% of searches two years ago compared to 31% by the end of last year. When creating content, what can we do for the best chance at being “snippeted”?

RB: Focus on creating great content and optimizing that content to appear on the first page. At STAT, we’ve found that 99% of snippets are sourced from ranks two through ten, with a majority coming from ranks three through four (when rank one is the snippet).

You’ll also want to research the types of formats appearing in the featured snippets for keywords you’re targeting, for instance paragraph, list, or table, and match them.

HM: Say I only have one day to try and improve my rankings. What should I focus on first to make the biggest impact?

RB: First thing’s first: spend the time making sure that your Google My Business listings are all accurate, consistent, and complete.

Want even more actionable marketing tips? Read our interview with fellow CTAConf 2018 speaker and product positioning genius April Dunford for advice on successfully launching a new product or offering into a noisy market.

Cyrus Shepard on what matters now for ranking in 2018 (and beyond)

Cyrus Shepard has been in the SEO game for nearly ten years, most recently heading up SEO and Content Development at Moz before founding his own digital agency, Zyppy. He’s written on pretty much every facet of search optimization (check out his Moz profile) and spoken at conferences around the world—with Call to Action Conference up next.

In his talk, SEO Success: One Engagement Metric to Rule Them All, Cyrus will cover what Google’s really watching when it comes to rankings and how to use that information to turn clicks into conversions. So we mined his SEO brain for a preview.

Hayley Mullen: It can feel like Google’s constantly updating its ranking factors. What should always be a priority when we’re trying to rank?

Cyrus Shepard: Google updates its algorithms hundreds of times a year, although only a few of those could be considered major core algorithm updates. That said, the critical SEO success factors stay incredibly consistent. These include:

  • Content that answers the user query
  • Content that’s crawlable and accessible to search engines
  • The quality and quantity of links

HM: What’s been the most significant change in Google’s ranking factors, in your opinion? What do you anticipate for the near and distant future?

CS: The most significant change in the past couple of years, in my opinion, has been the rise of featured snippets. For the first time, we’re actually seeing fewer clicks per impressions as Google is more frequently delivering answers directly in search results.

For websites that win featured snippets, they can often expect more traffic and less visibility. For everyone else, they can expect traffic and visibility to slightly decrease.

HM: Oof—what does that mean for marketers overall?

CS: It’s definitely a dilemma that I don’t have an answer for right now. On one hand, the “no click” search is a growing risk. On the other hand, Google continues to send billions of visits to publishers.

The challenge is that Google maintains monopoly power over search results, so we’re forced to play by Google’s rules and, say, optimize for featured snippets. We continue to give away more data to Google with the understanding that they will reward us with more web traffic, but the amount of data we give keeps rising while Google keeps more of the traffic for themselves.

HM: How much of a difference does speed really make, specifically in regards to AMP (accelerated mobile pages)? What are the top three things we can do to satisfy Google’s need for speed?

CS: Speed is hugely important and not only for AMP. Speed is a huge ranking factor because it impacts so many other elements that impact your search visibility. For example, bounce rate is highly correlated with speed—a site that loads a second slower is abandoned at a much higher rate. This will affect multiple aspects of SEO down the line.

In regards to AMP, they actually have advantages beyond speed that some folks aren’t aware of:

  • These pages can qualify for Google News carousels
  • Google marks them with an AMP symbol, which can increase clicks
  • Chrome pre-renders AMP results, making them load instantly

HM: Your talk at CTAConf is all about what Google’s watching in terms of how people interact with your site. Without giving away the most important point, what’s the one thing Google’s always taking into consideration (and one thing that doesn’t matter as much as we may think)?

CS: Google is likely always evaluating user satisfaction. User satisfaction goes by different names, including task completion, pogo-sticking, dwell time, and more. The basic idea is “does this page answer the user query?” or “does this user need to search other webpages for the right answer?” Exactly how Google does this is up for debate.

A metric that likely doesn’t matter as much as people think is bounce rate. That doesn’t mean it’s not a useful metric—but bounce rate alone doesn’t tell us much.

And with that, our search for answers on search just got a little easier. There’s a lot more knowledge to be shared at Call to Action Conference from both Rob and Cyrus—just two of the many reasons you should totally come! “Use the code “CTAConfSEO” at checkout until July 31, 2018 for 15% off all single, group, and customer ticket rates. You’ll not only learn how to tame the search beast, but hone your chops in every facet of digital marketing too.

Originally posted here: 

Ranking in Search in 2018: A Q&A With SEO Pros Rob Bucci and Cyrus Shepard

Thumbnail

Don’t Use The Placeholder Attribute




Don’t Use The Placeholder Attribute

Eric Bailey



Introduced as part of the HTML5 specification, the placeholder attribute “represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format.”

This seemingly straightforward attribute contains a surprising amount of issues that prevent it from delivering on what it promises. Hopefully, I can convince you to stop using it.

Technically Correct

Inputs are the gates through which nearly all e-commerce has to pass. Regardless of your feelings on the place of empathy in design, unusable inputs leave money on the table.

The presence of a placeholder attribute won’t be flagged by automated accessibility checking software. However, this doesn’t necessarily mean it’s usable. Ultimately, accessibility is about people, not standards, so it is important to think about your interface in terms beyond running through a checklist.

Call it remediation, inclusive design, universal access, whatever. The spirit of all these philosophies boils down to making things that people—all people—can use. Viewed through this lens, placeholder simply doesn’t hold up.

The Problems

Translation

Browsers with auto-translation features such as Chrome skip over attributes when a request to translate the current page is initiated. For many attributes, this is desired behavior, as an updated value may break underlying page logic or structure.

One of the attributes skipped over by browsers is placeholder. Because of this, placeholder content won’t be translated and will remain as the originally authored language.

If a person is requesting a page to be translated, the expectation is that all visible page content will be updated. Placeholders are frequently used to provide important input formatting instructions or are used in place of a more appropriate label element (more on that in a bit). If this content is not updated along with the rest of the translated page, there is a high possibility that a person unfamiliar with the language will not be able to successfully understand and operate the input.

This should be reason enough to not use the attribute.

While we’re on the subject of translation, it’s also worth pointing out that location isn’t the same as language preference. Many people set their devices to use a language that isn’t the official language of the country reported by their browser’s IP address (to say nothing of VPNs), and we should respect that. Make sure to keep your content semantically described—your neighbors will thank you!

Interoperability

Interoperability is the practice of making different systems exchange and understand information. It is a foundational part of both the Internet and assistive technology.

Semantically describing your content makes it interoperable. An interoperable input is created by programmatically associating a label element with it. Labels describe the purpose of an input field, providing the person filling out the form with a prompt that they can take action on. One way to associate a label with an input, is to use the for attribute with a value that matches the input’s id.

Without this for/id pairing, assistive technology will be unable to determine what the input is for. The programmatic association provides an API hook that software such as screen readers or voice recognition can utilize. Without it, people who rely on this specialized software will not be able to read or operate inputs.


A diagram demonstrating how code gets converted into a rendered input, and how the code’s computed properties get read by assistive technology. The code is a text input with a label that reads Your Name. The listed computed properties are the accessible name, which is Your Name, and a role of textbox.


How semantic markup is used for both visual presentation and accessible content. (Large preview)

The reason I am mentioning this is that placeholder is oftentimes used in place of a label element. Although I’m personally baffled by the practice, it seems to have gained traction in the design community. My best guess for its popularity is the geometrically precise grid effect it creates when placed next to other label-less input fields acts like designer catnip.


Facebook’s signup form. A heading reads, “Sign Up. It’s free and always will be.” Placeholders are being used as labels, asking for your first name, last name, mobile number or email, and to create a new password for your account Screenshot.


An example of input grid fetishization from a certain infamous blue website. (Large preview)

The floating label effect, a close cousin to this phenomenon, oftentimes utilizes the placeholder attribute in place of a label, as well.

A neat thing worth pointing out is that if a label is programmatically associated with an input, clicking or tapping on the label text will place focus on the input. This little trick provides an extra area for interacting with the input, which can be beneficial to people with motor control issues. Placeholders acting as labels, as well as floating labels, cannot do that.

Cognition

The 2016 United States Census lists nearly 15 million people who report having cognitive difficulty — and that’s only counting individuals who choose to self-report. Extrapolating from this, we can assume that cognitive accessibility concerns affect a significant amount of the world’s population.

Self-reporting is worth calling out, in that a person may not know, or feel comfortable sharing that they have a cognitive accessibility condition. Unfortunately, there are still a lot of stigmas attached to disclosing this kind of information, as it oftentimes affects things like job and housing prospects.

Cognition can be inhibited situationally, meaning it can very well happen to you. It can be affected by things like multitasking, sleep deprivation, stress, substance abuse, and depression. I might be a bit jaded here, but that sounds a lot like conditions you’ll find at most office jobs.

Recall

The umbrella of cognitive concerns covers conditions such as short-term memory loss, traumatic brain injury, and Attention Deficit Hyperactivity Disorder. They can all affect a person’s ability to recall information.

When a person enters information into an input, its placeholder content will disappear. The only way to restore it is to remove the information entered. This creates an experience where guiding language is removed as soon as the person attempting to fill out the input interacts with it. Not great!

An input called “Your Birthdate” being filled out. The placeholder reads, “MM/DD/YYY” and the animation depicts the person filling it out getting to the year portion and having to delete the text to be able to go back and review what the proper formatting is.
Did they want MM/DD/YY, or MM/DD/YYYY? (Large preview)

When your ability to recall information is inhibited, it makes following these disappearing rules annoying. For inputs with complicated requirements to satisfy—say creating a new password—it transcends annoyance and becomes a difficult barrier to overcome.

An input called “Create a Password” being filled out. The placeholder reads, “8-15 characters, including at least 3 numbers and 1 symbol.” and the animation depicts the person filling it out having to delete the text to be able to go back and review what the password requirements are.
Wait—what’s the minimum length? How many numbers do they want again? (Large preview)

While more technologically-sophisticated people may have learned clever tricks such as cutting entered information, reviewing the placeholder content to refresh their memory, then re-pasting it back in to edit, people who are less technologically literate may not understand why the help content is disappearing or how to bring it back.

Digital Literacy

Considering that more and more of the world’s population is coming online, the onus falls on us as responsible designers and developers to make these people feel welcomed. Your little corner of the Internet (or intranet!) could very well be one of their first experiences online — assuming that the end user “will just know” is simple arrogance.

For US-based readers, a gentle reminder that new may not mean foreign. Access is on the rise for older Americans. While digital literacy will become more commonplace among older populations as time marches on, accessibility issues will as well.

For someone who has never encountered it before, placeholder text may look like entered content, causing them to skip over the input. If it’s a required field, form submission will create a frustrating experience where they may not understand what the error is, or how to fix it. If it’s not a required field, your form still runs the unnecessary risk of failing to collect potentially valuable secondary information.

Utility

Placeholder help content is limited to just a string of static text, and that may not always be sufficient to communicate the message. It may need to have additional styling applied to it, or contain descriptive markup, attributes, images, and iconography.

This is especially handy in mature design systems. The additional styling options created by moving the string of text out of the input element means it can take advantage of the system’s design tokens, and all the benefits that come with using them.

Placeholder text’s length is also limited to the width of the input it is contained in. In our responsive, mobile-first world, there stands a very good chance that important information could be truncated:


An input called Your YAMA Code, with a truncated placeholder that reads, You can find this code on the ba-


I guess I’ll never know where that code is. (Large preview)

Vision

Color Contrast

The major browsers’ default styles for placeholder content use a light gray color to visually communicate that it is a suggestion. Many custom input designs follow this convention by taking the color of input content and lightening it.

Unfortunately, this technique is likely to run afoul of color contrast issues. Color contrast is a ratio determined by comparing the luminosity of the text and background color values; in this case, it’s the color of the placeholder text over the input’s background.

See the Pen Default browser placeholder contrast ratios by Eric Bailey (@ericwbailey) on CodePen.

If the placeholder content has a contrast ratio that is too low to be perceived, it means that information critical to filling out a form successfully may not be able to be seen by people experiencing low vision conditions. For most common input font sizing, the ratio is 4.5:1.

Like all accessibility concerns, low vision conditions can be permanent or temporary, biological or environmental, or a combination. Biological disabilities include conditions like farsightedness, color blindness, dilated pupils, and cataracts. Environmental conditions include circumstances such as the glare of the mid-day sun, a battery-saving low brightness setting, privacy screens, grease and makeup left on your screen by your last phone call, and so on.

This ratio isn’t some personal aesthetic preference that I’m trying to force onto others arbitrarily. It’s part of a set of painstakingly-developed rules that help ensure that the largest possible swath of people can operate digital technology, regardless of their ability or circumstance. Consciously ignoring these rules is to be complicit in practicing exclusion.

And here’s the rub: In trying to make placeholder attributes inclusive, the updated higher contrast placeholder content color may become dark enough to be interpreted as entered input, even by more digitally literate people. This swings the issue back into cognitive concerns land.


The email address field on GoFundMe’s password reset page has a placeholder that reads email@address.com and is set to a dark black color that makes it look like entered input. Screenshot.


The placeholder text color on GoFundMe’s password reset page makes it appear like entered input. Additionally, the checkmark icon on the Request New Password button makes it seem like the request has already been processed. (Large preview)

High Contrast Mode

The Windows operating system contains a feature called High Contrast Mode. When activated, it assigns new colors to interface elements from a special high contrast palette that uses a limited number of color options. Here’s an example of what it may look like:


An input field with a label that reads “Donation amount” and a placeholder that reads “$25.00.” The screenshot is taken with Windows High Contrast mode active, so the placeholder element looks like entered text content. Screenshot.


Windows 10 set to use the High Contrast Mode 1 theme running Internet Explorer 11. (Large preview)

In High Contrast Mode, placeholder content is assigned one of those high contrast colors, making it look like pre-filled information. As discussed earlier, this could prevent people from understanding that the input may need information entered into it.

You may be wondering if it’s possible to update the styling in High Contrast Mode to make a placeholder more understandable. While it is possible to target High Contrast Mode in a media query, I implore you not to do so. Front-end developer Hugo Giraudel said it best:

“High contrast mode is not about design anymore but strict usability. You should aim for highest readability, not color aesthetics.”

The people that rely on High Contrast Mode use it because of how predictable it is. Unduly altering how it presents content may interfere with the only way they can reliably use a computer. In the case of lightening the color of placeholder content to make it appear like its non-High Contrast Mode treatment, you run a very real risk of making it impossible for them to perceive.

A Solution

To recap, the placeholder attribute:

  • Can’t be automatically translated;
  • Is oftentimes used in place of a label, locking out assistive technology;
  • Can hide important information when content is entered;
  • Can be too light-colored to be legible;
  • Has limited styling options;
  • May look like pre-filled information and be skipped over.

Eesh. That’s not great. So what can we do about it?

Design

Move the placeholder content above the input, but below the label:


An input with a label that reads, Your employee ID number, and help content below the label that reads, Can be found on your employee intranet profile. Example: a1234567-89. The example ID has been styled using a monospaced font.


Large preview

This approach:

  • Communicates a visual and structural hierarchy:
    • What this input is for,
    • Things you need to know to use the input successfully, and
    • the input itself.
  • Can be translated.
  • Won’t look like pre-filled information.
  • Can be seen in low vision circumstances.
  • Won’t disappear when content is entered into the input.
  • Can include semantic markup and be styled via CSS.

Additionally, the help content will be kept in view when the input is activated on a device with a software keyboard. If placed below the input, the content may be obscured when an on-screen keyboard appears at the bottom of the device viewport:


iOS’ on-screen keyboard is obscuring information about password requirements on a “Set a password” input. Screenshot.


Content hidden by an on-screen keyboard. 3rd party keyboards with larger heights may have a greater risk of blocking important content. (Large preview)

Development

Here’s how to translate our designed example to code:

<div class="input-wrapper">
  <label for="employee-id">
    Your employee ID number
  </label>
  <p
    id="employee-id-hint"
    class="input-hint">
    Can be found on your employee intranet profile. Example: <samp>a1234567-89</samp>.
  </p>
  <input
    id="employee-id"
    aria-describedby="employee-id-hint"
    name="id-number"
    type="text" />
</div>

This isn’t too much of a departure from a traditional accessible for/id attribute pairing: The label element is programmatically associated with the input via its id declaration of “employee-id”. The p element placed between the label and input elements acts as a replacement for a placeholder attribute.

“So,” you may be wondering. “Why don’t we just put all that placeholder replacement content in the label element? It seems like it’d be a lot less work!” The answer is that developer convenience shouldn’t take priority over user experience.

By using aria-describedby to programmatically associate the input with the p element, we are creating a priority of information for screen readers that has parity with what a person browsing without a screen reader would experience. aria-describedby ensures that the p content will be described last, after the label’s content and the kind of input it is associated with.

In other words, it’s what content the input is asking for, what type of input it is, then additional help if you need it — exactly what someone would experience if they look at form input.

User experience encompasses all users, including those who navigate with the aid of screen readers. The help content is self-contained and easy to navigate to and from, should the person using a screen reader need to re-reference it. As it is a self-contained node, it can also be silenced (typically with the Control key) without risking muting other important information.

Including the help content as part of the label makes it unnecessarily verbose. labels should be meaningful, but also concise. Adding too much information to a label may have the opposite of the desired effect, making it too long to recall or simply too frustrating to listen to all the way through. In fact, the Web Content Accessibility Guidelines has rules that specifically address this: Success Criteria 2.4.6 and 3.3.2.

Example

Here is the solution implemented in live code:

See the Pen Don’t use the placeholder attribute by Eric Bailey (@ericwbailey) on CodePen.

And here’s a video demonstrating how popular screen readers handle it:

A Better Solution

“The less an interface requires of its users, the more accessible it is.”

Alice Boxhall

A final thought: Do you even need that additional placeholder information?

Good front-end solutions take advantage of special input attributes and accommodating validation practices to prevent offloading the extra work onto the person who simply just wants to use your site or app with as little complication as possible.

Good copywriting creates labels that clearly and succinctly describe the input’s purpose. Do a good enough job here and the label cuts through the ambiguity, especially if you test it beforehand.

Good user experience is all about creating intelligent flows that preempt people’s needs, wants, and desires by capitalizing on existing information to remove as many unnecessary questions as possible.

Accommodating the people who use your website or web app means taking a critical eye at what you take for granted when you browse the Internet. By not making assumptions about other people’s circumstances — including the technology they use — you can do your part to help prevent exclusion.

Take some time to review your design and code and see what doesn’t stand up to scrutiny — checking to see if you use the placeholder attribute might be a good place to start.

Standing on the shoulders of giants. Thanks to Roger Johansson, Adam Silver, Scott O’Hara, and Katie Sherwin for their writing on the subject.

Smashing Editorial
(rb, ra, yk, il)


More here: 

Don’t Use The Placeholder Attribute

Thumbnail

BEM For Beginners: Why You Need BEM




BEM For Beginners: Why You Need BEM

Inna Belaya



BEM makes your code scalable and reusable, thus increasing productivity and facilitating teamwork. Even if you are the only member of the team, BEM can be useful for you. Nevertheless, many developers believe that such a system approach like BEM puts additional boundaries on their project and makes your project overloaded, cumbersome, and slow.

We’ll be collecting all of the main aspects of BEM in a condensed form. This article helps you understand the basic ideas of BEM in just 20 minutes, and to reject prejudices that the system approach is detrimental to your project.

The Big BEM consists of Methodology, Technologies, Libraries, and Tools. In this article, we’ll talk more about the methodology itself because it is the concentrated experience of a huge number of developers and it brings a systematic approach to any project.

In order to show you some practical cases of BEM, we’ll touch on the BEM technologies and completely skip the libraries and tools.

From theory to practice:

So, is BEM a hero or a villain? It’s up to you! But first, read the article.


BEM as a Batman logo


BEMBatman

The Main Reasons Why We Do Not Use Any Selectors Except Classes

One of the basic rules of the BEM methodology is to use only class selectors. In this section, we’ll explain why.

  • Why don’t we use IDs?
  • Why don’t we use tag selectors?
  • Why don’t we use a universal selector?
  • Why don’t we use CSS reset?
  • Why don’t we use nested selectors?
  • Why don’t we combine a tag and a class in a selector?
  • Why don’t we use combined selectors-
  • Why don’t we use attribute selectors?

We Don’t Use IDs (ID Selectors)

The ID provides a unique name for an HTML element. If the name is unique, you can’t reuse it in the interface. This prevents you from reusing the code.

Common Misconceptions
  1. IDs are required for using JavaScript.
    Modern browsers can work with either IDs or classes. Any type of selector is processed at the same rate in the browser.
  2. IDs are used with the <label> tag.
    If you place <label> inside a control, it doesn’t need an ID. Instead of <input id="ID"><label for="ID">Text</label>, simply use <label><input type="...">Text</label>.

We Don’t Use Tag Selectors

HTML page markup is unstable: A new design can change the nesting of the sections, heading levels (for example, from <h1> to <h3>) or turn the <p> paragraph into the <div> tag. Any of these changes will break styles that are written for tags. Even if the design doesn’t change, the set of tags is limited. To use an existing layout in another project, you have to solve conflicts between styles written for the same tags.

An extended set of semantic tags can’t meet all layout needs, either.

An example is when the page header contains a logo. A click on the logo opens the main page of the site (index). You can mark it up with tags by using the <img> tag for the image and the <a> tag for the link.

<header>
  <a href="/">
    <img src="img.logo.png" alt="Logo">
  </a>
</header>

To distinguish between the logo link and an ordinary link in the text, you need extra styles. Now remove underlining and the blue color from the logo link:

header a 
  ...

The logo link doesn’t need to be shown on the main page, so change the index page markup:

<header>
  <!-- the <a> tag is replaced with <span> -->
  <span>
    <img src="img.logo.png" alt="Logo">
  </span>
</header>

You don’t need to remove the underlining and the blue color for the <span> tag. So let’s make general rules for the logo link from different pages:

header a,
header span

  ...

At first glance, this code seems all right, but imagine if the designer removes the logo from the layout. The selector names don’t help you understand which styles should be removed from the project with the logo. The “header a” selector doesn’t show the connection between the link and the logo. This selector could belong to the link in the header menu or, for example, to the link to the author’s profile. The “header span” selector could belong to any part of the header.

To avoid confusion, just use the logo class selector to write the logo styles:

.logo 
  ...

We Don’t Use CSS Reset

CSS reset is a set of global CSS rules created for the whole page. These styles affect all layout nodes, violate the independence of components, and make it harder to reuse them.

In BEM, “reset” and “normalize” aren’t even used for a single block. Resetting and normalization cancel existing styles and replace them with other styles, which you will have to change and update later in any case. As a result, the developer has to write styles that override the ones that were just reset.

We Don’t Use The Universal Selector (*)

The universal selector indicates that the project features a style that affects all nodes in the layout. This limits reuse of the layout in other projects:

  • You have to additionally transfer the styles with an asterisk to the project. But in this case, the universal selector might affect the styles in the new project.
  • The styles with an asterisk must be added to the layout you are transferring.

In addition, a universal selector can make the project code unpredictable. For example, it can affect the styles of the universal library components.

Common styles don’t save you time. Often developers start by resetting all margins for components (* margin: 0; padding: 0; ), but then they still set them the same as in the layout (for example, margin: 12px; padding: 30px;).

We Don’t Use Nested Selectors

Nested selectors increase code coupling and make it difficult to reuse the code.

The BEM methodology doesn’t prohibit nested selectors, but it recommends not to use them too much. For example, nesting is appropriate if you need to change styles of the elements depending on the block’s state or its assigned theme.

.button_hovered .button__text

  text-decoration: underline;

.button_theme_islands .button__text

  line-height: 1.5;

We Don’t Use Combined Selectors

Combined selectors are more specific than single selectors, which makes it more difficult to redefine blocks.

Consider the following code:

<button class="button button_theme_islands">...</button>

Let’s say you set CSS rules in the .button.button_theme_islands selector to do less writing. Then you add the “active” modifier to the block:

<button class="button button_theme_islands button_active">...</button>

The .button_active selector doesn’t redefine the block properties written as .button.button_theme_islands because .button.button_theme_islands is more specific than .button_active. To redefine it, combine the block modifier selector with the .button selector and declare it below the .button.button_theme_islands because both selectors are equally specific:

.button.button_theme_islands {}
.button.button_active {}

If you use simple class selectors, you won’t have problems redefining the styles:

.button_theme_islands {}
.button_active {}
.button {}

We Don’t Combine A Tag And A Class In A Selector

Combining a tag and a class in the same selector (for example, button.button) makes CSS rules more specific, so it is more difficult to redefine them.

Consider the following code:

<button class="button">...</button>

Let’s say you set CSS rules in the button.button selector.
Then you add the active modifier to the block:

<button class="button button_active">...</button>

The .button_active selector doesn’t redefine the block properties written as button.button because button.button is more specific than .button_active. To make it more specific, you should combine the block modifier selector with the button.button_active tag.

As the project develops, you might end up with blocks with input.button, span.button or a.button selectors. In this case, all modifiers of the button block and all its nested elements will require four different declarations for each instance.

Possible Exceptions

In rare cases, the methodology allows combining tag and class selectors. For example, this can be used for setting the comments style in CMS systems that can’t generate the correct layout.

You can use the comment to write a text, insert images, or add markup. To make them match the site design, the developer can pre-define styles for all tags available to the user and cascade them down to the nested blocks:

<div class="content">
  ... <!-- the user’s text -->
</div>
CSS rules:
.content a 
  ...

.content p 
  font-family: Arial, sans-serif;
  text-align: center;

We Don’t Use Attribute Selectors

Attribute selectors are less informative than class selectors. As proof, consider an example with a search form in the header:

<header>
  <form action="/">
    <input name="s">
    <input type="submit">
  </form>
</header>

Try using selector attributes to write the form styles:

header input[type=submit],
header input[type=checkbox] 
  width: auto;
  margin-right: 20px;

header input[type=checkbox] 
  margin: 0;

In this example, you can’t tell for sure from the selector name that the styles belong to the search form. Using classes makes it clearer. Classes don’t have restrictions that prevent you from writing clearly. For example, you can write it like this:

.form .search 
  ...

Now the code is less ambiguous, and it’s clear that the styles belong to the search form.

But the nested selectors still make the CSS rules more specific and prevent you from transferring the layout between projects. To get rid of nesting, use BEM principles.

Summary: class is the only selector that allows you to isolate the styles of each component in the project; increase the readability of the code and do not limit the re-use of the layout.

CSS styles isolation is the most frequent start point of the BEM journey. But this is the least that BEM can give you. To understand how isolated independent components are arranged in BEM, you need to learn the basic concepts, i.e. Block, Element, Modifier, and Mix. Let’s do this in the next section.

The Basics Of BEM

Block And Elements

The BEM methodology is a set of universal rules that can be applied regardless of the technologies used, such as CSS, Sass, HTML, JavaScript or React.

BEM helps to solve the following tasks:

  • Reuse the layout;
  • Move layout fragments around within a project safely;
  • Move the finished layout between projects;
  • Create stable, predictable and clear code;
  • Reduce the project debugging time.

In a BEM project, the interface consists of blocks that can include elements. Blocks are independent components of the page. An element can’t exist outside the block, so keep in mind that each element can belong to one block only.

The first two letters in BEM stand for Blocks and Elements. The block name is always unique. It sets the namespace for elements and provides a visible connection between the block parts. Block names are long but clear in order to show the connection between components and to avoid losing any parts of these components when transferring the layout.

To see the full power of BEM naming, consider this example with a form. According to the BEM methodology, the form is implemented using the form block. In HTML, the block name is included in the class attribute:

<form class="form" action="/">

All parts of the form (the form block) that don’t make sense on their own are considered its elements. So the search box (search) and the button (submit) are elements of the form block. Classes also indicate that an element belongs to the block:

<form class="form" action="/">
  <input class="form__search" name="s">
  <input class="form__submit" type="submit">
</form>

Note that the block’s name is separated from the element’s name with a special separator. In the BEM classic naming scheme, two underscores are used as a separator. Anything can work as a separator. There are alternative naming conventions, and each developer chooses the one that suits them. The important thing is that separators allow you to distinguish blocks from elements and modifiers programmatically.

Selector names make it clear that in order to move the form to another project, you need to copy all of its components:

.form__search {}
.form__submit {}

Using blocks and elements for class names solves an important problem: It helps us get rid of nested selectors. All selectors in a BEM project have the same weight. That means it is much easier to redefine styles written according to BEM. Now, to use the same form in another project, you can just copy its layout and styles.

The idea of the naming of BEM components is that you can explicitly define the connection between the block and its elements.

Modifiers And Mixes

Officially, “M” stands for Modifier, but it also implies one more important notion in BEM: “mix”. Both modifiers and mixes make changes to a block and its elements. Let’s take a closer look at this.

Modifiers

A modifier defines the look, state and behavior of a block or an element. Adding modifiers is optional. Modifiers let you combine different block features, as you can use any number of modifiers. But a block or an element can’t be assigned different values of the same modifier.

Let’s explore how modifiers work.

Imagine the project needs the same search form as in the example above. It should have the same functions but look different (for example, the search forms in the header and in the footer of the page should differ). The first thing you can do to change the appearance of the form is to write additional styles:

header .form {}
footer .form {}

The header .form selector has more weight than the form selector, which means that one rule will override the other one. But as we have discussed, nested selectors increase code coupling and make reuse difficult, so this approach doesn’t work for us.

In BEM, you can use a modifier to add new styles to the block:

<!-- Added the form_type_original modifier-->
<form class="form form_type_original" action="/">
  <input class="form__search" name="s">
  <input class="form__submit" type="submit">
</form>

The line <form class="form form_type_original"></form> indicates that the block was assigned a type modifier with the original value. In a classic scheme, the modifier name is separated from the block or element name with an underscore.

The form can have a unique color, size, type, or design theme. All these parameters can be set with a modifier:

<form class="form form_type_original form_size_m form_theme_forest">

The same form can look different but stay the same size:

<form class="form form_type_original form_size_m form_theme_forest"></form>
<form class="form form_type_original form_size_m form_theme_sun"></form>

But the selectors for each modifier will still have the same weight:

.form_type_original {}
.form_size_m {}
.form_theme_forest {}

Important: A modifier contains only additional styles that change the original block implementation in some way. This allows you to set the appearance of a universal block only once, and add only those features that differ from the original block code into the modifier styles.

.form 
  /* universal block styles */

.form_type_original 
  /* added styles */

This is why a modifier should always be on the same DOM node with the block and the element it is associated with.

<form class="form form_type_original"></form>

You can use modifiers to apply universal components in very specific cases. The block and element code doesn’t change. The necessary combination of modifiers is created on the DOM node.

Mixes

A mix allows you to apply the same formatting to different HTML elements and combine the behavior and styles of several entities while avoiding code duplication. They can replace abstract wrapper blocks.

A mix means that you host several BEM entities (blocks, elements, modifiers) on a single DOM node. Similar to modifiers, mixes are used for changing blocks. Let’s look at some examples of when you should use a mix.

Blocks can differ not only visually but also semantically. For example, a search form, a registration form and a form for ordering cakes are all forms. In the layout, they are implemented with the “form” block but they don’t have any styles in common. It is impossible to handle such differences with a modifier.
You can define common styles for such blocks but you won’t be able to reuse the code.

.form,
.search,
.register 
  ...

You can use a mix to create semantically different blocks for the same form:

<form class="form" action="/">
  <input class="form__search" name="s">
  <input class="form__submit" type="submit">
</form>

The .form class selector describes all styles that can be applied to any form (order, search or registration):

.form {}

Now you can make a search form from the universal form. To do this, create an additional search class in the project. This class will be responsible only for the search. To combine the styles and behavior of the.formand.search classes, place these classes on a single DOM node:


<form class="form search" action="/">
  <input class="form__search" name="s">
  <input class="form__submit" type="submit">
</form>

In this case, the .search class is a separate block that defines behavior. This block can’t have modifiers responsible for the form, themes, and sizes. These modifiers already belong to the universal form. A mix helps to combine the styles and behavior of these blocks.

Let’s take one more example where the component’s semantics is changed. Here is a navigation menu in the page header in which all entries are links:

<nav class="menu">
  <a class="link" href=""></a>
  <a class="link" href=""></a>
  <a class="link" href=""></a>
</nav>

The link functionality is already implemented in the link block, but the menu links have to differ visually from the links in the text. There are several ways to change the menu links:

  1. Create a menu entry modifier that turns the entry into a link:
    <nav class="menu">
      <a class="menu__item menu__item_link" href=""></a>
      <a class="menu__item menu__item_link" href=""></a>
      <a class="menu__item menu__item_link" href=""></a>
    </nav>
    

    In this case, to implement the modifier, you should copy the `link` block behavior and styles. This will lead to code duplication.

  2. Use a mix of the `link` universal block and the `item` element of the `menu` block:
    <nav class="menu">
      <a class="link menu__item" href=""></a>
      <a class="link menu__item" href=""></a>
      <a class="link menu__item" href=""></a>
    </nav>
    

    With the mix of the two BEM entities, you can now implement the basic link functionality from the `link` block and additional CSS rules from the `menu` block, and avoid code duplication.

External Geometry And Positioning: Giving Up Abstract HTML Wrappers

Mixes are used to position a block relative to other blocks or to position elements inside a block. In BEM, styles responsible for geometry and positioning are set in the parent block. Let’s take a universal menu block that has to be placed in the header. In the layout, the block has to have a 20px indent from the parent block.

This task has several solutions:

  1. Write styles with indents for the menu block:
    .menu 
      margin-left: 20px;
    
    

    In this case, the “menu” block isn’t universal anymore. If you have to place the menu in the page footer, you will have to edit styles because the indents will probably be different.

  2. Create the menu block modifier:
    <div>
      <ul class="menu menu_type_header">
        <li class="menu__item"><a href=""></a></li>
        <li class="menu__item"><a href=""></a></li>
        <li class="menu__item"><a href=""></a></li>
      </ul>
    </div>
    
    .menu_type_header 
      margin-left: 20px;
    
    .menu_type_footer 
      margin-left: 30px;
    
    

    In this case, the project will include two kinds of menus, although this is not the case. The menu stays the same.

  3. Define the external positioning of the block:  nest the `menu` block in the abstract wrapper (for example, the `wrap` block) setting all indents:
    <div class="wrap">
      <ul class="menu">
        <li class="menu__item"><a href=""></a></li>
        <li class="menu__item"><a href=""></a></li>
        <li class="menu__item"><a href=""></a></li>
      </ul>
    </div>
    

    To avoid the temptation to create modifiers and change the block styles to position the block on the page, you need to understand one thing:

    The indent from a parent block isn’t a feature of the nested block. It is a feature of the parent block. It has to know that the nested block has to be indented from the border by a certain number of pixels.

  4. Use a mix. The information about nested block positioning is included in the parent block elements. Then the parent block element is mixed into the nested block. In this case, the nested block doesn’t specify any indents and can be easily reused in any place.

Let’s go on with our example:

<div>
  <ul class="menu header__menu">
    <li class="menu__item"><a href=""></a></li>
    <li class="menu__item"><a href=""></a></li>
    <li class="menu__item"><a href=""></a></li>
  </ul>
</div>

In this case, external geometry and positioning of the menu block are set through the header__menu element. The menu block doesn’t specify any indents and can be easily reused.

The parent block element (in our case it is header__menu) performs the task of the wrapper blocks responsible for external positioning of the block.

Blocks In The File Structure

All BEM projects have a similar file structure. The familiar file structure makes it easier for developers to navigate the project, switch between projects, and move blocks from one project to another.

The implementation of each block is stored in a separate project folder. Each technology (CSS, JavaScript, tests, templates, documentation, images) is in a separate file.

For example, if the input block appearance is set with CSS, the code is saved in the input.css file.

project
  common.blocks/
    input/
      input.css # The "input" block implementation with CSS
      input.js  # The "input" block implementation with JavaScript

The code for modifiers and elements is also stored in separate files of the block. This approach allows you to include in the build only those modifiers and elements that are necessary for the implementation of the block.

project
  common.blocks/
    input/
      input.css           # The "input" block implementation with CSS
      input.js            # The "input" block implementation with JavaScript
      input_theme_sun.css # The "input_theme_sun" modifier implementation
      input__clear.css    # The "input__clear" element implementation with CSS
      input__clear.js     # The "input__clear" element implementation with JavaScript

To improve the project navigation, combine block modifiers with multiple values in directories.

The file structure of any BEM project consists of redefinition levels (you can learn more on them over here). Redefinition levels allow you to:

  • Divide the project into platforms;
  • Easily update the block libraries included in the project;
  • Use common blocks to develop multiple projects;
  • Change the design themes without affecting the project logic;
  • Conduct experiments in a live project.

Using blocks and storing all block technologies in the same folder makes it easy to move blocks between projects. To move all styles and behavior of the block together with the layout, just copy the block folder to the new project.

Non-Evident Advantages Of The Methodology

The Convenience Of Parallel Development

In BEM, any layout is divided into blocks. Because the blocks are independent, they can be developed in parallel by several developers.

A developer creates a block as a universal component that can be reused in any other project.

An example is the bem-components block library, which contains universal blocks, such as a link, button, and input field. It is easier to create more complex blocks from universal components. For example, a selector or checkbox.

Using blocks in project layout helps you save the time on integrating code written by several developers, guarantees the uniqueness of component names, and lets you test blocks at the development stage.

Testing The Layout

It is problematic to test the functionality of the whole page, especially in a dynamic project connected to a database.

In BEM, each block is covered by tests. Tests are a block implementation technology, like Javascript or CSS. Blocks are tested at the development stage. It is easier to check the correctness of one block and then assemble the project from tested blocks. After that, all you have to do is to make sure that the block wrapper is working correctly.

Customizable Build Of A Project

For convenient development, all blocks and technologies in a BEM project are placed in separate folders and files. To combine the source files into a single file (for example, to put all CSS files in project.css, all JS files in project.js, and so on), we use the build process.

The build performs the following tasks:

  • Combines source files that are spread out across the project’s file system;
  • Includes only necessary blocks, elements, and modifiers (BEM entities) in the project;
  • Follows the order for including entities;
  • Processes the source file code during the build (e.g. compiles LESS code to CSS code).

To include only the necessary BEM entities in the build, you need to create a list of blocks, elements, and modifiers used on the pages. This list is called a declaration.

Since BEM blocks are developed independently and placed in separate files in the file system, they don’t ‘know’ anything about each other. To build blocks based on other blocks, specify dependencies. There is a BEM technology responsible for this: the deps.js files. Dependency files let the build engine know which additional blocks have to be included in the project.

Practical Case: BEM Is Not Only For CSS

In the previous sections, all code examples are for CSS. But BEM allows you to modify the behavior of the block and its representation in HTML in the same declarative way like in CSS.

How To Use Templating In BEM

In HTML, the block markup is repeated every time the block appears on the page. If you create the HTML markup manually and then need to fix an error or make changes, you will need to modify the markup for every instance of the block. To generate HTML code and apply fixes automatically, BEM uses templates; blocks are responsible for the way they are presented in HTML.

Templates allow you to:

  • Reduce the time used for project debugging, because the template changes are automatically applied to all project blocks;
  • Modify the block layout;
  • Move blocks with the current layout to another project.

BEM uses the bem-xjst template engine which features two engines:

  • BEMHTML
    Transforms the BEMJSON description of the page to HTML. The templates are described in .bemhtml.js files.
  • BEMTREE
    Transforms data to BEMJSON. The templates are described in BEMJSON format in .bemtree.js files.

If templates aren’t written for the blocks, the template engine sets the <div> tag for the blocks by default.

Compare the declaration of the blocks and the HTML output:

Declaration:


  block: 'menu',
  content: [
    
      elem: 'item',
      content: 
        block: 'link'
    },
     
      elem: 'item',
      elemMods:  current: true , // Set the modifier for the menu item
      content: 
        block: 'link'
      
    }
  ]
}

HTML:

<div class="menu">
  <div class="menu__item">
    <div class="link"></div>
  </div>
  <div class="menu__item menu__item_current">
    <div class="link"></div>
  </div>
</div>

To modify the menu block layout, you need to write templates for the block:

  1. Let’s change the menu block tag:
    block('menu')(
      tag()('menu') // Set the "menu" tag for the menu block 
    )
    

    Modified HTML:

    <menu class="menu"> <!-- Replace the "div" tag with the "menu" tag for the "menu" block -->
      <div class="menu__item">
        <div class="link"></div>
      </div>
      <div class="menu__item menu__item_current">
        <div class="link"></div>
      </div>
    </menu>
    

    Similar to CSS, the template is applied to all “menu” blocks on the page.

  2. Add an extra element (menu__inner) that works as an inner wrapper and is responsible for the layout of the elements in the menu block. Originally the menu__inner element wasn’t included in the declaration, so we have to add it when the templates are built.

    BEM templates are written in JavaScript, so you can also use JavaScript to add a new element to the template:

    block('menu')(
      tag()('menu'),
      content()(function() 
        return 
          elem: 'inner',
          content: this.ctx.content
        ;
      })
    )
    
    <menu class="menu"> <!-- Replace the "div" tag with the "menu" tag for the "menu" block -->
      <div class="menu__inner">
        <div class="menu__item">
          <div class="link"></div>
        </div>
        <div class="menu__item menu__item_current">
          <div class="link"></div>
        </div>
      </div>
    </menu>
    
  3. Replace tags for all inner and item elements:
    block('menu')(
      tag()('menu'),
      content()(function() 
        return 
          elem: 'inner',
          content: this.ctx.content
        
      }),
      elem('inner')(
        tag()('ul')
      ),
      elem('item')(
        tag()('li')
      )
    )
    
    <menu class="menu">
      <ul class="menu__inner">
        <li class="menu__item">
          <div class="link"></div>
        </li>
        <li class="menu__item menu__item_current">
          <div class="link"></div>
        </li>
      </ul>
    </menu>
    
  4. Set the <a> tag for all links on the page:
    block('menu')(
      tag()('menu'),
      content()(function() 
        return 
          elem: 'inner',
          content: this.ctx.content
        
      }),
      elem('inner')(
        tag()('ul')
      ),
      elem('item')(
        tag()('li')
      )
    );
    block('link')(
      tag()('a')
    );
    
    <menu class="menu">
      <ul class="menu__inner">
        <li class="menu__item">
          <a class="link"></a>
        </li>
        <li class="menu__item menu__item_current">
          <a class="link"></a>
        </li>
      </ul>
    </menu>
    
  5. Modify the existing template. Rules in templates are applied in the same way as in CSS: a lower rule overrides a higher rule. Add new rules to the template, and change the link tag from <a> to <span>:
    block('link')(
      tag()('a')
    );
    block('link')(
      tag()('span')
    );
    
    <menu class="menu">
      <ul class="menu__inner">
        <li class="menu__item">
          <span class="link"></span>
        </li>
        <li class="menu__item menu__item_current">
          <span class="link"></span>
        </li>
      </ul>
    </menu>
    

BEM Is A Customizable System

BEM methodology provides you strict rules to create a system in your project. But at the same time, a lot of BEM rules can be customized. BEM methodology allows you to change the naming convention, choose the most convenient file structure or add any technologies you want to the block.

Now you can tune in the system and make your own superhero of BEM!


BEM as a Captain America logo


BEM Captain America

How To Get More Out Of BEM

To start learning BEM principles, visit our website. If you have any questions you’d like to ask the team, join our Telegram channel or open up a discussion in our BEM Forum.

Smashing Editorial
(rb, ra, il)


Continue reading here: 

BEM For Beginners: Why You Need BEM

Thumbnail

Lessons Learned While Developing WordPress Plugins




Lessons Learned While Developing WordPress Plugins

Jakub Mikita



Every WordPress plugin developer struggles with tough problems and code that’s difficult to maintain. We spend late nights supporting our users and tear out our hair when an upgrade breaks our plugin. Let me show you how to make it easier.

In this article, I’ll share my five years of experience developing WordPress plugins. The first plugin I wrote was a simple marketing plugin. It displayed a call to action (CTA) button with Google’s search phrase. Since then, I’ve written another 11 free plugins, and I maintain almost all of them. I’ve written around 40 plugins for my clients, from really small ones to one that have been maintained for over a year now.

Measuring Performance With Heatmaps

Heatmaps can show you the exact spots that receive the most engagement on a given page. Find out why they’re so efficient for your marketing goals and how they can be integrated with your WordPress site. Read article →

Good development and support lead to more downloads. More downloads mean more money and a better reputation. This article will show you the lessons I’ve learned and the mistakes I’ve made, so that you can improve your plugin development.

1. Solve A Problem

If your plugin doesn’t solve a problem, it won’t get downloaded. It’s as simple as that.

Take the Advanced Cron Manager plugin (8,000+ active installations). It helps WordPress users who are having a hard time debugging their cron. The plugin was written out of a need — I needed something to help myself. I didn’t need to market this one, because people already needed it. It scratched their itch.

On the other hand, there’s the Bug — fly on the screen plugin (70+ active installations). It randomly simulates a fly on the screen. It doesn’t really solve a problem, so it’s not going to have a huge audience. It was a fun plugin to develop, though.

Focus on a problem. When people don’t see their SEO performing well, they install an SEO plugin. When people want to speed up their website, they install a caching plugin. When people can’t find a solution to their problem, then they find a developer who writes a solution for them.

As David Hehenberger attests in his article about writing a successful plugin, need is a key factor in the WordPress user’s decision of whether to install a particular plugin.

If you have an opportunity to solve someone’s problem, take a chance.

2. Support Your Product

“3 out of 5 Americans would try a new brand or company for a better service experience. 7 out of 10 said they were willing to spend more with companies they believe provide excellent service.”

— Nykki Yeager

Don’t neglect your support. Don’t treat it like a must, but more like an opportunity.

Good-quality support is critical in order for your plugin to grow. Even a plugin with the best code will get some support tickets. The more people who use your plugin, the more tickets you’ll get. A better user experience will get you fewer tickets, but you will never reach inbox 0.

Every time someone posts a message in a support forum, I get an email notification immediately, and I respond as soon as I can. It pays off. The vast majority of my good reviews were earned because of the support. This is a side effect: Good support often translates to 5-star reviews.

When you provide excellent support, people start to trust you and your product. And a plugin is a product, even if it’s completely free and open-source.

Good support is more complex than about writing a short answer once a day. When your plugin gains traction, you’ll get several tickets per day. It’s a lot easier to manage if you’re proactive and answer customers’ questions before they even ask.

Here’s a list of some actions you can take:

  • Create an FAQ section in your repository.
  • Pin the “Before you ask” thread at the top of your support forum, highlighting the troubleshooting tips and FAQ.
  • Make sure your plugin is simple to use and that users know what they should do after they install it. UX is important.
  • Analyze the support questions and fix the pain points. Set up a board where people can vote for the features they want.
  • Create a video showing how the plugin works, and add it to your plugin’s main page in the WordPress.org repository.

It doesn’t really matter what software you use to support your product. The WordPress.org’s official support forum works just as well as email or your own support system. I use WordPress.org’s forum for the free plugins and my own system for the premium plugins.

3. Don’t Use Composer

Composer is package-manager software. A repository of packages is hosted on packagist.org, and you can easily download them to your project. It’s like NPM or Bower for PHP. Managing your third-party packages the way Composer does is a good practice, but don’t use it in your WordPress project.

I know, I dropped a bomb. Let me explain.

Composer is great software. I use it myself, but not in public WordPress projects. The problem lies in conflicts. WordPress doesn’t have any global package manager, so each and every plugin has to load dependencies of their own. When two plugins load the same dependency, it causes a fatal error.

There isn’t really an ideal solution to this problem, but Composer makes it worse. You can bundle the dependency in your source manually and always check whether you are safe to load it.

Composer’s issue with WordPress plugins is still not solved, and there won’t be any viable solution to this problem in the near future. The problem was raised many years ago, and, as you can read in WP Tavern’s article, many developers are trying to solve it, without any luck.

The best you can do is to make sure that the conditions and environment are good to run your code.

4. Reasonably Support Old PHP Versions

Don’t support very old versions of PHP, like 5.2. The security issues and maintenance aren’t worth it, and you’re not going to earn more installations from those older versions.


The Notification plugin’s usage on PHP versions from May 2018. (Large preview)

Go with PHP 5.6 as a minimal requirement, even though official support will be dropped by the end of 2018. WordPress itself requires PHP 7.2.

There’s a movement that discourages support of legacy PHP versions. The Yoast team released the Whip library, which you can include in your plugin and which displays to your users important information about their PHP version and why they should upgrade.

Tell your users which versions you do support, and make sure their website doesn’t break after your plugin is installed on too low a version.

5. Focus On Quality Code

Writing good code is tough in the beginning. It takes time to learn the “SOLID” principles and design patterns and to change old coding habits.

It once took me three days to display a simple string in WordPress, when I decided to rewrite one of my plugins using better coding practices. It was frustrating knowing that it should have taken 30 minutes. Switching my mindset was painful but worth it.

Why was it so hard? Because you start writing code that seems at first to be overkill and not very intuitive. I kept asking myself, “Is this really needed?” For example, you have to separate the logic into different classes and make sure each is responsible for a single thing. You also have to separate classes for the translation, custom post type registration, assets management, form handlers, etc. Then, you compose the bigger structures out of the simple small objects. That’s called dependency injection. That’s very different from having “front end” and “admin” classes, where you cram all your code.

The other counterintuitive practice was to keep all actions and filters outside of the constructor method. This way, you’re not invoking any actions while creating the objects, which is very helpful for unit testing. You also have better control over which methods are executed and when. I wish I knew this before I wrote a project with an infinite loop caused by the actions in the constructor methods. Those kinds of bugs are hard to trace and hard to fix. The project had to be refactored.

The above are but a few examples, but you should get to know the SOLID principles. These are valid for any system and any coding language.

When you follow all of the best practices, you reach the point where every new feature just fits in. You don’t have to tweak anything or make any exceptions to the existing code. It’s amazing. Instead of getting more complex, your code just gets more advanced, without losing flexibility.

Also, format your code properly, and make sure every member of your team follows a standard. Standards will make your code predictable and easier to read and test. WordPress has its own standards, which you can implement in your projects.

6. Test Your Plugin Ahead Of Time

I learned this lesson the hard way. Lack of testing led me to release a new version of a plugin with a fatal error. Twice. Both times, I got a 1-star rating, which I couldn’t turn into a positive review.

You can test manually or automatically. Travis CI is a continuous testing product that integrates with GitHub. I’ve built a really simple test suite for my Notification plugin that just checks whether the plugin can boot properly on every PHP version. This way, I can be sure the plugin is error-free, and I don’t have to pay much attention to testing it in every environment.

Each automated test takes a fraction of a second. 100 automated tests will take about 10 minutes to complete, whereas manual testing needs about 2 minutes for each case.

The more time you invest in testing your plugin up front, the more it will save you in the long run.

To get started with automated testing, you can use the WP-CLI \`wp scaffold plugin-test\` command, which installs all of the configuration you need.

7. Document Your Work

It’s a cliche that developers don’t like to write documentation. It’s the most boring part of the development process, but a little goes a long way.

Write self-documenting code. Pay attention to variable, function and class names. Don’t make any complicated structures, like cascades that can’t be read easily.

Another way to document code is to use the “doc block”, which is a comment for every file, function and class. If you write how the function works and what it does, it will be so much easier to understand when you need to debug it six months from now. WordPress Coding Standards covers this part by forcing you to write the doc blocks.

Using both techniques will save you the time of writing the documentation, but the code documentation is not going to be read by everyone.

For the end user, you have to write high-quality, short and easy-to-read articles explaining how the system works and how to use it. Videos are even better; many people prefer to watch a short tutorial than read an article. They are not going to look at the code, so make their lives easier. Good documentation also reduces support tickets.

Conclusion

These seven rules have helped me develop good-quality products, which are starting to be a core business at BracketSpace. I hope they’ll help you in your journey with WordPress plugins as well.

Let me know in the comments what your golden development rule is or whether you’ve found any of the above particularly helpful.

Smashing Editorial
(il, ra, yk)


Link:  

Lessons Learned While Developing WordPress Plugins

Thumbnail

Monthly Web Development Update 5/2018: Browser Performance, Iteration Zero, And Web Authentication




Monthly Web Development Update 5/2018: Browser Performance, Iteration Zero, And Web Authentication

Anselm Hannemann



As developers, we often talk about performance and request browsers to render things faster. But when they finally do, we demand even more performance.

Alex Russel from the Chrome team now shared some thoughts on developers abusing browser performance and explains why websites are still slow even though browsers reinvented themselves with incredibly fast rendering engines. This is in line with an article by Oliver Williams in which he states that we’re focusing on the wrong things, and instead of delivering the fastest solutions for slower machines and browsers, we’re serving even bigger bundles with polyfills and transpiled code to every browser.

It certainly isn’t easy to break out of this pattern and keep bundle size to a minimum in the interest of the user, but we have the technologies to achieve that. So let’s explore non-traditional ways and think about the actual user experience more often — before defining a project workflow instead of afterward.

Front-End Performance Checklist 2018

To help you cater for fast and smooth experiences, Vitaly Friedman summarized everything you need to know to optimize your site’s performance in one handy checklist. Read more →

News

General

  • Oliver Williams wrote about how important it is that we rethink how we’re building websites and implement “progressive enhancement” to make the web work great for everyone. After all, it’s us who make the experience worse for our users when blindly transpiling all our ECMAScript code or serving tons of JavaScript polyfills to those who already use slow machines and old software.
  • Ian Feather reveals that around 1% of all requests for JavaScript on BuzzFeed time out. That’s about 13 million requests per month. A good reminder of how important it is to provide a solid fallback, progressive enhancement, and workarounds.
  • The new GDPR (General Data Protection Regulation) directive is coming very soon, and while our inboxes are full of privacy policy updates, one thing that’s still very unclear is which services can already provide so-called DPAs (Data Processing Agreements). Joschi Kuphal collects services that offer a DPA, so that we can easily look them up and see how we can obtain a copy in order to continue using their services. You can help by contributing to this resource via Pull Requests.

UI/UX

Product design principles
How to create a consistent, harmonious user experience when designing product cards? Mei Zhang shares some valuable tips. (Image credit)

Security

Privacy

  • The GDPR Checklist is another helpful resource for people to check whether a website is compliant with the upcoming EU directive.
  • Bloomberg published a story about the open-source privacy-protection project pi-hole, why it exists and what it wants to achieve. I use the software daily to keep my entire home and work network tracking-free.
GDPR Compliance Checklist
Achieving GDPR Compliance shouldn’t be a struggle. The GDPR Compliance Checklist helps you see clearer. (Image credit)

Web Performance

  • Postgres 10 has been here for quite a while already, but I personally struggled to find good information on how to use all these amazing features it brings along. Gabriel Enslein now shares Postgres 10 performance updates in a slide deck, shedding light on how to use the built-in JSON support, native partitioning for large datasets, hash index resiliency, and more.
  • Andrew Betts found out that a lot of websites are using outdated headers. He now shares why we should drop old headers and which ones to serve instead.

Accessibility

Page previews
Page previews open possibilities in multiple areas, as Nirzar Pangarkar explains. (Image credit: Nirzar Pangarkar)

CSS

  • Rarely talked about for years, CSS tables are still used on most websites to show (and that’s totally the correct way to do so) data in tables. But as they’re not responsive by default, we always struggled when making them responsive and most of us used JavaScript to make them work on mobile screens. Lea Verou now found two new ways to achieve responsive tables by using CSS: One is to use text-shadow to copy text to other rows, the other one uses element() to copy the entire <thead> to other rows — I still try to understand how Lea found these solutions, but this is amazing!
  • Rachel Andrew wrote an article about building and providing print stylesheets in 2018 and why they matter a lot for users even if they don’t own a printer anymore.
  • Osvaldas Valutis shares how to implement the so-called “Priority Plus” navigation pattern mostly with CSS, at least in modern browsers. If you need to support older browsers, you will need to extend this solution further, but it’s a great start to implement such a pattern without too much JavaScript.
  • Rachel Andrew shares what’s coming up in the CSS Grid Level 2 and Subgrid specifications and explains what it is, what it can solve, and how to use it once it is available in browsers.

JavaScript

  • Chris Ashton “used the web for a day with JavaScript turned off.” This piece highlights the importance of thinking about possible JavaScript failures on websites and why it matters if you provide fallbacks or not.
  • Sam Thorogood shares how we can build a “native undo & redo for the web”, as used in many text editors, games, planning or graphical software and other occasions such as a drag and drop reordering. And while it’s not easy to build, the article explains the concepts and technical aspects to help us understand this complicated matter.
  • There’s a new way to implement element/container queries into your application: eqio is a tiny library using IntersectionObserver.

Work & Life

  • Johannes Seitz shares his thoughts about project management at the start of projects. He calls the method “Iteration Zero”. An interesting concept to understand the scope and risks of a project better at a time when you still don’t have enough experience with the project itself but need to build a roadmap to get things started.
  • Arestia Rosenberg shares why her number one advice for freelancers is to ‘lean into the moment’. It’s about doing work when you can and using your chance to do something else when you don’t feel you can work productively. In the end, the summary results in a happy life and more productivity. I’d personally extend this to all people who can do that, but, of course, it’s best applicable to freelancers indeed.
  • Sam Altman shares a couple of handy productivity tips that are not just a ‘ten things to do’ list but actually really helpful thoughts about how to think about being productive.

Going Beyond…

  • Ethan Marcotte elaborates on the ethical issues with Google Duplex that is designed to imitate human voice so well that people don’t notice if it’s a machine or a human being. While this sounds quite interesting from a technical point of view, it will push the debate about fake news much further and cause more struggle to differentiate between something a human said or a machine imitated.
  • Our world is actually built on promises, and here’s why it’s so important to stick to your promises even if it’s hard sometimes.
  • I bet that most of you haven’t heard of Palantir yet. The company is funded by Peter Thiel and is a data-mining company that has the intention to collect as much data as possible about everybody in the world. It’s known to collaborate with various law enforcement authorities and even has connections to military services. What they do with data and which data they have from us isn’t known. My only hope right now is that this company will suffer a lot from the EU GDPR directive and that the European Union will try to stop their uncontrolled data collection. Facebook’s data practices are nothing compared to Palantir it seems.
  • Researchers sound the alarm after an analysis showed that buying a new smartphone consumes as much energy as using an existing phone for an entire decade. I guess I’ll not replace my iPhone 7 anytime soon — it’s still an absolutely great device and just enough for what I do with it.
  • Anton Sten shares his thoughts on Vanity Metrics, a common way to share numbers and statistics out of context. And since he realized what relevancy they have, he thinks differently about most of the commonly readable data such as investments or usage data of services now. Reading one number without having a context to compare it to doesn’t matter at all. We should keep that in mind.

We hope you enjoyed this Web Development Update. The next one is scheduled for Friday, June 15th. Stay tuned.

Smashing Editorial
(cm)


See the original article here: 

Monthly Web Development Update 5/2018: Browser Performance, Iteration Zero, And Web Authentication

Thumbnail

WordPress Local Development For Beginners: From Setup To Deployment




WordPress Local Development For Beginners: From Setup To Deployment

Nick Schäferhoff



When first starting out with WordPress, it’s very common to make any changes directly on your live site. After all, where else would you do it? You only have that one site, so when something needs changing, you do it there.

However, this practice has several drawbacks. Most of all that it’s very public. So, when something goes seriously wrong, it’s quite noticeable for people on your site.

Preventing Common Mistakes

When creating free or premium WordPress themes, you’re bound to make mistakes. Find out how you can avoid them in order to save yourself time and focus on actually creating themes people will enjoy using. Read more →

It’s ok, don’t feel bad. Most WordPress beginners have done this at one point or another. However, in this article, we want to show you a better way: local WordPress development.

What that means is setting up a copy of your website on your local hard drive. Doing so is incredibly useful. So, below we will talk about the benefits of building a local WordPress development environment, how to set one up and how to move your local site to the web when it’s ready.

This is important, so stay tuned!

The Benefits Of Local WordPress Development

Before diving into the how, let’s have a look at the why. Using a local development version of WordPress offers many benefits.

We already mentioned that you no longer have to make changes to your live site with all the risks involved with that. However, there is more:

  • Test themes and plugins
    With a local copy of your site, you can try out as many themes and plugin combinations as you want without risking taking your live site out due to incompatibilities.
  • Update safely
    Another time when things are prone to go wrong are updates. With a local environment, you can update WordPress core and components to see if there are any problems before applying the updates to your live site.
  • Independent of an online connection
    With your WordPress site on your computer, you can work on it without being connected to the Internet. Thus, you can get work done even if there is no wifi.
  • High performance/low cost
    Because site performance is not limited by an online connection, local sites usually run much faster. This makes for a better workflow. Also, as you will see, you can set it all up with free software, eliminating the need for a paid staging area.

Sounds good? Then let’s see how to make it happen.

How To Set Up A Local Development Environment For WordPress

In this next part, we will show you how to set up your own local WordPress environment. First, we will go over what you need to do and then how to get it right.

Tools You’ll Need

In order to run, WordPress needs a server. That’s true for an online site as well as a local installation. So, we need to find a way to set one up on our computer.

That server also needs some software WordPress requires to work. Namely, that’s PHP (the platform’s main programming language) and MySQL for the database. Plus, it’s nice to have a MySQL user interface like phpMyAdmin to make handling the database more convenient.

In addition to that, need your favorite code editor or IDE (integrated development environment) for the coding part. My choice is Notepad++ but you might have your own preferences.

Finally, it’s useful to have some developer tools to analyze and debug your site, for example, to look at HTML and CSS. The easiest way is to use Chrome or Firefox (read our article on Firefox’s DevTools), which have extensive functionality like that built in.

Available Software

We have several options at our disposal to set up local server environments. Some of the most well known are DesktopServer, Vagrant, and Local by Flywheel. All of these contain the necessary components to set up a local server that WordPress can run on.

For this tutorial we will use XAMPP. The name is an acronym and stands for “cross platform, Apache, MySQL, PHP, Perl”. If you have been paying attention, you will notice that we earlier noted MySQL and PHP as essential to running a WordPress website. In addition, Apache is an open source solution for creating servers. So, the software contains everything we need in one neat package. Plus, as “cross platform” suggests, XAMPP is available for both Windows, Mac and Linux computers.

To continue, if you haven’t done so already, head over to the official XAMPP website and download a copy.

How To Use XAMPP

Installing XAMPP pretty much works like every other piece of software.

On Windows:

  1. Run the installer (note that you might get a warning about running unknown software, allow to continue).
  2. When asked which components to install, make sure that Apache, MySQL, PHP, and phpMyAdmin are active. The rest is usually unnecessary, deactivate it unless you have good reason not to.
  3. Choose the location to install. Make sure it’s easy to reach as that’s where your sites will be saved and you will probably access them often.
  4. You can disregard the information about Bitnami.
  5. Choose to start the control panel right away at the end.

On Mac:

  1. Open the .dmg file
  2. Double click on the XAMPP icon or drag it to applications folder
  3. That’s it, well done!

After the installation is complete, the control panel starts. Should your operating system ask for Firewall permissions, make sure to allow XAMPP for private networks, otherwise, it won’t work.


Large preview

From the panel, you can start Apache and MySQL by clicking the Start buttons on the respective rows. If you run into problems with programs that use the same ports as XAMPP, quit those programs and try to restart the XAMPP processes. If the problem is with Skype, there is a permanent solution by disabling the ports under ToolsOptionsAdvancedConnections.


Large preview

Under Config, you can also enable automatic start for the components you need.


Large preview

After that, it’s time to test your local server. For that, open your browser, and go to http://localhost.

If you see the following screen, everything works as it should. Well done!


Large preview

Installing WordPress Locally

Now that you have a local server, you can install WordPress in the same way that you do on a web server. The only difference: everything is done on your hard drive, not an FTP server or inside a hosting provider’s admin panel.

That means, to create a database for WordPress, you can simply go to http://localhost/phpmyadmin. Here, you find the same options as in the online version and can create a database, user and password for WordPress.


Large preview

Once that is done and you want to install WordPress, you can do so via the htdocs folder inside your installation of XAMPP. There, simply create a new directory, download the latest version of WordPress, unpack the files and copy them into the new folder. After that, you can start the installation by going to http://localhost/newdirectoryname.


Large preview

That’s basically it. Now that you have a running copy of WordPress on your website, you can install themes and plugins, set up a child theme, change styles, create custom page templates and do whatever your heart desires.

When you are satisfied, you can then move the website from a local installation to live environment. That’s what we will talk about next.

How To Deploy Your Site With A Plugin

Alright, once your local site is up to your liking, it’s time to get it online. Just a quick note: if you want to get a copy of your existing live site to your hard drive, you can use the same process as described below only in reverse. The overall principles stay the same.

Either way, we can do this manually or via plugin and there are several solutions available. For this tutorial, we will use Duplicator. I found it to be one of the most convenient free solutions and, as you will see, it makes things really easy.

1. Install Duplicator

Like every other WordPress plugin, you first need to install Duplicator in order to use it. For that, simply go to PluginsAdd New. In the search box, input the plugin name and hit enter, it should be the first search result.


Large preview

Click Install Now and activate once it’s done.

2. Export Site

When Duplicator is active on your site, it adds a new menu item in the WordPress dashboard. Clicking it gets you to this screen.


Large preview

Here, you can create a so-called package. In Duplicator that means a zipped up version of your site, database, and an installation file. To get started, simply click on Create New.

In the next step, you can enter a name for your package. However, it’s not really necessary unless you have a specific reason.


Large preview

Under Storage, Archive, and Installer are options to determine where to save the archive (works for the Pro version only), exclude files or database tables from the migration and input the updated database credentials and new URL.

In most cases you can just leave everything as is, especially because Duplicator will attempt to fill in the new credentials automatically later. So, for now just hit Next.

After that, Duplicator will run a test to see if there are any problems.


Large preview

Unless something major pops up, just click on Build to begin building the package. This will start the backup process.

At the end of it, you get the option to download the zip file and installer with the click on the respective buttons or with the help of the One-Click Download.


Large preview

Do so and you are done with this part of the process.

3. Upload And Deploy Files On Your Server

If all of this has gone down without a hitch, it’s now time to upload the generated files to their new home. For that, log into your FTP server and browse to your new site’s home directory. Then, start uploading the files we generated in the last step.

Once done, you can start the installation process by inputting http://yoursite.com/installer.php into the browser bar.


Large preview

In the first step, the plugin checks the archive’s integrity and whether it can deploy the site in the current environment. You also get some advanced options that you are welcome to ignore at the moment. However, make sure to check the box where it says “I have read and accept all terms and notices,” before clicking Next.

Your site is now being unpacked. After that, you get to the screen where it’s time to input the database information.


Large preview

The plugin can either create a new database (if your host allows it) or use an existing one. For the latter option, you need to set up the database manually beforehand. Either way, you need to input the database name, username, and password to continue. Duplicator will also use this information to update the wp-config.php file of your site so that it can talk to the new database. Click Test Database to see if the connection works. Hit Next to start the installation of the database.

Once Duplicator is done with that, the final step is to confirm the details of your old and new site.


Large preview

That way, Duplicator is able to replace all mentions of your old URL in the database with the new one. If you don’t, your site won’t work properly. If everything is fine, click the button that says Next.

4. Finishing Up

Now, there are just a few more things to do before you are finished. The first one is to check the last page of the setup for any problems encountered in the deployment.


Large preview

The second is to log into your new site (you can do so via the button). Doing so will land you in the Duplicator menu.


Large preview

Here, be sure to click on Remove Installation Files Now! at the top. This is important for security reasons.

And that’s it, your site should now be successfully migrated. Well done! You have just mastered the basics of local WordPress development.

Quick Note: Updating Your Database Information Manually

Should the Duplicator plugin for some reason be unable to update wp-config.php with the new database information, your site won’t work and you will see a warning that says “unable to establish database connection”.

In that case, you need to change the information manually. Do this by finding wp-config.php in your WordPress installation’s main folder. You can access it via FTP or a hosting backend like cPanel. Ask your provider for help if you find yourself unable to locate it on your own.

Edit the file (this might mean downloading, editing and re-uploading it) and find the following lines:

/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

Update the information here with that of your new host (by replacing the info between the ‘ ‘), save the file and move it back to your site’s main directory. Now everything should be fine.

WordPress Local Development In A Nutshell

Learning how to install WordPress locally is super useful. It enables you to make site changes, run updates, test themes and plugins and more in a risk-free environment. In addition to that, it’s free thanks to open source software.

Above, you have learned how to build a local WordPress environment with XAMPP. We have led you through the installation process and explained how to use the local server with WordPress. We have also covered how to get your local site online once it’s ready to see the light of day.

Hopefully, your takeaway is that all of this is pretty easy. It might feel overwhelming as a beginner at first, however, using WordPress locally will become second nature quickly. Plus, the benefits clearly outweigh the learning process and will help you take your WordPress skills to the next level.

What are your thoughts on local WordPress development? Any comments, software or tips to share? Please do so in the comments section below!

Smashing Editorial
(mc, ra, yk, il)


Excerpt from – 

WordPress Local Development For Beginners: From Setup To Deployment

Why Web Application Maintenance Should Be More Of A Thing

Traditional software developers have been hiding a secret from us in plain sight. It’s not even a disputed fact. It’s part of their business model.

It doesn’t matter if we’re talking about high-end enterprise software vendors or smaller software houses that write the tools that we all use day to day in our jobs or businesses. It’s right there front and center. Additional costs that they don’t hide and that we’ve become accustomed paying.

So what is this secret?

Well, a lot of traditional software vendors make more money from maintaining the software that they write than they do in the initial sale.

Not convinced?

A quick search on the term “Total Cost of Ownership” will provide you with lots of similar definitions like this one from Gartner (emphasis mine):

[TCO is] the cost to implement, operate, support & maintain or extend, and decommission an application.

Furthermore, this paper by Stanford university asserts that maintenance normally amounts to 60% to 90% of the TCO of a software product.

It’s worth letting that sink in for a minute. They make well over the initial purchase price by selling ongoing support and maintenance plans.

We Don’t Push Maintenance

The problem as I see it is that in the web development industry, web application maintenance isn’t something that we focus on. We might put it in our proposals because we like the idea of a monthly retainer, but they will likely cover simple housekeeping tasks or new feature requests.

It is not unheard of to hide essential upgrades and optimizations within our quotes for later iterations because we‘re not confident that the client will want to pay for the things that we see as essential improvements. We try and get them in through the back door. Or in other words, we are not open and transparent that, just like more traditional software, these applications need maintaining.

Regardless of the reasons why, it is becoming clear that we are storing up problems for the future. The software applications we’re building are here for the long-term. We need to be thinking like traditional software vendors. Our software will still be running for 10 or 15 years from now, and it should be kept well maintained.

So, how can we change this? How do we all as an industry ensure that our clients are protected so that things stay secure and up to date? Equally, how do we get to take a share of the maintenance pie?

What Is Maintenance?

In their 2012 paper Effective Application Maintenance, Heather Smith and James McKeen define maintenance as (emphasis is mine):

Porting an application to a new server, interfacing with a different operating system, upgrading to a newer release, altering a tax table, or complying with new regulations—all necessitate application — maintenance. As a result, maintenance is focused on upgrading an application to ensure it remains productive and/or cost effective. The definition of application maintenance preferred by the focus group is — any modification of an application to correct faults; to improve performance; or to adapt the application to a changed environment or changed requirements. Thus, adding new functionality to an existing application (i.e., enhancement) is not, strictly speaking, considered maintenance.

In other words, maintenance is essential work that needs to be carried out on a software application so it can continue to reliably and securely function.

It is not adding new features. It is not checking log files or ensuring backups have ran (these are housekeeping tasks). It is working on the code and the underlying platform to ensure that things are up to date, that it performs as its users would expect and that the lights stay on.

Here are a few examples:

  • Technology and Platform Changes
    Third-party libraries need updating. The underlying language requires an update, e.g. PHP 5.6 to PHP 7.1 Modern operating systems send out updates regularly. Keeping on top of this is maintenance and at times will also require changes to the code base as the old ways of doing certain things become deprecated.

  • Scaling
    As the application grows, there will be resource issues. Routines within the code that worked fine with 10,000 transactions per day struggle with 10,000 per hour. The application needs to be monitored, but also action needs to be taken when alerts are triggered.

  • Bug Fixing
    Obvious but worth making explicit. The software has bugs, and they need fixing. Even if you include a small period of free bug fixes after shipping a project, at some point the client will need to start paying for these.

Hard To Sell?

Interestingly, when I discuss this with my peers, they feel that it is difficult to convince clients that they need maintenance. They are concerned that their clients don’t have the budget and they don’t want to come across as too expensive.

Well, here’s the thing: it’s actually a pretty easy sell. We’re dealing with business people, and we simply need to be talking to them about maintenance in commercial terms. Business people understand that assets require maintenance or they’ll become liabilities. It’s just another standard ongoing monthly overhead. A cost of doing business. We just need to be putting this in our proposals and making sure that we follow up on it.

An extremely effective method is to offer a retainer that incorporates maintenance at its core but also bundles a lot of extra value for the client, things like:

  • Reporting on progress vs. KPIs (e.g. traffic, conversions, search volumes)
  • Limited ‘free’ time each month for small tweaks to the site
  • Reporting on downtime, server updates or development work completed
  • Access to you or specific members of your team by phone to answer questions

Indeed, you can make the retainer save the client money and pay for itself. A good example of this would be a client’s requirement to get a simple report or export from the database each month for offline processing.

You could quote for a number of development days to build out a — probably more complex than initially assumed — reporting user interface or alternatively point the client to your retainer. Include within it a task each month for a developer to manually run a pre-set SQL query to manually provide the same data.

A trivial task for you or your team; lots of value to your client.

A Practical Example

You’ll, of course, have your own way of writing proposals but here are a couple of snippets from an example pitch.

In the section of your proposal where you might paint your vision for the future, you can add something about maintenance. Use this as an opportunity to plant the seed about forming a long-term relationship.

You are looking to minimize long-term risk.

You want to ensure that your application performs well, that it remains secure and that it is easy to work on.

You also understand how important maintenance is for any business asset.

Later on, in the deliverables section, you can add a part about maintenance either as a stand-alone option or bundled in with an ongoing retainer.

In the following example, we keep it simple and bundle it in with a pre-paid development retainer:

We strongly advocate that all clients consider maintenance to be an essential overhead for their website. Modern web applications require maintenance and just like your house or your car; you keep your asset maintained to reduce the tangible risk that they become liabilities later on.

As a client who is sensibly keen to keep on top of the application’s maintenance as well as getting new features added, we’d suggest N days per month (as a starting point) for general maintenance and development retainer.

We’d spread things out so that a developer is working on your system at least [some period per week/month] giving you the distinct advantage of having a developer able to switch to something more important should issues arise during the [same period]. Depending upon your priorities that time could all be spent on new feature work or divided with maintenance, it’s your call. We normally suggest a 75%/25% split between new features and important maintenance.

As previously mentioned, this is also a great opportunity to lump maintenance in with other value-added ongoing services like performance reporting, conducting housekeeping tasks like checking backups and maybe a monthly call to discuss progress and priorities.

What you’ll probably find is that after you land the work, the retainer is then not mentioned again. This is understandable as there is lots for you and your client to be considering at the beginning of a project, but as the project is wrapping up is a great time to re-introduce it as part of your project offboarding process.

Whether this is talking about phase 2 or simply introducing final invoices and handing over, remind them about maintenance. Remind them of ongoing training, reporting, and being available for support. Make the push for a retainer, remembering to talk in those same commercial terms: their new asset needs maintaining to stay shiny.

Can Maintenance Be Annoying?

A common misconception is that maintenance retainers can become an additional burden. The concern is that clients will be constantly ringing you up and asking for small tweaks as part of your retainer. This is a particular concern for smaller teams or solo consultants.

It is not usually the case, though. Maybe at the beginning, the client will have a list of snags that need working through, but this is par for the course; if you’re experienced, then you’re expecting it. These are easily managed by improving communication channels (use an issue tracker) and lumping all requests together, i.e, working on them in a single hit.

As the application matures, you’ll drop into a tick-over mode. This is where the retainer becomes particularly valuable to both parties. It obviously depends on how you’ve structured the retainer but from your perspective, you are striving to remind the client each month how valuable you are. You can send them your monthly report, tell them how you fixed a slowdown in that routine and that the server was patched for this week’s global OS exploit.

You were, of course, also available to work on a number of new requested features that were additionally chargeable. From your client’s perspective, they see that you are there, they see progress, and they get to remove “worry about the website” from their list. Clearly, ‘those clients’ do exist, though, so the most important thing is to get your retainer wording right and manage expectations accordingly.

If your client is expecting the moon on the stick for a low monthly fee, push back or renegotiate. Paying you to do — say — two hours maintenance and housekeeping per month in amongst providing a monthly report and other ancillary tasks is exactly that; it’s not a blank cheque to make lots of ad-hoc changes. Remind them what is included and what isn’t.

How Do We Make Maintenance Easier?

Finally, to ensure the best value for your clients and to make your life easier, use some of these tactics when building your applications.

Long-Term Support (LTS)

  • Use technology platforms with well documented LTS releases and upgrade paths.
  • Ongoing OS, language, framework and CMS upgrades should be expected and factored in for all projects so tracking an LTS version is a no-brainer.
  • Everything should be running on a supported version. Big alarm bells should be ringing if this is not the case.

Good Project Hygiene

  • Have maintenance tasks publicly in your feature backlog or issue tracking system and agree on priorities with your client. Don’t hide the maintenance tasks away.
  • Code level and functional tests allow you to keep an eye on particularly problematic code and will help when pulling modules out for refactoring.
  • Monitor the application and understand where the bottlenecks and errors are. Any issues can get added to the development backlog and prioritized accordingly.
  • Monitor support requests. Are end users providing you with useful feedback that could indicate maintenance requirements?

The Application Should Be Portable

  • Any developer should be able to get the system up and running easily locally — not just you! Use virtual servers or containers to ensure that development versions of the applications are identical to production.
  • The application should be well documented. At a minimum, the provisioning and deployment workflows and any special incantations required to deploy to live should be written down.

Maintenance Is A Genuine Win-Win

Maintenance is the work we need to do on an application so it can safely stand still. It is a standard business cost. On average 75% of the total cost of ownership over a software application’s lifetime.

As professionals, we have a duty of care to be educating our clients about maintenance from the outset. There is a huge opportunity here for additional income while providing tangible value to your clients. You get to keep an ongoing commercial relationship and will be the first person they turn to when they have new requirements.

Continuing to provide value through your retainer will build up trust with the client. You’ll get a platform to suggest enhancements or new features. Work that you have a great chance of winning. Your client reduces their lifetime costs, they reduce their risk, and they get to stop worrying about performance or security.

Do yourself, your client and our entire industry a favor: help make web application maintenance become more of a thing.

Smashing Editorial
(rb, ra, hj, il)

View this article: 

Why Web Application Maintenance Should Be More Of A Thing

Creating A UX Strategy

(This is a sponsored article.) As designers working primarily on screen, we often think of user experience design as being primarily a screen-focused activity. In fact, user experience affects the entirety of what we build and that often includes activities that are undertaken off-screen.

To design truly memorable experiences, we need to widen our frame of reference to include all of the brand touchpoints that our users come into contact with along their customer journey. Doing so has the potential to materially impact upon business outcomes, recognizing the role that design — and user experience — can play at the heart of a wider business strategy.

Whether you’re building a website or an application, at heart you are designing for users and, as such, it’s important to consider these users at the center of a customer-focused ecosystem. Great brands are more than just logos or marques, and websites or applications, they’re about the totality of the user experience, wherever a customer comes into contact with the brand.

This expanded design focus — considering touchpoints both on- and off-screen — becomes particularly important as our role as designers widens out to design the entirety of the experience considering multiple points of contact. It’s not uncommon for the websites and apps we build to be a part of a wider, design-focused ecosystem — and that’s where UX strategy comes in.

Over the last few years, we have seen designers move up the chain of command and, thankfully, we are starting to see designers occupy senior roles within organizations. The emergence of designers as part of the C-Suite in companies is a welcome development and, with it, we are seeing the emergence of CDOs, Chief Design Officers.

As James Pallister put it in “The Secrets of the Chief Design Officer,” an article exploring the CDO phenomenon written for the UK’s Design Council:

“As Apple’s valuation shot higher and higher in recent years, a flurry of major corporations — Philips, PepsiCo, Hyundai &mdahs; announced the appointments of Chief Design Officers to their boards.

This was no mere coincidence. Seeking to emulate the stellar success of design-led businesses like Apple, global companies are pouring investment into design.”

This investment in, and appreciation of, design has been long overdue and is beginning to impact upon our day-to-day role as designers.

Forward-thinking companies are elevating the role of designers within their hierarchies and, equally importantly, stressing the importance of design thinking as a core, strategic business driver. As a result, we are seeing design driving company-wide business innovation, creating better products and more engaged relationships with customers.

As this trend continues, giving designers a seat at the top table, it’s important to widen our scope and consider UX strategy in a holistic manner. In this article, the eighth in my ongoing series exploring user experience design, I’ll open the aperture a little to consider how design impacts beyond the world of screens as part of a wider strategy.

Considering Customer Journeys

Before users come into contact with a website or an app, they will likely have been in contact with a brand in other ways — often off-screen. When considering design in the widest sense, it’s important to focus on the entirety of the customer journey, designing every point of contact between a user and a brand.

Forrester, the market research company, defines the customer journey as follows:

“The customer journey spans a variety of touchpoints by which the customer moves from awareness to engagement and purchase. Successful brands focus on developing a seamless experience that ensures each touchpoint interconnects and contributes to the overall journey.”

This idea — of a seamless and well-designed experience and a journey through a brand — should lie at the heart of a considered UX strategy. To design truly memorable experiences, we need to focus not just on websites or apps, but on all of the touchpoints a user might come into contact with.

Consider the Apple Store and its role acting as a beacon for Apple and all of its products. The Apple Store is, of course, an offline destination, but that doesn’t mean that the user experience of the store hasn’t been designed down to the last detail. The store is just one part of Apple’s wider engagement strategy, driving awareness of the business.

The Apple Store is an entry point into Apple’s ecosystem and, as such, it’s important that it’s considered in a holistic manner: Every aspect of it is designed.

Jesse James Garrett, the founder of Adaptive Path which is an end-to-end experience design company, considers this all-embracing approach in an excellent article, “Six Design Lessons From the Apple Store,” identifying a series of lessons we can learn from and apply to our designs. As Garrett notes:

“Apple wants to sell products, but their first priority is to make you want the products. And that desire has to begin with your experience of the products in the store.”

Seen through this lens, it becomes clear that the products we design are often just one aspect of a larger system, every aspect of which needs to be designed. As our industry has matured, we’ve started to draw lessons from other disciplines, including service design, considering every point as part of a broader service journey, helping us to situate our products within a wider context.

If service design is new to you, Nielsen Norman Group (helpful as ever), have an excellent primer on the discipline named “Service Design 101” which is well worth reading to gain an understanding of how a focus on service design can map over to other disciplines.

When designing a website or an app, it’s important to consider the totality of the customer journey and focus on all of the touchpoints a user will come into contact with. Do so, and we can deliver better and more memorable user experiences.

Designing Touchpoints

As our industry has evolved, we’ve begun to see our products less as standalone experiences, but as part of a wider network of experiences comprised of ‘touchpoints’ — all of which need to be designed.

Touchpoints are all the points at which a user comes into contact with a brand. As designers, our role is expanding to encompass a consideration of these touchpoints, as a part of a broader, connected UX strategy.

With the emergence of smartphones, tablets, wearables and connected products our scope has expanded, widening out to consider multiple points at which users come into contact with the brands we are designing.

When considering a UX strategy, it helps to spend some time listing all of the points at which a user will come into contact with the brand. These include:

  • Websites,
  • Apps and mobile experiences,
  • Email,
  • Support services,
  • Social media.

In addition to these digital points of contact, it’s important to consider >non-digital points of contact, too. These off-screen points of contact include everything, from how someone answers the phone to the packaging of physical products.

To aid with this, it helps to develop a ‘touchpoints matrix’ — a visual framework that allows a designer to join the dots of the overall user experience. This matrix helps you to visually map out all of the different devices and contexts in which a user will come into contact with your brand.

The idea of a touchpoints matrix was conceived by Gianluca Brugnoli — a teacher at Politecnico di Milano and designer at Frog Design — as a tool that fuses customer journey mapping with system mapping, which can be used as the basis for considering how different user personas come into contact with and move through a brand.

Roberta Tassi, as part of her excellent website Service Design Tools — “an open collection of communication tools used in design processes that deal with complex systems” — provides an excellent primer on how a touchpoints matrix can be used as part of a holistic design strategy. Tassi provides a helpful overview, and I’d recommend bookmarking and exploring the website — it’s a comprehensive resource.

As she summarises:

“The matrix brings a deeper comprehension of interactions and facilitates further development of the opportunities given by the system — of the possible entry points and paths — shifting the focus of the design activities to connections.”

This shift — from stand-alone to connected experiences — is critically important in the development of a ‘joined up’ UX strategy.

When you embark upon developing and mapping a broader UX strategy, a touchpoints matrix helps you to see how the different nodes of a design join up to become part of an integrated and connected experience or an ‘ecosystem.’

Building Ecosystems

When we holistically consider our role as designers, we can start to explore the design of the whole experience: from initial contact with a brand offline, through engaging with that brand digitally. Collectively, these amount to designing a brand ecosystem.

Ecosystems aren’t just for big brands — like Facebook, Instagram or Twitter — they are increasingly for everything we design. In a world that is ever more connected, what we design doesn’t stand in isolation. As such, we need to consider both context and scope as part of an integrated strategy.

In addition to considering the design of products, we also need to consider the wider ecosystem that these products sit within. For example, when considering the design of applications — whether web-based or native — we also need to consider: the user’s first point of contact and how we drive discovery; the experience while using the application itself; and addressing wider issues (such as offering users support).

All of the aspects of an ecosystem need to be designed so that we deliver great user experiences at every point in the process. This includes:

  • The process of discovery, through social and other channels;
  • The design of a company or application’s website, so that the story that’s told is consistent and engaging;
  • The content of email campaigns to ensure they’re equally considered, especially if there are multiple email campaigns targeted at different audiences;
  • The packaging, when we’re designing physical, connected products; and
  • The support we offer, ensuring that customers are looked after at every point of the journey, especially when issues arise.

This list is just the tip of the proverbial iceberg, but it clearly shows that there are multiple points on a customer’s journey that need to be designed. A considered UX strategy helps us to deliver on all of these aspects of an ecosystem and become increasingly important as the ecosystems we design become richer and more complex.

In Closing

The opportunities ahead are fantastic for designers working in this industry. The landscape we are designing for is evolving rapidly and, if we’re to stay ahead of the game, it’s important that we turn our attention towards the design of systems in addition to products. This involves an understanding of UX strategy in the broadest sense.

When embarking upon the design of a new website or product, or undertaking a redesign, it’s important to widen the frame of reference. Taking a step back and considering the entirety of the user experience leads to better and more memorable experiences.

By considering the entirety of the customer journey and all the touchpoints along the way we can create more robust, connected experiences. By focusing on the design of holistic experiences, we can delight users, ensuring they’re happy with the entire experience we have crafted.

This article is part of the UX design series sponsored by Adobe. Adobe XD is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype, and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance, and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.

Smashing Editorial
(ra, yk, il)

See original – 

Creating A UX Strategy

Monthly Web Development Update 3/2018: Service Workers, Building A CDN, And Cheating At Design

Service Worker is probably one of the most misrepresented technologies we currently have. When I hear people talking about it, the topic almost always revolves around serving an app when a user is offline. However, Service Worker can do so much more than that, and every week I come across new articles that show how powerful the technology really is.

This month, for example, we can learn how to use Service Worker for cross-tab messaging and to load off requests into the background with the Background Sync API. I think the toolset we now have in our browsers already allows us to build great experiences regardless of the network state. Now it’s up to us to make the experiences so great that users truly love them. And that’s probably the hardest part.

News

Sketch 49
Sketch 49 has arrived, and with it comes the new Prototyping in Sketch feature which lets you see the entire flow in action. (Image credit)

General

  • Ed Ellson examined Chrome’s Background Sync API and the retry strategy it uses to perform a request. By allowing synchronization in the background after a first attempt has failed, the API helps us improve the browsing experience for users who go offline or are on unstable connections.

UI/UX

Cheating At Design
Use color and weight to create visual hierarchy instead of size is only one of the seven practical tips for cheating at design that Adam Wathan and Steve Schoger share. (Image credit)

Security

  • With GraphQL you can query exactly what you want whenever you want. This is amazing for working with an API but also has complex security implications. Instead of asking for legitimate, useful data, a malicious actor could submit an expensive, nested query to overload your server, database, network, or all of these. To prevent this from happening, Max Stoiber shows us how we can secure the GraphQL API in our projects.

Privacy

  • WebKit is introducing the Storage Access API. The new API targets one of the major issues with Safari’s Intelligent Tracking Protection (ITP): Identifying users who are logged in to a first-party service but view content of it embedded on a third party (YouTube videos on a blog, for example). The Storage Access API allows third-party embeds to request access to their first-party cookies when the user interacts with them. A good solution to protect user privacy by default and allow exceptions on request.

Web Performance

  • Janos Pasztor built his own Content Delivery Network because he thinks it can be a better solution than using existing third parties. The code for the CDN of his personal website is now available on Github. A nice web performance article that looks at common solutions from a different angle.
  • A year after Facebook’s announcement to broadly use Cache-Control: Immutable, Paul Calvano examined how widespread its usage is on the web — apart from the few big players. Interesting research and it’s still sad to see that this useful performance tool is used so little. At Colloq, we use it quite a lot, which saves us a lot of traffic and load on our servers and enables us to serve a lot of pages nearly instantly to recurring users.
Global stats of a self-built CDN
Global stats for the custom CDN that Janos Pasztor built. (Image credit)

HTML & SVG

JavaScript

CSS

Accessibility

Accessibility Checklist
The Accessibility Checklist helps build accessibility into your process no matter your role or stage in a project. (Image credit)

Work & Life

  • This week I read an article by Alex Duloz, and his words still stick with me: “When we develop a new application, when we post content on the Internet, whatever we do that people will have access to, we should consider just for a minute if our contribution adds up to the level of dumbness kids/teenagers are exposed to. If it does, we should refrain from going live.” The truth is, most of us, including me, don’t consider this before posting on the Internet. We create funny things, share funny pictures and try to get fame with silly posts. But in reality, we shape society with this. Let’s try to provide more useful resources and make the consumption of this more enjoyable so young people can profit from our knowledge and not only view things we think are funny. “We should always consider how teenagers will use what we release.”
  • The MIT OpenCourseWare released a lot of free audio and video lectures. This is amazing news and makes great content available to broader masses.
  • Jake Knapp says great work requires idealism and cynicism and has strong arguments to back up this theory. An article worth reading.
  • There’s an important article on how unhappiness has grown in America’s population since around the year 2000. It reveals that while income inequality might play a role, the more important aspect is that young people who use a lot of digital media are unhappier than those who use it only up to an hour a day. Interestingly, people who don’t use digital media at all, are unhappy, too, so the outcome of this could be that we should try to use digital media only moderately — at least in our private lives. I bet it’ll make a big difference.
  • Following the theory of Michael Bradley, projects don’t necessarily need a roadmap for success. Instead, he suggests to create a moral compass that points out why the project exists and what its purpose is.

Going Beyond…

We hope you enjoyed this Web Development Update. The next one is scheduled for April 13th. Stay tuned.

Excerpt from – 

Monthly Web Development Update 3/2018: Service Workers, Building A CDN, And Cheating At Design