Connection News, again
If you haven't recently, take another look at Connection News. I've given it a few new features and much faster.Connection News has been the best feature nobody uses. It was good in theory, but it was slow. It's much faster now. As SilentInAWay put it:
"... [T]his afternoon, it took about a minute and a half to load this page for my interesting libraries. With this speed-up, it took several seconds to load the page the first time that I invoked it; for all subsequent loads, however, it has taken about a second. Wow!"Connection News now tracks "newness"—putting a little "NEW" marker next to books, reviews and ratings if they're new since the last time you looked at Connection News. To discuss the feature and suggest improvements, check out Talk.
Labels: connection news, optimization, speed
posted by Tim at 10:01 AM
16 Comments:
I haven't used this because it doesn't support RSS. I don't poll for news, in general.
Unfortunately I can't see any speedup :(
I've been using it a bit! Helps me keep up with my interesting libraries and when new books are released. I've got some great recommendations through this feature too! Glad to hear it is going to run faster.
I have to disagree--it's not the best feature that nobody uses, it's the potentially-best feature that didn't get developed enough. There's just not enough customization. I regularly look at multiple individual libraries because I can't do what I want with connection news.
I don't see _Zoe_'s comment here yet. I hope it will show up.
Do you want the ability to make custom lists, is that the missing part for you?
Slightly confused about your ability to respond to my comment without seeing it....
But yes, custom lists are a big part of it. Both custom lists of people and custom field selection. At the very least, I want to be able to see more than just date added, reviews, and ratings. It would be even better if I could look at multiple fields in a single list. My friends are extremely inactive, so a combined list of books added and reviews and ratings entered would be better than checking each list individually, often in vain.
Sorry. I get it by email, but it wasn't posted.
A combined "friend feed" is coming. It's computationally more expensive, so I'm working on it. My opposition to caring about the date-read stats is often stated. The answer is to note when a book is put on a currently-reading list, which is also coming, but not coming immediately.
Special list may be coming. I'm certainly going to offer the ability to see all your categories together in a list.
As far as I'm concerned, that's no answer at all. As long as the feature is based on you telling people what they should want to use it for, it's not going to be nearly as good or popular as it could be. The reason LT is better than other book sites is its flexibility and the amount of data we can enter about our books. You should be trying to make the most of that, not trying to force everyone into the same mold.
Developing is choosing. What will make people happy? What are the costs of doing it? I have to make choices.
I could spend the day on the feature you want—and cut off another slice of limited RAM to make sure it was fast—but as it would be used by very few and would, I think, actually turn many off insofar as the data is so paltry, I am choosing not to.
Hi Tim, I think this feature might be popular more if it had its own tab.
Maybe you could drop the Talks tab (it is a Groups feature) and introduce a Friends tab to make more people aware of this. You could call it Connections if you wanted to.
There's no way it would take you all day to add date read to connection news; I'd guess more like 15 minutes. It would be the exact same code that you already have for entry date, except that you might have to deal with the fact that not every book has data in that field.
Your paltry data is a self-fulfilling prophecy. People enter that data far more on Goodreads, because Goodreads makes it easy. You hide the field away at the bottom of the disorganized edit page, you don't include it in any of the five default display styles, you don't bother fixing a huge bug that makes it disappear from the catalogue if people aren't careful, and you exclude it from every feature. Anyone who manages to find it and use it successfully is almost by necessity a power-user, so of course their opinions aren't representative and shouldn't be considered.
Your argument that most people don't use the field would mean something if you'd given them a chance to do so, but that's not the case. If you had it in Display Style A (do you really think the average person cares much about the publication date?) and on the Add Books page, if you displayed people who had recently read a book on the work pages along with people who had recently entered it, if you made it more user-friendly by letting people enter only the month, if you gave Chris a bit of time to finish his timeline, and still there was no interest, then I'd be convinced that the average user didn't care about it. As it stands, your opinion of it has prevented the average user from having a chance.
>>There's no way it would take you all day to add date read to connection news; I'd guess more like 15 minutes.
I count 14 steps. At one minute per step, you're right.
1. Fix existing problems with the dates.
2. Decide if this is to cover date-read or date-started too, whether it is to count multiple data reads, etc.
3. If new schema requires something like month-but-not-day, change database to accomodate new understanding. Take system down for 30 mins at night. If fuzzy dates are allowed, that's a whole new set of functions too.
4. Find everywhere in the application the relevant dates can be changed or accessed, or the underlying data can be shifted to a new understanding (eg., deleting books, updates via import, user-name changes, etc.)
5. Add a new function that generalizes this, because all changes will now need to be routed through memcache not the database, which was formerly the only thing that needed changing. The db is too slow for connection news to pool this and other types of data points for many users under a second or two.
6. Create functions for retrieving, filling, expiring and restoring the memcached data when requested.
7. Create functions for refilling memcache to an acceptable level after a server crash and put it on the list of functions that get triggered when this happens.
8. Document new data structures formally and informally with Chris.
9. Test it.
10. Push it.
11. Post about it.
12. Watch error log and talk post. Watch talk more closely for a few hours because bugs may pop up in other contexts.
13. Argue with users who think that the system should be tracking multiple dates or whatever is not to their liking. Make changes after users insist.
14. Fix bugs that come up, each time resetting the memcache version and pusing new versions to the machine.
Oh, I forgot: Lose place in code because other duties make it hard to set aside 8-12 hours of coding. I got a call today that will pay someone's wages for 6mo. But it requires work and not on this. That's life.
Look, development is not easy. With a database the size of the Library of Congress running on a few commodity servers, with developers stretched thin, with a train at 8pm to catch tonight, laundry to do and a kid that needs occasional tickling, it's harder still.
1. Hopefully something you were planning to do anyway, but certainly not something I expected for this. It could just be a combined feed of old and new date data.
2. Don't worry about multiple dates or date started.
3. Obviously showing date read in connection news does not require month-but-not-day.
(For 2, 3: This is where you went wrong with currently reading in the first place: You said then that it was sometimes better to deal with all the complexity at once, partially added multiple dates, and we ended up worse off than we were before you'd done anything.)
4. All the ways you already considered for entry date, plus catalogue and edit screen.
5. I'm still not seeing how this is vastly different from what you already have for entry date. Ditto 6, 7, 8....
13. But you're doing this already, at least the first part :)
Okay, I understand that things have gotten messy because of the partial implementation of multiple dates. I know development in general is not easy. But when you've already done something for one field, does replicating it for another field really require starting from scratch?
But congratulations on that phone call! I'm sorry I complain all the time. It's just extremely frustrating that what I consider one of the key parts of the site (I discovered LT not because I wanted to catalogue my books, but because I was looking for lists of what other people had read) is partially broken, and that the solution seems to be to ignore it and hope everyone forgets about it. Doesn't it seem crazy that instead of using the data you already have (date started, which could be linked to currently-reading with an opt-out), you're going to start storing other data about when the book is put on the currently-reading list, so that many people will choose between either the date fields or the currently-reading checkbox, making both less useful?
I use connections news quite a bit. I've gotten some great suggestions for books based on other peoples additions to their libraries (not that I need any more suggestions considering my current tbr pile and wishlist, but I'd hate to miss out on something great!) I think it is a great resource!
The answer is to note when a book is put on a currently-reading list, which is also coming, but not coming immediately.
Can I jump in to ask what may be a very dumb question? How do these "currently reading" lists work? I just now took advantage of the opportunity to check this box on my book edit page, and it didn't come up on my profile. I've tried to go back into all the talk threads, blog postings, etc., but have not found an answer to my question. I know that profile-updating was the plan, but does this checkbox not actually do anything yet? Many thanks...
Topper
Post a Comment
<< Home