61–70 of 308 posts
I almost always need to rotate photos 90⁰ to the right, so I have to tap that button three times. Apart from that, if I have only one way to rotate my photo, clockwise seems more intuitive to me anyway.
I understand the design principle but I would argue it's a bad implementation principle. Engineering attention is finite. Why would you spend time thinking about 8 clicks when most people will only need ~3? Not all user-action possibilities are equally important, and if they are, then you better have infinite resources to spend on engineering.
It's not really a question of how many taps they support, but how fast . This same issue also seems like it would prevent you from quickly double-tapping the button to turn an image upside-down, a much more common use case.
I don't know, I understand the principle, but I don't see how you can determine the value of a principle outside of a specific context.
Even for accessibility, we can't target every context in the name of being accessible. We still have to pick which contexts of inaccessibility we'll need to support with more attention.
Earlier quoted context omitted.
What’s wrong with flat UIs? Skeuomorphic designs have served their purpose of helping people get used to computers, but now that is no longer necessary.
[flagged]
Camera app should negate the need. most pictures are of people and scenary, and 99.99% of the time the intent is to take the photo in the right order. Simple totally offline ONNX models exist, whcih should make it trivial to categorize the right orientation. Acceleometer/magnetometer can feed this, but should not be the default. Just do this and avoid the hassle of rotating at all!
Earlier quoted context omitted.
[flagged]
I’m being serious. I find skeuomorphic UIs to be too visually overwhelming compared to flat UIs.
a) a different statement from "I prefer X"
and
b) pretty low effort, trivially to Google (or ask AI) and generally a bit on the ignorant side
A better reply would not just have said what it said but contained actual wonder about the topic. Like this, it's just indistinguishable from engagement bait.
A different UX issue I have with these buttons is that the designers seen to have chosen the wrong rotation direction. I almost always need to rotate photos 90⁰ to the right, so I have to tap that button three times. Apart from that, if I have only one way to rotate my photo, clockwise seems more intuitive to me anyway.
I used to have a device with a physical button which, when you pressed it, would beep and add 30 seconds to the time. However, sometimes it would beep and not add 30 seconds, and sometimes it would add 30 seconds without beeping, so you always had to squint at the dim display to discover whether it had worked or not. I thought this must be a peculiarly bad design ... but since then I have lost count of the number of…
> Why? How, even, have they implemented this? This is really common because of two design features that most UI frameworks share: - The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler ha…
No, but what should happen in cases like that is that the on-click handler disables the button while it is unresponsive. This will communicate the fact that the button is unresponsive visually to the user and also inhibit the button-was-pressed feedback.
Earlier quoted context omitted.
There’s effectively no universal list of UX warts people agree with. The Flat UX fad was objectively terrible on just about every metric I was taught, but people were actively pushing for such designs.
Why was that? What causes such fads? Why did everyone go along with it?
Earlier quoted context omitted.
It's not really a question of how many taps they support, but how fast . This same issue also seems like it would prevent you from quickly double-tapping the button to turn an image upside-down, a much more common use case.
Not prevent, just not provide very responsive feedback, right? I don't know, I understand the principle, but I don't see how you can determine the value of a principle outside of a specific context. Even for accessibility, we can't target every context in the name of being accessible. We still have to pick which contexts of inaccessibility we'll need to support with more attention.