[PatternFly] modals and wizards -- should they be movable?

Michael Burman mburman at redhat.com
Tue Mar 21 15:20:03 UTC 2017 

On Tue, Mar 21, 2017 at 5:19 PM, Michael Burman <mburman at redhat.com> 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 <lhinson at redhat.com> 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 <lclayton at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Mar 20, 2017 at 5:37 PM, Allie Jacobs <ajacobs at redhat.com>
>>> 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 <mamburn at redhat.com>
>>>> 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 <lclayton at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, Mar 20, 2017 at 1:45 PM, Matt Carrano <mcarrano at redhat.com>
>>>>>> 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 <
>>>>>>> gshereme at redhat.com> 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
>>>>>>>> gshereme at redhat.com
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> PatternFly mailing list
>>>>>>>> PatternFly at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Carrano
>>>>>>> Sr. Interaction Designer
>>>>>>> Red Hat, Inc.
>>>>>>> mcarrano at redhat.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> PatternFly mailing list
>>>>>>> PatternFly at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> PatternFly mailing list
>>>>>> PatternFly at redhat.com
>>>>>> 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
>>>>> PatternFly at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Allie Jacobs
>>>> UXD
>>>>
>>>> calendar
>>>> <https://www.google.com/calendar/b/1/embed?src=ajacobs@redhat.com&ctz=America/New_York>
>>>>
>>>
>>>
>>> _______________________________________________
>>> PatternFly mailing list
>>> PatternFly at redhat.com
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170321/ac6eee61/attachment.htm>

More information about the PatternFly mailing list