I think the history of tabs serves as a fascinating case study of how Apple's neglect for its own UI frameworks assisted the rise and acceptance of cross-platform frameworks like @electronjs and the corresponding decline in the importance of "nativeness" and "the HIG". 1/🧵
Tabs made their first appearance in NetCaptor in 1998, and by 2003 were considered such a killer feature that they made their way into the beta of Safari, to much fanfare. Today, tabs are of course considered a critical feature in every browser. 2/🧵 Image
But more importantly, they've since become expected in just about every document-based app. The problem was, tabs were difficult to implement on the Mac since there was no built-in component and it was hard to make them fit into AppKit's NSDocument/WindowController model. 3/🧵
Although Apple had shipped tabs in Safari, developers were left to their own devices to figure out tabs for the individual apps. Critically, this was true both in terms of implementation and *behavior*. With no AppKit component, there was no strong Apple direction for tabs. 4/🧵
Normally, in these cases the dev community tried to copy Apple components. This was a favored approach for mimicking pro apps e.g. But Safari tabs don't necessarily give you all the answers for editing-heavy apps, and let's not forget, Safari tabs were weird and upside down! 5/🧵
So what ended up happening is that a major facet of 2000's UI ended up getting developed, organically, and inconsistently, by each developer's different take on it. Some tried to follow Safari's model, others made more traditional tabs (like TextMate). 6/🧵
This may seem mundane, but it represents a first major instance of Apple ceding control of the Mac experience to the emergent behavior of the ecosystem. You'd never have expected Apple to let that happen with the position of the window close button or Dock minimization! 7/🧵
Just ask yourself, do you consider "tabs" to be a well defined feature in macOS that you'd get angry at an app for deviating from? Not unless it deviates as much as Monterey Safari, right ;) 8/🧵
Apple did eventually end up adding an API for tabs to AppKit, but not until *2017*, 12 years after they shipped their first tabs in Safari! By that point, it was more of a pain to convert legacy code than anything, and it wasn't helped by a woeful lack of documentation. 9/🧵
For a long time, the best resource on how to use AppKit’s tabs was a single WWDC video. And of course, being new, it lacked many of the features existing apps had already implemented. It was too late, now it was a "chore,” not a "feature", and with little perceived benefit. 10/🧵
What's important here is that there are two critical components in achieving a consistent OS: the vendor must offer both a strong vision of how things should work, and *also* provide an easy avenue for making things work that way. Apple has been failing at both on the Mac. 11/🧵
And this eventually leads to a much bigger problem: through this inaction, users are slowly acclimated to a chaotic app ecosystem. If key modern features are defined "organically," that expectation begins to bleed over to the old features as well. 12/🧵
If tabs work differently in every app, then why should they expect drag and drop to be any different? Not to mention geekier features like key commands? The entire UX expectation is eroded as consistency increasingly becomes the exception, not the rule. 13/🧵
This of course isn't helped as Apple's own Catalyst apps often fail to adhere to any rules as well, giving users even fewer examples of "the way things should be." (or perhaps, "the way things used to be"). 14/🧵
But again, tabs are just one case study, versions of this have been happening throughout all of AppKit and the UX on macOS in general, exacerbated by complete top to bottom (buggy) OS redesigns that solidify in users the idea that UX consistency is secondary to aesthetics. 15/🧵
In the last decade, macOS has slowly been allowed to degrade into an environment where there are increasingly fewer downsides to counteract the benefits of going non-native, and that’s not on developers. It’s been a long time coming, and it isn't going to be easy to fix. 16/🧵

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Francisco Tolmasky

Francisco Tolmasky Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @tolmasky

7 Aug
We’re past the point where giving Apple the benefit of the doubt can be interpreted as anything other than willful ignorance from a place of Western privilege. These aren’t hypotheticals, we already have examples of Apple's policies failing people in other countries. 1/🧵
Case in point, while we argue whether sideloading would ruin our "experience" on the iPhone, the bottleneck of the @AppStore was already wielded against Hong Kong protestors when China forced Apple to remove HKmap.live, an app they used to avoid police violence. 2/🧵
If your takeaway is that this is merely a "troubling situation" in the "complicated relationship with China," then you aren't only demonstrating how you feel about people in other countries, but also living under a comfortable delusion that this couldn’t happen here too. 3/🧵
Read 11 tweets
5 Aug
This is in part because people have no framework for dealing with non-binary risk. People don’t understand “30% risk.” They just round up to 100% or down to 0. Everyday low stakes decisions reinforce this, like if there’s 30% chance of rain assuming 0% and leaving your umbrella.
But there’s no real logic there, you actually just don’t care either way. Worst case scenario, you get wet. That’s why we have this “what’s the point of living if we have to wear masks” logic: it comes from the same place as “you can’t spend your life worrying about umbrellas.”
The true test of appropriate decision making is whether you’d still make the same decision in the future when presented with an unlikely misprediction. E.g. in poker, just because an unlikely card comes out and you lose, doesn’t mean you’d negatively judge your play of that hand.
Read 5 tweets
5 Aug
This is a worrying pattern: eliminating web features in an attempt to play whack-a-mole with bad websites. We’ve seen this with breaking cross-site caching, font detection, and now prompt(). Perhaps we should be rethinking something more fundamental about browser UI instead.
Here is an example of a more generic solution for establishing trust with the user through a tamper-proof “Secure UI” area of the screen (in this case using the iPhone’s screen surrounding the notch):
Today I can easily draw an exact replica of the 1Password browser plug-in prompt using CSS & trick you into typing your password. But should we disable styling on the web as a response? That’s basically the stance we took with partitioned caching, and for lower stakes (tracking).
Read 4 tweets
9 Jul
A sad aspect of subscription software is how you’re almost necessarily making things that can’t last. Software has always struggled with ephemerality, but subscriptions are condemned to die with their owner (person or co.). I want to make things that have a shot of outliving me.
Forget even outliving you though, 5 years from now, don’t you want to be able to show people this thing you worked really hard on and were so proud of? Like, actually let them touch it, not dig up some video walkthrough on YouTube or something.
It’s funny because software contains the key building blocks to make truly timeless artifacts that don’t decay like physical items and can be copied effortlessly for safe storage. But instead, we’ve found ways of making the average lifespan of apps be less than a physical book.
Read 4 tweets
7 Jul
I think the @AppStore may represent a “Closing of the Frontier” moment (in the American history “Frontier Thesis" sense) that may in part explain the dramatic slowdown in UI and UX innovation in iOS (and even more so in iPadOS) following the iPhone’s initial dramatic launch. 1/🧵
It's no secret that macOS has… borrowed many of its now familiar workflows from 3rd party devs. Spotlight (Watson and QuickSilver), Widgets (Konfabulator), and iCloud Drive (Dropbox) to name just a few. And to be clear, this a good thing and has generally been wll received. 2/🧵
The key thing here is that these utilities started on the "fringe"... the frontier. They weren't shrinkwrap software you bought at Fry's like Microsoft Word, and they weren't installed by the same crowd that installed any old shareware game either. 3/🧵
Read 14 tweets
9 Jun
Thought experiment: if Apple said fuck it and just gave the new M1 MacBooks touchscreens and bare bones touch APIs, but no further direction or “UX investment,” then 5 years later which do you think would be home to more exciting touch apps and UX developments: macOS or iPadOS?
I say the Mac: if for no other reason that a tinkering community could actually exist. It wouldn’t be about wondering if *this is the year* Apple really decides to take the iPad seriously. Some passionate college kid could come up with a cool idea and ship it — for the whole OS!
But here’s another thing: either way we’d be maximizing our options. Currently, Apple has simply decided by decree that the future of touch has the evolve up from the a phone OS to Desktop workflows. They’ve forbidden trying to evolve down from an existing Desktop OS.
Read 20 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!