Re: Hardware/Software UI Relationship

2007-07-18 Thread ramsesoriginal

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

2007-07-18 Thread Giles Jones
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

2007-07-18 Thread Gabriel Ambuehl
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

2007-07-18 Thread Giles Jones
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

2007-07-18 Thread Frans Grotepass
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


Fw: Re: Hardware/Software UI Relationship

2007-07-18 Thread Giles Jones


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


Re: Hardware/Software UI Relationship

2007-07-18 Thread Joe Pfeiffer
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


Re: Hardware/Software UI Relationship

2007-07-17 Thread Torfinn Ingolfsen

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

2007-07-17 Thread Benjamin Schieder
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

2007-07-17 Thread ramsesoriginal

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

2007-07-17 Thread Giles Jones
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

2007-07-17 Thread David Duardo
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

2007-07-17 Thread David Duardo
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

2007-07-17 Thread Lars Hallberg

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

2007-07-16 Thread Dirk Bergstrom
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

2007-07-16 Thread Lars Hallberg

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

2007-07-16 Thread David Duardo
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