Idiotic Client Feedback

The Reality Behind the Responsive Web Design

've had a hard time believing many people across the globe still believe that fluid grid system and media queries will somehow magically revive your website into the largest hit within a span of few months. Such hopes on a misunderstood concept is sad, and it also makes me angry over all those evangelist of responsive web designs who have sung their hearts out in the praise of responsive web designs without giving away the finer details that matter.

Why am I so annoying today is because I'm tired of writing all the safeguards and advices about those finer details you missed and how they come back to stab you from behind. Hmph(taking a deep breath). Sorry, if I got a bit carried away, happens to you if your sitting 9 hours a day in front of your PC thinking about how to warn others of the supposed foolhardy they are so keen on doing.

Without much ado, responsive web design and mobile ready website means the same if, and only if, a professional and competent web designer is saying so. Otherwise it is a simple case of getting your website to be made to fit in a mobile. Okay, I'm not saying someone is trying to rob you or something, its possible the concerned person or agency in question is himself uncertain about the nuances of responsive web design.

I have to admit the real perspective of RWD can be quite elusive, hence the common misunderstanding. So i'm gonna break it down to you in few simple points so you read them carefully and get an idea of what am I trying to say and why it is important :-

• Responsive Web Design came into being to support the idea behind making a unified website for all the devices.
• Flexible images in fluid grid system and media queries definitely constitute a major part of RWD and initially it was all there was to it.
• So what you think it means is what it meant at the start but as the concept developed a whole new identity emerged.
• Accommodating your website into mobile is one aspect but representing it in mobile is another.
• The representation includes content, its placement – what and where, and embedding performance into your website.
• Studies have shown people will stay on a webpage if it loads within a second or two in the mobile.
• This combination gives you an actual responsive design and to state it correctly a mobile smart website.
• The idea is to engage the user to the last minute and communicate with him in a crisp yet effective manner.

I'm hoping whatever I wrote was of some value to you and would help you in deciding the future of your website and your business.

Could LinkedIn spell the demise of the CV?

LinkedIn is a recruitment consultant’s dream tool. With millions of candidates at their fingertips, a powerful search function, and other strong networking functionalities, headhunting is now at its most efficient. Posing as a platform to talk about your professional activities, your LinkedIn profile is a CV and more. In this blog, we’ll have a look at the benefits of LinkedIn, raising the question whether traditional CVs are necessary in the modern job market.

Better Exposure

In the past, if you needed work, it was customary to send your CV via snail mail to your target employers, and then keep your fingers crossed for a reply. The trouble with this very dated approach is that you limit the sets of eyes that see your CV. Hosting a CV online gives you better exposure to more employers – people who are more likely to share the link to your profile than resend a CV onto someone that may be interesting in employing you.

Easier to Update

Making even the smallest edits to your printed CV can lead to huge alterations to its layout. LinkedIn have devised an extremely easier interface in which you are able to use to update your profile with a few clicks, instead of tiresomely re-drafting and re-printing your CV.

CV and Cover Letter all in one

With LinkedIn you have the ability to write a 2000 word description about yourself, which, if written correctly and concisely, is more than enough space to write a cover letter style description of yourself.

Recruiters come to you

Thousands of recruitment consultants use LinkedIn every day to headhunt for positions that they have been given the responsibility to fill. In a dramatic role reversal, you could have recruiters and employers coming to you, instead of you approaching them about work.

Of course, there are downsides to using LinkedIn. Sending a CV to an employer via snail mail is a great way to show your own competence in writing and communicating. Using LinkedIn as your CV also loses the personal touch – being able to tailor each CV to suit each employer that you would intend to contact – optimising your chances of being employed.

Ultimately, at Explore we recommend a healthy mixture of keeping your LinkedIn profile up-to-date, as well as regularly maintaining a CV in a word doc which is ready to print as required.

How Much Has The Web Really Changed?

Responsive design is about more than just layout; it’s about designing for the Web, which means, mostly, for people with browsers. And that’s just about everything we know about the people who visit our websites: they are probably using a browser. All the rest we just don’t know.
Up until not so long ago, we used to base our designs on some rather general assumptions about screen size and input type. With the rise of devices with various screen sizes and alternative ways to interact, these assumptions have turned out to be unreliable. We need to upgrade the defaults that we use when we start designing our websites.

A Closer Look

People keep saying that the Web has changed. But has it really? Let’s take a look at all of the things that have actually changed.

Screen Sizes

In the 1990s, the Web was 640 pixels wide. In the early 2000s, it grew to 800 pixels. A few years later, we decided it should be 1024 pixels. But five years ago, all of a sudden, something strange happened. A device with a very small screen entered the market. Suddenly, our ideas about the size of the Web did not work anymore. Later on, tablets entered the market. People hold these things however they want. Today, the height of the viewport could be bigger than the width! But is that new? Not really.

Screen sizes, shown in a non-flexible medium. (Photo and work: Aram Bartholl)
We never really knew what size the window of our visitors would be. We just assumed it was at least the random pixel width that we felt comfortable with. These numbers were always arbitrary, and there were always people who could not see the entire website. We simply ignored them.

“Everyone Has a Mouse”

We’ve always assumed that everyone uses a mouse. Even though we knew that this was not always true, most designs completely ignored alternative ways of interacting. People who had to use a keyboard, for whatever reason, had a very hard time interacting with our websites.
But because most people did use a mouse, and because back then many designers thought that designing only for the majority was OK, we created websites that were unusable for a lot of people. And this turned out to be a growing number. Many mouseover interactions are completely dysfunctional on a touch device. Because people love these devices, and even managers and designers use them, they are harder to ignore.

“Everyone Has Broadband Internet”

Another thing we always assumed was that everyone had a super-fast Internet connection, at least as fast as our own. And if they didn’t already have it, they’d have it soon. This was again mostly true; speeds were increasing. But today, more and more people use crappy, unreliable 3G connections all the time. If you’ve ever travelled on a train in The Netherlands, you know what I mean. And if you’ve ever had to rely on the mythical “free hotel Wi-Fi,” then you know for sure that the assumption about the ever-increasing speed of our Internet connections is just not true. This is a big change in our thinking; we really should consider these users. This will have a major impact on what our designs look like.

“Everyone’s Computer Gets Faster Every Year”

It used to be true that computers would get faster and faster. If you waited half a year before buying a computer, you would get one that was twice as fast, for the same price. This was true of new desktop computers, but mobile devices have priorities other than processor speed. The most important thing for a phone, for instance, is battery life: you really don’t want to have to charge it after every phone call.
And there’s another trend: instead of creating ever-faster devices, many manufacturers are starting to sell ever-cheaper devices. Many people care about price and battery life more than about processor speed. This is also not new: what happened to your old computers? You probably sold them or gave them away. People keep using old stuff. Not everyone has the same hardware as we designers do.

“All Monitors Are Calibrated”

Well, we always knew this to be untrue, right? Only the monitors of visual professionals are calibrated. Most other monitors don’t display colors accurately, and many monitors are downright crappy. Most mobile phones that I’ve tested have pretty decent screens, until you start using them outside, in the sunshine. If you’re lucky, you can read the content, but you definitely cannot see the subtle gradients in low-contrast designs.
I haven’t even mentioned “modern” black and white screens. These, too, are not new. People have always used crappy monitors, and people with bad eyesight have always visited your websites. It’s just that more and more people are seeing a subpar color palette. Instead of buying a state of the art monitor, buying a cheap monitor and several low-end devices to test your work on might be a better investment.
All of these things are not new. In 2002, John Allsopp wrote the monumental article “A Dao of Web Design.” People such as Jeremy Keith and Roger Johansson have written about all of these facts for years and years. And yet, somehow, we’ve always managed to actively ignore them. But we really can’t anymore. The Web actually did change in the last five years, with new devices, new browsers and many, many cool new features. We need new defaults. The old ways of creating websites just don’t work anymore.

This Is Responsive, the excellent resource about responsive design by Brad Frost.
In the past few years, we’ve been actively researching new ways to deal with all of these different screen sizes. But apart from responsive design, there are many more challenges in today’s ever-growing pile of devices. We have to find new patterns of interaction: we need interfaces that work on any device. Maybe we have to reconsider that enormous photo carousel on the home page, now that we know that not everyone has a cheap and fast connection. New defaults are emerging, and I’ve collected a few for you here.
The things in this article are not new. Many clever people have written about them in many articles and many books. But these ideas, like all good stories, have to be repeated many times so that people understand and remember them.

New Default: Activate

I initially titled this section “New Default: Touch.” But I came to realize that “touch” has a different meaning for everyone. Some people, like me, think of a single tap when we hear the word. Others think about swiping and complex gestures. That’s why I settled on the heading “New Defaults: Activate.” All devices, no matter what kind of input they offer, let the user activate something in some way.
With a mouse, it’s a click; with a touch device, it’s a tap; on a keyboard, it’s the “Enter” key. There are ways to activate things by voice, and by waving your arms in the air. And many devices offer more than one way to interact. The only thing that all of these devices have in common is the action of activating. Most of them are capable of doing many other things, too, but all of them can activate stuff.
Only recently have we really started thinking about alternative methods of user input. We used to assume that everyone uses a mouse. Hiding content and showing it on mouseover was considered to be a decent design pattern. And it used to work for most people — until all of these wonderful touch devices entered the market. What should a device without a mouse do when content can be revealed only with a mouse? Different devices have different solutions. Let’s look at a simple drop-down menu.

See a live example of this navigation pattern.
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 solutions 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.
For instance, if you are certain that someone is using a mouse, you could enable some mouseover interactions. Or if you’re sure that someone has fat fingers, you could make small buttons a bit bigger. But only do so in addition to the default activate interaction, and only if there’s no doubt about it, and only if the enhancement would really make things better. Those are quite a few ifs, and some of them, such as the mouse usage, are very hard to detect — especially on devices that offer more than one way to interact, such as a laptop with an optional mouse, touch pad, camera, microphone, keyboard and touchscreen. Give it some serious thought. Do you really need to optimize for a mouse?

New Default: Small Screens

Growing is easy. Most things grow. Babies grow, trees grow, curious minds grow. They don’t grow by themselves, but you don’t need much energy to make things bigger. This is just what things do when they live. While shrinking things is definitely possible, it’s also much harder. You could, for instance, compress a car to a fraction of its original size. A compressed car does have a certain aesthetic appeal to it, but it is definitely not as useful as it was before. The same goes for websites. Shrinking a desktop website does not always result in a pleasant experience on a small screen.

Cedro di Versailles by Italian artist Giuseppe Penone clearly shows that things grow. On the other hand, the work Papalote Goliad by American artist John Chamberlain shows that shrinking can be aesthetically appealing but may result in less useful results.
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.
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. Because this is about the only thing we know for certain — since color is absent on most Kindles, most of the latest CSS doesn’t work on old browsers, and layout is of minor importance on small screens — starting with the text is logical.
I wrote an in-depth article about defining breakpoints on the basis of typography, so I won’t repeat every detail here. But the basic idea is that you start by designing the relationship between the different font sizes. Almost everyone, no matter what device they have, will be able to see this. 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.
I’ve presented this as a very strict way of working; in real life, of course, things are not as rigid. I’m not talking about “activate only” or “small screen only.” 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.

New Default: Content

The way we designed our websites until recently was by putting a header with the logo and navigation at the top, putting the subnavigation on the left, putting some widgets on the right, and putting the footer at the bottom. When all of that was done, we’d cram the content into the little space that was left in the middle. 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. It was as if we were not so confident in our own content and tried our best to come up with something else that our guests might like.
But 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. Make sure people will understand it and find it useful. Perhaps even delight them with it!
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.

Compare a typical news website’s attention to widgets with Medium’s complete focus on content.
By starting with the content first, you can come up with some very interesting solutions. For instance, does the logo really need to be at the top of every page? It could very well go in the footer on many websites; such as in digital style guides or on pages for registered users. Many links that we used to put in the subnavigation might work better in relevant spots in the main content.
For instance, 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. And when looking at the hierarchy of a 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. A simple “skip” link at the top of the page could either take the visitor to the navigation or fetch the navigation and show it at the top of the page.
In this era of responsive Web design, we need many new clever solutions. As we’ve seen here, our old defaults don’t work anymore. We need to reconsider how we work with interaction, how we approach design and how we shape our content. But we need to think about one other very important thing, and that is where our content comes from.

New Default: The API

Luke Wroblewski wrote a fantastic article about designing an application for the command line first, and then enhancing it for different needs. This is not just a nerdy idea, but a very practical idea, too. If you are able to design and develop your own application, you could test the functionality relatively easily before even starting to think about what it will look like on different devices. This requires designers to work with developers to design a feature that at first works only from the command line. If the feature does not work as expected, then you merely have to change the API, rather than also a bunch of visual designs. Once the API works as you want it to, enhancing it for all of the devices and screen sizes that you want to support becomes easier.
Most of the time, you wouldn’t design the entire API of the application that you’re building. Most companies would choose a content management system (CMS) of sorts or a specialized tool to help them achieve what they want to do. I’ve always been amazed that CMSes are so often chosen only by technical people and business people. This causes many problems during the design process.
Developers and business people have different goals than designers. Developers want stuff that is easy to develop on. Business people want stuff that’s cheap. But designers want to make the best and most beautiful things possible. These goals can easily conflict.
I’m not saying that designers alone should choose the system, but they should definitely be a part of the decision-making process. I’m convinced that the selection of CMSes will improve. And I’m convinced that CMS makers will start to improve their products once designers get involved. Right now, all CMSes I know of deliver hostile cruft unless you tweak them extensively.
But it works the other way around, too. If designers are involved in the selection process, they will have a say in the choice of tool and will understand how it works, what’s possible, what’s easy and what’s hard. This will result in designs that are based in part on the tool, not just on imagination. This is an important part of the design process that has not yet been optimized. Right now, the command line and the systems that deliver the content we design for are the domain of the developers, and designers have nothing to do with them. That is a pity. Just as you would want to take advantage of the knowledge of developers in the design process, you would want to take advantage of the knowledge of designers in the development process.

Progressive Enhancement

If you review the sections above, you’ll see that what I’ve described is nothing other than progressive enhancement. You start with the content, then design the content and optimize it for different screen sizes and devices, and after that you can further optimize for very specific features such as mouse usage and fat fingers. Many Web developers build websites according to this principle. They transform the beautiful Photoshop documents that they receive into all of the different layers described above.
This can work out fine if the developer has a good sense of design and a delicate attention to detail. But if they don’t — which is often the case — this can easily result in crappy usability and ugly details. I’m not saying that designers shouldn’t use Photoshop anymore. If that’s your tool, go ahead and use it. But do remember that you’re designing the layers of the Web, not the layers in Photoshop. There’s much more to the Web than a single beautiful image. People will see our creations in innumerable ways. We design for all of these people — remember that. We don’t just design for the CEO with a laptop. We also design for the people on the train and the people with “free hotel Wi-Fi.”

Tools

I’ve mentioned Photoshop a few times because it’s still widely misused for designing websites. One reason we have a hard time with progressive enhancement in the design process is due to a lack of good Web design tools. The tools we use are built to wow; they mostly help you to create the “paint,” not to design the core. Fortunately, more tools are popping up with very specific functions in the design process. These are micro-tools such as the International Measure Slider, which helps you to define breakpoints in your grid; tools such as Gridset, which helps you to create grids for different screen sizes; and excellent tools that help you to define typography. By incorporating these tools into our design workflow, we might start making better stuff.

Conclusion

The Web has always been a weird, borderless, flexible medium. In the last couple of years, we’ve started to realize that designing for this medium is fundamentally different from the design work we’ve done previously. The fixed dimensions and the singular ways of interacting that formed the basis of all types of media that we’ve worked with for centuries just don’t work on the Web. This truly is a unique medium.
We have to find new defaults, new starting points for our design process. I’ve explained some of these new defaults here, but of course there are many more. The way we work with forms, for instance, could probably use a whole series of articles by itself. Some new starting points are well established by now, but I’m sure many more will be invented in the near future. I am curious to hear about new patterns and new defaults that you have discovered and have used successfully in your projects.

What’s All The Fuss About Vendor Prefixes?

You’ve probably seen talk the last couple of weeks about browser makers moving to adopt the -webkit prefix in their non-WebKit browsers. Mozilla appears to be leading this move and the response from the developer community has been to strongly suggest this as a very bad thing.

The Issue

In a nutshell vendor prefixes exist to allow browsers and developers experiment with css properties like transitions that aren’t quite standardized yet. Each browser uses their own prefix, -webkit, -moz, -o, -ms, etc. and when we want to implement one of these properties we should use all these prefixes along with the non-prefixed version.
Through the above, browsers and standards bodies can see how everything is working and ideally the information helps finalize the spec at which point browsers and developers move to support the non-prefixed version only.
If we as developers have been doing things right we already have that non-prefixed version in our code and nothing breaks.
However all is not perfect.

• Some vendor prefixed properties are not part of the spec.
• Some are proprietary and may never find their way into the standards.
• Some web developers are using these proprietary properties.
• Some browsers feel the need to support these proprietary properties or be seen as less capable.
• Some specs are often painfully slow to become standards.

The danger is that we find ourselves back in a time where sites list warnings like this site works best in browser x. Please update your browser.

What Can We Do?

I won’t pretend to understand every nuance of what’s at stake here. As a developer my main concern is I want to be able to transform an element here or animate something there and I just want to know how to do that and which browsers it will work in.
With that information I can make an informed choice about whether or not to use something and just as importantly where in the stack from “has to work” to “cool feature for those few who’ll be able to see it,” it should be added.
As developers we should do a better job of using vendor prefixed properties. We shouldn’t rely on them to the point of our sites breaking without them. We should lean toward not using proprietary features, except at the top of the progressively enhanced stack. And we should be better about using all vendor prefixes instead of just one or two.
Those of us who write about things like multi-columns and flexbox should be clearer about what is part of the working spec and what’s proprietary and not evangelize the proprietary as ready for use.
Vendors could dial back a bit on the proprietary stuff and drop support for prefixes once they are no longer needed. The W3C for it’s part could speed up its own process moving specs to the recommended stage.
We could all do something to help the situation.

Additional Resources

Again I won’t pretend to understand every nuance in this issue and it’s possible I’ve mischaracterized a few things above. I’m still trying to sort some of this out, but think it’s important enough to want to present the issue sooner rather than later.
Here then are some of the articles I’ve collected these past couple of weeks. They aren’t in any specific order other than the order they found me. A search for vendor prefixes will lead to plenty more.

• Call For Action: The Open Web Needs You *Now*
• Vendor Prefixes – about to go south
• This Must Not Happen!
• Unfixed
• TL;DR on Vendor Prefix Drama
• CSS vendor prefixes threaten open web
• Best Practice for Programming with Vendor Prefixes
• Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies
• The Vendor Prefix Predicament: ALA’s Eric Meyer Interviews Tantek Çelik
• SitePoint Podcast #150: The Vendor Prefix Kerfuffle
• Pre-fix the web!
• 7 Solutions to the CSS3 Vendor Prefix Crisis
• The vendor prefix mess

Have you thought about this? How are you currently using vendor prefixed css? Any ideas for a workable solution?

BEM: The Block, Element, Modifier Approach To Decoupling HTML And CSS

For the last couple of months I’ve been thinking a lot about giving our css best practices a refresh and along the way have looked at approaches such as OOCSS, SMACSS, and DRY CSS. They all have some common underlying principles, one of which is the separation of structure and presentation.

We’ve all had this goal for years, but our practices haven’t really achieved it. Instead of decoupling our html and css we’ve been locking them ever tighter and making them more and more dependent on each other. I apologize if you’re getting tired of hearing me talk about coupling, but I think it’s a very important concept to understand if you want to develop scalable and maintainable websites.
 I want to touch on a few of the points and then give a quick walk through of yet another method (BEM) with similar goals to the ones we’ve been talking about.

Decoupling HTML and CSS

Ideally we’d like to be able to completely rewrite our html or css without touching the other. That’s unlikely to happen all the time. There will often be a need to changes one after changing the other. However the less dependent our html and css are on each other, the better. Using OOCSS we reduce coupling by dropping descendent selectors in favor of classes. With a DRY CSS approach we’re also using classes, but here the magic is based more on how we organize our css around stylistic groups. SMACSS falls somewhere in between these approaches.
All agree we should move away from location based selectors as tying css selectors to a specific html structure leads to greater difficulty in changing either html or css. Inevitably we’re left managing specificity.
Jonathan Snook refers to this as the depth of applicability or in his words, “the depth at which a particular rule set impacts the elements around it.”
For example consider the following code for a relatively simple navigation bar with a single drop down.

1 2 3 4 5 6 7 8 9 10

<ul id="nav"> <li><a href="">Item 1</a></li> <li><a href="">Item 2</a> <ul> <li><a href="">Sub Item 1</a></li> <li><a href="">Sub Item 2</a></li> </ul> </li> <li><a href="">Item 3</a></li> </ul>

If we were to write some css targeting the link in the drop down ( #nav li a ), the depth of applicability is 5. Even though we didn’t specifically mention every element along the way we’ve moved through ul#nav to li to ul to li to a, or 5 levels of html structure.
That’s too much and it also affects both the top level links and secondary links in the drop down. Jonathan offers two ways to reduce the depth of applicability

• Child selectors — using #nav > li > a limits the scope to the top level links
• Class selectors — is ultimately the better approach as it’s not dependent on html structure at all

Jonathan offers some additional explanation and examples in the Smashing Magazine article, which is worth a read if you’ve yet to see it.
The key is in seeing that many of the selectors we’ve been using over the years are coupling our html and css ever tighter. The debate is still ongoing as to the best way to decouple things, though hopefully you agree there’s a need for decoupling.

BEM — Block, Element, Modifier

The BEM approach to developing websites comes from the developers at Yandex. It has similar goals to the approaches we’ve seen before.

• Quick development
• Team efficiency
• Scalability
• Code reuse

Blocks and Elements

Under BEM a block is it’s own independent entity. Blocks can be simple or complex and they can contain other blocks. There’s something familiar in this as every html element is displayed as a box or block of some kind.
At the highest level of a design, your blocks might be your header block, footer block, main content block, and sidebar block. Your header would likely include several blocks inside such as one for your logo and tagline, another for a navigation bar, and maybe another making up a search field and button.
Elements are parts of blocks. They perform certain functions within the block and they’re context dependent. Take an element outside its block and it no longer makes sense. For example a search block might be made up of 2 elements.

• Input field
• Button

Removing one doesn’t make sense as the block would no longer function correctly.
Together blocks and elements are arranged in your design to form your page layout. Elements are arranged inside blocks and blocks are arranged inside other blocks working up to the outermost container blocks that shape the page as a whole.
Blocks and elements should have keywords (names) associated with them. The only way the same name or keyword is reused is when the same block or element is being reused. Blocks must be independent of each other to allow for arbitrary placement within the design. We want to be able to take our search block and easily move it from the top right in the header to the middle of the sidebar for example.
This leads to 3 guidelines for writing css:

• Blocks should have unique names, which become classes
• HTML elements should not be used in css selectors since they aren’t context-free
• Cascading selectors for several blocks should be avoided

Here again it’s the use of classes that aims to solve the problem of coupling. We’re also encouraged to avoid location based selectors (context dependent) to help decouple our code.

Modifiers

What happens when you have a block like a search input and button and you want to add another to the page that looks similar, though not exactly like the first? This is where modifiers come in. Modifiers help us create similar though different blocks from already existing blocks.

A modifier is a property of a block or an element that alters its look or behavior. A modifier has a name and a value. Several modifiers can be used at once.

Typically a modifier will be an additional css class you would add to an element. An example I’m sure you’ve come across is highlighting the currently selected menu item so it stands out from the rest of the menu items. To achieve this you probably created css similar to the following.

1 2 3

.current { background: #f00; }

You’d then added class=”current” to the currently selected menu item. The class modifies one element inside your navigation block.
BEM goes a lot further than what I’ve described above. In fact it’s for more than just html and css. It covers behaviors with Javascript, though the same basic principles and approach apply. I’ll let you read the original source if you’d like more details. I mainly wanted to show you the basic approach.
The idea of seeing a web page as elements within blocks within blocks is an easy one to grasp and probably how many of us already view the pages we develop. I certainly have, as you can see in a couple of posts I wrote for Onextrapixel a couple years back.

• Part 1: How to Turn a Design Image Into a Working Web Page
• Part 2: How to Turn a Design Image Into a Working Web Page

Summary

Again I hope I’m not repeating myself too much in all these posts, but these concepts are important ones to understand. Ultimately I think we should be rethinking some of our css practices as they haven’t been as great as we’d like to believe. Many have been thinking the same thing and over the last few years we’ve seen quite a few new methods and approaches for writing html, css, and javascript.
Most of these methods are similar in their underlying goals and principles, which is the main thing to be paying attention to. You’ll likely pick and choose techniques across some of these approaches depending upon the specific problem in front of you as opposed to following any one entirely.
It’s the underlying principles like decoupling html and css that are more important. It’s the idea of reducing location based selectors, mostly likely through a greater use of classes that you should be thinking about. See how each approach attempts to solve this and decide which makes the most sense for you.
If you’re getting tired of these posts please let me know. I realize I’ve been offering a lot about this same basic concept for awhile and perhaps the message has long since gotten across. If you are enjoying these posts and some of the methods I’ve been pointing to, let me know as well. There are more approaches out there with similar goals in mind that I could cover.

The Four Key Components of a Great Web Design

There’s a lot that goes into creating a web design, but I believe it can be broken down into four main components. If you’re able to execute on all four, you will have a hit web design on your hands. However, if you come up short on one, the entire design will suffer. That’s the challenge. All aspects of a great design must compliment each other while helping achieve the end goals of the website. In this article, I’ve broken down the four key components of a great web design with examples and resources.

1. A Solid Layout

The importance of having a good foundation applies to just about everything in life. If the foundation is wrong, everything that is put on top of it will probably fail. In web design, the foundation is your layout. Laying out a web design involves placing all the content and navigational elements. You want to establish a hierarchy in these elements that gives the most important ones prominence, and this should be determined by how you think your audience will use the site.

Use Wireframes

A common practice by web designers to nail down a layout is to create a wireframe, which is basically a bare-bones representation of the various elements that will appear on the page. Wireframes are typically made up of gray scale boxes and blocks of placeholder text. The key is to keep things simple and not get caught up in color and design elements.
Jesse Bennett-Chamberlain of 31Three is great about posting his design processes on his blog. Here is an example wireframe he created for the Embrace Pet Community project.

Be generous with whitespace

One key aspect of a great layout is more about what’s in between (or rather not in between) your various page elements. I’m talking about whitespace or negative space. Many designers make the mistake of over crowding their web designs. Don’t be afraid to let your pages breathe. Adding larger amounts of whitespace will actually give your design a more sophisticated look.
With so much going on in the layout of The Swish Life, Liam McKay realized how important it was to use wide margins around the content to give this design an open and airy feel while making it easy to skim over all of the text. Notice how much empty space is around the blocks of content. This makes it easier for the user to focus in on what’s important.


Mutant Labs is another great example of good use of whitespace. It gives this dark design an open feel and lets the subtle chalk board texture and doodles room to show through.

Learn more about layout and wireframes

Wireframes Magazine is a blog written by information architects and interaction designers that has lots of info and examples of layouts and wireframing.

2. Effective Typography

Just like layout, typography plays an important role in how a user digests the content of a website. It’s important for a web design’s typography to be easy to read and follow while establishing structure and hierarchy within the content.

Big = important

31Three uses all caps and a large font size for the titles and subtitles. This establishes a clear hierarchy that distinguishes the headings as having more importance than the paragraph below.

Make it legible

By using high contrast between the text and the background, Dan Cederholm made the text on Simple Bits very easy to read. Also notice the amount of line spacing used in the paragraphs. Always make sure to use enough to make a body of text easy to read. This normally requires some experimentation, but a good rule of thumb is to set the line height to 1.5em, which is 1.5 times greater than the font size.

Learn more about typography

If you want to learn more about typography, we’ve compiled a list of great sites about the subject, and we’ve also go a list of tools to help you with typography on the web.

3. The Right Color Scheme

Choosing the right color scheme is extremely important, because it will set the mood of your design more so than any other component. Don’t let your own personal taste determine what colors you use. That should be based on what’s trying to be achieved with the site and what you know about it’s audience.

Dare to be different

The Gap Medics site features a bold choice of colors that goes against everything we are used to seeing on medical related sites. It’s appropriate since the site is trying to attract young medical students. The colors help give the site a young hip feel that softens seriousness of the subject matter.

Sometimes little color is the right color

Carsonified basically only uses two colors. The dark brown and a creamy white compliment the vintage poster style and design elements. Sometimes a minimal color palette is all you need.

Need help choosing the right color scheme?

Adobe’s Kuler is a community driven web app that lets your browse color palettes created by others. You can also create your own by using the color wheel, harmony rules, and color sliders. There are also other tools to help you choose the right colors.

4. Appropriate Design Elements

This is where you can have a lot of fun with a design. Your creativity can go wild here with texture, icons, patterns, etc. However, keep in mind that design elements also play a big role in setting the mood of the design. So keep things consistent with the goals of the website and it’s audience. Also keep the design elements consistent with the other three components we’ve already mentioned.

Consistency in action

The designer of Red Velvet Art did an excellent job of utilizing the same hand drawn style throughout the various design elements. Notice how the icons, background pattern and doodles all work together. The consistency also flows through to the typography and retro color scheme.

Attention to detail

The Squarespace blog has a typical blog layout and an overall clean design, but notice the pixel perfect tick marks that line the left and right borders of the content area. It’s such a minimal design element, but it serves it’s purpose in establishing focus on the content while staying consistent with the rest of the design.

Less really is more

This design could have worked well on a white background, but Elliot Jay Stocks loves using texture. To stay consistent with the open feel of the site, he went with a light and subtle grunge texture. It works because it doesn’t take away from the minimalism of the layout and still adds another layer of interest to the design.

20 Do’s and Don’ts of Effective Web Typography

I would like to keep up with that topic and go over 20 do’s and don’ts of effective web typography. It’s an important part of designing for the web, yet it’s often overlooked (even by me previously). Below are the 20 do’s and don’ts and in the comments section, you’re free to let us know of any of the items we might have missed.

DO NOT use too many different font faces on the page

You may have 1,000+ fonts downloaded on your computer, but when they’re being displayed all on the screen at the same time, you’re not going to have many people impressed. Not only will this cause your website visitors to have a hard time reading, it’s also going to just make you look tacky.

DO NOT switch from serif and sans serif fonts multiple times

Sticking with the theme from above, switching from Serif and Sans Serif fonts multiple times per page will do you more harm than good. Readibility is the #1 thing you need to be worried about with your website, because no matter how “cool” it looks, if the visitor can’t read whats on the page easily, they’re going to leave.

DO NOT ignore planning for font increase by the viewer

Older audiences will adjust the font size view on their screens in their internet browsers settings, so no matter what font you default the text at, it might not be showing this way for the visitor. This can cause errors if you aren’t taking larger fonts into account for headers and other various items which might break the design if they break into two lines.

DO NOT use Sans Serif fonts for large bodies of text

Sans Serif fonts are great for the clean, uniform look – but when you’re putting together large bodies of text (10+ lines), switching your fonts to a serif font will allow for better readability as the curves and shapes help guide the eyes better than the straight, uniform lines of the Sans Serif fonts.

DO NOT overuse font replaces like Cufón and siFr

Cufón and SiFR are just two of the various ways you can replace text in your browser to give off a more custom look, but use it wisely. Using the font replacement for the entire web page is going to be a bit overload and will distract the visitor from the actual reason you’re typing on the page in the first place – you want them to be able to read it. I would advise to generally stick with headings and calls to action for your font replacements and leave the major bodies of text as regular, web safe fonts.

DO NOT overdo the emphasis in your text

A good writer will be able to emphasize the words they want without using bold, italics or underlines. If you’re text is littered with tons of strong and italics and underlines, you might want to rethink what you’re doing. Utilizing the codes to emphesize specific items wisely will make things look – and read – thousands of times better.

DO NOT forget to utilize font stacks in your css codes

When I’m building websites, I tend to like using helvetica for the text of specific items. I realized early on that not a lot of people will have purchased helvetica, so the font won’t display properly on their page if I simple use “font: helvetica;” in my css, so I read up on font stacks and use them religiously now. Basically, it gives you the option to use any font you want, and also allows for back ups in case the visitor doesn’t have the specific font you give first. An example would be like this: “font: Helvetica, Arial, sans-serif”, which basically says that you want the page to display helvetica for the text, and if thats not available on the visitors computer, you want the page to use arial – and if for some reason that isn’t available, it gives a generica sans-serif font.

DO NOT type in all caps – use text-transform when you need it

So, lets just say that you want your headings to all be capitalized – how do you do it? DO YOU EXCESSIVELY TYPE IN ALL CAPS? There are a few problems with that. First, it’s annoying. Second, it’s not easy to edit them out later on if you redesign your site and do not want all caps anymore. So what do you do? Utilize the text-transform css code. Here’s an example.

text-transform: uppercase;

DO NOT forget to use accent characters when needed

Typing words like Cufón numerous times on the page without the accent characters will make you look sloppy and uneducated. Yes, it’s true. So utilizing the accent characters will allow you to display the words properly (it’s really polite to do so) and it also is a lot easier than you’d think. You can get a full list of accent characters by visiting this article from w3.org.

DO NOT – I repeat – DO NOT use comic sans or papyrus on anything!

This is actually a rule across all forms of design that use typography – web, print, ect. Never – I repeat – never use comic sans or papyrus on anything. It’s tacky and deserves to be lumped in with IE6 – and we all know how bad people hate IE6, right?

DO use line height to your advantage

Relying on the default line height for your text will bite you in the ass in the long run because it’s honestly just not enough room between lines and will not allow you to work with a proper baseline grid (more on that below). I tend to keep my line height 5-6 px larger than the font size I choose – so if my font size is set to 13px, I will make the line-height 18px.

DO use the proper text colors on the page background

The best thing to do (in my opinion) is to utilize an off-white (#F8F8F8) font on a black background and a dark gray (#252525) font on a white background. It helps the contrast become minimal and doesn’t strain the eyes as much for your visitors when they’re reading your content.

DO use web safe fonts as often as possible

When you’re building your font stacks, make sure you’re using the web safe fonts as much as possible. The fonts that are installed on both PC and MAC can be found by reading this article on ampsoft.net. When you have a knowledge of what web safe fonts are out there, you can better prepare your website for the break down from your original fonts to the fonts that are most common and would be used if the visitor didn’t have your font installed.

DO use a proper hierarchy for your pages

Utilizing a great hierarchy for your web pages will allow your visitors to quickly scan your content and find the most important items. Nothing is worse than getting to a page and having to spend 30-60 seconds looking for the content and finding out what it’s even about. Use proper title tags for the most important sections and smaller title tags for less important sections. You can also use different colors and spacing to vary the hierarchy for your pages.

DO make use of a baseline grid

A consistent vertical grid will help readability for your web page and also increase the visual appeal of the overall design. Proportion and balance shouldn’t be broken by font sizes, so sticking to a proper vertical baseline grid will allow your page to flow naturally from top to bottom as well as from left to right. Acheiving this effect is as simple as these few lines of code below. Notice that the line height for the text is the same size as the margin for the bottom of the paragraph blocks of text (you should also keep this in mind for header tags as well as images).

body {
 font-family: Helvetica, Arial, sans-serif;
 font-size: 13px;
 line-height: 18px;
}

p { margin: 0 0 18px 0; }

DO utilize white space as much as possible

Keeping up with the above do, utilizing white space in your design will help your pages readability. It will allow your page to breathe and give your visitors eyes a rest. Don’t believe me? check out the image below and let me know which item you think is best for readability.

DO keep the use of centered text to a minimum

Centering text is good for one line or maybe a speech bubble in your design, but requiring your visitors to read large blocks of text will cause their eyes to drift and not follow line by line as easily as if the text were aligned to the left or right.

DO use shade variations to help areas stand out more

When designing your next site, keep this in mind – if your body text is black and your sidebar text is a medium gray color, your content will visually stand out and be read faster than the sidebar items. The same goes for blockquotes and other non-essential items that you do not want to take away from the attention of your main content areas.

DO make sure you know about, and use, proper letter spacing for titles

This is an item I didn’t think about very often – until recently. If you are utilizing the text-transform css code I wrote about above, you’re going to notice that the text might be a bit hard to read. Utilizing the letter-spacing property in your css will help curve that problem. There is an example below but please know that the letter spacing is relative to your fonts default letter spacing so it might work differently for various fonts and font sizes.

h1 { text-transform:uppercase; letter-spacing: 1.25em }

DO make use of a typographic scale in your css codes

Using a proper typographic scale will allow your page to be read easily by the visitor and will allow you to keep the hierarchy in tact that we spoke about above because if your main text is 12 pixels, then the blockquote and paragraph fonts will be 125% larger by using the 1.25em code in your css. If you properly use a typographic scale, it will actually look like a flieght of stairs – like the image below.

body { font-size: 12px; }
h1 { font-size: 5.0em; }
h2 { font-size: 4.0em; }
h3 { font-size: 3.0em; }
h4 { font-size: 2.0em; }
blockquote { font-size: 1.5em; }
p { font-size: 1.25em; }
input { font-size: 1.0em; }
small { font-size: 0.75em; }

Anything I missed?

Let me know in the comments. I’m ready to learn from you all and I hope you learned a thing or two from me today as well. Thanks for taking the time to read my article and don’t forget to share it with friends through email and social networks if you enjoyed it.

How & When to Build Website Content using Tables

Back in time over a decade ago, web development was still living through its infancy. Developers would commonly build website layouts constructed with HTML4 tables, and this was standard practice most of the time. When CSS finally grew into popularity precedents began to change. It was now easier for developers to use div elements and position everything with CSS stylesheets.

But even following modern practices of HTML5/CSS3 we can still find a use for tables. The specifications haven’t changed much since HTML4 and with good reasoning. In this article I’d like to share a few techniques and ideas for when you should be using tables in your webpages. We can also look into where tables will be going in the future of content on the Internet.

Historical Origins

Tables were originally the best solution for website layouts because of their flexibility. Developers wanted to support all screen resolutions and tables could handle these additional attributes. These include the width attr which was specified in a percentage value. This means your table rows would adjust naturally based on a percentage of the browser window.
Fluid-width layouts were very popular since design aesthetics have not always been as influential. As CSS became more prevalent it didn’t make sense to style webpages using table attributes anymore. Each row of data had to be split by <tr> tags which would eventually feel bulky and abnormal.

But this formatting has continued to this day with modern HTML5 tables. You can read a bit more about the HTML table element from W3Schools excellent resources page. There is also a list of related tags and optional attributes correlated with formatting tables.

How To Display Tabular Data

By far the most common useage of modern tables is when formatting tabular data. This may seem like a no-brainer but I have run into countless developers who simply loathe tables. It’s like an all-or-nothing relationship where you either use them or you don’t. This is a horrible attitude since you’re fighting against the natural order!
HTML tables are great for data listings, catalogs, image galleries, products, or anything with a similar block-style layout. You’ll be able to create these pages using CSS but it’s going to require a litany of additional properties. So why even go with that route if it requires additional work?
Tables can naturally be split into core sections with a header, body, and footer. This schematic follows any traditional layout where you’ll have some header rows to define the datatypes, followed by a long list of data rows. Adding a footer is completely optional but it can be used for some type of legend or table key index.

Formatted Table Captions

Another newer addition with HTML5 are table captions which hover towards the top of the page. These fields are often inside the table element yet right before you open any new content rows. It’s almost like a header to define the content found inside your table listing.
To scale this out even further you can add a whole descriptive block of text defining your table output. The newer HTML5 tags for details and summary are ultimately optional but very useful. I can think of various corporate environments where you need to describe various bits of data and share it onto a public webpage.

This extra content is beneficial not just for the end user, but also for search engine crawlers. Captions are considered much like table headers and the summary description is a good way to load up related keywords. Again these are completely optional tags, but they can exert a large effort towards keeping your webpage organized.

Dynamic JS Effects

Tables can be even cooler if you pair JavaScript libraries into your layout. It’s possible to allow users functionality such as drag-and-drop, inline editing, and so much more. Think of all the different pricing tables or member lists you’ve ever seen. All those layouts can be created custom from scratch and even optimized using tables.

One of my favorite scripts is named Tablecloth which is a completely dynamic open source solution based on JavaScript. By including a copy of the CSS/JS files you can add hover functionality to any table element in your webpage. As you mouse over table cells you’ll see a highlighted row and column effect matching your current position.
The extensibility of these scripts only adds to the growing collection of open source solutions perfectly formatted to be used by more advanced frontend web developers.

How to Determine Proper Situations?

It can be difficult figuring out which situations require a table in your layout. I very rarely use them except for content which is often formatted into rows. One reason this works well is because you don’t need to adjust floating divs and create “artificial” rows in your markup.
Tabular data can be found in almost every website so it’s not cheating to use divs or other markup instead. Tables are beneficial to developers who understand why they’re using that markup and how you can format rows & columns together. Tabular layouts are perfect for galleries with smaller thumbnails linking to full images, videos, whatever.

I would argue the largest reason to not use tables is when formatting your overall website layout. The newer HTML5 header, footer, nav, and section elements fit the roles much better. But understand there is no “wrong” area to use tables in your content. It ultimately boils down to personal preferences and what you feel comfortable designing into your markup.

Conclusion

Tables are still just as relevant in web design today as they have ever been over the years. Developers have evolved and found better tools for creating entire website layouts. But this has also guided new semantics which follow content as the primary motivator in web development.
I hope this article can provide some deeper insight for newer web developers. It’s true that almost nobody suggests building an entire website with tables anymore. But it’s also true that nobody is ruling out tables as a deprecated element. There is a purpose for every bit of website markup and following these standards will get you more experience as a skilled web developer.