Ideas on theme compatibility
As mentioned in yesterday’s development chat, BuddyPress 1.7′s theme compatibility goal gives us the opportunity to review the existing BP-Default theme. The aim is to better understand what the main parts of the design are; what we like and what we should improve on. We’ll use this to help understand what should be in 1.7′s theme compatibility, and to use as a starting point to build wireframes and designs for 1.7.
From the BuddyPress.org post, ‘The Default Theme’, which was posted a few months ago:
In an undetermined future version of BuddyPress, we’re going to start bundling template parts along with features. These template parts are intended to be the canonical set of skeletal styling that BuddyPress provides out of the box. It has the benefit of being a turn-key installation for everyone, and allows us to push out updates more quickly and evolve the platform without worrying about how themes that are outside of our control might break. These templates will work with *any* existing standard WordPress theme without any modifications.
Just to clarify, the bits to consider aren’t the header or sidebar, they are as shown in this image: the main content area — the components. For instance: the activity stream, the groups directory, the member profile.
To kick off the review I’m going to pose a few questions and it would be great to find out what people think about those areas in the BP-Default theme.
- What do you like about those areas?
- What areas do you think don’t work?
- Are there any examples of things being done well that could be learnt from?
This is just the first talking point to get the ball rolling. As was discussed in the developer chat the next stages would be to work out the weak points and what can / should be kept. From there wireframes and designs will eventually happen.
As a side point, if you’ve ever wanted to get involved more in BuddyPress but didn’t because you are UI focused – now is the time to get involved.

Tammie Lister 1:01 pm on August 16, 2012 Permalink |
I’ll be self answering a little and kick this off hopefully with a few of my own thoughts:
1. What works / I like?
I think the activity stream is fairly solid in sense of layout – maybe the buttons aren’t that obvious right under though.
2. What areas do you think don’t work?
I think the ‘status’ posting could be more defined somehow and not sure about the placing.
I feel profiles are a rather ‘damp squid’ and could be far more break away from the same format. I do think members / groups and profiles should all look different enough that you know where you are by format not just design.
I would love to also see HTML5′ification of this as part of the process. Also a more semantic approach to naming and far cleaner CSS. We are going to have to use some CSS for this but having that easily pulled out and adjusted – with options to do that – is important. Therefore, we need a well commented, easy to navigation CSS file that is easy to dip in a change.
I’m not sold on options / menu bars being right – there are a lot of navigation then more under – it seems perhaps a too crowded option and somewhat clumsy.
Perhaps activity streams could become less bloated in layout they seem a little ‘fat on design’.
I think I would not like to see it go the way of lots of javascripting or other scripts for layout – that would be creating hurdles for designers when this should hopefully make things easier.
3. Any examples to learn from?
https://twitter.com/karmatosed profiles on Twitter are worth a look. Not perfect but a good starting point.
http://www.facebook.com/shift.ms?ref=hl for groups is really nice – I don’t like a ton of what Facebook do but for groups and timelines it’s nice. I’m not sold on activity becoming a timeline clone though.
https://medium.com/c/2a65aec3167b as a different way of displaying information is worth a look
I am keen though we look at things nobody has done and maybe do some out of box thinking here.
Paul Gibbs 1:23 pm on August 16, 2012 Permalink |
If the template parts use HTML5, we will end up embedding HTML5 markup inside someone’s HTML4 theme, and all hell will break loose; we’d have to put at least put in html5shiv. It’s worth discussing, but I’m a bit skeptical of how practical it would be.
Tammie Lister 1:34 pm on August 16, 2012 Permalink
Hmm valid and perhaps an indication of my HTML blinkers. I do think it has discussion legs but yes if we’re going for as ‘neutral’ as possible inside a theme good point. I do dream of a HTML5 world though
Hugo -hnla 4:19 pm on August 16, 2012 Permalink
If the template parts use HTML5, we will end up embedding HTML5 markup inside someone’s HTML4 theme, and all hell will break loose
while I understand what you’re saying this does rather smack of the old chestnut “we can’t do anything lest we break someone’s site”
mercime 2:30 am on August 18, 2012 Permalink
I agree. Do no harm, do it HTML4. Designers can then easily transform elements to HTML5 in their own themes.
Quint Rahaman 4:43 pm on August 18, 2012 Permalink
Paul, what you describe is a definite possibility. Still, “buyer beware”, is a more lean approach. With the utmost respect, @mercime, what is HTML4? Do you get my point? Saddling everyone with this HTML4; ie having to know it to then transform it to HTML5 guarantees that everyone has to make the “transformations”. On the other hand, if the client is made aware of the qualifications and prerequisites for the newest version of BuddyPress, then whatever that person chooses to do is their responsibility–they know the price ahead of time. Besides, they must test, test, test… test, then roll to production. My two cents…
Stas 1:16 pm on August 16, 2012 Permalink |
Since there are chances BuddyPress’s UI will get a facelift, I would suggest to add some generic UI styles so that plugin/component developers can leverage from, in case they are less good at design and want to keep the same UX for end-users.
Some resources to get inspired:
http://foundation.zurb.com/
http://twitter.github.com/bootstrap/ (meh)
Thanks a lot for starting to care about BuddyPress UI/UX, people will remember you!
Tammie Lister 1:44 pm on August 16, 2012 Permalink |
I don’t think some styles is a bad idea – my only caution would be to not use an existing framework as kind of over seeing yet another site use Twitter Bootstrap / Zurb (could just be me and I am coming to it as a designer not developer). I do worry about scope of this with the huge mountain of other things we’re doing.. but “more hands make light work”
It is cool to have some focus on UI and hopefully it will give people a chance to say what they feel about it and get involved.
Paul Gibbs 1:34 pm on August 16, 2012 Permalink |
Some stuff I dislike:
Boone Gorges 2:41 pm on August 16, 2012 Permalink |
I’m also not a fan of the two-layer nav bar structure in profiles and groups.
For the Commons In A Box project, we’re working on a nested nav that is, I think, a big improvement. For one, it goes back to the vertical item nav of the old BP theme. For another, it puts child links in a place that actually makes sense. Say you’re looking at the Activity section of my profile. The menu would look like this:
Profile
Activity
Personal
Mentions
Friends
Groups
Settings
etc
So, the two navs become one, in a logical way.
Boone Gorges 2:42 pm on August 16, 2012 Permalink |
Dang it, P2 wrecked my styling.
Profile Activity Personal Mentions Friends Groups Settings etcTammie Lister 3:10 pm on August 16, 2012 Permalink
As someone that just spent their afternoon wrestling damn menus ‘again’ +1 * lots for that.
Anton 10:03 pm on August 20, 2012 Permalink
I’d go so far as to join all personal stuff in one menu:
Account
– Notifications
– Public profile (with links to Edit and Delete account). Avatar, email and password can be found and changed on the Edit page directly.
The arguing goes like this: All areas but Edit, Change, Compose, Delete are non-verbs. Verbs tend to work best as action items, e.g. buttons, whereas tabs/areas are better called something you don’t believe will trigger any action directly. You just want to get somewhere.
Many of these “action” pages are also very short so a H2 between them on a slightly longer page, designed for editing/changing/deleting would take away some clicks, I think.
Anton 10:31 am on August 22, 2012 Permalink
To show what I mean above, see: https://twitter.com/nat0n/status/238221137421668352 and https://twitter.com/nat0n/status/238221229948014592
Tammie Lister 1:57 pm on August 22, 2012 Permalink
Eeep we went too deep into rabbit hole I can’t reply to your comment Anton
To be honest I’m not that keen on the combined it seems hard to use and move around. Perhaps it’s the fact it’s still in default and would be good to take into mockups though – I don’t think it in default is helping the look much. Worth pursuing in a wireframe I think with a focus on paths and priorities of content.
I do think we need a proper menu solution not just a mushing of content together onto less pages with the same menu. Yes, we can merge things but ultimately we need to tackle the menus somehow as smaller or larger – they are there.
Anton 7:49 pm on August 22, 2012 Permalink
> I’m not that keen on the combined it seems hard to use and move around.
OK, I just thought that putting seldom used items together could ensure other tabs/menu item/whatever we come up with, are more clearly visible.
As with the default look: You just have to imagine it’s Balsamiq
Hugo -hnla 4:11 pm on August 16, 2012 Permalink |
back to the vertical item nav of the old BP theme. For another, it puts child links in a place that actually makes sense
1. The notion and implementation of the object nav & sub nav as disparate and divorced elements always was a terrible thing causing issues with styling and logical flowed markup.
2. Vertical Vs. Horizontal: horizontal navs or tabs are fine when the number of possible items are known but become awkward to deal with when an unknown variable, whereas vertical navs have less of an issue in this respect.
Of the two points here #1 tends to be a fundamental issue of correct structuring and dom building while #2 is more a design/ theme issue and as such less of a factor in initial re-factoring for theme compat as #1 enables #2 to flourish and for frontend developers / themers to make a considered choice as to how they render the nav items free of the issues that plagued things before.
mercime 3:25 am on August 18, 2012 Permalink
** Allow for Vertical OR Horizontal Item nav **
Being able to adjust/tame item nav to taste per site requirements without twisting under and over with absolute positioning and the like so as not to make direct changes to the template was fun but wild. Let’s take the wildness away.
Tammie Lister 4:51 pm on August 20, 2012 Permalink |
Just putting into sketch format all the navigation stuff talked about here:
Also to second Mercime’s comment – this could lend itself to a function (of course a default would be needed to decide on).
Anton 9:04 pm on August 20, 2012 Permalink
Re: Sort alternatives hidden in a select menu – Could we display them all as links instead? Will plugins add items or can we be sure how many there will be?
Tammie Lister 9:22 pm on August 20, 2012 Permalink
We can’t be sure.. that’s the extra complexity.
modem looper 3:10 pm on August 16, 2012 Permalink |
I suggest the member header get moved to the left of content with nav structure as Boone points out. This will create a sidebar only on BP pages for adding extra custom content. As for design; keep it simple and somewhat generic. Let themes include extra styles for the BP elements
Hugo -hnla 4:15 pm on August 16, 2012 Permalink |
But this is less about themeing and more about allowing BP to be freely themed without let or hindrance – where a member header is placed is a design or frontend issue for the dev bringing a site together, what we need to focus on is how BP allows for templating and markup flow that suits the end sites requirements.
Quint Rahaman 4:37 pm on August 16, 2012 Permalink |
Speaking from a user standpoint, the following are my observations/suggestions:
1. The Horizontal tab structure is fine when the main menu items remain few. The problem is that their are too many, energetic developers out there who keep writing great BP plugins. If I activate as many as I would really want to, then visually, the user sees layered, horizontal tabs. My technical term for that outcome is, “Yuck!”
Option 1: Build some sort of horizontal tab scrolling capability.
Option 2: Attach some sort of disclosure triangle at the end that would reveal the remaining tabs (similar to what is done in Safari on the Bookmarks bar when the browser window size isn’t sufficient to display the entire bar).
Option 3: Allow the user to customize the layout of the tab structure through drag and drop, similar to how Folders are created on iOS.
Option 4: Forget the Horizontal tabs. Move to Vertical. The disadvantage here is the reduction in display real estate. So, how about a compromise? The WordPress dashboard appears “responsive”. I am specifically referring to the menu which reduces down to icons when the browser’s window size gets to some predetermined setting. So, how about this also be done for the BP menus but also add the ability for the user to manually contract and expand the menu?
Other suggestions:
1. No page refresh–similar to the site Tammie referenced in her earlier comment: medium.com
2. No resetting the page back to the top of the window when a menu item is selected.
That’s it for now.
Ray 6:14 pm on August 16, 2012 Permalink |
Some points I’d like to make.
1) Horizontal navbar: I agree with everyone that the horizontal navbar needs to be changed to a vertical navbar.
However, due to some theme’s content width, if we are planning to add a vertical navbar, we might want to consider making this a toggleable feature – eg. `apply_filters( ‘bpt_enable_navbar, true );`
This is so themes can disable the navbar if they wanted to and place it in their sidebar widget with a template tag.
2) bp-default sidebar: While we’re on the topic of sidebars, we should think about building a few widgets that ports some of the sidebar functionality from bp-default over.
login widget
forum tags widget (though we’re moving away from bundled bbPress)
notices widget (should probably drop support for notices in the sidebar; though I have some thoughts about notices in general, see next point)
3) Site-wide notices: IMO, this is a strong feature that is under-utlized in bp-default. We should think about making notices like the WP Toolbar. When a notice is turned on, add markup in ‘wp_footer’. CSS-wise, use `position:fixed` so the notice is prominent. I’ve implemented this myself in a few themes I’ve worked on.
4) Activity post form on profile page: I would like to get rid of the activity posting form from profile pages and perhaps use a toggleable button. Or at least, move it to an area that is more prominent when we revamp the layout.
5) Activity filter dropdown: The activity filter dropdown needs to be filterable and it needs to be a separate template tag. Right now, these options are hardcoded into the template.
I’d also like to take the opportunity to audit and consolidate what gets seen in this dropdown and also think about getting rid of the secondary activity navbar. The secondary activity navbar feels unnecessary when there’s a dropdown filter. While we’re revamping the dropdown filter, we could also take time to ensure that it isn’t tied to the activity “type” column. Then, we could port some of these navbar items into the dropdown filter.
6) Buttons: bp-default was okay for buttons when no plugins were added to the mix. However, when plugins did add buttons, this cluttered up the UI. We should think about consolidating all buttons in the profile and profile loop into some form of dropdown.
7) Rethink certain layouts and functionality: This is kind of a catch-all item for some UI stuff.
a) PM inbox styling – while functional in bp-default, this often looked clunky in themes with a limited width. Maybe take this opportunity to change the inbox / sent loop entirely?
b) “Notify group members of changes via email” – this item doesn’t really do anything useful. We should probably remove this
c) Group admin members screen – perhaps move this functionality into the main group members screen?
8) HTML5: I’d like to introduce the required attribute for any input validation. This will not break any existing themes. Though, you could argue that HTML5′s required validation looks kinda ugly and the styling varies from browser to browser. I can live without this, but thought it might be neat to get frontend validation for free
Phew! That was longer than I intended! Let me know what you guys (‘n gals) think and thanks for reading!
Tammie Lister 9:04 pm on August 16, 2012 Permalink |
Assuming I’ve got the right end of the stick about widgets that is an interesting idea… so rather than have those in the actual theme you’d pop into widgets. I do worry about putting too much directly in code but add to that if it can be done like the way WordPress comments are (so maybe not widget) then great. I’d use the comment form as an example of that.
Hugo -hnla 9:31 pm on August 16, 2012 Permalink |
Think most of these points are valid, why `apply_filters( ‘bpt_enable_navbar, true ) to manage the style of something rather than simply passing a param to function?
A lot of what is being discussed thus far on the thread is about themeing issues while most valid do we not need to focus specifically on unlinking BP from theme how things are displayed and where must simply be a user/dev choice.
Nothing wrong about using html5 atts after all it’s mainly those that are gained through html5, they degrade pretty well in browsers not understanding them and where not there’s simple scripting to smooth things over.
Paul Gibbs 9:50 pm on August 16, 2012 Permalink |
In case people don’t know, all templates in bbPress therefore the theme compat., can be embedded with shortcodes. For example: http://testbp.org/2011/08/18/forum-shortcode-as-comments/
And the actual widgets run an appropriate short code. So if we built a “log in form” widget, it’d be a template part, and even if we didn’t want that template used in the “default” theme compatibility , it’d be trivial for someone to use it in their theme.
Tammie Lister 10:19 am on August 17, 2012 Permalink
Ok so what would be needed is a documentation push on listing shortcodes then along with that. Cool.
Quint Rahaman 7:01 pm on August 16, 2012 Permalink |
The following would apply if Group admins were able to apply categories to their Group.
From a user’s standpoint, I would prefer not having to scroll through what could be an enormously long list of groups to find the right one or the right set. Providing the user with an interface where they could fine tune their Group search and then be able to save those search results into its own listing… I guess, a directory of favorite group searches would work. Also, any group could be added to or deleted from any search list at any time. This list could also act as one of the filter options for the Activity Feed.
So, example categories for a “sports” BP site: competitions, collegiate competitions, amateur competitions, professional competitions, high school competitions, tennis, football, soccer, ping pong, country, curling, etc. For a global BP site, a user could spend an enormous amount of time trying to find their groups and grouping given the present setup. Plus, the user probably wouldn’t want to churn through the activity for all of the Groups that he/she follows but rather a filtered list of groups by way of a “set” of groups. Hopefully, this makes sense.
The above would also apply to Members.
Coming in BuddyPress 1.7: Compatibility for ALL WordPress Themes - WPMU.org 10:34 pm on August 16, 2012 Permalink |
[...] for the community to review the existing BP-Default theme. Tammie Lister has fired up this discussion on the BP Development blog. You’re invited to jump in and review the existing BP-Default [...]
Selu VEga 1:00 am on August 17, 2012 Permalink |
Well, I have been playing around buddypress a lot lately, Im getting big projects here on Spain and with my limited english I will try to explain my feelings about features that could make better BP for anyone.
GROUPS AVATARS: The square avatar for groups is so limited, old fashioned. The real deal should be totally editable width and height by admin, I mean about to be able to give different sizes like extended buddypress plugin gives but more, because any project can be different, It can takes by default 100% of width avaliable and the user will shorter or larger depending of theme used and if sidebar are used.
PROFILE GROUP AND USER SCREEN, DEFAULT SIDEBARS: That its really needed, admin can choose if will use own created ones, or default buddypress sidebar, left or right positioned, like the user wants, should be editable on widget area. Gives power by default, and its giving the opportunity to non expert users to embrace easily the communitty experience.
USER PROFILE: A collapsible menu|nav sidebar including avatar, account menu and navigation would make users focus on activity and not on too many choices to distract his attention to the story. On the default sidebar you must see your stats, your friends, your groups and latest answer on forums.
Obviously, he should have the opportunitty to share something from anywhere on the profile screen but the settings one.
GROUP: By default, if a group Its open, for me its equally important the activity of that group as users that belong to them to join in. Dont know exactly how, but I would show users from the splash screen probably as the last activities on the same time. Also the same collapsible sidebar for navigation and settings its quite needed.
NO MORE FILTER DROPDOWN, AUTOCOMPLETE ITS THE KING: Quite difficult when you have more than 50 groups to select proper one, autocomplete filters are much better. When start to sharing, just can appear group activity button and writting the name from the group, you see all the matches and select the proper ones.
ORDERING ACTIVITY BY CATEGORYS OR HASHTAG AND NAVIGATING LIKE A BOOK: ThIs is a improvement more than style suggestion, but is on my mind from the last 3 years and nobody else did it. What if I could navigate my activity stream giving categories or hashtags. ¿What is unique of this? I believe it could be so fun if I could navigate through those tags moving from different activities categories or hashtags like I flip a page on an book, just loading all the next or previous activities related to my order, so I could have my interests order as I want. Very useful for curated content networks. (im developing a rare delicious clone but based on Buddypress, its quite fun to do it) http://pruebas.circulosur.com (just trying).
MESSAGES: Why don’t try to make something like whatsapp on a buddypress way? I mean, the conversations should have differents levels, my chat box and my friend or friends chat boxes should have not only different colors but one float left and other float right.
Another thought: Why dont deliver a grid style just in case a full width page is choosen, its proved that its the present future of UI, its more visual, and everyone its trying to organize activities in a more visual and big screen (retina display) oriented.
Anyway, if something its not understable enough and are interested, just ask!
Sorry again for my english and long life to Buddypress.
Selu Vega
Anton 11:31 pm on August 19, 2012 Permalink |
I tried your idea of flexible group avatars and they could work out nice, with some small modifications (see screen dump at https://twitter.com/nat0n/status/237329669442134016). The goal of the edits was to not affect 150x150px avatars design-wise, just to enable 100% width too.
There I also played with having a column version of the item-nav/item-body with an (as for now) unstyled item-list-tabs (which can’t be called ‘-tabs’ in that specific place btw). Hope you like it!
Selu VEga 11:54 pm on August 19, 2012 Permalink
Cool, with some work and letting admins choose the width of the avatar could be so useful and actually can really met the needs of practically all themes posibilities!
The bar collapsible, should work really well! Thanks for the effort!
karmatosed 2:17 pm on August 20, 2012 Permalink
These are cool. I would like to maybe suggest we step away from the default theme and move into wireframes though purely to try and separate theme away. Please, though if you don’t feel that’s right say it’s merely a suggestion. I do feel a lot of this is falling into the theme side not something initially maybe that falls under theme compatibility. We have to be careful of that pitfall.
Avatars for instance I’d tentatively suggest should be set only in the theme – rounded, full width.. whatever it kind of makes sense being theme stated. For instance, I frequently adjust this myself and come to think of it can’t think of a theme I haven’t done that in lately. CSS can do this relatively painlessly.
We should consider a ‘default’ perhaps but as has been stated in earlier comments having the option of changing ‘to taste’ is important. I think that’s a big takeaway from these comments for me. Personally, way I’m trying to think of this is like an ‘untheme’ – probably needs a better description
All that said I don’t want to distract from what you did, it is really cool to look at though and I’m not taking away from that in my suggestion towards a less ‘themecentric’ mindset. I added your screenshot to the Google Doc for referencing ease.
My worry with a column as you have there is it expects a wider theme – perhaps we need to not think in terms of columns / layout but more in terms of positioning.
Quint Rahaman 3:53 pm on August 20, 2012 Permalink
Anton,
Thanks taking the time to put the example together. This is the first time that I’ve seen a rendering of the BP navigation items in a column format. I haven’t paged through all of the sites on bpinspire.com but of those that I have, I have yet to see a site implement BuddyPress in this style. I maintain it’s a necessary option for the Site Admin to implement through the Dashboard. However, as I’ve mentioned somewhere on this post, the ability for the Admin to easily group BP menu items is an essential function. If not, given the sheer number of BP plugins, what you’ve shown could become a long list of menu items that would look similar to the Member or Group directory. The user would not be happy. Of course, if the “grouping/nesting” of menu items were an option, then either vertical and horizontal “tab” styles could be implemented.
rachelbaker 1:51 pm on August 17, 2012 Permalink |
I have always found the different “stream” areas: Activity, Group, Topics, etc. hard to follow. I really like the approach 37Signals takes with the BaseCamp discussions: http://cl.ly/image/0F1o3R1t2W2Y
There is lots of information that is easily segmented (and the content is similar to what we have now: http://cl.ly/image/131p2m1Z2r3Y)
Anton 7:57 pm on August 19, 2012 Permalink |
Agree! I can see where the activity stream approach comes from (Twitter) but what I think would benefit many BP sites is the 37Signals way with separate lists for forum posts, new groups and activity/status updates.
Tammie Lister 8:11 pm on August 19, 2012 Permalink |
I really love this idea. I’d love it as the default one. My only hiccup could be those people that do want the merged view. Perhaps this is a case for adding a series of ‘views’ that can be called on in the template. I’m not just talking filtering just something like:
activity_stream_type(merged), activity_stream_type(split)
Tammie Lister 4:30 pm on August 20, 2012 Permalink |
Based on this I’ve come up with the following mockup. It has a number of things discussed merged into one wireframe. On purpose it has no styling this is purely sketching.
1 : Could have actiions under this
2. Actions can have function to display as drop down or buttons:
stream_entry_actions(buttons)
stream_entry_actions(dropdown)
3. The stream itself can be called to display differently
stream_display(merged)
stream_display(filterable)
4. This will show /hide more script style
*function names as suggestion
Quint Rahaman 4:50 pm on August 20, 2012 Permalink
When laid out like this, it brings to mind tributaries merging into the stream. With that in mind, one should be able to style the tributaries, and interact with each without having to leave the main stream (or the page). Not every user would care about each tributary, so, providing the user with visibility settings would be great.
Anton 9:15 pm on August 20, 2012 Permalink
I like it being more separated, much more clean than blended. I guess I’d propose three ways:
1) Mixed, as it is now
2) Separated (what goes at the top though? we decide? or theme designers?)
3) One at a time, with tabs as filters (Updates as default maybe)
Quint Rahaman 3:35 pm on August 22, 2012 Permalink
Here’s an example of an enterprise social networking site… just for kicks.
http://www.tibbr.com/features.html
Tammie Lister 8:08 pm on August 19, 2012 Permalink |
I’m collating this all into a Google Spreadsheet to start off with to try and get some points from what is being said: https://docs.google.com/spreadsheet/ccc?key=0Al8bavYmIsGNdE5FdTZ5ZWhSeEhCbkpvMUtEZ2w4VVE#gid=0 – this will be a work in progress though so just doing to try and get the ‘lay of the ground’. It’s editable to all.
I have split into some ‘Types’. ‘Enhancement’ is where reviews of existing UI lies, ‘Feature’ is new additions / functionality and ‘Theme’ is where whilst valid it probably falls more into something themes should be doing with the new theme compatibility. ‘Discussion’ is where the debate wasn’t as clear cut and probably needs some separate review.
If anyone thinks I’ve not translated anything into that enough please speak up – I think I’ve caught most things though.
Tammie Lister 2:35 pm on August 20, 2012 Permalink |
In light of the feedback it’s become also clear what areas currently are maybe a bit too fixed or need to make sure are not fixed and truly ‘theme independent’. As a result I’m going to make a list here:
https://docs.google.com/spreadsheet/ccc?key=0Al8bavYmIsGNdHVuMXNOWXBFRGQ4UnNJOXFNbU1lMnc
It’s open like the above document for anyone to add to.
I’d tentatively suggest this could be a useful one for the UI styles task if that does happen. That aside though, hopefully it will act as a focus as to what is a problem now or needs to be made sure isn’t one.
Roger Coathup 10:29 pm on August 23, 2012 Permalink |
Are you planning to release this theme under the name: bp-default?
If so, anybody who’s got a pre-existing site built as a child of bp-default, will see their site radically changed if they upgrade BuddyPress.
It would be much more sensible to release this under a different name, so not breaking the look and feel of existing sites.
This is what WordPress do… if they change the ‘default’ theme that ships with WP, they change the name… default, kubrick, 2010, 2011.
In the case of BP, you might want to package two themes with each release — one that continues to morph with every release (as bp-default has done to date), and one that people can safely use and know will stay fixed (so, not breaking the layout / look / feel) of the sites they’ve built if they upgrade the core.
Tammie Lister 10:55 pm on August 23, 2012 Permalink
It’s not a theme, this would be the default format if no theme is activated that has styling. From, what I recall keeping BP Default there was always a plan as a fall back for users.
That said though, the days of requiring a theme to get BuddyPress working are going in 1.7. Themes will become extras and custom work not essential for it to work.
Paul Gibbs 6:02 am on August 24, 2012 Permalink
Right, all this stuff is not a WordPress theme.
Get involved in this weeks dev chat « BuddyPress Development Updates 8:15 pm on August 20, 2012 Permalink |
[...] Comments Tammie Lister on Ideas on theme compatibil…Quint Rahaman on Ideas on theme compatibil…Tammie Lister on Ideas on [...]