View Full Version : Maemo 5 Alpha SDK released
Today, Nokia introduced the Maemo 5 Alpha SDK including the new UI framework and APIs for application development. The redesigned Maemo UI provides a simple and beautiful experience with a finger based full screen context. Developers can now use hardware-accelerated 3D graphics at WVGA resolution. We recommend that developers writing applications for Maemo 5 follow the UI style introduced with this Alpha SDK to provide a user experience consistent with the core applications.
More:
http://maemo.org/news/announcements/maemo_5_alpha_sdk_released/
http://maemo.org/development/sdks/maemo5_alpha_sdk/
Looks good. I know what I'll doing tonight :)
i hope someone provides a VM file for this, as the UI needs a closer inspection, but the manual install of the SDK is close to a nightmare imo...
pawpawyoung
2009-03-02, 15:48
Yeah, this is what I'm longing for. Thank you Nokia Maemo guys.
cool! whan can we upgrade?
Ok, ok, I'll let March 2 slip in under the wire as "around February"...
Well done, Maemo team! :D ;)
This is great. One of my big complaints is how hildon-desktop is a big monolithic lump. I'm so glad the desktop is getting some separation:
In Diablo, the single hildon-desktop process implemented the Home for desktop applets, Statusbar for the status applets on top of the screen, Task Navigator for launching and switching between applications, Dbus service for notifications and compositing functionality for transparency in applets.
Programming errors in these different types of applets often caused hildon-desktop process to crash and restart. After a restart following such a crash, hildon-desktop would only load a 'safe' set of applets, excluding applets that were not part of the sales package.
In Fremantle, the widgets (formerly known as applets) are removed from the process implementing window management, application switching, application launching and drawing of the Home. This separation will allow for better reliability in aforementioned functions...
I also think the new UI sounds a bit like the one described in the Unwired View Nokia Sparrow post (http://www.unwiredview.com/2009/02/25/secrets-mwc09-nokia-sparrow-android-30-luxury-android-from-motorola-and-more/).
...a novel, transparent widget based interface. Each running application gets it’s own semi-transparent widget to put it’s content in. Multiple applications can be stored in memory “for months”. E.g. when you are writing a document or e-mail, just swipe the finger through the screen and semi-transparent panels with active or pre-set applications and their content pop-up. Select one and you can start working with it at once.
well so far the screenshots looks like canola gone desktop...
thats why i would like to check it out first hand...
well so far the screenshots looks like canola gone desktop...
thats why i would like to check it out first hand...
http://static.maemo.org/static/m/Maemo5_alpha_SDK_SampleApplication.png
That screenshot I believe is Maemopad, the provided sample application.
http://static.maemo.org/static/m/Maemo5_alpha_SDK_ApplicationMenu.png
Edit: H'mmm, maybe not!
a different option is that someone captures the basics on video and ups it to youtube or similar.
that is, starting, opening programs and so on...
that is, if what we are seeing images of are even close to the final gui for maemo5...
mine would be a long slow video (maybe timelapse)
i'm getting 5seconds/frame :(
/me kicks tabletpc and ubuntu and lack of linuxfoo
I don't believe what you're seeing in the SDK is very much of what will be released in Maemo 5. They're releasing just enough to let you develop to the new UI API. I believe there's lots of whiz-bang that they won't reveal until the last second.
I don't believe what you're seeing in the SDK is what will be released in Maemo 5. They're releasing just enough to let you develop to the new UI API. I believe there's lots of whiz-bang that they won't reveal until the last second.
your probably right, tho i wonder if its a indication that nokia is aiming at the net enabled media player that archos have been showing of (not to mention that other device we all love so much to talk about)...
still, there is a calendering api in there now (closed source).
add the other stuff and im thinking location aware services and ovi integration, maybe including a calendar that can understand gps...
meh, im going to give mer a spin ones maemo4 gives up its ghost, and use my N800 til it fatally breaks...
/me will have to find out how to access the calendaring, it will help to have real appointments underneath my sketching calendar :)
GeneralAntilles
2009-03-02, 20:29
I don't believe what you're seeing in the SDK is what will be released in Maemo 5. They're releasing just enough to let you develop to the new UI API. I believe there's lots of whiz-bang that they won't reveal until the last second.
By "last second", you mean "the beta SDK", of course.
By "last second", you mean "the beta SDK", of course.
No, I mean even more last second than that. ;)
hhedberg
2009-03-02, 22:04
Here is a picture of Mauku running on Maemo 5 Fremantle (alpha). Pressing full screen button hides the window title bar. Dialogs are appearing on the bottom of the screen (like homemade dialogs in Mauku already before Fremantle).
Thanks Henrik! I think this is the first Maemo 5 screenshot not coming from Nokia.
If you could drop a few lines somewhere about your first impressions porting Mauku to Fremantle, that would be great.
Same request to other developers getting their hands dirty with this Maemo 5 Alpha SDK. And keep posting/linking here your screenshots (or screencasts!). Thanks!
I believe there's lots of whiz-bang that they won't reveal until the last second.
Just curious: what whiz-bang are you talking about? If you mean all the stuff coming with the applications, sure. This SDK is basically an empty shell for developers to fill.
If you are still talking about the Maemo 5 UI, what is missing is mostly described in the release notes (http://maemo.org/development/sdks/maemo5_alpha_release_notes/):
Desktop edit mode
Status area
Task switcher
If you are talking about something else, please explain. :)
I have a feeling that the task switcher is going to have some serious whiz-bang (see the quote from the Unwired View article in my post above (http://internettablettalk.com/forums/showthread.php?p=268328#post268328)). Is that coming in the beta SDK or is that something that will be revealed at the very end? It looks like we won't see it before the hardware is released:
Task switcher is not present in this release either. Hence you can only run one application at a time from the UI. The final release will, however, include the task switcher.
EDIT: Sorry, I reread my previous post above, and it sounds like I believe you're going to change the UI. I just believe you've only revealed the bare bones, enough to get people developing without "wrecking the surprise" as it were ;)
mine would be a long slow video (maybe timelapse)
i'm getting 5seconds/frame :(
/me kicks tabletpc and ubuntu and lack of linuxfoo
It sounds like that's not necessarily your fault:
Known limitations
On Debian Lenny (x86 scratchbox target), the response time of actions on using the UI framework is known to be high.
epertinez
2009-03-03, 08:56
Is there any repository of applications to set up?
GeneralAntilles
2009-03-03, 09:12
Is there any repository of applications to set up?
This is the first release appropriate for application development, and, so far, we have . . . three: Mauku, Maemopad, and Arora.
Work is underway to get Fremantle set up in Extras.
benny1967
2009-03-03, 09:17
Just curious: what whiz-bang are you talking about?
maybe the whiz-bang that makes it impossible to run maemo5 on N8x0 devices. screenshots (and 1 single screencast) i've seen so far don't look as if my N800 couldn't do it. :)
I tried Maemo5 alpha with Qt and It works pretty good. It still seems to need some fine tuning on appearance, etc. but anyway it works.
A picture of maemo5 running the Qt tutorials cannon game.
http://g.imagehost.org/0835/qtmaemo5.png
It sounds like that's not necessarily your fault:
Known limitations: On Debian Lenny (x86 scratchbox target), the response time of actions on using the UI framework is known to be high.
I'm experiencing the same, multi-second gui response times on a recent laptop, and I think it's not related to Debian Lenny only, but to problems with the intel x.org driver in Ubuntu (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094) intrepid (https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/288650), jaunty and quite possibly Debian Lenny.
I don't have any hard evidence other than that I've seen the exact same problem happening for other applications that do something fancy graphics-wise, or java applications like jedit. I asked lcuk on IRC yesterday, and he confirmed he is also running Intrepid like me.
I'm experiencing the same, multi-second gui response times on a recent laptop, and I think it's not related to Debian Lenny only, but to problems with the intel x.org driver in Ubuntu (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094) intrepid (https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/288650), jaunty and quite possibly Debian Lenny.
I don't have any hard evidence other than that I've seen the exact same problem happening for other applications that do something fancy graphics-wise, or java applications like jedit. I asked lcuk on IRC yesterday, and he confirmed he is also running Intrepid like me.
I found a workaround (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094/comments/4): Add the following line to the "Device" section of /etc/X11/xorg.conf.
Option "AccelMethod" "XAA"
I just tested it and now the GUI is fast and responsive. I already had this in my xorg.conf at one time, but found better workarounds for the apps I was using. For now I'm fine with it if it allows me to play with the Fremantle SDK, although the overall graphics performance becomes maybe a tad slower.
Somebody should update the "known issues" section of the release notes.
Viipottaja
2009-03-03, 10:55
Benny, where is the screencast you saw?
benny1967
2009-03-03, 11:21
there's one of a file chooser dialog in one of the pre-alphas
http://www.youtube.com/watch?v=--zN8RmXOcI
seeing this, i hope there'll be at least whiz or bang added to the final product :D
Thanks for digging up that screen cast. I like this filechooser.
The final result will certainly even look much better. But this is the kind of kinetic scrolling I've always wanted. :)
benny1967
2009-03-03, 11:51
It's a little bit complicated to use... like you have to scroll all the way up again if you find that the file you're looking for is not in the currently selected directory, but in one of its sub-folders. a good chooser would let you select directories from an additinal tree on the left. (there's a very good reson why file choosers normally have two or even more lists to select directories, files, recently used... blabla). in this case obviously form didn't follow function, but was dictated other factors.
anyway, the point wasn't that it's less comfortable than what we have today, the point is that it would run on an N800 an therefore (according to the announcments about Maemo5 not being ported to N8x0 because of it's clutter-based, 3D-accelerated interface) probably isn't the real thing.
But Maemo 5 is a bit more than a filechooser, isn't it.
I have a feeling that the task switcher is going to have some serious whiz-bang (see the quote from the Unwired View article in my post above (http://internettablettalk.com/forums/showthread.php?p=268328#post268328)). Is that coming in the beta SDK or is that something that will be revealed at the very end? It looks like we won't see it before the hardware is released:
Is this task switcher going to enable instantaneous switching between apps or between tasks within apps? Will it switch between only two or will it toggle through more than two? IMHO, a good use of new graphics HW if it does. There's little worse on a MID than annoying lag or multiple steps being needed when switching between tasks. And how will it switch? finger input on screen or key?
Viipottaja
2009-03-03, 14:18
Yep, the kinetic scrolling looks promising. I assume the directory chooser will be improved in the final release.
I found a workaround (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094/comments/4): Add the following line to the "Device" section of /etc/X11/xorg.conf.
Option "AccelMethod" "XAA"
I just tested it and now the GUI is fast and responsive. I already had this in my xorg.conf at one time, but found better workarounds for the apps I was using. For now I'm fine with it if it allows me to play with the Fremantle SDK, although the overall graphics performance becomes maybe a tad slower.
Somebody should update the "known issues" section of the release notes.
It did not work for me.. I have tried with just the AccelMethod option and also the ones in the workaround link. Is there something more that I have missed?
But Maemo 5 is a bit more than a filechooser, isn't it.
Yes, it's a 3D, clutter-based, OpenGL-enhanced filechooser. :) :D ;)
Stskeeps
2009-03-03, 17:37
Yes, it's a 3D, clutter-based, OpenGL-enhanced filechooser. :) :D ;)
Is it? It runs fine under Mer..
I have created 10 screenshots of gPodder running in the Fremantle Alpha SDK:
http://farm4.static.flickr.com/3597/3325540709_fe9817e626.jpg
Is this the first Python GUI application to be run in Fremantle SDK? Anyways, all pictures can be found at this URL:
gPodder in Fremantle Alpha SDK Screenshots on Flickr (http://www.flickr.com/photos/63684846@N00/sets/72157614753854732/)
qwerty12
2009-03-03, 18:03
Majorly impressed with the SDK. My Transmission port compiled with only one minor change needed to the code and the build-deps it needed were already installed - I only had to get 3 more (and they're in the SDK repo so no problems there).
http://qwerty12.maemobox.org/transmission1.png
(And my F6 still works to get fullscreen in the SDK!)
Is this the first Python GUI application to be run in Fremantle SDK?
I think is the fourth application seen inside Fremantle, after Mauku, Maemopad, and Arora :)
Is this the first Python GUI application to be run in Fremantle SDK?
I think it's the first pygtk app to be running, but not the first in python (technically):
I was running pyclutter applications in the pre-alpha SDK:
http://www.youtube.com/watch?v=YclW3nlC1BA
http://www.youtube.com/watch?v=RMcRF2va2Qs
I agree that it are just test and not useful applications, except the one where my face is seen multiple times :P
there's one of a file chooser dialog in one of the pre-alphas
http://www.youtube.com/watch?v=--zN8RmXOcI
seeing this, i hope there'll be at least whiz or bang added to the final product :D
In defence of Fremantle, I have to say I wasn't pressing the mouse very trusting, and in a device the behaviour is better than seen in the video.
As Stskeeps says, it's running in Mer, so the new Hildon widgets can be tested with an device.
Also, other Fremantle widgets can be seen in this screenshots: http://www.flickr.com/photos/yerga/sets/72157612365187767/
or here (are the same): http://share.ovi.com/channel/yerga.Hildonwidgets
Though, they are from the first alpha (without theming), and they could have changed in the updates.
I found a workaround (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094/comments/4): Add the following line to the "Device" section of /etc/X11/xorg.conf.
...
It did not work for me.. I have tried with just the AccelMethod option and also the ones in the workaround link. Is there something more that I have missed?
me neither, extremely frustrating.
benny1967
2009-03-03, 19:18
In defence of Fremantle, I have to say I wasn't pressing the mouse very trusting, and in a device the behaviour is better than seen in the video.
Oh... that. I didn't refer to the kinetic scrolling (couldn't care less). It was the overall clumsiness and looks of the thing.
And, again: The original point was answering the question if what we're seeing from the UI in this alpha is (close to) the final UI. My bet was "no", because the reason given for not offering Maemo5 to N8x0-owners was "the revamped UI relying on graphics acceleration" (see here (http://maemo.org/news/announcements/first_maemo_5_sdk_release_targeting_platform_devel opers/)). Now because we see nothing that relies on graphics acceleration so far (and Stskeeps tells us it runs fine under Mer), either they dropped the idea of a UI relying on graphics acceleration (which would be a good thing, as it would bring Maemo5 to my N800) or, more likely, we haven't seen the real thing yet.
me neither, extremely frustrating.
*Sigh* Now it's back to very slow for me, too, after working fluidly this afternoon. Didn't change anything, and haven't been taking any drugs. Very mysterious. At least now I know how it's *supposed* to work.
Stskeeps
2009-03-03, 19:34
Now because we see nothing that relies on graphics acceleration so far (and Stskeeps tells us it runs fine under Mer), either they dropped the idea of a UI relying on graphics acceleration (which would be a good thing, as it would bring Maemo5 to my N800) or, more likely, we haven't seen the real thing yet.
Let me just clarify what I meant - libhildonfm2 + libhildon from fremantle works fine, and i have seen no use (yet) of GL acceleration in these. There might also be a performance benefit of having PVR2D acceleration in Xorg with regards to kinetic scrolling etc.
http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle says it quite clearly what clutter is used for:
Fremantle introduces a new UI framework which uses Clutter OpenGL library. It provides the following functionality:
* Window manager
* Task Launcher
* Task switcher
* Home view
* Status menu and status area
* New Hildon notification API for handling desktop notifications.
allnameswereout
2009-03-03, 19:34
It did not work for me.. I have tried with just the AccelMethod option and also the ones in the workaround link. Is there something more that I have missed?Your AperTexSize has to be accurate though.
Did you restart X?
This works for me:
Section "Device"
Identifier "Configured Video Device"
Driver "intel"
Option "AperTexSize" "262144"
Option "XVideo" "1"
Option "XaaNoPixmapCache"
Option "XAANoOffscreenPixmaps" "1"
Option "DRI" "true"
Option "AccelMethod" "XAA"
EndSectionNow its smooth again :)
Oh... that. I didn't refer to the kinetic scrolling (couldn't care less). It was the overall clumsiness and looks of the thing.
And, again: The original point was answering the question if what we're seeing from the UI in this alpha is (close to) the final UI. My bet was "no", because the reason given for not offering Maemo5 to N8x0-owners was "the revamped UI relying on graphics acceleration" (see here (http://maemo.org/news/announcements/first_maemo_5_sdk_release_targeting_platform_devel opers/)). Now because we see nothing that relies on graphics acceleration so far (and Stskeeps tells us it runs fine under Mer), either they dropped the idea of a UI relying on graphics acceleration (which would be a good thing, as it would bring Maemo5 to my N800) or, more likely, we haven't seen the real thing yet.
Well, the new hildon-desktop we are seeing in the picture of the announcement is based in clutter and libmatchbox2 (what depends on clutter too).
So I imagine it's relying in graphics acceleration.
And here the next SharePy version running in Fremantle.
It's running in plain gtk without hildon and looks fine anyway, except the images in the treeview are with 'bad' colours.
As a comment aside, it's a bit weird that this thread hasn't been taken to the home. I wonder if Reggie & Roger are aware?
Engadget has picked the news: http://www.engadget.com/2009/03/03/maemo-5-gets-alpha-sdk-nokia-fans-rejoice/
It's a little bit complicated to use... like you have to scroll all the way up again if you find that the file you're looking for is not in the currently selected directory, but in one of its sub-folders. a good chooser would let you select directories from an additinal tree on the left. (there's a very good reson why file choosers normally have two or even more lists to select directories, files, recently used... blabla). in this case obviously form didn't follow function, but was dictated other factors.
I like the look of the single column chooser, and would like to see something similar for a file manager (as long as there is a way of copying to other folders somehow). I find that each column in the current 2-column view on Maemo 4.1 a bit too narrow so that I cannot read an entire file or folder name.
hhedberg
2009-03-03, 21:13
If you could drop a few lines somewhere about your first impressions porting Mauku to Fremantle, that would be great.
Porting was pretty straightforward: I just recompiled the sources against the new libraries. ;)
The Alpha SDK have serious issues with graphics (as expected: it is still alpha). Depending on video card and settings, UI is either lagging or messing with colors and contents (or both). For example, menus are totally cluttered (! ;)) with ATI Radeon 9200 PRO. Fortunately, I had better luck with my good old laptop, which has Intel 855GME Extreme Graphics 2. It seems that without compositing window manager UI is not responsive enough, so all visual effects must be turned on in Ubuntu Intrepid. However, the UI was not a speed monster in my 1,2 GHz laptop either, so I really hope that OMAP3 has enough horse power to make it smooth... ;)
Nevertheless, it was really promising to see Mauku on Fremantle - altough in inverse colors. ;) (Toggling fullscreen on and off makes colors right, so there is a tiny moment to make a screen capture before the application updates its widgets again.)
I like the look of the single column chooser, and would like to see something similar for a file manager (as long as there is a way of copying to other folders somehow). I find that each column in the current 2-column view on Maemo 4.1 a bit too narrow so that I cannot read an entire file or folder name.
yep, the ability to hide the dir list, along with horizontal scroll would have been nice.
gpe is close on maemo4, but it seems i must read up on programming for it to get that final distance covered...
I could upload Modest 2.1-2009.08 screenshots if some Nokian allow it (it's still to see if Modest should have done this release) .
It costs a couple of hours built it (delete the not released dependences, built wpeditor, built tinymail from the svn, etc.).
Just say, very finger friendly :)
I'd like to see that yerga :D
I could upload Modest 2.1-2009.08 screenshots if some Nokian allow it (it's still to see if Modest should have done this release) .
It costs a couple of hours built it (delete the not released dependences, built wpeditor, built tinymail from the svn, etc.).
Just say, very finger friendly :)
The purpose of the Fremantle Alpha SDK release is to provide the APIs for development, but the official applications are not intended to be out at this point (except some example apps, osso-xterm and the Application Manager).
Thanks for noticing the Modest source code was out. It was pulled by a dependency that needed to be satisfied by the current Modest source package. We have pulled it back, only because we are actually planning a nice release for Modest when the project is ready for it (with code repository out, good release notes, screenshots of the stable version and so on).
About the performance issues in the SDK related to the graphics acceleration, it would be good that those of you suffering/solving them would share your pain and glory at http://bugs.maemo.org so Soumya and the development platform team get more feedback for debugging, fixing and documenting. Thanks!
Anyone saved the masses of us the hassle of installing the SDK by creating a virtual machine image to share?
That would be nice indeed ;)
The purpose of the Fremantle Alpha SDK release is to provide the APIs for development, but the official applications are not intended to be out at this point (except some example apps, osso-xterm and the Application Manager).
Fair enough.
I'll try not leak it, except if I receive a great quantity of money or 1000 karma points :P
It's going in the good way, but this is my personal and untransferable opinion.
A screenshot of the new HildonAppMenu: http://maemo.org/api_refs/5.0/alpha/libhildon/HildonAppMenu.html
Anyone saved the masses of us the hassle of installing the SDK by creating a virtual machine image to share?
would the pvr/opengl/clutter stuff work in vmware?
I have had problems in the past with "normal" opengl within my older vmware box.
qgil, will make a proper bug report after tea.
konttori
2009-03-04, 19:11
you can run clutter and opengl via software rendering in vmware. You just need a fast(ish) pc.
i have reported the bug regarding very slow performance on my scratchbox
https://bugs.maemo.org/show_bug.cgi?id=4180
what is the expected framerate running this software?
does internal hardware testing have the same issues?
VirtualBox and VMWare have OpenGL hardware acceleration, but it requires special guest drivers and probably doesn't cover ES.
Master of Gizmo
2009-03-05, 07:41
Osm2go also runs under Freemantle:
http://www.harbaum.org/osm2go-freemantle.png
There were several things missing. Goocanvas wasn't an issue and was quickly compiled and packaged for freemantle. But two of the old closed source packages are missing: gpsbt and tablet-browser-interface. Are there already documents explaining what do use as a replacement?
Also the new screen layout will require some changes in osm2go's ui. E.g. the toolbar spacing got bigger and the toolbar on the left can't hold all the icons anymore (that's why there's this "expander" on the bottom). Also most dialogs have to be adjusted to cope with the buttons being on the right side. That's in fact a design decision i don't fully understand. The idea may be that with the wide screen placing the buttons on the side leaves a more "square" area for the application to work with. By imho the problem is that those buttons eat up space horizontally (since their text labels are horizontal). This leaves a big unused area above such an button. The application cannot use this area and i am afraid we loose too much screen space by this new layout. I don't like it ...
For most dialogs this shouldn't be too much of a problem and makeing them look nice in the new layout is probably just a matter of some "#ifdef FREMANTLE" adjustments.
Master of Gizmo
2009-03-05, 11:44
Just to explain what dialog button layout i am talking about:
This is osm2go running under diablo (this is in fact the version i compiled using the fremantle sdk which is running just fine under diablo!):
http://www.harbaum.org/dialog-diablo.png
And this is exactly the same binary running in the fremantle alpha sdk:
http://www.harbaum.org/dialog-freemantle.png
Another interesting difference is the fact that the dialog in the fremantle screenshot does not have a "cancel" button. How comes?
Also note that the window title under fremantle is just test and not "OSM2Go - test" as it would have been under diablo (the diablo screenshot shows a project named "schloss" while for the fremantle i have been loading a project named "test").
This is all quite interesting. Hopefully this isn't the final theme, but I don't like the way the title bar for the dialog box is almost as dark as the dialog box background, so that it is hard to distinguish. Can you cancel by clicking above (outside) the dialog?
Is there any more documentation or style guide on the new UI yet? I find UIs fascinating.
Thanks MoG! Can you please convert your questions into bugs at http://bugs.maemo.org ? Default location Development Platform -> SDK.
This way we can keep a better track and hopefully answer them sooner & better.
This is all quite interesting. Hopefully this isn't the final theme, but I don't like the way the title bar for the dialog box is almost as dark as the dialog box background, so that it is hard to distinguish. Can you cancel by clicking above (outside) the dialog?
Is there any more documentation or style guide on the new UI yet? I find UIs fascinating.
Clicking out of dialogs makes them disappear, yes.
No documentation and style guides yet, sorry. We didn't want to wait for the docs to push the alpha code. The developer documentation is planned to be provided with the beta.
Master of Gizmo
2009-03-05, 12:10
Hopefully this isn't the final theme, but I don't like the way the title bar for the dialog box is almost as dark as the dialog box background, so that it is hard to distinguish. Can you cancel by clicking above (outside) the dialog?
Oh, you are right, clicking outside the dialog closes it and it seems to be handled like "cancel". Wow, how counterintuitive!!! Honestly, this is not the first time i am using a computer and i did not understand how to close a dialog. I think that's the worst case for a UI.
Also the color theme is pretty ugly, agreed. Seems to be some special low-contrast military camouflage style ...
Oh, you are right, clicking outside the dialog closes it and it seems to be handled like "cancel". Wow, how counterintuitive!!! Honestly, this is not the first time i am using a computer and i did not understand how to close a dialog. I think that's the worst case for a UI.
Hopefully they've done, or will do, user testing on this. I know that Canola uses the same method to close the dialogs that slide in from the right-hand side, and it took me a few seconds to guess how to dismiss those the first time I saw them.
Also the color theme is pretty ugly, agreed. Seems to be some special low-contrast military camouflage style ...
Well a black background is the iPhone style, isn't it, now copied by several other handhelds. I'm not saying it's good, but I can see why they've picked it.
Master of Gizmo
2009-03-05, 12:39
Well a black background is the iPhone style, isn't it, now copied by several other handhelds.
This isn't black, this is some dark olive with slightly less dark olive decorations/texts. The iPhone may have a black background, but it has way more contrast in its gui elements.
Are the new devices going to be finger-only, i.e. not come with a stylus? I ask because http://maemo.org/development/sdks/maemo5_alpha_overview/ says that the stylus keyboard has been removed, and the window/app close button is much larger than before.
GeneralAntilles
2009-03-05, 13:52
Are the new devices going to be finger-only, i.e. not come with a stylus?
I can't speak to what'll be bundled with the hardware, but the touchscreen is resistive, so there's no reason you couldn't use a stylus.
This is theme is for the SDK only and if you don't like it file bugs to improve it. Or come up with alternative themes when Urho is done with the Theme Maker (soon, apparently).
About the click out of the dialog to Cancel, as a user nobody told me about it and I don't remember about the first time, so I guess it was not a traumatic change. I didn't even notice there are no Cancel buttons anymore! :)
benny1967
2009-03-05, 15:04
Oh, you are right, clicking outside the dialog closes it and it seems to be handled like "cancel". Wow, how counterintuitive!!! Honestly, this is not the first time i am using a computer and i did not understand how to close a dialog. I think that's the worst case for a UI.
wasn't there an announcement that fremantle would have an improved UI? *sigh*
will diablo run on the maemo 5 "lead device"? :p
Master of Gizmo
2009-03-05, 15:45
will diablo run on the maemo 5 "lead device"? :p
Your question probably is "can a diablo theme be run under fremantle" which is likely a "yes". Why shouldn't you be able to replace the hacked hildon core libs with some that look like diablo?
On the other hand: The fact that some colors in an alpha are ugly doesn't mean this will stay that way. Why should Nokia publish these early versions if they don't intend to listen to threads like this one?
I indeed like their basic idea of cleaning of the dialog boxes to make more space for content. Perhaps they just need some hints.
E.g. the "where's my close button" problem can easily be solved by adding some small "X"-Shaped icon to the dialog title bar. Most users are familiar with the meaning of an (X) icon in the upper right corner of their dialogs title bar. I think i'll file a bug report to suggest just this ...
This is theme is for the SDK only and if you don't like it file bugs to improve it. Or come up with alternative themes when Urho is done with the Theme Maker (soon, apparently).
About the click out of the dialog to Cancel, as a user nobody told me about it and I don't remember about the first time, so I guess it was not a traumatic change. I didn't even notice there are no Cancel buttons anymore! :)
as a user I would expect the presence of a big fat X in the top right to also act as a close button for a dialog.
(since you also seem to be using that location for "back" as well the user will expect it soon enough)
I can't test at the moment but if you click the big X (which is actually for the test form and not the dialog) does the dialog close and then the test form?
if so, thats a major problem for the UI, if not its still disconcerting because the user will close the dialog using the artifact of UI from behind.
Personally I prefer giving people a clear way to (cancel/close/dismiss/do nothing) on actual dialogs, that way there is none of this. (at the same time I am even more guilty because I can make screens with no ui at all :p)
GeneralAntilles
2009-03-05, 15:52
wasn't there an announcement that fremantle would have an improved UI? *sigh*
UI "quality" is a highly subjective area, and, really, the only real way to judge a UIs effectiveness is to use it on the device it's intended for. The only way to do that is to work at Nokia. So, something makes me think the folks there with devices working on the UI probably have a better picture of how well it actually works than us. ;)
will diablo run on the maemo 5 "lead device"? :p
The Diablo "UI" was already ported to Fremantle (please see the pre-alpha SDKs and Mer).
How about the other way? Can someone tar up an armel rootfs of the SDK (just the libraries, etc) so I can see if we can get some Fremantle GUI on current devices? Or is that what the good folks at Mer are doing right now?
I'm not entirely clear about this yet -- Does the current UI already require OpenGL ES to render?
kanishou
2009-03-05, 18:22
There are some issues with colours on scratchbox, it should look better on a device. E.g. the turquoise you see, is actually lime green...
Closing dialogs by tapping outside their area (which is dimmed) provides by far the biggest possible click target. Putting a visible X somewhere would only distract from that, and it takes just a few seconds to learn, then it feels completely natural. I bet you also learned that you can close menus on your desktop by clicking somewhere else. :)
lcuk: The X in the background is getting dimmed like the rest of the inactive background, and tapping anywhere on that space will only close the dialog of course.
The Diablo "UI" was already ported to Fremantle (please see the pre-alpha SDKs and Mer).What would be really nice is if you could easily multitask between diablo apps and fremantle apps on top of Mer on a N8x0. sweet! :D
kanishou,
does the dialog close when you press escape?
kanishou,
does the dialog close when you press escape?
I'm not kanishou of course, but I hope so. But then, do we know for sure that the new hardware will have Esc buttons?
Clicking outside of dialogs to make them close may take a little getting used to, but I'm coming around to the idea. As long as it's consistent in the UI then it should be relatively learnable. Other than Canola, are there other UIs that cancel dialogs like that?
does the dialog close when you press escape?
I noticed that the Mer dialogs (based, I guess, on the first SDK?) don't have any visible way to close them either, and pressing the Esc key on my N800 closes them just fine.
Y
I indeed like their basic idea of cleaning of the dialog boxes to make more space for content. Perhaps they just need some hints.
E.g. the "where's my close button" problem can easily be solved by adding some small "X"-Shaped icon to the dialog title bar. Most users are familiar with the meaning of an (X) icon in the upper right corner of their dialogs title bar. I think i'll file a bug report to suggest just this ...
Yes, thanks, but I think those are already planned... There are visual hints related to dimming (and i think even an icon in the upper right corner), they're probably not yet implemented to the alpha.
We naturally did do user testing with this new dialog style, and there wasn't any major problems in regards to closing.
benny1967
2009-03-05, 19:11
We naturally did do user testing with this new dialog style, and there wasn't any major problems in regards to closing.
you probably wanted to say "...and they showed a vast improvement in usability in regards to closing."
nokia wouldn't change things if users had only minor problems with the new way, would they?
;)
you probably wanted to say "...and they showed a vast improvement in usability in regards to closing."
nokia wouldn't change things if users had only minor problems with the new way, would they?;)
Well no, it's not a "vast improvement in usability". I think it's a nice improvement over the previous style that requires you to aim and hit a small target. Tapping outside is a large-to-huge target. Also it frees up space and clears up the screen. There will be a visual effect making this target even clearer.
Perhaps at some other day I might have more humour for comments like this, but today I kind of don't get the positive side of complaining over everything.
benny1967
2009-03-05, 19:57
Well no, it's not a "vast improvement in usability". I think it's a nice improvement over the previous style that requires you to aim and hit a small target.
vast or nice, it's what i meant: your original comment made it sound like yes, it was a problem in the UI testing, but only a minor one so nobody cared. now your saying that it's an improvement, and my guess was that this is what you wanted to express in the first place.
Perhaps at some other day I might have more humour for comments like this, but today I kind of don't get the positive side of complaining over everything.
sorry if my bitterness shines through here too much. i tried to hide it because i know there's a lot of people who are proud of what they released. (and they are right, i can tell there's a lot of us who like it.)
i still hope that in the end, on the actual hardware, with proper theming and with the missing pieces added, i will get used to it.
lemmyslender
2009-03-05, 20:07
From all I have read, this is supposed to be a very open project. As such there was a pre-Aipha, and the current Alpha release, and eventually a Beta release.
I don't think anyone is complaining, only offering as I would expect (not complaints) constructive criticism and a variety of opinions as a result of these releases.
I have made changes to my own programs that I felt improved them only to find out that the majority of endusers didn't understand or "get" the changes. This resulted in reversing some of these to avoid headaches and complaints from the endusers. Sure they would have eventually gotten used to them, but at what cost?
Perhaps if Nokia were a little more forthcoming with details, some of the questions/criticisms/complaints would be headed off. On the other hand, I'm sure that there would be a whole crop of other issues.
But Maemo 5 is a bit more than a filechooser, isn't it.
Yes, it's a 3D, clutter-based, OpenGL-enhanced filechooser. :) :D ;)
Is it? It runs fine under Mer..
Yes, yes it does. Although I think the OK button could be a bit bigger.
http://farm4.static.flickr.com/3610/3331650806_83c982721b_o.png (http://www.flickr.com/photos/qole2/3331650806/)
Stskeeps
2009-03-05, 20:37
Yes, yes it does. Although I think the OK button could be a bit bigger.
http://farm4.static.flickr.com/3610/3331650806_83c982721b_o.png (http://www.flickr.com/photos/qole2/3331650806/)
That's not hildon-fm. That's GNOME's file chooser (or GTK, i forget.)
Master of Gizmo
2009-03-05, 20:39
There are some issues with colours on scratchbox, it should look better on a device. E.g. the turquoise you see, is actually lime green...
Ok, so it looks like red and blue are exchanged. You can adjust that e.g. with imagemagick using this:
convert in.png -channel RGB -separate sepimage.png
convert sepimage-2.png sepimage-1.png sepimage-0.png -channel RGB -combine out.png
rm sepimage-?.png
When applying that script to my two screenshots they look like this:
http://www.harbaum.org/osm2go-freemantle-recolor.png
and this:
http://www.harbaum.org/dialog-freemantle-recolor.png
benny1967
2009-03-05, 21:05
Are the new devices going to be finger-only, i.e. not come with a stylus? I ask because http://maemo.org/development/sdks/maemo5_alpha_overview/ says that the stylus keyboard has been removed, and the window/app close button is much larger than before.
i think i remember reading somewhere that yes, i'll need to buy a stylus as an extra 3rd party accessory. can't remember/find the source, though, which makes this info pretty unreliable.
i was disappointed at first about the removal of the stylus keyboard: a lot of things just dont work well with the thumb keyboard: chatting, x-terminal, frequent use of numbers,...
i guess it just doesn't matter, though, as long as there's a hardware keyboard. i own an N800, so i couldn't live without the stylus variant, but i hope N810-owners will confirm that hardware keys are even better.
That's not hildon-fm. That's GNOME's file chooser (or GTK, i forget.)
Are you sure? It doesn't look like any Gnome/GTK file chooser I've ever seen before. And that giant OK button on the right looks just like the Fremantle UI screenshots we've seen...
Maybe it's some weird bastardization of GTK / Hildon due to the fact that this is OpenOffice with GTK compatibility, and I'm running this in a chroot, but most of the other aspects of the Liberty theme look right.
benny1967
2009-03-05, 21:28
qole, i thought you threw this in as a joke, but: it looks pretty much like the file chooser i have on my gnome desktop. really. except that the OK-button is completely out of place (and proportion), which makes the actual files list too narrow.
So it is a weird bastard child of Gnome/GTK, Diablo and Fremantle. Sweet. :D
Can someone post a screenshot of what the Mer filechooser is supposed to look like?
So it is a weird bastard child of Gnome/GTK, Diablo and Fremantle. Sweet. :D
Can someone post a screenshot of what the Mer filechooser is supposed to look like?
AFAIK, there isnt "Mer filechooser". There is the Gtk filechooser (your screenshot) or the new Hildon filechooser (the mentioned video).
And AFAIK, Hildon filechooser isnt 3D and clutter based (because of this, it's running in Mer without problems). The new Hildon desktop it's clutter based.
there was a video somewhere showing a file selector that basically looked like a tree view combining dirs and files...
i suspect the the file manager will be somewhat similar...
Let me rephrase, then; I would like to see what the new Hildon filechooser in Mer looks like. From my picture, we can assume that some of the elements of the new Fremantle theme (like that big OK button, and the removal of the cancel button) have been pushed up to the GTK level, so all GTK dialogs will display these features.
EDIT: Ok, I watched the video (http://www.youtube.com/watch?v=--zN8RmXOcI). Now I know.
EDIT2: Is it a bug that the new OK button size and placement breaks the GTK file chooser dialog? Should I report it?
you probably wanted to say "...and they showed a vast improvement in usability in regards to closing."
nokia wouldn't change things if users had only minor problems with the new way, would they?
Of course they would, that's what they hired UI designers to do.
:p
http://www.harbaum.org/osm2go-freemantle-recolor.png
and this:
http://www.harbaum.org/dialog-freemantle-recolor.png
gizmo, those screenshots look cool! (*much better than the originals now the colors are "right)
I played with clutter over christmas and it obviously runs better directly on the laptop itself without worrying about emulation and scratchbox etc
what i want to know though is it possible to take an application designed for clutter on normal x86 and recompile it for maemo/fremantle, or would I need lots of special fremantle specific porting afterwards? (much like the x11 hildonizing)
I'm eager to make a start and the teasing of these screenshots is making me want to try more.
But two of the old closed source packages are missing: gpsbt and tablet-browser-interface. Are there already documents explaining what do use as a replacement?
tablet-browser-interface will be in the beta. The alpha doesn't include any browser related packages.
gpsbt is dropped, http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle#Location_framework updated.
qwerty12
2009-03-06, 07:18
Pictures of a HildonFileChooser from the Alpha. Doesn't look pretty much different from yerga's video.
Creating a folder:
http://qwerty12.maemobox.org/freemantle/createfolder.png
Opening a file:
http://qwerty12.maemobox.org/freemantle/openfile.png
Saving a file:
http://qwerty12.maemobox.org/freemantle/savefile.png
Choosing the location:
http://qwerty12.maemobox.org/freemantle/savefilechooselocation.png
I'm sure you all know this but I'll possibly repeat this for consistency, although the dark theme doesn't do well to show it, there isn't a need (functionality wise) for a cancel button because the X in the top right corner acts as one for whatever dialog you have open.
Oh yeah, as demonstrated in Yerga's video, teh chooser haz kineticz
Is it a bug that the new OK button size and placement breaks the GTK file chooser dialog? Should I report it?
http://qwerty12.maemobox.org/freemantle/gtk.png
^ - doesn't look terribly broken to me (and it's not one of the smaller gtk dialogs :)). I can still cancel with the X. Only problem I have there, at least in scratchbox, I can't resize the bookmarks. Apart from that, usable - just not ideal. (Although Maemo programs should be using the HildonFileChooserDialog anyway ;))
Master of Gizmo
2009-03-06, 07:34
what i want to know though is it possible to take an application designed for clutter on normal x86 and recompile it for maemo/fremantle
This (color corrected) screenshot is from the gtk-clutter-test application that is included with clutter-gtk. In order to run this i had to:
port and package clutter-gtk (since it's not part of fremantle which is rather odd since these are the gtk bindings for clutter)
hildonize the gtk part of the test app
no changes in the clutter part were required
The entire process took less than half an hour. But there are artifacts around the bitmaps and the frame rate is very low. So, yes, you can run clutter via scratchbox, but it's not very useful yet (at least on my machine, but perhaps i am just suffering from the performance problems you also experience).
http://www.harbaum.org/clutter-gtk-fremantle.png
i guess it just doesn't matter, though, as long as there's a hardware keyboard. i own an N800, so i couldn't live without the stylus variant, but i hope N810-owners will confirm that hardware keys are even better.
I have an N810 and use the hardware keyboard most of the time. However, I do revert to the stylus keyboard when doing lots of number data entry (e.g. in gnumeric), as it is annoying entering numbers with the hardware keyboard, due to having to use Fn. An additional row on the hardware keyboard would be very welcome.
as i do not own a n810 i have to ask, can you not double press fn to lock the key function?
as i do not own a n810 i have to ask, can you not double press fn to lock the key function?
Yes, you can. But if you have to enter a mix of number and letters, this isn't good either.
as i do not own a n810 i have to ask, can you not double press fn to lock the key function?
Yes you can.
as i do not own a n810 i have to ask, can you not double press fn to lock the key function?As others have said, yes you can, but in Gnumeric (which was my example) you have to do this separately for each cell. So for that specific use case, the stylus keyboard is easier.
allnameswereout
2009-03-06, 20:03
as a user I would expect the presence of a big fat X in the top right to also act as a close button for a dialog.The user might have to adapt, but different symbols on same location might be confusing.
I would find a big square with a line (sortof like an arrow) to a small square a logic way to imagine this.
Some things the user decides and quickly wants to get that done. UI consistency is then very useful for workflow. There is also no relearning afterwards.
Another way to close applications could be from a task manager, instead by default only minimizing applications.
Personally I prefer giving people a clear way to (cancel/close/dismiss/do nothing) on actual dialogs, that way there is none of this. (at the same time I am even more guilty because I can make screens with no ui at all :p)On a longer timescale users want to use symbols for such, that much I know. It might take them a bit longer to adapt to, but eventually they'll get used to it and love it.
This is the kind of UI consistency a good HIG aims for.
I think a black UI with little as much light colour is better for battery than other way around?
I think a black UI with little as much light colour is better for battery than other way around?
A dark background would help battery life on an OLED display, but not on a backlit display as used in the N800 and N810.
Regards,
Roger
The application menu can store until 15 items in the same screen (see the screenshot), if you have more than 15 items you can see the other items scrolling (kinetically) until the rows below.
Also, there is a new property in the .desktop files: X-Maemo-Prestarted. It seems to allow applications be pre-started (logically as the name indicates). I didn't can to do it work in scratchbox though.
yerga,
that looks fantastic!
the only thing out of place is the back icon, why isnt it in the top left?
The prestarted application flag sounds good - :D lets hope its not abused too much :p
The prestarted application flag sounds good - :D lets hope its not abused too much :p
Hopefully not. Though the hildon-desktop (who manage this) checks the used memory and acts in consequence.
A comment from the source code:
/* Prestarting depends on the env var HILDON_DESKTOP_APPS_PRESTART and the
* amount of /proc/sys/vm/lowmem_free_pages up to
* /proc/sys/vm/lowmem_notify_low_pages.
* not set|false|no - Never prestart apps.
* yes|auto|0 - Prestart if there are more free pages than stated in
* /proc/sys/vm/lowmem_notify_low_pages.
* number - Prestart if there are more than this number of free pages.
*/
the only thing out of place is the back icon, why isnt it in the top left?
Because cancel/back/close function is always in the top right
sometimes I want to close my browser without having to go back 4 pages.
think about that with dialogs.
benny1967
2009-03-06, 21:44
The application menu can store until 15 items in the same screen (see the screenshot), if you have more than 15 items you can see the other items scrolling (kinetically) until the rows below.
is there i way to organize applications systematically (like the well-established menu/submenu-structure) so you don't have to scroll planlessly through an unsorted list? having 50+ items in the menu and no way to group them would be quite a challenge. are the blue "example"-entries folders?
A fun tip for playing with the new UI on your existing tablet:
Install x11vnc on your Scratchbox machine; then, after the Xephyr :2 -screen 800x480x16 ... & line, do the following:
x11vnc -display :2 -nopw
Note the port that is being shared, and use VNC viewer on the tablet to go there (of course, start up your Scratchbox UI first). (eg 192.168.0.4:5901) Then just fullscreen the display. It's kinda scary -- it looks like you're running the new UI right on your tablet. It lets you try out the applications using your fingers. The kinetic scrolling isn't great (finger swipes don't translate well, I guess), but it works well enough for testing and you can tap on all of the buttons with your finger and get an idea for how big things will be on a portable screen.
In other news, I couldn't just untar the maemo5 armel rootstrap into a partition on my tablet and then chroot into it; I get an "illegal instruction" error (or something).
I also see why the GTK dialog box should be OK in Fremantle; the dialog boxes span the entire width of the screen. The problem occurs when taking the Fremantle-GTK dialog boxes and trying to sqeeze them into Diablo-sized dialogs. This is what was happening to me...
qole, you just gained a whole new bottle of absinthe at the next summit!
is there i way to organize applications systematically (like the well-established menu/submenu-structure) so you don't have to scroll planlessly through an unsorted list? having 50+ items in the menu and no way to group them would be quite a challenge. are the blue "example"-entries folders?
I think so, though I haven't tested it.
I know two things that could be referent to this:
* A new property in the .desktop files: X-Maemo-Category (for example in the control-panel this property is Main).
* maemo-select-menu-location is deprecated now, and it does nothing.
benny1967
2009-03-07, 11:26
I know two things that could be referent to this:
* A new property in the .desktop files: X-Maemo-Category (for example in the control-panel this property is Main).
* maemo-select-menu-location is deprecated now, and it does nothing.
X-Maemo-Category sounds promising. it'd interesting to know, though, why the regular "Categories" wasn't used. there's probably something that X-Maemo-Category does differently.
X-Maemo-Category sounds promising. it'd interesting to know, though, why the regular "Categories" wasn't used. there's probably something that X-Maemo-Category does differently.
I think with the new property in the .desktop files it's more freedesktop compliant than with the old system. If there is other technical reasons to use it, I don't know (yet).
benny1967
2009-03-07, 12:19
I think with the new property in the .desktop files it's more freedesktop compliant than with the old system. If there is other technical reasons to use it, I don't know (yet).
thats what i meant: it's cool because it looks a lot like the freedesktop-standard. but: there has to be a reason why they didn't use the real freedesktop-property in the first place. maybe you can only use one X-Maemo-Category (which would make sense in the context of such a device) whereas the regular freedesktop-property "categories" is designed to accept a list of items. is that it? is X-Maemo-Category restricted to one value?
Autobuilder for Fremantle now available (http://lists.maemo.org/pipermail/maemo-developers/2009-March/054298.html). If you have packages uploaded in Diablo extras-devel please follow the discussion in maemo-developers since they might be uploaded automatically to the Fremantle extras-devel repo (and see how many of them build).
Also, I have started a list of Fremantle early ports (http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle#Fremantle_timeline), trying to offer the most relevant/illustrative link for each of them. Many point to posts to this very same thread. :)
Also good to see that Fremantle app news and screenshots are starting to spread: http://arstechnica.com/open-source/news/2009/03/developer-ports-frets-on-fire-to-maemo-5.ars
Does anyone know how portrait/landscape mode will work (see http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle which links to https://bugs.maemo.org/show_bug.cgi?id=644)? Will there be a 'default' or 'preferred' mode? With other mobile devices, portrait is the default mode.
How will dialogs work in portrait? The big OK button on the right-hand side will take up even more room in portrait, so do they automatically move to the bottom of the dialog or similar?
Does anyone know how portrait/landscape mode will work (see http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle which links to https://bugs.maemo.org/show_bug.cgi?id=644)? Will there be a 'default' or 'preferred' mode? With other mobile devices, portrait is the default mode.
How will dialogs work in portrait? The big OK button on the right-hand side will take up even more room in portrait, so do they automatically move to the bottom of the dialog or similar?
Like Quim says, "Portrait mode will be supported at a platform level in Fremantle, in addition to the usual and default landscape mode. Note that this doesn't mean that all applications will have portrait mode automatically."
Landscape is the default mode, as previously. Applications can provide portrait mode, if it is necessary. Dialogs do look different in portrait, as far as I remember.
Thanks, I should have read the bug more closely to see that landscape was the default. It would be good if developers were encouraged to support portrait, at least, e.g. with a style guide giving help about how to lay out apps in the different orientations.
Does anyone have any portrait screenshots, esp. with dialogs?
Maybe not so interesting, but here's some screenshots of Leafpad running in Fremantle
mikkov: Interesting how the drop-down menu looks mis-aligned, and "Find and Replace" goes outside the button. I wonder why?
benny1967
2009-03-14, 21:03
also, it seems the application is "dimmed" in the background while the application menu is showing. gives the impression of an application that's locked or no longer responding.
mikkov: Interesting how the drop-down menu looks mis-aligned, and "Find and Replace" goes outside the button. I wonder why?
Do you mean how the menu is in center instead of left? That's how all menus are placed in Fremantle SDK.
"Find and Replace" just seems to be too long string for the layout. This is exactly same code as diablo version where it works fine.
benny1967
2009-03-14, 21:40
"Find and Replace" just seems to be too long string for the layout.
anybody knows if there's a reason for this odd placement of buttons in fremantle? it breaks most layouts, always looks close-packed and wastes space above. for all these drawbacks, there must be a reason for these buttons to be where they are.
Probably your right thumb :)
benny1967
2009-03-14, 22:58
Probably your right thumb :)
i don't see the position of my right thumb changing if the content of the dialog would be above the "find and replace" button, not tucked away to its left.
it looks a little broken the way it is... same as the centered application menu.
GeneralAntilles
2009-03-14, 22:59
it looks a little broken the way it is... same as the centered application menu.
I imagine all will become clear once you have a device in your hands. :)
The device will have an automated right thumb controlled with bluetooth ;) The button is this big because the chinese plastic these days can't be trusted to hit smaller target. :D
benny1967
2009-03-14, 23:11
The device will have an automated right thumb controlled with bluetooth ;) The button is this big because the chinese plastic these days can't be trusted to hit smaller target. :D
good reason. seeing what's being done here, i'm close to believing it. ;)
otoh, if you think of it, a button along the bottom of the screen would be even bigger (much bigger) and an easier target for chinese plastic bluetooth thumbs. this way, they could even bring back the "cancel"-button and make it less confusing as a result.
I imagine all will become clear once you have a device in your hands. :)
Yes please! I need to have it all become clear. Right now.
I'll cover shipping and handling, and I'll sign an NDA;)
Regarding all the questions about color choices, dialog boxes, and over all "store front" issues... Has a theme maker been released yet?
Having been involved at this level of the SDK for a number of cell phone models it has been my experience that the colors used in the SDK are almost never used in the as shipped product, at times quite a few widgets seen in the SDK never make it to production, and buttons, dialog boxes, and icons are seldom finalized until a theme maker has made the rounds so that tweaks can be made.
The amazing thing here is that we are all privy to, and can provide meaningful input based on an Alpha SDK provided by the dang manufacturer and not leaked or stolen by a some character/hacker months after it is relevant to anyone. :)
This level of involvement with the eventual users of this device by Nokia is a new approach by any major manufacturer and I enjoy watching it develop and wish all a great success.
GeneralAntilles
2009-03-15, 01:15
Has a theme maker been released yet?
konttori's working on it, but it seems likely that he'll hold off until the beta when the full UI is released (rather than surgically removing features of Theme Maker to match what's in the current alpha release).
What if we start a new thread concentrating on this dialog layout issues. This thread is getting wide and long.
What if we start a new thread concentrating on this dialog layout issues. This thread is getting wide and long.
For the dialog layouts, the idea there was to get more vertical space for dialogs, while at the same time doing a change that could be done for the Fremantle scope and timeframe. Yes, horizontal space is therefore reduced, but since we're pretty much getting rid of all the split screen UI designs anyway, vertical space is more useful than horizontal space.
ColdFusion
2009-03-15, 13:27
For the dialog layouts, the idea there was to get more vertical space for dialogs, while at the same time doing a change that could be done for the Fremantle scope and timeframe. Yes, horizontal space is therefore reduced, but since we're pretty much getting rid of all the split screen UI designs anyway, vertical space is more useful than horizontal space.
How about this:
http://img120.imageshack.us/img120/4997/dialogfreemantlerecolor.png
That way you save up on horizontal and vertical space, and still have a big area for the button to touch it with your thumb.
How about this:
http://img120.imageshack.us/img120/4997/dialogfreemantlerecolor.png
That way you save up on horizontal and vertical space, and still have a big area for the button to touch it with your thumb.
Well yes, in theory :)... If you would have always only one button there and wouldn't mind the geeky vertical text. But there can be 3-4 buttons in that area, and people generally prefer to read horizontally. I'm of course very much biased, but I think that the new dialogs and notes look ... much better than the old ones, on the final hardware.
benny1967
2009-03-15, 15:56
But there can be 3-4 buttons in that area,
... like "cancel".
anyway, the last word on the UI pobably was spoken long ago. I didn't see any encouragement or even friendly interest in this thread when improvements were discussed. - So either the final thing will be totally different and absolutely breathtaking, anyway, so that it's no use discussing this alpha-UI... or we'll have to count on Mer (or future versions of Maemo) to iron things out.
I still hope what we're seeing isn't it but something hastily put together to make a public alpha possible at all without revealing even a tiny bit of the final UI.
Short video demonstration of Maemo 5 Alpha :)
http://www.youtube.com/watch?v=AiNF4C1p030
The application manager doesn’t work for me, and the Fremantle extras-devel repository doesn’t list the available packages trough the web, so I only showed in the video the apps that I know that are already in the repository.
ColdFusion
2009-03-15, 17:57
Well yes, in theory :)... If you would have always only one button there and wouldn't mind the geeky vertical text. But there can be 3-4 buttons in that area, and people generally prefer to read horizontally. I'm of course very much biased, but I think that the new dialogs and notes look ... much better than the old ones, on the final hardware.
There are 6 buttons there in the screenshot. ;)
imho...
there can be even 2 vertical buttons on the side and it'll still be useful. And a dialog box doesn't need much more buttons, especially if "cancel" is "click outside". Also it's better to have a long vertical button where the caption fits as to have a small horizontal one where it's either abbreviated or goes outside of it's boundaries.
On my "old and deprecated" device I can use very efficiently the whole right side of the screen with my thumb. Reading a few button caption vertically won't be that bad or you can put some meaningful icons instead.
I can't understand why you want to have a tiny button (which one has to "click" with a thumb) and huge empty space that's not used for information display or anything else. If you want it so badly, stretch the button to take the whole empty space on the right.
Right now all the arguments are settled "you users are wrong, on the final device you'll be able to see the bigger picture (which is secret right now and we can't tell you, but it'll be awsome)". We're presented with an Alpha, which in the "normal world" means "we're open for suggestions, discussion and feature requests", but at this moment I don't see a lot of interest from nokia in that regard. We're only told to have "faith" that "nokia knows best".
I hope that you can see where the frustration comes in the users. And I really hope, that when the final device is in our hands you might be more inclined to listen to people's suggestions. ;)
Short video demonstration of Maemo 5 Alpha :)
http://www.youtube.com/watch?v=AiNF4C1p030
Note that the apps demoed are straight ports from Diablo or the Linux desktop, not optimized for Maemo 5. This includes Maemopad, that was included in the alpha as an example of an app that works just recompiling. Even the Application Manager has got the minimum adaptations for the new UI.
But this is the first Fremantle screencast I'm aware of. Thanks!
PS: I'm going to open a new thread right now about the dialog box UI. Give me some time.
there can be even 2 vertical buttons on the side and it'll still be useful. And a dialog box doesn't need much more buttons, especially if "cancel" is "click outside". Also it's better to have a long vertical button where the caption fits as to have a small horizontal one where it's either abbreviated or goes outside of it's boundaries.
-- Reading a few button caption vertically won't be that bad or you can put some meaningful icons instead. --
Right now all the arguments are settled "you users are wrong, on the final device you'll be able to see the bigger picture (which is secret right now and we can't tell you, but it'll be awsome)". We're presented with an Alpha, which in the "normal world" means "we're open for suggestions, discussion and feature requests", but at this moment I don't see a lot of interest from nokia in that regard. We're only told to have "faith" that "nokia knows best".
I hope that you can see where the frustration comes in the users. And I really hope, that when the final device is in our hands you might be more inclined to listen to people's suggestions. ;)
Well, aesthetically I would consider vertical text to be a disaster, especially when there would be more than one button on that area. It is not a scalable solution anyway.
You don't want to do a design where the total width of the available content area on the left would depend on the amount of buttons on the right (where each new button would make the available area slightly narrower). There can be cases where the content presentation on the left is the same for multiple dialogs, possibly with different amount of buttons on the right.
There are some limitations in how much we are able to discuss at this stage, sorry about that. Once the beta and the final product comes out, it's easier to say more. Anyways, I still believe that this here is one example of the discussion part of the alpha release. :)
Actually the right place to discuss the the dialog box was not a new thread but
Dialog button position/layout changed
https://bugs.maemo.org/show_bug.cgi?id=4183
Right now all the arguments are settled "you users are wrong, on the final device you'll be able to see the bigger picture (which is secret right now and we can't tell you, but it'll be awsome)". We're presented with an Alpha, which in the "normal world" means "we're open for suggestions, discussion and feature requests", but at this moment I don't see a lot of interest from nokia in that regard. We're only told to have "faith" that "nokia knows best".
I hope that you can see where the frustration comes in the users. And I really hope, that when the final device is in our hands you might be more inclined to listen to people's suggestions. ;)
The quotes are yours. :)
This SDK represents the first *public* alpha release of the Maemo 5 UI, but such UI has gone through an extensive period of development and testing, including user testing and specific usability testing. Briefly said, regular users were happy.
Does this mean that the doors for feedback are closed? Of course not, but this doesn't mean that we will automatically accept the conclusions made in this thread based on (screenshots of) straight Diablo / Linux desktop ports in an SDK. ragnar and I are providing arguments about why we think the changes are good.
And you must realize that you are not regular users either. Of course Till misses a Cancel button. He wrote the code for that! :) But is the average Maemo 5 user going to miss it? Are you going to miss it the day after you get your new device? We think you won't.
http://www.internettablettalk.com/forums/attachment.php?attachmentid=3243&stc=1&d=1237061656
mikkov: Interesting how the drop-down menu looks mis-aligned, and "Find and Replace" goes outside the button. I wonder why?
I would say not bad for a straight port of a Linux desktop application (with not the best HIG implementation in that dialog box?).
- Rename "Find and replace" for "Replace"
- Change the checkbox "Replace all at once" for a "Replace all" button to go under the "Replace" button.
and the dialog will improve significantly. Note that those changes are probably good for the desktop version too, so no need to fork. At least Gedit and OpenOffice.org treat Replace/Replace-all this way.
Said that, something that would be good to check with the UI designers is what to do with button label texts longer than the button itself. Seing the text going off the button is really bad so there is room for improvement there, I guess. Either the button accepts more than one line of text or cuts the text. I will ask, but if someone wants to file a bug to keep track it will be appreciated.
I still hope what we're seeing isn't it but something hastily put together to make a public alpha possible at all without revealing even a tiny bit of the final UI.
What you are seing are basically Diablo or Linux desktop apps recompiled for Fremantle. I wonder whether the it you are missing is caused for that or is it really because the Maemo 5 UI is not matching your expectations. If the latter, can you describe your expectations?
To be clear, let's split the Maemo 5 UI:
- System UI: home, status bar, task launcher, task switcher... anything happening "outside" the applications. As said in the alpha sdk announcement, there are some pieces still missing here.
- Optimized application UI: what you get squeezing the new UI elements following the guidelines (that will be released as soon as they are ready, not yet). We haven't seen anything yet, but Hildon is alrady providing all the elements for the developers willing to give it a try.
- Legacy application UI: all the elements kept to ease the compatibility between Diablo & Linux desktop apps. And this is what all these straight recompiles are using.
benny1967
2009-03-15, 22:16
I wonder whether the it you are missing is caused for that or is it really because the Maemo 5 UI is not matching your expectations.
not matching expectations.
If the latter, can you describe your expectations
Yes: "Wow!"
I knew from the information I had before that the Maemo5 UI wouldn't be one I would love to work with - simply because I'm the "my N800 is my laptop and runs Gnumeric" type of user and I understood you're not heading my way. (Which is OK, you got me under your spell meanwhile and I'll move your way if I have to.)
But (or rather: Therefore) I also expected the Maemo5 UI would make me go "Wow!" looking at it, if not using it. Clever design, revolutionary ideas, best in class, something you look at and say: "Of course it has to be this way! Why didn't I invent this?!"... Something that's just cool, beautiful, sexy. Something that makes St. Jobs want to buy one.
Now we have missing "Cancel" buttons and menus in the wrong places (breaking the most basic rules of graphical UI design), wasted space and strangely re-positioned buttons, squeezed lists and whatnot, all for no apparent reason other than "because we can". (Or so it seems - I wrote above that I still think it all will be different when the real thing's out.)
- Optimized application UI: what you get squeezing the new UI elements following the guidelines (that will be released as soon as they are ready, not yet). We haven't seen anything yet, but Hildon is alrady providing all the elements for the developers willing to give it a try.
- Legacy application UI: all the elements kept to ease the compatibility between Diablo & Linux desktop apps. And this is what all these straight recompiles are using.
These are the things I'm referring to when talking about a "Maemo5 UI", not the (mostly missing) part "outside the applications".
What we've seen so far were some screenshots of new widgets (http://share.ovi.com/channel/yerga.Hildonwidgets) (maybe even from a pre-Alpha?) that are particularly uninspired (http://share.ovi.com/media/yerga.Hildonwidgets/yerga.11983) (and no, I'm not referring to theming or the missing labels).
Mostly, however, there's what you call "legacy application UI". Personally, I had expected that they should look as good as on Diablo, if not better. In reality they all look more or less broken, with captions being cut off and lists showing only part of their contents. (see this (http://www.internettablettalk.com/forums/showthread.php?p=269233#post269233) and this (http://www.internettablettalk.com/forums/showpost.php?p=269351&postcount=104) post for bad examples.)
So yes, it's about personal expectations... after all, if I liked Diablo, I should love Fremantle, shouldn't I? Now I find I don't really. All I've got is the hope that as Fremantle will grow out of alpha-stage, it'll grow on me.
I must say, having the gtk applications composited and running in the new framework has surprised me :)
I'm sure the theming thereof will be tweaked and adjusted until its as comfortable as it can be.
Whats going to be interesting indeed is what we can achieve with clutter itself.
The video vdvsx posted gives a glimpse of this with the system UI (which was totally lost on me until today)
glancing at the capabilities it looks like we may be able to do stuff which I stress and strain to achieve on the 8x0 easily :)
does anyone know how to use the lower level cogl actor classes?
I will need to be able to draw GL lines.
Whats going to be interesting indeed is what we can achieve with clutter itself.
The video vdvsx posted gives a glimpse of this with the system UI (which was totally lost on me until today)
Oh, man, that's too bad! I installed Scratchbox and ran the i386 SDK desktop (are we going to have to wait for the beta before the armel one works?), and that level of UI responsiveness is what I got out of the box.
Perhaps my setup is important: I have an nVidia 8800 series video card and I'm running Ubuntu 8.04.
And by using my x11vnc tip that I gave above, I can use that UI on my N800. It looks at least as good as the YouTube video, and I can use my fingers to do the clicking. The biggest problem on the N800 is the lack of a virtual keyboard.
lcuk: Perhaps you need one machine with a medium- to high-end nVidia card running Ubuntu (at least, dual booting to Ubuntu) to do dev work on Fremantle... You can use x11vnc to forward the display to your touchscreen devices...
I'm of course very much biased, but I think that the new dialogs and notes look ... much better than the old ones, on the final hardware.
Can I clarify, do you mean "final hardware" or "final UI" or "with our polished applications"?
I wonder whether the it you are missing is caused for that or is it really because the Maemo 5 UI is not matching your expectations. If the latter, can you describe your expectations?
My expectations in 2008 were that the UI would be like Diablo, but better. What do I mean by "like Diablo"? I mean the basic user input/output paradigm that tended to distinguish Diablo/Hildon UI from other mobile based UIs at that time, and which caused my preference for Diablo. Flexibility and configurability, multitasking, utilization of a pointing device, zoom and switch view keys, stylus support, etc. (Granted there was some overlap with previous inactive UIs, but Hildon was distinct) What do I mean "but better"? Quicker switching between tasks, no rendering delays, no scrolling delays, more logical and intuitive menus for more prevalent use cases, and some fatter, finger friendly, buttons are OK. Simple, but vitally important things, that would then work appropriately and not with the limitations of the previous HW generation.
My expectations are now more like optimistic hopefulness because of previous comments on this forum that it is difficult to simultaneously support finger-friendly with other UI paradigms, and that some distinguishing elements of Hildon may be dropped (if not from Maemo, then from the next device). If I look at Maemo 5 UI, will I instantly recognize that it is based on an updated and improved version of Hildon, and not as similar to Ubuntu Mobile or iPhone or Pre? I am beginning to doubt that. There's been enough said about significant changes that Nokia's idea of better is a subjective reworking of the UI which may or may not be my idea of better (and might in fact be drastically different).
ColdFusion
2009-03-16, 17:38
Well, aesthetically I would consider vertical text to be a disaster, especially when there would be more than one button on that area. It is not a scalable solution anyway.
Like I said, put some icon instead of text. I don't mind having vertical text, but that's probably me.
You don't want to do a design where the total width of the available content area on the left would depend on the amount of buttons on the right (where each new button would make the available area slightly narrower). There can be cases where the content presentation on the left is the same for multiple dialogs, possibly with different amount of buttons on the right.
No, you got me wrong.
Excuse my crude mock up, but I'm in a hurry right now.
http://img228.imageshack.us/img228/4997/dialogfreemantlerecolor.png
You can have only one big button on the left or right (like in my old mock up), or have them both at the same time. That way you can have one action with the left thumb and a different action with the right thumb. Or you can have a maximum of 4 buttons on the dialog if they're split in half (like I numbered them there) and you'll still have "cancel" as "click out". That makes 5 actions utilizing the same space that you have now in your dialogs, but with more convenient and efficient thumb navigation, because the buttons are bigger.
I have too made my own usability testing on my n800 with me as the only tester. And I'm really happy with it! So you can say that my usability testing was 100% successful :p
Well anyway, that's my idea, having the limited information that's presented to us. ;)
This SDK represents the first *public* alpha release of the Maemo 5 UI, but such UI has gone through an extensive period of development and testing, including user testing and specific usability testing. Briefly said, regular users were happy.
Happy with the Alpha UI that we see now, or with a mock up of the *final UI* installed on the next device?
That's a very important question, because I don't think that they would be happy if they had to use the UI as we see it now. That's why some of us here are not happy. :)
Does this mean that the doors for feedback are closed? Of course not, but this doesn't mean that we will automatically accept the conclusions made in this thread based on (screenshots of) straight Diablo / Linux desktop ports in an SDK. ragnar and I are providing arguments about why we think the changes are good.
Well but that's all we have! Give us a mock up of the "final UI", give us an inside how the new device would look like, be designed and used (with both hands, with thumbs and a hw keyboard, with eye tracking, accelerometer navigation, mind reading), give us some example apps that are designed specifically with Fremantle in mind.
That's the only way you can get meaningful feedback. We can't be of help if we don't have enough information. But like I said, I'm not really sure that nokia wants such feedback from us.
Happy with the Alpha UI that we see now, or with a mock up of the *final UI* installed on the next device?
That's a very important question, because I don't think that they would be happy if they had to use the UI as we see it now. That's why some of us here are not happy. :)
--
Well but that's all we have! Give us a mock up of the "final UI", give us an inside how the new device would look like, be designed and used (with both hands, with thumbs and a hw keyboard, with eye tracking, accelerometer navigation, mind reading), give us some example apps that are designed specifically with Fremantle in mind.
That's the only way you can get meaningful feedback. We can't be of help if we don't have enough information. But like I said, I'm not really sure that nokia wants such feedback from us.
Tested with the final UI, and/or as good simulations as were available the time, naturally. Alpha release wasn't really an UI showcase by any means. The beta SDK is coming "soon'ish" and will give you a better idea on things. We can't be giving mock-ups before that, sorry.
Then again, you're completely right about the example apps and so on. Actually we were discussing this exact topic over lunch with qgil. Things tend to make more sense if they are explained. :)
I think the next-generation hardware will be powerful enough to run desktop software, but the new UI seems to be continuing the demand that software has to be "ported" and "hildonized" to the new UI.
I strongly believe the best UI is one that can scale gracefully to handle various levels of complexity without breaking. But the other school of thought says that the more complex apps should squeeze themselves through the keyhole of the UI if they want to run under that UI. Desktop UIs tend to follow the first paradigm, mobile UIs tend to follow the second one.
If you want to know what side of the UI fence you're on, ask yourself, what is wrong with this dialogue box: the label is too big, or the button is misplaced/too small?
http://internettablettalk.com/forums/attachment.php?attachmentid=3243&stc=1&d=1237061656
If you want to know what side of the UI fence you're on, ask yourself, what is wrong with this dialogue box: the label is too big, or the button is misplaced/too small?
http://internettablettalk.com/forums/attachment.php?attachmentid=3243&stc=1&d=1237061656
According to OpenOffice.org "Replace" is better than "Find and replace", and HIG (for computer desktops) in general recommend just one word if you don't need strictly 2 or 3. Now what?
Also what is your opinion about my comments (http://www.internettablettalk.com/forums/showpost.php?p=271909&postcount=152) about this very same screenshot?
About the text going off the button, as said in the link above I think it's a bug that needs more work to make sure that texts fit always inside buttons no matter what. Can someone file a bug or should I?
Also what is your opinion about my comments (http://internettablettalk.com/forums/showpost.php?p=271909&postcount=152) about this very same screenshot?
I think that you are, as always, very diplomatic.
But I think you blame the app more than the UI.
I think it's a bug that needs more work to make sure that texts fit always inside buttons no matter what. Can someone file a bug or should I?
Thanks for taking the initiative in these things. We complain, you file bugs :)
Actually the right place to discuss the the dialog box was not a new thread but
Dialog button position/layout changed
https://bugs.maemo.org/show_bug.cgi?id=4183
Too bad it was so quickly marked "RESOLVED WORKSFORME"
lemmyslender
2009-03-17, 01:23
Would it be possible to setup a poll on the whole cancel button thing. I thi k the results could be very telling.
Having read through this thread and the bug report, my admittedly warped mind came to this conclusion:
It would make more sense to me to open up a dialog, perhaps a file chooser and having selected the file I want, click on the background to go back into the program I was working with having choosen my file. Instead of an OK button, there would only be a "Cancel" button to close the dialog if I didn't want to make a choice. It seems to me that in most cases, the background area would be larger than the button area, which would make it better suited to be the default OK choice. The larger area would make it easier to hit. "Cancel" being the non-default choice should be harder to hit otherwise you would get a lot of false "Cancel"s
Just my 0.02 cents
Would it be possible to setup a poll on the whole cancel button thing. I thi k the results could be very telling.
They would probably be telling of people being cautious and wary of changes, especially before seeing the big picture and trying the new version out for themselves, but hopefully your implication didn't try to be that the perfect UI could be done by polling internettablettalk users about UI design specifics and following the results. :)
I would have lots to say about 'democratic' design processes and what the end result usually ends up being, but perhaps the short version is that I don't really believe in polling in cases like these.
benny1967
2009-03-17, 11:18
I would have lots to say about 'democratic' design processes and what the end result usually ends up being, but perhaps the short version is that I don't really believe in polling in cases like these.
Also, UI design is not about personal preferences as are expressed in polls, no matter if it's a poll on ITT or a world wide poll among all Nokia customers.
UI design is a trade you learn, much like carpenter and plumber. There are books about it, teaching you pretty boring rules to follow, things you have to do, things you mustn't do, processes for quality control... And there's a well defined set of contradictory aims that you need to know about and that you will need to balance. The rest is experience.
You'll also find that most of the times, the best UI is the one you don't like and wouldn't vote for (if given a choice), because it's more efficient and let's you do you daily tasks much quicker and easier than the nice and friendly one you'd have voted for in a poll.
ColdFusion
2009-03-17, 12:06
Well I don't think there is a "best" or "right" UI. It's pretty much very vague and subjective. There are _some_ guidelines and some ways of doing things, just because people are used to some things that have been established. It's not universal and not an exact science.
With the tablets we have the opportunity to invent some truly unique and new UIs because in itself it's a unique and new platform. We don't have to stick with desktop paradigms and things that make sense outside of the tablets.
We don't have all the information to make a democratic poll. If everyone would get the new device and test in real life situations the various proposed UIs for a period of time, only then could we make an informed voting.
lemmyslender
2009-03-17, 13:22
I was probably thinking more along the lines of a generic poll, not specifically related to this. Certainly, a UI designed by majority vote would be horrific and nobody would be happy with it (well maybe 2 people).
I just keep reading things like "no major problems in testing", which lead me to believe that there were "minor" problems, which is to be expected. I just wonder about the definitions of major and minor.
As an example: a group does a study and determines that pedaling a bicycle backwards is more efficient, producing more power and is better exercise. They have data to back this up. A company decides to produce the bicycle. Testers are hired and instructed how the bicycle works. After using the bicycle for a couple of days, the users agree that it seems to be better exercise and more efficient, a very few have trouble getting the hang of it
(minor problems). The bike goes into production and gets sold at Walmart.
I'd bet that even though the change should be for the better and improve bicycles as we know them, most people would end up returning them the next day, since they don't work as expected (pedaling forward). Over time enthusiasts may begin pushing it mainstream, but that could be much further down the road.
I guess it seems that it wouldn't take much more to enable some kind of cancel button, or "x" and make both methods work, to ease backward compatibility and allow users the chance to make the shift.
...it wouldn't take much more to enable some kind of cancel button, or "x" and make both methods work, to ease backward compatibility...
The "x" button wouldn't just be for compatibility, it would be for consistency. The notion of "click on any window's close button to get rid of it" is pretty-much universal and it would be a shame to break it. The convention for a close button is "x", or red, or both.
If I have to click outside a dialog box to close it, part of my brain is forever going to be feeling like I've clicked on another window to bring it to the front, and hidden a modeless dialog. It's not an interface that will feel right when I use it. I hope Nokia re-thinks this one.
Regards,
Roger
The big "X" button is always there in top right corner. I thought that only way to close dialogs was to press that "X" until I read here that you can click any part of the background.
- Rename "Find and replace" for "Replace"
- Change the checkbox "Replace all at once" for a "Replace all" button to go under the "Replace" button.
I tried these suggestion and they work very well. In normal GtkDialog replace button and replace all check box are above each other without modifications.
Reason for "Find and Replace" must be that there is GTK_STOCK_FIND_AND_REPLACE but no GTK_STOCK_REPLACE. So changing text to "Replace" produces untranslated string which is basically too much work :)
Note that if you convert the "Replace all" checkbox by a button just like "Replace" you save one click to the user and you probably get an even nicer layout. Again, this is what at least Gedit and OOo do.
Note that if you convert the "Replace all" checkbox by a button just like "Replace" you save one click to the user and you probably get an even nicer layout. Again, this is what at least Gedit and OOo do.
Ah didn't quite catch that. But this was minimum effort change :)
Note that if you convert the "Replace all" checkbox by a button just like "Replace" you save one click to the user and you probably get an even nicer layout. Again, this is what at least Gedit and OOo do.
Replace All is too dangerous to be made a button in my world.
GeneralAntilles
2009-03-17, 20:28
Replace All is too dangerous to be made a button in my world.
Really? Most developers don't seem to think so. Besides, that's why there's Undo.
Yeah, for Replace in Files too ;) And this is not a developer application.
GeneralAntilles
2009-03-17, 20:55
And this is not a developer application.
Developers: the people who write applications that users use.
One solution is to stop calling these things "Dialog Boxes." What class of thing is the on-screen keyboard? It doesn't seem to be a "Dialog Box" and it has a button to hide it. Sometimes I can hide it be tapping outside of its context. Sometimes not. But it seems I can always make it disappear if I place a "Window" (including dialogs but not popups) in front of it. I choose to call it a "Context Popup Thing." Well, the new "Find and Replace" looks like one of these.
And sorry, but an "X" in the window frame of a "Dialog Box" is optional. Sometimes the designer adds/removes the window frame and/or its functions based on modality or context. Your typical options for getting rid of a "Dialog Box" are "OK", "Cancel" or <escape>. Not "X". Especially in Hildon. If there's an "X," it might just be a "Window." If it is a "Window" and it's not "fullscreen", there should be an "X." But if it's a "Context Popup Thingy," something like the on-screen keyboard's bottom-right "lower" button seems just fine.
Clicking outside "Popup Menus" to remove them is normal and we're used to it. The same is just not true of "Dialog Boxes." And it's not really true for these "Context Popup Things."
These are just the facts (and maybe one or two opinions). Where things are going from here sounds like a slight morphing. But in the end it's just software...
GeneralAntilles
2009-03-17, 21:24
I see. Thank you.
My point is, most applications provide a Replace All button.
Reason for "Find and Replace" must be that there is GTK_STOCK_FIND_AND_REPLACE but no GTK_STOCK_REPLACE.
Can you raise a bug (http://bugs.maemo.org/) suggesting that in Fremantle the English test for [font=monospace]GTK_STOCK_FIND_AND_REPLACE[/URL] is "Replace", and point to Quim's message?
Can you raise a bug (http://bugs.maemo.org/) suggesting that in Fremantle the English test for [font=monospace]GTK_STOCK_FIND_AND_REPLACE[/URL] is "Replace", and point to Quim's message?
Isn't this a bug against GTK+ upstream and not Hildon/Maemo?
Isn't this a bug against GTK+ upstream and not Hildon/Maemo?
I think it should be raised in bugs.maemo.org for three reasons:
It is typical to report bugs to your provider, who is then responsible for liaising with upstream (admittedly, here this is a low-level developer-focused bug, so this may not apply so strongly)
This is more acute for Maemo - and especially in fremantle - where space is restricted and the button size in a dialogue box (where this text is most likely to appear) is fixed.
This should be fixed for the fremantle release, and it going upstream to some future Gtk+ version (if at all) is not going to help Maemo developers and users.
From point #3, a bug could be raised saying "fix bug #FOO from bugs.gnome.org in Maemo 5 Gtk+ before release", but there's still then a bug in bugs.maemo.org, just proxying upstream.
Andre Klapper
2009-03-18, 13:46
I'm fine if you go ahead and file a bug in bugzilla.gnome.org and post the bug ID here, and I'm also fine if you file a bug in bugs.maemo.org that I can forward to bugzilla.gnome.org.
https://bugs.maemo.org/show_bug.cgi?id=4219
Here's set of aisleriot screenshots
(and what the heck is happening to picture sizes?)
Master of Gizmo
2009-03-19, 21:13
Of course Till misses a Cancel button. He wrote the code for that! :) But is the average Maemo 5 user going to miss it? Are you going to miss it the day after you get your new device? We think you won't.
I missed it, because i was expecting things to happen in error. The average user faced with this will say "Wait, no cancel button? There must be another way to close the dialog!". I just though "No cancel button? The SDK is broken". The average user would never come to the same conclusion i came to.
What i in fact did was to click the X in the upper right corner and the dialog diappeared. But i once more wasn't sure if it was closed by a failure in the framework or by purpose. Again, an end user won't expect this to be a bug. He'd just think "ok, i clicked the X, now the dialog is gone. This seems to be the way things are supposed to work here".
Single major problem with this: He thinks clicking the X is the supposed way to close the dialog which it in fact isn't. But i can live with that ...
konttori
2009-03-19, 21:18
actually the cancel behavior feels pretty intuitive when you use it in practice. Also, it's a one time learning experience.
Getting back to the close button discussion...
First time I deal with the new UI, it seemed pretty logic to me, that clicking outside of the dialog will make it disappear, but since I'm a HCI enthusiastic and so much people here have complains about the lack of close button, I decided to expose the UI to regular computer users.
I asked five friends (windows and mac user's) and three familiars (ubuntu user's - chat, web and office only), to test the Fremantle UI. Just a small test in order to expose them to the lack of close button.
Five of them, used the UI without any complains, and don't even blink when they have to hit outside the dialog to close it. The other three made me two different question:
"Where is the close button ?" and "Should I click outside the dialog to close it ?"
But I didn't have enough time to answer, because they actually close the dialog without my help.
Note that none of this people are programmers/geeks/power users, after the test I asked them: "Why do you clicked outside the dialog to close it ?", and the answers was mainly this two:
"The dialog seems like a pop-up to me, so I clicked outside of it, in order to close it ".
"Why not, when I have layered windows in my desktop and I want to switch the focus to another window, I click in the window that I want".
So in my opinion we can't call this a "Norman interface", I think the majority of the users will learn how to close the dialog in seconds, and as was said before it's a one time learning experience.
My 2 cents :P.
Laughing Man
2009-03-31, 03:29
VDVsx, I'm an HCI junky too! In fact I'm an undergraduate in a Psychology lab dealing with HCI issues right now. Going into a masters program in Fall for Human Factors Psychology. :)
I think this dialog seems to make more sense too, though I can think of one problem (I haven't tried the alpha out myself). Is this something you could hit accidentally?
allnameswereout
2009-03-31, 16:06
Here's set of aisleriot screenshots
(and what the heck is happening to picture sizes?)The scrollbar is not optimized for finger usage. The buttons on the bottom aren't either. While scrollbar is not a big deal I think buttons on bottom is a bit difficult to do this on the 800x480 screen because if you use too big buttons (combined with the top bar) there is not much left of the 480 pixels.
VDVsx, I'm an HCI junky too! In fact I'm an undergraduate in a Psychology lab dealing with HCI issues right now. Going into a masters program in Fall for Human Factors Psychology. :)
I think this dialog seems to make more sense too, though I can think of one problem (I haven't tried the alpha out myself). Is this something you could hit accidentally?
No think so, you can see a example here: http://www.youtube.com/watch?v=AiNF4C1p030
(http://www.youtube.com/watch?v=AiNF4C1p030) (around 00:49)
benny1967
2009-03-31, 18:26
Five of them, used the UI without any complains, and don't even blink when they have to hit outside the dialog to close it. The other three made me two different question:
"Where is the close button ?" and "Should I click outside the dialog to close it ?"
But I didn't have enough time to answer, because they actually close the dialog without my help.
;)
funny how different people draw different conclusions from the same facts. if i were responsible for this project and you confronted me with these figures, i'd say:
3 out of 8 people react confused when confronted with the new changes
the new style doesn't bring any advantage
the new style breaks established cross-platform rules
i'd call my team after your presentation and tell them to immediately re-work the whole thing.
but then... further discussing this doesn't lead us anywhere.
Also, at the Maemo summit we were told to consider one-handed use in our application design. I wonder what these dialogs do if the screen is rotated into portrait?
;)
funny how different people draw different conclusions from the same facts. if i were responsible for this project and you confronted me with these figures, i'd say:
3 out of 8 people react confused when confronted with the new changes
the new style doesn't bring any advantage
the new style breaks established cross-platform rules
i'd call my team after your presentation and tell them to immediately re-work the whole thing.
but then... further discussing this doesn't lead us anywhere.
One time learning, and they are not confused, otherwise they probably will not act without others help.
Innovation/difference is a advantage.
This style follow the principles that I learned in HCI, and in IMHO, I don't see any rule breaked here.
Best regards.
Also, at the Maemo summit we were told to consider one-handed use in our application design. I wonder what these dialogs do if the screen is rotated into portrait?
Show on the side? :D
arsinmsn
2009-04-07, 18:56
So the question with the lack of a cancel button is: how do you teach (or remind) the user that the dialog box is closed. I think the answer is to standardize the ways boxes and windows can disappear. So a box being hidden by a window (the other likely possibility when clicking outside the dialog) should disappear differently from a box being dismissed. Presumably the style of dismissal disappearance would be similar in style to what happens to a window when its application has closed. Some small animation might be appropriate.
Difference can't equal advantage. Consistency can.
The way the dialogs are anchored to the bottom of the screen makes me think that they are intended to slide on and off, which would certainly look different to another window just been brought in front of the dialog.
kanishou
2009-04-14, 10:51
So the question with the lack of a cancel button is: how do you teach (or remind) the user that the dialog box is closed. I think the answer is to standardize the ways boxes and windows can disappear. So a box being hidden by a window (the other likely possibility when clicking outside the dialog) should disappear differently from a box being dismissed. Presumably the style of dismissal disappearance would be similar in style to what happens to a window when its application has closed. Some small animation might be appropriate.
Clicking outside a window will always close it, it won't get hidden by selecting something behind it. It's a common mechanic all over the UI, so it becomes perfectly natural after five seconds of "training".
And it's really not any different than what is already very common on our desktops (menu popups are closed by clicking outside) and all over the web (navigation popups are regularly closed the same way). It's just made even more discoverable by the blurring of the background.
In this case difference does indeed equal advantage, because it's plain more effective to use the large unused space for closing instead of a small button.
kanishou
2009-04-14, 11:00
Single major problem with this: He thinks clicking the X is the supposed way to close the dialog which it in fact isn't. But i can live with that ...
This won't be an issue if the blurring is strong enough to make the X practically disappear.
It might be an issue with Mer, if the blurring cannot be implemented this way. Then again, Mer is probably mainly going to be used by people familiar with the matter.
vBulletin® v3.8.8, Copyright ©2000-2024, vBulletin Solutions, Inc.