Hi Caty, here's my feedback regarding this.
On Fri, Jun 15, 2012 at 3:53 PM, Ecaterina Moraru (Valica) < [email protected]> 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 > 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 > Sounds good, that would definitely be useful. 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; > I'd say color themes should be an admin-only feature. Organizations usually want to enforce a consistent look & feel for internal and external tools. Color Themes are a great way to let them achieve this. > - makes sense that maybe a normal user could create a 'Panel' but right now > this is not possible from Panels.WebHome; > For the same reason as above, I don't think this action should be available to users that are not administrators (or developers). > - 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; > Yes, the invitation application should be more discoverable. The way it's made visible in XWiki Cloud could be a good source of inspiration. > - Stats again could be used by both. > I don't really agree, see below. > 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. ). > I strongly agree with this. 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). > Your proposal of an "app bar" on the left of all pages was a nice solution to this issue. 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? > >From the use cases I see within organizations, I'd say only admins should be able to access Statistics. Stats are sensitive information that admins use to monitor activity on the wiki and take action. For instance, you don't necessarily want all your users to know that the "important procedures" space is never looked at by anyone. > 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. > OTOH functional admins without technical knowledge are often surprised to see "technical" spaces and pages on the homepage of the wiki. 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. > +1, but only provided there's an user-friendly interface for those apps. > 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 > Applications descriptors are more and more needed, especially with the arrival of a fully functional extension manager in the coming releases. 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). > I agree that the user / admin / dev separation would be better than the simple user / advanced user separation that we currently have. Guillaume Thanks, > Caty > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
