September 18th, 2008

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.