Topic: Opinions on the new UI buttons? (v. 25.08.13 - v. 25.08.27 Discussion)

fuzzballfox said:
Not to mention said "Download" button is the only option behind another button with the 3 dots :P
The View/Download thing has been throwing me off- I share images with peeps by right clicking the uh..w/e the hell it's called button now and getting the url- I dunno if it's just my muscle memory being thrown off but the constant change is throwing me off lol

It's not always the only button there.

One of the complaints had been that the toolbar overflows into a new line on small screens. A solution to this was to move some of the lesser-used buttons (fullscreen and note toggle) into that menu on smaller screens.
On desktop, the download button may be the only entry there for now. In the future, we'll add more stuff that may end up going into that menu.

cinder said:
It's not always the only button there.

One of the complaints had been that the toolbar overflows into a new line on small screens. A solution to this was to move some of the lesser-used buttons (fullscreen and note toggle) into that menu on smaller screens.
On desktop, the download button may be the only entry there for now. In the future, we'll add more stuff that may end up going into that menu.

I think I'd just prefer if they went to the next line.

This new layout works. I'm not completly in love with the star to favorite but that's a thing which I'll get used to. Otherwise it's calm and clear. 7/9 UI upgrade score.

The new favorite button has far too subtle a difference between favorited and not favorited, what with only the star being filled in with the exact same color. I didn't like the recent change in the colors of the favorite button, but at least those were still obvious at a glance whether or not the post is favorited. I'd suggest that either the whole button should change color like before, or at least use a different color for the star after favoriting.

Also, idk if it is already happening in some capacity, but it feels like there should be some sort of internal/limited release testing of changes like these before they are rolled out to everybody.

The star button for the favourite looks way better than the ugly coloured buttons we had in the last update (the yellow was not a good idea) would maybe say make the button a bit wider but that's a minor nitpick. I personally still think the 3d effect is out of place in the site itself so would just say to make them flat. overall I'm pretty happy with it and I'm happy you guys actually listened.

Not a huge fan, there should be a toggle for having favorites green/red vs filled/unfilled. This change has been making it difficult to distinguish what i already favorited.

In time this will probably become easier as i get use to it, but i much prefer an option for the color version.

wonkeyferret88 said:
Not a huge fan, there should be a toggle for having favorites green/red vs filled/unfilled. This change has been making it difficult to distinguish what i already favorited.

In time this will probably become easier as i get use to it, but i much prefer an option for the color version.

See here for my thoughts on user customization, and here for a further clarification.

You seem to forget that you're working in two dimensions. Vertically, these buttons are rather big, but horizontally, they have plenty of room to grow. In other words, too tall, not wide enough.
Here's the changes I'd make (plus some more edits to compensate, like line-height and the select element):

.st-button {
	height: 1.75rem;
	padding: .35rem .65rem;
}

It may seem subtle, but would definitely be an improvement, for me at least.

Some more thoughts: Don't mess with muscle memory and reorder buttons needlessly. Having both 'View' and 'Download' is redundant, making the three dots menu doubly so. People know how to download images with the existing view link. Adding obscure hotkeys is not a compromise.

robrobl said:
You seem to forget that you're working in two dimensions. Vertically, these buttons are rather big, but horizontally, they have plenty of room to grow. In other words, too tall, not wide enough.

cinder said:
One of the complaints had been that the toolbar overflows into a new line on small screens.

robrobl said:
Some more things: Don't mess with muscle memory and reorder buttons needlessly.

We've discussed the reasons; if you disagree, explain why you find these insufficient.

robrobl said:
Having both 'View' and 'Download' is redundant...

They aren't, it's a bug (one that actually might be fixed now, so try again).

robrobl said:
...making the three dots menu doubly so.

Again:

cinder said:
One of the complaints had been that the toolbar overflows into a new line on small screens. A solution to this was to move some of the lesser-used buttons (fullscreen and note toggle) into that menu on smaller screens.
On desktop, the download button may be the only entry there for now. In the future, we'll add more stuff that may end up going into that menu.

robrobl said:
People know how to download images with the existing view link.

And again, the View button behaves (& will continue to behave) exactly like the old Download button.

robrobl said:
Adding obscure hotkeys are not a compromise.

Characterizing them as obscure doesn't work to discredit them as a solution, especially when multiple users in this thread discuss utilizing them. Letting users use hotkeys to avoid faffing about a UI has been a staple of design since Diablo (& even earlier); it is an appropriate compromise to preserve fast accessibility for desktop users while not cluttering the UI for mobile users.

Additionally, slight contradiction:

robrobl said:
You seem to forget that you're working in two dimensions. Vertically, these buttons are rather big, but horizontally, they have plenty of room to grow. In other words, too tall, not wide enough.
...
Don't mess with muscle memory

I didn't mind the previous favorite buttons but honestly the star is way too small. I could easily miss it and click something I did not intend to click on (especially since the other buttons are way bigger). Moreover, it's not as clear to know if I fav'd something at first glance. Its also less intuitive to just have a star. Maybe a hybrid button with a star that fills in with the word "favorite" might be the best option to fix the size and visibility concerns.

Really not a fan of the star button. There's very little visual difference between a hollow and a filled star and it takes a second of "thinking" when looking at a page to figure out if you've already favorited it or not. The red and green colors worked perfectly fine before and I don't know why it needed to change. If the size was the problem, maybe try abbreviating it to "Fav" when there isn't enough space for the full button.

tonycoon said:
Really not a fan of the star button. There's very little visual difference between a hollow and a filled star and it takes a second of "thinking" when looking at a page to figure out if you've already favorited it or not. The red and green colors worked perfectly fine before and I don't know why it needed to change. If the size was the problem, maybe try abbreviating it to "Fav" when there isn't enough space for the full button.

To support Mobil devices, like what I am NOT using.

cinder said:
It's not always the only button there.

One of the complaints had been that the toolbar overflows into a new line on small screens. A solution to this was to move some of the lesser-used buttons (fullscreen and note toggle) into that menu on smaller screens.
On desktop, the download button may be the only entry there for now. In the future, we'll add more stuff that may end up going into that menu.

Download/"View" was absolutely not a lesser-used button. It's more important than an automatic download button. It was a very important button, but that's not the point, because at least something analogous to it still exists.
Because the new buttons have zero color feedback by default, and because the names have been shifting, I initially thought the new dropdown menu had completely replaced the Download button, and I wouldn't even be ABLE to access the direct image URL anymore, and was absolutely panicking and ready to go ballistic on the forum. Thankfully I noticed the new button. Not helping that the "View" button is tiny. The Favorite button is also awful, there's zero color feedback to it now.

Also more proof that being clearer about button language is having the opposite effect. Users being able to customize things with CSS is irrelevant, I know it exists, it doesn't fix anything, because 95% of users don't even know it exists, and most who do, don't know how to use it, myself included.
Sure, I can theoretically change the button's color for me specifically, but that's a very, VERY high and advanced level of site usage that's far off the beaten path, and requires specialized knowledge of how to even use it. Meaning that by default, 99% of users will have no immediate color feedback for the buttons. CSS can maybe fix MY personal issue about button colors (not really because I have zero idea how to use it,) but that doesn't change anything for everyone else.

It is cool that this site has that feature at all, most places don't, but it doesn't help the overwhelming majority of users. I'd have to learn an entire damn programming language to change the color of two buttons, or go and whine at someone else to do it for me, both of which I'm not doing, and it isn't just about me anyway. Advanced site personalization doesn't really have anything to do with the site in general. In every possible context, having all the buttons look the same and be colorless is a straight downgrade from several extremely important and essential buttons being very clearly and unambiguously colored, and there is no possible circumstance where that's wrong, both on desktop and mobile alike.

Also: I just opened mobile while writing this to see how it is, and BOTH BUTTONS are now hidden inside the dropdown. What the fuck? I thought all the annoying changes were for mobile convenience, now I can't even access images directly at all without hitting a tiny dropdown button on a tiny phone screen, and then hitting another tiny button inside that dropdown, potentially hitting the wrong damn one. How is that MORE convenient?

kerflurval said:
To support Mobil devices, like what I am NOT using.

and here I thought I was just going crazy about the UI changes

personally I use the unofficial e621 mobile app, e1547, and it works fine

yea, yea, it's not "officially endorsed" but I haven't had any issues with it, and found it easier to brows than the site more often than not

so I really don't get the point of the change, but, not my call to make

tonycoon said:
Really not a fan of the star button. There's very little visual difference between a hollow and a filled star and it takes a second of "thinking" when looking at a page to figure out if you've already favorited it or not. The red and green colors worked perfectly fine before and I don't know why it needed to change. If the size was the problem, maybe try abbreviating it to "Fav" when there isn't enough space for the full button.

at the very least, we really shouldn't be using --color-link-active or other accent-y colours for buttons that are in a "neutral" state like this.

aacafah said:
Visual elements take up space, and space comes at a premium on small displays (plus, as said earlier, separation from View). And before my fellow desktop users jump down my throat, we'll likely add a hotkey for it down the line; you get your fast access, & mobile users get to have less of their screens taken up by buttons.

I browse on desktop mode on a tablet so too bad for me I guess

Edit: the view button does the exact same thing as the download button so it's fine I guess??? I'm confused now

aacafah said:
We've discussed the reasons; if you disagree, explain why you find these insufficient.
They aren't, it's a bug (one that actually might be fixed now, so try again).
Again:
And again, the View button behaves (& will continue to behave) exactly like the old Download button.
Characterizing them as obscure doesn't work to discredit them as a solution, especially when multiple users in this thread discuss utilizing them. Letting users use hotkeys to avoid faffing about a UI has been a staple of design since Diablo (& even earlier); it is an appropriate compromise to preserve fast accessibility for desktop users while not cluttering the UI for mobile users.

Additionally, slight contradiction:

I've read your linked post, and I don't see how that is relevant to anything I said. What I am reading is, that you are perplexed why people find the buttons simultaneously too big and too small, and I told you why. They are visually too big vertically, and now (in their current state, i.e. with a star symbol instead of the previous 'favorite' label) too narrow. The old labels of 'Favorite' and 'Download' would fix that.

The download button is redundant, because the view button is the download button. Hell, it was even called "Download" before all the changes, as you said yourself. Right-click (long-press) > save as. Everyone that uses a browser for more than a minute knows that. The minuscule convenience of it working with a single-click is not worth the cognitive load, clutter and space it takes up, which you admit is at a premium. Especially since you've totally negated it by hiding it behind an extra click anyways.

On that topic, only once the buttons would overflow to a new line, that's when you deploy the '...' menu to hide them. "Responsive design" and "progressive enhancement" and all that.

Any statistics to back up how many users use or even know about the hotkeys? I've searched for their documentation and they were buried so deep, you can't expect the average user to find the page or care to find it. Any feature the average user doesn't know about, may as well not exist. Also consider "browsing one handed". I'd go so far to say that not many people who do know about them, would even want to use them, myself included. I'm not taking my hand off the mouse to fumble with any keys.

Finally, that's not a contradiction. What's important is the order of the buttons, not the actual position and size on screen, otherwise simply having a page that scrolls would be a problem. You've moved the 'View/Download' button from third place to almost last. I constantly catch myself trying to click on the "image-resize-selector" instead. That's what I was getting at.

Also this whole "testing in production" is simply not how you do things. Spin up a beta.e621.net or something, where people who care about the site can give you feedback before it goes fully live. Then, also take that feedback to heart and don't hide behind "people just hate change/will just get mad anyways".

Anyways, I'm done discussing this. Take my advice or don't, I guess.

I'm glad we've Custom CSS. It took a while, but I'm happy with the result.

/* ---- REPLACE START ---- */
/* Stretches 'Favorite' button. Also gives it green and red colors as it was before */

#ptbr-wrapper .ptbr-favorite-button[favorited="false"] {
 background-color: rgb(47, 157, 47);
 box-shadow: 0 .25rem rgb(0, 100, 0);
 width: 120px;
 height: 32px;
}

#ptbr-wrapper .ptbr-favorite-button[favorited="true"] {
 background-color: rgb(170, 29, 0);
 box-shadow: 0 .25rem rgb(100, 0, 0);
 width: 120px;
 height: 32px;
}
/* ---- REPLACE END ---- */

/* Stretches 'View' button */
#ptbr-wrapper .ptbr-fullscreen-button {
 display: inline-block !important;
 font-size: 1.25rem;
 width: 120px;
 height: 32px;
 text-align: center;
}

/* Hides '...' button */
.ptbr-etc-toggle {
  display: none !important;
}

/* Hides size selector */
/*
.ptbr-resize {
  display: none !important;
}
*/

/* Displays '...' button contents */
.ptbr-etc-menu {
  display: block !important;
  position: static !important;
  margin: 0 !important;
  padding: 0 !important;
}

/* Fix font size for 'Fullscreen' and Hide 'Fullscreen' button that is inside of a '...' menu but I dont think it's necessary so it's commented
Feel free to uncomment if you don't need it and don't forget to uncomment 'View' button below
It's implemented in an annoying way that if you zoom out on your phone - there will be 'View' button instead of 'Fullscreen' */

.ptbr-etc-menu .ptbr-etc-fullscreen {
/* display: none !important; */
 font-size: 1.25rem;
}

/* Hides 'View' button; Uncomment if you don't need it and don't forget to uncomment "display: none !important;" above in 'Fullscreen' */
/*
.ptbr-fullscreen {
  display: none !important;
}
*/

/* Gives 'Download' button orange-ish color, shadow, etc. */
.ptbr-etc-menu .ptbr-etc-download {
 display: inline-block !important;
 font-size: 1.25rem;
 background-color: rgb(222, 147, 79);
 box-shadow: 0 .25rem rgb(176, 97, 31);
 width: 120px;
 height: 32px;
 text-align: center;
}

#ptbr-wrapper .ptbr-favorite-button[favorited="false"]:hover {
  background-color: rgb(57, 177, 57);
}
#ptbr-wrapper .ptbr-favorite-button[favorited="true"]:hover {
  background-color: rgb(200, 39, 10);
}
.ptbr-etc-menu .ptbr-etc-download:hover {
  background-color: rgb(242, 167, 99);
}

#ptbr-wrapper .ptbr-favorite-button,
.ptbr-etc-menu .ptbr-etc-download {
  transition: background-color 0.2s ease, box-shadow 0.2s ease;
}

/* Reorder View, Download and Resize */
#ptbr-wrapper {
  display: flex;
  flex-wrap: wrap;
  gap: 5px;
}

/* Consistent reordering of all buttons */
.ptbr-vote {
  order: 0;
}

.ptbr-favorite {
  order: 1;
}

.ptbr-etc {
  order: 2;
}

.ptbr-fullscreen {
  order: 3;
}

.ptbr-resize {
  order: 4;
}

.ptbr-notes {
  order: 5;
}

/* small fix for a mobile users */
.ptbr-etc-menu {
  display: flex !important;
  flex-wrap: wrap;
  gap: 5px !important;
  position: static !important;
  margin: 0 !important;
  padding: 0 !important;
}

And

/* ---- REPLACE START ---- */
/* Stretches 'Favorite' button. Also gives it green and red colors as it was before. */
#ptbr-wrapper .ptbr-favorite-button[favorited="false"] {
 background-color: rgb(47, 157, 47);
 box-shadow: 0 .25rem rgb(0, 100, 0);
 width: 120px;
 height: 32px;
}

/* remove ⭐ */
#ptbr-wrapper .ptbr-favorite-button[favorited="false"] svg {
  display: none;
}

/* rename */
#ptbr-wrapper .ptbr-favorite-button[favorited="false"]::after {
  content: "Favourite";
  color: white;
  font-size: 1.25rem;
}

#ptbr-wrapper .ptbr-favorite-button[favorited="true"] {
 background-color: rgb(170, 29, 0);
 box-shadow: 0 .25rem rgb(100, 0, 0);
 width: 120px;
 height: 32px;
}

/* remove ⭐ */
#ptbr-wrapper .ptbr-favorite-button[favorited="true"] svg {
  display: none;
}

/* rename */
#ptbr-wrapper .ptbr-favorite-button[favorited="true"]::after {
  content: "Unfavourite";
  color: white;
  font-size: 1.25rem;
}
/* ---- REPLACE END ---- */

UPD. 25.08 - moved 'Notes' button to the end

"If you don't like our changes, we recommend you adopt a second career as a programmer". That's a little impractical for most of us and comes across as really insincere.

Great. You get near-universal disapproval for all these unwanted UI changes and what do you do? Make even more of them. You seem to think that user custom CSS is the be all and end all of fixing web developers mistakes. Despite CSS being unwieldy, arcane to users who aren't web developers (most of us), the fact that every update has a high change of breaking ALL our custom CSS rendering our fixes non-functional (which is has done with every single one of the changes in this batch), and the fact that it usually CAN'T fix (undo) most developers changes.

To be fair the new favorite star does function properly which is the most important thing. It's just uglier. And harder to press successfully than the previous version because it's smaller. If you're set on keeping it then the entire button should change colors like the superior previous version which had the word favorite on it instead of just filling in the star. It was much easier to tell visually whether something is or is not favorited that way.

I'll also point out that while having separate View and Download buttons would make sense for convenience, that convenience is negated by putting the Download button under a drop down menu. If I want to download a picture that's uploaded to this site it would be equally convenient for me to hit the View button, right click, and click Save As because of the drop down menu. If this drop down menu is intended to be convenient? It isn't. Drop down menus are to be avoided when possible in web UI design as a general rule. Think carefully whether a drop down menu makes things more, or LESS convenient before implementing one.

The view button should be reverted to say Fullscreen which was more clear regarding it's function.

Putting the button for image size (which we usually wouldn't want to mess with) directly between all the other buttons we may wish to press was a mistake. Especially since that wasn't where it was before. You've put it right where the Fullscreen button was previously. I'd recommend putting it on the far right where it's out of the way. (Clearly this is another fix that would be "easy" to do with CSS, right?)

You had a functional website design that was well liked and decided to change it to a worse state. No matter how much you assert that it "makes sense" to make changes like that, it doesn't. Users like any change that makes a site run better or is entirely behind the scenes. If you're going to change the UI? It better ACTUALLY be significantly better after the change. Better to just NOT change UI things when there isn't a problem with the UI.

aacafah said:
Considering the outcry the last time that button was yellow, I doubt we're gonna do that until more people echo that sentiment.

It seems like the shade of yellow has changed unless my brain is playing tricks on me bc it's smaller, if so then maybe there should be a unique animation that plays when you click the favorite button like the star pops up a little bit and glitter comes off or maybe just a liquid fill animation would work, this would address the complaints about the button not being responsive enough
It could also be that the shape is the issue, you could change it to a banner symbol instead like other sites use for bookmarks
I also agree with the other that say the button should just be a little wider, I think it's height is good

I definitely do think these recent UI changes have been an improvement, although I am on mobile

Couldnt all of this just been baked into the theme options? That way people could have their cake and eat it too? Or at least polled to see if this was actually a problem that needed fixing or if it was a fixing looking for a problem?

Going to be honest, not a fan of now having to hit a dropdown menu button on mobile, especially when the button it replaced was in the middle. I also now have a large amount of padding on the sides in exchange for a cut off size select box.

I personally like the new UI, but if others do not fancy it, please allow for the UI to be toggleable, like themes and e6 Icon are, with a new account setting switch.
Thank you.

ilikeeagles said:
I personally like the new UI, but if others do not fancy it, please allow for the UI to be toggleable, like themes and e6 Icon are, with a new account setting switch.
Thank you.

If furaffinity can do it I'm sure e621 can

Not sure how many people this would be relevant to, but a 1-press download button has been in my wish-list forever. But hiding it behind a drop-down kind of defeats the benefit imo, since it's the same number of clicks as right click > save as. It's a small inconvenience, but if there were any way to have the new download button be always visible, personally I would benefit from it at least. If size is a concern, possibly using just an icon could be an option? This would also distinguish it from view/fullscreen.

I love the new Favourite button’s design, it’s exactly how one would expect it to work.

May I suggest that the one-click download button be iconified and placed next to the favourites star?

And the “View” button perhaps should also be iconified to a white “Eye” symbol.

I’d also recommend moving the preview resolution drop-down further away from the button clusters, so as not to confuse it to be an option for what resolution is retrieved when the download/view source button is clicked.

I just spotted the banner alert for favorites again. Thank you for adding that back!

Just adding my voice to the people that dislike the UI changes. I think the new buttons are quite ugly and I don't think having a drop down menu for download makes much sense. Even if there might be more buttons in some cases, I would be against a drop down menu because that's hidden functionality. I think it would be better to have two rows of buttons. And if "View" (which is a strange button because it's unclear what it is meant for. I can already view the image??) duplicates the function then there's no need for two identical buttons.

I'm also still annoyed with the change to the tags where they are now longer text but some sort of image overlaid on some text. That strikes me as very unfriendly design. Text should be text.

Do we really need this to make it more mobile friendly? I've used e621 on mobile and it was absolutely fine as it was. In fact, I deliberately turned off the mobile mode because I found it less easy to use.

I do like that the favorite is now a little star. i have a custom css that adds a star on the upper corner of my favorites when looking at their thumbnail, so this goes along with that rather nicely.

Is it normal that on mobile, touching an image doesn't toggle notes anymore?

lzhom said:
Is it normal that on mobile, touching an image doesn't toggle notes anymore?

Same on desktop, clicking the image no longer hides/shows notes. I hope this was just a mistake with the update and not an intentional change? The button underneath the image is far less convenient to toggle notes, especially on larger images.

this is absolutely sisyphean. the following CSS doesn't cater to non-re621 users. from memory.

[class*=ptbr],
[id*=ptbr],
.st-button,
.kinetic {
  border-radius: 0.35rem !important;
  box-shadow: none !important;
  font-family: Verdana, system-ui !important;
  translate: none !important;
}
#ptbr-wrapper .ptbr-etc {
  /* Right-click or Long press -> Save Image As... */
  display: none !important;
}
#ptbr-wrapper .ptbr-fullscreen-button,
#ptbr-wrapper .ptbr-favorite-button {
  padding: 0 0.6rem;
  width: unset;
}
#ptbr-wrapper .ptbr-fullscreen-button:hover {
  background-color: var(--palette-background-orange-d5) !important;
  color: #000;
}
#ptbr-wrapper .ptbr-favorite button::before {
  content: "Favorite";
}
#ptbr-wrapper .ptbr-favorite-button {
  color: #fff !important;
}
#ptbr-wrapper .ptbr-favorite-button[favorited=true]::before {
  content: "Favorited";
}
#ptbr-wrapper .ptbr-favorite-button svg {
  display: none;
}
#ptbr-wrapper .ptbr-favorite-button[favorited=false] {
  background-color: var(--palette-background-green-d5);
  color: var(--palette-text-white);
}
#ptbr-wrapper .ptbr-favorite-button[favorited=false]:hover {
  background-color: var(--palette-background-green-d10);
}
#ptbr-wrapper .ptbr-favorite-button[favorited=true] {
  background-color: var(--palette-background-red-d5);
}
#ptbr-wrapper .ptbr-favorite-button[favorited=true]:hover {
  background-color: var(--palette-background-red-d10);
}
#ptbr-wrapper .ptbr-score {
  background-color: unset !important;
  font-size: inherit !important;
  margin: 0 !important;
  padding: 0 !important;
  height: unset !important;
}
#ptbr-wrapper .st-button,
#ptbr-wrapper .ptbr-resize-select {
  align-items: center;
}
@media (min-width: 700px) {
  #ptbr-wrapper .st-button,
  #ptbr-wrapper .ptbr-resize-select {
    height: 1.85rem !important;
  }
}

The switch to the star really makes things unclear, I think the changes are bad and headed into just more bad changes at this rate.
as well as it broke my custom css.
It was quick to replace but it really makes the response of "just use your own css if you don't like any changes" feel really hollow and dismissive if you can't even make changes that keep those working.
Im not usually one to complain but this entire thing is quite aggravating.

- Making the buttons bigger is good. They're easier to hit on mobile and desktop now.
- I don't think the design language of the new buttons matches the current UI, they look a bit out of place.
- I don't like replacing the word "Favorite" with a star, it makes it harder to press/parse. It's probably the most used button of the bunch yet it's the smallest one.
- Getting rid of the "Adding post to favorites..." notification at the top is unfortunate, but buttons having a "processing" state mostly makes up for it.

#ptbr-wrapper .ptbr-favorite-button {
  &::before {
    content: "Favourite";
    color: white;
  }

  &[favorited="true"] {
    box-shadow: 0 .25rem #957d2d;
    background-color: #c6a534;

    &::before {
      content: "Unfavourite";
    }
  }

  svg {
    display: none;
  }
}

I didn't think the new favorite ui could get worse but dear god it somehow did, now there's no color anymore at all other than the star getting filled in which makes it Even Harder to tell what is & isn't favorited.
.
Also the decision to put the download button behind 3 dots with it being the Only thing there is... questionable.

Buttons are fine now, imo; slightly better on desktop, and a bit of a sidegrade on mobile.

The notes change however, is perplexingly bad. Clicking/tapping on the image was a fast and easy way to switch between focusing on the image and whatever the notes have to say. Now, if you want to, say, go panel by panel in a comic, reading translated text and then taking in the original artistry of the panelling/text layout, it is significantly more difficult. Instead of read, click, admire, click, you add a scroll to the bottom, scroll up, find your place to each click action. I don't see an issue with having both methods be usable, if keeping the new notes button would be of use to others, but for me at least it's rather less useable than the previous setup.

Great, first they make it worse and when I find a cludge that makes things usable again they make things worse again

How do I change the fav-star back to how it used to be?

lunacy2 said:
How do I change the fav-star back to how it used to be?

Check my css above, maybe it will be helpful

Not a fan. The previous Favorite/Unfavorite was easier to read at a glance and easy to click on a small touchscreen like, say, a phone. Might be a use case to consider, I hear these smartphone thingies are getting popular. Having to really zoom in and carefully tap the little star nestled unnecessarily between other elements is frustrating. Space wasn't a premium there, before.

The star for favorites is fine, although it could be bigger for the moblie users and maybe be a brighter yellow to match the light green votes number better.
What I would like to see is the "post favorited" pop-up return.

"View" seems like an odd choice. I don't think there was anything wrong with the button being labelled Fullscreen.

I did also prefer the bigger buttons, and the download button being nested does sort of eliminate its convenience. To be honest, I didn't even notice them getting bigger with the previous update; I think their size was fine until the current iteration.

The more muted colours are nice. I get why the favourite button was coloured (glad it still is), but the fullscreen button didn't need to be. The rest of the UI is very sparing in that regard.

I wish things would stop changing for the sake of it.

colordude said:
What I would like to see is the "post favorited" pop-up return.

It's especially useful for those of us on unstable connections since it can take multiple attempts to actually favorite a post

Will customization options be added in settings for future updates? Better to give users all options at hand possible for everyone's satisfaction.

And i meant Options, not CSS.

Sorry if I'm being less through; engaging as thoroughly as I want to with you guys is taking all the time I have before work, and I think at some point we'd both prefer I actually work on the site rather than discuss working on the site. In the interest of time, I'm just going to highlight messages whose points I've already covered (in full or in part), & address a few points; I'll try to get back around to all of you, but no promises.

I'm also gonna start linking the custom CSS snippets in the order they come out, so people have an easy place to view all of their options.

Onto the new.

quetz said:
I didn't mind the previous favorite buttons but honestly the star is way too small. I could easily miss it and click something I did not intend to click on (especially since the other buttons are way bigger).

The problem with sizing is that not only are we trying to handle both desktop & mobile screens, we are also try to manage devices with different numbers of pixels per inch that are viewed at different distances from the viewer's face, with different viewers having different preferences; it's a mess. I'm planning on making a more comprehensive UI scaling system (yes, with a slider users can adjust) to address this, but that a big undertaking; it'll take a while.

quetz said:
...it's not as clear to know if I fav'd something at first glance.

I'll see about restoring the red background when a post is favorited; that'd likely be more clear.

quetz said:
Its also less intuitive to just have a star.

I'd say using a heart as is done in the post info pane would be ideal (or switching that to a star as well), but we'll see.

quetz said:
Maybe a hybrid button with a star that fills in with the word "favorite" might be the best option to fix the size and visibility concerns.

On narrow screens, having a text button would eat into horizontal real estate we don't have & we're already getting complaints about.

ilikeeagles said:
...please allow for the UI to be toggleable, like themes and e6 Icon are, with a new account setting switch.

See here for my thoughts on user customization toggles, and here for a further clarification.
Just to show we've thought about this, if we did it at all, an account setting switch would likely be the worst way to do it, as it'd be the same on every browser; storing it in LocalStorage keeps the preference locked to each browser, so people who would benefit from different setups on different devices can easily take advantage. On that note, that's how the aforementioned themes & icon are implemented as well. This is an example of the hidden complexities we're working with.

vibrantlordiction said:
Download/"View" was absolutely not a lesser-used button. It's more important than an automatic download button. It was a very important button...

I'm not discrediting your experience, but your experience is not universal. That's the core challenge of all UI/UX design; adequately meeting the needs of different kinds of users who may all use the software in radically different ways. For the person who saves all their stuff locally, an automatic download button might be vastly more important than opening in a new tab. For you, it might be the other way around.
That being said, I think either you're confused or I'm having trouble understanding your point; the View button (i.e open in new tab) currently is prioritized over the Download button.

vibrantlordiction said:
Because the new buttons have zero color feedback by default...

This is our solution to the contention over the button colors. We could not find a color that everyone liked (before you say "what about x, read this thread again; there is no pleasing everyone), so we decided to make them neutral.

vibrantlordiction said:
...and because the names have been shifting...

We picked View b/c some people didn't like Fullscreen, it is a long label, & we have a real Download button now. To those advocating for a longer & more accurate label, we're aiming for accuracy, but not at the cost of brevity.

0f8c4c9d05154171ae8 said:
May I suggest "Open Raw" or "View Source File" or something along those lines?

The former is viable, although confusing to less advanced users, & the latter is way to long. Since you're already viewing the image, View implies a different viewing mode, & is shorter than Fullscreen; that's good enough.

0f8c4c9d05154171ae8 said:
May I suggest that the one-click download button be iconified...
...And the “View” button perhaps should also be iconified to a white “Eye” symbol.

I'm very in favor of just turning these into icons; language-agnostic, permanently kills the label debate, more clear, greater flexibility for sizing due to the square ratio of most icons.

vibrantlordiction said:
...because the names have been shifting, I initially thought the new dropdown menu had completely replaced the Download button, and I wouldn't even be ABLE to access the direct image URL anymore, and was absolutely panicking and ready to go ballistic on the forum...
Also more proof that being clearer about button language is having the opposite effect.

Only when a user used to the old layout first sees the new one; for new users & people who are used to it, it's far more clear. It only caused problems for you b/c it contradicted your expectations. I'd be curious to see how you feel about it now that you've had some time & distance to temper that first impression. I can understand being surprised at first, but you just said you're aware that the names have been changing & you noticed a button with an icon that commonly indicates more options are available; I don't think your immediate judgement, as understandable as it is, is very substantive evidence of an objective failure of clearer language. Especially when your first thought isn't to open the menu or more closely read the button labels, but to complain on the forums; that speaks to confusion born from change, not confusion born from an inherent lack of clarity. I'd like to hear if your opinion has softened, or if it hasn't, why you still find this confusing after gaining familiarity.

vibrantlordiction said:
Users being able to customize things with CSS is irrelevant, I know it exists, it doesn't fix anything, because 95% of users don't even know it exists...

I'm aware, that's why we're trying to improve the UI for those who can't customize it themselves. Additionally, every single time there's a complaint about the UI, without fail, someone brings up custom CSS. If it's such a problem for a user that they seek help with it, they will learn about custom CSS, & likely have a snippet already made, if not made soon.
That being said, I find this point very frustrating when people who raise it also say they want an option in the exact same menu (though as said prior, we're not putting it there); if no one is going to be aware of custom CSS b/c it's hidden in user settings, then no one's going to be aware of a UI customization button placed on the same submenu. That makes this similarly useless as a proposed solution, on top of the points raised prior; it's just that instead of being told to copy-paste a premade snippet that does exactly what you want, you have to be told to change an option that may or may not solve some of your problems. There's some other points that separate them, but for the most part, what's the difference?

vibrantlordiction said:
...and most who do, don't know how to use it, myself included.

1. Go to Settings -> Advanced -> Customization -> Custom CSS
2. Paste any of the multitude of provided snippets in the box.
3. Press Save Settings
There's not much more we can do to simplify this. If you're just using other people's fix-it snippets, it's dead simple.

vibrantlordiction said:
Sure, I can theoretically change the button's color for me specifically... by default, 99% of users will have no immediate color feedback for the buttons. CSS can maybe fix MY personal issue about button colors... but that doesn't change anything for everyone else.

Here's the thing; none of us speak for all of us. Some people like the current buttons:

0f8c4c9d05154171ae8 said:
I love the new Favourite button’s design, it’s exactly how one would expect it to work.

rekterthealebrije said:
I do like that the favorite is now a little star. i have a custom css that adds a star on the upper corner of my favorites when looking at their thumbnail, so this goes along with that rather nicely.

And some people hate them. There's benefits & disadvantages to both, but at the end of the day, some people simply do not care how objectively or subjectively better or worse something is; they just do not like it & want it that specific way, and that's ok, but we cannot please everyone.
In v25.08.20, we changed the buttons to address criticisms of the prior update, and now people are complaining that they thought the prior update was great; all of which is fine, I'm not complaining about that, I'm just trying to illustrate that there's no pleasing everyone without an extremely granular customization option. We do not have the resources to make a system like that while also making it accessible to users, so we simply gave users the ability to perfectly customize to their preferences with the (almost) the same tools we use. So long as we get most of the way there & keep things consistent when we do (put a pin in it), that's the best we could possibly do.

vibrantlordiction said:
Sure, I can theoretically change the button's color for me specifically, but that's a very, VERY high and advanced level of site usage... and requires specialized knowledge of how to even use it.
...I'd have to learn an entire damn programming language to change the color of two buttons, or go and whine at someone else to do it for me...

That's the thing; that's objectively untrue, especially if you're working with a premade snippet.

#ptbr-wrapper .ptbr-favorite-button[favorited="false"] {
 background-color: rgb(47, 157, 47);
 box-shadow: 0 .25rem rgb(0, 100, 0);
}

selector {
   property1: value1;
   property2: value2;
}

#ptbr-wrapper .ptbr-favorite-button {
   property1: value1;
   property2: value2;
}

#ptbr-wrapper .ptbr-favorite-button {
   background-color: value1;
   property2: value2;
}

Obviously, this isn't a full lesson in CSS, but if you already have the selector & the property, just changing a color takes 2 minutes total & zero expertise; if you don't have the property it varies but usually only takes 5 minutes & 20 seconds worth of instruction; if you don't have the right selector, that can be challenging (especially when, as in this example, it's dependent on an attribute selector), but typically takes 10 minutes & 5 minutes worth of instruction.

I didn't link the Mozilla Developer Network docs because I wanted people to spend 2 months learning CSS, I linked them because 5 minutes of reading the intro to CSS & the occasional 10 seconds of searching on there will let you customize the UI how you want 75% of the time, & if you just want to change a color in a snippet someone already made for you, it takes 1 minute of reading this & 1 minute reading how to properly type the color.

I'm trying to empower people to customize the site how they like because - with the work I already did making the snippet as a template - they could have changed the color to whatever they wanted in the time it takes to read my posts. I don't expect people to fully learn CSS; hell, I don't expect actual web developers to fully learn CSS. Just knowing the basics & looking it up for a couple minutes works fine, & that's something anyone can do.

azreal said:
"If you don't like our changes, we recommend you adopt a second career as a programmer". That's a little impractical for most of us and comes across as really insincere.

I truly apologize if that's how it came off, but I'll remind you that those comments were made at the same time I gave you CSS snippets, snippets I specifically formatted & even gave some instructions for tweaking. I was never saying "got a problem, go learn to fix it yourself lol"; I specifically acknowledged that not everyone is willing/able to learn even that smidge of CSS (which, again, is 100% fine).

aacafah said:
And finally, I forgot to properly thank the other users who've been creating, customizing, tweaking, & sharing their custom CSS, specifically opaquetopus & MkLXIV. We provide that field because we care about enabling users to customize their experience (again, as much as practically feasible), and this work enables our less technically-inclined users to do so as well; regardless of whether it's in response to contentious UI changes or not, this is great work that's worthy of being celebrated.

Again, if that's how it came off, I'm sorry, but I never said this.

aacafah said:
If you want to learn how to make your own (or tweak theirs), the Mozilla Developer Network is a great resource for all things web development, including CSS.

aacafah said:

supina said:
I don't like them. At least we should get an option to switch back to the old UI like in Wikipedia.

See here for my thoughts on user customization.

We already enable users to customize the site's appearance through custom CSS, & there are a multitude of premade snippets that do what you want. If there's a compelling reason you find them insufficient, specify what they are & maybe other users (or myself, if I have the time) can address them.

I admit I got close to it here, but that's because I was trying to give you what you wanted & encouraging you to tweak it if you wanted, because, again, everyone wants different things & I can't make everyone happy.

aacafah said:
If the following snippet doesn't look right, you're gonna have to play with it yourself (or hope someone else does & shares it) to get your desired results. I've already discussed resources to learn how to change these yourselves (I promise, it's not hard for changes like these), & I don't have the time to customize it for everyone, nor the time to find the exact way the old UI was laid out & translate that for the new HTML. I'll save you some time & tell you you're gonna wanna tweak the width, height, padding, margin, & box-shadow properties; what values to use are up to your tastes.

I think I'm justified at being a little hurt at you characterizing "I'm sorry if this isn't exactly what you want, but I tried my best to get you all the way there, & I even left a roadmap to get you there; from what I can tell, you're only 2 minutes of walking away!" as "Oh, you wanna go there? Let me drive you to the middle of the woods & leave you there; you figure out how to get there".

azreal said:
Great. You get near-universal disapproval for all these unwanted UI changes and what do you do? Make even more of them. You seem to think that user custom CSS is the be all and end all of fixing web developers mistakes.

1, I didn't make any of these changes; I'm reporting back to the people who did & trying to argue on your behalf. I can't just overrule them, & we don't function in a hive mind.
2. The people who did make these changes are strongly tempted to kill custom CSS because every update we get swarmed w/ requests (that I put a lot of effort into trying to fulfill and am happy to do so when I'm able), and whenever we make future changes, we get swarmed with complaints about it breaking. Is that what you'd prefer? This isn't a threat; despite the desire, there's been zero actual discussion about killing it (because as I've said, despite the troubles it causes us, we value empowering our users to customize their experience as much as we feasibly can); I'm just saying this is an option, & if you don't want to utilize it, we're limited in what we can do, especially in the short term.

We've taken numerous pieces of feedback from this thread & other forum posts (tapping on the score number shows the score ratio, re-adding the alert, fixing the star not being filled, revising the contentious colors, tweaking & retweaking the button sizes, tweaking & retweaking the button labels, stopping the toolbar from breaking into 2 rows,...), so let's not pretend we aren't listening & engaging with your feedback. As stated before, what one of you likes, another hates, & we cannot please everyone; we're trying to find a middleground that works best for everyone.

azreal said:
Drop down menus are to be avoided when possible in web UI design as a general rule. Think carefully whether a drop down menu makes things more, or LESS convenient before implementing one.

We know. That's why View isn't in there on wide enough screens; we're planning on pulling everything out of it on wide enough screens & only adding to it when certain buttons would overflow the screen.

nanomecho said:
Will customization options be added in settings for future updates? Better to give users all options at hand possible for everyone's satisfaction.

Again, see here for my thoughts on user customization toggles, and here for a further clarification.

nanomecho said:
And i meant Options, not CSS.

Again, would you rather have it as a fallback, or not at all?

I don't have the time to continue this; I'll still be reading what you guys are saying & reporting back to the rest of the team, but don't expect my prior levels of thoroughness; it clearly isn't effective enough at adequately engaging with your concerns, & is taking way too much time to do, time I could spend on adding new features (before you give a snarky response, I said adding new features, not revising the CSS; I've linked my contributions before, you can see for yourself. I don't like screwing with UI; I'd rather do stuff like add groups to the post search).

Again, thank you to those putting the time and effort into helping other users by making custom CSS snippets.

aacafah said:
I'm very in favor of just turning these into icons; language-agnostic, permanently kills the label debate, more clear, greater flexibility for sizing due to the square ratio of most icons.

I'd argue that icons have a habit of being less clear, more ambiguous. Like the example of having an eye icon in place of View. To me, the eye icon says "show/hide" something, perhaps notes or the image itself if blacklisted, and doesn't indicate it's a direct image link. That's something I really dislike with modern UI designs, making everything generic icons that have no clear meaning and you just have to try it to find out what it means yourself (and I'm not a fan of clicking random icons to figure out what they do). It's one thing to have icons alongside text labels as an aid to help clarify meaning, but they're not a replacement. I like my text labels as they're better at conveying meaning, where even if certain chosen words are imperfect, they're easier to infer intent; "Fullscreen" for example isn't difficult to infer it's for making the image take up the page, or "View" meaning to view the image (in a way that's different from in the page); these may not be the best word choices to indicate it's a direct image link, but they're easy to "get". Icons, in contrast, come across as trying to imbue meaning into a pictograph, like you're filtering what you mean into a select set of icons, and we need to reverse that to figure out what you meant by using a given icon, rather than the particular icon being inherently meaningful. I just want to be able to read what it is, not guess what the UI designer means by the given icon choice.

This may have been brought up before, but I've noticed the site running slower with the past few UI updates. Pages take longer to load, favs/votes take longer to register, etc. I remember I was always impressed by how simple it was and how well it ran on slower hardware. It would be nice if there was something like old.reddit.com.

watsit said:
I'd argue that icons have a habit of being less clear, more ambiguous. Like the example of having an eye icon in place of View. To me, the eye icon says "show/hide" something, perhaps notes or the image itself if blacklisted, and doesn't indicate it's a direct image link. That's something I really dislike with modern UI designs, making everything generic icons that have no clear meaning and you just have to try it to find out what it means yourself (and I'm not a fan of clicking random icons to figure out what they do). It's one thing to have icons alongside text labels as an aid to help clarify meaning, but they're not a replacement. I like my text labels as they're better at conveying meaning, where even if certain chosen words are imperfect, they're easier to infer intent; "Fullscreen" for example isn't difficult to infer it's for making the image take up the page, or "View" meaning to view the image (in a way that's different from in the page); these may not be the best word choices to indicate it's a direct image link, but they're easy to "get". Icons, in contrast, come across as trying to imbue meaning into a pictograph, like you're filtering what you mean into a select set of icons, and we need to reverse that to figure out what you meant by using a given icon, rather than the particular icon being inherently meaningful. I just want to be able to read what it is, not guess what the UI designer means by the given icon choice.

For that specific example, I'd prefer a open link icon to an eye, but I'd say that when used consistently within & across sites, you can intuit their meaning pretty easily. You can recognize a download button, contextually recognize an upvote & downvote button, etc. If it doesn't hurt, adding labels can always increase clarity, but I'd say well-selected icons can be just as clear.

aacafah said:
For that specific example, I'd prefer a open link icon to an eye, but I'd say that when used consistently within & across sites, you can intuit their meaning pretty easily.

I think this elegantly shows the problem. Ultimately what you have is a Direct Image Link, which would be the ideal label. Fair enough that you can't use that due to size considerations, but rather than using a shorter term or word to say basically the same thing within the size constraint, you're limiting yourself to a select set of icons. You say it's not bad "when used consistently within & across sites", which may be true to a point, but here we see it's not being used consistently. The aforementioned open link icon is used for an (and is called) "external link". It's saying it's taking you off-site, to a place this site doesn't control. It's essentially a Caution icon for a link. If I saw that under the image, I'd think it was taking me somewhere away from e6, perhaps the top source link or something, and wouldn't associate it with a direct image link like I can with the labels. The issue ultimately is, there isn't a commonly used icon for what the link is for, and trying to find a "different but close enough" icon will inherently give the wrong impression since the other icon's already associated with something else (and using a custom or more obscure icon will be that much harder to infer meaning from, vs simply using text to simply say what you mean).

I'd agree it's a matter of finding a similar enough icon, but I'd say it's so close it doesn't matter, and would still be more roundly accepted than any label we attempted to use. People are clearly going to react surprisingly negatively no matter the words, so any icon stands a better chance.

aacafah said:
For that specific example, I'd prefer a open link icon to an eye, but I'd say that when used consistently within & across sites, you can intuit their meaning pretty easily. You can recognize a download button, contextually recognize an upvote & downvote button, etc. If it doesn't hurt, adding labels can always increase clarity, but I'd say well-selected icons can be just as clear.

I'm not sure what you call the "open link icon" would be all that good, since it's generally used to differentiate external links from intra-site links, both on here and elsewhere (I know that the CDN is technically a different domain, but most users wouldn't consider e6's image host "separate" from the rest of the site).

I think you'd want an icon that more clearly communicates that the user is opening something that's already on the current webpage in some other way. I feel like something similar to a picture-in-picture icon or an expand image icon would get the idea across more succinctly.

The new buttons are fine imho, but the new default keybinds are a bit annoying.

Switching F to toggling faves as opposed to having F and Shift+F for fav/remove makes it really easy to accidentally remove things from your favorites if you're not paying attention.

I know about the keyboard shortcuts page but those don't seem to be saved with my account. I, like many others presumably, use e621 mainly in private tabs, so having to go in and remember to reassign my shortcuts the way they used to be is a bit of a hassle.

Hope this is the right place for that, and thanks for running e621!

aacafah said:
I'd agree it's a matter of finding a similar enough icon, but I'd say it's so close it doesn't matter, and would still be more roundly accepted than any label we attempted to use. People are clearly going to react surprisingly negatively no matter the words, so any icon stands a better chance.

I mean, people were fine with a single "Download" button for like a dozen years (after it was changed from "View original" or something), and they were fine with it using a download icon on mobile since the mobile layout was added in 2019 or whatever. it's only now that we're deciding we need a new button that links to that same content in a slightly diffrent way that we need to change the language of the buttons.

if I'm being honest I don't think a button that's just the exact same as right-clicking/long-tapping the existing button and selecting "Download link" is all that necessary. I mean, do people save stuff to their personal machines often enough that removing those few extra steps really helps that much? especially when you just add other, diffrent extra steps by putting the download link into a submenu anyway? the kind of people who save porn and stuff to their hard drive already know how to save stuff to their hard drive.

dba_afish said:
If I'm being honest I don't think a button that's just the exact same as right-clicking/long-tapping the existing button and selecting "Download link" is all that necessary.

And if you use samples? That's only effective if you use original.

As for exactly which icon to use, I was gonna be late for work, so I wasn't looking very hard; I'm sure there's a better one (image upscale is a nice option).

neocypher said:
The new buttons are fine imho, but the new default keybinds are a bit annoying.

Switching F to toggling faves as opposed to having F and Shift+F for fav/remove makes it really easy to accidentally remove things from your favorites if you're not paying attention.

I know about the keyboard shortcuts page but those don't seem to be saved with my account. I, like many others presumably, use e621 mainly in private tabs, so having to go in and remember to reassign my shortcuts the way they used to be is a bit of a hassle.

Hope this is the right place for that, and thanks for running e621!

That's... A very good point. That complicates things. We could tweak the defaults, next weekly update, but I guess the simple immediate answer would be to use the progressive web app to isolate that data from your main browser while persisting local storage?

aacafah said:
And if you use samples? That's only effective if you use original.

that's right-clicking on the image and selecting "Save image". you can right click on the link to the full-size image (the button now labled "View") and download the contents of the link, it works with any link on the internet, video, image, html, whatever.

aacafah said:
That's... A very good point. That complicates things. We could tweak the defaults, next weekly update, but I guess the simple immediate answer would be to use the progressive web app to isolate that data from your main browser while persisting local storage?

The PWA would work as a band-aid, although that would mean the settings are still per device. Keeping settings consistent on a per-account basis would be the cleaner solution imho (like how it already is with some other site settings like default display mode).

My humble thoughts as mobile-exclusive user:

The toolbar is fixed! it's all in one row as it should. However now the text inside the "resize" selector cuts off after the few first letters, making it read as "Sample (", "Fit (Vertic" and "Fit (Horiz"

I appreciate the addition of the Download button now just immediately downloading the thing instead of first opening the raw file in a new tab, since whenever i choose to view the raw file, i just set it to "Fit (Vertical/Horizontal)". but it's just my preference.

Id appreciate it if the source/download button returns the main bar rather than being hidden in a collapsible button

wait a sec, why a star and not a heart? we already use ♥ to denote favcount on the posts index, and I think that symbol is even more associated with the concept of favouriting stuff on the internet.

Round 2: The latest things people have made get it pretty close but I'm still a stickler for the behavior of the old download button being simply an anchor tag to the image source(sometimes I outright use it to open the full image, sometimes I alt+click to save as), and monke neuron activation demands it say "Download" since I'm already here in the guts of the thing.

I've Frankensteined together the CSS from wife and Rekuba above. Primarily it's wife's; I don't use re621, but that CSS gets things most of the way there just fine. Then I added in the re-ordering used by Rekuba to put things back into fav/download/size. For my own specific change to this, I hid the main download element since the "View" text was in the way, and replaced it with an :after pseudo-element containing "Download". This messed up spacing on the buttons and there's probably something extremely simple to adjust that but I couldn't figure it out playing with properties in the pseudo. Instead I was able to wing it by increasing the gap property in Rekuba's re-order to 26px, and it looks close enough on PC again.

/* Abandon all hope ye who style here */
[class*=ptbr],
[id*=ptbr],
.st-button,
.kinetic {
  border-radius: 0.35rem !important;
  box-shadow: none !important;
  font-family: Verdana, system-ui !important;
  translate: none !important;
}
#ptbr-wrapper .ptbr-etc {
  /* Right-click or Long press -> Save Image As... */
  display: none !important;
}
#ptbr-wrapper .ptbr-fullscreen-button,
#ptbr-wrapper .ptbr-favorite-button {
  padding: 0 0.6rem;
  width: unset;
}
/* Stuff for hidden button left in for reference */
#ptbr-wrapper .ptbr-fullscreen-button {
  background-color: rgb(160, 82, 45) !important;
}
#ptbr-wrapper .ptbr-fullscreen-button:hover {
  background-color: rgb(150, 72, 35) !important;
}
/* Hide the html text bit of the element that says "View"
   Replace with an -after pseudo-element that displays "Download"
*/
#ptbr-wrapper .ptbr-fullscreen {
  visibility: hidden;
}
/* Don't forget the hover color change */
#ptbr-wrapper .ptbr-fullscreen-button:hover:after {
  background-color: rgb(150, 72, 35) !important;
}
#ptbr-wrapper .ptbr-fullscreen-button:after {
  display: inline-flex;
  align-items: center;
  padding: 10px;
  content: "Download";
  visibility: visible;
  position: absolute;
  box-sizing: border-box;
  background-color: rgb(160, 82, 45);
  border-radius: 6px;
  height: 2rem;
  justify-content: center;
  line-height: 1rem;
}
/* Fix the other buttons */
#ptbr-wrapper .ptbr-favorite button::before {
  content: "Favorite";
}
#ptbr-wrapper .ptbr-favorite-button {
  color: #fff !important;
}
#ptbr-wrapper .ptbr-favorite-button[favorited=true]::before {
  content: "Unfavorite";
}
#ptbr-wrapper .ptbr-favorite-button svg {
  display: none;
}
#ptbr-wrapper .ptbr-favorite-button[favorited=false] {
  background-color: rgb(0, 100, 0);
  color: white;
}
#ptbr-wrapper .ptbr-favorite-button[favorited=false]:hover {
  background-color: var(--palette-background-green-d10);
}
#ptbr-wrapper .ptbr-favorite-button[favorited=true] {
  background-color: var(--palette-background-red-d5);
}
#ptbr-wrapper .ptbr-favorite-button[favorited=true]:hover {
  background-color: var(--palette-background-red-d10);
}
#ptbr-wrapper .ptbr-score {
  background-color: unset !important;
  font-size: inherit !important;
  margin: 0 !important;
  padding: 0 !important;
  height: unset !important;
}
#ptbr-wrapper .st-button,
#ptbr-wrapper .ptbr-resize-select {
  align-items: center;
}
/* Reorder View, Download and Resize */
#ptbr-wrapper {
display: flex;
flex-wrap: wrap;
gap: 26px;
}

.ptbr-resize {
order: 3;
}

.ptbr-fullscreen {
order: 2;
}

.ptbr-etc {
order: 1;
}
}

Is the download button supposed to be inside a [...] menu or did I mess something in my settings?

shloppo said:
Is the download button supposed to be inside a [...] menu or did I mess something in my settings?

Yes to the former.

shloppo said:
Is the download button supposed to be inside a [...] menu or did I mess something in my settings?

Note that the Download button in the ... menu is technically new. The old Download button was renamed to View, since it didn't actually download it and just loaded the image directly, and the new Download button actually downloads it.

I don’t like them, I preferred the old version

i don't mind tbh, as long as they work well then am happy enough :)

one addition i would like to see tho, is if you fave a post then it automatically adds a like

currently (afak) you have to fave and like separately on E6

but on other sites like Derpi, adding a fave automatically adds a like

i would like to see this happen on E6 too

bogdanurs said:
i don't mind tbh, as long as they work well then am happy enough :)

one addition i would like to see tho, is if you fave a post then it automatically adds a like

currently (afak) you have to fave and like separately on E6

but on other sites like Derpi, adding a fave automatically adds a like

i would like to see this happen on E6 too

My problem with that is that fav isn't necessarly the posts that you like the most but also just posts you'd like to put in a seperate gallery.

dappe said:
My problem with that is that fav isn't necessarly the posts that you like the most but also just posts you'd like to put in a seperate gallery.

I think you should look up the definition of favorite
Also any feature like this would definitely have a toggle

spectre110 said:
I don’t like them, I preferred the old version

"Is bad, make good" is not a very useful critique. If you just want to vent, you've achieved your goal, pay this no mind; if you want us to make informed decisions about the future of the UI, could you be even slightly more specific? If you look back, you'll notice a wide variety of opinions about exactly what was good before & what is bad now (with some even preferring certain elements of the current design over the former), so we can't read your mind and determine what you specifically do & don't like.

The popup when a fav is added was useful because sometimes an error would occur and i would know it wasn't saved. It wasn't redundant.

It's hard to tell if an image is fav with new look, but I'm sure I'll get used to it. I would prefer something more obvious, I see others agree. Asking users to add filters or code to customize on their end is not the solution.

My biggest issue is the inability to remove the annotation boxes from an image by tapping it. Please fix this as some images are covered in white boxes. Maybe I'm missing something. *shrug*

kthx

I've been messing around with the buttons to see if I can get them to "feel" better. I think the favourite button's icon should have a dark fill when the post isn't faved, I think it better communicates an "empty" state than having no fill like it currently does.

what I ended up liking was this:

.ptbr-favorite-button svg {
  color: var(--color-link);
  fill: var(--color-foreground);
  stroke-width: 1.67;
}
.ptbr-favorite-button[favorited="true"] svg {
  color: var(--palette-background-gold-d10);
  fill: var(--palette-background-gold-d10);
}

which look like this.

Something very small and probably stupid, but I'm mostly here on moblile and the Download Fullscreen button was a nice one click. It may sound dumb but I put images in full screen a lot so I can zoom in, and now with the button behind a menu it's adds up pretty quick for me. Is there a personal way to work around it?

On that note, my phone is pretty big so I might as well ask here if I could move buttons around the UI? I tried mobile gestures and it never works consistently.

lightc said:
Something very small and probably stupid, but I'm mostly here on moblile and the Download Fullscreen button was a nice one click. It may sound dumb but I put images in full screen a lot so I can zoom in, and now with the button behind a menu it's adds up pretty quick for me. Is there a personal way to work around it?

On that note, my phone is pretty big so I might as well ask here if I could move buttons around the UI? I tried mobile gestures and it never works consistently.

Here's my solution that solves the problem that you've stated but....

.hidden { display: block;}

This can be made better by appending the class/id of just the menu button to the front but I can't find it at the moment

Ah found it

.ptbr-etc-menu { display: inline; }

snpthecat said:
Here's my solution that solves the problem that you've stated but....

.hidden { display: block;}

This can be made better by appending the class/id of just the menu button to the front but I can't find it at the moment

Ah found it

.ptbr-etc-menu { display: inline; }

It works! Doesn't look too pretty but it still does the job. Is there any way to push the "prev" and "next" buttons to the left or right side of my screen? (And the Fullscreen button lol.) I don't mind if there's a place to learn how to quickly tinker with CSS as well so I'm not a bother to anyone. (But I'm an idiot with coding so probably a stupid ask from me.)

here's all the changes I'd personally make to the current ptbr stuff for mobile:

/*make sure buttons have consistent font sizes and vert alignment*/
#ptbr-wrapper .st-button { font-size: .85rem; align-items: center; }

/*slight fav button redesign*/
.ptbr-favorite-button svg {
  color: var(--color-link);
  fill: var(--color-foreground);
  stroke-width: 1.67;
}
.ptbr-favorite-button[favorited="true"] svg {
  color: var(--palette-background-gold-d10);
  fill: var(--palette-background-gold-d10);
}

/*always show "View" button*/
#ptbr-wrapper .ptbr-fullscreen {
  margin-left: -.375rem;
  display: flex;
}

/*view icon (placeholder), slightly reduce horizontal footprint*/
#ptbr-wrapper .ptbr-fullscreen .ptbr-fullscreen-button {
  font-size: 0.000001px;
  padding-left: .67rem;
}
#ptbr-wrapper .ptbr-fullscreen .ptbr-fullscreen-button::before { 
  font-size: 1.67rem;
  font-weight: 700;
  content: "↸";
  transform: scaleX(-1);
  color: var(--color-link);
}

/*reduce resize dropdown footprint (preferably we'd change the strings so they all fit nicely, currently just "Original" does, "Sample" kinda does)*/
.ptbr-resize select { max-width: 5rem; }

/*always display note toggle on posts with notes on posts with notes*/
.ptbr-notes { display: flex }
.c-posts.a-show:not(:has(#notes>article)) .ptbr-notes { display: none; }

/*notes toggle icon, reduce horizontal footprint*/
.ptbr-notes-button { width: 3.33rem; text-wrap: nowrap; }
.ptbr-notes-button::before { content: "⎘"; font-size: 1.25rem; margin-right: -.2rem; }
.ptbr-notes-button::after { content: ": On"; }
.ptbr-notes-button[enabled=false]::after { content: ": Off"; }

/*hide etc menu*/
.ptbr-etc-toggle { display: none; }

for me this makes all the shown buttons visible on viewport widths down to 378px without causing an overflow. and on my own base viewport width of 432px I can just barely fit the etc button there as well, although getting that close to the screen edge is not ideal.

honestly, I fell like it might be better to just have one or the other of the download or view button, and then allow the user to toggle its behavior between opening the image in the current tab or opening a download dialogue. I do genuinely believe that pseudo-context menus like the etc menu ought to be avoided as much as possible, especially for purposes that are semi-common like hiding notes or full-screening page content. and definitely should just not exist when they contain only one option.