On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol <[email protected]> wrote:
> > > On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica) <[email protected]> > wrote: > > > > On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <[email protected]> > wrote: > > > >> Hi devs, > >> > >> With the recent introduction of the Applications Index (see > >> http://extensions.xwiki.org/xwiki/bin/view/Extension/ > >> Application+Index+Application/) we need to agree on a few things. > >> > >> In the past we had: > >> * We wanted all new app that you installed to automatically be visible > in > >> the Applications Panel > >> * This is why the Applications Panel config had a blacklist (and not a > >> white list) > >> > > > > There are some nice side effects of the current behavior that I would not > > want to lose: > > A. after you install an app with the EM, it immediately appears (if it > has > > the UIX defined) in the AppBar and is ready for usage. The admin does not > > need to do the second step manually. We save him a click (in practice is > > more than a click). > > B. after you create a new app with AWM, you automatically have it in the > > AppBar. In theory that app should be useful for the user, since he > manually > > create it to his own liking. We are saving him a click+. > > However following this strategy you shouldn’t be allowed to blacklist the > apps that you blacklisted since they fail point A now (and you should > consider them as extensions - we bundle them but they could be not bundled, > and the same problem will appear with contrib extensions. > > What I’m questioning is considering that Invitation, Panels, Scheduler, > User Directory and Tour are special applications and that we only want to > hide those and all others should be listed by default. > So as I said, I don't consider the mentioned apps as user-centered apps (Invitation and Panels are for Admins, User Directory was already in the Drawer, Tour and Scheduler are technical). They should have the UIX to be promoted in the AppBar, but sure we should find a way to say they are apps. > > > The only problem is when the wiki is getting out of control, too many > apps, > > no favorite order, just alphabetical. For this there is this issue > > http://jira.xwiki.org/browse/XWIKI-13075 > > > > > >> What we’ve done: > >> * We add the Applications Index > >> > > * We removed some apps from the Applications Panel. Namely: Invitation, > >> Panels, Scheduler, User Directory and Tour applications. this was done > >> using hardcoded blacklist xobjects in PanelsCode. > >> ApplicationsPanelConfiguration. > >> > >> The need: > >> * We need to remove this hack. It’s not normal for the Panels module to > >> know all the apps that shouldn’t be listed in it! > >> > > > > So the main problem is that currently the AppBar is defined in Panels > > module, instead of the Application module. This is known and we also have > > an issue for the move, see http://jira.xwiki.org/browse/XWIKI-13502 , we > > just didn't had the time to do it. > > It would be exactly the same problem. There’s no reason for the > Application module to depend on all those apps and that’s not a good > practice IMO. > > Let me ask differently: why did you moved out those apps? Just because or > are there some rules that you applied? In that case shouldn’t those rules > also be applied to any other app that’s installed? > The apps were not something an user would benefit from every day. And yes this rule should apply to any other apps that wants to get inserted in the AppBar, which is a QuickLinks for apps. > > > > >> Proposal: > >> * Replace the blacklist configuration of the Applications Panel by a > >> whitelist one > >> * When a new app is installed, list it in the Applications Index but > don’t > >> add it to the Applications Panel > >> * If an admin wants to add this new for his users, he’ll need to add it > in > >> the Admin UI for the Applications Panel. > >> > >> WDYT? > >> > > > > I'm not sure I like this very much :) > > > > IMO the main problem is that we are using the "Add Application" UIX > > http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/ > AddApplicationUIX > > to define applications. > > For me, ideally, we would have a separate mechanism to define an app (not > > this UIX). Application Index would display all the XARs that contain an > app > > descritor, while the AppBar would list the apps that have the UIX. > > I’ve been thinking about this and I have a different opinion. IMO we can > continue to have the same UIXP for the App Index and the App Panel. > > It seems logical to me that: > * The Application Index is the place where an app that you install is added > * Now that we have an App index, the App Panel should be a Favorite, i.e. > listing favorite apps decided by the Admin of the wiki (and in the future > users may be able to override with their own favorites if the admin allows > it) > > > The problem with the AppBar and the blacklisting appeared when we added > the > > UIX to applications that were not "user-oriented", not useful in the > daily > > flow, not needed for fast navigation prioritization, but that contained > the > > UIX since we added this step to our recommended development app > practices. > > Ideally the UIX should be added to applications intended for normal users > > that need a fast access point in the AppBar. > > This was catered for already. If you were not an admin the App Panel was > only listing user-oriented apps (there was a check for admins in apps). > Personally I don’t agree with the rationale that Admins are lesser users of > the wiki and that they shouldn’t have fast access to admin apps. > > If an Admin installs a new admin app (for ex), that app will be displayed > in the App Panel and we certainly don’t want to add yet another blacklist > xobject in the App Panel. > > > Having it as a white list, will reduce the user-centered applications > > discoverability and rapid access. > > That’s the role of the App Index IMO. Maybe we need to make it more > visible or maybe it’s just because we’re not used to it yet. > > So my understanding is that the behavior you’d like like is: > * Keep a blacklist of app for the XE flavor (KB flavor soon). So this > means the config should be moved to the flavor. > So depends how we create the definition of the Flavor, if it's from the scratch (as list of module) or from XE. If it's from XE, than yes, the flavor could overwrite or provide the list of default bundled blacklisted apps that it does not want to promote. Each flavor could optimize the AppBar according to its needs. If the flavor is from scratch and it selects from the start the needed apps, the initial blacklist could be empty. > * All further apps installed by an admin will appear in the App Panel, > even if they’re for admins only. It’s up to the admin to decide to remove > them or not and decide if he wants to show the one we blacklisted in the > flavor by default. > > Sounds globally ok to me. > > I guess the only point where I’m not 100% in agreement is the removal of > quick access to admin apps for admins but I’m not going to fight this since > it’s not that important that admin users have to do 2 extra clicks to > access them, and if we consider the App Panel as a favorite it’s acceptable. > Regarding admins, some apps have some UIX code that mentions that the app should be listed only for Admins, but that's another story. If we were to create personalized favorites lists http://jira.xwiki.org/browse/XWIKI-13770 than we will have a recommended initial list that every user (including Admin) could customize (but this is already an advanced / extended use case). User might not even know that they can customize the AppBar (because we don't have an Edit/Customize button for that panel and also the Application Panel section is inside the Applications area, instead of being near the Look&Feel and Panel Wizard) [but that's another story]. Thanks, Caty > > Thanks > -Vincent > > > WDYT? > > > > Thanks, > > Caty > > > > > >> > >> Thanks > >> -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
