Closed Bug 245862 Opened 20 years ago Closed 20 years ago

Preferences dialog should be at the same place on all OS

Categories

(Firefox :: Settings UI, defect)

Product:
Firefox
Component:
Settings UI
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: askwar, Assigned: bugzilla)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040606 Firefox/0.8.0+ (NESI)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040606 Firefox/0.8.0+ (NESI)

In bug 245765, the Preferences menu entry moved to the Edit menu again for
XP_UNIX, but not for XP_MACOSX and also Windows. Because of this, Firefox users
cannot find Preferences on the same spot for all the supported OS.

That's *EXTREMELY* bad, because one of the MOST important pros of Firefox (and
Mozilla) is that it is cross-platform and thus should AS MUCH as possible behave
the same everywhere. 

With the introduced change, it no longer does.



Reproducible: Always
Steps to Reproduce:
Start Ff on Windows, Linux, MacOS X and try to find the Preferences menu entry.
Actual Results:  
On Linux, it is under Edit. On all the other OS, it is is still under Tools.

Expected Results:  
According to bug 245765, GNOME HIG dictates that Preferences has to be under
Edit. Because of that, the other OS have to follow.

Or GNOME HIG should not be followed, and Preferences should be under Tools
again. Either way is fine - it just *HAS* to be consistent.



Because it makes Firefox harder to use, I'm setting severity to Major.
Depends on: 245765
This should probably be resolved as invalid.

See bug 245765 comment 8.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
No longer depends on: 245765
Gnome HIG should be followed in Gnome, Apple HIG should be followed on Mac, and
Microsoft HIG should be followed in Windows.

It *is* consistent - with the operating system.
(In reply to comment #1)
> This should probably be resolved as invalid.
> 
> See bug 245765 comment 8.

No, it should not. As I said, one of the most important aspects of
Firefox/Mozilla is the cross platform aspect. If Firefox should be a cross
platform application (which I hope it still should be), then it REALLY should be
consistent to itself in the first place and to the OS only in the 2nd place.
When menu entries are at different spots on different OS, it is no longer
consistent to itself.

(In reply to comment #2)
> Gnome HIG should be followed in Gnome, Apple HIG should be followed on Mac, and
> Microsoft HIG should be followed in Windows.
> 
> It *is* consistent - with the operating system.

So cross platform constency is not important anymore? Firefox should behave
completely differnt on all the different OS it's running on?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Firefox should be consistant with the Operating System it is running on - at
least in this respect.

-> Invalid
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
Verified.
Status: RESOLVED → VERIFIED
Verified.
So firefox should behave differently on each OS and should not be cross platform
anymore. Further, "GNOME" is not an OS - what about KDE? There, Preferences
should NOT be under Edit, as pointed out in bug 245765 comment 10.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
Firefox is a GTK application, not a QT application, not to mention that
integration with GNOME is being actively worked on. In this case, the GNOME HIG
would most certainly apply.

-> Invalid, again.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
In that instance, Firefox's behavior should match whatever is standard for that
enviroment. but this bug is still invalid, as all OS'es should not have the same
behavior.

-- Verified, again.
Status: RESOLVED → VERIFIED
Another question - you're saying that it should be consistent to the OS. If
that's the case, why is a new "standard" theme being introduced? This theme
doesn't look as "native" as the old theme on Windows. But the argument for
introducing the new theme was (to my understanding), that Ff should be
consistent *across differnt OS*.

Now, IMO those changes contradict each other. If cross-OS consistency is wanted
by introducing a non-natively looking theme, the app should behave the same on
all OS. But, if the app should not behave the same on all OS (like you're saying
in this bug here), then I don't understand why a new standard theme should be
introduced.

-> Reopened again.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
(In reply to comment #10)
> Another question - you're saying that it should be consistent to the OS. If
> that's the case, why is a new "standard" theme being introduced?

The new theme has introduced because of licensing issues with Qute.

The Winstripe theme is not the same as the Pinstripe theme, it's only similar. 
So Windows and Linux versions look different than the Mac OS.

Invalid, again.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
> Firefox is a GTK application, not a QT application, not to mention that 
> integration with GNOME is being actively worked on. In this case, the GNOME 
> HIG would most certainly apply. 
 
A gtk application is not necessary a gnome application. There are many 
examples for that. And a qt application is not necessary a kde app. Again 
there are also many examples for that. 
 
IIRC, the so called "Gnome integration" that is being worked on, is done by 
Firefox developers, and not by gnome-developers. 
 
Btw, it IS confusing that under the "edit" menu one can find content-area 
specific commands "copy, cut, paste", and then Preferences which is completely 
unrelated to the other content-area. But that's not the point of this bug. 
 
Either follow the HIG of the desktop Firefox runs under (good luck with 
that... xfce, kde, gnome, blackbox, windowmaker, etc), 
or let it behave equally regardless of the desktop, and use the windows hig as 
base. 
 
I guess nobody ever complained about "Tools->Options" under Linux. 
 
Fine, we're a GNOME app.  Happy now?  Unless someone decides to step up to
maintain a KDE/qt port, we'll continue to act like a GNOME app.

And plenty of people complained, GNOME people first and foremost.
(In reply to comment #13) 
> Fine, we're a GNOME app.  Happy now?  Unless someone decides to step up to 
> maintain a KDE/qt port, we'll continue to act like a GNOME app. 
 
Ok, I am fine with that. 
But be aware that I was talking about HIG and not toolkits! 
Toolkits don't matter for users. 
 
> And plenty of people complained, GNOME people first and foremost. 
 
I guess soon you'll have the KDE people start complaining... ;-) 
no. unfortunately KDE people aren't even able to port Fx to QT :/
*** Bug 248906 has been marked as a duplicate of this bug. ***
I find it utterly idiotic to make different menues for different OS's. Consider
a guidebook for firefox, you have to make different screenshots and descriptions
for each OS instead of just one. Shouldnt SIMPLICITY stand above all ??

The reason that KDE people havent ported FF to qt, is most likely due to the
fact, that it works just fine as it is, so why waste time.
Of course simplicity is good, but for, say, an OS X user, the expected place to
find the preferences is under the menu that has the application's name in it. 
Anywhere else will confuse someone who is an experienced OS X user but a new
FireFox user;  On the other hand, there is no equivalent on Windows to the
application menu.

It comes down to a question of whether we're more interested in consistency
cross-platform for the Firefox user who uses the app on multiple platforms, or
consistency within a platform for the new user.

I'd argue that since the latter is more likely to have difficulty finding
things, we should design for that user, but an argument can be made either way.

On the mutant third hand, is there a reason the Prefs item can't be located in
more than one menu on some platforms?  That way people who are new to the
browser can find it where they expect from their OS (and perhaps its default
browser *cough*IE*cough*), but people who use the browser cross-platform can
also expect to always find it in the same place....
It just took me over a month to gather enough ambition to figure out where the
options dialog went.  For those of us who disabled the 'Edit' menu in
userChrome.css, this is not a very happy move.  I was completely boggled why all
my Windows-using friends still had Tools->Options.  Since the rest of the edit
menu has nothing to do with functionality and everything to do with text, this
is rather confusing.
Perhaps I am re-opening an ugly can of worms but...

Could someone do usability testing?  Instead of arguing arcane technical points
and guessing what users think, wouldn't it be better to gather data and do what
the users are observed to think?

I am not experienced in usability testing, or else I would volunteer to do this
myself.
For the 800th time since we did this: 

The platforms we currently support (Windows, GNOME, Mac OS X) all have
"expected" locations for preferences.  Obviously, this is different on these
different platforms.  Our goal is to behave like a regular app on all three
platforms, NOT to behave like some universal browser that can be used in many
places but doesn't quite fit anywhere.
*** Bug 255609 has been marked as a duplicate of this bug. ***
Can an option be added to move the options dialog between tools and edit?

The only way to control cache, cookies, saved passwords, etc, etc, etc is under
the options dialog.  It's extremely disruptive to my computing behavior when I
have to stop and actively think about which OS I'm currently running, so where
the control might be right now.  I use windows half the time (at work) and linux
half the time (at home).

Same goes for the many different keyboard shortcuts.  If you believe it's best
to integrate into the OS to become a "standard app" for that OS fine, it's a
valid point.  But make these sorts of things customizable and Firefox will be
much more usable for /everyone/.
I just added my vote to this bug. It's really annoying to have two different
things in Windows and in Linux when (nearly?) all the rest is the same.

FYI, I'm a KDE user. Am I using an unsupported platform?
We're not going to make a cross-platform app that doesn't respect the target
platform's conventions.

KDE isn't unsupported, its just not the platform we're using as our baseline on
*nix.  With the fresh resurrection of the Qt port, I can forsee having to rework
some of the #ifdefs to follow KDE's HIG as a build option (so that KDE-based
distros/users can build something that feels more KDE-like).  But that's future
fodder, really, and outside of the context of this bug.  It wouldn't change the
defaults for GTK2 builds etc.
I use Firefox in Linux and Windows and I've read all the arguments here.  I have
a suggestion -- in addition to the the 'Options' and 'Preferences' commands in
the menu, place a button on the tool bar and add a command to the right-click
menu to call up the Options/Preferences dialog.  This will help the
multiple-operating-system-user avoid accidentally clicking on the wrong menu
item ('Edit' or 'Tools').

I would add the button to my toolbar myself, but apparently there is no
Tools/Preferences button available in the toolbar customizer.
*** Bug 292053 has been marked as a duplicate of this bug. ***
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
Would it be possible to make everybody happy and provide an option for this? Even if it's just one of those about:config ones. I am also pretty annoyed by the current behavior but I think it's because I use both Windows and Ubuntu every single day, Ubuntu at work, Windows on my laptops. Maybe people should have such a configuration, however, I see the point that there are also many "only Windows" or "only Linux" users which might want to see the menu item where they first expect it to be. IMHO it's a pretty sad state anyway that n different HIG exist but, well, better than none at all. Having an option would give everyone the opportunity to choose.
You need to log in before you can comment on or make changes to this bug.