Build ID: 1999092508 Platform: all The UI for opening files and Web sites (URLs) has deteriorated significantly over the past several weeks. What has happened exactly? It seemed that we had the problem solved in early 1999: there was a single item in the File menu labeled 'Open'; the keyboard accelerator was O and the shortcut was Ctrl+O. The dialog that it would bring up allowed you to type in a URL, or click Choose File to select a local file. Additionally, there was a check box for an implicit pref to open the file in a new window. The current UI is poor. There are too many things in the File menu, and the keyboard shortcut for Open File does not make sense. Ctrl+L was (if I remember correctly) used in previous Netscape browsers (pre 4.x?) for "Open Location"; pressing Ctrl+L and getting the file picker box is confusing. Have any final decisions been made in this area?

German is responsible for the File|Open UI. He should also have the keyboard shortcut sepced outalready. Reassign to german so he can point out the final design and sepc.

the reason is there is no good way to combine assigning an URL with picking a file in one dialog. the 4.x solution of having two modal dialogs stacked on top of each other is less preferrable than have two disitnct entry points. We will see how this is doing in usability testing.

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

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

I don't mind it as it stands now, with two options, but it would be useful to have a "in new window" checkbox.

are yu talking about opening files? No method is known to me that can enhance the OS based dialogs in an XPFE fashion.

Yeah that's true I guess until someone does an xp file picker, but at least for opening pages.

I suggest that the way it is done for open file, and the default for open page, should be what occurs when you hit a link for consistency purposes. This is of course replacement now, but bug #15512 offers a possible way to change this.

Referring to comment two up, I just realised there's already an option for open page. I should have known that. I am not here ...

If we can enhance the dialogs in a platform specific fashion, wouldn't that be better than no enhancements at all? To me it would seem that just passing a list of extra checkboxes would suffice for this and most situations, and you wouldn't need to try and convert XUL to local widgets. If the local OS doesn't support this, there's no loss.

can you mock your concept up (ASCII art would suffice, just so that I can better understand your concept...)

My only comment at this point is that the keyboard shortcuts are backwards. In legacy Netscape browsers (as well as IE on Windows and Mac OS), Ctrl+L means "Open Web Location", and Ctrl+O means "Open File". At this point I agree with German that the two-dialogs-stacked-on-top-of-each-other solution is not ideal. I still do like the idea of an "In New Window" check-box, however. I'll see if I can provide an example of that.

I would agree with cpratt's proposal. However, even if you decide to leave the "Open File" menu item on the file menu, it is still useful to be able to access "Open File" dialog from the "Open Web Location" dialog box, and a button to do so should be added.

German, are you referring to the checkboxes within the standard os open file dialog?

The matter is time. I do not think we have the time to build platform specific enhancements into native dialogs for 5.0. But the dialog that Christopher is proposing would circumvent that by preloading all the branching UI into an XPFE dialog, and solely leave the file open as antive dialog. I like that to be the Open Llocation dialog. I agree the Open Fiel... as both a seperate menu item as well as a 'bridging' button on the 'Open Location...' make sense. Frowarding this bug to sdagley, since he had some good feedback on ealier incarnations of the file|open dialog for macs. Steve please comment on cpratts design (attachment 3509 [details] from 12/15/99 09:55) and feel free to re-assign to me.

german, strange as it may seem I'm in complete agreement with you on this one :-) . As long as we have a sperate menu item to allow opening a file directly I happy with cpratt's dialog (and especially happy it avoids having to add a checkbox to native file open dialogs).

See bug 23950 for another design of this dialog, including an XUL implementation.

yep, I like that one. Only implementation problem Don's team might see if the component 'Composer' is not installed (if there ever would be such a config), how do we know to disable that radio button? Can we check it in? Don? That will help us close this bug and bug 23950

Changing QA contact to someone more competent.

I have checked in an improved open location dialog. Please open a new bug if you would like an specific changes made.

I'm frankly not sure what to do with this bug, so I'm rubber-stamping it as Verified/Fixed. Unrelated to any UI decisions made on the Mozilla tree, the File || Open UI remains unacceptable for a commercial product, and is the most complicated Open dialog I've seen in a commercial web browser. It also doesn't look like it was done by a professional designer, like IE dialogs do: - The Choose File functionality is redundant with the "Open File..." menu item - Does opening a Web URL for editing from Navigator really happen with such frequency that it's worth the cognitive overhead to present users with the choice of whether they want to edit a document every time they open a URL? (This results in the need to do a radio button, rather than a one-item checkbox like IE does.) - Why are the Open/Cancel buttons not at the bottom-right portion of the dialog? - Why does the dialog layout not follow a grid system, as explained in an introductory visual UI design book like "Designing Visual Interfaces"? - Why is the baseline of the radio button items 2 px off of the baseline of the label? You get the idea. I defer to the n.p.m.ui folks to decide what they want on the Mozilla tree; I know a lot of discussion went into it, and I recognize that open-source folks have different UI values than home users. I'll file specific Commercial-specific usability bugs if we still have this Mozilla dialog on the commercial build when Beta comes by. I don't see why we're not just using a simple dialog on the commercial tree like what cpratt suggests. --- elig feeling disgruntled...

> Unrelated to any UI decisions made on the Mozilla tree, the File || Open UI remains unacceptable for a commercial product and is the most complicated Open dialog I've seen in a commercial web browser. elig@netscape.com: Sorry you feel that way, but Netscape would be very wrong to base a UI design decision solely on the opinions of a single individual, such as yourself. Usability research based on a group of users of varing experience would be far more appropriate. > It also doesn't look like it was done by a professional designer, like IE dialogs do: Maybe Netscape should spend less time on visual look and MORE time on usability and function. - The Choose File functionality is redundant with the "Open File..." menu item WRONG. You cannot open a file in the existing web browser, or a new composer window with "Open File". - Does opening a Web URL for editing from Navigator really happen with such frequency that it's worth the cognitive overhead to present users with the choice of whether they want to edit a document every time they open a URL? (This results in the need to do a radio button, rather than a one-item checkbox like IE does.) Netscape MUST learn than removing functionality from the web browser is not the solution to usability problems. It may help new users, but experienced users such as myself WILL become pissed off. Using 2 checkboxes instead of 3 radio buttons becomes a mess, as does 2 radio buttons and a checkbox. I have considered all these options for a considerable time, and believe 3 radio buttons is the best option. It may take a little more time to parse for first time users, but users learn quickly. Removing the option to open a document in Composer is also not the solution, as it adds 2 extra steps to a frequent operation for anyone using Composer, that would take 1 step with my design. - Why are the Open/Cancel buttons not at the bottom-right portion of the dialog? Why should they be? The dialog has been designed to minimise the user eye movement from one item to another. Hence you move down the dialog from top to bottom, and then left to right. The horizontal line breaks the dialog into two parts - the URL specification part, and the opening part. The horizontal line becomes an attractor for eye movement, and so after looking at the "Open in which window" question, the users eye will follow the line across to the Open/Cancel buttons. Putting them at the bottom feels jarring - I've tried it. - Why does the dialog layout not follow a grid system, as explained in an introductory visual UI design book like "Designing Visual Interfaces"? There is more to UI design than simple "cookbooks". The item positioning is already based on a simple grid. - Why is the baseline of the radio button items 2 px off of the baseline of the label? A simple problem to fix. Good to see you pay attention to details. > get the idea. I defer to the n.p.m.ui folks to decide what they want on the Mozilla tree; I know a lot of discussion went into it, and I recognize that open-source folks have different UI values than home users. So you are claiming to understand and represent the values of home users better than myself and the others who contributed to the debate. I'd like to see fewer unjustified assertions like this, and more UI design based on usability research. Even if that statement was so, then it is a pitty that Netscape only wants to cater to one market. > I'll file specific Commercial-specific usability bugs if we still have this Mozilla dialog on the commercial build when Beta comes by. I don't claim to have a perfect dialog - it is only the first step. However, removing functionality from the current dialog would be a MISTAKE. Every element of my design was very carefully considered. If you would like a more detailed explaination of why things are as they currently are I would be happy to do so. > I don't see why we'renot just using a simple dialog on the commercial tree like what cpratt suggests. Simple dialogs might be best for simple people, but you will be excluding a significant number of less simple people. This is NOT good UI design. It is a pitty you want to lower the functionality of the product to the lowest common denominator.

So, in summary: 1. Unless you can show me some usability studies to show the dialog is too complex I reject this statement. 2. The "Open in composer" function IS necessary for anyone who seriously uses the Composer. 3. The dialog might not be the "prettiest" dialog around, but usability and functionality are more important than looks. 4. I don't see any other major problems with the dialog.

Sometimes, I wish I were involved in Mozilla on a volunteer basis, and could justify a multi-hour, researched discussion on UI issues, and didn't have a several-page long list of higher priority stuff that Netscape expects me to do. I split off a separate bug report (#26153) yesterday afternoon, assigned to ben; you may wish to repeat your comments into that bug report.

[Just to be clearly, that wasn't sarcasm, nor meant as a "swipe" in any fashion.]

Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.