Re: Tab implementation review

_______________________________________________
Usability mailing list
Usability <at> gnome.org
http://mail.gnome.org/mailman/listinfo/usability

Re: Tab implementation review

Just a comment:

I've been using Safari 4 for a week now, and find its tab  
implementation surprisingly easy to adjust to. I don't know if other  
users will be as adaptable as I was, but it might be worth looking at.

Randall.

Re: Tab implementation review

On Tue, 2009-03-03 at 19:39 -0500, Randall Wood wrote:
> Just a comment:
> 
> I've been using Safari 4 for a week now, and find its tab  
> implementation surprisingly easy to adjust to. I don't know if other  
> users will be as adaptable as I was, but it might be worth looking at.
> 
> Randall.

Interesting approach. Could be worth looking at some of these ideas in
detail. There's a good write-up here:
http://www.macworld.com/article/139026/2009/02/safari4tabs.html

Allan

Re: Tab implementation review

tabs, should have the option of being positioned on the top, on the
bottom or on eider side, this way we would give the user options
instead of standards :), and the same program would fit on different
cultures (those who write from below-up or right to left)

On Thu, Mar 5, 2009 at 7:47 AM, Allan Day <allanpday <at> gmail.com> wrote:
> On Tue, 2009-03-03 at 19:39 -0500, Randall Wood wrote:
>> Just a comment:
>>
>> I've been using Safari 4 for a week now, and find its tab
>> implementation surprisingly easy to adjust to. I don't know if other
>> users will be as adaptable as I was, but it might be worth looking at.
>>
>> Randall.
>
> Interesting approach. Could be worth looking at some of these ideas in
> detail. There's a good write-up here:
> http://www.macworld.com/article/139026/2009/02/safari4tabs.html
>
>
> Allan
>
>
> _______________________________________________
> Usability mailing list
> Usability <at> gnome.org
> http://mail.gnome.org/mailman/listinfo/usability
>

Re: Tab implementation review

On Thu, 2009-03-05 at 09:22 +1930, Dokuro wrote:
> tabs, should have the option of being positioned on the top, on the
> bottom or on eider side, this way we would give the user options
> instead of standards :), and the same program would fit on different
> cultures (those who write from below-up or right to left)

Most of the time, users don't want options, they want something they can
use. Most people (myself included) don't care about where tabs are, as
long as they are always at the same place. This is the sort of decision
designers should make, instead of deferring it to users. Concerning i8n,
if there is really a need to position tabs differently depending on the
language or cultural standards, this should be carefully determined for
every particular situation and encoded in the locale so that it happens
automatically and appropriately. I don't really know if this is
necessary, though.

By the way, Gnome used to have undockable menus and toolbars by default.
They were deactivated as developers noticed that almost no-one actually
wanted to move them, and that moving them by accident would often result
in a very confused and annoyed user. A sane decision, as far as I'm
concerned.

Cheers,

M. S.

[Fwd: [Bug 569668] Places menu shouldn't use non-Nautilus handler for bookmarked folders]

Dear usability people,

May I request your attention for bug 569668, which was marked NOTABUG
today? I still think this is a problem that needs to be solved: when
opening a folder bookmark from the Places menu, it should be opened with
Nautilus and not with some other application, regardless of the mime
association of folders.

If you agree that this bug should be reopened, please say so. Lionel
Dricot already commented, as you can read in the forwarded message. 

regards,

-- 
Reinout van Schouwen

From: glib (bugzilla.gnome.org <bugzilla-daemon <at> bugzilla.gnome.org>
Subject: [Bug 569668] Places menu shouldn't use non-Nautilus handler for bookmarked folders
Date: 2009-03-04 14:39:36 GMT

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=569668

  glib | gio | Ver: unspecified

Lionel Dricot changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ploum <at> ploum.net

------- Comment #12 from Lionel Dricot  2009-03-04 14:40 UTC -------
> "[...] Reinout [..] believes that "properties -> open with" does this.
> However, that is completely wrong. "

An end user is never wrong. It's a bug in the feature or it's a misleading UI. 

I've one golden rule : if a developper ever tell to a user : "You are wrong,
you doesn't understand the software", there's a problem and an important one.
Note that I don't say you have to change the software. Sometimes, simply
changing the documentation or the way stuffs are presented is enough.

> From a user perspective, there is no difference between "Nautilus" and "Gnome
> panel". They should behave the same.

Indeed. I can see a billion of valid reasons why they should act differently.
But I'm sure I could not find one real user who will understand it when trying
to access his bookmarks.

After reading this thread, I see two possible solutions :

1) We don't allow changing the handler for folders. It makes a lot of sense and
I don't see any usecase that are working right now and would be broken.
Currently, that how I see a solution to this bug.

2) Implement a "Open this folder with". This should not be that hard. Putting a
.hidden file in the folder with a command should be enough. Maybe there's even
a XDG standard for that kind of stuff (or we can create one).
The standard browsing would still be available with a right clic under nautilus
and would be consistent in gnome-panel/nautilus/whoever implement the spec.

--

-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=569668.

_______________________________________________
Usability mailing list
Usability <at> gnome.org
http://mail.gnome.org/mailman/listinfo/usability

Re: [Fwd: [Bug 569668] Places menu shouldn't use non-Nautilus handler for bookmarked folders]

On Wednesday 04 March 2009 3:19:19 pm Reinout van Schouwen wrote:
> Dear usability people,
> 
> May I request your attention for bug 569668, which was marked NOTABUG
> today? I still think this is a problem that needs to be solved: when
> opening a folder bookmark from the Places menu, it should be opened with
> Nautilus and not with some other application, regardless of the mime
> association of folders.

What if the user's default file manager isn't Nautilus?

--

-- 
Mackenzie Morgan
http://ubuntulinuxtipstricks.blogspot.com
apt-get moo

_______________________________________________
Usability mailing list
Usability <at> gnome.org
http://mail.gnome.org/mailman/listinfo/usability

Re: [Fwd: [Bug 569668] Places menu shouldn't use non-Nautilus handler for bookmarked folders]

Hi,

Op woensdag 04-03-2009 om 21:16 uur [tijdzone -0500], schreef Mackenzie
Morgan:

> What if the user's default file manager isn't Nautilus?

What if the sky were green and the grass were blue? 

As far as I'm concerned, we're striving to create a seamlessly
integrated environment. We can only go so far in accommodating users who
knowingly put non-Gnome components into the mix.

regards,

--

-- 
Reinout van Schouwen

Re: [Fwd: [Bug 569668] Places menu shouldn't use non-Nautilus handler for bookmarked folders]

On Thursday 05 March 2009 6:56:38 am Reinout van Schouwen wrote:
> Hi,
> 
> Op woensdag 04-03-2009 om 21:16 uur [tijdzone -0500], schreef Mackenzie
> Morgan:
> 
> > What if the user's default file manager isn't Nautilus?
> 
> What if the sky were green and the grass were blue? 
> 
> As far as I'm concerned, we're striving to create a seamlessly
> integrated environment. We can only go so far in accommodating users who
> knowingly put non-Gnome components into the mix.

Well maybe a GConf key should exist to set which file manager the user prefers?

--

-- 
Mackenzie Morgan
http://ubuntulinuxtipstricks.blogspot.com
apt-get moo

_______________________________________________
Usability mailing list
Usability <at> gnome.org
http://mail.gnome.org/mailman/listinfo/usability

Re: keyboard/focus annoyance after sorting in list view

[ added usability <at> gnome.org to cc ]

2009/3/6 Holger Berndt <berndth <at> gmx.de>:
> I don't know how Apple does it -- but to me, that is an excellent idea!
> Though I don't think this can be automated in a meaningful way, as
> general rules by widget type are not really useful.
>
> Still, gtk+ could have a global bool switch to build up the focus chain
> of all focusable widgets or just the ones that the developer considers
> "important" for keyboard navigation. Each widget would have a property
> "important_for_keyboard_navigation" that application developers can
> set.
>
> Closing the loop to the other thread, Ctrl-Tab would then be an alias
> to Tab if the global switch is set to true.
>
> Alternatively, the global switch could be left out completely, and
> Ctrl-Tab be made an iterator that only considers these "important"
> widgets.

Agree. Teaching gtk+ about such a property would be very useful and
Alt+Tab could indeed be overloaded with what the HIG currently assigns
it to:

"Ctrl+Tab, Shift+Ctrl+Tab	Moves keyboard focus out of enclosing widget
to next/previous control, in those situations where Tab alone has
another function (e.g. GtkTextView)"

This paragraph is, I think, completely compatible with "Moves keyboard
focus among important user input widgets" since the widgets where Tab
alone would behave differently from the "Move to next widget" seem to
be among the ones which would be marked as "important".

Rui
--
nautilus-list mailing list
nautilus-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/nautilus-list