Hi Guillaume,

On 23 Nov 2015 at 17:00:47, Guillaume Lerouge 
([email protected](mailto:[email protected])) wrote:

> Hi Vincent,
>  
> thanks for your feedback. Please see my answers below.
>  
> On Mon, Nov 23, 2015 at 4:43 PM, [email protected]  
> wrote:
>  
> > Hi Guillaume,
> >
> > See below.
> >
> > On 23 Nov 2015 at 15:30:09, Guillaume Lerouge ([email protected](mailto:
> > [email protected])) wrote:
> >
> > > Hi Devs,
> > >
> > > first of all I'd like to congratulate everyone who worked on the latest
> > 7.x
> > > releases. I tried a 7.4 snapshot locally and it's looking great! The
> > > interface feels much simpler and fresher overall, well done!
> >
> > Thanks, glad you like it.
> >
> > > Nested spaces bring about a significant change in the way information is
> > > stored and organized in XWiki. They make it less necessary to create
> > > sub-wikis to compartmentalise information.
> > >
> > > Besides, at the moment a sub-wiki is almost exactly the same as the main
> > > wiki upon creation. I've been doing plenty of demos of XWiki 7.4 at a
> > > conference last week and it was difficult to explain the difference
> > between
> > > the main wiki and a sub-wiki.
> > >
> > > Therefore, I would like to suggest the following changes:
> > >
> > > 1. *View the main wiki as a collaborative content repository* (what a
> > > wiki is most often associated with). Therefore the main wiki would have
> > the
> > > most wiki-like features (treeview and tagcloud in a pane on the left) and
> > > global activity stream on the home page. Users looking for a "simple"
> > wiki
> > > wouldn't even need to create sub-wikis.
> > >
> > > 2. *View subwikis as collaborative workspaces* (created for a project or
> > > another type of shorter-lived initiative). A subwiki would retain the
> > > appbar on the left, as well as panels on the right that are specific to
> > > each app (ex: forum app, blog app...). The homepage would be made of
> > > widgets surfacing information from the various apps installed. Additional
> > > subwiki templates could be added later on, once flavors are built into
> > the
> > > product.
> > >
> > > 3. *Add the horizontal menu to the standard install.* In addition to
> > > this, an entry should be added to the menu to automatically list existing
> > > sub-wikis the user has access to. This would make navigation between
> > wikis
> > > more discoverable and easier to use.
> >
> > Related to this, we’re already planning this:
> > http://jira.xwiki.org/browse/XWIKI-12538
> >
>  
> Indeed, is would answer the use case quite nicely.
>  
> > My feeling is that these changes would make the distinction between nested
> > > spaces and sub-wikis much easier to explain and understand for users:
> > >
> > > - *Want to share generic information? Put it in the right location in
> > > the main wiki.*
> > > - *Want to work with others on a restricted project? Create a sub-wiki
> > > for this purpose.*
> > >
> > > With the addition of the horizontal menu, the main wiki would act as
> > both a
> > > portal to information and a knowledge repository.
> > >
> > > Looking forward to your feedback,
> >
> > I think you’re entering into flavors here. There are plenty of various
> > needs and you’re listing one. There are others, such as using XWiki for a
> > farm (just to list one).
> >
> > That’s exactly why we’ve started developing the notion of flavors btw.
> >
> > So far, what we’ve agreed not long ago was to say that the XWiki project
> > should focus on offering a generic platform with a generic default flavor.
> > And to leave it to the community to offer flavors on extensions.xwiki.org 
> > and
> > those flavors would appear then first time you install XWiki or create a
> > subwiki.
> >
>  
> This does not change the fact that the generic platform should be a
> sensible "default" state. While I agree that item 2 would be fixed by
> flavors and item 3 isn't needed with the drawer solution described above,
> it does not change my feedback about item 1 (though I'm not sure what you
> mean by "generic" nor how you define it).
>  
> In any case, at the moment I don't see how the current main wiki is more
> "generic" than the solution I'm proposing. Actually, I think it's actually
> less "generic" since it's further away from what people expect of a "wiki"
> than my proposal, since most wikis don't have an app bar but a navigation
> tree :-)
>  
> In conclusion I don’t see how points 1, 2 or 3 could be integrated in a
> > default platform flavor because they really look specific. I personally
> > wouldn't 3 by default since our goal was to unclutter XWiki and the menu
> > would add back clutter and I don’t think that all flavors require such an
> > horizontal menu.
> >
> > Regarding the differences between spaces and wikis, we have this thread
> > listing the differences:
> > http://markmail.org/message/qcjnev4qkhvjivj2
> >
> > This led to
> > http://design.xwiki.org/xwiki/bin/view/Proposal/WikivsNestedSpaces which
> > we should move to the doc proper. I’ll try to do this in the coming days.
> >
>  
> I happen to be well aware of that page since I was part of the discussion
> thread that led to its creation :-) Unfortunately, it's a poor solution to
> the issue at hand. You can't expect a brand new user to go through that
> page and understand all the implications when pondering whether to create a
> nested page or a sub-wiki.
>  
> IIRC, you've quoted the KISS principle at us a number of times in the past.
> I'm sure you'll agree that this page is anything but Simple ;-) Having a
> simple heuristic for users asking the question would be much better IMHO.

I’ve now updated the page at 
http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization

Let me know if you like it and if you have ideas to improve it further.

Note: The page had lots of tech details indeed but you forgot to check the 
section called Summary…

Thanks
-Vincent

> Thanks,
>  
> Guillaume
>  
> Thanks
> > -Vincent
> >
> > > Guillaume

_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to