When I started using Book Collector almost every time the dimensions given were Height and Width, i.e. the length of the spine and the width of a cover - similar to the width of a page.
More and more frequently people seem to be using Width as the width of the spine. This is actually more useful when you are looking for a particular book in your library (I have over 2000 to search).
Could we have three options, namely Height, Width and (I suggest) “Spine” - for spine width.
We would need the CLZ team to create a way existing users could move their selected Width entries into “Spine” or indeed choose to leave them in “Width”.
One further tweak would be an additional photo of the book’s spine. I note some enterprising users are photoing the spine alongside one or other cover.
On our bookshelves the appearance of the spine is the easiest way to find an individual book.
Anyone agree?
–TLererton–I agree with you! Especially since books are 3-D objects having the three dimensions makes sense! I have over 3000 from children to adult in both hard cover and paper back. As I get older, paper back is easier to hold.
Rollingf
This problem has come about because of all the new “smart” young things coming into the data entry field who weren’t paying attention in school. So now they dont know how to tell the difference between height, width and thickness. They confuse width with thickness and now I have to correct all their mistakes that are downloaded through Core. I don’t blame CLZ for this, the problem originates further up the line.
I’m wondering if you know the following:
In Book Collector you can actually set extra images (edit a book, go to the LINKS tab, and you can add a local extra image file yourself) - that would require you to take a picture//scan the spine though (and spine images aren’t exactly just available for the millions of books we have in Core of course).
As for the spine width, not sure if that is information that is available for us - but indeed there is no field for that right now. You could create your own field through Tools > User Defined Fields if you’d like.
Could you give me some examples where it seems to give you the Spine width instead of regular width when you add the book from Core?
I’m sorry I have to ask, if you can also show me some examples where you got the spine width instead of regular width?
It surprises me this topic, this is not on our radar at all that the width is suddenly spine width - I’m starting to think this might be an inches vs centimeter problem (that is actually a setting in Book Collector)
Hello AJ. No, it’s not a cm. vs inch problem - though I have come across that a few times, particularly for books likely to have been entered in the USA.
It’s a problem with the prefill too as the Width that appears isn’t cleared between books.
All the ones I have come across I have updated in my collection and I can’t find any today. I will have submitted the correct width to Core already anyway.
If a book is recorded on Core with a width of, say, 20mm or less, that’s a Thickness not a Width. Can you do such a search?
I must say this chat has been useful already in that others here use the word “Thick” rather than my suggestion of “Spine” and that’s a much better heading.
Adding a “Thick” field would be a great idea for all the reasons I’ve suggested previously.
Thanks for your reply @TLeverton !
Can you find an actual example for me please, where it is providing you with the wrong width?
I would like to attack this from examples that you (or other users provide) where it is clearly giving a “spine width” instead of the actual width, and then find that entry in Core, to see what happened there.
Hello AJ,
The best example I can give you is one of the 3 books I entered yesterday -
Fighting Techniques of Naval Warfare - ISBN 9781906626235. It should be the same in core now, as I haven’t synced back to it as yet. At least that is the one I think I had the problem with.
When this problem occurs I usually get the height correctly, in mm, but not the width - it is very obvious that someone has put the spine thickness in as the width.
It is not an inches vs. millimetres issue, as why would you get a mix of both being downloaded?
Geoff
Hi Geoff,
So I’ve tried adding that book on my side, and it came up with:
I also checked the Core database and it shows in our Core as this:
That seems to be correct?
Note that our Core is set to MM, but depending on your app/software setting you get MM or Inches.
It might’ve been fixed already if someone submitted to it, but since you added it yesterday that can’t be it.
Can you show me a screenshot what it looks like in your program, and possibly send me another example?
Here’s one I just found. Incidentally, if you use presets when adding a new book it’s easy to leave the previous book size so it can over-write the width which might be why the problem gets missed.
The Dictionary Of Obscure Sorrows by John Koenig Hardcover 9781501153648
Hope this helps!
Hello AJ,
And here’s one I just found. I went to the Brisbane Bookfest today (1 million used items on sale for a week to support a charity), bought a dozen books and this was the first one I entered. Jackpot.
It seems that there are many examples of this wrongful size info in Core. One of your programmers should be able to run a query on it for all incidences of, say: width less than 50mm. Should get quite a few results…
Cheers,
Geoff
Oh, the isbn for this book is 9781447272663.
Geoff
I just found another Peter James books with wrongful width data. ISBN: 9781509816408.
I found another one with a value of 0 for width, but I don’t think you would count that as part of same problem? ISBN is 9781529004250.
I won’t sync back to Core (and overwrite them) before you say you have seen them.
Cheers,
Geoff
And because of the 3 reply limit - a bit silly really, because I really am replying for a 4th time - I have to add this one as an edit.
Following is one that is just completely wrong it seems. ISBN 0671319906
But the 10 equates to the 9.5 inches in height of the book and the 6 almost equates to the 6.5 inches of the books width - which may support your argument somewhat. But why would these values be in the millimetre field???
Cheers again,
Geoff
Thanks for posting these. We’ll investigate these, and it seems this is enough information/examples to investigate for now. I’ll reply back here when I have further information.
Note: we just upped the reply limit as well. The “3 consecutive reply limit” was a default setting “for new users”, it seems.
Hello AJ,
Have you seen the examples that I and the other user below have found of the incorrect width data?
Is there any progress in correcting this occurrence, as it is rather annoying and frustrating to have to fix when it regularly occurs.
Cheers,
Geoff
Whoops, I should check for replies before typing messages, eh? Sorry about that.
Looking forward to learning what you find out.
Cheers,
Geoff
No worries Geoff, I understand you’re eager to get some more information on this.
This is currently under investigation, I don’t have any further information at this point, we’re looking at how this data came in, from which source, and if we can see if the source is just providing things wrong.
I will reply back here when I know more.
Hi Geoff and AJ. I assume one like this is an inches not millimetres issue.
I think the width vs thickness is much more common and have found several more of them. If this mistake is the case it can lead to a useful improvement as I suggested earlier with a ‘Thick’ box in the Dimensions options.