Simon,

The first thing that comes to mind for me, in terms of intranet
best practices, is to understand current and evolving work
practices--so that the shibboleth of productivity can actually
become a real value.

In other words, user research, user research, more user research.
You know the users, and you can talk to them at any time. No more
excuse for failing to study their needs--at the beginning of each
project and over time.

Marijke


Simon Grant wrote:
>
> Hi all
>
> I joined this list as I will shortly be in an environment
> designing intranet applications, and I wondered, do people
> know of any good summary - like best practice - of the
> use of corporate intranets in general? Or particular
> aspects (human, not technical) of best practice?
>
> I'll borrow a practice from chi-web and offer to summarise
> replies received if you don't think they are worthy of
> a separate post to this list.
>
> Thanks
>
> Simon
> --
> Simon Grant
> Personal http://www.simongrant.org/home.html  a @ simongrant.org
> Information Strategists http://www.inst.co.uk/  inst @ inst.co.uk
>
>
> To unsubscribe from this group, send an email to:
> intranet-user-experience-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--
Marijke Rijsberman       marijke@...        650-493-5201

- Interfacility  - - - - - - - - - - - - http://www.interfacility.com/
Creating conditions for success in interactive design projects.

- iBuilders Project Managers Forum  - http://projectmanagersforum.net/
Meeting place and community for people who manage interactive design
projects.

- "O Time, Cash, Strength, and Patience!" -- Herman Melville

Hi all

I joined this list as I will shortly be in an environment
designing intranet applications, and I wondered, do people
know of any good summary - like best practice - of the
use of corporate intranets in general? Or particular
aspects (human, not technical) of best practice?

I'll borrow a practice from chi-web and offer to summarise
replies received if you don't think they are worthy of
a separate post to this list.

Thanks

Simon
--
Simon Grant
Personal http://www.simongrant.org/home.html  a @ simongrant.org
Information Strategists http://www.inst.co.uk/  inst @ inst.co.uk

List Members,

I've been asked to take a look at a group called Hubbard One who
claim to have software which handles content management for internet,
intranet and extranet sites.  Don't have anything more specific on
them, but they are marketing to law firms.  Anyone know anything
about them?

Your feedback is welcome online and offline.

Carole M. Ekker
Global Information Services
Akin, Gump, Strauss, Hauer & Feld, LLP
Washington, DC
mailto:cekker@...

Anne makes several good points that are worthy of consideration.  However,
because of circumstances in our organization, we are unable to comply with the
development model she describes.  We are personnel poor and politically
challenged -- our development staff is very limited and busy with other things,
and the homegrown portal solution is the victim of some nasty politics.

Despite the worthy merit of developing an intranet portal yourself (I'll get to
the definition part in a minute), we really are going to be better off with a
commercial solution.  Having been personally responsible for generating and
sustaining interest in the portal, recruiting content contributors, and training
page and content administrators, I for one will be relieved to have access to
some of the tools offered by the commercial solutions.  I agree that content is
king -- I've spent the
majority of the last 18 months laying the groundwork for content generation.  We
simply aren't in a position to create the necessary tools to enable publication
of content.

As for the definition of the portal we are looking to deploy, we are setting our
sights on what I'll call, for lack of a better term, a "full service portal",
one that will contain information about and access to a wide a variety of things
-- firm information (knowledge bases, contact information, access to billing
records), applications (time keeping, document assembly), and personal tools
(mail, weather, stocks, personal Web favorites).  The paradigm is one which
replaces the desktop,
incorporating business process into a single homogenous interface.  A true
gateway to all the tools our staff need to conduct business (including checking
their stocks without having to wander too far afield).

That said, I still am anxious to get any feedback.  I know what I'd like to do
this time around, having had the intranet building experience once already, but
I never like to create in a vacuum.

Keep the comments coming, and anything Plumtree or Hummingbird specific is
welcome.

Carole Ekker
Global Information Systems
Akin Gump Strauss Hauer & Feld
Washington, DC
mailto:cekker@...

-----Original Message-----
From: South, Anne [mailto:Anne.South@...]
Sent: Monday, August 20, 2001 6:45 PM
To: 'intranet-user-experience@yahoogroups.com'
Subject: RE: [intranetUX] Portal Shopping - Plumtree vs. Hummingbird


Hi Carole,

I'm interested to hear what you mean by a portal. Do you mean something that
is capable of personalisation? Something that can enable easy authoring? A
web page crammed with information and content feeds?

We looked into developing a portal about 12 months ago. The company I work
for is quite a bit larger than yours, but after doing some research, I came
to the opinion that there was a lot of "vaporware" on sale for
extraordinarily large sums of money. My impression is that portal technology
was quite immature, and what was being offered required a lot of hidden work
behind it on the business side to put it to good use.

I would only give the following advice that might not necessarily be
relevant to your situation. These are mandates that we try to follow.
1) The strength of internet technologies arises from the fact that it is an
open and free protocol. Wherever possible, we favour products that do not
tie us down to proprietary solutions.
2) By far, the "smarts" around an Intranet occur on the business side. We
are now focusing on being clever with content, not clever with technology.
The lower-end technology is more than adequate to provide most
functionality, and we feel the energy is better spent on developing good
content and ensuring there are business processes in place about owning that
content. You will never be able to buy that from a software vendor.

Good luck with your portal.

thanks,

Annie
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Annie South
Information Architect

Intranet Management Project
Telstra | Finance and Administration | eProcesses
Level 18, 242 Exhibition St, Melbourne  3000
(03) 9634 4996  :  Tel
(03) 9634 5151  :  Fax
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> -----Original Message-----
> From: cekker@... [SMTP:cekker@...]
> Sent: Tuesday, 21 August 2001 8:34 am
> To: intranet-user-experience@yahoogroups.com
> Subject: [intranetUX] Portal Shopping - Plumtree vs. Hummingbird
>
> Hello List Members!  I am thrilled to have found this active and
> intelligent group of people.
>
> My firm currently has a "home grown" Intranet Portal developed in
> Domino.  It's a less than satisfactory solution (for reasons which are
> not necessarily related to the platform), so we are considering
> migrating to a commercial package.  We are focusing on Plumtree and
> Hummingbird as the major contenders.  I've been given the job of
> putting together evaluative information on these two products in
> particular and the portal market generally.  I've looked at both of
> them and have an initial preference but need to be sure I'm looking
> at all the factors.
>
> I've got a few questions for those of you familiar with either of the
> two products I'm evaluating which will help me in navigating through
> the pros and cons of these products.  If you or your company have
> implemented or developed an intranet portal, I'm interested in finding
> out your experiences generally, and with either of these products
> specifically.
>
> Here are a few details for context:  We are a large international law
> firm, about 3,000 end users in 15 offices on two continents.
> Infrastructure is medium grade.  Offices are connected by WAN.
> Network is NT 4.0.  Browser is IE 5.5.  DMS is PC Docs.  Mail is MS
> Exchange.  RAS is through Citrix.  Back office accounting system will
> soon be CMS.  Although we have some Notes applications, we will be
> phasing them out over time.  Office applications are Microsoft.
>
> What software are you using for your Portal (i.e., one of the
> commercial packages or a combination of pieces)?
>
> What products are you currently evaluating or, if already implemented,
> which ones did you evaluate prior to deciding?
>
> If you've already decided on a product or implemented a Portal, what
> was the deciding factor which led you to the product or solution you
> selected?
>
> Did you use an integrator to get your Portal up and running?
>
> What issues arose during implementation?
>
> Plumtree and Hummingbird both boast about their development tools.  If
> you know them, have you found these to be flexible and easy to use?
>
> Are there any best practices you would recommend following in
> implementing an Intranet Portal in general or with regard to these
> products specifically?
>
> I gratefully thank you in advance for any feedback you can provide.
> If anyone would like to contact me personally, please feel free to
> email.
>
> Carole M. Ekker
> Global Information Services
> Akin, Gump, Strauss, Hauer & Feld LLP
> mailto:cekker@...
>
>
>
>
> To unsubscribe from this group, send an email to:
> intranet-user-experience-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>


To unsubscribe from this group, send an email to:
intranet-user-experience-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



The information contained in this e-mail message is intended only for the
personal and confidential use of the recipient(s) named above. This message may
be an attorney-client communication and/or work product and as such is
privileged and confidential. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended recipient,
you are hereby notified that you have received this document in error and that
any review, dissemination, distribution, or copying of this message is strictly
prohibited. If you have received this communication in error, please notify us
immediately by e-mail, and delete the original message.

Hi Carole,

I'm interested to hear what you mean by a portal. Do you mean something that
is capable of personalisation? Something that can enable easy authoring? A
web page crammed with information and content feeds?

We looked into developing a portal about 12 months ago. The company I work
for is quite a bit larger than yours, but after doing some research, I came
to the opinion that there was a lot of "vaporware" on sale for
extraordinarily large sums of money. My impression is that portal technology
was quite immature, and what was being offered required a lot of hidden work
behind it on the business side to put it to good use.

I would only give the following advice that might not necessarily be
relevant to your situation. These are mandates that we try to follow.
1) The strength of internet technologies arises from the fact that it is an
open and free protocol. Wherever possible, we favour products that do not
tie us down to proprietary solutions.
2) By far, the "smarts" around an Intranet occur on the business side. We
are now focusing on being clever with content, not clever with technology.
The lower-end technology is more than adequate to provide most
functionality, and we feel the energy is better spent on developing good
content and ensuring there are business processes in place about owning that
content. You will never be able to buy that from a software vendor.

Good luck with your portal.

thanks,

Annie
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Annie South
Information Architect

Intranet Management Project
Telstra | Finance and Administration | eProcesses
Level 18, 242 Exhibition St, Melbourne  3000
(03) 9634 4996  :  Tel
(03) 9634 5151  :  Fax
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> -----Original Message-----
> From: cekker@... [SMTP:cekker@...]
> Sent: Tuesday, 21 August 2001 8:34 am
> To: intranet-user-experience@yahoogroups.com
> Subject: [intranetUX] Portal Shopping - Plumtree vs. Hummingbird
>
> Hello List Members!  I am thrilled to have found this active and
> intelligent group of people.
>
> My firm currently has a "home grown" Intranet Portal developed in
> Domino.  It's a less than satisfactory solution (for reasons which are
> not necessarily related to the platform), so we are considering
> migrating to a commercial package.  We are focusing on Plumtree and
> Hummingbird as the major contenders.  I've been given the job of
> putting together evaluative information on these two products in
> particular and the portal market generally.  I've looked at both of
> them and have an initial preference but need to be sure I'm looking
> at all the factors.
>
> I've got a few questions for those of you familiar with either of the
> two products I'm evaluating which will help me in navigating through
> the pros and cons of these products.  If you or your company have
> implemented or developed an intranet portal, I'm interested in finding
> out your experiences generally, and with either of these products
> specifically.
>
> Here are a few details for context:  We are a large international law
> firm, about 3,000 end users in 15 offices on two continents.
> Infrastructure is medium grade.  Offices are connected by WAN.
> Network is NT 4.0.  Browser is IE 5.5.  DMS is PC Docs.  Mail is MS
> Exchange.  RAS is through Citrix.  Back office accounting system will
> soon be CMS.  Although we have some Notes applications, we will be
> phasing them out over time.  Office applications are Microsoft.
>
> What software are you using for your Portal (i.e., one of the
> commercial packages or a combination of pieces)?
>
> What products are you currently evaluating or, if already implemented,
> which ones did you evaluate prior to deciding?
>
> If you've already decided on a product or implemented a Portal, what
> was the deciding factor which led you to the product or solution you
> selected?
>
> Did you use an integrator to get your Portal up and running?
>
> What issues arose during implementation?
>
> Plumtree and Hummingbird both boast about their development tools.  If
> you know them, have you found these to be flexible and easy to use?
>
> Are there any best practices you would recommend following in
> implementing an Intranet Portal in general or with regard to these
> products specifically?
>
> I gratefully thank you in advance for any feedback you can provide.
> If anyone would like to contact me personally, please feel free to
> email.
>
> Carole M. Ekker
> Global Information Services
> Akin, Gump, Strauss, Hauer & Feld LLP
> mailto:cekker@...
>
>
>
>
> To unsubscribe from this group, send an email to:
> intranet-user-experience-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

Hello List Members!  I am thrilled to have found this active and
intelligent group of people.

My firm currently has a "home grown" Intranet Portal developed in
Domino.  It's a less than satisfactory solution (for reasons which are
not necessarily related to the platform), so we are considering
migrating to a commercial package.  We are focusing on Plumtree and
Hummingbird as the major contenders.  I've been given the job of
putting together evaluative information on these two products in
particular and the portal market generally.  I've looked at both of
them and have an initial preference but need to be sure I'm looking
at all the factors.

I've got a few questions for those of you familiar with either of the
two products I'm evaluating which will help me in navigating through
the pros and cons of these products.  If you or your company have
implemented or developed an intranet portal, I'm interested in finding
out your experiences generally, and with either of these products
specifically.

Here are a few details for context:  We are a large international law
firm, about 3,000 end users in 15 offices on two continents.
Infrastructure is medium grade.  Offices are connected by WAN.
Network is NT 4.0.  Browser is IE 5.5.  DMS is PC Docs.  Mail is MS
Exchange.  RAS is through Citrix.  Back office accounting system will
soon be CMS.  Although we have some Notes applications, we will be
phasing them out over time.  Office applications are Microsoft.

What software are you using for your Portal (i.e., one of the
commercial packages or a combination of pieces)?

What products are you currently evaluating or, if already implemented,
which ones did you evaluate prior to deciding?

If you've already decided on a product or implemented a Portal, what
was the deciding factor which led you to the product or solution you
selected?

Did you use an integrator to get your Portal up and running?

What issues arose during implementation?

Plumtree and Hummingbird both boast about their development tools.  If
you know them, have you found these to be flexible and easy to use?

Are there any best practices you would recommend following in
implementing an Intranet Portal in general or with regard to these
products specifically?

I gratefully thank you in advance for any feedback you can provide.
If anyone would like to contact me personally, please feel free to
email.

Carole M. Ekker
Global Information Services
Akin, Gump, Strauss, Hauer & Feld LLP
mailto:cekker@...

I'm with Ward on this quesiton ... > Why not give the intended
users ... a list of functions and let them tell you what to label
them? You may at least get an idea as to the relative brevity (or
lack thereof) that they are comfortable with or expect ..."<

In my world (big international law firm) there are two development
methodologies -- On the one hand there is the one which operates from
the premise that the end user doesn't have a clue and it is the
developer's job to tell them what they want.  On the other hand,
there is the methodology which starts from the opposite shore, that
of the end user's wants, needs and desires.

I am a fan of the latter, and view development as an act of
diplomacy.  That is, find out what the end user hopes to accomplish
(in this case let's say finding something on the intranet which
fulfills a business need or purpose), but give them good advice when
they appear to be straying from good technical design principles.

It's a fine line and requires a great deal of balancing, but I think
in the end you get better UI, happier clients, and a more successful
product.

Carole M. Ekker
Project Manager
Akin Gump Strauss Hauer & Feld
Washington, DC
mailto:cekker@...

The concept of subsites has been extremely important to our Intranet
development. We came to the realisation about 18 months ago that this was
the only way we could really structure the Intranet in any meaningful way.

To give you some context, our Intranet is huge and until recently had little
or no centralised management. We conducted an audit last year and found
around 800 sites, and suspected another 400 or so existed. We have over
300,000 pages.

We are currently implementing this sitelet idea. We have defined a number of
"sitelet types". These types, at the moment are things like "organisational
unit", "product or service", "project" etc. The focus here is on sitelets to
deliver information rather than enable some workflow or application. For
each sitelet, we are in the process of defining a number of mandatory
elements, and a number of recommended elements. The mandatory elements are
things like "about this site", and "site owner". For an org unit site, other
mandatory elements are things like "our people", "org chart" etc. The
recommended elements are things we have identified that exist on most sites
of that type. In essence, we provide an IA stencil that authors can fill
with their own content. They can add their own custom elements to the site,
as they see fit (within certain rules, such as the structure must be at most
three tier).

We are about to launch a site building tool that enables easy non-technical
authoring. The plus for authors is that when they use our mandatory and
recommended elements, these elements are indexed and searchable at the
highest level (home page). For instance, the "about this site" enables users
to browse by site types, or do a key word search on these descriptions.

We launch in October. I'll let you know how it goes.

Annie


> -----Original Message-----
> From: dcjarvis@... [SMTP:dcjarvis@...]
> Sent: Tuesday, 14 August 2001 11:14 pm
> To: intranet-user-experience@yahoogroups.com
> Subject: [intranetUX] Sub sites
>
> All,
>
> I'm working on an intranet project for a corporate client in the UK.
>
> I am toying with using the concept of "sub-sites" to organise content
> and navigation for the intranet. By this I mean rejecting the common
> approach of having a nav bar on the screen at all times which allows
> the user to navigate around all areas of information. Instead I want
> to create separate mini sites for particular functions/features for
> defined user groups, eg a News site to hold internal and external
> announcements. The reason for this is to facilitate expandability and
> flexibility as time goes on.
>
> Does anyone have any advice or experiences with using this concept
> that they would be willing to share?
>
> Thanks, d
>
>
> To unsubscribe from this group, send an email to:
> intranet-user-experience-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

All,

I'm working on an intranet project for a corporate client in the UK.

I am toying with using the concept of "sub-sites" to organise content
and navigation for the intranet. By this I mean rejecting the common
approach of having a nav bar on the screen at all times which allows
the user to navigate around all areas of information. Instead I want
to create separate mini sites for particular functions/features for
defined user groups, eg a News site to hold internal and external
announcements. The reason for this is to facilitate expandability and
flexibility as time goes on.

Does anyone have any advice or experiences with using this concept
that they would be willing to share?

Thanks, d

Thanks, this is exactly the sort of story I'm looking for.  And you
are not the only one who's seen the tension between content metadata
(which is a lot of work) and the search engine (which really needs
that metadata).

Avi

At 10:23 AM -0500 8/13/01, Michelle L Keller wrote:
>I was not part of the intranet search engine selection or install process
>but I can tell you I hear about it all the time! Our search engine is
>pretty awful.  It consistently tops the list of complaints from our users.
>The person most responsible for the search engine blames the site
>publishers for not including enough metadata about their sites in the
>headers.  The site publishers blame the search engine set-up.  I think
>they're both right!
>
>I share this as a warning...whatever you choose, make sure you understand
>what will be needed from both the set-up/installation standpoint and the
>publisher standpont.  And be ready to do a few "education" sessions to make
>sure everyone gets it and is working together to make the search engine as
>effective as possible.

--
_________________________________________________
Complete Guide to Search Engines for Web Sites, Intranets,
    and Portals: <http://www.searchtools.com>

Paula Thornton wrote:
> You need to get out a little more often Alistar...
>
My thoughts:
This is a new list, and I believe an exciting one. It's important that we
all feel free and able to express our ideas and knowledge (or lack of)
without being made to feel stupid, ignorant or attacked. The comment to
Alistar made me cringe. I know Alistar probably didn't perceive it in this
way- but I did. Perhaps I'm not across a rapport or missing something in
translation between hemispheres. However, if engaging on a personal level,
rather than with the ideas becomes a normalised part of the culture of this
list, then I for one will not be participating.

Annie

Alastair: I think you'd agree that 'search' is an application (one that is
often grossly ill-designed).

In that regard, with the exception of those information portals that simply
hardcode access to topics, I'd say non-application portals are a minority.

The distinctions between information-only portals will fade (over 50% of all
browsees rely on 'search' as their primary means of navigation). But for
now, the focus and design intents of the two 'can' (but necessarily
shouldn't) be different.

Again, my only point is that should someone choose to use the term "portal"
in discussion on this group, they should add some clarification to avoid
confusion. There clearly are 'different' kinds.

> What if the "somewhere else" you are helped to get to is an
> "application" site (supports doing over finding); and what if there are
> very many of these destinations which you can get to from such a
> "portal" (i.e., these destination "application" sites are *only*
> accessible from this "portal")?

Does that affect the "portal"?  I'm not sure what your getting at here.  The
type of destination does not affect whether the status of a portal, does it?
Perhaps the homepage of Yahoo! is a portal and the applications provided by
Yahoo! are not, but you get to then from the homepage...

> Also, I posit the following:
>
> search site != portal
> finding == doing (or at least, finding is an example of doing)


I agree that finding is a subset of doing (I think we all understood what
Paula meant), however, a search site is a very good way of finding things,
so that arguement might need a little more explaination?

> In short, I don't think "portal" has ever been defined in such a way
> that it makes sense to talk about "the definition of 'portal'."

From the nearest dictionary:<cheeky grin>
"Portal, n 1 an entrance, gateway, or doorway, esp. one that is large and
impressive."
(not sure on the relevance of "large and impressive" in this context!)

-Alastair

What if the "somewhere else" you are helped to get to is an
"application" site (supports doing over finding); and what if there are
very many of these destinations which you can get to from such a
"portal" (i.e., these destination "application" sites are *only*
accessible from this "portal")?

Also, I posit the following:

search site != portal
finding == doing (or at least, finding is an example of doing)

In short, I don't think "portal" has ever been defined in such a way
that it makes sense to talk about "the definition of 'portal'."


FWIW,

<> Ward Conant
<> Solution Design and Production
<> URS Corporation - Information Technology Practice
<> tel 865.220.8154
<> fax 865.483.9061







"Alastair Campbell" <ac@...>
08/13/2001 12:18 PM
Please respond to intranet-user-experience


         To:     <intranet-user-experience@yahoogroups.com>
         cc:
         Subject:        Re: [intranetUX] Portals


To clarify my previous points:

A portal by definition is something to help you get somewhere else, i.e.
supporting the task of finding, rather than actually doing anything.  That
is a definition that many sites like Yahoo! exceed to keep people coming
back.

Precision seems to slip through anybody's hand the minute someone
tries to define
            what a word like Portal means.  It's ultimately popular usage
that just takes root
           and obliterates all other efforts to precisely define them.

           In the context of Intranets, a "Portal" generally seems to refer
to a single Web site address
           that all parties connected with the company go to do their stuff
in connection with the
           company.

           I was reading an interesting case study of CISCO's "Portals". They
have an Employee
           Connection Online for employees, Business Connection Online for
Customers to Configure
           and order their equipment online and a Manufacturing Connection
Online for their suppliers
           to find out what Cisco needs, bid for, and supply them. So they
seem to have three portals,
            one intranet and two extranets.

           Interesting tidbit from the case study about their Employee portal
was that initially  when they
           made information about their company *ONLY* available not many
employees used it apparently.
           However when they contracted with Yahoo to create a custom portal
that mixed Yahoo stuff with
           Cisco stuff, usage zoomed.

           The lesson here seems to be that in the minds of Intranet users, a
Portal is a single stop
           Web address for a set of functions!

           Just my 2 cents!

           Nari Kannan

Nari Kannan

Linkblox, Inc.
1725 Magnolia Circle
Pleasanton
CA 94566

Cell: 925 487 1768
Home: 925 600 7426

   -----Original Message-----
   From: Alastair Campbell [mailto:ac@...]
   Sent: Monday, August 13, 2001 9:19 AM
   To: intranet-user-experience@yahoogroups.com
   Subject: Re: [intranetUX] Portals


   To clarify my previous points:

   A portal by definition is something to help you get somewhere else, i.e.
   supporting the task of finding, rather than actually doing anything.  That
   is a definition that many sites like Yahoo! exceed to keep people coming
   back.

   I'm *not* saying that portal users shouldn't also be able to access
dynamic
   content, e.g. stocks/weather or
   "combine information from a costs database and an Excel spreadsheet to
   compare budget to actuals".
   (From http://www.businessobjects.com/products/bobj/bobj_2.htm, I didn't
have
   time to look around extensively, but it does appear to be a useful
intranet
   application.)

   IMHO however, these extras are beyond the (very limited) scope of just
being
   a portal.  Sorry to split hairs, I just don't see that a portal 'with
knobs
   on' is antthing else.  Some of the tools listed by Paula seemed to be
tools
   to help develop/deliver portals, and some were interesting intranet
   applications, but I don't see how these would fit within the term portal.

   Getting back to Jeff's original post, the page under development does
sound
   like it will use static content, and will not include web apps etc.
   directly, so will *just* be a portal.  A useful page of links like the old
   days ;)

   -Alastair


   ----- Original Message -----
   From: "Paula Thornton" <paula.thornton@...>

   > Alastair: Any clarification on the comment about end-user vs.developer
   > perspective? It appears unfounded. All of the tools listed were end user
   > deliverables (they're simply portal delivery products), and several of
   them
   > were analytical tools (I mixed and matched arbitrarily).
   >
   > Lastly, ever notice on Yahoo!, Excite and the like that there are things
   > like stock quotes, weather, etc.? That makes those the same blended
   portals
   > as the others.


   To unsubscribe from this group, send an email to:
   intranet-user-experience-unsubscribe@yahoogroups.com



   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]

To clarify my previous points:

A portal by definition is something to help you get somewhere else, i.e.
supporting the task of finding, rather than actually doing anything.  That
is a definition that many sites like Yahoo! exceed to keep people coming
back.

I'm *not* saying that portal users shouldn't also be able to access dynamic
content, e.g. stocks/weather or
"combine information from a costs database and an Excel spreadsheet to
compare budget to actuals".
(From http://www.businessobjects.com/products/bobj/bobj_2.htm, I didn't have
time to look around extensively, but it does appear to be a useful intranet
application.)

IMHO however, these extras are beyond the (very limited) scope of just being
a portal.  Sorry to split hairs, I just don't see that a portal 'with knobs
on' is antthing else.  Some of the tools listed by Paula seemed to be tools
to help develop/deliver portals, and some were interesting intranet
applications, but I don't see how these would fit within the term portal.

Getting back to Jeff's original post, the page under development does sound
like it will use static content, and will not include web apps etc.
directly, so will *just* be a portal.  A useful page of links like the old
days ;)

-Alastair


----- Original Message -----
From: "Paula Thornton" <paula.thornton@...>

> Alastair: Any clarification on the comment about end-user vs.developer
> perspective? It appears unfounded. All of the tools listed were end user
> deliverables (they're simply portal delivery products), and several of
them
> were analytical tools (I mixed and matched arbitrarily).
>
> Lastly, ever notice on Yahoo!, Excite and the like that there are things
> like stock quotes, weather, etc.? That makes those the same blended
portals
> as the others.

I was not part of the intranet search engine selection or install process
but I can tell you I hear about it all the time! Our search engine is
pretty awful.  It consistently tops the list of complaints from our users.
The person most responsible for the search engine blames the site
publishers for not including enough metadata about their sites in the
headers.  The site publishers blame the search engine set-up.  I think
they're both right!

I share this as a warning...whatever you choose, make sure you understand
what will be needed from both the set-up/installation standpoint and the
publisher standpont.  And be ready to do a few "education" sessions to make
sure everyone gets it and is working together to make the search engine as
effective as possible.

~~~~~~~~~~~~~~~
Michelle Keller, corporate intranet manager
Hallmark
816-274-4042
mkelle1@...

Jeff Lash wrote:

> Others involved in the project think that the links need more
> description/annotation. They don't think that, on their own, they will be
> descriptive enough. My feeling is that the annotation will clutter up and
> confuse the interface, and since it's only a very small group of people who
> will be using the page, and using it quite often, first-time visiting
> intuitiveness is not the top priority.

Alternatives:

(1) only first-time-visitors see annotations (or they only see
     them for the first week, or ...)

(2) annotations are removed from links after they're visited (once
     or some multiple of times)

(3) annotations are default, but user-selectable

The latter is the approach I'm using on a current project; each of
the portal modules has a description included ("legend") that will
display until the user chooses to hide it.

FWIW!
--
H*
Hassan Schroeder ----------------------------- hassan@...
Webtuitive Design ===(+1) 408-938-0567 === http://www.webtuitive.com

     -- creating dynamic Web sites and applications since 1994 --

Alastair Campbell wrote:
>
> I wasn't aware that the word portal had anything to do with
> application type web usage.

Sure - a "portal", "gateway" or <insert_fave_buzzword> aggregates
resources for a user. It's pretty limiting to think that includes
only static content, eh?

--
H*
Hassan Schroeder ----------------------------- hassan@...
Webtuitive Design ===(+1) 408-938-0567 === http://www.webtuitive.com

     -- creating dynamic Web sites and applications since 1994 --

Alastair: Any clarification on the comment about end-user vs.developer
perspective? It appears unfounded. All of the tools listed were end user
deliverables (they're simply portal delivery products), and several of them
were analytical tools (I mixed and matched arbitrarily).

Lastly, ever notice on Yahoo!, Excite and the like that there are things
like stock quotes, weather, etc.? That makes those the same blended portals
as the others.

Ah, I see the confusion now.  I was thinking from the end user's perspective
rather than the developer's.  I would assume that there are many tools to
make portals, but they aren't actually portals themselves...  (E.g. a canvas
is not a painting.)

I am interested in the analytical tools Paula mentioned, since that might
expand what I would consider a portal to be.  Any examples?

-Alastair


----- Original Message -----
From: "Paula Thornton" <paula.thornton@...>

>
> Heard of Plumtree, Vignette
>
(http://www.vignette.firm.ro/CDA/Site/0,2097,1-1-1329-2611-1442-2606,00.html
> ), Microstrategy, Brio, Business Objects, mySAP, PeopleSoft Enterprise
> Portals
>
(http://www.peoplesoft.com/en/us/products/applications/ebus/portal/product_c
> ontent.html)?

Alastair said: "I wasn't aware that the word portal had anything to do with
application type web usage."

Heard of Plumtree, Vignette
(http://www.vignette.firm.ro/CDA/Site/0,2097,1-1-1329-2611-1442-2606,00.html
), Microstrategy, Brio, Business Objects, mySAP, PeopleSoft Enterprise
Portals
(http://www.peoplesoft.com/en/us/products/applications/ebus/portal/product_c
ontent.html)?

You need to get out a little more often Alistar...

************************************
Paula Thornton, Interaction Design Strategist
Thus the task is not so much to see what no one yet has seen,
but to think what nobody yet has thought
about that which everybody sees ~ Schopenhauer

I wasn't aware that the word portal had anything to do with application type
web usage. Is anyone else?  The regular definition is similar to 'gateway',
which doesn't seem to fit the word so easily.  At the risk of going somewhat
off topic, where does this other meaning come from?  Also, is it specific to
intranets or does it generalise to the intranet?

-Alastair

PS. A quick search on portal definition:
http://searchebusiness.techtarget.com/sDefinition/0,,sid19_gci212810,00.html



----- Original Message -----
From: "Paula Thornton" <paula.thornton@...>

> Alastair made a reference to a term that I thought we might want to agree
to
> disagree about: portal.
>
> There are basically 2 things people accomplish online: look for things and
> do things (although you 'could' classify looking as doing). While the word
> 'portal' was aligned to concepts like information brokers (e.g.Yahoo!), it
> also applies to concepts like data brokers (e.g. analytical tools...which
> are applications) and concepts like magazine format corporate
> intranets/extranets to allow participants (clients, vendors, suppliers,
> employees), to both find and do (sometimes falling under the category of
> knowledge management).

Alastair made a reference to a term that I thought we might want to agree to
disagree about: portal.

There are basically 2 things people accomplish online: look for things and
do things (although you 'could' classify looking as doing). While the word
'portal' was aligned to concepts like information brokers (e.g.Yahoo!), it
also applies to concepts like data brokers (e.g. analytical tools...which
are applications) and concepts like magazine format corporate
intranets/extranets to allow participants (clients, vendors, suppliers,
employees), to both find and do (sometimes falling under the category of
knowledge management).

So...

If you're going to use the word portal, you might want to be more specific
about your intended use of the word for the reader.

************************************
Paula Thornton, Interaction Design Strategist
Thus the task is not so much to see what no one yet has seen,
but to think what nobody yet has thought
about that which everybody sees ~ Schopenhauer

Hi All,

I'm doing some research on intranet search installations, and would
like to hear stories, good and bad, about how search engines work in
your institutions.  If you have strong opinions, I would very much
like to interview you by phone, chat or email.

Many thanks,

Avi Rappoport
Principal Analyst
Search Tools Consulting
--
_________________________________________________
Complete Guide to Search Engines for Web Sites, Intranets,
    and Portals: <http://www.searchtools.com>

Why not give the intended users (you said there aren't very many of
them) a list of functions and let them tell you what to label them? You
may at least get an idea as to the relative brevity (or lack thereof)
that they are comfortable with or expect ...


Just a thought,

<> Ward Conant
<> Solution Design and Production
<> URS Corporation - Information Technology Practice
<> tel 865.220.8154
<> fax 865.483.9061

At 10:23 10-08-2001 +0100, Alastair Campbell wrote:
>[on the subject of descriptive links on intranet design]


I am also working in an Intranet project, but I opted for a different choice:
All my links are extra-descriptive, and straight to the point. No fancy
metaphors, no artificial shortening of links, etc.

This intranet is being designed for a set of 400 distributed users, some of
which have very, very little knowledge of computers, let alone the Web.

The purpose is to make the intranet a tool that can be used daily in supporting
user's activities, not just something that is checked out once in a while.

I have considered the rapid gaining of experience due to this daily use, but
still opted for descriptive links. Why?

- training is not feasible

- the experience factor can be eventually compensated for by progressively
shortening the link words, which is possible in the product we are using
(ex: over time, change "Electronic Mail" to "E-Mail").

On this subject, I recommend:

http://www-106.ibm.com/developerworks/usability/library/us-brevity.html



j

--
Eng. João Pedro Martins
Link Consulting, Tecnologias de Informação, SA, http://www.link.pt
Telf (+351) 213100082
Serviço Usabilidade Link:
http://www.link.pt/Canais/artigo.asp?idclass=1908&idarticle=2194
Veja também o site: http://www.usabilidade.com

Hi Jeff (& everyone),

My experience on intranets has been more on the 'internet' end of the
scale:- very large and diverse population who are unlikely to use it every
day.

However, I use my own 'portal' page (www.alastc.co.uk/bookmarks.htm) as a
homepage.  As anecdotal evidence; almost none of the links have any
description. Even though I do not use some of the links for weeks, I don't
need any explanation because they have meaning due to the groupings.

Two thoughts follow from this (fairly related) experience:
1. Is it possible that one of the group could be left in charge of editing
the page?  Since efficiency is a major factor, the page would have to
develop over time.

2. You are probably right, but the grouping/separation of types of links is
important.  I assume you've done some sort of interviewing to determine
this?  Card sorting might be overkill for one page, but I've found that I
had to move some links up to prevent me from having to scroll all the time.
You don't want to be stuck with the design that people remember but isn't
efficient!

my t'pence,

-Alastair

PS. Re:
> I'd have them tell me (without
> clicking) what each link does and see if they're right. (Or, I'd give them
> tasks and see if they select the correct link, I haven't decided yet.)

I would go for the task oriented scenario:- its more realistic to the
situation they will be in once you've left!


----- Original Message -----
From: "Jeff Lash" <jeff@...>
To: <intranet-user-experience@yahoogroups.com>
Sent: Friday, August 10, 2001 1:41 AM
Subject: [intranetUX] Welcome and first question

> I'm working on a page for a department at work. The page will be a portal
> with access to features (web apps, documentation) only used by people in a
> specific department. My feeling is that, since it is a small set of people
> using the page, and using it repeatedly, the links may not be
> super-intuitive the first time, but after the second or third time the
links
> will make sense and the learnability will be quite high.
>
> Others involved in the project think that the links need more
> description/annotation. They don't think that, on their own, they will be
> descriptive enough. My feeling is that the annotation will clutter up and
> confuse the interface, and since it's only a very small group of people
who
> will be using the page, and using it quite often, first-time visiting
> intuitiveness is not the top priority.
>
> I'd like to run an informal test to see if I'm right (I'm hoping I am,
> obviously), and I was wondering if anyone had ever done anything similar.
I
> am thinking of taking a few people from the department, showing them the
> interface (without annotation) and asking them what they think the links
do.
> Then, I'd have them try the links and see what happens, and have them
inform
> me (in their own words/description) what the link does. Then, I'd stop,
and
> take the page off the Intranet. A week or so later, I'd put the page back
up
> again and test the same exact users again. I'd have them tell me (without
> clicking) what each link does and see if they're right. (Or, I'd give them
> tasks and see if they select the correct link, I haven't decided yet.)
>
> My feeling is that this should be a good way to determine if they remember
> how the (initially non-intuitive) links function. Obviously, this could be
> tested several times over a few weeks, perhaps testing on Mondays and
> Thursdays for a week or two. By the end of the period, it should be clear
> whether they remember what links do what, or whether annotation is needed.
>
> So, has anyone done anything like this before? (Excuse my naivety if it
has,
> I just don't know about it. I can't remember hearing anything about
testing
> the same design on the same group of users at two or more different points
> in time WITHOUT making changes in between.) Does anyone have any
> data/experience/anecdotes about the learnability of an oft-used Intranet
> interface? Any suggestions on how I should go about this?
>
> Thanks and looking forward to some good discussions here...
>
> .jeff.

Hi Jeff, everyone.

Jeff, I'm SO with you on this one. It's one of my many wheelbarrows.
Intranet is different from Internet. If a site has a clear purpose of
frequent use, then it's focus should be efficiency and not first time
useability, if and when these two ends are in conflict. First time
useability should be addressed by training. Period. We have a closed
audience and a predictable end-user platform- something the Intranet bods
don't. We should exploit this unashamedly.

When you scale up inefficiencies, they cost a company of significant size
buckets of money. The approach you take to design should in all ways be
linked to the purpose of the content. And the purpose of the content, as we
all know, should be clearly and unambiguously articulated.

In your case, I'm not sure what the frequency of use is, whether it's
monthly, weekly, daily or many times a day. If it's daily or many times a
day then one thing you might like to consider is doing a speed test on the
interface, that is, giving some users a small set number of tasks to achieve
and then seeing exactly how fast they can achieve them. This may help with
positioning of the links on the page and their ability to accurately hit the
links and upload speeds. It really brings home the need for clean and
economical click throughs and small file sizes. It might also identify
non-interface related problems such as slow data delivery or tardy database
or server responses.

Your approach to testing sounds good. I would only say that the value of
performing extensive user testing in a business environment relies on us
distracting employees from their real work, which again translates to a cost
for the business. We need to be economical with the amount of time we demand
from the people, and rely on our own creativity and intelligence wherever
possible. I have been on projects where the efficiency and perfection that
was gained in interface development was far outweighed by the actual cost to
the business to develop it.

And while I'm on my soap box, I'm a strong believer that "stickiness" of an
Intranet site can sometimes be a bad bad thing.

Thanks for setting up the list Jeff. I've sometimes felt I was on a
different planet to our external facing brothers and sisters.

thanks,

Annie
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Annie South
Information Architect

Intranet Management Project
Telstra | Finance and Administration | eProcesses
Level 18, 242 Exhibition St, Melbourne  3000
(03) 9634 4996  :  Tel
(03) 9634 5151  :  Fax
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



> I'm working on a page for a department at work. The page will be a portal
> with access to features (web apps, documentation) only used by people in a
> specific department. My feeling is that, since it is a small set of people
> using the page, and using it repeatedly, the links may not be
> super-intuitive the first time, but after the second or third time the
> links
> will make sense and the learnability will be quite high.
>
> Others involved in the project think that the links need more
> description/annotation. They don't think that, on their own, they will be
> descriptive enough. My feeling is that the annotation will clutter up and
> confuse the interface, and since it's only a very small group of people
> who
> will be using the page, and using it quite often, first-time visiting
> intuitiveness is not the top priority.
>
> I'd like to run an informal test to see if I'm right (I'm hoping I am,
> obviously), and I was wondering if anyone had ever done anything similar.
> I
> am thinking of taking a few people from the department, showing them the
> interface (without annotation) and asking them what they think the links
> do.
> Then, I'd have them try the links and see what happens, and have them
> inform
> me (in their own words/description) what the link does. Then, I'd stop,
> and
> take the page off the Intranet. A week or so later, I'd put the page back
> up
> again and test the same exact users again. I'd have them tell me (without
> clicking) what each link does and see if they're right. (Or, I'd give them
> tasks and see if they select the correct link, I haven't decided yet.)
>
> My feeling is that this should be a good way to determine if they remember
> how the (initially non-intuitive) links function. Obviously, this could be
> tested several times over a few weeks, perhaps testing on Mondays and
> Thursdays for a week or two. By the end of the period, it should be clear
> whether they remember what links do what, or whether annotation is needed.
>
> So, has anyone done anything like this before? (Excuse my naivety if it
> has,
> I just don't know about it. I can't remember hearing anything about
> testing
> the same design on the same group of users at two or more different points
> in time WITHOUT making changes in between.) Does anyone have any
> data/experience/anecdotes about the learnability of an oft-used Intranet
> interface? Any suggestions on how I should go about this?
>
> Thanks and looking forward to some good discussions here...
>
> .jeff.
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> intranet-user-experience-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

Hi. Welcome to the list. I'm Jeff.

I'm a bit surprised at how many people have joined already (over 100 in only
a few days). Hopefully this will be a good forum for discussing and sharing
information and anecdotes on user experience as it relates to intranets.

Just a few notes before I jump right in to it:

1) While I'm technically the moderator, I don't plan on doing much
moderating. If people start spamming or things get out of hand, I'll step
in, but otherwise I'll just let things run themselves.

2) No attachments will be distributed to the list (for bandwidth and virus
reasons). If you want to share a file, please do so; just upload it to the
files area (http://groups.yahoo.com/group/intranet-user-experience/files/).
Similarly, for those of us who prefer plain-text, if you could turn off
HTML/RichText, that would be great.

3) There are lots of neat features on the group site (database, bookmarks,
polls, etc.), and, hey, they're included and free, so you might as well use
'em.

Okay, enough administrativia. I'll kick of the discussion...

I'm working on a page for a department at work. The page will be a portal
with access to features (web apps, documentation) only used by people in a
specific department. My feeling is that, since it is a small set of people
using the page, and using it repeatedly, the links may not be
super-intuitive the first time, but after the second or third time the links
will make sense and the learnability will be quite high.

Others involved in the project think that the links need more
description/annotation. They don't think that, on their own, they will be
descriptive enough. My feeling is that the annotation will clutter up and
confuse the interface, and since it's only a very small group of people who
will be using the page, and using it quite often, first-time visiting
intuitiveness is not the top priority.

I'd like to run an informal test to see if I'm right (I'm hoping I am,
obviously), and I was wondering if anyone had ever done anything similar. I
am thinking of taking a few people from the department, showing them the
interface (without annotation) and asking them what they think the links do.
Then, I'd have them try the links and see what happens, and have them inform
me (in their own words/description) what the link does. Then, I'd stop, and
take the page off the Intranet. A week or so later, I'd put the page back up
again and test the same exact users again. I'd have them tell me (without
clicking) what each link does and see if they're right. (Or, I'd give them
tasks and see if they select the correct link, I haven't decided yet.)

My feeling is that this should be a good way to determine if they remember
how the (initially non-intuitive) links function. Obviously, this could be
tested several times over a few weeks, perhaps testing on Mondays and
Thursdays for a week or two. By the end of the period, it should be clear
whether they remember what links do what, or whether annotation is needed.

So, has anyone done anything like this before? (Excuse my naivety if it has,
I just don't know about it. I can't remember hearing anything about testing
the same design on the same group of users at two or more different points
in time WITHOUT making changes in between.) Does anyone have any
data/experience/anecdotes about the learnability of an oft-used Intranet
interface? Any suggestions on how I should go about this?

Thanks and looking forward to some good discussions here...

.jeff.