Attached is yet another mock - this suggestion feels more like a dialog to me. Regarding Mike's comment on buttons vs links - I agree but in my mock its used for an advanced link (that would bring up the edit bookmark dialog) - which I find OK personally (since my guess is that this feature is not heavily used). Regarding behavior. When using my dialog - we would not add a bookmark until the user presses Add - this is to reduce the panic when the user accidentally clicks the star button. This is also more in line with standard dialog behavior. When a bookmark exists - the Add button would be changed to Remove.
Sverrir On Wed, Dec 10, 2008 at 9:33 AM, Mike Pinkerton <[EMAIL PROTECTED]>wrote: > > IMHO, links don't belong in native UIs at all, except when they take > you to a web page (ie, linking to the privacy notice on the web from > explanatory text). The proper interface element for an action in an > application is a button. > > On Wed, Dec 10, 2008 at 1:18 AM, Peter Kasting <[EMAIL PROTECTED]> > wrote: > > On Tue, Dec 9, 2008 at 5:29 PM, Simon B. <[EMAIL PROTECTED]> wrote: > >> > >> The Bookmark bubble doesn't suit me, so I've made some redesign > >> suggestions: > >> http://sites.google.com/site/chromiumdev/bookmark-added > > > > Note that when clicking on a currently-unstarred site, our existing > design > > shows "Bookmark Added!" (a la 1A), not "Bookmark" (what you mark > > "Original"). We show the "Original" case when you click an > already-existing > > bookmark. > > The mocks you present nearly all change the button layout in ways that > are > > pretty unusual for a Windows UI. All but 1A move the close button to the > > upper right, which is extremely unorthodox, and even 1A puts non-button > > controls horizontally aligned with the close button, which is also > unusual. > > Your mocks also make heavy use of horizontal space, changing the flow > from > > being nearly vertical to being more of a zigzag. Our current design is > far > > more typical of Windows UI layout, with its roughly-square shape and its > > vertical flow. > > If I were to get more specific, I would say that in all the designs > except > > perhaps number 3, the close button is further from the star than in the > > original, so the stated goal of making it easier to mouse to seems > > unachieved (even if the targeting issues from moving it to a nonstandard > > location didn't apply). > > I am not necessarily opposed to changing "Edit" from a button to a link, > but > > there are problems: as Glen says, it'd be nice to place it after the > other > > controls in the flow, yet making it a link practically demands that it be > > placed near "Remove" (as you've done), which as Ian and Brett say should > > almost certainly remain in the upper right. These conflicting demands > pose > > a quandary, and since a button is not terribly unusual here, I would > > probably stick with that. > > In short, I think our current design is better overall than any of the > > proposed mocks. 1A is perhaps the best of the alternatives, but I still > > find it a step backwards. > > I think your suggestion about selecting the text so the beginning (not > the > > end) is in view is a good one. I would go ahead and file that as a > feature > > request at crbug.com. > > PK > > > > > > > > > -- > Mike Pinkerton > Mac Weenie > [EMAIL PROTECTED] > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
<<inline: add_bookmark.JPG>>
