This topic is currently marked as "dormant"—the last message is more than 90 days old. You can revive it by posting a reply.
1timspalding
As some of you saw, we thought we were going down for an hour last night, and we were down for nearly eight—Yuck.
Basically, the process that went so smoothly and under-time on Sunday night went horrid last night, through a mix of user error (mine) and random weirdness. We ended up having to perform some rather taxing operations on large database tables, and that took time. Until about 4am, the problems were hardly noticed, leading us to underestimate how long it would take to finish.
We're now up, although one of our main databases is still recovering, so we're in "throttled" mode, which turns off non-member access to some pages. We will be fully up soon.
Anyway, apologies and thanks.
Tim
Basically, the process that went so smoothly and under-time on Sunday night went horrid last night, through a mix of user error (mine) and random weirdness. We ended up having to perform some rather taxing operations on large database tables, and that took time. Until about 4am, the problems were hardly noticed, leading us to underestimate how long it would take to finish.
We're now up, although one of our main databases is still recovering, so we're in "throttled" mode, which turns off non-member access to some pages. We will be fully up soon.
Anyway, apologies and thanks.
Tim
4Nicole_VanK
As Master Yoda would say: Sith happens.
7pgmcc
How long did it take you to select the titles for the down time screen?
I suspect they were not chosen at random, nor piled in a haphazard fashion.
The paradox of excellence
L.A.Dead
Waiting
A spot of bother
Chaos
You suck
The corrections
Out of crisis
Good to great
I suspect they were not chosen at random, nor piled in a haphazard fashion.
The paradox of excellence
L.A.Dead
Waiting
A spot of bother
Chaos
You suck
The corrections
Out of crisis
Good to great
9keristars
I really love the down.php page. Even when I'm disappointed that LT is down, the bookstack makes me grin.
10Nicole_VanK
Yeah, at least it's a fun down sign.
12timepiece
I wish the bookpiles on the down.php page would rotate. I'm so used to that one by now, a different one would likely distract from from the fact of being down.
13pgmcc
#8
Thank you! It was too logical a sequence to be chance.
It reminded me of the mock phases of a project where it starts with ignorant enthusiam, and moves on to such things as grudging acceptance and the long, dark night of the project manager.
Thank you! It was too logical a sequence to be chance.
It reminded me of the mock phases of a project where it starts with ignorant enthusiam, and moves on to such things as grudging acceptance and the long, dark night of the project manager.
15Read2Me2010
You all do a terrific job. It is a great website that I couldn't do without. Thank you so much. Now take a nap.
17timspalding
No, it's all for scaling and speed. Half of the changes we made worked. The other half, um, didn't, and had us in trouble for much of the day. I spent the day working on queries and schemas that continue to give us problems. I found a few I could solve with the system running.
My goal is to have your catalog never take more than 10 seconds to load. 90% of the time, we're already there. Indeed, the median time is less than 1 second of processing. But there is a stubborn 10% of the time when loading your catalog is simply unacceptably slow, especially for larger catalogs.
My goal is to have your catalog never take more than 10 seconds to load. 90% of the time, we're already there. Indeed, the median time is less than 1 second of processing. But there is a stubborn 10% of the time when loading your catalog is simply unacceptably slow, especially for larger catalogs.
18Heather19
Is it under certain conditions or something? I mean, are there specific things (collections, power-edit, whatever) that make the catalogue take longer to load? (I love learning how this site works)
20timspalding
There are various components to site speed. We work on data structures and database queries. We work on web servers. We use caches of various sort. We are working on issues like this much of the time. At present, we are working on making Your Books faster, especially for users with lots of books, and especially on the "first hit" of the day.
The problem boils down to this:
Disk is slow and memory is fast. LibraryThing's data is much larger than fits in memory. It's about 225GB in total—with maybe 175 of that being directly active stuff.
Mostly, things are okay, and the problems are more about query design and changing dynamics of a complex system than core limitations. MySQL does a good job keeping the parts of it in memory that are used the most, and therefore most likely to come in handy. Basically, as bits of data are drawn from the disk, MySQL also tucks them away in the buffers and caches. Stuff in the buffer pool "ages out" over time, as new stuff comes in. Common stuff tends to be in, uncommon stuff out. Thus at any time, the basic info for most common works, ISBNs, editions, authors and so forth are in memory, in whole or in part. Rarer stuff takes longer to get, but rarer items also tend to have less data associated with them, so there's a balancing effect. Some categories of data—aggregate data, like recommendations, etc.—are cached in other ways.
You can see this effect all over the site. Some pages are fast and some are slow. If you find a slow one, and it takes, say, 5 seconds to load, you can usually rely on it to take much less time if you hit it immediately after. But wait an hour and the page may return to a 5-second load--assuming nobody else has hit it, or its resources.
The central Your Book tables, however, are both very large and rather "isolated" from other data. They are not commonly queried extensively in the course of normal business, as other tables are. The data in them are not commonly needed until it's needed. As a result, when a user with a lot of books hits the site for the first time in some hours, his data can take a while to "warm up" and initial pages can be excruciatingly slow. It's a long tail. In the last ten minutes, for example, members hit 31, 19, 9, 8 and 5-second queries on "Your Library," the queries probably corresponding to most of the time it took the page to load. Every other query—and there were many—was under five seconds.
How large is large? It depends. I'd say it gets potentially annoying after 1,000 books, but more commonly after 2k or 3k. People with 10k libraries will usually see a very long wait time on the first catalog page they hit. This applies, of course, to when you look at someone else's library too.
We're working on the large-library problem. So far, we've chipped away relentlessly at the speed of Your Books, but the improvements have mostly affected the fat middle. So, we're looking at some other ways of approaching it.
The problem boils down to this:
Disk is slow and memory is fast. LibraryThing's data is much larger than fits in memory. It's about 225GB in total—with maybe 175 of that being directly active stuff.
Mostly, things are okay, and the problems are more about query design and changing dynamics of a complex system than core limitations. MySQL does a good job keeping the parts of it in memory that are used the most, and therefore most likely to come in handy. Basically, as bits of data are drawn from the disk, MySQL also tucks them away in the buffers and caches. Stuff in the buffer pool "ages out" over time, as new stuff comes in. Common stuff tends to be in, uncommon stuff out. Thus at any time, the basic info for most common works, ISBNs, editions, authors and so forth are in memory, in whole or in part. Rarer stuff takes longer to get, but rarer items also tend to have less data associated with them, so there's a balancing effect. Some categories of data—aggregate data, like recommendations, etc.—are cached in other ways.
You can see this effect all over the site. Some pages are fast and some are slow. If you find a slow one, and it takes, say, 5 seconds to load, you can usually rely on it to take much less time if you hit it immediately after. But wait an hour and the page may return to a 5-second load--assuming nobody else has hit it, or its resources.
The central Your Book tables, however, are both very large and rather "isolated" from other data. They are not commonly queried extensively in the course of normal business, as other tables are. The data in them are not commonly needed until it's needed. As a result, when a user with a lot of books hits the site for the first time in some hours, his data can take a while to "warm up" and initial pages can be excruciatingly slow. It's a long tail. In the last ten minutes, for example, members hit 31, 19, 9, 8 and 5-second queries on "Your Library," the queries probably corresponding to most of the time it took the page to load. Every other query—and there were many—was under five seconds.
How large is large? It depends. I'd say it gets potentially annoying after 1,000 books, but more commonly after 2k or 3k. People with 10k libraries will usually see a very long wait time on the first catalog page they hit. This applies, of course, to when you look at someone else's library too.
We're working on the large-library problem. So far, we've chipped away relentlessly at the speed of Your Books, but the improvements have mostly affected the fat middle. So, we're looking at some other ways of approaching it.
21SilentInAWay
I'm definitely noticing a speed-up searching my catalog.
My library is approaching 7000 books, and searches have often been so slow that I've taken to finding books in my catalog by searching LT for the author and then clicking on the "see yours" link on the author page.
I just tried searching my catalog directly a few times -- each query took only seconds to display!! The first search took the longest; subsequent ones were very quick!!
Is this the result of your efforts, or low traffic right after the site came up?
My library is approaching 7000 books, and searches have often been so slow that I've taken to finding books in my catalog by searching LT for the author and then clicking on the "see yours" link on the author page.
I just tried searching my catalog directly a few times -- each query took only seconds to display!! The first search took the longest; subsequent ones were very quick!!
Is this the result of your efforts, or low traffic right after the site came up?
22thorold
I'm daily expecting Tim to turn up in my library with a wheelbarrow to take away everything from University of Oxford Examination Decrees and Regulations to Harry Potter and the Philosopher's Stone for redistribution to less fortunate members, leaving me with only my 999 most obscure books. Little does he know that the dead weight of the 1980 Examination Decrees is a vital structural component of my bookshelves, and anyone attempting to remove it risks provoking an avalanche...
Actually, Your Books seems to be very fast this morning - you're obviously doing something right. Or is it just too early for America?
Actually, Your Books seems to be very fast this morning - you're obviously doing something right. Or is it just too early for America?
23timspalding
Probably random. But thanks :)
24timspalding
It's too late for America!
25timspalding
Believe me, we won't know if we gained at all for some hours. Right now, we're running on only 3/4 servers—one had to be taken down and mucked with to improve its performance. It'll be afternoon tomorrow before the caches will be as full as they were before we went down.
26MarthaJeanne
Could you please try to warn us in advance if we are going to wake up to no LT? I know you put up a warning an hour or two before, but that isn't very helpful to those of us outside the USA. I've been on the past three evenings until 10 or 11 pm 4-5pm your time), and then in the morning the site has been down. I understand that you can't always give 12-14 hours notice, but when you can it would really help.
This has hit me rather hard, as I have been trying to prepare printouts for a trip, and although all the complicated formatting can be done anytime, I need LT to get the raw data. If I'd known, I could have done the copy paste part the night before.
This has hit me rather hard, as I have been trying to prepare printouts for a trip, and although all the complicated formatting can be done anytime, I need LT to get the raw data. If I'd known, I could have done the copy paste part the night before.
27MrAndrew
The screen colours are brighter, my mouse is scrolling faster, and my beer is 2 degrees cooler this evening. Thanks!
28FicusFan
I was just in a series page, and clicked on a book link to go to the book page, and it timed out :(
Only 133 people on the system.
Only 133 people on the system.
29timspalding
Here are the results (the black parts should be ignored). Basically, things got faster. This isn't showing the issue I mentioned—what happened to the really long catalog accesses?
30theapparatus
>It's about 225GB in total—with maybe 175 of that being directly active stuff
Please tell me you're not doing all that directly to disk.
Why not just do what the social networking sites do and get a couple (or hundreds) of cheap boxes with as much memory as you can in there and memcache the site?
We do that for our inhouse antispam solution. Have a pair of 96 gig servers, load their databases to memcache and save them once every 10 minutes to disk, one on the 1 minute and the other on the 6 minute.
As to the searching, got to admit that I just do a site search to find one of my books. I don;t search off of my profile page. Does take a while.
Please tell me you're not doing all that directly to disk.
Why not just do what the social networking sites do and get a couple (or hundreds) of cheap boxes with as much memory as you can in there and memcache the site?
We do that for our inhouse antispam solution. Have a pair of 96 gig servers, load their databases to memcache and save them once every 10 minutes to disk, one on the 1 minute and the other on the 6 minute.
As to the searching, got to admit that I just do a site search to find one of my books. I don;t search off of my profile page. Does take a while.
31Aerrin99
I have noticed a number of things on the site moving faster - work pages and my catalog in particular seem to have had a couple of seconds shaved off for me, and while I might attribute it to blips in my network, it's been happening consistently enough for me to think it's something more.
So hooray for that!
So hooray for that!
32timspalding
>30 theapparatus:
So, a few thoughts on your post.
1. The goal is to have as much come from memory as possible. How it's in memory is irrelevant, and I'm sure you will agree. If we can get it from memory most of the time, but the memory is a buffer pool or query cache, that works.
Although we have 200GB of data, it's a long-tail dataset. The most active data is maybe 5-10% of that. As a result, most "disk" queries do get pulled from memory, not from disk.
As stated, the problem is that some of the long tail can get very "cold" indeed. We have 5,000 book libraries that don't get touched once a month! Warming that data up fast is a real challenge.
2. Memcached is a powerful tool. We use it extensively.
(If you don't know what memcached is, basically it's a simple in-memory key/value store. You put things in, and take them out. They expire from the cache when you want them to, of course, but they also "age out" as new data comes into.)
Our use is predicated on the core understanding that memcached data can always go away. You can't rely on the stuff you put there being there when you query the next time. You can't rely on it being there to save to disk. (You can be sure it's USUALLY going to be there if you get it soon after it's put there and nothing crashes. Much of our metics tracking works this way, but we can lose 15 minutes of page timings in a way we can't lose 15 minutes of new books.) This is basic to how it works. That memcached also crashes from time to time, taking all its data with it, is just another illustration of the problem--albeit easier for non-programmers to understand.
As a result, memcached tends to be used in a cascade of fallbacks. First you check memcached, then you check the disk. If you retrieve from disk, you put it in memcached. Most critically, this is how your bare list of bookids, and the collections they belong in, exists to the site. If it's in memory, it uses that. If not, it gets it from disk and puts it in memory.
In practice, we have two types of memcached data--stuff we keep live and up-to-date, and stuff we use for caching--data that lives for a while in memory, being queried many times until, eventually, it is lost and replaced from disk.
3. Memcached's strength is its austere simplicity. It's weakness is the same. Relational databases are somewhat out of vogue these days, but they are an extremely powerful concept. It is not relational.
So, for example, if you want to store a user's list of works and a work's list of users, you have to store the same data twice. If you want to change them, you have to change them both places. You rapidly get to a situation where you are juggling keys for ever user-to-works, work-to-users, user-to-ratings, user-to-reviewid, work-to-ratings, work-to-reviewids, etc. Then, when you change a work number, you might have to change a few hundred thousand memcached keys. Obviously, there's no way to "search" for data across keys--no way to search for stuff you haven't explicitly decided to store in a specific key. If you can get by with expiring key/value storage, it's a great solution. We use it for that. Some sites need no more. But LibraryThing needs more.
Relational databases offer a different solution. A piece of data is stored one place—indeed storing data in one place and in one way is a core design principle—but can be accessed many ways. So, you can have a table that stores users books, their relationship to the work level, its author and the ratings they gave it, and that data can be accessed based on any of those data points. That's a powerful thing.
4. Relational databases are somewhat out of fashion now, with people returning to the simpler key/value stores of pre-relational systems--whether as something like memcached, non-relational databases, queues, flat files or whatever. While we've actually gone this way for some parts of the site, we haven't gone all the way.
LibraryThing has orders of magnitude more "live" data than other similar sites, the data is deeply intertwined and global, there are more "primary object types" and all the data is twisted and turned in far more complex ways. When I think about other social sites I know—Facebook, for example—I think "I wish I had THEIR data!" Certainly they are storing a lot of key-value pairs, but how much do they turn the data? How much is "global"? Can you see your newsfeed in any order? Can you see all relationship-changes across all users? Can you find out the sex of members who posted a video today? Can members unilaterally change basic data across all users--for example deciding that from now on "it's complicated" is going to be part of "single"--and expecting the system to roll with it flawlessly. LibraryThing revels in this sort of fluidity, global scope and relational mixing. We want to do more than store a list of books. We want to tell you works for a tag, tags for a work, tags for an author, tags for a tagmash, tags for a subject, subject for a tagmash, and on and on and on.
5. We have various paths forward. One of the most promising is to separate the global and personal layer more strongly, and shard the latter across devices and/or systems. The main work there is already in place--the core book tables are sharded by user number, but still being queried on all boxes. Tonight or tomorrow we'll move to partial sharding of those requests, in order to prejudice a given set of machines for personal-data access, and thereby keep their caches in shape for that.
Anyway, I gotta get back to work, but those are some thoughts.
So, a few thoughts on your post.
1. The goal is to have as much come from memory as possible. How it's in memory is irrelevant, and I'm sure you will agree. If we can get it from memory most of the time, but the memory is a buffer pool or query cache, that works.
Although we have 200GB of data, it's a long-tail dataset. The most active data is maybe 5-10% of that. As a result, most "disk" queries do get pulled from memory, not from disk.
As stated, the problem is that some of the long tail can get very "cold" indeed. We have 5,000 book libraries that don't get touched once a month! Warming that data up fast is a real challenge.
2. Memcached is a powerful tool. We use it extensively.
(If you don't know what memcached is, basically it's a simple in-memory key/value store. You put things in, and take them out. They expire from the cache when you want them to, of course, but they also "age out" as new data comes into.)
Our use is predicated on the core understanding that memcached data can always go away. You can't rely on the stuff you put there being there when you query the next time. You can't rely on it being there to save to disk. (You can be sure it's USUALLY going to be there if you get it soon after it's put there and nothing crashes. Much of our metics tracking works this way, but we can lose 15 minutes of page timings in a way we can't lose 15 minutes of new books.) This is basic to how it works. That memcached also crashes from time to time, taking all its data with it, is just another illustration of the problem--albeit easier for non-programmers to understand.
As a result, memcached tends to be used in a cascade of fallbacks. First you check memcached, then you check the disk. If you retrieve from disk, you put it in memcached. Most critically, this is how your bare list of bookids, and the collections they belong in, exists to the site. If it's in memory, it uses that. If not, it gets it from disk and puts it in memory.
In practice, we have two types of memcached data--stuff we keep live and up-to-date, and stuff we use for caching--data that lives for a while in memory, being queried many times until, eventually, it is lost and replaced from disk.
3. Memcached's strength is its austere simplicity. It's weakness is the same. Relational databases are somewhat out of vogue these days, but they are an extremely powerful concept. It is not relational.
So, for example, if you want to store a user's list of works and a work's list of users, you have to store the same data twice. If you want to change them, you have to change them both places. You rapidly get to a situation where you are juggling keys for ever user-to-works, work-to-users, user-to-ratings, user-to-reviewid, work-to-ratings, work-to-reviewids, etc. Then, when you change a work number, you might have to change a few hundred thousand memcached keys. Obviously, there's no way to "search" for data across keys--no way to search for stuff you haven't explicitly decided to store in a specific key. If you can get by with expiring key/value storage, it's a great solution. We use it for that. Some sites need no more. But LibraryThing needs more.
Relational databases offer a different solution. A piece of data is stored one place—indeed storing data in one place and in one way is a core design principle—but can be accessed many ways. So, you can have a table that stores users books, their relationship to the work level, its author and the ratings they gave it, and that data can be accessed based on any of those data points. That's a powerful thing.
4. Relational databases are somewhat out of fashion now, with people returning to the simpler key/value stores of pre-relational systems--whether as something like memcached, non-relational databases, queues, flat files or whatever. While we've actually gone this way for some parts of the site, we haven't gone all the way.
LibraryThing has orders of magnitude more "live" data than other similar sites, the data is deeply intertwined and global, there are more "primary object types" and all the data is twisted and turned in far more complex ways. When I think about other social sites I know—Facebook, for example—I think "I wish I had THEIR data!" Certainly they are storing a lot of key-value pairs, but how much do they turn the data? How much is "global"? Can you see your newsfeed in any order? Can you see all relationship-changes across all users? Can you find out the sex of members who posted a video today? Can members unilaterally change basic data across all users--for example deciding that from now on "it's complicated" is going to be part of "single"--and expecting the system to roll with it flawlessly. LibraryThing revels in this sort of fluidity, global scope and relational mixing. We want to do more than store a list of books. We want to tell you works for a tag, tags for a work, tags for an author, tags for a tagmash, tags for a subject, subject for a tagmash, and on and on and on.
5. We have various paths forward. One of the most promising is to separate the global and personal layer more strongly, and shard the latter across devices and/or systems. The main work there is already in place--the core book tables are sharded by user number, but still being queried on all boxes. Tonight or tomorrow we'll move to partial sharding of those requests, in order to prejudice a given set of machines for personal-data access, and thereby keep their caches in shape for that.
Anyway, I gotta get back to work, but those are some thoughts.
33anglemark
@21
My library is approaching 7000 books, and searches have often been so slow that I've taken to finding books in my catalog by searching LT for the author and then clicking on the "see yours" link on the author page.
I always do that except for when I'm accessing LT from the mobile; then I'm directed to my own library and have to wait the three minutes it takes for the initial search to return a result.
My library is approaching 7000 books, and searches have often been so slow that I've taken to finding books in my catalog by searching LT for the author and then clicking on the "see yours" link on the author page.
I always do that except for when I'm accessing LT from the mobile; then I'm directed to my own library and have to wait the three minutes it takes for the initial search to return a result.
34timspalding
Right. That's the problem. (Anglemark's library is almost 7k too.)
I do think we're making progress, though.
Incidentally, one technique we may implement is having your home page trigger a load of your catalog in the background. So, while you take a quick look at what's going on, it's warming up your data.
I do think we're making progress, though.
Incidentally, one technique we may implement is having your home page trigger a load of your catalog in the background. So, while you take a quick look at what's going on, it's warming up your data.
36lorax
Incidentally, one technique we may implement is having your home page trigger a load of your catalog in the background. So, while you take a quick look at what's going on, it's warming up your data.
That's a great idea, but is it actually going to help all that much? How many people enter via their home page vs going directly to their catalog, or entering via another point such as their profile page or Talk? (This is an actual question; you've presumably looked at this data.)
That's a great idea, but is it actually going to help all that much? How many people enter via their home page vs going directly to their catalog, or entering via another point such as their profile page or Talk? (This is an actual question; you've presumably looked at this data.)
37theapparatus
When you log in, it drops you down onto your home page and therefore will cause the data load.
38lorax
37>
I don't log out. Many people don't. So the "what happens when you're logged out, and when you log in" isn't always relevant.
I don't log out. Many people don't. So the "what happens when you're logged out, and when you log in" isn't always relevant.
39quigui
> 38 If you don't log out, but enter through www.librarything.com you go to your homepage, not the catalog.
But I'm not sure if it helps much to load the catalog when a user enters the homepage. Probably the users that use more their catalog enter through their catalog - they skip the extra step. Those who go to the homepage might want to look at other things besides their books, and not need to load catalog at all.
But I'm not sure if it helps much to load the catalog when a user enters the homepage. Probably the users that use more their catalog enter through their catalog - they skip the extra step. Those who go to the homepage might want to look at other things besides their books, and not need to load catalog at all.
40lorax
39>
If you don't log out, but enter through www.librarything.com you go to your homepage, not the catalog.
Do you honestly think I'm such a complete moron that I don't know that?
My question was not "Gee, I'm an idiot!" It was "How many people, via whatever mechanism -- logging in, going to www.librarything.com, going to librarything.com/home/MEMBERNAME, I don't care -- go to their home page as their standard entry point, rather than going to their catalog or Talk or another entry point?
If you don't log out, but enter through www.librarything.com you go to your homepage, not the catalog.
Do you honestly think I'm such a complete moron that I don't know that?
My question was not "Gee, I'm an idiot!" It was "How many people, via whatever mechanism -- logging in, going to www.librarything.com, going to librarything.com/home/MEMBERNAME, I don't care -- go to their home page as their standard entry point, rather than going to their catalog or Talk or another entry point?
42skittles
#41: Who are the other five?
Then we can chat & share stories!!
But I don't share books except through BookMooch & Paperbackswap!!
Then we can chat & share stories!!
But I don't share books except through BookMooch & Paperbackswap!!
43MikeBriggs
41> No, I returned from vacation on Tuesday.
44Nicole_VanK
One of them would be me. But yeah, I guess I'm on vacation.
45reading_fox
Unfortunetly me. My brouser deletes all cookies on closing, and so I have to relog in to all such sites whenever I visit them. I've never really liked the homepage, but have to wait for it to load on any visit to LT (I could archive some comments which might speed it up I suppose) and then wait for my catalogue to load too. Background cataloguye loading would be nice.
46timspalding
but have to wait for it to load on any visit to LT
In most browsers, you can leave as soon as it starts. Most of the sections are "ajaxed-in." Do you have to wait for all of it to laod?
In most browsers, you can leave as soon as it starts. Most of the sections are "ajaxed-in." Do you have to wait for all of it to laod?
47reading_fox
There's a notable (not long, but noticeable) period where I have to wait, but once that's passed yes I can navigate away before all the sections have fully loaded.
48brightcopy
I'm assuming before Tim bothered implementing this, he'd grep/trace through the visitor logs and see if it would actually help. It'd be pretty feasible to actually SEE if people were usually entering directly into their "cold" catalog or if they were hitting other pages first.
49timspalding
I am also thinking we may have a more general "Hey, you just arrived" function. It could trigger from any page.
50quigui
> 40 I was just pointing out that it's another mechanism to get to the home page. There is bound to be a lot of people that enter through librarything.com - easier to type if they don't have the site bookmarked.
51lorax
48>
I was assuming he'd actually done that, and was asking what the results were, because I'm nosy, er, curious, like that.
50>
But again, you were assuming that I didn't know that??????
I was assuming he'd actually done that, and was asking what the results were, because I'm nosy, er, curious, like that.
50>
But again, you were assuming that I didn't know that??????
52quigui
> 51 Not at all. Just pointing out all the possibilities. I find that sometimes its best to get all the ideas out, even the obvious, because it's easier to see the entire problem and then easily discard what is not needed. Also, what is obvious for some, might not for other. When I posted before, I didn't remember people would be entering through Talk - but you did. Even though I come to Talk regularly I almost never go directly to it.
53brightcopy
Nobody thinks you're an idiot or a moron, lorax.
Perhaps we could move on.
49> I wonder if you can sift through the data and find any pattern. Like those people that only visit their catalog once a month. Is there any regularity there, so that if they haven't visited in over 25 days, you can start warming up the data because it's likely they'll visit sometime in the next week.
Meh, probably a little too much fine tuning. Would be interesting, though.
Perhaps we could move on.
49> I wonder if you can sift through the data and find any pattern. Like those people that only visit their catalog once a month. Is there any regularity there, so that if they haven't visited in over 25 days, you can start warming up the data because it's likely they'll visit sometime in the next week.
Meh, probably a little too much fine tuning. Would be interesting, though.
54thorold
>53 brightcopy:
But it would be fun having spooky welcome messages to remind us how much theCIA LibraryThing team know about us: "Hallo - we weren't expecting you back until tomorrow!" or "Hey, don't you usually log on from work at this time? - taking a sickie, are we?"
But it would be fun having spooky welcome messages to remind us how much the
55brightcopy
54> LOL
"Try to make it home by 7 or your catalog will get cold!"
"Try to make it home by 7 or your catalog will get cold!"
56Ennas
I don't mind the down time (well...actually I do, but I understand that it's necessary), but a message "We'll be back up around 7:30 am" when it is 11:15 am in my timezone is not very helpful. Maybe you could add a timezone next time. :)
57beardo
56:
Here on the West Coast of Canada, I'm always three hours behind LT time - I figure the site's default timezone then to be Eastern Standard Time. For those outside of North America, that would be New York time.
ETA: Unless, of course, the LT clock is adjustable for each member and I just haven't figured it out. :)
Here on the West Coast of Canada, I'm always three hours behind LT time - I figure the site's default timezone then to be Eastern Standard Time. For those outside of North America, that would be New York time.
ETA: Unless, of course, the LT clock is adjustable for each member and I just haven't figured it out. :)
58lorax
57>
Almost; the site's timezone is always Eastern Time. So right now that's Eastern Daylight Time (GMT - 4) rather than Eastern Standard Time (GMT - 5). (Having worked for a few years somewhere where the DST switchover always caused problems twice a year, this was an important distinction.) Sometimes there is a timezone in their down message, but I agree that putting in a GMT offset would be helpful for non-US residents. ("EDT" or "EST" are not likely to be universally helpful.)
Almost; the site's timezone is always Eastern Time. So right now that's Eastern Daylight Time (GMT - 4) rather than Eastern Standard Time (GMT - 5). (Having worked for a few years somewhere where the DST switchover always caused problems twice a year, this was an important distinction.) Sometimes there is a timezone in their down message, but I agree that putting in a GMT offset would be helpful for non-US residents. ("EDT" or "EST" are not likely to be universally helpful.)
60lorax
59>
No problem. Probably 90% of the time it doesn't matter because neither person in the conversation makes the distinction, but I thought I'd mention it.
No problem. Probably 90% of the time it doesn't matter because neither person in the conversation makes the distinction, but I thought I'd mention it.
61bernsad
Rather than putting a timezone offset in for each user I would be happy just to see a clock of the current LT time ticking away.
Hmm, message says back at 7:30, clock says 7:29:32, good!, should be back up in about 2 weeks.
Hmm, message says back at 7:30, clock says 7:29:32, good!, should be back up in about 2 weeks.
62MrAndrew
I'd find a GMT offset useful... even better would be "USA EDT 7:30am (GMT -4 hours)". That would help me convert to the AU EST i'm on right now, or the AU EDT that i'll be on next month (you'd think that people in different countries could come up with something more creative than "Eastern Standard Time"... maybe we should be on "Eastern Skippy Time... no wait that's still EST... how about you guys change to "Eastern Yankee Time"?)
>#54: "Nice bathrobe."
"Those shoes really don't go with that outfit, you know?"
"OMG! Put some clothes on, fer chrissake!"
>#54: "Nice bathrobe."
"Those shoes really don't go with that outfit, you know?"
"OMG! Put some clothes on, fer chrissake!"
63timspalding
Some results of our efforts are apparent. Catalog pages are faster overall, and especially for "cold" pages on large libraries. Evidence:
This shows the percent of catalog ("Your Library") pages that take more than five seconds to render on the server. They used to comprise about 6% of queries, with a lot of ups and downs. Since the final changes—yellow—we are now bumping around 2.5-3%, with no sudden upward jerks.
This shows the average speed of catalog ("Your Library") pages, expressed in milliseconds (1000 = 1 second). It used to fall around 1.5 seconds. Since the change, it's fallen to around 1 second, so about 1/3 less time.
It is too early to be more specific, but I don't think it's too early to say something. The effects are no a blip. It's notable our performance was so good during the hardest part of the day—the early afternoon. The data stands up well when charted against traffic, which hasn't changed much day-to-day.
Similar, if smaller, gains are detectable on other pages that use one or more queries dependent on sharding. Much improved replication speeds on personal-catalog tables has removed various occasions for stale or incorrect data.
While I sympathize with members who think the site is fast enough, I don't think excessive waits—30 seconds or more was mentioned above—are okay. If a moderate amount of work can show major gains there and elsewhere, it's worth it. In a few days of fiddling we've managed to cut 10-plus-second queries in half, and speed up the catalog for all (.5 seconds is noticeable). The gain brings other goals in reach too, as it walks us back on the slowing effects of maybe 12 months of data, opens up new optimizations, and makes possible new resource-using features.
So, according to Zoe's numbers, you didn't want it. I did it anyway. And I think I was right! :)
This shows the percent of catalog ("Your Library") pages that take more than five seconds to render on the server. They used to comprise about 6% of queries, with a lot of ups and downs. Since the final changes—yellow—we are now bumping around 2.5-3%, with no sudden upward jerks.
This shows the average speed of catalog ("Your Library") pages, expressed in milliseconds (1000 = 1 second). It used to fall around 1.5 seconds. Since the change, it's fallen to around 1 second, so about 1/3 less time.
It is too early to be more specific, but I don't think it's too early to say something. The effects are no a blip. It's notable our performance was so good during the hardest part of the day—the early afternoon. The data stands up well when charted against traffic, which hasn't changed much day-to-day.
Similar, if smaller, gains are detectable on other pages that use one or more queries dependent on sharding. Much improved replication speeds on personal-catalog tables has removed various occasions for stale or incorrect data.
While I sympathize with members who think the site is fast enough, I don't think excessive waits—30 seconds or more was mentioned above—are okay. If a moderate amount of work can show major gains there and elsewhere, it's worth it. In a few days of fiddling we've managed to cut 10-plus-second queries in half, and speed up the catalog for all (.5 seconds is noticeable). The gain brings other goals in reach too, as it walks us back on the slowing effects of maybe 12 months of data, opens up new optimizations, and makes possible new resource-using features.
So, according to Zoe's numbers, you didn't want it. I did it anyway. And I think I was right! :)
64SchanleyMedia
>63 timspalding: makes possible new resource-using features
As the site grows, I understand and agree that optimization is needed just to keep up with scaling issues, so thank you (even if I for one didn't ask for it directly.) :)
I've been wondering what percentage of the largest libraries are so large because of cataloging parts of anthologies/box sets separately. Would a new contains/relationships feature help to reduce personal library sizes by rendering some individual catalog records unnecessary, or is this really not a large contributor to library size in the grand scheme of things? (Maybe it's mostly massive wishlisters, after having spot-checked a few large libraries.)
I do realize that a new relationships feature would create lots more data-crunching and cascading impact on code for other features. a net loss in speed/processing, but I'd be glad if this week's optimizations might in some small way help bring such a resource-intensive new feature closer to fruition.
As the site grows, I understand and agree that optimization is needed just to keep up with scaling issues, so thank you (even if I for one didn't ask for it directly.) :)
I've been wondering what percentage of the largest libraries are so large because of cataloging parts of anthologies/box sets separately. Would a new contains/relationships feature help to reduce personal library sizes by rendering some individual catalog records unnecessary, or is this really not a large contributor to library size in the grand scheme of things? (Maybe it's mostly massive wishlisters, after having spot-checked a few large libraries.)
I do realize that a new relationships feature would create lots more data-crunching and cascading impact on code for other features. a net loss in speed/processing, but I'd be glad if this week's optimizations might in some small way help bring such a resource-intensive new feature closer to fruition.
65brightcopy
63> It might not have been particularly high on my priority wishlist, but that doesn't keep me from being impressed. Damn fine job.
66infiniteletters
Speed and stability are always high on my wishlist. It doesn't matter how good a site's features are when you can't use them (site going up and down constantly rather than planned outages) or when it takes too long to use them.
67jjmcgaffey
64> There's actually a contained in/contains feature in the works - I've played with it in BETA. It's great, but doesn't actually answer my needs. I want to be able to review and enter reading dates separately for separate bits of an omnibus (and an anthology/collection - that's also in the works, but not released even to BETA yet). So although I can see contained-in stuff, I still catalog books-in-omnibuses as 'inclusions' so that I can review and date them. I don't think the feature will include that, even when it's complete - what I believe it will include is no more recommendations for parts when you have the whole, and possibly better displays of checkmarks on the series pages (so it doesn't say you're missing something if you have it in an omnibus).
Anyway, I doubt that's a major contributor to library size. I had more than 4000 books before I started doing inclusions. Even my wishlist doesn't bring it down to under 4000 (closer, but not below - wishlist 164, inclusions 143, library total (all collections) 4453). I'm not one of the largest libraries, but not small either...
Anyway, I doubt that's a major contributor to library size. I had more than 4000 books before I started doing inclusions. Even my wishlist doesn't bring it down to under 4000 (closer, but not below - wishlist 164, inclusions 143, library total (all collections) 4453). I'm not one of the largest libraries, but not small either...
68_Zoe_
So, according to Zoe's numbers, you didn't want it. I did it anyway.
Next up: comments on reviews? ;)
Anyway, I don't disagree with your decision here. The site speed should be acceptable for everyone; if 80% of people say it's fast enough, you still need to worry about the other 20%. You're the one who decided to add polls about speed :P
More importantly, I don't see the list of priorities as meaning that you should only do things from the top. What I do think is important is making sure you do some things from the top (or lots of quick-win things from the top-middle), so that people remain generally satisfied with the direction of the site.
Next up: comments on reviews? ;)
Anyway, I don't disagree with your decision here. The site speed should be acceptable for everyone; if 80% of people say it's fast enough, you still need to worry about the other 20%. You're the one who decided to add polls about speed :P
More importantly, I don't see the list of priorities as meaning that you should only do things from the top. What I do think is important is making sure you do some things from the top (or lots of quick-win things from the top-middle), so that people remain generally satisfied with the direction of the site.
69r.orrison
You also know more about the internals than any of us possibly could -- I'm more than happy to accept that the changes were necessary to cope with growth and potential new features.
I think people would prefer to see Zoe's list applied to prioritizing work that's not necessary to keep the site running -- bug fixes before new features, for example.
(And I guess, if the work you do for LibraryThing for Libraries is necessary for big paying customers to keep the site running, that qualifies too, even though it isn't anywhere on the list at all.)
I think people would prefer to see Zoe's list applied to prioritizing work that's not necessary to keep the site running -- bug fixes before new features, for example.
(And I guess, if the work you do for LibraryThing for Libraries is necessary for big paying customers to keep the site running, that qualifies too, even though it isn't anywhere on the list at all.)
70thorold
>62 MrAndrew:
Shamelessly repeating a tip someone else posted here a year or two ago - I use FoxClocks to display local time and US Eastern time in my Firefox browser bar, so I can always see what time it is in Tim's world if I'm using my own computer. Doesn't help if you don't have Firefox or can't install add-ons, of course.
Shamelessly repeating a tip someone else posted here a year or two ago - I use FoxClocks to display local time and US Eastern time in my Firefox browser bar, so I can always see what time it is in Tim's world if I'm using my own computer. Doesn't help if you don't have Firefox or can't install add-ons, of course.
71bnielsen
#70: Thanks. I installed FoxClocks and then found out how to get something like it to display on my profile image. (When the site is down, that doesn't help me of course, so I'll keep FoxClocks nearby.)
72lorax
61>
I don't think anyone's talking about a per-user offset; just a mention of what the LT timezone is, with a GMT offset for people unfamiliar with US timezones.
I don't think anyone's talking about a per-user offset; just a mention of what the LT timezone is, with a GMT offset for people unfamiliar with US timezones.
74theapparatus
Does seem to be faster. At least it was only taking a few seconds to search on my collection. (7,300 works.)
75AnnaClaire
how about you guys change to "Eastern Yankee Time"? (#62)
Only if you guys change to "Eastern Aussie Time."
:)
77timspalding
Anyway, I don't disagree with your decision here ... More importantly, I don't see the list of priorities as meaning that you should only do things from the top....
Sorry if my tone didn't come through entirely. I was mostly ribbing you. And I wasn't bashing your ribs...
That said, I do feel a certain timidity and expectation of criticism when I work on such things. I do need users to understand that "my view" of the site's operation does include factors others don't see as clearly as I do. Site performance and stability is one. Sometimes it includes factors I can't even show you, like personnel issues, or can't talk about for business reasons. In the last weeks we sowed up two large data sales--together they pay for a programmer for a year. Nowhere in your list is there a "work on data feeds and selling data." :)
Obviously, what users want is of paramount importance. I have a fairly good understanding of it. But it's definitely not perfect. The most interesting things on your list are where things that I thought would be high, are low, or low, high. There are definitely some surprises in there. And that's very useful. It's also useful as a quick-reference. I have a full plate right now. But my plate empties for short and long periods, and glancing over Zoe's list will be very handy.
Sorry if my tone didn't come through entirely. I was mostly ribbing you. And I wasn't bashing your ribs...
That said, I do feel a certain timidity and expectation of criticism when I work on such things. I do need users to understand that "my view" of the site's operation does include factors others don't see as clearly as I do. Site performance and stability is one. Sometimes it includes factors I can't even show you, like personnel issues, or can't talk about for business reasons. In the last weeks we sowed up two large data sales--together they pay for a programmer for a year. Nowhere in your list is there a "work on data feeds and selling data." :)
Obviously, what users want is of paramount importance. I have a fairly good understanding of it. But it's definitely not perfect. The most interesting things on your list are where things that I thought would be high, are low, or low, high. There are definitely some surprises in there. And that's very useful. It's also useful as a quick-reference. I have a full plate right now. But my plate empties for short and long periods, and glancing over Zoe's list will be very handy.
78_Zoe_
Sorry if my tone didn't come through entirely. I was mostly ribbing you. And I wasn't bashing your ribs...
Don't worry, I wasn't seriously suggesting that review comments should be your next project either ;)
That said, I do feel a certain timidity and expectation of criticism when I work on such things.
It may sometimes seem that users don't want you to work on back-end things, but I think in this case the reaction was strongly positive for a couple of reasons: 1) it didn't seem like you were spending that much time on it (a few days? at least, you were doing other things at the same time, like venue images) and 2) you demonstrated visible results with the graphs. Quick improvements with visible results are almost always good. Explaining what you're doing and why is also a big help. If you spend months working on back-end things and don't tell anyone, of course users will become grumpy when it seems that nothing is being done.
In the last weeks we sowed up two large data sales--together they pay for a programmer for a year.
That's great!
I'm curious: which items on the list surprised you?
Don't worry, I wasn't seriously suggesting that review comments should be your next project either ;)
That said, I do feel a certain timidity and expectation of criticism when I work on such things.
It may sometimes seem that users don't want you to work on back-end things, but I think in this case the reaction was strongly positive for a couple of reasons: 1) it didn't seem like you were spending that much time on it (a few days? at least, you were doing other things at the same time, like venue images) and 2) you demonstrated visible results with the graphs. Quick improvements with visible results are almost always good. Explaining what you're doing and why is also a big help. If you spend months working on back-end things and don't tell anyone, of course users will become grumpy when it seems that nothing is being done.
In the last weeks we sowed up two large data sales--together they pay for a programmer for a year.
That's great!
I'm curious: which items on the list surprised you?
79timspalding
Some that are interesting to me:
"Support other media" got creamed. I have definite problems with doing this. The best arguments against it are that it would suck up huge amount of time, and distract us, and that, if not implemented right, could dilute or warp the unique social environment. But it's one of the most common emails I get from new users—can I add my CDs and DVDs?
Apps did worse than I would have thought. Again, this is one of the major complaints against us—we don't have a decent mobile version or app. There have been multiple threads about this, complaining that we don't have one. (Incidentally, the main reason we don't--that Amazon data is prohibited from mobile devices--is flatly, flagrantly violated by our competitor, whose mobile app includes books that only exist on Amazon. Why Amazon allows this is beyond me, but whatever.) We are actually moving to make one, based on our LTFL apps. I rather hope users don't hate us for making one.
I'm also not sure why "Estimated original publication date" got creamed. This is something I really want to do. I want a work page to show the original copyright by default next to title and author, ie.,
The Catcher in the Rye by J. D. Salinger (1951)
This is probably one that would be discussed more.
"Add a changes log to user catalogs." Got voted down. I think this would be wonderful--the solution to any number of problems, in embryo anyway. The problem he is that data structures like that are VERY complicated. And it would require ripping out the floorboards like you wouldn't believe. But I wouldn't expect users to take that into account.
Etc.
"Support other media" got creamed. I have definite problems with doing this. The best arguments against it are that it would suck up huge amount of time, and distract us, and that, if not implemented right, could dilute or warp the unique social environment. But it's one of the most common emails I get from new users—can I add my CDs and DVDs?
Apps did worse than I would have thought. Again, this is one of the major complaints against us—we don't have a decent mobile version or app. There have been multiple threads about this, complaining that we don't have one. (Incidentally, the main reason we don't--that Amazon data is prohibited from mobile devices--is flatly, flagrantly violated by our competitor, whose mobile app includes books that only exist on Amazon. Why Amazon allows this is beyond me, but whatever.) We are actually moving to make one, based on our LTFL apps. I rather hope users don't hate us for making one.
I'm also not sure why "Estimated original publication date" got creamed. This is something I really want to do. I want a work page to show the original copyright by default next to title and author, ie.,
The Catcher in the Rye by J. D. Salinger (1951)
This is probably one that would be discussed more.
"Add a changes log to user catalogs." Got voted down. I think this would be wonderful--the solution to any number of problems, in embryo anyway. The problem he is that data structures like that are VERY complicated. And it would require ripping out the floorboards like you wouldn't believe. But I wouldn't expect users to take that into account.
Etc.
80brightcopy
79> Keep in mind that some of the non-Yes votes on apps is because many of us are already aware of the challenges the Amazon data presents.
ETA: And yes, I definitely took that into account for the changes log. I think "users" in a general sense might not take it into account, but the people who follow RSI aren't a representative sample.
ETA: And yes, I definitely took that into account for the changes log. I think "users" in a general sense might not take it into account, but the people who follow RSI aren't a representative sample.
81timspalding
>79 timspalding:
That's a constant problem with the data. Still, the other factor is that non-representative samples may be "more important" samples. The RSI people are also the seeds of the site, as it were. So, a tennis game of arguments.
That's a constant problem with the data. Still, the other factor is that non-representative samples may be "more important" samples. The RSI people are also the seeds of the site, as it were. So, a tennis game of arguments.
82r.orrison
I would still recommend voting yes if you want the app. Amazon data is a challenge, yes, but it might not be addressed if there's not enough support for the app. If there is a lot of support for the app, then the issue may be addressed. If it turns out to be impossible, all the yes votes in the world won't make them waste time on it.
Tim - is there a problem using Amazon data on a website that happens to look nice on a small screen?
Tim - is there a problem using Amazon data on a website that happens to look nice on a small screen?
84skittles
#79: regarding tearing up the floorboards
I'm glad that LT has a floor.
And has a very stout door.
'Cause walking around
With books falling a down
Would get to be quite a bore.
I'm glad that LT has a floor.
And has a very stout door.
'Cause walking around
With books falling a down
Would get to be quite a bore.
85brightcopy
82> Well, the other reason to not vote Yes is that it falls below other things on my personal wishlist. It's just another shortcoming of a Yes/No/Undecided poll that lumps everything at one flat level.
86FicusFan
I would also say that sometimes users get cranky about what you are doing (that isn't on their list), if:
1. There is a great silence about what is being worked on, so it seems that nothing is being done at all.
2. There are lots of new little features that pop in, unrequested, when long time requests and bugs are ignored.
You of course know what is going on and why, but we don't get the whole picture and can only base our conclusions on limited information.
I think we are all happy that the site runs faster, and that you have done things to insure the financial stability of LT - we just get frustrated sometimes.
1. There is a great silence about what is being worked on, so it seems that nothing is being done at all.
2. There are lots of new little features that pop in, unrequested, when long time requests and bugs are ignored.
You of course know what is going on and why, but we don't get the whole picture and can only base our conclusions on limited information.
I think we are all happy that the site runs faster, and that you have done things to insure the financial stability of LT - we just get frustrated sometimes.
87lorax
79>
"Support other media" got creamed. I have definite problems with doing this. The best arguments against it are that it would suck up huge amount of time, and distract us, and that, if not implemented right, could dilute or warp the unique social environment.
Got it in one. Both of those are extremely important to me. And I think it would be all but impossible to implement it in a way that didn't, as you put it, "dilute or warp the unique social environment" (or, as I would put it, "destroy everything that makes the site what it is"). Well, you could create a parallel but unconnected "DVDThing", but then you'd get complaints that people couldn't see all their stuff in one place.
I voted a strong No on that, and I only voted "No" on things that I thought would be actively harmful to the site; otherwise I just left them blank or voted "Undecided" for things I didn't care about.
"Support other media" got creamed. I have definite problems with doing this. The best arguments against it are that it would suck up huge amount of time, and distract us, and that, if not implemented right, could dilute or warp the unique social environment.
Got it in one. Both of those are extremely important to me. And I think it would be all but impossible to implement it in a way that didn't, as you put it, "dilute or warp the unique social environment" (or, as I would put it, "destroy everything that makes the site what it is"). Well, you could create a parallel but unconnected "DVDThing", but then you'd get complaints that people couldn't see all their stuff in one place.
I voted a strong No on that, and I only voted "No" on things that I thought would be actively harmful to the site; otherwise I just left them blank or voted "Undecided" for things I didn't care about.
89lorax
86.2a
And then there are the long-time bugs that people have been complaining about for months, to the point that established members have given up on them, that get fixed in half an hour when a newbie reports them on a thread Tim happens to be reading. That's absolutely maddening. What's the point of having a "Bug Collectors" group if people with the power to fix the bugs don't even monitor it?
And then there are the long-time bugs that people have been complaining about for months, to the point that established members have given up on them, that get fixed in half an hour when a newbie reports them on a thread Tim happens to be reading. That's absolutely maddening. What's the point of having a "Bug Collectors" group if people with the power to fix the bugs don't even monitor it?
91timepiece
>79 timspalding:
I voted No on specific apps because I own neither an iPhone nor an Android device. I do sometimes access the site remotely, and therefore voted yes for the mobile SITE, because that could be used by everyone, not just users of a specific device. I hate sites that develop only apps, leaving everyone else out in the cold, when they could develop a page that could also be accessed via iPhone, serving everyone.
I voted No on specific apps because I own neither an iPhone nor an Android device. I do sometimes access the site remotely, and therefore voted yes for the mobile SITE, because that could be used by everyone, not just users of a specific device. I hate sites that develop only apps, leaving everyone else out in the cold, when they could develop a page that could also be accessed via iPhone, serving everyone.
92Morphidae
What's this list being voted on anyway? I don't go into RSI because of how aggressively nasty it can be.
93Nicole_VanK
RSI (Repetitive strain injury) is indeed pretty nasty
96LesMiserables
By and large the downtime is necessary and plays a part in all internet business. I can be frustrating especially when you need to access your banking account or email and it's not working when you go online.
But many internet users do not understand the machinery of the platforms and without an explanation they get a little hot under the collar.
Like cars, databases need servicing, parts need changed or a new car sometimes is in order.
I think LT's downtime spash-page is sufficiently communicative to let us know that it will be up when it's up!
But many internet users do not understand the machinery of the platforms and without an explanation they get a little hot under the collar.
Like cars, databases need servicing, parts need changed or a new car sometimes is in order.
I think LT's downtime spash-page is sufficiently communicative to let us know that it will be up when it's up!
97jjmcgaffey
93, 94> LOL! I think that every time I go to that group...
79> That's exactly why I voted against Support other Media - I would _love_ to have it, but not at the expense of LT as it is. You've convinced most of the vocal Talk members, at least.
I'd like to have an app, especially now that I'm moving from a Palm (where I had a setup that worked) to an Android phone, where I don't - but I can browse the site and do at least some of what I want there. Hmmm, I should make a very limited view...but which of my lovely views shall I eviscerate? Thinking.
I don't remember seeing either of the other two - it's possible that the 'estimated' in the pub date put people off. And yeah, I'd love a change log - which were the books I just modified? but as you say it would require a lot of basic database changes. I remember when you added the new Other Authors and, of course, Collections - a lot of oddities for a few days (and downtimes). It would be nice; whether it would be worth the trouble is something only the people who know the code can answer.
79> That's exactly why I voted against Support other Media - I would _love_ to have it, but not at the expense of LT as it is. You've convinced most of the vocal Talk members, at least.
I'd like to have an app, especially now that I'm moving from a Palm (where I had a setup that worked) to an Android phone, where I don't - but I can browse the site and do at least some of what I want there. Hmmm, I should make a very limited view...but which of my lovely views shall I eviscerate? Thinking.
I don't remember seeing either of the other two - it's possible that the 'estimated' in the pub date put people off. And yeah, I'd love a change log - which were the books I just modified? but as you say it would require a lot of basic database changes. I remember when you added the new Other Authors and, of course, Collections - a lot of oddities for a few days (and downtimes). It would be nice; whether it would be worth the trouble is something only the people who know the code can answer.
98andyl
#79
I voted against the mobile apps because I haven't got a fancy phone and I believe that there are somewhat of a distraction (although obviously not as much as other media). I'm sure it has a big kewl factor with quite a few people, but I'm not sure how much they will use the feature when produced.
As I am sure you know what people say they want and what they really want often differ markedly. This is true in the world of business applications and I am sure it is even more true when you come to the general public.
I voted against the mobile apps because I haven't got a fancy phone and I believe that there are somewhat of a distraction (although obviously not as much as other media). I'm sure it has a big kewl factor with quite a few people, but I'm not sure how much they will use the feature when produced.
As I am sure you know what people say they want and what they really want often differ markedly. This is true in the world of business applications and I am sure it is even more true when you come to the general public.
99235711
I think I voted undecided on support for other media. The question seemed to be phrased in such a way that it could mean anything. Full support for other media would dilute the bookish character of the site too much, but a way to filter search results by media type (which some people have requested and which may be referred to by the poll) wouldn't hurt. (Though I'm not sure how that would work if you left it to users to indicate media type; give me a way to do so with Power Edit and I'll do it gladly, but you can't make people. And doing it through Common Knowledge would make it useless for distinguishing between printed books, ebooks, audiobooks, etc.)
