Difference between revisions of "Specification Common find toolbar"

Revision as of 10:28, 16 November 2009

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.

References

Contacts

Acronyms and Abbreviations

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

File:FindBar.png

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 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.

<first Toolbar>

<ITEM-NUMBER TextField>

<"ITEM-NUMBER" Button>

<"ITEM-NUMBER" Button>

Help | User Interface Element Templates | Example Spec

Accessibility

Accessibility is the responsibility of the I-Team, beginning with UX, DEV and QA, to ensure that the following requirements are fulfilled:

1. Is the feature fully keyboard accessible?
   (Ex: "I can go everywhere and use every function using the keyboard only"
   <START TYPING HERE>
2. Have I specified visual alternatives for the case that the specified feature includes audio as output?
   <START TYPING HERE>
3. Are text alternatives for all icons and graphics available?
   <Start typing here>
4. Don't provide important information in colors alone
   (Ex: marking important information hard coded in red)
   <START TYPING HERE>
5. Does the specified feature respect system settings for font, size, and color for all windows and user interface elements?
   <START TYPING HERE>
6. 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
   <START TYPING HERE>
7. Ensure that assistive technology (AT) (like ZoomText or Orca) is able to read everything.
   <START TYPING HERE>

QUESTIONS?

If you need help while designing, implementing or testing the accessibility of the UI, ask/visit:

1. The accessibility check list at the OpenOffice.org Wiki
2. accessibility@ui.openoffice.org (The accessibility mailing lists, preferred)
3. For specific implementation details, architecture: mt@openoffice.org (Malte Timmermann)
4. For specific UX and testing questions: es@openoffice.org (Éric Savary)

Migration

<START TYPING HERE --- If this part is irrelevant state a reason for its absence.>

Configuration

<START TYPING HERE --- If this part is irrelevant state a reason for its absence.>

Help | Configuration Table Template

File Format

<START TYPING HERE --- If this part is irrelevant state a reason for its absence.> Help

Help | File Format Table Template

Open Issues

<State a bulleted list of issues Issue here>