Markup

There is a longstanding problem with the Bitcoin’s user experience, and it’s a problem that grows along with Bitcoin’s price. Luckily, it’s easily solvable.

This UX issue has nothing to do with user-interface or interaction design, but is instead typographical in nature — it involves the format by which amounts of Bitcon are typically expressed.

I hereby take my stand against the use of huge body text in online articles, particularly on magazine-type sites that presumably want to foster a comfortable reading experience.

Now, the examples below are from desktop websites. I realize these days people basically only care about mobile. But I have also come across the too-big text problem on mobile sites, and I do think consideration should still be shown for the needs of desktop users, of whom there are still many — for example, people goofing off at their work computers.

So how big is bad? Well, as Potter Stewart said of obscenity, I know it when I see it. Consider this example from Bloomberg Businessweek. (Apologies for Tumblr’s inability to use high-res inline images. Click images for full-sized screenshots.)

I deem this text to be Too Big. Here, the browser is as large as I can make it without taking it full screen. Note the difference in scale between the UI elements on the screen, like the menu bar items, and the article’s text. Also, note that my screen is not at its default resolution here — it’s a Macbook Pro 13″ with its display scaled to simulate a higher resolution, so the problem is even worse at the default screen resolution. 

For a worst-case scenario, how does the layout look on, say, one of those little 12-inch Macbooks, with a screen size of 1152 x 720 points? Something like this: 

That’s just crazy! Not even one entire paragraph is visible. Is that really a nice way to read on the web? And it’s even worse where articles are broken up with lots of ads and such. (The body copy uses the font Publico at 22px, if you’re wondering.)

I think some designers might do this because they think huge text enhances readability and creates a certain modern aesthetic. They might also reason that on the Web, as opposed to print, since there is no "budget" as far as the area taken up by written content, they should take advantage of this freedom afforded by electronic media.

I would guess that another reason is that layouts are concocted on some web designer’s gigantic 27- or 32-inch display, where the large text might seem to look pretty good.

But on the typical user’s smallish laptop display, layouts with a huge font size look like they came straight out of a Reader’s Digest large-print edition (Remember those? Ask your grandpa!). This detracts from readability, because the reader needs to scroll constantly as he or she reads it.

Designers typically use fancy Macs with nice trackpads and Magic Mouses that enable cool "inertia scrolling” gestures that let you scroll vast distances with a quick flick of the fingers. They thus may be oblivious to the agony of people using old Windows machines, many of whom, to scroll content, have to fiddle with ancient mouse wheels, or even (the horror!) click and drag on scroll bars. 

And readers often scan articles rather than actually reading them. With so little content on the screen at a time, scanning becomes a chore.

Finally, for some purely subjective commentary, I just don’t like it! It feels less comfortable to read something that uses text so grotesquely big and out of proportion with everything else on my computer's display.

When you read a well-designed print magazine like the New Yorker, are the articles set in giant text? No, and that’s not because they’re trying to save money on paper (or at least not only because of that). It’s because print designers, building upon hundreds of years of tradition, know what sorts of layouts are most pleasing to read. 

For contrast, see this example from the good old New York Times, using Georgia at 17px in this example (here, we're back at my scaled-up 13" display resolution): 

Much better! To quantify the difference, 218 words of article text are visible in this NYT article versus only 154 words on the huge-text Businessweek article in a window of the same size, even though the NYT has an annoying banner obscuring the bottom of the page. 

Here’s an example from the New Yorker: 

Also good! Here, 248 words are visible (again, versus only 154 words for Businessweek). The font size is a little bigger, but still not too big, and the generous column width lets more of the article fit in the viewable area.

Note that the article text in the preceding two examples does not seem wildly out of scale with the UI elements on the screen — in fact, that would be my rule of thumb for sizing body text: it should have some reasonable connection to the scale of other content on a typical user’s display such as email messages, UI labels, and typical web content, such as Google search results. Your article text can be larger than these things, but not too much larger. 

On Quora, I wrote an answer to this question: “What do you think is the key difference between About Face by Cooper, Design Sprint by Jake Knapp, and Lean UX by Jeff Gothelf regarding user research?”

Compared to those other books, I would say that About Face outlines a more monolithic approach to UX design in general and to user research in particular. By that I mean that Cooper prescribes a rather elaborate process for designing a product, including stakeholder interviews, competitive and industry research, and “ethnographic” research (including going onsite with prospective users and observing their day-to-day activities), and user interviews. All of this takes place in an introductory phase of a larger design process that can be seen as a long pipeline that culminates in the delivery of detailed design documents to a development team, which the designers will support as development proceeds.

In contrast, both Lean UX and Design Sprint envision shorter cycles of design, experiment, test, feedback, and iteration — in the parlance of Lean UX, the build-measure-learn loop.

Have you heard that we’re going to get some new emojis in 2017? Emoji 5.0 adds 56 new symbols, including nine brand-new smileys like Exploding Head and Face With Monocle. The following examples are from Google's Android O implementation:

Yet still left unremedied is a glaring omission in the standard smiley set — tears of happiness. I don’t mean the message conveyed by the existing uproarious-laughter emoji — 😂— but rather a sort of sentimental, overcome-with-emotion kind of happy crying:

I posit that this is a pretty basic and well-recognized emotional state that people would readily express through the means of emoji. I mean, it would sure be more useful than, say, “laughing & sweating” (😅) and “weird clown face” (🤡), am I right?

And so I’ve mocked up what said smiley might look like in various styles.

A typical use case follows:

The Magic Mouse 2′s awkard charging stance has become a symbol of Apple’s supposed loss of design mojo. This post from my LinkedIn timeline expresses a typical sentiment:

“See, the mouse is useless when you’re charging it,” say the critics. “If only they’d thought to put the charging port at the end of the mouse, so it could work like a regular wired mouse while it’s charging! Plus, this just looks dumb.”

In fact, I’d say that Apple’s solution here is a pretty good one, and here’s why: 

If you could use this mouse while it was plugged in, a lot of people would use it that way permanently, or at least a lot more than necessary — they would always leave it plugged in, similarly to how laptops are often plugged in whenever they're used. Many of these users might not even realize the mouse is wireless and assume that it always had to be plugged in.

This would degrade the overall experience by turning a wireless mouse into a wired mouse. In fact, it would be even worse than a normal wired mouse, because Lightning cables are stiffer and bulkier than a typical mouse cord, which is lighter and more flexible. What's more, the Lightning cable might be longer or shorter than the optimal length for a mouse cord.

It seems better to make charging the mouse and using it mutually exclusive activities. You use the mouse unplugged, can’t use it when it’s charging, and that’s that. (All this assumes the necessity of a wire for charging — presumably, wireless charging will soon be a viable option for things like this.) 

Obviously, Apple’s solution can be inconvenient if the battery happens to run out completely while you’re using the mouse. I’m guessing that in practice, though, this doesn’t amount to much of a hardship. The user is presumably given plenty of warning in macOS when the mouse’s battery is running low. Charging the mouse doesn’t take very long, and the charge is supposed to last as long as a couple of months. 

I’m not saying that Apple has necessarily hit upon the best possible solution here, but I don’t think the critics of this design have put forward a better one. 

In olden times, when you were looking at a web page in a browser, you’d always see the full URL in the address bar above it — at least, as much as would fit. In most browsers, this is still the case.

But if you’re using Safari for iOS or Mac, it shows only the domain name, leaving off anything to the right, such a path and filename. You can only see what’s to the right of the domain name when you tap (or click) on the address bar in order to bring it into editing mode.

Here, I’ll argue that this is a bad thing.

(Thankfully, you can, at least for now, optionally set Safari for Mac to show full web addresses.) 

Apple introduced this URL-truncating behavior with iOS 7 along with a dramatic redesign of the OS. Safari for Mac followed a year later with Yosemite. (Update: apparently Chrome on Android does this too.)

The philosophy behind many of those design changes was to remove extraneous or decorative elements, leaving only the bare essentials of the interface. In some cases, UI elements disappear from the screen completely in order to give content the sole focus.

Many of these changes have arguably been detrimental to iOS’s usability, and have been widely debated and discussed elsewhere. Here, I’ll focus on the URL issue.

I’m not sure if Apple has ever bothered to articulate the rationale behind this change, but if they did, it would probably sound something like this: In the context of the address bar, the domain name itself (e.g. example.com) is a concise way to help the user identify the site. It’s a cue that tells the user that the full web address is there and can be conjured up if tapped/clicked and then copied, edited, whatever. But the path, filename, query string, and whatever else can appear after “.com/” is technical, noisy, and often meaningless and normally there’s no reason for it to be visible to the user. Therefore, showing the entire URL is against Apple’s ethos of hiding technical details from users (and it could even compromise security).

So what’s wrong with this line of reasoning?

There’s usually useful information to the right of the domain name, and there are good reasons it should be visible even when the user hasn’t given focus to the address bar. 

At the most basic level, when full addresses display, you know immediately whether you are on the site’s home page. If you only see a domain name, you’re at the main page. But the rest of the URL can also provide more fine-grained information about where you are.

To be sure, some web addresses contain unhelpful gibberish — for example, you used to come across a lot of articles with URLs like this:

news.com.com/2100-1083_3-5138072.html

But for reasons of human-readability and search engine optimization, most modern sites and content management systems these days generate more meaningful URLs that are easier for human beings to parse.

Consider some examples:

washingtonpost.com/politics/

washingtonpost.com/news/post-politics/wp/2015/09/15/white-house-formally-announces-chinese-president-xi-jinpings-first-state-visit-on-sept-25/

afar.com/travel-guides/france/paris/guide

afar.com/hotels/cusco-peru/belmond-palacio-nazarenas

freakonomics.com/books/superfreakonomics/

freakonomics.com/2014/05/07/testing-the-limits-of-google-translate/

It’s clear which URLs refer to articles or blog posts (the inclusion of a date is a big hint) and which point to other sorts of pages. And these addresses convey not only information about the content of particular pages, but about the information architecture of the website. For example, the first freakonomics.com link tells you that you’re looking at a page about a book called Superfreakonomics, but also suggests that you’re in a books section that presumably contains other pages about books.

This is not to say that users scrutinize every URL they come across — most are undoubtedly mostly ignored most of the time (although I’d argue that when it’s visible, the user unconsciously scans its information). And a page layout will surely give you cues that tell you what sort of page you are on and where you are in the site’s hierarchy if it’s designed well.

Unfortunately — this might come as a shock — not all websites are designed well. Many don’t give you a good indication of where you are. And especially on blogs, it can be unclear — especially in the above-the-fold portion of the page — whether you are on an individual post, the home page, or on a page showing all posts of a tag or category. With a full URL, this information is clear at a glance.

And even for sites that are thoughtfully designed, they all are done a little differently, and so it takes some extra cognitive effort to interpret a particular layout and its navigation cues. But there’s always a URL, and it acts as a concise but information-dense indicator of where you are and what sort of a page you’re on.

On iOS, Safari’s URL-hiding can be particularly annoying. Consider that on a cellular connection, data speeds can be quite slow, particularly if you have spotty coverage (i.e. you use T-Mobile). Say you launch Safari and it immediately begins to reload whatever is in the frontmost tab, which in this case says “facebook.com.” While it’s loading, the page is totally blank.

“It’s taking a long time to load, but when it does, I will see all of the delightful things that have been posted to my news feed!”

Oops, it was just a leftover tab from when I used Facebook to log in to a different site! Cue sad trumpet.

For this reason, I’m often faced with the decision of whether to tap on the URL in mobile Safari to make sure I’m going where I think I’m going, or just wait, taking the risk that I’m wasting time loading a page I don’t want to see. This unnecessarily introduces a situation where the user doesn’t know what’s going on, which is never a great thing in a UI.  

In short, full URLs are concise, human-readable, metadata-rich info-nuggets, and there are plenty of good reasons not to hide the portion that often has the most useful information. I realize that this train has long left the station, but I remain a proud UI reactionary. Long live the URL!

P.S.Designers looking to mitigate the domain-name-only problem might wish to consider the example of the New York Times blogs, where some important information is placed in off to the left, not the right, in subdomains that are always visible in the address bar. It doesn’t solve the problem completely, but it’s a way to add some higher-level navigational landmarks to the address bar. (Unfortunately, mobile users are still redirected to a generic mobile.nytimes.com domain name.)

I’m not sure what the rationale of that construction is, as it has been the convention for NYT blogs since before iOS 7 was a thing. SEO probably had something to do with it, but I wonder whether they were also thinking about the UX of typing URLs. For instance, if you want to read Mark Bittman’s blog, you can just start typing “bittman” in the address bar, and, if you’ve visited before, the rest of the URL autofills, and then you only need to hit Enter.

P.P.S. For more on the UX of URLs, see this Jakob Nielsen piece from all the way back in 1999. The principles of good URL construction still apply. Fun fact: according to an eye-tracking study, “people spend 24% of their gaze time looking at the URLs in the search results.” I wouldn’t be surprised if this were still true.

The article contains this interesting passage: “It is likely that domain names only have 3-5 years left as a major way of finding sites on the Web. In the long term, it is not appropriate to require unique words to identify every single entity in the world. That's not how human language works.” Nielsen was on the right track — Google and social media have made the act of typing in URLs a much rarer occurrence. Yet Nielsen’s prediction of the emergence of a superior addressing system has not come to pass.

I once worked in the interactive department of a PR firm. We made websites for big companies. Our department employed two full-time proofreaders. At multiple points during a web project, every page of the website would be printed out and anything made of words was checked — body copy, menu items, alerts, labels, tag lines, subheads, pull quotes, you name it. The proofreaders were very good, and they always found a surprising number of errors.

At another time, I was a volunteer on a small political campaign. I’d written a press release that was checked and ready to go, but at the last second, the candidate added one line and sent it off himself. In that one sentence, he misspelled his opponent’s name. It made us look stupid, and he was embarrassed.

I’ve been a staffer at two magazines, and at both, we went through multiple rounds of proofreading before sending an issue to the printer. Editorial staffers at all levels took part. A single piece of copy might have been checked a half-dozen times before going to press. Mistakes — sometimes bad ones — would still go out, but tons more were prevented.

I often see grammatical mistakes, stylistic errors, and just plain typos in well-known applications like GrubHub’s in the above example. In one company where I worked, the name of our company was spelled two different ways throughout our products and company website. If your product has errors and inconsistencies like that, it seems junky and amateurish.

With what’s happened to the publishing industry in the past decade or so, there are a lot of underemployed proofreaders and copy editors out there. Use them! And if you can’t, at least establish a style guide and a process where multiple sets of eyes check every piece of language before it goes out the door. You (hopefully) QA your software; QA the words, too!

P.S. The error from that GrubHub image that jumped out at me and inspired this post was the circled portion, where “let’s” should have been “lets.” But an eagle-eyed proofreader would notice a few more things:

The logo says “grubHub,” while the headline says “GrubHub.” Which is it?

The text field placeholders are capped up (“Enter An Address”), but the labels (”Where are you?”) aren’t. Is that what you want? Even if it is, “An” should be capped down regardless.

To be consistent with the placeholder in the second text field, something like “Street address” would work better in the first. 

And does it matter?

My post on LinkedIn's use of dark patterns garnered a few comments on Reddit, and a couple of negative remarks there prompted me to write this update. 

Here are the comments in their entirety. The first:  

What? I didn't want to add all my gmail contacts! Better just fill out these forms, click through these screens, and hope this does what I wanted to do!

I think this is just a mix of LinkedIN's [sic] terrible metric-driven design and this guy being a moron.

And the second: 

I hate IinkedIn [sic] for the shady practices of maintaining hidden profiles for unregistered people and it's the main reason I'm not a member.

However, there are so many clues throughout those steps that you're not simply inviting one person that it comes across as a little contrived.

Why anyone would give over their email account password to ANY site is beyond me.

I expected this sort of response so I suppose it's worth addressing these points, which boil down to:

It was my own fault for being stupid

In particular, I was stupid for putting in my Gmail credentials when LinkedIn requested them

It's never a good idea to dismiss the consequences of bad design as the result of the user's stupidity. And in this case, as I argued before, the design isn't just bad, but is intentionally misleading, as both commenters seem to acknowledge. 

LinkedIn is a publicly traded company with revenue of $1.5 billion in 2013. You'd expect some baseline of good behavior from such a grown-up service. I certainly didn't expect it to employ dark patterns in an effort to spam my contact list. Maybe I should have, but LinkedIn’s bad faith was the point of my post.

The fact that I didn't expect it explains why I could blithely "fill out these forms, click through these screens, and hope this does what I wanted to do," which commenter #1 finds moronic, commenter #2 "contrived." Trust me, it's a different experience to actually go through the screens trying to perform a task than to read an analysis of the process after the fact. What’s more, well, yeah! Of course I “clicked through these screens,” thinking the things I expected to happen would happen! That’s the point of a UI, fool! I should be able to go about my business using established services like LinkedIn without always worrying that someone hiding behind a tree will dart out and punch me in the face. 

But wasn’t it dumb to put my Gmail credentials into LinkedIn? Well of course it was! That became obvious as soon as I realized that my contact list had been spammed. But my experience is utterly typical — as evidenced by the class-action lawsuit and numerous complaints on LinkedIn's help boards.

I had qualms about granting access to my Gmail, but it seemed like the quickest way to move forward, and I assumed it would be easy to skip over anything that could get hairy — in short, I was assuming a minimal level of good faith on LinkedIn’s part. 

A cautious user might always deny Account A’s request for access to Account B, the rule commenter #2 seems to advocate. But the idea that I violated some basic rule of internet hygiene by putting in my Gmail credentials is spurious.

In fact, it's a common practice to grant one service access to one's account on another service. For instance, my accounts on Spotify and Quora have access to my Facebook account. I put my bank and credit card credentials into Mint. You know why? Because integrating those services is useful, and they are trustworthy enough not to do anything horrifying with the access I've given them.

It will spam everyone you know using one weird trick

I recently was fooled by LinkedIn into bombarding most of my Gmail contacts with invitations to "connect." Or, more accurately, LinkedIn spammed my Gmail contacts by way of its confusing, deceitful design.

Am I letting myself off the hook too easily for not paying close enough attention to what I was doing? I readily acknowledge that I should have been more careful, but my experience was not unique: the same practices that hoodwinked me are the subject of a class-action lawsuit recently green-lighted by a federal judge.

In fact, I'd argue that much of LinkedIn's viral growth is due to the evil UX methods I describe below. 

The troubles began when I decided that I wanted to send a LinkedIn invitation to one person who was not already a member. Again, I only wanted to send one invitation to one e-mail address. Sounds easy, right? 

Well, how would one go about doing such a thing? 

Spotify uses a little speaker-indicator to show which track is currently being played. You can see it at the left side of the image below. 

Unfortunately, that indicator is placed in the exact piece of real estate that otherwise shows you whether the track is "starred". 

Therefore, with the track currently being played, you have no way of knowing whether it is starred or not until you hover over the speaker icon with your mouse cursor, which hides the speaker/playing icon to reveal whether the track is starred.  

(Starring tracks is a pretty important action to me, as I often use the "Starred" collection as a playlist.)

Unfortunately, the vast majority of the times that I have wanted to know whether a particular track was starred have been while the track is playing.

This makes sense, right? "Hey, I like this track. Have I already added it to my favorites? I can't tell by glancing at it, because the speaker icon thing is in the way, so I'll push my mouse cursor to hover over this tiny icon ... ah, I see now that I'd already starred the track. Never mind." 

Zipcar was having some trouble when I was trying to modify my reservation today.

After clicking on a “change reservation” link, I first saw an animated activity indicator—

and after a minute or so, the site apparently gave up, serving up this page with this message:

“Hang on while we refuel. We’ll get you zipping again in no time.”

As an error message, this is worse than useless. If the site instead had served up, say, a generic error page with a status code, I would at least be aware that something went wrong. But with this message, I could only be sure that an an error had occurred because the word “error” was in the URL.

This message sacrifices clarity for cuteness. Why?

It doesn’t clearly indicate that an error occurred

It doesn’t explain why it happened

The user’s recommended next step is ambiguous

“Hang on while we refuel / We'll get you zipping again in no time" could be interpreted as an instruction to do nothing and wait for something to happen

How about something like this:

Sorry, but an error occurred. Our website is too busy to complete your request. Please try again later. If you require assistance now, call 1-866-4ZIPCAR.

An error page should explain what happened in non-technical terms and guide the user to a solution. 

Back in the old days, Georgia and Verdana were the workhorse typefaces of the Web. They were designed specifically to be highly legible on low-resolution displays (i.e. screens) whereas most older typefaces were designed with a very high resolution display in mind (that is, paper).  

But today's larger, higher-resolution screens, as well as easy-to-use web-font solutions like TypeKit, are allowing designers to create roomier designs with more adventurous typography. The smartphone world in particular, with Retina-class displays (and print-like screen resolutions) nearing ubiquity, might encourage even greater latitude.

But the fact that a high-DPI display can flawlessly render razor-thin letterforms doesn't give us an excuse to stop worrying about legibility.

You can see in the top screenshot that Mashable's site, set in Helvetica, is more readable than Betaworks on the bottom (using a free Google font), even though Betaworks uses a larger font size. The difference is more pronounced on an actual Retina iPhone screen, which is smaller (and sharper) than the above screenshot—assuming you're not reading this on a mobile device!

iPhone and other super-high-res screens might have incredible sharpness, but don't forget that you're still dealing with little letters on a very small screen. 

I'm not advocating a return to the boring old days of Verdana everywhere, but when choosing a typeface, particularly for a mobile application, legibility still needs to be the top concern.

Sometimes when I'm using Yahoo Fantasy Baseball, I'll apparently be logged in normally, able to browse around and view my team and league info:  

  But when I try to take some action like changing my lineup, this browser alert box pops up, telling me, "Your login cookie has expired":   

     When I hit "OK," I get kicked out to a generic Yahoo page (featuring an enormous ad) that makes me type in my password to continue:

UI gaffe: QuarkUpdater

When you install QuarkXPress for the Mac, its installer sets up an updating utility to automatically run at a set interval.

If QuarkUpdater finds that you have the most recent version of QuarkXPress, it pops up a modal dialog box informing you of the fact. 

So I am sometimes greeted by this unasked-for dialog, and QuarkUpdater's bouncing dock icon, when I arrive at work.

I assume it behaves this way to keep the user informed when he or she manually initiates a check for updates. But it doesn't make sense to show this dialog box when the updater is run automatically. The auto-updater should unobtrusively check for software updates without bothering the user when there is nothing new to report.

If you're wondering, you can disable automatic updating of QuarkXPress in System Preferences, in the Quark Update preference pane. 

Daring Fireball is on my daily must-read list. When he's at his best, John Gruber's insight and analysis are indispensable. 

But often, he tosses off drive-by opinions like the following: 

Ron Johnson Out at JC Penney

I’m with Moltz and Panzarino; they shouldn’t have hired him if they weren’t going to give him more time to turn it around.

Really? So what does Gruber know about JCP's financial condition, the retail industry, Ron Johnson's execution as CEO, or JCPenney's business in particular? I'm guessing he doesn't follow any of these things too closely. 

The culprit is an acute case of smart-guy-itis—a condition suffered from many whose high intelligence leads to overconfident pontificating about issues outside of their areas of specialization. (It's similar to male answer syndrome.)

For an egregious example, let's look back to January 18, when Gruber was pushing a theory hatched by some guy on Seeking Alpha claiming that options traders were conspiring to push Apple's stock price down, with the goal that certain options would expire worthless when the stock closed at or below $500. The conspirators would then amass big profits during the inevitable run-up in Apple's stock price that would follow.

As AAPL closed at $500, quoth Gruber, "I still have that bridge to sell you if you don’t think the fix was in on this."

Not "this looks like an interesting theory" or "the closing price seems a bit uncanny," but to Gruber, this conspiracy of options traders to manipulate Apple's share price was so obvious that he had a bridge to sell to skeptics. He should get a job at the SEC!

The ensuing run-up in Apple's stock price didn't happen. Today it closed at $426.98. Where's my bridge? 

Anyhow, back to Ron Johnson, whose reign lasted a short two years—not long enough to have a fair shot at a turnaround, claims Gruber.

"Dig responsive design? Hate fluid grids? Try a Frameless grid." I was sold on the Frameless approach when I first laid eyes on that headline. But I had a hard time finding examples or technical explanations showing how the Frameless system is used, so it was difficult to get started. After figuring things out a bit, I decided to write this tutorial in the hopes that it will be useful to others. 

Let me start by sharing links to the most useful resources I've found elsewhere. 

This article by Pete Wailes doesn't go into technical detail; its purpose is to give you a high-level approach to designing for the Frameless grid system.  

Stack Overflow user lolmaus offers a plain-English overview of the Frameless grid. 

Another denizen of Stack Overflow, Davy8, explains Frameless's core LESS variables and mixins. 

The Frameless stylesheet is implemented in both LESS and SASS, which are CSS preprocessors that allow for such goodies as variables, nested rules, and more. I elected to use the LESS version for this guide. If you're unfamiliar with LESS, I recommend spending a short time learning the basic concepts before continuing. I also assume you're well-versed in CSS.