Concerning the resizability of dialogs
John Levon
Context:
http://bugzilla.mozilla.org/show_bug.cgi?id=150251
Before I ask the questions below, I need to make some things clear.
1. I am aware of the tendency bz mentions in point 2), that resizable
dialogs encourage bad dialog design. I am talking exclusively about
point 1).
2. The reason I'm asking is because I want to understand the rationale
for this decision, not request a change in Mozilla.
Boris stated that it is Mozilla UI policy to disallow resizing for all
dialogs. This seemingly includes all the managers (e.g. form, cookies)
that have pseudo-content areas but are in fact dialogs - I can only
assume each one of these is a UI bug as a result.
Instead my question concerns dialogs such as the download status dialog
(not the manager). Given that it's perfectly reasonable for the user to
resize the dialog to see more of a URL, what are the UI justifications
for preventing this ?
What about list boxes ? Since list boxes may reasonably take a number of
items, and Mozilla is still being designed for 640x480 screens, and
scroll bars a pain, why is this problem to be left unsolved ?
I have tried to find the guideline points that Boris references, and
have only found the passing comment :
http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-132.html
I couldn't find a rationale there, or elsewhere ?
Is there somebody/somewhere that can give a rationale ?
thanks
john
Matthew Thomas
>...
> http://bugzilla.mozilla.org/show_bug.cgi?id=150251
>...
> Boris stated that it is Mozilla UI policy to disallow resizing for all
> dialogs. This seemingly includes all the managers (e.g. form, cookies)
> that have pseudo-content areas but are in fact dialogs - I can only
> assume each one of these is a UI bug as a result.
The following is copied and pasted from my resolution of the bug, with
minor corrections.
A dialog is:
* modal (sometimes it isn't, usually as a workaround for a bug -- e.g.
the Preferences dialog is non-modal to let you download more
`content packs')
* closed with the mouse by clicking a button along its bottom
* closed with the keyboard by typing Enter or Escape or (in rare
cases) access+something.
A normal window is:
* non-modal
* closed with the mouse by clicking a button in its title bar
* closed with the keyboard by typing accel+W.
These aren't the only two kinds of window in a decent GUI, but they're
the only two kinds which Mozilla's toolkit knows about. To make things
worse, Mozilla's toolkit allows you to make various wialogs/dindows
which are confusing hybrids of the two. Wherever you find such beasts,
you should file a bug to fix them. For example, the cookie manager,
forms manager, and image manager are dialogs, but they're non-modal, so
they should be normal windows with menu bars instead. (`Edit' > `Select
All' would be quite handy in most of them, for example.)
Now, *any* window (whether it's a dialog, or an ordinary window) should
be resizable if, and only if, the majority of its contents would benefit
from being resizable.
In *most* cases, but not all, this means that dialogs should *not* be
resizable. An example is the Preferences dialog, where a majority of the
dialog is taken up by radio buttons and checkboxes and stuff which don't
benefit from being resizable. A counter-example is an Open or Save
filepicker, where a majority of the dialog is taken up by a listbox
which does benefit from being resizable.
And in *most* cases, but not all, this means that ordinary windows
*should* be resizable. An example is a browser window -- it would be
pretty annoying if you couldn't resize it to see more of a page. A
counter-example is the Calculator bundled with Windows or Mac OS, where
there are a fixed number of buttons which fit in a particular size so
there's no point in ever being a different size.
So, please file bugs on individual windows which are dialogs but should
be ordinary windows, are ordinary windows but should be dialogs, are
resizable and shouldn't be, or aren't resizable and should be.
> Instead my question concerns dialogs such as the download status
> dialog (not the manager).
See, now that's one of the kinds of window which Mozilla's toolkit
doesn't have a clue about: progress windows. Mozilla fakes them using
dialogs, with the result that (a) they have the wrong kind of window
border and (b) they're not collapsible.
> Given that it's perfectly reasonable for the user to resize the dialog
> to see more of a URL, what are the UI justifications for preventing
> this ?
Because a majority of its contents -- the progress meter, the Cancel
button, the checkboxes and various buttons -- don't benefit from being resizable.
In any case, the progress `dialogs' shouldn't exist any more, since the
whole point of implementing the download manager was to eliminate them.
> What about list boxes ? Since list boxes may reasonably take a number
> of items, and Mozilla is still being designed for 640x480 screens, and
> scroll bars a pain, why is this problem to be left unsolved ?
>...
Sure. If a majority of a window is taken up by a listbox, the window
should be resizable. The various Managers fall into that category.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mpt.phrasewise.com/>
John Levon
> [snip classification]
Seems reasonable. I'm not so sure about your modality requirements
but I don't want to get into /that/ one :)
> you should file a bug to fix them. For example, the cookie manager,
> forms manager, and image manager are dialogs, but they're non-modal, so
> they should be normal windows with menu bars instead. (`Edit' > `Select
> All' would be quite handy in most of them, for example.)
This makes sense to me.
> Now, *any* window (whether it's a dialog, or an ordinary window) should
> be resizable if, and only if, the majority of its contents would benefit
> from being resizable.
I keep hearing this assertion, but only as an assertion. /Why/ ? Given
your use of the word "majority", you are admitting that there is a trade
off. I am interested in the other side of the trade off because I can't
think of a good reason to disallow resizing of any dialog, especially
one with at least one variable-geometry widget.
> benefit from being resizable. A counter-example is an Open or Save
> filepicker, where a majority of the dialog is taken up by a listbox
> which does benefit from being resizable.
I'm glad to hear that I've mis-interpreted bz's "dialogs shouldn't be
resizable" comment :)
> *should* be resizable. An example is a browser window -- it would be
> pretty annoying if you couldn't resize it to see more of a page. A
> counter-example is the Calculator bundled with Windows or Mac OS, where
> there are a fixed number of buttons which fit in a particular size so
> there's no point in ever being a different size.
Examples and counter-examples are all very well, but they don't answer
my question for the borderline cases that really matter.
> So, please file bugs on individual windows which are dialogs but should
> be ordinary windows, are ordinary windows but should be dialogs, are
> resizable and shouldn't be, or aren't resizable and should be.
Yes, there's certainly many cases where things are currently wrong in
Mozilla. It's fairly difficult for me to test these bugs though, since
resizing is not disabled at all on my Linux system :)
> See, now that's one of the kinds of window which Mozilla's toolkit
> doesn't have a clue about: progress windows. Mozilla fakes them using
> dialogs, with the result that (a) they have the wrong kind of window
> border and (b) they're not collapsible.
Can you give an example (a screenshot ?) of what Mozilla should be doing
? You call it a "progress window" - that means it /should/ be resizable,
right ?
> Because a majority of its contents -- the progress meter, the Cancel
> button, the checkboxes and various buttons -- don't benefit from being resizable.
But one of them does. Majorly. For your attitude to make sense, two
points have to be shown :
1. There has to be a significant UI disadvantage to allowing resizability
2. This disadvantage has to outweigh the convenience of being able to
resize the dialog
This is true whether the majority of the dialog is resizable, or not,
unless you intend to call anything with a variable-geometry widget a
"window" not a "dialog", which seems more like sophistry than actually
addressing the question.
> In any case, the progress `dialogs' shouldn't exist any more, since the
> whole point of implementing the download manager was to eliminate them.
Maybe when the huge UI problems with the download manager itself have
been fixed. Currently I'd be very disappointed to see that pref go away
again (and so would the bugzilla dupe rate :)
thanks
john
Sailfish
> Matthew Thomas wrote:
>
>>Now, *any* window (whether it's a dialog, or an ordinary window) should
>>be resizable if, and only if, the majority of its contents would benefit
>>from being resizable.
>>
> contains content that can grow to the point at which users want to
> resize it so they don't have to scroll. The preferences dialog contains
> several such fields, and therefore we should consider allowing it to be
> resizable. I see little reason not to allow resizing, at least on
> platforms where this is common, since users who don't try to resize it
> will be unaffected. To keep developers 'honest', it could be kept to a
> fixed size through UI freeze, or resizing allowed only in production builds.
>
I have to agree with Peter on this. I spent a considerable amount of
time hunting down the reason why the display of Preferences/Mail &
Newsgroups/Message Display section Plain Text Messages was all scrunched
up on my theme. I finally realized that it was because of the size
enforcement. It turns out that my theme uses a somewhat larget menulist
button than is normal and this was what was causing the other stuff to
be displayed badly. I ended up having to write a special selector kludge
to shrink the padding for than panel. It still doesn't look good but
it'll have to do :-(
--
Best Regards,
Pat
"Surfin' the Net...grappling with the 3rd Wave"
Got a message? Project It!? http://www.projectit.com/
John Levon
> I have to agree with Peter on this. I spent a considerable amount of
> time hunting down the reason why the display of Preferences/Mail &
> Newsgroups/Message Display section Plain Text Messages was all scrunched
> up on my theme. I finally realized that it was because of the size
> enforcement.
Hold on, are you saying that the maximum size is *hard coded* ??
I must have mis-interpreted you, surely.
john
Sailfish
privy to the internal discussions on this), this was done to prevent
option-creep from the development folks....
Peter Trudelle
Peter
Sailfish
> This was 'fixed' (in the sense of being made unchangeable) in bug 79948
> large.
>
> Peter
>
above?), the size of the dialog/window/panel/whatever shouldn't be fixed
for the theme developers. imo, if a themer wants to add chrome that
makes the panel grow then they should be allowed to. If the end-user
doesn't like the enlargement of that panel due to the added chrome then
they will either not use the theme because of it or inform the themer of
their dislike.
KaiRo - Robert Kaiser
> Hold on, are you saying that the maximum size is *hard coded* ??
In terms that it is not available to a user, yes.
In terms that it is a fixed number given in some UI [XUL] file and can't
be changed by any dynamic item, no.
1) The prefs dialog dimensions are defined in some file in locale
settings, so that transaltors can change them if their lanaguages need a
bigger size of the dialog.
2) The dimensions are specified in em, so it should dynamically resize
with different fonts used. I'm not sure what font setting this is
derived from, though.
Robert Kaiser
John Levon
> 1) The prefs dialog dimensions are defined in some file in locale
> settings, so that transaltors can change them if their lanaguages need a
> bigger size of the dialog.
>
> 2) The dimensions are specified in em, so it should dynamically resize
> with different fonts used. I'm not sure what font setting this is
> derived from, though.
Good, that's what I meant. I'm glad it's not quite that bad :)
As Peter pointed out, I don't understand why they can't be made
resizable for the user in releases only, especially since the "disallow
resizing" advocates' arguments seem to have evaporated.
regards
john
Sailfish
I don't think this helps theme designers who don't have a convenient way
to 'package' locale setting changes with their theme....
Matthew Thomas
>
> Peter Trudelle wrote:
> >
> > Matthew Thomas wrote:
> > >
> > > Now, *any* window (whether it's a dialog, or an ordinary window)
> > > should be resizable if, and only if, the majority of its contents
> > > would benefit from being resizable.
> >
> > That is your opinion.
Sure, it's my opinion. And like many trivial and semi-obvious things,
it's not described explicitly in Apple's and Microsoft's interface
guidelines. But it *is* the behavior which has been followed by Apple
and Microsoft in their operating system software, and by Apple,
Microsoft, and most other vendors in their application software, for the
past eighteen years. Now, it's possible that Apple and Microsoft asked
me for my opinion on the matter eighteen years ago, but I consider that
unlikely, since I was six years old at the time. I certainly have no
memory of such an event.
As development tools with a marginal cost of zero are distributed more
widely (distributed for no extra charge with Linux and with Mac OS X,
for example), a greater proportion of application software will be
(like Mozilla) of the free and shareware varieties. So I think interface
guidelines will need to become much more explicit, in order to talk
about things like this -- things which would be obvious to commercial
vendors who can afford more interface design expertise.
>...
> I have to agree with Peter on this. I spent a considerable amount of
> time hunting down the reason why the display of Preferences/Mail &
> Newsgroups/Message Display section Plain Text Messages was all
> scrunched up on my theme. I finally realized that it was because of
> the size enforcement. It turns out that my theme uses a somewhat
> larget menulist button than is normal and this was what was causing
> the other stuff to be displayed badly.
That's a deliberate themeability bug: a Mozilla theme shouldn't be able
to change the size of controls like that (indeed, native themes don't
change the size of controls on either Windows or Mac OS), but it can.
The bug exists for a good reason, however -- the Classic theme needs to
imitate different platforms which have differently-sized controls,
because Mozilla's GUI is written to work on multiple platforms. That
multi-platform GUI is, ultimately, another deliberate bug -- perpetrated
in order to maximize the number of supported platforms for the least
possible development effort, at the expense of usability.
So as not to beat a dead horse, I should point out that I agree with the
existence of those last two bugs. If it weren't for the cross-platform
GUI, I wouldn't be able to use Mozilla at all. And if it weren't for the
Classic theme having properly sized controls, I'd be able to use
Mozilla, but it would be very eye-watering. But I *don't* agree with
silly propositions which people try to attach to the coat-tails of those
bugs -- silly propositions like making the Preferences dialog resizable
for non-Classic theme reasons.
Matthew Thomas
>
> Matthew Thomas wrote:
>...
> > Now, *any* window (whether it's a dialog, or an ordinary window)
> > should be resizable if, and only if, the majority of its contents
> > would benefit from being resizable.
>
> I keep hearing this assertion, but only as an assertion. /Why/ ? Given
> your use of the word "majority", you are admitting that there is a
> trade off. I am interested in the other side of the trade off because
> I can't think of a good reason to disallow resizing of any dialog,
> especially one with at least one variable-geometry widget.
For three reasons.
(1) Making a window resizable results in a grippy appearing in the
bottom right corner, which looks extremely ugly given the design of
most windows which don't have scrollbars or status bars
<http://bugzilla.mozilla.org/attachment.cgi?id=34722>.
(2) It increases the probability of getting into an unusable state --
someone accidentally resizing the window to be far too large, and
not realizing how they did it -- for very little benefit. For a
similar example, see Joel Spolsky's discussion of the resizable
Windows taskbar
<http://joelonsoftware.com/uibook/chapters/fog0000000059.html>.
(Microsoft would have been better to make the taskbar resizable
only if a modifier key was being held down. But that solution
wouldn't work for windows, since the taskbar is a unique control
which can have unique behavior like that, while windows are not.)
(3) It's inconsistent with the whole of the rest of the operating
system, and inconsistent with most other third-party software. Of
course, Microsoft, Apple, and other vendors have been following the
behavior I described earlier, for the past eighteen years, mainly
because of reasons (1) and (2) -- but that doesn't stop being
consistent with them from being a valid reason in itself. (If you're
using Linux, of course, it's true that this consistency doesn't
apply, but it's also true that you can hack your window manager to
make everything resizable if you're feeling particularly
rebellious.)
>...
> Examples and counter-examples are all very well, but they don't answer
> my question for the borderline cases that really matter.
What borderline cases do you have in mind? (The bug which started this
thread, the Preferences dialog, certainly isn't a borderline case -- a
large majority of its panels wouldn't benefit from being resized.)
>...
> > See, now that's one of the kinds of window which Mozilla's toolkit
> > doesn't have a clue about: progress windows. Mozilla fakes them
> > using dialogs, with the result that (a) they have the wrong kind of
> > window border and (b) they're not collapsible.
>
> Can you give an example (a screenshot ?) of what Mozilla should be
> doing ?
* <http://mackido.com/Interface/Copy/copy.gif>
* <http://mackido.com/Interface/Copy/wincopy.gif>
> You call it a "progress window" - that means it /should/ be
> resizable, right ?
No, a progress window is never resizable -- at least, I've never seen
one which is. (Sometimes a progress window expands and contracts based
on the state of a disclosure triangle; but that's to show/hide extra
controls, *not* to change the size of any of the controls.)
>...
> 1. There has to be a significant UI disadvantage to allowing
> resizability
>
> 2. This disadvantage has to outweigh the convenience of being able to
> resize the dialog
As described above.
> This is true whether the majority of the dialog is resizable, or not,
> unless you intend to call anything with a variable-geometry widget a
> "window" not a "dialog", which seems more like sophistry than actually
> addressing the question.
If so, it's your sophistry, not mine. Whether something is a window or a
dialog was described in my earlier message, and it has absolutely
nothing to do with whether it contains a `variable-geometry widget'.
> > In any case, the progress `dialogs' shouldn't exist any more, since
> > the whole point of implementing the download manager was to
> > eliminate them.
>
> Maybe when the huge UI problems with the download manager itself have
> been fixed. Currently I'd be very disappointed to see that pref go
> away again (and so would the bugzilla dupe rate :)
>...
Two of the `Tends to Suck' syndromes at work here. #7: `Where volunteers
are involved, however, it's much more likely that the project maintainer
will agree to add a user preference for the issue in question, in return
for the continued efforts of that contributor.' And #9: `When something
has an inefficient design, people get used to the inefficiency, and
complain when it becomes efficient.'
Sailfish
> Sailfish wrote:
<snip/>
>>...
>>I have to agree with Peter on this. I spent a considerable amount of
>>time hunting down the reason why the display of Preferences/Mail &
>>Newsgroups/Message Display section Plain Text Messages was all
>>scrunched up on my theme. I finally realized that it was because of
>>the size enforcement. It turns out that my theme uses a somewhat
>>larget menulist button than is normal and this was what was causing
>>the other stuff to be displayed badly.
>
> existence of those last two bugs. If it weren't for the cross-platform
> GUI, I wouldn't be able to use Mozilla at all. And if it weren't for the
> Classic theme having properly sized controls, I'd be able to use
> Mozilla, but it would be very eye-watering. But I *don't* agree with
> silly propositions which people try to attach to the coat-tails of those
> for non-Classic theme reasons.
>
Ewell! Bad hair day?
Anyway, in my particular case, the only "non-Classic" theme modification
done which caused this "scrunch" problem was that the menulist button
was define with a little extra (a few pixels!) padding to give it a bit
more pronounced look. Hardly something a dialog panel shouldn't be able
to accomodate, imo.
John Levon
> (1) Making a window resizable results in a grippy appearing in the
> bottom right corner, which looks extremely ugly given the design of
> most windows which don't have scrollbars or status bars
> <http://bugzilla.mozilla.org/attachment.cgi?id=34722>.
Giving an example of mis-managed geometry doesn't prove anything. If I
show you a picture of a dialog with a resize grippy that /doesn't/ look
a mess, does that prove /my/ point ? Of course not.
> (2) It increases the probability of getting into an unusable state --
> someone accidentally resizing the window to be far too large, and
> not realizing how they did it -- for very little benefit. For a
> similar example, see Joel Spolsky's discussion of the resizable
> Windows taskbar
> <http://joelonsoftware.com/uibook/chapters/fog0000000059.html>.
Strange, I'm not talking about resizable/dockable toolbars. I wonder why
you think that example is relevant.
Your argument holds equally well with the resizability of content
windows. It is just as easy to resize the window to be too large, and
not know how you did it. So I discount this point too, unless you intend
to remove resizability for all windows.
The benefit is not little: that is you once again making the same
assertion, without justification.
> (3) It's inconsistent with the whole of the rest of the operating
> system, and inconsistent with most other third-party software.
The consistency argument is the strongest one you have made, but it's a
meaningless one, simply because Mozilla's interface looks and behaves
nothing like any other application. Therefore, using your "consistency
distance" rule, it should be more consistent with itself, than with the
platform. Fix the 100,000 other platform consistency bugs first, then
you can start removing useful features for the sake of consistency, ok ?
If we were talking about Chimera, then platform consistency would
certainly override the convenience.
> * <http://mackido.com/Interface/Copy/wincopy.gif>
Does this resize itself based on the filename length ? What happens
when the filename is as long as the width of the screen ?
>> Maybe when the huge UI problems with the download manager itself have
>> been fixed. Currently I'd be very disappointed to see that pref go
>> away again (and so would the bugzilla dupe rate :)
>>...
>
> Two of the `Tends to Suck' syndromes at work here. #7: `Where volunteers
> are involved, however, it's much more likely that the project maintainer
> will agree to add a user preference for the issue in question, in return
> for the continued efforts of that contributor.' And #9: `When something
> has an inefficient design, people get used to the inefficiency, and
> complain when it becomes efficient.'
Are you seriously saying that the download manager is more efficient ? A
dialog (sorry, window) that needs resizing from the default to show the
percentage of a download ? That needs scrolling when you start to
download a file just to /see the progress/ of what you requested ? That
is slow, and has no facility to automatically remove downloads ?
The download manager UI should never have landed in its current state,
so it is no wonder that the pref got put back (I'd have been happier to
see it removed again instead.)
(And yes, we've all read your article)
regards
john
Matthew Thomas
>...
> Peter, thx for the reference. However (and I believe you stated it
> above?), the size of the dialog/window/panel/whatever shouldn't be
> fixed for the theme developers. imo, if a themer wants to add chrome
Syndrome #11 strikes again. A theme can only change the theme; it
*can't* add chrome, for *any* purpose. That's why you can't put a
Home button on the main toolbar just by theming the toolbar, remember?
> that makes the panel grow then they should be allowed to.
If themers were allowed to change chrome at all, it would be a security
bug. An innocent-looking theme could replace the Reload button with a
Reload-and-then-secretly-send-my-browser-history-to-EvilCompany.com
button, for example.
> If the
> end-user doesn't like the enlargement of that panel due to the added
> chrome then they will either not use the theme because of it or inform
> the themer of their dislike.
>...
If the fixed size of the Preferences dialog in Mozilla disturbs you as a
themer, you're welcome to use WindowBlinds or Kaleidoscope to theme a
different browser. Like Internet Explorer, for example.
Errrr ... hang on. The Preferences dialog in Internet Explorer is of
fixed size.
Ok, Netscape 4.79 then?
Nope, Communicator's prefs dialog is fixed size too.
Opera?
Fixed size. (Opera might be crazy, but it's not *that* crazy.)
iCab?
La la la, fixed size.
Well, dang. Looks like you'll have to write your own WonkyBrowser. :-)
Sailfish
Matthew, either I'm not being clear or you're intentionally missing the
point. Allow me to restate the facts, as I know them.
1. The Preference panel size was set "fixed" primarily as a crude, yet
effective, way to inhibit option-creep from the development folks.
2. The size of the Preference dialog panel is not an industry standard
but some arbitrary size based on the options that now exist in Moz (and
perhaps other factors.)
3. There is no technical inhibition that prevents the Preference panel
from being able to re-size in the production release.
4. Theme writers are encouraged to exploit the styles of the existing
widgets using standard CSS and -moz stylesheet methods.
While I can accept (even understand) the reasoning for imposing the
limit at the Moz development end because of step 1, I believe to enforce
that limit on theme writers whose kewl widget style may extend beyond
the current panel dialog is an inhibition without reason. Why?
1. If a particular theme ends up defining widgets which cause the
Preference panel to balloon to an unusable size (hardly likely but for
the sake of the argument..) then the users of that theme will rightly
blame the theme developer and NOT Moz.
2. When a theme developer develops styles for widgets there's an
implicit expectation that the window/dialog/whatever will
expand/contract in order to accomodate the styles (within reason,
surely.) This is a characteristic MOZ should insure for a theme
developer, since its unreasonable for them to know every place a
particular widget might present itself and (even if one knew) have to
test ALL those places every time they make a style change to insure it
doesn't break something in some arbitrarily post-release hard-coded
dialog/window box.
If I've stated the facts correctly, then it seems that forcing a fixed
size Preference panel in the production release is more an autocratic
decision than one based on reason, no?
Lastly, I'm not arguing the user-resize option; although, I believe a
case is being made for that from another?
Neil
> hen a theme developer develops styles for widgets there's an implicit
> expectation that the window/dialog/whatever will expand/contract in
> order to accomodate the styles (within reason, surely.)
Unfortunately this doesn't work for <pane>s such as in wizards or of
course Preferences.
--
Warning: May contain traces of nuts.
Sailfish
> Sailfish wrote:
>
>> hen a theme developer develops styles for widgets there's an implicit
>> expectation that the window/dialog/whatever will expand/contract in
>> order to accomodate the styles (within reason, surely.)
>
>
> Unfortunately this doesn't work for <pane>s such as in wizards or of
> course Preferences.
>
So I've noticed :_)
Felix Miata
> John Levon wrote:
> > Matthew Thomas wrote:
> > > Now, *any* window (whether it's a dialog, or an ordinary window)
> > > should be resizable if, and only if, the majority of its contents
> > > would benefit from being resizable.
> > I keep hearing this assertion, but only as an assertion. /Why/ ? Given
> > your use of the word "majority", you are admitting that there is a
> > trade off. I am interested in the other side of the trade off because
> > I can't think of a good reason to disallow resizing of any dialog,
> > especially one with at least one variable-geometry widget.
> For three reasons.
> (1) Making a window resizable results in a grippy appearing in the
> bottom right corner, which looks extremely ugly given the design of
> most windows which don't have scrollbars or status bars
> <http://bugzilla.mozilla.org/attachment.cgi?id=34722>.
Give me full functionality over a trivial cosmetic blemish any day.
Resizable windows did not always have grippies. They don't need them to
be resizable either.
> (2) It increases the probability of getting into an unusable state --
> someone accidentally resizing the window to be far too large, and
> not realizing how they did it -- for very little benefit.
A legitimate concern, but one with low real world risk.
> (3) It's inconsistent with the whole of the rest of the operating
> system, and inconsistent with most other third-party software. Of
> course, Microsoft, Apple, and other vendors have been following the
> behavior I described earlier, for the past eighteen years, mainly
> because of reasons (1) and (2) -- but that doesn't stop being
> consistent with them from being a valid reason in itself. (If you're
> using Linux, of course, it's true that this consistency doesn't
> apply, but it's also true that you can hack your window manager to
> make everything resizable if you're feeling particularly
> rebellious.)
It's my PC, not that of some programmer. Just like with stupid web
pages, the ability to override stupid page/app behaviors should be
maximized in whatever way practical.
> > Examples and counter-examples are all very well, but they don't answer
> > my question for the borderline cases that really matter.
> What borderline cases do you have in mind? (The bug which started this
> thread, the Preferences dialog, certainly isn't a borderline case -- a
> large majority of its panels wouldn't benefit from being resized.)
That a large majority wouldn't really isn't the issue. That only one
would is sufficient. I filed a bug on one, and have seen at least one
other.
--
"It is impossible to rightly govern the world without God and the
Bible." George Washington
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://mrmazda.members.atlantic.net/
Matthew Thomas
>...
> Giving an example of mis-managed geometry doesn't prove anything. If I
> show you a picture of a dialog with a resize grippy that /doesn't/
> look a mess, does that prove /my/ point ? Of course not.
No it doesn't, because for the third time, windows versus dialogs is not
the issue. Resizable versus non-resizable is the issue.
> > (2) It increases the probability of getting into an unusable state
> > -- someone accidentally resizing the window to be far too large,
> > and not realizing how they did it -- for very little benefit.
> > For a similar example, see Joel Spolsky's discussion of the
> > resizable Windows taskbar
> > <http://joelonsoftware.com/uibook/chapters/fog0000000059.html>.
>
> Strange, I'm not talking about resizable/dockable toolbars. I wonder
> why you think that example is relevant.
As with the Preferences dialog, it's an example of something which has
an unreasonable probability of getting into an unusable state -- someone
accidentally resizing it to be far too large, and not realizing how they
did it -- for very little benefit.
> Your argument holds equally well with the resizability of content
> windows.
No it doesn't, because with a document window, you're much more likely
to *want* it to be a size which is different from its current size.
Because for a document window, a majority of the window (i.e. the
content area) benefits from being resizable. Which is, you may remember,
the rule I gave in the first place.
>...
> > (3) It's inconsistent with the whole of the rest of the operating
> > system, and inconsistent with most other third-party software.
>
> The consistency argument is the strongest one you have made, but it's
> a meaningless one, simply because Mozilla's interface looks and
> behaves nothing like any other application.
Really? What build are you using? It sounds like you've got some pretty
serious bugs in it. Most nightlies I download look very much like other
applications, especially Netscape 4.x.
There are some minor respects in which Mozilla doesn't behave like other
applications. For example, Mozilla's option menus open below their
button, which is annoying -- both because it's inefficient, and because
in almost every other Mac application (and in most Linux applications)
option menus open on top of their button. But problems like that are
filed as bugs, because that's exactly what they are.
> Therefore, using your
> "consistency distance" rule, it should be more consistent with itself,
> than with the platform.
You have it nearly right. It's more *important* to be consistent with
the rest of the program than with the rest of the platform. But if
possible, and if it's not extremely detrimental to do so, it's best to
be consistent both with the rest of the program *and* with the rest of
the platform. Most programs achieve that, and Mozilla can too.
> Fix the 100,000 other platform consistency
> bugs first,
Like I said in response to Sailfish, the existence of one bug generally
doesn't excuse the existence of another.
> then you can start removing useful features for the sake
> of consistency, ok ?
I'm not removing it. As for usefulness, the usefulness of any design
detail needs to be weighed against the clutter, inconsistency, and risk
of confusion which it would cause. Making the Preferences dialog
resizable would be particularly diabolical, in that it would increase
clutter, inconsistency, *and* risk of confusion, all at the same time.
> If we were talking about Chimera, then platform consistency would
> certainly override the convenience.
Why would it apply to Chimera, and not to Mozilla? Remember, Mozilla on
OS X uses native-looking controls.
> > * <http://mackido.com/Interface/Copy/wincopy.gif>
>
> Does this resize itself based on the filename length ?
No. It's the same width as every other progress window in Windows
Explorer. That has the additional benefit that you can tell by its size
that it's a progress window, without even looking at its contents. (The
same applies to progress windows in the Mac OS Finder and in Netscape
4.x for Mac, which are all the same size, though not the same size as
progress windows in Windows.)
> What happens
> when the filename is as long as the width of the screen ?
It gets ellipsized. (That would only happen if the filename was longer
than about 100 characters, which is hardly ever the case.)
>...
> Are you seriously saying that the download manager is more efficient ?
If it was implemented properly, yes it would be. You wouldn't have a
multitude of progress windows flapping about, the browser window
wouldn't keep losing focus, and you could see (and, if necessary,
re-enact) previous downloads in a single place.
> A dialog (sorry, window) that needs resizing from the default to show
> the percentage of a download ?
Bug.
> That needs scrolling when you start to
> download a file just to /see the progress/ of what you requested ?
Bug.
> That is slow, and has no facility to automatically remove downloads ?
Bug.
> The download manager UI should never have landed in its current state,
That may well be true.
> so it is no wonder that the pref got put back
No wonder, but no excuse either.
> (I'd have been happier
> to see it removed again instead.)
>...
Precisely. Don't pref it; either fix it or remove it.
Matthew Thomas
>...
> Matthew, either I'm not being clear or you're intentionally missing
> the point. Allow me to restate the facts, as I know them.
>
> 1. The Preference panel size was set "fixed" primarily as a crude, yet
> effective, way to inhibit option-creep from the development folks.
That is true. However, that is perhaps the least important reason for it
to remain fixed.
> 2. The size of the Preference dialog panel is not an industry standard
> but some arbitrary size based on the options that now exist in Moz
> (and perhaps other factors.)
The Preferences dialog is as large as it can possibly be, while still
fitting completely on the screen, without overlapping the taskbar in
Windows, the menu bar in Mac OS, or an ordinary-sized Panel in GNOME or KDE.
It is considerably larger than the Preferences dialog was in Netscape
4.x, which in turn was considerably larger than the Preferences dialogs
in most other programs.
> 3. There is no technical inhibition that prevents the Preference panel
> from being able to re-size in the production release.
That is true. I frequently see people such as yourself making that
mistake -- thinking that something being *easy* to do has any bearing on
whether it would be *right* to do. Module owners (and Bugzilla component
owners) repeatedly have to correct such people.
>...
> 2. When a theme developer develops styles for widgets there's an
> implicit expectation that the window/dialog/whatever will
> expand/contract in order to accomodate the styles (within reason,
> surely.)
Within reason, definitely. However, to do that for the Preferences
dialog, Mozilla would need to mentally lay out all the panels, to find
the width of the widest one and the height of the tallest one.
Mozilla is slow enough at laying out one panel, but the current
Preferences dialog (not counting the Debug section) contains *40*
panels. If Mozilla had to lay out 40 panels before opening the dialog,
we'd be waiting for *minutes*.
(Personally, I think that having any more than about 12 preference
panels shows that Mozilla's preferences are way out of control; but the
same problem with calculating the size would cause a frustrating delay
even with 12 panels.)
> This is a characteristic MOZ should insure for a theme
> developer,
Sorry. As I said in the `Navigator chrome review' thread, making life
easier for theme developers is not nearly as important as making Mozilla
usable. Themes are just a frilly extra, and users outnumber theme
developers by a ratio of about a million to one.
Sailfish
> The Preferences dialog is as large as it can possibly be, while still
> fitting completely on the screen, without overlapping the taskbar in
> Windows, the menu bar in Mac OS, or an ordinary-sized Panel in GNOME or KDE.
I'm not sure that means anything. By definition, a Preference panel is
something that is open only for the duration it takes to set some option
and then closed, i.e., even if it does obscure some other opsys bars on
lo-res monitors, its not like they would be using them while they're
setting a preference anyway, imo.
> That is true. I frequently see people such as yourself making that
> mistake -- thinking that something being *easy* to do has any bearing on
> whether it would be *right* to do. Module owners (and Bugzilla component
> owners) repeatedly have to correct such people.
I wasn't arguing that, merely insuring that it wasn't an obstacle.
> Within reason, definitely. However, to do that for the Preferences
> dialog, Mozilla would need to mentally lay out all the panels, to find
> the width of the widest one and the height of the tallest one.
That's all I've been asking for. Hey, how about this as a compromise?
Allow the Preference panel to expand by, say, 10% to accommodate
external factors?
> Sorry. As I said in the `Navigator chrome review' thread, making life
> easier for theme developers is not nearly as important as making Mozilla
> usable. Themes are just a frilly extra, and users outnumber theme
> developers by a ratio of about a million to one.
You still don't seem to get it. Forget about theme developers for a
minute. For that matter, forget about the stinking Preference panel.
What I'm talking about is a general philosophy for any panel, window,
dialog that is made available for customization. Allowing some room for
expansion on each of these seems like a logical thing to do, imo.
John Levon
>> Giving an example of mis-managed geometry doesn't prove anything. If I
>> show you a picture of a dialog with a resize grippy that /doesn't/
>> look a mess, does that prove /my/ point ? Of course not.
>
> No it doesn't, because for the third time, windows versus dialogs is not
> the issue. Resizable versus non-resizable is the issue.
I can't parse this as a response to what I said. Again, giving some
example of some screwed up geometry proves nothing.
>> Strange, I'm not talking about resizable/dockable toolbars. I wonder
>> why you think that example is relevant.
>
> As with the Preferences dialog, it's an example of something which has
> an unreasonable probability of getting into an unusable state -- someone
> accidentally resizing it to be far too large, and not realizing how they
> did it -- for very little benefit.
An assertion.
>> Your argument holds equally well with the resizability of content
>> windows.
>
> No it doesn't, because with a document window, you're much more likely
> to *want* it to be a size which is different from its current size.
> Because for a document window, a majority of the window (i.e. the
> content area) benefits from being resizable. Which is, you may remember,
> the rule I gave in the first place.
Logic error !
(a) Windows are OK to resize because I want to resize them. So that
makes it impossible for them to be resized "too large".
(b) However for dialogs (this "majority" crap or not) I don't want to
resize them, so allowing it would allow the possibility of me resizing
them to be too large.
This is the argument you've just made. Unfortunately, the desire to
resize dialogs is exactly what we're arguing about, so assuming that I
don't want to do that in point (b) is completely nonsensical. And
further, the conclusion from the premise in point (b) doesn't follow.
And further, the conclusion from the premise in point (a) doesn't follow
either.
And you're doing a fine job of restating your "majority" "argument"
without backing it up at all.
> Really? What build are you using? It sounds like you've got some pretty
> serious bugs in it. Most nightlies I download look very much like other
> applications, especially Netscape 4.x.
>
> There are some minor respects in which Mozilla doesn't behave like other
> applications.
You've got to be kidding. There are thousands of platform consistency bugs.
I'm flabbergasted somebody who has categorised Mozilla as unusable
(utter hyperbole: it may be bad, it's not that bad) would brush this
issue aside so easily.
> You have it nearly right. It's more *important* to be consistent with
> the rest of the program than with the rest of the platform. But if
> possible, and if it's not extremely detrimental to do so, it's best to
> be consistent both with the rest of the program *and* with the rest of
> the platform. Most programs achieve that, and Mozilla can too.
Yes, fair point, I think. I accept this.
> I'm not removing it. As for usefulness, the usefulness of any design
> detail needs to be weighed against the clutter, inconsistency, and risk
> of confusion which it would cause. Making the Preferences dialog
> resizable would be particularly diabolical, in that it would increase
> clutter, inconsistency, *and* risk of confusion, all at the same time
>> What happens
>> when the filename is as long as the width of the screen ?
>
> It gets ellipsized. (That would only happen if the filename was longer
> than about 100 characters, which is hardly ever the case.)
Unfortunately it's extremely common with URLs. Of course the download
manager (one assumes) will eventually avoid this particular case, but
it's the most visible and obvious case.
>> Are you seriously saying that the download manager is more efficient ?
>
> If it was implemented properly, yes it would be. You wouldn't have a
> multitude of progress windows flapping about, the browser window
> wouldn't keep losing focus, and you could see (and, if necessary,
> re-enact) previous downloads in a single place.
I'm quite sure you're right. However, you haven't answered my question.
Are you seriously saying that the download manager /is/ more efficient ?
You're implicitly saying "no" here, it seems.
>> (I'd have been happier
>> to see it removed again instead.)
>
> Precisely. Don't pref it; either fix it or remove it.
I'm glad you agree; it's a pity the module owner doesn't.
regards
john
Felix Miata
> John Levon wrote:
> > What happens
> > when the filename is as long as the width of the screen ?
> It gets ellipsized. (That would only happen if the filename was longer
> than about 100 characters, which is hardly ever the case.)
Isn't the right question whether the URL was longer than 100?
ftp://ftp.netscape.com/pub/communicator/english/4.79/windows/windows95_or_nt/complete_install/cc32d479.exe
John Levon
> Mozilla is slow enough at laying out one panel, but the current
> Preferences dialog (not counting the Debug section) contains *40*
> panels. If Mozilla had to lay out 40 panels before opening the dialog,
> we'd be waiting for *minutes*.
Bug.
john
p.s. do you understand now that replying "bug" does not resolve an issue ?
John Levon
> I'm not sure that means anything. By definition, a Preference panel is
> something that is open only for the duration it takes to set some option
> and then closed, i.e., even if it does obscure some other opsys bars on
> lo-res monitors, its not like they would be using them while they're
> setting a preference anyway, imo.
Any application obscuring such things is buggy (but in fact this is
something that should be enforced the window manager, or equivalent).
> That's all I've been asking for. Hey, how about this as a compromise?
> Allow the Preference panel to expand by, say, 10% to accommodate
> external factors?
That's no kind of compromise at all.
regards
john
Sailfish
> Sailfish wrote:
>
>> I'm not sure that means anything. By definition, a Preference panel is
>> something that is open only for the duration it takes to set some
>> option and then closed, i.e., even if it does obscure some other opsys
>> bars on lo-res monitors, its not like they would be using them while
>> they're setting a preference anyway, imo.
>
>
> Any application obscuring such things is buggy (but in fact this is
> something that should be enforced the window manager, or equivalent).
I disagree. What about folks who still use 320x240 (CGI) monitors? At
some point software needs to de-support older hardware. I don't think
the preference panel obscures any system toolbars at 800x600 dpi which
seems like the minimum target that Moz (or any other program) should be
shooting for, imo.
>> That's all I've been asking for. Hey, how about this as a compromise?
>> Allow the Preference panel to expand by, say, 10% to accommodate
>> external factors?
>
> That's no kind of compromise at all.
Please explain?
All I'm saying is that any object that a software program makes
available to external manipulation should allow some "wiggle-room" for
unforeseens. Otherwise, don't make it available, imo.
John Levon
> I disagree. What about folks who still use 320x240 (CGI) monitors? At
> some point software needs to de-support older hardware. I don't think
> the preference panel obscures any system toolbars at 800x600 dpi which
> seems like the minimum target that Moz (or any other program) should be
> shooting for, imo.
It was decided some time ago that 640x480 is the minimum iirc.
e.g.
http://bugzilla.mozilla.org/show_bug.cgi?id=117027
regards
john
Sailfish
John, thanks for the reference and, in fact, I did noticed that the
Preference panel barely fits into the screen at that resolution.
I won't get into the debate as to whether this is the best low-water
resolution mark (I've made my opinion known) but I will reiterate that I
do not believe that the lo-res panel issue is relevent to my point. That
is, that all objects that Mozilla makes available for external
manipulation should allow a degree of "wiggle-room" in them.
fwiw...
John Levon
> I won't get into the debate as to whether this is the best low-water
> resolution mark (I've made my opinion known) but I will reiterate that I
> do not believe that the lo-res panel issue is relevent to my point. That
> is, that all objects that Mozilla makes available for external
> manipulation should allow a degree of "wiggle-room" in them.
Not at all, the dialogs should size themselves appropriately: this is
completely independent of any argument concerning user resizability.
Then if your theme causes the dialog to not fit in 640x480, then it is a
bug in your theme.
The fact that Mozilla's toolkit is incapable of doing multi-paned layout
for e.g. the preferences dialog is the bug that should be fixed, as far
as I can see.
regards
john
Sailfish
> Sailfish wrote:
>
>> I won't get into the debate as to whether this is the best low-water
>> resolution mark (I've made my opinion known) but I will reiterate that
>> I do not believe that the lo-res panel issue is relevent to my point.
>> That is, that all objects that Mozilla makes available for external
>> manipulation should allow a degree of "wiggle-room" in them.
>
>
> Not at all, the dialogs should size themselves appropriately: this is
> completely independent of any argument concerning user resizability.
Agreed.
> Then if your theme causes the dialog to not fit in 640x480, then it is a
> bug in your theme.
Also agreed.
> The fact that Mozilla's toolkit is incapable of doing multi-paned layout
> for e.g. the preferences dialog is the bug that should be fixed, as far
> as I can see.
I'm not sure I understand the "multi-paned" layout reference correctly
by overall, I also agree.
It seems we are in general agreement on this issue, no?
barney
>
> Not at all, the dialogs should size themselves appropriately: this is
> completely independent of any argument concerning user resizability.
I agree with this, in theory, however there are still open bugs about
prefs panels with content that doesn't fit. Some of these have been
open since the prefs windows first became non-resizable. Curious why
these have been outstanding for so long. Is this not just as bad (or
even worse) as "accidentally" resizing a window so as to become unusable?
John Levon
> I agree with this, in theory, however there are still open bugs about
> prefs panels with content that doesn't fit. Some of these have been
> open since the prefs windows first became non-resizable. Curious why
> these have been outstanding for so long. Is this not just as bad (or
> even worse) as "accidentally" resizing a window so as to become unusable?
It is /far/ worse. They're outstanding for the same reason every other
bug is outstanding: it hasn't been fixed yet.
I know that's almost a tautology, but it's certainly the case.
regards
john
John Levon
> I'm not sure I understand the "multi-paned" layout reference correctly
> by overall, I also agree.
I'm referring to mpt's comment that Mozilla's toolkit layout is so slow
it would take minutes to layout something like the prefs dialog.
> It seems we are in general agreement on this issue, no?
If you're retracting your wish for some "slop" in resizing, then yes.
regards
john
Sailfish
> If you're retracting your wish for some "slop" in resizing, then yes.
Amazing. There's no better thread segment proving the limitations of the
written word, imo. To answer your question, "No. Not at all."
Matthew Thomas
>
> Matthew Thomas wrote:
>...
> > has an unreasonable probability of getting into an unusable state --
> > someone accidentally resizing it to be far too large, and not
> > realizing how they did it -- for very little benefit.
>
> An assertion.
That's right. To be clear, I'm not arguing that the lack of resizability
in the Preferences dialog *shouldn't* be changed; I'm explaining why it
*won't* be changed. (And yes, I just checked with the relevant module
owner.) While I'm trying to make the explanation as simple as possible,
whether you understand it is unlikely to make any difference to Mozilla.
This is purely a public service on my part. :-)
> > > Your argument holds equally well with the resizability of content
> > > windows.
> >
> > No it doesn't, because with a document window, you're much more
> > likely to *want* it to be a size which is different from its current
> > size. Because for a document window, a majority of the window (i.e.
> > the content area) benefits from being resizable. Which is, you may
> > remember, the rule I gave in the first place.
>
> Logic error !
>
> (a) Windows are OK to resize because I want to resize them.
No. *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. (The same
inequality, generalized, should apply to anything which a program allows
a user to do.)
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.
> So that
> makes it impossible for them to be resized "too large".
That's not particularly relevant to this discussion, but no, that's
wrong too. Even when a window is resizable, resizing it larger than the
entire display is something which isn't very useful (decreasing the
probability that you want to do it deliberately), *and* something which
is quite difficult to undo (increasing the pain of doing it
accidentally). That's why most window managers make that impossible (or,
if not impossible, very difficult) to do.
> (b) However for dialogs (this "majority" crap or not) I don't want to
> resize them,
You may indeed want to resize them, but you are part of a tiny minority.
(Which is why most software vendors use non-resizable windows so often,
and your calling them `crap' is unlikely to make any difference.)
> so allowing it would allow the possibility of me resizing
> them to be too large.
>
> This is the argument you've just made.
No, it's a straw man, some parts of which you excerpted from my
argument, and some parts of which you made up completely yourself.
> Unfortunately, the desire to
> resize dialogs is exactly what we're arguing about, so assuming that I
> don't want to do that in point (b) is completely nonsensical.
I'm not assuming that *you* don't want to do that, I'm judging that 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. That is
true for some windows, and for some dialogs, but not for others.
> And
> further, the conclusion from the premise in point (b) doesn't follow.
> And further, the conclusion from the premise in point (a) doesn't
> follow either.
Huh? Even disregarding the straw man nature of the argument, if it
contains a necessary point (b), of course the conclusion doesn't follow
just from the premise in point (a).
> And you're doing a fine job of restating your "majority" "argument"
> without backing it up at all.
I don't need to. Apple, Microsoft, Macromedia, Adobe, and other vendors
(including Netscape, up till now) have done it quite well already.
>...
> > There are some minor respects in which Mozilla doesn't behave like
> > other applications.
>
> You've got to be kidding. There are thousands of platform consistency
> bugs.
Thousands, I doubt. A couple of hundred, perhaps. I've filed a fair few
of them.
> I'm flabbergasted somebody who has categorised Mozilla as unusable
> (utter hyperbole: it may be bad, it's not that bad) would brush this
> issue aside so easily.
You were trying to use it as an excuse to make Mozilla even *less*
platform-consistent, so it was pretty much a red herring.
>...
> > > Are you seriously saying that the download manager is more
> > > efficient ?
> >
> > If it was implemented properly, yes it would be. You wouldn't have a
> > multitude of progress windows flapping about, the browser window
> > wouldn't keep losing focus, and you could see (and, if necessary,
> > re-enact) previous downloads in a single place.
>
> I'm quite sure you're right. However, you haven't answered my
> question. Are you seriously saying that the download manager /is/ more
> efficient ?
>...
No. It's never done anything at all, for me, except take up space in the
`Tools' menu. No download ever gets shown in it. So, no, I don't think
it's being efficient at all. :-)
Matthew Thomas
>
> Matthew Thomas wrote:
>
> > The Preferences dialog is as large as it can possibly be, while
> > still fitting completely on the screen, without overlapping the
> > taskbar in Windows, the menu bar in Mac OS, or an ordinary-sized
> > Panel in GNOME or KDE.
>
> I'm not sure that means anything. By definition, a Preference panel is
> something that is open only for the duration it takes to set some
> option and then closed, i.e., even if it does obscure some other opsys
> bars on lo-res monitors,
No, we couldn't do that even if we wanted to. In Windows and Mac OS, at
least (I can't remember what happens in GNOME and KDE), the dialog
wouldn't cover the taskbar or menu bar; they would cover the dialog.
They're always on top. (The same goes for the Dock in OS X, which causes
grief for OS X users since the Dock is so damn tall.)
> its not like they would be using them while
> they're setting a preference anyway, imo.
If they're copying and pasting settings from another program into the
dialog, they sure will.
>...
> > Within reason, definitely. However, to do that for the Preferences
> > dialog, Mozilla would need to mentally lay out all the panels, to
> > find the width of the widest one and the height of the tallest one.
>
> That's all I've been asking for. Hey, how about this as a compromise?
> Allow the Preference panel to expand by, say, 10% to accommodate
> external factors?
And what might those factors be? (Here's where you say `the theme', and
I chortle.)
>...
> You still don't seem to get it. Forget about theme developers for a
> minute. For that matter, forget about the stinking Preference panel.
> What I'm talking about is a general philosophy for any panel, window,
> dialog that is made available for customization. Allowing some room
> for expansion on each of these seems like a logical thing to do, imo.
>...
Definitely. As was mentioned earlier, languages other than English
(particularly German) often need quite a bit more room than English to
say the same thing. In professional-quality software, that usually
*doesn't* mean that the size of the windows needs to change, because
they were designed with enough space available already.
So, the solution is to make more space, by getting rid of some of the preferences.
John Levon
> That's right. To be clear, I'm not arguing that the lack of resizability
> in the Preferences dialog *shouldn't* be changed; I'm explaining why it
> *won't* be changed.
Certainly: if you remember to my original post, I stated I wasn't
arguing for a change in Mozilla; rather just to understand the rationale.
> whether you understand it is unlikely to make any difference to Mozilla.
heh
> No. *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. (The same
> inequality, generalized, should apply to anything which a program allows
> a user to do.)
I suppose we just disagree on the co-efficients here
> (Which is why most software vendors use non-resizable windows so often,
I'm not at all sure this is the primary reason, given how much easier
non-resizability is to implement :)
> No, it's a straw man, some parts of which you excerpted from my
> argument, and some parts of which you made up completely yourself.
This is how I interpreted your comments. It seems that I
mis-interpreted: your clarification is certainly a valid argument.
> I don't need to. Apple, Microsoft, Macromedia, Adobe, and other vendors
No they haven't (unless you can point me to a rationale I've been unable
to find). They have merely implemented things in this way. For this
argument to hold, you would have to believe that nothing ever gets done
in a certain way because it is easier to do.
> No. It's never done anything at all, for me, except take up space in the
> `Tools' menu. No download ever gets shown in it. So, no, I don't think
> it's being efficient at all. :-)
>
It's even more broken for you than it is for me :)
regards
john
p.s. this was hell to write due to the 5-second hang bug in mailnews
compose, so please excuse sloppy editing
John Levon
> Definitely. As was mentioned earlier, languages other than English
> (particularly German) often need quite a bit more room than English to
> say the same thing. In professional-quality software, that usually
> *doesn't* mean that the size of the windows needs to change, because
> they were designed with enough space available already.
Uh ? Professional-quality software (whatever that might be) has a
working shrink-to-fit layout system that automatically accomodates
localization, without the need for the dialog designer to consider the
possible length of a translation of a particular label (as is required
by an em-based system).
The dialogs are emphatically not "designed with enough space available
already".
regards
john
Sailfish
> No, we couldn't do that even if we wanted to. In Windows and Mac OS, at
> least (I can't remember what happens in GNOME and KDE), the dialog
> wouldn't cover the taskbar or menu bar; they would cover the dialog.
> They're always on top. (The same goes for the Dock in OS X, which causes
> grief for OS X users since the Dock is so damn tall.)
This is only a problem because, 1) the low-water res mode is, what I
suspect, a little used 640x480 and 2) too many preferences in some panels.
> If they're copying and pasting settings from another program into the
> dialog, they sure will.
This is a feature that's seldom used by the majority of folks and I
would dare say, those that do, use a res quite a bit larger than the one
where it causes a problem.
> And what might those factors be? (Here's where you say `the theme', and
> I chortle.)
"The theme" is merely the most obvious (perhaps "only"?) external
manipulator but that's not to say that others may not exist, either
today or in some new reincarnation of various opsys UIs? Designing a bit
of flexibility in dialogs and such minimizes one more maintainability
issue, imo.
> So, the solution is to make more space, by getting rid of some of the preferences.
No disagreement here on that one.
morbit _at_ cdn.gs
> Sailfish wrote:
>
>>Matthew Thomas wrote:
>>
>>
>>>The Preferences dialog is as large as it can possibly be, while
>>>still fitting completely on the screen, without overlapping the
>>>taskbar in Windows, the menu bar in Mac OS, or an ordinary-sized
>>>Panel in GNOME or KDE.
>>
>>I'm not sure that means anything. By definition, a Preference panel is
>>something that is open only for the duration it takes to set some
>>option and then closed, i.e., even if it does obscure some other opsys
>>bars on lo-res monitors,
>
>
> No, we couldn't do that even if we wanted to. In Windows and Mac OS, at
> least (I can't remember what happens in GNOME and KDE), the dialog
> wouldn't cover the taskbar or menu bar; they would cover the dialog.
> They're always on top. (The same goes for the Dock in OS X, which causes
> grief for OS X users since the Dock is so damn tall.)
>
well at least for KDE 3.0 the panel is always-on-top
--
cdn
--
Orbit3 lives
Get Orbit3+1 from : http://themes.mozdev.org - Stable |
http://morbit.cdn.gs - Development
Orbit Retro from : http://themes.mozdev.org - Stable |
http://orbit-r.cdn.gs - Development
Sailfish
> And what might those factors be? (Here's where you say `the theme', and
> I chortle.)
On an unrelated issue, I've beome aware of a program called, GTK, which
seems to allow users to manipulate UI widgets outside of Mozilla. While
I'm not completely clear on all that it allows, could this not affect
the characteristics of Mozilla widgets?
Matthew Thomas
>...
> On an unrelated issue, I've beome aware of a program called, GTK,
> which seems to allow users to manipulate UI widgets outside of
> Mozilla. While I'm not completely clear on all that it allows, could
> this not affect the characteristics of Mozilla widgets?
GTK+ is a GUI toolkit for X11 (though it has also been ported to
Windows). It's the toolkit used by the GIMP (from which it gets its
name, GIMP ToolKit), GNOME, Gnumeric, Evolution, and assorted other programs.
Mozilla on X11 uses GTK+ for various things, but not for drawing
interface controls themselves.
dwx
- the thread is too long for me
- I have difficulties following any conversation involving 3+ people
- I dunno where which message I should reply to
so, here we go, starting fresh:
1. The entire mozilla.org project seriously needs a usability lab
(I assume it doesn't already have one) where visual clutter and
feature bloats can be detected early in developement.
2. All the arguments for Preference resizability assume that
the only solution to accomodate long strings of text is enlarging
the dialog. However, we can either re-layout the Preference
dialog or removing some options. Both solutions, I admit, will
like cause as much controversy as this one.
Maybe we can spun off a separate thread to discuss the
alternatives?
3. The Preference dialog, as it is now, has too much clutter.
And many hidden options available through editing the .js file
are proposed to be included in the dialog. I don't think we
want the dialog any larger (it's already BIG). As mentioned
by someone in this thread, restricting the size of Preference
is a very effective way to prevent it grow too large.
4. As for themes, we could use more space between groups of
options to increase the usability of Preference. However, theme
designers should refrain from overstyling and keep their designs
to the bare minimum.
5. As for long strings (i.e. URL)? It's quite unsensible to resize
a dialog just to get an input field long enough. I don't expect
URL address to fit nicely in my browser's url bar. Even if a long
URL does fits, it's likely to be so obsecure that the only thing
I could do with it is probably copy/paste. There are very few
input field in the Preference that could house big string and so
I don't think resizability would provide enough benefit to
outweight issue #3. (Besides, those input fields are of good size,
I think)
6. As for localization, let the Germans deal with it. (j/k)
Space constraint is something that every localizer deals with -
you can use abbreviation, or apply some obsecure words where
there's no direct language equivelents, or deviates from the
original words so to make the language easier to understand.
I think the issue here is really 1) judgement on the side of
the translators and 2) reserving some space in the 'layout'
of Preference. Resizability is not the issue here.
7. The original argument by Matthew Thomas
Now, *any* window (whether it's a dialog, or an ordinary
window) should be resizable if, and only if, the majority
of its contents would benefit from being resizable
still holds. The Preference should NOT be resizable.
Making it resizable will not bring significant benefit to
the user and would not be the best solution to what are
actually layout problems.
dwx
> the only solution to accomodate long strings of text is enlarging
> the dialog. However, we can either re-layout the Preference
> dialog or removing some options. Both solutions, I admit, will
> like cause as much controversy as this one.
>
> Maybe we can spun off a separate thread to discuss the
> alternatives?
another alternative I forgot to mention is using a popup edit
box for long string of text:
.-----------------------------------------:---.
| some very long l o n g loooong tex... |...|
`-----------------------------------------^---`
upon clicking the [...] button, a popup edit box with the
same width as the edit line and the height of two lines
would appear. Wrapping should be forced and there should
be no scrollbar. Return/Enter key should also be
interpreted as confirm. (If height of more than two line
is required, then there's some seriously problem with
choosing an edit line in the first place.)
Matthew Thomas
>...
> so, here we go, starting fresh:
Very good summary.
>...
> 7. The original argument by Matthew Thomas
>
> Now, *any* window (whether it's a dialog, or an ordinary
> window) should be resizable if, and only if, the majority
> of its contents would benefit from being resizable
Or, to be more precise (as I was eventually forced to be), if the
probability that people would resize it 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.
> still holds. The Preference should NOT be resizable.
> Making it resizable will not bring significant benefit to
> the user and would not be the best solution to what are
> actually layout problems.
John Levon got to the nub of the matter when he said `we just disagree
on the co-efficients'. I expect that the people who hang out in this
newsgroup -- people who live, breathe, and excrete Web browsers -- will
consistently underestimate the probability that people will do something
by accident, and also underestimate the average pain caused by those
accidents. (The same problem applies, AFAICT, to GNOME and KDE.)
Sailfish
Hmmm, this thread is in dire need of a resize capability of its own,
methinks.
Anyway, I loaded Moz 1.1 on Linux the other day and noticed that the
Preference panel was resizable. Is that by design for Linux?
John Levon
> John Levon got to the nub of the matter when he said `we just disagree
> on the co-efficients'. I expect that the people who hang out in this
> newsgroup -- people who live, breathe, and excrete Web browsers -- will
> consistently underestimate the probability that people will do something
> by accident, and also underestimate the average pain caused by those
> accidents. (The same problem applies, AFAICT, to GNOME and KDE.)
I suspect you might be right. What interests me is why you feel yourself
to be above such a problem ? You're an expert on the existing Mozilla
UI; why are you immune to this ? Is this related to your assertion that
you find UI design "easy" ?
I hope this doesn't sound like a personal attack, because it's not. I'm
a developer, with a strong interest in UI design, and I have to admit, I
find it to be damned difficult, both in terms of discarding a
developer's attitude, and trying to work out what the "average user" is
all about. I would appreciate some insight into how you operate. (I
admit this is rather offtopic, so a blog or email reply might be best).
regards
john
John Levon
> Anyway, I loaded Moz 1.1 on Linux the other day and noticed that the
> Preference panel was resizable. Is that by design for Linux?
It's a bug.
john