[xwiki-devs] Follow-up brainstorming about adding apps in administration (menu, scheduler)
5 Sep
2018
5 Sep
'18
2:57 p.m.
Hello everyone,
I'm writing this email as a follow-up after (yet another) brainstorming
with Vincent about how adding the app Menu in the administration
(https://jira.xwiki.org/browse/XWIKI-15483).
Sorry in advance if I repeat things that have already been said.
So the general problem is that we want to be able to put apps with an
existing UI in the admin context, without loosing the ability to use the
apps outside the admin. It's already possible to include external apps
in the admin in keeping their UI, but it implies that the app can be
used without changing the page: for example, the menu app involves to go
to /edit when creating a new menu so it cannot be directly integrated as
it is now.
The best solution would be to create two UIs, one for the app to be used
externally and one for the admin, but then it would imply to maintain
twice the code.
The solution on which we agreed with Vincent on the short-term view, is
to provide in the admin the app inside an iframe: the only problem we
see would be the design adaptation, especially for the responsiveness,
but it should do the job.
Another solution discussed, to only allow using the app through the
admin (and so to keep only this UI) seems not acceptable as the app
might be used by other users in some usecases.
It's also possible to only provide in the admin a link to the app, and
then to open it using the standard path, i.e. outside the admin, but
then the user might be constantly switching context which looks bad in
the UX point of view.
Maybe to ponderate this problem of context switching, a long term view
solution would be to allow displaying the administration menu in some
apps but I really don't know if it's feasible or not.
So to conclude, first:
- do you agree with the short term solution to use an iframe for
displaying the admin app in the admin, at least as a first step for the
menu app?
Then how do you think we should do more globally for the other admin app
(menu, scheduler, stats, admintools, ...):
1. maintain two UIs
2. include the existing UI in an iframe
3. provide only a link to access the app externally
4. ... another idea?
Thanks,
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
5 Sep
5 Sep
3:20 p.m.
On Wed, Sep 5, 2018 at 3:58 PM Simon Urli <simon.urli(a)xwiki.com> wrote:
Hello everyone,
I'm writing this email as a follow-up after (yet another) brainstorming
with Vincent about how adding the app Menu in the administration
(https://jira.xwiki.org/browse/XWIKI-15483).
Sorry in advance if I repeat things that have already been said.
So the general problem is that we want to be able to put apps with an
existing UI in the admin context, without loosing the ability to use the
apps outside the admin. It's already possible to include external apps
in the admin in keeping their UI, but it implies that the app can be
used without changing the page: for example, the menu app involves to go
to /edit when creating a new menu so it cannot be directly integrated as
it is now.
The best solution would be to create two UIs, one for the app to be used
externally and one for the admin, but then it would imply to maintain
twice the code.
The solution on which we agreed with Vincent on the short-term view, is
to provide in the admin the app inside an iframe: the only problem we
see would be the design adaptation, especially for the responsiveness,
but it should do the job.
Another solution discussed, to only allow using the app through the
admin (and so to keep only this UI) seems not acceptable as the app
might be used by other users in some usecases.
The main use case of the Menu app is to allow Administrators to easily
create navigation menus using the WYSIWYG editor. These menus are usually
placed after the header.
Users creating their own menus or even having 2 instances of menus are not
the main objective of this application. These are nice functionalities, but
we should first take care of the general / important function / objective
of this application.
We should clearly define what are the "administration" applications and
integrate them correctly inside Administration. How many times did normal
users created Panels? Or created Jobs or even Tours?
Even the creation of Wikis from outside of Administration is debatable.
We rely on having and checking for rights, but having this mechanism, we
are splitting and spreading functionality all over the place, without
having a clear path for the user on how to reach those applications and
what is the connection between them.
IMO there are 2 approaches:
A. either integrate the CRUD inside the Administration, like we do for
Users, Groups, (we could do the same for Wikis), etc.
B. either have the creation/editing/deletion somewhere external, but
provide links to Manage the entities from Administration, like we do in the
case of Color Themes, Icon Themes, Skins, Panels, and in the Administration
just select the "active" entity of that particular type.
In theory, everything listed in B (Icon Themes, Panels, etc.) could be
integrated inside Administration and be restricted only to Admins. The
issue here is our Developer persona, that is not always an Administrator
(although he might be in 80% of the cases).
It's also possible to only provide in the admin a link to the app, and
then to open it using the standard path, i.e. outside the admin, but
then the user might be constantly switching context which looks bad in
the UX point of view.
Maybe to ponderate this problem of context switching, a long term view
solution would be to allow displaying the administration menu in some
apps but I really don't know if it's feasible or not.
So to conclude, first:
- do you agree with the short term solution to use an iframe for
displaying the admin app in the admin, at least as a first step for the
menu app?
-0 , iframes are the worst
Then how do you think we should do more globally for the other admin app
(menu, scheduler, stats, admintools, ...):
1. maintain two UIs
2. include the existing UI in an iframe
3. provide only a link to access the app externally
4. ... another idea?
5. integrate the functionality inside Administration and deprecate the
other/independent way (the other so called 'UI').
Thanks,
Caty
Thanks,
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
4:01 p.m.
On 9/5/18 3:20 PM, Ecaterina Moraru (Valica) wrote:
What about the remaining 20% or so of non-admin users using those apps:
do they have access to the admin for those specific apps then?
On the long term view WDYT about the possibility to display an admin
panel when accessing the admin, which would replace the current admin
menu, and would remain visible when editing a menu/panel?
Simon
On Wed, Sep 5, 2018 at 3:58 PM Simon Urli
<simon.urli(a)xwiki.com> wrote:
Agreed: actually my solution right now is to used a {{display}}. We nav
out the admin when doing action but it's consistent with the behaviour
of panels.
Hello everyone,
I'm writing this email as a follow-up after (yet another) brainstorming
with Vincent about how adding the app Menu in the administration
(https://jira.xwiki.org/browse/XWIKI-15483).
Sorry in advance if I repeat things that have already been said.
So the general problem is that we want to be able to put apps with an
existing UI in the admin context, without loosing the ability to use the
apps outside the admin. It's already possible to include external apps
in the admin in keeping their UI, but it implies that the app can be
used without changing the page: for example, the menu app involves to go
to /edit when creating a new menu so it cannot be directly integrated as
it is now.
The best solution would be to create two UIs, one for the app to be used
externally and one for the admin, but then it would imply to maintain
twice the code.
The solution on which we agreed with Vincent on the short-term view, is
to provide in the admin the app inside an iframe: the only problem we
see would be the design adaptation, especially for the responsiveness,
but it should do the job.
Another solution discussed, to only allow using the app through the
admin (and so to keep only this UI) seems not acceptable as the app
might be used by other users in some usecases.
The main use case of the Menu app is to allow Administrators to easily
create navigation menus using the WYSIWYG editor. These menus are usually
placed after the header.
Users creating their own menus or even having 2 instances of menus are not
the main objective of this application. These are nice functionalities, but
we should first take care of the general / important function / objective
of this application.
We should clearly define what are the "administration" applications and
integrate them correctly inside Administration. How many times did normal
users created Panels? Or created Jobs or even Tours?
Even the creation of Wikis from outside of Administration is debatable.
We rely on having and checking for rights, but having this mechanism, we
are splitting and spreading functionality all over the place, without
having a clear path for the user on how to reach those applications and
what is the connection between them.
IMO there are 2 approaches:
A. either integrate the CRUD inside the Administration, like we do for
Users, Groups, (we could do the same for Wikis), etc.
B. either have the creation/editing/deletion somewhere external, but
provide links to Manage the entities from Administration, like we do in the
case of Color Themes, Icon Themes, Skins, Panels, and in the Administration
just select the "active" entity of that particular type.
In theory, everything listed in B (Icon Themes, Panels, etc.) could be
integrated inside Administration and be restricted only to Admins. The
issue here is our Developer persona, that is not always an Administrator
(although he might be in 80% of the cases).
It's also possible to only provide in the admin a link to the app, and
then to open it using the standard path, i.e. outside the admin, but
then the user might be constantly switching context which looks bad in
the UX point of view.
Maybe to ponderate this problem of context switching, a long term view
solution would be to allow displaying the administration menu in some
apps but I really don't know if it's feasible or not.
So to conclude, first:
- do you agree with the short term solution to use an iframe for
displaying the admin app in the admin, at least as a first step for the
menu app?
-0 , iframes are the worst Then how do you think we should do more globally
for the other admin app
(menu, scheduler, stats, admintools, ...):
1. maintain two UIs
2. include the existing UI in an iframe
3. provide only a link to access the app externally
4. ... another idea?
5. integrate the functionality inside Administration and deprecate the
other/independent way (the other so called 'UI').
Thanks,
Caty
>
> Thanks,
> Simon
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.urli(a)xwiki.com
> More about us at http://www.xwiki.com
>
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
3:38 p.m.
Hello,
On Wed, Sep 5, 2018 at 2:57 PM, Simon Urli <simon.urli(a)xwiki.com> wrote:
Hello everyone,
I'm writing this email as a follow-up after (yet another) brainstorming with
Vincent about how adding the app Menu in the administration
(https://jira.xwiki.org/browse/XWIKI-15483).
Sorry in advance if I repeat things that have already been said.
So the general problem is that we want to be able to put apps with an
existing UI in the admin context, without loosing the ability to use the
apps outside the admin. It's already possible to include external apps in
the admin in keeping their UI, but it implies that the app can be used
without changing the page: for example, the menu app involves to go to /edit
when creating a new menu so it cannot be directly integrated as it is now.
The best solution would be to create two UIs, one for the app to be used
externally and one for the admin, but then it would imply to maintain twice
the code.
The solution on which we agreed with Vincent on the short-term view, is to
provide in the admin the app inside an iframe: the only problem we see would
be the design adaptation, especially for the responsiveness, but it should
do the job.
Another solution discussed, to only allow using the app through the admin
(and so to keep only this UI) seems not acceptable as the app might be used
by other users in some usecases.
It's also possible to only provide in the admin a link to the app, and then
to open it using the standard path, i.e. outside the admin, but then the
user might be constantly switching context which looks bad in the UX point
of view.
Maybe to ponderate this problem of context switching, a long term view
solution would be to allow displaying the administration menu in some apps
but I really don't know if it's feasible or not.
So to conclude, first:
- do you agree with the short term solution to use an iframe for displaying
the admin app in the admin, at least as a first step for the menu app?
I would rather have, for a short term solution, a redirection to the
menu app instead of having an iframe.
Then how do you think we should do more globally for
the other admin app
(menu, scheduler, stats, admintools, ...):
1. maintain two UIs
2. include the existing UI in an iframe
3. provide only a link to access the app externally
4. ... another idea?
Thanks,
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
Thanks,
Adel
2203
days inactive
2203
days old
3 comments
3 participants
participants (3)
-
Adel Atallah -
Ecaterina Moraru (Valica) -
Simon Urli