Gadgetopia

WhiteHouse.gov Goes Drupal : Interesting.

WhiteHouse.gov has gone Drupal. After months of planning, says an Obama Administration source, the White House has ditched the proprietary content management system that had been in place since the days of the Bush Administration in favor of the latest version of the open-source Drupal software

Can Java CMS match the PHP ones? : This is a very interesting post from a Java development community.  You can sum it up in this excerpt:

Maybe while the Java world was engaged in talking of high end, super techie stuff, with the words ‘enterprise’, ‘transactions’ and ‘SOA ‘embedded in every sentence, the PHP guys actually went out and created a lot of simple yet very useful software.

Introducing The Dynamic Data Store : EPiServer is shipping a handy new feature in CMS 6 which provides for data storage of…whatever.

[…] storing data in a database using Entity Framework or NHibernate requires you to design and compile a class when developing your application. This works really well when you know the shape or structure of your data at compile time. EPiServer CMS has a few features where the shape or structure of the data isn’t actually known until runtime.

The Dynamic Data Store is very key-value-ish, like Amazon’s SimpleDB or Google’s BigTable.  It gives you a simple place to store variably-shaped data when building your apps, without having to roll new tables or build ORMs.  There are so many times when you just want to store some random piece of data, and the Dynamic Data Store gives you a simple way to do that, and get it back out, strongly-typed, even.

The comments on this blog post are interesting – there are a lot of people expressing reservations that developers will mis-use it, which is understandable.  In everything, it’s all in the execution.  Anything can be mis-used, if you’re careless.

Allan has written a handy example to store ratings of a certain page.  He wrote a simple “Rating” class, which has a property for the page to which it’s applied.  Then he wrote a couple extension methods so you can get this information directly off EPiServer’s core content object.  In the end, he’s built a feature that looks as though it’s built right into EPiServer and has an infrastructure behind it, when really it consists of nothing but a half-dozen methods and perhaps 20 lines of code.

Gilbane Boston 2009 - Content Management Conference: I managed to wrangle a speaking slot at Gilbane Boston on December 1-3.  I’m going to be giving a shortened version of my Chicago talk entitled “Content Types: The Building Blocks of Your Content Model.”

COPE: Create Once, Publish Everywhere : Here’s an interesting article from NPR on what they call COPE – Create Once, Publish Everywhere.

COPE is the key difference between content management systems and web publishing tools, although these terms are often used interchangeably in our industry. The goal of any CMS should be to gather enough information to present the content on any platform, in any presentation, at any time.

What they’re talking about is storing content in such a way that the final presentation layer is unimportant.  In fact, they differentiate their “CMS” from what they call “WPT” — “Web Publishing Tools.”

This is important – page through the SlideShare presentation on the page.  In it, they show the editing interface where they put together the story, and they show all the different forms which came out of it, from Web to iPhone.  Great examples of presentation-free content management.

In reading this, I was really stuck how similar it is to the post I made this spring called Beyond Web Centricity in Content Management.  I said:

[…] sometimes we (as Web developers) get too caught up in the “Web” part. Sometimes we get very Web-centric about our content, when we really should be looking at content from a completely presentation-free perspective.

The NPR article includes an extensive graphic explaining their different layers of their storage system and where items are cached along the pipeline.

Why do WYSIWYG editors suck at invisible, surrounding elements?

I’m evaluating a design right now to quote a content management implementation.  One of the elements involved arbitrarily shading an area of the page.  The HTML jockey in me says, “Just wrap that section in a DIV…”  But the CMS integrator in me knows that the client is going to be doing this in a WYSIWYG editor, and how do you do this?

One of the problems is that it’s a somewhat abstract thing for content editors to understand – they don’t know anything about HTML and tags, so they can’t grasp the idea of some invisible, surrounding…thing, around their other content.

WYSIWYG editors don’t help.  Try to find easy functionality for surrounding other content in a div and then – and here’s the kicker — putting a class or an ID on that DIV.

If you end up finding or configuring this, then you have to explain it to the editors.  It becomes a training issue, because it’s much tougher to understand than just, “Write some text there…” or “Put an image there…”

So, what ends up happening?  Tables, baby.  A single-row, single-column, single-cell table with a class on it.  WYSIWYG editors have all sorts of functionality for tables, and they show them visually very well in a way content editors understand.

A little sad, though.

Rant over.

Intranet in the cloud : A nice rant about how more companies should host their intranets externally, rather than inside their own infrastructure.

I was recently pressed on the subject of a “hosted intranet” and why an organization shouldn’t outsource their intranet to “the cloud.” God forbid we let professionals who know what they’re doing maintain our second-rate, after-though, cost-center of an intranet!

It is baffling to me that the intranet isn’t hosted externally for more organizations. Well, I’m well versed with clueless executives with knee-jerk reactions around “security”, privacy, and “the way things have always been done” but I guess I’m naïve to have faith that more would start to embrace the 21st century. If these dolts can Facebook then surely there’s hope, right?

At first glance, this fits with my experience.  Intranets should be developed under the auspices of Business Communications, rather than IT.  Blend does continuing technical maintenance of two large-ish intranets, and in both cases, we don’t work directly under IT.  The IT staff of the companies involved are very helpful, but the intranet is not their primary concern.  They only get involved when there’s a problem.

However, my second reaction to hosting an intranet in a cloud is that intranets often (hopefully) get embedded deep into the technical infrastructure of a company.  With any luck, they’re more than just tacked-on news article generators, but instead integrate with internal tools and resources like scheduling, task management, Active Directory, messaging, and the like.

Integrating a system this deep can be hard to do remotely.  I was just looking at Amazon’s Virtual Private Cloud the other day, which puts a cloud of machines local to your network.  While this would certainly work, there would likely be latency issues, and you have to ask what the point is, then.  If your intranet is crippled when it can’t talk closely with other, internal systems with crazy-fast response times, then what’s the point of having it in the cloud in the first place?

Nine Mistakes That Turn Your Corporate Intranet into a Ghost Town : I really enjoyed this article.  It’s full of some good, practical advice.

Mistake #2: Creating a one-way communication platform: Intuitively, it doesn’t make sense. Tight controls around who can publish, and strict policies and heavy approval processes only stop people dead in their tracks. If you make it easy for people to contribute and publish information, they’ll gravitate towards the intranet, not away.

This post goes back to my post from years ago entitled The Three Types of Intranets.  So does the point below:

Mistake #5: Downplaying the importance of integration. […] the primary value of an intranet lies within its ability to integrate data from a variety of applications for easier management, accepting anything less would give you little more than a fancy Web interface.

Let us now praise metators : Tony Byrne succumbs to use of the word “metator.”

Metators are not just found among corporate web teams. Records managers have been dealing with metadata for decades. Now, you might think of your enterprise records manager as some corporate ninny who makes you clean up your virtual bedroom. In reality, she is organizing and processing large volumes of information on behalf of the enterprise, its customers, and ultimately for you, too. She is, in short, a metator.

Bob Boiko coined this word long ago – it’s a portmanteau of “editor” and “metadata.”  I’ve loved the idea of it since I read about it in the first edition of The Content Management Bible, so many years ago.  I resist using the term because it’s really awkward to say (seriously – try saying it out loud in a sentence).

The idea is that there’s an editor who isn’t so much concerned with dotting i’s and crossing t’s in an actual piece of content, but more concerned with figuring out where that single piece of content fits into the larger picture – how it relates to other content, and where it should fit in the overall scheme of the information architecture of an organization.

A metator is a librarian, really.  Someone who assumes responsibility for ensuring the all the bits of information in a domain is intelligently organized in relation to each other.  An actual librarian doesn’t read every book, but they know where the books of beekeeping are, and why they’re in that particular spot, and why books on yachtmanship aren’t in the same place.

For a large-enough organization, this role is critical.  Content editors turn out reams of content, and the last stop in the workflow should be a metator who effectively puts the content in his wheeled cart, and pushes it into the stacks to be shelved in the right place.

Content Management Systems just don’t work. : This is an excellent post about something we’ve discussed before – is a “boxed” CMS really worth it?  For instance, in this excerpt, the author is struggling with the decisions that the vendor or platform makes for you:

See— the problem with a full scale Content Management System is that it has too many opinions. Those opinions were though of by somebody other than you and the needs of your organization. The more developed a content management system (or any piece of software, really) the more “opinions” it has. And the more “opinions” it has, the more likely one of them is going to really tick you off.

I can relate to this.  We work with one system in particular that makes an astonishing array of presumptions about how you’re going to use it, and if you try to step outside those presumptions, demons fly out of the abyss and try to suck your eyeballs out.

This goes back to a previous discussion we had about Content Management as an API.  In that post, we had a great experience with hand-rolling a CMS.  Sadly, in another situation it was the exact opposite – we tried to hand-roll something simple, but the client wanted more and more “CMS-ish” features, and there came a point where we realized we had spent so much time and effort that we could of purchased a commercial system and been better off.

For me, the solution is a boxed system with a great API.  In fact, ensure that the system is built from the API out, rather than the interface and publication layer in.  For now, EPiServer has filled this need for us.  eZ publish is good too, and Ektron’s API is getting better and better every release (though they’ve had the distinct disadvantage of backing the API into the product, which makes it so much harder and longer, as they’ve been fleshing out this API for about four years now, and are just now getting close to done with it….)

So, in the end, I don’t agree with the author’s contention that you just need a good Rails/Django developer over a boxed CMS.  He says it’s an over-used point, but I still believe you just end up re-writing too much functionality in the end.

Web content migration: disastrous strategy : Gerry McGovern has a great plan for solving the intranet content problem – don’t migrate your old content. Abandon it and start again.

Taking your old intranet content and migrating it into a new software system is doomed to failure. If your website isn’t working then ask this question: why isn’t the website working? Is it because of the technology? Is it because of the graphics and the layout? Or is it because of the content? Nine-times-out-of-ten it will be the content.

Are you paying competitive hourly rates? : J. Boye did a survey of the rates charged by content management integration firms, mostly in Europe.

The values quoted here are in Euros, and the current exchange rate is 1 Euro = $1.42.  As such, system integrators are expensive, it turns out.

Blend charges a list rate of $125/hour, which puts us well under any rates quoted on this page.

Via Seth.

Open Source CMS Award:Packt is launching their annual open-source CMS contest.  This year, I’m a judge in the “Overall” category, but with Drupal and Joomla moved to the “Hall of Fame” and not eligible in the category,  it’s anyone’s game.

The 2009 Open Source CMS Award nominations have begun. Nominate your favorite CMS for the appropriate categories today and help them win their share of $24,000! If you’ve benefited from an open source CMS and would like to give something back to the team that made it happen, now is the time!

Judging this is, for me, a little grueling.  Every year, I download, install, and try out every single candidate system.

A long time ago, I wrote a post about how the interface to your app should be removable – you should be able to lift it off, and have a competent enough API underneath to still work with the app.

eZ publish is very good at this.  All their PHP code will run from a command line.  Ektron, not so much – to my knowledge, Ektron’s API will only run in the context of the Web server.  And they’re not alone – I would say the majority of CMS are like this.

I’m probably nitpicking here, actually.  But the ability to run a program outside of the context of the Web server is usually a pretty good indication of the general strength of the API and how it’s been architected.

Like eZ publish, EPiServer has strict separation of their API and their interface, and here’s the ultimate manifestation of that: a command-line interface to an EPiServer CMS.

Written by Magnus Stråle, this allows you to browse an EPiServer content repository from the command line – you can “cd” through the tree, list “files” (really content objects), etc.  I played around with it last month at EPiServer’s new digs outside Chicago, and it’s kind of neat.

But…also kind of pointless.  I mean, there’s not much you can really do with it, and I’m sure Magnus knew this.  In truth, I suspect he wrote it as a semi-comedic exercise – a gee-whiz bit of functionality to show off at a conference.

But, it does demonstrate the point I made two years ago:

When building a new piece of software, you really need to completely divorce the interface from the API. You need to get in the mindset that your app is really just a data store and a set of logic modules that do something. That is your application.

At the same time, you can build an interface that lets a human interact with your application. This an obviously very important piece, so it should get at least as much attention as the application itself. But never forget that the interface is layered on top of the application. In a perfect world, it can be lifted off and thrown away, leaving a fully-functional API underneath.

In that sense, it’s awesome.

Trends: Thinking beyond the RFP: This discussion of RFPs by Kas Thomas (otherwise known as “the guy who took my job”), provides fantastic advice on writing RFPs – don’t write requirements, write the beginning of stories and invite the vendor to finish them for you.

[…] write a user narrative or concrete scenario for every one of your key requirements, and demand a narrative answer in response. For example, rather than ask whether a product natively supports delegation of authority in workflows, compose a concrete user narrative.

“Cathy, the Managing Editor, has the necessary rights to designate authors for stories and reassign stories from one author to another in her department. Cathy will be traveling frequently on business, and in her absence she wants her assistant, Bill, who does not have Managing Editor rights, to be able to assign and reassign stories in her stead. Describe the steps that Cathy would need to carry out before she goes on vacation, including any GUI features Cathy would use, to delegate the necessary authority to Bill for a period of N days. Describe any administrator or developer interventions that might be necessary. Describe what actions Bill will have to take in order to act as Cathy’s proxy.”