Closed Bug 77258 Opened 23 years ago Closed 23 years ago

search personal toolbar icon and url bar icon

Categories

(SeaMonkey :: Search, defect, P1)

Product:
SeaMonkey
Component:
Search
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
mozilla0.9.1

People

(Reporter: matt, Assigned: matt)

Details

Add icon on personal toolbar for search
change button for search.

I'll use a place holder instead until icon is created.
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1
do we have a bug for the icon creation? can we put that in here as a dependency? 
sure, if you like. i am working on that icon and a bunch of others right now 
though

What?  How many freaking search icons are we going to have.  Once again, making 
the personal toolbar NOT PERSONAL.  Hello?  Anyone home?
Is this adding another static button to the personal toolbar? (that's what it
sounds like because currently, bar adding another datasource to the bookmarks
area, we don't support custom bookmark icons) If so, I ask that this be
reconsidered. Per Design E, already 50% of the "personal" toolbar in commercial
builds is gone for static, mostly useless donkey crap. Adding more items would
make less than half the horizontal space at the average resolution available.
This would make migration of bookmarks 4.x profiles practically useless. Could
somebody please tell whomever makes these decisions to stop undermining those of
us who are working hard to make the features that our customers care about kick
ass. 

At any rate, no more static icons will be accepted in Mozilla. Suggest moving
this bug to bugscape. 

(On a positive note, the search integration that german designed for joe's
autocomplete widget is fabulous and obvious, a real convenience. How about we do
more things like that - that make sense for the user?)


calm down kerzmaster.  these are removable buttons - thus the, "personal" aspect 
is still there

Lame. 

Personal Toolbar has always meant bookmarks toolbar. How many novices are going
to know that they can turn all this off through preferences? These items should
all be bookmarks folders and items if they're going to be there at all. That
provides the consistency of UI that this toolbar needs. 
Can someone point me to the spec on this please?  This was discussed and
evaluated in a public forum I trust?  Anyone have news URLs they can point me to?
This is not acceptable in Mozilla.  This bug should be closed and moved to 
BugScape.  It is completely ridiculous to have a Search button on the Personal 
Toolbar.

Wontfix on behalf of Navigator.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Verifying.  Have a nice day.
Status: RESOLVED → VERIFIED
I'm glad this got misfiled in bugzilla, because it exposed what seems to be a
bad idea some at netscape.com are intent on foisting on their Mozilla-derived
product.  Is anyone in favor of the donkey crap in the PT that Ben decries
willing to stand up and defend it in public?  Sophistry about removable but
there by default donkey-crap buttons being somehow "personal" aside?

/be
if users actually found a search button useful at some point, would it matter in 
this discussion?? 

there's a report showing that some of the donkey-crap (namely search button) in 
4.x received extremely high frequency. did users find it useful after?  that i 
don't know. apparently users relied heavily on a simple button, as the report 
implied the relatively complex search facility in 6.0 did not perform as well. i 
do not know what mozilla reports showed however.

German is constantly promoting search as one of the biggest and most common user 
tasks,  article here cited recently-

http://www.useit.com/alertbox/20010415.html

i feel that by providing both simple to discover AND advanced search facilities 
we accommodate more users equally.  however intrusive adding yet another button 
might seem, search is genuinely worthwhile. there are two justifications that 
happen to coincide here. one of them happens to work for mozilla imo.

Then how about we look at how the current toolbar structure, while initially
designed with the best intentions, cannot scale to accompany UI for items which
users need, rather than shovelling items into the user's personal space?

I've been meaning to try and start a discussion on this very issue for some time
now, knowing that there are probably buttons that need to be added, and there
are buttons that some vendors may wish to add. The conclusion that I've come to
is that the current toolbar setup doesn't work well in this case, and I think we
need to discuss what changes can be made to make it work. 
As surprising as it may seem, this was actually a good compromise with the
business owners of search.  I agree that this bug should be transferred to
Bugscape and there is no need for Mozilla to add this button.  Once the bug is
transferred to Bugscape, I'd be glad to post the analysis behind the decision (I
can assure you there was plenty).

As for personal toolbar space in general, I agree we need to manage this space
with end users in mind, and it is difficult given the value of the real estate
to business owners and constituents inside and outside the company.  But to me,
this is much better than adding big buttons to the main toolbar, which I'm sure
it will alarm you to know, is what the Netscape.com folks would really like.  I
personally would like to minimize the number of items we ship in the personal
toolbar and I'll be doing what I can to affect this.
We had discussions about toolbar contents, many months ago in the UI newsgroup
and elsewhere, but I don't feel they are reflected in the current design. I
agree that Search deserves a prominent button, as does Print and possibly even
Home, but have always felt they should go in the main toolbar, not the
"personal" toolbar.  
cc'ing German

Here's is the backdrop:
while we are gently moving the url bar to be more suitable to how people
navigate the web: more and more search becomes the relevant way get at web based
information. While we are doing that there is number of users still (mostly
beginners), that are coming from a 4.x usage background that expect "Search" to
be a web destination, and are not ready yet to use the integrated search. To
accomodate these users we were looking for a solution and the bookmarks bar
seemed to be the most suitable.
Also like any button on the personal toolbar is supposed to be, the search
button will be removable for those not desiring it. We are still debvating
whether there is a need at all for the search button to the left of the url bar,
as we now will have a much better autocomplete that integrates search
functionality right into the url bar in a more obvious and visible way. Folks
this is work in progress, much like users change the way they navigate the internet.
Here's is the backdrop:
while we are gently moving the url bar to be more suitable to how people
navigate the web: more and more search becomes the relevant way get at web based
information. While we are doing that there is number of users still (mostly
beginners), that are coming from a 4.x usage background that expect "Search" to
be a web destination, and are not ready yet to use the integrated search. To
accomodate these users we were looking for a solution and the bookmarks bar
seemed to be the most suitable.
Also like any button on the personal toolbar is supposed to be, the search
button will be removable for those not desiring it. We are still debvating
whether there is a need at all for the search button to the left of the url bar,
as we now will have a much better autocomplete that integrates search
functionality right into the url bar in a more obvious and visible way. Folks
this is work in progress, much like users change the way they navigate the internet.
Summary: search personal toolbar icon and url bar icon
Summary: search personal toolbar icon and url bar icon
The ability to add and remove buttons is not a defining characteristic of the 
personal toolbar; eventually it will be generic behavior for all toolbars.  
Despite noble efforts to prove otherwise, there is nothing innately personal 
about searching.  The Personal Toolbar has (theoretically) a very narrow 
purpose: easy access to oft-used bookmarks/links.  Some have suggested renaming 
it the `Links Bar', as in IE.  You yourself called it the `Bookmarks Bar.' That 
said, why do you feel that the bookmarks bar is the most suitable place to 
store a search button?  The more extraneous and unnecessary buttons you add to 
the toolbar, the more you dilute it, and the less usable it becomes.  Some 
users might be caught in a sticky situation where they have to keep the entire 
toolbar open just for one or two misplaced buttons.

As Ben said (and as Matthew has been advocating for years), the solution is to 
rethink our current toolbar structure.  Letting buttons spill onto the personal 
toolbar just because our current, braindead design prevents them from fitting 
elsewhere isn't an acceptable solution.
marlon, german: strawman arguments about the desirability of a discoverable,
dedicated search UI, talk about removability, and claims that it helps some
users, do not count.  My 4.x netscape has a personal toolbar, I've used it for
years, it's fully populated by *my* *personal* links.  Don't usurp it, or I will
not use your browser.  If you don't care about me, consider all those 4.x users
who have not migrated to 6.0x.  How many can you afford to alienate?  I'd like a
rough number estimate.

/be
Adding buttons that can be disabled in preferences is a cop out, not a solution.
We should all feel ashamed of ourselves for even /thinking/ of it as a viable
option. This is not a geek protest. This is not engineering being selfish. This
is a real concern. If you cannot see it you are deluding yourselves. 

If you value the integrity of your work, learn to say "no." Standing between
Netscape.com's need to make money and CPD's need to make a decent browser is one
thing: User Interface Design. 

Now, here's what I expect. I expect the UE group to either produce viable UI
that satisfy Netscape.com's need to make money, or I expect them to tell
Netscape.com that it is not possible within the constraints of the system.
Otherwise I believe that Netscape.com should create its own distribution for
itself by itself. I do not expect to see the company that I work for driven into
the ground by a combination of stupidity and resignation. 

You can expect me to continue to be a pain in the ass on a daily basis if need
be about these issues, wherever they may fall (Bugzilla, Bugscape) until the
appropriate people obtain clues. 

Read the headlines. Read the feedback forums. Netscape doesn't have a lot of
fans left. Netscape 6.0 was an abortion of a release. Let's try not to make it
worse, okay?


heh, where's a strawman? nowhere did German or I infer someone else's argument. 
perhaps you meant something else.

actually, here's a strawman fallacy - i argued simpler search is necessary in 
6.x.  And instead of arguing that search was unnecessary,  you (collectively) 
replied: it's not needed for Mozilla; search doesn't belong in the personal 
toolbar. we already admitted it might not be necessary for mozilla, so... why not 
argue with *us* instead of strawman?   we simply made two points - there are 
marketing needs and UI needs, we are not covering up anything.  the report made 
it clear - users did not know that they could click the search button with an 
empty field.  
  
Search is one of the biggest and most common user tasks. 4.x simple search 
feature is used with very high success (i.e. people push the button alot). A more 
complex 6.0 search feature is comparatively unsuccessful (i.e. people aren't 
pushing the button).  Therefore 6.0 search is not as successful at accomplishing 
one of the biggest and most common user tasks. This is a big UE problem.

so far i haven't seen anyone refute that.

• "...i've used it for years, it's fully populated by *my* *personal* links" - 
this inference does not prove that a search button would be unwelcome or 
detrimental

• "braindead design prevents them from fitting elsewhere isn't an acceptable 
solution" - ad hominem

• "Bookmarks Bar, Personal Toolbar, Links Bar" - the mere validity of its name 
does not offer any premise for argument in this case, nor by any means does it 
preclude adding search to the toolbar.


personal gripes and snide remarks are meaningless and don't qualify as arguments. 
they only allow us to lower our expectations of you.


i would be interested discussing:

• (obvious) if any evidence we have gathered in context which showed "Home", 
"Search", and "My" would or were impeding bookmark tasks. Show how a users 
perception of the toolbar was altered by the existence of 2 or 3 other features 
which could be not manipulated like bookmarks. to what degree there was 
confusion? finally, did users discover that they could customize the non-
bookmarks?

• for users which actively manage their personal toolbar: evidence which shows 
there are many/some/none cases where users already allocated a bookmark to link 
to their favorite Search feature. 

• another solution which may have been already been mentioned, but i'm not sure 
could not get implemented -  we could add value to bookmarks and suffice 
marketing demands both, if we offered custom icons.  so that each bookmark's look 
could be user-selected through bookmark management, offering a small set of 
differing colors, and icons:  a car, a Home, a Search, a bike, one for Sports, 
etc. then it's just a matter of setting up the default links.  this solution 
would be the least intrusive.

•  an idea to turn the personal toolbar into an expandable "tray".  The tray 
could either a) scroll left to right with buttons at each end, b) scroll left to 
right with dragging (using a modifier and click), or c) expand the personal 
toolbar tray vertically by dragging on a separator grippy up and down.




 

Since you're complaining about everyone else's lack of evidence (and since 
you're arguing in favor of changing the current behavior), can you please cite 
yours?  That "search is one of the biggest and most common user tasks" is 
probably well supported by the research cited in the useit.com url you cited, 
but so far I haven't seen any usability data that shows that the solution 
you're proposing is the way to go.  Frankly, however, I'd be wary of any such 
usability data; I believe it was German who explained the movement of the 
Search button to its current location by saying that 4.x users tried to search 
for a term in the urlbar by clicking the Search button.  Now you seem to be 
saying that users don't realize they can go to the search page through the 
button, and you want to add *another* one to make this clear.  Is the plan 
currently to add and move buttons around at will until a few million users get 
it right? I was under the impression that complaints or problems are detected, 
feasible solutions are designed based on the data, and then the various designs 
are tested on a sample of people to see the reaction.

(And, honestly, did you really expect this to pass by without an outcry?  A bug 
was filed in an engineering component definitively stating what was to be done, 
without any sort of explanation.  You bypassed any type of Mozilla UI design 
process currently in place (discussing in the newsgroups, filing in User 
Interface Design, discussing with members of the community).  The comments that 
I see in this bug are not necessarily `snide remarks,' they are passionate 
remarks from people who spend their time working to improve the product only to 
hit the brick wall of a marketing department that thinks it's qualified to make 
(or heavily influence) user interface decisions.)

Now for some of your arguments: 

> this inference does not prove that a search button would be unwelcome or 
> detrimental

It does not indeed.  But generally it's up to the people arguing for change to 
support themselves with tangible evidence.  If this is that important to 
marketing and users (and you've made it clear that it is), why are we grasping 
at straws instead of testing solutions?  Or will the results of this discussion 
be tested?  The original bug invited no discussion whatsoever, instead stating 
matter-of-factly what's happening.

> "braindead design prevents them from fitting elsewhere isn't an acceptable 
> solution" - ad hominem

How so?  It's a serious issue. I don't know how Netscape has responded publicly 
to the many complaints that the Home button deserves a more prominent position 
on the Navigation toolbar, but here in xpapps land the real reason is "lack of 
space."  That's also partly the same reason that most users can't see the last 
part of most web addresses.  

> "Bookmarks Bar, Personal Toolbar, Links Bar" - the mere validity of its name 
> does not offer any premise for argument in this case, nor by any means does it
> preclude adding search to the toolbar.

It confuses me that you seem to imply that the contents of a toolbar are 
irrespective of its name.  (Yes, I do think the Navigation toolbar should be 
renamed once it becomes the normal toolbar it should be).

Before I made this comment, I was unaware that you were *adding* another Search 
button, given the bug report's cryptic language (I presume this is the case 
from numerous reports, but correct me if I'm wrong); I assumed you were just 
moving it.  So, like you, I would like to discuss a couple issues myself:

•  How do you address the fact that the user will be staring at two "Search" 
buttons*?  In your mind, how does this *clarify* things?  How does the user 
know which button does what if they didn't know before?  Why is it a good idea 
to dramatically change search behavior again now that Netscape 6.01 users have 
finally grown accustomed to it?  Is having three different core search designs 
among three different releases a good idea?  If so, shouldn't this be the time 
to get it right? 

[*] Some have said that the plan is to remove the text from the button next to 
the urlbar, leaving just an icon.  I can't discern that either from this bug 
report, so I'll leave that alone for now.]

•  What's running through the user's mind when she sees two checkboxes 
labeled "Search" in the toolbar customizability list (a hack which will later 
be removed)?

•  What kind of usability studies were done to solve the 4.x problem (see 
above) such that it resulted in the inverse problem in 6.0?  What has been done 
differently this time around to make you more confident that this solution is 
the one to solve both problems?

Have you looked through the currently open Search bugs?  I know that Matthew 
Thomas, for one, has some well thought-out comments and designs concerning 
Search in them.

That said, understanding that Netscape has marketing needs and secure in the 
knowledge that nothing of this sort will happen in Mozilla (although hopefully 
search will be improved in other ways), I do appreciate your open-mindedness 
and willingness to explore other alternatives.  Personally, I'd like to see 
this bug stay closed and work be done on improving the Search functionality 
(see other bugs, or talk to Matthew).

Finally, in bug 71138, I asked if you could create an icon for a proposed `Add 
Bookmark' button.  You responded `when in doubt, leave it out'.  I'd say 
there's more than reasonable doubt here, so what's the deal?
marlon, nice try taking the high road after the battle was over.  FYI, I will
continue to be as personal, gripey, and snide as I always have been -- but you
won't find fallacies, rewrites of history, or misused English in my bug
comments.  Get used to it.

>heh, where's a strawman? nowhere did German or I infer someone else's argument.

You mean imply, not infer.

>perhaps you meant something else.

No, I mean your comments dated 2001-04-26 and 001-04-25.  Search PT icon
removability, search discoverability, etc., are strawmen.  The *non-strawman*
argument to knock down *in this bug*, if you can, is the one I repeated, which
Ben made in his 2001-04-25 22:35 comment ("Personal Toolbar has always meant
bookmarks toolbar") and 2001-04-25 22:27 comment ("This would make migration of
bookmarks 4.x profiles practically useless"), kerz made in his 2001-04-25 22:22
comment ("Once again, making the personal toolbar NOT PERSONAL"), etc. etc.

This bug's summary is "search personal toolbar icon..." not "simpler search is
necessary for 6.x" (use Mozilla milestones, please).

You did not advance an argument here that others failed to rebut, instead
erecting their own strawmen.  It was you who did a drive-by (2001-04-25 22:30)
sniping at kerz (personal, if not snide, remark) and injecting the removability
straw-man as if that has any merit or relevance.  You then erected the
discoverability strawman.

Who is the royal "we" ("we simply made two points") in your latest comment,
which rewrites this bug's history?  You and German came late and off-topic.
Where did any of your points get made in an open forum *before* this bug was
filed in an attempt to usurp yet another personal toolbar place?

It's great to design a better PT or otherwise improve Mozilla UI in ways that
everyone agrees with.  That has nothing to do with this bug or the hostile
reaction it elicited, to which you then jumped in with fallacy after fallacy.

>* "...i've used it for years, it's fully populated by *my* *personal* links" - 
>this inference does not prove that a search button would be unwelcome or 
>detrimental

That's not an inference, it's a statement of fact.  Get your vocabulary
straight.

FYI, *I* say this bug's summary and intent are unwelcome and detrimental,
because my maximized window's PT is full right now, and I keep it full.  But
your vague language ("unwelcome" or "detrimental" to whom?) leave you
weasel-room to argue that some cohort in the 4.x installed base may have PT room
to spare -- and I won't take that bait.  Answer my question: how many users can
you afford to alienate into sticking with 4.x or switching to another browser?

Don't bother with more fallacies or rewrites of the history of this bug.  Take
design issues to the newsgroup and stop trying to get the last word in this bug,
which is already a poisoned well, thanks both to its original summary and clear
intent, and to the fallacious, spurious defenses that you and others mounted of
adding a search icon to the PT. 

/be
OK! Now that we've all cleared our throats, so to speak ;) 

We've all made good points here. Unfortunately it's mostly tied up in strongly 
written sentences - and I take the blame for this having started it. 

Summarizing what I believe to be the key points raised:-

Facts:
- Seamonkey's current search system is sophisticated but less successful
- Netscape 4.x's prominent simple search is a proven success
- Seamonkey's personal toolbar offers less horizontal space for bookmarks
  than Netscape 4.7 (in Mozilla and Commercial builds, especially Comm.)
- Importing a full personal toolbar folder from a 4.7 profile will lead to
  some bookmarks being invisible.

Requirements:
- Netscape.com has informed CPD that the search layout of 6.0 and Seamonkey
  is less beneficial to them, and they would like improvements made.

Proposed solutions:
- add a search button to the personal toolbar, reviving 4.x's simple search.

Given the layout of Navigator's toolbars currently, the proposal that UE has 
come up with is probably the only option. There aren't many spots on the 
Navigation toolbar for another button, the only place being over by the print 
button and there's already a Search button there. You could perhaps argue for a 
search button to the left of the Location field, but given the size of the 
location field in standard resolutions, especially in the Classic Skin, this 
will probably cause other usability problems.

Search isn't the only button that people have wanted to add. Print was added 
around the middle of last year among some fuss about its placement on the 
"Navigation" toolbar. I'm sure there have been others and will be others. 
Commercial builds have static "My Netscape" buttons in the personal toolbar as 
well.

What this seems to be suggesting, in my mind, is that the current toolbar layout 
does not scale, and does not work for a commercial distribution. 

What I propose therefore is a family of possible solutions based around the 
toolbar layout from previous Netscape releases (4.7) and Internet Explorer:

Solution A) Like Netscape 4.x or IE:
1) Command Toolbar  (Back, Fwd, Reload, Stop, other buttons)
2) Location Toolbar (Location Field)
3) Personal Toolbar (User's bookmarks)

Solution B) Like AOL:
1) Command Toolbar     (other buttons)
2) Navigation Toolbar  (Back, Fwd, Reload, Stop, Location Field)
3) Personal Toolbar    (User's bookmarks)

I think these solutions or a solution similar to these will allow commercial 
vendors like Netscape.com to be satisfied, and users to be satisfied as well. 
[Plug: Not to mention these solutions also make toolbar customization easier to 
implement!]


Newsgroup thread, please.  Please don't morph this bug after it is VERIFIED
WONTFIX.  Let it record the decision (flames and all) not to add a search icon
to Mozilla's PT.

/be
Index to this bug
=================
address field, shortness of .................................. bug 43739
affect (verb) vs. effect (verb) ... http://bartleby.com/64/C003/015.html
Bauer, German, on use of Personal Toolbar ... bug 48704 2000-08-11 18:46
bookmarks, custom icons for .................................. bug 32087
Bookmarks Bar, renaming Personal Toolbar to .................. bug 48820
buttons, duplicate, confusion caused by ...................... bug 21059
infer vs. imply .................. http://bartleby.com/64/C003/0174.html
scrolling tray for Personal Toolbar  http://iarchitect.com/tabs.htm#TAB7
Search UI failure in Seamonkey
  business owners of .................................. file:///dev/null
  constituents of ............................................ bug 76547
  mpt's warnings . bug 28146, bug 32791 2000-07-10, bug 44455 2000-07-14
searches are belong to Netscape, all your .................... bug 65911
Toolbar
  need for one in Seamonkey .................................. bug 49543
  use of, for Add Bookmark button ............................ bug 71138
  use of, for Home button bug ................................ bug 65088
  use of, for Load Images button ............................. bug 61710
  use of, for Print button ................................... bug 50106
  use of, for Search button ............................ yet to be filed
actually meant infer, not imply. i would draw an irrelevant inference with 
someone's argument, present it, and defeat it. you appear to have somewhat loose 
interpretation of a strawman, i believe we are loosing focus of the real issue. i 
am sorry i brought it up, let's not belabor it. 

about my response to Jason where (2001-04-25 22:30) (which was 
supposed to be jokingly poking at him, i apologize if anyone misinterpreted 
that)  I simply meant- the personal toolbar is a place to contain items which a 
user can customize and manipulate.  a bookmark item is customizable, and can be 
manipulated.  a search button is also customizable, and 
can be manipulated. therefore, both bookmarks and a search button should be on 
the personal toolbar.

"should" be on the personal toolbar (not MUST), I agree with Ben's well 
made point that our toolbars are not scalable.  but short of adding a new toolbar 
or redesigning the browser... we're late in the game, this is the most 
logical next place. Of course there is always going to be risk of alienating some 
users when you redesign something, we just have to do something that is the most 
acceptable. 
 
mpt -  http://iarchitect.com/tabs.htm#TAB7 - that is true, there are lots of 
dangers with tabs.

are we moving any remnants of discussion over to newsgroup?

Starting a thread in n.p.m.ui now called "Navigator Toolbar UI." I invite 
everybody here to join in. Yes, it is a bit late to propose this for some 
releases, since it would require (probably) non-trivial modifications to the 
skins. However, I think it's probably a good idea to start talking now so we 
can prioritize it for the next release cycle. 
More fallacies, so I must labor, if not belabor the point:

"I simply meant- the personal toolbar is a place to contain items which a user
can customize and manipulate.  a bookmark item is customizable, and can be
manipulated.  a search button is also customizable, and can be manipulated.
therefore, both bookmarks and a search button should be on the personal
toolbar."

This is a syllogism of the form

major: PT contains items that users can C&M
minor: bookmark items can be C&M; search button can be C&M
conclusion: PT should contain search button

There's actually a fourth term (bookmark item), so this appears at first to be
an example of the fallacy of the fourth term.  But let's say "items" in the
major premise are bookmark items (and ignore Net2phone and other gewgaws), and
try to fix the syllogism to use only three categorical terms: belongs-on-the-PT
(B), C&M-able-item [the middle term] (C), and of course the-search-button (S):

major: all C are B
minor: S is C
conclusion: S is B

It's a nice argument, and I still call it a strawman, because it is both weaker
than and different from the one kerz, Ben, et al. are making:

major: all B are U
minor: S is not U
conclusion: S is not B

where U is user-defined.

It doesn't matter one whit how C&M-able a Netscape-predefined item may be; if it
isn't user-defined, it doesn't belong on the PT.  And the lateness of the hour,
and the scarcity of space on other toolbars, do not count for more than special
pleading in bugscape.

/be

(mpt: nice Index! Please add "loosing" vs. "losing".)
wow, clearly masterful spelling. i guess we have to reach now, perhaps our 
arguments aren't that strong after all?  let's throw in more ad hominem and 
appeal to people, then we can all sit around in powwows, eat toast with marmalade 
and scoff at each other's adam's apples.

seriously, i think we might be getting somewheres.  none of my arguments have 
been strawmen, nonetheless i will be happy to tranquillize myself for the 
remainder of the discussion, while you continue to bludgeon it.  here's a new 
term you might like to try out: red herring.  it'd make a nice replacement for 
your version of strawman 

okey dokey, you finally started to make a point 3/4 of the way through your last 
comment:


-------
"It's a nice argument, and I still call it a strawman, because it is both 
weaker
than and different from the one kerz, Ben, et al. are making:

major: all B are U
minor: S is not U
conclusion: S is not B

where U is user-defined.

It doesn't matter one whit how C&M-able a Netscape-predefined item may be; if it
isn't user-defined, it doesn't belong on the PT.  And the lateness of the hour,
and the scarcity of space on other toolbars, do not count for more than special
pleading in bugscape."

-------


as often occurs, there is simple disagreement in definitions.  The 2 arguments we 
make above are both cogent per se, contingent on the distinction we choose to 
make between "pre-defined" and "user-definied".  since we are now getting at the 
root, i will make my final argument (maybe):

user-defined items belong in the PT. since pre-defined items are also user-
defined items,  pre-defined items belong in the PT.

definitions: 

• user-defined item - an item which a user can select and make changes to
• pre-defined item - a user can select and make changes to, which has an initial 
preset made.

If it's just an argument of preset vs. not preset, consider this analogy:

When you buy a new car, the car stereo in your new car has 20 or so radio 
stations preset to randomness. More than likely, not something you are gonna live 
with.  Who here believes new car buyers feel alienated by Toyota Co, Nippon, 
because the new car they just bought had preset stations which weren't all blank? 
Do car buyers break into raging fits of insanity and switch back to their old 
cars?   

I agree that pre-defined items belong in the Personal Toolbar, but IMO the
dispute is really over what constitutes a pre-defined item.  When I upgrade to
Netscape 6 from Netscape 4.x, all of my personal toolbar links (which filled the
toolbar in 4.x) are shoved off the toolbar to make way for items that I did not
request.

A better way of thinking of it is like this.  When I installed Netscape 4.x, it
came with a bunch of pre-defined bookmarks on my Personal Toolbar.  I patiently
wiped them all, and then filled the Personal Toolbar with the stuff I wanted.

When I upgraded to Netscape 6, suddenly half of my Personal Toolbar was again
filled with pre-defined items, but I'd already expressed my desire not to have
these items when I installed 4.x.

If - every time I upgrade my browser - I again have to manually remove all of
these items to reclaim my personal toolbar space, then a bad user experience has
been created.  

Pre-defined items should just be *bookmarks* in the user's personal toolbar
folder.  They should only be present for new users, not for existing users who
upgrade.  Our desire to force these buttons onto users is what led to an entire
new toolbar show/hide UI in the prefs panels, when the existing bookmarks UI
could have sufficed, had we been willing to just fill *new* users' toolbars with
pre-defined options.

So basically I think nobody is disagreeing with the idea of pre-defined items. 
We're disagreeing with the idea that we'd put these items into someone's already
established Personal Toolbar, thereby rendering it useless.

Options to consider:
(1) Only put these items in a new user's toolbar.  Upgrading users would not
have their Personal Toolbars affected.
(2) Make a new toolbar and leave the Personal Toolbar alone.
(3) Mix and match.  Compromise on which buttons everyone should be affected by,
and be willing to make some of these buttons for new users only.

The real problem here is that we're up to six buttons and a separator that are
added to a user's *existing* personal toolbar.  I can only fit 8 buttons on my
PT right now.  If you add the two new buttons (Search and Start), when I upgrade
from 4.x to 6.5, my links will literally disappear!  That's not a good user
experience.

For the curious, the six buttons are: Search, Start, Home, MyNetscape,
Net2Phone, and Bookmarks.

The problem that David mentions is exaggerated by the fact that the static items 
appear as bookmark items, and yet they are not, they are not removable via the 
bookmarks window. Marlon mentioned near the start that it was UE's wish (correct 
me if I'm wrong) that these are actually placed in the bookmarks window and are 
removable by that mechanism. This would work for My Netscape and Search, and 
possibly Home with some cunning hackery in Bookmarks, but not for Net2Phone, 
which is a combination link button/application launcher, and not for the 
bookmarks button (although this should arguably be removed anyway and replaced 
with drag filing support into the toplevel bookmarks menu for IEp). 

A compromise:
Why can't we extend bookmarks to support custom icons (not too hard) and then 
add the search (and indeed the My Netscape) button to the default personal 
toolbar set in the default bookmarks.html? This would give david what he wants - 
not clobbering migrated profiles, give users what they want (consistent UI 
between elements). All that would then be left are buttons like Bookmarks and 
Net2Phone. 

Still encouraging people to check out the Navigator Toolbar UI thread in npm.ui 
however for a better long term solution. 
dave - very true. actually, in a world of brand new Netscape users everything would be fine - people expect to play with their settings. i guess the good news to the search marketing people (correct me if i am wrong) is at this point about 85% of the browser market ARE would-be, new Netscape users. so at least they have that going for them.  but as you mentioned, we should also be easing migration for the 4.x to 6.5, and 6.0 to 6.5.  Using my analogy from before - if you just got your car back from the shop after getting the engine tweaked, and you found out that they also messed with your stereo, changed a couple of presets. you'd either be very annoyed, or blow a fuse.  you might even kill a guy. That's going 6.0-6.5

so here are some further options based on what i've seen:

OPTION 1*) add a search button to the PT for everybody- where search link comes set with the existing search setting for the 6.0 to 6.5 upgrade, and a Netscape preset search setting for the 4.x user.  

User Experience IE, Opera, etc. (85%):  Unaffected.  Presets are to be expected especially with a new product.

User Experience NS4.x (12%): The 4.x user experiences a totally new, redesigned Netscape product for the 1st time.  new UI, can't even compare it to 4.x. there's very little transference taking place.  They will recognize their bookmarks in the PT, accompanied by the relocated search. hopefully they appreciate the reduced, cleaner four button UI, and the space savings. oh, and Net2Phone. Question: What percentage of 4.x users make use of their personal toolbar at all?

User Experience NS6.0 (3%?): user now sees an extra search button in their PT, with their existing prefs intact, they click and get a search page that is familiar to them. they find it easier to get to a search page because they have a simple button.  for those who decide it's a nuisance more than convenience; or that submitting an EMPTY text field in the URL bar makes far more sense(??) to get to a search page - they remove it. 
 
(NON)OPTION 2) add another toolbar - this just seems to be overreacting - for the addition of a single button, when the overall goal is to save space and simplify the UI.  an extra toolbar spanning the width of the browser with nothing but 2 or 3 buttons seems silly; then somebody might come along and add even more buttons for the sake of it, and we'd end up with messy, cluttered UI again. it also totally defeats 6.0's biggest novelty which is to save space.  i'd rather compromise something else.  we removed the task/status bar, let's not add another one in its place.

OPTION 3) do not change anything, unless a new profile is created.  Only Netscape newbies get a search button.. this is dangerous though, because we are creating inconsistencies within the same product version.  Some NS6 users would have simple search, and some would not. Very confusing situation. 

*For the record, there was never a plan to have 6 buttons in the PT (search, start, home, my, net2phone, bookmarks). i have never heard of such a thing- we've always planned to CONSOLIDATE with the start feature. this could begin a whole new argument, but I envision 3 buttons MAX.  If we can't hit 3, then I believe we're going too far.

Of the options mentioned, my vote is that we supply 6.0 users with the addition of simple search based on their search prefs; that we impose a max of 3 total PT buttons for everyone; and that Netscape newbies just get it all.

There is one more possibility, which could potentially leave search alone, but i am researching this option.

If Ben is being realistic about doing custom icons - then that just makes Option 1 even easier to digest.  It also makes the product more customizable, and fun. (However, if he's not already committed to getting drag'n drop working FIRST, then i'd say it's a waste of time right now)


This bug was never about adding PT search icons *only* for newbies, or no one
would have reacted badly!

I'm surprised it took so many false starts (and really long lines) to get to the
issue: don't mess with the PT when migrating profiles.

But who cares what I think?  "Personal gripes... are meaningless."  Then why
should anyone care about marlon's very personal hope ("hopefully they appreciate
the reduced, cleaner four button UI, and the space savings"), offered as the
sole rationale for his OPTION 1's effect on 4.x users?  What kind of hand-wavey
noise is this?

In the old days (4.x, I've been around since 1.1), there were at least some
junk-science usability studies.  How many 4.x users have what number of items in
their PTs is a fine question, and it should be answered *before* this bug is
filed in the form in which it was filed (it asked for OPTION 1 to be implemented
with no prior discussion; the bad reaction then drew out a backward discussion
that finally got to the obvious meat of the issue -- which is not a process to
be proud of).

Yes, this is personal: I'm here not to defend my 4.x PT.  I'm here to keep bugs
from being filled with late (where were the UI specs and open discussion?  why
haven't you, marlon, responded yet to Ben's posting in m.ui?), fallacious,
self-serving spam.  Personal accountability for bogus bug comments hurts.  For
what it's worth, I'm sorry I picked on your spelling.  I'm still angry about
this bug's entire history and what it shows about too many individuals at
netscape.com, insofar as they can be judged by their UI design ownership and
attitude toward the open source community.

BTW, don't expect any Netscape release in sight to make much of a dent in market
share.  The dominant cause of market share is distribution.  The first market to
worry about, therefore, is the one consisting of those 4.x users, who either
have some brand loyalty, or else just inertia, behind their user-agent choice.

/be
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.