Follow-up brainstorming about adding apps in administration (menu, scheduler)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Follow-up brainstorming about adding apps in administration (menu, scheduler)

Simon Urli
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
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: Follow-up brainstorming about adding apps in administration (menu, scheduler)

Ecaterina Moraru (Valica)
On Wed, Sep 5, 2018 at 3:58 PM Simon Urli <[hidden email]> 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
> [hidden email]
> More about us at http://www.xwiki.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Follow-up brainstorming about adding apps in administration (menu, scheduler)

Adel Atallah
In reply to this post by Simon Urli
Hello,

On Wed, Sep 5, 2018 at 2:57 PM, Simon Urli <[hidden email]> 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
> [hidden email]
> More about us at http://www.xwiki.com

Thanks,
Adel
Reply | Threaded
Open this post in threaded view
|

Re: Follow-up brainstorming about adding apps in administration (menu, scheduler)

Simon Urli
In reply to this post by Ecaterina Moraru (Valica)


On 9/5/18 3:20 PM, Ecaterina Moraru (Valica) wrote:

> On Wed, Sep 5, 2018 at 3:58 PM Simon Urli <[hidden email]> 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
>> [hidden email]
>> More about us at http://www.xwiki.com
>>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com