Just to highlighting some issues with the activity filters currently not so obvious due to the select menu UI:

Other things to look at here: Left hand side navigation/sub navigation, idea on splitting “core” functions and plugins with a divider/space for less clutter (don’t know if people visit many BP sites but this way they might get a feeling for what’s “standard” BP and additions/plugins. could scrap that idea though.)

Also feel activity should be chronological (as it currently is), not segmented by type (final wireframe above). Filtering lets you get it by type.

I’m sure there will be sites that might want the above layouts, but I don’t think they are right for a generic theme like a default one packaged with BP. Equally, I think it’s important that the BuddyPress core API becomes more theme neutral, and there is more encouragement to people to develop themes that are not children of BP-default.

@rogercoathup – one suggestion I have put forward and will be working on as a wireframe suggestion is the activity streams having a function you can set to display in different formats. This makes things easier from a ‘themeing’ view. I’ll be mocking up more over the weekend but that already was up on bpdevl.wordpress.com as a suggestion and I think where @nat0n was running on from by combining it with the menu view in other areas. http://bpdevel.wordpress.com/2012/08/16/ideas-on-theme-compatibility/#comment-5709

I don’t think the aim at all is to force any method to be the one you go with – we have to make things easy not harder.

Ok, excuse me while I get a few thoughts out, this could be a long post but want to cover a few things from your wireframes if that’s cool…

I don’t personally think a search for filtering works – a search for search yes.. filtering not so much. Really filtering usually has a predetermined set of things. Autocomplete isn’t usually used for filtering it’s for search and drilling down. Filtering in the context of this data set isn’t what autocomplete things are designed for. Now, if you are suggesting that it’s a search perhaps indicate that as it’s not clear to me unfortunately by the wording, icon and format you are using. I’m also wandering if that is auto complete as it has a filter button?

I don’t mind the separating into sections where plugins go personally as far as menu items go. It a little bit makes sense but also does cause issues if people want a more ‘merged’ view rather than a ‘us/them’ view which you are showing.

Having one load more doesn’t to me make too much sense if you have split the data types. A more ‘load more’ per section approach ala Basecamp probably is a more suitable loading mechanism for split data.

Interesting ideas though. I do prefer the menu but I also wander how that would adapt to narrower themes. Perhaps we can offer a ‘minimal’ view in that case maybe even with icons ala wordpress admin. Probably a bit of a left field idea though that.

I feel the titles then descriptions under is a bit of wasted space. I’d suggest a description by or under the title then a full width for the actual item. You’re just going a little too wide for my liking personally in some of your layouts. It works having the title and description just save some space a little rather than adding another column.

@hnla: I suppose you’re right. End users probably don’t want to know what’s in the “core package” and what’s not. The end result is what counts for them.

@modemlooper: Too many tabs, absolutely. Just wanted to show what the current situation actually is, albeit with the filter categories hidden in a select menu. I’ll get back to you all with more suggestions on how to solve this. This many tabs is not what anyone wants.

@karmatosed: You got me on many points I see The filter button should probably be hidden by javascript as to not cause clicking you don’t want when autoloading content. “Load more” can’t be used when filtering has been done, true, only when unfiltered (to view everything).

In summary, you could say that what I want to achieve is more connection between the navigation and the filters. The way they are named and laid out to day causes troubles that I wanted to solve by using more plain english and headers. I’ll try to come up with more ideas to clarify this way of thinking further.

I think this might be overkill for an average user of a social site. For a UX it’s bad to have so many options. The profile page needs to be stripped down to the most relevant info for that user. The directories is where “search” filtering would work better.

@modemlooper: Besides the location, what do you think about the changes per se? I agree what you say about the average user and if you suggest some of these choices should be removed from core I’d fully support that.

The problem with asking for feedback about default themes/settings is everyone wants to add when it should be about subtracting. The goal is not to provide fancy features, it should be about allowing for the most customization. And please, please don’t tell me vertical navigation is open for discussion.

@FIQ at the starting stage every opinion is valid. If you have any ideas on how you think things should be you are also welcome to add your opinion along with anyone else.

I in part agree with what you say about less options but it should be subtracted with analysis of if useful. I also think a dash of ‘blue sky’ thinking isn’t a harm to the process at all at this point.

This is pretty much the point that @johnjamesjacoby made in the trac ticket @djpaul has referenced:
“and we’d need to possibly deal with decoupling bp-default and the BuddyPress components, as right now they are almost purpose-built for each other.” Or, as anyone who does a lot of custom BP development finds — presentation elements that should be independent of the core API aren’t.

@djpaul I’m speaking kind of blunt because I believe you are smart enough not waste words. I don’t believe never is a valid term. I think it can always be done. Maybe not tomorrow, but I believe it should be a goal. With all the collective knowledge of BP developers I believe with the right motivation it not only can be possible it will be.

I guess ‘BP’ needs defining in this context. BP core does not or should not require any css it’s the app, there obviously will need to be a modicum of styles that ship with the template pack so injected bp functions render with a little clarity in whatever theme they are asked to present their elements in.

This clarity of separation of BP core from themeing is vital in this 1.7 phase.

However there appears to me still some confusion in what is being discussed here; templating or themeing, the group name is ‘bp-deafult’ this seems inappropriate going forward as this shouldn’t really be about a default theme, there, really, should be no default theme after 1.7 drops just a well conceived basic skeletal pack to build from in themes.

Lummy lots moved on in a different direction to the original post here

@hnla : This post was created to collect the wireframes for discussion. If there was the ability to create new groups I most certainly would have agreed starting a new BuddyPress UI one would have been more appropriate. However, unless I’m being blind there isn’t currently on this site (if there is great lets do that). In light of this – there needed to be a place where people’s wireframes could have a home and be discussed.

In saying about the group / post origins that isn’t aimed at distracting from the lively discussion here. Perhaps some of that could be highlighted with separate discussion threads to avoid it being lost deep on page 2 of a thread with a different title. Just my thoughts if it’s something people are passionate about.

@FIQ, @rogercoathup : If you do have any thoughts, discussion points to raise though it would be great for you to come along to the BuddyPress developer meeting this week on Wednesday at 19:00 UTC. It’s planned to talk through the wireframes during that meeting along with I am sure the theme process based on the latest trac. Be great to get both your input in that process as you have strong views.

Personally, I agree that as little CSS should be used but the fact is like it or not interfaces need a basic structure otherwise you are just creating things for developers. Note I said ‘basic’. But, currently the wireframes are about ‘possibilities’ and considering what could happen as a UI. Nothing is set, no dice have been cast.

Yes and initially that is exactly what it should be built for or at least the very bare minimum of styles in a skeletal template but even then given one doesn’t know what theme these template functions may apply to it can convey almost nothing by way of font size, colors backgrounds or even positioning as all these aspects are visual layout, and by virtue then fall into themeing which BP must now acknowledge and understand it plays no part in, this does mean though that in some senses things become a little harder for users, they can’t so easily have an out of the box styled theme as has been the case where bp-default was concerned but this now falls to themers to supply and hopefully a cadre of bp themers taking a bp-default theme forward to the next generation of purpose built BP themes.