Enter, stage right: Captain Data Modeler

Have you read Martin's latest blog on Tips for Averting Bad Web Experiences? If so, cool... read on right here, y'all.
If not, go there first, then be sure to come back here to read my additional thoughts on some of Martin's 10+ tips.

One of my favorite tips in Martin's list is: #4 Beware of arrogant label-makers. In thinking about that tip, in my mind, it basically boils down to...
Don't force your audience to talk [understand] the internal language you walk [use and sometimes change quarterly] in order to find what they need on your web site. There's no doubt in my mind that 9 times out of 10, most customers and partners are not hip to [in the know of] any given company's internal, specialized terminology, and acronyms.

The development dialog on this can be a tough one:
Marketing Professional: "But, now we all call it: Newfangled Feature with YaYa Functionality [NfFwYYF]"
Metadata Modeler: "Do you think our customers will follow navigation or search for that term specifically?"
Marketing Professional: "Hmmm, well... Yeah, especially if I send them some opt-in direct email marketing on the NfFwYYF too!"

Perhaps true to the select audience in the know, but the longevity of the design is certain to be enhanced by figuring out why the customer needs your "NfFwYYF" and give it a clear cut home on the web w/ navigation to it that the audience is more likely to understand.

We could take the www.sun.com/solutions site (a portion of sun.com heavily driven by metadata models) as a case in point.
When the experts started designing this section of sun.com they realized: our authors/employees and our customers/audience speak different languages... Therefore, it was critical that our metadata model address the needs of the internal content authors, while keeping the goals and language of the customer clearly in the forefront of our design. Our metadata model had to map the two vocabularies together and bridge the gap. Captain Data Modeler saves the day!

(Sidebar: How come there aren't any really geeky super heros? OK, sure, Spider-Man is kinda geeky without his suit on, but what kind of super hero outfit would Captain Data Modeler wear? A black and white body suit with a bunch of open and close brackets? Sorta like the Riddler: "I am a man of few words, but many riddles". Captain Data Modeler: "I am a man (or woman!) of little content, but many models to put it in..." But I digress...)

Step #1-- Let the authors focus on authoring
Like many companies, Sun has some highly specialized internal terminology, code phrases, product names, (ala NfFwYYF) that our employees understand and use when creating content stories, case studies, partner profile info, etc. To author our content efficiently, we decided that employees should associate metadata to content (tag content) using Solution terms from a highly specialized, internal-centric vocabulary. This vocabulary became our "Solutions Authoring Taxonomy". It was a flat taxonomy (simply a list of terms in the vocabulary) which included just enough information to not overwhelm content authors.

Step #2 -- Create a Navigation Scheme that Maps Customer Goals to the Tagged Content
Customers need to solve a business problem or infrastructure challenge and if they don't find language they understand on a web site, they're apt to surf right on by. We decided that customers should be able to navigate and find Solutions using the words and phrases they understand. This multi-level hierarchy became the "Solutions Web Navigation Taxonomy". Now, gluing the two taxonomies together was the fun part. (Figuring out the terms in the vocabularies was only the half of it! Now we had term relationships to map!) Many hours were spent by subject matter experts and customer driven design advocates tying the unique identifiers from the Authoring Taxonomy to the customer goals of the Web Navigation Taxonomy.

Use Case: So when a customer's goal is to:
Gain Competitive Advantage
    by : Delivering Superior Product Quality

The customer is lead to all kinds of information authored and tagged with specific terms used internally, like:

  • Adaptive Engineering
  • ERP
  • Product Development
  • SCM
  • Service Delivery
  • Visualization

However, the only thing the customer needs to know is their goal, not our internal terminology for it.

What's also cool: Because these internal terms can be mapped to many different customer goals, the content is authored once and can be repurposed as business climates, goals and challenges evolve. In the end, the web site was redesigned, modeled, and targeted at decision-makers, line-of-business leaders, and IT managers and communicates how Sun, with its partners, address the most common business challenges. As these business challenges evolve, the metadata behind the site is ready for evolution.

Ok, I've rambled past my limit. More Adventures of Captain Data Modeler later.


Post a Comment:
Comments are closed for this entry.

Passionate about data engineering strategy and solutions for Sun’s external web sites. Happiest when building taxonomies, data models, and high performing teams.

Kristen Harris
Web Data Engineering


« July 2016