Closed Bug 44733 Opened 24 years ago Closed 24 years ago

Find dialog should be named the same in all windows

Categories

(SeaMonkey :: Bookmarks & History, defect, P2)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.8

People

(Reporter: bugzilla, Assigned: mcafee)

Details

(Whiteboard: nsbeta1+)

Attachments

(1 file)

patch to change to Search History|Bookmarks
2.66 KB, patch
Details | Diff | Splinter Review 
Build ID: 2000070608

Some inconsistencies:

* History has Edit | Find in History..., while Bookmarks just has Edit | 
Find... -- both invoke the same window (whose title is simply "Find", I filed a 
separate bug on that)

* The browser, messenger and composer use Search | Search Bookmarks/History to 
invoke this window, but Bookmarks and History totally ignore this consistency 
and put a "Find" (instead of "Search") command in the Edit menu.
I was mistaken in my original comment.  Composer also uses Edit | Find (I 
believe...I'm away now, but I remember discovering that before I left). This is 
a glaring inconsistency that we need to work out.
Summary: Inconsistency between Bookmarks, History and Navigator menus → Inconsistency between Bookmarks, History, Composer and Navigator menus
since this bug has such broad scope, cc'ing Don as blessed with looking at such things (and figuring out who should fix).

resummarizing, m19.
Summary: Inconsistency between Bookmarks, History, Composer and Navigator menus → Find dialog should be named the same in all windows
Target Milestone: --- → M19
This bug needs some Vera-work.

As for the first part:

    Main windows -- Navigator, Messenger, Composer -- should have `Find (in This
    Page) ...', `Find (in This Message) ...', and `Find (in This Page) ...'
    respectively. This is to avoid confusion with searching all messages/the
    Internet/whatever.

    The question is: do we want to continue this pattern with accessory windows
    (history, bookmarks, address book)? The History people seem to have said
    `yes', and the bookmarks people have said `no'.

As for the second part:

    I think the global items in the Search menu (CCing JohnG) should remain
    static between components, while searching bookmarks/history also have `Edit'
    > `Find ...' just like all the other components. This means multiple access
    points for searching the bookmarks/history, if you happen to be in the
    bookmarks/history at the time; but I think maintaining consistency for each
    access point outweighs the redundancy.
Assignee: slamm → verah
Steve, I'll take this and assign it back to you after I go through the UI and 
figure out what we have to change to make the UI text consistent.
first part checked in to change Edit | Find... to Edit | Find in Bookmarks...
(in Manage Bookmarks)
whoa. There is no 'Find' in bookmarks - or at least there shouldn't be. Every menucommand that invokes the big stand alone 
search window(used to be called Advanced Search) should be labled 'Search Whatever'. If you want the little stupid dialog, e.g. for 
searching within text on a page (Ctrl+F) then it should be labled 'Find in Whatever'.

I don't know the mail scenarios but for Bookmarks/History there should only be a 'Search Bookmarks/History' (as appropriate). 

OK, so the history window and the manage bookmarks window should have Edit | 
Search History... and Edit | Search Bookmarks..., respectively?
Yup. I dunno about exact wording (e.g. Search/Search in/Search within) though, that's for verah

Accepting
Status: NEW → ASSIGNED
Claudius -- what is the basis for your statement about using "Search.." 
versus "Find in..." ? I'm trying to get a handle on this so we can achieve some 
consistency.
Hmmm, I only see 3 possibilities: 1)  Everything everywhere is called 'Find...' 2) Everything everywhere is called 'Search' 3) Some 
mix of the two.

I don't support choice 1 Because, we have toplevel 'Search' menus everywhere. Are we going to use the 'Search' menu to 'Find' 
stuff? The fancy buttons in the chrome (urlbar, sidebarpanel) read 'search'. 
b) The Advanced Search dialog(the big clunky window for bookmarks/history) recently used to and one day  may again do 
Internet Searches as well. That window has the same look and feel as dong a multiple engine internet search with the sidepanel.

I'm not crazy about choice 2 either but at least it would be consistent and most everything is already called 'Search' now anyway.

I advocate choice 3.
I believe we have already taught users what the 'Find' functionality is - 'Find In Page'. A tiny dialog comes up and your word is 
selected on the page before you. I think people recognize 'Search' as something different. You get a more sophisticated dialog 
and your results are aggregated in this separate window.
4.x did this fine in Mail. 'Find' allowed you look for text within the message before you. 'Search messages' allowed you to do a 
query on all your messages and aggregate the results. I'm arguing for the same setup.

Now if that was a mistake in 4.x then I'm wrong and all this stuff should just be called the same thing :-)

I hope some of that makes sense...
</rambling diatribe>

What's wrong with this?
* The `Edit' menu has one `_Find in {current component} ...   Ctrl+F' item.
* The `Search' menu has multiple `Search {component}' items.

So yes, Bookmarks would have `Edit' > `Find in Bookmarks' and `Search' > 
`Search Bookmarks', and History would have `Edit' > `Find in History' and 
`Search' > `Search History', providing two menu items for the same dialog. But 
That's Okay. (Or, at least, it's better than confusing users by altering the 
menu structure just for these two components.)
Blocks: 44689
I'd rather not have two items in each menu. I don't think people are confused by 
mixing "search" and "find." I am persuaded by Claudius's logic: "Find in..." is 
for the little dialog, "search" is for the big one. So we need:

Edit | Search History
Edit | Search Bookmarks

Reassigning back to slamm.
(P.S. Do we have a History window?)
Assignee: verah → slamm
No longer blocks: 44689
Status: ASSIGNED → NEW
to answer the ps: yes the Global History window can be accessed by going to the Tasks toplevel menu
and selecting Tasks|Tools|History. Unless meant do we have a history search dialog? The answer to
that is 'yes' as well.

Further complicating matters are my new bugs 41616 and 41617
Yikes! Okay, *where ever* this item appears, it/they should be:

Search Bookmarks
Search History
-OR the nicely compact-
Search Bookmarks/History
reassigning to me.

So should they be in a separate Search menu or not?
Assignee: slamm → BlakeR1234
Priority: P3 → P2
Status: NEW → ASSIGNED
Priority: P2 → P5
Target Milestone: M19 → mozilla1.1
I will file a separate bug on bringing in a search menu. Yes we'd want that for 
consistency reasons with all the apps on the platform. The search menu acts as a 
consistent access point for local and global search options. I'll get back to 
this bug once the new bug is filed.

Not gonna worry about this right now...
Assignee: blakeross → ben
Status: ASSIGNED → NEW
Priority: P5 → --
Target Milestone: mozilla1.1 → ---
Netscape Nav triage team: this is a Netscape beta stopper.
Keywords: nsbeta1
Priority: -- → P2
over to chris.
Assignee: ben → mcafee
nav triage team:

marking nsbeta1+
Whiteboard: nsbeta1+
nav triage team: chris, please put a mozilla0.8 or mozilla0.9 milestone into 
this. thanks, Vishy
we marked this .8 on paper, marking it online here.
Target Milestone: --- → mozilla0.8
I am not convinced that we decided what to do by reading the above reports.
Can someone help summarize this?
1. "Find in Bookmarks" and "Find in History" in the BM/Hist windows resp. need 
to be renamed to "Search Bookmarks" and "Search History"
2. A separate discussion/bug deals with whether we need to make these two 
windows consistent with other app windows by moving those items to a separate 
Search menu for those windows
1 can be done without waiting for 2.
thanks german.  What should the accelerator key be?  It used to be Ctrl+F,
either it should change or we should just remove it.  (History already has no
accelerator for find.)
I actually think Ctrl-F is still appropriate for both History and Bookmarks,
since this is the most immediate search available in those windows.
r=matt
a=ben@netscape.com. Sorry for the delay, was passed out in a pool of blood. 

Change checked in for bookmarks, history as German described in (1).
Marking fixed.  Note, I left in Ctrl-F in bookmarks menu as German
suggested.  History did not have Ctrl-F, we should file a bug if
we need to do this (I wasn't sure if history also needs Ctrl-F).
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
There is no reason for not doing it in history as well as both BM and Hist grow 
very similar and as the History wd becomes more robust, more people will want 
to use it and find items. So being to leverage that knowledge from the BM 
window is prob a good thing
about to file new bug
filed sep bug 67908 on Hist 
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: