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

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.

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.

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.

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.

I'm sorry. You really seem hung up on this "search" word. Which is obviously a symptom of a problem with how I've laid out the page. When you first visit the page its doing a search, more specifically a search for your message records that are in a given folder. And when you first visit the page its perfectly reasonable to expect that you might want to move all or most or some of those records to a specific folder. It seems to me that you want to force people to do this twice. I don't really understand why except that it seems to have to do with the word searching. Apparently you don't feel that "show all records in folder X" is searching and that we have to use a different term or something. I don't really get it. Would simply changing the word "Search" to "Show" make things more clear?

Just to clarify I expect a common usage pattern will be: 1. click on link in cb to go to inbox; 2. select a group of messages; 3. select a destination for them to go to; 4. submit.

Now that ive written that down I can see that since the destination will most likely be the deleted folder we should provide an easy way to shortcut to it. So mea-culpa there.

Another usage pattern i expect to see is: 1. click on link in cb to go to inbox; 2. go through visible nodes placing them in distinct destination folders. 3. submit. This is actually the usage pattern I wanted when I started this patch. I wanted to be able to search and sort into multiple folders because of my admin duties here. It can be difficult to keep track of messages to and from people on different subjects and I wanted a way to deal with that easily. Being able to "sort out my inbox into groups" is something that I want to do without having to submit for each group. It gets really annoying. So I guess its safe to say that that feature will stay in some form or another. Perhaps as a "sticky" setting.

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 asked people before, and I didn't really get much feedback of this sort. But I'll be the first to admit that this is hardly the slickest design. But the things I would have thought people would care about dont seem to have come up... :-)

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.

Ok, now im following you better. I think i can see what you mean. A list of links down the side with the different folder names in them and a reduced set of controls for dealing with them, at least by default. Or something like that.

BTW, since you might be patching this please try to remember: Not breaking private messages from existing clients is a very important point. Backwards compatibility with existing code is pretty well mandatory.

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.

No its cool. Now that your feedback is making sense to me I dont mind. :-) Some of your original comments still dont make sense to me entirely, probably because I'm too close to the implementation, but between this reply and tyes comments I'm getting an idea of what you think is wrong and needs to be changed, and thats great.

Ill say something as and aside about user options: I've seen that harmony on this site is only really had when there are a reasonable number of options available. Somebody always hates a feature that somebody else simply must have. When one of those people has the power to provide a patch, its hard and IMO unreasonable to say no.

Anyway, cheers, and i look forward to those patches. :-)

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

FYI, it is my guess that demerphq thought that you meant "different page" when you said "different form" (I certainly started out with that interpretation).

- tye