Tags are tremendously useful for enabling your site visitors to find related content. Providing a good experience depends upon a well-defined and consistent tag taxonomy. Here's how.
Rule #1: Avoid redundancy and overlap.
Don’t add synonyms or slight variations of keywords. While this helped SEO in the late 90’s, modern search engine algorithms incorporate thesauruses and context to help searchers find content.
Adding synonyms adds visual clutter for the user, but does not improve discoverability. If they sound similar, they are similar; choose one.
Don't do this:
Any time you’re tempted to create a new tag, consider whether an existing tag will do the job. And if you do create a new tag, make sure it actually relates to existing content as well, rather than being a solo tag.
Rule #2: Use as few tags as possible.
Long tag lists on blog articles make it harder, not easier, for the reader to make choices. Worse, impairs their ability to focus and fatigues their decision-making and follow-up ability.1
Two or three tags is ideal; don’t exceed five. Really.
This is a bit of a corollary to Rules #1 & #2. To make it easy to avoid redundancy and keep the list short, provide a list of tags for your authors to choose from.
Here's an example of it in action in our SiteManager CMS which powers this blog:
Rule #4: Don't use your main subject as a tag.
iMarc is an interactive agency. We make a lot of websites. Notice how many of our blogs are tagged "websites" or "interactive" or "agency"? Right. None.
If it's your main subject, your content already reflects it. No need for a tag.
Rule #5: No solo tags
Visitors always should be able to use Tags to discover new content; a tag used only once is useless. When a visitor clicks on a tag and the only result is the very article they were just at, they begin to question the site’s integrity. It’s better for an article to have no tags than a tag used just once.
There may be occasional exceptions, such as when an article is the first in a series. Even in this case, it’s usually better to start out tag-free, then add relevant tags as you publish new content.
Solo tags make for lonely content:
That's it. Go forth and tag responsibly.
Phys.org. “Too many choices – good or bad – can be mentally exhausting.” 14 April 2007. http://phys.org/news127404469.html. Vohs, Kathleen D. “Making Choices Impairs Subsequent Self-Control: A Limited-Resource Account of Decision Making, Self-Regulation, and Active Initiative.” Journal of Personality and Social Psychology. 2008;94(5):883-898. ↩
iMarc is thrilled to welcome five new members to our team. Let us introduce you to the outstanding new recruits!
Thomas Saraceno, Director of Experience
Thomas brings a wealth of experience to iMarc. Most recently, he worked as a designer at TripAdvisor. As Director of Experience at iMarc, he leads the UX team to deliver engaging and innovative digital experiences. He works to research and understand both the business needs and users’ behaviors in order to create innovative and easy-to-use websites.
After work, you can find Thomas at home with his wife and daughter. Thomas also has a dual identity as a rock star. He plays guitar (not to mention left-handed guitar) for a band and is basically iMarc’s very own Jimi Hendrix. Thomas also lives on a farm and rides/repairs motorcycles, making him probably the coolest person we know.
Victoria Anderson, Office Manager
Prior to iMarc, Victoria studied communication and media studies at Bridgewater State. After college, she worked as a manager for a Boston-based marketing company. As Office Manager and Receptionist at iMarc, she helps keep our team organized and productive by answering the phones ever-so promptly and pleasantly, managing office orders (iMarcians use a lot of Post-it notes), planning company events and client meetings, and filing bills.
After work, you might find Victoria on a beach, desperately deciding on an Instagram filter, and talking to her cat. Not necessarily all at the same time.
Tommy Chanthaboune, UX Engineer
Tommy Chanthaboune was previously a web developer/UX engineer for BBA Solutions in Arkansas. There, he was able to dive into the textbook industry, and learn about everything from packing books to coordinating policy for third party collections. Primarily, he worked with their development team to build great products. At iMarc, Tommy will be developing websites and applications with client-side technologies.
Outside of work, you might find Tommy kicking around a soccer ball, reading, or hanging out with his friends and family. He loves getting in touch with his inner-foodie, and frequently tries new restaurants. If you’re looking for a new place to grab a bite, ask Tommy!
Allison Boyajian, Marketing Coordinator
Allison Boyajian came to iMarc as a recent graduate from Boston University where she studied mass communication and French. Throughout college, Allison held several positions working on marketing, business development, and copywriting. At iMarc, she brings her communication expertise to the table by creating, delivering, and optimizing our marketing materials to ensure a strong message that is consistent with our brand image.
After work, you’ll probably find Allison conjuring up something sweet in her kitchen, finding overpriced sparkly pillows to add to her collection, or riding her mint green cruiser. She also tries to create her own knock knock jokes. They’re usually not very funny.
Katelyn Weber, New Business Specialist
Katelyn joins us at iMarc after having worked as a senior business development representative at Brightcove. Prior to Brightcove, Katelyn attended Assumption College where she studied marketing. At iMarc, she works on our business development team, seamlessly handling all things new business. She works with companies to help them define their web and mobile strategies, ensuring that our custom solutions align to their objectives.
When she’s not working, Katelyn is likely to be working up a sweat at the gym, searching for innocent puppies to call her own, or eating Mexican food. (She highly recommends Mi Mexico Lindo in Metheun, MA!)
Visit our About Page to learn more about the amazing iMarc team.
Design isn't my thing. I still have opinions, but when it comes down to details like spacing and typography, I'm just guessing. The lack of certainty keeps me second guessing myself, so I'm always looking for ways to justify my reasoning for why I like one thing more than another.
For the iMarc Boilerplate, we focused on consistency. Spacing between any two related elements is always the same (1.5 ems), and spacing between two unrelated elements should always be consistent (3 ems.) Hardly imaginative, but consistent. However, font sizes, line-heights, and most other metrics are based off of what I found in similar projects or in practice. Popularity and convention are nice, but are poor justification.
Poking around and looking at things like typographic scales and ideal text widths, I came across the golden ratio a number of times. The golden ratio, ~1.618, is supposed to be inherently aesthetically pleasing, occurring through history and nature. I had played around with using the golden ratio before, but found it was a little too big as a ratio (~1.618) to use for line-heights, for example:
Still, the golden ratio seemed like a great starting point. This got me thinking about typographical metrics. To define a few:
Font size is what we specify, but doesn't seem to correspond to any part of the text's actual height or width.
Whereas point size is roughly from the top of uppercase letters to the bottom of letters like 'y' or 'p'.
Cap height is the height of uppercase letters.
X-height is the height of lowercase letters like 'x' or 'o'.
Leading is the space in between lines.
And lastly, line height, is point size plus leading, but is normally expressed as a ratio to the font size.
The golden ratio is really meant to be between visual elements, and the font size isn't the actual size of the text. Here's Lato at 100px, at 2x magnification:
The truth is that all of the dimensions of 100px Lato are smaller than 100px. If I want the ratio between leading and point size to be golden, I need to adjust for the difference between font size and and point size. I did this and got a line height of 1.44. This is closer to what I was hoping for:
However, the more I looked at this, the more I was unsatisfied. Two things stood out:
I wanted to use the x-height instead, as that seemed like a better measurement of height of the text than point size.
I wanted more leading. In fact, I wanted to try making leading ~1.618 times the size of the text, instead of the other way around.
After these changes, I ended up with this:
This works out that, if you'd like the ratio of your x-height to leading to be golden when using Lato, you should use a line height of approximately 1.36. Here's the text again without highlighting:
And here's an overlay, showing the golden spiral overlaid on some 100px Lato at 4x:
This was enough to make me happy. Now I have a method for picking line heights that I can justify and do without fussing around or trying to decide which looks better.
I measured a few other popular fonts and shared the results below. I'm not suggesting that these line heights are always the best choice, but at least these numbers have some reasoning behind them.
iMarcians care very much about doing their very best, whether it’s code, design, experience, or content. We argue—sometimes vociferously—about what, exactly, is best. Today's topic: Punctuation.
Let’s talk about dashes. There are many—see Your PC is not a typewriter for the full list. I’m interested in the use of dashes to denote an change in thought or direction, for example:
Many readers of Adventures of Huckleberry Finn consider the ending flawed—Hemingway, for example, said that Twain “cheated”—while others have praised it. (source)
You’ve got two choices, the en-dash and the em-dash.
Typographer Robert Bringhurst has exiled the em-dash, claiming it’s Victorian. However, other typographers disagree based on contemporary American usage. The Chicago Manual of Style prescribesthe unspaced em-dash, as does the Oxford Guide to Style, the New York Times Manual of Style and Usage, and most American book publishers.
Spacing around the em-dash is a valid concern. Full spaces can really make words seem too far apart; typographers solved this problem centuries ago. Modern recommendations vary by style guide; most American, Austrialian, and some British guides recommend using hair spaces or simply setting them closed. Several major English publishers (including the prestigious Cambridge University Press) use a space, en-dash, space, and most Canadian style guides do as well. (Did I mention that Bringhurst is Canadian?) The spaced en-dash is the convention in German and French as well.
Here are samples of the spaced en-dash, the un-spaced em-dash, the spaced em-dash, and the hyphen, set in Georgia and as rendered by Safari 7… (I’ve borrowed and mangled content from DIY Leather Tassel Necklace, which I found because of the domain name. Ironically, she uses en-dashes instead of em-dashes.)
And that’s in a decently well-made font. Some font designers make, ah, questionable choices. For example, the Mac system font Lucida Grande, for no good reason, uses almost identical glyphs for the en-dash and hyphen, making the em-dash the only sane choice:
So, we can’t count upon commonly used fonts to have sane metrics (except for newer browsers which support @font-face—hooray for them!). But it gets worse.
The real trouble with “space en-dash space” is line breaks. Web browsers traditionally suffer from truly horrific typography. No line should begin with a dash of any sort, yet browsers will cheerfully honor a space for a break and push your en-dash to the next line:
Any good typographer would catch and fix this, but web browser engineers haven't yet noticed the problem.
(Let’s not even get into Microsoft Word’s autocorrect follies, other than to say it rarely honors the typeface you’ve selected and substitutes fonts without telling you.)
So now what?
The en-dash can’t be relied upon to look right, and it causes weird wrapping. The em-dash is right in every font I’ve examined, and it prevents browsers from doing horrible things.
Most British and Canadian publishers prefer the spaced en-dashes. Most American publishers and newspapers prefer the unspaced emdash.
We definitely don’t use French or German as our working language.
We’re an American company and our clients’ sites are overwhelmingly written in US English. We should use—nay, mandate!—the unspaced em-dash.
Or we could sidestep the debate entirely. Just put in a period and start a new sentence. It worked for Hemingway.
This has been a big growth year for us in many ways, and there are three fundamental things that we have to execute very well on for that to happen. If you're interested in how we work our magic, here's the recipe for iMarc's "Special Sauce":
In fact this is always a work in progress, and evolves with nearly every project because it's so core to our operations. It's been nearly 17 years since we first started producing web projects, and we've learned quite a lot about what works really well, and made our share of mistakes along the way too. For brevity on our site here we've distilled it into three primary phases: Discover, Create, Innovate, but each of those include a lot of sub stages, checks and reviews, and collaboration points with our clients and our internal and external project partners. If you don't develop and stick to a sound process its easier to get derailed and lose control of a project.
I frequently refer to this as the "dovetailed joints" of our work, the part of our craft that is unseen by many, but has such a large bearing on the long-term stability, security, and potential for ROI of our work. There's so much that goes on under the hood to make the work great - how we provision and manage our servers and development environment, the developer tools we create and use, the professional code standards we adhere to, our discovery, design and UX techniques, and much more. We work very hard to stay current with the best practices of our constantly-evolving industry, and we have collected all of our best practices in our Company Handbook. If this is your business too you may feel free to use them and we hope you find them as valuable as we do. http://handbook.imarc.net/
None of this works at all without great people, and we have that in large measure. Have a look over on our "About" page and meet the team. Many of the crew have been with us for 10+ years, and although we do enjoy a deep bench of excellent freelancers and contractors that help with our projects now and then, we rely on full-time staff for the most part, and we're happy to show them off on our site. These are the people that produce the award-winning work and we're proud of them and grateful for the contributions they make every day to our company and our clients.