[HN Gopher] Overengineered Anchor Links
___________________________________________________________________
Overengineered Anchor Links
Author : matser
Score : 373 points
Date : 2025-04-03 14:36 UTC (1 days ago)
(HTM) web link (thirty-five.com)
(TXT) w3m dump (thirty-five.com)
| carlosdp wrote:
| The article is a neat read! The design of the blog itself is even
| more interesting. I don't love the right-aligned way it starts,
| but I _love_ the inline activations of the left popup! So cool
| matser wrote:
| Thanks! It has some cons, like worse scanability. But I think
| its really cool that you can have something open next to your
| paragraph, especially when you need to consult the popup quite
| often. Like, a table with a bunch of data would also be quite
| nice with this approach I feel.
|
| If you have any feedback I'd love to hear it!
| ramoz wrote:
| Just flip them.
| whiddershins wrote:
| i've been wanting to implement a design like this for blogs
| for 5 or 10 years. Great work on the inline detail on mobile.
| genuinely better than whatever i would have made.
|
| did you consider pushing the word(s) directly following the
| activation button to below the detail pane, rather than doing
| it based on line break?
| silveraxe93 wrote:
| The way https://gwern.net/ does it is quite good.
|
| The links open in a window, so you can still have centre
| aligned text with popups.
| Y-bar wrote:
| I clicked, thinking that it was perhaps someone who like me was
| annoyed by Jira's anchors/permalinks which is a <span> with a
| <button> with a JS event listener on click to load what would
| normally be an <a href> into the DOM.
|
| But this, this is similar, but different. I can't navigate to
| anchors with for example the keyboard.
|
| Question for the author: Why not use the HTML <a> element rather
| than a JS event listener on a non-interactive element?
| superkuh wrote:
| I thought the same. And on this site I cannot even see the
| proposed anchor link because it's a badly implemented web
| component custom-element that is all JS defined instead of
| wrapping actual HTML elements/text. It's such an overengineered
| anchor link that unless you succssfully execute all the
| javascript it doesn't appear at all. Very fragile.
|
| > But if you ever had to implement them, you might have
| encountered the .
|
| Wikipedia is also bad about JS-dependent false anchor links. I
| can't count the number of times someone "linked" me an "anchor"
| to an image on a wikipedia article that simply did nothing
| without javascript. All wikipedia would have to do is put a
| _real_ html a anchor next to the JS defined one to fix it but
| despite submitting bugs about this it 's never been fixed.
| ryandrake wrote:
| This seems like another case of the web development industry
| (in general) "fixing" "problems" that aren't really serious
| problems. I don't know of any user who would be confused by
| simply being at the bottom of a web page. I didn't look at
| the code, but my guess is it's a lot of Javascript spending
| cycles on my machine to solve a non-problem.
|
| I suppose the article author disclosed right away that it's
| "overegineered" so maybe the post is more of a joke or
| exercise in absurdity? Nobody would really spend time doing
| this for a real project, right? RIGHT?
| trainspottinfly wrote:
| Interesting solution. One little tip, I would advise picking a
| different heading for the section "The final solution". That
| phrase has a bit of unfortunate historical baggage.
| matser wrote:
| Ouch, thanks for the heads up
| johnisgood wrote:
| I have no idea what "The final solution" refers to in terms of
| this website that is negative; context matters.
| larusso wrote:
| It refers to the "Endlosung" of the Jew problem in Nazi
| germany.
| unclad5968 wrote:
| https://en.wikipedia.org/wiki/Final_Solution
| Jeremy1026 wrote:
| It is the culmination of the holocaust.
| immibis wrote:
| The penultimate step. The final step was the Allies stopped
| the German final solution, and sent them off to colonize
| Palestine instead (while keeping the gays in the
| concentration camps because the Allies were homophobic
| too).
| numeri wrote:
| It was the term invented by the architects of the Holocaust,
| and I disagree that "eh, context matters".
|
| Setting all moral arguments aside, it's important to know
| that similar phrases can work as dog-whistles to signal
| belonging to radical groups, and as such can easily give
| people the wrong impression about you as an author.
|
| If I were to see a blog post titled "Work will set you
| free"[1] written by a peer, prospective employee/employer,
| colleague, etc., it would immediately set off alarm bells in
| my mind - even if the content of the post is a completely
| innocent discussion of the uplifting benefits of buckling
| down on one's workload. At best, it implies lack of awareness
| - at worst, it implies some extremely hateful beliefs and
| desires.
|
| [1]: Written above the entrance to the Nazi concentration
| camps as a false promise encouraging prisoners often destined
| for death to work hard in forced labor.
| johnisgood wrote:
| We ought to change the whole IT terminology then. We keep
| killing parents and children. Context absolutely matters.
| Lack of context awareness is a deficit one should work on.
| numeri wrote:
| No, avoiding anything potentially negative is not what
| I'm saying. Your argument (that context always matters)
| leaves discourse and society highly susceptible to dog-
| whistles[1], by forcing all good-faith participants to
| interpret all communication in the most generous way
| possible. Bad-faith participants, on the other hand, are
| free to exploit that generosity.
|
| By calling out and avoiding dog-whistles, even including
| accidental Nazi slogans (once pointed out), we reduce the
| impact of this attack on good-faith discussion and actual
| increase the level of openness and being up-front with
| our opinions.
|
| One key difference between this and virtue signaling or
| thought policing is that it's the _specific wording_ that
| is avoided, and not the underlying _thoughts_ or
| opinions.
|
| [1]: https://en.wikipedia.org/wiki/Dog_whistle_(politics)
| johnisgood wrote:
| When I read manual pages and see the so called "harmful"
| words, I am not impacted by them negatively because I am
| aware of the context. Why is this should not be taught? I
| understand what you are trying to say, but you even said
| it yourself, "accidental", so there was no intent either
| to begin with, let alone context in which it is embedded.
|
| > thought policing is that it's the specific wording that
| is avoided, and not the underlying thoughts or opinions.
|
| So we should avoid the wording / phrasing such as
| "killing children" in IT? It refers to well-known
| concepts, within a specific context. It is bad outside of
| IT, for sure, but not inside IT, it refers to ending
| processes (as you probably already know)
| numeri wrote:
| You seem to be responding to what you think I'm saying,
| not what I'm saying. As far as I know, "killing children"
| is not a dog-whistle. No one uses the words "killing
| children" to e.g., secretly express support for the
| Holocaust.
| johnisgood wrote:
| I didn't think the person was supporting Holocaust
| because he used the phrase "The Final Solution", that
| phrase is made up from very common words, and why would I
| assume malice, especially in the context of IT?
|
| I may have used it unintentionally too, because "final
| solution" makes a lot of sense to use. The best way to
| ruin one's language is to keep using such common phrases
| that refer to such negative things. You know, there would
| not be a way to ruin it if people were just aware of the
| context and were not to attribute malice by default. It
| was probably accidental, like you said.
|
| I think the issue is with this not-so-generous
| interpretation of it by default, or reading too much into
| it.
|
| Do not allow your language to be ruined, and you could do
| a lot to help that cause.
| immibis wrote:
| Baggage which is back in vogue this year.
| meowface wrote:
| I'm sorry but anything that hijacks the scrollbar in any way is
| just a no-go. You have to not interfere with scrolling. (Taking
| some other action on the page during scrolling can be okay, but
| actually affecting the scrolling itself in any way while you are
| scrolling should be verboten, in my opinion.)
| matser wrote:
| Lenis.js (smooth scrolling lib) was actually implemented for
| some technical reason that is no longer required; so might
| actually remove it indeed.
| Sohcahtoa82 wrote:
| Pages interfering with how scrolling works infuriates me so
| much that I've often considered writing an extension that tries
| to disable that behavior, or even compile my own Firefox if I
| had to.
| encom wrote:
| I hope you do. And while you're at it, make it so websites
| are no longer able to fuck with the scrollbar in any way
| whatsoever, including but not limited to changing its size or
| colour.
| nizarmah wrote:
| The animations on the left are exactly what my primitive mind
| needs to understand better and stay engaged while reading an
| article. I _love_ it.
| cynicalsecurity wrote:
| Why not open a modal dialog instead?
| encom wrote:
| The answer to this question should always be "no". Under all
| circumstances.
| awayto wrote:
| I dabbled with this kind of issue in my docs and ended up using
| JavaScript's Intersection Observer [0]. It's not a perfect
| solution [1], but I think it worked well enough [2]. It just
| identifies when the element comes on screen and then marks it as
| active however you please. I do appreciate the depth the article
| went into though!
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/API/Intersectio... [1]
| https://github.com/keybittech/awayto-v3/blob/main/landing/la...
| [2] https://awayto.dev/docs/0.3.0/
| ruduhudi wrote:
| This is by far the best solution. Super simple and covers all
| those issues.
| mason55 wrote:
| FYI - you aren't handling the "scroll up" case.
|
| To see what I mean, click "Creating a Feature" then start
| scrolling up. Notice that "Creating a Feature" is still
| highlighted even though the entire screen is made up of text
| from the "Software" section.
|
| I probably only noticed this because I recently implemented a
| similar "active anchor" solution with Intersection Observer.
| wrsh07 wrote:
| It's hilarious reading the other comments. I'm on mobile but my
| first thought was how interesting and novel the site design was
| and how clearly communicated the problem they were trying to
| solve
|
| Cool post! It's refreshing to read a blog that doesn't ask me to
| subscribe with popups etc and gets into technical weeds
| noahjk wrote:
| Once I got over my fear of clicking their links, which I
| assumed would open a new page (but instead just expanded a pane
| in-line), I really enjoyed it. I'm very wary of opening new
| pages. (Also, I first tried to hold-click on the link to open
| in new tab, but it just behaved like regular text and
| highlighted, which led to a momentary confusion. I would have
| preferred a more obvious indication of what would happen when
| clicking, like a down chevron or something.)
| creata wrote:
| Yeah, styling it as a link makes it a bit unclear as to what
| it's going to do.
| matser wrote:
| Thanks!
| creata wrote:
| Thanks for publishing the article. Idk if my comment
| sounded too harsh; sorry if it did.
|
| If you're taking more unsolicited nitpicky suggestions,
| imo the ToC items on the left could use cursor:pointer
| and a background color change on hover.
| jw_cook wrote:
| I also assumed those were going to be links, but after a
| second of confusion I really liked the side pane with
| animations. It adds a lot to the article and it's more
| pleasant than the usual alternatives (lightbox on top of the
| text, or opening a bunch of tabs).
|
| Off the top of my head, I'm not sure how else you'd visually
| communicate _" this bit is interactive on click/hover but
| isn't a link."_ Maybe a different text color (without
| underline), background color, outline (replaced by the
| colored highlight bar on hover), or a slightly larger and
| more distinct icon to replace the generic 'image' icon?
| matser wrote:
| Thanks! Site is still in stealth alpha and posted an article
| here in hopes to get -some- feedback. Didn't expect this kind
| of anger hahah. Very grateful for the positive comments though.
|
| Im on the fence about pre-opening the 'tiles' on mobile. Do you
| (or anyone else) have any strong opinions on that?
| tyzoid wrote:
| I'm not seeing them show up, with or without JS enabled
| (firefox on android). I might suggest having some interaction
| for non-js users though (details element, perhaps?)
| wrsh07 wrote:
| I thought everything was pretty easy to use as soon as I
| realized what clicking a button would do (a little trickiness
| if you open the tile while the button is nearly off the top
| of the screen but honestly really great)
|
| Because I don't know what the drop off rate is when someone
| reads this, take what I say with lots of salt.
|
| Giving one button as a demo and then saying click on button
| to close (and leaving it implicit that the rest of the
| buttons need to be opened manually) seems good? Leaving them
| closed by default worked great for me!
| regularjack wrote:
| Incredible work, ignore the naysayers. As I was reading the
| article, I was thinking "this is hacker spirit". Well done.
| johnnypangs wrote:
| Agreed, I really liked how the site looked. I thought it
| was really slick and I am blown away by the how easy the
| author added extra information in a blog post. Nice work!
| gwern wrote:
| > the site design was and how clearly communicated the problem
| they were trying to solve
|
| I don't agree with either. Even after I enabled JS (no warning)
| and then after reading the whole page, finally realized that
| the implementation of popins was completely broken on Firefox
| and switched to Chrome to reread it (it doesn't help that the
| first 'link' is not a link+, and the link says it's 'broken'
| but it means broken in a _different_ way from being actually
| broken so when you click on it and nothing happens, you infer
| that nothing was supposed to happen, which is why you were told
| it was broken...), I still couldn 't understand WTF the problem
| _was_ or how any of this could be remotely justified compared
| to an ordinary ToC and section headers or anchors.
|
| + I'll just note that I have looked at many, many sidenote
| implementations (https://gwern.net/sidenotes) and the choice to
| make your sidenote/footnote link look exactly like a regular
| link is an... _interesting_ choice.
| Philip-J-Fry wrote:
| Sounds like a nice solution.
|
| Seems like if you open the "he thinks" image thing at the bottom,
| and then go back to the "beautiful" result, then it no longer
| works and the Conclusion heading doesn't get activated. That's
| how I reproduced it anyway.
| inetknght wrote:
| So what's going on for someone who doesn't have javascript
| enabled? No anchor links are available at all.
| soneca wrote:
| Nice read. Although I much prefer the first solution, the hotfix
| of adding extra padding to the bottom. UX-wise, not just because
| it is simpler.
|
| On large screens I prefer to not read texts at the bottom (I
| always scroll things enough so I am looking at them at the middle
| or top of the screen). Also, the positioning of the heading
| relatively to the screen is always the same on every scroll.
| noahjk wrote:
| While I usually detest giant footers, this is one use-case they
| lend benefit to, without causing a large empty space (which
| some people would then want to fill with an image). I agree
| from a UX perspective that I prefer when sites act the way I
| expect them to, and not try to do novel calculations of stuff
| (minus usability stuff like the 'dead zone' dropdown menu
| polygon calculation). On most pages, I expect a reading section
| to start when I scroll past a heading, and I prefer anchors to
| deliver the heading at the top of my viewport.
| type_enthusiast wrote:
| One could ask: what's the UX purpose of the "active anchor"
| indicator on the side navigation?
|
| One answer I can think of: if a reader is in the middle of a long
| section, and the heading is off the screen, it can remind them
| which section they're in relative to the others.
|
| This indicates (to me, anyway) that it's not a function of which
| heading you've scrolled to; it's a function of which section is
| on screen. If you use section-screen-area or something similar to
| highlight the active section, fiddling with the heading positions
| becomes unnecessary.
|
| If you have a tiny section at the end that can never take up the
| majority of the screen, then when the user is reading it, the
| active indicator won't really be useful anyway.
| swyx wrote:
| or if you sticky the current header, thats 1 line of CSS
| dahauns wrote:
| Please...don't. Vertical space is chronically in short
| supply.
| lukasb wrote:
| In my app the user could have an arbitrary number of long
| documents open on mobile at the same time, vertically
| stacked. (This UX makes sense for my app because most docs
| are daily journal entries.) Sticky headers are very useful
| here.
|
| Now I'm just waiting for scroll-timeline or scroll-state to
| hit GA so I can shrink stickied headers in pure CSS.
| layer8 wrote:
| I find such active anchors incredibly distracting. It's like
| something blinking at the side (or top) just because you've
| scrolled a bit.
|
| Regarding the purported problem they solve, maybe browsers
| should have an option to show current-heading information,
| similar to how IDEs show in which function or the like you're
| in within the current source file.
| hinkley wrote:
| The blur he put on the floating UI elements was also
| distracting af.
|
| I would spend political capital not to hire this person.
| kubb wrote:
| Cool I like the exercise in futility :)
| hombre_fatal wrote:
| Adding padding below the main page content seems ideal since it
| also fixes the issue where the tail end of the content is stuck
| at the bottom of the viewport instead of where you'd prefer it.
|
| Maybe a 90vh margin for mobile and 50vh for everything larger.
|
| Hmm, then again you'd still need TFA's solution for the latter
| case. The margin only solves it on mobile since a 90vh margin on
| desktop would look ridiculous.
| layer8 wrote:
| Absolutely this. You can use that space by having a generous
| footer with all your contact links and such.
| hombre_fatal wrote:
| Yeah, good point. It's kinda common to have a big footer.
|
| Examples: https://getbootstrap.com/, https://discord.com/,
| https://tailwindcss.com/
|
| That way on desktop you could get away with a 50vh margin
| under the content and then another 50vh for the footer.
| That's free overscroll.
| jopsen wrote:
| Yes, the boring solution is often the best.
| rage4774 wrote:
| Boring or the most simple solution? Okkam's Razor e.g. and on
| top of that I feel like problems are nowadays not looked
| anymore at something to be solved and forgotten but a quest?
| But I get your point!
| anon115 wrote:
| can you make them automatically trigger on scroll if you get
| close to its section?
| LinuxAmbulance wrote:
| As a backend person, sometimes I look at what's being done for
| front end stuff and pull back in ever so slight horror.
|
| It's an excellent article, and the work within is very well done,
| but there's a part of me that screams "Why would you introduce
| this much complexity for what should be a simple scroll?"
| (overcoming technical hurdles to produce the desired end result
| aside).
| matser wrote:
| Because I thought it would be fun :)
| steve_adams_86 wrote:
| It is fun! The person you're responding to isn't wrong; front
| end is a little horrifying. But it's kind of like a jungle in
| that the scary beasts, swamps, poisonous plants, and the
| harsh elements are accompanied by incredible opportunities to
| experiment, explore, discover, and appreciate beauty.
|
| Backend presents some awesome opportunities too, but I
| absolutely love weird problems like the one you're solving
| here. It's in the realm of simultaneously necessary and
| totally unnecessary. This is where interesting stuff happens!
| svachalek wrote:
| I remember the days when every new project started with "now
| let's write our own String class". As someone who works on
| both, it seems server and native software left this era in the
| distant past, but we're still there in web development.
| philsnow wrote:
| Frontend is completely inaccessible to me.
|
| From time to time I dip my toe in and try new things, but as
| productive as I can get with Astro, the illusion vanishes as
| soon as I have to understand any of the plumbing.
|
| Fortunately, I can still party like it's 1999 just fine: just
| yesterday, I worked on a janky brutalist web app (the same way
| I did back in 2002, cribbing from the O'Reilly "Dynamic HTML:
| the Definite Reference") and "deployed" it with rsync to
| pico.sh. It's practically unstyled and I didn't even use
| jquery, but it works.
| moron4hire wrote:
| The thing is, backend stuff is largely solved. You need to
| store data? Here you go, here's a database. You need to
| process a bunch of strings for similarity? We got an
| algorithm for that.
|
| But frontend stuff is messy. How do you tell a person what
| they're trying to do is wrong and they need to change their
| inputs? Oh, maybe we can highlight the input or we can pop a
| modal message. Haha, psyche! Users ignore that shit! Now what
| you gonna do, buddy?
|
| Frontend is a mess because all you people are a mess.
| bathtub365 wrote:
| Contempt for your users inevitably leads to bad products so
| it's no wonder things are bad if this is the prevalent
| attitude among front end web developers.
| throwaway9w4 wrote:
| I agree with you
|
| It reminds me of an online store in the beginning of
| 2000s
|
| To buy a product, you had to drag&drop the product image
| over the shopping basket icon. It took me quite a while
| to figure that out, and I bet they lost a lot of
| customers.
|
| [Edit: I acknowledge that a PM or manager may have forced
| the developer to do this, but it's just one example of
| many]
|
| Sometimes the developers have to take the blame, instead
| of blaming "stupid" users. Some take that attitude to
| frameworks as well. If the users complain, they haven't
| understood how to use it correctly. Just look at the "how
| to make a todos in 5min" video on YouTube to be convinced
| of its beauty
| moron4hire wrote:
| Yeah, it's really easy to cherry pick an example from the
| past of an application probably built by a junior level
| employee being brow-beat into submission my an MBA-laden
| PM.
| throwaway9w4 wrote:
| You may be right, but this is just one example
|
| Also, backend people can be arrogant as well, but it
| seems that for some reason new ideas tend to be picked up
| quicker in frontend, which unfortunately results in bad
| ideas spreading fast too.
| moron4hire wrote:
| Nah, the front end is just visible. And any errors that
| originate get surfaced in the front end. All you get to
| see as a use is "website said no".
|
| It's only now, in the days of "vibe coding" that I would
| firmly put the sole blame on developers for bad
| application interfaces, because it's usually just one
| clueless person who is YOLOing code out into the wild.
| Everywhere else: hidden icebergs of complexity and you
| didn't know what led to the current state.
| moron4hire wrote:
| I don't have contempt for users. I have contempt for
| single-issue developers who have never stepped out of
| their little corner of software who act like front end
| should be easy because it's "just" some scripting.
| singingboyo wrote:
| There's a difference between contempt (i.e. "users are
| stupid") and realism, though. And realism can range from
| "users don't want to troubleshoot" to "some users are
| near-violently anti-tech and won't read errors",
| depending on context.
|
| The unfortunate truth is that if you're doing B2C or even
| B2B outside of tech companies, the second one will often
| come up...
|
| Bad devs exist. Bad users do too. Thing is, you can't
| usually fire the bad users.
| Swizec wrote:
| > And realism can range from "users don't want to
| troubleshoot" to "some users are near-violently anti-tech
| and won't read errors", depending on context.
|
| No dude, I have things to do and your little software is
| a tiny roadblock in my day. I _dont want to_ become a
| fellow expert in your niche, do the thing and get out of
| my way.
|
| Building UI for work and for consumers is completely
| different. I've done both, user attitudes are veeeery
| different. Building an ecommerce page is also very
| different to building an engagement trap for users to sit
| in.
|
| Problems start when engineers/designers/producters don't
| understand their users and their goals. Or when the user
| is not also the customer (this is the worst)
| rfgmendoza wrote:
| contempt for users is the unavoidable consequence of
| having users.
| evilduck wrote:
| Lack of concern or outright contempt for front end and
| the users is why front end development is a subfield in
| the first place, because backend devs can't or won't
| produce something people can use.
| TeMPOraL wrote:
| > _backend devs can 't or won't produce something people
| can use._
|
| Where by people you mean management and sales, and by
| produce you mean add 150 different tracker scripts? :).
|
| Snark aside, contempt for frontend dev and contempt for
| users are two different things; the latter has thoroughly
| infected the fields of UI/UX. It's most visible in
| webdev, because that's where most UI work happens. Second
| to that is mobile app dev, where it's just as bad.
|
| Also, there are actually two somewhat distinct types of
| contempt for the user:
|
| 1) Paternalism - "users are idiots and need to be babysit
| at every step, or else they hurt themselves (or make us
| spend money on support)"; this one is pretty overt in
| UI/UX.
|
| 2) Exploitation - "users are livestock, the purpose of
| the site/app is to milk them as much as we can - whether
| it's taking their data, money, or both; the design must
| guide users to allow extracting maximum value from them
| before eventually discarding them"; this one is less
| talked about, even though it underpins many UI/UX
| patterns (not all of them known as "dark patterns").
| maccard wrote:
| I do a decent amount of ux work and probably fall into
| category 1 here. The problem isn't "we don't want to
| spend money on support", the problem is "people really do
| need to be babysat for a lot of things, and no matter
| what you do, they will not read the documentation.
| TeMPOraL wrote:
| That's fair. People really are like that. This is
| suboptimal, and I emphasize with both frustrated devs and
| PHBs worried about escalating support costs. The reasons
| behind why users are like this are complex, but "users
| are stupid" isn't one of them.
| rcxdude wrote:
| It's a decent approximation, if you remember it's an
| approximation for "the user is tired/stressed/not paying
| attention/doesn't actually want to deal with your app". I
| remember a talk which suggested "The user is drunk" as a
| better approximation, because it's more obviously not
| literally true.
| maccard wrote:
| I think "users are not paying attention" is a friendlier
| way to describe it.
|
| A while back, I was supporting an e-sports event. We had
| professionals, competing for an awful lot of money who
| were deeply familiar with the game. We had taken mobile
| phones, etc from them so no distractions.
|
| They were briefed before hand that all they had to do was
| wait until they were given the green light, and click the
| big OK button on their screen to enter the game. We added
| a giant modal with the OK that explained "press this
| button when you are told to". This was a last minute
| workaround for the fact that we could only tell how many
| people were in the queue for something, but not which of
| our expected players were not in the queue. Our telemetry
| tells us one person is missing, so we have to go walking
| around to find them. Found the guy, sitting in front of a
| giant modal saying "Click this when you are told to", and
| his response was "I didn't know I was supposed to click
| it".
|
| Now add mobile phones, children, doorbells, cooking,
| neighbours, and this becomes widespread.
| mschuster91 wrote:
| > Paternalism - "users are idiots and need to be babysit
| at every step, or else they hurt themselves (or make us
| spend money on support)"; this one is pretty overt in
| UI/UX.
|
| Reminds me of a quote I'm not too sure if it's authentic
| but it's way too believable: "There is a considerable
| overlap between the intelligence of the smartest bears
| and the dumbest tourists."
|
| Like, over half the population is barely literate [1].
| That's why we're seeing so, so many interfaces being
| "dumbed down", with options for "power users" being
| hidden behind ever increasing hurdles, font sizes and
| margins/paddings increasing, and visuals being dulled
| down. It's all being ground down to be palatable to an
| ever increasing amount of utterly braindead people.
|
| [1] https://www.thenationalliteracyinstitute.com/post/lit
| eracy-s...
| xmprt wrote:
| I don't read it as contempt but rather the equivalent of
| a backend engineer saying that you can't trust user
| inputs and need to validate, authenticate, and authorize
| every request.
| ChrisMarshallNY wrote:
| I wouldn't call what they wrote as "contempt." It seems
| to me, to be cynical realism; something I tend to
| exhibit, myself.
|
| I like people. I really do. I _especially_ love the users
| of the software I write, and go well out of my way, to
| craft the best UI possible.
|
| But I am _constantly_ being blindsided by knuckleheads;
| some of whom, are really, really smart, educated, and
| inquisitive people.
|
| I write iOS apps, and spend many, many hours, testing and
| tweaking. Right now, I am completely rewriting an app,
| because I couldn't get the UI right, at the final stage.
| I realized my fundamentals were borked, and that I needed
| to go back to the ol' drawing board, as Wile E. Coyote
| would say. Many developers would have shipped, but I have
| the luxury of being able to redo it (I have done it
| before).
|
| It's a cool trick, and one that I'd probably use, if I
| was dedicated to Web design, the way I am, to app design.
| mattpallissard wrote:
| > Frontend is a mess because all you people are a mess.
|
| As a backend guy who considers himself extremely fortunate
| that nearly all of his users/customers are technical, this
| got an audible chuckle out of me.
| busymom0 wrote:
| I believe it's because on the frontend, everyone wants to
| look different and have a unique identity. Whereas on the
| backend, everyone needs to be the same to follow standard
| best practices.
| moritzwarhier wrote:
| It's interesting that you used "wants" in the first
| sentence and "needs" in the second.
|
| Not saying that you're totally wrong, but I think this
| difference is not necessarily a deliberate decision by
| individual engineers, or caused by personality or skill
| level.
|
| The employee market demographics surely play a role, but
| this is about concretions, not generalizations.
|
| There is no lack of (often poor) generalizations when it
| comes to the skills and requirements demanded by BE and
| FE roles, respectively.
|
| Not wanting to dismiss your idea / the grain of truth.
| But IMO you are falsely generalizing.
|
| Also, there are not only FE devs claiming to be "full
| stack" when they don't know HTTP basics.
|
| There are also BE developers with similarly daunting
| knowledge gaps.
|
| Or in other words, in both worlds there are juniors
| masquerading as seniors and the other way around,
| depending on the organization.
| anon7000 wrote:
| Well, part of that is a business need (your
| app/website/whatever is an extension of your brand, which
| is a very important part of making money). The other part
| is there are actually many valid ways to style a button,
| or have some kind of hover animation, or some kind of
| navigation bar.
|
| Sure, there are _some_ guidelines and best practices, but
| there are just infinite ways to display information to
| people. You can 't just look at a technical specification
| for how well X/Y/Z performs because design is subjective
| and humans are all different. Whereas none of your users
| will complain if you use Redis (or similar) for caching
| something on the backend.
| pedroma wrote:
| I'd imagine consumer hardware is the same.
|
| For example, every Thunderbolt dock's internals are
| basically the same, while the outer shell tries to be as
| different as possible.
| myth2018 wrote:
| I think the biggest problem is that HTML and even HTTP
| weren't developed with those use cases in mind.
|
| Before WWW was a thing we already had user interfaces and
| the fact that current users frequently prefer those
| ancient, text user interfaces over modern ones tells a real
| LOT.
| lenkite wrote:
| Well if it continues to be a mess, something like WASM-
| based flutter-web might just eat the frontend
| robertlagrant wrote:
| > The thing is, backend stuff is largely solved. You need
| to store data? Here you go, here's a database.
|
| That's like saying "You need user interaction? Here you go,
| here's a frontend."
| mardifoufs wrote:
| That's only because you are used to the over complexity of
| backend work. As someone who is pretty far removed from both
| front and backend work (or web work in general), both seem
| pretty complex. Frontend at least has the excuse of being at
| the interface between humans and computers, which is inherently
| much harder
| nkrisc wrote:
| Because the default behavior, the problem they describe in the
| introduction, is bad. It confuses many people, I've seen it
| firsthand many times as an observer in usability testing.
| erikpukinskis wrote:
| Is it really necessary to highlight the heading at all?
|
| I'm a passionate frontend engineer, but I do think we are
| often busy "asking if we could", and ignore "if we should".
|
| Worth noticing, on mobile you can't even _read_ the
| conclusion in the "it's beautiful" demo, because the
| navigation covers it.
|
| I understand that it is just a demo, and that issue could be
| solved independently...
|
| But I think it also points at the observation that when you
| try to do these kinds of unusual things, you open yourself to
| unintended consequences.
|
| And while you can mitigate those consequences one by one, my
| experience is that you generally won't have a chance nailing
| them all, unless you are also minimizing their number... by
| not getting too fancy.
| nkrisc wrote:
| All I know is the default browser behavior for anchor links
| within a page has real usability issues when you have
| anchored headings at the bottom of the page.
|
| You are correct though that there are many cures worse than
| the disease, but it is a real "disease", so to speak.
| thaumasiotes wrote:
| > All I know is the default browser behavior for anchor
| links within a page has real usability issues when you
| have anchored headings at the bottom of the page.
|
| Yes, you click on the link and the text you were supposed
| to have jumped to is in the wrong place.
|
| But the "solution" here takes this very problem and
| expands it to cover the entire sample article instead of
| just the bottom of the sample article. How is that an
| improvement?
| hombre_fatal wrote:
| > Is it really necessary to highlight the heading at all?
|
| You should be able to take a given UX and ask yourself if
| it can be improved.
|
| A table of contents that tells you where you are on the
| page is useful.
|
| Here's an implementation:
| https://getbootstrap.com/docs/5.3/components/modal/
|
| On desktop, the table of contents on the right shows you
| which header you're on.
| tshaddox wrote:
| You say "backend" but I'm guessing you're not talking about
| modern cloud infrastructure work, the complexity at which I (as
| a frontend person) scream in similar abject horror.
| hnlmorg wrote:
| As a DevOps engineer who's spent the last decade specialising
| in cloud infrastructure, I whole heartedly agree with your
| scream of horror.
| madeofpalk wrote:
| I think the article does a pretty good job of explaining the
| gap between what can happen easily, and what a 110% over
| engineered "perfect" solution is to a UX problem.
|
| Building _excellent_ user interfaces is hard, regardless of the
| technical stack. You have to sweat a lot of the finer details,
| break out of any platform default behaviour where appropriate,
| and over engineer something in service of building a
| 'delightful' user experience.
|
| Or, you can do as most do, and just not do this. #anchor-links
| with `scroll-behavior: smooth;` CSS will get you the basic
| smooth scrolling.
| maccard wrote:
| The really hard part of that is that if you can't build an
| excellent interface, you will build a worse one than if you
| used the native interface. So you either need to be prepared
| to sweat every last detail forever.
| paulddraper wrote:
| > Why would you introduce this much complexity for what should
| be a simple scroll?
|
| The article explains the "why."
|
| > overcoming technical hurdles to produce the desired end
| result
|
| Yes.
| megadata wrote:
| > too far down to scroll
|
| Yeah, when you can't easily scroll anymore because it's "too
| far" then something has gone very, very wrong.
| hombre_fatal wrote:
| I don't get "as a backend engineer" comments like these.
|
| OP is doing a basic analysis on what kind of solutions exist
| for a typical UX edge-case. They even provide the simple
| solution that most people use (margin-bottom).
|
| And for fun they go on to see if they can solve it without the
| minor drawback of the simple solution.
|
| We've got to stop acting like it's a badge of honor to avoid UX
| consideration. We might not be people who implement UIs, we use
| UIs all day and should be able to muster up a few opinions
| about how a UX interaction should work.
| xnickb wrote:
| Looking at the UI of modern apps and websites, I think we're
| too late with this.
|
| What the mass user finds "intuitive" is already formed and
| it's in a horrible place and it's hard to go back.
| softwreoutthere wrote:
| More people use computer applications effectively now than
| at any previous point in history. You might want to check
| your priors and consider that taste does not inform
| usefulness.
| NanoYohaneTSU wrote:
| The issue is that UI/UX is in a terrible place. Your comments
| would be valid if this was 15 years ago.
|
| UX is in the gutter with extra clicks and terrible workflows
| in almost every website. UI is a catastrophe of mobile first,
| but not really, but sort of kind of we want power users but
| we need regular users, and all our UI kits look like total
| ass that is incompatible with so many other things.
|
| This website is a great example. The webpage doesn't load
| instantly and instead forces the user to wait for text to
| appear. Great UX engineering guys, make the user wait!
| chatmasta wrote:
| Let's not act like backend dev is much better. They're two
| sides of the same coin.
|
| The entire web stack - backend and frontend - is a mess
| because the nature of the web is cumulative development
| over two decades, leading to a pile of abstractions upon
| abstractions that by some miracle remain mostly
| interoperable and backwards compatible.
| hnlmorg wrote:
| More than 3 decades, not 2.
|
| My first website is 3 decades old now.
| jillesvangurp wrote:
| I can recommend backend people to do frontend once in a while.
| You don't have to like it. But it will make you a better
| developer. I've been in more than one team where there was this
| us and them dynamic and some lack of mutual understanding about
| why things worked a certain way or limitations and constraints.
| It can lead to poorly thought through APIs and API responses,
| which then triggers frontend work to engineer around that.
| Also, frontend developers tend to have better intuition for
| asynchronous stuff; because everything in a browser is async.
| Backend developers tend to be a bit naive on that front.
|
| I'm a hands-on CTO in a very small company. So, if it's
| technical, I'm doing it. Websites, apps, backends, databases,
| devops and all the rest. Not always fun. But at this point I
| can fill every role in a typical product team and do a decent
| job.
|
| And I agree that what passes for state of the art on the web is
| a bit meh. Anchors date back to the early days of the web. One
| of those forgotten features that is still vaguely useful but a
| bit underused. There's a reason mobile developers prefer native
| UI toolkits. Browsers are a bit limited and backwards. CSS is a
| bit of a straight jacket. And Javascript is a bit of a basket
| case as a language.
| bgro wrote:
| Chrome developers keep adding unhinged complicated "features"
| that nobody wants or asked for and immediately are abused and
| broken.
|
| Numerous autoplaying video methods for example especially when
| they follow the mouse, play in the background, or use lazy
| loading to be unkillable.
|
| Speaking of lazy loading or whatever hundreds of variations
| probably exist around it now, the terrible front end devs of
| the world have decided to use that for everything. Everything
| is a sliding panel full of sliding panels and there's no way to
| use browser back features coherently.
|
| Scrolling down a site now loads a new site and destroys your
| history. Even if you scrolled to move content up because an
| autoplaying video anchored to the bottom of the screen is
| blocking the view. Scroll down too far causes a jump and the
| site decides you're done and loads the next thing with no way
| to navigate back.
|
| How do these developers have a job? How are features like this
| even invented with no critical thought or understanding of real
| world use cases questioned. It's again and again and again that
| we see this.
|
| And the Google team is so proud every time with their demo
| videos that is painfully obvious they put no thought into it
| outside of their bubble of them deciding some random thing was
| technically possible to do as a proof of concept and should
| therefore be immediately released as a fully supported feature.
| hvs wrote:
| As a backend developer, I have a lot of respect for frontend
| developers that have to deal with edge-cases and minutiae that
| we don't have to. Building APIs and interfaces for computers is
| easy. Building them for people is HARD.
| asynchronousx wrote:
| Just came to say the blog site itself is awesome, I'd advocate
| for opening the diagrams automatically on mobile, they're
| amazingly slick.
| layer8 wrote:
| I missed that there were diagrams because I immediately
| activated reader mode at the top.
| Etheryte wrote:
| Another aspect of over engineered anchor links seems to be that
| at least on Chrome on iOS, back navigation doesn't work properly
| on this site as a whole.
| sprobertson wrote:
| FYI on the topic of scroll position, it seems inconsistent
| between history navigation. For example scroll to the very
| bottom, click your Internship blog post, and go back - it ends up
| somewhere towards the end but not quite. (Chrome Mac)
|
| On mobile just clicking the other blog post takes me to the end
| of that post. (Chrome iOS)
| jer0me wrote:
| Another solution I quite like is highlighting the headings of all
| the sections that are currently on screen.
| codazoda wrote:
| I agree...
|
| I don't think this is a real problem that needs solving; or I
| at least think it's a problem browser vendors should solve, but
| lets over engineer it while still trying to keep it simple and
| usable...
|
| What I might do is something similar to what you're suggesting.
| I would have the anchor tag be a regular old anchor tag. Then,
| I'd highlight the heading (maybe just temporarily) at the same
| time. I'd use CSS if I could figure that out or JS if I
| couldn't. The end result would send the user to the normal
| place and flash a highlight on the heading for users with JS
| support.
|
| Keep it simple, but over engineer it to make whoever requested
| this happy.
|
| Edit: After re-reading your response we probably aren't talking
| about the same thing, exactly.
| technojamin wrote:
| This seems like the obvious solution to me. You don't know what
| the user's eyes are looking at, so making the highlighting a
| visual representation of what's in the viewport seems
| preferable than nominating a single section as "current".
|
| In fact the final solution is pretty bad. Sure, it looks nice
| when I scroll down, but when I use the alternative navigation
| method of clicking the sidebar items, it just scrolls to
| unexpected places.
|
| Beautiful article, though.
| sntran wrote:
| The new CSS Overflow Specification 5 has scroll-marker that can
| replace anchor link. From my short test in Chrome 135, they seem
| to scroll to the right place.
| whirlwin wrote:
| In modern browsers, Text fragments let you highlight specific
| portions of text on a page, be it at the bottom or anywhere. In
| Chrome, just highlight the text and right click -> Copy link to
| highlight.
|
| I use it every day instead of anchors to highlight very specific
| parts of the text, to avoid referring to the whole section with
| an anchor. Some pages don't even have anchors
|
| Ref: https://developer.mozilla.org/en-
| US/docs/Web/URI/Reference/F...
| mhitza wrote:
| Interesting that none of those examples work on Brave on
| mobile. I wonder if those been used covertly for user tracking
| somehow before.
| JackYoustra wrote:
| Fantastic blog post. I love constrained optimization, it's always
| pretty to throw a solver at a well-defined problem
| daef wrote:
| my first instinct would be to let the triggerline move with the
| scrollposition, i.e. at scrollTop = 0 the triggerline is at 0vh
| and at scrollTop=max at 100vh... am i missing something?
| riz_ wrote:
| this is the best solution.
| miragecraft wrote:
| In the final demo, when I click on "Conclusion" in the side nav,
| it doesn't even bring the content into view.
| j_san wrote:
| Hey, another overengineer! :D
|
| My solution was to just highlight the last anchor if the user
| scrolled to the very bottom. Although this might skip the second
| last heading if its too close to the bottom.
|
| See here: https://sharezone.net/privacy-policy (most visible on
| desktop, on mobile you have to open the "Inhaltsverzeichnis" at
| the bottom)
| watersb wrote:
| As of iOS 18.4, macOS 15.4, Details/Summary HTML tags can be
| styled with CSS.
|
| Which might be an approach for the first few examples.
|
| I am sure there are other cases that would need anchors.
| cmgriffing wrote:
| I recently discovered the way Tanstack does this. Basically, if
| the heading of the section is in the viewport, then the list item
| is highlighted.
|
| So you could have multiple items highlighted, but it still
| "works" somewhat intuitively for the end user.
|
| The drawback is that it requires JS via intersection observer.
| But maybe the CSS standards committee could see value in this
| kind of thing eventually.
| uses wrote:
| It's an interesting problem - the approach I've taken in the past
| is to simply highlight all sections that are on the screen. This
| is pretty straightforward to do nowadays with
| intersectionObserver.
| porridgeraisin wrote:
| On Android, both the first and last example scroll to
| "Conclusion" in the exact same way for me, and the heading shows
| up in the same place within the div they are showing the examples
| in.
| jineshkrishnan wrote:
| Nicely presented article. The way anchor opens up and not letting
| go the context is good. Overall visual and the ease to access
| information is appreciated.
| NanoYohaneTSU wrote:
| Terrible culture that rewards psychopathy. Every CEO is an insane
| individual that has no remorse for any terrible action they do.
| This makes perfect sense that their entire corporation would
| reward breaking rules. It's what they would do afterall.
| robertlagrant wrote:
| For my Firefox desktop, even the "beautiful solution" at the end
| highlights "Middle Section" even if the Conclusion is fully
| visible, but I'm just not quite at the bottom of the page in
| terms of scroll.
|
| Surely the answer is to highlight all onscreen anchors. You don't
| know where my eyes are looking on a page with two headings on it.
| jiehong wrote:
| Highlighting the heading to scroll to is a must.
|
| It's what headings maps extension does when you click on one
| [0].
|
| [0]: https://addons.mozilla.org/en-
| US/firefox/addon/headingsmap/
| askew wrote:
| It's a shame that the overengineered anchor links in TFA don't
| work with the keyboard.
| hk1337 wrote:
| Reading the main content at the bottom right of the window is
| weird.
| DamonHD wrote:
| So over-engineered that I cannot even see them until I enable
| multiple rounds of JavaScript. And the colour scheme ignores my
| preferences and hurts my eyes.
|
| I backed right out of whatever that was.
| crooked-v wrote:
| I find this layout extremely weird and distracting to the point
| that I couldn't manage to get through the article at all. I would
| much rather have the fancy stuff as inline callouts, with none of
| the giant attention-grabbing bright buttons in the middle of the
| text.
| hoten wrote:
| Another potential option is to allow for multiple "active" states
| (everything in view). If the content is long enough, it can kinda
| work out. As you transition from one section to the next, both
| headers would be "active". For short content it would highlight
| too much though.
|
| snake-y example: https://zquestclassic.com/releases/2.55.0/
___________________________________________________________________
(page generated 2025-04-04 23:01 UTC)