Application UI Design Recommendations

Jeremiah Flerchinger jeremiah.flerchinger at
Wed Jul 18 20:38:34 CEST 2007

pauric wrote:
> Jeremiah "ouble-clicks are more common to desktops and filesystem
> browsing. The appropriate behavior can be used in the appropriate
> instance. Again I think we're just arguing over names, when event
> behavior is the real issue"
> I'm compiling the mapping of interactions to actions that were
> discussed this week.  One thing that is still open is Double Clicking.
> While I agree with some that openmoko should allow
> designers/developers to do what they want.. here is a little anecdotal
> evidence from some user research I did for my day job:  As users
> switch between the desktop and the web, and as more web apps for 2.0
> (and look like the desktop) I see a lot of web users double click on
> links (both text and icons)  While this doesnt break anything on the
> web, I think it might be confusing is some openmoko apps utilise
> double-clicking and others simply use a single tap to open/start/call
> etc
So they're double clicking when only a single click is required?  It's 
true this doesn't really matter for web links, but can cause a problem 
on the desktop if they start multiple instances of an app by double 
clicking when only 1 is required.  I actually recall seeing several 
people do this, initially, after I changed my desktop behavior.
> Should the wiki be updated to explicitly state 'double tapping should
> be avoided'?
I personally am fairly indifferent.  Double-clicking is what the average 
person is used to doing.  Is it better to go along with their 
intuition... possibly, if just to avoid people opening multiple app 
instances.  The allowed delay between taps to register a double-click 
could always be increased to reduce the argument of fast clicks making 
people push harder.  3/4 second between presses to register a 
double-press should be plenty.  Either that or we can just suggest for 
developers to eat clicks that occur too rapidly in the same spot.

 From what's been discussed, so far, the behavior I like is as follows:
  Press & Drag in window, list, etc - scroll/pan in that direction
  Press & Drag on icon in file browser, selected text, etc - drag that 
  Press in/on window, list, button, link, etc - basic action: 
(typically) a simple single-click like event (press button, follow link, 
open list or select list item).  Another example would be open opening 
contact detail in address book.
  Press on icon in file browser - open the file or execute app
  Extended-Press in window, list, etc - advanced events:  can either 
open a dialog with advanced options or execute some default action 
(place voice call to selected contact in list) with a cancel dialog/message
  Extended-Press on icon in file browser, selected text, etc - open 
dialog with advanced actions: cut, copy, paste, rename, delete, 
properties, edit/customize, etc.
  Extended-Press & Drag - select all icons, text, files, etc between 
initial & final position.

No-Press vs Press already have associated color/image changes.  A 3rd 
visual change should signify the initiation of an Extended-Press.
> thanks - pauric
> On 7/16/07, Jeremiah Flerchinger <jeremiah.flerchinger at> wrote:
>> Mohammed Musallam wrote:
>> > "many programs almost require a right-click."
>> >
>> > That's based on the assumption you're using a desktop device (just
>> > what pauric said) and we must try to avoid that. I know I've been
>> > running the same sentence over and over but look at the iphone 
>> (LATI) :)
>> >
>> > well the idea behind taking away the right-click is to force the
>> > designers to better design their programs work flow.
>> I see your point.  Of course if we just call the events by different
>> names this argument goes away.  Call them "simple press" and "extended
>> press" for example.  In the contacts menu a simple-press could select a
>> contact & bring up a page specific to that contact for calling, editing,
>> etc.  A extended press could initiate a call and bring up a dialog to
>> cancel.
>> They're just events mapped to functions and we can call them whatever we
>> like.  One is a basic event and the other can be an advanced event.  I
>> would say most apps use single clicks for simple/basic events and right
>> clicks for advanced events.  Single-clicks and double-clicks are more
>> common to desktops and filesystem browsing.  The appropriate behavior
>> can be used in the appropriate instance.
>> Again I think we're just arguing over names, when event behavior is the
>> real issue.
>> >
>> >
>> > ----- Original Message ----
>> > From: Jeremiah Flerchinger <jeremiah.flerchinger at>
>> > To: Mohammed Musallam <musallam001 at>
>> > Sent: Monday, July 16, 2007 3:31:25 PM
>> > Subject: Re: Application UI Design Recommendations
>> >
>> > Mohammed Musallam wrote:
>> >> What I don't like about the "pie chart" is that it clutters the
>> >> screen when its displayed and it would be confusing at first. I'm
>> >> wondering if we take a more simplistic approach.
>> > I don't like the idea of a visible pie chart, but an invisible one
>> > that provides scrolling as you drag outward & clicking in the middle
>> > would be great.  That's what I originally thought was implied on the
>> > wiki page.  Used in this manner it would also be completely intuitive.
>> >> if we start with the idea:
>> >> * All applications (for day to day) should be a finger application.
>> >> That includes Contacts, pim/calender, dialer, GPS & basic settings
>> >> (bluetooth on/off, wifi on/off, etc.)
>> >> * interface should be intuitive
>> >> * Big buttons and uncluttered interface
>> > I have to agree with you on all these issues.  Also what people don't
>> > understand is the physical screen size is less than half the size of
>> > the online screenshots.  2x the dpi means 2x smaller screen than what
>> > you see on your computer.
>> >>
>> >> Then: menus, popups & dialog boxes should be strictly removed or
>> >> limited to the bare minimum because of their small nature... it would
>> >> be difficult to use our fingers on them
>> > I can see limiting, but not removal.  Removing on-screen clutter and
>> > keeping everything big would be more effective, in my opinion.
>> >> ************
>> >> So I believe to simplify the touch interface:
>> >>     a. single-tap would equal a single click
>> > fine
>> >>     b. tap&hold would represent a double-click
>> > why not just double-click to double-click? that seems far more
>> > intuitive to me (or don't use it at all).
>> > use the tap&hold for a right click.  many programs almost require a
>> > right-click.  you also know you could right-click on those early macs
>> > by pressing the option key & clicking.  i think the right-click is too
>> > important to ignore.
>> >>     c. a drag would mean a scroll in that direction
>> > totally agree. that would be perfection and useful in almost all apps.
>> >> ************
>> >>
>> >>
>> >> ----- Original Message ----
>> >> From: Jeremiah Flerchinger <jeremiah.flerchinger at>
>> >> To: openmoko-apps at
>> >> Sent: Monday, July 16, 2007 1:57:02 PM
>> >> Subject: Re: Application UI Design Recommendations
>> >>
>> >> The "pie chart" clicking functionality looks very useful as described
>> >> under "Touch Gestures."   I think I would prefer a global behavior of
>> >> scrolling up/down/left/right after a press to scroll 
>> up/down/left/right
>> >> and a press-hold would perform a right click and bring up a typical
>> >> menu/dialog of options, if not accompanied by significant
>> >> dragging/scrolling.
>> >>
>> >> This would present a uniform method of scrolling across the 
>> applications
>> >> & the press hold for right click should translate well to any
>> >> application.  The phonebook could be quickly scrolled with a press &
>> >> drag, a second screen could be opened with a simple click to edit the
>> >> contact or call/email/etc, and a press-hold could open a message 
>> dialog
>> >> with the contacts name & the option to call or cancel.
>> >>
>> >> A press-drag left/right is suggested to translate to a click
>> >> right/middle.  It's a good suggestion, but I think scrolling 
>> left/right
>> >> would be more useful to the average user and extend better as a 
>> general
>> >> case.
>> >>
>> >>
>> >>
>> >> 
>> ------------------------------------------------------------------------
>> >> Be smarter than spam. See how smart SpamGuard is at giving junk email
>> >> the boot with the *All-new Yahoo! Mail *
>> >> 
>> <*> 
>> >
>> >
>> >
>> > 
>> ------------------------------------------------------------------------
>> > Be smarter than spam. See how smart SpamGuard is at giving junk email
>> > the boot with the *All-new Yahoo! Mail *
>> > 
>> <*> 

More information about the openmoko-apps mailing list