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).
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.
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!
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.
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.
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.
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.
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.
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.
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.
> 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)
The OPs website is dogshit. Random blobs in the text that expand and require close buttons? No wonder this clown is fussing over anchors, bro doesn’t know wtf design actually is. Arrogant front end devs have to invent new problems to keep their jobs. It is creative obsolescence in reverse.
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
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.
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.
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.
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.
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.
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.
> 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").
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
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!
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.
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.
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.
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
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.
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.
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.
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.
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?
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.
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?
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.
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!
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
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.
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.
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
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?
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!
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?)
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!
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.)
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?
> 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.
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
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.
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?
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.
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.
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.
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.
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).
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.
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.
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.
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)
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.
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.
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.
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)
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!
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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).
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
> 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)
The OPs website is dogshit. Random blobs in the text that expand and require close buttons? No wonder this clown is fussing over anchors, bro doesn’t know wtf design actually is. Arrogant front end devs have to invent new problems to keep their jobs. It is creative obsolescence in reverse.
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
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.
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.
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.
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.
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.
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.
> 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").
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.
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.
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.
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.
> 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/literacy-s...
contempt for users is the unavoidable consequence of having users.
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.
> 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."
> 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.
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.
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.
Well if it continues to be a mess, something like WASM-based flutter-web might just eat the frontend
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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?
Because I thought it would be fun :)
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!
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.
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.
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.
> 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.
> 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.
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
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.
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.
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.
The blur he put on the floating UI elements was also distracting af.
I would spend political capital not to hire this person.
or if you sticky the current header, thats 1 line of CSS
Please...don't. Vertical space is chronically in short supply.
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.
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?
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.
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?
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.
Absolutely this. You can use that space by having a generous footer with all your contact links and such.
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.
Yes, the boring solution is often the best.
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!
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...
Interesting that none of those examples work on Brave on mobile. I wonder if those been used covertly for user tracking somehow before.
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.
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.
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/
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
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?
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!
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?)
Incredible work, ignore the naysayers. As I was reading the article, I was thinking "this is hacker spirit". Well done.
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!
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.)
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?
Yeah, styling it as a link makes it a bit unclear as to what it's going to do.
Thanks!
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.
> 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.
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
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!
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.
Just flip them.
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?
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.
Another solution I quite like is highlighting the headings of all the sections that are currently on screen.
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.
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.
So what's going on for someone who doesn't have javascript enabled? No anchor links are available at all.
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.
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.
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.
Ouch, thanks for the heads up
Baggage which is back in vogue this year.
I have no idea what "The final solution" refers to in terms of this website that is negative; context matters.
https://en.wikipedia.org/wiki/Final_Solution
It refers to the “Endlösung” of the Jew problem in Nazi germany.
It is the culmination of the holocaust.
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).
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.
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.
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)
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)
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.
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.
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.
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)
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/
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.
This is by far the best solution. Super simple and covers all those issues.
Reading the main content at the bottom right of the window is weird.
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?
this is the best solution.
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)
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.
It's a shame that the overengineered anchor links in TFA don't work with the keyboard.
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.
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.
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.
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.
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.
Fantastic blog post. I love constrained optimization, it's always pretty to throw a solver at a well-defined problem
Just came to say the blog site itself is awesome, I’d advocate for opening the diagrams automatically on mobile, they’re amazingly slick.
I missed that there were diagrams because I immediately activated reader mode at the top.
Cool I like the exercise in futility :)
can you make them automatically trigger on scroll if you get close to its section?
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.
Why not open a modal dialog instead?
The answer to this question should always be "no". Under all circumstances.
In the final demo, when I click on "Conclusion" in the side nav, it doesn't even bring the content into view.
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.)
Lenis.js (smooth scrolling lib) was actually implemented for some technical reason that is no longer required; so might actually remove it indeed.
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.
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.
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.
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.