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)

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)