[maemo-developers] Moving windows in Maemo

[From: Sean Luke]

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