On Apr 12, 2007, at 4:41 AM, Eero Tamminen wrote:
By the time user was able to start moving notifications,
they go away (within 3 secs I think).
As I've already mentioned, I've found at least two counterexamples to
this in Nokia's own apps: the most famous being the email deletion
notification.
If you're going to allow applications to treat notifications as non-
modal (which Nokia has), then they MUST be movable.
While we're on the topic of notifications, 3 seconds is a LONG TIME
to wait when you're moving fast to do something. The problem here is
that Nokia regularly conflates two different kinds of messages as
"notifications":
1. REAL notifications of finished operations, like "email loaded"
2. Dialogs which inform you of an operation ONGOING, like "deleting
directory..."
#2 of course might have to be modal depending on the operation. But
#1 NEVER has to be modal, and indeed the fact that it's sitting there
for 3 seconds or whatever, making me wait before I can do something
for no reason at all, is really quite surprisingly irritating. For
example, the "touch screen and buttons activated" notification is
VERY irritating -- once I have unlocked my screen I must sit and wait
for another 3 seconds before I'm permitted to actually do anything.
Why? So I can read a notification which I've already seen a hundred
million times.
What you should do is distinguish between these somehow. I
personally would make all #2-style notifications modal, but for #1,
I'd instead temporarily (3 secs) change the text of the application's
title menu bar to the notification text, and change the menu bar's
color to an alert color. That's out of the way, non-modal, and
doesn't obscure anything relevant.
The only reason why user would want to resize a dialog (that I can
think
of) is to make it larger so that she can see more of its content.
However, these kind of dialogs usually already take all the available
space, so I don't see much point in that.
This is simply not true. Almost *none* of your dialogs take close to
all available space, and IMHO most of them are pretty bad when it
comes to organization.
- The Font/Format selector could have been resized to a much larger
size, eliminating unneccessary tab panes, allowing the user to choose
his font from a list rather than a pop-up combo box (why is bold/
italic/underline on a SECONDARY pane? sheesh), automatically showing
the preview without the user having to press the preview button AND
then the close button, etc. You wasted space badly there. Go get a
Mac and look at its resizable, well-organized font panel. This is
what Nokia should be emulating.
- The Color Selector could be resized to permit more user swatches,
- The Open File panel could have been made larger in both width and
height, and here it'd really be useful. Such dialogs also have
unnecessarily large tall title bars and waste a ton of valuable
vertical space in the button row. Why are the buttons on the bottom
in such a height-constrained dialog?
- Likewise for Save panels
- Contacts's "Add Field" dialog is miniscule, requiring a scrolling
list for fields. I guess that's fine since Contacts only has FOUR
OPTIONS there. Were Contacts to permit new fields (hello? Snail-mail
address? Birthday? GPS? AIM? Anniversary? IRC Handle? Custom
fields?), this window would be far too small.
etc.
If the dialog doesn't fill up the screen and is instead in a size
that's
not usable, that's a bug which should be reported separately.
These problems are endemic, not specific. I'm not going to fill out
bug reports for thirty different dialog boxes.
Note that some of the dialogs have static sizes because Gtk doesn't
always handle automatic resizing well enough. This is only a problem
with text ellipsizing though I think. Gtk has only concepts of
minimum
(for ellipsizable text="...") and full size of a widget, as getting
something reasonable in between would need a lot of iterating
(slowdown)
for the widget sizes.
Why do your windows need to have live resizing? Can't you just do a
wireframe resize?
Sean
_______________________________________________
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers
