Application UI Design Recommendations

Wed Jul 18 20:51:21 CEST 2007

The only reason I mention double tapping is that I cant think of an instance
of it on any mobile device I've used (iphone, zaurus) or designed (palmV)
for.  I think I'll make a statement to avoid it.

Also, Jeremiah said "Extended-Press & Drag - select all icons, text, files,
etc between initial & final position."

I dont think you will be able to do an extended press & drag.  Extended
press will already call the advanced/secondary function, so you cant drag.

Other than that.. the other UI design comments are pretty much what was
decided.

thanks - pauric

On 7/18/07, Jeremiah Flerchinger <jeremiah.flerchinger at gmail.com> wrote:
>
>
> 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
> selection
>   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 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
> >
> >>
> >>
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-apps/attachments/20070718/a1a38f02/attachment.html