Re: Hardware/Software UI Relationship
That's great that you have the dexterity to use your fingernails to poke at tiny buttons, but what about the wider audience? Do you think Aunt Jane or Uncle Leo would feel comfortable operating a phone with such tiny buttons? Is this even a relevant question? Is the phone being marketed to them? If not, then who? Before we dive in and start creating user interfaces from scratch we need to have some sort of basis of who will be using the phone and what they will be doing. Right now it is unclear which direction the community and FIC want to take. I have my personal ideas, but I want to get a consensus from everyone else. The Neo1973's LCD is 43mm x 58mm. Let's say you do 5 columns and 6 rows (30 buttons). In order to fill the width of the the LCD each button width should be button 8.6 mm. A reasonable height is 8 mm, which is less than the width of the button. 6 rows times 8mm is 48mm. That leaves 10mm for everything else. Subtract another 8 mm for navigation buttons and you literally have 22 pixels to have some sort of status bar plus a place to display the stuff you are actually typing. There simply isn't enough room. The iPhone's LCD is 50.8mm x 76.2mm. Let's take the 5 columns and 6 rows again. In order to fill the width of the the LCD each button width should be button 10.16 mm. A reasonable height again is 8 mm. This time you have 28.2 mm for everything else. In this case, not only are the buttons 15% bigger, you have plenty of room for everything else. 10.16mm x 8mm should be moderately comfortable. I have an alternative idea for a character input system on the Neo1973, a linearized rotary dial, but it requires that the LCD to have certain friction that would allow for the finger to slide easily down the side of the screen. My current phone has a screen that would work with this system, but I'm not sure if the Neo1973 will. Hardware needs to be conscience of software and software needs to be conscience of hardware. And this just doesn't go with the LCD, I want this idea of the hardware/software UI relationship throughout the whole product. The LCD is merely an example. - David Lars Hallberg wrote: David Duardo skrev: This is where I ran into trouble As high resolution as the the LCD is, it simply is too small to be used with a finger based user interface, which is what most people would want to use on a cellphone because it is most convenient. At the upper bound, with the Neo1973, you can have 3 columns by 4 rows of buttons that are of a comfortable size (.5x.5 inch^2). Actually, the buttons can be slightly smaller and more compact, but I'm estimating for people with slightly bigger fingers. You can see can see what I mean in the following image: My current phone have a touch screen and a UI designed for stylus. The QUERTY keyboard is 14 keys wide on a 55mm wide screen (and it has bevels). That makes 3.9 mm per key. It's a bit painful, but I use it with fingers all the time (fingernails rather). Keys twice that size should work just fine. 5 colums and 7 rows of buttons should be usable on the neo... however a clever UI should generally need less... but that's the density I would use for text input. ... And my fingers are not huge... but fairly big. /LaH ___ 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: Hardware/Software UI Relationship
I was actually thinking of a linearized rotary dial. You basically have a scrollbar on one the side of the screen. All you would do is drag the slider down until you see the character you want and then let go. The slider will then spring back to the top. Perhaps using text prediction you can have the slider lock into slots that are more likely, making easier to find the character you want. ramsesoriginal wrote: a wheel dialer, like the good old phones? or maybe a exagonal layot, you know, with the keys fully filling the part assigned to them, i hope you understand. Or even some sort of panning and zooming dialer, like you see the whole dialer, then you press on key, and it zooms to such a degree that you only se the half of the outermost keys. and then it just pans around as you type. ok,could be kind of weird. How on a customizable dialer UI? some sort of template system, so everyone can make some templates, and then we simply make usability tests? And we ship only one template, but make the others aviable as download? -- My corner of the web: http://ramsesoriginal.wordpress.com My dream, my world: http://abenu.wordpress.com ___ 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: Hardware/Software UI Relationship
Your explanation definitely shed some light on the Neo1973 for me. I guess the only thing we can do at this point is wait for Sean to make more hardware announcements. Dirk Bergstrom wrote: At Mon, 16 Jul 2007 18:00:06 -0400,David Duardo [EMAIL PROTECTED] wrote: How can the community and FIC work together to have the most cohesive vision between the hardware and software user interfaces? As I understand it, the Neo 1973 hardware was originally developed for an unspecified FIC customer. That deal fell through, and somehow OpenMoko came onto the scene. Thus we have this somewhat oddball platform. It wasn't planned this way, it's a happy accident that any of this happened at all. My reading of Sean's announcement is that future hardware platforms will be designed in a more collaborative fashion. I suspect that the hardware he talked about for 2008 is probably pretty far along in the design cycle by now, but the versions after that are likely to be more open. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 Update!
Why the Neo is going to have 2 tri-axis accelerometers is beyond me. The only reason you would want to use 2 3d accelerometers is if you want higher accuracy in rotation measurements, but for the type of application I see little gain in the extra accuracy. The Nintendo Wiimote only uses 1 3d accelerometer and the sensitivity is good enough. Here is a pdf that shows you what I'm talking about: http://kionix.com/App-Notes/AN005%20Tilt.pdf Notice how in figure 6 the angle of the different axis effect the tilt sensitivity. - David Mauro Iazzi wrote: On 05/06/07, Tim Newsom [EMAIL PROTECTED] wrote: If your tracking movement with 2 3D accelerometers... What would another one provide. As far as I can tell (I am not an expert...) Tracking all 6 vectors will tell you absolute movement in space. I.e, when 2 vectors point in the same direction with the same magnitude at approximately the same acceleration as gravity.. Its probably laying or positioned flat on that side. Probably is the key here. with two 3d (linear) accelerometers you cannot sense rotation around the axis between the two in an inertial frame of reference. Moreover you cannot distinguish if the Neo is laying face down or pushed downwards with 2mg force. This example is somewhat artificial, but means that you can probably find more realistic (though complicated) movements that are not distinguishable with only two accelerometers. You must then consider the errors which sum up, if you try to track. A rough mental estimate gives that you can sum up as much as 1 meter of error in ten seconds if you have a precision of 10^-3g over acceleration measure. (it does not mean that you are 1 meter away from the real position, it means that you can only be sure that you are at most 1 meter away from that). Most of the time you will need good assumptions to get any information from raw data: http://www.wiili.org/index.php/Motion_analysis can be of some help. No linear accel, no rotation, no tilt, are assumptions which can give some meaning to the data and can be done for single application, where you can assume the user will have some particular behaviour (or you require it). Still absolute tracking won't probably be anyhow realizable. --mauro ___ 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
