What will Intranet applications ultimately look like? Until we have more
experience, it may be impossible to tell. However, the following is my attempt
at five general rules meant to help sort through some of the issues involved in
designing an Intranet application.
#1: Think beyond traditional applications - think about
the whole function.
Because Intranet applications are modular, we can support more complete
functions. We do not have to pre-structure all the processes and information. We
do not have to build all the pieces at once. Think about the objectives, the end
result and alternate ways to get there.
#2: Develop the process in terms of functional classes and
how they relate to each other.
As complex, general-purpose applications begin to deconstruct into more
simplified functional logic, we will see how functional classes can be shared
across specialty domains. For example, most applications can be defined in terms
of the four functional classes listed below.
- Tracking (customers, resources, trouble tickets,
inventories)
- Configuring (products, solutions, benefits, financial
instruments)
- Informing
- Publication (pull)
- Notification (push)
- Exchanging
- Negotiations (ideas)
- Collaboration (ideas)
- Transactions (money)
Whether the number of basic classes is more or less than four, and whether these
are the "right" four, is not the point. The point is that classes such as these
allow us to reuse our content and tools across a broader range of domains than
the content and tools embedded in the current "silo" applications. As we gain
more experience the most effective classes will emerge.
#3: For each function within the solution identify whether
the process being supported is structured, semi-structured
or unstructured.
For each functional class ask what you expect of the user: repetition and
standard behavior or thought and innovation? Recognize that some of each may be
required in the process of reaching an end result. However, for a specific
functional class in a specific process the degree of structure should be
identifiable. Determining the degree of structure will help identify the tool or
approach for implementing the functional class. When the processes in a
functional class are well structured (e.g. money transactions, scheduling,
tracking, user profiling) database technology is indicated. When processes are
less structured (e.g. requests for others' experience, innovation, creation,
negotiation, exception handling) the message-based technologies are more
appropriate.
#4 View each interaction with the user in terms of the
appropriate degree of push and pull
This concept has been presented in detail in previous chapters. When identifying
push-pull characteristics for Intranet applications the following guidelines are
useful:
- Push what is needed now that has a short life
- One-time Notices and Requests
- Personal Communication
- Pull what will be referenced in the future
- Anything printed for large numbers of employees
- Recurring communication ( e.g.standing meeting
minutes)
- If it is not obvious, consider subscription agents
(list servers & personal agents)
#5 Support learning by individuals and the organization.
Unlike traditional applications, Intranet applications should be designed with
adaptation and learning in mind. Individuals can learn in several ways. They can
learn from the knowledge base, by retrieving what they and others have
previously learned and captured. They can learn by recombining and extrapolating
what they, or the knowledge base, previously learned. They can learn from
experience, through random or systematic trials. For the organization, learning
means not only solving the problem, but capturing the experience in the
knowledge base.
It should be obvious that learning can happen in both
structured and unstructured environments. Any complex
Intranet application should provide an area for unstructured
activity, an area where new knowledge can be generated.
These areas may take the form of discussion groups or chat
rooms for asking questions or brainstorming ideas, or they
may be tools that allow users to create what I earlier
called throw-away applications. These are applications that
are so quick and easy to create that non-technical users can
quickly build and publish custom functionality. Examples
that exist today are the wizards that let users create a
threaded discussion group within minutes to discuss their
single issue or to create a form to collect structured
feedback. In the future, we will see Java applets that look
like spreadsheets, can be configured for specific functions
just like today's spreadsheets, then included in an HTML
page.
|
|
