    
|
|
|
|
|
Once upon a time, websites were full of realistic textures, reflections, letterpressed type, and drop shadows. Buttons looked like actual physical buttons, menus like actual divider tabs. The departure from that aesthetic has a lot to do with the desire to move toward more resolution independent interfaces. It’s also just an evolution of taste as our users advance with technology. They are more open than ever to learn new features and interactions. This gives us more freedom as designers to explore new aesthetics like flat design.
But just because resolution independence and flat design prefer simple, scalable vector shapes over raster graphics and images doesn’t mean your website should be under-designed or any less usable. These tips will help ensure your flat aesthetic doesn’t fall victim to what might otherwise be referred to as a complete lack of design.
What I absolutely love about flat design is that it brings the emphasis back around to content. For awhile there, we were so focused on realism that content took a back seat. With flat design, there’s no fluff (quite literally) around the interface to distract the user from what’s important. But this can be a double edged sword if your information architecture isn’t well thought out.
Ensure usability when going flat by first fleshing out your content hierarchy. This usually takes place in the website planning and wireframing phase. Is your website’s content scannable? Can the user find his or her way quickly to the next actionable item on the webpage? A website’s aesthetic – whether flat or skeuomorphic – is irrelevant without a solid information architecture.
Content precedes design. Design in the absence of content is not design, it's decoration.
— Jeffrey Zeldman (@zeldman) May 5, 2008
One of the biggest usability concerns when implementing a flat design aesthetic is making sure actionable elements still look clickable. Flat design means less dimension, so harsh gradients and intense drop shadows on buttons are a no-go.
What that doesn’t mean is we simply strip our skeuomorphic design of any dimension and call it a day. Skeuomorphic and flat solve different design problems, so as designers and visual problem solvers, we have to approach flat design differently and address this particular usability concern in a new way.
Ensure actionable elements are still usable in your flat design by playing up contrast. This refers to color, size, and/or position of actionable elements to non-actionable elements. Provide visual cues as to which elements the user can interact with and visual feedback when the user hovers, clicks, or taps on actionable elements throughout your website. Was the click or tap successful? Is it loading? This could be as simple as a hover state (consider how this translates to mobile/tablet) or subtle CSS3 animation.
Exposure uses only a thin border to differentiate actionable elements, but provides strong visual feedback on hover.
Focus Labs‘ new website uses color, contrast, and positioning to differentiate clickable elements, and provide visual feedback on hover with CSS transitions.
Treehouse reserves bright, saturated colors as a way to distinguish actionable elements from non-actionable elements throughout the grayscale user interface.
Stripping a user interface of anything and everything remnant of real life can create a pretty cold and uninviting experience, void of brand personality. Although not a direct impact on usability, it can and will have an overall effect on the user experience.
Ensure your flat design continues to evoke a positive user experience by inviting the user to relate to your product as if it were just another human. This can be achieved by including plenty of supportive imagery as organic content to offset the flat user interface design. Including imagery – whether it be icons, illustrations, or photography – will also help create the illusion of depth inside an otherwise flat environment.
Mailchimp uses icons, illustrations, and photography to create depth and evoke brand personality.
Squarespace leverages photography as an opportunity to relate to the user.
ohbaby uses blurred imagery in the background to add depth to an otherwise flat environment.
Treehouse uses photography to add depth and personality to their flat design.
As you make the transition to a flat design aesthetic, whether it be for resolution independence or a simple matter of taste, consider the user experience along the way. It’s not as straightforward as stripping your current user interface of dimension, nor should it be. Flat design introduces an entirely new set of usability concerns that can be dealt with by refining the information architecture, emphasizing actionable elements, and humanizing your flat design.
The post How to Go Flat without Sacrificing Usability appeared first on Treehouse Blog.
]]>Variables are coming to CSS. They already have implementations, so there is no stopping it now. Firefox has them in version 29 and Chrome has them unprefixed in 29+ if you have the "Enable experimental Web Platform features" flag turned on.
To be clear, no amount of arguing on whether this is good or bad is going to change things at this point. But I still think it's interesting, so let's talk about it anyway.
I've been giving a talk recently about abstraction in computing. Looking back at the history of programming, there are several clear points where we stepped up abstraction to a new level. From the "1's and 0's" of machine code, to assembler languages, to compilers, and the abstractions of those giving us languages like C++.
Browsers are comprised of parts, like a rendering engine and a JavaScript engine. Those parts are written in C++. So when we write things like HTML, CSS, and JavaScript, we're yet another step up the abstraction ladder. HTML, CSS, and JavaScript don't replace the languages below them, they sit on top of them. They depend on the layers below to do the things they do best. HTML, CSS, and JavaScript are languages we invented in order to build the kind of things we wanted to build on the web: interactive documents.
As time goes on, we want/expect/need the web platform to do more. Capabilities are only ever added to browsers, never removed. We gobble up those new capabilities and use them to their limits. That makes building for the web more complex. We don't like complexity. It makes work harder and less efficient.
This has been going on long enough that we're taking that next step up the abstraction ladder. Abstraction is the natural combatant to complexity, so we employ abstraction to lower the complexity of the code we write.
The abstraction we most needed on the web was for HTML. It would be ridiculous to work on a website where every page was stored as a complete HTML document, from <!DOCTYPE html> to </html> that you edited directly. No one works that way anymore. Complete HTML documents are pieced together through templates and chunks of content.
Abstraction in JavaScript is inherent. The tools of abstraction are already there. Variables, loops, functions, etc.
The last web language to get the abstraction treatment is CSS, and that has come in the form of preprocessors. CSS is enormously repetitive and offers almost no abstraction tools. Preprocessors offer those things that we need so desperately and save the day.
Another thing at work here is the popularity of the web platform. It is the most successful platform ever in computers. More people build for it and use the things built from it than any other. In other words, HTML, CSS, and JavaScript are pretty damn successful. Largely due to the work of the efforts of web standards advocates, but that's a story for another day.
Why is a language like CSS so damn successful? Because it is so easy. Selectors and key/value pairs. That's it. Yes, there are lots of little gotchas as nuances. Yes, it takes a long time to really master. But the root language is very simple. In ten seconds you can show someone a block of code and explain how it works in such a way they completly get it.
h1 {
color: red;
}I'm convinced CSS is as successful as it is because of how easy the syntax is to understand, learn, and teach. There is plenty to bitch about in CSS, but I think correct language choices were made early on.
As languages do, CSS has evolved over time. Like everything in the web platform, it added new capabilities. Jeremey Keith pointed out that @keyframes represent a significant shift in CSS. For the first time, you could write CSS that had no meaning and wouldn't work at all if not for another block of CSS elsewhere in the code.
/* This means nothing... */
.animate {
animation: my-animation 0.2s;
}
/* ...if not for this, which could be anywhere or nowhere */
@keyframes my-animation {
to { color: red; }
}As Jeremy says:
So CSS variables (or custom properties) aren't the first crack in the wall of the design principles behind CSS. To mix my metaphors, the slippery slope began with @keyframes (and maybe @font-face too).
A given chunk of CSS is no longer guaranteed to have meaning.
CSS (the core language) is heading down the path of being fully programmatic. If variables are useful, surely loops are as well, right? We can start to imagine a version of CSS that has so many powerful programming capabilities that it no longer feels like that simple, easy, understandable language it came from. That simplicity that made it successful to begin with.
I'm absolutely not anti-variables or anti-any-programming-concept. I love these things. They empower me as an author, making my job easier and enabling me to do more. That's what all (good) abstraction layers do. So why not leave these concepts in the abstraction layer rather than alter the core principles of the language?
Again as Jeremy says:
Thanks to preprocessors like Sass, we can have our cake and eat it too.
In the spirit of back-and-forth blogging, allow me to respond to Jeremy again.
...not all abstractions are good abstractions.
He goes on to compare Sass and Haml, declaring Sass good and Haml bad. I'm largely in agreement there. I've worked with Haml a little and have never extracted much value from it, while I extract loads of value every day from Sass. I have two points to make here.
Chris made the case for abstractions being inherently A Good Thing.
The context here needs to be "over time". When these points in history come along where we step up the abstraction ladder, there are always languages that compete for that place in history. Developers duke it out (as we're seeing now with the CSS preprocessor market) and as the years go by a "winner" emerges with the vast majority of "market share" if such a term applies here.
The winners are A Good Thing as they have proven themselves. The losers were (probably) the less-good abstractions.
My second point is that I believe there is a such thing as a primary abstraction and secondary abstractions. Perhaps those aren't excellent terms, but what I mean is that there is an abstraction that provides the most important and valuable things authors need (the primary abstraction) then there are abstractions that provide little niceties (secondary abstractions).
As mentioned above, the primary abstraction of HTML is templates and content stored in data-stores. Haml is a secondary abstraction providing a more comfortable syntax for developers of certain flavors. CoffeeScript is also a secondary abstraction to JavaScript's inherent tools of abstraction.
Sass (or whatever the winner turns out to be over time) is the primary abstraction for CSS.
About Variables in CSS and Abstractions in Web Languages is a post from CSS-Tricks
]]>|
|
|
|
|
|
|
|