UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline, we often have use cases that a user wants to perform the same action for multiple list elements. The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element. We should discuss if this meets the user needs (at least for new functionalities). Kind regards Jan
Hi team, When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it. For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all". For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices. Regards, Samuel -----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements Hello Aline, we often have use cases that a user wants to perform the same action for multiple list elements. The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element. We should discuss if this meets the user needs (at least for new functionalities). Kind regards Jan _______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hello Samuel, I think we both agree that from a usage perspective we should support an action for multiple list elements. Please correct me if I am wrong. The next question is how to implement this. We currently have an action combo box for each list element. With an action combo box for the whole list we can do both: 1) Action for a single list element 2) Action for multiple list elements Depending on the selection the possible actions may change. There are also actions which can only be executed on a single list element. We definitely need further discussions on this. Kind regards Jan On 10/08/2015 09:24 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it. For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all". For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices.
Regards, Samuel
-----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline,
we often have use cases that a user wants to perform the same action for multiple list elements.
The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element.
We should discuss if this meets the user needs (at least for new functionalities).
Kind regards Jan
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hello Samuel, I did not find a response mail from you - maybe I deleted it by error. Therefore I resend this mail. Kind regards Jan On 10/09/2015 11:36 AM, Jan Schneider wrote:
Hello Samuel,
I think we both agree that from a usage perspective we should support an action for multiple list elements. Please correct me if I am wrong.
The next question is how to implement this.
We currently have an action combo box for each list element. With an action combo box for the whole list we can do both: 1) Action for a single list element 2) Action for multiple list elements
Depending on the selection the possible actions may change. There are also actions which can only be executed on a single list element.
We definitely need further discussions on this.
Kind regards Jan
On 10/08/2015 09:24 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it. For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all". For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices.
Regards, Samuel
-----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline,
we often have use cases that a user wants to perform the same action for multiple list elements.
The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element.
We should discuss if this meets the user needs (at least for new functionalities).
Kind regards Jan
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi Jan, Sorry for the delay, I got stuck rebasing my patches and working in the new-ui and I forgot to reply. I drew a quick mockup with Chrome and the screenshots are attached. The main problem is that these fonts are very small compared to the other UI elements in high resolution. We would have to resize "Basic Information" panel by half its width and expand Debug Reports and Repositories. But if we follow the new proposals for Host/Admin in Gingerbase, then we'll have Basic Information with 100% screen width and inline fields instead of blocks below the dashboard; Debug Reports and User Management can keep 50% - 50% screen width in Administration and Repositories can be 100% with Software Updates and Firmware Updates. Screenshots: 1.png = none selected 2.png = one item selected 3.png = multiple items selected Light gray buttons = disabled state Regards, Samuel -----Original Message----- From: Jan Schneider [mailto:schneidj@linux.vnet.ibm.com] Sent: quarta-feira, 21 de outubro de 2015 11:40 To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes@eldorado.org.br>; Aline Manera <alinefm@linux.vnet.ibm.com> Cc: kimchi-devel@ovirt.org Subject: Re: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements Hello Samuel, I did not find a response mail from you - maybe I deleted it by error. Therefore I resend this mail. Kind regards Jan On 10/09/2015 11:36 AM, Jan Schneider wrote:
Hello Samuel,
I think we both agree that from a usage perspective we should support an action for multiple list elements. Please correct me if I am wrong.
The next question is how to implement this.
We currently have an action combo box for each list element. With an action combo box for the whole list we can do both: 1) Action for a single list element 2) Action for multiple list elements
Depending on the selection the possible actions may change. There are also actions which can only be executed on a single list element.
We definitely need further discussions on this.
Kind regards Jan
On 10/08/2015 09:24 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it. For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all". For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices.
Regards, Samuel
-----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline,
we often have use cases that a user wants to perform the same action for multiple list elements.
The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element.
We should discuss if this meets the user needs (at least for new functionalities).
Kind regards Jan
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi Samuel, I like your proposal shown in the attached screenshots. I would only change the button labels 'Download All' and 'Remove All' on 3.png to 'Download' and 'Remove' like on the two other screenshots. The user might interpret 'Remove All' and 'Download All' in a way that it affects all list items - not only the selected ones. In your proposal all items of the former 'Actions' combo box are now permanently visible. I like this approach. Compared to the 'Action' combo boxes it needs more space but improves usability. Ginger host management will add a lot of new panels. To get a consistent look and feel we also need to re-arrange the existing panels which will reduce/solve the restrictions in panel width. I will start a discussion on this in the Ginger community. One important point I would like to state at the end: The design discussions should show the way we want to go. I do not expect that we can implement all these ideas by end of 2015. Let's be pragmatic on what is possible in the first step. Kind regards Jan On 10/21/2015 04:54 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi Jan,
Sorry for the delay, I got stuck rebasing my patches and working in the new-ui and I forgot to reply.
I drew a quick mockup with Chrome and the screenshots are attached. The main problem is that these fonts are very small compared to the other UI elements in high resolution. We would have to resize "Basic Information" panel by half its width and expand Debug Reports and Repositories. But if we follow the new proposals for Host/Admin in Gingerbase, then we'll have Basic Information with 100% screen width and inline fields instead of blocks below the dashboard; Debug Reports and User Management can keep 50% - 50% screen width in Administration and Repositories can be 100% with Software Updates and Firmware Updates.
Screenshots: 1.png = none selected 2.png = one item selected 3.png = multiple items selected
Light gray buttons = disabled state
Regards, Samuel
-----Original Message----- From: Jan Schneider [mailto:schneidj@linux.vnet.ibm.com] Sent: quarta-feira, 21 de outubro de 2015 11:40 To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes@eldorado.org.br>; Aline Manera <alinefm@linux.vnet.ibm.com> Cc: kimchi-devel@ovirt.org Subject: Re: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Samuel,
I did not find a response mail from you - maybe I deleted it by error. Therefore I resend this mail.
Kind regards Jan
On 10/09/2015 11:36 AM, Jan Schneider wrote:
Hello Samuel,
I think we both agree that from a usage perspective we should support an action for multiple list elements. Please correct me if I am wrong.
The next question is how to implement this.
We currently have an action combo box for each list element. With an action combo box for the whole list we can do both: 1) Action for a single list element 2) Action for multiple list elements
Depending on the selection the possible actions may change. There are also actions which can only be executed on a single list element.
We definitely need further discussions on this.
Kind regards Jan
On 10/08/2015 09:24 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it. For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all". For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices.
Regards, Samuel
-----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline,
we often have use cases that a user wants to perform the same action for multiple list elements.
The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element.
We should discuss if this meets the user needs (at least for new functionalities).
Kind regards Jan
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 22/10/2015 07:03, Jan Schneider wrote:
Hi Samuel,
I like your proposal shown in the attached screenshots. I would only change the button labels 'Download All' and 'Remove All' on 3.png to 'Download' and 'Remove' like on the two other screenshots. The user might interpret 'Remove All' and 'Download All' in a way that it affects all list items - not only the selected ones.
In your proposal all items of the former 'Actions' combo box are now permanently visible. I like this approach. Compared to the 'Action' combo boxes it needs more space but improves usability.
Ginger host management will add a lot of new panels. To get a consistent look and feel we also need to re-arrange the existing panels which will reduce/solve the restrictions in panel width. I will start a discussion on this in the Ginger community.
One important point I would like to state at the end: The design discussions should show the way we want to go. I do not expect that we can implement all these ideas by end of 2015. Let's be pragmatic on what is possible in the first step.
For Kimchi 2.0 (to be released by the end of December) I'd say to launch the new UI as it was designed. We can open a github issue for each enhancement we agree and target it for the upcoming release after Kimchi 2.0 It also applies to the new navigation bar we have agreed too.
Kind regards Jan
On 10/21/2015 04:54 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi Jan,
Sorry for the delay, I got stuck rebasing my patches and working in the new-ui and I forgot to reply.
I drew a quick mockup with Chrome and the screenshots are attached. The main problem is that these fonts are very small compared to the other UI elements in high resolution. We would have to resize "Basic Information" panel by half its width and expand Debug Reports and Repositories. But if we follow the new proposals for Host/Admin in Gingerbase, then we'll have Basic Information with 100% screen width and inline fields instead of blocks below the dashboard; Debug Reports and User Management can keep 50% - 50% screen width in Administration and Repositories can be 100% with Software Updates and Firmware Updates.
Screenshots: 1.png = none selected 2.png = one item selected 3.png = multiple items selected
Light gray buttons = disabled state
Regards, Samuel
-----Original Message----- From: Jan Schneider [mailto:schneidj@linux.vnet.ibm.com] Sent: quarta-feira, 21 de outubro de 2015 11:40 To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes@eldorado.org.br>; Aline Manera <alinefm@linux.vnet.ibm.com> Cc: kimchi-devel@ovirt.org Subject: Re: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Samuel,
I did not find a response mail from you - maybe I deleted it by error. Therefore I resend this mail.
Kind regards Jan
On 10/09/2015 11:36 AM, Jan Schneider wrote:
Hello Samuel,
I think we both agree that from a usage perspective we should support an action for multiple list elements. Please correct me if I am wrong.
The next question is how to implement this.
We currently have an action combo box for each list element. With an action combo box for the whole list we can do both: 1) Action for a single list element 2) Action for multiple list elements
Depending on the selection the possible actions may change. There are also actions which can only be executed on a single list element.
We definitely need further discussions on this.
Kind regards Jan
On 10/08/2015 09:24 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it. For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all". For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices.
Regards, Samuel
-----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline,
we often have use cases that a user wants to perform the same action for multiple list elements.
The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element.
We should discuss if this meets the user needs (at least for new functionalities).
Kind regards Jan
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 27.10.2015 13:31, Aline Manera wrote:
On 22/10/2015 07:03, Jan Schneider wrote:
Hi Samuel,
I like your proposal shown in the attached screenshots. I would only change the button labels 'Download All' and 'Remove All' on 3.png to 'Download' and 'Remove' like on the two other screenshots. The user might interpret 'Remove All' and 'Download All' in a way that it affects all list items - not only the selected ones.
In your proposal all items of the former 'Actions' combo box are now permanently visible. I like this approach. Compared to the 'Action' combo boxes it needs more space but improves usability.
Ginger host management will add a lot of new panels. To get a consistent look and feel we also need to re-arrange the existing panels which will reduce/solve the restrictions in panel width. I will start a discussion on this in the Ginger community.
One important point I would like to state at the end: The design discussions should show the way we want to go. I do not expect that we can implement all these ideas by end of 2015. Let's be pragmatic on what is possible in the first step.
For Kimchi 2.0 (to be released by the end of December) I'd say to launch the new UI as it was designed. We can open a github issue for each enhancement we agree and target it for the upcoming release after Kimchi 2.0 It also applies to the new navigation bar we have agreed too.
Aline, the design spec is outdated in some areas: it doesn't reflect the separation into the various plugings and the additional functionality we are planning in host-management. Please let us look at the areas we know we want changes which are triggered by design discussions/decisions taken after the UI-Spec was finished. I agree that we will have enhancements which will not be doable for Kimchi 2.0. But I hope that such basic things like reorganising the navigation bar shouldn't be a big effort with the new framework.
Kind regards Jan
On 10/21/2015 04:54 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi Jan,
Sorry for the delay, I got stuck rebasing my patches and working in the new-ui and I forgot to reply.
I drew a quick mockup with Chrome and the screenshots are attached. The main problem is that these fonts are very small compared to the other UI elements in high resolution. We would have to resize "Basic Information" panel by half its width and expand Debug Reports and Repositories. But if we follow the new proposals for Host/Admin in Gingerbase, then we'll have Basic Information with 100% screen width and inline fields instead of blocks below the dashboard; Debug Reports and User Management can keep 50% - 50% screen width in Administration and Repositories can be 100% with Software Updates and Firmware Updates.
Screenshots: 1.png = none selected 2.png = one item selected 3.png = multiple items selected
Light gray buttons = disabled state
Regards, Samuel
-----Original Message----- From: Jan Schneider [mailto:schneidj@linux.vnet.ibm.com] Sent: quarta-feira, 21 de outubro de 2015 11:40 To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes@eldorado.org.br>; Aline Manera <alinefm@linux.vnet.ibm.com> Cc: kimchi-devel@ovirt.org Subject: Re: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Samuel,
I did not find a response mail from you - maybe I deleted it by error. Therefore I resend this mail.
Kind regards Jan
On 10/09/2015 11:36 AM, Jan Schneider wrote:
Hello Samuel,
I think we both agree that from a usage perspective we should support an action for multiple list elements. Please correct me if I am wrong.
The next question is how to implement this.
We currently have an action combo box for each list element. With an action combo box for the whole list we can do both: 1) Action for a single list element 2) Action for multiple list elements
Depending on the selection the possible actions may change. There are also actions which can only be executed on a single list element.
We definitely need further discussions on this.
Kind regards Jan
On 10/08/2015 09:24 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it. For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all". For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices.
Regards, Samuel
-----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline,
we often have use cases that a user wants to perform the same action for multiple list elements.
The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element.
We should discuss if this meets the user needs (at least for new functionalities).
Kind regards Jan
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 27/10/2015 14:16, Walter Niklaus wrote:
On 27.10.2015 13:31, Aline Manera wrote:
On 22/10/2015 07:03, Jan Schneider wrote:
Hi Samuel,
I like your proposal shown in the attached screenshots. I would only change the button labels 'Download All' and 'Remove All' on 3.png to 'Download' and 'Remove' like on the two other screenshots. The user might interpret 'Remove All' and 'Download All' in a way that it affects all list items - not only the selected ones.
In your proposal all items of the former 'Actions' combo box are now permanently visible. I like this approach. Compared to the 'Action' combo boxes it needs more space but improves usability.
Ginger host management will add a lot of new panels. To get a consistent look and feel we also need to re-arrange the existing panels which will reduce/solve the restrictions in panel width. I will start a discussion on this in the Ginger community.
One important point I would like to state at the end: The design discussions should show the way we want to go. I do not expect that we can implement all these ideas by end of 2015. Let's be pragmatic on what is possible in the first step.
For Kimchi 2.0 (to be released by the end of December) I'd say to launch the new UI as it was designed. We can open a github issue for each enhancement we agree and target it for the upcoming release after Kimchi 2.0 It also applies to the new navigation bar we have agreed too.
Aline, the design spec is outdated in some areas: it doesn't reflect the separation into the various plugings and the additional functionality we are planning in host-management. Please let us look at the areas we know we want changes which are triggered by design discussions/decisions taken after the UI-Spec was finished.
The UI spec was already finished! I mean, there is no one working to update the spec documentation to reflect the changes we did related to wok and kimchi as a plugin.
I agree that we will have enhancements which will not be doable for Kimchi 2.0. But I hope that such basic things like reorganising the navigation bar shouldn't be a big effort with the new framework.
The priority for Kimchi 2.0 is to have the new UI as it was firstly designed + UI for the new features planned. I agree, if time allows, to implement the ideas we have discussed for 2.0, but I doubt it will happen as we are only 1 month for the code freeze and the new UI is not up and running.
Kind regards Jan
On 10/21/2015 04:54 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi Jan,
Sorry for the delay, I got stuck rebasing my patches and working in the new-ui and I forgot to reply.
I drew a quick mockup with Chrome and the screenshots are attached. The main problem is that these fonts are very small compared to the other UI elements in high resolution. We would have to resize "Basic Information" panel by half its width and expand Debug Reports and Repositories. But if we follow the new proposals for Host/Admin in Gingerbase, then we'll have Basic Information with 100% screen width and inline fields instead of blocks below the dashboard; Debug Reports and User Management can keep 50% - 50% screen width in Administration and Repositories can be 100% with Software Updates and Firmware Updates.
Screenshots: 1.png = none selected 2.png = one item selected 3.png = multiple items selected
Light gray buttons = disabled state
Regards, Samuel
-----Original Message----- From: Jan Schneider [mailto:schneidj@linux.vnet.ibm.com] Sent: quarta-feira, 21 de outubro de 2015 11:40 To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes@eldorado.org.br>; Aline Manera <alinefm@linux.vnet.ibm.com> Cc: kimchi-devel@ovirt.org Subject: Re: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Samuel,
I did not find a response mail from you - maybe I deleted it by error. Therefore I resend this mail.
Kind regards Jan
On 10/09/2015 11:36 AM, Jan Schneider wrote:
Hello Samuel,
I think we both agree that from a usage perspective we should support an action for multiple list elements. Please correct me if I am wrong.
The next question is how to implement this.
We currently have an action combo box for each list element. With an action combo box for the whole list we can do both: 1) Action for a single list element 2) Action for multiple list elements
Depending on the selection the possible actions may change. There are also actions which can only be executed on a single list element.
We definitely need further discussions on this.
Kind regards Jan
On 10/08/2015 09:24 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it. For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all". For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices.
Regards, Samuel
-----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline,
we often have use cases that a user wants to perform the same action for multiple list elements.
The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element.
We should discuss if this meets the user needs (at least for new functionalities).
Kind regards Jan
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 28/10/2015 10:03, Aline Manera wrote:
On 27/10/2015 14:16, Walter Niklaus wrote:
On 27.10.2015 13:31, Aline Manera wrote:
On 22/10/2015 07:03, Jan Schneider wrote:
Hi Samuel,
I like your proposal shown in the attached screenshots. I would only change the button labels 'Download All' and 'Remove All' on 3.png to 'Download' and 'Remove' like on the two other screenshots. The user might interpret 'Remove All' and 'Download All' in a way that it affects all list items - not only the selected ones.
In your proposal all items of the former 'Actions' combo box are now permanently visible. I like this approach. Compared to the 'Action' combo boxes it needs more space but improves usability.
Ginger host management will add a lot of new panels. To get a consistent look and feel we also need to re-arrange the existing panels which will reduce/solve the restrictions in panel width. I will start a discussion on this in the Ginger community.
One important point I would like to state at the end: The design discussions should show the way we want to go. I do not expect that we can implement all these ideas by end of 2015. Let's be pragmatic on what is possible in the first step.
For Kimchi 2.0 (to be released by the end of December) I'd say to launch the new UI as it was designed. We can open a github issue for each enhancement we agree and target it for the upcoming release after Kimchi 2.0 It also applies to the new navigation bar we have agreed too.
Aline, the design spec is outdated in some areas: it doesn't reflect the separation into the various plugings and the additional functionality we are planning in host-management. Please let us look at the areas we know we want changes which are triggered by design discussions/decisions taken after the UI-Spec was finished.
The UI spec was already finished! I mean, there is no one working to update the spec documentation to reflect the changes we did related to wok and kimchi as a plugin.
I agree that we will have enhancements which will not be doable for Kimchi 2.0. But I hope that such basic things like reorganising the navigation bar shouldn't be a big effort with the new framework.
The priority for Kimchi 2.0 is to have the new UI as it was firstly designed + UI for the new features planned.
I agree, if time allows, to implement the ideas we have discussed for 2.0, but I doubt it will happen as we are only 1 month for the code freeze and the new UI is not up and running.
(Just to make sure it is clear for everyone) That means, you are more than welcome to send patches to cover those changes we have agreed! But Samuel, Socorro and Andre will be completely focused on getting the new UI + UI for the new features done for 2.0
Kind regards Jan
On 10/21/2015 04:54 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi Jan,
Sorry for the delay, I got stuck rebasing my patches and working in the new-ui and I forgot to reply.
I drew a quick mockup with Chrome and the screenshots are attached. The main problem is that these fonts are very small compared to the other UI elements in high resolution. We would have to resize "Basic Information" panel by half its width and expand Debug Reports and Repositories. But if we follow the new proposals for Host/Admin in Gingerbase, then we'll have Basic Information with 100% screen width and inline fields instead of blocks below the dashboard; Debug Reports and User Management can keep 50% - 50% screen width in Administration and Repositories can be 100% with Software Updates and Firmware Updates.
Screenshots: 1.png = none selected 2.png = one item selected 3.png = multiple items selected
Light gray buttons = disabled state
Regards, Samuel
-----Original Message----- From: Jan Schneider [mailto:schneidj@linux.vnet.ibm.com] Sent: quarta-feira, 21 de outubro de 2015 11:40 To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes@eldorado.org.br>; Aline Manera <alinefm@linux.vnet.ibm.com> Cc: kimchi-devel@ovirt.org Subject: Re: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Samuel,
I did not find a response mail from you - maybe I deleted it by error. Therefore I resend this mail.
Kind regards Jan
On 10/09/2015 11:36 AM, Jan Schneider wrote:
Hello Samuel,
I think we both agree that from a usage perspective we should support an action for multiple list elements. Please correct me if I am wrong.
The next question is how to implement this.
We currently have an action combo box for each list element. With an action combo box for the whole list we can do both: 1) Action for a single list element 2) Action for multiple list elements
Depending on the selection the possible actions may change. There are also actions which can only be executed on a single list element.
We definitely need further discussions on this.
Kind regards Jan
On 10/08/2015 09:24 PM, Samuel Henrique De Oliveira Guimaraes wrote: > Hi team, > > When I was updating wok.grid.js and I asked Atreeye to create > wok.list.js we discussed if we should set a parameter to choose > between action buttons on top or left of each item (in case we had > only wok.grid.js) or create this new widget for the Debug > Reports and > Repositories. However, when I implemented this in the new-ui and > started playing with these buttons, I noticed some anti-patterns. > If you look into the attached images (debug_reports.jpg and > repositories.jpg), you can see that the active line enters in the > "selected" state. When you click outside this area, the list item > keeps selected but the drop-down menu is hidden. In addition to > that, > the "Add / Generate" buttons are in the panel context, not just the > active item on the lists. I'm attaching a mockup with these buttons > on top and the context menus on the left (button_top.jpg). > There's also the iOS pattern that is recommended on the mobile > mockups that Susan forwarded to me (mobile.jpg). If we agree > that the > mobile design should take this pattern, then we'll have to update > wok.grid.js and merge with wok.list.js, adding the suggested > behavior > for mobile devices. I think we can use the same pattern on the > desktop, but there are some points that we should agree before we > start developing it. For instance, if I select multiple > repositories > and one of them is disabled and the other ones enabled, I > believe we > should have action links such as "Enable All / Disable all". For > Debug Reports, I'm not sure If iOS allows to download files so we > could show a "Download All" only for Android devices. > > Regards, > Samuel > > -----Original Message----- > From: kimchi-devel-bounces@ovirt.org > [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider > Sent: quinta-feira, 8 de outubro de 2015 13:29 > To: Aline Manera <alinefm@linux.vnet.ibm.com>; > kimchi-devel@ovirt.org > Subject: [Kimchi-devel] UI Extension Proposal - Same Action on > Multiple List Elements > > Hello Aline, > > we often have use cases that a user wants to perform the same > action > for multiple list elements. > > The User Interface Design Specification - Kimchi, 2014-12-23 forces > the user to do this separately for each list element. > > We should discuss if this meets the user needs (at least for new > functionalities). > > Kind regards > Jan > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel _______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi Samuel! Hi Jan! I'd suggest to have the "Generate" button (which does not depend on selected items) to be displayed aside of "Debug Reports" title. Similar from what we have for the Tabs. For example: | Debug Reports + Generate| | |Delete | Enable | Disable | | | report1 | | report2 | Regards, Aline Manera On 21/10/2015 12:54, Samuel Henrique De Oliveira Guimaraes wrote:
Hi Jan,
Sorry for the delay, I got stuck rebasing my patches and working in the new-ui and I forgot to reply.
I drew a quick mockup with Chrome and the screenshots are attached. The main problem is that these fonts are very small compared to the other UI elements in high resolution. We would have to resize "Basic Information" panel by half its width and expand Debug Reports and Repositories. But if we follow the new proposals for Host/Admin in Gingerbase, then we'll have Basic Information with 100% screen width and inline fields instead of blocks below the dashboard; Debug Reports and User Management can keep 50% - 50% screen width in Administration and Repositories can be 100% with Software Updates and Firmware Updates.
Screenshots: 1.png = none selected 2.png = one item selected 3.png = multiple items selected
Light gray buttons = disabled state
Regards, Samuel
-----Original Message----- From: Jan Schneider [mailto:schneidj@linux.vnet.ibm.com] Sent: quarta-feira, 21 de outubro de 2015 11:40 To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes@eldorado.org.br>; Aline Manera <alinefm@linux.vnet.ibm.com> Cc: kimchi-devel@ovirt.org Subject: Re: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Samuel,
I did not find a response mail from you - maybe I deleted it by error. Therefore I resend this mail.
Kind regards Jan
On 10/09/2015 11:36 AM, Jan Schneider wrote:
Hello Samuel,
I think we both agree that from a usage perspective we should support an action for multiple list elements. Please correct me if I am wrong.
The next question is how to implement this.
We currently have an action combo box for each list element. With an action combo box for the whole list we can do both: 1) Action for a single list element 2) Action for multiple list elements
Depending on the selection the possible actions may change. There are also actions which can only be executed on a single list element.
We definitely need further discussions on this.
Kind regards Jan
On 10/08/2015 09:24 PM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it. For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all". For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices.
Regards, Samuel
-----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline,
we often have use cases that a user wants to perform the same action for multiple list elements.
The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element.
We should discuss if this meets the user needs (at least for new functionalities).
Kind regards Jan
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 08/10/2015 16:24, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
When I was updating wok.grid.js and I asked Atreeye to create wok.list.js we discussed if we should set a parameter to choose between action buttons on top or left of each item (in case we had only wok.grid.js) or create this new widget for the Debug Reports and Repositories. However, when I implemented this in the new-ui and started playing with these buttons, I noticed some anti-patterns. If you look into the attached images (debug_reports.jpg and repositories.jpg), you can see that the active line enters in the "selected" state. When you click outside this area, the list item keeps selected but the drop-down menu is hidden. In addition to that, the "Add / Generate" buttons are in the panel context, not just the active item on the lists. I'm attaching a mockup with these buttons on top and the context menus on the left (button_top.jpg). There's also the iOS pattern that is recommended on the mobile mockups that Susan forwarded to me (mobile.jpg). If we agree that the mobile design should take this pattern, then we'll have to update wok.grid.js and merge with wok.list.js, adding the suggested behavior for mobile devices. I think we can use the same pattern on the desktop, but there are some points that we should agree before we start developing it.
For instance, if I select multiple repositories and one of them is disabled and the other ones enabled, I believe we should have action links such as "Enable All / Disable all".
Agree. But I'd say to have separated actions: "Enable All" and "Disable All"
For Debug Reports, I'm not sure If iOS allows to download files so we could show a "Download All" only for Android devices.
There are some issues open on github related to that, ie, iOS does not allow user to download the debug report as it does not have an application to open it.
Regards, Samuel
-----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Jan Schneider Sent: quinta-feira, 8 de outubro de 2015 13:29 To: Aline Manera <alinefm@linux.vnet.ibm.com>; kimchi-devel@ovirt.org Subject: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements
Hello Aline,
we often have use cases that a user wants to perform the same action for multiple list elements.
The User Interface Design Specification - Kimchi, 2014-12-23 forces the user to do this separately for each list element.
We should discuss if this meets the user needs (at least for new functionalities).
Kind regards Jan
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (4)
-
Aline Manera -
Jan Schneider -
Samuel Henrique De Oliveira Guimaraes -
Walter Niklaus