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

Tue Mar 21 15:38:50 UTC 2017

I would like to add our PMs and customer support to this discussion as well

On Tue, Mar 21, 2017 at 5:20 PM, Michael Burman <mburman at redhat.com> wrote:

>
>
> 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/sh
>> ow_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
>

-- 
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/6e69863f/attachment.htm>