Tips to Master Microcopy for Web Designers

Untitled.jpg

Written content makes up the vast majority of all websites because it’s the easiest content to produce and consume. The style of writing is a big factor in a website’s usability, but it often gets overlooked with design aesthetics taking priority.

When just starting out, and diving into web copy, you’re bound to make simple mistakes in the writing process. With this post, I’m hoping to help you iron out these mistakes by outlining the basics of copy and microcopy, explaining what they are and how they function on the Web.

As you practice writing you’ll find new methods for generating interest from readers. But also keep a keen eye while browsing other sites to study their methods for writing attractive page copy.

How Copy Defines Your Site

Written content is at the heart of most websites. Content is often a primary reason why people visit a site, or it’s at least used to guide people around a site.

Blogs drive readers to consume content. But written content may also coverdifferent features for a new web application. Content is a vehicle used as a means to an end. With blogs, the content actually is the end goal of delivering quality content that’s valuable to readers.

But the way you design copy can have a big impact on consumption and user experience.

For example, take a look at the home page for Wake. The layout uses big bold letters to tell you what this app does (a collaboration app for designers). But scroll down and you’ll find a section with tooltip callouts explaining the interface features.

Visitors don’t like wading through documentation to learn about your product. Say what you do in the shortest amount of time with the clearest copy possible. This is also the foundation of most great landing pages.

Sometimes there is room for a little fun and creativity too, like on the home page of MailBakery.

The content writers for MailBakery use a metaphor that compares coding & designing e-mails with the process of baking sweets. Their home page uses the text “we bake HTML emails” to cleverly describe what they do.

Fun vectors and metaphors sell people a visual idea associated withwordplay. This can be tricky and doesn’t work for every company. But it’s a powerful marketing technique when done right.

Other sites, like Patreon work better with clear and straightforward statements.

The home page heading says “Recurring funding for artists and creators”. This doesn’t get overly complex about the technology, because the technology is secondary to the purpose. Technology is a tool used to do something – in this case it’s a donation engine for creatives.

By studying examples like these, you’ll learn how to write content that sellswithout feeling gimmicky. There’s a lot to learn when you’re just getting started. Reading may help you find a direction.

Here are some posts about quality web copy to get you started:

Finding A Voice

All of your copy for a single project should follow a similar written voice. This is usually subtle but still noticeable and even capable of being documented like MailChimp’s style and tone page.

Lots of people write posts about personal writing tone and how to find your voice.

But remember that your voice may not always be the best strategy for every project. Some websites or blogs require a more serious tone, others more aloof. Some sites work best with humorous copy, or even a mix of all these things.

Generally speaking, my advice is to edit down your writing, and avoid verbose sentences. Everything you write should further the purpose of the content without redundancy.

Also be sure to create a structured hierarchy so that your text reads naturally. This is always a good idea for SEO and for page design. But clean text withdistinct patterns can also be helpful to readers trying to understand content.

Here are some tips to get you started:

  • Be clear and concise
  • Have a goal in mind before writing
  • Structure content in a logical flow
  • Use typography to build a visual hierarchy

The voice you write in may change from project to project. But the strategies for writing great copy typically remain the same.

Looking Into Microcopy

All copy on the page can be broken down into segments, like headers and body content. One less explored area is microcopy, a form of web copy as it applies to small elements on the page.

Most page elements that rely on microcopy are also interactive elements. These might be page links, buttons, input fields, or anything that exists for the user’s attention.

A lot of microcopy writing has to do with conversions and further content explanation. Therefore microcopy could also include non-interactive elementslike image captions and info/alert messages.

Microcopy is where you examine the smallest bits of writing to see if certain words could increase measureable stats. For example this case study showed howchanging one word improved clicks by 161%. That’s how significant microcopy is to the user experience.

Different websites use microcopy for different reasons. The home page of a blog like Hongkiat will be very different than the home page of Zendesk because the user’s goals are different.

This Zendesk screenshot has two buttons that naturally contrast each other. Because the microcopy uses the “or” word in midway between these two buttons, they’re presented as opposing options to the same end. You can either get started right away, or take a tour and decide afterwards.

And if you take the tour there’s a big signup button at the bottom asking you to start your free trial:

Someone who doesn’t want to signup might place themselves in “the other” group and prefer the tour. The particular phrasing of this microcopy suggests that a visitor can do either of these two options, therefore it carefully steers the attention away from the third option, i.e. is leaving the site.

Here’s another great example of microcopy from this ConversionXL post. These two screenshots demonstrate the immense difference of removing Buffer’s input placeholder text from the sharing field.

These small optimizations are often achieved through clarity and a deeper connection with the audience. Use microcopy to explain things better, and help visitors interact with the site in a more meaningful way.

Some areas to consider updating or analyzing for great microcopy:

  • Input field label & placeholder text
  • Form button text
  • Navigation link text
  • Guided instructions
  • Image carousels
  • Error/404 pages

You’ll find microcopy on anything that users may interact with, or small snippets of text that provide relevant info to all users (like modal signup windows or little info boxes).

Once you understand the benefits for great microcopy it’ll naturally become a significant part of your copywriting workflow.

Putting It All Together

Page copy and microcopy should have a thematic relationship. The writing style and tone should be familiar across the entire website. This includes techniques for title capitalization and sentence/paragraph length.

The first step is to figure out the goals of your current project. Do you want toincrease conversions for signups, sales, or pageviews? Or are you making a new site and getting content organized for launch?

At each stage of the content creation process you’ll need to consider what you’re trying to achieve before you can achieve it.

If you have trackable goals, then try A/B tests to gauge metrics.

But the most important thing is to keep writing and keep trying new things. Get yourself in the headspace of your visitors, and consider how they might feel landing on each page of your site. Do your headings make sense? Is there a natural flow of typography down the page? Do you instinctively want to keep reading?

Ask yourself these questions as you write, and you’ll quickly spot your own mistakes. In time it’ll become like second nature.
Written by Jake Rocheleau 

Did you find this article helpful? Don’t forget to drop your feedback in the comments section below. Suggest for you:

☞ Design Your Own Web Development Lab

☞ Hands on Sketch 3 Training – Website Design

☞ The Extreme Web Development Course

☞ CSS3 Introduction web Building Blocks Fundamentals

☞ Web Design For Grandmothers With Html

Advertisements

Best Practices for Progressive Enhancement in Web Design

Untitled.jpg

The craft of building websites is incredibly complex with many fast-changing parts. The goal of the web design community is to lessen the complexity, andreduce the potential for error at each stage of the creation process.

Progressive enhancement is such an idea in web design that aims to reduce errors and provide a consistent user experience across the board. The concept has its own Wikipedia page which explains it as a method of fully-accessible content, rendering enhanced features only when supported by the browser.

It’s easy to understand progressive enhancement, but not as easy to apply it directly to your design work. I’d like to cover some best practices for progressive enhancement in real-world projects to help designers think more sustainably about their workflow.

1. Understanding Progressive Enhancement

The theory of progressive enhancement recommends to start with a simple website that works in all browsers, making it accessible for every visitor. Then add features whenever possible.

This is the opposite of graceful degradation which includes all features by default, then degrades when something doesn’t work.

Progressive enhancement is better for the overall user experience, because at its core it loads only necessary elements. Every web browser can support text (and usually images). Without any CSS this information will look bland and tasteless, but it’ll be accessible.

This List Apart article argues that progressive enhancement is content-first withstyles and dynamic components added later. Content in semantic HTML should be delivered before anything else.

The advanced CSS and JavaScript we use today are widely supported, but if we want to follow the principles of progressive enhancement, they should be considered luxuries.

Here’s a general rundown of the main features of progressive enhancement, that you should take into account:

  • Semantic markup for all content
  • Users’ browser preferences needs to be respected
  • Content and basic functionality should be available to all users
  • Unobtrusive JavaScript is loaded only in environments that can support it

Technological restraints in front-end development are primarily determined by browser compatibility. Progressive enhancement gets you back to the basics thinking about how the bare-bone simplest webpage might look like. From there, you can plan for more advanced features, like CSS3 properties.

But what about browsers that don’t support modern CSS3? This is where sites like Can I Use come into play. You should decide which features are worth implementing, and make judgements based on the target audience of your website.

2. Subsistence In Stylesheets

Most browsers today support all the basic properties you need. But advanced CSS3 is still a problem for legacy users, and progressive enhancement offers a solution.

Instead of looking for fallback methods to maintain these new features, concern yourself first with proper layout structures.

Write semantic HTML and CSS markup that works in as many active browsers as possible (support for ancient browsers like IE5 support isn’t necessary).

Take for example this JSFiddle that uses floats with two sidebars (.fixed), and a fluid content area (.fluid). If you delete all CSS, and rerun the code you’ll notice everything stacks up nicely with the first column, then second, and finally the last.

Some developers would prefer to have the content column (.fluid) appear first in the HTML. This is where progressive enhancement comes into play, andalternate CSS solutions become viable.

The two primary goals of your HTML are as follows:

  • Fully semantic and valid code
  • A consistent experience for everyone

The most straightforward way to achieve these goals is to start from nothingand work up, as most progressive enhancement advocates would recommend it.

If your code looks good with CSS both disabled and enabled, then it offers a reasonable solution for everyone.

It’s also worth considering at what point you drop support for something. Microsoft has already dropped major support for IE6 , so users running that browser may not be worth your time.

But there’s still one big question: if a browser doesn’t support my modern CSS, what should I do?

You simply write code that works without it, and consider the modern CSS as a progressive enhancement. This is the beauty of the progressive enhancement methodology.

You don’t need fallbacks, because you’re basically assuming that nothing is supported by default.

Progressive enhancement methods are about making the site usable even in cases when something isn’t supported—but if it is supported, all the better.

You need to consider how content actually flows without CSS. For example, when I disable CSS on Transmit’s website, the content still flows organically down the page.

Yes, it’s ugly, and yes, it feels like we’ve lost twenty years of progress… but it works.

3. Handling JavaScript

It’s worth mentioning that each JavaScript issue you may bump into during the development process is tricky and unique. When you build a new project with progressive enhancement, you should list all your required JS-based features, and consider how they could operate without JavaScript.

This will require lots of online research to find valid solutions. Aaron Gustafson wrote a great blog post with solutions to various problems, like replacing Ajax with a meta refresh for content inside an iframe.

Also, when you create JavaScript tabs, it’s a good idea to use anchor links with real ID values. That way, when JavaScript is disabled, you can still have the tabs visible and accessible by anchor value. Aaron wrote another piece on A List Apartthat covers a more general overview of how you should think about these problems.

Here’s another example. Let’s say you have a link that loads content dynamically. The href value is empty, because everything loads via JavaScript with thepreventDefault() method.

Instead, it would be wise to set the href property to point to a different pagewhere the content could load naturally, but the visitor only sees that page when JavaScript is disabled.

Progressive enhancement is about more than JavaScript, but with web development advancing further every year, there’s no doubt that JavaScript plays a significant role.

Operate under the assumption that everything has been disabled, and scale up from there. This might include problems with embedded widgets that are out of your control, the <noscript> tag is a viable solution here.

Also think about JavaScript features that lack comprehensive browser support. This includes the fetch API, the push API, the arrow function syntax, or even browsers without support for modern libraries like jQuery.

Every feature requires individual testing with an individual solution.

The essence of progressively enhanced JavaScript is to build content that functions without any scripting. This may lead to a rudimentary user experience, but that’s okay as long as the website is usable, and the content is accessible.

If you want to do live testing, you can typically disable CSS and JavaScript in every major browser to see how your website performs. It’s also worth considering using extensions like A-Tester for WCAG compliance.

JavaScript with progressive enhancement is a huge topic. Here are some posts to help you dig deeper:

Where Progressive Enhancement Falls Short

Although progressive enhancement is a brilliant idea for almost every type of modern website, it simply may not be applicable to projects that aim to push the limits of web technology.

For example, this methodology is not a good solution for web applications that function solely on Ajax calls. Is that a good choice for accessibility? No, of course not. But if that were the case most of Codrops’ tutorials wouldn’t even exist. You have to remember the target audience.

A business website probably doesn’t have the audience that cares about flashy new CSS3 perspective properties, but web developers can be the perfect audience for such advanced features.

Progressive enhancement only falls short for web applications that simply don’t care about going back in time. I realize these web applications are few and far between, but developers love progress, and in some cases it can be sensible to forge ahead with new tech leaving the stragglers behind.

I am a proponent of progressive enhancement (or even graceful degradation, your choice) for general web projects. But I also realize it’s not the perfect solution for everything. In fact, there is no perfect solution. It all boils down to audience needs and project goals.

Further Reading

If you’re constantly building web projects, you should consider applying progressive enhancement to your workflow. It’s much easier than it seems at first glance, and it all starts with the fundamentals. Most topics surrounding progressive enhancement just require practice and testing. Try out the suggestions from this article, and see what works best for your workflow.
Written by  Jake Rocheleau

Did you find this article helpful? Don’t forget to drop your feedback in the comments section below. Suggest for you:

☞ Hands on Sketch 3 Training – Website Design

☞ CSS3 Introduction web Building Blocks Fundamentals

☞ Web Design For Grandmothers With Html

☞ CSS3 Gradients for Web Designers

☞ Learn Responsive Web Development from Scratch

Best Practices for Progressive Enhancement in Web Design

Untitled.jpg

The craft of building websites is incredibly complex with many fast-changing parts. The goal of the web design community is to lessen the complexity, andreduce the potential for error at each stage of the creation process.

Progressive enhancement is such an idea in web design that aims to reduce errors and provide a consistent user experience across the board. The concept has its own Wikipedia page which explains it as a method of fully-accessible content, rendering enhanced features only when supported by the browser.

It’s easy to understand progressive enhancement, but not as easy to apply it directly to your design work. I’d like to cover some best practices for progressive enhancement in real-world projects to help designers think more sustainably about their workflow.

1. Understanding Progressive Enhancement

The theory of progressive enhancement recommends to start with a simple website that works in all browsers, making it accessible for every visitor. Then add features whenever possible.

This is the opposite of graceful degradation which includes all features by default, then degrades when something doesn’t work.

Progressive enhancement is better for the overall user experience, because at its core it loads only necessary elements. Every web browser can support text (and usually images). Without any CSS this information will look bland and tasteless, but it’ll be accessible.

This List Apart article argues that progressive enhancement is content-first withstyles and dynamic components added later. Content in semantic HTML should be delivered before anything else.

The advanced CSS and JavaScript we use today are widely supported, but if we want to follow the principles of progressive enhancement, they should be considered luxuries.

Here’s a general rundown of the main features of progressive enhancement, that you should take into account:

  • Semantic markup for all content
  • Users’ browser preferences needs to be respected
  • Content and basic functionality should be available to all users
  • Unobtrusive JavaScript is loaded only in environments that can support it

Technological restraints in front-end development are primarily determined by browser compatibility. Progressive enhancement gets you back to the basics thinking about how the bare-bone simplest webpage might look like. From there, you can plan for more advanced features, like CSS3 properties.

But what about browsers that don’t support modern CSS3? This is where sites like Can I Use come into play. You should decide which features are worth implementing, and make judgements based on the target audience of your website.

2. Subsistence In Stylesheets

Most browsers today support all the basic properties you need. But advanced CSS3 is still a problem for legacy users, and progressive enhancement offers a solution.

Instead of looking for fallback methods to maintain these new features, concern yourself first with proper layout structures.

Write semantic HTML and CSS markup that works in as many active browsers as possible (support for ancient browsers like IE5 support isn’t necessary).

Take for example this JSFiddle that uses floats with two sidebars (.fixed), and a fluid content area (.fluid). If you delete all CSS, and rerun the code you’ll notice everything stacks up nicely with the first column, then second, and finally the last.

Some developers would prefer to have the content column (.fluid) appear first in the HTML. This is where progressive enhancement comes into play, andalternate CSS solutions become viable.

The two primary goals of your HTML are as follows:

  • Fully semantic and valid code
  • A consistent experience for everyone

The most straightforward way to achieve these goals is to start from nothingand work up, as most progressive enhancement advocates would recommend it.

If your code looks good with CSS both disabled and enabled, then it offers a reasonable solution for everyone.

It’s also worth considering at what point you drop support for something. Microsoft has already dropped major support for IE6 , so users running that browser may not be worth your time.

But there’s still one big question: if a browser doesn’t support my modern CSS, what should I do?

You simply write code that works without it, and consider the modern CSS as a progressive enhancement. This is the beauty of the progressive enhancement methodology.

You don’t need fallbacks, because you’re basically assuming that nothing is supported by default.

Progressive enhancement methods are about making the site usable even in cases when something isn’t supported—but if it is supported, all the better.

You need to consider how content actually flows without CSS. For example, when I disable CSS on Transmit’s website, the content still flows organically down the page.

Yes, it’s ugly, and yes, it feels like we’ve lost twenty years of progress… but it works.

3. Handling JavaScript

It’s worth mentioning that each JavaScript issue you may bump into during the development process is tricky and unique. When you build a new project with progressive enhancement, you should list all your required JS-based features, and consider how they could operate without JavaScript.

This will require lots of online research to find valid solutions. Aaron Gustafson wrote a great blog post with solutions to various problems, like replacing Ajax with a meta refresh for content inside an iframe.

Also, when you create JavaScript tabs, it’s a good idea to use anchor links with real ID values. That way, when JavaScript is disabled, you can still have the tabs visible and accessible by anchor value. Aaron wrote another piece on A List Apartthat covers a more general overview of how you should think about these problems.

Here’s another example. Let’s say you have a link that loads content dynamically. The href value is empty, because everything loads via JavaScript with thepreventDefault() method.

Instead, it would be wise to set the href property to point to a different pagewhere the content could load naturally, but the visitor only sees that page when JavaScript is disabled.

Progressive enhancement is about more than JavaScript, but with web development advancing further every year, there’s no doubt that JavaScript plays a significant role.

Operate under the assumption that everything has been disabled, and scale up from there. This might include problems with embedded widgets that are out of your control, the <noscript> tag is a viable solution here.

Also think about JavaScript features that lack comprehensive browser support. This includes the fetch API, the push API, the arrow function syntax, or even browsers without support for modern libraries like jQuery.

Every feature requires individual testing with an individual solution.

The essence of progressively enhanced JavaScript is to build content that functions without any scripting. This may lead to a rudimentary user experience, but that’s okay as long as the website is usable, and the content is accessible.

If you want to do live testing, you can typically disable CSS and JavaScript in every major browser to see how your website performs. It’s also worth considering using extensions like A-Tester for WCAG compliance.

JavaScript with progressive enhancement is a huge topic. Here are some posts to help you dig deeper:

Where Progressive Enhancement Falls Short

Although progressive enhancement is a brilliant idea for almost every type of modern website, it simply may not be applicable to projects that aim to push the limits of web technology.

For example, this methodology is not a good solution for web applications that function solely on Ajax calls. Is that a good choice for accessibility? No, of course not. But if that were the case most of Codrops’ tutorials wouldn’t even exist. You have to remember the target audience.

A business website probably doesn’t have the audience that cares about flashy new CSS3 perspective properties, but web developers can be the perfect audience for such advanced features.

Progressive enhancement only falls short for web applications that simply don’t care about going back in time. I realize these web applications are few and far between, but developers love progress, and in some cases it can be sensible to forge ahead with new tech leaving the stragglers behind.

I am a proponent of progressive enhancement (or even graceful degradation, your choice) for general web projects. But I also realize it’s not the perfect solution for everything. In fact, there is no perfect solution. It all boils down to audience needs and project goals.

Further Reading

If you’re constantly building web projects, you should consider applying progressive enhancement to your workflow. It’s much easier than it seems at first glance, and it all starts with the fundamentals. Most topics surrounding progressive enhancement just require practice and testing. Try out the suggestions from this article, and see what works best for your workflow.
Written by Jake Rocheleau

Did you find this article helpful? Don’t forget to drop your feedback in the comments section below. Suggest for you:

☞ Hands on Sketch 3 Training – Website Design

☞ Learning Dynamic Website Design – PHP MySQL and JavaScript

☞ HTML CSS How to Create a Website from Scratch

☞ Build a Responsive Website with HTML5, CSS3 and Bootstrap 4

☞ Build Responsive Website Using HTML5, CSS3, JS And Bootstrap