Hi,
ext Sean Luke 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,
I don't understand. Infoprints are never modal, they don't even
take focus.
> 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.
If this is really a case, please file a bug to the Maemo Bugzilla.
> What you should do is distinguish between these somehow. I personally
> would make all #2-style notifications modal,
According to the device UI style, dialogs should be always modal
(to application if there's an application window open). If they
are not, please file a bug about those too. (you can refer to
the UI stylesheet :-))
>> 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.
I hope the Nokia UI designers are also reading this list...
> - 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.
Fact of life: Bugs that are not reported to bug tracking system
"do not exist". Maybe you could file a single bug about dialog sizes
in general and list above items in it?
>> 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?
I'm not talking about user resizes, but calculating the dialog sizes.
Did palms or Newtons ellipsize too long strings or were they only
available in English? :-)
- Eero
_______________________________________________
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers
