What is Functionality? A CM Domain White Paper By Bob Boiko

What is Functionality?
A CM Domain White Paper
By Bob Boiko
This white paper is produced from the Content Management Domain which features the full text
of the book "Content Management Bible," by Bob Boiko. Owners of the book may access the CM
Domain at www.metatorial.com.
This paper retitles chapter 4 of the CM Domain
Table of Contents
Table of Contents__________________________________________________________________2
What Is Functionality? ____________________________________________________________2
Monolithic Vs. Mix-and-Match Functionality___________________________________________3
Functionality Interspersed with Information ___________________________________________4
Managing Functionality Like Information _____________________________________________5
Publishing functionality on the Web _______________________________________________6
Where information and functionality diverge ________________________________________7
Summary _______________________________________________________________________7
Since the time computers first entered organizations as accounting and manufacturing
automation systems, the industry's seen a steady movement toward computer-based business
processes. Today, a worker in an organization commonly spends her entire day "doing business"
in front of a computer terminal. Inside organizations, business is largely electronic. Until recently,
however, the movement of information between organizations was slow. Organizations and their
partners were often on different internal systems and had different processes and standards that
don't easily translate across company lines. Between organizations and their end users
(customers, members, media contacts, and industry watchers), the basic connectivity that would
enable the end-user computers to communicate with the organization's computers was largely
absent - until the advent of the Web.
With the Web and the open standards it engenders, the way is now clear for making the transition
to computer-based business processes among organizations and their partners and end users.
The Web provides both the basic connectivity for end users and a "lingua franca" that enables
different computer systems to communicate. Today, business functionality can extend far beyond
the office to reach anyone with a computer and an Internet connection.
The way is clear, but the road is still rough. But as you see in this white paper you can go a long
way toward making all your business electronic by applying a content model to computer
functionality.
What Is Functionality?
In the software world, a computer-based process is known as functionality. The functionality that
a computer application offers casts a human process into a series of human-computer
interactions using a user interface. From the standpoint of the organization, you can say that
functionality is the way that you do business by using a computer.
Simply put, functionality is the stuff that you do on the computer. Unlike text, sound, pictures, and
motion, which you experience (by reading, hearing, or seeing), you do functionality (by requesting
or responding to something). A user interface represents functionality as a set of buttons, menus,
dialog boxes, and other controls that give you a particular capability. Microsoft Word, for example,
provides table functionality. The functionality is available from the Table menu at the top of the
Word window. If you choose the Table » Insert Table command, Word displays a dialog box full of
buttons and other controls that enable you to specify how you want the Insert Table functionality
to perform. On the Web, functionality is programming code that lives in a Web page or on a Web
server. It does useful things such as performing calculations, allowing you to submit data via a
form, carrying out financial transactions, verifying your credit card information, and so on.
Functionality's taken the following two major steps over the course of computing:
CM Domain White Paper
Bob Boiko
Copyright 2002 Metatorial Services Inc. & HungryMinds Inc.
Do not reproduce without permission.
Page 2
?? It's moved away from monolithic programs, where all the functionality is built-in, toward mix-
and-match programs, where the functionality exists in small chunks known as objects.
?? It's moved away from applications with the single purpose of presenting functionality toward
Web sites in which functionality and content intermingle and become hard to tell apart.
Taken together, these two steps enable you to treat functionality as a form of content.
Monolithic Vs. Mix-and-Match Functionality
In the early days of computing, all the functionality of an application was built into the application.
The application's programmers coded all their own functionality from scratch. Today, much of the
functionality that an application provides comes from outside the application itself. It's created and
packaged into functionality objects that programmers then glue together into an application.
Computers entered the organization one process at a time. First came accounting and
manufacturing systems. Then came spreadsheet and writing applications. Today hundreds of
different types of computer applications are used in organizations. Because of the way they
entered organizations, however, these applications were often unable to communicate with other
applications, they duplicated the functionality of other applications, and couldn't easily integrate
with each other. Because of this incompatibility, much of an organization's functionality is today
locked in silos of distinct applications that don't easily operate with one another.
Most newer applications take solid steps to break down the borders of different applications.
Communication standards (such as XML) provide a standard accepted map among the different
vocabularies and methods of various applications. Open programming standards such as the
Application Programming Interface (API), object-oriented programming, and Remote Procedure
Calls (RPC) ensure that interoperability is built directly into the core of modern applications.
The result of the newer application models is that knowing or caring about the application that
hosts a particular functionality becomes less and less important to you. You merely need to know
how to connect to, and use, the functionality that you need. Conversely, building complex
applications that combine the best functionality and data from a variety of sources is becoming
easier and faster than ever.
Today, programmers pack pieces of functionality into programming objects. Objects serve as a
standard way to package and transfer functionality. Every object programmer knows exactly how
to access the functionality in an object and to include the object in her own programs. In fact,
many programs (especially those on the Web) do nothing more than draw together a set of
previously created objects into a customized look-and-feel.
My notion of content components shares a lot with programming objects. In fact, content
components serve the same basic function as programming objects. They both provide a level of
isolation between the person who creates them and the person who uses them. If I create a
content component or a programming object, for example, I give it a set of attributes that enable it
to take on a life of its own. Later users of the component or object find it and use it based on
these attributes (that is, the metadata for components and properties and the methods for
objects). They know that the component or object serves the purpose they intend for it and don't
need to look inside the component or object to see what it contains or how it works.
Functionality that you package in objects can have the following characteristics:
?? Segmented: Functionality can come in chunks as small as you like. (Small in the computer
world means not taking up many bytes, not requiring much of the computer's processing
power to run, and not requiring a lot of supporting hardware or software to run.)
?? Shared: You can easily locate and use the functionality that someone else created apart
from the application that they originally intended it for.
CM Domain White Paper
Bob Boiko
Copyright 2002 Metatorial Services Inc. & HungryMinds Inc.
Do not reproduce without permission.
Page 3
?? Encapsulated: To use the functionality in your application or Web page, you don't need to
know how the functionality works; you need only know how to invoke it and what sort of
results it delivers back to you.
These three attributes of modern computer functionality pave the way for treating functionality as
content.
Functionality Interspersed with Information
Before the multimedia age, the state-of-the-art computer application used a graphical user
interface (GUI) consisting of buttons, menus, and a small set of other program controls that gave
the user the capability to interact with a given program. The application's aesthetic was efficiency
of space and parsimony of language. Programmers prided themselves on their ability to use as
few pixels as possible to convey the meaning of each action. Long explanations and anything
else that you might consider content was relegated to the system documentation.
Multimedia applications began to overturn this aesthetic, and the Web destroyed it. After users
stopped working with data and started working with content, the assumptions of how to create an
application shifted, too. Interspersing text, pictures, and sounds with application functionality
became not only acceptable, but also standard. And although the small set of standard program
controls never disappeared, a whole host of other controls appeared to deal with the interesting
new needs of content applications. The text hyperlink and the hyperpicture, for example, weren't
part of the classic GUI, but were added later to deal with the need to link from one piece of
information to another.
In the old world, the premium was on parsimony. Applications had terse menus, well-ordered and
trim dialog boxes, and buttons with one word or less (such as Del instead of Delete) on them. On
the Web, a new aesthetic has taken hold. If the old style was Spartan, then the new one is Attic.
On the Web, the menus can come with a paragraph of text. Dialog boxes are interspersed with
pictures, ads, text, and links to other sites and applications all across the Web. The "buttons," in
the form of linked images, stretch all the way across the screen. The result is a tremendous
amount of mixing between content and functionality, and a blurring of which is which.
In the older software applications, the programming code that creates functionality was packed
deep inside executable files (EXEs). On the Web, you can type computer code directly into HTML
(today's basic language that you use to create Web pages) just as you can any other content.
Although this mixing of content and functionality has caused untold thousands of all-nighters by
frustrated programmers who pine for the good old days of neatly encapsulated programs, it's also
provided the capability to create an entirely new way of thinking about an application. In the past,
an application was a single, defined thing. Applications changed interface or functionality only
once every year or two, when the creators made another product release. On the Web, not only
can you change interface and functionality, but you're fully expected to do so. A good site delivers
personalized functionality based on what it can infer about the user. The same functionality may
show up in different contexts, and a particular function may even be represented with different
controls, depending on the situation.
On the Web, functionality and content are mixed and matched to whatever extent the site owners
can manage. It's a management issue. To mix and match content and functionality, you must be
well organized. You must have a lot of structure in place that enables you to efficiently store and
deliver your functionality where and when you need it. In short, you need a CMS.
Functionality objects enable you to treat functionality more as content. The new aesthetic, of
content-rich applications that provide personalized functionality to the user, demands the use of
functionality as content objects. Luckily, you can use the same tools and processes to manage
functionality as you do content.
CM Domain White Paper
Bob Boiko
Copyright 2002 Metatorial Services Inc. & HungryMinds Inc.
Do not reproduce without permission.
Page 4
Managing Functionality Like Information
Content management consists of collecting, managing, and publishing content. I define content
as information that you enhance with data and put to a particular use. I can now extend the
definition of content to include functionality that you've packaged for reuse in objects or in blocks
of programming code.
To illustrate this notion, look at a piece of information and a piece of functionality that you must
manage:
Suppose that Wingnuts, Inc., wants to make people aware of upcoming marketing events.
People, in this case, means staff, partners, and customers. Making aware means listing the
appropriate events on the company's intranet, on the Internet, and in e-mail messages.
The following events functionality is available to Wingnuts in a programming object:
?? Listing event descriptions.
?? Showing the details of a single event.
?? Creating a new event.
?? Deleting an event.
The information that the object can provide for an event is as follows:
?? A name.
?? A location.
?? A date.
?? A description.
?? A picture.
?? An owner.
?? Target customer type.
?? Marketing purpose.
You can imagine that, for the different combinations of person and outlet (which refers to
audience and publication in CMS-speak), you must use the appropriate set of functionality and
information, as follows:
?? Staff should be able to list, show detail, and create events on the Internet or intranet. If any
staffers are the event owners, then they should be able to delete them, too. Staff shouldn't be
bothered by e-mail and should see all the information associated with an event.
?? Partners see events only on the Internet site and in e-mail messages. On the Internet, they
should be able only to list and show details of events. The information that they see on the
Internet shouldn't include the marketing purpose of the event. In e-mail, they should see only
a list of events, but each list item should contain a link to a page on the Internet site that
shows the event detail.
?? Customers (like partners) see events only on the Internet site and in e-mail messages and
should have only two options on the Web, list events and show event detail functions.
How much difference exists between the way that you must manage functionality and the way
that you manage the information? First, notice that you do need to manage both the information
and the functionality. You need to publish both in the same three publications (the intranet site,
the Internet site, and e-mail messages). You need to store both in a way that you can access a
subset of their parts. Finally, you need to subject both to the same rules that determine which
parts are available to whom and in what publication.
CM Domain White Paper
Bob Boiko
Copyright 2002 Metatorial Services Inc. & HungryMinds Inc.
Do not reproduce without permission.
Page 5
Both functionality and information are kinds of content that you need to create, store, and access
in such a way that you can target and format them appropriately for publication. With functionality,
as with information, you can tackle the problem of managing - multiple publications by hand or by
using a CMS.
Publishing functionality on the Web
Because you bring functionality onto a Web page via blocks of text, you can treat that
functionality as just another type of content to publish.
If you look inside a Web page, then you see that everything in it is text. In HTML, for example, the
following text block causes a button to appear on the page. The button, after someone clicks it,
initiates a search:
<input type=submit value=Search>
If you want the same button on ten pages, then you simply include the same text block on each
page.
The next text block calls a Java applet onto the page. An applet is a "miniapplication," or, as I call
it in this white paper, a functionality object. The following code passes the applet all the
information that it needs to do its job:
<applet code="Events.class" width="468" height="234">
<param name="User Type" value="Staff">
<param name="Pub" value="Intranet">
</applet>
The <applet> tag tells you which Java applet you want on the page, and the <param> tags pass
the applet all the information that it needs to perform its functions correctly. In this case, you can
probably guess that this applet lists events and can behave differently based on the user type and
publication. You really see no difference between storing the block of text that invokes this applet
and storing a block of text that describes an event. Moreover, no extra process or software is
necessary to embed this block of functionality in a container that tells a CMS what the
functionality is for, to whom it applies, its status, and on what pages to include it. The same
process that you use to create a content component from a block of information you can also use
to create a component from a block of functionality definition. Whether it's delivering functionality
or information onto a page matters not at all to a CMS.
Of course, I don't discuss a lot of details here, such as how you package and deploy the events
applet and exactly how you go about storing complete code blocks versus dynamically filling in
the correct parameters. But that's not my task at the moment. The point that I hope I'm making
here is that if you store a functionality generating text block and call it into publications, then
you're making it into just another kind of content component.
Even at the highest level, the similarities are solid. Whether you're managing information or
functionality, you make an agreement with the creator or owner that enables you to capture her
valuable creation; you devise a way to store what you collect; and you devise a way to deliver the
creation electronically to the people who need it.
As you see in more detail throughout this white paper, a CMS provides the following
capabilities— and more— for effectively managing and delivering functionality:
?? The CMS repository provides a place to store the code chunks that provide the functionality.
?? The CMS metadata facilities provide a way to tag functionality so that you can effectively
store, locate, and select it for use in a particular page.
CM Domain White Paper
Bob Boiko
Copyright 2002 Metatorial Services Inc. & HungryMinds Inc.
Do not reproduce without permission.
Page 6
?? The CMS workflow system provides a way to wrap the functionality in a process for
reviewing and approving it. Many CMS systems actually supplant the source code
management systems that programming organizations traditionally use.
?? The CMS templating system provides the capability to locate a particular chunk of
functionality on a particular page based on the user, or any other rules that you may use to
place information on a page. In addition, the templating system enables you to customize the
user interface of the functionality based on rules that you design. You may present the
beginner's interface or the advanced interface, for example, based on the perceived
computer savvy of the user.
Where information and functionality diverge
Where information and functionality management diverge is in the details, as the following list
describes:
?? To collect content, you work with authors or bulk content sources. To collect functionality,
you work with application developers. Instead of making an agreement with a person to
deliver a certain type of information, you make an agreement with a programmer to supply
software code segments that create the functionality. You also make an agreement with a
system administrator, who assures that, when the code runs someday, the database or other
system that the code works with is available and ready to respond.
?? To manage content, you send it through a variety of workflows that ensure its accuracy,
connection to other content (metadata), and relevance. To manage functionality, you send it
through a variety of workflows to ensure that it works as you want (that is, with no bugs), is
the most current version available, and can connect to its data sources.
?? To publish content, you create templates that draw in relevant content chunks and
navigation. You ensure that the content always makes sense relative to the other content that
surrounds it. To publish functionality, you create templates that draw in and integrate code
chunks with the surrounding code in the template. You ensure that any supporting code
registers on the Web server and is ready for the code that you draw into templates to call it.
You also ensure that all connections to other servers or data sources are enabled on the
server.
By and large, these details fall below the radar of a CMS. The biggest hurdle to overcome is the
mindset change that your developers and organization may need to undergo. They, too, must
come to believe that functionality is a kind of content to collect, manage, and publish just as
information is.
Tip
People frequently ask when you would put your functionality code into the CMS repository and when
you would not. One reason not to put code in the repository is if programmers are used to a different,
or more sophisticated, version control system, but the CMS that you choose or build doesn't offer that
level of sophistication.
Summary
Functionality is the capability to interact with a computer to perform a particular task. You create
functionality by programming it using computer code and by presenting it in a user interface. Here
are some things to keep in mind about modern functionality and how it relates to content:
?? Where previously functionality was trapped within massive programs, today it's segmented
into lightweight objects and code blocks that you can share and reuse in a variety of contexts.
CM Domain White Paper
Bob Boiko
Copyright 2002 Metatorial Services Inc. & HungryMinds Inc.
Do not reproduce without permission.
Page 7
?? Where previously functionality stood separate from information, today it so intermixes with
text, pictures, and other types of information that determining just where the information ends,
and the functionality begins, is often difficult.
?? In construction and in presentation, functionality shares so many of the attributes of content
that you have no reason not to treat it as just another type of content.
CM Domain White Paper
Bob Boiko
Copyright 2002 Metatorial Services Inc. & HungryMinds Inc.
Do not reproduce without permission.
Page 8