Stuff Collected

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
• MCAD/MCAE
• 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.

If I had a nickel for everytime some Web publishing manager told me their job requires them to copy and paste content between various Web sites… Well, let’s just say, I could buy a lot more stock.

I hear about this from friends who work on sites across the industry — there’s lots of mindless manual repurposing of content going on out there. This is a problem on sooo many levels on sooo many sites… not only is it expensive, and time consuming, but it even affects usability of web sites since all that manually repasted data is pretty much trapped in its own little silo never to be used again.

Case in point: I was in a web technology User Committee meeting the other day and the subject came up that we’re using two (or three or more?) different tools to create and manage a certain type of product content, with each destination site pretty much storing its own copy of the content.
We’re copying and pasting, or building perl scripts to do our data mining. What we really want to do is write it once and reuse it.

A well-respected colleague, Martin Hardee, responded “You know, it really all comes down to data models, right?”

My mind jumped in gear… Maybe these blogs are my chance to make metadata evangelists and data modeling believers out of everyone! (ok, maybe a few, if they start reading!) I know every company has this same challenge. Now thanks to Will and others, we now have a cool place to talk about it.

So yeah, data architecture is what I’ve been working on here at Sun for the last 1 1/2 years — metadata and data models. (My previous 4 years were spent managing Web publishing tools for one area of sun.com, so I have the battle scars to understand the importance of data models.) We’re breaking down silos of Sun product content, developing XML schemas to drive common elements, driving creation and implementation of hierarchical metadata, and working on creating the tools and services for people to get at this content. But, its challenging.

I’m sure as I get better at this blogging thing, I’ll fill you in on what I’ve been working on and its challenges and triumphs. But first, here’s some links you might browse to get up to speed on metadata and data modeling for the Web.

• Developing and Creatively Leveraging Hierarchical Metadata and Taxonomy
• Frequently Asked Questions about RDF

More later…
Kristen