Dining in the Dark

Posted on April 25, 2012 by Adrian Roselli

This post originally appeared on my blog on Wednesday, April 25, 2012.

A blindfolded photo attempt of my meal, served and eaten in near darkness. Thankfully it turns out that my aim with my fork was better than my aim with my cellphone camera.

Two weeks ago our longtime client Olmsted Center for Sight (formerly the lengthily-named Elizabeth Pierce Olmsted, M.D. Center for the Visually Impaired) held a benefit dinner titled “Dining in the Dark.” The concept was quite simple and given away by its name — attendees would enjoy a meal in total darkness. Not only did my company co-sponsor the event, I attended it and had the pleasure of dining with Olmsted’s president.

The meal started off with wine and salad, which you were allowed to eat in light. Then we were presented with bibs and blindfolds, and the lighting was turned down to just the candles on the table (the servers needed to see, after all). And so in darkness we set upon the main course followed by the dessert course and wrapped up with coffee service. During the main course an Olmsted representative guided us through techniques to get the lay of the land, identify foods, cut meat, find drinks and so on. I ignored all this and dove in with my characteristic nonchalance about my meal and found myself stymied by the simplest things — it takes a couple tries to realize your knife is upside down and that you are cutting with the blunt edge and not the sharp edge.

I have spent over a decade working with Olmsted Center for Sight. I have had the opportunity to see how its clientele/constituency uses computers and surfs the web. I have attended seminars, spoken at events, been a part of lawmaking discussions, implemented software and web sites, all in my time consulting with Olmsted. I have been working with low-vision and blind users for most of my professional career, but nearly always in the form of technology. Though I had some time running concerts for thousands of attendees and making sure outdoor and non-standard venues were handicapped accessible, this dinner afforded the chance for me to experience some of the day-to-day tasks that I take for granted, but this time without sight.

This post may seem to be a little outside of my generally technical discussions here, but I believe that experiences like this are important for anybody who cares about inclusive design or accessibility. Some day everyone reading this will have reduced vision, mobility, hearing, and so on. Learning now how to design and build to support those changes serves to position future generations of developers to design and build to support the future you. That’s just a good investment in your long term well-being.

Consider spending an hour blindfolded and try to do a mundane task like get dressed, eat a meal, or even use the web to look up a menu on a web site (you’ve already seen me rant about how awful that experience is for average users). Consider limiting your movement, restricting yourself to a chair, putting in earplugs, and so on. You may find your get far more insight into daily life as well as software and web development than you expected.

If you’re still reading and also care about accessibility, then in keeping with the low vision theme of this post here are some resources to use when developing sites for the blind. This is not an exhaustive list by any means, but there are links to many others within.

Screen reader demos, research and resources by Alistair Duggin. Written the day after my dinner.
Web Accessibility Toolbar 2012 from The Paciello Group. A handy resource to validate and review any page you are viewing.
The NonVisual Desktop Access (NVDA) screen reader (MS WIndows) is a free resource (for which you should donate) that can help you understand how a site is “heard” by a blind user.

This handy video shows you how blind people use the iPhone 4S. It’s worth a couple minutes of your time.

This link isn’t a resource, instead it’s a story of a police department using its forensic techniques to help save 26 pages of hand-written content after the blind writer’s pen ran out of ink.

Updating My Web Site? Yeah, I’ve Been Meaning To Get To That…

Posted on April 11, 2012 by Thomas Garigen

I’ve been wondering – how many people out there would remember to check the batteries in their smoke detectors if it weren’t for daylight savings time?

Every six months, I spend a minute or two on a Saturday night trying to remember if I gain or lose an hour that weekend. Shortly after figuring out if I’m jumping ahead or falling back this time around, I inevitably hear my dad’s voice in the back of my head saying, “Every time you change the clocks, make sure you also remember to change your smoke detector batteries.” Day-to-day family life is pretty crazy for me these days, so I’m not 100% certain I would remember to change those batteries if my dad hadn’t hammered it into my head for years. And I’m glad I remember, because my family and my house are pretty important to me!

While I’m willing to bet most people would agree with the idea that if you run a business of any kind these days, you need a web site. But the time frame for how often you need to update (or outright change) your web site is probably far less agreed upon than say, how often you need to change the batteries in your smoke detectors. Most people might argue you should mix things up every two to three years, but I’ll bet there are some who would say you can go longer.

At the risk of sounding like my mother, technology is hard to keep up with. What’s new and fresh today will be old news in a short period of time. The truth is, if your web site is more than two years old and you are not planning to update it, or the technology it rests on, you’re probably behind the times (and your competition). For example, if your site doesn’t automatically adjust when it’s viewed on a cell phone or tablet, what are you waiting for? Your site won’t develop a mobile-friendly version of itself. How about an even more basic question – are you still sending content changes and updates to your web vendor or “tech guy” instead of using a quality CMS in-house? Well, guess what? You’re essentially hoping the smell of smoke will get you out of bed late at night, because you’ve neglected your smoke detector maintenance.

Regardless of how long you think you can go without paying it some attention, the sales call to see if you are ready to update your web site should be viewed like daylight savings. It’s a subtle reminder, me calling to say “Hey, Busy Person! Don’t forget about this important part of your business.” When you get the call, even if you aren’t ready to deal with it then and there, ask me to call you back on a specific date in the future (sooner, rather than later) and put that call on your schedule now. It will help you make sure that your site update doesn’t get put off longer than it should.

Hmm. Maybe I should change my phone sales pitch. “Hi, this is Tom from Algonquin Studios. Have you changed the batteries in your smoke alarms and when would you like to begin updating your company’s web site?”

HTML5 and Enterprise on Mobile

Posted on March 14, 2012 by Adrian Roselli

This post originally appeared on my blog on Saturday, March 10, 2012.

An Argument

HTML5, CSS3 Early last week .net Magazine posted an article Why HTML5 is not the choice for enterprise mobility by David Akka. The article starts off with the statement HTML5 is being hailed as the programming language… That’s as far as I got before I realized this article had a fundamental misunderstanding of HTML5.

If you’ve read my blog enough, you know that I have been constantly struggling with how developers have shot themselves in the foot by allowing HTML5 to mean far more than just the HTML5 specification. Reading the comments to the article you can see that some people think the author is talking about just the mark-up language, and others seem clueless that there is a markup language.

I soldiered on and read the rest of the article. I realized that the main thrust of the article is less a technical assessment of HTML5, but is instead a discussion of how this collection of specifications is seen by so very many as a panacea for web application development. The author makes some valid points about security (specifically user-based, such as phishing scams thanks to bad browsing habits), lack of robust synchronization, and the ongoing changes to the W3C standards that can wipe away development efforts when the browser makers decide to change direction to match.

The author’s inability to clearly and correctly identify the appropriate specifications and speak to examples left the door wide open for anyone who rails against words such as “enterprise” to attack the article on its lack of technical merits.

A Response

In a response post, Why HTML5 is a choice for enterprise mobility by Kevin Sweeney, the three core arguments from Akka are challenged. The security issue is brushed aside as a function of poor development. The asynchronous nature of the web is addressed out of hand as a function of images and CSS, not so much about client-server communication and how best to lock and release records (for example). The argument about HTML5 as an unfinished specification isn’t addressed any more than to suggest that using it will make it wrap up sooner, but still with a fundamental misunderstanding of just which of the W3C specifications are really the ones in question.

A Response to the Response

Akka responded with another post, Why HTML5 is not the right choice for enterprises right now – or the defence of David Akka, which gets into some more detail on the technical side, but still gets some terminology wrong. As the one comment on the post demonstrates, people will skip the arguments within just to go after the technical detail, making the response effectively moot.

My Thoughts

When I get past all the misunderstandings of the specifications in the posts, including HTML5, I tend to agree with the overall message of the original post that rapid adoption, possibly for the sake of being cutting edge, is a real issue. This also assumes, of course, that the writer of (and responders to) the original article actually understand what “enterprise” means.

Security

So much of modern web security is about defending against user-initiated attacks — phishing scams, malware, adware, viruses-as-email-attachments, and so on — that I think the real issue with security is really a combination of keeping users from doing daft things and protecting your environment when they do.

Add to this developers who haven’t been inculcated in an enterprise environment and maybe don’t think about the sensitivity of data passed over the wire, or enterprise developers re-positioned to use these new web technologies, and you have some further risk.

Factor in web beacons that seem to come with the territory of developing all the “new shiny” and there is also an end-user security factor to consider. While a developer may not embed a Facebook button or an ad banner on an enterprise web app, that doesn’t mean they aren’t in the code borrowed from somewhere else, especially if the developer is new to the game.

Synchronicity

I’d like to think every developer has already built a system to lock records — ideally one that doesn’t halt all other operations on the system. This should always happen at the server level. The challenge here is how to handle dropped connections, users who don’t “log out,” and the other trappings of a stateless protocol propped up by a scripting language that has to manage calls to an API on the server that actually does the real work.

This can be addressed and has been successfully on the desktop. On mobile it’s a bit trickier with more likelihood of flaky connections and long wait times. It doesn’t need to be, but too many scripting solutions that ping the server (maybe for XML, maybe to order a pizza) don’t have clean methods of handling dropped connections and can end up leaving users stranded.

While that’s not the technology’s fault it is something that, lacking a clear standard, requires each company to re-invent for itself.

Unfinished Standards

Many sites are leaning on the W3C Web Storage specification (which is not HTML5, but is lumped in with it). If you’ve been paying attention over the last week you have seen a battle over this specification, with some developers calling for its termination in favor of a solution like Mozilla’s IndexedDB or the now defunct WebSQL W3C specification.

Those developers who might have wanted to use WebSQL only to see it get pulled may now fear the same thing happening to the localStorage API (Web Storage). Web applications they built to support it may need to be revisited. Clients, projects, etc. may need to be updated. Dollars will need to spent. This is enough to make a company hesitate.

If you aren’t in the loop, check out some of the ongoing discussions and remind yourself that anyone in enterprise development through web apps (mobile or otherwise) needs to stay on top of these battles to make ongoing informed decisions.

There is no simple solution for local storage by Chris Heilmann;
PSA: DOM Local Storage considered harmful by Taras Glek;
In defense of localStorage by Nicholas C. Zakas;
localStorage, perhaps not so harmful by John Allsopp.

Conclusion

Look to the business case. Don’t fall for the arguments against enterprise mobile web applications just because someone is afraid of a new paradigm, but instead make sure the resistance is based on sound business and technical considerations. Don’t fall for the arguments in favor just because of a knee-jerk reaction against “stodgy” enterprise models or a gee-whiz fanboy/girl mentality to all things mis-labeled as HTML5.

Ongoing Misunderstanding of Flash and HTML5

Posted on March 8, 2012 by Adrian Roselli

This post originally appeared on my blog on Saturday, March 3, 2012.

The latest article that uses absolutes and broad generalizations to imply an otherwise non-existent struggle between Flash and HTML5 is from UX Booth, “What the Demise of Flash Means for the User Experience.” To be fair to this article, I see regular missives on Flash vs. HTML5 and this particular UX Booth article is just an example of many of them in one easy to cite place.

The opening gives away the false premises for the rest of the piece:

Adobe’s decision to cease development of the mobile Flash platform and increase their investment in HTML5-related efforts created perhaps the final piece of conclusive evidence that HTML5 is the current go-to technology for creating ubiquitous user experiences regardless of device.

First I have to accept that the author is talking about more than the HTML5 specification and is also referring to CSS3, JavaScript, and the W3C specifications that are related to HTML5. This lack of clear delineation chips away at the argument.

Adobe has held that the fragmentation of mobile devices is too hard to keep up with on its own. Flash will still exist for mobile wrapped in AIR applications instead, and Flash is not going away from the desktop. Adobe’s decision to increase investment in HTML5 (via Edge and to a lesser extent Muse) is mostly unrelated since there is a market for an HTML5 authoring tool independent of Flash.

Not only is this neither conclusive nor the final piece of evidence that HTML5 is the current go-to technology, this is anecdotal evidence at best. In addition, HTML5 itself is nowhere near complete and the element often regarded as the Flash-killer, canvas, isn’t anywhere near as robust as Flash and still lacks strong scripting or styling support in the specs.

I think it’s fair to challenge the claim that HTML5 creates “ubiquitous user experiences regardless of device” when you consider all the polyfills and shims that need to be implemented to create similar experiences on a few devices. It’s also fair to say that my netbook does not handle some of the related HTML5 specifications the same as my tablet or mobile phone, partly due to various levels of hardware and browser support. Let’s not even get into video and audio codecs or the touch events specification (neither of which are part of the core HTML5 specification).

HTML5 excels at giving users a delightfully inconsistent experience on any device through the concepts of “graceful degradation” and “progressive enhancement.”

Those terms pre-date HTML5 and I can do both with HTML4 and CSS2. The author continues on and cites responsive design as a feature of HTML5, even though my own site is an example of an HTML4 site using responsive design to adapt to assorted displays.

Additionally, more than 90 percent of all smartphones and tablets are HTML5-enabled, which means that all the benefits of HTML5 can be utilized today to provide impressive mobile websites.

The author’s math doesn’t bear out the assertion — by the author’s numbers, 10% are not HTML5-enabled and so cannot benefit from HTML5. For the other 90% that are, even they cannot enjoy all (author’s word) the benefits of HTML5 today.

Making or upgrading to an HTML5 site can be as minimal as simply using HTML5′s doctype [...]

The implication here is that simply changing a doctype gets you all the benefits of HTML5, when in reality you still have the same HTML, CSS and script.

The post never does answer its own question — what does the demise of Flash mean for the user experience? From the article, more HTML5 use. In itself that doesn’t tell me how the user experience is affected, just how developers are affected. If the developer does a good job, the user experience doesn’t need to change. The user shouldn’t need to worry about the underlying technology.

Too many HTML5 articles and posts today, like this one, work to promote the markup language (and usually CSS3 and JavaScript, even if they don’t know it) by contrasting it against another technology that is falling away or is just a popular target of derision. The pro-HTML5 cheering is easy when another technology has already been recognized as out-of-date, but this doesn’t do anything to advance HTML5 and its related specifications.

I’d love to see more practical discussions of what HTML5 (and related specs) can do today along with all the nifty experiments that are moving the collection of specifications along.

Comparing Mobile vs. Desktop Data for Improved Experience

Posted on February 22, 2012 by TerriSwiatek

Mobile web sites and web pages are all the rage and it’s no wonder, with sales of mobile devices soaring (Gartner). So, maybe you’re considering a mobile version of your own site, but you want to be smart about it, doing what’s best for your site based on what makes good sense for your business. Thankfully, web analytics is here to the save the day! Analytics = super exciting, right? Well, bear with me here.

Start by accessing your Google Analytics account (if you don’t have Google Analytics installed on your web site, check it out to learn more about the insights and information the service can help you gather about your site).

You’ll want to set your date range for the past 12 months and go to the Mobile Overview section* (Click images for larger screen shots):

This report will show the percentage of visitors came to your site from mobile devices during the past year. If it’s a decent piece of the pie chart, usually 10% or more, the data is telling you it would probably be smart to invest in the development of a mobile site.

Click one level down to Devices and you’ll see which mobile devices are the biggest drivers to your site. It’s important to note if Apple devices are at the top of the list as Flash won’t work on these devices (and probably never will). You’ll want to keep this in mind and consider an alternative to Flash when designing your mobile site.

Now, let’s dig a little deeper. What kinds of content are your mobile visitors viewing most often (Content>Site Content>Pages)? Does it differ from desktop users? If so, those answers can point you to better ways to organize your content for a mobile site design.

Here’s how: Hop down to the Content section, click on Pages, and bust out some Advanced Segments. Under the defaults, you’ll automatically have a Mobile Traffic option at your fingertips. This report will give you insight on what the most viewed content from your mobile visitors is. Is this same content at the top of your mobile site design or extremely easy to access on a mobile device? It should be.

You could just compare “Mobile Traffic” to “All Visits” but let’s be more awesome.

Create a quick and simple “Custom Segment” for Desktop Visitors.

Click “+ New Custom Segment” > Name it “Desktop Visits” >Select “Include Mobile Exactly Matching No” > Test then Save your segment. You’ll know you did it right if your Mobile Traffic and Desktop Visits add up to All Visits.

Now, you can start comparing differences between your mobile and desktop site visitors. Just select the “Mobile Traffic” advanced segment and your new “Desktop Visitors” custom segment, hit apply, and check out the differences. For example, on our own site I found mobile visitors spend way more time on our Web Design and Careers pages than a typical desktop visitor.

If you don’t see a lot of differences between the way mobile and desktop user visit and interact with your site, simply creating a more mobile-friendly version of your current site is probably a valid option and should work perfectly for the vast majority of your mobile visitors. On the other hand, if there are big differences between the two kinds of interaction, you may want to consider a new design for your mobile site, pushing the most important content for mobile visitors to the top or highlighting it to make it more easily accessible via mobile devices.

If you’re an analytics user, have you tried any of these reporting options and checked out your metrics? Did you find anything interesting? I’d love to hear about it.

*All data shown is anonymous and is not reflective of our clients’ accounts.

The Mobile Web

Posted on February 16, 2012 by Colleen Ross

Author: Garret Hussak
February 15, 2012

If you’ve been listening to the word on the street, you’ve noticed…everyone’s talking mobile. We now expect that companies will provide us with access to their sites from mobile devices like smartphones and tablets, and developers are being called upon to create mobile sites and applications more and more often.

So, Why The Push For Mobile?

It’s simple – people are using mobile devices and the technology isn’t going away.

By one count, there are 5.3 billion mobile device subscribers in the world.
In the 4th quarter of 2012, manufacturers shipped more mobile devices (100.9 million) than PCs (92.1 million).
According to one source, mobile browsing has jumped almost 200% worldwide in the past year and is closing on 10% of total browsing.
It is estimated that by 2014, mobile browsing will surpass desktop browsing.

What To Consider?

While we can probably agree that mobile development is “where it’s at,” we need to remember, of course, that developing for mobile devices is it’s own animal, with both limitations and advantages that need to be taken into account:

Smaller screen size
Potentially slower connection speeds
Higher resolution displays
Access to the user’s location with GPS & other technologies
Access to the user’s camera
Access to the user’s contacts

How Do We Implement Mobile Functionality?

There are a variety of methods to reaching mobile users and catering to the benefits and limitations of mobile devices:

Mobile Applications – Apps are a great, often fun and engaging way to present content to people on the go. But it’s important to remember that apps are platform specific and can a long time to develop. You also need to take individual device capabilities into account when creating mobile apps.

Mobile Web Sites – Mobile versions of web sites that are either already in place or are being redesigned or developed from scratch are a perfect way to ensure visitors have the best possible experience when they access your site on their mobile devices. Mobile sites come with some great advantages over applications, as well, since they don’t have to be platform specific (though they can be, if necessary) and usually have a faster development time. Device capabilities also aren’t the issue they can be when developing apps.

Finally, Let’s Talk About Some Of The Technological Hurdles Involved In Mobile Development

As I mentioned earlier, mobile development is its own animal and we have to keep a few important practicalities in mind when we think about a mobile project:

The “old-school” idea that tables can be used for layout simply won’t fly on mobile devices. In a mobile environment, elements need to be able to stack as opposed to live side-by-side as in a desktop element.
Fixed widths won’t work. A 450px element might fit great on a desktop version of a site, but on most mobile devices that will have be switched to a fluid width.
Different users will see things (slightly) differently. Each device can have a different display resolution, aspect ratio, and browser.
Flash is dead slow and dying. Content previously presented using Flash should now be displayed using one of many mobile friendly technologies.

No DHTML, Please

Posted on February 2, 2012 by Adrian Roselli

Originally Posted by Adrian Roselli on January 25, 2012, on his blog.

The trend continues where I speak to clients, vendors, young developers fresh out of college, and even the teachers/professors who instruct them and they don’t understand that HTML5 and CSS3 aren’t the same specification. I have repeatedly shown an HTML 4.01 site with CSS3 to explain that they are each distinct specifications which can be applied in different combinations of different versions. This is further complicated when JavaScript is folded into the mix — some folks even think jQuery is part of the HTML5 specification.

I am repeating a request that when we who know better (developers, tech writers, robots named Frank) speak about discrete specifications, we refer to them as such.

When I talk to another developer about a feature, I want to know that when one of us says “HTML5″ we are both talking about that particular specification. When we use terms like “WOFF” or “WebGL” I have comfort knowing the developer has a particular set of technical standards in mind, but when one of us says “HTML5″ we each have to pause to consider what related specification the other might actually mean.

It seems fair to raise what sounds like a semantic point when we are discussing a specification that is all about encoding content in semantic and structural elements. I don’t think I should let this go, otherwise it feels like I have failed the semantic goal of HTML right at the outset.

What Motivated the Mini-Rant

Another free and fantastical service was released to the web development community on Tuesday, HTML5 Please. The same folks who also brought us sites like HTML5 Boilerplate, Modernizr and CSS3 Please are the fine team behind this resource. And this is part of the reason why I am so frustrated. Each of them knows the difference between HTML, CSS, and unrelated specifications like WOFF, SVG, Geolocation, WebGL, and so on.

In a (Google-doc-brokered) conversation with Ian Devlin (author of HTML5 Multimedia: Develop and Design), Paul Irish (one of the folks behind HTML5 Please) agreed to add a disclaimer to the site for the chronically unlikely-to-read-any-specifications-or-bother-to-know-the-differences-among-them. Mr. Irish made short work of it, too:

While named HTML5 Please, this site discusses features beyond the HTML5 specification, coming from CSS, SVG, and the greater Open Web Platform umbrella.

On Wednesday I went back to the site and noticed that the disclaimer was gone. I tweeted about it and was ultimately directed to a bug/issue report that provided justification for its removal:

[…] However, HTML5 represents an umbrella term for all new technologies (as is inferred from platform.html5.org). Also, the specification itself is now a living standard known as HTML and not HTML5.

Of course I was motivated to leave a comment:

I feel the ship has sailed when trying to communicate this point to the general public, tech writers, bosses, clients, and small children up the street. However, since the site is aimed at developers I think it does a disservice to not remind them that HTML5 means a very particular specification, and that it makes it easier in the future to cite new specifications that will be supported on the site (as they come up), but are otherwise distinct. For those who do know better (me, a couple folks above), it just looks like the site got it wrong and doesn’t understand the difference itself.

If we as technical professionals cede the meaning of HTML5 when speaking to other technical professionals, we are falling prey to marketing speak that has no place in discussions about specific technical matters.

That’s it, that’s the background. I’ve explained my thoughts on this before and am concerned that HTML5 has become a distilled marketing term that, unlike DHTML and Web 2.0, neither of which shared the exact same name as the version of a technical specification, only leads to confusion when developers are interacting with marketers, bosses, clients and vendors.

You may read previous variations on this rant here:

Time For a Redesign? Get to Know Your Users First.

Posted on January 18, 2012 by Mike Spencer

There are several good reasons why you might decide to redesign your web site and Steve Kiernan II was nice enough to detail them in an excellent blog post recently. To paraphrase Steve’s points, it really comes down to this: if your current web site isn’t effective, it’s time to redesign.

But how do you determine if your site is effective? Start by understanding your users.

First and foremost, your new design needs to cater to your users. Understanding who is using your current web site and how they are interacting with your content is crucial. Once you understand why users are coming to your site (or why they aren’t) and what they’re looking for, you’ll be able to make decisions about what content should be pushed to the forefront and drive the redesign.

Web Site Reporting

You can use tools like Google Analytics to learn more about your user base, including where they’re located geographically, what technology they’re using, and how they’re getting to the site. You can also see what pages your customers are viewing and how they’re engaging with your content.

Customer Polling

You can reach out to your clients via email, phone, or postal mail, or you can use services like SurveyMonkey or Wufoo to set up questionnaires to gather user demographics and feedback. This will allow you to ask targeted questions and gather feedback from actual users. To capture feedback from the widest audience, you should use a variety of methods to communicate with your customers.

User Groups

To go a step further, you can set up user groups and watch how customers interact with your web site. Ask users to complete common tasks (i.e. find the company phone number, add a t-shirt to the shopping cart, etc.) and observe how they complete them. This will allow you to see what tasks users struggle with and where the web site suffers (or flourishes). You’ll also have a captive audience so you’ll be able to ask questions and gather feedback.

So, now you understand your users. What’s next?

Review Business Objectives

Once you gathered that information, you’ll need to answer two very important questions:

#1 – Do the business objectives for your site align with actual user engagement?

If they do, then your redesign should focus on improving what you’re already doing well and refreshing visuals as needed.

If they don’t, then your redesign should push users to the content that will help you achieve those goals while still allowing users to efficiently access the content that they’re looking for.

For example, let’s say you sell t-shirts and sneakers. You earn more money on sneakers, but you sell a lot more t-shirts. As a result, you may want to push sneakers in your redesign, but you shouldn’t make buying t-shirts difficult. Selling t-shirts should simply be the second priority of the new design.

#2 – Do your actual users align with your target audience?

If they do, then you’re in good shape. Your redesign can focus on small improvements and new graphics and you don’t need to make sweeping changes.

If they don’t, then your new design should cater to the desired audience, but still be welcoming and accessible to the other users.

Let’s say you’ve got a site dedicated to promoting your region or city as a vacation destination and you offer information about local attractions and events that visitors may be interested in. But, Analytics shows that a large segment of your site traffic actually comes from area residents looking for exciting things to do on the weekends. When planning your redesign, you could consider adding a “staycation” section designed specifically with these people in mind. While the main focus of your site can be attracting out of town guests, you’d still be able to offer the valuable information so many people are looking to your site to provide.

Determine Priority Content and Design the Site Around It

Simply put, you need to determine what content is most important and build the design (especially the Home page) around that content. See my blog post on this very subject for additional information.

Get Additional Feedback

Once you’ve gone through the design phase, put it in front of your users and get their feedback. Before you commit to the costs of development, you’ll want to make sure that current users won’t have trouble interacting with the new design.

Setting up a small focus group, rather than a large pool of users, may give you the most valuable feedback because you’ll be able to see individual reactions and speak to users one-on-one.

Continue Monitoring

It’s easy to think your project is complete once your new site live, but remember-ongoing user satisfaction is the true measure of success for any redesign. That’s why it’s important that you continue to monitor user interaction even after your new site has launched. You’ll need to make sure that users are still able to accomplish their objectives on the site and determine the effectiveness of new initiatives.

Time to Update Your Web Site Copyright Date

Posted on December 28, 2011 by Adrian Roselli

Our Senior Usability Engineer, Adrian Roselli, originally posted on this topic on our QuantumCMS support forum on January 12, 2011. As another new year approaches, we thought the information, with a few updates, might be worth repeating here:

It’s that time of the year where you should take a few minutes to log in to QuantumCMS and update the copyright date on your web site. If you don’t remember where it is, for most of our clients it’s a Site Property that you can edit. If you don’t remember how to edit that property or don’t have your documentation handy, this tutorial can help: Adding a Site Property (it also works if you just want to edit the existing property).

Why is it on your site?

Perhaps you only have a copyright statement on your site because we included it in our design, perhaps you have it because your legal counsel suggested it, perhaps you only have it because you’ve seen it everywhere else. Since I am not a lawyer, doling out legal advice isn’t in the scope of this post. You can ask your own legal counsel about how declaring a copyright protects your content.

I am writing this from the perspective of U.S. companies, although I know some of you reading this are not U.S. companies. In that case, I suggest you check your own country’s laws on copyright.

If you are more inclined to track this information down on your own, you may want to take a look at the U.S. government Copyright.gov site, specifically the page “What Does Copyright Protect?” which links to a PDF file (“What Works Are Protected?“) containing the following statement:

No publication or registration or other action in the Copyright Office is required to secure copyright.

If you are adamant about registering your web site with the U.S. Copyright Office you should grab a copy of “Copyright Registration for Online Works” (provided as a PDF file).

How else is the copyright date used?

I’m glad you asked.

Many web site users see the copyright date as a quick cue to how fresh the content is, even telling them if the site is stale. If you are visiting a site with a date of 2009 (and it is almost 2012) in the footer, you might think that nobody has touched the site in three years. And you might be right.

Many sites use the copyright with a year span (1998-2012, for example) to demonstrate how long a site or organization has been in existence. This may not impart any added benefit if you are pursuing somebody who has stolen your content, but it does at least indicate to users that you have been around for a while, are current, and probably know a good attorney.

Don’t wait too long to update the copyright date on your site. If your site claims to be from 2011 by this time next week it will appear to be (at least) over a year old or (at most) a couple weeks old. Remove that confusion by taking a few minutes to update it.

Design By Committee – How To Make It Work

Posted on December 14, 2011 by TerriSwiatek

Design by Committee is an inescapable situation in many corporate environments today. It’s also the bane of most designers’ existence. I can understand the thinking that two heads are better than one, but trying to please a group of four or more varying opinions can seem like an impossible and very frustrating task that frequently ends in a “too many cooks spoil the stew” scenario.

Many people, on both the committee and design side, despise this particular challenge, but in my perspective it presents an opportunity to think of some ways to improve a process that so often ends in mediocre design solutions that no one really wants.

Identify the design’s purpose for all parties
Knowing the purpose of the overall design is imperative to keeping a committee on task but it also should drive design-making decisions. A design and its elements should be tied to a specific audience and overall objective that’s agreed upon by the committee in the beginning. When presenting the design, being able to communicate why a design element was used and how it meets the overall goal or appeal to the agreed upon audience can make committee buy-in easier.

Help keep egos and politics in check
All too often, a design by committee project ends up focused on the internal structure of an organization, or worse, a decision maker’s personal tastes, rather than the audience it’s meant to engage. Having the guts to ask why an individual or group is requesting a change and if that change will help meet the objectives they defined is our responsibility. Being a “yes man” may help you gain favor initially but it will most likely fail your design project and, ultimately, your goals.

For example, choosing a specific color or font because it matches your branding is a good reason for a design change, as it will help improve brand recognition and consistency across marketing efforts. Choosing a trendy font, just because you like it, as opposed to one that is more readable for your older target audience is not a good decision. As designers, we are trained to consider such things but we need to remember that the people on the committee might not be – bringing conversations back to these tangible points helps correlate something visual with the end purpose of the design.

Ask for feedback in a constructive manner
More often than not, personal backgrounds or emotional responses can end up directing a design by committee project. Asking open-ended questions can be a lead in to these emotionally-driven responses and misguided direction.

Fortunately, there are some questions you can modify to get more valuable feedback. Instead of simply asking if the CEO approves of, or likes, a design, you can ask if he feels the design meets previously-stated project objectives or if it appeals to the target audience. His answer then becomes less about is personal feelings and more about the goals of the project.

When presenting a design in person, over the phone, or even via email, it’s easy to ensure your audience understands the goals of the project but, sometimes a design will be presented to others without your knowledge or participation. Keeping the project’s objectives and key background points with your design can give context to someone who otherwise would have none.

Use research when available
You won’t always have the luxury of market research but when you do, it is incredibly valuable to the success of a design by committee project. It can help give the group an unbiased opinion of what imagery or language appeals to your target audience and, instead of basing decisions off of assumptions or popular opinion, they can be determined by audience trends.

Wrapping it up
In my experience as both an in-house designer and someone who produces work for outside clients, I don’t think I’ve ever been in a situation where I was designing for just one decision maker – whether they were in the room or not. Finding ways to collaborate with our clients in a goal-driven way whether they’re internal groups or outside clients is something we should all aim to do and keeping the above tips in mind should help make it easier for us in the long run.