Talk:VisualEditor/Design/Table editor

Hovering on mobile?
I like this design, and I think it covers all the basics: change the number of rows and columns, set the top row to gray (or not), etc.

One possible problem: How do you "hover" on a mobile device? Is table editing intended to be impossible for mobile users? Whatamidoing (WMF) (talk) 23:01, 10 July 2014 (UTC)


 * For touch devices, we're expecting to only show the handles if you select in the area (i.e. if you drop a cursor there), which is slightly less quick but works well enough. Does this make sense to you? Jdforrester (WMF) (talk) 02:43, 11 July 2014 (UTC)


 * I think the hovering is good for advanced editors. But for beginners they will not see that there is an affordance to add or delete tables. I suggest that there be icons for this (similar to the Confluence wiki, I've seen many beginners able to use tables with their icons), and that they be turned on by default. Advanced users can then turn them off. As noted above, please look into how responsive your design is on pads and telephones (although I am old-fashioned and use a laptop, still). --WiseWoman (talk) 06:17, 11 July 2014 (UTC)


 * Maybe the design sketches don't make it clear enough – the idea is that on either selection or hover tools would be provided. I'm not sure about whether there's enough space to try to show lots of icons (rather than just a button) given how wikis generally lay out their tables. Also, all of VisualEditor is designed to work on both mobile and desktop devices, worry not. :-) Jdforrester (WMF) (talk) 17:35, 11 July 2014 (UTC)


 * I agree. Provide something to click (or touch) to select a row or a column. I prefer option 8 as well - menu drops down when the row or column is selected. Filceolaire (talk) 14:23, 11 July 2014 (UTC)


 * Yes, the idea is to how the handles on hover or selection; on mobiles, it will have to be selection-only. Jdforrester (WMF) (talk) 17:35, 11 July 2014 (UTC)

Menu for changing the whole table
There should be a button to click to bring up a menu of options that apply to the whole table:
 * Make table sortable/unsortable
 * select format (lines colours etc.) from a shortlist of preset named options. Each wiki to define what options they want to offer as their style guidelines. Shell may vary the details of these - if you have the 'subdued' shell then colours are toned down, made more pastel; if you have the 'high contrast' shell then everything is tweaked to make it more legible to people with poor eyesight. Filceolaire (talk) 15:06, 11 July 2014 (UTC)


 * That's what the grab handle in the top left would do – click to get a menu for the whole table, drag to move the table elsewhere. Jdforrester (WMF) (talk) 17:30, 11 July 2014 (UTC)
 * I've now modified the description to make it obvious – thanks for the catch. Jdforrester (WMF) (talk) 17:44, 11 July 2014 (UTC)

merge cells / split cells
I notice the desired functionality includes merging and splitting cells. Is this really needed? I know this was used in the good old days as a presentation tool for web pages but I'm pretty sure we don't want to do that. Is this used much on wikipedia? The immediate effect of doing this is that it prevents the table from being sorted and makes it impossible to add or delete rows and columns. Filceolaire (talk) 14:32, 11 July 2014 (UTC)
 * It is used unfortunately often, although on en.wp this is usually handled through complex templates that construct the table for you. Whatamidoing (WMF) (talk) 17:17, 11 July 2014 (UTC)

Wikidata integration
Wikidata integration is a thing which tables will need to have at some stage in the future. This can come in two ways:
 * 1) Import data from multiple wikidata items. In this type of table each row in the table corresponds to one item in wikidata and each column corresponds to a property that may be used in a statement about that item or the qualifier to a property.
 * 2) Import data from one wikidata item. For example a sports league table. Each league season will have an item. In that item there will be statements for each team giving all their stats so each row is the object of a "participant" property and each column is a qualifier to the wikidata statements about those participants.

Maybe number 2. should be a bunch of templates? Filceolaire (talk) 14:43, 11 July 2014 (UTC)


 * Neither of these issues are in-scope for table editing; those are both kinds of transclusion, and per the Wikidata team we're not rushing to implement them yet. Jdforrester (WMF) (talk) 17:36, 11 July 2014 (UTC)
 * OK then. Just so long as the software doesn't prevent this being added later. Filceolaire (talk) 19:20, 22 July 2014 (UTC)


 * Indeed! Jdforrester (WMF) (talk) 19:46, 22 July 2014 (UTC)

Do we want people to set column widths?
It is important that wikipedia pages are readable on a wide variety of screen sizes from cheap phones to projections. Sometimes people will want the table to autoadjust to the screen size. This can mean you have really narrow columns - in those cases people will want to side scroll instead. I'm not sure what the solution is but I'm a little wary of having column widths dictated by editors rather than readers.

Row heights should IMHO always autoadjust and should never be preset else you can lose info off the bottom of the cell without even knowing it. Filceolaire (talk) 14:54, 11 July 2014 (UTC)


 * I sometimes want to declare that two-column tables must be evenly split (column width = 50%). Defining an exact number of pixels is not so good in most cases.  I've seen a few that use small "columns" basically for color-coding.  That might be a reasonable use of pixel-based definitions.  Whatamidoing (WMF) (talk) 17:20, 11 July 2014 (UTC)


 * However, maybe we don't want to encourage that? I'm not sure. Jdforrester (WMF) (talk) 17:59, 11 July 2014 (UTC)


 * Don't want to encourage pixel-based column sizes, or don't want to encourage any column sizes at all? Whatamidoing (WMF) (talk) 16:59, 14 July 2014 (UTC)


 * The latter; sorry for my inclarity. The number of times people want to do certain things may be high, but it's almost always against the intent of the system (in this case, HTML). Jdforrester (WMF) (talk) 19:24, 14 July 2014 (UTC)
 * What does "encourage" mean in this context? Making it impossible to fix (=at the very least, to remove) a preëxisting column-size problem might be less than desirable.  If you take away the ability to set them entirely, then I'll just do it in wikitext—which is fine for me, but not so great for other users.  However, I would not want to make it a prominent feature, because usually it shouldn't be done.  Whatamidoing (WMF) (talk) 20:07, 14 July 2014 (UTC)

What is the initial size of 4x4 based on?
Did you do some kind of research on table sizes in Wikipedia to get to these figures? If you want a quick and simple solution, it would be ideal if the initial size fits in at least some cases. Dcutter (talk) 20:05, 14 July 2014 (UTC)


 * Yes; I went through Special:Random on a few wikis hunting for use of tables, and found that four columns seemed to be about the normal (for the relatively rare articles that actually use tables). From a quick spate of Randoms just now, see Donnie Wahlberg, Bahnhof Coesfeld (Westf) and Chimillas for examples. Jdforrester (WMF) (talk) 20:41, 14 July 2014 (UTC)

Variation 8 (all actions in menu)
This looks really good! Regarding point 8 (variation: all actions shown in menu), I prefer this and think it's generally a good idea if all actions are also available through menus somewhere, not only icons. In my experience, I many users grew up with traditional "menu-driven" software and would not immediately realise that the + icon means "insert row/column" if it isn't spelled out somewhere. Stephan Matthiesen (talk) 09:09, 22 July 2014 (UTC)
 * I do agree, I think Variation 8 is more user friendly because it is "classic". I think it is the best solution. NemesisIII (talk) 22:02, 26 July 2014 (UTC).

Recommendation from fr.wp
Hi all, while discussing the current status of tables in VE, where actions like hitting Backspace or Del can impact both the structure and the content of a table cell, a few users expressed their hopes that this won't be the case when VE will allow complete editing of tables (precisely like hitting Backspace in the first parameter of a template does not harm the template itself). --Elitre (WMF) (talk) 15:10, 25 August 2014 (UTC)

RTL
Well, I had to chime in with RTL :)

RTL considerations are not very different for tables. The default direction for columns and cells should be the site's direction.

It would be very nice to be able to change the direction of:
 * the whole table: in which direction do the columns go
 * a column: for example, in a table of the largest cities in the US in a Hebrew Wikipedia article, the table is RTL by default, and most of the data is written in Hebrew, but the column with names of the cities in English should be all LTR.
 * a single cell
 * a row. This would be useful for articles such as en:List of numbers in various languages, but if its development is expensive, I'd guess that the priority of this is lower.

There are also the cursor movement considerations. They, again, aren't very special, but during the development it must be tested that if I'm at the end of a cell in an RTL table and I press the left arrow key, I am moving to the next (logical) cell, and so on.

Thanks for the consideration :) --Amir E. Aharoni (talk) 13:40, 19 October 2014 (UTC)


 * Block-level language (and directionality) editing is something that we need to do more widely, and represents a huge amount of design work that is not a high priority; however, you can make a selection and use the inline language tool to set RTL/LTR status and/or language across the whole selection. Jdforrester (WMF) (talk) 18:21, 20 October 2014 (UTC)

Ctrl-End
I love using the Ctrl-Home and the Ctrl-End keys, which bring the caret to the beginning and the end of the document. (The actual combination may be different on Mac OS.) This already works well in VE.

I also love the little variation to this feature that exists in LibreOffice. If you press Ctrl-End in a table cell, the caret goes to the end of the cell. If you are already at the end of a cell, it goes to the last row of the table. And if you pressing it for the third time, it goes to the end of the document. Comparable logic works for Ctrl-Home. AFAIK, in other word processors, Ctrl-End always goes immediately to the end of the document, but I might be wrong.

It maybe just me, but I find this feature very convenient, and I miss it when I use Google Docs or MS-Word.

Please consider this :) --Amir E. Aharoni (talk) 13:58, 19 October 2014 (UTC)

Feedback - most needed next features
Hi team,

I've been playing with the new table editor function and I'm working on a new, Table-heavy, list article that I've wanted to create for ages but until now I never dared start. So - thank you! The 'add new row' feature is the 'killer app' for visual-editor tables as far as I'm concerned - I never wanted to start a big table before out of fear that if I changed my plan for the layout/content then I would have to manually go through and add pipes to each segment manually to add a new line....

With that said, I've been pushing the limits of what the current table editor can do and I find myself switching back and forth between visual and traditional editor to get different things done in the easiest manner. The single most time-consuming thing that I have to do on the traditional editor is what is listed in your "possible features" list as:  "Reorder columns (drag sort)" . From my personal experience with this version of visual editor, I would strongly suggest that THIS is the most important priority.

The NEXT most important issue, again, in only my own experience with this software as it currently stands, is the fact that currently you have to double-click to activate a cell for editing. This means that, even though you're already in editing mode, you have to constantly swap back off the keyboard to the mouse to double-click a new cell in order to enter content. If it were only a single-click, then this would enable all sorts of keyboard shortcuts to navigate between cells. Most importantly, 'double-click to edit a cell' means that you cant use the Tab or arrow keys to navigate around a table while editing. This greatly slows down data-entry.

Lots more other features could be added of course, and everyone will have their own ideas, but I just wanted to give my feedback based on the current iteration. Great work, keep it up. Wittylama (talk) 16:08, 27 January 2015 (UTC)


 * Wittylama, if I said that your comments were thoughtful and wise, you might guess that I have exactly the same POV. Actually, the ability to tab between cells is #1 on my list.  Drag-and-drop columns (and rows, I think, but I'm certain about the columns) is definitely in the works.  I haven't heard anything about changing the requirement to double-click on table cells, but I'll ask.  Whatamidoing (WMF) (talk) 22:06, 9 February 2015 (UTC)