64719 - ftp(tree) - double-click files confuses users

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect, P3)

Description

[Ari Heitner]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; m18) Gecko/20001227
BuildID:    2000122708

Traditionally, browsers represent ftp as a web page, with directories being
links to new pages, and files as download links. Seems pretty reasonable. And
it's definitely what people are used to.

For some reason mozilla decides
a) not to make ftp entries visually look like links
b) to require double-clicking to open a directory or download a file. That's
*definitely* not what the user is expecting the browser to do, given that every
other place anywhere following a link is a single-click.





Reproducible: Always
Steps to Reproduce:
Ftp. double click. ftp. double click.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Confirming bug and reassigning to [e-mail].

Comment 2

[[e-mail]]

Component could possibly be Networking:FTP

Comment 3

[Keyser Sose]

Moving to Networking.
Triaging the Most doomed (which Happens to Ben right now :)

Comment 4

[Doug Turner (:dougt)]

This is not going to be fixed for 0.9.  removing keyword and milestone.

Comment 5

[tenthumbs]

Note that ftp via a proxy becomes a single click. Mozilla need to be
consistent.

Comment 6

[sairuh (rarely reading bugmail)]

single-clicking the file in an ftp view was the way it worked in 4.x. how
difficult would this be to implement [just curious]? adding catfood kw, and
clearing milestone for reconsideration. nominating for moz0.9.1 and beta1.

Comment 7

[Jesse Ruderman]

This bug seems to be mutually exclusive with allowing multiple files to be 
selected at once.  I don't think the current behavior is confusing -- other 
trees in Mozilla use double-click to open, and Windows Explorer uses double-
cilck to open (ftp view is more similar to Windows Explorer than it is to a 
webpage imo).

See also bug 75262, "double-clicking ftp folder should expand folder".

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

Jesse: I don't understand why those two things would be mutually exclusive. 
Selection multiple items is typically done with shift/alt/command/control clicks.

Comment 9

[Jesse Ruderman]

When I select multiple items, I usually don't hold a modifier when clicking on 
the first item.  I guess I could hold Ctrl while clicking the first one, but I 
don't think users will figure out that it's possible to select items at all if 
it's necessary to hold Ctrl.  (Also, Ctrl+Click can't be "add to selection" 
and "open in new window" at the same time...)

Comment 10

[Doug Turner (:dougt)]

moving to 0.9.1.  

I am not sure that this is required.  Applications using a tree widget require a 
double click to perform an operation such as downloading.  

Comment 11

[Jesse Ruderman]

cc mpt

Comment 12

[Matthew T (active 1999-2002)]

This is a difficult problem, because there are two equally understandable 
approaches.
(1) Imitate a Web page as much as possible. This makes us consistent with other
    content appearing in the Navigator window (i.e. Web pages), and with other
    FTP listings which are gated through a proxy or through an HTTP server.
(2) Imitate the platform's file manager as much as possible. This makes us
    consistent with most other file listings the user is used to.

My personal preference is (2), since users are more familiar with folder 
listings in their file manager than with HTMLified FTP listings. The corollary 
is that when an FTP listing is being displayed, the Web-page-specific items in 
the `View' menu should be replaced with ones relevant to a file listing. That 
means users could choose `View' > `as Links' to get the one-click behavior, and 
that setting would persist for all FTP listings (until they switched back to 
`View' > `as Icons' or `View' > `as List').

Comment 13

[Ari Heitner]

I have no objections to mpt's suggestions.

There is no default file manager on Unix, and trying to imitate one is silly. It
makes to make the default view (on Unix) "as Links" or "as Webpage" or whatever
you want to call it.

Comment 14

[Doug Turner (:dougt)]

I don't mind what it does now.  I am futuring. 

Comment 15

[Doug Turner (:dougt)]

reassigning to [e-mail].

Comment 16

[Bradley Baetz (:bbaetz)]

I really don't see how (2) is programatically possible.

If someone comes up with a patch I'll look at it, though.

Comment 17

[benc]

RELNOTE for NS 6.2 : (low priority)

If FTP is using the directory viewer (need correct term here) files must be 
double-clicked to be opened in the window, or saved to disk (with a context menu 
or menu command).

<since we have HTML on by default, I think the impact is minimal>

Comment 18

[Bradley Baetz (:bbaetz)]

*** Bug 117964 has been marked as a duplicate of this bug. ***

Comment 19

[Peter Trudelle]

The basic function of the browser is to present all content with similar
affordances, by far the most common being the link to present the content of
files shown in the browser window. In fact, the success of browsers is due in
large part to the way it makes access to content universal through links that
can be opened with a single click.  Trying to mimic the file system inside the
browser is not a good approach, since we don't know that our users are
comfortable with that, but we do know they can click on links, and are expecting
to do so in the browser.    In fact, imitating the default file system in the
current manner can even be wrong, for instance on my system, which has the file
system configured to imitate the browser's link behavior.  Double-clicking is
thus an extremely foreign gesture for me, and even if I know it is required it
is at least twice as difficult.  IE6 gets this right, as you'd expect since it
is the file system browser.
nominating for nsbeta1, this is part of our overall attempt to unify
click/twisty behavior for MachV.  If this is not fixed in mozilla, we may have
to override this behavior in Netscape.  cc marlon for ue input.

Comment 20

[Bradley Baetz (:bbaetz)]

Note that this is currently only an issue for file:///, and that listing will be
in html too Real Soon Now. That view uses a single click, as is expected.

All other tree widgets require double clicking, as does stuff like the file
picker. Ftp browsers which use a tree based interface requries double clicking -
single click == selection, double click == action.

The twisty itsself only requires a single click, as is usual for tree-based widgets

Comment 21

[Peter Trudelle]

Not all tree widgets require double-click; sidebar bookmarks, history, what's
related and search results are all going to be single click.  What do users care
what type of widget is used to contain and present the content?  If it looks
like a link, they'll click on it.

I'm not sure what remaining case you're talking about, but the argument about
single click being needed for selection begs the question of whether typical
users will really need and want to select multiple items in that context.  Why
will they? (I reallly don't know.)  That argument is why the items I list above
currently require different gestures to open, and why double-click will soon be
relegated to separate 'management' windows.
   
BTW, your use of the term 'required' is a bit of an overstatement, since Windows
and Mac file system browsers can be configured to work quite well without any
double-clicking.  

Comment 22

[Bradley Baetz (:bbaetz)]

Well, once we have a download manager, a user could select multiple items and
say "download these"

Also, it doesn't really look like a link per se - its not underlined, for
example, and visited links don't change color (OK, thats mainly because the
:active and :visited pseudo classes don't work for <tree>, so when jan does the
outliner support that may be revisited)

Comment 23

[Jan Varga [:janv]]

I started working on tree -> outliner for directory view.
If we are going to use html view, I'll leave it as it is

Comment 24

[Bradley Baetz (:bbaetz)]

Jan: We need both, because embedders who don't want XUL still need to view
directories. The XUL viewer was removed from the defaults mainly because it was
really slow - see my perf numbers in the other bug. Its a much nicer interface,
and I would prefer it to be on by default, if it can be made fast enough.

Comment 25

[Jan Varga [:janv]]

Current XUL directory viewer is really slow, I guess it is because old <tree>
sucks even more for larger windows.
Now I have almost usable viewer which uses outliner.
It is fast even on Linux :)
And looks sweat

Comment 26

[Bradley Baetz (:bbaetz)]

Right. Tree sucked for this, so it was turned off for outliner, then <outliner>
was meant to be renamed to <tree> for 0.9.7, then 0.9.8 - I put it off until
that happened, and it hasn't happened yet ;)

Comment 27

[Peter Trudelle]

We need to be careful to design for optimizing the common scenarios of typical
users.  Making fundamental selection decisions on the basis of what some users
'might' do can easily make the product much harder for most people to use at
all.   An example of this would be to make something that might naturally be
presented as a link look different just to support multiple selection.   To do
so, we should be sure that this was a very common operation, and that there was
no way to accomodate it otherwise, for example by multiple clicks. We really
don't need or want to have the browser incorporate a full-featured FTP client,
anymore than we want it to have a full-featured download manager.  That kind of
feature creep was a big factor in its becoming a bloated, slothful browser.

Comment 28

[Bradley Baetz (:bbaetz)]

Sure, and I do plan eventually to move the pref for XUL vs html out of the debug
pref panel.

The actual fix for this bug is abuot two lines; I'm happy to do whatever UE
suggests.

Comment 29

[marlon bishop]

not sure if we are still talking about file:/// or ftp://, but in either case,
we should display the data in web tradition.  the other interface breaks the
paradigm of links and single clicking, and we don't need the extra interaction
that it is implying  

Comment 30

[Bradley Baetz (:bbaetz)]

We're talking about the xul view, which is just file:/// for the moment.

So is teh consensis then to remove the XUL view? I know that there are people
which like it...

Comment 31

[Peter Trudelle]

I'm not suggesting how to implement, nor do I hear Marlon saying so, that is
your department. :-)  We just want to ensure that files appear and work like
other links.      If the XUL implementation can provide for that, and offers
other benefits (better icons?), then it may still be the right choice.

Comment 32

[Bradley Baetz (:bbaetz)]

OK, so the original question still remains:

"In a tree widget, a single click on the twisty will expand the directory.
Should a single clikc on a file attempt to download that file? What should a
single click on a directory do? Is there a way to indicate this feedback to the
user better, to differentiate it from other tree-based ftp viewers qhich use
double click? (eg underline, change color on mouseover/mousedown, etc)?"

Maybe I should take this to npm.ui...

Comment 33

[Peter Trudelle]

I think we've already covered this. Some other tree/outliner widgets have leaf
nodes that are links. If it walks like a duck, and quacks like a duck...
I don't see any reason why folders couldn't open/close on single click too.
I'm curious to hear the cost/benefit analysis of using XUL for this rather than
HTML.  

Comment 34

[Peter Trudelle]

BTW, don't take my comment on the folder single-click as definitive, we should
still get UE input.  I suspect we may need to change it everywhere, or nowhere,
for consistency.  

Comment 35

[benc]

Just decide before the next milestone... :)

Comment 36

[Jesse Ruderman]

nsbeta1+, really?  I don't think Mozilla is using a tree widget for local
directories or ftp directories right now.

Comment 37

[Bradley Baetz (:bbaetz)]

File still uses it, but I hoope to fix that RSN.

Comment 38

[Peter Trudelle]

Sooner than 'future'?  ;-)

Comment 39

[Bradley Baetz (:bbaetz)]

No, the bug to use html for file:// is mozilla1.0, and I plan to do that this
weekend.

I'm still waiting for UE input on this bug though, I think.

Comment 40

[Peter Trudelle]

I thought comment #29 was pretty clear.  Even if you use XUL, it should behave
like the bookmarks tree in the sidebar, for consistency.

Comment 41

[Bradley Baetz (:bbaetz)]

Yeah, but the bookmarks tree still shows.

OK, I'll change it then.

Comment 42

[Bradley Baetz (:bbaetz)]

Since the tree widget will be off for 1.0, moving to 1.1alpha, and removing
nsbeta1+.

Comment 43

[Peter Trudelle]

nsbeta1-, as long as it isn't on by default.

Comment 44

[Bradley Baetz (:bbaetz)]

xul dirviewer bugs -> 1.2. I have no time..

Comment 45

[Peter Trudelle]

So, is the default view now html?

Comment 46

[Bradley Baetz (:bbaetz)]

Bah. I only meant to move RFE's, sorry.

I was hoping to have the html view patch done last weekend, but I didn't have time.

Comment 47

[benc]

(agreeing w/ the above, but for diffent reasons)

The double-click got started in the Macintosh Finder, which, from what I've
heard,  is actually a violation of Apple's Human Interface Guidelines.

I think that later applications which offered single and double-clickable items
got a more consistent interface. The general logic should be "single click does
something", "double click does something else."

NeXTstep's workspace manager did this (you get the same behavior by using Mac OS
X Finder's "View as Columns, or several modes of Active Desktop that I can't
easily describe how to configure). 

If you single-clicked a file, it would select the file, but also give user
feedback by giveing an enlarged icon, and some basic file information.

If you double clicked a file, it would open the file.

Absent that model, a single click should just pass through to the file (as
somewhat agreed above). If we implemented a double click, probably it should do
the most reasonable context-menu or file-"opening" behavior, which would
probably be a download interface of some kind.

Comment 48

[Peter Trudelle]

Browsers load links on single-click. There is no double-click behavior, and I
don't see how we could add one.  

Bradley, is the default view now HTML? If not, could you use a hand with this? 

Comment 49

[benc]

The FTP default is HTML, File is still xul-tree.

Comment 50

[Bradley Baetz (:bbaetz)]

Yeah - I should start working on html-file again Darin's patch broke some stuff,
though, so I can't test on teh locales whihc would be problematic.

With this bug, help would be wanted. I may have a bit more time in 2 weeks, and
lots mroe in 4, but for the momement, I'll review fixes.

Comment 51

[Peter Trudelle]

What needs to be done?  Is there anyone on the Nav team who you'd recommend?

Comment 52

[Bradley Baetz (:bbaetz)]

I have no time to work on mozilla at the moment, so dougt is taking over FTP

open ftp bugs -> him

Comment 53

[Doug Turner (:dougt)]

xul dirviewer

Comment 54

[Samir Gehani]

Nav triage team: nsbeta1+/adt3

Comment 55

[Samir Gehani]

Current trunk builds are using the HTML viewer for ftp, http, and file
protocols.  Removing plus for reconsideration by nav triage.

Comment 56

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 57

[Vedran Miletic]

retargeting

Comment 58

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 59

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 60

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 61

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 62

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 63

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 64

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420