Activity Favorites: alternative management & new features

[imath]

I really like the "Favorite" activity feature, it helps "bookmarking" the activities that we are interested in.
But i think as this bp.org forum suggested, this feature would be even more powerful if we were able to have some complementary infos about favorites :

• an easy way to figure out who favorited my activities or other members activities.
• the amount of time an activity has been favorited by community members.
• a new filter to list all favorited activities so that we have some way of "highlighting" the activities the community find interesting.

So i've been working on a patch to include these suggested features. To achieve it, i've made some change in the way favorites are managed:

1. Use bp_activity_add_meta to store favorited instead of the 'bp_favorite_activities' user_meta.

Thanks to this function introduced in 2.0, it's now possible to add as much as user ids for a meta_key and an activity_id, so i moved the user meta into an activity meta 'user_favorites'. One of the advantage is that the "favorite count bug" if a favorited activity is deleted does not exist anymore (See #4327, #3794)

2. Use of an activity meta query to get user's favorites (compare => '=', value => user_id) or all users favorites (compare => 'exists')

3. Adapt the UI to include a nav to toggle comments / favorites for each activity, see following screenshots ;)

If an activity hasn't been favorited yet, the favorites tab is not showing. By Default the "Replies" tab is active, to see the favorites, user needs to click on the corresponding tab

When the favorites tab is active, the user avatars who favorited the activity are listed.

I haven't build the eventual upgrate routine yet, and this first patch surely need some improvements. What is your opinion about it ?

[boonebgorges]

Cool idea. I definitely agree that this kind of functionality is sorely missing from activity favorites.

My most serious concern is about scaling. Say you have a site with 1000 users. It's not too hard to imagine your activity table having 1,000,000 rows after some use. Then let's say people start using activity favoriting fairly regularly (especially since it'd become so much more useful). It's easy to imagine tens or hundreds of thousands of rows being added to activitymeta. The nature of the activitymeta table (and meta_query in general) means that queries against the data are going to be very slow (especially the = query). Multiply by 20 within a single activity query loop. And this is on a relatively small site with fairly modest numbers.

Activity favorites are many-to-many relationships, and are ideally best represented with a proper relationship table. The schema would be something like:

id bigint(20) AUTO_INCREMENT PRIMARY KEY,
activity_id bigint(20),
user_id bigint(20)

with indexes on each column (and maybe a date column too).

Before moving forward too much with your suggestion, I'd like to see some real data. imath, maybe you can write a new command for ​https://github.com/boonebgorges/wp-cli-buddypress/ for generating activity favorites. Then, generate a ton of data on your proposed schema. Then, whip up a table like I'm suggesting and generate a ton of data on *that* schema. Then, run some numbers to see what the differences are like at scale for the various kinds of queries that you'll be running. I have a feeling the differences are going to be very significant - especially as the activitymeta table gets larger (think about the extra stuff we're storing in there these days - 'post_title', etc).

[imath]

Replying to boonebgorges:

Cool idea. I definitely agree that this kind of functionality is sorely missing from activity favorites.
... I have a feeling the differences are going to be very significant

I've compared the two schemas : you were right, using a new table for favorites is globally better, we gain an average of 45% in query performances.

There are 2 contexts where it's not the case, but numbers are really close. The gain can be up to 66% when adding a favorite.

You can see the detail of my tests on this ​gdoc excel sheet
I wanted to have more than 1 favorite for each activity, this explains the choices i've made on the data generated (100 users, 2300 activities & 13400 favorites)

As i compared all the features, i kept on building an upgrade routine for this new table, just in case. So 5644.bp_activity_favorites_table.patch is using this schema. I think it can be improved again for the 'add favorite' & 'remove favorite' as we could do a

SELECT activity_id WHERE activity_id = [to_favorite] AND user_id = [bp_loggedin_user_id()]

to check if the 'to favorite' activity is already favorited instead of getting all the favorites to see if the one to favorite is in the array or not. Maybe some caching could also be done at some places.

I'm also attaching to this ticket the wp-cli command (5644.wp-cli-bp.diff) i've used so that you can check if i did right ;)
NB: to make the command run you'll need to comment the is_user_logged_in() check that the function bp_activity_add_user_favorite() is doing.

I really think it could be a nice feature ;)

[karmatosed]

I brought this up in the dev chat and will do my best to summarise my points here a little more cohesively.

I think this is a great feature, but I think it adds complication to a feature that means 2 things already. Favouriting has come to mean 2 things and we who use networks kind of assume this is accepted behaviour. This is a bad assumption and one that leads to confusion in new users and even sometimes ourselves.

A good example is when someone favourites on Twitter. Do they like what you said? Do they want to save it for later as it’s a great link? Or is that both? I know I make that assumption usually based on who does it. This user I know uses it as a +1, this one I know is just saving it. How is this a good UX? We can't assume behaviour based on our assumptions.

I agree that we should where possible use the conventions of networks. But, should we be bound to them so much that we take on their confusion? Just because Twitter jumped off a cliff should we, would we? :)

In an ideal world I would propose we consider a bookmarking system and like system.

Bookmarking: saving for later and categorising
Liking: +1, good job!

I think if we assume that favourites are always used for bookmarking we’re jumping to an assumption we shouldn’t with the UX.

I really like the idea of bookmarking, of categorising those. I also know that having this and a like system is something a lot of communities are calling out for.

Sorry to throw a bit of a spanner but I think it’s worth considering the UX a bit on this one. That way we can have something that does all this awesome functionality, doesn’t confuse and simply rocks.

[johnjamesjacoby]

Tammy is correct that bookmarks are definitely not what likes are for, at least not anymore. Likes are basically a drive-by non-committal comment; a way to say "I support this thing, but not enough to type any words." It's the difference between a friendly nod and saying "Hello".

Imath - can you spend some time making some new activity stream actions for the liking process? So that when a member likes an activity stream item, it also creates a new activity stream item saying: "John liked: 'Whatever the thing is' that lives in this place."

Does that make sense?

[hnla]

I agree with Karmatosed reading through that summary - and with jjj 'likes' are somewhat ephemeral non committal tags not used to generate a list, where a list is generated one would assume to use 'Bookmark' or 'Favourite', I do see 'favourite' & 'bookmark' as semantically interchangeable though, maybe that's wrong!

[ubernaut]

i think that bookmarking is a much more confusing concept to users than liking and just because you can use a thing in a certain way doesn't mean you have to.

if we are talking about adding a feature to categorize/bookmark things that isn't covered by what liking does now i think we are actually adding a lot more complexity to what is now a fairly standardized UX convention.

Not to say i disagree that it might be beneficial to have a discreet booking/categorizing system apart from liking, but that if we add a lot of new different ways to do a very basic thing which favoriting already does in a well understood and intuitive way it may backfire and nobody will bother using it.

[johnjamesjacoby]

I had not considered the difference between "favorite" and "like" but I do agree that it's important to distinguish. They are two different functionalities with separate goals, IMO.

• Favorites: "This conversation is worth coming back to, and I might Unfavorite it later"
• Likes: "I may never come back to this again, but I do support it right now"

Perhaps we keep favorites what they are today, and experiment with bolting on a more passive "Likes" functionality like I eluded to above, still shepherded by Imath in this ticket (since there's so much good discussion here.)

[boonebgorges]

I think the word "Favorite" is a big part of the problem. It's ambiguous between "bookmarks" and "likes".

While I personally kinda like the ambiguity of the feature (I think it's part of what makes the feature interesting on Twitter as well) I can see the argument for making it clearer in BuddyPress.

If we're going to try to sharpen the focus of the feature's UX, we should keep a couple things in mind:

1. There are already many sites using Favorites, and we don't want to introduce changes that would alter that experience in harmful ways. For example: displaying a list of those users who have favorited an item within the context of the activity stream may cause some discord for users who have been using Favorites for a semi-private bookmarking system. So we should consider these kinds of changes carefully.

2. There are certain kinds of communities that will want to use something like Likes, and certain communities that will want to use something like Bookmarks. If we're going to push Favoriting in one of these two directions, we should try to pick the direction based on what will best serve the largest possible percentage of BP installations. Alternatively (or in addition), when choosing which direction to push Favorites, we might think about building a maximal feature set that can be pared down, rather than the other way around. For instance, a Like feature would probably show a list of users who have liked within the activity stream, while a Bookmark feature would not. In this case, we may want to build this feature in by default, and then make it easy to shut it off. Likewise: it makes sense for there to be a public user tab "Likes", but maybe not a public "Bookmark" tab; so it make make sense to build the feature and make it easy to turn off. I guess what I'm saying is that maybe it makes sense to err on the side of Like, and then build in the necessary filters to allow site admins to turn it more into private bookmarks if they'd prefer.

[imath]

First, thank you all for your great comments. I'm sorry for my late reply, i've needed to put my brain together ;)

I understand your concerns about the potential ambiguity between "favorite" and "like". In France favorite == "préférée, c'est à dire celle qu'on aime le plus" => the one we like the most. So maybe it's the reason i don't have the same concern. And BuddyPress is using "favorite" not "bookmark".. So to me it's really close to "Like" but the advantage is that the term is not the Facebook one..

That said, when i've built this patch my first concern was to find a way to "highlight" the activity a new user should check when discovering his BuddyPress powered community. My mistake in the description of this ticket was to put it at the 3rd place.

I use BuddyPress in a corporate world and for "workmates" they need to easily find what are the updates to check to go straight to what's interesting. There's a lot of thing into the activity stream, so i thought having a way to filter it to only get the activity members marked as "préférées" would help them to engage and make contacts with other mates. Because there's a good chance that if my co-worker found something interesting, i would also find it interesting.

as JJJ said, we could create a "like" activity_type and leave favorite the way it is:

• the content would be an action saying "imath liked JJJ's update" with a link to parent activity to discover the content liked
• the only little annoying thing (blame me!) would be that activity heartbeat will load this new activity on top of activity stream..
• i guess people would want to have a counter on the parent activity to see how much the activity was liked and as boonebgorges said to know who liked the activity
• filtering 'activity_likes' type would list "mini" activities

Of course we could replace what i've done for Favorites in favor of Likes, this would probably introduce a new template in member's profile page..

i think i really "like" boonebgorges option 2 : if i understand well it would require to build some options or filters to let the admin customize the "favorite" term/slugs... but most important will let them choose the behavior they want between Like or Bookmark

I think the show_hidden is respected in my patch as i don't list user_favorites in the stream but attach them to the parent activity, just like comments. So i think privacy is not altered.

I agree with what we've talked about in dev chat. If we are to create a table it should be an "interactions" table so that we could eventually use it for other stuff such as mentions, "favorite".. and maybe plugins could add some more interactions type... And maybe it could be interesting to have in members profile page an interaction subnav using the drop down filter to list the mentions or the favorites or likes... (instead of the mentions & favorites subnav)

Finally i'm not a fan of the term "Like", reminds me too much a social media..

[imath]

In 5644.activity_table.patch, I've tried to take in account the most of your feedbacks.

1/ The community administrator has the choice

He can choose from the BuddyPress settings wether to leave activated the "like" feature for "BuddyPress Favorites" or to use them as "private bookmarks"

I guess this will need some better explanation, i'm not satisfied of my "Use favorites as a like feature"...

2/ Favorites / Likes are specific activities

In this patch i've explored a new way (i think boonebgorges suggested it in last dev-chat) of storing the favorites by using the activity table. I've updated the ​gdoc excel sheet where i now compare the 3 options (activity meta / specific table / activity table). Using the activity table seem to be less performant than using a specific table but it's still a lot better than using the activity meta. Moreover i think my patch can be improve by some object caching at key places.
Thanks to the fact that action strings are generated at run time since 2.0, whether "likes" or "bookmarks" are on the action of the activity is automatically the good one.

3/ Favorites as Likes

I've tried to take in account theme backcompat in this patch. So it should work in most themes using the BP Theme Compat feature. I've only had an issue with the hook bp_activity_entry_meta which is after the 'delete activity' link. So i moved it up and created the bp_activity_after_delete_button_entry_meta hook. Meaning the count are staying in buttons (my first patches was using 'interaction navs').

Using the drop down filter 'Likes' will list all activities that have been liked by at least one user, the order is the one the parent activity date. (As Activity heartbeat i was afraid to change this..). If the administrator chooses a 'stream' mode to display comments, the 'like' activities will show. The time since link is the one of the parent. As stream mode is on in Activity Administration, here's a new screenshot illustrating this point :

Clicking on "View Activity" will show the "Liked activity".

A like is only "deletable" from the Activity Administration.

It's possible to view the likes made by a user on his profile. Nav / Directory tab names, strings, slug of the favorites are customizable using a filter if the user (for instance me!! doesn't like the "like" term).

4/ Favorites as Private bookmarks

If this setting is on, the users who favorited the activity won't show in activity stream. The "favorites" user's profile nav will only be viewable by the user himself or the admin. Other than that, it behaves the same way than before. The administrator will be able to manage users favorites by choosing to filter activities on the 'activity_favorite' type

I hope i'm close to your ideas about this feature. Waiting for your new feedbacks about it.

[ubernaut]

looks interesting imath although i will say I'm more confused about what the like/favorite is supposed to do than ever at this point :/

apropos of this whole discussion was this most recent edition of tldr which is all about likes if you have 8 minutes to spare id say its probably worth a listen:

​http://www.onthemedia.org/story/26-drake-likes/

[karmatosed]

I was late to the dev chat so apologies if going over ground already covered. Also sorry if this is overly simplistic feedback, trying to dip my toe back in reading back over this.

For me 'use favourites as likes' is crippling UI. We should never have an option to use something as another thing. Even if for backwards compat.

Same goes with 'using favourites as' - this is also confusing. Maybe this is a simple privacy option though. Hide favourites and it becomes private. Lets not add the bookmark term.

I am fairly sure we can work out a UX that splits it and avoids the complications of options.

If what I've said is more problem than solution, I am happy to jump into dev one day and put Sketch where my mouth is with some mockup help :)

[imath]

Replying to karmatosed:

I am fairly sure we can work out a UX that splits it and avoids the complications of options.

Thanks a lot for your feedback karmatosed. Well i've built the patch, trying to "mix" jjj & boonebgorges latest comments. The patch is an alternative, admin can choose the behavior of the favorite feature.

I wonder if admins would like to have the 2 behaviors at the same time : being able to bookmark and like. If so, i guess it's a bp-like component story and no more a ticket to try to enhance the favorite feature (and to avoid inconsistency troubles in favorite count when an activity favorited is deleted).

But your mockups are of course very welcome ;)

[boonebgorges]

I think "crippling UI" might be overstating it a bit, but I do agree with karmatosed's general thoughts here. Let's get clear on what we're building, and then build it to do that thing really well; then, we can build in filters and whatnot so that people can make it do something else.

My personal feeling is that, in the spirit of all the other open-by-default parts of BuddyPress, we should think of favorites as likes. Build everything as public. I also think that this will probably suit a greater percentage of sites better than the private bookmarking feature.

I do find karmatosed's suggestion of user-based privacy to be sorta compelling. Individual users could opt to make their favorites private. This would (a) block others' access to their Favorites tabs, and (b) hide their favorites from the stream and from favorite counts. We could use 'hide_sitewide' to make this happen pretty seamlessly from a technical point of view. Having this sort of user-level privacy feature seems like it addresses a similar concern to the "private bookmarking" thing, but does it in a way that does not muddy the feature so much.

karmatosed, if you were interested in exploring this idea a bit more in some sketches, it'd be really helpful.

[imath]

Here comes another patch!

5644.activity_table.02.patch is introducing a user-based privacy feature and is trying to follow boonebgorges 's personal feeling.

I guess the UI can be improved. Let's wait for karmatosed expertise about it. In the meantime UI is imath's "crippling" style ;)

Finally i think the favorites privacy setting should "merge" with the profile field visibility setting in a "Privacy" subnav of the user's setting nav. But for now, i've quickly built a different tab for the favorites privacy setting.

[imath]

we can build in filters and whatnot so that people can make it do something else

Today i've tried to build a bp-custom.php file to override the favorites with a likes feature to test the filters i've added in previous patch.

It made me finds some bugs and realized that in case of a like feature, the "unfavorite" action should be neutralized, so i've added a way to do so, corrected bugs and improved existing filters.

5644.activity_table.03.patch is including these improvements, and i'm also attaching the bp-custom.php file i've built to test the filters and build a like feature.

[Bowromir]

I've given the latest patch a spin and I'm pretty darn excited to see this take shape. Reading through all the comments in this ticket here are my thoughts..

I really like the idea of allowing "Favorites" feature to be used in two ways depending on the type of BuddyPress community you're running. One option is to use favorites as a "liking" system and a friendly nod (as JJJ put it) to the creator of the activity. This is something that's very welcome to anyone who uses BuddyPress and it's activity stream for a community similar to Facebook. Using Favorites as bookmarks could be very useful in communities that utilise the activity stream as a news source and less as a social stream.

But I agree with Tammie about the UX concerns this presents in terms of implementation. Just because the code/logic is very similar, it does not mean that Likes/Favorites are comparable from the users point of view. Hence I don't think it's smart to let an admin turn "Favorites" into "Likes". It's comparable to the Friends vs Followers concept.. very similar in terms of functionality for devs, but not so much for users. My entire social circle including my mom & dad immediately understands what the "Like" and "Friends" button does (thank you Facebook) but explaining them a "bookmarking" and "follow" button would be a lot harder.

My assumption by looking at the existing BuddyPress communities out there, and the themes that are being sold on ThemeForest and other places, is that most BP sites build are social networks more akin to Facebook than to Twitter. This is why I would make the argument that a "Like' button would have bigger benefits for most communities then a "Favorite" button. Also because "Liking" something is a great way to keep people active and most importantly reward users for being active. Something all communities could benefit from (especially in the early days of launching a community).

In my opinion I think something similar to the "Default Active Components" strategy in BP 1.7 could also be used for Favorites and Likes. Existing installs would keep using "Favorites" whilst new installs would be using "Likes" be default. Under the hood this functionality would be very similar (@imath his awesome patch has proven that this is possible) and legacy site owners could even migrate from favorites to likes with relative ease by changing a setting and informing their users of the change functionality.

It could look something like on the attached screenshot.

Now in regards to the "Like" functionality and what it should do by default.. I think there's are some things that could be problematic.

• I don't think "Likes" should be shown by default in the activity stream. People like a lot of stuff. If you have 200 friends it would mean that within no time your activity stream would be filled with "Like" entries. A possible solution would be a "trigger" where a new "Bowe, Boone and 8 others liked JJJ his activity" would be posted when a certain amount of likes are reached. Although I'm sure this would probably complicated and resource heavy code?

• I'm not entirely sure about using tabs to switch between "Replies" and "Likes". Purely because seeing instantly who liked something is strong motivator for users to click that like button too. And the more likes the more activity and happy site owners :-)

This is pretty much it for now :-) Great discussion and thanks for the awesome work Mathieu)]]

[Bowromir]

Activity Options

[imath]

Replying to Bowromir:

This is pretty much it for now :-) Great discussion and thanks for the awesome work Mathieu

Thanks a lot for your feedback Bowe :)

Only problem, is i built the patches to be the one or the other :

• 5644.activity_table.patch was using a setting
• and 5644.activity_table.03.patch requires some hooks to turn favorites into likes

I understand the screenshot as if the 2 of it could be used at the same time..
We probably could create two types of activity : activity_favorite as in the patch and activity_like to make that possible without a specific BP component, but i guess it would be best to have it as a different component.

The init goal of my ticket was to suggest an enhancement for the favorites feature (solving the favorite count bug appearing when a favorited activity is deleted at the same time).

I have the feeling, that the real need doesn't seem to be "improve" favorites but "create" a "like" feature and keep favorites the way they are.

I think i'm part responsible because of my suggestion to show people who favorited an activity. I realized it might have been a mistake. Sorry for that.

Maybe we could do smaller steps by first moving favorites out of user meta and leave the feature like it is today, solving the favorite count trouble.

Then on a future release, consider building one or 2 components ( bp-favorite, bp-like )

[boonebgorges]

Let's try to talk about this during today's dev chat to see if we can get a handle on the problem that we're trying to solve for 2.1.

[imath]

Extracted the part of the code that was fixing the 'favorite count' bug and built a patch on #3794

see ​https://buddypress.trac.wordpress.org/ticket/3794#comment:6

[DJPaul]

This is a pretty rich ticket in terms of contributions to it so far, and it would be nice to pick it up again for 2.2. I am very keen to introduce Likes. imath, is this something you're interested in working on for 2.2 with me?

[imath]

Replying to DJPaul:

is this something you're interested in working on for 2.2 with me?

I am very interested :) I think i need to first fix this related ticket #3794 by adding more unit tests as boonebgorges suggested. Working on it today ;)

[DJPaul]

Yes, it makes sense to get #3794 finished first as I think we'll be able to re-use a lot of the same implementation.

---

To start the like button discussion again, and having read through all the previous comments once again, I'd like to propose the following course of action:

• Finish #3794.
• Rename the existing "favourite" button to "bookmark".
• Add a new "like" button to the Activity component.
  • Technically, we'll be liking Activity items rather than the real object/post that the activity points to, but to the end user, they won't notice the difference.
  • In the activity item template, show either gravatars of everyone who has liked an item, or just text like "10 people have liked this item", or some combination/variation thereof (to be decided later).

[imath]

I think the big challenge is "UI", my suggestions about this didn't satisfy see older comments/patches. So i think if we're working on a "like" feature and display avatars or text to inform who/how many people liked the activity, then: we first need to have a consensus about the UI.

Other than that, i'm OK with DJPaul's course of action and would really be happy to have this in core :)

[johnjamesjacoby]

My thoughts:

• “Bookmark” is still a poor word choice. It's already used by browsers to imply “Favorite Sites”; it's not modern sounding; it conveys the infrequent adding & removing of items, which as a feature makes it sound less powerful than it is.
• As a UI, core default needs to be incredibly simple. No JS, no fancy show/hide CSS. Enough markup to make fancying them up possible. We can ship with an example of how to extend the UI, but let's not spend too much time on what a bunch of avatars in a row looks like.
• There should exist echo/return functions to individually get: avatars, profile links, display names as titles, the total count of likers, and the like/unlike buttons.
• I'd love it if the markup for outputting avatars was a template part, so it could be easily overridden in a child theme.
• Lets ditch the on/off UI, as there's no way to guarantee it applies (other than using theme_supports functions, which I would rather not do.) Example: In making a child theme that does not support automatically refreshing Activity Streams, end users are still left with a visible option that does nothing.
• Re: data storage, I see a few viable options. 1) New database table to point the relevant object ID's together. This gives us things like timestamps, maybe custom-like-types, etc… 2) Use the activity stream table, with a custom action type. We get a lot for free this way. 3) Store the same meta_key bp_user_like with a value of the user ID, and then easily query for and slurp them up for each activity stream object. We get less data about each like, but it's simple and fast.

[ubernaut]

i agree about the bookmark term.

[boonebgorges]

Thanks for getting this conversation moving again.

Rename the existing "favourite" button to "bookmark".
Add a new "like" button to the Activity component.

I'm not convinced that it's wise to try to do both. I think it's too complex, and I think that very few sites will be interested in using both features. My opinion is the same as here ​https://buddypress.trac.wordpress.org/ticket/5644#comment:19 - just change Favorites to Likes and forget about a bookmarking feature (leave it for a plugin). I could probably be convinced that the two features could coexist happily with the right UX mockups.

As a UI, core default needs to be incredibly simple. No JS, no fancy show/hide CSS. Enough markup to make fancying them up possible. We can ship with an example of how to extend the UI, but let's not spend too much time on what a bunch of avatars in a row looks like.

I agree strongly with this principle, though I think we'll at least need to truncate very long lists of avatars (perhaps with a "...and 55 more" link that goes to the untruncated list on the activity permalink page).

[hnla]

“Bookmark” is still a poor word choice. It's already used by browsers to imply “Favorite Sites

Have to agree with jjj here the term 'bookmarks' worries me slightly, even in fact changing a term familiar i.e 'favourites' even though we have to.

I frontend dev terms it might be nice to be able to switch easily from 'Display Avatar Likes' to a more simple display 'Like' count, obviously some sites may have a lot of likes displaying all those as avatars might be problematic for layouts, default would be 'Likes Count'. So we could do something along lines of bp_likes_display(array('avatars' => true)). Truncating the avatar list though does seem a sensible provision, the activity permalink template would be somewhere it would be far easier to show a longer/full list.

I'd love it if the markup for outputting avatars was a template part

Moving forward its essential we try and keep as much markup out of the core files as possible, if we can create mini template includes that's ideal, there are still areas of BP components that frustrate in having markup buried away.

Agree on the keep it simple, and providing just solid well marked up/classed structure, although we can always look at providing some example visual fun that could be dropped into css files.

[techguy123]

Hi, I was wondering if there's an approximate date for the official release of this awesome set of improvements to Favorites? And I'm assuming it would be part of the core BuddyPress update? Thanks :)

[DJPaul]

Hi @techguy123

*Probably* BP 2.4 (about 4/5 months from now) or 2.5. There are some dependencies that we want to make sure we get right before we can move forward with this.

[techguy123]

Replying to DJPaul:

Hi @techguy123

*Probably* BP 2.4 (about 4/5 months from now) or 2.5. There are some dependencies that we want to make sure we get right before we can move forward with this.

Thanks for the super quick reply. Sounds great, looking forward to it. I really appreciate all of you guys' work towards this goal! Thanks :)

[bymiki]

Hi guys, is there any news on this ticket?

Please, do not let this idea die. In my opinion it is a necessary concept in every social network. If you realize, Twitter, Facebook, Google+, Instagram ... all have their system to indicate that something you like. And for the users, to receive that "I Likes" is an important boost to continue to bring things to the social network

Thanks!

[Bowromir]

I agree.. I'd love to see this discussion opened again.

[techguy123]

Yes! Definitely looking forward to an update, excited! :D

[mercime]

Is this something we're still considering for bp-legacy or shall we leave legacy alone and introduce in bp-nouveau? :D @imath @hnla

[hnla]

@mercime @imath think I would favour functionality in core, implementation in Nouveau - sort of push Nouveau in respect of new BP features if the feature is ready enough for prime time.

This is definitely a feature that is desired.

[imath]

@hnla @mercime

1/ I agree with Hugo. The favorite feature is Activity's component territory. And even if we could "bypass" Core to fix the #3794 issue and bring cool favorites as described in this ticket inside BP Nouveau, i think it's probably the wrong way around.

2/ BP Reactions will be BP Nouveau "ready" so it can be used to replace favorites ;)

3/ I know a lot of people are really annoyed about the #3794 bug (one of the reason why i've built the reactions plugin is this and the fact that we can test the Activity table scenario and an upgrade UI), but we first need to decide what's best for users: the activity table or a specific relationships table ;)

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/

[imath]

I'm not sure I will progress a lot about it during 14.0.0, but I'd like to try something new/different from the possible roads we thought of so far about improving Likes/Favorites and also fix #3794.

I'm back again with Favorites improvement. The story of this ticket highlighted the fact we should consider moving to Likes. I agree and now we have a Backward Compatibility Add-on (BP Classic). I believe we should move the Activity Favorites feature into this Add-on and finally have Likes instead into BuddyPress.

I've tested many ways to fix this ticket and I believe I finally have something solid to improve how we deal with Likes or more globally with Reactions to an activity. My reasoning to build the Activity Likes feature is Activity comments or Activity Likes are both reactions to an activity: I like what the activity says or I reply to it. So Activity Likes can be compared to Activity comments without content. If this PR is still a WIP, it already contains:

• An Activity Type API (it should help us fix ​#6429
• Examples of what improvements this API can bring: see the bp_activity_type_supports() function.
• An initial Reaction API I'm inaugurating with the Activity Likes feature.
• Adding/Removing Likes, getting likes count for an activity, getting the activity the user liked

Next steps if we agree on this scenario:

• List the users who liked an activity on the Activity single screen
• Ajax/JavaScript implementation into Template packs

More possible ambitious steps:

• Sort Activity stream according to number of activity likes
• Sort Activity stream according to number of comments.

I really think we should go this road for Activity Reactions/Likes. What do you think? Should we make this the 14.0.0 release top feature?

Trac ticket: ​https://buddypress.trac.wordpress.org/ticket/5644

Maybe if I explain it this way, you may gain a different perspective. Currently, I am a member of a site that has ability to Like activity posts in addition to being able to Favorite activity posts. As a matter of fact, the site admin has relabeled Favorites to read as Bookmark which allows members to have a list of activity posts that they can just refer to because:

• They can Like the post at a later time/date.
• They can Comment on the post at a later time/date.
• They can later refer to the post for sharing purposes at a later time/date.

Seems to me, you are creating an either this or either that situation by moving the Favorites functionality into BP Classic. I'm not sure why site admins can't have both as is currently possible now.

@emaralive & @renatonascalves

Thanks a lot for your feedbacks, I'm just following the consensus that was found about choosing both features, favorites or likes only:
See ​https://buddypress.trac.wordpress.org/ticket/5644#comment:36

Moreover, Favorites are very buggy, we really should deprecate it. If there's a strong willing to absolutely keep the idea of Bookmarking I'll surrender but in this case it should be rebuilt as the Like feature using an activity type having a reaction role.

@imath I don't have a strong opinion about it. To be honest, I'm not sure if this feature is used a lot in communities.

If we can deprecate it without any major issues to users, great. I do have a strong opinion that the API should be flexible enough that plugin developers can use it for other components, if desired.

BuddyPress is very good at being extendable to developers. The current API in this pr could do with some improvements, getting the reactions is a bit burdensome, lots of PHP filtering.

@renatonascalves thanks for your review by the way, I'll update the PR accordingly. This is still a WIP but I believe the Activity Type API combined with the reaction one will improve & simplify things.

@emaralive & @renatonascalves

Thanks a lot for your feedbacks, I'm just following the consensus that was found about choosing both features, favorites or likes only: See ​https://buddypress.trac.wordpress.org/ticket/5644#comment:36

@imath & @renatonascalves

Seems to me the referenced comment was from 9 years ago, of which, that was the thought then (2015) and this is now (2024). AFAIK, things/thoughts/conditions change over time.

Moreover, Favorites are very buggy, we really should deprecate it. If there's a strong willing to absolutely keep the idea of Bookmarking I'll surrender but in this case it should be rebuilt as the Like feature using an activity type having a reaction role.

As to buggy, could you expand upon this notion, @imath? The last bug I remember is reconciling Activity IDs after an Activity/Comment was deleted.

I'm trying to imagine how Slack would work without the ability to Save for later (bookmark); meaning, I can only react to a message. I suppose I could manually copy the message link and save it in a text file but, that would actually be archaic and I shudder at the thought.

However, in all fairness, I've not checked out this PR to see how it actually works and when I get an opportunity, I will do so. If, by chance, there isn't the ability to bookmark then I would recommend the exploration of "_it should be rebuilt as the Like feature using an activity type having a reaction role_" because I dont know what that means nor what it would look like.

I agree that bookmarking/favoriting and liking posts are two different types of actions, and while adding reactions is a great improvement (and probably expected funtionality for most users), I'd hate to lose bookmarks, for those users who are bookmarkers. If bookmarks are buggy, we should fix them. I'm guessing that one of the issues is that the old code stored them in a serialized array (I'm guessing about this), so when an item is deleted, it's hard to remove them from all of the serialized arrays.

Reactions are great!

Ahaha thanks a lot 😍 for your reactions 😉 @dcavins & @emaralive.

As David explained using serialized information into a user meta will always be a trouble and we need to avoid doing this as much as we can (we sometimes have no other choices).

Favorites are already gone, reading your 2 comments: you're now talking about bookmarks so I think we can satisfy everyone's expectations:

1. the current "Favorites" is "classic" BuddyPress and needs to be deprecated, moved to BP Classic so that very conservative users can always enjoy it.
2. Modern BuddyPress is "Likes" & "Bookmarks".

Likes: will help make the most interesting activities to rise once we'll be able to sort activities according to the number of likes or comments. So that's the most interesting feature to me, it's a community feature in the sense that thanks to the public expression of the community members I can see the best of activities.

Bookmarks are a "selfish" need, it's less interesting to me, but, I was actually using it on Twitter 😁 (I'm not saying the before last letter of the Alphabet, because I left Twitter before it was renamed). So "technically" speaking: to me, "Bookmarks" are hidden "likes" only visible to me. I can go to my list of bookmarks, read the activity, then remove the bookmark once I've read it. I agree it's interesting to build this feature using reactions and probably use this feature to eventually migrate the favorited activities that are still existing.

But Favorites are different, it's more persistent. My favorite movie is Matrix, my favorite pizza is Pepperoni : it won't change... I think BP Favorites were used as bookmarks.

In short can we agree on, let's build 2 Activity reactions in 14.0.0:

• Likes
• Bookmarks

and keep Favorites, but, into the BP Classic Add-on 🧐 ?

Technically speaking, will I be able to add Group reactions? Like a group? Bookmark a group? A blog post? Like a message? Bookmark a message (similar to Slack)?

Let's not build the API attached to the Activity component since that's not the only one a site might need it. So naming Activity reactions might be the wrong start. Having a "Reactions API" might be better.

💥

Thanks @renatonascalves for your feedback. I understand you expect something larger than Activity "Reactions". Maybe the "Reaction" word is a problem, btw. To me a comment is already an activity reaction, for example.

1) I'm afraid what you seem to suggest won't be achieved in 4 months for 14.0.0. A centralized Reaction API makes me think about this project that never happened: ​https://github.com/buddypress/bp-relationships
2) Thanks for insisting about ​https://github.com/r-a-y/buddypress-followers I wasn't aware it included features to subscribe/follow an activity or a blog. I thought it was only targeting users.
3) FWIW: about liking, bookmarking a group, a post, a blog : you'd be able to do so liking or bookmarking the activity generated by these objects. To me liking a group or a blog does less sense than an activity, a comment or a post by the way.
4) Messages: the star feature is doing a nice job, I believe.

I'm not as ambitious as you seem to be. I'm suggesting to satisfy a need I often read on BuddyPress support or in reviews about it, find a way to:

• introduce Activity likes (as a replacement of favorites was my understanding of the ticket's history).
• I thought it could replace gracefully Favorites, but understood the majority of the team thinks we should keep this feature
• introducing Activity bookmarks using some kind of hidden likes can be done for 14.0.0 and I hope can satisfy @emaralive & @dcavins concerns.

But this ticket is not about building a central Reaction API (I'll edit the PR's title as I admit it was misleading), it's about improving favorites management. I'm now trying another alternative way using activity children to create likes or bookmarks just like we do for comments.

So:

• If the "Reaction" word is a problem, I'm fine with using another one 😃.
• If using activity children to manage likes or bookmarks is a problem or everyone thinks a central reaction API is the right way to fix this ticket, I can halt there and move to another ticket.

I begin to believe this ticket is cursed 😂 🧙‍♀️ At least, I've tried many ways to improve the current Favorites situation for 10 years!

Agree! Let's move the convo for an extendable API for ​https://github.com/buddypress/bp-relationships or a related ticket. I mistakenly assumed that was the goal here.

Thanks for insisting about ​https://github.com/r-a-y/buddypress-followers I wasn't aware it included features to subscribe/follow an activity or a blog. I thought it was only targeting users.

I used it before to add a feature to a client site. It has a good database schema that made the job a breeze.

I just refreshed the PR, but I won't work on improving the Activity Favorites / Likes (or eventually Activity Bookmarks) feature anymore (although "Likes" is one of the features users expect to finally get in BuddyPress just like it was the case for the private visibility).

I understood you all disagree with my strong conviction that it has to be managed using Activity children just like Activity Comments.

Let's wait for an hypothetical more global BP Reactions API to land one of these days in BuddyPress (eg: ​https://github.com/buddypress/bp-relationships)... The ironical part about it would probably be that users will want these reactions to generate activity entries (duplicate info we could have avoided with the way I'm convinced we should use). Nevermind.

Instead I'll pick the part about the Activity Type "API" to clean the mess currently existing between Activity Actions & Activity Types from this ticket ​#6429.

Just adding my two cents here that, I know you are unhappy with this outcome, and I totally understand the frustration.

However, long term, I do think having a relationship API is the right approach to take, even if it takes longer to get there. I'm personally invested in this feature, so you can be sure we will make some progres in the next release.

The ironical part about it would probably be that users will want these reactions to generate activity entries (duplicate info we could have avoided with the way I'm convinced we should use).

^{here I think we will need to have better integration not only with the activity component, but also with the notifications component, the settings component (so that one can turn off notifications), etc.}

There is another ticket related to the notifications part somewhere. But the pieces are all connected. Your work on the Activity Type "API" will help with this task too. :)