Hello,
I have a few remarks of my own. Please see below:
On Fri, Jun 15, 2012 at 4:53 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
Hi,
XWIKI-7568 <http://jira.xwiki.org/browse/XWIKI-7568> - Implement mechanism
to hide technical content
added some big changes for me in the way we organize things inside XWiki,
what we consider to be hidden or not and how we reach hidden applications.
As a first visible change, now the Spaces gadget found on Main.WebHome
doesn't display anymore spaces like 'AnnotationCode', 'ColorThemes',
'Invitation', 'Panels', 'Scheduler', 'Stats'.
My main concern is that if something is not visible and accessible it will
never be used and thus it doesn't exists.
+1, I agree
That's why I've created:
XWIKI-7916 <http://jira.xwiki.org/browse/XWIKI-7916> - Integrate
ColorThemes functionality inside Administration
XWIKI-7920 <http://jira.xwiki.org/browse/XWIKI-7920> - Integrate Scheduler
functionality inside Administration
XWIKI-7919 <http://jira.xwiki.org/browse/XWIKI-7919> - Create an entry
point for Stats inside Administration
XWIKI-7918 <http://jira.xwiki.org/browse/XWIKI-7918> - Have an entry point
for the Invitation application
While some functionality may seem normal to be Admin only (also because
some of the hidden spaces were about configuration), some is arguable:
- 'ColorThemes' initially were supposed to be used also by normal users in
their profile but this didn't made it in final implementation;
- makes sense that maybe a normal user could create a 'Panel' but right now
this is not possible from Panels.WebHome;
- Invitation should be able to be used by both types of users, but without
the setting of the server mail, the users will always receive an error;
- Stats again could be used by both.
What I would like is that things that are about configuration should always
be integrated in the Administration. I am referring to the Scheduler
configuration, Stats configuration, Search Suggest configuration, etc. The
logic behind is that the Administration acts like an entry point for any
configuration related actions. As Admin I shouldn't go outside
Administration in order to achieve my configuration task (ex.
XWIKI-7917<http://jira.xwiki.org/browse/XWIKI-7917>
XWIKI-7921 <http://jira.xwiki.org/browse/XWIKI-7921> etc. ).
Now adding configuration inside Administration still doesn't solve the
problem on the entry point. As an administrator, after I've completed the
configuration step, where do I find the application? As a normal user is
the same question + how do I even know that applications exists?
For this issue I've created
XWIKI-7927 <http://jira.xwiki.org/browse/XWIKI-7927> - Create an entry
point for all available applications inside the wiki
This can be implemented as a gadget, as a panel or even as an Application
Index (as a livetable or as a grid).
+1 we should have something custom for our applications, so users can
easily see them. Having a space listed there doesn't mean necessarily
it contains an application.
Now another problem remaining is that of specifying if an application is
intended for Advanced, Simple users or both. Who should see Stats app? All
the users? Just advanced users?
As a first step, the hidden feature works because 'advanced' applications
will be considered 'hidden' for users. The problem is what we consider
'advanced' to mean. Is ColorThemes or Stats an advanced application? And is
especially problematic since by default the Administrator has an 'advanced'
+ 'hidden' configuration, meaning that he will not be able to see by
default ColorThemes or other configuration (but currently hidden)
application that might be useful for him (he needs to know that the
functionality exists somewhere). So he is an 'advanced' user that doesn't
have visibility to 'advanced' applications.
For this, I reported
http://jira.xwiki.org/browse/XWIKI-7935 because
for the moment, you can't do much about this (seeing hidden pages,
only if you know their name) if you are a simple user.
So IMO the hidden mechanism is great for hiding technical pages (pages like
*Sheet, *Template, Macros, internal pages, etc.) from users. It doesn't
matter if those pages exist (from an user's point of view) as long as there
is an UI that integrates them.
The bad part of the current status of the 4.1RC1 is that IMO we should not
consider entire applications to be hidden. Internal pages of the
'Invitation' app should be hidden, but the WebHome (that contains the
functionality and the UI) should be available/discoverable somewhere.
Another important thing I would like to point out is that when doing a
migration from an older version, some pages: BlueSky, Bordo,
InnerDark, Natural, Nightfall, Peach for the ColorThemes Space and
ClassEditorWelcome, GlobalRightsEditorWelcome, Tags, WebPreferences
for Panels space (there might be others too) will not be deleted and
they won't be marked as hidden. So these leftover pages from previous
versions will unhide a space and make it visible in the Spaces macro,
because they contain unhidden documents.
IMO this is an important aspect, if we want to have a clean and
consistent behavior after the migration.
In order for 'advanced' applications to not be displayed for normal users
we should have another field that describes the application and this can be
'simple' or 'advanced' (and not rely just on the 'hidden').
XWIKI-7925 <http://jira.xwiki.org/browse/XWIKI-7925> - Have application
descriptors for Application spaces
So the only problem remaining (besides the actual implementation :) ) would
be to discuss what applications are advanced (or even admin only) and what
are not (thus available to the general population). Keep in mind that the
current separation is now simple/advanced but we might need a
user/developer/admin separation in order to better separate the task
functionality of our current applications scopes (ex. since we might want
to have admins only applications that should not be available to
developers, both being advanced users).
+1 here, we should decide. Guillaume was stating that mostly
enterprises are forcing the same look and feel over their whole wiki.
But don't forget that an XWiki instance has several mods, it can be an
open wiki, etc. In these cases we might want to allow these kind of
customizations at a user level. A hardcore approach would be to have
rights for applications too, but I guess this is not feasible.
Regards,
Sorin B.
Thanks,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs