I've changed the inbox to allow search and some other features. You now have the facility to have multiple archive folders, which you can name and organize. If you delete a message you can recover it up to 24-48 hours later. Hopefully its not too hard to figure out how it works.
I will say that I'm not super happy with the layout of the page. I'm open to suggestions but given my time availabilty these days patches are better (/me looks at pmdev). Cheers.
$world=~s/war/peace/g
Errk. Can the people who dont have a lot of PMs have a way to continue use the old interface? The new one is really confounding.
There are typically about 10 messages in mine, so I dont need search or any fancy folder stuff. But I delete messages often, and doing so now involves a combobox. I think its enough to select Move [selected] messages to [(deleted)] and then tick off messages? Not obvious, though.
Shouldnt General be called Inbox?
Choosing folders by twiddling the search stuff is confusing. When I moved a few messages into the Archives folder, I was momentarily puzzled at where they went and how I could get them back.
Sorry; the features are nice, I suppose (Id need a while to figure out all the things I can do now), but that interface is just horrible.
Makeshifts last the longest.
Every twenty four hours the trash bags are dumped. Then anything in the deleted folder is moved into the trash bag. This way you have at minimum twenty four hours to undelete, and at maximum 48. I could have called them "soon to be dumped" and "recently deleted" or something like that, or even not shown any difference to the user, but I didnt.
The other two issues ill look into, but you could just as easily post a patch. :-)
$world=~s/war/peace/g
Ok, I propose the following.
First, who is going to submit a search at the same time as theyre 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.
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.
The search stuff needs to be a completely separate from. Preferrably should go at the bottom, I think. Default the folder to (all), since thats 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.
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 theyre easier to reach when the user inevitably goes to refine his/her search.
-
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.
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 huge number of folders and frequently file many different messages into many different of these folders. I cant imagine that being such a large fraction of the userbase that its worth degrading the pages skimmability for everyone else.
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.
Makeshifts last the longest.
Default the folder to (all), since thats 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 didnt notice that because I didnt have any archived messages, so the link is just to Message Inbox and brings up the messages in General.
Makeshifts last the longest.
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:
- 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.
- 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.
- 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.
- Patches welcome.
- 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.
- 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?
$world=~s/war/peace/g
The combination is absolutely required.
No, its 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 cant combine the various parts then you have severly crippled the implementation.
Youre stuck thinking in terms of the implementation. I dont 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 dont know if you as the one who developed the code and interface can appreciate how confounding that form is for someone else. I dont think Im exactly stupid, but it took me 10 minutes of experimentation to twiddle all the knobs and understand whats going on. Way too complicated.
How do you plan to fit them all on one line.
I dont. 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 other than you will be doing. Burying this action in a combobox thats 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?
Im not aware of why you say Comboboxes are the least usable UI control by far; avoid whenever possible.
They require you to aim very precisely with the mouse; flagrant violation of Fitts law. They are awkward to operate with the keyboard. They are timeconsuming to grok with non-visual browsers.
All of these problems just vanish if you replaced the thing with two checkboxes.
You cant seperate the action of searching from the action of viewing a folder as thats how the latter is accomplished.
You dont seem to have grasped that I dont care how it works internally. You want to present an easily-navigable, familiar interface. I dont care if its all smoke and mirrors. Thats for the implementor to know, not for the user.
Maybe.
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 significant. In terms of usability, adding TMTOWTDI to an interface is a horrible idea because youre forcing the user to make an irrelevant decision about which one of two ways to achieve the same result they should pick.
I suppose the dropdowns are useful if youre showing messages from multiple folders. (See updated.) So show them only on a search results page. And no, I still dont 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 you really need them.
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 arent 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 appreciate the features, I do.
I just want them shuffled behind an interface that requires as little concentration as possible to use. The current one requires a lot of headspace in order to be operated successfully, and theres really no need for it to be so demanding, even if disarming it requires smoke and mirrors. The users mental model need not match the implementation; youre at leisure to deceive them in order to encourage a mental model where fewer parts are affected by the most common tasks.
Ill see what I can do about patches.
Makeshifts last the longest.
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 ie., doing a search should be a separate action from moving things (in terms of the interface). The effect is that a click on whats currently called Constrain would disregard any changes on the Send part of the page and vice versa.
Makeshifts last the longest.
No, its 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 dont 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 theres 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 its 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
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:
* ...
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
Ive done some tweaking of the UI for the inbox. I hope that some of your concerns are resolved now. Please post any patches to demerphq's sandpit, not to the inbox, as the sandpit is where they will get tested before they go to the inbox.
$world=~s/war/peace/g
That looks much nicer, though its not quite there yet IMHO.
Concerning patches: I thought Id poke and prod it on the dev server and post patches to the regular inbox once Im done. Not good?
Makeshifts last the longest.
If you could give me feedback on demerphq's sandpit id be obliged. If added a "simple mode" and changed the layout in a way that hopefully you will find more intuitive.
As for the pmdev server im not sure. Its possible that the code here will run there ok, is fairly out of synch right now.
$world=~s/war/peace/g
Echoing Aristotle's concerns, perhaps we should revisit the idea of a list of check boxes rather than the drop list for selecting the currently viewed "folders".
An objection to using check boxes was raised related to the editable nature of the folders and there was a nice compromise suggested, but I forget what it was. Did you archieve any of that discussion in some fashion?
DWIM is Perl's answer to Gödel