    
|
|
|
The trend of fixed heading styles in web design has grown exponentially in recent years. I have read a lot of criticism, both for and against these techniques, and generally it boils down to personal preference. Lots of designers have a problem dealing with navbars overtaking their screen with little-to-no value added into the user experience. Others find these techniques immensely helpful, as they provide quick access to popular links without the need to scroll way back up to the top of the page.
In this article I want to delve a bit deeper into these trends of fixed headers and navigation bars. I want to look at some examples for how this may be constructed on your own website projects, and where the trends may be leading as we forge ahead into the future. There are certainly issues to deal with regarding these trends and I hope to briefly touch upon the potential tribulations for this user experience. But if you can build a fixed header that still leaves plenty of room for page content, it may just prove to be a winning design interface.
The first and most obvious interface is to apply your navigation bar settings so that they look natural in the page. This means you can setup a layout where the top navigation appears to blend naturally along with the other page elements. Take the example from Theory’s website.
The entire heading area appears to fit naturally right at the top of the page. It is difficult to tell the navigation is fixed until you begin scrolling down the page. It also demonstrates a good purpose of using parallax single-page scrolling. Everything can be located at the click of a link and users are not rummaging through a complicated navigation structure. These fixed bars can work wonders for a website’s branding design.
The largest issue is combating a difficult experience on mobile devices. It is possible to redesign the layout so it all forms responsively to the smaller browser window. However the fixed navigation bar can still be a problem since there is not as much room for content. It should be obvious that parallax single-page websites can benefit the most by using this technique.
Another good reason why different sites will use this style of navigation is for easy-access to important webpages. Even if there are lots of other sub-pages you can still point out the most common ones which gather the most number of pageviews. This can help first-time visitors to gauge the type of content on your site and how much interest they really have.
Nova Crystallis is a Square-Enix online magazine which also uses the fixed navigation bar technique. This is a good example to illustrate how content may still be accessed while keeping a fixed navigation. The website logo and popular categories are listed at the top in an orderly fashion. This navigation provides easy access to other post archives where readers may find similar articles.
Granted, online blogs and magazines are not the only websites for using fixed topbars. Almost any website can use this technique, but you really want to consider how it will affect user experience. Often times you can fit this navigation into content-heavy websites much easier because of the larger page number. Consider how frequently users may look to browse other categories and sections within a website. Social networks are another great example where users are frequently switching between pages, and the fixed navigation provides a quick solution.
The biggest issue I have noticed is a lack of support for mobile devices. Responsive layouts are very commonplace yet they are not perfect to use in every project. But an even worse idea is to keep a very large fixed navigation bar on your mobile site, while also scaling the site to “width=device-width” in the viewport. It forces all the page text to conform into the mobile browser which may be partially covered by the top navigation bar.
Your typical visitor from their laptop or desktop should have enough room to clearly read the page content. As long as the fixed navigation is given extra space at the top then every visitor will have space to access the page from their home monitor. Even tablet computers may still provide an acceptable browsing experience – but handling mobile traffic can be a confusing exception. I would typically recommend dropping the fixed navigation and moving to a mobile-friendly alternative.
Hidden navigation menus can be seen everywhere. Even this exact Treehouse blog layout has a mobile responsive solution with a hidden menu. Recognizing that mobile screens are much smaller than any other, you can provide a cleaner experience from almost any device. It may be worthwhile to poll some visitors for their feedback and see how your navigation ideas are landing.
Often times I am surprised to find this design style in so many layouts. Using a fixed heading panel is a unique way to setup background images or videos above-the-fold of your website. These could also be vector illustrations, your company logo, branding, really any webpage elements to catch the visitor’s attention. The homepage of Google Ventures is one example.
Fixed headers will not scroll down the page and continue along with the user. Rather the background image and contents inside the header appear to stay fixed as the user scrolls. This makes the entire header behave as its own independent “panel” offset by the rest of the layout. The technique is more useful as an aesthetic design effect than anything else. But you want to capture a user’s attention right after they land on your page and this is one way to do so.
Now this style of design has really stood out to me because it is quick to notice and often very elegant. When you initially land on a page you will notice the navigation and heading area blends naturally. Then as you begin scrolling past a certain point the header will reshape itself and appear fixed at the top of the page. Scrolling back up the header un-sticks itself and you find the same layout as when the page first loaded.
Hongkiat is a great example of this technique in action. The regular header at the top of the page will include links to categories and other pages on the blog. As you scroll beyond the header a new fixed navigation bar will appear. This is very small and does not take up a whole lot of space. You will find the website logo and a small collection of social media sharing badges. This gives your visitors access to quick information as they need it, while also keeping the full header accessible at the very top of the page.
The reason I enjoy rolling headers is because each website has the chance to experiment by changing up the content. Your top header may be a lot bigger than the fixed alternative, and so you have the chance to include only the most important links. As long as the fixed navbar isn’t taking up massive screen real estate then you can expect mostly positive feedback.
Along with the tips above I also would like to share a brief gallery of design examples. Fellow designers who are interested in these trends may not know exactly where to get started. And what a better method of doing research than by checking out other similar websites using these techniques? I have put together another 30 various website layouts using fixed headers and navigation elements. Check out the showcase gallery and feel free to share your own thoughts with us in the post discussion area below.
The post Fixed Headers and Navigation Bars Used in Web Design appeared first on Treehouse Blog.
]]>Page edited by Andrea Mocko
Browse All Classroom Technology Articles
Collapse all
|
Popular Articles
Don't See What You're Looking For?
Help us improve: Suggest an article or Add a Comment on any page. |
Page edited by Andrea Mocko
|
More about RT |
Help us improve: Suggest an article or Add a Comment on any page.
|
|
In his junior year at UMBC, Collin Wojciechowski ’13, political science, represented nearly 180,000 students within the University System of Maryland (USM) as their sole student representative on the Board of Regents. Wojciechowski advocated against “doomsday” budget cuts and tuition increases and successfully lobbied to overhaul the USM policy for assessing student fees, making students an active part of the discussion.
Without the aid of scholarships, he would never have been able to serve his fellow students in this way. We sat down with the newly graduated Sondheim Scholar to talk a little bit about the part scholarships have played in his life.
Help UMBC students do AMAZING things. Make a gift to the 30 Days/30 Scholarships campaign today!
Q: How important was it to your college career to have the support of scholarships?
A: Being the son of a firemen and a public school teacher and the oldest of three brothers who all aspire to seek higher education, having the support of a scholarship was extremely important to my college career.
Q: Can you tell us a little about what it meant to you to be able to serve as the student regent, and then to continue working with legislators?
A: If I did not have a scholarship, I would not have been able to be the USM Student Regent; it’s as simple as that. I only had the time and ability to serve at that post because I did not have to work a side job to pay for college.
Being the Student Regent was one of the most meaningful experiences of my life. Representing students through such trying times as merger debate and the doomsday budget was the thrill of a lifetime. To then be able to take what I had learned on the Board and use it to represent Dr. Hrabowski in Annapolis was a dream. I have never had more fun then the Session I spent advocating for UMBC before legislators.
Q: Has that work given you added insight into education funding, and if so, can you talk a little about the significance of alumni support of education in Maryland?
A: Having been a member of the Advancement Committee of the USM Board of Regents, which oversees alumni giving, I feel I have a unique perspective on the significance that alumni support plays in higher education in Maryland. While our state, specifically Governor Martin O’Malley, has done tremendous things for public universities in terms of funding, student support and financial aid always need assistance. As students and their families continue to face economic difficulty it is up to the alumni base to ensure UMBC is a place welcoming to everyone.
Read more about Collin and his UMBC experiences on the Class of 2013 site.
]]>|
|
 |
We are talking and reading a lot about responsive Web design (RWD) these days, but very little attention is given to Web applications. Admittedly, RWD still has to be ironed out. But many of us believe it to be a strong concept, and it is here to stay. So, why don’t we extend this topic to HTML5-powered applications? Because responsive Web applications (RWAs) are both a huge opportunity and a big challenge, I wanted to dive in.
Building a RWA is more feasible than you might think. In this article, we will explore ideas and solutions. In the first part, we will set up some important concepts. We will build on these in the second part to actually develop a RWA, and then explore how scalable and portable this approach is.
It’s not easy to admit, but recently it has become more and more apparent that we don’t know many things about users of our websites. Varying screen sizes, device features and input mechanisms are pretty much RWD’s reasons for existence.
From the lessons we’ve learned so far, we mustn’t assume too much. For instance, a small screen is not necessarily a touch device. A mobile device could be over 1280 pixels wide. And a desktop could have a slow connection. We just don’t know. And that’s fine. This means we can focus on these things separately without making assumptions: that’s what responsiveness is all about.
The “JavaScript-enabled” debate is so ’90s. We need to optimize for accessibility and indexability (i.e. SEO) anyway. Claiming that JavaScript is required for Web apps and, thus, that there is no real need to pre-render HTML is fair (because SEO is usually not or less important for apps). But because we are going responsive, we will inherently pay a lot attention to mobile and, thus, to performance as well. This is why we are betting heavily on progressive enhancement.
RWD has mostly to do with not knowing the screen’s width. We have multiple tools to work with, such as media queries, relative units and responsive images. No matter how wonderful RWD is conceptually, some technical issues still need to be solved.
Not many big websites have gone truly responsive since The Boston Globe. (Image credits: Antoine Lefeuvre)
In the end, RWD is mostly about client-side solutions. Assuming that the server basically sends the same initial document and resources (images, CSS and JavaScript) to every device, any responsive measures will be taken on the client, such as:
<picture> or @srcset to get responsive images;Some of the issues surrounding RWD today are the following:
Imagine that these challenges (such as images not being responsive and CSS loading unnecessarily) were solved on all devices and in all browsers, and that we didn’t have to resort to hacks or polyfills in the client. This would transfer some of the load from the client to the server (for instance, the CMS would have more control over responsive images).
But we would still face the issue of responsive content. Although many believe that the constraints of mobile help us to focus, to write better content and to build better designs, sometimes it’s simply not enough. This is where server-side solutions such as RESS and HTTP Client Hints come in. Basically, by knowing the device’s constraints and features up front, we can serve a different and optimized template to it.
Assuming we want to COPE, DRY and KISS and stuff, I think it comes down to where you want to draw the line here: the more important that performance and content tailored to each device is, the more necessary server-side assistance becomes. But we also have to bet on user-agent detection and on content negation. I’d say that this is a big threshold, but your mileage may vary. In any case, I can see content-focused websites getting there sooner than Web apps.
Having said that, I am focusing on RWAs in this article without resorting to server-side solutions.
RWD is clearly about layout and design, but we will also have to focus on responsive behavior. It is what makes applications different from websites. Fluid grids and responsive images are great, but once we start talking about Web applications, we also have to be responsive in loading modules according to screen size or device capability (i.e. pretty much media queries for JavaScript).
For instance, an application might require GPS to be usable. Or it might contain a large interactive table that just doesn’t cut it on a small screen. And we simply can’t set display: none on all of these things, nor can we build everything twice.
We clearly need more.
To quickly recap, our fundamental concepts are:
Fully armed, we will now look into a way to build responsive, context-aware applications. We’ll do this by declaratively specifying modules, conditions for loading modules, and extended modules or variants, based on feature detection and media queries. Then, we’ll dig deeper into the mechanics of dependency injection to see how all of this can be implemented.
We’ll start off by applying the concepts of progressive enhancement and mobile first, and create a common set of HTML, CSS and JavaScript for all devices. Later, we’ll progressively enhance the application based on content, screen size, device features, etc. The foundation is always plain HTML. Consider this fragment:
<div data-module="myModule">
<p>Pre-rendered content</p>
</div>
Let’s assume we have some logic to query the data-module attribute in our document, to load up the referenced application module (myModule) and then to attach it to that element. Basically, we would be adding behavior that targets a particular fragment in the document.
This is our first step in making a Web application responsive: progressive module injection. Also, note that we could easily attach multiple modules to a single page in this way.
Sometimes we want to load a module only if a certain condition is met — for instance, when the device has a particular feature, such as touch or GPS:
<div data-module="find/my/dog" data-condition="gps">
<p>Pre-rendered fallback content if GPS is unavailable.</p>
</div>
This will load the find/my/dog module only if the geolocation API is available.
Note: For the smallest footprint possible, we’ll simply use our own feature detection for now. (Really, we’re just checking for 'geolocation' in navigator.) Later, we might need more robust detection and so delegate this task to a tool such as Modernizr or Has.js (and possibly PhoneGap in hybrid mode).
What if we want to load variants of a module based on media queries? Take this syntax:
<div data-module="myModule" data-variant="large">
<p>Pre-rendered content</p>
</div>
This will load myModule on small screens and myModule/large on large screens.
For brevity, this single attribute contains the condition and the location of the variant (by convention). Programmatically, you could go mobile first and have the latter extend from the former (or separated modules, or even the other way around). This can be decided case by case.
Of course, we couldn’t call this responsive if it wasn’t actually driven by media queries. Consider this CSS:
@media all and (min-width: 45em) {
body:after {
content: 'large';
display: none;
}
}
Then, from JavaScript this value can be read:
var size = window.getComputedStyle(document.body,':after').getPropertyValue('content');
And this is why we can decide to load the myModule/large module from the last example if size === "large", and load myModule otherwise. Being able to conditionally not load a module at all is useful, too:
<div data-module="myModule" data-condition="!small">
<p>Pre-rendered content</p>
</div>
There might be cases for media queries inside module declarations:
<div data-module="myModule" data-matchMedia="min-width: 800px">
<p>Pre-rendered content</p>
</div>
Here we can use the window.matchMedia() API (a polyfill is available). I normally wouldn’t recommend doing this because it’s not very maintainable. Following breakpoints as set in CSS seems logical (because page layout probably dictates which modules to show or hide anyway). But obviously it depends on the situation. Targeted element queries may also prove useful:
<div data-module="myModule" data-matchMediaElement="(min-width: 600px)"></div>
Please note that the names of the attributes used here represent only an example, a basic implementation. They’re supposed to clarify the idea. In a real-world scenario, it might be wise to, for example, namespace the attributes, to allow for multiple modules and/or conditions, and so on.
Take special care with device orientation. We don’t want to load a different module when the device is rotated. So, the module itself should be responsive, and the page’s layout might need to accommodate for this.
The concept of responsive behavior allows for a great deal of flexibility in how applications are designed and built. We will now look into where those “modules” come in, how they relate to application structure, and how this module injection might actually work.
We can think of a client-side application as a group of application modules that are built with low-level modules. As an example, we might have User and Message models and a MessageDetail view to compose an Inbox application module, which is part of an entire email client application. The details of implementation, such as the module format to be used (for example, AMD, CommonJS or the “revealing module” pattern), are not important here. Also, defining things this way doesn’t mean we can’t have a bunch of mini-apps on a single page. On the other hand, I have found this approach to scale well to applications of any size.
An approach I see a lot is to put something like <div id="container"> in the HTML, and then load a bunch of JavaScript that uses that element as a hook to append layouts or views. For a single application on a single page, this works fine, but in my experience it doesn’t scale well:
To solve these issues, instead of letting application modules control themselves, what about making them more reusable by providing the element they should attach to? Additionally, we don’t need to know which modules must be loaded up front; we will do that dynamically. Let’s see how things come together using powerful patterns such as Dependency Injection (DI) and Inversion of Control (IOC).
You might have wondered how myModule actually gets loaded and instantiated.
Loading the dependency is pretty easy. For instance, take the string from the data-module attribute (myModule), and have a module loader fetch the myModule.js script.
Let’s assume we are using AMD or CommonJS (either of which I highly recommended) and that the module exports something (say, its public API). Let’s also assume that this is some kind of constructor that can be instantiated. We don’t know how to instantiate it because we don’t know exactly what it is up front. Should we instantiate it using new? What arguments should be passed? Is it a native JavaScript constructor function or a Backbone view or something completely different? Can we make sure the module attaches itself to the DOM element that we provide it with?
We have a couple of possible approaches here. A simple one is to always expect the same exported value — such as a Backbone view. It’s simple but might be enough. It would come down to this (using AMD and a Backbone view):
var moduleNode = document.querySelector('[data-module]'),
moduleName = node.getAttribute('data-module');
require([moduleName], function(MyBackBoneView) {
new MyBackBoneView({
el: moduleNode
});
})
That’s the gist of it. It works fine, but there are even better ways to apply this pattern of dependency injection.
Let’s take a library such as the excellent wire.js library by cujoJS. An important concept in wire.js is “wire specs,” which essentially are IOC containers. It performs the actual instantiation of the application modules based on a declarative specification. Going this route, the data-module should reference a wire spec (instead of a module) that describes what module to load and how to instantiate it, allowing for practically any type of module. Now, all we need to do is pass the reference to the spec and the viewNode to wire.js. We can simply define this:
wire([specName, { viewNode: moduleNode }]);
Much better. We let wire.js do all of the hard work. Besides, wire has a ton of other features.
In summary, we can say that our declarative composition in HTML (<div data-module="">) is parsed by the composer, and consults the advisor about whether the module should be loaded (data-condition) and which module to load (data-module or data-variant), so that the dependency injector (DI, wire.js) can load and apply the correct spec and application module:
Detections for screen size and device features that are used to build responsive applications are sometimes implemented deep inside application logic. This responsibility should be laid elsewhere, decoupled more from the particular applications. We are already doing our (responsive) layout composition with HTML and CSS, so responsive applications fit in naturally. You could think of the HTML as an IOC container to compose applications.
You might not like to put (even) more information in the HTML. And honestly, I don’t like it at all. But it’s the price to pay for optimized performance when scaling up. Otherwise, we would have to make another request to find out whether and which module to load, which defeats the purpose.
I think the combination of declarative application composition, responsive module loading and module extension opens up a boatload of options. It gives you a lot of freedom to implement application modules the way you want, while supporting a high level of performance, maintainability and software design.
Sometimes RWD actually decreases the performance of a website when implemented superficially (such as by simply adding some media queries or extra JavaScript). But for RWA, performance is actually what drives the responsive injection of modules or variants of modules. In the spirit of mobile first, load only what is required (and enhance from there).
Looking at the build process to minify and optimize applications, we can see that the challenge lies in finding the right approach to optimize either for a single application or for reusable application modules across multiple pages or contexts. In the former case, concatenating all resources into a single JavaScript file is probably best. In the latter case, concatenating resources into a separate shared core file and then packaging application modules into separate files is a sound approach.
Responsive behavior and complete RWAs are powerful in a lot of scenarios, and they can be implemented using various patterns. We have only scratched the surface. But technically and conceptually, the approach is highly scalable. Let’s look at some example scenarios and patterns:
In general, the point is to maximize portability and reach by building on proven concepts to run applications on multiple platforms and environments.
Some of the major advantages of building applications in HTML5 is that they’re future-proof and portable. Write HTML5 today and your efforts won’t be obsolete tomorrow. The list of platforms and environments where HTML5-powered applications run keeps growing rapidly:
Note: Tools such as Adobe PhoneGap Build, IBM Worklight and Telerik’s Icenium all use Apache Cordova APIs to access native device functionality.
You might want to dive into some code or see things in action. That’s why I created a responsive Web apps repository on GitHub, which also serves as a working demo.
Honestly, not many big websites (let alone true Web applications) have gone truly responsive since The Boston Globe. However, looking at deciding factors such as cost, distribution, reach, portability and auto-updating, RWAs are both a huge opportunity and a big challenge. It’s only a matter of time before they become much more mainstream.
We are still looking for ways to get there, and we’ve covered just one approach to building RWAs here. In any case, declarative composition for responsive applications is quite powerful and could serve as a solid starting point.
(al) (ea)
© Lars Kappert for Smashing Magazine, 2013.
]]>