Vertical Table Adjustment w/ Mouse

StarOffice 8 / OpenOffice.org 2.0

Task ID(s)

#111597#

Category	Specification Affects

<Other>

Abstract

Until Writer 7 the row height of tables in Writer could only be adjusted/changed by “Row Height” dialogue. Since East-Asians are used to vertical page layouts where table rows basically become columns it is desired that row height can also (like column width) easily changed/adjusted by mouse cursor.

Main goal is to transport the mouse functionality of column manipulation over to rows.

i-Team

Specification Owner	Michael Brauer	michael.brauer@sun.com
Marketing (MA)	Susan Jefferies	Susan.Jefferies@Sun.COM
User Experience (UX)	Falko Tesch	falko@sun.com
Development(DEV)	Michael Brauer	michael.brauer@sun.com
Quality Assurance (QA)	Michael Rüß	michael.ruess@sun.com
Documentation (DOC)	Frank Peters	fpe@sun.com
String Reviewer	Elizabeth Matthis	Elizabeth.Matthis@sun.com

Specification Reviews

Version	Reviewer	Comment
Reviewed by UX 15/08/03	Christian Jansen	see Notes
UI String Review		
Reviewed by QA <Date>		
Reviewed by DOC 15/08/03	Uwe Fischer	Feedback was delivered by mail.

Document History

Version	Author	Comment
Draft 13/08/03	Falko Tesch	first draft
Second Draft 15/08/03	Falko Tesch	Edited based on UX and DOC input
Third Draft 21/08/03	Falko Tesch	based on LHO input
Final 22/08/03	Falko Tesch	Sent out to iTeam
Addendum 04/09/03	Falko Tesch	added formal data from MIB
Addendum II 03/02/04	Falko Tesch	Changed modifier behaviour

Contents

Glossary	1

References	1

1	Motivation	1

2	Goals	1

2.1	How does this feature meet the requirements	1

2.2	How does this feature improve the program architecture	1

3	Dependencies	1

3.1	Technical Dependencies / Requirements	1

4	Detailed Specification	1

4.0.1	General Behaviour	2

4.0.2	Behaviour for Changing Row Height within the Tables	2

4.0.3	Behaviour for Changing Row Height through Ruler	3

4.0.4	Behaviour for Changing Split Cells Row Heights	3

4.1	Error Conditions	4

5	Future Tasks	4

6	Legal Issues	4

7	Notes	4

Glossary

Term	Description
Fit to size	Automatically adjusts the row height to match the contents of the cells.
Row Height	Changes the height of the selected row(s). To access this function choose “Format - Row - Height”
Row line	The border of a table row
Column line	The border of a table column

References

n/a

Motivation

Give users of vertical layout mode the same usability for tables in Writer as horizontal writers have.

Goals

Table manipulation abilities with mouse must be the same for rows and columns.

How does this feature meet the requirements

This feature will enhance the intuitive use of tables in Writer for everyone.

How does this feature improve the program architecture

None

Dependencies

Technical Dependencies / Requirements

None

Detailed Specification

Note: All definitions like left, right, up and down within this specification relate to horizontal page layout.

Currently there are two different ways the user can affect the table columns with the mouse:

Using the mouse cursor directly to drag the column borders to left or right and therefore adjusting the column width.

Using the table handles within the ruler to adjust the column width.

There are also special cases:

If cells have been split dragging the cells left and/or right borders will only affect the borders of the split cell(s).

The above movement can also be accomplished by using “CTRL + ALT + Cursor LEFT/RIGHT”. Actually this key composition also moves left and right cell borders (from non-split cells) independent from the columns width!

This document will specify the transition of the first three issues from above to manipulate row height in table with the mouse.

General Behaviour

Moving the mouse cursor over table row lines of any kind changes the cursor layout from standard to adjustment handle layout .

We will use this cursor only if the system does bnot provide a native one (default behaviour for all cursors)

The snapping area where the cursor changes its layout is 2 pixel in size from the row line's origin to top and bottom (see Figure 1).

Figure 1 Snapping area

The above also goes for intersections with column lies. In other words: To select a column line the user has to move at least 3 pixels away (in vertical direction) from the row line to get the vertical adjustment handle.

Moving a row line is displayed by creating a dotted snap/grid line that crosses the whole document canvas from left to right. The original row line stays at its origin until mouse button is released. The design of this line is analogue to the existing line when moving columns (see Figure 2).

Figure 2 Horizontal Table Handle

Behaviour for Changing Row Height within the Tables

Once the cursor changes to adjustment handle layout/mode the user can selected and drag the complete row line with the mouse (while holding the left button pressed). Releasing the left button will “drop” the row line at its current position.

Changing the position of the row line will also affect the value within the “Row Height” dialogue (value in spin box).

Manual height adjustment with mouse (or keyboard, see 4.0.4) must not alter the “Fit to size” status of the affected row!

“Fit to Size” is enabled (default):
Dragging the row line with the mouse can never create a smaller row height value than determined by the internal calculations of minimal row height. Dragging the row over the given limit must have no effect and no cell content must be severed. There is no limit in creating bigger values than the minimal required one though. The only way to change this is to disable “Fit to Size” within the “Row Height” dialogue.

“Fit to Size” is disabled:
Dragging the row line can create any row height value bigger then 0. Thus cell content can be cut off. Current implementation limits the max. height by the page size.

Note: There are changes underway to break this limitation. Therefore I adjust this spec already given there is no page limit anymore!

Behaviour for Changing Row Height through Ruler

Like in 4.0.2 changing row height with mouse is also possible via ruler (analogue to column width). Therefore the table marks in rulers have to be introduced also for row height (this applies to the vertical ruler in horizontal page layout and to the horizontal ruler in vertical page layout).

The same graphical symbol like in the horizontal ruler is to be used for this.

ToolTip: When resting the cursor above such graphical symbol (for more than 1 sec.) within both rulers will bring up a context sensitive tool tip for about 4 seconds.

String list

Item	English	German	Comments
ToolTip - horizontal ruler	Adjust table row	Tabellenzeile ändern	
ToolTip - vertical ruler	Adjust table column	Tabellenspalte ändern	

Dragging this handle will affect the row height the same way as dragging the row line itself. So the same rules as in 4.0.2 apply.

The ruler must reflect/display all available row lines once the cursor is located within a table. This behaviour is analogue to the existing behaviour for column handles.

[For further details please refer to that specification.]

Note: Since the vertical ruler can never expand over more than one page but table cell will be able to (in the future) the user will only be able to change the cell's height within the rulers scope (thus never bigger than the printable area). Nevertheless it is still possible to drag the cells height above this by using the cells row border line itself.

Behaviour for Changing Split Cells Row Heights

In case the user changes the row height of vertically split rows dragging the row line will only affect the split cell (not the surrounding cell row lines) as long as the to-be-moved line is not aligned with any other left or right from it. This again is analogue to the split cell behaviour for dragging column widths.

In case a split line is aligned to a right and/or left neighbour these lines have to be moved, too. This allows the user to drag lines the way she is used to it in case of aligned lines.

For all detailed adjustment behaviour 4.0.2 applies.

Key Board Shortcuts

ALT + Cursor DOWN/UP: Change height of entire row by moving lower border, leave other rows as they are

ALT + CTRL + Cursor UP/DOWN: Change row height only in vertically split cells by moving lower border (for details pls. refer to 4.0.4 Behaviour for Changing Split Cells Row Heights ). This shortcut will never move lines outside the split cell even not if they are aligned to the to-be-moved part.

ALT + CTRL + SHIFT + Cursor UP/DOWN: Change row height only in vertically split cells by moving upper border (for details pls. refer to 4.0.4 Behaviour for Changing Split Cells Row Heights ). This shortcut will never move lines outside the split cell even not if they are aligned to the to-be-moved part.

Key Board + Mouse

CTRL + “horizontal mouse movement” moves all row heights in movement direction and proportionally altering the height of all rows above the mouse handle.

Example: If the user “grabs“ the fourth row border of a table and moves the mouse with a pressed CTRL button downwards (to side's bottom) than all three rows above the “grabbing” point will be altered proportionally in height.

SHIFT + CTRL + “horizontal mouse movement” moves only the row height of the selected

Error Conditions

None.

Future Tasks

The feature within this spec have to make their way into the new table implementation planned in future releases.

Legal Issues

None.

Notes

CJ – 1: Do we need per default a vertical ruler visible?

FT: No, we do not.

CJ – 2: Please add a “snap to grid” to both rulers -> compare with MS

FT: Good idea, but this exceeds the scope of this specification.

CJ – 3: Please improve the look of the column indicators ruler!

FT: Good idea, but this exceeds the scope of this specification.

CJ – 4: 4.0.1 the cursor should look a little bit different please compare with MS

FT: Good idea, but this exceeds the scope of this specification.

CJ – 5: For moving I have to position my mouse pointer exactly on the cell guides. -> We have to be more tolerant.

FT: Done, changed to 3 pixel.

CJ – 6: 4.04 Are the shortcut compatible to MS? I think they aren't.

FT: I aligned the keyboard short-cuts to existing ones. These have been defined by Frank Loehmann in the light of accessibility. Therefore I will not adjust them towards MS Word. BTW, I couldn't find any shortcuts that can actually manipulate tables in Word!!

<Required – This paragraphs gives the audience idea of what to aspect from this document. It should be described shortly what problem will be solved.>

The source of software product implementation and change is the I-Team (Implementation Team). I-Teams are typically comprised of people who have skills in the areas of Product Marketing, Development Engineering, Technical Publications, and Test Engineering. I-Teams define the features or set of changes (based on input from SCs, customers, Engineering, or Marketing), plan the implementation project, perform the implementation and testing...

Recommended - Please list of technical terms or specialized field of knowledge here.

Required - Give references to related documentation, such as engineering designs, technical specs, and other sources for related units. Also include links to documents that other sections in this spec need to refer to, such as user opinions usability test reports.

<Required - What is the reason for pursuing this project?>

<Required - The goals section must be short but also provide a clear statement of the goals, to achieve with this feature, project or task. A clear statement in this section gives the Development, Quality Assurance and Documentation guidance.>

<Recommended - Describe how this feature will meet expected requirements>

<Recommended - Descripe how this feature will improve the program architecture.>

<Recommended - Are there any requirements or dependencies for this feature? Does the implementation of this feature create any requirements/dependencies to other program parts?>

<Required - First of all the concept section should give the audience an overview of how the new feature will work. When this is done this section has to cover the necessary things to finish this feature. This is the crucial part of the specification. If images are used in the concept, it is very important that these images provide a caption. The caption should be short and has to describe shortly the image. UI Mockups has to provide a caption too, if possible the mockups shouldn't be scaled and our standard user interface font, Andale Sans UI has to be used for strings on dialogs.>

<Required - Dialogs providing strings which have to be translated, have to be accompanied by a table containing the strings used in the image (English or German or both) Strings have to include mnemonics and the item for which the string is used. Mnemonics have to be visualized by a ~ - symbol in front of the letter which has to be displayed mnemonic.>

<Required - Key Board shortcuts used in dialogs have to be listed in a table with a small description.>

<Required - List all error conditions, and the action the system takes about them. If an alert box comes up, which kind is it? Include exact text of messages, or say what points need to be covered. Error Messages need a string list>

<Recommended - If there are features which couldn't be implemented but have to be implemented in the future. State these in here with a description why the feature couldn't be implemented right now.>

<Recommended - If there are any legal issues to deal with the should be described here. Legal issues could be for example we have to redistribute third party technology. This section can also contain links the Legal Review Tool.If the Specification will be published on OpenOffice.org this section has to be removed.>

<Recommended - Questions will arise during the writing of the specification. State these in here.>

Vertical Table Adjustment w/ Mouse

Page 2

/home/ft93697/Documents/Specs_CVS_root/g11n/table_adjustment/Vertical_Table_Adjustment_w_Mouse.sxw

Falko Tesch

2003-08-13T11:13:30