MUSEUM-L Archives

Museum discussion list

MUSEUM-L@HOME.EASE.LSOFT.COM

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Museum discussion list <[log in to unmask]>
Subject:
From:
Peter Wehr <[log in to unmask]>
Date:
Tue, 8 Aug 1995 16:45:40 -0500
Reply-To:
Museum discussion list <[log in to unmask]>
Parts/Attachments:
text/plain (109 lines)
>The Museum that I work for is considering putting up some WWW pages,
>but wants some information in the field of cost-benefits before it
>does so.  If any one could help me on the following points, either
>through their own experiences, or by directing me to published
>material, I would be very grateful.
>
>1.  What is the cost overhead in staff time of maintaining web
>pages?  I know this depends a lot on the size, but a rough rule of
>thumb, hours per megabyte per month would be useful (if anyone has
>done this kind of audit!).
>
>2.  Do web pages actually generate an appreciable increase in
>visitors, or do most museums with web pages view it as widening
>their public access, rather than income generation?  How many people
>each month access your web pages on average?
>
>3.  What is the success of museum shops on the web, and what form
>has proved the most profitable?
>
>Thanking you all in advance.
>
>Alan E West
>[log in to unmask]


I am not sure how useful this will be, but I will try to take a stab at it
-- but first a disclaimer.  I am not sure that there is a enough of a
sample to determine what a typical site is.  They vary incredibly in nature
and complexity.  Even within a site different sections dramatically
different development time. For example maintaining a searchable database
of type specimens is much more difficult to build and support than a
presenting the museum's mission statement.

A large factor is who is doing the actual HTML development and designing
the look and structure of the site.  If a non-museum person is brought in
as a developer a certain amount of time is needed to translate the material
into a state that the developer can use.  If a staff member needs to learn
HTML and how to maintain a server the learning time needs to be taken into
consideration.  If an outside multimedia developer with a museum background
is brought in it will remove staff pressure, but specialized consultants
can be expensive.

My experience has led me to believe that unless you get very lucky with
bringing in a generic or student HTML developer you will find yourself
spending a lot of one on one time with the developer.  Back when I was
doing multimedia at a university museum I had better luck with teaching
museum students multimedia than teaching multimedia students what is
important to a museum.  This does not mean you will not get a good result.
Some of the best sites out there use this method, but it tends to take more
staff time in the liaison role.

HTML is a relatively simple environment, but there are associated skills in
designing structure and presenting information that come with training
and/or experience.  Just because someone knows HTML does not mean that they
will be a successful web developer any more than knowing a page layout
program will make you a successful print designer.  The time it takes to
build the experience to be a successful developer is extremely hard to
predict and depends a lot on the training and past experiences of the would
be developer.

Outside consultants with museum experience are probably the most efficient
as they have the necessary experience base and should have tools and
templates that they have developed on previous projects.  However, this
experience has a dollar value attached to it.

With this said, I tell my clients to think of the staff time in terms of
developing a conventional publication of comparable complexity to the point
were it is ready to go to the printers.  Extending the metaphor, think of
the developer(s) and that interaction as being similar to working with a
graphic designer and the editor. Like most design problems, creating a
work-flow structure that is efficient is half the battle.

On to the other questions:

I have been trying to find tangible data from webmasters as to the
visitation question, with mixed results.  It is very hard to prove any of
this, but several webmasters have told me that using the Web to promote
changing exhibits does seem to give an attendance boost near the time of
the opening.  In terms of general attendance there are so many variables it
is hard to get any clear idea on what effect a web site has.  Since K-12 is
generally cutting down on school trips an increase in Web generated
visitors may not show up in the stats.  I know of no instances of the web
site being blamed for a visitation decrease.

The museum shop issue is also unclear.  Again, informal poling suggests
that the success of online museum shops depends greatly on both the sites
overall popularity, the nature of the merchandise and how unique it is.  I
have heard some webmasters claim the increase in store sales pays for the
development costs of the site.  Besides merchandise there are other revenue
generators such as travel tours, publications, traveling exhibits and
membership sales which are common web site components.  These areas require
very little development time so even if they don't generate a lot of
revenue it is probably worth the effort.

I hope this helps, but there really is no formula or rule of thumb for this
type of thing and making one up would be counter productive.  I truly wish
there was because it would make bid building much easier.


Peter Wehr

***********************************************************
Project Director
Museum Online Resource Review http://www.okc.com/morr
Overall Knowledge Company, Inc.        tel:(212) 346-7776
30 West Broadway, 9th Floor            fax:(212) 346-2287
New York, NY 10007                     http://www.okc.com
***********************************************************

ATOM RSS1 RSS2