Application name should not be included in window title

RESOLVED FIXED in seamonkey2.0b2

Status

SeaMonkey
UI Design
RESOLVED FIXED
18 years ago
9 years ago

People

(Reporter: Matthew Paul Thomas, Assigned: stefanh)

Tracking

(Blocks: 2 bugs, {pp})

Trunk
seamonkey2.0b2
PowerPC
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 6 obsolete attachments)

(Reporter)

Description

18 years ago
To reproduce:
* Open the attached testcase.
* Look at the title bar.

What you should see:
* `Public enemy number one'.

What you actually see:
* `Public enemy number one - Mozilla'.

Advertising the name of the program in the title bar is completely redundant, since:
* it gives the impression that the application is just a visitor on the user's
  system (cf. file managers, which don't include `Windows Explorer' or `Finder'
  in the titles of their folder windows);
* on Mac OS, the name of the application is visible in the application menu
  anyway;
* in all Mozilla applications, the title bar is already used for other things,
  which are usually quite long to begin with (e.g. Web page titles, message
  subject lines);
* this is an open-source project, and as such should not subject users to
  constant advertising for a program they are already running.

Occurs with:
* Build 2000101620, Mac OS 9.0

Does not occur with:
* any other document-based application I have ever seen on the Mac, except
  for previous versions of Mozilla.

This bug will depend on other bugs which make sure that the window title always
has some content.
(Reporter)

Comment 1

18 years ago
Created attachment 17335 [details]
testcase

Comment 2

18 years ago
I disagree that the appname should not be appended to the page title in 
Windows.  Every application I've ever used has had its name in the titlebar, 
and it would be quite odd if, for example, a page had `Microsoft Internet 
Explorer' as its title and that's all we put in the titlebar.  This should be 
mac-only, and maybe linux as well.

Comment 3

18 years ago
Two other points, in response to yours:
* I don't see the name in the titlebar as `advertising', and I don't think too 
many other users would either.  Why are we advertising a product they're 
already using?  I think of it more as program identification, a quick reference 
to the app name without a visit to the about dialog.
* Windows Explorer does not just give directory or file information in the 
titlebar, it is prepended by "Exploring -".  It doesn't need really need to say 
the full `Windows Explorer' because the user thinks of it as another integrated 
part of Windows (as indicated by its interface's conformance to the rest of the 
OS UI, and lack of a specific about box -- it just uses the global Windows 
one), and it's really not a separate application.
(Reporter)

Comment 4

18 years ago
[Third attempt at entering this ...]

Adding dependency: This bug needs to be fixed before bug 36305 (proxy icon in
title bar) will make sense from a UI perspective.

Response to Blake's points:

> Every application I've ever used has had its name in the titlebar

The latest version of MSN Explorer for Windows doesn't, it just has the title of
the page. The start of a trend? I certainly hope so.

> it would be quite odd if, for example, a page had `Microsoft Internet
> Explorer' as its title and that's all we put in the titlebar

Maybe, but there is much less scope for that kind of titlebar pratfall than
there is scope for the kind of titlebar pratfall shown by my testcase.

> Why are we advertising a product they're already using?

Exactly.

> I think of it more as program identification, a quick reference to the app
> name

In an ideal world, users do not need to care which app they are using. This is
an almost completely painless step towards that ideal world. If a user needs to
know which app they are using, they can use the About box. (In such cases
they'll likely need to know the version number too, information which the title
bar will normally not provide anyway.) There is no need to clutter their display
with the app name all of the rest of the time, when they do not need to see it.

> Windows Explorer does not just give directory or file information in the
> titlebar, it is prepended by "Exploring -".

In the normal case, where you double-click on a disk or folder icon on your
desktop, this is not true; only the folder name is shown. `Exploring -'
indicates a particular view mode of Windows Explorer, in the same way that an
app might append `(Read-Only)' to the title. It is not really anything to do
with the app name.

> the user thinks of it as another integrated part of Windows

Exactly. That's what we should be aiming for -- an interface which the user does
not notice, because it just blends in with the rest of the system.
Blocks: 36305
Depends on: 56993

Comment 5

18 years ago
I asked why we'd be advertising a product they're already using to (hopefully) 
show that the user doesn't think we are, not to prove the point that we 
shouldn't be.  In most (if not all) other non-Internet-related applications, 
the `title' in `titlebar' is the app title; not <title>bar.  We would be 
redefining the role of the titlebar if we did this.

When you double click on a folder, what appears is just a window showing the 
folder contents.  This isn't really a separate application, and I think it's to 
the user that they aren't launching a new application when they do that.

We don't currently blend in with the system at all, and I think some other 
changes would have to be made to make the app integrate more before we do this, 
if that's our goal.  Personally, I think a better justification for doing this 
would be to unify the browser chrome and the webpage (which, iirc, was one of 
the original goals pf the product).  In other words, the browser chrome would 
just be extended navigation of the webpage displayed in the content area, and 
thus it would make sense to only display the webpage title in the titlebar, 
because the user thinks he's looking at one entity -- a webpage.  But we're 
really nowhere near this full integration (and I'm not sure that we're even 
headed in that direction - are we still trying to design the chrome according 
to web look and feel?)
On the Mac (at least) the title bar should only contain the document title--regardless of 

whether Mozilla is considered app-centric or document-centric.

Comment 7

18 years ago
How about making it a preferences?

Comment 8

18 years ago
I will shoot myself if you make this a preference.

Comment 9

18 years ago
For now i'm marking this as mac only.

Comments?
Hardware: All → Macintosh
(Reporter)

Comment 10

18 years ago
*sigh*

Ok, Mac only then. But I predict you'll be doing this on Windows too within 
three years. :-)
Keywords: pp
akkana, d'you think the application name should be in the titlebar of unix
mozilla/n6 windows? since i prefer less clutter in general, i wouldn't mind it
going away. but i don't have strong feelings about this...

Comment 12

18 years ago
Not that big a deal to me really, but since you asked:

I like having the name of the app in the titlebar: I don't actually care that
it's in the titlebar itself (if I can see the titlebar, I can see the window and
figure out what app it is) but that also makes it show up in the application
list as a Mozilla or Netscape window.  When I'm choosing from a long list of
minimized windows trying to find my browser window, it can be quite difficult if
the window is listed as "Files" or "My page" or " " (blank) or other such titles
one commonly sees on the web.

Comment 13

17 years ago
I think Matthew is a man before his time.  -> Future, maybe I'll look into this 
for mac at some point.
Target Milestone: --- → Future
Blocks: 73812

Comment 14

17 years ago
Looks like there is pretty strong agreement that at least on the Mac, the
application name should not appear in the window title. Shouldn't this be a
pretty easy code change to make?

Comment 15

17 years ago
This is assembled here:

http://lxr.mozilla.org/mozilla/source/xpfe/appshell/src/
nsContentTreeOwner.cpp#567

but unfortunately we can't just #ifdef XP_MAC in this file, we'd need to fix it 
in the DTDs and in general these are locale specific and not plaform specific 
everywhere.

Comment 16

17 years ago
See also bug 80735, "Build id in window title lowers usability".
(Reporter)

Comment 17

17 years ago
*** Bug 107695 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
Nominating for Mozilla 1.0.
Keywords: mozilla1.0
Created attachment 57300 [details] [diff] [review]
Quick fix I use myself

I attached a quick patch that works for me and removes 33 chars from the title.
I don't expect this to be checked in. I'm just attaching it in case someone
wants to use it in a personal build and doesn't want to search for the right
source line to zap.

Comment 20

17 years ago
From the comments in this, and bug 80735, it becomes obvious this is a personal
preferance. So why not a pref that would be OFF by default (for the reasons
stated in 80735), which would remove " - Mozilla {Build ID: XXXXXXXXXX}" from
the title?

Also, I don't feel this depends on 56993, as a blank title isn't the end of the
world.
Created attachment 60323 [details] [diff] [review]
Patch for making it a pref

I'm attaching a patch for making this a pref. With the pref set the effect is
the same as with attachment 57300 [details] [diff] [review] on the Mac but with the pref service
overhead.

Both patches zap both " - Mozilla" and the build id. However, the build ID is
still available on about:blank. If you want either patch to go in, you'll need
to convince Asa and MPT that build ID on about:blank is enough. 

I'd prefer attachment 57300 [details] [diff] [review] which just zaps the extra stuff on the Mac and
doesn't access the pref service.
..or rather, I'd prefer zapping " - Mozilla" and the build ID on other
platforms, too. I don't like the extra stuff on Linux and Solaris, either.

Updated

17 years ago
Keywords: mozilla1.0 → mozilla0.9.8

Comment 23

17 years ago
smfr (or one of the other super reviewers, but I think it was him) told me #ifdef 
XP_MAC is not acceptable in that file ... so the pref thing is probably better. 

I think this is probably called quite a lot (this is a guess), so I'm not 
convinced its a great idea to read from the prefs service every time.

The two ways of fixing that would be to use an instance variable, or something 
like the admitedly ugly local static approach

static bool needToGetPref = true
static bool userWantsTitle = true

if (!needToGetPref){
	userWantsTitle = pref service lookup ...
	needToGetPref = false;
}

The instance variable approach is much cleaner, naturally it should actually be a 
class variable (static) if its the same for all windows...

Come up with a fix to that stuff and I will r=.

(obviously we can make this platform specific by setting the pref to different 
defaults on each platform. If you go that route, you need to include that in the 
patch too).

Comment 24

17 years ago
I just measured henri's patch. Using a pref takes ~1 tick (this is Mac OS 10, on 
a G4 400mhz) and its called twice every time we open a window. I'm not sure 
exactly what the ticksize is on mac os x, but its either 1 millisecond or less.

So ignore my earlier comment.

That said, aparently Asa will block any patch which removes the build id from the 
title bar, so we'll have to change the DTDs. sigh... 

Comment 25

17 years ago
Must...resist...making a...derisory...comment...

Comment 26

17 years ago
Created attachment 61868 [details] [diff] [review]
new patch addresses most concerns

This patch builds on Henri's. It makes it a pref, turns that pref on only on
Mac OS (so all other platforms keep "Mozilla" or "Netscape" in the name.

It also *preserves* the buildid in the titlebar in Mozilla builds, regardless
of the setting of the pref on any given platform.

Obviously in commercial Netscape builds, we get the desired effect, which is
the window title is the document title with no embelishments.

Everyone satisfied? If you want to flip the pref on Linux/Windows, please argue
about that somewhere other than this bug.
Attachment #57300 - Attachment is obsolete: true
Attachment #60323 - Attachment is obsolete: true

Updated

17 years ago
Keywords: review

Comment 27

17 years ago
LordPixel, does the pref also turn off the titlemodifiermenuseparator (" - ")
from displaying if the buildName is turned off? It should, since the buildID
will already be "seperated" by the curly brackets.

Also, be sure this takes effect on Mac OS X as well.

Comment 28

17 years ago
Yes, I noticed the problem with the hyphen this morning. I'll fix the patch later 
when I have more time.

Also, I test on mac os x first.

Comment 29

17 years ago
Created attachment 61897 [details] [diff] [review]
Fixes the hyphenation issue
Attachment #61868 - Attachment is obsolete: true

Comment 30

17 years ago
Created attachment 62648 [details] [diff] [review]
Removes "- Mozilla" on Mac OS. Moves the buildid into the menubar

Alternative solution

1/ remove "- Mozilla" on Mac OS only

2/ move "{buildid: XXXXXXXXXXXX}" into the menubar on all platforms.

I add it to the name of "Debug" menu, so the menu is called "Debug {buildid:
XXXXXXXXXX}"

This is highly visible, and it means Moz has nice window titles on Mac OS.

Came up with this idea chatting to timeless earlier today.

Comment 31

16 years ago
Nominating for Mozilla 1.1. Can we get this patch reviewed and into the beta, or
does it need to wait for 1.2?

(Does this really depend on bug 56993?)
Keywords: mozilla0.9.8 → mozilla1.1

Comment 32

16 years ago
What if I have an "IE" skin for Mozilla, and the same page loaded in Moz and
IE... how do I tell which application is which?

What other application doesn't name themselves in the window title? That's what
it's *for*. Document <title> is secondary.
> What if I have an "IE" skin for Mozilla, and the same page loaded in Moz 
> and IE... how do I tell which application is which?

- Doctor, doctor, it hurts when I do this!
- Don't do it then.

It is silly that Mozilla should include additional cruft in the title bar in
order to let users of an IE theme distinguish between Mozilla and IE. If you
want then to be distinguishable, don't use a theme that makes them
indistinguishable. Like, duh.

> What other application doesn't name themselves in the window title? 
> That's what it's *for*.

I'm guessing you are a Windows user. 

Opera 6 doesn't show the app name in the title bar when run in the SDI mode on
Windows XP. I can distinguish between Mozilla, Opera and IE because their UIs
aren't identical and they all have distinct icons in the top left corder of the
windows and in the Taskbar.

On the Classic Mac OS and on Mac OS X, Netscape and Mozilla are the only apps
whose windows have the app name in the title bar even though there is a document
title. So how do I know which app I'm looking at? First of all, apps don't look
exactly *identical*, even though they are supposed to look *similar* to each
other. Secondly, the app name is displayed in the menu bar (which is the
platform convention). When I'm looking at the window listings in the Dock, the
window titles are grouped by app, so including the app name in the window titles
is useless and adds clutter.

In the GTK/Gnome world, things are usually less consistent than on Mac. A quick
sampling shows that there are apps that don't include the app name in document
windows and then there are those that do. The GIMP and Dia (whose accessory
windows could be considered relatively Mac-like) don't have the app name in the
title bar of document windows. Gnumeric and AbiWord (whose UI design could be
considered more Windows-like) have the app name in the title bar. It is worth
noting, though, that AbiWord also exists on Windows and that might affect the
UI. Galeon has the app name in the title bar, but that could be considered to be
just Mozilla influence. 

Again, the fact that the UIs of different apps aren't identical, even though
they are similar, is enough for me to figure out which app I'm looking at. When
the window titles show up in the Gnome Panel, they are prefixed with distinct
icons that let me know which app they belong to.

Comment 34

16 years ago
in the future, mozilla and ie will probably both put site icons into the system 
menu instead of app/document icons, this means that the visual queue you 
suggest will be gone.

mpt suggests that users won't, don't and shouldn't care which app is doing the 
rendering.

that's certainly one view. if you want to know which is doing it, then 
help>about (windows) will tell you. [for MacOS you'd just check the multifinder 
area, and for MacOSX you'd check the app menu]
Assignee: ben → lordpixel
Konqueror put a favicon in Gnome Panel. I didn't like it.

Which icon would you use when the Taskbar on Windows XP or the Gnome Panel
groups Mozilla windows?

Comment 36

16 years ago
app icon, which would probably be a lizard/raptor/M. but you really don't want 
to think about this (this is partially an unsettled legal issue) as it's 
probably the job of that app (taskbar/panel) to pick the icon, i don't think 
there's an attribute they look for. -- I could be wrong in which case you 
should definitely correct me :)

Comment 37

16 years ago
[change keyword since Mozilla 1.1 has already been released]
Keywords: mozilla1.1 → mozilla1.2, nsbeta1

Comment 38

16 years ago
What is the status of this patch? Is it still up to date? Will it make it into
mozilla1.2?
Keywords: helpwanted
adt:nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Updated

15 years ago
No longer depends on: 56993

Comment 40

15 years ago
Created attachment 127602 [details] [diff] [review]
patch to fix windows and tabs based on pref

this is a patch to remove " - Mozilla" from the titlebar on the mac, based on
attachment 62648 [details] [diff] [review]. i didn't look at moving the build id to the debug or QA menu,
because that's a wee bit beyond my current knowledge of mozilla. (-:

suggestions / revisions would be appreciated. thanks.
Attachment #61897 - Attachment is obsolete: true
Attachment #62648 - Attachment is obsolete: true

Updated

15 years ago
Status: NEW → ASSIGNED

Comment 41

15 years ago
taking
Assignee: lordpixel → lbenne01
Status: ASSIGNED → NEW
Keywords: helpwanted, mozilla1.2, nsbeta1-

Updated

15 years ago
Status: NEW → ASSIGNED

Updated

15 years ago
Assignee: lbenne01 → guifeatures
Status: ASSIGNED → NEW

Comment 42

15 years ago
i didn't read all of this, but it seemed to me that people are only talking 
about advertisement. i think i've got an interresting point to add. 
i have a mouse with 2 thumbbuttons and i'm using imwheel to make them work as 
"back" and "forward" keys. imwheel translates the 6th and 7th mousebutton to 
another event depending on the window title that the mouse action happend on. 
so i vote for the Mozilla in the title. 
Product: Core → Mozilla Application Suite

Comment 43

14 years ago
, or patch review? Both Seamonkey and FF continue to lack the application icon
on window titlebars on Mac (bug 107695 duped to this).
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures

Updated

10 years ago
Component: XP Apps: GUI Features → UI Design
(Assignee)

Updated

10 years ago
Depends on: 457548
(Assignee)

Comment 45

10 years ago
I'll do mailNews et al once bug 457548 is resolved.
Assignee: nobody → stefanh
Severity: enhancement → normal
OS: All → Mac OS X
Priority: P3 → --
Target Milestone: Future → seamonkey2.0a2
(Assignee)

Comment 46

10 years ago
Created attachment 344144 [details] [diff] [review]
Patch for mailNews

Just attaching a patch for mailNews.
(Assignee)

Comment 47

10 years ago
Created attachment 355846 [details] [diff] [review]
Remove appName from viewPartialSource.xul (pushed)

Neil, are you OK with this? Afaics, this is the only window (that isn't a "main" window) that has "- SeaMonkey" appended to the title. My idea is that in order to be consistent with the other windows win/nix should be happy with this change too.
Attachment #355846 - Flags: superreview?(neil)
Attachment #355846 - Flags: review?(neil)

Updated

10 years ago
Attachment #355846 - Flags: superreview?(neil)
Attachment #355846 - Flags: superreview+
Attachment #355846 - Flags: review?(neil)
Attachment #355846 - Flags: review+

Comment 48

10 years ago
Comment on attachment 355846 [details] [diff] [review]
Remove appName from viewPartialSource.xul (pushed)

I guess this is OK. (Regular view source does have a - SeaMonkey, but then again you can even browse in it these days!)
(Assignee)

Comment 49

10 years ago
Comment on attachment 355846 [details] [diff] [review]
Remove appName from viewPartialSource.xul (pushed)

Pushed this to comm-central as changeset 2421d18c3a24.
Attachment #355846 - Attachment description: Remove appName from viewPartialSource.xul → Remove appName from viewPartialSource.xul (pushed)
(Assignee)

Comment 50

10 years ago
Comment on attachment 344144 [details] [diff] [review]
Patch for mailNews

I think we can do this now, after this it's onlt browser left.
Attachment #344144 - Flags: review?(mnyromyr)
(Assignee)

Comment 51

10 years ago
Comment on attachment 344144 [details] [diff] [review]
Patch for mailNews

(This is identical to how Thunderbird does it, btw)

Updated

10 years ago
Attachment #344144 - Flags: review?(mnyromyr) → review+

Comment 52

10 years ago
Comment on attachment 344144 [details] [diff] [review]
Patch for mailNews

Looks sane (for Mac at least).
(Assignee)

Updated

10 years ago
Attachment #344144 - Flags: superreview?(neil)
(Assignee)

Comment 53

10 years ago
Created attachment 357723 [details] [diff] [review]
New version without ifdef'ing (pushed)
Attachment #357723 - Flags: superreview?(neil)
(Assignee)

Updated

10 years ago
Attachment #344144 - Flags: superreview?(neil)

Updated

10 years ago
Attachment #357723 - Flags: superreview?(neil) → superreview+
(Assignee)

Comment 54

10 years ago
Comment on attachment 357723 [details] [diff] [review]
New version without ifdef'ing (pushed)

Pushed this as changeset ef7223d5becb. I'll leave this open until browser windows are fixed.
Attachment #357723 - Attachment description: New version without ifdef'ing → New version without ifdef'ing (pushed)
(Assignee)

Updated

10 years ago
Attachment #344144 - Attachment is obsolete: true
(Assignee)

Comment 55

9 years ago
I fixed the browser in bug 457548.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: seamonkey2.0a2 → seamonkey2.0b2
You need to log in before you can comment on or make changes to this bug.