As discussed in IRC, here are some ideas to clean up the /messages pages that don't involve substantial architectural changes to the message list table:

1. Streamline the "Actions" fieldset

I think there are a few two many buttons and menus here, which make it confusing to use. I'd rather have fewer visible options with all of them contained on a single line (using much less screen real estate). And if we did fit these on a single line, we might consider moving them out of the fieldset and just display them visibly at the top of the message list.

So here's how I'd possibly do it. Create three drop-down menus:

a. Actions... (includes "Archive", "Delete", "Mark as read", "Mark as unread")
b. Apply tag... (includes "Tag1", "Tag2", "Add new tag...") -- For those with permission, the "add new tag" would take them to a separate page (or overlay) to add a tag.
c. Remove tag... (includes "Tag1", "Tag2")

And then get rid of the "Execute" button because the actions should execute upon selecting them in the drop down.

2. Streamline the "Filter Messages" fieldset

I think this might look better if there wasn't such a big form embedded in this fieldset. It's usually so big that once I open it, I can't see my message list anymore. So instead, how about just having a single autocomplete box at the top of the page (labeled "Filter by user" or "Filter by participant") along with a "Advanced search" text link next to it. This autocomplete would be substantially smaller than the current "Participants" autocomplete. If the "Advanced search" link was clicked it would take them to a separate page (or overlay) where all of the options in the current form would be visible.

One alternate option would to display both a "Search" box (the current "search subjects" field) and "Filter by user" field side by side, but it would be important to get them on the same line. Then I'd still have the "Advanced search" link.

If we did what I've outlined above, we could maybe get ride of the "Filter Messages" fieldset altogether. Better yet, I'd love to get the three "Actions" drop-down menus along with the "Participants" autocomplete appearing on the same line in Bartik. It would make all of these options a nice cohesive page element. If we did this right, the width would be pretty limited. And it would still look fine for users who didn't have one or both permissions.

Thoughts?

--Ben

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

BenK’s picture

Some other thoughts:

3. Change order of "Participants" column: Currently, "You" is listed before the other participants. Should "You" be the last participant since it's a given that you're participating? Or maybe hide it altogether from the list page?

4. Instead of displaying the tags in a separate column, I think it would be cool to display them in the subject column below the subject line for each thread. We could make them appear like tags (with little icons) just as I proposed at http://drupal.org/node/956336 for the message view page.

5. Is there any way to format the date field like github does: "2 days ago" or "23 hours ago" or "Oct. 22, 2010". It would make things a little bit cleaner to look at.

--Ben

BenK’s picture

Hey Berdir,

Given your recent comments in IRC...

berdir: Btw, I learned a lot about ajax and tabledrag while working on my properties school project, I will be able to use that on the /messages redesign issue, I think

... I'm interested to hear your thoughts on this thread whenever you have a chance.

--Ben

Berdir’s picture

Status: Active » Needs review
FileSize
17.65 KB

I think we should try to do incremental improvements here...

1. A first patch, mainly tackling the actions area
- Moved above the list and removed the fieldset
- Removed buggy/broken javascript to submit on selection/remove buttons and instead use #ajax and #states. Yes, #ajax :)
- Moved the archive button into the select, refactored the whole thing to be able to easily declare if an operation should be a button or an option in the select. Also added an alter hook to allow sites to change this.
- Left the Delete button, I think we have enough space to do that and that's probably the most often used action apart from mark as read. Could in theory be customizable per site or even user, but that's something for later.
- Also didn't remove the add tag autocomplete field, I kinda like that, but I'm not sure..
- Some CSS styling to have the same margin between the different elements. Maybe we can optimize this a bit but already looks much better than the default, where only buttons have a higher margin.

2. Nothing changed, not yet sure what to do with this...

3. Removed the current user from the Participant list to try this out, we can still decide to make this configurable. I think I like it...

4. Not possible by default. However easy to do by overriding 2 theme functions for a site. See http://blog.worldempire.ch/de/api/search/6-2/list_field__, you basically need to merge the tags theme function into the subject one and empty the tags theme function.

5. Well, core does have both a format_interval() and a format_date() function. The question is when to use what... The patch currently uses format_interval() for messages which were sent last month.. You can also configure how the date is formatted at admin/config/regional/date-time, there is an issue open about making it configurable which date format to use.

Note that there will be test fails, I'll look into these later... You can still test this.

BenK’s picture

Status: Needs review » Needs work

Hey Berdir,

I took a look at your patch and things are already looking better. Great work. I've done some more testing and thinking, so here are my notes:

1. I really like the improvements in the actions area.

* I agree that we should keep "Delete" as a separate button.

* For the tagging elements (autocomplete, apply tag button, remove tag dropdown), what if we did it similar to what we did on the message view page? Instead of the "Tag this conversation" link, the link would say "Tag conversations". Clicking the link would reveal the tagging form just like on the message view page... except that this time the form would include the autocomplete, apply tag button, and remove tag dropdown. We'd also probably need a "Cancel" link on that form like we did on the message view page. This option would help the UI better match between /messages and the message view page. Plus, it would make things look cleaner and simpler.

2. For the "Filter Messages" area, what if we made it very similar to what I just proposed for the tagging area? Basically, we'd follow the same approach as the message view page. We'd git rid of the field set and instead just have a simple text link that says "Filter conversations". Clicking that would reveal the one-line filtering form which would look very similar to the one-line tagging form. From left to right, this would include a "Participant" autocomplete, a "Tags" dropdown, and a "Subject" search box. The "Filter" button would be at the end of the line (with a "Cancel" link next to it). What do you think?

We'd also need to figure out where to put the "Filter conversations" link. I'd suggest to the right of the "Tag conversations" link if that's possible. This way, all of our options would be on a single line. If the "Filter conversations" link would get in the way of the tagging form when the tagging link is clicked, how about making both the tagging form and filter form appear beneath the actions line?

3. I think I also like it without the current user. It's just extraneous information. But one thought: Currently, if you send a message to yourself, the "Participant" field is blank. Should there be a special case to print "You" if the current user is the only conversation participant? Or do you think this is unnecessary extra text? I wasn't sure.

4. OK, thanks for the explanation and how-to.

5. That's a great suggestion to display different formats based on the time range (that's what Gmail does too). I took a look at how Gmail does it to get some more inspiration. Here's my suggestion for formats based on how old a given message is:

Current hour: 25 min ago
Current day (but not within the hour): 10:30 am
Current year (but not on the same day): Nov 25
Prior years (not the current year): 11/25/08

Ideally, these would be configurable by the site admin for all four time ranges. Or alternately, is there any way to have the PM module add its own date and time formats (which the site admin could then change at admin/config/regional/date-time)?

Thanks for your nice work on this!

--Ben

Berdir’s picture

1. Interesting idea with the link, but maybe as a follow-up so we can get the existing improvements commited asap? (thinking about a beta release...)

2. I don't think the filter form fits on the same line as the other stuff and I'm not convinced that it would be good UX. When you click on tag messages for example, it wouldn't be intuitive how to go the the filter from form from there (you'd have to click on cancel for and then another link). Anyway, I'm currently working on creating a contributed module out of my filter_extender patch that can build filter forms for all types of tables. That would allow us to optimize the filter handling once and use it in privatemsg, userpoints and other modules. But that needs some time and we might have to postpone this until 7.x-2.x. For short term improvements, we could try to save a few unnecessary lines in the current filter form and not waste too much time on it.

Ultimately, the idea is that we can improve the filter_extender in contrib and then move it into Drupal 8.

3. That's probably the reason we haven't removed it so far. I doubt that there is an easy way to improve this, so I'll probably leave it like it is now (with the patch).

5. Nice ideas, I'll see if that's possible.. will undo the changes in this patch and then handle that in the other issue.

What do you think?

BenK’s picture

Hey Berdir,

OK, sounds good.

I can create a separate issue thread for 1).

As for 2), yes we could just try to do a simple quick fix until we can pursue a longer-term solution. How about the following:

a. Change "Search subjects" label to "By subject".
b. Shrink the size of the "Participants" autocomplete. It could be about half the width that it currently is now. Change "Participants" to "By participant".
c. Change "Tags" list to a dropdown menu. Change label to "By tag".
d. Maybe put the "By participant" field and "By tag" dropdown menu on the same line.

As for 3), yes, let's just keep it without the current user shown (as we do in the current patch). All things being equal, less text clutter is better.

And if we could implement 5) that would be a big improvement, I think.

--Ben

Berdir’s picture

Status: Needs work » Needs review
FileSize
20.66 KB

2a. Changed. Also changed "Search messages" (visible when body searching is enabled) to "By content". other suggestions?
2b. Changed.
2c. Changed the label. This is a multiple select, it can't be a dropdown as that doesn't allow to select multiple tags. Shrunk it to the size of 3 however.

I also noticed that we already had some CSS but it was broken since a very long time ;). I updated it to place the label on the same line and removed unecessary margins and paddings from different places. It is much shorter now.

5) Agreed, but in the other issue :)

Status: Needs review » Needs work

The last submitted patch, improve_messages_list.patch, failed testing.

Berdir’s picture

Status: Needs work » Needs review
FileSize
19.8 KB

Fixed the tests, also made the filter widget collapsed by default again.

BenK’s picture

Status: Needs review » Needs work

The latest patch looks great. A substantial improvement. Almost marked this RTBC, but there are two possible small changes:

1. The CSS changes may have caused the "Tag this conversation" form on the message view page to have its button and cancel link below the autocomplete field (instead of next to it, all on one line).

2. We could possibly put the tags area in its own column on the left of the 'By subject' and 'By participant' area. That would save vertical space. But maybe with long tags it could cause things to break apart.

Feel free to mark as RTBC if you think #1 is unrelated and #2 isn't feasible.

Overall, this patch has some very nice improvements!

--Ben

BenK’s picture

One more thing regarding "By content" (visible when body searching is enabled)...

How about:

"By message text"

or

"By message body"

or

"By message content"

--Ben

Berdir’s picture

Version: 7.x-1.x-dev »
Status: Needs work » Patch (to be ported)
Berdir’s picture

1. Fixed.
2. Not changed.

- Fixed system/ajax wsod error
- Renamed to "By message text"

Commited!

Berdir’s picture

Status: Patch (to be ported) » Fixed

Ported to 6.x-2.x. That was tricky....

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.