GSoC 2011 Tables Design
GSoC 2011 Tables
This page contains technical/functionality considerations regarding the implementation of tables in Scribus as part of Google Summer of Code 2011. Here I'll try to keep an up to date document describing the design of the implementation, a list of open technical problems and questions regarding the functionality of the tables, including a couple of use cases as well as everything else concerning my work on bringing tables support to Scribus.
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. I've never used even used Indesign myself before.
Table Creation/Editing
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 — Worthwhile?
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 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 possible cell/row/column) styles? I'd really like to get the opinion of other team members on this.