The South By Southwest Interactive panel picker has done its duty and about 60 panels were announced last week, but one still caught my eye that did not get selected: Social Media for Luxury Brands and Brands With Issues. It looks like a very interesting discussion. One line from their abstract states what I would consider to be the crux of the issue of involvement in social media for luxury brands - “Some high-end brands fear getting their hands dirty by mixing with the masses.”

That’s no longer true for Cartier who overcame any supposed fear and got their hands dirty on MySpace last summer. I for one was surprised that Cartier has a MySpace presence. See and hear http://www.myspace.com/lovebycartier for the actual page and to view their 4048 friends.

The world’s most desirable luxury brands according to Forbes magazine include Gucci, Chanel, Calvin Klein, Louis Vuitton and Christian Dior. These are the brands that respondents to the survey would buy if money were no object. If you haven’t seen the site Brand Tags yet, check out the tags for Louis Vuitton (here’s a hint: expensive luxury bags are the top three tags).

One of Cartier’s stated goals with a MySpace campaign was to market to a younger crowd, but Cartier is not just after the teenyboppers instant messaging with their friends about their latest crush. MySpace says that fully 85% of their U.S.-based users are over 18 so Cartier’s definition of young may be 20-somethings.

According to the Forbes article, though, United Arab Emirates and Hong Kong are the world leaders in luxury goods consumption. So perhaps there’s a mismatch in the MySpace “walled garden” eyeball/audience tendency and the most likely luxury brand consumer.

No matter the analysis of effectiveness of reaching their target, the reality is that all brands are seeking the viral nature and virtual word-of-mouth marketing that social media offers. What brands do you wish were more “hip” online for you to share with others? Which brands have you tuned out on your favorite social media sites?

Duo Consulting has been working with Drupal (an open source content management system) for well over a year now, creating sites like the award-winning Chicago Public Schools Alumni site.

As part of our continued commitment to the overall Drupal effort, and the Chicago technical community specifically, Duo is helping to sponsor Drupal Camp Chicago, including sponsoring a student registration, as well as sending several of our own developers to participate.

Suggested session topics run through the life cycle of a Drupal application, from installation to performance tuning. It looks to be a good event for anyone interested in learning more about this CMS!

Web usability expert Jakob Nielson just released a new study that I think every marketing manager with a company website ought to pay attention to. It’s about your company’s About Us page.

The study, released last week, follows up on an earlier study done five years ago and looks at 63 websites from large, medium and small companies, government, and nonprofits. You can read the executive summary on Nielson’s Alertbox website or download the whole thing for a reasonable price (compared to most studies like this) if you want to see the dirt on the company sites with usability problems or see examples of good About Us pages. But here is some of what he says about putting your best face forward on these important pages, along with some of what I’ve seen of this in my own experience.

“On each site, we gave users one open-ended task: evaluate the organization. We also gave them several directed tasks, such as to find out who runs the organization, what community or social programs the organization contributes to, and when the organization was founded.”

There was some good news and some bad news on these tasks. First, usability for those pages had actually increased by (what Nielson calls) an acceptable 9% in five years, but the bad news was that when users were asked to find out what the organizations actually do success rates went down from 90% to 81% in the last five years. Apparently, a trend has emerged where marketing execs are more interested spewing “marketese and blah, blah” about what they do, than being clear.

I do a lot of research via company websites and I see this type of mistake a lot. They usually say something like, “We deliver you the most innovative solutions in multiple languages to give you improved outcomes and a more impactful position in a unique marketplace within all industries.”
What!? But what do you do? It kills all your credibility to be so vague that you appear to be trying to be all things to all people. Nielson has this to say about credibility:

“Trust and credibility are major issues on the Web, where even the biggest company exists as only a few words and pictures in a browser window. The most deceitful and unethical company can look as good as a company with a long history of community involvement and honest customer relationships. Explaining who you are and where you come from does matter, as do simple things like providing management biographies and photos.”

Nielson, gives some great free advice in his executive summary. For example he suggests web designers have a homepage link that simply says About Us or About Company Name since this is what most users are accustomed to. In his study users had trouble deciphering the meaning of nonstandard terms like  Info Center or other descriptors, so it’s best to use what is familiar, rather than trying to be different.

And it’s important to be sure the content on your About Us page says clearly who you are, becuase as Nielson says, this is pretty much the content you want all other content based upon, so it’s important to nail it down tight—without the marketese and blah, blah. He then goes on to recommend a hierarchical structure for the rest of your About Us information (more free advice):

“We recommend providing About Us information at 4 levels of detail:

• Tagline on the homepage: A few words or a brief sentence summarizing what the organization does.
• Summary: 1-2 paragraphs at the top of the main About Us page that offer a bit more detail about the organization’s goal and main accomplishments.
• Fact sheet: A section following the summary that elaborates on its key points and other essential facts about the organization.
• Detailed information: Subsidiary pages with more depth for people who want to learn more about the organization.

Nielson explains the effectiveness of this approach through a good example (Alcoa) and bad example (US General Services Administration).  Search these yourself and see if you don’t agree.

This is just an overview, so if you want to read the study information that supports these ideas, or you need some type of metrics to convince your boss, you might consider reading the entire report, but Nielson’s exec summary has even more valuable information than I can talk about here. So, I’ll leave you with Nielson’s bottom line on this:

“The Web is very depersonalized, but from our earliest usability studies, we’ve seen that users like getting a sense of the company behind the website.

Having a good About Us section facilitates this understanding. Clearly stating what you do helps customers understand your site as a whole. Of course, your overall site is what ultimately represents your organization to users. People look at product pages and read the site’s content when they’re evaluating an organization as a possible vendor, business partner, employer, investment, or (in the case of charities) donation recipient. Communication isn’t restricted to About Us. But dedicating an area to providing users with facts about your organization and its history and values helps pull all of the site’s content together.”

I readily admit that the phrase “interest networking” sounds like Dilbert-speak to me. But I’ve been playing with Twine for a while (www.twine.com) and it seems appropriate to describe the experience as finding interests you have in common with other people. However, I don’t think its strength lies in networking because I still haven’t found how to import my contact lists to see who else I know on Twine. I guess I expected that feature because other new-ish networking tools like Plurk gave me that option.

I also tend to automatically correlate Twine with Twitter, even though the only thing they have in common is the first two letters of their name. I was first alerted to Twine from someone I follow on Twitter, so I suppose that’s the connection that’s stuck in my mind.

Twine is in private beta right now, but all you need to do is enter your information to request an invitation. I requested mine back in June and got it immediately. This invite-type beta is a way of artificially inflating the cool factor, but it is in fact cool because it seems to add a social net to the finding of content. Their value pitch is “organize, share, and discover information around your interests.” In my experimentation with Twine, it seems like Twine helps you find web content that communities have chosen. For example, entering “wiki” gave me some articles that the usual net I cast hadn’t found yet, some even from the early 2000s. Try a search with your interests and see what you find - I’d love to hear your experience with Twine.

Twine’s tagline is “Twine takes everything you’re into and ties it all together.” So far, I’d like it to tie my “peeps” and various other networks together a little better, but I think I need to have it tie my interests together instead.

What do you do when your web content engine, while aging gracefully, indicates to you that it’s ready for the rocking chair on the porch? Serena Collage had an internal communication leak to a few message boards, such as the Collage Higher Ed Yahoo Group and their own Support forums, that hints at the eventual sunsetting of the product.

Later correction and clarification came on the Support forum from Vickie Schira of Serena, saying “Serena has not announced any major changes to the Collage product plan, and there isn’t an announcement planned that I’m aware of. In case you haven’t seen it before, Serena does have a published end of life (EOL) process. That process gives a two year lead into ending support. The two year timer begins when Serena notifies the customer base. If you would like to read more about the EOL process, you can see it here.”

With a detectable trend toward fewer updates for a product, perhaps even expiration of support of the product, what are some considerations for migrating the content? Duo Consulting is researching products that can be suitable alternatives to Serena Collage. One key tactic is ensuring that both the content and the structure migrate smoothly to a new platform. While the sun hasn’t set on Serena, good content and structure decisions assist in smooth moves no matter where your content lives and breathes.

I have to admit, after reading Understanding Twitter, that I didn’t get it either.  When I logged on for the first time last week, though, The Content Wrangler, Scott Abel, had already put my email address in as someone allowed to voyeur-in on him.  So I did.  And I like the way he uses it.  It defies the “navel-gazing” description that some give Twitter.

Scott’s twittering is helping me get it.  Here’s why. Take a look at some of his entries, such as this one: “The Twitter message only had one word, ‘Arrested’,” which referred to a recent CNN story about a young man who freed himself from an Egyptian jail with a one-word post sent from his cell phone. As a matter of fact, even CNN is Twittering (as Scott also points out). This is the kind of information sharing I’m interested in—and will likely stay tuned for.

As I started playing around with Twitter, my mind became a jumble of ideas thinking about all the possible ways a tool like this could be used in business or education.  I see where companies like Comcast, are using Twitter to feed outage updates and other customer service information to customers. (Too bad they can’t tweet me the new PIN that’s required to access my account information I’ve been trying to get for a month.) And you might have to forgive the hokey “Comcast Cares” logo floating around on the page, but they must care—at least a little—if they are trying new tools to reach customers.

Most of what I’ve read about Twitter discusses using the tool to communicate to outside customers, but other than that, couldn’t Twitter be used for internal communications? Could collaborators on a single project tweet one another to give status updates? Legal might tweet  Communications, “Signed off on CEO quote about how the IRS sucks,” implying that a press release is ready for the next step in the process.

With a tool like this, managers could keep an eye on the progress of team projects, see where things get stalled, and even tweet the team with information as basic as, “So and so is out today. Pls move this forward and circle back to him tomorrow.” You don’t need more than 140 characters to say that.  Mash it with a wiki and you have a free system that allows you to communicate with followers, contribute content, and keep an eye on the whole process to boot. This seems much simpler to me than the typical check-in-check-out-and-email content management tools we’ve all grown accustomed to.

I see this working in the classroom, too.  Students, who previously used clunky message boards to collaborate, could use Twitter to tweet each other about a project. “Gerbil seems nervous on diet of Red Bull and Skittles. Switching back to gerbil feed tomorrow,” and document the whole process for everyone—including teachers—to see.

So, I guess I’m starting to get it a bit more, but like so many other new tools, it’s gonna take me some time to realize its full impact on my life and my work. I’d like to hear how others may be using Twitter for internal communications.  In the meantime, I think I’ll check out what Scott’s doing right now.

What about using a wiki as a war room, a single location for strategic action-packed activity surrounding a specific set of goals? Wikis have lots of great features that make it an ideal collaborative web space. We’re not the first to think of this either - this article from a wiki about using wikis for Project Management discusses Building a Virtual War Room. But Duo has an excellent example of using an internal wiki page as a command center, a war room of sorts.

Duo uses its internal wiki to document and collaborate on mission-critical projects, like Chicago Park District registration. When the throughput gets intense, the Duo Consulting team uses an internal wiki as a war room for troubleshooting a web application that contains underlying SQL queries to help Chicagoans register for park department offerings. The wiki becomes a strategic command center, a virtual room from which information is gathered and decisions are made. With a slogan for Chicago Parks like “Come out and play” a war room metaphor seems opposite to the end game, but the team must attempt fully concentrated efforts and strategic decision making from one location. There are a couple of reasons why the wiki is so useful:

• there are so many people involved, with so many time-critical tasks and dependencies, that one central location that shows the progress prior to registration helps keep the team on track as a team
• during registration itself, there are so many people monitoring so many different aspects of the application all at once that they need one central location to store that information, as well as knowing who is responsible for following up on any immediate issues
• the wiki engine itself does an awesome job of syntax highlighting and storing SQL queries
• the team can use the wiki as a task list, crossing off items as they’re done.

A specific scenario as an example: one team member might log an issue where a patron can’t register for a particular class. The site is giving the user conflicting information about whether the class is sold out already or not. Another team member might throw up the raw database SQL for that class display on the wiki, and a third team mate might closely analyze that SQL for clues as to what the underlying issue really is – all within minutes, because it’s so important for people to be able to register for these programs as quickly as possible. It’s like the wiki page is the heads-up display in the war room.

Kelly Tetterton, director of development at Duo says, “In some ways, I would imagine working on Chicago Parks Department registration is not entirely dissimilar from working at the air traffic control tower at O’Hare – it feels like that kind of high-pressure, high-intensity experience.”

I’d say that wiki updates give more immediate answers to questions than emailing and waiting for a reply. Wikis make all decisions known to all who monitor the pages. Wikis let you display mission-critical information in a heads-up display or you can print if you happen to like your clipboard or three-ring binder. Wiki’s history pages give you the path to the decision made, and wiki discussion pages can contain lively back and forth while the main page maintains the “truth” decision for the time being.

Let’s hear some war stories - how are you using internal wikis as your strategic project war room?

Apparently Google is not content with merely taking over the world. From their early beginnings as the ubiquitous little search engine that could, they’ve made a name for themselves through adding innovation on top of their acquisitions and partnerships. Until recently, web browsers were immune to this innovation—Google applications required Firefox, IE, Safari, Opera, and any other modern web browser to run.

But as of September 2, 2008, Google stepped onto even their toes, releasing the Google Chrome browser that is fast, standards-compliant, and above all, looks ready to do business as a shell for Google’s web-based word processor, spreadsheet, e-mail, calendar, and other applications. The fact you can also browse the world wide web through the program is a bonus.

Bigger Better Browser

Life hasn’t been the same since browser technology advanced to where developers could create interactive experiences within a web browser that looked and felt like desktop applications. These rich internet applications (RIA) paved the way for what we refer to as cloud computing: software and data that exists anywhere on the Internet are funneled through an application on a user’s desktop, who doesn’t need to know how they work or where they’re stored. So long as the applications behave as expected, and reassure the user that their data is safe, they are happy with not knowing.

Google Chrome seeks to build on everything for which we’ve used a web browser to date, and move us all into territory we have yet to explore. The very nature of the product lends itself to more creative uses, many of which don’t even exist, or may be twirling cartwheels inside developers’ heads.

In most companies the browser is the central application on a user’s desktop. In my previous life as a logistics data analyst, we used our web browser to connect to a software suite to manage our workload, cut purchase orders, pay invoices, write contracts, follow up on back orders, process returns, communicate with our co-workers, track our time… standard business stuff. Looking back, this was a rather limited use for our browser in terms of an application enabler.

In other parts of the Internet world, the web browser has been used to run more complicated web applications like wikis and blogs, content management systems, document control systems, and of course, true desktop-like applications. The developers behind Google Chrome saw this brave new world and designed the product to be invisible. After all, the important part of your day includes everything but the technology.

If Looks Could Kill Other Browsers

The first thing I noticed about Chrome is how it looks. The interface is basic, but sleek. There is no application menu, and no toolbars that take up a lot of space. Everything that could happen happens in the browser, or at least in a browser tab. The tabs appear at the very top of the window, creating the look of a physical filing cabinet. Other browsers’ tabs also point upwards, but still underneath a lot of menus and toolbars that drove me to buy a bigger monitor.

Google Chrome: A Browser Without Menus

What this means for me is that I can write this article in Google Docs (or Zoho Docs, for the non-partisan) with as much writing room as possible, before posting it into our blog CMS. This is a major plus for me. I use Google Docs to keep track of stuff between my day gig and my home life. I use Docs to record notes, and Spreadsheets to track my cash expenses. All this information is available to me from any computer connected to the Internet. Some may argue that using the free versions make my information less secure “in the cloud”, but as my information isn’t CIA-level top secret I feel pretty safe.

Of course, I do copy my data from Google’s servers into other formats, and store some of the information on my own hard disks. Adam Pash wrote an article about backing up your data from Google’s servers on Lifehacker.com, the core focus of the article isn’t that Google is evil, but that redundancy is always the best option. I’ve heard it said that digital data doesn’t really exist unless it exists in at least two places.

No More Hurry Up and Wait

Google Chrome takes the browsing experience to new heights, in both web-standards–compliance and rendering speed. Based on a recommendation from the Android team the developers chose Webkit, the same w3c-fascistic rendering engine used by Apple’s Safari browser. I say, “fascistic”, because I’m still hurting from the experience of Safari breaking one of my web projects. Eventually I’ll come to grips with the understanding that this will teach me to write more standards-compliant code.

I see a noticeable speed improvement when viewing pages through this browser. The speed also improves my experience using browser-based applications. I read that Google uses techniques like DNS-pre-fetching and caching, and separate virtual machines (V8) that operate separately within each tab, but all this means to me is that web pages load more quickly and applications operate invisibly. Period.

For people on the go, on the road, and rarely sitting still, the idea of always-on access to Internet applications and data is a big plus. When the browser steps out of the way, it makes even remote collaboraton easier.

The End of the Hourglass

Have you ever been surfing the web with a handful of tabs or a couple of windows open, when suddenly one page hung on the hourglass and your system froze in the process? Then, when you killed the offending tab or window, the entire application shut down, and you were forced to start your browsing experience afresh. Most web browsers run as a single application even when multiple tabs and windows are open. Hang one, you hang ‘em all.

Google Chrome ends the hourglass behavior by keeping applications in separate tabs and windows separate from each other. This way, when an application in one tab hangs, closing that tab shuts down only that application. All the other tabs are left intact. Plus, applications cannot read information between tabs, so your information is more secure than in other web browsers.

The best part of the hype surrounding the browser’s launch was the 38-page comic book by Scott McCloud (aptly chosen, considering the benefits of Google Chrome to cloud computing technology). Page 14 explains in a more technical manner why V8 technology runs JavaScript faster than other browsers.

Google Chrome V8 Technology Processes JavaScript Intelligently

Looking Forward

I don’t think an application exists that doesn’t have faults. Google Chrome is no exception, though its faults are miniscule in comparison to other *cough* commercial applications.

First, Chrome is in perpetual beta. This frees the developers to continue to make tweaks and improvements with no timed release schedule. This also helps Google answer any complaints with, “This is only a beta, so some features are still being worked out.”

Second, at the time of this writing, Chrome can’t access any trusted sites that require a password. I downloaded the browser for the first time at work, and tried to test how well it let me edit the wiki on our corporate Intranet. The program couldn’t save my credentials, and our network locked my account after the fifth failed login attempt.

Finally, Chrome is open source, which really isn’t a fault at all. By licensing the source code for external developers to work with, Google opens the door for improvements and feature adds from the developer community outside Google. I’m sure this will prove to be a big win in the long run.

Links to Google Chrome Stuff

• Direct download to the Google Chrome installer (inactive—Google forces you to download from their Chrome home page).
• Google Chrome home page
• Detailed information about Google Chrome

This is a great conference. It’s great to be back in NYC. There is no place like NYC. The sights. The smells. Seeing my family. All great. Here is a sample of today’s sessions …

Keynotes: 

Tim O’Reilly: Web 2.0 is a data operating system; Work on stuff that matters; Create more value than you capture; Great potential in big problems; Vote: don’t let those who don’t participate pick our leadership. 

Clay Shirkey: Information OVERLOAD. New problem? Not really. Soon after Gutenberg revolutionized printing there were too many books in print for most people to read in a lifetime. This problem has been with us for about 500 years. We need a new perspective on data flow. We need better filters.

Cloud Panel :: 

An interesting discussion about what the cloud is. And isn’t. Best bits? Remember to consider scaling down when you are obsessed with scaling up or out. It’s always good to be as close to your end-users as feasible. When cpu’s are sold as a utility, coding practices will change lower utilization costs.

Digg Scaling :: Joe Stump

Stump Dump:

Scaling can cause severe hair loss.

Your mother lied: Share nothing. Share nothing architectures are the key to scaling out.

Decentralize; expect failure; just add boxes.

Cache forever; explicitly expire; develop a chain of responsibility.

Partition your data!

Joe Stump. Awesome.

Sequel to SQL

Whoa. As a (relational) database guy this talk was fascinating and scary. Relational databases don’t work in the cloud. Period. Geir explored plate spinning on EC2, Google’s BigTable, Amazon’s SimpleDB and 10gen’s Mongo data persistence platforms. It’s a different world now. “Eventually consistent” is my new, favorite term. Bottom line is we need to think about this problem from a new perspective and develop new solutions.

Scaling Meebo : Sandy Jen

The only women geek presenter so far. Sandy did a great presentation. Ironically, in my mind she was the geekiest as Meebo is a C/C++ application. She cautioned us to carefully decide when to be synchronous and when to be asynchronous. She confirmed a personal truism for me: Nothing simulates real life like real life. Load testing can provide valuable insights, but you don’t know if it’s going to work until you let your application loose. Also, look at alternative to Apache. lighttpd rocked their world. 

Alix Iskold :: Amazon Web Services

They rock. Why?

• Pay per use model
• Instant scalability
• Reliable/Redundant/Secure
• Simple REST/SOAP API
• Amazon’s Experience and Commitment (overlooked and unappreciated)

When we think about the usability of the products that we sell, it’s because we have come to recognize that usability affects user perception of our products and, ultimately, sales. When consumers don’t find a product usable, they have unfavorable reactions that range from not using the product to returning it, to blogging about their complaints to steer others away from buying it. We’ve learned to take usability seriously, and put a certain amount of effort into making sure our designs are well thought out. When it comes to bringing products into the organization, can we make that same claim?

The implications of implementing a content management system (CMS) not vetted for its usability can make it a disruptive and costly endeavor. The idea that users will simply adopt a technology implementation is idealistic, but often does not bear out. Human nature is to take the path of least resistance, and when an application puts barriers in the way of accomplishing a task, a user is likely to fall back on tried-and-true ways as the means to a speedy end. When a naturalistic system is presented, i.e., the system is made to work in a way more natural to humans, users are far more likely to adopt the system. I’ve watched users, particularly when under pressure to get something done “right now,” or by quitting time on Friday, to bypass technology with system-based processes, in the interest of expediency. They may even intend to redo their little shortcuts “the right way” when they return Monday morning, but of course, by the time Monday rolls around, they’ve either forgotten or gotten caught up in work-a-day pressures that deprioritize the correction of a process they see as inherently broken.

Ultimately, system non-adoption or non-adherence costs the organization in several ways: loss of time, loss of content accuracy, and ultimately loss of the very efficiency that the system was put in place to address. That can translate into lost hours, lost productivity, and, in organizations sensitive to the possibility of potential lawsuits arising from content irregularities, an increased risk factor.

Testing a content management system for usability before its implementation is not unusual, and should be part of the standard due diligence undertaken by any organization considering a move to content management. System usability can be tested at several steps during the presale phase.

The first usability test can be done as early as during the demo, where you can watch for obvious usability problems, such as illogical sequencing of steps in a process, or interface buttons or commands that require jumping around or opening multiple windows at odd times during a process. The next test can be done once you’ve developed your use cases to present to the shortlisted vendors. In the ensuing discussions, the vendor should be able to demonstrate how you would accomplish specific tasks, based on your use cases. Because a CMS may have significant customizations for your organization, a coherent, end-to-end test is not likely, but the vendor should be able to isolate common tasks for testing. The last, and most extensive, test should be during the proof-of-concept, when the system you’ve chosen has been customized and installed for testing. This is the last chance to get any usability kinks worked out of the system. At this point, you shouldn’t be testing for the obvious - that should have been done before signing on - but you should still have the option to put the application through its paces to ensure that internal users can get their work done with ease.

Putting effort into getting a usable CMS goes beyond the obvious need for driving efficiency and accuracy. It says that you value your internal users enough to ensure that they have a toolset that works for them. Usability in a CMS creates a win-win situation, and that goes a long way in the workplace toward system adoption.