[xwiki-devs] Follow-up brainstorming about adding apps in administration (menu, scheduler)
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 [email protected] More about us at http://www.xwiki.com
On Wed, Sep 5, 2018 at 3:58 PM Simon Urli <[email protected]> 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 [email protected] More about us at http://www.xwiki.com
On 9/5/18 3:20 PM, Ecaterina Moraru (Valica) wrote:
On Wed, Sep 5, 2018 at 3:58 PM Simon Urli <[email protected]> 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
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.
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').
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
Thanks, Caty
Thanks, Simon -- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
Hello, On Wed, Sep 5, 2018 at 2:57 PM, Simon Urli <[email protected]> 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 [email protected] More about us at http://www.xwiki.com
Thanks, Adel
participants (3)
-
Adel Atallah -
Ecaterina Moraru (Valica) -
Simon Urli