I asked this in the 'site improvements' group but got
no replies whatsoever :( The 'author' and 'title'
catalogs under librarything.com/m are indexed by
simple integers; it would be much more useful if
they were indexed alphabetically: ie. replace links:

1 2 3 4 5 ...

with new links:

A B C D E ...

where a click on 'A' takes you to authors (or titles)
beginning with 'A'. This is so obvious that I wonder
why it hasn't already been implemented, and so worry
if there's something obvious I've missed!

Hopefully I'll do better in this thread than on my last
attempt :)

Mike

Probably not... as it says in the group description "This is a group for LibraryThing to announce and discuss new features and other improvements with members." Only LibraryThing staff should start discussions here. You did the right thing when you originally posted in the other group.

This particular feature has already been requested and discussed many times for the standard catalog, and it has been said that it is actually more difficult to do than it seems.

Thanks! That makes sense.

I don't think it would be difficult to implement, but it would keep the database quite busy calculating where our A's B's etc begin.

Only if it paginated at the A's directly. If it kept the current pages and simply displayed letter sequences instead of numbers, that would work fine.

5>

No, it still needs to know "the M's start on page 37", even if the top 3 results on page 37 are L's, to be able to jump to the right page. (Actually it needs to know 'the first M result is #845' or the equivalent to be able to handle different numbers of results per page.)

This is one of those things that seems like it is quite easy to do but in reality is exceptionally difficult. Impossible? No. Difficult to the point of being improbable? Yes.

Thanks for thinking about it! If you do figure out a
way to do it without undue load on the DB, do consider
it a low hanging fruit: it's very frustrating hunting
around for a particular author/title at the moment!

Mike

I agree. I'd like to have it myself. After all, I use LT for my book collection too. :)

6>

You know, I'd be pretty happy if it just displayed the letter of the first item on the page, even if item two started a new letter. It would still get you a heck of a lot closer to where you were aiming than guessing wildly.

I'm guessing that would be somewhat easier to program, as well. You would have to figure out what to do when the catalog was sorted by a non-alphabetic field (would you just display the first digit of the Dewey #? How about Entry Date?), but first letter of first entry on the page would work well for the far more common author, title, and tag sorts.

6/7: I'm talking about turning

1 2 3 into

A-Ax Ay-Ch Ci-E etc

Keeping the same pagination, but looking at the 1st and last letters of the author record would be easier than doing sections directly.

That's really not any easier. The problem is that in order to figure out where "G" starts within your catalog you have to actually fetch ALL of the your catalog. There's a longer explanation but that's the gist of it.

11: If you have 10 pages in your catalog we only fetch the records from a single one, but we know how many total books you have so we can build the pagination from that. See my previous comment for why alphabetic pagination is a problem.

Now, we could certainly switch over to a COMPLETELY alphabetic pagination and we could solve the issue, but I think that we'd just open up other problems with that (variable number of items per page, sort pagination issues, etc.).

Not just the records at the page breaks?

1, 20, 21, 40, 41
1, 100, 101, 200, 201

I think that conceptDawg's message 12 "longer explanation" would include some calculations showing that asking the database for (sort this guys library on title and get record 1) (sort this guys library on title and get record 20) (sort this guys library on title and get record 21) (sort this guys library on title and get record 40) .. is probably worse than (sort this guys library on title and get all records) by a large factor.

Remember that the database isn't as clever as a human, so it might very well perform a complete sorting for each of the single record queries since it doesn't know for sure that nobody changed anything since the previous sort. Even if it is clever enough to notice that the sorting isn't necessary, it means that the database should keep the result of the sorting around for a while and that might not be a wise thing. It is a standard tradeoff between using lots of memory or lots of time, and this might even be a case where the database needs lots of memory and lots of time.

One of the problems with databases is that it is very easy to ask for something that takes a tremendous amount of time to answer and databases aren't clever enough to tell you that you asked a stupid question. I honestly don't think this is a lowhanging fruit. It would be a nice addition if LT had memory and cpu's to burn but they don't.

Just to make a long message even longer :-) consider that some of us might sort on something silly as publication date, so my 4000 books would show up as 200 pages with a lot of them displayed as 1976-1976 and stuff like that. Also some sorting programs are really bad if you sort a lot of identical keys, so this could trigger some weird behaviour.

We already know that there is an index on each person's catalog since it gets out of whack every once in a while and cD has to reindex it; in fact there must be an index for every column that you can sort on. But that's as far as my db knowledge goes. I don't know if it's possible or efficient to have it retrieve just records 1, 51, 101... in the order of those indexes.

Also what about i18n issues? Many people have books with titles not in the normal ASCII range - ranging from accented French letters to completely different alphabets.

Also you would still need numeric pages for sorting by most of the other fields - only author and title can really be alphabetised.

I would agree that there is far more than meets the eye.

17: Slightly off-topic, but... the index is just used by the catalog search code (even LONGER story there...don't get me started). The rest of the site interaction is straight database interaction (with a healthy dose of memcache and other caching buffering it).