Tag Archive for: Development

With content management system (CMS) comes responsibility

With Great (CMS) Power Comes Great Responsibility

One of the biggest advantages of using a content management system (CMS) is that it allows developers to empower site owners with unprecedented control of their website.

Giving website owners the ability to create, edit and manage their web property has many benefits. However, having too many features and site-management capabilities can burden the client and can wreak havoc on a website.

Read on for the five most common mistakes web developers make in an effort to empower their clients.

Mistake #1: WYSIWYG Editor Overload

What You See Is What You Get (WYSIYWG) editors (or rich-text editors) are great features to install in content management systems because they allow content creators the ability to create, edit and manage web pages without the need to know HTML.

WYSIYWG editors are so useful to end-users that you’d find most open source content management systems with it enabled by default. For example, WordPress has the Visual Editor and it’s the default content-editing view.

But is it really a good idea to let your client center text and turn it purple? Probably not. Ever been to a site with blue underlined text that wasn’t clickable? How about a company website that have hyperlinks in bolded, black text? These probably happened because they had out-of-the-box, un-customized WYSIWYG editors, which usually comes with everything but the kitchen sink.

In fact, the first thing most of our clients ask about is if they can limit how much their editors can use formatting.

Consider customizing WYSIWYG editors to only have the following:

Text Formatting

  • Heading 1
  • Heading 2
  • Heading 3
  • Heading 4 (if needed)
  • Blockquote
  • Ordered and unordered lists
  • Italics
  • Bold
  • One or two special CSS classes for emphasizing or de-emphasizing text

Web Content Elements

  • Links
  • File upload/attach
  • Images
  • Tables (with instructions to use properly on tabular data only)

Get Rid of

Below, see an example of a rich-text editor with too many options and features. It burdens the user interface and, when used improperly, can make web pages look like a Myspace page.

By configuring the CMS’s rich-text editor, content creators can have a less intimidating time composing content.

Of course, this is just a general guideline. Some project might need more and some might need less. A good practice would be to determine what’s needed and what’s not for each project instead of shortcutting the process and simply just providing the client with everything.

Mistake #2: Clients Editing CSS or HTML

A reasonably astute person with a desire to learn can edit HTML and CSS. But that’s true about anything. Just as car manufacturers don’t expect us to understand the inner workings of a car to be able to operate it, we shouldn’t expect our clients to know CSS and HTML to be able to run their website.

Like many design agencies, we tried to train our clients and their staff with HTML and CSS so that they could be fully empowered to make changes to their site. But every time, typically within a year or so, the client was so sick of it and had wasted so much time and money doing something they hated that they had us take back control of their websites.

When deploying content management systems, consider limiting access to the style sheets only to experienced professionals.

Mistake #3: Confusing “Empowered” with “Expert”

There was a recent Harvard Business Review report that talked about a number of studies that have shown that in order to be an expert at something, you need to have 10,000 hours of experience at it. It applies to chess, and music and business. It could also apply to web design and web development.

While you might have been in this industry for 5 or 10 years, your clients might only have a few hours experience as an operator of a site.

Don’t just turn over a CMS and hope that your client has enough experience to be an expert at usability and web design. Make sure you’re available for when they’re stuck.

Mistake #4: Giving Them More Than They Ask For

We’ve had a couple of clients come to us and tell us that their last web developer created a site that doesn’t do what they need it to do.

When we looked closer, we discovered that it did, in fact, do everything they needed it to do. And a lot more.

By going in, modifying the interface and removing and renaming things, we were able to create a much easier UI to use.

We know too many developers who create too many features for a project. Of course, when they put the product in front of real users, it becomes quickly obvious that it’s not user-friendly.

Mistake #5: Thinking That the Default CMS Settings Is Good

Today’s content management systems are so robust that you can pick any of the top five systems and 99% of your clients will have more features than they need.

What clients need is the ability to get their job done, and as web developers, it’s our responsibility to facilitate that. We need to make educated, experienced decisions so that our clients don’t have to. We need to help clients focus on what makes them awesome (as a person and as a company) and give them tools to leverage that.

Conclusion

As developers, we need to step up to the plate and make sure that our clients have tools that not only empower them in being able to manage the content on their site, but also empowers them to make the best use of their time.

Giving clients more choices and abilities to mess around with their website isn’t the same thing as empowering them. We might really just be hampering them and slowing them down with too many options, features and doodads.

by

HTML5 compatibility

, ,

I’m going to make a bold prediction. Long after you and I are gone, HTML will still be around. Not just in billions of archived pages from our era, but as a living, breathing entity. Too much effort, energy, and investment has gone into developing the web’s tools, protocols, and platforms for it to be abandoned lightly, if indeed at all.

Let’s stop to consider our responsibility. By an accident of history, we are associated with the development of an important tool our civilization will use to communicate for decades to come. So, when we turn our minds, idly or in earnest, to improving HTML, we must understand just how far-reaching the ramifications of today’s decisions may be.

HTML 5, the W3C’s recently redoubled effort to shape the next generation of HTML, has, over the last year or so, taken on considerable momentum. It is an enormous project, covering not simply the structure of HTML, but also parsing models, error-handling models, the DOM, algorithms for resource fetching, media content, 2D drawing, data templating, security models, page loading models, client-side data storage, and more.

There are also revisions to the structure, syntax, and semantics of HTML, some of which Lachlan Hunt covered in “A Preview of HTML 5.”

But for this article, let’s turn solely to the semantics of HTML. It’s something I’ve been interested in for many years, and something which I believe is fundamentally important to the future of HTML.

The BBC recently announced that they would drop the hCalendar microformat from their program listings, due to accessibility and usability concerns with the abbr design pattern. This demonstrates that we have, beyond any doubt, pushed the semantic capability of HTML far past what was ever intended, and indeed, what is reasonably possible with the language. We have simply run out of HTML elements and attributes with which to mark up more richly semantic documents. If we continue to be clever with the existing constructs of HTML, more problems such as this will arise. But HTML suffers from a fundamental defect as a semantic markup language—its semantics are fixed, not extensible.

This is not simply a theoretical problem. Hundreds of thousands of developers use the class and id attributes of HTML to create more richly semantic markup. (They also use them as “hooks” for CSS styling, but that’s another matter.) Almost invariably, those developers use ad hoc vocabularies—that is, values they have made up, rather than values taken from existing schemas. It’s pseudo semantic markup at best.

Many pages around the web use microformats to add more structured semantics than available in HTML’s impoverished set of elements and attributes. In this case, the values used for the class attribute come from agreed-upon vocabularies, sometimes adopted from other standards, such as vCard, sometimes from newly minted vocabularies where no solid pre-existing standard exists (as is the case for hReview).

Extensible semantics

There is a very real problem that needs to be solved here. We need mechanisms in HTML that clearly and unambiguously enable developers to add richer, more meaningful semantics—not pseudo semantics—to their markup. This is perhaps the single most pressing goal for the HTML 5 project.

But it’s not as simple as coming up with a mechanism to create richer semantics in HTML content: there are significant constraints on any solution. Perhaps the biggest one is backward compatibility. The solution can’t break the hundreds of millions of browsing devices in use today, which will continue to be used for years to come. Any solution that isn’t backward compatible won’t be widely adopted by developers for fear of excluding readers. It will quickly wither on the vine.

The solution must be forward compatible as well. Not in the sense that it must work in future browsers—that’s the responsibility of browser developers—but it must be extensible. We can’t expect any single solution we develop right now to solve all imaginable and unimaginable future semantic needs. We can develop a solution that can be extended to help meet future needs as they arise.

These two constraints in tandem, present a huge challenge. But in the context of a language whose major iterations arrive a decade apart, and whose importance as a global platform for communication is paramount, this is a challenge that must be solved.

So, how is HTML 5 addressing this issue? HTML 5 introduces a number of new elements. Some of these are what I’ve termed “structural”—section, nav, aside, header, and footer. The dialog element is a kind of content element, akin to blockquote. There are also a number of data elements, such as meter, which “represents a scalar measurement within a known range, or a fractional value; for example disk usage,” and the time element, which represents a date and/or a time.

While these elements might be useful, and seem to have generated some interest, do they really solve the problem we’ve identified, particularly within the twin constraints of forward and backward compatibility?

Let’s consider each constraint.

Backward compatibility

How do current browsers handle these new elements, such as section? Well, the most recent versions of Safari, Opera, Mozilla, and even IE7 will all render a page as follows.

<h1>Top Level Heading</h1> <section> <h1>Second Level Heading</h1> <p>this is text in a section element</p> <section> <h1>Third Level Heading</h1> </section> </section>

It looks like an excellent start. But when we try styling, for example, section elements with CSS that looks like this:

section {color: red}

…most of the above-mentioned browsers manage to style the element, but IE7 (and so presumably 6) do not.

So we have a serious backward compatibility issue with 75% of browsers currently in use. Given the half-life of Internet Explorer, we can predict that most users will be using IE6 or IE7 even several years from now.

If HTML 5 introduces these new elements, what is the likelihood they’ll be implemented by the vast majority of developers—given the knowledge that they’re essentially incompatible with the majority of browsers in use?

Unfortunately, if you are looking for alternative solutions to the CSS problem, putting class attributes on your section elements and then trying to style them using the class value won’t work in IE. Perhaps there is some kind of workaround out there, but unless there is, that looks like a deal breaker right there.

Let’s turn to forward compatibility, the second constraint.

Forward compatibility

We’ll start by posing the question: “why are we inventing these new elements?” A reasonable answer would be: “because HTML lacks semantic richness, and by adding these elements, we increase the semantic richness of HTML—that can’t be bad, can it?”

By adding these elements, we are addressing the need for greater semantic capability in HTML, but only within a narrow scope. No matter how many elements we bolt on, we will always think of more semantic goodness to add to HTML. And so, having added as many new elements as we like, we still won’t have solved the problem. We don’t need to add specific terms to the vocabulary of HTML, we need to add a mechanism that allows semantic richness to be added to a document as required. In technical terms, we need to make HTML extensible. HTML 5 proposes no mechanism for extensibility.

HTML 5, therefore, implements a feature that breaks a sizable percentage of current browsers, and doesn’t really allow us to add richer semantics to the language at all.

Several questions remain about the new elements. Where have these new element names come from? How was it decided that there should be a navigation element, and that it should be called “nav”? Why should the same term apply to page-level, site-level, and meta-site-level navigation?

Why not adopt an existing vocabulary, such as Docbook? Its document structure vocabulary is far richer and it’s been developed by publishing experts over many years. This is not an argument in favor of Docbook, specifically: the point is that the extremely important task of providing a mechanism for semantic richness in HTML is being approached in an ad hoc way, paying apparently little attention to best practices in related work going back 30 years or more. (The original work on GML began in the early 1970s.)

Some thoughts on a solution

So, having been critical of current efforts, do I have any practical suggestions on how to solve this problem? Well, I have the start of one.

If adding elements to HTML is out of the question, at least within the parameters of this discussion, attributes are the other logical area of HTML to concentrate on. After all, for nearly a decade, we’ve been using class and id attributes as mechanisms to extend the semantics of HTML. A great many developers are familiar and comfortable with this. The microformats project demonstrated that the existing attributes of HTML are not sufficient, as a generalized mechanism, to extend the semantics of HTML. So, if we are to use attributes to help solve this problem, we need to come up with one or more new attributes. Before we get into the mechanics of how that might work, it’s only fair to subject this suggestion to the same requirements we have for the new elements of HTML 5. Most importantly, is introducing new attributes to HTML backward compatible? And if so, does it provide a workable mechanism for semantic extensibility in HTML?

Let’s invent a new attribute. I’ll call it “structure,” but the particular name isn’t important. We can use it like this:

<div structure="header">

Let’s see how our browsers fare with this.

Of course, all our browsers will style this element with CSS.

div {color: red}

But how about this?

div[structure] {font-weight: bold}

In fact, almost all browsers, including IE7, style the div with an attribute of structure, even if there is no such thing as the structure attribute! Sadly, our luck runs out there, as IE6 does not. But we can use the attribute in HTML and have all existing browsers recognize it. We can even use CSS to style our HTML using the attribute in all modern browsers. And, if we want a workaround for older browsers, we can add a class value to the element for styling. Compare this with the HTML 5 solution, which adds new elements that cannot be styled in Internet Explorer 6 or 7 and you’ll see that this is definitely a more backward-compatible solution.

Extensibility through attributes

Instead of new elements, HTML 5 should adopt a number of new attributes. Each of these attributes would relate to a category or type of semantics. For example, as I’ve detailed in another article, HTML includes structural semantics, rhetorical semantics, role semantics (adopted from XHTML), and other classes or categories of semantics.

These new attributes could then be used much as the class attribute is used: to attach to an element semantics that describe the nature of the element, or to add metadata about the element.

This is not dissimilar to the role attribute of XHTML, but rather than having a single attribute “bucket” for all element semantics, we should identify the different types of semantics for an element, and separate them out.

For example, the XHTML role attribute works like this:

<ul role="navigation sitemap"> <li href="downloads">Downloads</li> <li href="docs">Documentation</li> <li href="news">News</li> </ul>

The values of the role attribute are a space-separated list of words from the default vocabulary, or from a defined vocabulary.

Why not simply adopt the role attribute as-is? Well, there are other kinds of semantics for which the term role doesn’t apply. For example:

<p rhetoric="irony">He’s a fantastic person.</p>

This demonstrates a theoretical type of semantics—“rhetoric,” which could be used to markup the rhetorical nature of a document. This element clearly doesn’t play the role of irony in the document. Rather, the contents of the element are ironic.

Here is another example. It’s increasingly obvious that HTML lacks a way to attach a machine readable version of a humanly readable value, e.g., a date. This is at the heart of the problem the BBC has with the hCalendar microformat that we referred to earlier. While <span role="2009-05-01">May Day next year</span> really doesn’t make sense, something along the lines of <span equivalent="2009-05-01">May Day next year</span> would.

Again, whether we use the specific term “equivalent” or some other term for this kind of semantic attribute is not the issue. What’s important to note is that it’s not as simple as using either the class attribute or the role attribute as a one-size-fits-all bucket to hold semantic information. For a properly extensible solution that provides backward compatibility and sufficient flexibility, a solution along these lines looks worth investigating.

I titled this section “some thoughts on a solution” because a significant amount of work needs to be done to really develop a workable solution. Open questions include the following.

  • How many distinct semantic attributes should there be? Should these categories be extensible, and if so, how?
  • How are vocabularies determined?
  • Do we simply invent the terms we want, in much the same way that developers have been using class values, or should the possible values all be determined by a standardized specification? Or should there be a mechanism for inventing (and hopefully sharing) vocabularies, using some kind of profile?
  • If we have a conflict between two vocabularies, such that two identical terms are defined by two different vocabularies, how is this resolved?
  • Do we need a form of name spacing, or does some other mechanism exist?

Rather than rushing to answer these questions, I’m posing them to highlight the issues that need to be addressed, and to start a dialog. The ramifications and reach of decisions made in HTML 5 are too great for decisions to be made in the absence of at least some input from those highly knowledgeable about linguistics, semantics, semiotics, and related fields.

Hopefully, if nothing else, then it’s clear that simply “making up new elements” isn’t a solution to how to increase the semantic capacity of HTML.

Let’s not rush into these decisions lightly—after all, with climate change we’ve saddled our grandkids with enough trouble as it is. Let’s at least leave them the best possible HTML we can.

by

Slim and sexy style sheets

,

When it comes to conservative code, CSS files usually get the short end of the stick. Grabbing all of the presentation and layout information from the HTML and dumping it in the CSS has finally become a standard process for most designers. (If it isn’t yet, make it yours.) While this is the exact purpose of a style sheet, there are plenty of methods by which a designer can make sure that the CSS that loads for every page is, like the HTML, as clean and concise as possible.

CSS as a Process

For many designers, the process of building a style sheet consists of starting with the outer containers of the HTML structure and working their way in, aligning and styling as they go. How many times have you sized and centered your #wrapper element, and then moved onto aligning the logo and primary navigation in the <header>, and then continued your way down the page? This process certainly works, but there is a much better and quicker way to handle CSS. Much as we did with the HTML, we can recycle code and use a modular approach in a way that makes more sense and takes less time.

Instead of designing a style sheet with the HTML in mind, we should carry over our mindset from the rest of the design process, putting the user first. In our new and improved CSS process, let’s start with the most important and prevalent elements of our design. These will almost always be the content. The whole point of delivering clean and semantic code is to ensure that no matter what the screen, device or context of our visitor, they will have access to the fantastic message that our website is trying to convey. For this reason, we’ll start the primary portion of our style sheet with the typography.

01 body, select, input, textarea {
02     font: normal .825em/1.25em Tahoma, Geneva, sans-serif;
03     color: #353838;
04 }
05 h1, h2, h3, h4 {
06   font-family: Georgia, "Times New Roman", Times, serif;
07   color: #202020;
08 }
09 h1, h2 {
10   font-size: 1.875em;
11 }
12 h2 {
13   text-align: center;
14   font-weight: bold;
15   line-height: 1.5em;
16   border-bottom: 4px solid #e5e5e5;
17   -webkit-box-shadow: 0 1px 0 #b2c6e1;
18    -moz-box-shadow: 0 1px 0 #b2c6e1;
19       box-shadow: 0 1px 0 #b2c6e1;
20   margin: 1em 1.25em;
21 }
22 h3, h4 {
23   font-size: 1.25em;
24   margin: .75em;
25 }

When it comes to text, we start with the most global rules and get more specific as we move down the style sheet, a pattern that should be repeated for other portions of the website.

Because typography is usually the most heavily used element on a website, it stands to reason that we should define our core font rules on a high-level element, such as the <body> element. If we want different typographic rules for headlines or certain page elements, we can declare them just after the default settings. If you have trouble figuring out which typographic declarations to add to your high-level selector and which to use as overrides, simply mark them all up and then identify which are the most common. Apply the most common declarations to the high-level element, and build specificity as you go forward.

With the typography set and the HTML structure solid, we have a website that could technically be delivered as a functional product to any device or browser. Anything we do from this point on should be to enhance the user’s experience.

For many designers, enhancing the experience starts with coloring the page. After typography, the color palette is arguably the element that most affects a website, and therefore should be next in the style sheet. I find that a good color palette is ingrained in every level of a design, and that breaking colors out into a separate section of the CSS leads to a lot of extra lines of code and a lot of selectors that are used solely for color but that have twins throughout the style sheet serving other purposes. I am not a fan of branching a single selector into different bits for the sake of lining up declarations. However, neither method is inherently good or bad. Find a system that works best for you, and maintain consistency across the project.

Finally, we get to the structure and layout of the website. With wonderful typography and eye-catching colors sprinkled throughout our website, we can line things up the way they should be and in a way that makes the website easy to read, navigate and interact with. We can continue with the method we adopted for the typography, putting the general rules first and then getting into the details later on. One thing that will hold us back is the lack of a hierarchy in HTML for anything other than typography.

Looking at the elements included in HTML4, the specification was clearly not prepared to support the complex layouts that designers and clients demand today. We had six levels of importance for headlines, but only abstract elements like <div> and <span> for structure, with no way to indicate hierarchy. HTML5 has gotten us closer, but we aren’t there yet. To make up for this, let’s look to the global class structure that we started implementing in our HTML earlier. We used the .contentContainer class to define the areas of our website that will be visual containers for our content. This class gives us the power to style a big portion of our website quickly and allows us to easily add new containers later without having to force them to fit the style of our website using CSS.

1 header, footer, .contentContainer {
2     background: #f1f1f1;
3     -webkit-box-shadow: 0 0 15px rgba(0, 0, 0, 0.25);
4       -moz-box-shadow: 0 0 15px rgba(0, 0, 0, 0.25);
5         box-shadow: 0 0 15px rgba(0, 0, 0, 0.25);
6     border-radius: 3px;
7 }

Reduce, Reuse, Recycle

Much like with HTML, style sheets can get pretty funky when we get to the point of adding and removing individual declarations in order to get an element to look or behave the way we want. The gracious way in which Web browsers handle CSS rules that they don’t understand or don’t need makes this practice rather common, thus bloating our style sheets. For this reason, go back through the style sheet at the end of the day and remove any rules that no longer serve a purpose. The task is a painstaking one, but as with most such tasks, plenty of tools exist to help us along.

Another task that can save size and space is to group selectors that have the same set of style declarations. From a technical standpoint, it makes sense to create a group of selectors whenever two or more share at least one declaration. I love to take advantage of grouping selectors by using something I call CSS effects. With some of the new CSS3 declarations, I’ve found that I can move the layer styles that I copy and paste in Photoshop right into my style sheets.

1 .mainBox, .secondaryBox, .footerBox {
2     background-image: -moz-linear-gradient(rgba(0, 0, 0, 0.3), rgba(0, 0, 0, 0));
3     background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(rgba(0, 0, 0, 0.3)), to(rgba(0, 0, 0, 0)));
4     background-image: -webkit-linear-gradient(rgba(0, 0, 0, 0.3), rgba(0, 0, 0, 0));
5     background-image: -o-linear-gradient(rgba(0, 0, 0, 0.3)), to(rgba(0, 0, 0, 0));
6     background-image: -ms-linear-gradient(rgba(0, 0, 0, 0.3)), to(rgba(0, 0, 0, 0));
7     background-repeat: no-repeat;
8     border: 5px solid rgba(0, 0, 0, 0.2);
9 }

We can apply this declaration stack to any element on our page to achieve a gradient. The use of RGBa allows us to retain the background colors of individual elements and to “outsource” the gradient style to a common selector.

CSSeffects in The Neglected Necessities Of Design

When combined with healthy HTML practices, spending more time on the essential pieces of solid Web design results not only in faster pages and a lighter server load but, more importantly, in a user experience that thrives on any platform regardless of the design method employed. Speaking of user experience, we still need to add one important piece to this puzzle.

by

Lessons from mobile web design

, , , , ,

Mobile development is all the rage, and the interactive industry is in great turmoil as countless tablets and smartphones come to market.

Mobile app development gets most of the attention, while the mobile web somewhat quietly creeps along. But the mobile web is making progress every day as more and more developers launch mobile-optimized interfaces.

The great thing about the mobile web is that it is fundamentally built with all of the same tools used in traditional web design and development.

This makes it far more approachable than app development. Also, many users will want to visit a company’s website on the go, without necessarily needing a full-blown app.

Building websites optimized for mobile is so similar yet so different then designing for the desktop. Certain factors take on a far more significant role. For example, screen size variations, user attention spans and usability issues are more critical then ever.

These same issues are ever present on the desktop but are sometimes easier to overlook. Here we’ll look at some lessons to learn from the optimization that is happening on the mobile web. The lessons can directly inform how we design and how we think about traditional web design and website architecture.

 

Simplified navigation on mobile websites

One of the first things that becomes evident when digging into mobile websites is the extreme simplification of the navigation. Navigation not only becomes very prominent and central on a mobile website, but is also quite often trimmed down substantially to focus on only the most critical elements.

I find it amazing how top-level navigation can be boiled down to two to four items on most mobile websites. Of course, I recognize that the content on a mobile website is quite often optimized for the intended audience. For example, Truth Tabernacle Church has six options in its main navigation, only one of which has made it into the navigation for the mobile version; and the one that made it (“Contact”) is the focus of the entire home page.

The content that didn’t make it into the mobile version is, of course, still entirely relevant. The mobile interface is intended to catch people trying to find the church or check out the service times or simply contact them. These are the most likely objectives of the mobile surfer. Those hitting the full website on a desktop computer are as likely to want those things as they are to want to research the church to see whether it is the sort of place they would like to visit.

So, what is the lesson to learn? Don’t these two interfaces target totally different audiences and have totally different purposes? Perhaps, but we can learn a lot from the extreme focus of the mobile interface. Notice how everything is about the actions you can take? The church has eliminated all of the navigation elements that feel like boxes to check off.

One interesting element is the “About” navigation option on the full website. The mobile website may be optimized for people on the go, but there is no reason to assume that they wouldn’t be interested in reading about the church and its beliefs. Someone may have mentioned the church to you in passing, prompting you to look it up on your phone.

So, the navigation option for this element should be changed. What if, instead, it communicated something like, “What you should know about us”? While a bit long, it reflects a more helpful attitude. A general “About” bucket feels like a place to hold all of the information that no one reads. “A visitor’s guide to our church” feels a lot more useful and targeted.

The simplicity and focus of the mobile interface shows that everything must have a purpose to earn a slot on the website. If the same were true of the full website, we would be less inclined to fill it with seemingly important content and more inclined to make sure everything has a clear function.

This reflects a very task-oriented mentality. Every option challenges the user to take some active step. It is as though every passive option has been purged and reduced to actionable items on the mobile website. This leads us to the next lesson: be extremely task-oriented.

 

Mobile websites are task-oriented

With a task-oriented mindset, let’s reconsider the full website. While the home page is beautifully designed, the call to action is far less evident. The content is full of bits of information waiting for you to decide to be interested.

For example, the large banner highlighting a coming event fails to call me to some kind of action; very passive. With a task-oriented mentality, we could vastly improve on the “Read more” call to action. This could be as simple as making the call to action much more prominent; for example, a large button in a contrasting orange. Additionally, the call could be changed to “Learn more and sign up.”

Another example is the welcome message. I appreciate the intention and the message being communicated here. The message shows that real people are behind the website, and it attempts to make the page feel personal. But again, let’s dissect this with a task-oriented mentality. A great follow-up to an introduction like this would be a clear call to action encouraging visitors to take the next step. After all, the only people who will be reading this are newcomers. Current members will skip right past this to things like the event calendar. So, offer a conversion point for users, like “Ask us a hard question” or “What to expect when you visit.”

By contrast, the “Special guest” box is fantastic. It addresses key issues and drives people to dig deeper. I only wonder whether it could be a more prominent element of the page. Again, members will get to where they need to go; so focusing on those who are new to the website and the church would go a long way to maximizing the opportunity.

I know I am really beating this website up, but it is not because I dislike it or think that it doesn’t serve its function. My goal is only to challenge our thinking and our preconceived notions of what a website should look like and do. I actually commend this church for having a beautiful and functional website, with a mobile extension to boot!

 

Mobile websites dramatically shrink their content

Another obvious lesson related to paring down the navigation is that mobile websites invariably shrink their content. Not only are the number of options reduced to the core functionality and purpose of the website, but the copy is vastly reduced, too.

In some cases, much of the copy is eliminated entirely! This begs the question, is this content necessary on the full website if the mobile version functions well without it? Divi Aruba is a great example of this. The alluring marketing speak laid overtop the photo might seem like a must-have element for the home page, but it has been nuked on the micro mobile website.

On the mobile version, the logo is placed on top of the same image, and yet it still conveys the exact same message: if you want to go some place like this, read on. Why not use this prominent spot to drive people to the desired action? Surely the designers know what is the most critical element for converting visitors to customers. Put this information to work, and drive people there with a prominent call to action instead of fluffy marketing speak.

 

All the good stuff, sans fluff

This leads us to the next lesson: lose the fluff. The next example is a positive demonstration of this. Travel Tex is a travel information website for the state of Texas. It has a clear purpose and audience in mind. Fortunately, the designers have fully embraced the fluffy-less mindset.

Not only does the mini mobile website focus entirely on the topic at hand and the key actionable items, but so does the full website! What a relief to see almost no fluff at all. Including something dreary like a history of Texas would be all too tempting. If people wanted a history lesson, they wouldn’t come this website. You will be hard pressed to find content that is not relevant to this website’s singular purpose.

Get into the habit of questioning everything. This is the only way to really boil a website down to its critical elements, which is exactly what happens on a good mobile website. Tough choices are made and otherwise valuable content is cut in order to streamline the website. Call fluff for what it is and nuke it!

 

Branding is king on the mobile web

I am all about creativity on the web. In fact, many of the greatest changes in the industry have come about as a result of a refusal to stick to the status quo. But there is a time and place for everything. So many designers use their assignments as an excuse to release their creative juices, for no other purpose than to do something creative. This turns the website into a design for the designer, not for the client and their needs. This is one thing the mobile web warns against rather boldly.

Branding is incredibly consistent on the mobile web, and one of the most consistent parts is the placement of the logo. On mobile websites, you won’t find any crazy logos at the bottom with fixed footers. Functionality is king, and logos always appear at the top. Can you imagine hitting a mobile website and not seeing the logo right away? Yet this is commonplace on many full websites.

Here are a few websites that, while minimal and lacking in mind-blowing style, are rich in branding that can’t be missed.

The lesson here can have a profound impact on how you approach your work and on the fundamental value you pose to your clients. For every designer who figures out that the client’s needs should be their entire purpose for the project, there is another who wants to show the world how creative and original they are.

Like anyone else involved in the production of a website, the web designer should be single-minded in serving the client, helping their business and improving the bottom line. With every element you put on a mobile website, considers its role and the benefit it will bring. Apply this mentality to everything you do, and you will soon find a strong ally in your client.

The more we embrace the needs of the client and do everything we can to bring value to their website, the more we will see a fundamental shift in our work. We will go from building “cool stuff” to looking at everything from the client’s perspective. Does this feature stand to increase their profit? How can the design be changed to improve their business? If a byproduct of your work is more money for the client, then you will find opportunity everywhere.

 

Websites without the gimmicks

One of the greatest achievements of the mobile web is the total lack of gimmicks. To be fair, there is a time and place for gimmicks on the web. In fact, I dedicate whole sections of my books to them. But the lack of gimmicks on mobile websites demonstrates that these seemingly great ideas serve no real purpose.

Everything that goes on a mobile website should go through several filters. Is the content relevant and utterly useful? Is the content critical, and does it serve the core purpose of the website? Is the website easy to use and understand? Is the navigation unconventional? If so, is it critical to the function of the website? The answer may well be yes, but more often than not, it will be a decisive no.

Some gimmicks that are noticeably absent from mobile development are splash screens, unusual navigation, meaningless animations and interactivity, inline scrolling regions, odd layouts and fixed-width layouts. The efficiency of the mobile web is amazing.

 

Conclusion

As you can see, we have a number of lessons to learn from the mobile web; particularly, its ability to reveal unnecessary elements of a website. As with many things in life, a slight change in perspective often opens our eyes to the true value of things we have long taken for granted.

I am not suggesting that we have lost sight of the purpose of the web. Rather, I am proposing that we adopt a far more strategic mentality.

by

Lessons Mark Zuckerberg taught us about business

, ,

You don’t get to 600 million friends without doing something spectacular. Mark Zuckerberg knows this more than anyone. But I wonder: do we have any hope of achieving similar success?

Facebook’s story begins, like most businesses, with a single idea and an ambitious person that executes it. Zuckerberg wasn’t a world-class genius, and Facebook was hardly a revolutionary idea. Yet here we stand: Facebook is one of the most valuable websites on the Internet, Zuckerberg is one of the world’s youngest billionaires, and MySpace… let’s not pick on them.

There wasn’t any magic, fate, or destiny at play here — anyone could’ve been in Zuckerberg’s position. However, just because anyone on this planet has the potential to achieve success, doesn’t mean that anyone else actually will.

There are factors at play: things like leadership, experience, timing, funding, and execution play their roles. But some things will always stand out above the rest, and many of the factors that really make a difference will never be taught at an ordinary business school. So let’s steal a few pages from Mark Zuckerberg’s school of business.

Lesson 1: Be passionate about what you do

If there is any way to create something that hundreds, thousands, or even millions of people will eventually use on a daily basis, you better be sure to create something that you would have passion and dedication in creating.

The aforementioned isn’t exactly a revelation to anyone, but if you are not genuinely interested in what you are creating, why would anyone else be? They wouldn’t. It’s a serious problem for many entrepreneurs of both young and old.

Lately we have seen entrepreneurs creating this businesses that some have little interest in actually investing their heart and soul into. Some of these startups look great on paper, but, in the end, the whole intention is to quickly flip these businesses to a company that has plenty of cash on hand. The investors, founders, and, if they’re lucky, employees get rich and everyone goes out for drinks to celebrate. If this is the measure of success, it is no wonder why we hear so much discussion about a potential tech bubble.

Mark Zuckerberg, however, is one of the most prominent examples in recent history of someone who has the passion. Not only did he care about his project, but he also turned down billions of dollars in order to let his company thrive. Turning away billions of dollars, and the opportunity to never have to work again, can’t be that difficult. Can it?

But the reality is that you, me, everyone needs to be reminded every once in a while that having a dedication and passion for what we do in life is key to happiness.

Lesson 2: Constant evaluation

There are generally two types of people in business: those who prefer to play it by gut instinct and those who analyze every little measurable detail. Both have their pros and cons; having a mix of both couldn’t hurt. Generally a person gravitates towards one or the other.

Mark Zuckerberg is the analyzer.

Zuckerberg always insisted that his employees create powerful analytics dashboards. Their purpose was simple: allow him and fellow employees to gauge the interest in newly released features to coordinate their global domination. While other companies were still figuring out which advertisements could be placed at which spot and generate the most return, Facebook focused on optimizing the performance of the user experience. He wanted to know which features worked and which did not.

Those who can gather enough data to garner an understanding of their users, while also being able to determine which features work and which do not, will ultimately be in a better position to achieve success.

The takeaway: do anything in your power (within reason, of course) to find ways to measure success and failure across the board, but don’t get so caught up in the data that you are unwilling to explore new avenues.

Lesson 3: Be willing to experiment

In Facebook’s infancy, its founder preferred to push out enhancements and never look back. This is, admittedly, easy to do when you have a few thousand users; they expect things to change at a rapid clip. But Facebook was different. People relied on Facebook in more ways than most other websites — it was a service that connected people to each other. At this point, failure is unacceptable.

Still, Zuckerberg preferred the gung ho method of development. He would regularly introduce new features — adding the “Wall,” introducing chat functionality, allowing third-party development, and changing the site’s layout (which I have had numerous complaints about before).

One has to admire the company’s insistence on pushing out features in a world where critical services tend to iterate slowly and safely (think Microsoft Windows). This insured that Facebook was a step ahead of the competition while also appearing innovative amidst growing competition.

Sure, there were those who didn’t appreciate these drastic changes (especially those dealing with privacy settings and layout), but when you have a vision, sometimes it pays to put in the extra effort and take the risk; explore it through to the end.

Lesson 4: Be aware of opportunity

Before Facebook, there was CourseMatch, an application that allowed students at Harvard University to compare their course selections for that semester. With this, Zuckerberg indulged students’ desires to know which classes their friends were joining. He exploited an opportunity.

Facemash was a similar expereince. It was Harvard’s Hot or Not for students. These students were interested in knowing where they stood socially — in some ways, we all do. And Zuckerberg, once again, saw an opportunity to exploit this as well.

Facebook was simply a culmination of all these previous opportunities into a single useful package.

It isn’t magic. But it does require looking at things in a different way — to see things for what they could be, as opposed to only what they have been or currently are. Zuckerberg’s ability to notice these opportunities and execute on them gave him the edge in creating and maintaining products that people believed in.

Opportunity exists everywhere — especially with the Internet, where the ability to reach millions is easier than ever. Perhaps there is so much opportunity out there that, perhaps, we have become ignorant to spot the most obvious of opportunities. But being able to spot opportunity is an invaluable skill.

Lesson 5: Make something useful

Facebook isn’t simply another interesting website to visit every once in a while. It is a tool that millions of people use to connect to each other. People use it for sharing experiences and creating new ones. Most importantly, Facebook does something that no other website has been able to do as efficiently, effectively, and with such impressive scale: it creates a virtual environment to interact with your real friends.

I don’t think it is necessary for me to explain how useful something like this is; the 600 million plus members does that well enough. Yet it is this usefulness that makes the company a success. It is a recurring theme that all successful companies build upon. It is also something that many startups don’t seem to comprehend.

If you want the best business advice out there, here it is: create something useful.

Explaining what makes a product or service useful is simple: it is something that people are using repeatedly and on a regular basis. Make something that you and others could use on a regular basis, and make this thing unique. If you do this, along with everything else mentioned here, you will have an opportunity to create and maintain a successful business.

And who knows? Maybe you will be the one creating the next Facebook killer.

by

Is Facebook temporary?

,

Last week, the most prestigious investment bank in the world, Goldman Sachs, decided to invest almost 2 billion dollars in the social network Facebook (a mix of its own and its clients capital), which on paper made the six year old startup worth $50,000,000,000.

Yes, a social networking site is now worth $50 Billion Dollars. With a B.

The recent frenzy around the Goldman Sachs investment as well as the selling of private shares has been a sight to see: everyone wants in on the action. To the casual observer Facebook can do no wrong, they are still growing strong and everyone seems to want in on it.

But, if you’ve ever been a part of an online social network, you might be wondering…what happens when all the cool kids leave and nobody goes there anymore? It has happened with all of them so far, from the online BBSes of the 80s right up to Facebook’s predecessor MySpace, which while still having millions of users is doing poorly financially and has lost its cool edge.

Douglas Rushkoff, who has witnessed and chronicled the rise of the Web as well as anybody, thinks that the recent investment is actually a signal that Facebook has reached its zenith, and will soon join the ranks of all the other “been there, done that” social networks. In Facebook Hype will Fade, he lays out his argument:

Rushkoff writes:

“Appearances can be deceiving. In fact, as I read the situation, we are witnessing the beginning of the end of Facebook. These aren’t the symptoms of a company that is winning, but one that is cashing out.

The object of the game, for any one of these ultimately temporary social networks, is to create the illusion that it is different, permanent, invincible and too big to fail. And to be sure, Facebook has gone about as far as any of them has at creating that illusion.

If you were there for Compuserve, AOL, Tripod, Friendster, Orkut, MySpace or LinkedIn, you might have believed the same thing about any one of those social networks. Remember when those CD Roms from AOL came in the mail almost every day? The company was considered ubiquitous, invincible. Former AOL CEO Steve Case was no less a genius than Mark Zuckerberg.

Yet social media is itself as temporary as any social gathering, nightclub or party. It’s the people that matter, not the venue. So when the trend leaders of one social niche or another decide the place everyone is socializing has lost its luster or, more important, its exclusivity, they move on to the next one, taking their followers with them. (Facebook’s successor will no doubt provide an easy “migration utility” through which you can bring all your so-called friends with you, if you even want to.)

We will move on, just as we did from the chat rooms of AOL, without even looking back. When the place is as ethereal as a website, our allegiance is much more abstract than it is to a local pub or gym. We don’t live there, we don’t know the owner, and we are all the more ready to be incensed by the latest change to a privacy policy, or to learn that every one of our social connections has been sold to the highest corporate bidder.

So it’s not that MySpace lost and Facebook won. It’s that MySpace won first, and Facebook won next. They’ll go down in the same order.”

Rushkoff’s argument is that Facebook is merely the latest in a long line of social networks that have risen and fallen…he sees no reason why Facebook (albeit the biggest ever) is no different.

In the long term I definitely agree with Rushkoff…Facebook has a lifecycle just like everything else. But short-term we can identify several factors that will influence how fast Facebook loses its mojo:

Social Graph Export

Once we have our friends identified and connected with, a service becomes more valuable because we don’t have to go anywhere to find them. Facebook is betting that by owning the social graph (and making it difficult to export) they will have you locked into the service long-term. So far this seems to be the case, but if other social networks can use the current export tools to recreate the social graph and add valuable data on top of it, then they could start stealing user’s attention away from the service.

The Loss of Exclusivity

But there also comes a point when we’ve connected with so many people in one spot that that spot loses its exclusivity…it’s not special to be there anymore. This is the point that Rushkoff is making…equating social networks with social hotspots like gyms or clubs, whose popularity ebbs and flows with some sort of cool factor. This is a natural change that will inevitably occur…it already feels like Facebook is not cool anymore.

The Value of Niche Networks

For some time now we’ve seen other, niche social networks grow slowly into real communities. Sites like Ravelry, PatientsLikeMe, Dribbble, and others focus on supporting a specific activity and by doing so serve their audiences better than an all-encompassing social network like Facebook can. As more and more niche networks mature, they’ll increasingly steal attention away from Facebook.

A Return to Identity

Design-wise, it’s well known that Facebook is the yang to MySpace’s yin. Where MySpace let users customize their page in any way they wanted, Facebook has very little customization options at all. We’re seeing the rise of personal identity sites like flavors.me and about.me fill that gap…it will be interesting to see what sort of adoption those identity sites get going forward. So far they’re growing quickly.

In the meantime, Facebook is the current social network juggernaut now worth 50 billion dollars and they seem to have all the momentum in the world. The question is…is Facebook bound by the same laws of physics as everyone else?

by

Usability testing. How to?

, , ,

Many designers come to me for usability testing consulting services. One of the reasons they reach out is because they assume usability testing must be a complex, scientific process. As a result, they’d prefer to have an outside company conduct their usability tests.

Then I tell them I rarely run usability tests anymore! Why? Well, in my experience the best way to do usability studies is to do it yourself. So I spend a lot of time helping teams do learn how to do it themselves, not doing it for them. By conducting their own quick and dirty usability studies, design teams can get feedback faster, easier, and more affordably than hiring an outside professional.

Usability Testing Is Not a Complicated Process

The first thing I tell designers is that it’s a mistake to think that usability testing has to be complicated. It’s a technique anyone can learn with a little training and a lot of practice. Usability testing isn’t rocket science, but it does need to be integrated into a design team’s overall process in order to work.

I’ve found that the most successful teams learn to conduct their own informal testing whenever they can without waiting for the usability team’s availability. In the most successful projects, the team has a design idea, they quickly sketch it and create a prototype, and then test it as quickly as possible.

When I work with design teams who have never conducted a study, I teach them the basics of usability testing, have them observe me facilitate one or two sessions, and then they try it on their own with my guidance. After a few of these sessions, these usability “newbies” are usually ready to run their own testing sessions.

Usability Professionals Act as the Coaches

So what’s the role of the usability professional? In most mid-to-large-sized corporations, there are too many design projects for one person—sometimes even an entire usability team—to run all of the usability studies the design teams need.

As a result, the usability professional is most successful as a Coach who educates and advises the organization on which projects to focus on, how to plan and run their studies, and how to analyze the results. They can better serve design teams by sharing best practices for conducting usability tests, interviews, field studies, diary studies, and other research techniques.

How Can Design Teams Start Testing On Their Own?

If you’ve never conducted a test, start right away. Try a test next week; it’s not as complicated as it may seem. At its core, a usability test involves putting a person in front of your product and watching what they do. Your goal is not to implement the scientific method as you elaborately lay out a treatise on the usability of your product – just to observe how well users can accomplish their desired tasks with it.

Time and time again I’ve seen immediate results from such an approach. Learning how to run internal usability tests will not only save a company money, but will instill a “design for usability” mentality into your design team and, hopefully, the organization as a whole.

So instead of hiring an outside professional to do usability testing for you, try to find one who will act as your coach and guide instead. In no time you’ll be up and running with a regular testing plan that will benefit you far longer than the immediate project. Your design team will be more self-sufficient as a result.

by