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.
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?
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.
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.
Maybe. (Hopefully.)
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.)
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.
In reply to Re^5: Searchable Inbox
by Aristotle
in thread Searchable Inbox
by demerphq
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |