Hippo CTO blog - Arjé Cahn

Is Responsive Design Too Much Response And Not Enough Design?

2012-05-14T08:38:22Z

At Hippo we’re certainly seeing the explosive growth of companies investing in delivering content to multiple devices. And, while we mostly think of smartphones – it’s not just those devices that are part of that growth. Last holiday season, studies found that the total share of people owning a tablet device almost doubled. In fact, if you’d like to learn more about this trend – we’ve recently released a whitepaper ("Mobile Content Optimization - Content Marketing on the Go") describing how the priorities of creating content for mobile and desktop devices are beginning to shift.

One idea that has gotten a tremendous amount of attention is Responsive Design. If you’re not familiar with the term – it became popular after Ethan Marcotte published an excellent post on the subject on A List Apart web site back in 2010. That post subsequently inspired the book by the same name.

We know that today it’s not enough to make your Web strategy compatible with Mobile – you have to optimize your content for Mobile. Smart marketers and communicators are taking specific content strategies to their mobile channels. But, while Responsive Design has its place – and will work very well – it is only one piece of the puzzle for the enterprise to manage Web Content.

See, from content MANAGEMENT perspectives – Responsive Web Design works best when your WCMS is only capable of managing one channel. As a publisher with this kind of WCMS, you’re inherently depending on the responsiveness of CSS Media Queries to adapt the content and design to any device. For large enterprises – defaulting to this approach can actually mean LESS efficiency, LESS flexibility and MORE costs.

Let me explain what I mean:

Responsive Web Design Challenges

There has been a lot written – and some of it wonderfully well thought out on this subject. I would absolutely recommend Luke Wroblewski’s blog on the topic among others. Luke points out correctly, that while Responsive Design is one way of tackling the challenge – it’s definitely not the only way. And I’d like to take the opportunity to expand on that by pointing out some of the challenges from the enterprise web content strategy point of view.

1. Downloading Is An Issue For Both The User AND A Cost To The Enterprise

Despite your device or internet speed – when you access a Web site using Responsive Web Design, the totality of CSS, code and images that are on the page are downloaded at their fully rendered weight for the desktop experience. And it’s then the device and onboard browser’s job to resize and optimize that page as the screen shrinks and expands. But using this strategy means that you’re delivering (and making the user download) perhaps 80% more than is necessary for the experience.

So, let’s just take images as an example. Let’s say we have one page with six images that total 210K for the desktop experience. If we were to instead resize those images and deliver them in a channel-specific way they might be a total of 45K. That means there’s a 165K extra payload for the mobile visitor. Now, when you look at one visit and one visitor this doesn’t mean much (although in some cases – especially with data plan caps - this can be a real cost to your audience).

But it gets even more interesting when we look at the enterprise and costs. Using that same math – if we assume 5 million visitors per month (very common for Hippo enterprise customers) and we assume 20% of them are arriving via mobile device – that means 1 million visitors are downloading that extra 165K. Meaning an extra 165 Gigabytes of data per month delivered out of the data center. And, remember that’s just ONE PAGE! And, by the way, we didn’t even get into the extra CSS, Javascript and other code that also has to be delivered to accommodate the Responsive Design. These are real costs to the enterprise.

2. For Mobile Users Speed Counts

Mobile is becoming a huge piece of the e-Commerce pie – and speed absolutely is a huge predicator of that. Audiences are now expecting content to arrive in their mobile device as fast (or in some cases even faster) than their desktop counterparts. There have been studies done recently that suggest that an enterprise generating $100,000 per day could actually be losing $2.5 million annually with just a 1 second delay in their site.

And this isn’t just ecommerce either – over the last year Google has made more adjustments to their algorithm and speed is, more than ever, a critical factor in how websites are ranked in Search Results (and this includes mobile). Additionally, it’s also clear that faster sites don’t just improve your user’s experience; they can also reduce your overall costs.

Despite the advancements being made on the power of handheld devices – which are becoming themselves handheld computers - wireless networks still are still not there. A recent study done by Ofcom showed that while households using mobile broadband are increasing – it’s still less than 20% of the market. And, web pages still took, on average, 8.5 seconds to load on mobile – which is much slower than on fixed broadband.

This means that anything we do as an enterprise should be focused on delivering content to our users faster and more efficiently.

3. Responsive Design Doesn’t Take Context Into Account

Of course at Hippo, we are passionate about delivering contextually relevant experiences to audiences – and Responsive Design does not take this into account. Responsive design ONLY takes into account the device accessing the design – and more precisely only the screen size. For example, we need to be able to accommodate different TYPES of interfaces based on devices and input interfaces. As a web site that is optimized for desktop shrinks – so too must it also be optimized for “touch and swipe” interfaces rather than point and click. This is an important contextual layer.

Also, responsive design doesn’t look at location, connectivity speed, behavior and personal preferences. All of these can affect WHY a user wants to interact with content, and HOW.

For example, one of the examples that’s often used in Responsive Design is the Boston Globe website. Go try it. As you resize your browser window, it elegantly adapts using grids and media queries to eliminate content and reduce the design as you access it. But WHICH CONTENT SHOULD IT REMOVE? Using Responsive Web Design we have to decide which content to remove as part of the design process – not as part of the content consumption. Shouldn’t the AUDIENCE decide which content they want to view as part of the experience based on either their previously stated preferences, their real-time behavior on the site or even the context of where they are located? For publishers who only manage one channel that might seem like a “nice to have” – but for enterprises in today’s competitive world this is a definite requirement.

What’s The Solution

As Luke Wroblewski points out in his post – there should be multiple approaches to delivering content to multiple devices. One intriguing idea that he puts forth is RESS (Responsive Web Design with Server Side Components). He describes this as where “a single set of templates define an entire Web site for all devices but key components within that site have device-class specific implementations that are rendered server side”.

Now, I don’t want you to get the wrong idea. I’m not completely discounting the value of Responsive Design. It has its place. But, especially for enterprises, it’s not a one-size-fits-all solution. This gets back to the challenge that I mentioned in the beginning. Responsive Design is great when you are limited by your content management system to only managing one channel of content.

So, for example, if you’re blogging using WordPress, or using a solution like Drupal to manage one Web channel this can be an easy solution for delivering multiple versions of content to mobile devices.

But here at Hippo, we recommend a different approach – which utilizes our Context Aware Server. Using this, enterprises can manage channels in multiple ways – and in whichever way makes sense for their web content strategy. For example, the mobile corporate blog can be delivered using Responsive Design, while content from it is re-used on the ecommerce platform and delivered using a combination of a specific desktop channel, a dedicated mobile phone phone channel, an iPad optimized channel delivered as an “online magazine” and all across multiple languages and adapting in real-time as the user interacts with the content. Images, code and delivery is all optimized in real-time delivering only what’s necessary for the experience.

Ultimately, your content strategy should be a completely separated concern from the interface that is used to access it. Responsive Design blurs those lines a bit – and it’s important that we remember that it’s just one more way to deliver web content. And easier and “more fluid” doesn’t always equate to better or more efficient.

Join Hippo In Supporting Standards For Web Experience Management

2012-01-03T10:22:10Z

There has certainly been a lot of debate about Web Experience Management. Some analysts like Janus Boye have called it "meaningless vendor jargon". Some others like Scott Liewehr of Gilbane have said that understanding Web Engagement Management is "crucial to your business". Forrester has attempted to create its own definition – calling it "customer experience management". And, finally, others such as Julie Hunt – have written how Web Engagement Management even extends into the intranet of Enterprise 2.0 – and how content should be utilized to engage employees.

So here’s my take on it:

The trend in Web Content Management for the last couple of years has been Search Engine Optimization (SEO) - and it was all about getting your audience to your site. Period. Just make sure they find you. But then what? What happens once they get there? How do you keep them on your site? How do you make sure they come back later, how do you get them to start doing business on your site? How do you make your visitors fall in love with your site?

That’s Web Experience Management. It’s whatever comes after they’ve found you.

The trend is becoming clear. The web – and how we create, collaborate and consume content is becoming more personalized and contextual. It’s what makes people love your site. And, at Hippo we’re absolutely committed to helping our customers empower their audiences through contextualized web content experiences. We hope you’ll join us over the next year as these standards become reality.

We’re extraordinarily excited to be an instrumental part of a new technical committee as part of OASIS, the open standards consortium. OASIS has just announced that a new draft charter to establish the OASIS Web Experience Management Interoperability (WEMI) Technical Committee has been submitted. I’m very proud to say that Hippo is taking a leadership role with other member companies such as Adobe, Jahia, Liferay, Magnolia, Nuxeo, OpenText and SDL on this important committee.

In the charter – the idea of Web Experience Management is defined as an evolution of Web Content Management. Basically it says “where WCM provides the foundation for collaboration by offering users the ability to manage content, WEM emphasizes the importance of the delivery of the aggregated content into a total Web Experience."

Regardless of whether you think this is jargon, or just another word for “personalized" content – our belief is that developing standards for how this type of data can be made portable from tool to tool and how interoperability between different tools for content management, display, reporting, search indexing and meta data management all become an incredibly important factor for customers.

Our goal will be to agree on a simple domain model for WEM and, additionally, create an abstract set of standard features that would be commonly implemented by these types of tools. We will also be looking to identify future functionality that would be useful – but may not yet exist.

At Hippo we really believe that multi-channel content management is not enough. Through our continued work on the Apache Rave project – our new work on this WEMI standard – and our commitment to open standards and open source in general – Hippo is striving to make the Web a more contextual, personalized and empowering experience. As I said in the committee announcement:

“The ability to bring together different streams of information from disparate content systems using a standardized API is part of our vision for a more contextualized web experience. We intend to support WEMI in our Hippo CMS product line."

And, we hope you - our extended community - will join us in our effort.

The first meeting of the WEMI TC will be held on 16 Jan by teleconference, and a Call for Participation is currently open for OASIS members. If you want to join, please see the OASIS WEMI page.

Raving about Rave!!

2011-09-28T07:12:35Z

So, if you didn’t know – here at Hippo we’re doing some incredibly cool stuff with the Apache Software Foundation. One of the new things that I’m excited about is Apache Rave, a project currently undergoing Incubation within Apache.

Apache Rave is a new Web and Social mashup engine. Right out of the box it will provide an extensible, lightweight Java platform to host, serve and aggregate Open Social Gadgets and services – all through a highly customizable friendly UI.

It's like a portal - but without the portal. Instead of heavy weight, expensive, server-side Java portlets, Rave is taking a more modern approach focusing on client side rendering of Gadgets and Widgets.

I like the Rave concept because it’s built and targeted to be an engine for web sites, intranet portals and social network channels. I believe that these things will eventually blend into one thing - and become the building blocks of every website. I see more and more demand for portal like behavior in websites - as well as social aspects and personalization. Intranets have traditionally been very behind the firewall, but the trend is to move more and more of the organization's internal apps to the cloud. At the same time, people start to understand that a business really is and has always been a true social network - and that a more social approach to intranets is the future. Rave brings all this together. And I'm thrilled to be part of it!

Mark my words: in 5 years time, every website will be personalized and socialized.

The reason for starting Rave as an open source project within the Apache Software Foundation is to combine several existing projects and teams that have been working on projects focused on their own target audience and community but have (more or less) the same overlapping goals. Being one of the iniators, we plan to use Rave to strengthen our context-aware personalization and collaboration features for multi-site and multi-channel oriented platforms. This is why Hippo developers are activitely participating to realize this, adding our own knowledge and code from our content management background.

The goal for Rave is to become a lightweight and open-standards based extensible platform for using, integrating and hosting OpenSocial and W3C Widget related features, technologies and services.
In a truly trans-Atlantic effort, the Rave proposal brings together both US and European partners. These include:

MITRE Corporation (United States) - This company manages federally funded research and development centers.
Open Gateway Computing Environments project (United States) - NSF-funded collaboration between Indiana University, San Diego University, San Diego Supercomputer Center and Texas Advances Computing Center
SURFnet SURFConext Portal project (Netherlands) - Next generation collaboration infrastructure
OSS Watch (United Kingdom) - Open Source Software advisory service
Hippo – (Netherlands & United States) Open Source CMS & Portal provider
…and several other individuals.

The initial features of Apache Rave will include OpenSocial persistence and SPI implementation, gadget repository with life-cycle management, and OAuth support. The initial code contributions come from three Apache-licensed code bases: SURFnet SURFconext Portal, MITRE OpenSocial Enterprise Container, and OGCE: Gadget Container code.

We're working hard on a followup codebase donation from Hippo, which will provide a context-aware mapping engine, alongside content integration features.

Apache is open! If you think this is a project you should be part of, then don't hesitate to read the Getting Involved page and dive into the Rave :)

We’d love to hear your thoughts. Let us know what you think about the Apache Rave project and we’ll keep you posted as the project gets further along!

Tell us how we're doing... And win an ITunes Gift Card!

2011-07-18T11:47:21Z

Dear reader,

Thank you so much for being part of the Hippo Community!

We want you to know that we value your feedback a lot - it's what makes our community such a great place to be :)

We'd love it if you'd use the following form to let us know how you think we're doing. If you have any thoughts on what we should improve to make your life as a Hippo developer easier, then please go ahead and put it in. Anything goes. No fields are required - just give us as much info as you like to. And...

... we're giving away 5 €20 ITunes Gift Cards amongst the first 50 fully completed forms!

Thanks for helping us build a kick-ass content management system!

Arjé Cahn,
CTO, Hippo

We’re With You As We Ride On The Hippo Trail

2011-06-23T15:05:17Z

I’m a big believer that when you’re developing software, that your team and the process you use is much more important than your specific choice of technology. Our passion for developing community and teamwork is much more important than the applications we build.

And, we really strive to keep that community alive with our “extended team” (that’s you!) as well. We want every single developer and architect that works on Hippo CMS to feel like they’re part of something really cool – and ultimately really important.

I really want to stress that with our latest set of releases – including 7.5 and our newest 7.6 that we’re focusing a lot of attention on feedback that we’ve gotten both from beginner Hippo developers – all the way through to some of the most advanced developers out there.

Our whole goal is to innovate the world of Java Open Source Web Content Management – and certainly we know that developers are a huge piece of that. Over the coming weeks, I’m going to blog about some of these innovations in more detail. But in case you haven’t kept up with some of our latest developments - here are some of them under the headings that we’re most passionate about:

Open Source & Open Standards

Our passion for Open Source and Open Standards started 10 years ago – and we’re continually trying to stay innovative: from our most recent work and contributions to the Apache Foundation, to Open Social and our latest work with Surfnet and the MITRE Corporation. And, we’re listening to you as well. We heard you loud and clear. Some of the recent new things in Hippo CMS include:

Relaxed CND’s – making it much easier to set up document types
A New HST REST Engine – giving developers an easy and standard way of accessing all their content.
Run & Develop Easier With Cargo Support
JRebel Support to speed up your development cycle
CMIS Support adds interoperability with ECM Systems (see what we’re doing with Nuxeo)
Support for Spring MVC (also read this excellent post by Jeroen Reijn on Spring Android and REST)
Handling changes in a DTAP environment

Templates & WCMS Developer Support

Of course one of the biggest jobs as a CMS developer is to quickly support the business users and their need to “change” things and keep up with the latest technologies. From the expanded use of JavaScript, to HTML5, CSS3 and of course mobile and social interfaces - We’ve heard the community loud and clear that we needed to continually innovate.

The ability to support rich user experiences and mobile interfaces is becoming a “must-have” for Web content management systems. Our newest releases meet this challenge – providing Hippo CMS users the ability to develop any kind of HTML5 front-end experience that they wish.

Some of the other new things here include:

Hippo CMS Template Composer
Freemarker Template Support
Pugpig - ok, it may not a Hippo project - but it’s really slick framework for HTML5 driven tablet magazines that we’re currently experimenting with (did I forget to mention PhoneGap?)

Love For The Process

And, of course, as I said in the beginning – the real passion is to make sure that we’re helping developers to make the process easier and more efficient. So, we’ve added a whole new set of resources here for the developers. These include:

Our new Hippo Trail – which is a full set of documentation and videos that walk you through from taking your “first steps” all the way through to “Hippo Awesomeness”.
Automatic Export – which makes it so much easier for the development team to work together using a revision control system like Subversion.
Console Improvements – We’re adding a number of new enhancements here including auto completion.

As I said in the beginning – over the coming weeks, I’ll blog a bit more detail about some of these exciting new features and approaches. In the mean time, keep the feedback coming. We’re here for the community – and we want to see both you and Hippo shine!

Is JCR Dead? So What If It Is?

2011-01-13T14:35:33Z

Josette Rigsbe wrote an article on CMSWire asking the question "Is JCR Dead?". I wanted to quickly respond with my answer, which in itself is a question: "so, what if it is?"

JCR is an engineering standard that's been around for a number of years. It's low-level. It's used by developers to build complex applications, usually on top of a content repository. Content management applications - like Hippo CMS - have been using JCR for years.

And, that's the point. JCR is a standard for developers. It's not a standard that will help you reach out to your audience. It's not a publishing standard in a format such that your visitors can consume it on their laptops, mobile phones or whatever device they want to use. It's not a standard that's going to help your Web content be "context-aware".

This is what REST API's and other Web standards are for. Our view at Hippo is that we do JCR for CMS Developers, and Web and REST for your audience.

There is no "Holy Grail" of standards, or one standard to "rule them all". It's clear to us that the evolving world of standards moves continuously and we believe that a WCMS needs to be flexible and open enough to move along side them. And, because standards evolve, they have a life of their own. They come to life, evolve and eventually they die. It's a very healthy process. So, yes, JCR evolves and will one day die. Just like CMIS will evolve - and one day die.

But the death of a standard doesn't matter to our customers. Our customers want interoperability. Our customers want our systems to be able to communicate with each other and to be able to export content out of a CMS whenever they want to replace it with another system. Standards are good. They give you that interoperability. But open standards are like languages. It really doesn't matter that they evolve. All that matters is that we can communicate.

If you're deciding on a content management system, you shouldn't need to worry about the life and death of standards. What matters most is that you want a CMS that serves your audience. For that you need to look further than just whether any vendor slaps the JCR or CMIS sticker on their repository. Look for a CMS that has openness built into its DNA. A CMS should breathe open standards. Look for a CMS that thinks in terms of your audience and how to deliver content in the way they want to consume it - not how the developer decided it should be consumed. At the end of the day, an effective CMS not only stores content in a way that empowers the business to manage it; it delivers the content in a way that empowers the person at the very end of a CMS - the audience - to consume it.

The Dutch national government has a brand new website

2010-03-31T08:14:36Z

News from the Dutch open source camp:

"On March 31, 2010, the first version of www.rijksoverheid.nl went live. This common website for all government ministries will make the central government more recognizable and accessible." (source: http://www.rijksoverheid.nl)

"Starting in 2010, the Dutch national government will communicate via a single website: www.rijksoverheid.nl. The various ministries will be added to the website in stages. As of its launch on 31 March, 5 ministries are currently active on this website. During the course of the year, the other ministries will be added." (source: http://www.rijksoverheid.nl)

I have to admit: our government has been very ambitious right from the start of this humongous project. The goal they set for themselves is not an easy one: to open up all information, in every possible way, using "Open Content, Open Data, Open Standards and Open Source".

It's no secret that this new grand website is based on a large set of open source components, among which many Apache projects, and of course my personal pride Hippo CMS. Hats off to Apache for being such a great open source community, and for being the foundation and source of inspiration for everything we do at Hippo!

"The government doesn't want to be tied to certain suppliers and licenses and therefore chooses for open standards and open source. [..] Using open standards will make it easier to exchange information with other government websites"

Congratulations to everyone who worked on this mega project, in particular everyone at ONS, Gerrit, Jettro, Michael, Gemma, all the JTeam guys, and of course the people here at Hippo: Bart, Berry, Frank, Ard, Stephan, Dennis, and the man who should receive an award for being the hardest working man in CMS business: Jeroen Reijn (maybe one day, he will :) ).

Hippo CMS 7.4 preview: version compare

2010-03-19T16:51:03Z

This is work in progress - but I got so excited when I saw it working that I couldn't resist turning it into a quick Friday afternoon demo video. This functionality will be released in Hippo CMS 7.4 which is scheduled for June, so I'm afraid I'm going to have to ask you for a bit of patience - but at least you'll have something to look out for :)

Suppose Joe is our author and he's working on a new article that he wants to push live. He requests publication, and sends the article off to his editor, Jane, for review.

I'm logging in as Jane now, and I can see the request that she got. Jane is fine with the article, so she pushes it live.

A couple of days later, Joe the author comes in again, and he changes some of that content he wrote before. And he requests publication again.

Jane logs in, sees the requests and wonders: What's new?

Hold it here - I need to explain some background. Of course we have versioning and history and all that. Every CMS does. But how easy is it to get to that comparison view? How many clicks do you have to perform to compare the current version of the document with the one that's online right now? And what kind of a view does it give you? How often do you do this? And if it would be *super* easy, wouldn't you just want to see that comparison view all the time? All in all, you're working with a team of editors in the same content pool and you need that contextual information about what's going on in the system, and who did what, where.

So that's what we did. We made it uber-super easy!

Click it - and there you go! That's what's new. Hippo CMS shows you the comparison view right there when you view the article. That is, when something has changed. It simply shows you the difference between the current version of the document and the one live on the website. How useful is that? If you need more information - you can of course dive into the version history, but this simple comparison view is probably all you need.

Again - we hope to be releasing this with Hippo CMS 7.4 in June, so hold tight.

In the meantime, let me know what you think - feedback is very much appreciated.

What's wrong with portals?

2010-03-11T08:50:36Z

This post clearly describes the problem that I see with all current portal implementations: they treat content as “just another application running inside a portlet”. When we stick to this paradigm, it will kill Portal. Content behaves very different from legacy apps, and simply offering a contextually disconnected content management portlet is not enough. Content deals with semantics and relationships: users expect a portal to be smart enough to render content that is related to the apps they see right there on their screen, and they expect content to be reused across different sections in a portal, wherever that makes sense. Not to mention user-generated content.

Wikis gave users the possibility to quickly create and collaborate on content, but they don't come with the visual application integration that Portals offer. And they lacked the degree of control of a decent content management system. Integrating Portal and CMS is more than just adding a 'content portlet'. Adding an in-context application to a Wiki page would be more in line with how users think. They navigate your online consumer portal, find a page that answers their question and then they want to act on it directly. The FAQ page on “How to request a new password” should render the “New password” portlet in-line with the article. This is just an example - but this is clearly the direction Wikis are heading as they're maturing towards something that resembles an integration of Portal and CMS, and they're leaving traditional Portals way behind.

Portal vendors need to move towards the Content Driven Portal. At least, this is direction we've chosen to go with Hippo Portal. Users want URLs that make sense, that say something about the information that can be found on a page. They want to pop the URL of a portal page into an email and send it to someone else and it should just work - within the appropriate security constraints of course. What applications are shown on the portal page should follow the context, not the other way around. People got used to this concept during the Wiki revolution, and they'll never want to go back.

2010: the year the E-Reader will become the content managers’ favorite productivity tool

2009-12-31T11:43:41Z

Flipping through my usability notes, I noticed one of our Hippo CMS users mentioned the following about proof-reading:

“There is no printing facility for content in Hippo CMS so everything has to be done on screen. Even if we could print, we can only see a single field, not the whole article, so it's a bit pointless trying to proofread this way. This leads to long periods of time staring at a screen. It's also very difficult to spot typos on screen, leading to potential loss of quality in copy.”

Exactly. Often enough, also I spot typing errors only after having printed out my text (like this blog post), and walking through it again while commuting on the train. The letters start to dance before my eyes when I’m behind a monitor for too long. Sometimes it helps a lot to just put your text aside, do something else for a while, and then return to it on a quiet moment to walk through what you’ve written. So, why not implement a printing functionality in Hippo CMS, to allow authors to take their text with them? Everybody got so used to printing out Word documents anyway, that it baffles me that this idea had never appeared to me before.

So I put the print function on our roadmap.

But somehow, it feels wrong. What happened to the paperless office? It’s almost 2010 (it’s the 31st of December, 11:45 in the morning, as I write this), Kopenhagen happened only a few weeks ago, I’ve been driving the most economical car on earth for years, and I use the printer as little as possible. I don’t want to have a tree cut down for me to be able to proof-read my blog post!

Enter the e-reader. 2009 was the year of the e-reader. A number of those devices already boost a keyboard and the possibility to add annotations to texts, to store them and synchronize them with your PC. And every modern writer nowadays carries an e-reader to read their books anyway, right?

So here’s the thought: let’s make a tool that allows you, after a long day of writing, to take all the texts you’ve worked on with you on your e-reader. You grab your reader again when you sit on the train, where you walk through all passages for typos and make annotations. The following day, you import all those changes back into Hippo, or maybe you’ve already sent them to the content repository over wireless email.

I don’t know whether the latest generation of e-readers are already open enough to share annotations with a content management system. Maybe we’ll have to wait for that to happen in 2010. But at least I found a very good excuse to rush downtown and treat myself with another gadget to go try it out!