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)

@Whatamidoing (WMF): 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)

@WiseWoman: 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)

@Filceolaire: 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)

@Filceolaire: 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)

@Filceolaire: 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)

@Filceolaire: 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)

@Filceolaire and Whatamidoing (WMF): 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)

@Whatamidoing (WMF): 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)

This is a big complaint from our users. I find it extremely frustrating as well. I do agree that specifying pixel widths is not good but what is wrong with allowing percentage widths? That scales to any device and yet allows authors to have some control over what is important. For example, let's say I have a table with 3 columns; book Title, Author, and Summary. As the author, I believe the most important column for the reader is Title. If the title catches my eye, I want to look at the Summary. Yet the Summary column overtakes the table because it is a paragraph of content. I would want the title to take up 40%, Author 20% and the Summary 40%. Yet for me, the Summary takes up 70% or more of the table.

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)

@Dcutter: 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 W:Donnie Wahlberg#Film, W:de:Bahnhof Coesfeld (Westf)#Bedienung and W:es:Chimillas#.C3.9Altimos alcaldes de 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)

@Amire80: 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)

Thanks Whatamidoing (WMF)! I'll try to come to the triaging meeting today and will mention it if I can. I've also noticed another weird thing within the tables when inserting an external link (actually, I'm not sure if it's limited to only adding external links within tables or happens everywhere). I'm working on an article in a sandbox in en.wp with a LOT of tables. I'm deliberately trying to push the system to its limits - and it's holding up pretty nicely. It's slowing down a LOT when I load the visual editor, but that's not surprising. I'm also round-tripping a LOT between the two editing styles depending on the functionality I need (they're both better for different things). One thing that does frustrate (other than what I already mentioned as feature requests) that when I insert/edit a new external link it:

• Frequently inserts an INTERNAL link to the word that I highlighted - even though I pasted in the URL that I wanted to insert as an external link. It seems that if I press the done/insert link button before it has finished thinking, then it simply forgets I had added an external link URL, and makes it an internal link instead. I worked out that I have to wait for a few seconds before it finishes thinking, and THEN press done.
• When I want to open up and edit in VE an external link that I had already placed in a table previously, I have to double-click the cell to activate it (this sometimes sends me to the very bottom of the page from where I have to scroll back up. Then, with the cell active, I single-click on the link to activate the dialogue to edit it - which will then send me to the very top of the page from where I have to scroll back down.

Not sure if I can turn those into formal bug reports, but if you've seen something similar (or can replicate that when trying to use the VE on the sandbox article I linked above) please tell me. Wittylama (talk) 13:43, 11 February 2015 (UTC)

Wittylama, your first one is already filed as a bug. It happens to me, too.

The bad scrolling is probably browser dependent. Are you using Safari? Whatamidoing (WMF) (talk) 18:22, 20 February 2015 (UTC)

Hiya Whatamidoing (WMF) I'm using Chrome on OSX. I've replied in greater detail over on w:Wikipedia:VisualEditor/Feedback#Suggestions with a more precise way to replicate the behaviour. Wittylama (talk) 12:07, 27 February 2015 (UTC)

Keyboard interaction to change the focus in the table

I miss some keyboard function... I like to work with the keyboard, to change the focus to the next field in the table. I like the intergration like MS Excel. Here I can select with the cursor field the correct field in the table and can input my text. After I finish to write the text in the field, I can press enter to go to the next field or with cursor left, right, up and down to navigate to my next favorite field.

February 2016 Update

In case anyone's watching this page:

There will be improvements to the table tool soon. One major improvement is the ability to copy and paste columns, which will allow you to copy a column and paste it into a different place in the table. This will make re-arranging tables much easier.

If you want to hear about these improvements after they have happened, then you may want to subscribe to m:VisualEditor/Newsletter. You can also look at https://phabricator.wikimedia.org/tag/visualeditor-tables/ to see what is planned. Whatamidoing (WMF) (talk) 19:20, 1 February 2016 (UTC)

Great news @Whatamidoing (WMF): , I'm going to put a few feature requests below, what would be the best way to let the VE team know about them? Put the on Phabricator? Thanks, John Cummings (talk) 19:45, 22 April 2016 (UTC)

Phab is best/fastest, and, if you tag your requests with the project "VisualEditor-Tables", it's also the most likely to be seen by the devs who work on it. Here or at VisualEditor/Feedback is okay, too. Whatamidoing (WMF) (talk) 01:51, 24 April 2016 (UTC)

Thanks @Whatamidoing (WMF): , I'll put them on Phabricator. John Cummings (talk) 09:28, 24 April 2016 (UTC)

feature requests for table editor in VE

Hi

After using the table editor to do tables for my WMF grant reports (which I spent several hours having to trial and error correct in wikitext) I would like to request the following features, it would save people doing grant reports and I'm sure people editing Wikipedia as well a lot of time.

1. The ability to change the colour of individual cells, this is especially helpful when creating timelines.
2. The ability to add multiple rows or columns simultaneously, it is very time consuming to create big tables.

Thanks

John Cummings (talk) 19:55, 22 April 2016 (UTC)

After editing table it meshedup

Here i created a table http://www.mat54-wiki.nl/mat54_Wiki//index.php/DIN95-SOHMS After editing ad the r parameter the table doesnt show correct. Can anyone point me to the solution ????? Had to create and fill the table again

keyboard shortcut to move table rows up and down

Is this possible and am I missing it?

If so, what is the shortcut for moving tables rows up and down in visual-editor?

If not, please add it!

Thanks! /Rich