5 Oct
2016
5 Oct
'16
4:49 p.m.
On Wed, Oct 5, 2016 at 5:47 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com
have
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.
pplicationUIX
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.
wrote:
>
>
> On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol <vincent(a)massol.net wrote:
>
>>
>> > On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica)
<valicac(a)gmail.com>
> wrote:
>> >
>> > On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <vincent(a)massol.net>
> 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.
>
* shouldn't
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 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?
> 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/AddA 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.
* 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs