Application UI Design Recommendations
Jeremiah Flerchinger
jeremiah.flerchinger at gmail.com
Wed Jul 18 21:20:44 CEST 2007
pauric wrote:
> 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.
You're right we wouldn't be able to do an extended press & drag. The
touch gestures mentioned in the wiki also wouldn't be possible with the
normal tap behavior. Additional apps or mechanisms would be required to
switch to and handle additional states of operation. I guess the state
could be changed in apps through options in an extended press dialog/menu.
>
> 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
> <mailto: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
> <mailto: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
> <mailto:jeremiah.flerchinger at gmail.com>>
> >> > To: Mohammed Musallam <musallam001 at yahoo.com
> <mailto: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
> <mailto:jeremiah.flerchinger at gmail.com>>
> >> >> To: openmoko-apps at lists.openmoko.org
> <mailto: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
> <http://us.rd.yahoo.com/evt=40705/*http://mrd.mail.yahoo.com/try_beta?.intl=ca>>
> >>
> >>
> >>
> >>
> >
>
>
More information about the openmoko-apps
mailing list
