This is literally the best ux pattern you can have. It is intuitive - user immediately discovers it when performing the obvious action, it increases the user experience (more text to read) without any real downside.
It is the first thing I suggest to anyone when I see someone didn't implement it.
This is only true if you assume users always scroll down while reading and the only reason they scroll up is to find the header... but many of us scroll up and down while reading and find the re-appearance of the header to interfere with our goal of reading the content. So there is a clear downside for us "up and down" readers.
I don't know what portion of users we are though, I'm glad to see I'm not the only one!
Seriously, have you ever used one? Because most people do not read monotonically downwards. We often scroll back to see something in a previous sentence referred to in the spot we are reading. So we want to go back one or two lines. Bot NOOOOooo, the header pops up, covers 1/4 of the screen, so now we have to scroll that much more, pushing off the screen the other text we hoped to keep on the screen, and it might even go through a few adjustments. So, now, what was a non-event less distracting than turning the page in a book or magazine has now become a fully distracting scroll-fest.
Is that clear enough for you?
>>This is literally the best ux pattern you can have.
NOT EVEN CLOSE. The best User Experience pattern is to give the reader what they asked for AND NOTHING MORE. Nothing more for you, nothing more for your advertisers, and nothing more for them. We click to read the content, LET US READ the content, ALL the content, and NOTHING BUT the content. We'll even understand if some proper STATIC adverts are placed in the content, and we might even click thru if you've shown us something relevant and interesting
But as soon as you start putting motion and other distraction in the adverts, my priority becomes NOT reading the advert, but figuring out how to get it out of my face. And if by some chance I remember it, it is filed among "companies to avoid".
Why does it seem everyone who deals with advertising, from the execs down to the programmers, so stupidly thinks only of the first-order effects — "Grab Their Attention!" — and not the second-order effects, where being so offensive — surprise! — offends people...
I consider it context-dependent. If a site is intended for users to jump around to different pages often, then sticky headers make sense. If it’s designed for long-form articles or scrolling through feeds, then non-sticky headers make sense. When I have implemented them on my own sites, I try to keep them minimal and unobtrusive. But I also have never heard this complaint specifically, until now.
It's awful for the user. There is no reason why scrolling up should perform any other action then scrolling up the content. Zero benefit for anybody involved.
When a user wants to return to the navigation bar at the top he scrolls up. The navigation bar then immediately gets nearer.
The user discovery happens because the act he performs provides the exact intent you need to give him the shortcut.
Also for clarity this is only relevant for content based sites and not apps.
It is vanishingly rare for users to scroll up when reading content unless they want to reach the top
>It is vanishingly rare for users to scroll up when reading content unless they want to reach the top
This assumption is the problem. No, it is not rare for users to scroll up while reading. People are not perfect machines that read everything in one pass and understand it fully.
They may go back to re-read, or look at an earlier image or figure in the text, or otherwise. Sometimes people zone out for a minute and find they 'read' with their eyes but didn't actually take in the content. That requires going back.
For me, scrolling up to re-read is a basic use case of a web page. If it can't do that properly, it has failed.
On what basis do you make the claim that "It is vanishingly rare for users to scroll up when reading content unless they want to reach the top"?
If I were to judge from the comments here (and my own behaviours) it is quite common for users to scroll up when reading content for other reasons that wanting to "reach the top".
no. Scroll already does that. The header can stay where it is. The most intuitive thing you can do is have the content scroll in the direction the user asked for, when they asked for it.
If they want to go up to the top, they can already scroll. To the top.
That’s not why user scrolls up, or at least not the only reason. For example, reading this discussion I constantly scroll up and down to center the text on screen.
If the header only appears after scrolling up for a bit then it’s not so bad, but most implementations show the header after scrolling 1px up. That’s infuriating.
Apparently Israeli media is reporting that the price is so high that the government is requesting the founders will pay their taxes in USD and not Israeli Shekels in fear that such a large foreign exchange transaction will affect the exchange rate. ( Which is already unusually low and hurting exporters)
This would be the first time taxes are paid in a different currency in Israel history.
Pretty wild that it's such a large acquisition it can affect a nation's monetary policy.
There are multiple founders getting billions of dollars each. It's not so unreasonble to fear what could happen if daily trading volume suddenly had a significant increase from them collectively dumping billions of dollars onto the market on the same day to settle the tax bill.
The name “Calcalist” is indeed a play on “Economist” (it is not a proper Hebrew word, but fuses the Hebrew word for economy “calcala” with the English suffix for a professional work “ist”.
However, it is just an expanded version of Ynet’s business/economy section, and Ynet is probably the closest equivalent to USA Today or The Sun.
How can a word come from the Bible? It must have existed before the Bible in order to have a meaning inside of it. Or did you mean to write it came from Aramaic?
I mean that it already appears in the Bible, in old Hebrew (which is close to, but isn’t exactly Aramaic), with the meaning “to feed and provide” - and I did not find any documentation about how it formed (or came into) Hebrew.
Which means of course m, that it was already in use before the Bible was canonicalized.
I hate these studies. They make such bold claims and then when you dig deeper they basically gave a few students some questionuerre with leading questions and then claim they figured out how people work.
Building a C compiler should not have this problem. There is probably a million test suites coming from outside the LLM that it can sue verify correctness.
Are you saying principal engineers and tech minded PMs make lateral moves into director level manager without going through being entry level EMs first?
I've never heard of something like that. Usually the requirement for being director level manager of engineers is to at least have managed people as an EM for several years before.
The pay is aligned with the level whether or not you’re a people leader. To your point though, it may be difficult to go from Principal to Director. I see the lateral moves happen more at the Lead/Sr. Lead levels. They might do a Principal to a Sr. Manager as a trial period with the expectation that you’d be Director after a short time if you perform well. I’ve definitely seen directors become principals as well, so it goes both ways.
Engineering titles at least have a few things that are nearly universally shared (such as actually needing to code, expecting to mentor).
Product manager titles can have completely disjoint scopes of work between organizations - in one org they might be what was once systems designer role - getting requirements and writing specs, in another they might basically be doing UI or UX (even creating pages in figma), in others they are basically project managers.
This is a good method if you are stuck and you don't know what you need to do. It also helps explore a project with a specific task in mind.
It is not very useful in giving you confidence your changes would not cause unexpected side effects, which is usually the main problem working with legacy code.
If you want confidence when working with legacy code, your best bet is to do a strangler fig pattern - find a boundaries for the module you want to work on, rewrite the module (or clone and make your changes), run both at the same time in shadow mode, monitor and verify your new module is working the same as the old one, then switch and eventually delete the old module.
Mikado is really only powerful when dealing with badly coupled code. Outside of that context you’re kinda cosplaying (like people peppering Patterns in code without an actual plan).
Refactoring is generally useful for annealing code enough that you can reshape it into separate concerns. But when the work hardening has been going on far too long there usually seems like there’s no way to get from A->D without just picking a day when you feel invincible, getting high on caffeine, putting on your uptempo playlist and telling people not to even look at you until you file your +1012 -872 commit.
I used to be able to do those before lunch. I also found myself to be the new maintainer of that code afterward. That doesn’t work when you’re the lead and people need to use you to brainstorm getting unblocked or figuring out weird bugs (especially when calling your code). All the plates fall at that point.
It was less than six months after I figured out the workaround that I learned the term Mikado, possibly when trying to google if anyone else had figured out what I had figured out. I still like my elevator pitch better than theirs:
Work on your “top down” refactor until you realize you’ve found yet another whole call tree you need to fix, and feel overwhelmed/want to smash your keyboard. This is the Last Straw. Go away from your keyboard until you calm down. Then come back, stash all your existing changes, and just fix the Last Straw.
For me I find that I’m always that meme of the guy giving up just before he finds diamonds in the mine. The Last Straw is always 1-4 changes from the bottom of the pile of suck, and then when you start to try to propagate that change back up the call stack, you find 75% of that other code you wrote is not needed, and you just need to add an argument or a little conditional block here and there. So you can use your IDE’s local history to cherry pick a couple of the bits you already wrote on the way down that are relevant, and dump the rest.
But you have to put that code aside to fight the Sunk Cost Fallacy that’s going to make you want to submit that +1012 instead of the +274 that is all you really needed. And by the way is easier to add more features to in the next sprint.
There is probably a huge chunk of people who only need a slither of the features of a SaaS but are paying for everything they don't need.
If your particular use of a SaaS is not susceptible to security issues (for example you can use it on your local laptop) then a slither of features that are insecure is exactly the thing for you.
Not everyone is going to replace SaaS with half-baked personal implementations, especially the big companies that most SaaS are aimed at, but it will gnaw out some of the long tail of SaaS subscription revenue for sure.
Reminds me of the days I used to spend building my own Linux kernels or configuring X rather than paying the "Apple Tax", thus costing myself hundreds of hours of productive work time.
First time I'm seeing a "no AI" used to differentiate a work for hire.
Can't say this wasn't obviously coming. Boutique hand-coded consultancies/software-houses are probably going to spring up a lot.
reply