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

Things implemented as "user settings" that don't need to go on User Settings or a similar page are less of a problem, that is, 'sticky' features that are user settings under the covers but are just configured by (de)selecting them on the page where they matter. Such avoid many of the problems of "too many user settings".

- tye        

I lost some of your conversation there. But I beleive that a list of folders on the left could actualy be links that apply the search. Does that make sense? Kind of like saved searches in a nice list on the left. So clicking on the archived list would perform a search for all archived functions.

BTW Right now I have a single message, and its almost impossible to find on the page. ;) Perhaps more spacing would help to seperate out the message from the rest.

On the combo-check box. I like the combos on the message because you can divided messages into different folders easily that way. I think folders should always be in a drop down because 50 folders in radio or checkboxs is impossible to deal with. ;) Just my two cents. Great job on the new inbox. Thanks for all your time and effort.


___________
Eric Hodges

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        

Yes, sorry, I meant “form” as in HTML <form> – ie., doing a search should be a separate action from moving things (in terms of the interface). The effect is that a click on what’s currently called Constrain would disregard any changes on the Send part of the page and vice versa.

Makeshifts last the longest.