I built upon this, moved some tools and added a left hand side menu. Better? What works / don’t work?
To make it even denser, I opted out the avatar in the listing (also to avoid lots of extra http requests). I guess those could be added on hover (clue tip plugins or similar?) for desktop browsers if we wanted to.
We can’t mark a message as a favourite right now, and we won’t be changing this for 1.7.
Controversial idea: What about deprecating Notices, or not showing them in the Messages space in the template parts?
@djpaul: +1 to that. Feels more like a “site activity” thing, no? or somewhere else, outside of the “sending messages to people” area.
Combine @komatosed and @nat0n, parts of them: Use nat0n as the base but add pieces of komatosed. For example, the Reply, Favorite (not gonna happen soon), Show Thread, and Delete action icons could be placed in line right after the checkbox. I like the message form “appearing”. Also, to the left of the From field should be a checkbox to allow selection of all items in the current view.
And since “favoriting” won’t be in for 1.7, I thought I’d suggest the VIP functionality that Apple deployed in its most recent update of Mail. This will more than likely become a default expectation some time after 1.7. Hey, I can dream, can’t I? 
Notices should be a separate component not inside messages
@qrahaman: But isn’t “show thread” just the same as clicking on a message row? I’d like to have as few actions on each row as possible so maybe we could look at 1) what most people probably do most often and 2) what could be moved to a “view message/thread” context instead of this table view. E.g. I would think that Reply often comes after reading a message while Delete could come before (if unwanted or spammy content). How does that sound?
I’m going to take these ideas into a wireframe later so yes combining will happen @Qunit – good idea.
@nat0n : I feel a lot of your actions are split apart when could all be done ‘there’ in the actual message – seems a bit of a long journey up top then back to do things should be inline. Let me explore that later though. The do this with this feels a little too long form and stuck away from the ‘action’ so to speak.
If we can lets take out of having a menu too until that’s settled. It’s not fully set on that yet wireframe wise and be great to focus on the actual content here in these initial stages I think. For instance, the profile layout (messages if have profile wrapper would use that typically) is not actually the one we’re working on so that would change. Just want to get some focus on what is being worked on if that is ok?
@djpaul : I quite like idea of notices going from messages and perhaps going somewhere like the streams or some (dare I say it) admin bar notifications
@karmatosed: what “lot of actions”? I only have two – Mark as favorite (which won’t be there in 1.7) and Delete – same (or less) than yours. I also haven’t made a wireframe of the “actual message” – this is just a list view. I took inspiration from Gmail where actions are gathered on top and reading a message is separate from the listing. Most message readers do this and neither repeat tools for each row nor mix “browse mode” with “write mode”, which is what you get when doing too much stuff “inline”. I think it’s a very clear and nice distinction that I’d like to see in BP too. If it’s not on the radar for 1.7 then so be it – but one can hope, right?
@nat0n My issue as said is mainly with your splitting into ‘…with selected and actions’. Things need to be inline more. Let me do a mockup will explain things more.
I’ve built on a bit more – for now it shows notices in the navigation as working within the current boundaries of functionality for that menu (I have a suggestion in a different section for merging that).
I’ve done some notes on the wireframe to explain the functionality.
I am going to suggest the last in this thread is what we focus consideration on for a few days. Any feedback, points or wireframes that anyone wants to make based on this one would be welcome.
If inbox/sent/starred controls the message list view, those controls need to be above the message list.
The idea is that they are unless you click to send message then that box slides out and shows the form to send. Doesn’t have to be a box though just a revealing area.
What about the box slide open above?
This mixes buttons which provide functionality vs those which filter the current view (irrelevant of AJAX).
messaging doesn’t need (and shouldn’t have) AJAX / sliding panels etc.
That’s fine in the activity stream for short comments, but not appropriate to a messaging (essentially internal mailing) system. It just strikes as over-engineering in this case.
Take a look a the simple approach to messaging in Facebook (or the slightly more complex linkedIn) – or even current BuddyPress – which just needs a bit of tidying (and removing the public message’ option – whatever that is!), but otherwise is fine for messaging.
Wrt the user, I think it may be helpful to step back a bit. It’s not just comparing BP with FB and LinkedIn that should be considered. If the objective of the site administrator is to keep their members on their site for as long as possible, then providing them the tools to which they have grown accustomed should be done. From where I stand, a “message” is an email. It’s not a text which in it’s own defense has also become rather capable. Just as with any robust email application, it provides a set of tools to enable personalization and context: message formatting and file attachments (not Forwarding of PMs), to name just two.
These little details matter and because we pay attention to them, we will drive adoption of BuddyPress. I’m not saying that we don’t already pay attention to the details, but when the user starts advocating on BuddyPress’ behalf… “FB doesn’t do this, Drupal doesn’t do this, LinkedIn doesn’t do this…, etc,” then we change expectations and attract a whole bunch more resources to embolden the BuddyPress community. BuddyPress is solid. Let them catch up.
Didn’t Boone write a plugin for using tinymce on BP pages? Can we not use that or similar in “messaging/emailing”?
We seem to be drifting back to themeing and features, rather than the intended purpose of coming to an agreed notion of the best way to present basic BP content out of the box to any theme that tries to run and display bp content in default template files.
@rogercoathup: Erm Facebook requires scripting see this: https://skitch.com/karmatosed/e1t3i/1-messages. If we’re going with no scripting then Facebook isn’t something we should look at that has a layer.
I don’t think the current version is intuitive or not worth considering other options but perhaps no we shouldn’t rely on show / hide scripting – that point is fair enough.
You’ve lost me – yes, there are some basic dialogs popping up in facebook, if I’m on a profile and hit send message.
But, there aren’t sliding panels and ‘big’ AJAX features [edit: in messaging section - which is what you are templating here].
The more AJAX you put in, the more complex you make these default templates, the more difficult you will make it for anyone to reuse / adapt them in their themes.
For want of an another example – take a look at the template parts John Jacoby has created for bbPress (on which the whole BuddyPress approach is based) – they do a basic but complete job, and are reasonably simple to enhance (apart from a lack of documentation, and a somewhat confusing choice of names).
@qrahaman – if you want tinymce on a specific site – add it in your child theme – it’s trivial to implement using the new wp_editor function. For basic messaging, forum posts, activity stream entries though, it just hampers and complicates the UX.
@rogercoathup: Ah thought you were saying ‘no scripting’ hence my ‘but this is scripting’
I’ve removed the box and gone back to a simplified format:
@karmatosed,
Ship it.
One thought on nesting: Is there such a thing as “responsive” nesting? …meaning when the nested items get to a ridiculously small width, the group of “nests” re-adjusts to accommodate the originating width.
Will there be a forward function?
What about expand/contract?
