Gadgetopia

Content Modelling: It’s kind of eerie how similar this series of posts is to my presentation.  Especially the third one, where he talks about the reasons to model content.  This guy and I are seriously on the same wave-length.

Below sea level is where the content lives. The more complex the site and/or the amount of content there is, the greater the need to model the content. Content modelling is the process of creating and maintaining a content model. A content model is a representation of your information. This could be a diagram on a whiteboard, a pile of cards describing your products and services, an excel spreadsheet, or a fancy content modelling tool. All or none of them may be appropriate for your particular situation.

Great presentation on content modeling: Seth made some nice comments about my presentation.  He also cut to the absolute core of the situation with a point that I’m somewhat astonished I didn’t make in the actual talk.

This is why evaluating the content modeling facilities of a CMS is so important before buying it (emphasis mine):

The reason why I find this topic so important (aside from the fact that I am a recovering DBA myself) is that content modeling capability is one of those difficult to change characteristics of a content management system. It is what I call a “load bearing wall” in the customization of a CMS. That is, while it may be possible to remediate a content modeling limitation, all the buttressing required may make such an effort impractical. Content modeling architecture is so difficult to change, in fact, that the products themselves tend to live with what they have and change very little in this area

I forgive him for stealing the term “load-bearing wall” in relation to content management.

Content management authors and consultants are obsessed with “metadata.”  You “add metadata” to your content, apparently to describe it and make it easier to organize, or something.  You have “metadata” this and “metadata” that.

But here’s the thing: what is “metadata”?  And how is it different from “data”?

When you first start learning about content management and start reading books written by people like Rockley and Boiko, you keep hearing about “metadata.”  You get confused about this.  What is it?  How is it different from just good ‘ol data?

I examined this question in the middle of a session at Web Content 2009.  I don’t remember the session, but I remember asking a question which launched into a discussion of just what metadata was.  After this, I exchanged a couple Skype’s with Seth about it, and I think I’ve come a distinction.

Metadata is data added around content that cannot otherwise be structured.

Content management systems have their root in document management systems.  For these system, the concept of “metadata” makes sense.  The binary file – Word document, or whatever – was the “data.”  You couldn’t add any structured information to this, so you tacked on “metadata” around it to help describe it.

I find another example of this with Ektron.  Way back when, Ektron didn’t do structured content (let me emphasize that this was a long time ago).  So, even today, when you edit content, you have a “metadata” tab that you can configure to contain certain fields of structured information.  You did this because you couldn’t add structured information to the HTML – HTML just doesn’t hold that kind of information.  So you have the “data” as the HTML, and the “metadata” as the structured information.

So, in these causes, we have content that cannot be structured – a binary file or raw HTML.  To add specific, granular information to this, we have to have some other framework for it.  Enter metadata.

So, is metadata still relevant?  Not in most cases.  In mainstream Web content management these days, there’s no need to claim to have separate “metadata” because you can usually always structure your content now.  Data is data.  Content is designed to be structured, and metadata would just be pieces of structured data, just like your page title or your page body.

Why is this important?  Because the concept of “metadata” is confusing for people who have never had to use it.  There are people who have never been involved in pure document management situations where it made semantic sense to say “data” was one thing and “metadata” was another, so this concept doesn’t make sense.  In 99% of WCMS situations, there’s no difference.  Data is data.

I remember way back when I was ready Rockley and Boiko for the first time, I kept thinking, “What is this ‘metadata’ they keep talking about, and why haven’t I ever used this?”  And with Ektron, I never understood what the “metadata” tab was all about since I started using Ektron with structured XML right from the get-go.

In most cases, metadata is just data.  If someone disagrees, I’d love to hear an argument to the contrary.

Follow me for a second:

• eZ publish is from Norway
• Typo3, Sitecore, and Umbraco are from Denmark
• EPiServer is from Sweden
• Drupal is from Belgium (technically not Scandinavia, but don’t be so fickle…)

Can you think of any others?  And what is it with those people?  Do they have nothing to do but code during those long winter nights?

If you work with a development platform enough, you develop some weird, imagined relationship with the platform’s development team, even if you never meet them.  In working with the fruits of their labor day-in and day-out, you develop some mental picture of them, their general competence, and their mental processes.

Let’s consider two hypothetical platforms —

• Platform A is a never-ending pain-in-the-ass.  It never works how it should, it constantly drives you nuts, and it makes you want to throw your computer out the window at regular intervals.  It’s a mess of dead-end code, trainwreck APIs, and inexplicable architecture decisions that leaves you shaking your head in frustration a dozen times a day.
• Platform B is a joy to use.  It’s simple, it’s powerful, and there’s a background elegance to it that you identify with.  Every development decision slots neatly into the others, and the parts work together intelligently.  The platform becomes a force multiplier for you – your talents and capabilities are magnified by the elegance and intuitiveness of the platform, and you have success after success developing with it.

With either platform, you start to have visions in your head of the people who developed them.  The developers of Platform A are a bunch of barely-literate monkeys that couldn’t code their way out of a paper bag, and the developers of Platform B are Gods in Aerons – kings of programming that graciously cast their benevolence down on you.

I’ve worked with both Type A and Type B platforms extensively (sometimes both in the same day).  It’s made me understand how much of development is what I’ll call “feasibility speculation” and what effect those platforms and imagined developers have on it.

With development, and with content management especially, a lot of what you do is speculating whether or not a goal can be achieved.  So many conversations with clients start with, “Can we…” or “Is this possible…”  You need to draw together everything you know about their platform and figure it out.

In doing this, you often sit around and think, “Would the developers of Platform X have thought of this requirement?  Would they have accounted for it?”

With Platform A, your default answer becomes “no.”  You just assume that the people who built the platform would never have thought of that.  Their product has kicked you in the teeth enough times, and that you’re not even willing to put in much research time to find out.  If you do decide to research the problem, much more likely to give up early, because you just don’t trust it anymore.

With Platform B, you’re default answer becomes “yes” or something along the lines of “I’m pretty sure we can do that…” because you just know it will work.  You have this vision in your head of the developers as being competent and benevolent, so you just know they would have thought of just this situation.  Furthermore, you’re willing to put in some time to research the situation, because you have a great expectation of success.  When you do research, you’re very persistent because you know the decision is likely right around the next corner.

It’s this imagined relationship between you and the platform developers that drives success or failure.  Once a platform betrays you enough times that you stop trusting it, that’s tough to come back from.  They might make an improvement or two to the system, but there will always be this background uneasiness that the next disaster is right around the corner, and you should keep your expectations as low as possible.

It comes down to respect in the end.  Your opinion of a platform is, in large part, a reflection of the respect you have for the people that built it.  Once they lose your respect, your ability to do anything with their software is vastly reduced because your heart’s not in it anymore, and you’re not willing to give them another chance or the benefit of the doubt.  Your attitude sours, your expectations drop, and you stop believing that the platform can ever make you happy.

From there, it’s an almost impossible road back.

I just accepted a speaking slot at Web Content 2009 in Chicago in June. I’m going to be talking about modeling content — how do different systems handle the breaking down of logical content into manageable units? It’s something I’ve always been interested in, as the history of this blog demonstrates:

• Open vs Closed Content

• Discrete vs. Relational Content Modeloing

• The Envelope Pattern of Content Management

• Architecture and Functionality in Content Management

This is directly from the session brief I submitted:

• How well does a CMS allow you to structure content? Does it have any ability to manage different content types? Through configuration, or through custom module development?

• Can it structure content at all, or is everything an amorphous “page”? What are some common datatypes you might use to model content? What datatypes are offered by various systems?

• Can a system automatically generate input forms for your content? Can it validate these input forms? How usable are the forms? How well does a system allow you relate content to other content, and in what ways?

• Can you content pick up properties or attributes from context? Does the content object’s “place” in the content structure of the site allow you to derive information about it?

• Can a system allow you to easily compose content from separate component content objects?

• Can a system let you have repeating properties? Can you create “subcontent” to represent parent-child relationships between content objects?

I love to see some of you there. As we discussed a few weeks ago, this is a great conference for anyone involved with content management.

New Report: Drupal for Publishers: Seth Gottlieb does some really high-level consulting in the Big Media space — large magazines and publications you’ve heard of before. He tells them how to content manage their stuff, essentially. And if anyone has some hefty content management requirements, it’s these guys.

He’s writing a series of reports for publishers on various content management platforms and technologies. He just released the report for Drupal. I’m halfway through it, and at $100, it’s a steal.

The 24 page report is broken down into sections that explain what the different stakeholders (the publisher, the editor, and the developer) need to know about Drupal. The publisher’s section contains information about the time to market, availability of talent, cost, and the future of Drupal. the editor’s section covers functional aspects such as content entry, workflow, editorial control and general usability. The developer’s section discusses extensibility, security, performance, and developer resources.

I just want to make a quick pitch for the Web Content 2009 conference. I went last year, and it was a phenomenal event, full of great speakers and networking (what happened between the sessions was almost as important as what happened in them).

Stewart Mader is keynoting this year — he wrote “Wikipatterns,” which I read, reviewed, and really enjoyed. Ann Rockley is giving a session too. She wrote “Managing Enterprise Content: A Unified Content Strategy,” which is considered one of the seminal books in the field.

This year it couldn’t be at a better location — Gleacher Center of the University of Chicago. It’s right on the river, in the heart of downtown, just a few hundred feet from Michigan Avenue. You could get the downtown Chicago experience on a nice walk during the lunch break. The John Hancock building, Grant Park, the Art Institute, etc. are all within a 10-minute walk.

(I just got back from Chicago, and I stayed at the Springhill Suites — two blocks off Michigan Ave. — for $120 a night, which is a steal.)

I’ll be there. Hope you will too.

Here’s the problem with Web content management: 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.

(Fair warning: if you’ve working in ECM — enterprise content management — to much of any degree, this post is going to be a review.)

Consider an intranet. A company decides it needs a centralized “announcements” system — a communication vehicle to get information to various people in the company.

So, they grab some Web content management system and start adding “announcement” pages. In doing this, they need to specify things like menus and META tags and other Web-centric things. It is, after all, a Web content management system. We’re Web developers, and this makes sense to us — we view “the page above all.”

But, is this is the right way to do it? It strikes me that an “announcement” in the context of the enterprise doesn’t necessarily correlate to a Web page. It’s really a pure…nugget of information, uncorrupted by presentation. It has properties like a title, a body, an author, etc. that are universal. They transcend presentation.

So, what do you call a piece of information, unencumbered by concerns about its final destination(s)?

I think you call this — gasp! — content.

Dealing with our announcement in its most pure form, we can isolate the properties of it that are about it, rather than its presentation:

1. Title
2. Body
3. Publish Date
4. Expire Date
5. Effective Date
6. Author
7. Intended Audiences
8. Subject (a taxonomy assignment, perhaps)
9. Tags

These are all properties of the content that have nothing to do with how the content should appear in any particular medium. They are universal properties.

Now, I know what you’re thinking — isn’t this just the classic concept of separating content from presentation? Well, yes. But as Web developers who spend most of their time in WCM, we’re always viewing presentation through a Web-centric lens.

Why do we want to separate content from presentation? So we can make different content appear in different places on the site. Or so we can re-arrange a template without having to change any content. Or so we can have our designers work on HTML-ish markup while we devise a method to drop the content into to it.

But what if a page on some Web site isn’t the primary method of presentation? What if the content isn’t destined for a Web page at all? What if it will be consumed by end users in a half-dozen different formats, none of which involve a URL-addressable bit of HTML?

Back to our announcement, let’s consider for a minute all the things that could happen with that content. Assume, for this discussion, that this piece of content is about the north parking lot being closed on Friday for re-surfacing.

It could…

1. appear on the intranet.

2. be emailed to an internal mailing list.

3. be syndicated in an RSS feed.

4. be emailed to a third-party (the contractor, perhaps?)

5. be posted to an internal calendar.

6. be published in a department’s print newsletter.

7. appear on various LCD TVs around the building.

8. appear in other system — an interstitial login window (“Important Announcements!”) when customer services reps sign in, for instance.

9. be transmitted to other parties via a Web service or other method (press releases go to PRNewswire or something)

10. be sent to mobile devices via SMS.

Of all those options, only the first one has anything to do with a Web page.

In this case, what you want to see is the “announcement” be handled as pure content, then editors can add “presentations.” These presentations represent appearances of that content in various places and various media.

Each presentation has type-specific information that needs to be collected — information that’s not specific to the content itself, but specific to the medium in which you want the content to appear.

For example, if we have our pure announcement about the parking lot resurfacing, we can then choose to expose it to various presentation layers

• We want it to appear on the intranet, so we add a presentation for that.

  Presentation-specific properties: the section it should appear in, the title that should display in the navigation

• We want it mailed to all staff, so we add a presentation to an internal mailing list.

  Presentation-specific properties: the mailing list to send to, the “from” name and email, the priority

• Our IT group uses RSS feeds a lot, so we add an RSS presentation

  Presentation-specific properties: a list of RSS feeds it should appear on

• We want it to appear on some of the flat-panel TVs in the building, we add a presentation for that,

  Presentation-specific properties: the locations in which it should appear, the frequency of rotation in those locations (we decide to double the frequency on the flat-screen behind the receptionists desk in the north building (the building with the most people who park in that lot).

In this sense, we’ve created our pure bit of content, then we’ve linked it to several presentation mediums. Each presentation requires specific information about how to present the content — for instance, the intranet page needed META keywords, whereas the mailing list required priority.

Admittedly, all of this is a little specific to the enterprise. In a larger company, there are a lot more opportunities for presentation. There are mailing lists, and print newsletters, and the flat-panel TVs, and such.

For a public Web site, we obviously have HTML and RSS, and often email as well, but that’s about it.

However, here’s the story about how I came to write this post which will demonstrate why this is somewhat important for Web developers —

I was contemplating a new Web site for my son’s soccer team. In discussions with the parents and coaches, however, I discovered that very few of them would actually use it. They were used to getting information pushed to them over email — the coach would send these emails to about 40 people with all the details about the next game or practice.

It struck me that I could build a greatest Web site ever, and it would still be a huge step backwards. No one would check the Web site, and the coach would still be sending emails to people. It turned out that, contrary to my first Web-centric instinct, email was the primary presentation for the content, not a Web page.

Along these lines, I got the idea that the coach wasn’t sending emails or creating Web pages — he was creating “announcements.” This was a pure form of content, unencumbered by the actual presentation media it would end up it (and it would likely end up in more than one — email and Web for sure). In this case, it needed to be presented in email first, then perhaps archived in some searchable HTML format second.

For most Web sites, is this level of abstraction practical? Probably not. Gadgetopia has only two presentation methods: HTML and RSS.

But, especially in the enterprise, content has much greater reach and can appear in so many other forms that dealing with the content on a purely informational level can really help put it in perspective.

To what extent are potential content management customers able to separate a content management platform from a finished Web site? Let me give you an example —

I was running a demo of EPiServer the other day to a group representing a city government. Blend’s own Web site — blendinteractive.com — is built in EPiServer, so we often use this as a demo site to show them what the system can do.

What I was intending to show them was our site as a simple example of what EPiServer can be configured into doing. But, unbeknowst to me, they were looking at Blend’s site as the literal manifestation of what EPiServer was.

Part way through the demo, one lady asked me, “How would we add a link to that menu bar?” Thinking she was talking about navigation in general, I launched into a discussion of EPiServer’s implicitly-menued content structure.

Silence. Then, “Can we change that image up there in the corner?”

That’s when I realized that this particular group hadn’t separated (1) EPiServer the platform from (2) the Web site I was showing them right now.

I wonder how often this happens? For an end-user — someone who is not a developer and doesn’t build content-managed sites — the demo they download or interact with is the product as far as they’re concerned.

With a CMS product, you really have four levels of implementation:

1. The raw product.

2. A generic (sample) site built with the product.

3. A vertical-targeted generic site built with the product.

4. A client-specific site built with the product.

My demo audience was thinking they were getting Level 3, and they thought that’s what I was showing them. Sadly, in my head, I was showing them Level 2, and they were really buying Level 1.

In general, the further up the scale you go, the easier it is for laymen to understand and relate to their own situation. It also follows that the further up the scale you go, the easier it is to sell the product and your services.

Every vendor sells Level 1, obviously. On the other end of the scale, only integrators can provide Level 4, since that’s necessarily custom. But what of Levels 2 and 3? There are holes there where the vendor and the integrator meet and where either or both should provide some options.

This speaks to a few needs:

1. Vendors need to ship with solid sample sites (Level 2).

2. Vendors and integrators need to consider building vertical-targeted sites in advance of client needs (Level 3).

3. Integrators that demo these platforms need to be able to somehow explain the difference between the platform (Level 1) and a particular site built with the platform (Levels 2+).

EPiServer does ship with a sample site, though we’ve never used it, and it’s just as generic as the Blend site, so it probably wouldn’t have helped us.

Ektron has been a little more aggressive in this area. They have a series of what they call “Starter Sites” which are pre-built Ektron sites for particular verticals (Level 3). They have Starter Sites for:

• Intranets
• City government
• Hospitals
• Etc.

They all have specific themes, of course, but they go deeper than that into actual functionality designed around that vertical. For instance, the hospital site has a “Find a Doctor” feature pre-built. The city government site using Ektron’s mapping tools to provide a map of, say, construction projects.

Referring back to my list above, you’re now moving up the scale from Level 1 (raw product) to Level 3 (vertical-targeted site), so it should be conceivably easier for the prospect to understand, and easier for the integrator to sell.

There’s also an opportunity here for integrators. We can take raw products (Level 1) and massage them into intelligent demo sites for particular verticals (Level 3).

For instance, Blend could define a vertical (hospitals, for instance), then really examine it in terms of what specific needs that vertical has in a Web site. Then, once we’ve settled around a common set of needs, we could take an existing CMS product, customize it to meet that vertical, then go sell it.

By doing this, we’ve built-in two advantages.

1. We’ve obviously pre-built functionality that vertical might need.

2. We’ve positioned ourself well from a sales standpoint. We have a “conversation opener” we can use to cultivate business from hospitals, and we (hopefully) come across as experts in the field of hospital Web sites.

Both of these points are exactly what Ektron is trying to do with their Starter Sites. I have no idea how well this is working for them (but some people at Ektron follow this blog, so perhaps they’ll comment…).

I got an email a couple weeks ago about a new-ish CMS that was looking for partners. “Partners” in the CMS-world usually means integrators, like Blend, who specialize in a particular CMS.

CMS vendors like these relationships because their partners sell their CMS to clients, generally promote the market penetration of the CMS, and the vendor can call the partner in to help close a deal. If a deal is teetering on the question of integration services, the partner can swoop in, inspire some confidence, define a number, and help close the deal.

Blend, for the record, is an official partner for three vendors (all starting with “e” for some reason): EPiServer, Ektron, and eZ publish.

So, this vendor contacted me for a demo to see if we would sign-on as a partner. We went though a demo and the system was undeniably impressive. However, we we started taking about the partner program…there really wasn’t much there. While their system would have been fun to develop with, there didn’t seem to be much advantage to becoming a partner.

In the end, as a businessman (not a CMS fanboy, which I undeniably am), there is really just one reason for choosing to partner with a particular CMS: will it make us more money?

Yes, that sounds crass and denies all the joy and craftsmanship of being a student of content management, but you have to pay the bills, and, in the end, you have to make money to stay in business.

So, how does a CMS partnership make money for an integrator? Here is Blend’s experience, in no particular order:

1. Many partnership deals offer a mark-up of the list price. Anywhere from ten to twenty-five percent is not uncommon, so you get that off the top of any license purchase. This is even better when the CMS is only sold through partners (like EPiServer), not the vendor itself. In these cases, you make some money on strictly license deals that you wouldn’t get otherwise.

2. Good partnership deals refer leads to their partners. Ektron has excelled at this. They send us business all the time that they’ve prospected and almost closed, but that are hinging on implementation details. We provide a good implementation option, the deal closes, and everyone is happy.

3. You usually get marketing exposure on the CMS company site. For example, here’s our partner page at eZ publish (we don’t get dedicated, addressable pages with the other two). Some deals come through the door unsolicited just through exposure on these pages (though they’re often in the form of cattle-call RFPs sent to every partner the prospect could find).

4. Fast-tracked tech support, some of which is better than others. For instance, one of our partners has an engineer on Skype all the time that instantly responds to questions. Another one has a “special” ticketing system for partners, but I can’t see any difference in tickets I open through that method and tickets that go through the normal channel.

Those are the big four advantages Blend has experienced.

Now, some may say, what if the CMS is so-o-o-o good that it helps you close deals? Well, perhaps, but how does being a partner change that? I can still use a particular CMS without being a partner, so there’s no net advantage there.

What about professional services? Partnering with a CMS company lets you sell the professional services alongside the CMS, right? Well, yes, but again, I get this anyway, no matter what CMS we implement.

There are some other, softer advantages to partnerships that vendors tout:

1. Priority of feature requests. However, I highly doubt this ever actually happens. CMS versions are planned so far in advance, that feature requests — from partners or otherwise — probably have very little impact.

2. Specialized training. But, in the end, this is usually a precursor to the partnership relationship, not an advantage of the relationship. For both EPiServer and Ektron, we had to undergo training at our own expense.

3. A “closer” relationship with the vendor. There’s some validity to this — we have backchannel contacts at all three of our CMS vendors that have undeniably provided assistance from time to time.

4. The right to call yourself an “official partner” of that CMS. The right to name-drop, essentially.

So, back to the company that called me the other day. What did they offer?

• They offered 20% discount from list price. Not a bad cut, but it was mitigated by the fact that their product sold in the sub-$1,000 range, so how does that really help me? Two hundred bucks isn’t a huge margin, in raw dollars, and it disappears in comparison to a $20K to $50K professional services engagement.

• They offered a partner page on their site, which is always helpful. In these situations, I look to see who the nearest partner to me is, in geographical terms. We work all over the world, but when a prospect is seeking out a partner, they’re naturally going to do it by who is nearest to them, so, in this sense, geography is competition. This particular company has a partner in Minneapolis, which isn’t bad, but they had 50-75 U.S. partners in total, which is a big pool to compete in.

• They also offered some of the software benefits I mentioned: a “closer” relationship, fast-tracking of feature requests and support, etc.

This is great, but the biggest problem is what they didn’t offer: sales leads. According to them, most sales leads come directly in through partner pages, so they aren’t in a position to refer many leads directly to partners. In this sense, I’m at the mercy of a partner page on their Web site, competing with all the other partner pages, rather than a warm handoff of a qualified lead from their sales group.

So, in the end, we declined this one. Partly for the reasons I mentioned, but mainly because we have three partnerships already, and they’re working well for us. We’re not regularly in situations where we’re thnking, “Man, if only we had another CMS partnership to fall back on…”

CMS Watch says 40 percent of WCM vendors are embedding Lucene for search: Interesting that vendors are settling around an open-source standard for search.

A new CMS Watch report, The Web CMS Report 2009, has found that many web content management vendors are embedding their own search tools into the CMS, and nearly 40 percent have chosen the open source search tool Lucene, a project from the Apache Foundation that has proven to be very popular.

eZ did this with eZ Find. It’s based on Solr, which is a server based around Lucene. It works beautifully. Incredibly configurable.

XOOPS Teams Bury the Forks, Web CMS Code Reunited: This is interesting. Three XOOPS forks have come back together to be reunited into the main codebase. You don’t hear this enough.

It’s rare though, that these forks join back to the main branch. Rare, but not impossible. This is what has happened with XOOPS (news, site). They say its a sign of “visionary leadership” that has attracted not just one, but three of the XOOPS forks to come back […]

Good for them.

A month or so ago, my buddy Jakob Nielsen announced his 10 best intranets. Here’s an interesting point he makes:

Most impressively, fully half of the winning intranets used SharePoint, especially the recent MOSS platform (Microsoft Office SharePoint Server 2007). […] SharePoint use has grown dramatically in recent years. This is particularly impressive given that, from 2003–2006, the winning intranets didn’t use earlier versions of SharePoint at all.

I’ve wondered what the future might be for non-Sharepoint intranet technologies in Microsoft shops. Sharepoint often falls under existing licensing, making it effectively free, and it deeply integrates with everything else in the enterprise. Plus, it’s maturing quite rapidly.

What does this mean for traditional WCMS tools? Are they still relevant on their own, or only to the extent they integrate with Sharepoint? (Might be worth it to reconsider my Three Types of Intranets post here…)

I’ve used Ektron to build a couple intranets, and it keeps trying to stay relevant to the enterprise in the Sharepoint era — they’ve released some Web Parts functionality and a Sharepoint integration layer.

EPiServer has a connector for Sharepoint, and they have some pre-built Workrooms functionality that provides collaboration spaces, a lot like Sharepoint sites. EPiServer also has Community, which can rival Sharepoint in the internal (and external) social networking space.

Alfresco has the Share app, which is as Sharepoint-like as anything I’ve ever seen, which is impressive considering they abandon .Net completely (it’s a pure JEE app).

There are still some pure-plays in the Intranet CMS world like Community Server, then there are the “enterprise wiki” tools like Confluence. But are they eventually going to get squeezed out? Will Sharepoint become the default standard when people say “intranet”?

The Content Building Blocks of Web Content Management: I really liked this article from CMS Myth about how to break down the content of your CMS project into different parts. It’s a good way of looking at it.

Web Pages: While we’ve certainly moved to dynamic content delivery, most sites still require a traditional site map with individual pages defined.

[…] Templates & Layouts: Each page needs a defined template and layout. It’s important to standardize the templates and layouts and map them back to individual page types.

[…] Content Objects: […] A content object is best defined as a piece of content that has a set structure.

I guess I would argue that “Web pages” are content objects as well — they often have a defined structure besides just a title and body.

[…] Applications: Most sites have specific needs that require custom application development or third party integration.

I really have another post lurking around in my about “a CMS as a container for applications.” I’ll write that sometime soon.