Group items tagged

the subconscious mind is energized when jumping to the next line (as long as it doesn’t happen too frequently, see above bullet point). At the beginning of every new line the reader is focused, but this focus gradually wears off over the duration of the line (“Typographie”, E. Ruder).

In the last update, Google changed the layout of posts so that you only see three lines of the original post before you see “Read more” link. In other words, your first sentence has to be a gripping teaser to get people to click “Read More.”

The ideal length of a Google+ headline is less than 60 characters To maximize the readability and appearance of your posts on Google+, you may want to keep your text on one line.

Many different studies over the years have confirmed that shorter posts are better on Facebook.

Writing for KISSmetrics, headline expert Bnonn cites usability research revealing we don’t only scan body copy, we also scan headlines. As such, we tend to absorb only the first three words and the last three words of a headline. If you want to maximize the chance that your entire headline gets read, keep your headline to six words.

some of the highest-converting headlines on the web are as long as 30 words. As a rule, if it won’t fit in a tweet it’s too long. But let me suggest that rather than worrying about length you should worry about making every word count. Especially the first and last 3.

The ideal length of a blog post is 7 minutes, 1,600 words

to ensure maximum comprehension and the appearance of simplicity, the perfect line length ranges between 40 and 55 characters per line, or in other words, a content column that varies between 250-350 pixels wide (it depends on font size and choice).

Consider that shorter lines appear as less work for the reader; they make it easier to focus and to jump quickly from one line to the next. Opening paragraphs with larger fonts—and therefore fewer characters per line—are like a a running start to reading a piece of content. This style gets readers  hooked with an easy-to-read opening paragraph, then you can adjust the line width from there.

In September 2012, MailChimp published the following headline on its blog: Subject Line Length Means Absolutely Nothing. This was quite the authoritative statement, but MailChimp had the data to back it up.

Beyond the perfect length, you can also adhere to best practices. In general, a 50-character maximum is recommended, although MailChimp does point out that there can be exceptions: The general rule of thumb in email marketing is to keep your subject line to 50 characters or less. Our analysis found this to generally be the rule. The exception was for highly targeted audiences, where the reader apparently appreciated the additional information in the subject line.

The ideal length of a title tag is 55 characters Title tags are the bits of text that define your page on a search results page. Brick-and-mortar stores have business names; your web page has a title tag. Recent changes to the design of Google’s results pages mean that the maximum length for titles is around 60 characters. If your title exceeds 60 characters, it will get truncated with an ellipse.

Finding a hard-and-fast rule for the maximum recommendation of a title tag isn’t as easy as you’d think. Quick typography lesson: Google uses Arial for the titles on its results pages, Arial is a proportionally-spaced font, meaning that different letters take up different width. A lowercase “i” is going to be narrower than a lowercase “w.” Therefore, the actual letters in your title will change the maximum allowable characters that can fit on one line.

When you hover over a menu item, a submenu appears. But apart from hovering over an item, you can also simply click on it to follow the link. Now, what should happen when you tap on the item with a touch device? Should the submenus appear, or should the link activate? Or both? Or should something else happen? On iOS, something else happens. The first time you tap a link like that, the submenu appears; in other words, the hover event fires. You have to tap a second time to actually follow the link. This is confusing, and not many people will tap a second time. On Android, the submenu appears and the link is followed simultaneously. I don’t have to explain to you that this is confusing.

It’s very well possible to think of complex solutions11 whereby you define different interactions for different input devices. But the better solution, I think, is to make sure that the default interaction, the activate event, just works for everybody. If you really need to, you could choose to enhance this default experience for certain users.

The same principle that we follow for interactions — whereby we design the activate event first and enhance it later — applies to graphic design. We should start designing the things that we know everyone will see. That’s the content. No matter how big or small a screen is and no matter how minimal the feature set of a browser, it will be able to show letters.

rather than pollute the page with all kinds of links to get people out of there, we should really focus on that thing in the middle. Make sure it works. Make sure it looks good. Make sure it’s readable.

you start by designing the relationship between the different font sizes.

When the typography is done, you would start designing the layout for bigger screens; you can think of this as an enhancement for people with bigger screens. And after that, when the different layouts are done, you could add the paint. And by paint, I mean color, gradients, borders, etc.

When I say to start with typography, I don’t mean that you aren’t allowed to think about paint at the same time. Rather, I’m trying to find the things that all of these different devices, with all of their different screen sizes and all of their different features, have in common. It just seems logical to first design this shared core thoroughly. The strange thing is that this core is often overlooked: Web professionals tend to view their own creations with top-of-the-line devices with up-to-date browsers. They see only the enhancements. The shared core with the basic experience is often invisible.

All of the things we created first — the navigation, the widgets, the footer — they all helped the visitor to leave the page. But the visitor probably wanted to be there! That was weird.

To build a responsive website that works on all kinds of screens, designing for a small screen first is easiest. It forces you to focus on what’s really important: if it doesn’t fit in this small square, it is probably not terribly important. It forces you to think better about hierarchy, about the right order of components on the page.

Once you’re done with the content, you can start to ask yourself whether this content needs a header. Or a logo. Or subnavigation. Does it need navigation at all? And does it really need all of those widgets? The answer to that last question is “No.” I’ve never understood what those widgets are for. I have never seen a useful widget. I have never seen a widget that’s better than white space.

does the logo really need to be at the top16 of every page? It could very well go in the footer on many websites

the option to add extra luggage to a flight booking might be most effective right there in the overview of the flight, instead of in the middle of a list of links somewhere on the left of the page.

does the main navigation look more important than the main content? Most of the time it shouldn’t be, and I usually consider the navigation to be footer content.

Fluid layouts are often compared to water, but water isn’t always fluid. H2O has three different states, and depending on the temperature can be a solid, liquid, or gas, transitioning seamlessly from one to another at specific points (0ºC, 100ºC). An infinite grid also has multiple states (single column, multi-column, etc.), and should transition as seamlessly as possible between them at specific breakpoints as well. For example, just as ice is an appropriate state for water when the temperature is low, a single-column layout may be the appropriate state for an infinite grid on smaller devices. Water’s state change is caused by the rearrangement of its molecules. When an infinite grid changes state, we rearrange its components.

Each state in a responsive layout tends to be made up of the same components, such as an image gallery or navigation menu. However, as Ethan Marcotte recently outlined, the form these components take can vary dramatically between one state and another, usually involving a change in one or more of the following attributes: Hierarchy: What’s its order and prominence in the layout? Density: How much detail do you show? Interaction: Should it be a list of links or a dropdown? A carousel or a group of images? Width: Is it fixed (a specific width), flexible (set with max-width), or fractional (set with percentages)?

Pixels size an element relative to a particular resolution Ems size an element relative to its font size; large rems size it relative to the document’s base font size Percentages size an element relative to its container VH and VW units size an element relative to the viewport

Absolute units like pixels effectively give a layout a sell-by date, locking it to a finite resolution range in which it will “work.” Proportional units (ems, rems, and percentages) enable you to define the important relationships between elements, and are a crucial first step on the road to resolution independence.

lets say my largest state is 75em wide (any larger and the white space starts to dwarf the content), and my smallest is 34em (any smaller and the measure is less than optimal). In the largest state it makes sense for my navigation to be a horizontal list (interaction) at the top (hierarchy), but in the smallest state it might make more sense to move it to the bottom of the layout (hierarchy), or collapse it into a show/hide list (interaction). Designing these independently of one another helps you be more objective about what is best for each state, rather than stretching a one-size-fits-all solution across every state.

Just like water changes to steam when its molecules get too far apart, one state should change to another when the relationships between its components begin to break down, such as when the measure is getting too wide, or the left-aligned logo is getting so far from the right-aligned menu that the visual connection between them is broken.

The number of states you require will depend on how much your layout changes from one extreme to the other. For example, my smallest state has a single column with a collapsed menu, and my largest state has three columns and an expanded menu. However neither state looks quite right between 34em and 53em, so I’ve added an “in-between” state which maintains the smallest state’s single column article, but expands the menu and divides the footer into three columns to make the most of the space available. This smooths out the transition from one extreme to another quite nicely.

With each state change, remember to reconsider the hierarchy, density, interaction, and width of each component

the goal is to make the most of the space available, relative to your content, to maximize readability and presentation.

Designing for our readers requires us to understand the information that they will find useful and relevant and then shape that content into a beautiful experience.

To deal with this issue, Web developers can borrow from some of their tried-and-true methods. For years, websites have used browser detection to deliver different CSS stylesheets to different browsers. A similar approach is used to craft responsive designs - when sites load different layouts depending on the device being used to view it. Likewise, this sort of tactic could be used to handle graphics

That's exactly what they're doing at O3 World, an interactive agency based in Philadelphia. To account for different screen resolutions, they've begun creating multiple sets of graphics, which are delivered dynamically, depending on the user's screen resolution.

People look at lists with bullets more often than lists without bullets (70% vs. 55%, respectively).

This coincides with additional research that shows people tend to view the left side of the screen overall far more than the right.

Relying on the screen above “the fold” to do all of the heavy lifting is one of the biggest usability mistakes you can make. The idea that it is the only place web users will browse is a complete myth.

Multiple tests (including this one and this other one) have shown that users have no problem scrolling down below the fold. Surprisingly, they will browse even further down if the length of the page is longer.

Users are extremely fast at both processing their inboxes and reading newsletters. The average time allocated to a newsletter after opening it was only 51 seconds. This means that you need to get to the point in your emails in under a minute.

This coincides with a study from MarketingSherpa that shows people prefer short, clear, and un-creative headlines for their emails. (Creative headlines can seem mysterious, and mystery in an inbox may equal spam.)

Once you’ve earned the right to appear in a prospect’s inbox, be sure to keep that privilege by crafting emails that are clear and get to the point quickly. You don’t have as much time to broadcast your message as you would in an online article.

From our sample size, we saw a clear tendency towards sizes between 12 and 14 pixels. The most popular font size (38%) is 13 pixels, with 14 pixels slightly more popular than 12 pixels. Overall, the average font size for body copy is 13 pixels.

Heading font size ÷ Body copy font size = 1.96

The overall value, then, is 1.96. This means that when you have chosen a font size for your body copy, you may want to multiply it by 2 to get your heading font size.

line height (pixels) ÷ body copy font size (pixels) = 1.48Note that 1.5 is a value that is commonly recommended in classic typographic books, so our study backs up this rule of thumb. Very few websites use anything less than that. The number of websites that go above 1.48 decreases as you get further from this value.

line length (pixels) ÷ line height (pixels) = 27.8The average line length is 538.64 pixels (excluding margins and paddings)

space between paragraphs (pixels) ÷ line height (pixels) = 0.754

According to a classic rule of Web typography, 55 to 75 is an optimal number of characters per line.