Re: [Kimchi-devel] UI Extension Proposal - Same Action on Multiple List Elements

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(a)eldorado.org.br>; Aline Manera >>>> <alinefm(a)linux.vnet.ibm.com&gt; >>>> Cc: kimchi-devel(a)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(a)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(a)linux.vnet.ibm.com>; >>>>>> kimchi-devel(a)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(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>> _______________________________________________ >>>>> Kimchi-devel mailing list >>>>> Kimchi-devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>> >>> >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel