Posted under General
0xCCBA696 said:
Suggestion for design of the queue, by the way: set it up so that clicking on a thumbnail would load swap the thumbnail for the sample image and vice versa
This is actually a good idea, but wouldn't the page have to be flash/java based to achieve something like that?
homeless_homo said:
This is actually a good idea, but wouldn't the page have to be flash/java based to achieve something like that?
Granted, I'm no web expert, but I don't see why it couldn't work just like the "original image" link on a post where the image has been reduced in size.
homeless_homo said: This would actually ruin the only way Janitors/Mods have of really communicating between each other, which is that posts that are left alone build up at the bottom of the queue.
Yeah, I'd rather keep it sorted by date, personally, though options couldn't hurt.
homeless_homo said:
This is actually a good idea, but wouldn't the page have to be flash/java based to achieve something like that?
I was thinking more like just simple AJAX, which albert is already using (sparingly) across the site. For example, the "original image" link, as Fencedude mentioned, or more prominently the tag script stuff, voting, favoriting, etc. which is all done without loading another page in your browser.
Equally important, IMO, is my suggestion that there be individual AJAX-based "approve" links next to each image. For example, if you saw a thumbnail in the queue which looked promising, you'd click the thumbnail, and it would expand to the sample image size. If you didn't like the image after seeing it in more detail, then you'd just click it again and it would turn back into a thumbnail, and you'd continue going down the queue. If you DID like it, you'd click the "✔" (or whatever) link next to it, and then a message would appear at the top of the page saying "Post approved" (like the "vote recorded" or "comment posted" or whatever messages), without actually navigating you away from the queue.
You could also have some Javascript to make the post you just approved disappear from the queue without reloading the page. In fact, why not have a "✘" (or whatever) link as well? If you clicked it, it would remove that post from the queue page on your screen, and add the post ID to a cookie so that in the future whenever you loaded the screen that post would not appear. Whenever you loaded the queue page, Javascript on the page would also clean out from the cookie any post IDs which weren't in the queue any more, to avoid the cookie from growing indefinitely.
I don't think this would be hard to implement at all, compared to some other stuff Danbooru can do. So how about it, albert? If you're reading this thread, that is.
I really like this idea.
The problem as it is now is you get no feeling that you are accomplishing anything, so it gets really intimidating.
I've taken to largely just approving posts I like as they pop up on the main page, and only going into the queue if I see someone has uploaded something really good to see if they have any similar uploads to approve.
Perfect example of what I was describing in my very first post.
Read user hungkok2007's comments.
Updated by homeless homo
0xCCBA696 said:
You could also have some Javascript to make the post you just approved disappear from the queue without reloading the page. In fact, why not have a "✘" (or whatever) link as well? If you clicked it, it would remove that post from the queue page on your screen, and add the post ID to a cookie so that in the future whenever you loaded the screen that post would not appear. Whenever you loaded the queue page, Javascript on the page would also clean out from the cookie any post IDs which weren't in the queue any more, to avoid the cookie from growing indefinitely.
Some technicalities: doing it in the cookie would be difficult, since the script would have to *remove* old IDs to avoid having the cookie grow infinitely, without querying danbooru for each and every ID stored to see if they're still pending (you can't just look at the mod queue page, since there's no guarantee it's complete. We still want to be able to de-queue posts from individual users view).
Hmm, actually, I guess we could have an API call like get_oldest_pending_post, and remove all IDs below that. It'd be cheap enough to query and would still purge old IDs from the cookie.
After that, I think a further enhancement would be to reverse the order of the queue so that the oldest unreviewed posts went first.
Then you'd start dismissing them, accepting them or flagging them for deletion. In all three cases, the post would be gone from the queue. You could moderate all posts without ever needing to scroll down from the top of the page.
homeless_homo said: Perfect example of what I was describing in my very first post.
post #389068
Read user hungkok2007's comments.
::twitches:: Exactly.
Anyway, I won't try to stick my nose into the technical details but everything I'm reading so far sounds really good. I like the idea of hiding posts, I like the idea of viewing a larger version right in the mod queue, I like the idea of approving a post without having to view its individual page, I like the ideas that this could allow for putting oldest first and dismissing/accepting them one by one.
I think Fence nailed it when he says you don't feel like you're accomplishing anything in the queue. When I spend 45 minutes going through the whole thing and notice that my browser's scroll bar is only 2 pixels less compressed than it was when I started, it's... an unfortunate feeling. Of course if better images were uploaded this wouldn't be as much of an issue, but it is what it is, and if there are good technical solutions like this, I say go for it. (Easy for me so say since I don't have to code to though =P)
葉月 said:
Some technicalities: doing it in the cookie would be difficult, since the script would have to *remove* old IDs to avoid having the cookie grow infinitely, without querying danbooru for each and every ID stored to see if they're still pending (you can't just look at the mod queue page, since there's no guarantee it's complete. We still want to be able to de-queue posts from individual users view).Hmm, actually, I guess we could have an API call like get_oldest_pending_post, and remove all IDs below that. It'd be cheap enough to query and would still purge old IDs from the cookie.
I was thinking that the hiding of posts on the queue would be done client-side - it'd save db space if the server didn't need to know what posts which queue-viewer had rejected, and would save bandwidth if the client didn't report rejections (which would constitute most of the average queue-viewer's decisions on posts). Anyway, right now the client doesn't report rejections either - in fact, the person using the client can't even tell the client that he/she has rejected a post (which is what I propose to remedy).
But your "get ID of oldest unapproved post" works fine too - in fact, to make calculations easier on the server, you might want to just go for "get ID of youngest post older than 72 hours". Just a matter of where you want to optimize.
aldeayeah said:
After that, I think a further enhancement would be to reverse the order of the queue so that the oldest unreviewed posts went first.
Whenever I go through the queue (which I admit is not often) I try to start at the bottom to see if I can be the noble savior of some poor overlooked post, and of course I'm then inundated with the dregs of the mix and am highly discouraged from visiting the queue again. But if my post-hiding suggestion is implemented, this may yet be a viable approach. Good idea.
jxh2154 said:
I think Fence nailed it when he says you don't feel like you're accomplishing anything in the queue. When I spend 45 minutes going through the whole thing and notice that my browser's scroll bar is only 2 pixels less compressed than it was when I started, it's... an unfortunate feeling.
Er, well, to be honest I don't moderate the queue looking for a feeling of satisfaction or closure. I see it as more of a chore, with the occasional perk of finding a nice image (which I might have found anyway by browsing the comments or the posts).
But I think pretty much the same argument would be to say that letting posts that a queue-viewer has already mentally rejected stay on the page, even after reloading, is a counterproductive UI design in that it forces guaranteed-unwanted information upon the user. IMO it's that problem which warrants the changes I mentioned.
Updated by 0xCCBA696
0xCCBA696 said: Er, well, to be honest I don't moderate the queue looking for a feeling of satisfaction or closure.
I doubt that's what Fence meant and it's not exactly what I meant either. Even if you call it a "chore", the point of a "chore" is to get some job done, right? I load up the page and see a lot of stuff and go through it doing my job and then... it looks like I never even touched it. I also wonder if I missed anything, and it's simply harder to figure out where I last left off, and overall the "chore" doesn't feel like it's complete. That makes it harder to judge whether the chore was done correctly, and what you need to do differently next time to fix that.
Yes, all the points about interface design are part of it too. Of course they are. I'm not sure why you're treating the two as being wholly disconnected though... I don't see where my comments were at all incompatible with what you're suggesting. We're very much in agreement about what needs to be done and why, I think.
I'm not trying to disagree with you about anything really. I guess I was just trying to justify my proposal in terms more pertinent to "the efficiency of the operation" rather than "the happiness of the workers", which is normally how you'd submit requests for policy change, haha :P Not to say that albert is running a factory or something, but... anyway, yeah, it's pretty much the same thing.
0xCCBA696 said:
I was thinking that the hiding of posts on the queue would be done client-side - it'd save db space if the server didn't need to know what posts which queue-viewer had rejected
Yes, I'm talking about client-side as well. But you can't have it purely client-side without knowing what posts are still in the queue, or else the list of rejected IDs would grow indefinitely. You have to ask the site to know which ones you can kill (and you have to, since cookies have very real size limitations).
As I said in forum #14174, that would be workable if the queue as served contained every unapproved post, and all hiding of posts was done on the client side. This is also the mechanism by which, as I stated, the server would not have to remember who had hidden which unapproved posts.
Note that this kind of thing is done already on danbooru in blacklists (at least, afaik - I don't have much on my blacklist): all posts (between the indices demarcating that page of the search results) are loaded but the blacklisted ones are hidden before they are rendered, or at least fast enough after they are rendered to make it appear as if they are never visible. However, in Firefox, if you select "View page info" in the context menu on the page, you'll see the blacklisted thumbnails listed (which means they are in the DOM).
OK, I didn't get that part. Then I don't understand 葉月's objection; it's pretty easy to read the IDs of the posts from the DOM, update the cookie and hide things accordingly, as you said.
Anyway, how big can this cookie get? Storing the IDs of the dismissed posts in plain text with a single character delimiter, it'd be:
[maximum number of posts in the queue] *
([number or characters in the post id] + 1)
Post IDs are 6 digits these days, so thats 7 times the maximum number of posts in the queue, possibly 8 in a foreseeable future. We'll stick with 8 (power of two).
Maximum cookie size is 4KB (RFC 2019), so that means you can store up to 512 dismissed posts in plain text in a single cookie. A bit tight.
If we store them in Base64, 4 digits for the post ID are more than enough (64**4 is over 17 million). Plus the delimiter, it makes 5 bytes per post. Which allows 800 posts in a 4KB cookie.
That seems enough for most normal situations, and works in all RFC 2019-compliant browsers (that is, not IE 6). It's not infinite space, still, so this feature seems bound to be a bit fragile.
Updated by aldeayeah
If cookies can take arbitrary binary data, 3 bytes per post ID with no delimiter would be more than enough for the foreseeable future as well (until post #16777216), allowing for 1365 post IDs in the cookie. Or if you want to get a little ridiculous, 2.5 bytes per post would work until the advent of post #1048576 and would allow for 1638 post IDs in the cookie.
I didn't realize cookies had to be THAT small, though...
