Re: Dialer UI Design
Alex does bring up some excellent points, and I would like to point to the (unfortunately closed source) media centre app for the Nokia Internet Tablet called Canola as an example, which was written in Python (distributed as byte compiled python) and uses EFL for the graphics. Everything in the app feels very smooth and for the most part is quite responsive - it's the smoothest inertial scrolling I've seen in a non-apple product (not that I like inertial scrolling very much since the distinction between select and scroll is far too small, and would stay away from it on any interface I design). The UI is fairly well designed, mostly because they listened to their users and redesigned it to address the issues brought up. The only real problem with it is that it takes quite a while to load - but that's really only a one off initial time consuming task. Oh, and of course the other problem is that it's closed source, but maybe Instituto Nokia de Tecnologia will follow Nokia's (They are now independant) lead and open it up some day. Cheers, -Ian -- http://darkstarshout.blogspot.com/ -- On the day *I* go to work for Microsoft, faint oinking sounds will be heard from far overhead, the moon will not merely turn blue but develop polkadots, and hell will freeze over so solid the brimstone will go superconductive. -- Erik Raymond, 2005 -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
On Mon, Sep 29, 2008 at 8:07 PM, [EMAIL PROTECTED] wrote: Paroli? We need more info about this I am in the dark as much as you are... Minh Seems to be a contacts+phone+messages framework implemented in Python, as far as I have found. Please. For FOSS's sake, not Python! Do you really want the dialer to blank out for a minute at a stretch while the screen is repainted? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Am Dienstag, den 30.09.2008, 15:33 +0530 schrieb Nishit Dave: On Mon, Sep 29, 2008 at 8:07 PM, [EMAIL PROTECTED] wrote: Paroli? We need more info about this I am in the dark as much as you are... Minh Seems to be a contacts+phone+messages framework implemented in Python, as far as I have found. Please. For FOSS's sake, not Python! Do you really want the dialer to blank out for a minute at a stretch while the screen is repainted? *yawn* Predujice... :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
*yawn* Predujice... *yawn* years of experience using yumex, Fedora and what not. Carefully considered Predijuice. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Nishit Dave wrote: *yawn* Predujice... *yawn* years of experience using yumex, Fedora and what not. Carefully considered Predijuice. Can you point to something specific that makes python unsuitable for a responsive GUI? I've seen unresponsive GUIs written with many languages, but it is generally a problem with the code not the language. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
On Tue, Sep 30, 2008 at 5:01 PM, Alastair Johnson [EMAIL PROTECTED]wrote: Nishit Dave wrote: *yawn* Predujice... *yawn* years of experience using yumex, Fedora and what not. Carefully considered Predijuice. Can you point to something specific that makes python unsuitable for a responsive GUI? I've seen unresponsive GUIs written with many languages, but it is generally a problem with the code not the language. How about experience? I don't know about programming or system specifics, but as a user, I have always found most programs written in python to be prone to latency in screen redraws and freeze-ups. You can test that on the FR - just try Mofi, switch to say the home screen, and switch back. You will be able to see how long it takes before text appears. I have seen this happen everywhere. Just from an efficiency point of view, don't you think a compiled program may run better than an interpreted one on a system with limited hardware capabilities. Anyway, why do I bother... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
On 30/09/2008, at 9:41 PM, Nishit Dave wrote: How about experience? I don't know about programming or system specifics, but as a user, Please don't take this the wrong way. There's a common misconception amongst non-programmers and even some less experienced programmers than anything except compiled code is going to feel slow. This is what Mickey means by prejudice, you're judging that a poor user experience is Python's fault without really understanding how things work. I'll try to explain below. You can test that on the FR - just try Mofi, switch to say the home screen, and switch back. You will be able to see how long it takes before text appears. You mean start Mofi, then switch to a different app and back to the still running Mofi? The window renders virtually instantly for me, there's a little flash of it redrawing but you really have to watch for it and it's not noticeably worse than any other app. I'm switching between xterm and Mofi on Debian on the FreeRunner. The fact I can't see it could be due to Debian using a different GTK theme, I notice the font (and hence all the widets) are much smaller on Debian than on OM 2007/8, so it might render faster. The fact that Python is used for the application logic should have zero effect on the redraw speed. This is because the code that does the drawing (GTK), is actually written in C. The Python code tells GTK once when the window is created, hey I want five buttons and a textbox with this text, in this arrangement, you figure out the rest, it's then GTK's responsibility to redraw them and tell python when a button gets clicked or a menu item is selected. In a normal application that's just using standard widgets and not doing any custom drawing, redraws (like switching between applications) shouldn't execute any Python code at all. When you click scan the interfaces freezes, but that's because it's waiting for the hardware to do the wifi scan. This is poor practice, it should really do the scan asynchronously so the interface doesn't freeze and display a spinner, or at least say Please wait, scanning At least the freeze is not very long. But again, that has nothing to do with the programming language used, it's just as easy to make the same mistake with C. Just from an efficiency point of view, don't you think a compiled program may run better than an interpreted one on a system with limited hardware capabilities. For doing math intensive stuff like drawing, compression, encryption, etc -- sure definitely -- you're trying to do hundreds of millions of operations per second. For app logic, when this button is pressed, turn on the wifi, configure it with these settings and such there's really no difference between a few thousand CPU cycles of tightly optimized C code and a tens to hundreds of thousands of cycles of Python per button click, they're both imperceptible and are both not a bottleneck. Can you tell the difference between 1 microsecond and 1 millisecond? I certainly can't. I guess one might be able to form an argument that Python has a lower barrier of entry for programmers than C so you would be more likely in general to get programs written by less experienced people, but I personally might actually call that a point in favour of Python. ;-) It also by no means implies that Python programs are *only* written by inexperienced people. I hope that makes things a bit clearer. Analysing software performance is actually a very complex process and more often than not it's not just raw computation speed that wins the day. Often your intuitions like that compiled code should be better than interpreted byte-code often do not hold, as good code can often be exponentially better than bad code, while compiling might get you at the very most only a 5 to 10 times speed boost. Also, how caching and memory is used plays a very large role in the performance of programs running on modern hardware. But for typical GUI programs processor speed is usually largely irrelevant as long as the underlying toolkit is not completely broken. If a GUI is not responding it's a problem with how the program is structured, it should be doing something asynchronously instead of blocking the event loop. Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
On Tue, Sep 30, 2008 at 6:55 PM, Alex Osborne [EMAIL PROTECTED] wrote: You mean start Mofi, then switch to a different app and back to the still running Mofi? The window renders virtually instantly for me, there's a little flash of it redrawing but you really have to watch for it and it's not noticeably worse than any other app. I'm switching between xterm and Mofi on Debian on the FreeRunner. The fact I can't see it could be due to Debian using a different GTK theme, I notice the font (and hence all the widets) are much smaller on Debian than on OM 2007/8, so it might render faster. It might be because I use a Qtopia-based installation (2008.8-update) then, and GTK might run better on Debian 'natively', I guess. The fact that Python is used for the application logic should have zero effect on the redraw speed. This is because the code that does the drawing (GTK), is actually written in C. The Python code tells GTK once when the window is created, hey I want five buttons and a textbox with this text, in this arrangement, you figure out the rest, it's then GTK's responsibility to redraw them and tell python when a button gets clicked or a menu item is selected. In a normal application that's just using standard widgets and not doing any custom drawing, redraws (like switching between applications) shouldn't execute any Python code at all. This is very informative, thanks. I still have the feeling that GUI performance is poor when the executable is written in python. Maybe its just me. But for typical GUI programs processor speed is usually largely irrelevant as long as the underlying toolkit is not completely broken. If a GUI is not responding it's a problem with how the program is structured, it should be doing something asynchronously instead of blocking the event loop. I just hope everybody follows best practices. At the end of the day, all I need is something that is responsive. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
On 30/09/2008, at 11:34 PM, Nishit Dave wrote: If a GUI is not responding it's a problem with how the program is structured, it should be doing something asynchronously instead of blocking the event loop. I just hope everybody follows best practices. At the end of the day, all I need is something that is responsive. Yep. I guess one thing that makes it difficult is that the author of a program usually knows what the program is doing in detail. They'll be thinking something like oh, the program is just enumerating the doodad configuration, that's why the interface has frozen. So they won't really notice the problem because they have a good idea what's happening internally. While a user is thinking, hey I just clicked the settings button and the program has locked up for no good reason, what the heck?!? You can try submitting a bug report about it, but unfortunately, particularly for projects with small communities, the developer is likely to think, hmm, good point, but it'd be more fun to work on adding a new whiz-bang instead, besides it doesn't really bother me, can't they just be patient and wait for it to finish loading? At least in a project with a larger community these sort of small tweaks to how the interface looks and behaves can serve as a fairly safe entry point for developers new to the project to learn the code base. To a developer these sorts of things can really seem like trivial details not worth bothering over, but often they're really quick to fix and can dramatically improve the user experience-- they're just not very exciting to work on.___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Thanks Alex for this comprehensive post, that's exactly what I had in mind and should have actually written, but was too much in a hurry. Cheers, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: Dialer UI Design
Alex has an excellent point. Both complexity time of algorithms and the lack of asynchronous work / threading are enumerations of poor programming practices, and not characteristics of a byte code interpreter or the like. Some UI lockups could easily be fixed by simply using threads, or even coding without a polling while loop, but sometimes programmers don't generally think of using these techniques, or are more focused on functionality than speed. Either way, Alex is right in that any interpreter's reduction in speed will be minimal at best. It's *MUCH* more about how you code it, not what you code it in. Matthew Lane Purdue University - Department of Computer Science Alex Osborne wrote: div class=moz-text-flowed style=font-family: -moz-fixedOn 30/09/2008, at 9:41 PM, Nishit Dave wrote: How about experience? I don't know about programming or system specifics, but as a user, Please don't take this the wrong way. There's a common misconception amongst non-programmers and even some less experienced programmers than anything except compiled code is going to feel slow. This is what Mickey means by prejudice, you're judging that a poor user experience is Python's fault without really understanding how things work. I'll try to explain below. You can test that on the FR - just try Mofi, switch to say the home screen, and switch back. You will be able to see how long it takes before text appears. You mean start Mofi, then switch to a different app and back to the still running Mofi? The window renders virtually instantly for me, there's a little flash of it redrawing but you really have to watch for it and it's not noticeably worse than any other app. I'm switching between xterm and Mofi on Debian on the FreeRunner. The fact I can't see it could be due to Debian using a different GTK theme, I notice the font (and hence all the widets) are much smaller on Debian than on OM 2007/8, so it might render faster. The fact that Python is used for the application logic should have zero effect on the redraw speed. This is because the code that does the drawing (GTK), is actually written in C. The Python code tells GTK once when the window is created, hey I want five buttons and a textbox with this text, in this arrangement, you figure out the rest, it's then GTK's responsibility to redraw them and tell python when a button gets clicked or a menu item is selected. In a normal application that's just using standard widgets and not doing any custom drawing, redraws (like switching between applications) shouldn't execute any Python code at all. When you click scan the interfaces freezes, but that's because it's waiting for the hardware to do the wifi scan. This is poor practice, it should really do the scan asynchronously so the interface doesn't freeze and display a spinner, or at least say Please wait, scanning At least the freeze is not very long. But again, that has nothing to do with the programming language used, it's just as easy to make the same mistake with C. Just from an efficiency point of view, don't you think a compiled program may run better than an interpreted one on a system with limited hardware capabilities. For doing math intensive stuff like drawing, compression, encryption, etc -- sure definitely -- you're trying to do hundreds of millions of operations per second. For app logic, when this button is pressed, turn on the wifi, configure it with these settings and such there's really no difference between a few thousand CPU cycles of tightly optimized C code and a tens to hundreds of thousands of cycles of Python per button click, they're both imperceptible and are both not a bottleneck. Can you tell the difference between 1 microsecond and 1 millisecond? I certainly can't. I guess one might be able to form an argument that Python has a lower barrier of entry for programmers than C so you would be more likely in general to get programs written by less experienced people, but I personally might actually call that a point in favour of Python. ;-) It also by no means implies that Python programs are *only* written by inexperienced people. I hope that makes things a bit clearer. Analysing software performance is actually a very complex process and more often than not it's not just raw computation speed that wins the day. Often your intuitions like that compiled code should be better than interpreted byte-code often do not hold, as good code can often be exponentially better than bad code, while compiling might get you at the very most only a 5 to 10 times speed boost. Also, how caching and memory is used plays a very large role in the performance of programs running on modern hardware. But for typical GUI programs processor speed is usually largely irrelevant as long as the underlying toolkit is not completely broken. If a GUI is not
Re: Dialer UI Design
yes fso as the base with an adaptive beyesian feedback driven user interface. it would be great to see your top actions bubble up in the interface's navigation: everyone with a customly trained 'runner. i say written in xul as xumo :) On Mon, Sep 29, 2008 at 9:23 AM, Sander van Grieken [EMAIL PROTECTED] wrote: Ian-3 wrote: Qtopia sux, it's ugly and not pratical. We need absolutely the FSO with dialer, sms and contacts ( instead of zhone ) or SHR. I think Qtopia is beautiful and the most practical at the moment. But my biggest gripe is that it's not customizable and has no open development model. I agree that FSO provides the best foundation. I'd like to see a (non-nokia/tt) Qt based UI on top of that. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Hey, On Mon, Sep 29, 2008 at 2:58 PM, Ian [EMAIL PROTECTED] wrote: I naturally hit answer call a second time and as a result hung up immediately. Probably should avoid this UI design pitfall in future dialer (and other) interfaces. I agree with Ian totally. I've faced this situation many times. If we can have the *Answer and End Call buttons in different places on the phone, it could help. -- Regards Shashank As our circle of knowledge expands, so does the circumference of darkness surrounding it - Albert Einstein ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Le lundi 29 septembre 2008, [EMAIL PROTECTED] a écrit : I'm just sending this out there for anyone working on a/the dialer UI. At the moment with the qtopia (ergo, 2008.*) dialer the same part of the screen is used for answer call as end call, and since the UI is laggy (see below), I naturally hit answer call a second time and as a result hung up immediately. Probably should avoid this UI design pitfall in future dialer (and other) interfaces. I agree too. Do you think there is a ticket open already ? Minh -- Minh HA DUONG, Chargé de Recherche, CNRS CIRED, Centre International de Recherches sur l'Environnement et le Développement http://minh.haduong.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
On Mon, Sep 29, 2008 at 5:28 AM, Ian [EMAIL PROTECTED] wrote: A note on UI response times: 10ms should be the MAX response time, anything that takes longer has just 10ms to let the user know it's going to take longer (progress bar, hour glass, etc), otherwise the reaction is disconnected from the action that caused it in the user's mind and worse, the user will press the control again. Maybe we can have something similar to the Qtopia screen unlock thing. Instead of moving a key into a lock a phone handset can be moved onto or off a receiver. Just a thought. -Charles ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
On Mon, Sep 29, 2008 at 3:32 PM, Minh Ha Duong [EMAIL PROTECTED]wrote: Le lundi 29 septembre 2008, [EMAIL PROTECTED] a écrit : I'm just sending this out there for anyone working on a/the dialer UI. At the moment with the qtopia (ergo, 2008.*) dialer the same part of the screen is used for answer call as end call, and since the UI is laggy (see below), I naturally hit answer call a second time and as a result hung up immediately. Probably should avoid this UI design pitfall in future dialer (and other) interfaces. I agree too. Do you think there is a ticket open already ? Apart from that, don't you think call management function threads should get the highest priority attached when invoked? That should help the response times. On a side note, I think there is a real need to reconsider the UI of the phone altogether. Should we start a wiki page to get user inputs? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Ian-3 wrote: Hey all, I'm just sending this out there for anyone working on a/the dialer UI. At the moment with the qtopia (ergo, 2008.*) dialer the same part of the screen is used for answer call as end call, and since the UI is laggy (see below), I naturally hit answer call a second time and as a result hung up immediately. Probably should avoid this UI design pitfall in future dialer (and other) interfaces. A note on UI response times: 10ms should be the MAX response time, anything that takes longer has just 10ms to let the user know it's going to take longer (progress bar, hour glass, etc), otherwise the reaction is disconnected from the action that caused it in the user's mind and worse, the user will press the control again. Cheers, -Ian -- http://darkstarshout.blogspot.com/ -- On the day *I* go to work for Microsoft, faint oinking sounds will be heard from far overhead, the moon will not merely turn blue but develop polkadots, and hell will freeze over so solid the brimstone will go superconductive. -- Erik Raymond, 2005 -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Qtopia sux, it's ugly and not pratical. We need absolutely the FSO with dialer, sms and contacts ( instead of zhone ) or SHR. -- View this message in context: http://n2.nabble.com/Dialer-UI-Design-tp1125436p1125600.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Ian-3 wrote: Qtopia sux, it's ugly and not pratical. We need absolutely the FSO with dialer, sms and contacts ( instead of zhone ) or SHR. I think Qtopia is beautiful and the most practical at the moment. But my biggest gripe is that it's not customizable and has no open development model. I agree that FSO provides the best foundation. I'd like to see a (non-nokia/tt) Qt based UI on top of that. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Sander van Grieken wrote: Ian-3 wrote: Qtopia sux, it's ugly and not pratical. We need absolutely the FSO with dialer, sms and contacts ( instead of zhone ) or SHR. I think Qtopia is beautiful and the most practical at the moment. But my biggest gripe is that it's not customizable and has no open development model. I agree that FSO provides the best foundation. I'd like to see a (non-nokia/tt) Qt based UI on top of that. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community FSO will be the next framework ( instead of Qtopia ) for Openmoko and it's almost complete ( we need to wail until the milestone 4 will be release ). However we need a suite for use it as a daily phone, zhone it is only a test program ... -- View this message in context: http://n2.nabble.com/Dialer-UI-Design-tp1125436p1125902.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Le lundi 29 septembre 2008, Nishit Dave a écrit : On Mon, Sep 29, 2008 at 3:32 PM, Minh Ha Duong [EMAIL PROTECTED]wrote: Le lundi 29 septembre 2008, [EMAIL PROTECTED] a écrit : I'm just sending this out there for anyone working on a/the dialer UI. At the moment with the qtopia (ergo, 2008.*) dialer the same part of the screen is used for answer call as end call, and since the UI is laggy (see below), I naturally hit answer call a second time and as a result hung up immediately. Probably should avoid this UI design pitfall in future dialer (and other) interfaces. I agree too. Do you think there is a ticket open already ? Apart from that, don't you think call management function threads should get the highest priority attached when invoked? That should help the response times. On a side note, I think there is a real need to reconsider the UI of the phone altogether. Should we start a wiki page to get user inputs? I don't know what the developper actually want, but the wiki is definitely missing a page on paroli which I think is meant to be the Dialer UI in the next major upgrade. Minh ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Minh Ha Duong wrote: Le lundi 29 septembre 2008, Nishit Dave a écrit : On Mon, Sep 29, 2008 at 3:32 PM, Minh Ha Duong [EMAIL PROTECTED]wrote: Le lundi 29 septembre 2008, [EMAIL PROTECTED] a écrit : I'm just sending this out there for anyone working on a/the dialer UI. At the moment with the qtopia (ergo, 2008.*) dialer the same part of the screen is used for answer call as end call, and since the UI is laggy (see below), I naturally hit answer call a second time and as a result hung up immediately. Probably should avoid this UI design pitfall in future dialer (and other) interfaces. I agree too. Do you think there is a ticket open already ? Apart from that, don't you think call management function threads should get the highest priority attached when invoked? That should help the response times. On a side note, I think there is a real need to reconsider the UI of the phone altogether. Should we start a wiki page to get user inputs? I don't know what the developper actually want, but the wiki is definitely missing a page on paroli which I think is meant to be the Dialer UI in the next major upgrade. Minh ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Paroli? We need more info about this -- View this message in context: http://n2.nabble.com/Dialer-UI-Design-tp1125436p1125963.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Paroli? We need more info about this I am in the dark as much as you are... Minh ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
Paroli? We need more info about this I am in the dark as much as you are... Minh Seems to be a contacts+phone+messages framework implemented in Python, as far as I have found. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
