ability to include column headers when copying-and-pasting

[chriddyp]

Currently, when you copy and paste contents from the DataTable into Excel, only the currently selected contents are included. This item would enable the copy-and-paste to include the column headers when pasting the data.
This setting would be set by the Dash developer through a property like “include_headers_on_copy_and_paste=True”.

Note that this would be independent of the rows or columns (#317) that have been selected

[Marc-Andre-Rivet]

There are two scenarios to cover here:

1. copying from the table to somewhere outside the dash app scope (not in a table / same page / iframe) - we would want the headers to be present on op
2. copying to the table itself to somewhere in scope - we would not want the headers to be present on op

The basic implementation is very simple with a flag but, the UX for this seems confusing as a user would have very strong expectations for the selection to match the pasted value. As the headers were not selected, they are not expected. I would advice against implementing this as-is.

This looks more like a special copy selection as table kind of operation that should be triggered through another UI pathway than the standard Ctrl+C/V.

Considering this PR, #313, #314, maybe we want to include an operations/menu bar at the top of the table for the various special operations to live in, somewhat similar to the action bar in plotly.js instead of considering each in isolation. In this scenario, the flag would make this operation available instead of changing the copy/paste behavior.

Also wondering about the impact of this on a theoritical multi-zone selection feature in the future.

Also, maybe we make the headers selectable/part of navigation. Multi-cell headers are the edge case to consider.

@alexcjohnson Maybe you'll have additional insight from how the menu bar came into existence in Plotly.js

[wbrgss]

This looks more like a special copy selection as table kind of operation that should be triggered through another UI pathway than the standard Ctrl+C/V.

Expanding on some thoughts from a Slack DM with @Marc-Andre-Rivet. I think something like Ctrl+Ins, makes the most sense as a shortcut for this behaviour — either that or make column headers specifically selectable. That shortcut has precedent, including for this behaviour specifically. I think this would be preferable over a include_headers_on_copy_and_paste. I imagine a user could be switching back between copying headers and not, e.g. initially copying the whole table and subsequently copying additional rows as they are added. In which case it could be slightly annoying to turn the flag on and off.

include an operations/menu bar at the top of the table

For this type of behaviour et al, I think a context menu would be more appropriate. But this jars with the current "keyboard selection only" behaviour.

Another option is to just make the headers selectable as well. This is probably the most obvious UX behaviour for a table user. Again, not sure if it's worth it in terms of implementation difficulty.

[alexcjohnson]

The plotly.js menu bar serves basically two purposes: 1) to change how mouse actions behave (click-drag and hover) and 2) to do certain actions (download, autoscale...) in a discoverable way, without having to teach users new key combos. I do like the menu bar in light of #313 and #314, in which case I'd say "copy with headers" should just be an action you do from the menu bar, rather than a mode you choose from the menu bar. We could also give it a new key combo, and use the menu bar tooltips to tell users what that key combo is. If we do that, ins isn't Mac-friendly, I'd vote for ctrl/cmd-shift-c or something like that.

There's a question then of where to put the menu bar; on a graph it's easy to use some space at the top, which is usually a margin, esp. if the menu bar is only shown when the mouse is over the graph. Tables don't have margins like that... I suppose we can just make it opt in (perhaps with options for either always visible or only while the mouse is over the table... as long as hiding it doesn't reflow) and put it at the top (right or left)?

Re: making headers explicitly selectable - I'd also think you want to be able to omit the top row(s) and still copy headers, which you couldn't do with selectable headers under the current selection paradigm.

[chriddyp]

The basic implementation is very simple with a flag but, the UX for this seems confusing as a user would have very strong expectations for the selection to match the pasted value.

I agree in general that we could benefit from a broader UI for these types of issues. However, for this particular issue, the end-user is looking for a copy & paste behavior for a very particular workflow.

In other words, consider this feature for apps that have a very defined/structured workflow to-and-from Excel. This is a workflow that they are "trained in" and so they expect a very structured behavior.

So, in advance of the broader UI menu bar design, I'd vote in favor of making this a simple flag to start to in order to satisfy the requirements for this particular workflow.

[Marc-Andre-Rivet]

Discussion notes: This will be implemented as a flag changing the behavior and this flag will be documented as beta. Future UI work may impact it. When copying from the table onto itself, the headers should be ignored, when copying between two tables within the same tab, the headers should be ignored. It's not possible to do so across tabs. This ignore/include behavior should work with the current table implementation without requiring extra work.