Live data from Hacker News

Front end developers: stop moving things that I’m about to click on

medium.com

141–150 of 365 posts

Re: Front end developers: stop moving things that I’m about to click on

#141
post #7

I agree with [this][1] idea: > an autocomplete has one chance to reorder per keystroke. if you got it wrong and you have a better ordering a bit later you must “swallow the sadness” (as per the original author of this wisdom) but never change already displayed items [1]: https://twitter.com/dan_abramov/status/1470751551568363530

I want foo. - Type 'f' - foo appears in the search. - Type 'o', because I type with 10 appendages and getting them to work together requires pipelining. - foo disappears from the search This should never happen.

[deleted]

Re: Front end developers: stop moving things that I’m about to click on

#142
post #92

Earlier quoted context omitted.

Following the same theme of liminal UI areas, another thing that peeves me is touch screens like my local supermarket self-checkout which respond with a beep (indicating they know I hit the button) but do nothing, because apparently the beep-region and action-region and not the same. Or maybe I dragged my finger, in which case, please don't beep.

I spent half an hour last night resolving this exact class of bug on a padded clickable widget I was making. No one told me it had to be perfect, but I care about the user and don't ever want the user to be surprised. That's the difference you get with outsourcing your engineering team vs developing in-house. If you choose a good team, your developers feel directly responsible for the user experience, go beyond state…

I personally think that was a decent use of time - 30 minutes vs a product-lifetime of not pissing off users that little bit will give a lot of goodwill payoff. But I have worked at a place with in-house developers where they probably wouldn't have showed the initiative to do it themselves, and if brought up later as an annoyance I'd be asked for a "business case" which is a complete non-starter, because how do you even begin to quantify this in a way everyone can agree on?

I value polish for its own sake highly as I think you do too, a well made tool is more rewarding to use. But the ones forecasting developer effort need a concrete justification. So it's best to just sneak this in if you can and hope other people you work with feel the same, after all it's much quicker to do it up front than to lose context and revisit it later. Asking permission will cost far more than your 30 minutes.

Re: Front end developers: stop moving things that I’m about to click on

#143
post #68
post #15

A particular bane of mine is the self-oscillating UIs, youtube is particularly bad at it these days - if the mouse pointer is in 'just the right place' (which is bigger than it sounds) then you get the seek-bar preview frames popup, which moves things just enough that the mouse pointer is no longer over the area that triggers it, so it vanishes, and the whole thing starts again.

YouTube also has the problem that there is almost no dead space to "park" your cursor. You have to carefully place it in between autoplaying previews.

Since Office apps started putting an increasing number things in the title-bar (search, autosave, username, filename) there's limited dead space to use for traditional things like dragging and maximise / restore. I'm never sure where to 'grab' or double click - I don't know if I'm going to start a click-failure cascade if I do it in the arbitrarily, non-obviously 'wrong' place.

Re: Front end developers: stop moving things that I’m about to click on

#144

Earlier quoted context omitted.

I spent half an hour last night resolving this exact class of bug on a padded clickable widget I was making. No one told me it had to be perfect, but I care about the user and don't ever want the user to be surprised. That's the difference you get with outsourcing your engineering team vs developing in-house. If you choose a good team, your developers feel directly responsible for the user experience, go beyond state…

I disagree that this is an invariant of outsourcing; I have worked plenty of places where the contractors/vendors cared more than the FTEs. Conversely, the pressure for dark patterns has generally come from the inside.

This isn't a dark pattern, it's a combination of incompetent designer-developers and a lack of robust specification (on account of assuming competence in your designer-developers)

Re: Front end developers: stop moving things that I’m about to click on

#145
post #68

Earlier quoted context omitted.

YouTube also has the problem that there is almost no dead space to "park" your cursor. You have to carefully place it in between autoplaying previews.

I've noticed this with JIRA, there is not much space to click 'safely' to focus on the window

Azure DevOps is the same if not worse. I'm forever expanding or contracting the Description and Acceptance Criteria as there are no colour shades differentiating the sections - you have to watch the cursor change.

Then I wonder where the Description and Acceptance Criteria are for the next User Story, because it remembers that you (accidentally) contracted the Description for User Story X therefore you obviously don't want to see it for any others...

Re: Front end developers: stop moving things that I’m about to click on

#146

Related to this, here's a pet peeves of mine. When YouTube is buffering a video, it shows a spinner and you can't press play or pause. Usually if something is buffering a lot I'm in a place with spotty internet, so I'd like to pause until I'm somewhere with better Internet. If I say pause, you should not continue playing the video under any condition. I have made my intent clear.

Oh man, so many video-related websites do this shit. It’s even worse in some cases where if you hit pause, then drag the playhead back to the beginning (say because you want to wait and show the whole thing to someone), it starts playing again as soon as you let up on the playhead. Like, I want to pause, put the playhead somewhere and still be paused. Is that so fucking hard to understand?

Re: Front end developers: stop moving things that I’m about to click on

#147
post #54

I agree and don't like Web pages that are complicated, require time, clicks, and effort to learn to use, have page content jumping around, cover the page with images requiring the user to stop what they are trying to do, change the window size and magnification, find a way to get rid of the image and do so, return the window size and screen magnification to what they were, and get back to the reason they came to the…

You're doing everything right regarding cookies, but have somehow managed to either not understand how the EU would regard your non-use of them, or your site does not exist.

What I wrote is just a guess and partly a joke: Cookies and requests to permit them are now so pervasive on the Internet that NOT making such a request might cause some people to assume the site WAS using cookies WITHOUT permission and make a "stink". I still suspect that there might be some such "stink".

For the EU, I was poking fun at what appears to be some heavy bureaucracy in the EU. Also I was referring to the EU as a geographic region and not necessarily a government. I was guessing a "stink" might come from some person, maybe in the media or some small organization; I didn't say or believe that my site would actually be violating some EU law.

No request to permit cookies is one more way to save the users from botheration and more quickly get to the purpose of the Web site.

> your site does not exist

The code runs as intended, and site exists and is on the way to being available to the public.

The site seems to be by a wide margin the best solution for a problem.

The problem the site solves is one part of a quite general problem. There should be opportunities for more startups to solve other parts of the general problem. The general problem should be good for 2 billion users, but the part being solved by my startup might be 1% to 5% of that, that is, 20 million to 100 million. That is the site has a focused audience. The focus stands to make the audience smaller but easier to please.

Re: Front end developers: stop moving things that I’m about to click on

#148
post #142

Earlier quoted context omitted.

I spent half an hour last night resolving this exact class of bug on a padded clickable widget I was making. No one told me it had to be perfect, but I care about the user and don't ever want the user to be surprised. That's the difference you get with outsourcing your engineering team vs developing in-house. If you choose a good team, your developers feel directly responsible for the user experience, go beyond state…

I personally think that was a decent use of time - 30 minutes vs a product-lifetime of not pissing off users that little bit will give a lot of goodwill payoff. But I have worked at a place with in-house developers where they probably wouldn't have showed the initiative to do it themselves, and if brought up later as an annoyance I'd be asked for a "business case" which is a complete non-starter, because how do you e…

Agreed. Just make the best product you can, minding deadlines. If you think your deadlines are too short for the level of polish you prefer, discuss it with your manager and/or decide what is more important to you: polish, or pay. Whether that means putting up with it, finding a better-aligned organization, or starting your own product.

Re: Front end developers: stop moving things that I’m about to click on

#149
post #71

Something that really frustrates me is when an alert pops up on my screen just as I'm about to tap something, so my tapping then dismisses the alert before I've had a chance to read what it said. Hopefully the contents of said alert weren't important, but in most cases I'll never know…

If this is for Android, there's a notification history you can look in. You may have to turn it on first, can't remember if it defaults on or off.
Post reply on HN