On Friday 16 January 2009 09:55, ccornell - OpenOffice.org wrote:
> >> If we need to break things out into different namespaces (one Wiki
> >> engine, but a clear split between developer and user info) that
> >> can be looked at.
> >
> > Can you show me a working implementation of such a clear split?
>
> The most immediate thing I can think of is Wikipedia. They are using
> language namespaces to provide a clear split between information that
> is available in different languages. This uses a common database,
> and a common Wiki engine (so one set of tools to maintain) yet keeps
> the information in each namespace unique and separate.
Ok, than I see what our problem might be: For me, wikipedia's different
languages appear to be different wikis. I do not look at the underlying
technical infrastructure, I'm looking at it from the user's view. So
maybe we were talking about the same thing (total content separation)
but did not call it the same name ("different wikis" vw. "different
namespaces").
For me as ooo end user the usability requirement to have one consistent
documentation user space is a must. No matter how it is technically
realized. Again, I was thinking of the problem, not of the solution.
> It should be
> noted though that splitting any set of Wiki pages like this really
> does split it... a search in one namespace will not (to the best of
> my knowledge) return results from any other namespace. This was the
> reason (or so I understand) that the original Wiki was set up without
> namespaces.
(what from the project's view is ok but for the end user is a nightmare)
> > Instead, I believe that putting all project things in
> > one wiki and all end user help/documentation to a different place
> > (wiki or not) would make live much easier. As long as one wiki is
> > forced to serve both groups, one of the groups (the end user) will
> > be irritated (unless you separate the two content spaces completely
> > as if they were two completely different wikis - but you will need
> > make big efforts to get it working).
>
> You are right, it will take a lot of effort no matter which direction
> we go. The important thing is to try and spend that effort in the
> right direction. :-)
>
> One of the biggest issues is making sure that with whatever change is
> considered that people who know the current locations of things are
> able to still find things.
If the new location is "really better" (more consistent, faster
performance, ...) people might accept it quickly
> In the current structure, any shuffling
> we do is taken care of by the Wiki itself with the redirect pages.
(for me this is a minor issue)
> > But looking at the requirements level, it seems rather clear to me:
> > the end user needs a valuable and efficient (online) information
> > resource (ranging from help to extended documentation, tutorials
> > and solution examples contributed by users), which ideally should
> > be taylored to her/his os/platform. The possibility to leave
> > comments or to edit the document is desirable but not essential to
> > the user. So in my eyes we should at first agree what the
> > respective target groups' requirements are - and only then look at
> > their best implementation.
>
> This is something that has been discussed a couple of times. Some
> people champion Plone or Drupal, others say leave things as they are,
> others want a whole new Wiki rolled out.
The critical point will be: which solution does really better meet the
users' needs? (Therefore: what exactly are the users' needs?)
> There has already been some information and work done on this and
> collected here:
>
http://wiki.services.openoffice.org/wiki/Documentation/Dashboard/CMS_Evaluation
ok I see - even have contributed some minor issues there...
> but no action has yet been taken on it, and it has received
> very little attention from the community in general (it also has not
> yet been well broadcast to everyone).
Which should IMHO be made up soon - as anybody who works on
documentation should be invited to add his/her needs/points of view
before a decision is made.
Nino
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
