Christopher Hill

Recent Posts

Is Your Browser Strategy Straight Out Of 1994? (Part 5 of 5)

Posted by Christopher Hill on Apr 11, 2012 8:07:00 AM

Click here to see all articles in this series.

Welcome to the final installment in a multi-part series where I look at how IT departments may inadvertently cause more problems than they avoid in their approaches to deploying web browsers in their organization.

In the previous installment I recommended that organizations plan to stay with officially supported browser releases, and remain flexible so that in cases where a browser upgrade causes problems with certain sites or applications backup solutions be acceptable as an interim solution.

This installment gives you two more tips that can help deal with the inevitable browser update cycles and some final thoughts on the subject.

netscape1 resized 600

4. Be practical -- don't try to fight browser update cycles

At some point you may find that despite having browser options available you run into the need to go back to your vendor or development team with requests to fix compatibility problems with new browser releases. When doing so try to take a practical approach. Work with your developers and/or vendors to come up with an acceptable short-term solution to deal with the problem at hand. It often is counterproductive to go to enormous effort to get everything fully functional in all possible browsers when, by the time you have fully tested all the variations, new versions are being released and those browsers you just certified are no longer officially supported.

Stay focused on providing users with a practical path to access the tools they need. Find a solution, get it up and running, then decide if further effort is merited to support and certify against additional solutions. Browser development cycles have become more rapid. Don't bog yourself down in policies that ignore this reality.

5. Be strategic in your browser selection strategy

Deploying browser-based sites and applications should be done with the expectation that part of that cost is incurred over the life of the application in testing, support and deployment resulting from browser updates. Make this an ongoing part of your IT plan. I'm still surprised at the number of organizations who act as if browser releases are sprung on them without warning. In reality, most every company provides early access to browser releases and clear communication of upcoming releases.

When deciding which browsers to support IT organizations have often traditionally ignored the longer-term, strategic implications of their decisions. Notice a lot of iPhones and iPads in your users' hands? Maybe you should consider Safari as an option on the desktop, since there is a much higher likelihood that sites supporting desktop Safari will also support Safari on Apple's mobile devices. Considering that the underlying engine behind Safari (Webkit) is also the underlying engine behind Google Chrome, the Amazon Kindle browser, Android, and the Blackberry Tablet OS and webOS -- ensuring support today for Safari or Chrome on the desktop may pay additional dividends if you have mobile support planned for the future. Even Microsoft in their Windows 7 Phone browser has made adjustments to Internet Explorer to enhance their compatibility with Webkit given its dominance in the mobile space.

Today's web has more devices to support, more dangers to avoid, and new formal and de facto standards to address. Have you adopted a strategy for browser deployment that accepts these realities? Or are you pretending it is still 1994?

Topics: Internet Explorer, Safari, Firefox, Chrome, Browser Strategy Series

Is Your Browser Strategy Straight Out Of 1994? (Part 4 of 5)

Posted by Christopher Hill on Apr 10, 2012 8:07:00 AM


Click here to see all articles in this series.

1994 mobile phone

Welcome to the fourth installment in a multi-part series where I look at how IT departments may inadvertently cause more problems than they avoid in their approaches to deploying web browsers in their organization.

In the previous installment we considered the option of selecting two or more browsers as the corporate standard, giving flexibility when internal or external sites or web-based applications prove difficult to support in a single browser. 

Just like most organizations now support more than one phone handset (a difficult option in 1994), they should consider supporting more than one browser.

Today we will look two more practices deserving serious consideration in setting web browser standards in your organization.

2. Stick to officially-supported browsers

Many IT professionals might be surprised to discover that the browsers in use in their organizations are no longer actively maintained. Browser exploits go unpatched often compromising security in these cases. Companies should make it a policy to not allow unsupported browsers to be part of their standard deployments. Yet in many enterprises the opposite is the case. I've seen officially-supported releases specifically forbidden by IT departments because they are untested and instead users rely on older, unsupported releases. This is a dangerous policy that creates serious security risks.

There are a few reasons why organizations have allowed this untenable situation to continue. First is that they did not budget appropriate resources to the predictable browser schedules. Instead, they pretend these schedules do not exist and only try to react after a new version of a browser is released. Resources need to be allocated to begin testing beta versions of browsers for major issues and allocate resources to correct the problem. If you took the first recommendation, you may be able to buy extra time by instructing users to switch to an alternate browser until the sites and applications are adapted to the new browser release.

Budget for the inevitable cost of browser updates in your organization rather than trying to respond after they are released. Keep tabs on new browser releases so that you can plan for them in advance. Then make sure you have dedicated ongoing resources to ensuring the organization only use officially supported browsers. While it may seem you can't possibly keep track of all the browser updates, in reality vendors are very transparent. Most give clear signals of when to expect a major new version, and generally provide plenty of lead time to test beta candidates before the official release.

As of now, Mozilla officially supports Firefox 3.6.28, 10.0.3 and 11. So if you have users on Firefox 4, 5, 6, 7, 8 or 9 they are at risk as these releases are not actively maintained. Microsoft supports Internet Explorer 7, 8 and 9. They also have some provisional support for Internet Explorer 6 even though they have begged their customers to abandon this version. Apple takes a decidedly tighter approach, only supporting Safari 5.1.4 for the Mac and 5.1.5 for Windows. And Google is most aggressive, quietly pushing updates to Chrome often unbeknownst to the end user. Right now they support 18.0.1025. Get used to this - Firefox is heading that way as well.

As a browser-based software vendor, however, I am routinely asked to provide support for browsers that aren't even officially supported by their creator. While we strive for remaining browser neutral in our software, there are inevitable inconsistencies in browsers and versions that make it impossible to eliminate every possible problem created by inconsistencies in browsers.

It may be more work to update browsers frequently, but these updates should be prioritized to maintain security and support innovation. Make plans around the browser vendors' release schedules in advance and take advantage of beta programs to begin testing early. Proactively and aggressively encourage your users to stay on supported browser releases.

3. Browser support as a goal, not a requirement

One reason enterprises are loathe to support even two browsers is that they attempt to ensure that every application and site operate correctly on every browser they deploy. This can lead to impossible situations, complicated testing, and lengthy deployments as the organization tries to ensure all tools operate consistently across all browsers on all platforms they deploy.

While browser-based product vendors like me understand this as part of the cost of doing business, it seems that often organizations relying on browser-based tools set a far more difficult bar for application/browser compatibility than is necessary. Recently I found that an expense report utility I use does not seem to function correctly on Safari. Rather than spend a lot of my time (or my company's time) trying to figure out what the issue was, I instead use Firefox. Someday there may be a reason to worry about why it isn't working in Safari, but for now I have an acceptable workaround. Make this easier for end users by putting a browser-detect page in front of all corporate applications and updating it when testing new browser releases to inform users of their alternatives. Make updating this browser detection page a part of your browser test plan.

Are users annoyed when their browser of choice doesn't work with a tool? Perhaps. But denying any choice at all leaves them no option but to make a support request and wait.

That said, companies should plan to update their applications eventually whenever possible to handle all supported browsers. But making this a goal rather than a requirement allows practical decisions to be made. Is the latest update to Internet Explorer going to require a massive effort to support on your legacy tools? Look for supported alternatives from the other browser manufacturers for an easier temporary or permanent workaround. Make sure users are informed of this when they attempt to access the application. Don't assume that if you communicate these things through handbooks, emails, or posts to the corporate site you've done your job. Instead, try to detect problematic browsers on your site or application and provide users with the information they need to access the site or tool.

In the final installment we will look at two more recommendations for your corporate web browser strategy.

Topics: Internet Explorer, Safari, Firefox, Chrome, Browser Strategy Series

Is Your Browser Strategy Straight Out Of 1994? (Part 3 of 5)

Posted by Christopher Hill on Apr 6, 2012 9:00:00 AM

Click here to see all articles in this series.

Welcome to the third installment in a multi-part series where I look at how IT departments may inadvertently cause more problems than they avoid in their approaches to deploying web browsers in their organization.

Yesterday I talked about how the browser developers manage updates and supports for their browsers, and provided examples of a few ill-advised responses.

Today we look at some positive responses organizations should consider when handling web browser standards in their organization.

I understand the plight of IT departments. They can't upgrade the official company-supported browser to support new tools and technologies without having to extensively test and invest what could be substantial resources into updating old tools to work in the new browsers. While pressuring your software vendors to support years-old browsers may seem like a way to ease your support headaches, in reality this is really a short term gain with long term costs. Writing code to support years-old versions of every browser takes a lot of effort, and often introduces much more code complexity. Each version of each browser is a real cost to code against, test against and support. These costs will eventually be passed on to you even if you manage to hide this by pressuring browser developers or your web site developers and tool vendors. Higher licensing costs, slower innovation, delayed release schedules, increased complexity, reduced stability, longer testing cycles, reduced functionality and increased downtime are all potential liabilities incurred by each additional browser and version a vendor must support. Most of the browser developers have already acknowledged this and adopted update strategies that rapidly drop support for non-current browser versions.1994 netscape large resized 600

I've been thinking about this quite a bit lately and came up with a few suggestions that I think should be seriously considered by every IT organization. Not all IT departments can or should adopt these wholesale. But thinking through these suggestions may help alleviate some of the challenges faced by IT organizations managing web-based technologies. 

Today we will look at why you shouldn't try to regress to 1994 when there was only one browser available to most users.

1. Do not rely on a single browser platform for your end users

I'm often surprised that many IT departments force their entire organization to rely on a single version of a single browser. Personally I keep several browsers at the ready in case I run across problems working with a web site or application. The Macintosh computer I'm using to type this has installed on it Internet Explorer 9 (through Parallels virtualization software running Windows 7), Google Chrome 18.0.1025, Firefox 3.6.28, Firefox 11, and Safari 5.1.4.

Why is it that many enterprises sanction only a single browser and version as a corporate standard? Such a draconian mandate has the potential to create more support problems than it solves. Users who run across web sites and applications that don't operate properly with the single sanctioned browser are forced to contact their IT department for assistance, not use the site or application, or attempt to access the tool outside of the company computers (most likely from their home). 

Many users in their home environment are perfectly able to install and use multiple browsers. I have often seen "novice" computer users react to problems using a web site or application by switching to another browser. When they upgrade to the latest version of Internet Explorer only to discover problems with some site, they immediately will fire up Firefox to see if they can get around the problem. In a corporate setting, it may actually save in IT costs to give users options to troubleshoot and solve their own browser compatibility issues through trial and error. This buys time for the browser developers, site developers and tool vendors to find solutions to any issues on a particular platform.

Why not make two, three or all of the major browsers for your platform a standard part of the deployment? If the latest update to Internet Explorer breaks some vital application, there's a good chance it will continue to run in Firefox, Safari or Chrome. Think of it as a redundancy mechanism that minimizes the chance that any one browser update will bring everything to a halt. 

Yes, IT organizations will have to expend some additional resources keeping more browsers patched. But a single point of failure for a fundamentally critical tool like a browser seems shortsighted and needlessly restrictive. And the extra effort may ultimately save time and resources in that users have at least one other option than to call the IT department when a browser update occurs.

The next installment looks at two more ways to work with, rather than against, the reality of web browser software updates today.

Topics: Internet Explorer, Safari, Firefox, Chrome, Browser Strategy Series

Is Your Browser Strategy Right Out Of 1994? (Part 2 of 5)

Posted by Christopher Hill on Apr 5, 2012 9:00:00 AM

Click here to see all articles in this series.

Welcome to the second installment in a multi-part series where I look at how IT departments may inadvertently cause more problems than they avoid in their approaches to deploying web browsers in their organization.

In part 1 I talked a little bit about why I have an interest in this topic.

Today we will look at the release cycles and support provided by the major browser vendors. We then look at two very tempting but ultimately destructive strategies many organizations have tried to attempt to cope with the challenges of a web-based infrastructure.

Browsers with rapid release calendars: Chrome and Firefox

Unfortunately, many of today's browsers make it difficult to successfully employ a locked-down approach to technology deployments. Both Google Chrome and Mozilla Firefox have adopted rapid release cycle strategies whereby major new versions are introduced every 6 to 8 weeks. When a new release is introduced, a very short period of overlap exists before the vendor drops support for previous versions. Now web sites and web-based tools and applications must adapt to this reality if they are to use supported versions of Firefox or Chrome.
Mozilla and Google aren't doing this to destabilize your delicate software balance. They are instead trying to focus effort around a single browser release. When Firefox 12 debuts (scheduled April 24), you will have a few weeks to enjoy continued support on Firefox 11, during which time you should have plans well underway to support the new version. And you should make every effort to move on, if for no other reason than in the interest of security. Google's Chrome quietly updates their browser without user intervention. And note that this is categorized as a security feature. If Google Chrome is a used to access your web-based environments you better know when those updates are scheduled to occur and proactively test your applications. Firefox is moving in a similar direction.

While this makes it necessary to update more often, developers building around Firefox and Chrome can focus the vast majority of their effort around a single version of each for the Macintosh, Windows and Linux platforms.

IT departments should have the release schedule on their calendars and proactively plan to support the new releases as soon as possible. The new releases will have security updates and active support from the browser's developer.

Internet Explorer: Versions That Never Die

Brainthatwouldntdie resized 600

Microsoft often appears reluctant to cut off support for aging software, due in large part to the size of the install base and the fear of losing customers with aging hardware platforms. 

This is reflected in Internet Explorer. Internet Explorer 6 will be finally interred in April, 2014. This is for a product they are aggressively recommending customers discontinue using, a product that had been eulogized in a funeral ceremony in 2010. Allowing aging versions to continue well beyond their prime, Microsoft has created the browser that wouldn't die.

Even when IE6 is finally gone we still have to contend with Internet Explorer 7, 8 and 9, and soon 10. We can only hope that Microsoft musters up some courage to discontinue their aging releases or they'll all be around into the next decade.

Safari: Something old and something new

Apple mixes a bit of the old with the new in their approach to Safari. They have longer release cycles often tied to major OS/X operating system updates, and tend to aggressively discontinue support for all previous releases. So at any given time developers using web-based technologies can largely focus on a single version of Safari for the Mac, for Windows, and for iOS.

The B-Movie Scientist Policy

So your organization will no doubt have to decide how to adapt to life once your supported browser is dead and buried. You could join many of Microsoft's large customers and use threats, bribes, begging, and tears to cajol them into keeping whatever version you use on official life support well past their prime. Of course, companies like Apple and Microsoft (and open source communities in the Linux world) are unlikely to respond unless you have an enormous IT budget. Even if you do manage to succeed, your victory will only be short-term. Like an ill-fated b-movie scientist, your monstrous creations may be doomed to roam the earth indefinitely.

I read an interesting case study of a startup who estimated the cost of providing Internet Explorer support for their tool at $100K. They chose not to support the world's #1 browser and claim it as a competitive advantage! Writing web applications and tools that can cope with the idiosyncrasies of years of browser releases is a challenge. Building code to deal with all the subtle variances means increased complexity. Hiring staff members who understand all these variations can be difficult. Even keeping around working versions of these dinosaurs is a challenge. Ultimately, the time you may have saved by avoiding a browser upgrade is probably lost many times over in long-run expenses.

The "Monkey's Paw" Policy

monkeys paw resized 600I am even more stunned by the approach taken by organizations who don't have the clout to officially keep their chosen browser alive indefinitely. Even after the vendor pulls the plug on the software, many organizations refuse to let go. They continue to support software that the software's creator has given up on. They continue to allow their users to rely on unsupported, unpatched browsers. While this may be sustainable in the short-term, it is a dangerous strategy in the long term. Like a wish on a monkey's paw, unintended consequences may be serious.

As I vendor, I have seen this phenomenon first-hand. Customers will ask for assurances that our software will support "dead" releases, even though such assurances are in reality impossible to guarantee when the browser itself is unsupported.

When a customer tries taking this approach I politely decline. Ultimately most customers realize that supporting dead browsers is an unsustainable strategy only to be used for short-term, emergency situations. Putting systems and users at risk by forcing them to use browsers that do not receive security updates should not be a standard operating procedure. 

Well before the browser developer ceases support for the version of a browser you use, you should already be planning your upgrade.

So that's a quick summary of how the browser vendors handle the lifecycle of their browsers and a few suboptimal responses.

The third installment in this series explores positive steps to a proactive web browser strategy.

Topics: Internet Explorer, Safari, Firefox, Chrome, Browser Strategy Series, browser, web browser

Is Your Browser Strategy Straight Out Of 1994? (Part 1 of 5)

Posted by Christopher Hill on Apr 4, 2012 9:00:00 AM

Click here to see all articles in this series.

Welcome to the first installment in a multi-part series where I look at how well-intentioned IT departments may be causing more problems than they prevent in their approach to deploying web browsers in their organization.

This installment provides some of the context that lead me to explore this topic.

Are you still acting like it's 1994?The Web Browser: Mission Critical Infrastructure
RSI Content Solutions fields two product lines reliant on the web browser as client software: RSuite CMS and DocZone. Managing products that operate in the browser presents challenges when trying to balance functionality against the need to support a wide range of browsers and their versions. Browser developers have been under increasing pressure to provide rapid updates to remain competitive and deal with ongoing security concerns. Users have become more reliant on a range of browser-based tools and applications. Almost every category of traditional desktop applications now have browser-based alternatives available. It can become a real challenge to find that magical browser release that supports the range of platforms and technologies in use today.

I've worked as a vendor in the browser-based application space for more than five years. In that time, I have encountered a range of responses from IT departments dealing with browser deployments. Some exert little or no control, often providing guidance but ultimately letting the users decide what browser to employ and when to upgrade it. Some IT departments have locked things down so tight they only give their users access to a single approved browser. While this may be sufficient for a fairly narrow use case over some finite period of time, the inflexibility is often stifling their ability to take advantage of the latest tools and technologies.

It's ironic that the mission critical role of the web browser has lead to defensive policies in many organizations in seeming ignorance of the rich variety of available tools. In the interest of ensuring a "perfect" technology deployment, it is tempting to lock the organization to a functional set of tools. Just don't blink lest your heavenly solution suddenly show its shortcomings and leaves you mired down.

Over the next several days I will be inviting you to consider your approach to supporting the web browser in your organization. In the next installment, we will look at the various approaches browser developers have adopted regarding updates and support. I'll also tell you about two strategies that have seduced many an IT department astray only to find they're worse off than before. 

Installment number two discusses how browsers are updated today and why acting like a B-movie scientest or wishing on a monkey's paw is not the right response.

Topics: RSuite CMS, Internet Explorer, Safari, Firefox, Chrome, Browser Strategy Series, browser, web browser

Learn XML Schemas and DTDs in 5 minutes

Posted by Christopher Hill on Mar 22, 2011 12:56:00 PM

In my previous blog post I introduced XML in 5 minutes. As a follow up, here's another 5 minute lesson to understand what an XML Schema or DTD is and what it might mean to end users of XML-based systems.
In the previous post we created an XML document to describe a book. Recall that it used tags around the actual content to describe the content.
     <title>Alice's Adventures In Wonderland</title>
     <author>Lewis Carroll</author>
     <summary>This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.</summary>

We also learned how representing content in this way allows us to dramatically reduce the effort required to support multichannel publishing. It also helps a great deal with automation and moving content between systems or organizations as it eliminates some of the issues of file formatting.
What would happen to our stylesheet if someone decided to use different tags to label their content?
     <title>Alice's Adventures in Wonderland</title>
     <writer>Lewis Carroll</writer>
     <summary>This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.</summary>

What we called author in one document we called writer in another. This inconsistency might be small now, but if we didn't restrict what people named things in our XML we would have to support a potentially endless list of tags. In the previous article we wrote rules for how to make our books look good on a page. If we can't predict what tags (labels) people are going to use - such as author - then it becomes nearly impossible to reliably write rules.
So even though XML helps us get a consistent base format for content, we need more help to get predictability and consistency.
Enter the concept of a DTD or Schema. DTDs and Schemas are ways that systems can impose rules on the XML itself. You can describe what tags can be used, where they can be used, and put restrictions on the content of those tags. There are two different standards for describing these restrictions: Document Type Definition (DTD) and XML Schemas. We won't get into the syntax or pros and cons of the two approaches. For our 5 minute lesson we can just assume they both are ways to enforce consistent labeling of our tags in our XML documents.
Here in English is how we might communicate the requirements for our flavor of XML:
  1. Put everything inside a book tag. You can only have one of these.
  2. The first thing you put in a book is a title tag containing the title text. You cannot leave this out.
  3. The second thing you put in a book is an author tag containing the author name. You must have at least one author. If there are more, you can repeatedly add more tagged authors.
  4. After all the tagged authors, you can add a summary tag. This is optional - leave it out if you want. But you can have at most 1 summary.
This is essentially what a DTD or XML Schema does, although they do this in a language friendlier to computers.
DTDs/XML Schemas allow you to specify the rules for the structure of your XML documents
You can think of XML Schemas or DTDs as a means to create a template that all valid documents must follow

These rules can now be applied to the two examples above. The first example follows the rules, so we would say that the first XML document is valid. That means it conforms to the rules. The second document, when tested with the above rules, would be invalid. The presence of tagged content labeled "writer" is not allowed by the rules. 
In the XML world, XML Schemas or DTDs are used in a lot of scenarios, including:
  • XML editors know what is allowed by the rules and prevent writers from making mistakes
  • XML programs test incoming content and indicate when the rules are being broken, preventing formatting errors
  • XML stylesheets can be much more easily written as they only process valid content and don't have to worry about rulebreakers
  • If I want to merge my book content with yours, we can look at the rules and decide what adjustments will need to be made to bring our rules together
  • Industries can agree on the rules for types of content. So we might create a set of rules to represent newspaper articles, adopt it as an industry standard, enabling anyone to easily exchange newspaper articles without having to modify the content.
So when you hear someone rambling on about an XML Schema or DTD, they are really just talking about the rules governing how the particular XML document is to be structured.
That's XML Schemas and DTDs in 5 minutes. In the coming weeks watch the blog for more quick lessons on XML-related technologies.

Topics: publishing, XML, XML Schema, DTD, 5-minute-series

Learn XML in 5 Minutes!

Posted by Christopher Hill on Mar 15, 2011 8:24:00 PM

As product manager for an XML-based CMS, often I find myself answering the question "What is XML?" Not necessarily a simple thing to answer in passing - entire books and courses are dedicated to the subject - but in about 5 minutes most content creators can at least understand at a basic level what XML is all about. Here is my 5 minute XML class to give a first pass at answering this question. At the end most people should have a rough idea of what XML is and can start thinking about its potential.
Take a look at the following text:
Alice's Adventures In Wonderland
by Lewis Carroll
This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.
Reading it, you probably can infer that the underlined text is a book title. The italicized text appears to be the author of the book (if you dropped the word "by"). Then there is additional text. If you are familiar with the book, you can tell that the text is not part of the book itself, but appears to be a short summary. We know all of this because of certain conventions we have been taught as well as contextual clues provided by the words themselves.
Let's look at the same text again:
Lewis Carroll
Alice's Adventures In Wonderland
This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.

Even though the text looks quite different, we probably could still successfully interpret the author's intent. Now, imagine you have to train a robot to understand these two cases. What rules might you create to "teach" the robot how to decide how to successfully parse these two text examples and understand what parts of the text are titles, author names, and summaries? Even for these two limited cases, the list of rules is going to be quite involved, and will include rules based on formatting, language, and convention. And a robot will have to know that somewhere in the text are the three pieces of content, otherwise it probably has little chance of determining the nature of what it is looking at (Darwin the Jeopardy-playing supercomputer excluded).

Even if all that was true, errors are likely to creep in. Do your rules allow the robot to understand that "by" is really a formatting cue indicating the following text is an author name? What about the meaning of an underline? Bold? Italics? Each example uses the same formatting cues but in different ways. 

When you write a document in a word processor or a desktop publishing program you mostly focus on how that text looks. Imagine after all that careful work making the text look right for your printer, you decide your content should appear on a Web site. Suddenly all that formatting needs to be re-worked to take advantage of the conventions of the Web. Now if you want to deliver to an electronic reader or a mobile phone your formatting may again need to be revisited. 

This is an expensive proposition when you start imagining all of the possible delivery channels that may require formatting changes. For many channels, all that formatting work needs to be scrapped and done again. 

The answer to this is XML: the extensible markup language. A short way to summarize the promise of XML is that it allows authors to indicate what the content is rather than how the content looks. XML does this using tags, essentially text-based labels that indicate what a particular piece of data might be. Here is the same example as XML. Even though you may not know anything about XML, you can make sense of this content.

<title>Alice's Adventures In Wonderland</title>
<author>Lewis Carroll</author>
<summary>This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.</summary>

Yes, angle brackets seem a little cold, but notice how they are labels making the meaning of the various pieces of text completely unambiguous. Notice how each tag (i.e. <book>) has a match (i.e. </book>). These pairs create a container. Everything appearing between matching tags is considered contained by them.

Now, imagine you want to deliver the content to a printed page, web site or mobile device. It is much easier now to write a set of rules that indicate how each should be formatted.

Rule for <book>:
start a new page
Rule for <title>:
one the first line, output the text as underlined,16 point Helvetica
Rule for <author>:  
start a new line, output the text in italic, 12 point Helvetica
Rule for <summary>: 
double-space, start a new line, output the text in 12 point Helvetica

These rules could be called a stylesheet. In reality, stylesheets are written in a more machine-friendly format that are beyond the scope of a 5 minute XML course, but this example should suffice to give you an idea of what a stylesheet's role in creating presentable XML content is. 

If I had hundreds, thousands or millions of book content items I could use this single stylesheet to output them all and be guaranteed consistency. 

If I decide I want to switch to a new look for my content, maybe using Garamond instead of Helvetica, then I just need to modify the stylesheet. Notice how the original book content exists completely independently of the formatting. And notice that changing the look of something doesn't require any editing of the original content.

Suppose I want to deliver my content to multiple channels. Each channel has its own conventions, limitations, and capabilities. People expect different formatting on a mobile phone than on their desktop computer. A web site typically looks different than the printed page. We used to underline book titles in print - but underline means something else on the web so often a different format is used. Helvetica may not even be an available font for many channels. 

Fortunately, XML makes supporting each unique channel straightforward. Instead of endlessly modifying my content, I simply develop new rules (a new stylesheet, or a variation of an existing stylesheet) for a new channel. The authoring process is unaffected. Existing content does not need to be re-edited to support the new channel. Instead, the new rules are applied to the content generating channel-appropriate output. And as the number of channels expand, XML serves as a content anchor point so that you can adapt content rapidly and in an automated way to the unique requirements of each channel.
XML as an anchor for multichannel publishing

If all of your content were clearly labeled by what it is, it is not nearly as daunting to support new output formats for new opportunities. Instead to a massive conversion of all your formatted content from one format to another, you just have to develop a new set of rules and you are ready to go.

That's XML in 5 minutes. At least as it impacts content creation and delivery. In the coming weeks I'll be posting additional quick lessons on XML-related technologies.

Topics: ebooks, publishing, XML, 5-minute-series

Centralizing metadata, content and assets: Paradise Lost and Regained

Posted by Christopher Hill on Feb 23, 2011 5:46:00 PM

I've been working in content management for more than ten years, and thinking back over that time I realized that the dream of a true, standards-based, central repository for all of an organization's assets I naïvely espoused in the late 90s still hasn't become a reality except in the most narrow of applications. When I used to write and teach XML classes I was sure that open markup standards were going to revolutionize the way we created and managed assets. Around 2003 I started to become a bit disillusioned with my vision for content utopia. By 2008 I had all but thrown in the towel. Despite herculean efforts content kept worming its way into proprietary, tactical-level production systems and often was never seen nor heard from again, a victim of legacy of "fire and forget" publishing approaches common prior to the rise of the Internet.


Fortunately, just as I had resigned myself to living in a world of content silos, new strategic ways of managing content started to emerge that rekindled my ideals. The idea is more modest than my grandiose vision of pure standards I once embraced, but offers a new, more practical approach that can survive in the real world.


Rather than insist that every asset be centralized in a consistent, preferably open, format practicality may dictate that we instead work to build a centralized asset repository that shares common representations for all assets. The actual bits and bytes making up the asset (Word documents, InDesign files, photos, videos, etc.) can still be developed and stored in traditional systems where applicable, but a new system takes on the responsibility of cataloging relevant features and details about the asset in a centralized repository. So instead of insisting that every asset be physically managed in a central repository, we instead insist on the much more modest - and realistic - demand that all assets make relevant, common data and metadata available in a consistent format through a centralized system. This distinction means that rather than try to replace the tactical systems we use to create, manage or distribute content we instead develop a parallel, complementary content management strategy that reflects data in these systems and presents a common, consistent view of the asset regardless of type. 


So an image file may exist as a TIFF or PSD formatted file in a production system or on some hard drive somewhere, but the centralized repository maintains a record for this image with all of its relevant metadata and a standard image format readily accessible to any system (i.e. PNG, JPG in thumbnail and applicable preview formats). For a lot of applications, centralized lighter-weight representations of content is enough to create new products without returning to . For example, if I want to rapidly re-use images or stories on a new microsite, I don't have to resort to tracking down all of the content in its silos, but instead rely on these common representations to collect the assets together and send them into my Web CMS for the new microsite. Formats, conversions, and so forth can either be provided to the central system through traditional manual conversion or, preferably, through automated mechanisms built in to existing content workflows.


This sort of approach was attempted using search technologies at one time, but lacked an important ability to offer the depth of content management required to not just find the asset but also to be able to use and transform it. It gave us the ability to view the content but not any tools to do anything once we saw it. Search remains important, but a real central repository needs to actually have usable representations of content that can be managed, transformed and distributed as assets on their own. This requires a full content management system.


So my new vision of a centralized asset repository is not the end-all be-all "do everything" system that becomes impossible to design and build, it's a "do-some-things" central system that maintains some consistent, common format that can be readily transformed and transmitted and becomes an organization's strategic content reserve. It can answer questions like "what assets do we have about Egypt?" quickly, and serve as a baseline for those assets so that after finding them they can be used in our various tactical systems.


To build such a thing, consistent representations are needed. When looking for data standards we of course start with XML. When only a binary will do, ensuring that pointers are accurately maintained to the original assets and appropriate renditions of the binaries are created for things like the user interface of the central repository is an obviously useful model. Even if re-work is required the assets are already under active management. 


The RSuite Content Management System happens to be a great foundation for building shared, managed centralize repositories of content. The system is flexible, built on an XML standard database with a metadata model that can not only leverage existing metadata but also be extended in arbitrary ways to adapt to evolving requirements. It is built on open standards and is a good corporate citizen, ready to interoperate with existing systems. The native XML database and pointer management features ensure that consistent representations are available. This approach creates a solid foundation for a strategic, centralized asset repository. 


Part of my role as Product Manager for Really Strategies will be to focus on the ways that our existing clients have adopted XML-based content management. I'll be reporting in with our client success stories at building these content repositories here on the blog. 


Does your organization have a vision for managing content strategically? It’d be great hearing how others are working to address this challenge.

Topics: content management for publishers, publishing, CMS, best practices, XML, metadata

Comment below