Group items tagged

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.

In the latter block, each division might have a different class name or perhaps different additional classes applied. This allows for greater flexibility in rearranging them in the layout. In the first block of code, the three content divisions will always reside inside their parent container.

With CSS, we have the ability to rearrange blocks inside a container. We don’t have the ability to break content out of one container and move it inside another container. If you want more mixing of blocks, then you’ll need fewer containers.

there are currently far more instances of websites that are dropping columns wholesale

Every element is its own unique block and serves as its own container. The page’s main heading is its own contained block. All of the meta information is inside another container directly below it. After that, every paragraph, subheading and image is also its own self-contained block of content. The same goes for anything else that might end up in a post, such as a block quote or code block.

a challenge to how we think about structuring our HTML, particularly to how we use containers. Elements can’t move from one container to the next. We can fake it with complex CSS, or we can rewrite the HTML with JavaScript; but, ultimately, if we want to intermix elements, we’re best of using fewer HTML containers to create columns. Instead, we should leave more of our content blocks in their own containers and use CSS to create virtual columns in the layout. This solution doesn’t confine our elements to structural containers and instead enables us to more easily rearrange the elements in different layouts.

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.

this trend is not always about skeuomorphism – which implies a connection to a past incarnation of a similar design – but rather often about realism [2]: a purely visual style that tries to imitate real-world materials and textures, exemplified by Apple's tacky over-use of leather textures in some of their own apps.

skeuomorphic designs tend to look realistic (to make the connection with the original object clear), and realistic designs tend to be skeuomorphic (otherwise the realism would look out of place).

touch target couldn't be smaller than a certain size (Apple's Human Interface Guidelines recommend at least 44 by 44 pixels).

showing less on the screen, but doing more with it.

realism done wrong can morph into kitsch

the problem of getting skeuomorphism wrong: making something look like a physical object, but not work like it

That problem is that when borrowing elements from a design's previous incarnation, you often also bring its limitations along for the ride, even when these limitations have no reason to exist anymore

When done right, skeuomorphism and realism will trigger strong associations with real-world counterparts. This is both a strength and a weakness: sometimes, the association can be so strong that it will stop you from improving on what's already been done.

Gone were the shadows, highlights, gradients, and textures of iOS apps. Instead, Metro offered flat squares of color with big typography.

Microsoft's new design philosophy certainly seemed to strike a chord within the tech sphere, with many praising Metro's strong focus on typography and colors.

And while flat design is often purely visual, it does resonate with designer's love of minimalist concepts, embodied by the famous Antoine de Saint-Exupery that “perfection is achieved not when there is nothing left to add, but when there is nothing left to take away”.

Two of the most talked-about games in recent month, Letterpress and Hundreds both feature flat designs. In fact, Letterpress creator Loren Brichter even revealed that the whole game only uses a single image!

When you have a high-definition display and screen-optimized fonts, you quickly realize you don't need much else to create beautiful work.

is pushing many designers towards prototyping in the browser directly, foregoing static mockups entirely.

Add all this together and you begin to see why many designers are moving away from texture-heavy realism towards the more flexible and lighter-weight flat style.

keep in mind that the needs of users should always come before our aesthetic pursuits

visual style is nothing more than a means to an end [15]. If the situation calls for realism, go nuts on textures and highlights. On the other hand, if a flat aesthetic achieves the design's goal better then it might be time to go on a gradient diet.

With the recent releases of their newer mobile apps, Google has started pushing a style that some describe as "almost flat" [18], or maybe "skeuominimalism" [19]. Unlike the drastic visual wastelands of Gmail or Google Reader, this new style uses elements like shadows and gradients in a tasteful, subtle way. This style offers the best of both world: realism's affordances and subtle hints combined with the purity and simplicity off flat design.

another way to look at it is that it's simply design done right: seeking efficiency and simplicity without sacrificing usability to the altar of minimalism.

I will pick a camp and put my chips in with flat design (specifically, Google's less-extreme variety).

Google is not so much pioneering a new style as showing us what digital design looks like when it's done right

catch up with what the web has to offer, we'll have to get our hands dirty and start coding [21]. And when you're both designing and coding a layout, you start to appreciate the value of keeping things lightweight.

Flat design also forces you to really care about typography and layout, two areas where web design has traditionally lagged behind its more established print cousin.

280 Slides:

LovelyCharts:

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.

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.