Part of the purge of <https://support.mozilla.com/kb/Using+Firefox>. This article is a great chance to showcase FAYT.
Here is the first stab at this. * Do we need screenshots for FAYT or Quick Find (links only)? * Are the current screenshots too goofy? I didn't think of it when I was making them, but if an old blog entry from SUMO blog is too weird I can make others. * Should we bother mentioning that pressing / will also bring up Quick Find? I can't really think of why we would, except for old Mozilla Suite users?
(In reply to comment #1) > Here is the first stab at this. > * Do we need screenshots for FAYT or Quick Find (links only)? A bit of terminology nitpicking: Quick Find is the name of the feature you're referring to when you say FAYT and you can use it to find all text or links only. Technically the full on Find bar is also FAYT - which is the process of finding the first result while you type rather than waiting for you to hit a search button. FAYT has in the past also referred to Quick Find, but it's not referred to as such anywhere in the UI. to answer the question though, yes, the Quick Find bar is different from the find bar so we should show the difference. > * Are the current screenshots too goofy? I didn't think of it when I was making I don't think they're too goofy but I think you can get away with only showing one paragraph and making them smaller. The screenshot for phrase not found is a bit too blurry IMO, if you can get away with making it wider that'd be great. > them, but if an old blog entry from SUMO blog is too weird I can make others. > * Should we bother mentioning that pressing / will also bring up Quick Find? I > can't really think of why we would, except for old Mozilla Suite users? You should mention it as that will bring up the Quick Find bar if you don't have the pref enabled in options. I would mention the shortcut first and then mention that you can flip the pref so that it starts searching no matter what you type (outside a text field) Other than that I could use more headings under "using the Find bar" to break it up.
Ah, thanks for the clarification on FAYT. I got rid of the second paragraph in the highlighting screenshots and then made a very narrow mockup to fix the blurriness of the "Phrase not found" screenshot. I forgot to put the accelerator indicator on "Highlight all" and "Match case" I now notice, but I don't think that really matters... I also added the / for Quick Find (I guess we should mention that it can happen). And some spacing on the screenshots to break things up a bit. I think we're ready for review?
- remove intro (for these basic things, the intro is just clutter) - give step by step instuctions - only provide one access method (menu) - use a bullet point for each button, and include the [x] - in screenshots, show people where to find the Find bar - "Firefox's Quick Find capabilities help you find search phrases more quickly. To use these features, follow the instructions below. " tells me nothing. - Using [/] to trigger the Quick Find is pretty useless info, considering we already mention a different trigger that provides move options in the Find bar. The big difference in the feature is that you don't need to trigger it before you start typing. So: -- it might be better to replace the heading "Quick Find" with "Search for text when I start typing" or something. -- and move the section "Search links only" to "Using the Find bar"
(In reply to comment #4) >- remove intro (for these basic things, the intro is just clutter) This isn't going to be a short article, and I don't think there's any article that is so self explanatory that a brief summary isn't useful. In this case I think we have room to explain a bit more about what we mean by searching in a page and set up the idea that Firefox has two different functions for this. > - Using [/] to trigger the Quick Find is pretty useless info, considering we > already mention a different trigger that provides move options in the Find bar. > The big difference in the feature is that you don't need to trigger it before > you start typing. Since this feature is off by default, and some people want to leave it that way we should absolutely document this functionality. It's not the same as the Find bar and by not documenting it you're basically saying users should just use the find bar. Having the two separate functions was by design, otherwise "Search for text while I start typing" would just bring up the normal find bar. > -- and move the section "Search links only" to "Using the Find bar" I might be misunderstanding what you're saying, but as far as I can tell there's no switch in the find bar to search just links.
Users aren't going to read long articles just to find out how to search within a web page. Words are expensive. All we want to do is showcase a feature, not go into so much detail is confuses the user. If there's a reason for having a separate trigger, what is the use case for each?
I'll see if I can find some old discussion from when quick find was implemented, but aiui the basic difference is this Find - more useful in the sense of research, someone is looking for all references of a word on a page, or they're definitely going to look for the next reference in a page after they're done reading/gleaning information from the first one. Quick Find - user is trying to find a specific reference. They're looking for where they left off in a page, or looking for specific information they already read somewhere. Or they're looking for one specific piece of information. This is why there is no highlight all, and why it disappears on its own. Quick Find (links only) - as above, but looking for links. They know they were linked to content they're trying to find again from a certain page, or maybe in the case of a wikipedia article they're trying to find links to another page with more information. The word cost for mentioning the link only search is pretty cheap. You explain quick find and then toss on a "to search only link text use (') instead."
I love quick find (links only) since once you find the link, just press enter again to follow the link. No need for mouse. That said, do we have to document all the tiny detailed features of Firefox?
I consolidated a bunch of stuff and made the whole thing terser. I also took out the / trigger for Quick Find. If you disagree, you can put it back and I won't mind. I intended the first part to be a tutorial, since the only people who are going to get information out of it have never used find in any application before. Otherwise they would hit Ctrl+F like in any program. The other purpose of this article is to inform people who are looking to enable "Search for text when I start typing, and for people for whom the Quick Find bar come sup when they type in stuff.
Ok I've got two suggestions for handling this article. 1. Take out Quick find altogether and make it its own article Pros - totally cleans up the article, user still knows how to find stuff on a page Cons - for the most part Quick find is the better user experience, fewer clicks and it goes away on its own once you find what you're after. We could still mention the quick find article somewhere in this one if we wanted to. 2. Take out the instructions for turning on "search for text..." and only mention the keyboard shortcuts. Link outside the article if we want to mention this pref Pros - leaves all options in the article, but still removes a good chunk of clutter Cons - Still leaves out the best experience of this feature. I think the best experience is probably to properly document Quick Find in its own article, then decide if we want to reference that article in this one or not. We could then mention it briefly, something like "Firefox also offers a lightweight Quick Find option which can be triggered when you start typing and closes on its own once you've found what you're looking for" and link to the quick find article.
Reviewed and moved to KB at: Wed 20 of May, 2009 00:01 EST - just some minor tweaks and syntax corrections Thanks for your work on this Bo. It is really appreciated.