[maemo-developers] Fremantle UI Portrait Mode

[From: Cornelius Hald]

Hi,

this mail got a bit longer then I expected. I added some ideas how the 
UI could react to orientation changes. Those are only ideas and I know 
that it´s too late to implement/change all this. Also I´m aware that 
there might be different opinions ;) I just had to get this of my chest. 
Maybe it will at least evolve into a fruitful discussion :)

Alberto Garcia wrote:
> HildonAppMenu has automatic relayout. The number of columns changes
> from 2 to 1, and filters remain the same. If really necessary, you can
> also have a different menu for portrait mode, hide some of its items
> or change some of their labels.
>   
I think most people who use filters and the portrait mode will have to 
create a different version of the menu for portrait mode. In my opinion 
there is just not enough space to put them in one row. From the hildon 
HIG HIG[1]:
"Filters should be presented in groups. For example, if the menu should 
allow the user to sort a list of messages alphabetically, the filters 
present should be at least a "sort alphabetically" filter and a "sort by 
date"."

Well, first it´s not possible to present filters without a group, so the 
first sentence doesn't really make sense ;) and (more important) second: 
The example filter should have _at least_ "sort alphabetically" and 
"sort by date".
I cannot check right now, but I doubt that those two strings fit into 
the filter group in portrait mode. And even if they do, how does it look 
with non-english strings like "Alphabetisch sortieren" and "Nach Datum 
sortieren"?!
Maybe you should check again if the filter UI really makes sense at the 
moment. I know it looks cool, but that doesn't help much if later no one 
can use it.

> Standard (Gtk) toolbars don't change, because I don't think there's
> a reliable and generic way to change their layout. If a particular
> toolbar doesn't look good in portrait mode because it has too many
> items, it's IMHO the app -not the toolkit- that should take care of
> this. The same applies to many other widgets and the whole program
> UI in general (if it's going to support portrait mode it should be
> designed with that in mind).
>   
Hmm... Well, I think the toolkit should do as much as possible for the 
developer. If the developer wants to override all this magical stuff, 
then there surely should be a way to do so.

I have a couple of ideas how to do this. I have no idea how the relation 
between Hildon and Maemo-Gtk is, so I don´t know how feasible my 
suggestion are. Basically I was thinking that Hildon and Maemo-Gtk is 
one project and the word "hildon" is more or less just used to introduce 
API which does not exist in pure Gtk...
But anyways, here are some ideas how to embrace the portrait mode a bit 
more and make the life for application developers easier.

1a) Introduce some kind of "important" property for widgets. Using this, 
I could mark some of my buttons as important and thus the UI would make 
sure that they are shown even in portrait mode. Buttons or widgets 
without that flag could be omitted or put into a sub menu if there is 
not enough space. Using this mechanism I also could mark one of my table 
view column as important. The other column could be omitted.

1b) If a property like "important" is too generic/vague then how about a 
"portrait" and "landscape" property. This way I still would have the 
complete control over which widget are shown when and I would have to 
thing about portrait and landscape mode, but at least I wouldn´t clutter 
my code with lots of if (portrait_mode) statements...

1c) Or how about that: Landscape mode is always "edit mode" and portrait 
mode is always "view mode". In this way the application developer would 
get a big hint on which buttons/widget should be shown. I surely don´t 
need a "change font style" button if I´m in the "view mode". Using this 
distinction it would also be possible to change the behavior of other 
widgets in a meaning full way. For example the text view could change 
from being editable/selectable with the fingers in "edit mode" to being 
pannable in "view mode".

2a) Menus: Why not leaving the GtkMenu API like it is, but draw it like 
the AppMenu? It could still be hierarchically. If I press a button which 
opens a new sub menu, this sub menu just slided over the current menu 
and. That way all applications could use a finger friendly menu which 
using new API. If there are too many (more then 10) menu item, then just 
show scroll buttons like in the Diablo start menu. If there are 
GtkRadioMenuItems in that menu they could automatically be shown as 
Filters and so on...
Of course very long menus or menus with deep hierarchies would still be 
annoying for the end users, but they can be changed over time to make it 
a pleasant experience. IMO it still would be a much better experience 
then giving the user a device where every second application still has 
those ugly stylus menus.

2b) Toolbars: Automatically distribute all buttons on the toolbar evenly 
over the available space. In this way if an application has only 5 
buttons on the toolbar it will look good and consistent in landscape and 
in portrait mode.

2b) Toolbars: If there are too many items on the toolbar then displace 
some kind of ">" sign on the right side of the toolbar. This arrow 
symbol should have the same size like every other tool button. Then when 
the user clicks this button, the current toolbar just slides to the left 
out of the view and from the right side a new toolbar (or new tool 
items) slide in. Now this toolbar has a "<" sign on the left and maybe a 
">" sign on the right.
In this way even large toolbars stay finger friendly and don´t use more 
space then before. With the sliding animation the users gets enough feed 
back to know what´s going on.
Here again, the application developer should be encouraged to reduce the 
number of tool items or to drop the toolbar completely, still it would 
be possible to have a large toolbar if really needed and applications 
which are not completely ported would look nice too.

All in all I think that the Gtk-API should be used more, but that the 
rendering on the screen should just different from the rendering on the 
desktop. If I remember correctly there was quite some effort for Maemo 
4.0 to remove own/specific API and replace them with existing API, now 
it looks like we´re going into the other direction again.

If you argue that traditional Gtk application should still work as 
expected, I totally agree. Therefore I would suggest something like 
that: If a developer initializes his application with gtk_init() he gets 
traditional behavior and sizing, but if he uses hildon_gtk_init() all 
widgets represent them selfs als finger friendly as possible. This could 
of course also be decided on per widget basis if needed. Fine tuning of 
the Maemo UI can then be done by using properties (like finger size or 
thumb size) that are just ignored by normal Gtk. In my opinion this 
would make writing or porting UIs much easier. Almost every developer 
hates coding UIs, so I think it should be made as pleasant as possible.

I did not prove read, so please excuse minor mistakes... Now I hopefully 
can get back to work :)

Thanks for reading!
Conny


[1] http://maemo.org/api_refs/5.0/beta/hig/html/ch04s02.html