Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
I sort of disagree with you. People do not read the manual when they get a device. They try to use it and if they have to resort to the manual the designer has failed. with so complex a device the freerunner is, it is bound to require some studying before being able to use it fully. things like a mobile phone in the 21t century should be as close to intuitive as makes no difference. and that's, i think, is the core problem: the freerunner is no mobile phone! it does not simply do calls and sms. it's a full fledged computer which allows even for phone functionality. and for intuitivity: why has mcdonalds in the us of a to print caution! hot! on it's coffee cups? who expects cold coffee in a newly purchased coffee mug? why has a microwave to say don't put pets in here!? intuitive means basically nothing else than: meet the user's expectations -- and those users are trained by other paradigms already. the start button of windows 95 needed user training (who'd guess start means shutdown?) and still there's a popup on hover telling you, what's the meaning of so integral a part of the windows gui -- after about 12 years! ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
using ms4 and if I was a granny and hit a power button I'd think I just switched off the phone, not suspend. If I hit it again I'd think that I'd powered it on again, not resume. a grannie would be able to kill herself with a spoon ... everything above a kitchen knive requires understanding how the device works, which means reading soem kind of documentation before use -- if the device does not work as expected, it's usually a matter of pebkac. especially for a device with so limited a number of physical input elements it should be perfectly clear to any user that the two buttons have more than a simple on/off function but a broad number depending upon the situation. it might be an option (as usual) to make the behaviour of the pwr button configurable: a) do only on/off b) do suspend/resume and on/off c) expose a menu to select the desired action a) would be for what you call grannies b) for those preferring fast and minmal inavise action c) for the rest focusing solely on the (imho hardly likely) group of grannies would ostracize the number of users willing to use and looking for a more advanced device not tied up in the conventional paradigms of user interaction. building smartphones for grannies is a task a lot of companies aspire -- and i doupt openmoko would be able to survive! have a look at palm: they basically abandoned palmos in favour of wince -- and their phones a re to expansive and too bad to cope with stuff from htc or so, they left their niche and found no other ... ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 arne anka wrote: using ms4 and if I was a granny and hit a power button I'd think I just switched off the phone, not suspend. If I hit it again I'd think that I'd powered it on again, not resume. a grannie would be able to kill herself with a spoon ... everything above a kitchen knive requires understanding how the device works, which means reading soem kind of documentation before use -- if the device does not work as expected, it's usually a matter of pebkac. especially for a device with so limited a number of physical input elements it should be perfectly clear to any user that the two buttons have more than a simple on/off function but a broad number depending upon the situation. it might be an option (as usual) to make the behaviour of the pwr button configurable: a) do only on/off b) do suspend/resume and on/off c) expose a menu to select the desired action a) would be for what you call grannies b) for those preferring fast and minmal inavise action c) for the rest focusing solely on the (imho hardly likely) group of grannies would ostracize the number of users willing to use and looking for a more advanced device not tied up in the conventional paradigms of user interaction. building smartphones for grannies is a task a lot of companies aspire -- and i doupt openmoko would be able to survive! have a look at palm: they basically abandoned palmos in favour of wince -- and their phones a re to expansive and too bad to cope with stuff from htc or so, they left their niche and found no other ... Cheers for that you made me laugh with the grannies with spoons comment ;-) I sort of disagree with you. People do not read the manual when they get a device. They try to use it and if they have to resort to the manual the designer has failed. I can't remember the last time I read the manual for a phone, camera, DVD player. Devices performing everyday things like a mobile phone in the 21t century should be as close to intuitive as makes no difference. No offence to anybody on this list but like a lot of you I'm happy enough with the command line for a lot of stuff and that's maybe why we're not that good at usability. I'm not suggesting that we get tied up the conventional paradigms of user interactions but just a bit of usability. I think even a granny given an iPod for the first time would have a fairly good stab at playing some music. Obviously getting music into it would be a stretch. I also don't think that OpenMoko should even attempt to give use smart phones for grannies. They should give us a hardware platform and let us, the community, do the rest. Look at the xBox media centre for the original xBox built by a community, as far as I know, and a really good usable piece of Software IMHO. At the end of the day I'm still amazed that I've got an open platform. When my capable laptop for programming arrives and I get some time I'm going to have a menu on the power button ;-) Thanks again for the laugh. Grannies with spoons -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJLb++XlbjSJ5n4BARAnw3AJ9+4rcX4UZPK4e9CoMaGCnUhkS/zgCdFqEZ na7pfezQmbfeQ1Up2yKrIFg= =bW5x -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
[Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Hello everybody! First of all, thanks to all the developers and users who made FreeRunner possible and who constantly improves the functionality of this cool device. Special thanks to the Debian team. Installation was very smooth and easy. Could have been easier if install.sh supported creating one root/boot partition to make Qi happy. Nevertheless, i repartitioned my SD by hand, mounted it, created /boot and used the remaining steps from install.sh. Also i needed to copy the kernel to an appropriate name. Ok, now to the topic: The default installation of fso-frameworkd provides quite sensible rules.yaml, that can be customized to one's needs. By default it suspends the system on short power button press. But openmoko-panel-plugin wants to show a menu on the same event. Doesn't make sense to me ;) Moreover, the problem is that the only way to disable the menu i found is to modify the source. Not quite cool. I think that handling (i.e. performing actions) events is not a job a panel-plugin should do at all. We already have oeventsd, which is flexible enough, i think. Moreover the menu presented doesn't make sense. apm -s is not what i want to perform for suspending (appropriate dbus method is). And sudo shutdown ... is not very useful in the absence of sudo (i don't mind running as root... yet). The other problem is the virtual keyboard handling. Again, i don't think it's appropriate for a panel-plugin to react on a button for showing keyboard. And it's not configurable. Imagine i want to use two keyboards with different layout concurrently for some time. I need to customize the pkill command to close only one keyboard, not both. And then i need another button for another action. And so on. What do you think about it? OT: Why can't i fine-tune the star menu of fbpanel (the part to show .desktop files)? It seems that Category list is hard-coded. Good luck! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[EMAIL PROTECTED] ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Christian Adams wrote: if you don't want panel-plugin to react on the hardware-buttons, you could edit /etc/panel-plugin.conf and remove the entry 'buttons' from the 'plugins'-line in '[main]' same with the keyboard-launcher or simply do the same via the config-panels .. I use the current panel-plugin version but i don't have any /etc/panel-plugin.conf file. Do i have to create it by hand or should it be in the openmoko-panel-plugin package? Ciao, Rainer ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Hi, On Sun, 2008-11-23 at 17:40 +0100, Fox Mulder wrote: I use the current panel-plugin version but i don't have any /etc/panel-plugin.conf file. Do i have to create it by hand or should it be in the openmoko-panel-plugin package? that depends on what you wanne do. if you want to do a systemwide configuration, you should create the file by hand. if you want a user only configuration, you can use the config menu and you will find the config in ~/.panelpluginrc (hope i spelled it right). You also can create your config and then copy it to /etc, so you don't need you editor. cu sebastian ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Hi, On Sun, 2008-11-23 at 14:40 +0100, Christian Adams wrote: What do you think about it? first: if you don't like it, just don't use it .. ;) second: everyone who want's to used the software should do it! And we are always open for suggestions or patches to improve it! (the first sounded so hard) i am working on more flexibility / configurability for the future but as i (and also sebastian) don't do this as a full-time-job, it needs some time .. ;) the next version of the panel will contain a plugin system to reduce the needed memory. but it can also be used to remove features(i.e. the buttons handling). the discussions on button handling is always the same. everyone wants to use them. an if someone uses them someone comes and says: i want to do a diffetent thing with it. i, for my case, are happy with the handling as it is. i don't understand you problem with the keyboard in your mail. can you explain it a little bit in a concrete usecase? maybe we find a solution to fit all our needs. greetings sebastian ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
