[Sigia-l] 'Enterprise portals'

[Ruth Kaufman]

Hello. I'm new to the list, but I'll jump right in because I've been 
working a lot with portals lately.

On Wednesday, October 1, 2003, at 04:01 PM, Peter VanDijck wrote:

> Any ideas on 'enterprise portals'? They are (obviously) being pushed by
> the portal vendors. What is it? What should be guiding principles of
> building one? I'm looking for ideas on the conceptual level, but no the
> usual marketing drab. (I know, not easy).

I have two working definitions for "portal" that I use with my 
colleagues. I'm not assuming "intranet" -- this can apply to any kind 
of web domain.

1) User experience definition: An audience portal or a themed portal of 
some kind refers to the user experience of a particular type of web 
domain. A portal-like site or domain typically offers a user loads and 
loads of content and sometimes "miniapps" (as SAP calls them) or 
portlets (as WebSphere calls them) and web services. The content, 
applications and services may or may not "reside" within the domain. 
For example, Yahoo! aggregates much of its content, whereas NYC.gov 
supplies mostly its own content. A portal-like site also offers the 
user many ways to find, experience, and/or use the content -- search, 
navigation structures, directories, related links, adaptive 
personalization, etc.

2) Technology definition: A web site or domain could be called a portal 
simply if it's built using a "portal" product such as SAP, WebSphere, 
etc. The portal product may give site architects and builders tools for 
creating the kind of user experience described above, but the portal 
technology is, after all, just a tool. At the end of the day, a 
portal-like site can be built using any technology. I used to manage 
one manually about 5 years ago (but I don't recommend it!). Back to 
portal products. A portal site, if speaking strictly about the 
technical definition, can be an instance of the portal technology or it 
can be more like a subdomain -- a chunk of web stuff managed by the 
portal product, depending on the features of the specific product. Site 
architects could create a one-to-one relationship between a portal 
instance and a portal-like experience for their audiences, or the 
front-end design could mask back-end architecture.

> Here's a starter: what happens with the enterprise portal idea (I 
> refuse
> to write 'EP') when the next big thing comes along in 2-3 years?
I personally think portals, as information gateways, are here to stay, 
but we will develop better designs and apply their utility more 
judiciously. Some content and some audiences beg for portals, such as 
government information. Other portals transmit a lot of noise. Going 
forward, I think the functionality implied by "portal" will become more 
tailored to niche applications of the most successful user experience 
strategies and business concepts.

> What
> are the real, practical applications of an enterprise portal?
A few that come to mind:
*Aggregated* consumer services (financial services, home/auto 
maintenance, account management, etc. -- or at least this is on my wish 
list :))
Research services (BBB, consumer reviews, historical parts information, 
etc.)
Government services (community portals, access to forms, information 
about procedures, etc.)
Intranets (corporate communications, HR resources, tech support, 
mind-melding (aka knowledge management), networking, etc. -- perhaps 
too obvious an example)
...
I didn't realize this at first, but perhaps the net of it is Services. 
A lot of this stuff already exists in some form. I think audiences need 
to evolve alongside the technology and its potential applications. Five 
years ago I would have been very hesitant to bank online. This year, I 
haven't used even 10 stamps.


> When
> shouldn't you have one?
Some ideas:
When you have a specific message to communicate to a specific audience 
(i.e., when you don't require flexibility).
When your message /is/ your site (i.e., when your messaging suffers if 
you separate content from format.)
In the case of aggregated miniapps and web services -- when your users 
are better off using desktop apps, even if they're client-server apps. 
Sometimes the ergonomics are just better.

> What would it look like?
Depends on what it is. Does it mimic a web site? Is it a shopping 
venue? Is it trying to replace the Windows desktop? The more 
fundamental question is, what is it for?

> What is the role of
> personalization?
Three basic kinds of personalization.
1) Entitled spaces based on user profiling. e.g., customer extranets.

2) Customization -- Tools for users to customize a "MySpace" e.g., 
Yahoo!'s My Yahoo! These tools are appropriate when your users have to 
actually work (or play) at your site/domain for an extended period of 
time. You know that they'll be returning frequently. Overuse of these 
features will annoy users who don't perceive value in taking the time 
to establish a personalized space.

3) Adaptive personalization -- tracking user activities (openly or 
stealthily) and serving up content and function based on business rules 
and profile information. e.g., Amazon.com's "New For You". Clearly, 
this is appropriate for targeted messaging and promotions.

There's also the idea of extending personalization beyond the domain 
through off-site/off-line communication with the user. For example, 
when an amazon.com business partner refers to me by my first name 
because I have an amazon.com cookie on my machine. That's still a 
little creepy, but I think as audiences become familiar with these 
kinds of services, it will become incredibly useful. In a sense, it's 
the inverse of the portal concept.

Hope this helps.

Ruth