Re: Hardware/Software UI Relationship
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. -- -- Dirk Bergstrom [EMAIL PROTECTED] http://otisbean.com/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
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
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: Hardware/Software UI Relationship
On 7/17/07, Lars Hallberg <[EMAIL PROTECTED]> wrote: 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. Although the phone I currently use has physical keys, they are 4.8 mm x 5.0 mm. It felt cramped the first days, but works ok after that, even with fingers. :-) -- Torfinn ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
On 17.07.2007 08:32:24, Torfinn Ingolfsen wrote: > On 7/17/07, Lars Hallberg <[EMAIL PROTECTED]> wrote: > >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. > > Although the phone I currently use has physical keys, they are 4.8 mm > x 5.0 mm. It felt cramped the first days, but works ok after that, > even with fingers. :-) Myself, I'm frustrated with the hardware keys on 'modern' phones. They are small, hard to press, offer little to no feedback and bounce back and forth. An improved on-screen keyboard or even libgstroke bindings would be way better for input. Greetings, Benjamin -- Benjamin 'blindCoder' Schieder Registered Linux User #289529: http://counter.li.org finger [EMAIL PROTECTED] | gpg --import -- http://www.rocklinux.org/ The Distribution Build Kit pgptqRdcmZM29.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
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
Re: Hardware/Software UI Relationship
Benjamin Schieder <[EMAIL PROTECTED]> wrote : > Myself, I'm frustrated with the hardware keys on 'modern' phones. They > are small, hard to press, offer little to no feedback and bounce back > and forth. > An improved on-screen keyboard or even libgstroke bindings would be > way better for input. I agree, people talk about tactile feedback, but I'd rather have no tactile feedback than have horrible spongey or clicky feedback. The only qwerty keyboard I liked was the Nokia 9210. A good predictive engine will cut down on typing. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
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
On 17 Jul 2007, at 17:58, David Duardo wrote: 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. Sounds a bit complicated to me. A Qwerty keyboard would be better, but if space is limited you might be better with two characters per key, the predictive text would easily be able to tell which of the two characters you meant. After all it works for T9 on 0-9 keypad phones. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
David Duardo skrev: 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. Initially I believe in some experimentation and choice. After that there is time to seek consensus on the default and guidelines for how to blend in with everything else. But stuff like input method should be easy to replace after taste... That's probably the most important part of the process, identify what should be easily replaced and what interface that needs. The Neo1973's LCD is 43mm x 58mm. I would like a high density input method... but You can come a long way with 3x3 buttons and two press entry. 9x9 = 81 input combinations. Alternatively... make that one stroke where start and end defines the two 'button press'. My favourite for main UI is a text input tool at the bottom, where you input a progressive search term, say "we br"... That might match: web browser (app) tux web broadcast (web bookmark, document) Werner Brown (contact) Wera Brooks (contact) Wera Brooks at the pub (photo, document) etc.. The matching object is shown on top and selectable. Size on those object can depend on number of matches and can be compacted in intelligent ways like: [contacts 3] [document 12] [apps 2] choosing one hides the input area and use the whole screen to show the chosen matches. Selecting one match show that with large buttons for appropriate actions. Gesture short cuts like select a contact and drag down to dial can speed the interface up. If no search term is entered these 3 categories (contacts, documents and apps) may be displayed for browsing rather then searching after what You want. Maybe there should be 3 modes/preferences the user can shoes and that all/most UI should obey (explicit choices like input method may override): Minimum UI element: Mode name 4x4mm: Small stylus interface 8x8mm: Big stylus/small finger interface 12x12mm: Big finger interface I'm pretty sure the neo can be made highly usable :-) /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
I still think that some sort of modular keyboard (i mean: template, skin, whatever you may call it) would be the best solution: everyone chooses what fit's better for his needs. And everyone can develope in a simple way some sort of keyboard in the meanwhile, and we have plenty to choose from for the official realease to be included. -- 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
Re: Hardware/Software UI Relationship
Lars Hallberg <[EMAIL PROTECTED]> wrote : > My favourite for main UI is a text input tool at the bottom, where you > input a progressive search term, say "we br"... That might match: > > web browser (app) > tux web broadcast (web bookmark, document) > Werner Brown (contact) > Wera Brooks (contact) > Wera Brooks at the pub (photo, document) > etc.. > > The matching object is shown on top and selectable. Size on those object > can depend on number of matches and can be compacted in intelligent ways > like: [contacts 3] [document 12] [apps 2] That sounds very similar to QuickSilver on the Mac, it works really well. You start typing and then it provides matching documents, webpages, applications etc.. it's very fast. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
On Wednesday 18 July 2007 09:50:36 Giles Jones wrote: > > The matching object is shown on top and selectable. Size on those object > > can depend on number of matches and can be compacted in intelligent ways > > like: [contacts 3] [document 12] [apps 2] > That sounds very similar to QuickSilver on the Mac, it works really well. > You start typing and then it provides matching documents, webpages, > applications etc.. it's very fast. Katapult on KDE is kinda similar (I think it's actually intended to be a Quicksilver copy cat). It's included with Kubuntu, at least. pgpMde9XYOPrl.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
Gabriel Ambuehl <[EMAIL PROTECTED]> wrote : > Katapult on KDE is kinda similar (I think it's actually intended to be a > Quicksilver copy cat). It's included with Kubuntu, at least. Certainly sounds like an idea worth implementing on a mobile device. When you have your data with you on the move you have less time to find it. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
On Wednesday 18 July 2007 09:50, Giles Jones wrote: > > My favourite for main UI is a text input tool at the bottom, where you > > input a progressive search term, say "we br"... That might match: > > > > web browser (app) > > tux web broadcast (web bookmark, document) > > Werner Brown (contact) > > Wera Brooks (contact) > > Wera Brooks at the pub (photo, document) > > etc.. > > > > The matching object is shown on top and selectable. Size on those object > > can depend on number of matches and can be compacted in intelligent ways > > like: [contacts 3] [document 12] [apps 2] > > That sounds very similar to QuickSilver on the Mac, it works really well. > You start typing and then it provides matching documents, webpages, > applications etc.. it's very fast. I have no experience with the Mac, but playing around with the emu did bring up a few questions/alterations that would be nice. I checked out the terminal, but found it almost impossible to use with the Qwerty kb without tab completion. It would be nice to have a dropdown box instead of the tabcompletion. One or more dropdown boxes appear. At first only one to select the command. The command receives a shortlist determined by qwerty entries. After selecting the command, more dialogues apear. one for the options and one or more for the other command entries. From the options one can select an option and it gets added to the commandline. Command entries are often entering a path. It starts with the / and one can select the path per dir. The command gets expanded and pressing enter executes it. The terminal must be functional. I'll have a look at the code and whether I can add something like this to play with. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
Gabriel Ambuehl writes: >On Wednesday 18 July 2007 09:50:36 Giles Jones wrote: >> > The matching object is shown on top and selectable. Size on those object >> > can depend on number of matches and can be compacted in intelligent ways >> > like: [contacts 3] [document 12] [apps 2] >> That sounds very similar to QuickSilver on the Mac, it works really well. >> You start typing and then it provides matching documents, webpages, >> applications etc.. it's very fast. > >Katapult on KDE is kinda similar (I think it's actually intended to be a >Quicksilver copy cat). It's included with Kubuntu, at least. It's also how the PalmOS AddressBook application works. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fw: Re: Hardware/Software UI Relationship
>The terminal must be functional. I'll have a look at the code >and whether I >can add something like this to play with. Assignable buttons at the top of the terminal would be handy, allow the user to assign the most common commands. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community