Bio-Techne’s products are scientific and require the presentation of many data points to allow our users to make educated purchasing decisions. Instead of creating a mobile-first design, we needed to adapt our desktop content to work with mobile. Desktop-first is a tough ask, but we created the universal design system and pattern library for this specific purpose. After all, we weren’t just building a mobile eCommerce platform… we needed our software to work everywhere, on every device, in every country on the planet, with a consistent user experience. Let’s dive in with the first high-fidelity draft of our product search design.

This image represents my high-fidelity interpretation of the wireframes we created with our stakeholders, existing customers, and development team. I love design collaboration and working with my teammates to create a great user experience for each of our personas. I also love research. We spent a lot of time user testing these designs with one-to-one interviews, surveys, and comparing those results with our real-world data gathered through analytics. This is a basic first take–it lacks the evolution, polish, and consideration of the final design–but it excited our stakeholders and sparked even more creativity in our collaborative process. After a few more iterations, we had our final launch designs for the product search results and the associated features.

In this fifth iteration, you’ll notice many of the design system objects have been updated to their final assets including buttons, input fields, dropdowns, etc. Even still, this is just the aesthetic we used for the re-launch. If you visit the website now, you’ll notice even more improvements to the product search design. Updated iconography, new search filter designs, cleaner images, and more polish – nearly all of these improvements were based on suggestions from our customers. I love feedback, qualifying it with actual data, and using those suggestions to improve my designs.

I’ll leave you with one final thought about these designs: we worked very hard to ensure they were device independent. Hopefully, you noticed design inspiration from Material Design, Apple’s Human Interface Guidelines, Microsoft’s Fluent Design, and even some influence from Twitter’s Bootstrap framework. Most of these design systems have been vetted for a good user experience and accessibility, but some designs are certainly better than others. We pulled the best and most accessible designs from each system, tweaked them to satisfy our strict requirements, and developed a design system that feels at home on any platform. I hope to continue this trend in any role I take moving forward. A consistent user experience is my top desire for the software I create; a great design system and pattern library is the best way to ensure that for iOS, Android, or the web.

The post Reimagining eCommerce for iOS and Android appeared first on Neon Studio.

Over the last six months, my team and I worked on a design refresh with a heavy focus on usability and accessibility. A customer support team asked if the Avaya would accommodate their accessible team members — that request ultimately got me hired. AAfD 2.x was our opportunity to take all the good from 1.x and bring it into a user-centered environment.

Building a Design System for Avaya

We began by sharpening the team’s focus on UX and accessibility by utilizing design systems, pattern libraries, and style/branding guides. Defining these standards offered us the freedom to think creatively while staying inside a vetted user experience. With a design system, designers and developers could choose an existing pattern that satisfied the user stories without having to blaze a new trail. Our teams began building out our new designs with improved efficiency.

We referenced Material Design, Apple’s HIG, and Microsoft’s Fluent Design System during the creation process. The team also ensured these changes weren’t a radical departure from Avaya’s current aesthetic. This also allowed us to create something familiar, and entirely proprietary, all while accommodating the usability and accessibility mandate.

Creating Assets for the Design System

Buttons may not seem like an obvious place to start, but the majority of our interactions began with buttons. After buttons, we designed other controls, dropdowns, forms, menus, tables, lists, and more. Then came the layout of the main user interface. Before showing you the finished design, let’s look at some of these assets.

I’d like to highlight the UX-friendly interface controls; I merged the best concepts from Google, Apple, and Microsoft into a simple take on modern UI controls. I also designed a “Combo Box” that meets all current accessibility standards. The combo box is mostly used by Microsoft and hasn’t yet been embraced in other design systems. It also doesn’t have a native HTML object for the web. Even still, I’m an advocate for the combo box because it gives the user more interactive freedom in less space.

The Final Designs – AAfD 2.x

After creating hundreds of assets, it was time to design window frames and start creating the user interface. While this was strictly a desktop app, our design system was platform-agnostic for future mobile updates. Here are the finished designs.

Discussing the Designs

Clean, simple, and modern… but we still needed it to feel similar to the original 1.x designs. We changed the layout and many of the interactions to accommodate the newly mandated accessibility requirements. Too many interactions in 1.x required users to navigate across the app to continue the workflow. In contrast, 2.x grouped many interactions and eliminated those that broke accessibility guidelines.

Call appearances are the perfect example of grouping interactions. In the 1.x designs, starting a call, dialing, and the controls were far from each other. Now, all those interactions live inside the same card; users move a few pixels not inches. Because of those improvements, our users move the mouse less — saving them time and the company money.

In the new UI, we have the menu and status at the top and the call appearances in cards below. There are detachable tools in the bottom left, and audio controls in the bottom right. The tools were designed to be reactive. If you open a single tool, it docks at the bottom of the main window in a full-width layout. Open a second tool, and it will split them 50/50 unless you drag and drop it otherwise. Each tool renders as 1, 2, or 3 columns; they also detach or undock as a separate window entirely.

Wrapping Up

With UX at the center of every conversation, my devs started looking for the right solutions instead of the easy ones. Once you embrace UX, it’s impossible to banish it back to the fiery chasm whence it came. I shouldn’t imply that the user experience is “The Ring,” but let’s roll with it. It consumes you with jealousy for great interactions and makes you feel safe when you’re in its presence. Too much? Probably, I’ll see myself out.

Before I go, allow me to leave you with a before and after shot of AAfD so you can compare the work we did on 2.x with 1.x. It was certainly a fun and challenging project.

The post Simplifying Design and Development for Avaya appeared first on Neon Studio.

For years, designers relied on style guides so their developers could build UI elements that looked the same in every template. Developers waste a lot of time referencing the style guide to ensure their UI elements match the design. What if we could eliminate that process entirely? Enter: Atomic Design. Originally conceived by Brad Frost, Atomic Design separates your software into tiered UI elements: atoms, molecules, organisms, templates, and pages. At a rudimentary level, it’s like building software with Legos — there are thousands of pieces with specific dimensions that, when assembled correctly, make an object. Further still, using those modular components allows you to assemble the object the same way every time. As a designer, developer, or stakeholder, you don’t need to manufacture the Legos, you just put them together.

Using an atomic pattern library as the source of truth for your development process not only allows for rapid development, it also ensures a better user experience for new projects. Assuming you’ve user tested the UI elements in your library, you can include them in your new project without worrying about the usability of the interactions they create. If you find yourself needing a new UI element, your user experience designers can research the best implementation of that element and put it in the library for use in your new project and every future project after that. If that’s not enough to convince you atomic design is the future, let’s talk about a real-world implementation of this philosophy.

When I was hired at Bio-Techne, they didn’t have a streamlined development process, let alone a pattern library or even a website style guide. The best they could offer me was a branding style guide from corporate headquarters (basically just colors and fonts). They recently adopted the agile development approach but relied on their stakeholders for design feedback. I consider that a cardinal sin of design. I love NN/g’s mantra: you are not the user. A stakeholder cannot possibly define the design for a project without introducing bias. Stakeholders should be available for general, product-specific guidance, but the user experience team should define the design based on their knowledge of standard UI elements, interactions, and actual user testing results. That data, rooted in empathy, will always result in a better user experience.

Before moving forward at Bio-Techne, I had to define our overall design and development strategy. Since I wanted consistency and efficiency, we decided to work towards an atomic pattern library. The ultimate goal was to create a single source of truth for all design and development assets. It’s even possible to integrate your code-based pattern library with certain prototyping tools to keep the designers on the same page as the developers. It’s certainly complicated to get everything configured and communicating properly, but once you do, it’s an amazing way to do more work in less time. It also ensures a better user experience for every interface you build.

The post Design Systems, Pattern Libraries, a UX Perspective appeared first on Neon Studio.

[twenty20 img1=”7150″ img2=”7149″ offset=”0.5″]

Overall Design Aesthetic

I didn’t have complete design freedom for this project; it was my first project for Bio-Techne, after all. While some of my inspiration came from the existing company websites, I also referenced standardized design concepts based on popular guidelines like Material Design. Ultimately, our stakeholders asked for something clean and “science-y” — that’s certainly a starting point, but I added modern, simple, and usable to the list as well. Since the Tocris design would slowly roll out to our other Bio-Techne websites, I needed buy-in from stakeholders across the company. It sounds daunting, but when your role defines the design standards for a company that previously had none (and you’re good at it), you’ll find your stakeholders ready and willing to get on board.

Everything we did for this project became the foundation for the next three website projects at Bio-Techne. I’ll cover the unique aspects of those website projects in future portfolio pieces. For now, I need to stick with high-level concepts. We put an incredible amount of time into researching and user testing every aspect of this redesign… I would have to write a book to convey the care given to this project. Bio-Techne is a billion-dollar company, so we took it slow and made sure we did everything right while maintaining the philosophy of rapid development and iterative design in an agile environment.

Header Redesign

The new header for the website includes the Bio-Techne brands bar, the individual company logo, a large search field, cart information, account access, the internationalization tool, and the main menu… phew! Since I couldn’t convince the marketing department to update or replace the brands with a better design, I did my best to make it fit the new design direction. First, we replaced all the brands bar assets with retina-compatible images, flattened the images, and adjusted the colors. Then we re-built the code to make it responsive with adjustments for each Bootstrap desktop breakpoint. After finishing the brands bar, we started putting the other necessary elements into place and removed unnecessary items like social links.

I believe a good user experience dictates a clean and usable interface that offers users the same interactions on every device. Unfortunately, the marketing department chose to hide the brands bar on mobile (we adapted everything else). While it breaks my UX philosophy, it’s better to hide it than to clutter the mobile interface. If it were up to me, I would have done cross-site promotional content elsewhere on the site instead of relying on a massive gray bar in the header. C’est la vie.

Homepage Redesign

The team redesigned the homepage from the ground up as a CMS page. We worked with the marketing team to implement a new page featuring a large rotating content slider, targeted box-links to showcase products, category tiles, and other information. We accomplished all this while ensuring the design translates well from the largest desktops to the smallest mobile devices. Tiles would eventually become an integral component of our new global design styles as they create a content-rich, easily-consumable design with calls-to-action that offer the customer a way to quickly scan what’s new.

Tocris also had a bad habit of using long lists of bulleted text links. If you think about it, that design gives mobile users an extremely small touch target (in this case, 14px) to click the correct link. This is woefully insufficient. Apple’s iPhone Human Interface Guidelines suggest a minimum touch target of 44px. I find it annoying that Apple stopped following their own recommendations, but I was certainly going to fix that problem for Tocris. Instead of bulleted text links, we created linked image tiles with a title and the option for a brief description. These tile elements became a massive part of the global redesign and tested extremely well during user testing. In scenarios where we didn’t want images replacing bulleted links, we moved to a wider button style that improved our touch targets to 35px. While that’s not the recommended 44px, it was a tremendous improvement for mobile without hurting the desktop experience.

Main Menu Redesign

We completely redesigned the main menu to provide a clean user experience that includes a mega menu for the main product categories, the ability to highlight newly updated product categories with brightly-colored tags, and standard dropdown menus for non-mega sections of the menu. We also re-organized the top-level-menu content into new parent categories to simplify the overall link structure. Since the new menu items live in the CMS, our content managers could finally edit the menu as necessary without a code push. Lastly, we modified the default Bootstrap menu behavior to accept hover interactions to encourage discoverability within the menu content.

Mobile Menu Design

While we kept the design of the main menu on the desktop clean and simple, it’s still a very complicated link structure that includes several sub-layers. Upon first open, the mobile main menu shows the top-level-menu items with the ability to expand and hide the sub-level items for each. This takes a relatively complicated link structure and simplifies it for mobile in one of the most universally accepted user experiences available. Since we needed clickable top-level-menu items with sub-levels nested underneath, we added a large show/hide button to each top-level-menu item. We relied on color, border thickness, and positioning to illustrate the menu hierarchy. We did not rely solely on color because color is not an accessibility-friendly way to differentiate between objects. While there are obvious visual differences between the desktop and mobile menu layouts, it utilizes the same code for each layout and ensures familiarity in the user experience no matter what device you’re using.

Search Redesign

We scrutinized every element on the site from a responsive, mobile, and user-experience perspective. Search was one area that received significant attention. We researched filter styles, product comparison designs, organization by category, and filtering concepts to come up with the new search interface. Since search is the main way our users interact with our website, we focused the user flow on conversions. We show the users all the necessary information in a clean and organized layout (on desktop and mobile) so they can spend less time trying to figure out what they’re looking at and more time buying our products. Even our mobile users see the same simplified layout; there’s no difference in content between desktop and mobile.

Datasheet Redesign

One of the biggest challenges of a responsive design is organizing data-heavy content in a way that works for desktop and mobile layouts. We accomplished that with our datasheet redesign by creating organized sections that collapse as the screen becomes smaller without losing any of the valuable data. The mobile design specifically mirrors that of the desktop to ensure user recognizability no matter how they visit the Tocris website. Further still, we adapted every element to be simple, clean, and responsive so the smallest screens get the same user experience as larger desktops.

Footer Redesign

We created a new footer design that would eventually end up on all the redesigned Bio-Techne websites running this new global framework. Our stakeholders requested brand-specific links, support information, global branding links, and a social/connect section. We put each of those requests into their own column and added some color. Each footer column collapses vertically on smaller devices while retaining the same visual design. We also made the footer editable in the CMS so changes don’t require a code push. This was a significant improvement over the previous footers as they were crammed with unnecessary information and incredibly tiny text. Since implementing this design, user interactions with the footer content have dramatically increased.

Retina Compatibility for High-Resolution Displays

In addition to responsive design, we added retina image capabilities to the Tocris website to ensure our images look great on every device. Most modern devices (phones, tablets, and computers) ship with high-resolution displays that dynamically “pixel-double” images to make them sharper and clearer. Without this design addition, our images would appear pixelated on almost all mobile devices and even some computers. Click the Tocris image to see a basic example of the difference between non-retina images and a retina image. Not everyone can see the difference (it’s noticeable depending on your eyesight), but there’s a blurry quality to the top logo and crisper edges on the bottom. If you’re having trouble seeing the differences, check out the registered trademark symbol in the top right corner of each logo.

Everything Else

As I mentioned, I wanted to focus on high-level concepts for this portfolio project, but I still want you to be able to see everything else we accomplished during this redesign. Here’s a longer list of technical things we did to the website. If you have any questions about the list below, I’d love to discuss them with you. Give me a call or use the contact page to get in touch with me.

Improvements outside of code: Single SOLR Slice, Acquia Development Environment, Akamai ION Platform, and New Relic Monitoring.

Improvements to code: Shared Codebase, Worldwide Purchasing Capabilities, SOLR-Based Redirection, Geo-Location Technology, E-Commerce Analytics, Multiple ERP Capabilities, CMS Integrated SEO, Product-Level Caching, Search Boosting Capabilities, Fully-Integrated JSON-LD Schema Tagging, Product Reviews, Account Document Storage, Search Compare Tool, Content Translation, Search Term Replace Capabilities, Search Advertisements, and Site unit testing.

Wrapping Up

Leading the Tocris redesign was challenging and fun for me because I needed to organize a massive amount of data into a clean and usable interface. While I didn’t re-invent the wheel with this project, I designed and built everything from scratch to deliver an excellent user experience to our customers. As with all projects, we translated incoming feedback into improvements to our global design standards to further improve the user experience. Tocris has grown tremendously since the redesign and will continue to do so as we continue our design, build, test, and iterate philosophy.

The post Modernizing Tocris Bioscience with a UX Focus appeared first on Neon Studio.

It seems like the design industry gets a new prototyping tool every month, but there are some obvious front-runners that get the most attention. Does that mean those tools are better than the rest? Does the tool you use actually matter? Note: this article is quite old; newer options are available. We’ll write an update in the future. In the meantime, check out this site for useful information on prototyping tools. There are many factors that play into the selection of a prototyping tool, one of the most important is popularity. To remain competitive in the design world, you should stay familiar with the bigger players: Adobe Xd, Sketch, etc. That said, let’s dive into the factors we considered for our team.

• OS compatibility
• Price
• Ease of use
• Interactive / live prototyping with app support
• Responsive prototyping
• Wireframing and high-fidelity options
• UI Kits, pattern libraries, and design resources
• Stakeholder sharing features
• Designer collaboration
• Version control
• Developer Exports

OS Compatibility

Obviously, the first factor to consider when choosing a prototyping tool for designers is the OS compatibility. It’s not likely that your team is going to buy new devices to use a design tool. If you’re in an all-Mac environment, you can use anything you want. If you’re in a mixed environment, or all-PC, you have fewer options. Many of the tools that push the boundaries of prototyping are Mac-only. Since our team is all-PC (sad, I know), we had to stick with prototyping options that were cross-platform. While it certainly limits our choices, it doesn’t mean we’re any less capable of doing our jobs. I also need to mention web-based prototyping tools: I wouldn’t use them at this point. If you’re reading this article, you probably need more robust solutions than what a web-based tool can provide.

Pricing

Does pricing need an entire paragraph? Probably not, so here’s a quick guide. Pricing varies widely; most of these apps require a subscription. Expect to pay a minimum of $20 per month, per user. The obvious winner here is Adobe Xd as it includes the entire suite of applications with your subscription.

Design Efficiency

Design efficiency is relatively subjective. A clean UI and readily available interactions help make you more efficient, but taking time to learn a tool will always make you more productive. I recommend watching some videos of designers using the application before deciding your favorite UI. Even with that extra research time, you may find encounter roadblocks. Talk to the support team for the app to see if they can resolve the problems. Most of the support teams for these tools are extremely responsive because they want your business. Competition drives these tools forward.

Mobile Apps

Not many tools include an app that you can use for your prototypes. Many of them end up being web-only if they have a live prototyping feature. We ended up choosing a tool called Justinmind for this feature since it included an app that syncs your prototypes from your account. When you open the app, all the prototypes become available to test on that device. It’s great if you’re prototyping apps or testing your mobile layouts on iOS and Android. Since we originally looked at tools, several other apps have added this functionality. If it’s important to you, check around.

Responsive Prototyping

Responsive prototyping is a difficult concept for design tools. Very few have implemented it, and even fewer have been able to do it well. We ultimately chose to remove this factor from our comparison because of its limited availability in early 2017. We’d certainly like to consider this in the future, but at this point it’s not ready. Since our company uses Bootstrap 3 for responsive layouts, we decided to build separate templates for the corresponding breakpoints. We could do this with any software, but we like the templating/screen system that Justinmind used at the time.

Wireframing and High-Fidelity Prototypes

Depending on your design workflow and the overall user experience integration at your company, you may need a tool that handles both wireframing and high-fidelity prototypes. At our company, we have tons of meetings discussing layout and content architecture. In our process, we don’t need software for wireframing as we usually do those on a whiteboard during a meeting. We determine our basic layout and move to a high-fidelity solution so it’s easier for our stakeholders to understand the visual concepts.

UI Kits, Pattern Libraries, and Design Resources

Most of the major players distribute design resources like iOS UI assets, Material Design icons, etc. If you’re designing for a specific platform, you should investigate what UI kits are available to you for that software. If there are first-party kits, they’ll likely be maintained for future releases. Relying on third-party assets can be hit-and-miss, but some designers are more current than the bigger companies… so your mileage may vary. Asset management is also important. Many tools allow you to add assets to a library for use in other prototypes. Instead of copying/pasting assets between projects, you can just insert them directly from your library saving a significant amount of time for each project. Some tools can even integrate with an external pattern library — I haven’t used this yet, but knowing the advantage of pattern libraries in development, I imagine it would be awesome from a design perspective.

Prototype Collaboration

Let’s talk about collaboration. Unless you’re a solo shop, it matters. Actually, it still matters if you are a solo shop. As designers, we need to share our designs with other designers and stakeholders to gather feedback and improve our designs. The coolest aspect of collaboration is real-time sharing: you can have multiple designers working on the same prototype at once. This allows for a real-time collaborative process that’s new to the modern design world. Several apps have this option, but it’s not common. Another aspect of collaboration – stakeholder feedback – was a huge factor for our team. We wanted a commenting system that would allow our stakeholders to ask questions about specific design elements. At the time, Justinmind was the only tool that included commenting features without additional software or paid subscriptions. Lastly, do you need version control? Well, that depends mostly on your design process. If you have only one designer working on a prototype at a time, version control isn’t necessary and would be a glorified version of the undo button. If you will have multiple designers in a single prototype, it’s worth looking into a version control system. For our team, we decided against it because it was in its infancy in early 2017. Most of the major tools have some sort of version control system available.

Developer Exports

So many tools offer some sort of export feature that you should be able to give to a developer so they can start coding. At least that’s how it’s supposed to work… but it never does. Some tools simply give you the specifications for each element (this is cool), while others generate HTML, CSS, and JavaScript automagically for you. Auto-generated code is never as good as code purposefully-written by a human and audited by another human. Simply put: unless you’re using an integrated pattern library with pre-defined code for the elements in your prototype, it will not end up being accurate and should generally be avoided. That said, we ignored this as a factor when we were shopping for a prototyping tool. Eventually, we would like to see a complete integration with our atomic pattern library (for development) and the design libraries within our prototyping tool. That would allow us to design and code entirely within one source of truth. Sign me up.

What Tool Did We Pick?

In early 2017, Justinmind fit our needs the best. However, I would certainly like to revisit this process at some point in the future. Justinmind isn’t perfect; no design tool had everything we wanted. It’s also not a very popular design tool; it’s been around for a long time but has struggled to gain market recognition. Other tools see significant improvements, but Justinmind is relatively slow at feature additions. As the other tools get better, we will revisit their features every few months. It won’t surprise me if we end up on Adobe Xd at some point in the future, but in early 2017, it was a bit too new for us to consider it. Sketch is another very popular option, but it’s Mac-only so we couldn’t use it at Bio-Techne. Whatever tool you decide to use, make sure you’ve considered all the features we discussed in this article. Tools matter; they won’t make you a better designer, but they’ll certainly make you more capable as one.

The post Choosing a Prototyping Tool for Designers appeared first on Neon Studio.

Every browser renders each font differently, but we’ve found a relatively general technique to get the best possible results (so far) across all browsers. We tested these rules on the latest versions of Chrome, Firefox, Safari, Opera, Internet Explorer, and Edge. We also tested the rules on Windows, Mac, and Ubuntu. We’ll first show you our code and then explain why we do it. After that, we’ll tell you how to get the same results.

Font Face Best Practices Guide

@font-face {
	font-family: font;
	font-weight: normal;
	font-style: normal;
	src: url('/fonts/font.eot');
	src: url('/fonts/font.eot?#iefix') format('embedded-opentype'),
	url('/fonts/font.woff2') format('woff2'),
	url('/fonts/font.svg#font') format('svg');
	url('/fonts/font.otf') format('opentype'),
	url('/fonts/font.ttf') format('truetype'),
	url('/fonts/font.woff') format('woff'),
}

@media screen and (-webkit-min-device-pixel-ratio:0) {
@font-face {
	font-family: font;
	font-weight: normal;
	font-style: normal;
	src: url('/fonts/font.svg') format('svg');
}
}

body {
	-webkit-font-smoothing: antialiased;
}

That specific order will net you the best possible font rendering results across all browsers. Ultimately, most browsers try to use the first font in the source list. If it’s not compatible, it looks for the font file type it wants. Here’s how we came up with our recommended order:

• The font.eot file is a generally accepted practice for using @font-face within older versions of Internet Explorer.
• The font.woff2 works the best in most modern browsers, but isn’t compatible with older browsers.
• The font.svg file is the second best way to render fonts on compatible browsers (very few support it).
• The font.otf file is next because older versions of Firefox don’t render ttf, woff, or svg well on Windows.
• The font.ttf file works okay nearly everywhere, so we left it in as a fallback… but most browsers won’t use it.
• The font.woff file works great in most modern browsers and is the fall-back for woff2.

At this point, these rules work great everywhere except a few older versions of Chrome on Windows. These versions of Chrome on Windows always load the older woff file instead of the svg format – event though it’s compatible. In fact, if you use Google Fonts for your @font-face, it will only serve the woff file to compatible browsers. Since woff looks generally awful on Chrome in Windows, this makes Google Fonts practically useless. That’s why we added the chrome-specific @media query under the normal @font-face code.

The @media query allows us to target Chrome (and other WebKit browsers like Safari) specifically. By eliminating the other sources, we can force compatible versions of Chrome/Safari to load the font.svg file. The font.svg file renders beautifully because it has built-in anti-aliasing, but most browsers can’t use it.

Ultimately, we have to add all of these font files to our @font-face declaration because there is no single file type that works with every browser. Almost all modern browsers support woff/woff2, but developers and designers need to think about older browsers too. If a website doesn’t work well on an older browser, it could force people to ignore the content. At Drift, we build every site with as much backwards-compatibility as possible to reach the largest audience possible. That’s why we needed to write this Font Face Best Practices Guide in the first place.

We’re still not quite finished. Our Font Face Best Practices Guide would not be complete without adding the font-smoothing options to the body element. If any of our compatible browsers use something besides the font.svg file, we want them to smooth the font using ant-aliasing. That helps us maintain the look of the font across all browsers and platforms.

Converting a Font for the Best Font Face Compatibility

This is an art all by itself. We recommend starting with a font.ttf file and converting it to the rest of the formats with free online conversion tools. But… you can’t use a single converter to get all of the formats you need. So here’s what you should do:

• First start off with Font Squirrel – choose expert settings and check the boxes for TrueType, EOT Lite, and SVG. Everything else is fine.
• Never use Font2Web – their render/conversion techniques do not produce good results.
• We’re still missing the font.otf format, so go to FontConverter, upload the font.ttf again, and have it output font.otf.
• Now that you have all of the necessary files, upload them to your server and start building the CSS.
• Do not – I repeat do not – use the Font Squirrel CSS. That defeats the purpose of this article.
• Copy our CSS code and modify it for your font’s name and location.

Using Multiple Weights of the Same Font Family

It’s not possible to use the same font-family CSS declaration for multiple weights in @font-face. They won’t render properly if you try it. If you want to use multiple weights of the same font, you’ll still need to start with a font.ttf file and convert each weight using the instructions above. After you finish converting the different weights, you’ll need to add them as separate @font-face declarations, define the new source URLs for each new weight, and set the font-weight to normal, bold, etc. for each. To use them in the content, you’ll need to make sure that you’re using the right font-weight property for the right text. Here’s an example of how to make your h1 elements bold and p elements normal:

h1 {
font-family: font;
font-weight: bold;
}

p {
font-family: font;
font-weight: normal;
}

Don’t forget to add the extra @font-face declarations to the @media query for Chrome so it loads the font.svg file for each weight. You can use a single @media query for all of the @font-face rules. That’s it! You can now add beautiful typography to any website without hesitation thanks to our Font Face Best Practices Guide.

A Word of Caution

What? You said I didn’t have to hesitate. Yes, you’re right… because you should be using proper optimization techniques so this next section doesn’t matter. If you’re not, you have to decide what is more important: fast loading or beautiful fonts.

Using this technique is slightly slower than a service like Google Fonts. As we mentioned, Google doesn’t serve the fonts beautifully to all web browsers, so you’re sacrificing beauty for speed… unless you know how to properly optimize a website. Our Font Face Best Practices Guide doesn’t cover optimization, but we’ll give you a couple pointers.

You should be caching your website and using a CDN (Content Delivery or Distribution Network) to serve all static files to your visitors. If you’re doing that, this shouldn’t make a big difference in your website’s loading time… just don’t go nuts and add 10 fonts via @font-face. That would create a rather large, unnecessary download.

If you’re using WordPress, but not optimizing your site, we can help. We use W3 Total Cache for our optimizations. It can be a royal pain to configure properly, but we’re awesome at it. If you’d like help making your website faster (and prettier), just let us know.

That’s it – for real this time. Please be sure to bookmark our Font Face Best Practices Guide for future reference and share it with your friends. We’ll update it as necessary when font support across all of the browsers improves. We wish that everything supported svg, but it doesn’t look like that will ever happen. If you have suggestions or problems, let us know via our contact options. Be sure to clear your cache before reaching out; that could be causing the problem.

The post Font Face Best Practices Guide – Updated 2016 appeared first on Neon Studio.