Hi,
On 12 May 2011 15:30, Tim Donohue <tdono...@duraspace.org> wrote:
>
> IMHO Documentation should likely have (at least) two audiences:
> * Novice User (never tried DSpace before, but wants to try it out and get
> it running relatively quickly)
> * Advanced User or System Admin (describes/explains all available options
> in great detail)
>
> Currently, it seems like our docs are a bit more "Advanced User" oriented
> (just my opinion), or a conglomeration of both Novice and Sys Admin with no
> real rhyme or reason. Don't get me wrong, it's gotten much better over
> time, but we can probably do more to try and cater a bit better to both
> audiences.
>
There definitely is at least two audiences - the technical level of managing
the installation files, and the user level setting up content, policies,
etc. in the UI.
We probably don't have a clear [enough] demarcation between these roles in
the documentation - if you look at other software, these are often split
into separate documents. And I guess we have a grey area over 'slightly'
technical modifications, such as setting values in dspace.cfg, or changing
the logo / css in the UI.
You are right that the demo.dspace.org site can be used for Demos. But, if
> people *truly* want to try out DSpace completely (including doing their own
> configurations, and starting to learn more about all the options, etc), then
> they still have to install it locally. Demo.dspace.org just provides a
> place to "play" with the default interface & a few enabled settings. But, it
> still won't give you a sense of how you may want to truly use DSpace in your
> own local environment. To do that, you need to install it locally and play
> with its configurations/settings a bit.
Exactly. So now they've installed it locally, what do we tell them to do to
configure it? Our existing documentation centers around the Maven overlays
as a best practice for separating and managing your changes. Are we happy to
tell them to just alter files directly in their installation directory? Mess
around with the images / css / jsp / xsl inside the web applications? What
happens when they want to enable another addon?
Whilst the current installation steps are not easy, following them at least
gives someone a reasonably solid footing for anything they want to do after
that. If we make it easy to install in a completely different way, not only
may we (they) be back to square one fairly quickly, we could be creating a
bigger problem later on (customizations in the installation directory, but
now they need to switch to using the Maven process).
I honestly still feel strongly that there is a need for an easier way to
> install DSpace. If others disagree, then so be it (we can always start this
> conversation with some of our users at OR11 to see what they think).
>
I'm certainly not disagreeing - but simply making it easier without thinking
about what they may want to do after they have it installed may not be
beneficial, and possibly even counter productive.
I just lean towards having an easier way of working with the 'proper'
assembly project over doing something entirely different. With a wrapped
Maven / Ant process, we have the ability to include dealing with addons, and
possibly even being able to upgrade versions of Dspace relatively simply
(providing your changes don't conflict). I think the benefits gained from
that outweigh the implications of network connectivity and execution time.
And I'm not saying that should be the one-right-way either, but I would
encourage people to step back from thinking about what can be offered as an
easy installation, and think about the context of why someone is installing
it in the first place.
G
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
