Created attachment 137468 [details] It proposes a unified solution for table management remedying the above shortcomings Copy/cut and paste elements of a table: There is a principled difference between 1) copying/cutting some substructure of a table, i.e. a set of columns or rows, and 2) copying/cutting parts of the content of a table, i.e. the content of a set of cells. In case #1, the user wants to change the table structure. In case #2, he wants to change the content of the cells. Currently, LO Writer ignores this distinction. It follows a mixed and inconsistent strategy: 1) On marking some substructure of a table and copying/cutting it, always the substructure as such (including its content) is stored and reproduced at the goal position. 2) Nevertheless, on cutting the marked material out, the substructure in question is left empty, so the user is given the impression that only the cell content has been cut out. 3) Once the entire substructure has been stored, it ought to be possible to insert it, respecting the column and row structure of the table. In other words, a stored row should be pasted as an additional member of the existent table rows, and likewise for a stored column. As it is now, if one does want to insert the stored substructure at the target position, one first has to insert the corresponding set of empty columns/rows at the target position. Then one either marks the entire empty substructure or puts the cursor into its first cell and then does 'Paste'. This is cumbersome enough. Moreover, if one fails to provide the empty space, moving instead the cursor into the target position and doing 'Paste', the entire stored table substructure is pasted in the cell where the cursor is (useless function, as it destroys the table structure). Shifting a (set of) table columns/rows to a different position in the table is a frequent action which LO Writer does not support at all. As it is currently, this is a multiple-step procedure: a) Mark the entire column/row. (3 mouse clicks) b) CTRL-X extracts the content. (1 key) c) Delete the empty column/row. (2 mouse clicks) d) Put the cursor in the desired position and do 'insert column/row'. (3 mouse clicks) e) CTRL-V pastes the stored content in the new column/row. (1 key) Total: 8 mouse clicks, 4 keys hit. For all such operations of Copy, Cut, Paste and Shift, I suggest a principled solution in the file appended here (which, if implemented, would render LO table management by magnitudes superior to the functionality of competing products ...). It requires far less clicks and keys; for instance, shifting a row is done by one click and one mouse dragging. It also contains an example table for your convenience, to try out the reported (dys-)functionality of Writer.
Brilliant work, Christian. But your text might be a bit too long for most readers. So could you please add mockups? If you need support we can do that together (ping me on IRC or Telegram or here). Ideally, your solution would also solve some of the other issue with table styles (see bug 103100). At least some references may support the overall comprehension of the problem.
Created attachment 137516 [details] Mock-up of a table frame Here is a modest draft of the mock-up. Please improve and/or animate it.
Created attachment 137536 [details] table management iwork pages iWork Pages has a similar concept to this, where it shows the row and column headers, but does so when selecting the table. WPS Writer on the other hand shows its table management functions (move, resize, insert row, insert column) when hovering over a table. iWork Pages also has an interesting click behaviour, where if you click on a table it selects the table, similar to how when we click on an image it selects the image. Then when selected, clicking on a cell highlights the cell and you can then click and hold to drag or click and drag to alter the highlight. A third click brings you into the cell for editing its contents.
Created attachment 137588 [details] Mockup for simple table management Word cuts out the col/row and inserts it above or left of the new selection. User feedback is given via cursor which turns into an arrow down/left at the respective position at the table (plus a 'select all' floating button at top/left). We do the same for user feedback, and I think that's sufficient. Adding a lot of decorations around the table on hoover might be annoying for most users who don't want to manipulate rows/cols and is not much helpful for the rest. I fully agree on the other hand with cutting the col/row and a 'natural pasting'. So when the clipboard contains structured data it should be added as this. Word extends the table if the cursor is not at the first col/row (e.g. at B2), which makes sense. Missing in Word is a way to simply copy the data and keep the structure. We could make this possible by keeping the current behavior when only cells are selected. But in case the full col/row is selected it should also use the table structure. Tried to illustrate this in the attachment. The proposal doesn't consider a selection within the table (e.g. A2:B3). In this case Word and Writer work the same way and keep the source structure intact and paste the content into the target cells (data are overridden without warning). Would keep this.
Hi Heiko, not being a developer, I am, of course, in no position to fight for my proposal. Nevertheless, here are a few clarifications: - According to my proposal, a frame is drawn around a table if the user is editing the table. This would be as helpful in Writer as it is in Calc. - Doing anything with the table just only because the cursor is hovering over it does not seem a good idea to me; this might indeed be annoying to the user. - The point is not to give the user feedback on the state that Writer is currently in. The point is to render table management clear and simple. In my proposal, I had counted numbers of mouse clicks and keys pressed. None of the alternate proposals that have been mentioned fare better on this count. - My proposal is not restricted to operations of Copy/Cut/Paste (incl. Shift). It offers unified management of a whole set of further table operations. Moreover, is uniformity across different applications in LO not a virtue? - Is it an essential aspect of LO policy that it should imitate MS Word? Particularly in questions of table management, this would seem a bad idea to me. (There are, to be sure, features in which Word does fare better.) - When you write "The proposal doesn't consider a selection within the table (e.g. A2:B3)", you are not referring to my proposal, are you? Its entire section 2 is devoted to this problem. Cheers, Christian
(In reply to Christian Lehmann from comment #5) > ...I am, of course, in no position to fight for my proposal. As a user you are in the best position to fight. Don't hesitate to go ahead. > - When you write "The proposal doesn't consider a selection within the table > (e.g. A2:B3)", you are not referring to my proposal, are you? Its entire > section 2 is devoted to this problem. You talk about this use case in the first 2) but not further. Don't think anything is missing but wanted to add this for clarification- current behavior is good for cells only selections. Other than that I like how iWorks does the job (Jay's screencast). Looks like a lot of work, not really suited for GSoC. Any dev opinion about this?
> - When you write "The proposal doesn't consider a selection within the table > (e.g. A2:B3)", you are not referring to my proposal, are you? Its entire > section 2 is devoted to this problem. You talk about this use case in the first 2) but not further. Don't think anything is missing but wanted to add this for clarification- current behavior is good for cells only selections. Please don't forget that my first proposal, of 2.11.17, has an attachment, called writer_tables.odt, which describes this and other aspects in detail.
> Other than that I like how iWorks does the job (Jay's screencast). Indeed, pretty good. But how does one insert new or shifted columns/rows at a certain position? For shifting a column/row, you don't need my little triangles; a wandering arrow or red line, as in Thunderbird's bookmarks management, would be sufficient. But for inserting new columns/rows, I cannot think of a more user-friendly solution. (Consider that inserting in front of a certain position 1) is programmer's thinking and 2) does not work if you want to add them after the last column/row.
I like the frame concept to simplify workflow and enhance usability. I know that most colleagues doesn't know how to change tables/cells/row/columns because they don't use or like context menus, popping toolbars, complex dialog windows and anything similar. The current behavior in Writer isn't as easy as it should be. What came in my mind: - The "frame" elements should be implemented visually unobtrusive (light colors, with transparency of frame elements). - Responsive design (e.g. when hovering with mouse on an area between 2 rows in the "frame", the + symbol--or whatever it is designed--should become darker or less transparent to show the possible action). - Repeated actions without additional mouse way (if doing the same action several times, the action item where the cursor is or the mouse clicks on shouldn't change its position so that the user can do it without moving). - Don't know if it's best to add rows/columns automatically with or without user prompt when inserting cell content to a table position where rows/columns are missing at the buttom/right end. (Christian described a scenario with user prompt in writer_tables.odt, point 2.) - User actions in cell(s) should not change the table style itself (e.g. even/odd style difference) and removing/adding rows or columns should adjust the table style automatically. Only cell content properties (paragraph style properties and direct formatting) should change when do something with cells (del, move, etc.).
*** Bug 117232 has been marked as a duplicate of this bug. ***
*** Bug 121857 has been marked as a duplicate of this bug. ***
I like mock-up of a table frame, but without triangles
You don't need them if you drag rows/columns with the mouse, as this might work like in Firefox > Bookmarks > Management (shift of vertical order of bookmarks). But if you use CTRL-V for insertion, you need a mark for a possible insertion point.
*** Bug 115098 has been marked as a duplicate of this bug. ***
*** Bug 148867 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #15) > *** Bug 148867 has been marked as a duplicate of this bug. *** This is also a duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=148867, but the proposed enhancement here is much better and general one than my later one!
Let's drive this topic forward. Goal is to show a header when hovering over the table with rows and cols that allows to interact with the table. Ideally we implement it similarly to the iWorks example. Removing needsUX.
Comment on attachment 137588 [details] Mockup for simple table management Overly simplified mockup
Just a brief reminder: Writer assumes (specifically, in table formulas) that columns are numbered by capital letters and rows, by numbers. However, there is currently _no_ way of showing these identifiers of columns and rows in the same way as they are standardly shown in Calc. Once you are at it, it would be good to remedy this, too.
*** Bug 156454 has been marked as a duplicate of this bug. ***
*** Bug 158996 has been marked as a duplicate of this bug. ***