> Some people don’t care enough
>
> The more people you hire, the more likely you are to hire people who don’t care enough about good interface design. Good interface design needs to be valued by everyone who can affect the work. That includes developers, designers, product managers, and often the CEO.
I know where you're going with this, but here's a twist:
A CEO who cares about interface _design_ is path to micromanaging and pain. A CEO should care about interface _designers_, who are (hopefully) the people trained on how do it well.
Even better: CEOs should care about developers with UI/UX skills, because too often CEOs adopt designers like a pet and keep them busy 24/7 asking for mockups.
In the old times, I bought a Nokia smartphone (5230) because it shipped with offline maps – Nokia had the license for satellite data before Google Maps existed. I also drive a VW with built-in GPS and map loaded from SD card.
Offline maps are an obligatory "survival" tool. Most people trust too much they'll have connectivity, but it'll be the first thing to go down when it's most needed (extreme weather, blackouts, conflicts, etc).
I understand that, but I would expect distant LEO satellites to appear close to the horizon, such that a relatively small aperture in the orbits would allow for a large cone of clear sky near the ground.
That's the difference between "inventing things" and "discovering things".
If you believe you're inventing a solution, doing just enough to solve the immediate problem and stopping is the consequence.
If you believe you're discovering a solution, diving deeper into the problem to try and uncover some truth about it, stopping at the first solution is not enough if you can't explain why it works or why it will keep working in the foreseeable future – because that involves solving a category of problems, not just this single instance.
People like to think in terms of under vs. over engineering, but I don't think this is the right angle to discuss. You can certainly over engineer the first solution because you focused on a single instance of a problem and "missed the forest for the trees" – identifying a general pattern is useful to find what category of problem you're dealing with, research prior-art on it and uncover elegant/economical solutions.
They make sense for so called audiophiles who don’t understand Nyqist frequency theory.
It’s like photographers who are confused about the difference between raw and bitmap (jpeg), videographers confused about the difference between linear raw vs log vs gamma encoded, etc.
Just because a data format with higher bit depth/sampling frequency/whatever exists for editing purposes, doesn’t mean it’s “better” or makes sense as a consumption format for a finished work.
It’s always useful to look at prior art and review capabilities we might have missed. Innovation can happen by mixing the “good parts” of different old ideas.
If you ever worked with mainframe, you'll see a lot of similarities:
- Unified interface for object stores
- Source code stored with data files
- Job runner
I also see some similarities with Lisp machine, the fact Python also has a REPL, and able to dump/restore image state (but in this case discrete objects are serialized, not the entire memory).
This might sound crazy for people used to having 90% glue code / 10% business codebases, but to me seems like a very efficient way to have users directly drive what is effectively a large computer, and more like how things used to be.
The drawback is that it seems to be a monolith, and maybe hard to reimplement on top of more modern foundations. But as a general API, it seems to make sense.
Have you taken a look at kids nowadays? They look like fking zombies glued to their smartphones and wireless headphones. I go walk my dog, and not a single kid tries to play with it - only people of my age (40s) do.
We’re raising a generation of completely emotionally detached robots. There’s something deeply wrong and unsettling, and it’s happening in plain daylight.
Definitely. The secret will be identifying use cases where AI usage is a potential upside with limited downside, not the current blanket statements about replacing all jobs without considering lifetime ROI. There’s a lot of boring work AI can automate with minimal risk. There’s also the potential to decrease risk with AI too, including ensembles of different AIs modals and AI + human.
I’m bullish on Apple because of that. Tech waves always oscillate between mainframe/thin-client models at first, then commodity hardware catches up. Apple is well positioned to deliver that with the M series, all it takes is for the current AI bubble to pop a bit and memory costs go down.
To make parent’s point more exact: from Chen’s definition, these ER diagrams derived from SQL are the “physical” (most low-level) diagrams, you cannot recreate the “logic” or “conceptual” diagrams from it.
I guess nowadays few people care about this difference.
I know where you're going with this, but here's a twist:
A CEO who cares about interface _design_ is path to micromanaging and pain. A CEO should care about interface _designers_, who are (hopefully) the people trained on how do it well.
Even better: CEOs should care about developers with UI/UX skills, because too often CEOs adopt designers like a pet and keep them busy 24/7 asking for mockups.