Application UI Design Recommendations

[pauric]

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

Should the wiki be updated to explicitly state 'double tapping should
be avoided'?

thanks - pauric

On 7/16/07, Jeremiah Flerchinger <jeremiah.flerchinger at gmail.com> 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 gmail.com>
> > To: Mohammed Musallam <musallam001 at yahoo.com>
> > 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 gmail.com>
> >> To: openmoko-apps at lists.openmoko.org
> >> 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 *
> >> <http://us.rd.yahoo.com/evt=40705/*http://mrd.mail.yahoo.com/try_beta?.intl=ca>
> >
> >
> >
> > ------------------------------------------------------------------------
> > Be smarter than spam. See how smart SpamGuard is at giving junk email
> > the boot with the *All-new Yahoo! Mail *
> > <http://us.rd.yahoo.com/evt=40705/*http://mrd.mail.yahoo.com/try_beta?.intl=ca>
>
>
>