5 Oct
2016
5 Oct
'16
5:55 p.m.
Hi,
The only thing I could say about this is that I would also prefer to have
the App Panel be configured by an admin exclusively manually (i.e. not
having apps added by default, when they are installed). All the installed
apps should be listed in the App Panel administration section, and the
admin should be able to pick from them and specify the order.
Additionally, I would like the same behavior to be available for any use,
thus being able to customize his App Panel (plus the option to reset to the
default apps, configured by the admin).
The analogy here is obviously the User Directory columns customization
which works exactly in the above described way: admin sets defaults, use
can customize his own view.
Bonus/Nice to have: When visiting an application`s homepage, a user should
be able to see under "More Actions" (or somewhere) an option to "Add to
App
Panel" :)
Bonus2/Derailing: Just thinking about the nice to have feature above, it
would also be awesome to have some "Shortcuts" panel that would allow you
to add any page to it, for quick reference. Each user would have his own
"shortcuts". Something a bit similar to the Desktop in an Operating System.
Thanks,
Eduard
On Wed, Oct 5, 2016 at 5:49 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com
wrote:
> On Wed, Oct 5, 2016 at 5:47 PM, Ecaterina Moraru (Valica) <
> valicac(a)gmail.com
> 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
> >> 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/AddA
> >> pplicationUIX
> >> > 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
> >> devs(a)xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>