Re: [Ayatana] What's up with all the non-resizable windows?

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefanos A. wrote on 16/10/11 15:24:
> 
>> *Some* windows are ok to resize, because for those windows, the 
>> probability that people would resize them deliberately multiplied
>> by the benefit from doing so is greater than the probability that
>> people would resize them accidentally multiplied by the pain from
>> doing so.
> 
> I disagree with the core of this assumption. If a window becomes 
> painful when resize, then that window is broken, period. It should
> be redesigned to work correctly when resized.


It may not be anything to do with the contents of the window. For
example, someone may have accidentally resized the window to cover the
whole screen, and not understand what they did. The launcher is hidden
by default when a window is nearly full-screen, and (if Windows users
are any guide) only about a quarter of users use Alt Tab[1][2], so
they may be left unable to switch windows at all until the window closes.

[1] <http://research.microsoft.com/en-us/groups/vibe/msr-vibelog-07.pdf>
[2] <http://www.pcpitstop.com/research/shortcuts.asp>

>> For other kinds of window the inequality tips the other way -- 
>> usually as a result of resizing being much less useful, and 
>> sometimes also as a result of a usability benefit from all 
>> windows of the same type always being the same size for instant 
>> recognizability (which increases the pain of resizing them by 
>> mistake, as they then become less recognizable). Examples of the 
>> former include properties windows, preference dialogs, and most 
>> individual control panels; examples of the latter include alerts 
>> and progress windows.
> 
> You can achieve instant recognizability by opening all related
> windows (e.g. alerts) at the same initial size. Your argument makes
> a huge logical jump in saying that these windows should be
> fixed-size (instead of resizable with identical initial size). If a
> user choose to resize such a window it's because she has a reason
> to do so. Disallowing this *probably* prohibits the user from doing
> something he needed to do.


You're quite right. I was counting loss of consistency as part of the
cost, but I was wrong about that part.

> Concrete example: the language support dialog that reads "The
> language support is not installed completely". This is a fixed-size
> dialog has a 2-line listbox that contains more than 10 lines of
> text, something that falls somewhere between "completely broken"
> and "impossible to use". You simply don't have enough space to
> display all necessary information - and by making the window
> non-resizable, you prohibit the user from accessing the information
> necessary for an informed decision (install / cancel). Awesome.


You'll be pleased to know I redesigned that window last week,
including a much taller language list.
<https://live.gnome.org/Design/SystemSettings/RegionAndLanguage#inline-installation>

> How should I approach these bugs? Open a single bug report about
> all non-resizable applications (and be ignored or told to file
> separate bugs?) Open a new bug report for each broken non-resizable
> application (only to be told to file upstream?) File reports
> upstream (and be told these are by design?)
> 
> ...


Engineers use bug reports to track progress in fixing bugs, so one bug
report per thing that needs fixing. Separate windows that are
inappropriately unresizable should have separate bug reports.

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6cOZIACgkQ6PUxNfU6ecoRwQCbB4avkfWK6pyTcP9IJ97XqWPA
fGAAn1HucvKjFZNQSgFWiESgESU9pJjC
=A0gr
-----END PGP SIGNATURE-----