Ticket Information - ID: #442
| ID: | Category: | Severity | Reproducibility | Date Submitted | Updated By: |
|---|---|---|---|---|---|
| 0000442 | Feature Request | normal | always | 08/28/10 09:41PM | naiohoras |
|
|
| Summary: | Return of parent feature. |
| Description: | The parent feature was removed in the layout change. Considering the following; a. The pools system is not a valid alternative for the functionality found within the parent system, that is the linking of very specific images as a set, i.e. images which are part of the same series and/or only differ about 20% from one another (Such as seperate still-images of the same animation, as an example). b. The pools system is far more difficult to figure out than the parents system ever was, that is first trying to figure out what pool or pools the series belongs to, then making a search for said pool in an attempt to find the pools' ID, and then adding said ID within the tag field for the image series. (I already forgot how, by the way.) c. Contrary to the pools system, the parent system allowed the removal of excess imagery from the main posts list when they were part of the same parent list. Child posts did not appear which cleaned up the posts list considerably for those of us not wanting to see 15 of the same image with an 85% similarity between each in our updated posts list. Adding images to pools does not, in fact, remove the "child" images from the main posts list and thusly adds rather than removes clutter from the site, removing rather than adding, user friendliness in the process. The above clearly explains some reasons (for I'm sure there are others) to request the parent system to be returned to gelbooru. |
| Additional Info: |
lozertuser replied at 2010-08-28 23:14:51  |
| a. Images can belong to multiple pools so this argument is invalid. You can assign a title and description to pools. Pools handle this better than the parent/child system we had which did not support ordering. b. You still have to find the pool id as well as the post id for the old parent system. Both are located in the same area with the same url identifier as "id". c. This is a valid point, however maintaining two features which provide the same functionality, at an increase of database usage, is wasteful. By removing parent id from the table, we can then count posts slightly faster with less CPU load by not having to add on an additional WHERE query. This is what would add a bit of load to MySQL, especially at 2,000 queries per second. |
Maki replied at 2010-08-29 19:07:36 |
| b. I honestly don't understand what you mean with having to find the pool id. For the old parent system there was a textbox wherein the ID for the parent could be entered. Given that the ID of each image is found in the address bar of your browser and thusly easily accessible, and given that the textbox was there to receive this ID, this process is far easier than having to first go to the pools area and then trying to figure out what pool may be most applicable to the imageset you wish to add to a or multiple pools. It's confusing and is not as accessible for new users as should be. Make the process as easy as the old parent system and you overcome a major hurdle in this setup. c. While I can see the server load is lessened by this step, it's still the loss of functionality which was once there and now is nowhere close to there anymore. As said above, I would feel a lot better if the pools system was more easily accessible. It still would not solve the issue which the parent system did solve: Series of images which would otherwise fill up two or three pages in the main posts lists could be easily trimmed down to just the parent image. Now, that functionality is nowhere to be seen anymore. Considering the tag system already exists, I would say add the parent system and drop the pool system. I've not used the pool system once since visiting gelbooru and personally see no use for it. |
Maki replied at 2010-08-29 19:09:44 |
| c. Addendum to my previous remark: With the addition of the wiki system, the pools are made useless as the information found within the pools' description can more easily and more specifically made in the tag wiki rather than the pools description. Therefore there's no use for the pools system anymore other than being a more difficult-to-use parent system. |
internetlovemachine replied at 2010-09-03 04:22:44 |
| Danbooru makes due with having a wiki, a parent/child function, AND a pool function. They're all useful. As for your remark on pools being useless, Colonel Aki's "Life of Maid" series would be MUCH easier put in a pool, and putting info about it and when he releases new parts in the pools description, rather than trying to put all 203(and rising) images of it in a parent/child post feature, and placing that info in the wiki. I thought the parent/child post feature was immensely useful for 2-5 image sets, which I don't think is enough to warrant a completely new pool, and for linking duplicate images to the original upload. |
SystemError replied at 2010-11-17 06:22:43 |
| Although I can see the use of the pool system, I miss the parent system. Now we can't link similar images (for example dressed and nude, only 2 pictures, not enough for a pool) and duplicates/photoshops/fixed-scans. |
Dolljoints replied at 2010-11-28 19:58:19 |
| Just go ahead and create a pool for them, the staff obviously don't mind. I would like to see the pool titles displayed on the image's main page if it's less than 5 or so. |
naiohoras replied at 2021-05-31 11:50:49 |
| what I actually like about having parent-child feature is the ease of access, i.e. being able to see preview, and having only to one click away. with pool system, you need to at least 2 click away to access the image. that seems few, but imagine doing it for every images, every time. more than that, looking at it now, the pool system clearly is not very popular for linking similar images among the user (while I'm fine using the pool system, not all user are me). there are more unlinked similar images in Gelbooru rather than the one using pool system. |