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

Tue Mar 21 13:26:15 UTC 2017

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