Threaded discussion UI for my app

Question

In the system I am developing, I need to create a UI for managing customer notes. A customer note is a textual note related to a customer that a customer service representative writes. For example, a note might look like:

Please note that this customer does not like to be called early in the morning. If callback is required, do it in the afternoon.

Also, a note can be "replied to", for example:

Note 1 (written by customer service rep a):

The customer didn't receive her order, what happened?

Note 2 (written by customer service rep b):

It turns out that the customer entered the wrong address

Note 3 (written by customer service rep a):

I have called the customer and asked her for her address. It should be all good now.

A response can only be one level deep, as in the example above.

My idea to present this is as follows:

Have one big grid that displays all the notes (including metadata about each note). Notes that are part of the same reply chain, as in the above example, will appear next to each other in the grid, with the most recent note in the reply chain appearing at the top. To convey that each note in a reply chain is"connected", I want each note in the reply chain to have the same colour in its leftmost column, as in the image below. Is this a good idea? So as you scroll through the grid, you will quickly get a sense of which notes are related, and which are not.

By the way, this is a desktop application written in a legacy framework that can't do very much. So please don't suggest anything too fancy.

Answer 1

You mix two different types of information within a single thread: meta info, message, meta info, message, meta info, message, .... Neither working with meta info nor working with messages would be good.

Better, consider following.

Put everything related to one message into a single line / row. For instance:

Subject | Customer Service rep | Date | Message

or

Message | Subject | Customer Service rep | Date

Then if smb is interested in message flow only, he will read one column. If smb is interested in dates (e.g. how long did it took to resolve the customer request), he will focus on another column. It will be easier to read and to look up for everyone.

Answer 2

Solving these sorts of issues in "notes" is less desirable than using "cases", where an item is either open or closed, and has a definitive resolution. Assuming you can't do something like that, I'd try something like this:

Here, subject is listed first, and not repeated if it's the same for consecutive notes. If the thread is too long, you can hide old messages by default and allow the user to click to see more.

I'd avoid defining threads by color alone for multiple reasons.

1. Accessibility - your users may not be able to distinguish them.
2. More work - you'll need to think about what colors to use and if they should mean something
3. Extra weight - presumably you've got a lot of information on the screen, and this isn't the most important thing. I'd avoid emphasizing the notes with bright colors if possible.

Additionally, I'd consider using "days since note" instead of the actual date (but, still allow someone to see the date if they roll over it). In my experience, agents primarily try and mentally calculate this anyway. If we do it for them, it helps them work faster.