Difference between revisions of "Specification Common find toolbar"
Line 342: | Line 342: | ||
== Configuration == | == Configuration == | ||
− | The find toolbar is positioned right next to the standard toolbar in every application, but only in Writer and Calc it is enabled by default (makes rather less sense in Draw and Impress). | + | The find toolbar is positioned right next to the standard toolbar in every application, but only in Writer and Calc it is enabled by default (makes rather less sense in Draw and Impress because of less text search needs). |
== File Format == | == File Format == |
Revision as of 08:45, 4 May 2010
Specification Status | |
Author | Christoph Lukasiak (Clu) |
Last Change | 31. March 2010 |
Status (Help) | Standard |
Abstract
The 'Common Find toolbar' should be an addition to the 'Find & Replace' dialog, which provides a fast and easy text search without covering the search text.
Contents
References
Reference Document | Check | Location (URL) |
Prerequisites | in progress: [passed/failed] | n/a |
Product Requirement, RFE, Issue ID (required) | available | i107176 |
Accessibility Check (required) | See accessibility section for check list | |
Test case specification (required) | [available/not available] | <PLEASE ENTER LOCATION HERE> |
IDL Specification | [available/not available] | <PLEASE ENTER LOCATION HERE> |
Software Specification Rules | in progress | n/a |
Other, e.g. references to related specs, Product Concept Document | specification: search toolbar | |
Release Roadmap OOo 3.3 | http://wiki.services.openoffice.org/wiki/OOoRelease33 |
Contacts
Role | Name | E-Mail Address |
Developer | Carsten Driesner | cd@openoffice.org |
shizhoubo(robertzhou) | robertzhou@openoffice.org | |
Quality Assurance | Stefan Baltzer | sba@openoffice.org |
Documentation | Uwe Fischer | Uwe.Fischer@sun.com |
Icon Design | Stella Schulze | Stella.Schulze@sun.com |
User Experience | Christoph Lukasiak | Christoph.Lukasiak@Sun.com |
Jaron Kuppers | jaronbaron@gmail.com |
Acronyms and Abbreviations
Acronym / Abbreviation | Definition |
<WYSIWYG> | <What You See Is What You Get> |
Motivation
From the 'usage tracking' data of the 'find & replace' dialog we have learned that 76% of oo user just want to search inside the text, so we have to propose a fast & easy way to do so. Also it was often mentioned that the search & replace dialog covers the search area in an annoying way, so we must found an other solution for it. The other search settings like 'match case' etc. are used less than 0.1%, so we decided to leave them out in this toolbar, but like the replacing function they will still stay available in the find & replace dialog.
Detailed Specification
The common find toolbar is a standard toolbar containing a text search field, a next and forward button. It is located right next to the 'application standard' toolbar, is active by default and behave like every other toolbar (d&d, docking etc.).
By clicking into the search field, the info text disappear and the search text can be inputted. By entering the search field, the next and the previous button get active. After entering the search text, the search can be started by hitting the return key on keyboard or pushing the 'next' button. If anything is found, the first result is selected and can be edited or the next button can be clicked (is selected) for searching for the next result. If nothing is found (buttons get inactive) or it is searched to the end of the document, you get an info dialog similar to the behavior of the 'find & replace' dialog, like in all other cases, even if it works independent.
Find Toolbar
Property | State | Comment |
Toolbar Name: | Common Find Toolbar | |
<Other Language (Optional)> | ||
Has Closer: | no | |
Style: | Icon/Icon | |
Initial State: | docked | |
Initial Docking Position: | next to toolbar 'Standard' | |
Initial Floating Position: | no | |
List in "View/Toolbars": | yes | |
Is Context Sensitive: | no |
Find Textfield
Property | State | Comment |
Enabled: | always enabled | |
Disabled: | never disabled | |
Read Only: | no | |
Initial String: | Find | grey |
String Preselected: | no | |
Caret Position: | <0> | |
Characters Not Allowed | all characters allowed | |
Tip Help: | Find Textfield | |
TextField Label: | no | |
Shortcut: | Ctrl + G | focus in textfield |
Other: | <Specify Other Properties Here> |
Next Button
Previous Button
Find & Replace Button
Property | State | Comment |
Enabled: | by user in toolbar settings (check visible) | |
Disabled: | by default (not visible) | |
On Click: | opens 'Find & Replace' dialog | |
Tip Help: | Find & Replace | |
Button Label: | no | only icon button |
Icon: | File:Fernglas icon.png | cropped screenshot icon |
Other: | <Specify Other Properties Here> |
Accessibility
Accessibility is the responsibility of the I-Team, beginning with UX, DEV and QA, to ensure that the following requirements are fulfilled:
- Is the feature fully keyboard accessible?-> yes
- Have I specified visual alternatives for the case that the specified feature includes audio as output? -> feature does not contain audio output
- Are text alternatives for all icons and graphics available? -> yes
- Don't provide important information in colors alone(Ex: marking important information hard coded in red) -> considered
- Does the specified feature respect system settings for font, size, and color for all windows and user interface elements? -> yes
- Have I ensured that flash rates do not exceed 2 hertz for blinking text, objects, or other elements? In any case, try to avoid flashing UI elements -> considered
- Ensure that assistive technology (AT) (like ZoomText or Orca) is able to read everything. => dev & qa topic
QUESTIONS?
If you need help while designing, implementing or testing the accessibility of the UI, ask/visit:
- The accessibility check list at the OpenOffice.org Wiki
- accessibility@ui.openoffice.org (The accessibility mailing lists, preferred)
- For specific implementation details, architecture: mt@openoffice.org (Malte Timmermann)
- For specific UX and testing questions: es@openoffice.org (Éric Savary)
Migration
Common find toolbar should be migrateable (adaptable) for all oo applications (Writer, Calc, Draw/Impress) over uno api, while the 'Find & Replace' button get set inactive in the standard toolbar if find toolbar is active. In Impress the 'Präsentation' toolbar must travel into the second toolbar section (pic) to make space for the find toolbar and keep consistency.
Configuration
The find toolbar is positioned right next to the standard toolbar in every application, but only in Writer and Calc it is enabled by default (makes rather less sense in Draw and Impress because of less text search needs).
File Format
<START TYPING HERE --- If this part is irrelevant state a reason for its absence.> Help
Help | File Format Table Template
Future Tasks
- Autocomplete involves the program predicting a word or phrase that the user wants to type in without the user actually typing it in completely. This feature is effective when it is easy to predict the word being typed based on those already typed, such as when there are a limited number of possible or commonly used words, or when editing text written in a highly-structured, easy-to-predict language.
- Searching by inserting first letter (start searching by first char) .. from the first letter on the engine starts to search and to highlight the corresponding words; with every further letter the 'highlighted words collection' get less and less and came closer and closer to the searched word; it increase the speed of finding phrases and the overview.
- Highlighting (jumping/selecting trough marked items) .. at the moment we select the found phrases, which has the handicap that you cannot travel trough the selected words without loosing the selection and therewith the overview; so it can make sense to mark/highlight the found phrases instead, then travel between the highlighted phrases and edit single contents separately without loosing the search resultset.
- Remember former search strings (string listbox) .. often you search for the same words several times, so it can make sense to remember them (especially it they are long and complicated) and to make them available over a listbox in example to save the input of same phrases again and again.
- Enlargable toolbar, manual or if text get bigger than 'find textbox'.. in different countries and the corresponding languages the lenght of wording can differ a lot; not to make the toolbars (textfields) too long and ugly on one hand and not unnecessary limit them to an unconfortable lenght for some languages it would be nice if they could have a minimum length and expand if the words get longer.
- Inline messaging / info text inside textbox (messages like: nothing found etc.) .. info text in message boxes or dialogs look old fashioned, disturb the sight on the document, must be closed manually and bugs a lot of user; inline messages get more and more popular and give the same info in a more appropriate way.
Ideas
- drop down (snippets) functions (with additional function set like s&r dialog) .. to provide all functions which are available in the 'search & replace' dialog but not overload the toolbar it could make sense to provide drop down functionality for them.
- provide also smart & fast filter function for calc and base .. in application like base and calc filtering the data is often more important than searching for phrases, therefore a findbar in this applications should have the ability to filter
- allow choosing between search & filter function .. because of the rather similar intention of finding data it can make sense to combine search and filter functionality in the findbar and/or switch between this functions.
Open Issues
None.