September, 2008

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.

Google Chrome might seem like old news already, but based upon attendance at a bonus session this morning by Ojan Vafai, a developer from the Google Chrome team, there is a LOT of interest here at the conference. Recall that Chrome was released three short weeks ago!

Ojan described the motivation for Google to develop their own browser. Their developers were frustrated by the current state of browser stability and performance and the difficulty of building good web applications. They wanted and needed a stable application platform to develop and deliver great end-user applications. After surveying the current technologies they determined that the current providers of browsers were not keeping up with the needs of web applications. They decided to build their new browser on top of WebKit, Apple’s open source web browser engine.

Google’s plan for Chrome:

• Stability :: A browser that doesn’t crash. Period.
• Performance :: Browsers should load fast, be good citizens with respect to memory management, render html quickly and accurately and efficiently execute javascript.
• Enable Web Development :: Be compatible and consistent within standards and across platforms; provide good tools for developers.

Fraser Kelton gave an interesting talk on some ideas he has developed around some unintended side effects of this Web 2.0 thing. He outlined four trends that have the potential to create big problems for the adoption of new technologies. 

1. Open source and the commoditization of hardware: The costs of entry are so much lower today and as a result there are many, many, many new startups. Many of them are not good.
2. API’s and <blink>cloud computing</blink>: Small companies can stand on the shoulder’s of giants. They are trying to leverage existing innovation but most only offer a single “new” feature and since it is relatively easy to do, there are many copycats.
3. Blogs and aggregators: There is a tremendous increase in the velocity, frequency and volume of information. There is simply too much information about new companies to even attempt a thorough vetting.
4. Social features and read/write web: User generated content is a great thing, however, it does create a lock-in situation for many users. If you have been an avid user of Flickr and have built a network up around your photos you are unlikely to want to move to a new and better platform. Not a technical roadblock per se, but definitely a hindrance to innovation and new platforms in certain markets. Anyone up for developing a new and better photo sharing site?

Albert Wenger, a VC from Union Square Ventures gave a great talk on <blink>cloud computing</blink>. So what *is* cloud computing? A mere buzzword? The latest trend? Clearly there is something going on here. There was a huge public outcry when Dell attempted to copyright the phrase “cloud computing”. 

The concepts behind cloud computing have been around for over 40 years. John McCarthy, a computer scientist and inventor of Lisp stated in 1961:

“If computers of the kind I have advocated become the computers of the future, then computing may someday be organized as a public utility just as the telephone system is a public utility… The computer utility could become the basis of a new and important industry.”

The industry has touted utility computing and grid computing and neither technology was widely adopted. Virtualization may be the technology that will make cloud computing a reality. Tony Chung has a nice write up here.

Wenger defined four principles which define cloud computing for him:

1. No more machines! (Amazon’s EC2 is therefore not in the cloud)
2. Code over configuration (Cloud computing should not require the “arcane knowledge passed on by the secret society of sysadmins”)
3. Applications can scale without unreasonable demands on developers
4. Making it easy to bring web services together

I started out this morning at People Powered Products … but it wasn’t what I thought it was about. A quick permanent redirect across the hall landed me in Knowledge Sharing at Ideo presented by Doug Solomon and Gentry Underwood. Much more interesting for me. This talk outlined a year long project at Ideo to foster collaboration and knowledge sharing across the company. Knowledge workers face ambiguous and dynamic problems on a daily basis and must adapt and be innovative in real time. The goals of the project were to empower teams to learn from one another, connect geographically seperated offices and enable global collaboration. They came up with 7 lessons that are transferrable to other organizations:

1. Build pointers to people
2. Help people help themselves (wikis, portals)
3. Keep it simple and intuitive (wysiwyg, LDAP, auto-navigation)
4. Go where people already are (leverage existing blogs, email distros)
5. Reward individual participation
6. Aggregate the myriad of voices (self organizing streams of information)
7. Iterate early and often (Fail early and often to succeed quickly)