GSoC 2011 Tables Design

GSoC 2011 Tables Design

This page outlines the design and implementation details of tables in Scribus as part of Google Summer of Code 2011.

Page TODO:

• Summarize what was concluded in this thread on the mailing list.
• Make simple mockups for the most common UI operations on tables.
• Go through the old material below and make sure all questions there are incorporated into the new material. For those that are not, bring them into a new section "Unanswered Questions".

General Design

As was outlined briefly in my project proposal, the tables in Scribus will be implemented as a new page item. Handling of cell content will be delegated to text frames. More radical approaches to tables in Scribus have been suggested before, but the tables I'll be implementing as part of Summer of Code will be more traditional in the sense that tables will consist of a rectangular array of cells.

Use Cases

TODO.

User Interface Design / Interaction

These are some notes about the interaction design of the tables UI. A lot of the ideas come from this thread on the mailing list.

Modes of Operation

Mockup of the normal and editing modes.

Following the tradition of the modal way of working with items in Scribus, there will be two operational modes when working with tables; normal mode and editing mode. The possible operations for each mode are listed below. The operations are explained in more detail further down.

Normal Mode

This is the normal mode of operation when working with items in Scribus, and the one the user will be in directly after creating a table. In this mode, the user is able to

• Select tables.
• Resize tables.
• Move tables.
• Select rows and columns.
• Resize rows and columns.
• Select cells and regions of cells.
• Add and remove rows and columns.
• Format tables, rows, columns and cells.

Editing Mode

By double-clicking in a table cell with the mouse, the user is able to enter editing mode. In this mode, the user is able to

• Edit cell content.
• Navigate between cells using the keyboard.

The "quick" table creation widget in Calligra Words

Creating Tables

The current way of creating tables is quite sufficient; the user is able to create tables by pressing a button in the toolbar or by picking a menu item, entering the desired number of rows and columns and then mouse dragging the desired dimensions of the table on the page. Possibly, I could steal a widget that Casper Boemann of Calligra Words wrote which looks like the automatically expanding grid for selecting number of rows and columns in e.g. LibreOffice. He said it was OK, as long as I fix a couple of bugs he had found in it :) But in general, the current way of inserting tables works fine.

It should also be possible to create tables by importing them from a file, and the general consensus seems to be that CSV has higher priority than ODF, at least for the GSoC project. Hopefully the table implementation will be scriptable enough that this import could be done as a script.

Moving and Resizing Tables

Moving a table is a simple matter of dragging it around with the mouse, just like with other items in Scribus.

Mockup of moving a table.

Resizing a table is also done just like with regular Scribus items. We will probably want two ways of resizing the table, one where only the width of the last column is affected, and one where all column widths follow proportionally.

Mockup of resizing a table where only the last columns is affected.

Mockup of resizing a table where all column widths follow proportionally.

Warning:

What do we do with table height during resizing of tables? Is not scaling the entire table proportionally, both width and height, a valid use case? And how do we cover this? And should table width follow the width of the table frames like in these mockups, or should table width be independent of the width of the frame just like height?

Selecting Cells

Selecting cells can be done directly from normal mode. Using the Alt modifier, the user can select individual cells by clicking on them, and by using the Alt+Shift modifier a rectangular region of cells can be selected by dragging across them.

Mockup of selecting table cells.

Selecting Rows and Columns

Selecting rows and columns will work like in common word processors. When hovering the left edge of the first cell in row the cursor will be turned into a right-pointing arrow and by clicking the entire row is selected. Likewise for columns but when hovering to top edge of the first cell and with a down-pointing arrow.

Mockup of selecting a table row.

Mockup of selecting a table column.

Resizing Rows and Columns

Resizing rows and columns will also work like in common word processors. While in normal mode the user will be able to drag with the mouse on row/column boundaries to resize the rows and columns, respectively.

Mockup of resizing a table row.

Mockup of resizing a table column.

Editing Table Content

By double-clicking a cell the user is put in table editing mode. As text is typed, it will be constrained to the cell width, but the height of the row will grow automatically. If the rows of the table will not fit the frame, the overflow marked will be displayed.

Mockup of editing the contents of a table cell.

Formatting Tables and Cells

Formatting of tables and cells, such as background color, border color, border style, default paragraph style et.c. can be done either directly by using the Property Palette, or by using table styles or cell styles. These will be available in the Styles Manager just like normal paragraph or character styles, but will contain properties specific to tables and cells.

There is currently some work planned to rework the Properties Palette to be less cluttered and more context sensitive, and if this work will take place during the course of my GSoC project, this is something that might need to be taken into account. But no matter which version of the Properties Palette will be in use, I imagine that the user should be able to

1. (in normal mode with a table selected)
   • change formatting properties of the table.
2. (in normal mode with a row selected)
   • change formatting properties of the row and
   • change formatting properties of the table
3. (in normal mode with a column selected)
   • change formatting properties of the column and
   • to change formatting properties of the table
4. (in normal mode with a cell or rectangular region of cells selected)
   • change formatting properties of the cell(s) and
   • change formatting properties of the row(s) the cell(s) is/are in and
   • change formatting properties of the column(s) the cell(s) is/are in and
   • change formatting properties of the table the cell(s) is/are in
5. (in editing mode with the cursor positioned in a cell)
   • change formatting properties of the cell the cursor is in and
   • change formatting properties of the row the cursor is in and
   • change formatting properties of the column the cursor is in and
   • change formatting properties of the table the cursor is in.

as well as apply a style for any of the above.

The theme here is that with more specific parts of the table selected, such as a cell, the user should still be able to format higher level parts of the table which the cell is in, such as the row or the entire table.

Old Material

General Design

As was outlined briefly in my project proposal, the tables in Scribus will be implemented as a new page item. Handling of cell content will be delegated to text frames.

Interaction Questions

In the questions below, I refer quite a lot to Adobe Indesign CS5.5. This is not because I see it as a template of good design or anything, it's just that I happen to have come across a copy of it which I have running under VirtualBox, and it helps to have something existing to discuss around.

Table Creation/Editing

The "Table" menu of Adobe Indesign CS5.5

Is there a general consensus on how we want interaction with the tables to work? Looking at how tables work in Indesign CS5.5, their design is quite straight forward and works essentially as those found in word processors: The user is presented with a "Table" menu from which tables can be inserted and manipulated and formatted through dialogs that pop up. Something that might be different from how tables will work in Scribus is that in Indesign, tables can only exist as inline objects inside a text frame, not as objects on their own.

I'm imagining that in Scribus, the user is able to freely position the tables on the page, while in the future, we can hopefully let the user insert the table item I'll be creating inline in running text by making it an inline object of some kind? Another thing which I think will naturally be different in Scribus is that in Scribus, editing of item properties is mostly done through the Properties palette, and not so much through dialogs that pop up (thankfully! because table editing in Indesign seems to be very dialog-intense). I guess we will have a new tab on the PP called "Table" that will be disabled unless a table is selected, similar to how it works for images?

Table/Row/Column Resizing

In Indesign, tables, rows and columns are resized by click-dragging, and I'm guessing this is how we want it to work in Scribus too? Something that comes to mind is that for most items Scribus uses a modal way of interacting with the item: In the "normal" mode, the user is able to select, move and resize an item, while in the "editing" mode (entered by double-clicking) he/she is able to perform editing actions on the item, such as inserting text in text frames, or moving vertices of a polygon. Is this modal way of working something we want for tables as well, in order for them to fit in with the Scribus way of working? If so, I'm guessing actions such as column/row resizing should be available in the "editing" mode, while in the "normal" mode the user is only able to move/resize the table?

Resizing a table in Adobe Indesign CS5.5

Resizing a table row in Adobe Indesign CS5.5

Resizing a table column in Adobe Indesign CS5.5

Styles

A while ago I took an afternoon and investigated what it takes to create a new kind of style in Scribus, thinking this is something we might want for tables. It was mostly straight forward and I ended up with a primitive skeleton of a new style which is now in my Git repo. Since then however, I've started thinking; Are styles for tables (and even for rows/columns/cells) something we really want, or are they an unnecessary complication for small benefits? I don't know about other programs, but Indesign does not have named styles for tables. Tables are simple formatted by direct editing of properties for individual tables. How common are use cases where the user would really be hampered without support for named table (and possibly cell/row/column) styles? Would it be sufficient for Scribus if editing table properties is a per-table operation? I'd really like to get the opinion of other team members on this.

Cell Selection

I'm guessing we want cell selection to work similar to word processors and Indesign, where a user is able to enter a "cell selection" mode by starting to select some text in a cell with the mouse and then dragging outside the cell boundaries?

Technical Questions

Below are some of the technical questions I have to find answers to. Since the content of table cells will be represented using Scribus' regular text frames, several of the questions below are related to this.

Notification of Text Overflow in Text Frames

Using text frames for cell content means the table will have to be notified when overflow occurs in a text frame, to be able to correctly re-layout the table starting from the row in which the overflow occurred. If we eventually want to have width-growing columns, we'll also need a way to be notified when a line break is about to occur in a text frame. So the question is; do text frames currently emit any signals to indicate that content is overflowing? It seems it's not, but one place where such a signal could possibly be emitted is in PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might not be a correct solution though, perhaps the table should instead listen to insertions being made in the text frame, and query the frame for its overflow state using PageItem::frameOverflows()?

In addition to being notified of when overflow happens, the table will also need to be able to query the text frame for the height of its content, to be able to resize it correctly during table layout. Is this possible using the current API? If not, what would it take to add it?

Editing of Cell Content

As the text frames have their own modal way of being edited, and on top of that we'll probably have a modal way of editing tables (see above under Interaction Questions), how will we combine the two when it comes to editing cell content? I really don't think we want a multi-layered modal interaction, where the user first has to double-click the table, and then again double-click a cell in order to edit its content. Indesign is on the other extreme of this, there a user can directly edit the content of a table, without any modes of operation. I think what we want in Scribus is for the user to immediately be able to interact with the content of cells after the first double-click on the table. Or what do you think?

On top of this is the question of keyboard navigation between cells, which I'm sure we want. The table will probably have to somehow filter the keyboard events before they hit the underlying text frame of the cell in order to get this to work.

Disabling Decorations / Resize Handles of Text Frames

I will have to figure out how drawing of decorations, and possibly also the resize handles of text frames can be disabled. The table will only be interested in the text displaying / editing capabilities of the text frames, and will not want them to draw anything else such as borders, decorations or resize handles. Perhaps this is an easy thing, but still something I'll have to investigate.

Use Cases

TODO.