Allow to bookmark/favorite issues without abusing the Assigned field or issue tags

I have two additional suggestions:

1) Include a separate block on Dashboard for this, it may be implied but otherwise I don't see the difference from Following a post. The blocks titled "Your issues" and "Your posts" seem redundant, aggregating the same pages with slightly different meta info; I would rather have two columns: Bookmarks and Issues.

2) Include a bookmark link on Forum posts. Some of these include very useful posts about performance-tuning, for instance.

@mattcasey: Thanks for your suggestions. However, they're off topic for what sun is actually proposing here.

1) "Your issues" and "Your posts" are not redundant. They're only redundant if you never participate in forums. If the only posts you ever make on d.o are issues, then "Your posts" will just include issues. But, if you comment on or author d.o documentation "book" pages, participate in forums, etc, then "Your posts" sees all of them interwoven.

2) The ability to follow/bookmark forum posts is the topic of #1304216: A user should be able to "follow" individual pages of content and receive email notifications for new comments

However, what sun is proposing is something different than just "bookmarking" or "following". He's saying he wants 2 ways to flag/follow/bookmark something. He wants the current "follow" just so he can be informed about changes, etc. But, he also wants a way to mark things that are his "favorite" issues so he can prioritize those. Think of it as "normal follow" vs. "critical follow" or whatever. It's not a question of follow or not. It's 2 kinds of following.

@sun: In principle I agree with you. In practice, I wonder how many power users need/want this level of complication. I'm also concerned that the UI is going to get messy and confusing for the vast majority of folks who don't follow 1000s of issues like you and I do. ;) So, I'd like to see a) more discussion from people that they really need this and b) some thought put into how to do it in a way that doesn't overwhelm the issue experience for the 99% of users for whom the existing follow functionality is totally sufficient.

Thanks,
-Derek

Hrm, I thought I understood what you wanted this for, but the last two paragraphs of #3 have confused me. ;) You want to see a page hanging off issues showing everyone that has used the "this issue is one of my favorites" flag? See the debate on a very related topic at #1304558: Provide a page showing all the users following a given issue. :/ Instead of using this to organize your own issues, you want to use this to track "teams" working on specific issues? Wow. This just went from something that's useful maybe 1% of the time to something that's useful 0.01% of the time. :/ Maybe I'm being pessimistic. But, if that's what you want, I'd just say add a section to the issue summary in those incredibly rare cases where there's actually a "team" working on an issue like this.

Also, yeah, I was thinking of a "power user" checkbox in the profile, although that can get a bit messy in some ways, too. Even with that, I'm worried about UI. :/

I hate to say it, but I'm leaning towards "won't fix". I want to help empower our power users, no doubt. But this seems fraught with UI problems, limited use-cases, and will probably be a fair amount of work to implement for incredibly limited value. We need to pick our battles...

At the same time, I don't want to stifle initiative, so I'll leave this open for further comment and discussion for now.

Thanks,
-Derek

This may be a no-go due to system resource hogging but, if it's doable, how about private tags? Then anyone could come up with their own system of prioritizing by tagging issues in a way that makes sense to them. These tags would only be visible to the user who did the tagging so wouldn't clutter up the page with tons of tags.

Michelle

I have no idea how to implement "private tags", neither on the backend, nor in the UI.

I don't, either, unfortunately. I mean, I could probably come up with a module for it if I put some thought into it but a module that would scale to drupal.org's needs? Unlikely.

I would love this feature too.

Sometimes twenty new replies might come through and you can reply to a few quickly but some require you to come back to them later when you have more time to investigate or whatever.

I'm not as much a power user as sun or dries but would still find this extremely useful.

From my point of view the "dumb flag" option would be fine.
The checkbox to enable the feature was something I also considered but don't think is 100% necessary. Seeing as it would not be aimed at the masses it could be a smaller, more out of the way thing anyway. It doesn't have to be a great big second follow button, as that really could be confusing.

What about this for a simple start?

1. Flag for "favourite" issue
2. Add a block I can put on my dashboard which displays my favourites
3. Each favourite displays as a linked title + the normal new/updated marks

The current blocks available for the dashboard could use some new friends...

Right. That's what we've been considering since this was originally proposed. The same UI problems hold -- how do we obviously convey the difference between "favorite" and "follow" to end users? Is it worth complicating the default UI for 99% of the users of d.o that aren't going to need/want this functionality for the 1% of power-users that will? Do we conditionally show this new flag to users that opt-in to this complication via a per-user setting on their profile? What do we call that setting? Etc...

Personally, I think this needs to be postponed until after the d.o D7 launch. Then we can consider new features like this (along with a more massive reconsideration of the follow/notify functionality across d.o -- see #2005712: [META] Redesign issue email notifications among others) once we're running D7.

Thanks,
-Derek

I think 99% and 1% is an exaggeration. We need to talk about the % of total traffic that use the "follow" not the % of all traffic to d.o, are you really telling me that 99% of the % that use follow would not want or understand a "bookmark"?

Maybe "follow" is too broad a term then. What about "add to watch list" and and "pin to dashboard"? Surely you know which one I mean with each :)

Also, we could just have a link under the flags to a simple page explaining what each does with screenshots.

I don't think these UI problems are unsolvable, what % of people in this community are professional UI developers...

Waiting until after D7 is totally rational, but lets not exaggerate how difficult the most basic implementation is or understate how many people it would be super useful for - which is an ever growing number as both the number of issues and number of contributors for core increase.

- I might be exaggerating the exact %s, but it's all speculation at this point. ;)

- I believe we have to consider the people looking at issue nodes, not just the ones that have already figured out and are using "Follow". Having extra flags/buttons will potentially confuse everyone looking at (and trying to participate in) an issue. So, that's why I think 1% vs. 99% is closer to reality for this particular feature request.

- I know what you mean by "add to watch list" and "pin to dashboard", but wow -- those are pretty similar concepts.
<hat class="new-user">
-- What's a "watch list" and where do I see it?
-- What's the difference between that and my dashboard?
-- Why are these two things separate? Wouldn't anything pinned to my dashboard be something I'm watching?
-- WTF?
</hat>
;)

- I'm becoming one of the UI experts in our community after being responsible for these tools for so long, 100s of hours of conversations and reviews working with formally-trained usability people to improve the UX on d.o (and in core), and a lot of study of Edward Tufte's work. Some of the things I've learned:
-- Simple is better. Every time you add more stuff to a UI, you're in danger of making the usability suffer.
-- Any UI that relies on help text to explain itself has already failed.
-- Don't complicate the default for everyone to benefit a very small minority -- let the power users opt-in whenever possible.
...

No, these aren't impossible, and I'm not trying to exaggerate. But I think you're underestimating how confusing this subtle distinction is going to be for the vast majority of people looking at issues. However, I'm not trying to stifle your (or anyone else's) initiative, so I'm just trying to be transparent about my thought-process on this. That said, I'm violating my own advice that this isn't a high enough priority to be working on while the D7 port still isn't done (even with my volunteer time like I'm using to write this reply). :)

Thanks for your interest in helping to make d.o better!
-Derek

#12 - Aight, I'm sure you'll figure it out when you've got time to. Let me know if you need a hand with it :)

Could we just use a module like https://drupal.org/project/favorites or https://drupal.org/project/bookmark

@dww - Interesting ideas! I'm not convinced about the need to do this. I don't use bookmarks much myself. The Follow function works pretty well.

I guess it depends if it's a matter of the issues or other elements in Drupal. For instance I always find myself going back to the FAPI docs. There are other docs too that I might want to track. You can follow issues, but not projects or forums.

Mozilla has some interesting UI patterns to consider too #2205647: Add "I have this issue too" Button

As mentioned in #12 I think it would be fine if this was opt-in and the user chose to use it in their account settings or else they never saw it.

That way any help text you might need to explain the feature just goes in the settings page when this is turned on.

Mentors need a way to track "issues I'm mentoring someone on"
Mentors cannot use "issues I'm following" or "issues opened by" ...etc because they have sooooo many.

This issue might help mentors with that. tagging.

Adding another button won't solve the problem. OK, instead of one list you get two. That's not scalable as well. Another idea that raised during devdays was using 2 tagging UIs: one public (as today), another per-user. (i.e. based on https://drupal.org/project/private_taxonomy?).
Regarding concern of overloaded UI, private tagging can be hidden by default, and shown only with tools like dreditor

How about using nodequeue / smartqueue per user?

Create a "Sprint" content type and reference issues using node reference?

#21: Nice idea! Not sure that "sprint" is the right name, since we're talking about personal issues lists. Otherwise - user can create (issues topic? personal list? whatever name could be), and attach unlimited number of references to issue. These lists can be publicly accessed (when published), or private (otherwise). No new modules required on d.o. (another win)

Why do we need nodes for this? Seems architecturally quite strange.

Seems something like flag would be more appropriate.

It could conceivably be done with a taxonomy fielded flag, views would be needed to ensure user isolation.

As for the UI, I can imagine a "Add to List" button below the "Follow" button.

The only problem with attaching a vocabulary to flagging entity is sharing terms between different users. If we are ok with that, that's preferred over nodes (IMO). If not, we will need something like https://drupal.org/project/private_taxonomy

Yeah, that is the problem with a Flag-centric + Tags approach. I think if we were to create a "Bookmarked Issues" view, we could expose a taxonomy filter. That would give the appearance of private issues.

Actually, now that I think about it, shared tags for bookmarked issues is a feature in this case. It would allow multiple mentors to contribute to a single issue tag without the bottleneck of a primary mentor. YesCT may correct me on this. ^_^

I thought this was for users to specifically track issues they are themselves interested in.

Why do we need to use tags if it's just a list of favourites for the current user?

- I guess this came from #17

What about just multiple types of pre-configured flags?

Really if we start getting more complex than that and allow custom tags and things we need a views UI to view it all (as has been mentioned). At very least exposed filters.

Are we getting more complex than we need?

@rooby: this is not a concern. You and I will call different issues our "favorite", so our lists tagged with the same term won't overlap. I do see both cons and pros for sharing listing terms. Since shared vocabulary requires less added code, I vote for that.

I think tags is being discussed here because tags would generalize and also solve this issue.

I see/agree that making personal tags a separate issue would be helpful.

I'm with sun.

"Why are we even talking about tags" is what I was meaning in #27.

@sun, @rooby: I think there is some confusion about suggested solution, probably caused by blurry usage of the "tag" term. Suggested solution is still based on user flag, not tags themselves. Nobody will be able to remove "your" tag from the issue.
We are not talking about adding another set of tags to the issue. Instead, suggestion is to add taxonomy term field to the flagging entity. Your flags remain your flags, but you get an ability to tag them. Once again, not issues are tagged, but flags.
Does that make sense, or you still oppose this solution?

Yeah that's how I understood it, but I still think it's too much complexity that isn't needed if we are aiming for the title of this issue, which is just for a bookmark/favorite functionality.

Just one list of issues that you can see you have to come back to later.

The more complex we make the flagging the more complex we have to make the listings of those flags and the more complexity that is added the less likely we will get an outcome any time soon.

I think tags are a bit off topic here.
In theory if simple flags were added then tags on flags could always be added later if it's something in demand.

I think we should move forward with the simple flag functionality and consider tagging flags (or whatever) as a follow-up:

#2271877: Allow per-user tagging of issues

I'd be happy to help move this forward and/or provide reviews.

This is being discussed at Drupalcon, and it seems it's seems this is stuck on whether or not to do it, but pretty clear now on what it's trying to accomplish (though the solution is as of yet unclear if custom or using an existing module, the problem statement seems well defined now). I'd like to bolster the case for this with an example.

Github has "Watch" and "Star" buttons. They faced pretty much the same problem here. Some users wanted to favorite/star a repo to come back to later, but all that was available was "watch" which gave the user all the updates from that repo. They explain the reasoning for adding it pretty well in a blog post https://github.com/blog/1204-notifications-stars

Concerns about cluttering the UI, but Github tests everything very thoroughly and found it useful and worth the visual space.

We also did something similar at Kiva. We added a Star to loan pages (for logged in users). Starring the loan then allowed for seeing it in a "My List" view on our lend tab. This pleased our more involved lenders, while being unobtrusive enough to not confuse or distract casual lenders.

Starring seems to be a fairly common concept these days (eg. github, stackexchange, twitter, gmail, firefox/chrome bookmarks, etc.) and I think it fits this feature request well.

I have created "proof of concept" of multiple followed lists at https://valthebald-drupal.redesign.devdrupal.org/

If user does not perform any action, follow screen looks exactly as it looks today:

In edit user screen, it is possible to define "follow categories" (I don't like wording, but you got the idea):

When I do so, issue node view page looks like this:

I think we are keeping this with just a simple favorite.
#2271877: Allow per-user tagging of issues is where we are discussing multiple lists.

As with #2271877: Allow per-user tagging of issues, my biggest question on this would be what the performance impacts would be. I remember Narayan having to do some bit of crazy trickery to make Flag module performant on Drupal.org for the single "Following" flag we already have.

Specifically, Drupal.org has 750K issues, 1.2M nodes, and 1.6M user accounts overall. It'd be good to test any proposed modules against at least 200K+ nodes/users to see where they fall down.

Throwing an arbitrary nodes/users at something isn't necessarily the best way to performance test. Check for:

• Run EXPLAIN on new queries. Is it using indexes, not using temporary tables, etc?
• Look at the queries run, are there queries per-node, per-user, etc, that could be done in one query?
• Investigate anything that looks like it needs more investigation.

#1133956: Improve efficiency when displaying lists of flaggable comments might be what you are remembering for "crazy trickery to make Flag module performant".

> I remember Narayan having to do some bit of crazy trickery to make Flag module performant on Drupal.org for the single "Following" flag we already have.

People follow LOTS of issues. How many issues will they people feasibly want to have in their favourites? Wouldn't that be a fairly small number? 'Favorite-of-Dries' has currently 9 issues. Sun's assigned issues runs to 3 pages: https://www.drupal.org/project/issues/search/drupal?assigned=sun&status[...

Compare that with my 51 pages of followed issues -- because it's every single issue I've ever touched in my 5 (or is it 6?) years of Drupal!

(Also, regarding the 'Following' flag: Flag is being COMPLETELY misused for that feature. Full details here #2218345: Doesn't actually need Flag but basically, d.org is using Flag as nothing more than a REALLY expensive UI.)

> #2271877: Allow per-user tagging of issues is where we are discussing multiple lists.

If you use Flag 3.x, you can do multiple lists very easily by adding a taxonomy on the Flagging entities.

related, outside projects:

https://chrome.google.com/webstore/detail/drupal-issue-tracking/gigmiecl...
from @mglaman

and
https://github.com/Lullabot/drupalorg-issues
from @justafish

This issue was submitted to the GSOC project https://groups.drupal.org/node/455978#project33

Now that users can follow an issue, I guess this feature can be considered implemented.

Following can mean you clicked follow, or that you commented on it. While it's 100000% better than the old "+1 subscribe", my list of followed issues is exceedingly long compared to ones I would star/fave/bookmark if there were an additional flag available.

Yes, being automatically added as followers for adding a comment has its cons, especially for users who post many comments in different issues. It could help to have at least two different flag lists.