Ok, I propose the following.

First, who is going to submit a search at the same time as they’re moving some individual items to arbitrary folders and a group of others to yet another place? Allowing that sort of multiple action just forces the user to consider every single control on the page (all belonging to several distinct actions) for every single action he takes. Awful. The whole thing needs to be broken out into several independent forms.

1. Folders need to be listed as clickable links on the left-hand side, with the count of messages in the respective folder included on the label. The currently selected folder should be highlighted and not linked.

2. The search stuff needs to be a completely separate from. Preferrably should go at the bottom, I think. Default the folder to “(all)”, since that’s what most people are probably likely to want when they do a search. Instead of the [From | To | From/To] dropdown, put two checkboxes. Comboboxes are the least usable UI control by far; avoid whenever possible.

   Update: search in deleted messages only when the user explicitly asks for that.

3. When showing search results from all folders, no folder should be selected; or maybe show a virtual “Search Results” folder. In that view, put the search controls at the top so they’re easier to reach when the user inevitably goes to refine his/her search.

4. Untangle the message input box from the target selection. The current setup is

   Send to:
     * User: [_____]
   Nobody  Reply text:
     *  [________________]
   Reply to:
     * Foo says Blah
     * Bar says Blah
   

   Instead it should be

   Message: [________________]
   
   Send to:
     * Nobody
     * User: [_____]
   Reply to:
     * Foo says Blah
     * Bar says Blah
   

   A nice touch for those with JS enabled would be to auto-select the “User” checkbox when the attached entry gets changed to something non-empty. Actually now that I look at the new arrangement I wonder why there needs to be a “Nobody” option at all; sending to a blank username would accomplish the same.

5. Move/delete:

   • Put the controls on the right side in the replies table, lined up with the checkboxes.

   • Lose the Folder dropdown box for individual messages, since it adds a huge amount of visual clutter and only benefits the people who have a significant number of folders and frequently file many different messages into many different of these folders at once. I can’t imagine that being such a large fraction of the userbase that it’s worth degrading the page’s skimmability for everyone else.

     Update: the only other case where these dropdowns matter is when doing a search that picks up results from multiple folders. So group search results by folder.

   • To preserve the “apply actions to the results of a search” functionality, you can add the search parameters as hidden fields to the reply form.

6. Update: lose the “(deleted)” vs. “(trash-bag)” distinction. Just show how much time messages have left till irreversible deletion.

Makeshifts last the longest.

Default the folder to “(all)”, since that’s what most people are probably likely to want when they do a search.

I thought the same, but then I saw it also shows deleted messages. I don't want to see those by default.

Also: the link to message inbox from the Chatterbox Nodelet and Fullpage Chat links to the Archive. I don't want that, but it's the only link to the message inbox on those places. I rarely, if ever, look at archived messages. I just want an easier interface to continue a conversation in private. That's not what I get now.

Ah. I didn’t notice that because I didn’t have any archived messages, so the link is just to Message Inbox and brings up the messages in “General”.

Makeshifts last the longest.

I agree with much but not all these ideas.

The CB now always links to both "new msgs" and "archived msgs" (and /looks like/ two links -- the previous links ran together).

I'm more convinced of my previous stance that the drop-down 'destination' controls should go. I'd like the "all but" checkbox I asked for and a simple "Delete" button and a "Move to" button w/ a drop-down list of other folders (we could also just make a button for each folder, but I think that would be less clear).

I'd rather the forms stay at the top (imagine viewing 500 msgs, which I sometimes do) but think that having a 'sticky' state that hides or shows the 'search' form (which should be a separate form) would be nice.

"Nobody" is there (in part) because neither the "send to" nor "message text" fields get cleared when you submit to facilitate sending similar messages to multiple people, coping with addressing errors, sending multiple messages to one person, etc. And w/o "Nobody" (which is /always/ what is selected when the form is refreshed), it becomes /way/ too easy to accidentally send more than you wanted to (and the "whoa cowboy" duplicate message check will only catch fairly fast exact duplicates).

We really need a prominent warning if you submit with non-empty message text but "Nobody" selected, because this is now the mistake that is /way/ too easy to make.

But, with the warning, the correction (select a destination and submit again) is trivial. With the common mistake being "send when I didn't intend to", the "correction" isn't pretty.

I'd eventually like the "/msg author" links to use a different page that is better suited for just sending private messages (and uses a better method for preventing unintended repeats).

I'd not put so much separation between "Message:" and "Send to:", more like:

   Send: [.......]
   To:
    * Nobody
    * [....]
   In reply to:
    * ...
[download]

Much thanks to demerphq for putting this together. There is more work to be done to smooth out the interface, but I think it will come together well, especially if people pitch in with patches.

- tye        

Hmm. I realized that a common task for me (and probably for others) is to reply to a message and archive or delete it. So it'd be nice to continue to support doing that with a single 'submit'. A drop-down over the 'select' check boxes with a list of folders and 'delete' would work well for that, I think (while also having a "Move" button for clarity).

Though, 'submit' can trigger both sending a reply and moving/deleting... Should the 'delete' / 'move' buttons refrain from sending a reply? Probably not.

- tye        

Okay, I better see the usefulness of the 'move to' drop-downs. But I think they make the interface confusing and a little scarier so I'd default to not having them, allow users to choose to have them, and, when reporting search results not restricted to a single folder, use text to indicate which folder the message is in if the drop-downs are not enabled. (I wouldn't sort results based on folder -- I'd rather keep them sorted by date.)

- tye        

First, who is going to submit a search at the same time as they're moving some individual items to arbitrary folders and a group of others to yet another place? Allowing that sort of multiple action just ....

The combination is absolutely required. I want to be able to search for messages based on a set of criteria and then organzie them into folders. Not allowing that sort of multiple action means that I wouldnt be able to do that. Which would defeat the whole purpse of this patch.

To rephrase: the idea is that you can select a set of criteria to find some messages and then have the ability to move them around as needed. If you can't combine the various parts then you have severly crippled the implementation. What good is it to me to be able to find a bunch of nodes but not be able to do something useful with them?

Some responses:

1. No it doesnt. That would take up too much room. People can have up to 99 different folders if they like. How do you plan to fit them all on one line.
2. Its possble ill remove the from/to option and maybe change it to some other control. I'm not aware of why you say "Comboboxes are the least usable UI control by far; avoid whenever possible." Seems to me to be a good way to avoid confusion as it shows only the option selected and doesnt distract with the options not selected.
3. No comment. You don't seem to have grasped that _every_ view of the message inbox is a "search" of some sort. You _can't_ seperate the action of searching from the action of viewing a folder as thats how the latter is accomplished.
4. Patches welcome.
5. I might change the drop down folder. I might just add a delete radio button so folks with not so many messages don't need to use it. But your claim that this feature cant be useful IMO is not correct, I find it useful, in fact I wrote it because sorting out my inbox without it was proving to be incredibly annoying. And again regarding your comment about "apply actions to the result of the search", any view of your inbox is a result of a search.
6. Yes i might lose the distinction between "trash" and "deleted". But there is no way to show how long a message has until irreversible deletion. The script is unaware of the logic that controls the deletion and only knows the "state" of the record. (FYI -3 is "user cant see the node as its deleted", -2 is "trash-bag", -1 is "deleted", 0 is "general/inbox", 1 is Archived, 2+ are user defined. This value is stored for both the sender and the receiver. When the record is in state -3 for both it is actually deleted.

Anyway, you are pmdev, put together some patches that you think improves the situation, and if they don't impact on what i feel are the requirements then ill put them into play. So lets see your improvements as a patch ok?

update: I'd like to add that I realize my comments above might sound a little testy. If so im sorry, I appreciate the time you took to feedback, and Ill do what I can with the time I have to smooth out some of the rough edges. But patches would be appreciated as they are a lot easier to evaluate than text descriptions or little ascii pictures are. (Not to say diagrams and descriptions arent useful, just patches are more so.) For all I know I've misunderstood some of your points anyway, which would be pretty difficult with code.

---
$world=~s/war/peace/g

The combination is absolutely required.

No, it’s not, not on the first click of “submit”. You want to first search for something, then do things to the search results. Not both at the same time.

If you can’t combine the various parts then you have severly crippled the implementation.

You’re stuck thinking in terms of the implementation. I don’t care what the implementation looks like. As I said, if you need to carry around search parameters, then by all means stick them in hidden fields. But keeping the UI slavlishly close to the implementation does not make it usable.

I don’t know if you as the one who developed the code and interface can appreciate how confounding that form is for someone else. I don’t think I’m exactly stupid, but it took me 10 minutes of experimentation to twiddle all the knobs and understand what’s going on. Way too complicated.

1. How do you plan to fit them all on one line.

   I don’t. I said “on the left”, implying a vertical bar that looks much the way webmail UIs tend to work. Even with 99 folders this should still be manageable.

   Switching folders is pretty much the most common thing most people will be doing, other than replying. Burying this action in a combobox that’s lost in the noise of all the other controls is horrible affordance. And do you really think a combobox is navigable for someone with 99 folders?

2. I’m not aware of why you say “Comboboxes are the least usable UI control by far; avoid whenever possible.”

   Comboboxes are modal with respect to the rest of the interface. Therefore when picking an option with the mouse they require precise aim (flagrant violation of Fitts’ law); with the keyboard, are awkward to operate; with non-visual accesibility tools, are timeconsuming to grok. (Popup menus of any sort share all these problems.)

   All of these issues just vanish if you replace the box with two checkboxes: two trivially operated controls. If the number of options were significantly greater, then it might be worth using a combobox (but even then only as long as the number is modest). In this case, though, it’s just better to employ a more usable control.

3. You *can’t* seperate the action of searching from the action of viewing a folder as thats how the latter is accomplished.

   I don’t care how it works internally. You want to present an easily-navigable, familiar interface. It may all be smoke and mirrors. That’s for the implementor to know, not for the user.

4. Maybe. (Hopefully.)

5. But your claim that this feature cant be useful IMO is not correct, I find it useful

   Just because you find it useful does not mean the fraction of users who will also find it useful is at all significant. In terms of usability, adding TMTOWTDI to an interface is a horrible idea because you’re forcing the user to make an irrelevant decision about which one of two ways to achieve the same result they should pick. (Hick’s law.)

   I suppose the dropdowns are useful if you’re showing messages from multiple folders. (See update.) So show them only on a search results page. (And no, I still don’t care that every view is a search result. Put a hidden is_search field in the search form and decide whether to show the dropdowns by its presence, if necessary.)

6. The script is unaware of the logic that controls the deletion and only knows the “state” of the record.

   Well then show a “deletion within:” column saying either “24 hrs” or “48 hrs“. The specifics aren’t important, just make things explicit in the interface instead of making users a) notice there are two different folders that seem to mean the same b) research and memorise what the difference is c) keep this in mind whenever they use the interface.

As for testy tone: I understand that it’s frustrating to get a load of criticism first thing when you release something you put a lot of work in. And I appreciate the features, I do. I think the work is cool so far.

I just want the shebang shuffled behind an interface that requires as little concentration as possible to use. The current one simply has too many orthogonal parts at once, so it requires a lot of headspace in order to be operated successfully, when there’s really no need for it to be so demanding, even if disarming it requires smoke and mirrors. You don’t need to lose the orthogonality, merely to avoid exposing all of it all the time. The user’s mental model need not match the implementation; you’re at leisure to deceive users in order to encourage a mental model where fewer parts are affected by the most common tasks.

I’ll see what I can do about patches.

Makeshifts last the longest.