Hi Nino, Clayton, all RE: separating users and developers on the wiki OOo is hardly the only project that is facing this challenge. What do you think about MediaWiki's approach [1]? The Main Page has sections clearly labeled for Users, System Administrators and Developers with a few quick links for very broad or common pages, and a 'More' link to cater for more specific tasks/pages/sections, etc.
[1] http://www.mediawiki.org/wiki/MediaWiki RE: searching: There is no reason why projects can't add custom Google search boxes to their templates - users don't have to know about Google's site: function, but they get its benefits. However, since not all projects are self-contained, this wouldn't suit all projects. For example, there are some pages that are categorized as belonging to two different projects. However, only one page exists in one of these projects' structures. That means that a custom Google search will show the 'shared' page for only one of those projects, which is problematic if a project has many of these kinds of 'shared' pages. Regards, Ivan. On Fri, Jan 16, 2009 at 1:09 PM, Nino Novak <[email protected]> wrote: > Skipping many minor points trying to come back to the essentials... > > On Wednesday 14 January 2009 17:34, Clayton 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? I just > can't imagine it. 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). > > >> If we split into a developer and a user Namespace, >> there there are two unique place that people will need to search for >> info (was a reason Namespaces was not implemented in the first >> place). I think that we should be able to set up redirects across >> Namespaces so old page names lead people to the new location, but I'd >> have to research that (unless someone here knows more about this). >> >> As we have both said.. the solution to the problem is not clear. I >> hope others here can chip in with their thoughts and ideas. > > 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. > > Regards, > Nino > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
