deconstructing bug 210
Sep. 28th, 2011 12:55![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ursamajorRelevant URLs:
Bug 210, Overhaul "memories". Comments in particular suggest at least one good significant modification to the original spec![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png)
denise laid out.
Okay, what I want to do is deconstruct the existing spec, link to potential visual implementations, and think through the entire thing. So I think the smartest way for me to start that right now is to go step-by-step through the spec. Blockquotes are directly from the spec.
- Comments to Bug 210 (and predating the demise of Delicious) suggest that allowing cross-site bookmarking is a good extension of this. Could also allow for people importing bookmarks of other websites and from other services; I think a bookmark importer is important, but am unsure if it has to go out as part of the first release.
- In said Bug 210 comments,mark mentions canonicalization of on-site URLs; I responded to rb earlier today about the possibility of canonicalizing URLs for both entries and comments.
- I may need to come back to the Motivation and End Goal bits, but let's move on.
- I'm not sure I understand why "bookmark tags" should only be applicable to assets the user doesn't own, and this part may be undesirable given that I think the model should allow for bookmarking comments, which aren't currently "taggable." I do see things on Delicious where the author of a given post has tagged it "by:me," or where a specific Delicious account is dedicated to only listing the fic they themselves have written. That's a case where you couldn't post the fic itself directly to the Delicious website, though, so - is some of the logic so that people wouldn't bookmark their own stuff as a spammy form of self-promotion? Is this likely to be a big enough problem?
- Hierarchical tags, and bundles. I honestly didn't use bundles enough, and would love to talk to people who did use them. I liked the idea, I just felt like by the time I discovered bundles, I already had too many tags to sort through. Were there hierarchical bundles? Could those help in the organization of tags? Would that mean we'd still need hierarchical tags?
- Multi-word, comma-separated tags. Yes, please. These are lovely. Just, kindly inflict no repetitive NAGIOS-style popups on people about how awesome comma-separated tags are.
- Case-sensitivity in tags. Oh god oh god oh god please no is my gut reaction. Let people enter things in whatever case they want, but force toLowerCase() on submission. Obvious complications when character sets get outside of [a-zA-Z0-9] - do we force canonicalization there?
- I think I've gotten off-track.
- Both stricken, with good arguments as to why those limitations shouldn't exist. :)
- Does this mean that I *have* to subscribe to someone to see their bookmarks? Or, conversely, that if I subscribe to someone, I *have* to see their bookmarks? What if I'm following their journal for photography tips but really couldn't care less about their bandom bookmarks? Does it make any sense to separate these two functions? [It will add complications; the question is, what are those complications, and are they worth it?]
More questions as we go through each area.
- No arguments with #1. :)
- No arguments with #2 for onsite bookmarks. Less certain about how to enforce that for offsite bookmarks, if it's even at all possible.
- Agree completely with #3, with the caveat of canonicalizing "entry" and "comment" separately.
- Thumbs up to #4. :)
- Total agreement for #1.
- Sheer love for #2, with one minor caveat for off-site bookmarks: not all off-site content being bookmarked will have dates associated with them. Not sure how to handle that at this stage - make an assumption that for the purposes of sorting, if we can't automatically determine the original posting date of off-site content, call its "date entry was posted" the date that it was first bookmarked on DW?
- Thumbs up to #3.
- Love #4's extension on the original Delicious functionality.
- I miss #5 on the new Delicious so much already it's ridiculous [missing comments/notes]
- I'm down with #6.
- #1: Ooh, yes please. Especially if I could make multiple "jobs" where, for example, all "tech" bookmarks get crossposted to my journal daily, but all "recipe" bookmarks only get crossposted weekly.
- #2 and #3: Would this display on the entry itself? Would it be useful for others to see this metadata, or should this only display to the logged-in journal owner/community admin?
- I love all of these suggestions, especially the idea of booking something for a community. Re that - who should have permission to bookmark things for a community? Admins only? Community members? Could this be a setting in the community itself?
***
- Absolutely for #1, #3, and #4.
- #2: New Delicious has done this awful thing where when you click to save a bookmark, it SAVES IT PUBLICLY BEFORE LETTING YOU SPECIFY IT NEEDS TO BE PRIVATE. Before you can even add tags to it, or ANYTHING. Should we put a thing in where the "latest public bookmarks" page won't display any public bookmarks newer than ~5 minutes, a la the "latest posts" page?
- Edit: Also for #2 - if a user bookmarks something privately, I can totally understand why their username/comments/tags should not appear in the public meta-page for that bookmark. Should the fact that said user has bookmarked it count towards the displayed "# of people who have bookmarked this thing"? What if only one person has bookmarked something, and done so privately (or friends-only) - should the display count be 1 (indicating "somebody has bookmarked this, even if we won't tell you who or give you any details") or 0 (giving no indication)?
Is it enough of a privacy violation the fact that "somebody" has bookmarked that something?
- Enthusiastic agreement re all of the above.
- Works for me, and matches current options for other things.
- I like these options, and don't have any strong objections to them. Am pondering how and when the tag description would display.
Edit: I also meant to toss out the idea of "access-only" bookmarking - letting you make a bookmark that only people to whom you give access on your droll [wow, that seems like really awkward wording] can see. Less private than private bookmarks; more convenient than "sending" a bookmark to multiple peoples' inboxes as the bookmarks themselves would show up directly in the "network feed" where you read all of your friends' bookmarks. I assume that sharing bookmarks with custom groups could be a natural extension of this, though maybe not part of the first-round draft?
Bug 210, Overhaul "memories". Comments in particular suggest at least one good significant modification to the original spec
denise laid out.Okay, what I want to do is deconstruct the existing spec, link to potential visual implementations, and think through the entire thing. So I think the smartest way for me to start that right now is to go step-by-step through the spec. Blockquotes are directly from the spec.
MOTIVATION: To enhance user experience by standardizing on a single way of saving content (vs. the existing dual functions of tags & memories); to provide for an easy, grassroots form of cross-site content discovery; to make "best of site content" easy to find.
END GOAL: To replace the Memories function with a new form of site-wide bookmarking, similar to the functionality of del.icio.us, in which users can tag other people's posts and assets for later retrieval. To track both how many times a specific entry is saved by someone else, allowing users to find the most popular or most-talked-about entries, and how recently an entry was posted and/or first tagged, allowing users to find the freshest content for a specific tag.
- Comments to Bug 210 (and predating the demise of Delicious) suggest that allowing cross-site bookmarking is a good extension of this. Could also allow for people importing bookmarks of other websites and from other services; I think a bookmark importer is important, but am unsure if it has to go out as part of the first release.
- In said Bug 210 comments,
mark mentions canonicalization of on-site URLs; I responded to rb earlier today about the possibility of canonicalizing URLs for both entries and comments.- I may need to come back to the Motivation and End Goal bits, but let's move on.
BACKGROUND: The existing Memories function hasn't been updated in a very long time, and it wasn't very usable to begin with. With the advent of tagging, many users ceased using the memories function and switched to tagging, but tagging has its limitations -- one can only tag one's own posts, for instance.
This project will create a new type of tag -- the "bookmark tag" -- which can only be applied to assets that the user does not own and/or assets that are posted in a community. By applying a bookmark tag to an entry or asset, the user indicates that they'd like to save that asset for later perusal.
Bookmark tags should be freely creatable and editable by the user, so that the user can name and categorize their tags in any way they'd like. Individual cultures can then define a community-consensus folksonomy to allow them to find their preferred content.
When in doubt, this feature should follow the model set forth by del.icio.us.
- I'm not sure I understand why "bookmark tags" should only be applicable to assets the user doesn't own, and this part may be undesirable given that I think the model should allow for bookmarking comments, which aren't currently "taggable." I do see things on Delicious where the author of a given post has tagged it "by:me," or where a specific Delicious account is dedicated to only listing the fic they themselves have written. That's a case where you couldn't post the fic itself directly to the Delicious website, though, so - is some of the logic so that people wouldn't bookmark their own stuff as a spammy form of self-promotion? Is this likely to be a big enough problem?
- Hierarchical tags, and bundles. I honestly didn't use bundles enough, and would love to talk to people who did use them. I liked the idea, I just felt like by the time I discovered bundles, I already had too many tags to sort through. Were there hierarchical bundles? Could those help in the organization of tags? Would that mean we'd still need hierarchical tags?
- Multi-word, comma-separated tags. Yes, please. These are lovely. Just, kindly inflict no repetitive NAGIOS-style popups on people about how awesome comma-separated tags are.
- Case-sensitivity in tags. Oh god oh god oh god please no is my gut reaction. Let people enter things in whatever case they want, but force toLowerCase() on submission. Obvious complications when character sets get outside of [a-zA-Z0-9] - do we force canonicalization there?
- I think I've gotten off-track.
The feature should only allow bookmarking of top-level assets -- entries, pictures, etc, not comments -- and should only allow bookmarking of content on the site itself.
- Both stricken, with good arguments as to why those limitations shouldn't exist. :)
REQUIREMENTS:
This feature will create two new areas: the bookmark viewing area (where the user can see all entries that they've bookmarked), and the bookmark management area (where the user can manage their bookmarks). The bookmark viewing area should be divided into four tabs: your bookmarks, your network's bookmarks (content from your watched & trusted contacts), your extended network's bookmarks (content from your friends-of-friends), and the whole site bookmarks (content from everyone). The bookmark viewing area should also allow you to see bookmarking history & details for a specific URL.
- Does this mean that I *have* to subscribe to someone to see their bookmarks? Or, conversely, that if I subscribe to someone, I *have* to see their bookmarks? What if I'm following their journal for photography tips but really couldn't care less about their bandom bookmarks? Does it make any sense to separate these two functions? [It will add complications; the question is, what are those complications, and are they worth it?]
More questions as we go through each area.
BOOKMARK VIEWING AREA:
The feature must:
* Allow you to see all of the bookmarks you've saved, either altogether or by specific tags or tag bundles.
* Respect privacy levels -- a locked or private entry should never appear in the extended search results, even as a title + number of times tagged.
* Canonicalize an entry for the purposes of counting bookmarks (ie, with/without ?style=mine, ?format=light, #cutid=1, etc -- all should count as the same entry).
* Allow you to search for specific tags, both on your own bookmarks ("show me all things I've saved that are tagged 'rant'") and on other people's bookmarks ("show me all things my friends have saved that are tagged 'family'").
- No arguments with #1. :)
- No arguments with #2 for onsite bookmarks. Less certain about how to enforce that for offsite bookmarks, if it's even at all possible.
- Agree completely with #3, with the caveat of canonicalizing "entry" and "comment" separately.
- Thumbs up to #4. :)
The feature should:
* Allow you to see a specific user's set of (public) bookmarks and bookmark tags.
* Allow sorting by multiple settings: date entry was posted; order that entries were tagged by you (personal bookmarks page), both oldest-first and newest-first; order that entries were added to the tag by others ("show me the entries that have most recently been tagged 'friends' by others"); most-frequently-bookmarked under specific tags.
* Maintain a tag cloud of the most popular tags used (by you / your network / your extended network / site-wide).
* Track and display how many times the entry has been bookmarked, both by your friends and by members of the site as a whole.
* Provide a link to a page showing the number of times the entry has been bookmarked by others, along with any comments that other users left while bookmarking the entry.
* Show common tags on the URL detail page (aka, "other tags that are used for this post") to encourage tagging-system standardization among subcultures.
- Total agreement for #1.
- Sheer love for #2, with one minor caveat for off-site bookmarks: not all off-site content being bookmarked will have dates associated with them. Not sure how to handle that at this stage - make an assumption that for the purposes of sorting, if we can't automatically determine the original posting date of off-site content, call its "date entry was posted" the date that it was first bookmarked on DW?
- Thumbs up to #3.
- Love #4's extension on the original Delicious functionality.
- I miss #5 on the new Delicious so much already it's ridiculous [missing comments/notes]
- I'm down with #6.
The feature could:
* Allow you to automatically post your bookmarks to your journal (once a day/once a week/etc).
* Allow you to easily see all of your entries that have been bookmarked by others.
* Allow you to easily see which of your entries are most frequently bookmarked by others.
- #1: Ooh, yes please. Especially if I could make multiple "jobs" where, for example, all "tech" bookmarks get crossposted to my journal daily, but all "recipe" bookmarks only get crossposted weekly.
- #2 and #3: Would this display on the entry itself? Would it be useful for others to see this metadata, or should this only display to the logged-in journal owner/community admin?
It would be nice if:
* The tag search area could be boolean-searchable ("fic +sg1 -slash").
* While viewing a specific user's bookmarks page, you could then view *their* network/extended network as well.
* Communities could bookmark entries the same way personal journals can.
* While viewing a community's bookmarks page, you could then view a page for the bookmarks of all the community members.
* Community maintainers could empower community members to bookmark pages on behalf of the community, without having to give them maintainership.
* The feature offered a RSS feed of just a user's bookmarks -- all bookmarks, specific bookmark tags, etc.
* The tag search results let you specify a threshold ("only entries saved by 2/5/10/etc people")
- I love all of these suggestions, especially the idea of booking something for a community. Re that - who should have permission to bookmark things for a community? Admins only? Community members? Could this be a setting in the community itself?
***
BOOKMARK MANAGEMENT AREA:
The feature must:
* Allow for multi-word, comma-separated bookmark tags.
* Allow for private saving of bookmarks -- a user should be able to bookmark an entry and have it not appear in their friends' viewing area, not have their username/their comments appear in the bookmark count page, etc.
* Allow you to bundle tags, by creating a bundle name and assigning tags to that bundle.
* Allow you to leave optional comments on a bookmark, explaining why you bookmarked the entry.
- Absolutely for #1, #3, and #4.
- #2: New Delicious has done this awful thing where when you click to save a bookmark, it SAVES IT PUBLICLY BEFORE LETTING YOU SPECIFY IT NEEDS TO BE PRIVATE. Before you can even add tags to it, or ANYTHING. Should we put a thing in where the "latest public bookmarks" page won't display any public bookmarks newer than ~5 minutes, a la the "latest posts" page?
- Edit: Also for #2 - if a user bookmarks something privately, I can totally understand why their username/comments/tags should not appear in the public meta-page for that bookmark. Should the fact that said user has bookmarked it count towards the displayed "# of people who have bookmarked this thing"? What if only one person has bookmarked something, and done so privately (or friends-only) - should the display count be 1 (indicating "somebody has bookmarked this, even if we won't tell you who or give you any details") or 0 (giving no indication)?
Is it enough of a privacy violation the fact that "somebody" has bookmarked that something?
The feature should:
* Allow for bulk-editing of bookmarks -- an easy way to remove a specific tag from all bookmarks, delete the bookmarks altogether, etc.
* Allow you to rename the title of a bookmark, so that you don't have to rely on the title that the entry/asset was given.
* Allow you to make entire bookmark tags locked or private ("don't show anyone that I have a bookmark tag of 'sex'")
* Show the date when you bookmarked the entry.
* Allow you to bulk-rename a specific bookmark tag ('fiction' to 'fic', for instance).
- Enthusiastic agreement re all of the above.
The feature could:
* Allow you to send individual bookmarks to other people's inboxes ("links for you")
* Allow you to block specific individuals from sending bookmarks to you.
* Allow you to opt out of anybody sending bookmarks to you.
- Works for me, and matches current options for other things.
It would be nice if:
* The feature allowed for tag descriptions (short summaries of what goes in the tag, like describing "good fic" as "things that I really liked and want to come back and re-read")
* Tag descriptions could be set to either public or private, independent of the tag itself.
- I like these options, and don't have any strong objections to them. Am pondering how and when the tag description would display.
Edit: I also meant to toss out the idea of "access-only" bookmarking - letting you make a bookmark that only people to whom you give access on your droll [wow, that seems like really awkward wording] can see. Less private than private bookmarks; more convenient than "sending" a bookmark to multiple peoples' inboxes as the bookmarks themselves would show up directly in the "network feed" where you read all of your friends' bookmarks. I assume that sharing bookmarks with custom groups could be a natural extension of this, though maybe not part of the first-round draft?
