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.<br><br>Also, Jeremiah said "Extended-Press & Drag - select all icons, text, files, etc between initial & final position."
<br><br>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.<br><br>Other than that.. the other UI design comments are pretty much what was decided.
<br><br>thanks - pauric<br><br><br><div><span class="gmail_quote">On 7/18/07, <b class="gmail_sendername">Jeremiah Flerchinger</b> <<a href="mailto:jeremiah.flerchinger@gmail.com">jeremiah.flerchinger@gmail.com</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>pauric wrote:<br>> Jeremiah "ouble-clicks are more common to desktops and filesystem
<br>> browsing. The appropriate behavior can be used in the appropriate<br>> instance. Again I think we're just arguing over names, when event<br>> behavior is the real issue"<br>><br>> I'm compiling the mapping of interactions to actions that were
<br>> discussed this week. One thing that is still open is Double Clicking.<br>><br>> While I agree with some that openmoko should allow<br>> designers/developers to do what they want.. here is a little anecdotal
<br>> evidence from some user research I did for my day job: As users<br>> switch between the desktop and the web, and as more web apps for 2.0<br>> (and look like the desktop) I see a lot of web users double click on
<br>> links (both text and icons) While this doesnt break anything on the<br>> web, I think it might be confusing is some openmoko apps utilise<br>> double-clicking and others simply use a single tap to open/start/call
<br>> etc<br>So they're double clicking when only a single click is required? It's<br>true this doesn't really matter for web links, but can cause a problem<br>on the desktop if they start multiple instances of an app by double
<br>clicking when only 1 is required. I actually recall seeing several<br>people do this, initially, after I changed my desktop behavior.<br>> Should the wiki be updated to explicitly state 'double tapping should<br>
> be avoided'?<br>I personally am fairly indifferent. Double-clicking is what the average<br>person is used to doing. Is it better to go along with their<br>intuition... possibly, if just to avoid people opening multiple app
<br>instances. The allowed delay between taps to register a double-click<br>could always be increased to reduce the argument of fast clicks making<br>people push harder. 3/4 second between presses to register a<br>double-press should be plenty. Either that or we can just suggest for
<br>developers to eat clicks that occur too rapidly in the same spot.<br><br> From what's been discussed, so far, the behavior I like is as follows:<br> Press & Drag in window, list, etc - scroll/pan in that direction
<br> Press & Drag on icon in file browser, selected text, etc - drag that<br>selection<br> Press in/on window, list, button, link, etc - basic action:<br>(typically) a simple single-click like event (press button, follow link,
<br>open list or select list item). Another example would be open opening<br>contact detail in address book.<br> Press on icon in file browser - open the file or execute app<br> Extended-Press in window, list, etc - advanced events: can either
<br>open a dialog with advanced options or execute some default action<br>(place voice call to selected contact in list) with a cancel dialog/message<br> Extended-Press on icon in file browser, selected text, etc - open<br>
dialog with advanced actions: cut, copy, paste, rename, delete,<br>properties, edit/customize, etc.<br> Extended-Press & Drag - select all icons, text, files, etc between<br>initial & final position.<br><br>No-Press vs Press already have associated color/image changes. A 3rd
<br>visual change should signify the initiation of an Extended-Press.<br>> thanks - pauric<br>><br>> On 7/16/07, Jeremiah Flerchinger <<a href="mailto:jeremiah.flerchinger@gmail.com">jeremiah.flerchinger@gmail.com
</a>> wrote:<br>>> Mohammed Musallam wrote:<br>>> > "many programs almost require a right-click."<br>>> ><br>>> > That's based on the assumption you're using a desktop device (just
<br>>> > what pauric said) and we must try to avoid that. I know I've been<br>>> > running the same sentence over and over but look at the iphone<br>>> (LATI) :)<br>>> ><br>>> > well the idea behind taking away the right-click is to force the
<br>>> > designers to better design their programs work flow.<br>>> I see your point. Of course if we just call the events by different<br>>> names this argument goes away. Call them "simple press" and "extended
<br>>> press" for example. In the contacts menu a simple-press could select a<br>>> contact & bring up a page specific to that contact for calling, editing,<br>>> etc. A extended press could initiate a call and bring up a dialog to
<br>>> cancel.<br>>><br>>> They're just events mapped to functions and we can call them whatever we<br>>> like. One is a basic event and the other can be an advanced event. I<br>>> would say most apps use single clicks for simple/basic events and right
<br>>> clicks for advanced events. Single-clicks and double-clicks are more<br>>> common to desktops and filesystem browsing. The appropriate behavior<br>>> can be used in the appropriate instance.<br>
>><br>>> Again I think we're just arguing over names, when event behavior is the<br>>> real issue.<br>>> ><br>>> ><br>>> > ----- Original Message ----<br>>> > From: Jeremiah Flerchinger <
<a href="mailto:jeremiah.flerchinger@gmail.com">jeremiah.flerchinger@gmail.com</a>><br>>> > To: Mohammed Musallam <<a href="mailto:musallam001@yahoo.com">musallam001@yahoo.com</a>><br>>> > Sent: Monday, July 16, 2007 3:31:25 PM
<br>>> > Subject: Re: Application UI Design Recommendations<br>>> ><br>>> > Mohammed Musallam wrote:<br>>> >> What I don't like about the "pie chart" is that it clutters the
<br>>> >> screen when its displayed and it would be confusing at first. I'm<br>>> >> wondering if we take a more simplistic approach.<br>>> > I don't like the idea of a visible pie chart, but an invisible one
<br>>> > that provides scrolling as you drag outward & clicking in the middle<br>>> > would be great. That's what I originally thought was implied on the<br>>> > wiki page. Used in this manner it would also be completely intuitive.
<br>>> >> if we start with the idea:<br>>> >> * All applications (for day to day) should be a finger application.<br>>> >> That includes Contacts, pim/calender, dialer, GPS & basic settings
<br>>> >> (bluetooth on/off, wifi on/off, etc.)<br>>> >> * interface should be intuitive<br>>> >> * Big buttons and uncluttered interface<br>>> > I have to agree with you on all these issues. Also what people don't
<br>>> > understand is the physical screen size is less than half the size of<br>>> > the online screenshots. 2x the dpi means 2x smaller screen than what<br>>> > you see on your computer.<br>>> >>
<br>>> >> Then: menus, popups & dialog boxes should be strictly removed or<br>>> >> limited to the bare minimum because of their small nature... it would<br>>> >> be difficult to use our fingers on them
<br>>> > I can see limiting, but not removal. Removing on-screen clutter and<br>>> > keeping everything big would be more effective, in my opinion.<br>>> >> ************<br>>> >> So I believe to simplify the touch interface:
<br>>> >> a. single-tap would equal a single click<br>>> > fine<br>>> >> b. tap&hold would represent a double-click<br>>> > why not just double-click to double-click? that seems far more
<br>>> > intuitive to me (or don't use it at all).<br>>> > use the tap&hold for a right click. many programs almost require a<br>>> > right-click. you also know you could right-click on those early macs
<br>>> > by pressing the option key & clicking. i think the right-click is too<br>>> > important to ignore.<br>>> >> c. a drag would mean a scroll in that direction<br>>> > totally agree. that would be perfection and useful in almost all apps.
<br>>> >> ************<br>>> >><br>>> >><br>>> >> ----- Original Message ----<br>>> >> From: Jeremiah Flerchinger <<a href="mailto:jeremiah.flerchinger@gmail.com">
jeremiah.flerchinger@gmail.com</a>><br>>> >> To: <a href="mailto:openmoko-apps@lists.openmoko.org">openmoko-apps@lists.openmoko.org</a><br>>> >> Sent: Monday, July 16, 2007 1:57:02 PM<br>>> >> Subject: Re: Application UI Design Recommendations
<br>>> >><br>>> >> The "pie chart" clicking functionality looks very useful as described<br>>> >> under "Touch Gestures." I think I would prefer a global behavior of
<br>>> >> scrolling up/down/left/right after a press to scroll<br>>> up/down/left/right<br>>> >> and a press-hold would perform a right click and bring up a typical<br>>> >> menu/dialog of options, if not accompanied by significant
<br>>> >> dragging/scrolling.<br>>> >><br>>> >> This would present a uniform method of scrolling across the<br>>> applications<br>>> >> & the press hold for right click should translate well to any
<br>>> >> application. The phonebook could be quickly scrolled with a press &<br>>> >> drag, a second screen could be opened with a simple click to edit the<br>>> >> contact or call/email/etc, and a press-hold could open a message
<br>>> dialog<br>>> >> with the contacts name & the option to call or cancel.<br>>> >><br>>> >> A press-drag left/right is suggested to translate to a click<br>>> >> right/middle. It's a good suggestion, but I think scrolling
<br>>> left/right<br>>> >> would be more useful to the average user and extend better as a<br>>> general<br>>> >> case.<br>>> >><br>>> >><br>>> >><br>
>> >><br>>> ------------------------------------------------------------------------<br>>> >> Be smarter than spam. See how smart SpamGuard is at giving junk email<br>>> >> the boot with the *All-new Yahoo! Mail *
<br>>> >><br>>> <<a href="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</a>><br>>>
<br>>> ><br>>> ><br>>> ><br>>> ><br>>> ------------------------------------------------------------------------<br>>> > Be smarter than spam. See how smart SpamGuard is at giving junk email
<br>>> > the boot with the *All-new Yahoo! Mail *<br>>> ><br>>> <<a href="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
</a>><br>>><br>>><br>>><br>>><br>><br></blockquote></div><br>