JD National Demo Script
Outline
For more information, please contact
Charlie
Wood
VIGNETTE
INTERNAL USE ONLY
Fundamental concepts
The demo should be preceded by an
architecture chalk-talk describing the DB, CMS, and CDS components. Two
processes should be described: content entry and content delivery. Templates,
components, and caching should be defined and described. Then the demo
can be used to give concrete examples.
Templates
The front page, like every other served by StoryServer, is the result
of evaluating a template.
Components
Components are templates within templates. On the front door of our
demo site, the header and footer are components, as are the top and side
nav bars, "What’s New", "Market Indices", and "Accounts". On the production
side, components are just modular programming. I can assign someone the
task of writing a nav bar that works in a certain way, and then I can do
unit testing, integration testing, and deployment on just that one piece.
On the delivery side, we do our caching at the component level (as described
before), so we realize a huge performance gain.
Content re-use
By selecting a story, we can see one view of this individual piece of
content. The content itself is rendered by a set of templates to produce
the web view. If we wanted to get a different view of the same content,
like the printer-friendly view, we just run the same content through a
different template.
Content Management
As we discussed in the slide presentation, Content Management is
squarely aimed at reducing operational cost.
Universal Content Entry
Content Management starts with the origination of content. We’ll use
the term "Universal Content Entry", since however you can get bits into
a database or onto a file system, you can then tap StoryServer on the shoulder
and say, "Start managing that as content." The example that we’ll show
here is browser-based content entry, but StoryServer natively supports
email content submission and several of our customers receive content via
syndicated feeds or from other applications accessing a common database.
The key idea is that your content author shouldn’t have to know anything
other than a URL, a username and password, and how to fill out a form.
Note that this page (the content entry form), like every other served by
StoryServer, is the result of evaluating a template, so you can create
a completely unique interface depending on what you want your content authors
to see. The author simply fills out the form, which can contain text, binary
(using HTTP upload), and metadata (i.e. the "Section" menu) inputs, and
hits the "Save" button. His job of authoring content is now done. He doesn’t
have to know anything about HTML, FTP, or even how the content will be
used on the site.
Workflow
When the author hits the save button, two things happen: the content
is stored in the content repository (in this case a relational database),
and the appropriate workflow, or series of tasks that have to happen before
the content will go live on our site, is initiated. To manage this workflow,
we’ll use the Production Center tool.
When I launch the Project Manager, I see a project hierarchy in the
left frame, and the contents of the selected project on the right. Each
folder is called a project, and the hierarchy is completely abstract; it
doesn’t affect the navigation of the site, how files are laid out on the
disk, or anything like that. There are two attributes of projects that
will help you determine how to design your hierarchy. First, access control
is done at the project level. Each project has a list of owners and authorized
users. Second, each project can have a unique workflow. When an asset is
created in a project, it inherits the workflow from its parent project.
If we look at the workflow for the Articles project, we can see that every
asset created in that project will go through two steps before it goes
live: first, the Editors group is asked to categorize the content, and
then the Legal group will do a legal review. Notice that we have an option
selected to automatically launch the content as soon as the workflow completes,
so as soon as the lawyers are done with it, it will go live on our site.
We can see that our article was created in the database by locating
its content management record in the right frame. Notice that its status
is "working", meaning that it is somewhere in its workflow and hasn’t yet
gone live. At this point, it’s only visible on our development site. Most
of the articles are listed as "live", meaning that they’ve visible on our
live site. Several items are "expired", meaning that at some point before
or after they went live, someone (or some scheduled task) said, "Pull that
item off of the live site."
So our article is in the working state, and the first task in its
workflow has been assigned. The members of Editors group are notified in
two ways that they have something to do. First, they get an email notification
(the CMS speaks SMTP to your mail server). There’s also a to-do list built
into the interface here, where I can see all of the tasks that have been
assigned to me, or to a group of which I’m a member.
Let’s say Bruce and I are both in the Editors group. We both get
an email saying that a task has been assigned to our group and the details
for the task. I come in here first and start the task. This changes ownership
to me, removes it from Bruce’s to-do list, and puts a lock on it. There’s
a locking mechanism on every asset in the system, so you won’t have people
saving over each other’s work. I can now do whatever it is I need to do,
so I’ll look at the details for the content associated with this task.
From this view, I can look at the workflow, including what the current
task is and what tasks are remaining. I can modify the workflow for this
individual content item if I need to, I can do version control, and lots
of other things, but my task is to categorize the content, so I’ll preview
the article. At this point, StoryServer dynamically builds the page as
it would look if it were live, even though it’s not live yet. Now I know
that this article is about retirement, so I can go to the Keywords tab
and use the integrated Content Catalog to categorize this article. Most
users will be limited to choosing category/keyword pairs from a list that
has been set up by your site administrators. I choose the category "Financial’,
keyword "Retirement". I can assign as many category/keyword pairs to this
article as I like, so I can slice and dice my content at a fine level of
granularity. I’m now done with my task, so I can go back to the Task View
and Finish my task. Now the content moves to the next task in its workflow,
which was to get the Legal group to do a review.
I’m also in the Legal group, so I get another email notifying me
of the new task, and I see it show up in my to-do list. I start the task,
choose to view the associated content’s details, and preview the article.
Note that now, the article has some metadata along with it, in the form
of category/keyword information, so my Related Articles component can do
something useful. OK, so the article looks fine, but being the lawyer that
I am I decide that it needs a copyright notice. I go back to my details
view and select "Edit Record…", which takes me back to my browser-based
interface for doing whatever edits I need to do. So I add a copyright notice
to the text, select Save, and finish my task.
Staged Deployment
Remember that we selected the option to automatically launch content
as soon as the workflow completes. If we switch back to the Project Manager,
we can see the article go into the "Ready to Launch" state, an automatic
launch task gets fired off, which will execute immediately (at the next
minute boundary), which moves the content into the "Live" state. The article
can now be seen by our live Content Delivery Servers, so if we go back
to our live site, we see the new content reflected in the What’s New component
on the front page. Following the link, we see the full web view, including
related articles, and the printer-friendly view is built as well. If we
look at one of the related articles from last June, we see that its related
articles component has been updated to point to our new content. Basically,
our new content has now been integrated into our site.
Virtual Link Management
Notice that the link was automatically built, so you’re not in the business
of manually building links.
Scheduled Launch / Expiration
But getting content deployed to the site is only half the battle. We
also need to gracefully age content off of the site. Let’s say that we
know this article should only be on our live site until New Year’s Eve
at 11:00 PM. I certainly won’t be at the office, but we can set up a scheduled
task to expire this content at a certain date a time. What happens when
that expiration task finally happens is this: I’ll expire the content now,
and when we go back to our live site, the content and the links to the
content have been removed. If a user had the page bookmarked, they would
now get a 404 File Not Found. As far as the world knows, it’s just gone.
The content still exists in our database, so we could edit it and relaunch
it later, but it’s completely gone off of the live site.
Audit Trails
As this whole process has been happening, StoryServer has been keeping
a history for every asset in the system. So I can look at the History view
for this article and see who modified it, who launched it, who in Legal
said that this article wouldn’t get us sued. I like to call this the "Who
Do I Fire?" view. Essentially, this provides a level of accountability
for the operations of the site.
Version Control
If I wanted an additional level of control, to see not only who made
changes, but what changes the made, and to be able to roll back to a version
before any changes were made, I could select the auto-version option of
the project. That way, every time an asset goes live, it gets versioned,
so I’m guaranteed that if a user ever saw it on my live site, I have a
copy of it saved. This is particularly nice for versioning templates.
Personalization
The other side of this ROI coin is increasing the value you realize
from your site. StoryServer’s personalization features are aimed at driving
that habitual usage of your site that is going to increase< revenue/value>.
Arrival
Referring back to the slide that Bruce showed earlier, we’ll step through
each of the four stages of Lifecycle Personalization. The first phase is
when the customer has just landed on your front page. He hasn’t logged
in, you don’t know anything about him- except the information emitted by
the browser, which can be useful. First, StoryServer’s Presentation Agent
can determine the capabilities of the user’s browser, which lets you as
a template author write logic into your templates like "IF_SUPPORTS Java,
show this Java applet, ELSE show this HTML version". StoryServer can detect
over 30 browser capabilities, including things like support for Java, Frames,
and tables, OS flavor like MacOS, Unix, or Windows, browser versions, and
individual browsers like Navigator, MSIE, or WebTV. This lets you serve
a variation of any component that is specifically targeted to certain browser
capabilities, so you can get away from doing least-common-denominator designs.
The Presentation Agent also has support for detecting the language
setting of the browser, so if your user’s browser is set to Spanish, you
don’t have to ask him to click on the waving Mexican flag, you can just
serve him Spanish content automatically if it’s available on your site.
Anonymous
Once the user starts navigating around your site, the Observation Agent
can collect information about that user’s behavior. When the user pulls
up a piece of content about retirement, StoryServer remembers the fact
that this particular user, whether we know who he is not, saw something
from the category "financial", keyword "retirement". This observed behavior
can be used in two ways. First, in real-time to dynamically modify the
site based on this individual user’s observed behavior. As you see, as
I read more items about retirement, "retirement" becomes the keyword in
the category "financial" that I have seen the most. We’re passing that
information to the ad system, so I start getting ads having to do with
retirement, targeted to my observed behavior. Second, this information
is stored in the back-end relational database for reporting. Note that
all of this is done in an extremely high-performance manner using a two-tier
memory cache that reduces load on the database.
Interested
As the user continues to interact with the site, and is being served
the right version of the page for his browser and language, and is getting
a customized experience based on his behavior, he might eventually get
to the point where he is willing to divulge some information to the site
to get some recommendations. Note that we’re still not asking for explicit
information, we’re just asking the user to share some information about
his tastes. Now we’re at the "Interested" stage, the third stage of the
personalization lifecycle. Using a product that we OEM from NetPerceptions
called GroupLens Express, we can use collaborative filtering techniques
to make recommendations based on a user’s preferences, and the preferences
of the rest of the user community. This is the same technology used on
Amazon.com to make book recommendations, and moviefinder.com to recommend
movies. Here, a user can rate stocks, and based on what other users like
him think, the site can make recommendations.
Well-known
The final stage of personalization is probably the most familiar to
most people. In the "Well-known" stage, a user can uniquely identify himself
to the site, in this case using a username and password, and can get an
explicitly personalized experience. Once I log in here as cwood, my navigation
bar changes to call me by name, only stocks that the site knows I own are
shown in the stock ticker, and I can get access to what we call "personal
workspace applications". The example here is a stock portfolio manager.
This type of application is what you’ll find on a MyYahoo-type site, or
a corporate intranet that lets me set up a personal workspace.
Reporting
Since StoryServer has been managing my content and knows a lot about
it, and managing my users and their interaction with that content, there
is a lot of very useful information that is available for me as a business
manager to mine, enabling me to drive continuous improvement of my offering.
Keyword Manager
StoryServer supports three levels of reporting, the simplest being the
Keyword Manager. This is a broad-strokes report that will show the popularity
of each category and keyword, so I can sit down and say "it looks like
stocks, mutual funds, and retirement are my most popular subjects, but
no one cares about taxes, so why am I paying for that content to be created?"
Note that these are up-to-the-second stats, and I don’t have to run a report
or call my web administrator to get at these numbers.
Report Manager
The next level up is the Report Manager, which lets me submit ad-hoc
queries, or save those queries in a personal space or a shared space for
later use. The report manager lets me get at both explicit user profile
information and implicit observed behavior. Let’s say I want to see how
effective my efforts to reach retirement-age users are being. I can create
a report that says "show me all of the people whose age is over 65, and
who have seen something from the retirement category more than 20 times.
For each of those people, I want their email address and their first name,
since I’m going to send them a targeted email. I don’t care how they’re
sorted, and I could get the results either interactively on the screen,
or more likely, I’ll dump them to a file for import into Excel for charting
and graphing, or to a bulk emailer."
Open Profiling
The last level that we talk about is really about extensibility. Since
all of the user data- both explicit and implicit profile information- is
stored in open, published-schema, relational database tables, you can point
whatever third-party product you like at it, Crystal Reports, Oracle Reports,
Cognos, whatever, and mine your data that way.
Summary
-
Content Management: Lowering operational costs
-
Personalization: Increasing revenue/value
-
Reporting: Continuous improvement