I want to create a bubble of a space that’s free from the direct influence of AI. I believe that choice should exist, just like the choice to not be indexed by search engine bots over the web.
>> want to create a bubble of a space that’s free from the direct influence of AI.
It seems unlikely you will achieve that goal online, since there is no way (online) to differentiate between human, and bot. (Its unclear what constitutes AI in your mind but clearly a "dumb" crawler can gather information then scanned by an LLM.)
Of course nothing limits you to creating this space online. Think about creating such a space offline (where identifying humans is easier.)
>> I believe that choice should exist,
Of course the choice already exists. There are no LLMs at my farmers market.
Equally online you can choose not to use search engines, llms, social media, copilot, github, or any other tech you choose not to use. Expanding that bubble beyond yourself may be harder.)
I'm not on social media. So are lots of other people. We tend not to socialise online.
>> just like the choice to not be indexed by search engine bots over the web.
I fear that choice does not exist. You can certainly -indicate- that choice via robots.txt, but uou don't really get to "enforce" that choice, much less do you have an expectation that search engines are universally respecting that choice.
Let me say this next bit with respect. I say it with kindness, not malice. It's easier on you mentally if you fight battles you can win. At this point trying to define, much less live, a life unaffected by AI is like a cyclist railing against the use of cars [1]. Of course you arrange your life without a car. Of course you can socialise with like minded folk. But carving out spaces where cars are formally banned is rare.
[1] yes, I'm aware there are places that are less car-dependant than the US. Yes in Amsterdam there are a lot of bikes. But bikes tend to share the road with cars - there are very few car-free zones.
robots.txt is actually a really usefulay to tell an attacker where to look for juicy content that doesn't want to be indexed, but following it entirely voluntary. It's easy to imagine a dark web search engine that only has that content.
If you want your stuff to exist in the same way, but for OpenAI training, just block GPTBot in your robots.txt
bit snarky, but if don't think about/use what don't want AI to scan; then no possibility of AI scaning/getting relevant info don't want AI to get/have access to.
Of course, in order to make sure not 'thinking about things AI would scan/get access to' have to think about things AI would scan/get access to.
Have you ever noticed that B(lue) and G(reen) are the center most frequencies of the visible spectrum—VIBGYOR? If the human eye is naturally adapted for blue skies and green forests, how could the blue wavelength ever be harmful to our eyes? Those are the healthiest frequencies our eyes “consume!”
So much bullshit is marketed these days that it is impossible to sleep well.
Circadian rhythms are primary drivers for various hormones in your body (e.g. melatonin, body temps, cortisol levels). These rhythms are tightly tied to external/evolutionary triggers. Yours body resets its internal clock* based on external cues, the strongest of which are eating and exposure to daylight. Since we don't have little clocks saying it's 6:05 in our heads, the body uses blue light hitting the retinas as a proxy. It's the knock-on-effects of having misaligned cortisol levels (which further induce lack of sleep / stress) that are the problem, not the blue light.
*The natural rhythm of each individual differs, hence the cave/space experiments where some people naturally fall into a ~25h cycle [due to lack of external cues]).
During most of the evolution of our genus bright blue or green light meant it was daytime and hence time to be awake. But the red light from fires would often be present when our ancestors were sleeping. It isn't that you should avoid bright blue or green light in general, it's that you should avoid it for maybe an hour or so before you go to bed until when you want to wake up.
> But the red light from fires would often be present when our ancestors were sleeping.
I don't believe this is related. I believe it's simply that blue is the best/easiest/earliest color. The circadian rhythm is ancient, used by bacteria, plants, and mammals [1], long before humans had fire. Blue is most energetic, and is all that can be seen in the depths of the ocean, where life mostly likely originated.
i’m not sure if silicon valley is great at technical prowess anymore. the hype machine has run its course and the tech is more proliferated and distributed than ever before.
There are horrible slow or just badly built apps written with native stack as well.
Native is worthwhile for “appstore only” businesses. Mostly. For everyone else, a universal web app is the recommended path forward. Anyone who has a web app should absolutely avoid rewriting the same business logic three times over in native languages just for the appstores. It’s a nightmare to maintain and sync up three teams and codebases, not to mention also insanely expensive.
The future is pwa + webassembly + webview, and there’s no advantage of native over web whatsoever.
> Native is worthwhile for “appstore only” businesses. Mostly. For everyone else, a universal web app is the recommended path forward.
This take is outright wrong. Non-native/webview-based apps are only a tolerable option if your goal is to maximize the number of platforms you cover with the same code base and skeleton crew dev team, at the expense of forcing users to endure subpar user experiences.
As someone who spends enough time on iOS, I’ll take well written web app in a browser over well written native app any time. Do you really think that your whatever thing is so important as to justify me going to an atrocious AppStore and downloading yet another >100MB app with no way to block ads or tracking?
Unless you really exercise system API, I don’t want to hear about your CRUD needing native app to “provide best native experience”.
I'd argue there are a lot of app experiences that are inherently subpar by being apps.
Plenty of services are simply "good enough" as a web page. I don't need a permanent icon on my phone from the local pizzeria for the once every 3 months I order for pickup. How can you make my experience better with an app? Invent different and weird new checkboxes for the order selection process, or just hope they can poll for tracking data that wouldn't exist inside a browser session?
Apps are also a terrible fragmentation for "transient" interactions where you're starting with a search or other activity, and incidentally brush across the content, rather than starting with a full "I'm going to use an app" mindset. Suddenly the UI changes and flow is broken. (see: any time you search for something and click a Reddit result)
The feature with the worst UX is the one that’s missing. There’s a trade-off between perfecting features and adding more of them. Fully native app development plants the flag on the side favoring less features with a higher polish. That is not the right choice for the user in every case, even when viewed through the lens of user experience.
> What is it achieved through? Vendor locked, user and developer hostile native app stacks?
Yes, there is Vendor-lock in, you can't deny that. I don't know what you mean with "user-hostile" and "developer hostile".
I - as user - personally ignore anything web based, if there is a native alternative, as I prefer apps that follow the HIG and use the native toolkit of the platform. Sure I'm just a single person, so this is anecdotal.
> And that’s web stack with access to system APIs.
No I fully disagree. A good UX is only doable, if you use native components and fully follow the HIG. I have not yet encountered a good webapp that is on par with a native app that does exactly this.
Anything web based is good for "one code base - available - but subpar - for many platforms", while native apps are "One code base - one platform, but a great experience" (Given you follow the HIG and use native components)
One extremely trivial example: I don't want to accidentally delete e.g. my files, just because some app thinks switching e.g. "Ok" and "Cancel" around is nice.
While yes, web apps have their uses, but they can't match good native apps even remotely.
> Yes, there is Vendor-lock in, you can't deny that. I don't know what you mean with "user-hostile" and "developer hostile".
Anything that locks you in is hostile to you as a consumer.
> I - as user - personally ignore anything web based, if there is a native alternative, as I prefer apps that follow the HIG and use the native toolkit of the platform.
Interface guidelines and toolkit are different matters. You can write native apps that don’t follow HIG and you can write web apps that follow it.
> No I fully disagree. A good UX is only doable, if you use native components and fully follow the HIG. I have not yet encountered a good webapp that is on par with a native app that does exactly this.
What is a good UX?
> Anything web based is good for "one code base - available - but subpar - for many platforms", while native apps are "One code base - one platform, but a great experience" (Given you follow the HIG and use native components)
If I write Apple only web that follows HIG like a bible and adheres to all standards, where does it put me?
> One extremely trivial example: I don't want to accidentally delete e.g. my files, just because some app thinks switching e.g. "Ok" and "Cancel" around is nice.
That’s platform guidelines. Nothing stops me from implementing them in web app or disregarding them in native apps.
> While yes, web apps have their uses, but they can't match good native apps even remotely.
Sure they can, and they do. You probably used them at some point but couldn’t even notice they were web.
Sure you can. Those are interface guidelines. When you start talking about HIG that touch upon specific native elements, we’re back to why vendor lock-in is bad.
Ah yes. There are some unknown theoretical HIGs that you can follow which don't exist and don't reflect the actual platforms that people, you know, actually use.
This has nothing to do with blindly parroting "vendor lock in bad". Because Apple's HIGs for a long time were light years ahead of anything else, and yes, I would expect a well-designed app to follow them on the Mac (anything from accent colors, secondary focus and humane modal dialogs to affordances, accessibility considerations etc.)
Whereas "sure you can" web implementing some bogus HIGs can't even do a modal dialog right.
> Ah yes. There are some unknown theoretical HIGs that you can follow which don't exist and don't reflect the actual platforms that people, you know, actually use.
Sorry?
> Because Apple's HIGs for a long time were light years ahead of anything else, and yes, I would expect a well-designed app to follow them on the Mac (anything from accent colors, secondary focus and humane modal dialogs to affordances, accessibility considerations etc.)
What does this have to do with native vs web argument? The topic is here what and what you can't achieve with both technologies.
> Whereas "sure you can" web implementing some bogus HIGs can't even do a modal dialog right.
I gave you examples, and you dismissed them because "vendor lock in is bad" and "I don't see what this has to do with native vs web".
> ???
There's no modal dialog on the web that conforms to any of the existing HIGs. And while you can implement one, the amount of effort is ridiculous. Compared to native.
And that goes for almost literally everything. For example, there's a reason 99.9999% of the thousands of dropdown re-implementations fail even the simplest of accessibility checks.
This is a fringe view, in my estimation. Websites do not follow one HIG, people are used to variance. Also, when it comes to Apple, they tend to double down on outright stupid decisions, whereas Android is just a so much of a mess that native does not really mean anything. If you want to make something cool, the basket of native widgets will not get you far either. In general, do not stray away too far from the users expectations (which may well imply not following whatever the HIG says) and they will accept you. The platonic idealists will never be happy under any circumstance, so do not optimize for them.
>Yes, there is Vendor-lock in, you can't deny that. I don't know what you mean with "user-hostile" and "developer hostile".
IMO it's only "developer hostile" for developers who don't want to have to learn a new OS and languages. This sounds like someone with years of Angular experience who doesn't want to learn React because it'll make all the tricks they've learned getting Angular to behave obsolete. As far as being "user hostile" I've got no idea why that's in there... unless they're just throwing things against the wall to see if they stick, and if that's their intent they picked the wrong forum to do it in.
I wish, but I don't think it'll be the case as long as Apple and Google control the mobile platform. The problem was always economical, and not technological. The tides of regulation seem to be changing, and we might get key rulings on their stranglehold on the app stores in the coming years, but it's very hard to conceive how the regulator could compel them to open their systems, and for example implement certain PWA APIs.
Even this "someone" wins, if it's not a class action, I doubt any amount of money out of the lawsuit would change anything for a big company like Google. And I doubt case of these could result in class action anyways.
precisely. and we see a lot of similar behavior from Chrome now as it helps them replace the good old search form with a url bar as the main driver of their ad dollars.
this unsolvable battle is exactly why I opted for the Brave [1] browser. all the better if they’re able to use alternate engine under the hood next.
ah, but flat design is also skeuomorphic. methinks it was just some strategic intellectualism with no legs to look down on everything else that people made. clever tricks of the hive mind.
I can see this rapidly ‘degenerating’ into “what is a chair? Is a tree stump you sit on a chair?”- or “is there such a thing as a ‘chair’, after all ‘chair’ is an abstract concept and what we sit on is physical items”-type discussions.
“It’s skeuomorphic because it reminds me of icons which are things”
oh, yes! i remember those angry troll comments on HN as well. as if flattening all UI was the only thing that mattered and everything else was skeuomorphism.
no sweetie, not everything needs to be a pictogram. and everything you see or use online is skeuomorphism off of something in the physical world at some level. yeah, that flat design also.
Edit: Added "at some level" after helpful comments below.
If everything is something, then something isn't a useful category. Sure, all digital design is in some sense and to some extent a metaphor for real world objects. But skeuomorphism was always referring to things that were to an extreme extent following the design language of the real world, well beyond what was required by their digital constraints or expectations of the user.
That is a useful category of visual language description that is lost when you start with all-design-is-skeuomorphism. It's not wrong it's just not a useful model for anything.
[1] https://github.com/Toucaan/toucaan/blob/master/funding/fundi...