On Tue, Mar 21, 2017 at 5:19 PM, Michael Burman <[email protected]> wrote:
> Hello All) > > As i mentioned in the bz - https://bugzilla.redhat.com/ > show_bug.cgi?id=1434048 , i will add it here as well. > > Some use cases: > > 1) When creating a new VM on a large rhv-m production environment with a > lot of DCs, clusters and VMs, like we have(rhevm-3 for qe and dev). > Almost every time that i need to create a new VM on this environment, i'm > moving the new VM dialog bit a side, because it's hiding a reference to the > desired DC/Cluster which my other VMs are running on.When i move the > dialog, i know exactly on which cluster and DC to create it, without the > need to cancel. > > 2) Create new network with vlan, but vlan is in use, i can drag the > new/edit network window and to look which vlan isn't in use. > This is relevant as well for which network has specific label, QoS and > role. Sometimes you need the info of other networks while creating new > network and you don't always would like to cancel to view this info. > > 3) New data domain, one created with nfs type and one with iscsi, not > always recall what was created first, the iscsi? nfs? can drag the window > and take a look on what i already added. > > 4) New cluster, you need a reference of a Cluster CPU type of a specific > cluster in a large list of clusters. > > Note, that most of the real use cases are in large setups, with a lot of > DCs, clusters, networks, hosts, data domains, VMs and so on.. > I'm sure that we can find more use cases if we will ask the whole rhv qe > stuff. > > - The more i ask around the qe stuff , i understand that a lot of us using > this window dragging on a daily/weekly basis. And each team with it's real > need for information. > > - Some of the info that is required, not always could be possible on the > window dialog itself and hidden behind it, but it could be helpful to > complete the task. > > Regards, > > On Tue, Mar 21, 2017 at 3:26 PM, Leslie Hinson <[email protected]> wrote: > >> Greg has pointed to a great resource that highlights some of the >> disadvantages of a moveable dialog. Thanks for passing along! See: >> http://ux.stackexchange.com/questions/81134/should-moda >> l-dialogs-be-movable >> >> In particular, check out the section the highlights the following >> concerns: >> >> * Moving the modal requires a lot of cognitive load. >> * If users are needing to move modals, this is usually the result of poor >> design. >> * User moves dialog partly/mostly offscreen. >> * User moves the dialog, and then resizes the browser window. The dialog >> may now be offscreen, so this case needs to be worked out. >> * Scrolling ambiguity with responsive layouts. >> >> Matt hit on this second point when he said... >> >> If the concern is that it's covering content on the parent screen that >>> the user needs in completing the task, then it seems like a modal is either >>> the wrong solution or that information should be available from within the >>> dialog. >> >> >> The intent of PatternFly is to provide common solutions that adhere to ux >> best practices and standards. If an application determines that a moveable >> dialog is a requirement, the best approach might be to add that >> functionality in their application vs it being introduced to PatternFly >> (given the design concerns and small percentage of need). >> >> Greg: In your use case, is important information being hidden? I'd be >> curious how else the user is being impacted. >> >> Best, >> Leslie >> >> >> >> On Mon, Mar 20, 2017 at 7:03 PM, Liz Clayton <[email protected]> wrote: >> >>> Hi, >>> >>> On Mon, Mar 20, 2017 at 5:37 PM, Allie Jacobs <[email protected]> >>> wrote: >>> >>>> I'm not sure if there's any harm other than the widget moving around >>>> unexpectedly. >>>> >>> >>> I think there could be some harm if moving the modal around was a >>> distraction that cost the user time and/or task focus. >>> >>> >>>> But to Matt's point the use case for a modal would be one where the >>>> user should not be trying to interact with the base page. >>>> >>> >>> Also echo'ing Matt's point - placing modal dialogs front & center, >>> while blocking interaction with the background, demands attention and helps >>> to convey the importance of the task. Being able to push it aside might >>> minimize that. >>> >>> Maybe the 5% use case could be better served by additional on screen >>> help text or other contextual info. >>> >>> Liz C >>> >>> >>>> I would agree with updating PatternFly's modal documentation and >>>> possibly exploring a separate pattern for a moveable dialog. >>>> >>>> On Mon, Mar 20, 2017 at 4:46 PM, Mike Amburn <[email protected]> >>>> wrote: >>>> >>>>> I’m curious… what’s the harm in allowing modals to be moved? >>>>> >>>>> - allowing movement doesn’t alter the state of either the modal window >>>>> or the background >>>>> - no harm for 95% of the time when a user wouldn’t need to see >>>>> information in the background >>>>> - great benefit for the 5% that do >>>>> - keeps the info displayed in the modal focused on the 95% with a >>>>> workaround for the 5% >>>>> >>>>> No strong feelings either way, just thinking it through. >>>>> >>>>> >>>>> On Mon, Mar 20, 2017 at 3:20 PM, Liz Clayton <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On Mon, Mar 20, 2017 at 1:45 PM, Matt Carrano <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> It's an interesting question, Greg. IMO, the reason for using a >>>>>>> modal dialog should be to focus the user's attention on completing the >>>>>>> task >>>>>>> at hand before doing something else in the UI. So in working from that >>>>>>> premise, it begs the question of why someone needs the dialog to be >>>>>>> movable. If the concern is that it's covering content on the parent >>>>>>> screen >>>>>>> that the user needs in completing the task, then it seems like a modal >>>>>>> is >>>>>>> either the wrong solution or that information should be available from >>>>>>> within the dialog. >>>>>>> >>>>>> +1 >>>>>> >>>>>>> >>>>>>> I'm also interested in what others think about this. I wouldn't be >>>>>>> in favor of making PatternFly modals movable unless there is a use case >>>>>>> justification that we can point to. >>>>>>> >>>>>> >>>>>> I guess if any of the dialogs warranted being modeless >>>>>> <https://en.wikipedia.org/wiki/Dialog_box#Modeless> instead, then >>>>>> allowing them to move would make sense. If not, then I agree that they >>>>>> shouldn't need to move. >>>>>> >>>>>> It might be helpful to have some documentation for the "modal" widget >>>>>> in Patternfly, that offered some usage best practices and clarify terms >>>>>> (modal, modeless, dialog, overlay...) I found this little writeup useful: >>>>>> https://uxplanet.org/5-essential-ux-rules-for-dialog-design- >>>>>> 4de258c22116#.q1fizexrl . >>>>>> >>>>>> Liz C. >>>>>> >>>>>> >>>>>> >>>>>>> Matt >>>>>>> >>>>>>> On Mon, Mar 20, 2017 at 12:57 PM, Greg Sheremeta < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> We recently implemented Patternfly styling on our modal dialogs, >>>>>>>> and instantly received a bug [1] about them no longer being draggable. >>>>>>>> According to a quick search, bootstrap's modals do not support >>>>>>>> dragging, >>>>>>>> but that functionality could be added with jquery-ui [2]. According to >>>>>>>> [3], >>>>>>>> it's not a great idea. >>>>>>>> >>>>>>>> oVirt is quite modal-dialog heavy, so I can see why users would >>>>>>>> want this. We are in the planning stages of moving away from having so >>>>>>>> many >>>>>>>> dialogs, so I'm not terribly worried about it. But I did think it was a >>>>>>>> good idea to ask the list. >>>>>>>> >>>>>>>> So, what do people think about draggable modals? >>>>>>>> >>>>>>>> Best wishes, >>>>>>>> Greg >>>>>>>> >>>>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1434048 >>>>>>>> [2] http://stackoverflow.com/questions/27120579/jquery-dragg >>>>>>>> able-with-bootstrap-modal-scroller-strange-behaviour >>>>>>>> [3] http://ux.stackexchange.com/questions/81134/should-modal >>>>>>>> -dialogs-be-movable >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Greg Sheremeta, MBA >>>>>>>> Red Hat, Inc. >>>>>>>> Sr. Software Engineer >>>>>>>> [email protected] >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> PatternFly mailing list >>>>>>>> [email protected] >>>>>>>> https://www.redhat.com/mailman/listinfo/patternfly >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matt Carrano >>>>>>> Sr. Interaction Designer >>>>>>> Red Hat, Inc. >>>>>>> [email protected] >>>>>>> >>>>>>> _______________________________________________ >>>>>>> PatternFly mailing list >>>>>>> [email protected] >>>>>>> https://www.redhat.com/mailman/listinfo/patternfly >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> PatternFly mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/patternfly >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mike Amburn Dixon >>>>> Product Manager, Integrated Solutions BU >>>>> M: 919-818-1201 <(919)%20818-1201> >>>>> >>>>> >>>>> _______________________________________________ >>>>> PatternFly mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/patternfly >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Allie Jacobs >>>> UXD >>>> >>>> calendar >>>> <https://www.google.com/calendar/b/1/[email protected]&ctz=America/New_York> >>>> >>> >>> >>> _______________________________________________ >>> PatternFly mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/patternfly >>> >>> >> > > > -- > Michael Burman > RedHat Israel, RHV-M Network QE > > Mobile: 054-5355725 > IRC: mburman > -- Michael Burman RedHat Israel, RHV-M Network QE Mobile: 054-5355725 IRC: mburman
_______________________________________________ PatternFly mailing list [email protected] https://www.redhat.com/mailman/listinfo/patternfly
