Lately we have been utilizing a drawer style navigation in our designs to provide a better user experience in our websites. The request for quite a bit of content in the drop downs themselves (mega drop downs that span the full width of the site no matter which tab you have clicked) in some of our more complex higher-ed sites also creates the problem of covering up the content of the site and proving tricky when the site responds to mobile screen sizes. Putting the navigation in a sliding drawer is proving to be a unique solution that translates beautifully to mobile in responsive design.

If you look on Mashable, a popular news article site, the nav drawer does not shift the page down, but is a full width mega drop down menu. Compare to the University of Wyoming, a site recently developed by Beacon, which has a drawer based nav.

Whether or not this is the right nav for your site will probably be based upon a lot of factors like what type of content is in your drop downs and what type on content is on your homepage. If you have a lot of content in your navigation it may be worth while to put that navigation in a slider so that the homepage remains visible, even when the navigation is open. Also, you need to think about what your navigation does on mobile devices and tablets and how to best integrate this with your drop downs. Mashable.com serves up a different navigation for it’s tablet users, for example, simplifying the menu, so they put it in a side drawer. On the higher ed sites we develop here at Beacon, we need to provide a consistent navigation for users on every type of device, so we might use a similar drawer on both mobile and desktop, but just change the navigation to stack taller on smaller devices and open and close subsections. This also can allow us to integrate deeper navigational tiers in the main nav on mobile devices so we can keep the content area cleaner and simpler.

This solution can be elegant and it even translates very well to touch devices that do not have the ability to open menus on-hover. This keeps the experience more consistent through all the screen sizes by utilizing an on-click drawer.

Ultimately decisions like these need to be made on a case by case basis.

Many sites implement accordions for everything from menus and navigation to product features to calendar event details. The fact is that accordion lists are among the most popular implementations of javascript and can be seen in some implementation on almost every web application and most advanced web sites. With the recent explosion of mobile devices accessing the web there has been a lot more value placed on responsive design. One facet of that has been developing sites without relying on javascript which has been the most common way of generating rich media experiences for users. Some things simply can’t be done without javascript, but other things can be accomplished with a bit of innovation. Accordion lists are just one of many things commonly done in javascript that can be done even in browsers either with scripts disabled or not supported at all.

A typical html snippet for a list might look like this:

<ul id="accordion">
    <li>
        <h3>Section 1</h3>
        <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>
    </li>
    <li>
        <h3>Section 2</h3>
        <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>
    </li>
    <li>
        <h3>Section 3</h3>
        <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>
    </li>
    <li>
        <h3>Section 4</h3>
        <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>
    </li>
</ul>

A script would then operate on the items in order to provide them the desired behavior to expand and contract on click or hover. With a few simple modifications that same behavior can be accomplished without needing to rely on scripts being enabled on your customers browser (changes in red):

<ul id="accordion">
    <li>
        <label for="section-1-checkbox">Section 1</label>
        <input id="section-1-checkbox" type="radio" name="accordion-level-1" />
        <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>
    </li>
    <li>
        <label for="section-2-checkbox">Section 2</label>
        <input id="section-2-checkbox" type="radio" name="accordion-level-1" />
        <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>
    </li>
    <li>
        <label for="section-3-checkbox">Section 3</label>
        <input id="section-3-checkbox" type="radio" name="accordion-level-1" />
        <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>
    </li>
    <li>
        <label for="section-4-checkbox">Section 4</label>
        <input id="section-4-checkbox" type="radio" name="accordion-level-1" />
        <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</div>
    </li>
</ul>


<style type="text/css">
    #accordion input[name=accordion-level-1]:not(:checked) + div { display: none; }
    #accordion input[name=accordion-level-1]:checked + div { display: block; }
    #accordion input[name=accordion-level-1] { width: 0px; height: 0px; margin: 0px; opacity: 0.0; }
    #accordion label { cursor: pointer; }
</style> 

We’ve changed the h3 tags to labels and added for attributes pointing at the radio inputs that have been added next to the content that we want to toggle between displayed and hidden. The first two rules dictate which content is displayed based on the state of the radio button that precedes each content section. The third rule hides the actual input since it’s unlikely you want random input tags cramping your style (pun intended). The fourth rule simply provides feedback to your users on hover that the element is clickable. If you want to enable the expansion on hover the second rule can be changed to “#accordion li:hover div { display: block !important; }” and take special note of the !important attribute on that style. This is because the nature of styles will dictate that the first rule overwrite the second due to its specificity.

Obviously one of the drawbacks of this method is the lack of animation since animation was only possible with javascript prior to html5. The good news is that once this html/style accordion has been implemented you can also add scripts to you page to implement the accordion using script for those users that do have script enabled and render the styles we added for the scriptless version inert by simply removing the radio inputs from the DOM. Now your accordion can expand and contract both with and without script, though admittedly it will probably look better when scripts are enabled.

As the push towards mobile oriented design and responsive code takes off and gains momentum, the phrase “mobile first” has become a concept that we here at Beacon are quite familiar with. But what exactly this term means is a little fuzzy and, I think, even open to some interpretation.

The theory is, to create the best design possible you start by designing the experience for the mobile user before designing for the desktop. This is the exact opposite of how it’s always been done, if mobile was even approached at all. This will ensure that the mobile user has the best experience possible and that things aren’t built into the desktop design that don’t translate well to mobile and in turn, short change the user. While this works and is true, I believe that mobile & desktop simultaneously is the best approach. In art school, we were taught that in order to create a painting that had a high level of harmony and organization, it was best to work the entire canvas all at once. I like to think of designing websites in this same way. Instead of nailing mobile down and then migrating to desktop – I rather think of designing first the content architecture for all platforms and then building the graphical framework around this content that works at all resolutions. Also it is best if the visual design is designed specifically for the content. Content first and all resolutions simultaneously, even.

The truth is that mobile will not replace desktop. Not in the way that people might envision that it will. Mobile is definitely where we see the most growth in web traffic but many of the people that are using tablets and mobile devices are also using desktops, especially during their 8-10 hour work windows. Mobile devices are just allowing us to access the internet during a larger portion of our day and is satisfying more of our information needs.

Responsive design, like the devices it services, is about flexibility and accessibility, not one device over another. Therefore the experience needs to be designed holistically, providing all the information and content the user desires over all the platforms they use throughout the day.

Client side form validation is often undervalued despite the benefits it can have both on speed and user experience. The reason it is so undervalued is because it alone isn’t enough to rely on. Any client side validation can be removed, altered, or bypassed by a sufficiently informed individual with intentions of attempting to bypass your security measures so many developers will choose to rely solely on server-side validation which is much more secure from malicious attempts by the user. Since server-side validation is required many developers will solely look to that to alert the user to mistakes in the form be they missing fields or even invalid entries.

One solution in Asp.NET is to use the built in validation controls that validate fields both client and server-side (to avoid client spoofing), but what can we do when we either aren’t in an Asp.NET environment or the built in validation controls can’t process the necessary logic to properly validate inputs?

In classic Asp especially this is a big deal because since developers can’t rely solely on client side validation for security reasons they usually choose not to implement it at all. Where client side validation can really improve your site is in it’s performance. If your form is on a large page or even if the form itself is very large, then relying on server side validation requires a round trip to the server with all fields and values included. If something is amiss, the server has to return you to the page you were on and depending on the build of your site (classic asp or .net) the client and the server have to process either a full or partial post to alert the user to what might have been as simple as a missing checkbox selection. Why go through all that trouble and processing when a simple client side script can perform preliminary or even in some case full form validation without contacting the server? If your user has a slow connection, maybe they are on a mobile device, or perhaps they simply have a slow connection from their provider, they may not realize that when the page begins to reload something has gone wrong. Worst case scenario, they may see the page begin to refresh and assume they’ve finished the process and leave the page entirely. More often than not, they will simply wait for the page to reload, fix any errors they’re alerted to, and re-submit the form, but with client side validation, all that wait time can be avoided. The user doesn’t need to worry about possibly having to wait on a slow connection, they are never given the false hope that they may be done only to have the form pop right back up, and most importantly your network doesn’t have to field and respond to as many incomplete or invalid form submissions meaning your site responds faster for everyone.

As I mentioned before, client side validation cannot take the place of server-side validation because it isn’t as secure, but since the average user isn’t going to maliciously try to bypass your form validation (unless your site caters exclusively to hackers) the duplication of effort on the client side can not only improve the user’s experience on your site, but also cut down on unnecessary traffic through your network and speed up your site’s performance.

Two years ago I wrote a blog about “HTML5 the future of the web?” and now the future of the web is here. On December 17^th, 2012 the Worldwide Web Consortium (W3C) published the complete definition of the HTML5 specifications.

“Though not yet W3C standards, these specifications are now feature complete, meaning businesses and developers have a stable target for implementation and planning.”

“As of today, businesses know what they can rely on for HTML5 in the coming years, and what their customers will demand. Likewise, developers will know what skills to cultivate to reach smart phones, cars, televisions, ebooks, digital signs, and devices not yet known.” said W3C CEO Jeff Jaffe.

Check out the W3C announcement: http://www.w3.org/2012/12/html5-cr

In a world where speed and ease of use matters, sticky navigation bars are proving to be a valuable interface tool on the web.

I’ve rounded up a few examples of static of stick header and footers over the past week or so:

1) http://gillesmanzato.com/

2) http://webdesignerwall.com/

3) http://pinterest.com/

Pinterest’s is so wonderful because it had a header that scrolls and only the nav sticks. This means that the header section is more flexible and you are only sticking the section that people will actually need after they have scrolled.

4) http://www.bloom-london.com/

5) http://www.flickr.com/

6) http://www.hulu.com/

7) http://www.google.com/nexus/

The Cons:

Some of the issues with using a sticky header is that it does limit the design of any layout. You are confined to having the header exist in a short space. The Pinterest approach of having a scrolling header, but a sticky nav can resolve some of these issues and offer a bit more flexibility, however.

There is also the issue of browser and device support. It would definitely be something to keep in mind. Not all of your users are going to have the same experience with this technique.

Sticky footers and sidebars are also becoming more and more prevalent. It does takes a bit of discretion to use these things to that they do not become a nuisance and actually enable the user to have a better experience with the site.

As a new year approaches we often look for what the hot items or trends are going to be. For those of us who create websites the hot topic going into the new year is Responsive Web. With tablet and smartphone sales increasing and less users browsing through desktops, the way we design websites is rapidly changing. A million screens and we need to build for all of them. The solution is to make a website that works equally well on every device. The answer, responsive web design. In simple terms, a responsive web design uses “media queries” to figure out what resolution of device it’s being served on. Flexible images and fluid grids then size correctly to fit the screen. In 2013 we will start to see more companies going towards a responsive design to accommodate their users browsing patterns. Read more about Why 2013 Is the Year of Responsive Web Design on Mashable.com.

Responsive Web Design is peremptory for any company looking to redesign their website.  It sounds interesting, but what is responsive web design and how does it work?  Here is a quick rundown, in a non-techy way for this new standard practice in web development.

A responsive website is basically a site whose code is created so that it can automatically adapt to the screen sizes of various devices by setting rules to create fluid/flexible layouts.  This means that companies no longer have to develop separate websites for desktop users and for mobile/tablet users.  They just need one!

It does this through the use of CSS3 media queries.  CSS is the rules that create the design and layout of a website.  This optimized website code will let your website essentially look good on several desktop screen sizes, tablets, and smartphones.  This is a ‘game changer’ because it provides site owners the ability to give a similar experience for website visitors, regardless of how they are accessing the site.   All you have to do is modify the CSS to detect the size of a users’ device, and then it will automatically push out the website in a flexible way so that all media, images, content, and links are accessible.

I really was looking for some nice serious techie news to blog about today, but this article was just too irresistible to ignore: GIF wins Oxford’s ‘Word of the Year’.  Despite the hilarious sub-title “JPG and PNG decline to comment“, I really did learn a lot  in the guts of the article.  For example, I didn’t realize that our friend the “GIF” (graphic interchange format) has been around for 25 years (almost as long as me!) and that nearly every Internet browser ever made supports it (and believe me, that’s A LOT of programs, cause we test our sites in most of them).  The acronym has also evolved from a noun to a verb (“Most recently many media outlets were live-GIFing the 2012 presidential  debates.”).  According to the article “it’s the easiest way to share a quick animation.”

And as a completely un-techie side note, who even knew that Oxford Dictionary selected a “USA Word of the Year“???

A GIF of GIF

Responsive website design will take over the internet, it’s inevitable. It’s a beautiful answer to the question of how to make content on the internet appropriate for a wide array of devices and screen sizes. With each new design and development approach comes a whole new set of standards.

Often the best way to deal with the menu in responsive design is to either stack it, creating an array of buttons or hide it in a drawer. Hiding the menu always seemed like it would compromise usability to me, but I’ve now accepted it as a reasonable way to deal with the main navigation of a site when it gets down to being displayed on a small screen size. Consider this, the menu isn’t always needed for navigation, especially with the type of casual browsing someone may be doing from a mobile phone (while bored, waiting in line, at Starbucks).

Now that this technique is becoming standard, a universal icon is emerging to represent that menu that you instantly recognize. I present to you:

This seems to be the icon that is being most commonly used so far and seems to be quickly becoming a universally recognized symbol for a flyout navigation.

A few other options exist, however.

A menu in a standard type of drop down like shown above is not a bad option. But I think because that type of drop down is often used for many other areas (like contact forms) it isn’t immediately recognized as a main navigation and may confuse some users.

The grid icon is also sometimes seen and it’s commonly used to represent the menu in apps because they often utilize and icon based grid navigation. But for websites with text link navigations this symbol doesn’t directly relate.

I think it’s interesting how design is responding to responsive websites and creating graphics to suit it’s needs. Time will tell if the three line icon will become a true standard or if more innovative ways of showing navigations will arise.