Reply to post #771 (show post):
Definitely something wonky. I'm a librarian, and I just tried to add the missing book author -- nothing doing (I tried several times).

Reply to post #773 (show post):
Ah yes -- that must have been it (at least for the author thing). I accepted your changes, and it's now showing the author (plus, the superfluous ASIN is gone).

Thank y'all very much!

You guys rock! Love the team work :) Thanks a bunch :-)

Draft post maintains date/time of creation, not time of first publishing.

On some systems, I work on a post for several days before publishing it. That's the extreme example. However, this morning I started work on one post, saved it to drafts and then settled down to finish a chapter and post an update.

I returned to the post I started this morning, but when I hit the button to publish, it was posted with the initial creation date/time, rather than the date/time when I first hit the publish button ... hence it has appeared down the blog list ... and is also unlikely to be seen by anyone else, as it will presumably appear far down their dashboards as well.

Reply to post #778 (show post):
Yes it does.

If you wish to publish your Draft just now or schedule the post for the future publication, please update the Post Date on the right, e.g. choose today's date and time or schedule for any day/time you wish it it go online:

Reply to post #779 (show post):
This explains a lot. I never use the draft feature, so I never noticed they behaved this way. I’ve seen posts from people I’m following on the Explore page that I know I never saw on my dashboard. When I go back to my dashboard to look for them, they’re there, mixed in with other posts I had already read.

I can see why it works the way it does, but I hate that I’m missing posts from people I’m following. I’m following them because I want to see what they have to say. I think most people want their posts to show up when they publish it, not when they first saved a draft for it. If they don’t realize the drafts behave this way, or if they forget to manually change the date/time, they may put a lot of effort into posts that followers will never see.

I realize changing this might be problematic with your current program structure. You probably have no way to tell whether the saved date/time was entered manually by the user or if it was populated automatically. In that case, you couldn't just go and override those date/time fields with the current date/time once the user selected "Publish" because you might override a manually set date/time. You also probably wouldn’t want to leave them empty by default because then they wouldn’t sort nicely on the user’s Drafts page. But I really do think it would be better if the default behavior was for a post to show up under the date/time it was published unless the user specifies otherwise. Maybe you could consider a couple of program modification ideas for this while you’re working on your site redesign?

Option 1
Add a Boolean field, invisible to the user. Let’s call it flgPubNow. By default, flgPubNow = true. If the user manually inputs a date/time, set flgPubNow = false. When the user clicks “Publish”, if flgPubNow = true, overwrite the date/time field with the current date/time. This way, even if a date/time was established when the user saved a draft, it will be overwritten with the current publish date/time. If flgPubNow = false, leave the date/time field alone because we know the user manually entered it.

Option 2
Add an extra set of date/time fields. One set would represent the create date/time and they would not be editable. When the user saves a draft for the first time, or if they publish a post without saving a draft, these dates would automatically be populated with the current date/time. The Drafts page would be sorted by these fields.

The second set would represent the publish date/time. Users could edit these fields to force a specific publish date/time. Otherwise, the default value would be “now”. When/if the user saves a draft, these fields would not be modified in any way. Once the user publishes their post, the behavior would be the same as it is today – if the date/time has been modified, use that. If the date/time is set to “now”, use the current date/time. All of the other areas of the site (dashboard, blog, Explore, etc) would sort by these fields.

Option 1 seems like it would be easier to implement, but this option does have the advantage of providing visibility to the original create date for every post.

Option 3
[This space intentionally left blank.] Maybe somebody else can come up with a better/simpler change to put here that would work from a programming standpoint. :)

Reply to post #780 (show post):
I second Option 1 -- it's not important to me to be able to see when I first saved a post (as provided for in Option 2), but I would very much want the default "publish" setting to be that of the moment when I am actually ready to publish a post, not when I save it for the first time. To me that is counter-intuitive, and it is also counter-intuitive to manually have to post-date it if I anticipate I'll be working on it for a while.

Besides, even knowing I have to post-date it doesn't always help. I recently worked on a post for several days (on and off -- always saving the then-current version as a draft), and even though I manually post-dated the time of publication, I took longer to finish it than I initially anticipated, so at one point, when I had forgotten to post-date publication to an even later date and time, for a split second the uncompleted draft actually showed up on the dashboard -- long enough for someone to see it and comment on it. When I then selected a later publication date after all (and the post was consequently pulled back from the dashboard), the other blogger of course wondered where both my post itself and her comment had vanished ... which only became clear several days later, when I was finally ready to publish once and for all, and my post showed on the dashboard again (at my manually-selected final publication date / time), with her comment attached.

Oops, deleted my post before I saw your reply.

I haven't been having much luck with reports.

Reply to post #784 (show post):
I know, but it also seemed tricky with the problem not being with just a separate individual book :/

I'll try it on the main edition.

I cleared out ALL the edit requests on Thursday, and all the English new book additions, so anything before that date should have been taken care of if it was in the queue. I'll check now for anything added since.

Ok, I've cleared out all the current edit requests, and I've cleared out all the added books (English).

A few things:
1. As Bookstooge said, there are a limited number of librarians, so sometimes the turn around isn't as quick as it should be.

and
2. Factors that will slow down changes getting approved or new books cleared: not including all the information for the book record, but ESPECIALLY:

a. Not adding a source link - a LEGITIMATE source link (which includes Amazon but NOT Goodreads, btw). This is especially true for changed book covers because I, for one, won't approve a book cover change if I can't easily verify it's correct.

b. Not adding an ISBN or ASIN number to books published after 1970. If I have to chase down one of these, the book is getting skipped over until I have time to research it (or someone else does). That could be weeks. Records with ISBN's and ASIN's get cleared first.

c. I've seen this a lot more lately so I'll just mention it here: if you try to change the ISBN of a book record and I can verify that title belongs to the original ISBN, it's getting rejected. If you want your edition with your ISBN and you can't find it in the db, please create a new book record.

d. Also, I'll reject descriptions that have been changed to include reviews, or book blurbs, or advertisements ("free for a limited time!") per the librarian guidelines.

I personally try to check these lists at least once a week, sometimes twice but everything goes much faster if I don't have to hunt down a bunch of information that the request didn't include. I'm hoping BookLikes will soon be adding a notes field so librarians can communicate with the requestor, which will make everything easier too, and give someone an idea of why a change was rejected.

Hope this helps.

Thanks for all the hard work! I'll also keep those points in mind.

I'm assuming reports aren't then handled by librarians too?

k, thx.

Reply to post #790 (show post):
What kind of reports? I've only ever really worried about edits and added books - I might be missing something I should have been looking at... will go explore now.

ETA: Never mind - hoo boy, I never saw those before. I'll get started now.