Web Design, for the Web, you know, on a Computer

A lot of funky web designs - laden with inline scrolling, full of confusing navigation, accidentally hidden content, odd colors - are caused by designers or marketing personel who design websites on or for paper. Print designers make many fundamental mistakes when trying to design a site because they’re so locked into brochure or printed ad design that they don’t stop to think about how things will look online, how to deal with screen real estate, and how to handle a template which will be responsible for displaying varying content. Marketing managers have been known to actually print websites to paper and then discuss the design aesthetics based on the print-out! That’s like critiquing a CD mix while sticking your fingers in your ears and shouting “la la la la la”. The more that people realize web design is its own entity, the better treatment of design on the web we will see.

@font-face

Solving the dilemma of boring font choices or images for headlines is the @font-face CSS rule. By allowing the designer to upload a font and define it as a style, any font can now be displayed on any machine. Although support for this is not universal, it degrades into the normal CSS font rules gracefully, so you can start using it now to enhance your projects. I actually only used this for the first time about two weeks ago, but I’m already hooked!

CSS3

My favorite part about web design is chopping up a dozen tiny images to achieve rounded corners, gradients, and drop shadows. Wait… that’s my least favorite part. Thankfully, it’s something I’ll never need to do again thanks to CSS3 with it’s wonderful border-radius, gradients, and box-shadow properties. The additional wonders of multiple backgrounds, border images, text-shadows, and transitions will eliminate much hastle and enable great design.

jQuery

Simply put, jQuery obliterates the need for Flash. jQuery allows for amazing animations, gorgeous photo galleries, draggable and dropable user interfaces, and more without needing to introduce additional technology onto each page. Because jQuery is just JavaScript (which Flash usually needs to use just to load), and it operates by applying effects to standard HTML elements, the transition from a static mock-up to a engaging animated page requires less effort from the programmer and from the client’s machine. It’s an absolutely dream to work with and once people use this they’ll never go back to Flash.

Experienced Users

Once an entire generation grows up online the need for explaining simple operations in great detail, for reminding users to update their 10 year-old browser, and for scaling back designs should dwindle. It will be nice to be able to design without having to be constantly reminded that half the world still somehow doesn’t know to click on links and buttons or to click the logo to return to the home page. This might not happen any time soon, and their of course will always be a need to cater to thouse who are less tech-savvy, but it’ll be amazing to not have to worry about the lowest common denominator quite so much.

Inline Scrolling

In the early 2000s the rage in web design was making sites that looked like real world objects - desks, filing cabinets, bookcases, and so on. They tended to look great as a piece of art, but all functioned terribly as websites because every single content area on the page contained vertical, and sometimes even horizontal scrolling. Thankfully, most of these designs have disappeared as designers have learned to cope with the inconsistent amounts of content a web template needs to handle. Inline scrolling does rear its ugly little head every once in a while yet, so make sure to throw tomatoes and shout “boooooooo” at any designer you find committing this party foul.

Dark Helvetica on a Light Background

I get it, print designers, Helvetica rules your world. The thing is, it doesn’t look that fantastic on the screen, especially as small content text. It anti-aliases very lightly in most browsers, it’s Rs are funny, and it just looks dull. There are tons of better sans-serif fonts for use on the web, so go watch that movie about Helvetica one last time and then put it to rest.

Tables for Layout

I have crusaded against these since my very first day as a designer/developer and it’s been mostly a losing battle until this year. For the first time in my career I am not required to use HTML tables for layout but those many years of dealing with this antiquated method have scarred me for life. For those who are still using tables for layout, please, please, please, take a few weeks to learn the wonders of a div/CSS layout.

Flash

I took a class in Flash once and thought that I’d love it. As relatively inexperienced as I was back then, I could still tell that Flash websites were a mistake that should never have happened. Search engines, Content Management Systems, browsers, the forward and back buttons, screen readers, slower computers, servers, bookmarks, selectable text, and easy-to-use navigation all hate with Flash. Annoying music, needless animation, a lack of quality content, minute-long animations before you can see any real information, and people who like spending hours making simple text updates to their site all love Flash. Enough said.

IE6

Arguably the worst thing that has ever happened to the internet, IE6 has been driving designers and developers to the brink of insanity for a decade. This ancient piece of software refused to even adopt the standards of its day and certainly didn’t bother to keep up with any new developments since it came out. Because it was the default program of the most popular operating system in the world, it once held an unbelievably high market share and its grip on the world only very slowly waned with the introduction of Firefox, the release of IE7, the growing popularity of Macs, Safari for Windows, and Chrome. It still forces developers to reckon with it by staking out as much as 25% of the market share in some areas of the world, but within the next two years I predict it will finally become a non-factor.

We Know to Click

It’s a mouse. I get it. Move. Click. Move. Click. Move… click. That’s how it works. A call to action is great, but I know the action itself is a click. A simple “Learn More” is the same as “Click to Learn More.” I’d argue that “click to” can be compared to the “you” in an imperative sentence in English - we know it’s supposed to be there, so don’t bother writing it. Or actually, maybe we should add that back into the web, so that everything reads “You, Click Here to…”. Now THAT’S an idea!

Or at Lease We Should Know to Click

Often, when the words “click to” are required, it’s because the design isn’t intuitive. This means that the real fix lies in the designer’s hands, and that the underlying design issues should be addressed before adding “click to” everywhere. Slapping “click to” on a confusing design is like going nuts with the nail gun on a falling structure. It’s going to eventually fail unless you fix the foundation, so don’t just use the easy, quick fix.

Confusing Search Engines

Is this a website about your revolutionary new product, or about clicking? When two dozen links all contain the words “click to” these words will rank high to a search engine spider. By writing better copy that incorporates key words related to your product, service, or business, these words will rank high. Would you rather be represented on the web as “click to” or “quality solutions, low price, local business”?

Call for Action without Calling for Clicking

Avoiding “click to” text advances the overall effect of a page the same way that eliminating “be” verbs from an essay does. Granted, we all use tons of “be” verbs in our normal speech and writing, but I can honestly say, as someone who once managed to write a 20 page paper without “is,has,was,will…”, eliminating them greatly improves your writing. The same is true for web copy. Sure, “Click to Learn About Our Program” works, but “What Do We Do?” better captures the user’s interest while saving some screen real-estate. What this boils down to is that there is always a more cleverly worded, more concise, more engaging alternative to “Click to” text, so write it!

Documentation

The first part, often overlooked in the excitement of writing a new shiny plugin, is the basic author info and a markup example. I find the markup example to be quite handy while developing since you can keep the markup in the file you’re currently working on, saving you the trouble of toggling back and forth between markup and JS to remember what you’re traversing or manipulating.

1:  /*
2:   *     PluginName- jQuery plugin
3:   *     written by AuthorName
4:   *     URL
5:   *
6:   *     Copyright (c) 2010 AuthorName (AuthorURL)
7:   *     Dual licensed under the MIT (MIT-LICENSE.txt)
8:   *     and GPL (GPL-LICENSE.txt) licenses.
9:   *
10:   *     Built for jQuery library
11:   *     http://jquery.com
12:   *
13:   */
14:  /*
15:   *     markup example
16:   */

Declaration and Parameters

Next comes the basic plugin function declaration, complete with the default values and user options. This is the heart of the plugin and it’s something you’ll absolutely need to include in each and every plugin, so it’s best to just keep the code lying around in working order.

1:  (function($){
2:       $.fn.PluginName = function(options) {
3:            // Default Values
4:            var defaults = {
5:                 // height: 500, width: 500
6:            };
7:            var options = $.extend(defaults, options);

Initialization

After dealing with the defaults and options, I think it makes the most sense to list all the code responsible for initializing the plugin. The two steps to this are declaring any variables being used only internally and to actually write out whatever DOM manipulations or effects need to occur right as the plugin is initialized.

1:            // Internal Variables
2:            var aVariable;
3:            // Initializing Code

Methods

Next come the guts of the plugin. We begin by binding the methods and DOM references to each instance of the markup targeted by the plugin with “return this.each(function()”. The next line helps immensely by creating a variable which is used to keep track of the markup instance. Without this variable, you’ll find that your plugins often will only work if used once per page. Next come the reused helper methods of the plugin, which I find best grouped by event bindings, general helper methods, and then finally timed events.

1:            return this.each(function() {
2:                 var obj = $(this);
3:                 // Event Bindings
4:                 $("a", obj).click(function (){
5:                      // Click Code
6:                 });
7:                 // Plugin Methods
8:                 function aMethod() {
9:                      // Method code
10:                 };
11:                 // Timed Events
12:                 // timeout = setTimeout(function, 10000);
13:            });
14:       };
15:  })(jQuery);

That’s It

And that’s it. Although pretty basic, starting a new plugin from this template rather than from scratch can save a lot of headache. I welcome you to download it, give it a try, and offer any suggestions for improvements!

Download the Generic jQuery Plugin Template.

Markup

The markup requires two unordered lists wrapped in a div with a class of “verticalslider.” The first list is given a class of  “verticalslider_tabs” and contains the text (or images) that appear on the tabs. The second list is given a class of “verticalslider_contents” and contains the contents that appear to the side of the tabs.

1:      <div class="verticalslider" id="textExample">
2:      <ul class="verticalslider_tabs">
3:        <li><a href="#">Lorem Ipsum</a></li>
4:        <li><a href="#">Praesent Pulvinar</a></li>
5:        <li><a href="#">Nunc Adipiscing</a></li>
6:        <li><a href="#">Praesent Dapibus</a></li>
7:      </ul>
8:      <ul class="verticalslider_contents">
9:        <li>
10:        <h2>Lorem Ipsum</h2>
11:        <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut accumsan placerat bibendum.</p></li>
12:        <li>
13:        <h2>Praesent Pulvinar</h2>
14:        <p>Praesent pulvinar, lorem nec ullamcorper semper, ipsum erat vestibulum lacus, in sodales lorem mi in leo.</p></li>
15:        <li>
16:        <h2>Nunc Adipiscing</h2>
17:        <p>Nunc adipiscing purus id orci rutrum placerat.</p></li>
18:        <li>
19:        <h2>Praesent Dapibus</h2>
20:        <p>Praesent dapibus metus vitae velit blandit tempor.</p></li>
21:      </ul>
22:    </div>

Includes

To use VerticalTabs you must of course include jQuery, as well as including the single VerticalTabs JavaScript file and the single VerticalTabs css file.

1:  <script type="text/javascript" src="js/jquery-1.4.2.min.js"></script>
2:  <script type="text/javascript" src="verticaltabs/js/verticaltabs1.0.pack.js"></script> <!--http://dean.edwards.name/packer/-->
3:  <link rel="stylesheet" href="verticaltabs/css/verticaltabs.css" />

Initializing

Simply initialize the plugin as you would any other jQuery plugin.

1:  $("#textExample").verticaltabs();

Options

There are only a handful of options available for VerticalTabs detailed below:

• speed - the speed in ms it takes for one content item to fade out and the other fade in
• slideShow - boolean parameter which determines whether or not the contents automatically rotate
• slideShowSpeed - when in slideShowmode, this determines how long VerticalTabs pauses before switching contents
• activeIndex - specifies which tab and its corresponding contents displayed on load
• playPausePos - determines the position of the play/pause button when in slideShow mode (topRight, bottomRight, topLeft, bottomLeft).

View the Demo

Download Demo

Chapter 11 closes the book with a rather dull read on creating site and database backups, which must be done with two modules, seeking help on any CMSMS problems, and performance tuning. These are important concepts, but it was a dreary read and I think perhaps the advanced functionality or a case study of a really well done site would have been a better way to end the book.

Overall though, this is an incredibly useful and easy to digest manual for getting started with one of the best CMS applications available today.

So, after the far too sparse overview and warnings the book dives into the Products module which sadly needs a custom field added for image.  Creating templates and categories is covered and detail and the CMSMS eCommerce solutions start to look acceptable.

The next module to integrate is the Cart module which thankfully is easy to connect to Products. After Cart comes Orders which has tons of dependencies and templates to worry about and also needs to be integrated with Self Registration. This is where the eCommerce solutions begin to get very annoying to work on as there are so many forms to style - login, billing info, shipping info, etc.

The last step discussed in detail is setting a Paypal gateway. The book makes sure to explain the work one must do outside of CMSMS, setting up dev PayPal account, connects the CMSMS Shop to PayPal using IPN.

Optional modules for taxes, shipping, promotions, and gift baskets are also mentioned but not really explained. If you’re looking to use features like these, it’s better to just use a dedicated eCommerce platform as getting all of these independent modules to communicated with each other can be misery.

Overall the chapter does a good job introducing and explaining the eCommerce setup in CMSMS but it really glosses over the  more important aspects such as choosing the right eCommerce platform, building a secure environment, fulfilling orders, and more.

Chapter 8 deals with creating new module by using the CTLModuleMaker module. That’s right, you can use a module making module to create a new module. The book walks the user through the steps of  creating hierarchy, creating templates,  and integrating the module into the site search. Thankfully most of this difficult work is prefaced by encouraging the user to thoroughly search existing modules for the desired functionality before tackling the somewhat difficult task of creating a brand new module. The idea of modifying and combining existing modules to achieve new functionality is also encouraged with an example of turning the general feedback module  into a help ticket system.

These two chapters are really starting to get into the heart of CMSMS, but if you’re just a designer or an end user, you can probably put the book down at this point. For hardcore developers, these chapters mark the point where you should stop skimming and start really reading.

Following the exciting discussion on modules is the bit more dreary but incredibly important overview on users and permissions. As the chapter explains, the default user types are editor, design,  and admin, and in my experience, these three always seems to be  enough. For those who want to know about going beyond the default user types the book certainly provides more than enough information.

One somewhat confusing thing about this chapter is that at the very end of the users section the book discusses the archiver module. This module makes archives of all files and their changes across the site. It is presented in the chapter as a great tool to allow only the site admin to use, but I think it would have been better discussed in the modules chapter, or maybe the whole users and permissions chapter should have preceded modules. Oh well, there’s still been a lot of great info so far.

You can preview chapter 6 here.