How could you indicate that data is 'copy and paste-able' but not editable?

Question

I'm currently working on a data-rich desktop interface.

We have a situation where we're displaying a long list of attributes. Unfortunately I can't go into specifics but ultimately the user can copy and past individual attributes into a search field to narrow their results.

We want to be able to indicate that it's possible to copy individual attribute data. It was suggested that the attribute data be placed inside a text input, but that suggests the data is editable. We could place a border around it that gives it the appearance of an interactive element, and not editable, but that could suggest it is editable but disabled and therefore not helping to indicate the 'copy' function.

I'd be really interested to hear what everyone thinks about this. Sorry this is all a bit vague. The options we have at the moment (and none of them are right) are:

1. Text input - suggests it can be interacted with but also that it is editable (which it is not)
2. Outlined box around text - suggests it's different from other plain text but may look 'disabled' and not necessarily that it can be selected and copied
3. Do nothing - and have the function as an 'advanced' user function that they discover in their own time. It doesn't prevent novice users from using the system and assists advanced users who have learnt the behaviour through exploration.

Answer 1

You can use the text input/textarea, with the readonly attribute set

<input type="text" readonly value="Lorem ipsum" />
<textarea readonly>Lorem ipsum</textarea>

so the data is 'copy and paste-able' but not editable.

The problem is that the user might think that the input is disabled, but you can place a button after each text button that says "Copy to clipboard" or something related.

Answer 2

Assuming you have a light gray (or other pale-colored) background for the window in general, such as typically found in dialog boxes, the following conventions have been used and seem to be successful for text boxes:

Editable = Black text on a white background, with a border.

Interactive (e.g., tab-able, copy-able) but not editable = Black text on a pale (e.g., light gray) background, with a border.

Disabled (i.e. not currently interactive, but can be made interactive (and usually editable) by a simple user action) = Dark gray text on pale background, with a border.

Inert (e.g., a label) = Black text on a pale background, no border.

If you have a white background for the window, then there is no common convention. I’ve experimented with a “compact presentation” intended for a white background, but I haven’t completed user testing. It may be a good starting point for your testing.

Whatever coding you use, you may want to consider making all your attribute data interactive/copy-able throughout the app, whether it is specifically needed for a task or not, so your users will not have distinguish interactive and non-interactive read-only data. This also provides an important means of improving your app's flexibility to cover unexpected needs.

If your windows/pages look like a web app (or if it were a web app), it may not be necessary to do anything –your users may be used to selecting and copying arbitrary content –including labels and prompts –from web pages. Of course, then you should support such an ability (if it were a web app, you probably already would).

Answer 3

I've seen this interaction around, but I'm not sure if it would make sense for your site:

When a user clicks into the field, have it auto-select-all. That way the user knows that something is different about this field and it also saves them the step of selecting everything. Might not make sense in your current setup if you don't want them to select all, but might be good.

Edit: This is on top of the above user's suggestion of putting a "Copy" button next to the field.

Answer 4

For the user to notice that the test is selectable, the cursor pointer has to become an insertion point vertical bar, like the one I see now as I'm writing this.
This can be achieved by setting a readonly input element, like Chris suggested, but there might be other ways.
It is also important to agree a code with the user, like if it has a border it's editable else it's not. The users will learn it at once, without noticing.

Besides, we are all intrigued by the fact that you can't do something more straightforward, more usable. Like, that double-clicking an element would do the whole copy&paste cycle.
At least, copying the text into the clipboard with a button (as Chris suggested) or with a double-click would be something. As the copy action has no visible outcome, some sites add an animation, like a copy of the text moving up and vanishing in the air like a soul that goes to heaven. This (or whatever) is useful to reassure the user. The advantage of the animation over a "text copied" banner is that the animation happens where the user focus is.
Another plus would be to flag the already-copied elements, like for example setting the text in gray instead of black. This is useful in tasks where the user has to copy a number of elements and wants to be able to check her work for completeness.

Answer 5

All text should be copy and pasteable so that you do not need to highlight this just differentiate between editable and other text.

If you need to highlight this specific text then your option 2 sounds the best, and I don't see your issue here as there is no disabled text anywhere

Answer 6

You could make the text a link which copies to the clipboard. You could add a "copy" icon next to the text.

Ideally, I agree that if 80% of the users would want to use it to paste it in another piece of your UI 80% of the time, this is waht it should do by default. If you want to use it as an appendage to the search query, that's fine, but just do it automatically.

Answer 7

I'll follow the precedent already set by the operating system you're targeting - as a "data-rich desktop interface" I'm expecting that you're not talking about a web page.

For example, the Windows OS has a number of dialogs that provide similar functionality to that you describe - here's a file property dialog from Windows 8:

All of the field values shown allow the user to select and copy some/all of the value - if you look closely, you can see the cursor is shown at the end of the "Location:" field.

Following the conventions of the host OS has all the usual benefits of consistency - reducing the learning curve and so on.

Of course, if you're targeting Mac OS X or some Linux variant, be consistent with whatever your users will have already experienced.