An assortment of items for a Friday
This LJ code release means the death of memories. Unless you need more than 1000 entries in a tag, that is. The report says something about their implementation: they cache the last N entries tagged, as tags are added; the cache is permanent and not (say) lazily evaluated as tag-pages are requested. I wonder why there's a limit at all. Can easily
( Read more... )
I don't think it does, actually. I mean, it may, in the sense that LJ may decide not to continue supporting the memory function, but it doesn't remove the usefulness of memories.
(1) You can add things to your memories that are not in your LJ. I can't tag your posts. I can put them in my memories, though. (Yes, I could use del.icio.us, but I'm comparing LJ's memories to LJ's tags. It's meaningless to say "LJ raising the tag limit to 1000 makes the memory function outdated because you can use del.icio.us.") I can use *your* tags to view things, but maybe I don't like your (generic you) tagging system. Or maybe I want to see *all* of the Hiro/Ando fic from LJ that I like, all at once, instead of visiting person A's hiro/ando tag, ad then person B's, and so on.
(2) Memories give just that single-line description. For things like crack_van, where the memory description is the title and author of the fic being recced, that's much, much more useful than clicking on, say, the "x-files" tag and getting a list of all the recs. (Particularly, I'd say, for the people doing the reccing, who need to see if they're repeating themselves. But also, I'm a lot happier searching through 200+ titles than 200+ *posts*.
(3) Memories are, to a limited extent, sortable. (You can choose to view them by order added, by description, or by the journal the post was made in.) Tags are not.
(4) This is the purely subjective reason: some people prefer memories to tags. (I use both, in somewhat different ways and for somewhat different reasons--my tags are arranged for other people, but my memories are for my own use, more or less--but I know there are people, still, who do not have any desire to use tags on their posts, period. Some people find a system that works for them, and until it stops working for them, they see no reason to change just because there's something new out there.)
Reply
- At most five memory-tags per entry. Many fic recs posts need more than that. I've memoried a couple that needed twice that. No such limitation on tags.
- Note that crack_van limits its format to one story rec per post, which we don't. There isn't enough space in the memory title to adequately describe many GFR omnibus posts. The post browsing interface does better for this case.
- The process of adding a GFR post to a memory is agonizing. It requires two separate page loads (add post to memories, switch to doing so as giles_fic_recs not as me). Type text, with the entry itself in another window so that I can compose a reasonable description. Copy-n-paste tags, then delete some if necessary.
Have been thinking about ways I would improve this interface if I were to, say, write a suggestion to LJ's developers. Memories are a bookmarking feature, and a somewhat half-designed one. Del.icio.us does a better job in most ways (though space-delimited tags are a criminally bad design choice; not that I am harshly judgmental in any way).
Neither approach is perfect. It's all about the specific use case. When I compare the delicious bookmarks for my fiction to the Memories, I see some immediate reasons why the delicious implementation is preferable. Brief summaries are probably #1, along with tag bundles. (I also note that I could improve my memory titles if I were energetic.) LJ's post prologue browsing interface for tags also isn't as good as del.icio.us: the prologues are too long, and there aren't enough of them per page. OTOH, the bookmarks aren't sortable, which as you point out is a good feature.
The summary field is the key difference.
This oddly is not entirely academic to me, which is probably why I just spewed a bunch of random thought at you :). Have been thinking about how I would design a giant fanfic archive, and how I would solve the browsing problem. I have a couple of interesting ideas that I haven't seen in earlier archive implementations that might make it a cool project.
Reply
And because I thought you were speaking in general terms, I was pointing out a specific instance in which the memories are more useful than tags would be.
I don't disagree that del.icio.us is better than LJ's memories feature; it's also better than LJ's tags. OTOH, I was, again, comparing LJ-specific features to one another.
The summary field is useful, but then again, del.icio.us's benefit is that it's the reader who supplies the tags and the summary, and not the initial poster (they can be the same person, obviously, but they do not have to be). I may find your (again, generically) LJ tags completely worthless for my own purposes, and can use del.icio.us to apply tags that are meaningful to me. I rarely use the summary fields on del.icio.us, just because the tags give me the information *I* need, as a rule, and those tags are for me. *g*
I don't, actually, find tag-bundling all *that* useful, except for keeping similar tags sorted in the sidebar, which I could have done via hierarchical tagging. And, in fact, *do* by hierarchical tagging in some cases, because it's how my mind works.
Reply
I have also observed the problem that sometimes an author's tags are kinda bad, and that my own are better. I love the idea of last.fm style reader-supplied tags, with weighting so you can see which tags readers have applied to a story by consensus. Add Bayesian analysis to this mix ("other stories with this content had these tags applied to them, therefore perhaps the tags also apply to this story") and you get something useful that routes around author insanity.
Memory-making for GFR is time-consuming, and time is, alas, one of the things I'm shortest on. I was thinking earlier today about whether I could script it somehow. And the answer is yes: LJ's API has methods for dealing with memories. This might be the fastest path. Snag tags, sort by priority, drop off low-priority tags past the five-item limit, add to memories. The title is still useless most of the time, though. Argh.
One thing that I'm pretty clear on is that services like this need to cater to a variety of access methods. Which is to say, that any way readers want to get at the data is a way I should consider assisting. Building an index is also something I should consider doing. Which is another way of saying that I have my own opinion in re tags vs memories, but I'm also quite sure that what the users of a resource want is more important than that opinion. (User-centered design!) I just need to find a way to make tools to do it for me.
Reply
Leave a comment