@henrywright thanks for that function. Should be helpful
@hnla haha fair enough 🙂
But… it’s also an inevitability that tables get removed from layouts as most web traffic moves to mobile and tables with a lot of columns don’t work on mobile. Might as well just accept that and implement it now.
@buddyboss no inevitability there. Check out many responsive table solutions http://css-tricks.com/responsive-data-table-roundup/
@mercime thanks for posting the link. Good stuff. My suggestion is based on the assumption that most WP themes do not have these solutions in them as most sites are not using tables. BuddyPress is feeding its content into theoretically any WP theme and most themes are (or will be) responsive and most web traffic is (or will be) mobile. So if BP is feeding in content that is not going to work for a large percent of users it seems like something worth at least considering to change, even if there are some tradeoffs.
Anyways, I’m sorry as I didn’t mean to hijack this thread with these table discussions. We’re a bit off topic now 🙂
1. Event integration would be great, including inviting people to an event and being able to mark as attending not attending etc for users.
2.More privacy options on public groups such as being able to stop them from showing in the activity stream altogether but still allowing people to join without requesting.
3.Option to turn on some form of automatic activity refresh (for those people who have dedicated servers with good resources)
4.Privacy in general, being able to set your profile to public private or friends only etc.
5.Notifications to show avatars.
– add collapsing of activity comment replies
– ability to manage notifications (notification bubble). turn off/on individual events AND mass delete and filtering of notification table located in your profile. Deleting one at a time is painful.
personally i like seeing the first few replies left in an activity comment, this decides if i want to keep reading further comments or not and may lead to me commenting on it myself. i think the show more option is better than having to click to expand the comments before reading any at all.
I would like to have a better control over xprofile fields creation.
Specially maxlength and is_numeric declaration avaible on the editor page.
Something like:
Add a new field (select field type) > single line textarea
Maxlength ? [] Numeric ? []
Filtering bp-get-xprofile-field-data for each custom field is not always pertinent IMO. 😉
Core performance is my number 1 wish. I’m not so bothered about new features with bells and whistles as these can be added easily via plugins.
@henrywright i agree with you on that definitely, but adding some functionality that some plugins offer as built into buddypress would also help because your adding less weight from these plugins too no?
@buddyboss no inevitability there. Check out many responsive table solutions http://css-tricks.com/responsive-data-table-roundup/
@mercime C’mon! Even Chris Coyier (the first ever to try making a table responsive and author of the article you have linked) himself admits that there is no good solution to make tables responsive. The article essentially lists a bunch of hacks that people have tried in order to somehow make the table layout somewhat work on small screens. Nobody cares that much for tablets (yet) but mobile screens are becoming more important every day. And tables are not suitable for mobile devices (there might be task-specific hacks, but there is no general-purpose solution). We can’t stay in denial about this for very long.
@mercime P.S. In the survey results you’ve posted http://mercime.github.io/buddyPress-2014-survey-results/index.html (awesome job by the way), when 62.31% people list Responsive and 41.33% list Responsive, mobile-first as their Preferred BP Theme Features, to which specific aspect do you think they are referring?
@henrywright i agree with you on that definitely, but adding some functionality that some plugins offer as built into buddypress would also help because your adding less weight from these plugins too no?
@mcpeanut I am probably the person that asks most often for stuff to be included in the core. However I beg to differ with you on this as a general principle.
I think you are right – if everything I need is in the core then the install will probably be faster than having a barebones core and 500 different plugins that I need to achieve the functionality I need. With you on that.
Problem is: everyone’s “needs” may be different. That’s why WordPress and BuddyPress are extensible systems. If there are 500 features in the core and I need only 50 and the core is slower because of that, then I would be one of the people complaining about “bloat”.
So, it’s essentially akin to drawing a line in the sand and hoping you get to the goldilocks area: a core that’s not so bare as to not be useful and not so bloated as to be inflexible or noticeably slow.
I think there are 3 (relatively) objective tests that the developers can employ when considering whether to include a feature in the core:
- Will the feature be useful for (or used by) a sizable majority (60%+) of users
e.g. media management capability
- Will the feature be used by only a significant minority (5%+) but is mission-critical for those who use it
Mission-critical is defined as a feature without which the whole premise of the site of community (that uses the feature) will fall apart. e.g. activity widgets, facebook likebox, Genesis connect etc are not mission-critical but multisite, multilingual and hierarchical groups are
- Do we need the feature for strategic reasons
i.e. for marketing, competitive or usability reasons, e.g. new user activation workflow revamp
Passing any one test should put the feature on the roadmap. If multiple tests are passed, it should be a priority.
Hey @mcpeanut
The same code as either a plugin or as part of core should weigh the exact same on a site. Plugins only slow down or bloat a site if they are written badly. In theory you could have 100 plugins running with not much noticeabe impact on performance. Then you could have one bad plugin that grinds your site to a halt.
And tables are not suitable for mobile devices
@sooskriszta Noted. But it can be done. If you look again at the BP survey results via mobile device, the table is responsive with some modifications made on Coyler’s code. Morever, as hnla mentioned in earlier post which I agree with, you do not change semantic markup to suit devices.
when 62.31% people list Responsive and 41.33% list Responsive, mobile-first as their Preferred BP Theme Features, to which specific aspect do you think they are referring?
Refers to whether the theme’s responsive styles (via CSS media queries or JS solution) were prepared for mobile viewing or for desktop viewing first.
@sooskriszta totally agree with you on your 3 (relatively) objective tests – this is why I suggested 2 key features that need to be improved in buddypress *immediately*:
1) spam fighting
2) fragment caching
First, 99.9% of buddypress communities have to deal with spam and it is mission critical (who wants a website overrun with spam? users leave, google rank drops, etc.). How many forum threads are opened again and again about people asking for help dealing with spam? how many different methods need to be cobbled together? it just makes sense to take the best practices and build them into the core.
Second, performance is an issue that is more and more important not only because speed is a do or die issue (there is ample evidence of a direct link between a website’s speed and its success in converting and in pageview counts)
with buddypress, regular caching plugins simply do not work, we need fragment caching, and we need it YESTERDAY!
there is already a tentative step in the right direction with rarst’s fragment cache plugin but this should be developed into a full solution and built into core.
everyone will benefit from improvements in caching and it will make a MASSIVE impact on the overall quality and success of buddypress as a platform
/drops mic
Automatic Activity Timeline update please (like Facebook)
