user expectation - Is it worth making an exception to a single-click master/detail pattern?

I have a pretty standard table where each row represents a record. A single click on a row takes you to a different screen where you can view and edit various properties of that record. It's a common master/detail pattern and works well for most of our use cases.

Recently, we started getting complaints from a few users who want to be able select and copy text from the master table without loading the details screen. Depending on your input device, doing so ranges from difficult to impossible. Even if you can do it, the UX is pretty poor and has a high error rate.

We could simply ignore the complaints and tell these users to copy the text from the details screen instead of the master table, but it does mean they have to go back and forth wasting many clicks to copy the text from all the records they are looking for.

The other option is to make this table different from all the others on our site. Clicking on it wouldn't do anything so that text selections could still be made. I don't know if we would make double-clicks load the details, or add a button to do it, but the implementation isn't that important.

The problem with having this table be unique is the lack of consistency. Our users have learned that our tables work with a single click and had this pattern reinforced throughout the rest of the site. If this table defies their expectations they may assume it is broken or otherwise have trouble accessing the details screen. We could add a little bit of instructional text, but we all know how little users read. Even if they are successful they might be annoyed by this table just for being different.

The twist is that while only 10% of our users access this table, they access it on 90% of their visits. It would improve the lives of the "regular" users of that section, but anyone who "wanders in" from other parts of the site might be lost.

Is it worth making an exception on this table?

Answer

After talking with the affected users and a lot of root cause analysis it turns out that the problem was the master/detail pattern was misused in this situation. The master table contains the specific information they are looking for (and want to copy) the vast majority of the time. The details are rarely, if ever, referenced or needed.

The solution was to replace the interactive master table with a regular, static table so that the text can be selected and copied normally. Our site has plain tables on it, and since this is no longer conceptually a master/detail pattern, it's not really an exception. It will certainly meet user expectations about what you can do with a static table.

There are a couple of user entered details that needed a new control to be editable, but the expectation is that they will be edited far less often than the copy & pasting the other data.

Moral of the story: even common interface patterns can cause more harm than good if you don't understand the context of their use.