[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Tabbed browsing vs taskbar grouping; a proposal.
From:       Jorge Adriano Aires <jadrian () mat ! uc ! pt>
Date:       2004-02-29 17:30:54
Message-ID: 200402291730.54684.jadrian () mat ! uc ! pt
[Download RAW message or body]


> > This is nothing like the tabs situation. If the konq you select is not on
> > the right tab you just chose the appropriate tab.
>
> "Just choose"? You make it seem easy, but it isn't, since the names don't
> fit in the tab. I am talking about directories with full path, not web
> sites, remember?
>
> Sorry, this is the very problem we are trying to solve. Ignoring it won't
> solve it.

No, I didn't explain myself well. I'm talking about problem 2. 
I'm talking about what the tabs are good at, and I'm saying that your method 
don't have the tabs advantage. 

> > In this case if you click
> > and it is not the konq you want then you have to minimize it
>
> ??
> No, I don't need to minimize it. Just click on the taskbar button with the
> down arrow, and choose.

That is minimizing. Let me try to explain better.
When stating problem 2 you said:

"Tabbed browsing does not have this problem. because we have a two phases 
choice: the first click, on the taskbar, sends you to to the most recent 
konqueror directory; then, IF you don't like it, you can change the dir with 
a second click (this time on the tab)."

I'm claiming your proposed method doesn't do this well either. 
I think that now that I clarified what I'm talking about it should be easy to 
understand my reasoning on the first mail... let me know if I wasn't clear 
enough though.


> > and use the
> > other process to open it.
>
> Yes, if by "other process" you mean "click on the down arrow and then click
> on the correct directory". Two clicks. This seems inevitable: in order to
> choose, I have to see the whole path names. So I _must_ use two clicks,
> because we cannot statically allocate so much space to hold 10 full paths.

Yes, I'm saying that most people will end up using the current process *only* 
and ignore the 'normal' click (because they usually won't be able to predict 
the outcome, and end up having something they don't want, and undoing that 
and using the current process anyway... so 'normal' click only gets in their 
way). So they'll be in the same situation they are now... a little worst 
becouse now that process is slower becouse you have to hold the mouse button.

> > Most times you won't know if the one you want is the most recent one, so
> > you'll just use the "normal" process (which will be more annoying then it
> > is now because you'll need to hold for some time).
>
> Once again, no, if we use the double button approach. It seems you didn't
> read the whole post.

Yeap I read, but you're right I forgot to comment that.
But again, it isn't much different, I don't think getting the last used 
application is usable (I explained why) so everybody else will use the other 
button but now it will be smaller and more difficult to click.

> 1) First of all, when they click the back button in mozilla or MS-Explorer,
> the users have no problem understanding they are going to the most recent
> window,and that the down arrow pops up the list of all windows. This would
> look the same, so it would be immediately intuitive.

No quite different, the first is easier to understand because you have a 
sequencial history (so it's natural to walk back and forth) and, many times 
actually, related. When it comes to apps it is not sequential (you can have 
many open) and most times dissociated.

> > Have you tried using "tear-off handles" in the menu applications?
> Sorry, I don't understand what you mean by "menu applications"...

I mean "application menus" opsss :)

> > They used
> > to be on by default, but now I they don't even work anymore. (KDE 3.1.5,
> > don't have 3.2 in here to test it, anyone knows if it's fixed?). In
> > theory you should be able to click,
>
> click where?
In the tear of handle, which were located right below the menu if I recall 
correctly. Quite accessible (at least if kicker is located on the bottom).

J.A.

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]