My theory on this is that it is easier for designers to empathize with users who are the same age or younger, since in these situations they've had the experience of the user's age, whereas very few designers have had the experience of being old (save for the author of TFA).
It's hard to empathize with abstract people, you need to observe and engage actual people in their environment, which costs time and money. Too often people are stuck in a conference room talking about personas. I've ended up frustrated at clients telling them "you are not your customers" endless times.
It's amazing how much you learn getting out and talking to customers. One of my favorite examples is for a company that sold plumbing supplies to contractors. The biggest feedback was that these guys spent most of the day in a truck and needed to be able to place orders on their phones and they begged the team to make sure that all the buttons (and links) were much bigger so that their fat fingers could click on them: "this was designed by a pianist".
There's so many examples of interactions that show that the designer didn't understand what the end user is really trying to do. My bank makes me enter a first and last name for transfer recipients, but only use the last name on the confirmation step, however the bulk of my transfers are to family members!
Absolutely, it's that plus the fact that young designers and programmers crank out much more output. And they're cheap.
Myopia and hand aches give excellent perspective on the problems of accessibility in UI design. Alas, they also tend to limit my time with the machine and productivity in that time.
It's about the same how Reddit users' average age is purportedly twenty-something but the content and comments are dominated by teenagers. Teens just post way more.
Ultimately, accessibility for the elderly is a typical case where one has to invest additional effort by choice and principle. I.e. not gonna happen under just the market forces.
It's kind of funny to point out issues with SQL's composability, and in the same breath spec out a language in which "a set (including an empty one) cannot be an element of another set".
There are many real life problems with SQL but this doesn't feel like it's resolving any of them.
Most systems that I am aware of use a plain BVH. Memory requirements for the acceleration structure are not that much of a concern in most cases. Memory hogs typically are (in descending order) volumetric data (smoke/fire/...), textures and only then geometry. And because a BVH leaf node typically contains a few triangles, the BVH itself is always smaller than the geometry data.
That strategy is dumb because in practice people don't mind or prefer using distinct apps for each of their subnetworks; and when these networks start overlapping in the same app, they start posting less (Facebook's problem), creating multiple accounts ("finstas" on Instagram), or bifurcating their real friends to another app (Snapchat 3 years ago).
Hell the fact that Snapchat succeeded in growing a credible threat to Facebook with a fraction of the engineering and marketing resources as Google+ should tell you how wrong that strategy was...
Each of the networks grew initially by providing an insanely better experience specific to a subnetwork (FB for alumni networks, Insta for narcissistic hobby photographers with its filters, Snapchat for horny teens who want to send nude pics, or who want to be goofy with its funny face filters...)
There were a few niches where Google+ unintentionally ended up being successful, such as internal to enterprise, and for pro photographers who liked that pictures had an option to be hosted uncompressed. But the vision overall had poor market fit and would never have latched on to a dense enough subnetwork to succeed IMO.
The challenge is preserving ability for content to control all pixels; without it, the content ecosystem ends up developing single-purpose, generally crappy apps, which isn't necessarily a better thing either...
I'm not sure it is the only solution either - what about "secure attention key" type ways to get the system's attention (in this case the browser's), bypassing any content interception? For example, what if there was a key combo guaranteed to always bring in the browser UI, and typing that key combo was necessary before inputting any password field?
Alternatively, the reliance on browser password management could provide some security if it can be trusted to always work...
Those are some good ideas too - "only solution" was a bit hyperbolic - but I do think our options are limited, especially on mobile.
The Secure Attention Key is interesting, but would need the user to know you press it. And on mobile, it would probably need to be a dedicated button on the device, since I could just fake the on screen keyboard too.
Password manager auto-fill failing would clue a savvy user that something was wrong, but I suspect many would just assume it's a glitch and manually enter their credentials.
I saw an reply in another thread suggesting customizable browser background images for the UI bar, which a website would have no way of replicating. In my opinion that's probably the best approach, although it might mean throwing away the ability for sites to set the background color of the UI to match their theme (arguably losing nothing of value :).
With the use of gesture controls and swipe-up menus and "soft keys", etc, why not put in something like the "pie control" apps on Android, where the OS controls one part and the app controls another?
Consider a semi-configurable universal menu with a well defined access method, where you always can back out of the app, and in the case of browsers also have guaranteed access to switching tabs and accessing options, etc.
This gives me an idea... Even in fullscreen, I believe hovering the mouse near the top of the screen will also bring back some controls into view, but temporarily... So there's already some kind of "peek mode" for the controls... Entering this mode while typing a password in a standard password input field might make sense!
Hmm not if your users are trained to press Ctrl-Alt-Del again... The login screen would also allow them to order the OS to log off the current session too.
An API usually embeds significant design decisions that are hard work to come up with. That said, there is some precedent for companies reimplementing competitors' API verbatim in order to get customers to port their applications more easily...
In large companies, there's another factor to consider, which is that if you're a few years into the company, the stock grants that you received a few years back and that are still vesting now are now possibly worth a lot more... your total yearly comp increases quite a bit if your company stock did well for the few years you've been with them.
