Closed Bug 49201 Opened 24 years ago Closed 16 years ago

Print button should be hidden by default

Categories

(SeaMonkey :: UI Design, enhancement, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: hsivonen, Unassigned)

References

Details

2000081520 Mac, Classic theme

There is now a Print button. The space for the Print button is taken from the location field. 
As a result, the location field becomes unacceptably short at reasonable window sizes. 
Therefore, the Print button should go away. Not everybody runs their browser window 
maximized on a 1600*1200 screen.

I see the Taskbar syndrome here. Despite the UI design choices made in some apps, not 
every command needs a button. It is perfectly alright to use the menubar. Using the menu 
is fast enough a procedure to initiate printing.
Personally, I'd rather get rid of that useless search button... no offense, but
I never use search.netscape.com...
Why not make it possible to customize the taskbar? This way it would be possible
for someone who prints a lot to place a print button on his/her taskbar without
subjecting the rest of us to the button. By default, there could be one, two or
preferably, in my opinion, no buttons on the taskbar.
This could be implemented under prefs and/or a popup menu on the taskbar/taskbar
buttons.

cc self
This bug is related to (and may be a dupe of) bug 15144
The original bug has to do with removing the print button. I just posted my
$0.02 on the subject. I wouldn't call it a dupe.
The print button is discussed in bug 48704, and the search button in bug 44455.

 
Bug 15144 has been marked Future. This is not a duplicate of that bug.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
I completely agree with the inital description, just that it also applies to the
modern theme.
This should probably be marked as a duplicate of 48704 to keep all the 
discussion in one place, but I'll let German make that call.
Assignee: bdonohoe → german
I have attached modified versions of navigator.xul and navigatorOverlay.xul to 
bug 30797. These files allow the print button, the go button, and the search 
button to be toggled on and off.
These files have been tested on Win98 with the Modern skin, the Classic skin, 
and my Neoclassic skin (see bug 8415).
They need to be tested on Linux and the Mac.
Hyatt's checkin for bug 49431 includes making the print button optional. See his
comments on N.P.M.UI for details.
Ok, the Print button can now be turned off thanks to bug 49431. But it is still 
on by default, which I think is what this bug is mostly about. And when it is 
turned on, to paraphrase Ben Goodger, `the placement is sub-optimal'.

So:
* changing this bug from `Print button should be removed' to `Print button should
  be hidden by default', and downgrading to normal severity;
* filed bug 50106 about moving the Print button to a saner location.
Severity: major → normal
Summary: Print button should be removed → Print button should be hidden by default
All buttons should be on by default, so new users know they are there, unless 
there is html page that is shown at a new install that explains setting prefs.
Buttons that shorten the location bar while duplicating non-navigation menu commands 
(eg. Print, Find on Page) shouldn't be on by default.

Users who are likely to install Mozilla themselves are expected to know the basics of their 
platform including the standard location of the Print... command in the File menu. The 
button (if they really want it) is still discoverable via the pref dialog.

Users who don't know the platform basics are expected to have someone else to install 
and configure the browser for them.
Many users expect buttons to be there, and from experience many applications 
don't have configurable button bars.  A reminder that mozilla does not include 
all features from netscape4 someone might say oh no print button... no 
printing.  If you never use the menu bar (and this is possible) you'd never 
know.

Since we can't guarantee everyone takes a tutorial we have no way of explaining 
that buttons can be added or removed.

Setting status. Changing severity, this is trivial.
Severity: normal → trivial
Whiteboard: [Please Don't Fix]
> All buttons should be on by default

Do we ship with all skins? All packages?
If the window is 650px wide (a perfectly plausible scenario) and all the buttons are 
enabled, the URL http://www.mozilla.org/ doesn't fit in the URL field! It isn't a trivial 
problem.

Please express your opinion in the comment area instead of the status whiteboard.
Severity: trivial → normal
Whiteboard: [Please Don't Fix]
> [under certain circumstances] the URL http://www.mozilla.org/ doesn't fit in
> the URL field! It isn't a trivial problem.

I would even argue that this is a major problem, a blocker for shipping. At the
*very* least, the host must be fully visible (and it is common to have hostnames
with 20 chars). (Even if "Go" is disabled, we will propably still fail with
that.)
Such a tiny urlbar also looks crappy IMO.
> hostnames with 20 chars

s/hostnames/2. level domains/
Being able to customize a toolbar by turning off buttons is a feature.
Having to turn off buttons to get a usable URL field is a hack to cover a bad 
design. The solution isn't hiding buttons, it's moving the URL field to a 
location bar. See bug 49543.
This bug should be easy to fix. On the other hand, bug 49543 may remain unfixed for a 
long time.
No it should not be hidden by default. We have added it since a large number of
users (in the lab and outside) mentioned its usefulness and how they were used
to it from 4.x, Office etc.
Now for those who don't need/want it, this would usually be an audience that
would be able to find the settings under prefs that has recently been added to
turn the button off.
More toolbar customization is certainly something we should look into in future
releases. Marking fixed for now
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
No it should not be hidden by default. We have added it since a large number of
users (in the lab and outside) mentioned its usefulness and how they were used
to it from 4.x, Office etc.
Now for those who don't need/want it, this would usually be an audience that
would be able to find the settings under prefs that has recently been added to
turn the button off.
More toolbar customization is certainly something we should look into in future
releases. Marking fixed for now
Resolution: FIXED → ---
you mean wontfix, right?  reopening to mark as wontfix.
Status: RESOLVED → REOPENED
marking wontfix
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WONTFIX
german, did you collide w/ yourself, and did you use mozilla to make these 
changes?

cc tara because this is yet another resolution corruption.
yes wontfix is the right one. Timeless, I was colliding several times with myself 

while going through my bugs, using an MN6 build. Maybe the bugzilla server 

processes things at diff. speeds depending on workload.


vrfy per german
Status: RESOLVED → VERIFIED
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
This feature request is 7 year old. Time has passed and nowadays, people hardly ever print stuff. I think it is time to get rid of this "Print" button in the toolbar. Don't you think so?
Re-opening for re-consideration.
Save the trees.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Assignee: german → general
Status: REOPENED → NEW
QA Contact: mpt → general
Severity: normal → enhancement
This bug was originally WONTFIXed eight years ago. No comments in favour (well no follow-up comments at all) in 14+ months since re-opening so closing again..
Assignee: general → nobody
Status: NEW → RESOLVED
Closed: 24 years ago → 16 years ago
Component: General → UI Design
QA Contact: general → ui-design
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.