Now Viewing: Old Gelbooru ui
Keep it civil, do not flame or bait other users. If you notice anything illegal or inappropriate being discussed, contact an administrator or moderator.
Quote
Posted on: 01/26/21 01:58PM
Web design noob (read: I dont know wtf I'm talking about) here so forgive the ignorance but why is it so far fetched to have the option to store a cached version of the site layout from say, six months ago on a users local machine in the form of a cookie or something to be toggled at the discretion of the user?
Don’t get me wrong, y’all do what you gotta do. I’m just trying to understand. Personally I don’t much agree with the mobile layout much in its current form myself but I understand it’s a process and it kind of is what it is for now.
Don’t get me wrong, y’all do what you gotta do. I’m just trying to understand. Personally I don’t much agree with the mobile layout much in its current form myself but I understand it’s a process and it kind of is what it is for now.
Posted on: 01/26/21 06:42PM
That's not really how cookies work, and it also isn't how the old layout worked.
The layout change isn't just a change to the CSS. What actually gets sent from the server has changed in ways that are incompatible with the old layout. If we tried to load in the old layout on top of the new layout, a lot of important elements just would not show up due to fundamental differences in the way they display. Making them display would require a significant amount of JavaScript to interpret the page to place, for example, the unread mail message, or the pool message, or a way to view the fullsize version of an image on the page. This would also require us to support and develop for two views each in two entirely different layouts going forward, and this is something we definitely cannot do. If you want to create a UserScript and wrapper to do this for yourself, please feel free.
Keeping a toggle in user settings would avoid needing the JavaScript, but once again, we do not have a view component that can be neatly separated from the rest of the code and swapped out. Serving out the old layout on the server side would mean serving an entirely different PHP file to people with that setting. This means that all of that code would be duplicated, and whenever anything on the site changed at all, even something entirely on the backend that an end user wouldn't even see such as a change to the database schema, we would need to do the same work twice. Again, this is something we definitely won't do.
The solution to that would be to refactor to use a MVC model where we can just swap out the view component, but this would take months to finish, if not more than a year. We needed a mobile compliant layout immediately. We also have some planned backend changes, bug fixes, and feature improvements planned, all of which are important and would have to be put off for that entire time that we were converting the site.
Finally, if the Google crawler somehow sets itself to use the old layout (which I wouldn't be surprised if Google did on purpose to spite us for daring to offer users the choice of a layout that hasn't earned their approval), we would once again fail Google's mobile usability audit, which is the entire reason we made the new layout to begin with.
tl;dr however you slice it, offering and maintaining both layouts is technically infeasible.
The layout change isn't just a change to the CSS. What actually gets sent from the server has changed in ways that are incompatible with the old layout. If we tried to load in the old layout on top of the new layout, a lot of important elements just would not show up due to fundamental differences in the way they display. Making them display would require a significant amount of JavaScript to interpret the page to place, for example, the unread mail message, or the pool message, or a way to view the fullsize version of an image on the page. This would also require us to support and develop for two views each in two entirely different layouts going forward, and this is something we definitely cannot do. If you want to create a UserScript and wrapper to do this for yourself, please feel free.
Keeping a toggle in user settings would avoid needing the JavaScript, but once again, we do not have a view component that can be neatly separated from the rest of the code and swapped out. Serving out the old layout on the server side would mean serving an entirely different PHP file to people with that setting. This means that all of that code would be duplicated, and whenever anything on the site changed at all, even something entirely on the backend that an end user wouldn't even see such as a change to the database schema, we would need to do the same work twice. Again, this is something we definitely won't do.
The solution to that would be to refactor to use a MVC model where we can just swap out the view component, but this would take months to finish, if not more than a year. We needed a mobile compliant layout immediately. We also have some planned backend changes, bug fixes, and feature improvements planned, all of which are important and would have to be put off for that entire time that we were converting the site.
Finally, if the Google crawler somehow sets itself to use the old layout (which I wouldn't be surprised if Google did on purpose to spite us for daring to offer users the choice of a layout that hasn't earned their approval), we would once again fail Google's mobile usability audit, which is the entire reason we made the new layout to begin with.
tl;dr however you slice it, offering and maintaining both layouts is technically infeasible.
Posted on: 01/26/21 09:06PM
I know some of those words.
So basically theres neither the time, manpower, or resources to run two versions of the UI at once, and idk what the hell I'm talking about. Got it.
So basically theres neither the time, manpower, or resources to run two versions of the UI at once, and idk what the hell I'm talking about. Got it.
Posted on: 01/28/21 08:38PM
I miss the old UI, but more because I prefer to run my mobile browser (Opera Mini) in maximum data save mode, and new UI doesn't like it. I can change that setting, but then Favourite doesn't work on this site, and it will zoom out and display full pages for all sites, so I have to zoom and scroll everything just to read text. Used to get images near the top, now they are right at the bottom of a list of tags compressed all on the left of the page. Still, less annoying to deal with that here than dealing with zoom on every page or having to switch between the two when changing sites.
Add Reply