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

Tue Mar 21 15:19:28 UTC 2017

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-
> modal-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170321/5479328c/attachment.htm>