I wouldn’t even use AI to generate image descriptions (because it doesn’t have enough context to convey the meaning, aside from being wrong many times). Designers and developers should see it as part of their trade to build inclusive products, not try to patch it up as an afterthought with Accessibility overlays or AI-based “fixes”.
I hope so as well! I believe anyone that owns or knows a dog or cat is quite sensitized to the awful noises of fireworks (and straight-up explosives, as they are sometimes used). But I’m afraid too many people are still needlessly fascinated by the spectacle and don’t want things to change.
The library does this in during runtime, though, if I’m not mistaken? The original commenter is probably referring to a build step that extracts the Lottie content and only leaves JS and SVG in the final output (which is not the case, as the Lottie web player library itself needs to be included as well, to render the animations and provide interactivity APIs during the rendering of the web page).
Yes, and I think Lottie is very fitting for that use case! I was referring to reaching for Lottie even for simple small animations, because it seems easier to just drop the designer’s Lottie file into the project, rather than building the animation in a more native way. At least I’ve witnessed recommendations like this on Reddit.
I do like the idea of having a common and open format for animations. That being said, I see quite a few web devs reaching for Lottie (which will add quite a few hundred kilobytes for the library/wrapper, and some extra ones for each animation), instead of learning more about CSS- and SVG-based animations (which would be a multitude smaller and more easily adjustable). In that sense, I also don’t like how they continuously boast about Lottie’s small size on the main website, while only comparing it to gif and png files (and not mentioning SVG/CSS animations).
I’m sure it is a good fit for usage on native mobile apps, though.
There are some explicit efforts to surface smaller/indie websites, like web rings and e.g. Kagi’s small web features[1]. These kinds of things might help.
Interesting that you mention this! I like this game a lot, but would rather describe it as hectic and fast-paced (due to the many attempts to optimize race times or find shortcuts). But I do agree that the nature sounds and landscapes are lovely on their own.
I agree with most other commenters: Type safety is a great feature to have. And to intentionally dismiss it or only grant it to certain aspects of the application (where does business logic start and end anyway?) is a really bad sign for me.
This looks great with some apps that have matching themes, but I wonder if it quickly falls apart once you rely on apps with very non-consistent UIs (audio/video software, Discord, Spotify, Slack, and basically all other Electron-based apps). Although I guess there might be some matching CSS injection hacks available for the Electron ones?
Yes, they can ship such a dongle, but they have no right to claim to be open source or listening to their userbase then.
The problem is the hypocrisy of the company, and therefore loss of trust.
Makes me want to buy it less for sure, since the maker is clearly focusing on a feature (set) I don’t want to use or support. In the worst case, the AI stuff cannot be disabled and will annoy me on a daily basis.
If there was a group/vendor you could trust to develop such a universal engine to rule them all, that could work out. But, alas, no big tech company could ever be trusted with such a task (they would try to push their agenda, e.g. by preventing ad blockers).
It’s more money for Jeep, and it looks like they can get away with it, because there are no alternatives for the buyers(?). I’d be surprised if that is in any way good/cheaper for the users.
I think you can opt out of its AI features more or less completely, but you do have to look up all the relevant config options (mostly to hide buttons in the UI leading to AI festures).
I’m not saying these problems are non-existent in co-ops, but that the underlying attitude and mechanisms (co-ownership, more communication on eye level, generally smaller scope) help making co-ops more robust for these situations of “mismatching expectations”. Of course, people might need to leave or get kicked out of co-ops for various reasons and there are ways to manage that as well.
It’s also not a competition about who can win the argument: I think we’re both making our points and it seems like you have a more pessimistic (realistic?) idea of who the workers are. My experience with co-ops is anecdotal, of course.
It’s not just about hiring people who care to begin with, but caring for the business is much more natural if you’re a co-owner and can directly benefit from the organization’s success. Compare that to the gig economy where workers are worn down, paid as little as possible, and thrown out at a whim. In worker-owned businesses, workers are more motivated and more retained (there are also studies around this, afaik).
“Drivers often need firing.” – is that a given fact or would a small coop perhaps do better selection and/or training of drivers to create a high retention? This is a recurring scheme of cooperatives as well: longevity and people-centric thinking. While the standard business might toss out people without thinking twice, coops might approach these kinds of issues with more creativity and resourcefulness.
I agree with the idea of supporting local non-huge businesses that still (need to) for their customers. But I think the coop concept works for more spread-out organizations as well, especially when it comes to digital services. As you mentioned, some big organizations like banks and grocery stores (that operate country-wide or even internationally) exist in Europe. There are also remote-first design/tech cooperatives around.
You might be interested in Subvert, a group of people (formerly?) from Bandcamp that are now founding a worker-/artist-owned version of Bandcamp and launching the platform soon. They basically want to avoid running into the same issues that came with Bandcamp’s recent ownership changes and the instability and worker-facing hostilities around it.
They also published a magazine explaining their thinking behind the setup, etc. – you can find out more on their website: https://subvert.fm/
Could be interesting to check out, even if just for inspiration or fun.
I would argue that Next.js pre app router was a solid and helpful framework for rendering React components on the server side (as long as your setup wasn’t too complex or you were using their own hosting service anyway). But in the recent years they really seem to have screwed up the ease of use and reliability. Nowadays, I wouldn’t recommend Next.js to anyone anymore.
Absolutely plus one on this. LanguageTool is great and I’m also very happy on the free tier. With the app installed on macOS it also checks mails in the Apple Mail app, for example.
I basically followed that approach with my web (browser) extension: Started with the absolute basics (HTML, CSS, vanilla JS) and slowly ran into situations where I needed more modern features – notably file splitting/imports and types to manage the growing and repetitive JS code.
The approach worked for me and I learned some neat things about vanilla CSS and JS features, but I would also rather start new projects with a boilerplate or framework, because even small projects easily grow in scope and it’s nice to be prepared for the eventuality.