Topic: Double clicking an image should upvote the image

Posted under General

The upvote button is small on mobile and too far for my right thumb to reach. Hard to use when using this site with one hand.

redphoenix42 said:
The upvote button is small on mobile and too far for my right thumb to reach. Hard to use when using this site with one hand.

Brother can't upvote a post because his other hand is occupied. đŸ˜­

Watsit

Privileged

Clicking an image (is supposed to) show/hide notes on an image (it seems to have broken recently, but hopefully will come back). Having double-click cause an upvote would likely cause accidental upvotes from people trying to hide and show notes. It would also create an uneven interface by not having an appropriate gesture to downvote an image.

watsit said:
Clicking an image (is supposed to) show/hide notes on an image (it seems to have broken recently, but hopefully will come back). Having double-click cause an upvote would likely cause accidental upvotes from people trying to hide and show notes. It would also create an uneven interface by not having an appropriate gesture to downvote an image.

the notes thing is now a toggleable third option that shows up in the download/fullscreen ellipsis (where applicable) which is a bit better because I hate when I zoom in to read or touch the tiny notes but I miss and they all disappear so you gotta tap and try again then miss and do it all over again

Updated

Watsit

Privileged

fliphook said:
the notes thing is now a toggleable third option that shows up in the download/fullscreen ellipsis (where applicable) which is a bit better because I hate when I zoom in to read or touch the tiny notes but I miss and they all disappear so you gotta tap and try again then miss and do it all over again

Sounds like something that should be either an account/theme toggle, or handled differently on the mobile UI. On desktop there's no issue with accidental clicks for zooming since you don't touch to zoom, but scrolling down under the image to click the tiny "Notes: On/Off" button is much less convenient when you want to hide or show them while looking at the image (particularly on large/tall images like comics, where it's often used), and more prone to accidentally clicking an adjacent button (like (un)favoriting).

I thought they were trying to make the entire site more mobile friendly
And the favorite button is very centered from what I've seen be it tablet or cell phone

Watsit

Privileged

fliphook said:
I thought they were trying to make the entire site more mobile friendly

At the expense of the desktop experience, it seems.

fliphook said:
And the favorite button is very centered from what I've seen be it tablet or cell phone

On desktop, there's a set of buttons under the image. Starting from the left, there's Upvote, Combined Score (clicking on it shows the number of upvotes and downvotes separately), Downvote, Favorite, Notes: On/Off (hidden if there's no notes on the image), a drop-down for the size (to select Original, Fit (Horizontal), etc), View, and ... (which expands to Download), These buttons are all relatively small; on my screen, taking up roughly 1/4th to 1/3rd of the horizontal-fit image.

well OP is talking about these buttons on mobile being difficult to reach which I'm having a hard time to understand because it works for me so far

I may not have a PC but I have used them before and from what i remember your hand don't need to move longs distance to reach wherever you need it to go on screen

maybe redphoenix42 would like a button that reaches from one end of the pic to the other like a giant space bar just above the other options or at least as wide as the other options combined but still above them

Watsit

Privileged

fliphook said:
I may not have a PC but I have used them before and from what i remember your hand don't need to move longs distance to reach wherever you need it to go on screen

They're not usually on-screen. For example,
post #4552189 post #103247
you need to scroll down quite far to reach the Notes toggle button, whereas for years we could just click the image wherever we happened to be when we wanted to toggle the notes.

fliphook said:
maybe redphoenix42 would like a button that reaches from one end of the pic to the other like a giant space bar just above the other options or at least as wide as the other options combined but still above them

I'm not sure more stuff above the image would be a good idea. There's already enough with the two header bars and the navigation bar(s) for the search and pool(s) pushing the image down off-screen. Having more buttons to jump-to-bottom-of-image would be a poor workaround, and not solve the issue if you want to toggle them while in the middle of a taller image (there's no button there to jump down, and can't jump back to where you were).

Remember this is a forum created about upvotes, yes I did point out the note toggling and things started to get off topic and looking back at this chat I did confused upvote button with favorite button

OP wants easier access to the up arrow (the furthest to the left) and not so much the star (the very centered button I already mistakenly pointed out)

That is the thing to either think about or just tell them to get gud

Watsit

Privileged

fliphook said:
Remember this is a forum created about upvotes, yes I did point out the note toggling and things started to get off topic and looking back at this chat I did confused upvote button with favorite button

I pointed out the note toggling originally being a function of clicking the image. The O.P. wanted double-clicking the image to function as upvoting the image, which I pointed out would clash with the previous behavior that some of us want back. You mentioned removing the click-image-to-toggle-notes behavior was good for mobile, which it may be, but we'd still like it back for desktop, at least as an option since the alternatives aren't good, which would be a problem for double-clicking-to-upvote.

How about holding a click on an image to upvote it? But it has to be a click on a part of an image that doesn't have a note over it.

redphoenix42 said:
How about holding a click on an image to upvote it? But it has to be a click on a part of an image that doesn't have a note over it.

Doing that would require you to search for the spot. Would be easier to just reach for the upvote button in a familiar location in that case.

drato said:
Doing that would require you to search for the spot. Would be easier to just reach for the upvote button in a familiar location in that case.

it'd also fuck with normal expected browser behavior, since long presses bring up the context menu, like right-click does on PC.

I guess maybe having an option to use a double click to upvote in the themes and gestures settings would be the way to go especially since the tap for notes thing is now set in the ellipsis under the image

use it if you want (if/when implemented) or just stick with using the up/down arrows

Aacafah

Moderator

watsit said:
At the expense of the desktop experience, it seems.

We could just add a note toggle hotkey. We have a framework to enable desktop users to overcome almost any UI complaints; let's not throw the baby out with the bathwater when we own a colander.

Updated

this wasn't origninally about notes. the notes was something we pointed out that was changed

this was about upvoteing with one hand, specifically their right hand
they can't reach the upvote button on the left side of the screen with their right thumb

although the only time I only have one free hand to navigate the site is when I'd be driving which would be unsafe so I don't do

why does OP only have one hand available for navigation and upvotes? RedPhoenix42 better not be on the phone while driving

Aacafah

Moderator

I'm aware; I don't have an answer to that. If we moved it to 1 side or the other, that'd impact people based on handedness. Besides, even if you tried to appeal to righties, some prefer to hold the phone w/ their non-dominant hand to free up their dominant hand. For origami, I presume.

Watsit

Privileged

aacafah said:
We could just add a note toggle hotkey. We have a framework to enable desktop users to overcome almost any UI complaints; let's not throw the baby out with the bathwater when we own a colander.

Not a fan of hotkeys when web browsing since my hands aren't usually on my keyboard if I'm not typing. And especially if I want to be sure I don't accidentally press the wrong key and do a completely different action (I'm known to fat-finger keys, or end up a row off from where I thought I was; you wouldn't believe how often I end up typing fomh;er+c;aws when adding tags to a post and need to erase and retype it), I need to look away and adjust the position of my keyboard (or I need to feel for the little nib on the f or j keys and focus as I slowly feel my way to a specific key) if I want to be sure. As opposed to just moving the mouse I'm already using to click the image I'm already looking at that the pointer is already near.

Aacafah

Moderator

Hotkeys are remappable, you can just use a value that won't accidentally trigger something else; if your hand is off the keyboard, you could use the spacebar.

To return to the original topic of discussion, if sliding the toolbar to the other side would work, add this to your Custom CSS:

/* @media (min-width: 50rem) { */
  #ptbr-wrapper {
    justify-content: flex-end;
  }
/* } */

To prevent it from affecting the desktop layout, remove the surrounding /* & */ from the 1st & last lines & tweak the number 50 until it works for you.
To fold these into one another, the only fully sufficient solution would be granular yet accessible UI customization. I'll repeat my thoughts on user customization.

I am a huge proponent of user choice & freedom. I'd love to allow users (myself included) to customize changes to their heart's content; I think that's an ideal worthy of striving towards.

That being said, I'm not the head honcho, so there's that.

The problem isn't a lack of desire; we already have some theme customization (I'm still rocking the pride logo myself w/ the Bloodlust color scheme as my theme; go here & you can do the same). The problem is how to expand that practically.

Here's a little inside baseball for you; e621ng (which is open source btw; you're more than welcome to contribute to the direction the site takes) is written with Ruby On Rails, or just Rails for short. Rails is a multi-page app framework that renders everything on the server. We'll circle back to this.

The main problem is that e621 has 1 dedicated developer (that's Cinder) & a motley crew of volunteer contributors (such as myself). Having Cinder validating that these hobbyists work isn't going to make the system explode is already a ton of work. Separating out UI changes, many of which are also tightly tied to changes in how the backend server works (because everything is handled on the server, Rails & many MPA's tightly couple front-end & back-end) even further shrinks the time he can spend adding new things to the site. Adding some kind of beta site/granular UI toggle for every potentially contentious change is a herculean task that would completely halt development for weeks at the very least, probably closer to months. For a beta site, it would also require approval from & cooperation with the technical staff at Bad Dragon (the site's owners). For a granular toggle system, it would implicitly demand supporting deprecated UI elements & styles, with users rightfully imo getting very angry when we break their specific combination of UI settings while iterating the site's design & features. I'll also remind you that any & all bug fixes need to be handled by him too, meaning either those also need to put on hold, or those will eat away at the dev time for our solution.

On top of that, because Rails is rendered on the server & has tooling to facilitate that, all of the HTML (& some of the JS iirc) is embedded in .erb files that need to be processed by the server, & a lot of the JS also is tightly coupled to changes in the backend logic. Therefore, we'd need to update the server itself every single time there's a UI update regardless of whether or not the backend logic actually changed. We shouldn't lose uptime everytime, but in software development, you learn not to rely on what "should" happen pretty quick. So, instead of developing & updating the server logic & the UI at the same time, we'd have to develop the UI independently of the backend logic for much as possible, & update the server logic & UI separately. This is simply not practical, at least for the time being.

Besides, with the Settings -> Advanced -> Custom CSS option, we've already given more user customization than any other site on the planet; you can almost always get back to exactly what you want yourself without placing this burden on development.

Tl;dr, we'd love to have our version of Discord PTB, or the Steam Client Beta, but that is simply not a task we have the resources to undergo, & we place greater priority on moving the site forward than carving out exceptions so users can avoid changes.

Edit

Firstly, to include Donovan's excellent point,

donovan_dmc said:

nacre said:
So make those changes for the mobile site and not the desktop one.

before anyone says "oh but it's more to maintain" It's two buttons that worked fine for 15 years before this.

You're applying that logic to just this change when it really applies to the entire site, consider that mobile first changes are made in various places of the site, each may be just a few things on their own but combined it's a lot of things

Additionally, since I first wrote this, I've found cases where how the user's customizations are stored is also user-dependent.
The user settings pane stores all of its data on the server, & therefore all of it is uniform across all devices you sign in on; all other options (e.g. the searchbar's settings menu, the themes menu, your currently deactivated blacklist items, keyboard shortcuts, etc.) are stored in Local Storage (to be simple, inside your browser), & therefore it can be customized for each browser (/device) you use.
Server storage:

  • Eats up server bandwidth to update
  • Eats up server storage even if unused
  • Requires a page refresh every time it's changed in order to reflect updates
  • Increases the memory load on the server for every loaded user, which decreases performance
  • Increases chances of mandatory server downtime every time it changes (b/c the database must be updated as well)
  • Is persistent across all browsers used to access the site

Local Storage:

  • Is persistent on the browser it's set on
  • Virtually zero storage on users' machines
  • No mandatory page update when changed
  • Reloading the same page is also faster b/c the previously cached value is the same as the new one (as the changes only occur client-side)

Obviously, granular UI customization would be best served by being stored locally; it's specific to each browser, it adds no extra server load, & (unlike custom CSS) you can see the results as you tweak them without needing to reload the page (which obviously also decreases server load). However, the point of incognito/private windows is that they don't persist local data created during the browsing session (including Local Storage) across sessions, & many users are using incognito/private windows when accessing e6. As such, these users are limited in their options (although I'd recommend installing the PWA from an incognito/private window, as that stores its data separately from the main browser, & its initial data would be copied from the mostly empty local data from that session). Even a granular system can fail to appease everyone.

I will say that I'd be interested in looking into customizing the button ordering (& only the button ordering, specifically b/c of the customization's small scope) & hiding the option in the ribbon's overflow menu; that would probably take at least a month (maybe closer to 2, as I'd likely want/have to properly learn Vue for this), & I currently have other commitments taking priority, but I'll look into it. Do not take this as a promise; my todo list is already packed, I'm not sure how long it would take, & there's still the potential it won't be liked by the rest of staff.

Here's my solution:

/*repositions votes to the right*/
#ptbr-wrapper .ptbr-vote {
position:relative; left:260px;
}
/*repositions the image size and dropdown menu to the left*/
.ptbr-resize, .ptbr-etc {
position:relative; right:120px;
}
/*repositions fav button to the left, you can change the numerical values to move it around*/
.ptbr-favorite {
position:relative; right:120px;
}

Edit the numbers to how you want em. (left:260px means moving the object an additional 260 px to the right)

Watsit

Privileged

aacafah said:
Hotkeys are remappable, you can just use a value that won't accidentally trigger something else; if your hand is off the keyboard, you could use the spacebar.

Still less convenient to have to move my arm to my keyboard when I'm already using my mouse. This would also only work for a single hotkey (if I want to do something else that needs a hotkey, it can't also be set to use the spacebar), and wouldn't work if some text input field has input focus (URL bar, search bar, etc).

I've never heard of this "double-tap to upvote" behavior before; I'm guessing it's something that's in one of the big-name social media apps? (That would explain the "double tap now if you'd scrunkly the when" meme, kinda.) I wonder if that's what OP really wants: an app, that behaves completely differently from the website and is made exclusively with phone users in mind.

errorist said:
I've never heard of this "double-tap to upvote" behavior before; I'm guessing it's something that's in one of the big-name social media apps? (That would explain the "double tap now if you'd scrunkly the when" meme, kinda.) I wonder if that's what OP really wants: an app, that behaves completely differently from the website and is made exclusively with phone users in mind.

YouTube Shorts does it, I assume most other vertical video platforms function similarly.

watsit said:
Clicking an image (is supposed to) show/hide notes on an image (it seems to have broken recently, but hopefully will come back). Having double-click cause an upvote would likely cause accidental upvotes from people trying to hide and show notes. It would also create an uneven interface by not having an appropriate gesture to downvote an image.

Ugh, this is like the selection issues with text boxes since browser developers 'improved' them. Cursor moves for inexplicable reasons when trying to paste, too. Soooooo many misclicks out there like this, I bet.

Aacafah

Moderator

watsit said:
Still less convenient to have to move my arm to my keyboard when I'm already using my mouse. This would also only work for a single hotkey (if I want to do something else that needs a hotkey, it can't also be set to use the spacebar), and wouldn't work if some text input field has input focus (URL bar, search bar, etc).

I'm very aware of the compromises; I already said the only good solution is complete customization & that I'll look into it, but it will take a long while if it happens at all, & explained why. This suggestion was for a serviceable solution that won't take forever to implement.

You said you don't use the keyboard, so I'd say it's a pretty natural extrapolation to assume you're not currently using any hotkeys anyway (I wouldn't have suggested it otherwise), & if you're fine with using the mouse to click, you can easily change the focus already. Besides, we don't auto-focus text fields unless you click Reply or something, & if you did that (or manually clicked a text box), it's reasonable to assume you're both aware of it & are going to be using the keyboard anyway; seems like a moot point IMO.

errorist said:
I've never heard of this "double-tap to upvote" behavior before; I'm guessing it's something that's in one of the big-name social media apps? (That would explain the "double tap now if you'd scrunkly the when" meme, kinda.)

It's mainly popular in social media sites that don't have an equivalent but opposite action (e.g. Instagram & TikTok only); if we were to map anything to this, it'd be (un)favoriting.

errorist said:
I wonder if that's what OP really wants: an app, that behaves completely differently from the website and is made exclusively with phone users in mind.

I'm working on improving the PWA & hoping to use it to better handle this stuff, but keep your expectations low; I'm not making promises unless I know I can keep them.

Watsit

Privileged

aacafah said:
I'm very aware of the compromises; I already said the only good solution is complete customization & that I'll look into it, but it will take a long while if it happens at all, & explained why.

And this is what I find aggravating. A feature that has existed for years that people use, which incidentally had already broke on accident a few months ago and got people to speak up about using/wanting it back before it was fixed relatively quickly, is unceremoniously removed again with a "I want to fix it, but I can't say when and may never do it". Which essentially tells me, "don't expect it to happen". If you knew the customization would be needed for people that use the feature, could you not have held off on changing it until people could set it back as it was? It's not like the site was on the brink of breaking without the change, it could have stayed as it had been until it could be done "properly" the first time, so as to not take away features people have used for years and might get back sometime in the future perhaps.

aacafah said:
You said you don't use the keyboard, so I'd say it's a pretty natural extrapolation to assume you're not currently using any hotkeys anyway

Currently, yes. But I think it's also a fair extrapolation that being forced to use a hotkey for some feature now when I've never had to before, future changes may require me to start using more hotkeys. Considering how relatively stable this site has been over the years I've been here, even through the e6ng transition, with all the changes that have been happening in these last few months (since about Feb/March) we can't take anything for granted. I've had to add more custom CSS these last few months to unbreak a number of these changes (which is still lacking in some areas) than I have in the years I've had an account here. I have no idea what to expect going forward so I make no assumptions about what I'll need to do to keep the site functional.

aacafah said:
Besides, we don't auto-focus text fields unless you click Reply or something, & if you did that (or manually clicked a text box), it's reasonable to assume you're both aware of it & are going to be using the keyboard anyway; seems like a moot point IMO.

I don't think it's too unreasonable that I could click the URL bar or search bar first before deciding to look at an image, prior to adjusting my posture to use the keyboard. Or maybe I clicked it on accident, or some confluence of actions caused the browser to focus some text field, when I had no intention to use it. Just because a text field has focus doesn't mean I'm prepared or intended to use the keyboard.

Aacafah

Moderator

I'm not doing this again. This is the last reply you're getting on this.
1. Us devs aren't a monolith. Like I've said multiple times, I didn't make a single one of those UI changes people were complaining about, & I was just fine with how things were before (& expressed that I preferred some elements of the prior design); please stop accusing me of things I didn't do. You're yelling at the wrong guy. I'm not in charge.
2. Yes, I am telling you not to expect it, because I don't like building expectations I can't be sure I can deliver on. When/if I know I have the time & ability, I'll say so.
3. Customization is in no way "needed for people that use the feature". We are discussing UI preferences, not UI capabilities. You have all the same capabilities as you did before. You're more than welcome to have a preference, & I'm telling you I'd very much like to spend months of my time, with zero payment or reward, while working a full-time job, to cater to your preferences. If that's not good enough for you, I'd personally prefer you find a less callous way to express that.
4. I didn't say that these assumptions are universal, absolute, & cover all potential scenarios. For the last time, I am trying to help you find a temporary solution while I look into a more sustainable & scalable permanent solution, & I made well-reasoned assumptions about your situation to attempt to find that temporary solution. If that's not good enough, then I won't bother with it.
5. "I don't think it's too unreasonable that I could click the URL bar or search bar first before deciding to look at an image, prior to adjusting my posture to use the keyboard." Yes, and I don't think it's unreasonable to say that you could just click right back off while your hand is still on the mouse. Or use Tab to switch focus afterwards. Or simply try to avoid that 1% edge case & have it work in the remaining 99% of cases. I've said it how many times now;

aacafah said:
This suggestion was for a serviceable solution that won't take forever to implement.

6. "Or maybe I clicked it on accident, or some confluence of actions caused the browser to focus some text field, when I had no intention to use it." So you can't find that many scenarios where my assumptions wouldn't hold true & need to cite you misclicking the very narrow URL bar that's far away from most interactive page elements (in which case, just click off) & a cosmic ray flipping a bit in your processor. Again, my suggestion was intended to cover as many naturally-occurring cases as possible, so I'd say it does a pretty good job if you're having this much trouble finding plausible scenarios where it isn't effective.

You really seem to hold this perspective that I'm your enemy when I am actively trying to help you, & I'd really prefer it if you stopped doing that. I doubt I can help you anymore at this juncture, so I won't be trying to; you've made it perfectly clear nothing other than exactly what you personally want is acceptable. If that's the case, then you're going to have to either wait for me (or the other volunteer devs) to do that while accounting for the myriad preferences of the >2 million other people who use this site or do it yourself. And no, I'm not saying "do it yourself b/c I won't"; I'm saying I can only give you so many options, & you're going to have to pick one of them, even if it has some elements you dislike, & doing it yourself is always a valid option. I've already told you I want to do what you want me to do, and you're still angry; I can't do much else for you, & I'm wasting free time explaining this to you that could be spent working on it instead.

If this measure isn't in any way sufficient for this use case, then I won't waste time adding it. Thank you for your feedback. Now let's stop derailing this thread.

Original page: https://e621.net/forum_topics/59230?page=1