Danbooru2's UI

From forum #85248: The Danbooru 2 discussion thread is 42 pages long now, has many different topics in it, none of which are on the actual moving to 2booru, and I'm not willing to read the whole thing to find every discussion I want to follow or participate in. That's what threads are for.

richie said:

Moving pool bar to the bottom is just another failure from the point of new danbooru UI, and again it's not question of feeling - it's an objective fact.

Moving pool browser to the top left (as it was at the begining) was only slightly worse than top bar: it stayed in place (very good) but it's harder to return to click if you went away with pointer to browse translations (for example).

Putting pool bar at the bottom is the worst solution from these three. If you do browse pool using it, then with every post you need to focus on finding the next/prev buttons as you don't have slightest idea where these buttons can be this time. Disaster.

Removing the pool info from the top of an image has long been requested on the forums.

• The large attention-drawing bar at the top became a problem when images were added to several pools.
• Images in several pools shift the whole web page up and down, which makes skimming through a pool and tabbed browsing very annoying. Parent/Child notices still do this and I hope they get moved to the side bar where pools were.
• The >> arrows blacking-out reveals that you're on the last page, before you've read the comic, which I sometimes disliked. I'd rather the story tell me I'm at the end, not danbooru's UI.
• When only using the mouse, getting the the bottom of a comic, then having to scroll back to the top, is annoying. The solution was to turn on quick-search and type >>, which I liked but I can imagine not everyone (particularly chrome users) disliking.
• Wanting to move back and forth through the pool quickly is now solved with the arrow keys (although not really due to a bug).

Though, the real problem here was images being part of more than one pool, which 99% of the time, was due to these "collections" pools, which I still advocate should be their own colour of tag, especially now that tags are grouped together.

Edit: However, I do sympathise that the new UI is not so great if you're only using a mouse, and the old pool UI certainly looked cleaner, so ideally there'd be a setting to hide the pool info at the bottom. However, wherever it is, it should definitely say:

<< My Pool >>, not «next pool:My Pool prev»

Serlo said:

• Images in several pools shift the whole web page up and down, which makes skimming through a pool and tabbed browsing very annoying. Parent/Child notices still do this and I hope they get moved to the side bar where pools were.

Parent/Child notices are fine where they currently are. Image can have only one parent post and now, in Danbooru 2, multilevel child-parent post relations have been disallowed too. So any given post will have only one such notice at max. This does not shift the image even nearly enough to worry about it.

I do agree with everything else in your post though.

MyrMindservant said:

Image can have only one parent post and now, in Danbooru 2, multilevel child-parent post relations have been disallowed too.

Oh thank god, that was the worst thing.

I don't like the way quoting a comment defaults to placing the quoted text below my own comment.

Serlo said:
Removing the pool info from the top of an image has long been requested on the forums.

Can I have a link to these requests/discussions about it then? I've searched a little but with no success.

• The large attention-drawing bar at the top became a problem when images were added to several pools.
• Images in several pools shift the whole web page up and down, which makes skimming through a pool and tabbed browsing very annoying. Parent/Child notices still do this and I hope they get moved to the side bar where pools were.

These two points don't apply to the problem of positioning pool bar, and in fact they are partially correctly resolved: multiple pool bars are merged into one, with the one browsed currently bolded and on the top of the pool list. This was definitely a good idea - sadly, moving pool bar from top to bottom made it insignificant.

• The >> arrows blacking-out reveals that you're on the last page, before you've read the comic, which I sometimes disliked. I'd rather the story tell me I'm at the end, not danbooru's UI.

While I might a little sympathize with you here, let's face the truth - you never know if this is really the end of story or (temporary) end of uploads only.

• When only using the mouse, getting the the bottom of a comic, then having to scroll back to the top, is annoying. The solution was to turn on quick-search and type >>, which I liked but I can imagine not everyone (particularly chrome users) disliking.

...and now, when browsing the pool you have to scroll down everytime. Doesn't matter if picture is resized or not, if the picture (visible part of it) is interesting for you or not - you have to scroll down everytime and search next/prev button. What's the difference with level of the annoyance here?
Well, there is one: when scrolling up for the top pool bar you can't go too far. You scroll mechanically up and (sooner or later) you're there. This can't be said about scrolling down - you must focus on stopping at the place you need - if not you'll find on bottom of.. comments. Or the bottom empty space - if tag list is long enough.

• Wanting to move back and forth through the pool quickly is now solved with the arrow keys (although not really due to a bug).

I didn't test it too much, but I like the idea. Still again, this feature is absolutely irrelevant as the argument of pool bar placement.

However, wherever it is, it should definitely say:

<< My Pool >>, not «next pool:My Pool prev»

Agreed here.

I agree with what Serlo said, especially the second and fourth bullets.
The pool bar at the bottom is a big improvement.

Serlo (and other users) said:
[pools below the image is better]

richie (and other users) said:
[pools above the image is better]

I’m getting the impression that the opinions are pretty much divided here and this discussion seems to lead nowhere.

A significant amount of users dislikes pools at the bottom and a significant amount of users dislikes pools at the top, so it looks like it boils down to user preference.

I think this must either become an official user configuration option or half the users must use one of the readily available user scripts to move the pool bar (hint, hint).

MyrMindservant said:

Parent/Child notices are fine where they currently are. Image can have only one parent post and now, in Danbooru 2, multilevel child-parent post relations have been disallowed too. So any given post will have only one such notice at max.

Personally I rather disagree with this decision on not allowing multileveling (though I will admit I didn't care for the majority of its usage), unless an alternative for making image sequences that doesn't involve pool creation and parent/child relationships are used only for variations as opposed to short sequencing of images.

With parent/child in how it is currently being used for short sequences and image variations, multileveling child-parent relationships should be allowed. Especially in this kind of example: Images A, B, and C are sequential and so B and C are made children of A. Image D is a variation of B and image E is a variation of C. D should be a child post of B, E should be a child post of C, neither should be a child post of A unless B or C are deleted (which gets me into another issue on post deletion).

When an image gets deleted all the favorites get migrated to the parent. With using child-parent relationships on sequences it can result in people favoriting one image in the sequence and then down the road someone deleting that image and their favorite registration getting migrated to potentially a completely different image. This has happened during cases where a better version of the image that was favorited was uploaded, instead of having the older version a child of the new one before deletion the new one ends up just being made a child of the first image in the sequence. A real example of this was with rantuyetmai going back and purging some HCG sets, didn't matter what the first image that the others were parented to looked like, he'd delete the child posts and migrate all the favorites to the parent post.

Preferably I think a non-pool sequencing method should be added. It could be as simple as something similar to parenting just you put the post ID in on the image for the next or previous image like you would when indicting an image is a parent to the image. That why parent/child relations can pretty much be restricted to using on variations.

Comics, sequences, daily posts/collections, finished versions and derivatives should be so easy, like the system on g.e-hentai.org. Tagging, upload quality and translations should be the only issues on danbooru yet we seem to have managed to mangle this too. :(

NWF_Renim said:

Unless an alternative for making image sequences that doesn't involve pool creation and parent/child relationships are used only for variations as opposed to short sequencing of images.

I disagree. If it's longer than 2 images, it should be a pool. I could write an essay on the differing natures of the parent/child and pool systems and how they gel with human users, but I'll make this short for because this is really something for a new topic.

Problems when the whole sequence is parented to the 1st post:

• You have to work out the order yourself.
• Has all the bad parts of a pool (can have the whole thing spoilt by seeing the posts all together, though pool descriptions often avoid this for us)
• Has non of the the useful bits of a pool (description, can be found in the pool index, sequencing).

Problems when the whole sequence is tiered/nested:

• You need to load 2n-1 pages to read an n-long comic:
• Page 1 - 1st image, parent
• Page 2 - show child posts
• Page 3 - 2nd image
• Page 4 - show child posts
• Page 5 - 3rd image
• Derivatives of one of the pages? Finding which one continues the sequence is often roulette.
• I often click the parent or child when I meant to click the other.
• No idea how long the sequence lasts until you've read the whole thing.

The only reason to use a parent/child over a pool is that you don't have to think up a name, but that can easily be fixed with a standard format that looks at the tags of the parent:

copyright_tag - Parent #parentID (artist_tag)

copyright_tag1/copyright_tag2 - Parent #parentID (artist_tag1/artist_tag2)

Don't want to find these 3 or 4 page long comics? Add -parent to the search. Also this nicely accommodates page variations.

Anyone thinks the old pool management is better?

BarefeetChaser said:

Anyone thinks the old pool management is better?

Management? Nothing's changed about the mangement in danbooru 2, and by management I'm talking about who can and can't create and delete pools and what is and isn't allowed as a pool.

Unless you're talking about some change from 2011 or before.

I don't think that 3-5 page sequences that don't even have names should all get their own pool.

But there's another method of making a sequence of posts. Comment paginators. See post #1358487 for an example.

I think that short 3-5 page long sequences would work best with comment paginators. Of course, they aren't perfect:

• Can only be changed by the person who originally made the comment.
• Must be made before anyone else comments.

But those aren't issues for the majority of small sequences.

Pools should be used for any sequences longer than that.

We don't need another method of sequencing when we already have those two as well as parents.

A system that relies on comments is not a reliable system, but adding pagination to the parent/child system would really help.

Serlo said:

Management? Nothing's changed about the mangement in danbooru 2, and by management I'm talking about who can and can't create and delete pools and what is and isn't allowed as a pool.

Unless you're talking about some change from 2011 or before.

My bad, I was referring to deleting posts from a certain pool.
Now you have to enter the pool editing page, find the number id of images you want to remove, delete them, then submit to finish editing. I thought the old one is actually easier to use? Just enter delete mode and click on images.

BarefeetChaser said:

My bad, I was referring to deleting posts from a certain pool.
Now you have to enter the pool editing page, find the number id of images you want to remove, delete them, then submit to finish editing. I thought the old one is actually easier to use? Just enter delete mode and click on images.

You can also go to the post pages and type -pool:X into their tags, where X is the pool ID.

And I don't think it's a bad change. Being able to remove from pools so easily could be abused for regular members (or it could happen accidentally).
If you have access to tag scripts, I believe using the -pool:X format in one will work, and simulates the delete mode that we used to have.

Toks said:

You can also go to the post pages and type -pool:X into their tags, where X is the pool ID.

And I don't think it's a bad change. Being able to remove from pools so easily could be abused for regular members (or it could happen accidentally).
If you have access to tag scripts, I believe using the -pool:X format in one will work, and simulates the delete mode that we used to have.

Thanks!

Put Pools back on top. Why are we changing something which isn't broken in the first place?!

Also to the guy who's constantly plugging his Script. Stop being an attention whore. Forcing a script to unfuck the interface is just covering up the failure. Making it an option in personal account is one thing but it still leaves the mistake there.

We shouldn't have changed the UI half as we did as looking at how from Danbooru 2's initial launch thankfully we've reverted mostly to the better layout aka the original

Serlo said:

Removing the pool info from the top of an image has long been requested on the forums.

Requested, perhaps; but is it the correct solution?

• The large attention-drawing bar at the top became a problem when images were added to several pools.
• Images in several pools shift the whole web page up and down, which makes skimming through a pool and tabbed browsing very annoying. Parent/Child notices still do this and I hope they get moved to the side bar where pools were.
• When only using the mouse, getting the the bottom of a comic, then having to scroll back to the top, is annoying. The solution was to turn on quick-search and type >>, which I liked but I can imagine not everyone (particularly chrome users) disliking.

These three points are probably the most contentious, the last one in particular. While I personally agree that the pool-bar proliferation was excessive and inconsistent, I don't agree that placing pool navigation below the image is the most humane decision. First off, it will tend to violate the principle if state indication; users cannot know if an image is in any pool or not without scrolling to the bottom of the image. Because of this, it's a violation of users' efficiency, as well. And because it requires variable amounts of scrolling, it ends up inconsistent as well.

It's with these considerations in mind that I continue to advocate for a fixed float for pool navigation at the top right corner of the page. Quoting myself:

DschingisKhan said:

By making it a consistent location within the user's view pane, it speeds acquisition. If the current pool is always at the top of the list (when a post is in multiple pools), we can also leverage the fact that users don't need to move the mouse to go to the next page. I specify top right because corners have the most efficient performance (Fitt's Law applied) and we already use the top left for the main navigation. Also, a left-to-right layout is going to be more natural for most of our userbase.

Does anyone have any strong objection to this, conceptually? Having used it in practice, I find it very natural for a wide variety of pools.

• The >> arrows blacking-out reveals that you're on the last page, before you've read the comic, which I sometimes disliked. I'd rather the story tell me I'm at the end, not danbooru's UI.

Personally, I think it should just not display in that case.

• Wanting to move back and forth through the pool quickly is now solved with the arrow keys (although not really due to a bug).

This is good as long as it's obviously documented and signaled to the user. Basically, no one should be caught unaware of what keyboard shortcuts are active at any given time. So there needs to be an indicator. As the shortcuts already require JS to work we could go a little further and make it an icon with a label. Expand a (popover?) menu of explanation onClick or onHover. If they're disabled, strike the text and add a red "No" symbol over the icon (It's important to also signal that they're NOT available; this is why the icon should still exist).

Though, the real problem here was images being part of more than one pool, which 99% of the time, was due to these "collections" pools, which I still advocate should be their own colour of tag, especially now that tags are grouped together.

This is something that we've discussed in the past, as they're not semantically different from tags in this usage. I'm not sure which direction this should go, but the dual identity of pools is something we could stand to fix.

However, wherever it is, it should definitely say:

<< My Pool >>, not «next pool:My Pool prev»

Agree 100%

@Zelinkokitsune: I highly suggest you to calm down. After that, return and actually add something relevant to back yourself up.

First of all, being used to something ≠ that something being the best solution. I, for one, don't quite understand how pools at the top helped with navigation in them. Well, it did, if you were content with viewing 25-80% of it. With how they are at the bottom, you view an image/read the page as a whole and proceed to the next without any unnecessary scrolling/clicking/whatever, which did happen earlier.

I also believe, that placing pools at the bottom is one of the best things that happened to this site after it's entire change, even though I'm very used to them being placed at the top.

Edit:

First off, it will tend to violate the principle if state indication; users cannot know if an image is in any pool or not without scrolling to the bottom of the image.

Why is that a relevant knowledge before actually getting to know what the content is?

If that's really a "must have" thing, then maybe "This post is in n pools" at the top would help?

Why is that a relevant knowledge before actually getting to know what the content is?

If that's really a "must have" thing, then maybe "This post is in n pools" at the top would help?

Because you might not scroll down far enough to even see the pool bar, or you may read the page and spoil yourself, because you didn't know there were pages before it.
If I open an image, I want to know if it's part of a comic before I read it. I may also want to immediately go back 1 page to assure that I didn't miss any pages since I last checked the pool.
Note that I cannot do that by pressing the LEFT/RIGHT arrow keys since they default to my search query, not the pool. And even if I could, it's always nice to be able to accomplish the same task with just the mouse with as little additional effort as possible.
The bar should always be at the same position for better usability. As already mentioned by others, you do not know how far you need to scroll, so you waste time with unnecessary scrolling.

Furthermore, when editing tags for a larger image, the bars for both the pool and tag query obscure too much of the screen's space, resulting in the need to scroll up repeatedly to find more items to tag.
(The "Rating", "Parent" and "Source" fields in the edit form also require twice as much space as they need. They should be merged into single lines (no display:block). And I wish "Submit" were where the "Related Tags" button currently is)

The bar on top was never a problem until you have an image that is in 2+ pools. We should instead try to split the pool system so that a post can only be in 1 of them. The "collection" pools can then be listed near the tags again.