[haiku-development] Re: Ctrl+Alt window management functionality

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Tue, 22 Jan 2013 14:47:13 -0500

On Mon, Jan 21, 2013 at 7:01 PM, Matt Madia <mattmadia@xxxxxxxxx> wrote:
> On 1/21/13, pulkomandy@xxxxxxxxxxxxx <pulkomandy@xxxxxxxxxxxxx> wrote:
>>> How about LMB on the border performs a move, and option key+LMB
>>> performs to a resize, good compromise?
>>
>> RMB already performs a resize. You think this is not easy to reach, and want
>> to replace it with a key + LMB ? I think this is only change for the purpose
>> of change now. RMB drag is easier than LMB drag + a key.
>>
>> So, we already have a good compromise.
>
> Exactly. This is why I vehemently oppose you changing the LMB or RMB
> functionality with regards to moving the window or resizing it.
> (Altering the visual appearances during CTRL+ALT is something I agree
> with and even have some suggestions further below.)
> Changing the behavior of LMB and RMB would be breaking consistency in
> order to "fix" a problem by implementing an improper solution.
>
> To put it bluntly, arguing to change behavior of LMB, RMB, CTRL+ALT on
> "poor discoverability" (or even ergonomics) is a moot point.
> By needing to control two devices (a pointer and a keyboard), CTRL+ALT
> is advanced, we cannot demand users to use it as the only or primary
> means.
> CTRL+ALT is alternative because there are other means to achieve the
> same effect.

I don't see how it is a moot point because the action requires you to
use the mouse and keyboard simultaneously and it's not true that there
are real alternatives, you can only resize a window by the bottom
right corner and only move a window by the tab, and only if it is in
focus.

If you discount ergonomics and discoverability then yes the current
solution is consistent and works except for the details but I just
don't see how you are able to do that. To use your language, I
vehemently oppose any solution that requires the user to perform a RMB
drag no matter how consistent it is.

Why won't you work with me to find an alternative instead of fighting
me? If your argument is consistency there is no reason that the
solution can't be just as consistent as the current one. You act as if
we must give up consistency to gain ergonomics and discoverability and
that just isn't true!

> To be clear, those other means only require either 1. just a LMB on
> the title bar or resize corner.  2. LMB or RMB on window border
> The 1st is quite discoverable and easy to accomplish.
> The second is slightly less discoverable and slightly less easy to
> accomplish (after all, a second mouse button is needed).
> Using CTRL+ALT is even less discoverable and even more difficult to perform.
> However, there is a strong consistency between all three. That should
> be maintained.

You recognize that despite being consistent the functionality is quite
hidden, but you don't consider that to be as big an issue as me. What
is the merit of having "advanced" functionality that will not be
discovered by the vast majority of users when you could have similar
functionality that will be discovered by most users?

> Okay, on to addressing the highlighting of CTRL+ALT...
>
> (Aside from Stack and Tile) there are no instances where the window
> border becomes highlighted for window management.
> (For SAT, I cannot think of a more intuitive method to convey "these
> two parts will stick together".)
> So, let's remove the border highlighting for CTRL+ALT and replace it
> with something more descriptive.

Okay I am following you here... the borders are confusing.

> Next, let us recall that upon CTRL+ALT, the entire application window
> can receive and properly trigger a LMB, RMB. This includes the frame,
> title bar, resizer corner, window border, ...,
>
> So, upon the CTRL+ALT keypress, a grey (or some other system/user
> defined color) transparent mask could be drawn over the entire
> application window.

Yes, that sounds like a pretty good solution although I don't see why
it should be user defined, maybe use a nice light grey partially
transparent box over the window, (can we do transparency effects?)
although updating the mouse cursor might be enough.

> This will hopefully convey the entire application window is a uniform
> canvas wrt CTRL+ALT+LMB,RMB.
> That should also convey the notion of "CTRL+ALT will act differently
> than the standard window behavior".
>
> For differentiating beteween CTRL+ALT+LMB and CTRL+ALT+RMB, ...
> First, during that key press, there is no need to convey presice
> pointer location.
> After all, the entire application window will respond to a LMB, RMB.
> So this affords us the opportunity to repurpose the mouse cursor into
> a more informative role.
>
> I'm curious if it is feasible to draw two mouse cursors side by side
> at the same time.
> One (e.g., a 4 directional arrow) to convey moving the window.
> Another to convey "In this current pointer location, the window can be
> resized on the east border only".
> Obviously, that second cursor would change, depending on the location
> of the pointer.

Perhaps we could display the LMB action big in the center with the RMB
action little in the bottom right corner of the cursor. With the
previously mentioned solution of using ctrl+LMB=RMB this might be an
ideal solution.

> The positioning of these dual cursors (i.e. which one is drawn on the
> left and the right) would be dependant on the user's current mouse
> configuration (i.e., left handed vs right handed configuration).
> In the case of single button devices, only the LMB cursor would be shown.

You are right that I have been referring to the buttons as LMB for
primary and RMB as secondary assuming a right handed user, that is my
mistake, of course I meant primary and secondary not left and right,
please excuse my omission.

> I think this would make CTRL+ALT+LMB,RMB more intuitive to users,
> without destroying the current consistency of LMB and RMB behavior.

I do not wish to destroy the current consistency but I would wish
there would be a different way to accomplish this without using the
secondary mouse button. You have minimized my reasons but I stand by
them, dragging with the secondary mouse button is poor UI and should
be avoided. Let's come up with a solution that is equally consistent
but uses the primary mouse button instead.

On Mon, Jan 21, 2013 at 7:01 PM, Matt Madia <mattmadia@xxxxxxxxx> wrote:
> On 1/21/13, pulkomandy@xxxxxxxxxxxxx <pulkomandy@xxxxxxxxxxxxx> wrote:
>>> How about LMB on the border performs a move, and option key+LMB
>>> performs to a resize, good compromise?
>>
>> RMB already performs a resize. You think this is not easy to reach, and want
>>
>> to replace it with a key + LMB ? I think this is only change for the purpose
>>
>> of change now. RMB drag is easier than LMB drag + a key.
>>
>> So, we already have a good compromise.
>
> Exactly. This is why I vehemently oppose you changing the LMB or RMB
> functionality with regards to moving the window or resizing it.
> (Altering the visual appearances during CTRL+ALT is something I agree
> with and even have some suggestions further below.)
> Changing the behavior of LMB and RMB would be breaking consistency in
> order to "fix" a problem by implementing an improper solution.
>
> To put it bluntly, arguing to change behavior of LMB, RMB, CTRL+ALT on
> "poor discoverability" (or even ergonomics) is a moot point.
> By needing to control two devices (a pointer and a keyboard), CTRL+ALT
> is advanced, we cannot demand users to use it as the only or primary
> means.
> CTRL+ALT is alternative because there are other means to achieve the
> same effect.
>
> To be clear, those other means only require either 1. just a LMB on
> the title bar or resize corner.  2. LMB or RMB on window border
> The 1st is quite discoverable and easy to accomplish.
> The second is slightly less discoverable and slightly less easy to
> accomplish (after all, a second mouse button is needed).
> Using CTRL+ALT is even less discoverable and even more difficult to perform.
> However, there is a strong consistency between all three. That should
> be maintained.
>
> Okay, on to addressing the highlighting of CTRL+ALT...
>
> (Aside from Stack and Tile) there are no instances where the window
> border becomes highlighted for window management.
> (For SAT, I cannot think of a more intuitive method to convey "these
> two parts will stick together".)
> So, let's remove the border highlighting for CTRL+ALT and replace it
> with something more descriptive.
>
> Next, let us recall that upon CTRL+ALT, the entire application window
> can receive and properly trigger a LMB, RMB. This includes the frame,
> title bar, resizer corner, window border, ...,
>
> So, upon the CTRL+ALT keypress, a grey (or some other system/user
> defined color) transparent mask could be drawn over the entire
> application window.
> This will hopefully convey the entire application window is a uniform
> canvas wrt CTRL+ALT+LMB,RMB.
> That should also convey the notion of "CTRL+ALT will act differently
> than the standard window behavior".
>
> For differentiating beteween CTRL+ALT+LMB and CTRL+ALT+RMB, ...
> First, during that key press, there is no need to convey presice
> pointer location.
> After all, the entire application window will respond to a LMB, RMB.
> So this affords us the opportunity to repurpose the mouse cursor into
> a more informative role.
>
> I'm curious if it is feasible to draw two mouse cursors side by side
> at the same time.
> One (e.g., a 4 directional arrow) to convey moving the window.
> Another to convey "In this current pointer location, the window can be
> resized on the east border only".
> Obviously, that second cursor would change, depending on the location
> of the pointer.
>
> The positioning of these dual cursors (i.e. which one is drawn on the
> left and the right) would be dependant on the user's current mouse
> configuration (i.e., left handed vs right handed configuration).
> In the case of single button devices, only the LMB cursor would be shown.
>
> I think this would make CTRL+ALT+LMB,RMB more intuitive to users,
> without destroying the current consistency of LMB and RMB behavior.
>
> --mmadia
>

Other related posts: