Skip to:
Content

BuddyPress.org

Opened 5 years ago

Closed 20 months ago

#5644 closed enhancement (maybelater)

Activity Favorites: alternative management & new features

Reported by: imath Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.0
Component: Activity Keywords: 2nd-opinion, needs-refresh, trac-tidy-2018
Cc: espellcaste@…, ubernaut@…, karmatosed@…, roger@…

Description

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)

  1. Use of an activity meta query to get user's favorites (compare => '=', value => user_id) or all users favorites (compare => 'exists')
  1. Adapt the UI to include a nav to toggle comments / favorites for each activity, see following screenshots ;)

https://farm8.staticflickr.com/7454/14194963945_6b72319107_z.jpg

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

https://farm8.staticflickr.com/7398/14008358487_75477b4bd1_z.jpg

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 ?

Attachments (8)

5644.patch (30.9 KB) - added by imath 5 years ago.
5644.bp_activity_favorites_table.patch (38.0 KB) - added by imath 5 years ago.
5644.wp-cli-bp.diff (4.9 KB) - added by imath 5 years ago.
5644.activity_table.patch (60.6 KB) - added by imath 5 years ago.
5644.activity_table.02.patch (63.5 KB) - added by imath 5 years ago.
5644.activity_table.03.patch (63.1 KB) - added by imath 5 years ago.
bp-custom.php (2.6 KB) - added by imath 5 years ago.
Screenshot 2014-06-10 14.39.20.png (92.9 KB) - added by Bowromir 5 years ago.
Activity Options

Download all attachments as: .zip

Change History (61)

@imath
5 years ago

#1 follow-up: @boonebgorges
5 years ago

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).

#2 in reply to: ↑ 1 @imath
5 years ago

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 ;)

@imath
5 years ago

#3 @espellcaste
5 years ago

  • Cc espellcaste@… added

This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.


5 years ago

#5 @ubernaut
5 years ago

  • Cc ubernaut@… added

#6 @karmatosed
5 years ago

  • Cc karmatosed@… added

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.

#7 @johnjamesjacoby
5 years ago

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?

#8 @hnla
5 years ago

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!

#9 @ubernaut
5 years ago

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.

#10 @johnjamesjacoby
5 years ago

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.)

#11 @boonebgorges
5 years ago

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.
  1. 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.

#12 @imath
5 years ago

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..

#13 @imath
5 years ago

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"
https://farm6.staticflickr.com/5480/14072997690_1f8043428a_z.jpg
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').
https://farm4.staticflickr.com/3726/14259616425_7468a5099e_z.jpg

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 :
https://farm6.staticflickr.com/5160/14072957139_fce934debf_z.jpg
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
https://farm4.staticflickr.com/3833/14072997740_c325397e7f_z.jpg

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

#14 @ubernaut
5 years ago

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/

This ticket was mentioned in IRC in #buddypress-dev by imathfromparis. View the logs.


5 years ago

This ticket was mentioned in IRC in #buddypress-dev by imathfromparis. View the logs.


5 years ago

#17 follow-up: @karmatosed
5 years ago

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 :)

#18 in reply to: ↑ 17 @imath
5 years ago

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 ;)

#19 @boonebgorges
5 years ago

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.

#20 @imath
5 years ago

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.

#21 @imath
5 years ago

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.

@imath
5 years ago

#22 follow-up: @Bowromir
5 years ago

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)]]

Last edited 5 years ago by Bowromir (previous) (diff)

@Bowromir
5 years ago

Activity Options

#23 in reply to: ↑ 22 @imath
5 years ago

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 )

#24 @boonebgorges
5 years ago

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.

This ticket was mentioned in IRC in #buddypress-dev by jjj. View the logs.


5 years ago

#26 @imath
5 years ago

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

This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.


5 years ago

#28 @DJPaul
5 years ago

  • Milestone changed from 2.1 to 2.2

This ticket was mentioned in IRC in #buddypress-dev by imathfromparis. View the logs.


5 years ago

#30 follow-up: @DJPaul
5 years ago

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?

#31 in reply to: ↑ 30 @imath
5 years ago

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 ;)

#32 @DJPaul
5 years ago

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).

#33 @imath
5 years ago

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 :)

#34 @johnjamesjacoby
5 years ago

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.

#35 @ubernaut
5 years ago

i agree with jjj about the bookmark term.

Last edited 5 years ago by ubernaut (previous) (diff)

#36 @boonebgorges
5 years ago

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).

#37 @hnla
5 years ago

“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.

#38 @DJPaul
5 years ago

  • Milestone changed from 2.2 to 2.3

#39 @DJPaul
5 years ago

  • Milestone changed from 2.3 to Future Release

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


5 years ago

#41 @rogercoathup
5 years ago

  • Cc roger@… added

#42 @techguy123
5 years ago

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 :)

#43 follow-up: @DJPaul
5 years ago

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.

#44 in reply to: ↑ 43 @techguy123
5 years ago

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 :)

#45 @bymiki
4 years ago

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!

#46 @Bowromir
4 years ago

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

#47 @techguy123
4 years ago

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

#48 @mercime
3 years ago

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

#49 @hnla
3 years ago

@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.

#50 @imath
3 years ago

  • Keywords needs-refresh added; has-patch removed

@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 ;)

This ticket was mentioned in Slack in #buddypress by hnla. View the logs.


3 years ago

#52 @DJPaul
20 months ago

  • Keywords trac-tidy-2018 added

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/

#53 @DJPaul
20 months ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.