[ adding rhev-tech from feedback ]
I also think it's basic to have the dialog movable.
Why regress from the current UI on this aspect?
I remember adding this feature as customer consider it useful.
Thanks,
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306 <+972%209-769-2306>
8272306
Email: [email protected]
IRC : ydary
On Fri, Mar 24, 2017 at 12:03 AM, Marina Kalinin <[email protected]>
wrote:
> Oved,
> Just from my point of view, based on the fact I did not see the 4.2 yet.
> And I do not really work on big deployments - I agree with all and I think
> indeed if something is missing from the dialogue indeed can be added to the
> dialogue itself. Each use case should be reviewed separately and a separate
> bug should be opened.
>
> Thus, I suggest, maybe Michael can have a face to face session and discuss
> the changes with UI developer and see if the implementation is satisfying
> and if any bugs are needed to be filed to satisfied the end user
> experience.
>
> Thanks,
> Marina.
>
> On Thu, Mar 23, 2017 at 4:47 PM, Oved Ourfali <[email protected]> wrote:
>
>> Hi
>>
>> The guideline as far as I know, and it is also reflected here is that the
>> need to move dialogs around is a sign of poor design.
>>
>> However, if something is missing in a dialog, and making me want to move
>> it, then perhaps some data need to reside on the dialog itself?
>>
>> We are also looking into changing the UI design to something similar to
>> cfme, in which there are no pop up dialogs, but you browse to a new view
>> and once you finish you go back to the previous one.... Which means you
>> can't move it neither see anything behind it. It isn't an issue on cfme,
>> satellite, openshift and more.... Not sure why it is an issue for RHV. Not
>> any "regression" is a bad thing. Sometimes it fixes a poor decision done in
>> the past.
>>
>> If something is missing in any dialog, causing you to move it, then
>> perhaps it is a bug that should be opened on the relevant team who owns it,
>> so that they can improve it.
>>
>> Keep in mind that the reason behind the changes we have made in the last
>> few months, and also now, is to aligh RHV to patternfly, just like the
>> other products. I'm not sure whether you had the chance to see how exactly
>> the dialogs look like now. If you do, I'm sure you'll be impresses, and so
>> will our customers. I highly doubt moving dialogs is as important to them
>> as you think.
>>
>> But perhaps I'm wrong here. If I am, I suggest you open an issue to
>> patternfly to support that, but as much as I like RHV, I don't think it is
>> special in this case, and not sure why we need this ability specifically in
>> RHV.
>>
>> Unless that patternfly team has another reference to someone requesting
>> this. Doesn't sound like a priority to me.
>>
>> Best regards,
>> Oved Ourfali
>> Manager, Software Engineering
>> RHV-M Infrastructure and UX Group
>>
>>
>> On Mar 23, 2017 12:02 AM, "Marina Kalinin" <[email protected]> wrote:
>>
>> Hi Michael,
>>
>> Thank you for your email.
>> So, it is on 4.2 (I tried seeing how it is on 4.1 and it is still
>> movable).
>> I totally agree with you from your description, that movable dialogues
>> are convenient and not-movable are problematic.
>> Chatting with the support folks on irc, they did not like the idea
>> either, for the same reasons as Mike didn't like.
>>
>> I am trying to think if there is another option to solve this problem and
>> keep the dialogues static.
>> This will require much more logic probably, on the dialogue itself to
>> avoid selection of already used items or incorrect placement. Sounds
>> something we do not want to deal with, if you are asking me.
>>
>> Some irc comments:
>> - define "would not be movable"? oh, I see...that'd be frustrating
>> because right now we can move them around which might be helpful if you
>> need to check something that's already behind that pane. it'd be more of a
>> problem if you had to start all over because you had to cancel the dialogue
>> box.
>> - I dont like that because sometimes I need to move the windows to see
>> the info below them.
>>
>> Cheers,
>> Marina.
>>
>> On Tue, Mar 21, 2017 at 11:38 AM, Michael Burman <[email protected]>
>> wrote:
>>
>>> 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 <[email protected]>
>>> wrote:
>>>
>>>>
>>>>
>>>> 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/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 <[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-essenti
>>>>>>>>>> al-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 <%28919%29%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
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Burman
>>> RedHat Israel, RHV-M Network QE
>>>
>>> Mobile: 054-5355725
>>> IRC: mburman
>>>
>>
>>
>>
>> --
>> Thanks,
>> Marina.
>>
>>
>>
>
>
> --
> Thanks,
> Marina.
>
_______________________________________________
PatternFly mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/patternfly
