Curated content for content, computing, and digital experience professionsals

Day: March 3, 2009

Why Copy Your Competitors Bad Choices? Search Can Work for You

I’ve often been curious about why companies frequently procure enterprise applications used by their competitors, destined to be followers instead of leaders. It seems to reflect a lack of imagination but, more importantly, a lack of confidence that one could select another solution with more possibilities for enhancing the organization’s competitiveness.
Look at three popular concepts about search:

  • The search box for keyword search is dead or only marginally useful
  • Professionals spend 10 – 20% of their workday searching (and often unsuccessfully)
  • Vast amounts of critical unstructured content is un-discoverable in most enterprises leaving organizations at risk in litigation, weak in leveraging fundamental knowledge and research for innovation, poor at customer support because known solutions can’t be found, and competitive intelligence is scarce to unearth because so much of it lies hidden in desktop email in-boxes.

If we accept these propositions, doesn’t it say something about the “leaders” in the search industry that we believe and accept so little from search?

Why do most organizations not try to solve at least one of these problems by seeking solutions that will save hundreds of thousands of dollars in wasted labor, litigation costs, R&D expense, or lost customers due to poor service? Why do companies seek to procure search applications from companies that have been around for a decade or more, licensing evolutionary products, not revolutionary ones? Why would a company ignore innovative new products in favor of products that have given “search” a bad reputation? Why do organizations make hundred thousand dollar, or more, procurements without expending a few hundred dollars on documented product comparisons, and instead rely on a few widely published charts with less than a page or two on each product?

Most important, why are organizations not seeking search applications that will give them an edge by uncovering a nugget that will get a product to market faster, help marketing groups position a product better against the competition, or give support services representatives superior tools for getting information back to customers instantly with a proven solution to a query? Where is the will to apply search technology more astutely than your competitors in every area of your business? Why is search not expected to perform flawlessly and be as ubiquitous as any other software tool in your workflow? It does not have to be a poor performing stepchild but it does require its own experts to be well executed. Come to think of it, I have never seen a help wanted posting requiring expertise in search technology implementation. Hmmm…

There are well over a hundred viable search applications and hundreds of other applications that have search embedded for point solutions. You may need to acquire, implement and maintain a number of products across the enterprise to realize all the benefits search can bring but these products can work together, just as other components of a well-run enterprise do. At a time when organizations are cutting employees, appropriate search solutions may just offset the loss of expertise by uncovering at least some of the lost assets left behind.

Structured Editing & Wikis

If you know me you will realize that I tend to revisit XML authoring tools and processes frequently. It is one of my favorite topics. The intersection of structured tools and messy human thinking and behavior is an area fraught with usability issues, development challenges, and careful business case thinking. And therefore, a topic ripe for discussion.

I had an interesting conversation with a friend about word processors and XML editors the other day. His argument was that the word processing product model may not be the best, and certainly isn’t the only, way to prepare and manage structured content.

A word processor is software that has evolved to support the creation of documents. The word processing software model was developed when people needed to create documents, and then later added formatting and other features. This model is more than 25 years old (I remember using a word processor for the first time in college in 1980).

Of course it was logical to emulate how typewriters worked since the vast majority of information at the time was destined for paper documents. Now word processors include features for writing, editing, reviewing, formatting, and limited structural elements like links, indexes, etc. Again, all very document oriented. The content produced may be reused for other purposes if transformed in a post process (e.g., it could output HTML & PDF for Web, breaking into chunks for a repository or secondary use, etc.), but there are limits and other constraints, especially if your information is primarily designed to be consumed in print or document form.

It is easy to think of XML-structured editors, and the word processor software model they are based upon, as the most likely way to create structured content. But in my opinion, structured editors pay too much homage to word processing features and processes. I also think too many  project teams assume that the only way to edit XML content is in an XML document editor. Don’t get me wrong, many people have successfully deployed XML editors and achieved targeted business goals, myself included, but I can point out many instances where an alternative approach to editing content might be more efficient.

Database tools that organize the information logically and efficiently are not likely to store that data as documents. For instance, you may have an financial system with a lot of info in relational fields that is extracted to produce printable documents like monthly statements, invoices, etc.

Or software manuals that are customized for specific configurations using reusable data objects and related document maps instead maintaining the information as static, hierarchically-organized documents.

Or aircraft information that needs to match the configuration of a specific plane or tail number, selected from a complete library of data objects stored centrally.

Or statutes that start formatted as bills, then later appear as enacted laws, then later yet again as published, codified statutes, each with their own formatting and structural peccadilloes.

Or consider a travel guide publisher that collects information on thousands of hotels, restaurants, attractions, and services in dozens of countries and cities. Sure, the content is prepared with the intent of publishing it in a book, but it is easy to see how it can be useful for other uses, including providing hotel data to travel-related Web sites, or building specialized, custom booklets for special needs (e.g., a local guide for a conference, guides to historical neighborhoods, etc.).

In these examples of what some might call database publishing, system designers need to ask them selves what would be the best tool for creating and maintaining the information. They are great candidates for a database, some application dialogs and wizards, and some extraction and transformation applications to feed Web and other platforms for consumption by users. They may not even involve an editor per se, but might rely entirely a Wiki or other dialog for content creation and editing.

Word processors require a mix of skills, including domain expertise on the subject being written about, grammar and editing, and some formatting & design, use of the software itself, etc. While I personally believe everyone, not just teachers and writers, should be skilled in writing well and making documents look legible and appealing, I realize many folks are best suited for other roles. That is why we divide labor into roles. Domain experts (e.g., lawyers, aircraft engineers, scientists and doctors, etc.) are usually responsible for accuracy and quality of the ideas and information, while editorial and product support people clean up the writing and formatting and make it presentable. So, for domain experts, it may be more efficient to provide a tool that only manages the content creation, structuring, linking, organization, etc. with limited word processing capabilities, and leave the formatting and organization to the system or another department or automated style sheets.

In my mind, a Wiki is a combination of text functionality and database management features that allow content to be created and managed in a broader Web content platform (which also may include static pages, search interfaces, pictures, PDFs, etc.). In this model, the Web is the primary use and printing is secondary. Domain experts are not bothered with concepts like page layout, running heads, tables of content generation, justification & hyphenation, etc., much to the delight of the domain experts!

I am bullish on Wikis as content creation and management tools, even when the content is destined for print. I have seen some that hide much of the structure and technical “connective tissue” from the author, but produce well formatted, integrated information. The blogging tool I am using to create this article is one example of a Wiki-like interface that has a few bells and whistles for adding structure (e.g., keywords) dedicated to a specific content creation purpose. It only emulates word processing slightly with limited formatting tools, but is loaded with other features designed to improve my blog entries. For instance, I can pick a keyword from a controlled taxonomy from a pull-down list. And all within a Web browser, not a fat client editor package. This tool is optimized for making blog content, but not for, let’s say, scientific papers or repair manuals. It is targeted for a specific class of users, bloggers. Similarly, XML-editors as we have come to know them, are more adept at creating documents and document chunks than other interfaces.

Honestly, on more than one occasion I have pounded a nail with a wrench, or tightened a bolt with the wrong kind of pliers. Usually I get the same results, but sometimes it takes longer or has a less desirable result than if I had used a more appropriate tool. The same is true for editing tools.

On a final note, forgive me if I make a gratuitous plug, but authoring approaches and tools will be the subject of a panel I am chairing at the Gilbane San Francisco conference in early June if you want to hear more. </>