The framing hammer got heavier with a longer handle, broader face, straighter claw, and waffled face better for gripping nails (also why most loose framing nails have a cross-hatched pattern: so they can mate with the hammer face). From there, materials science really kicked in, and we saw steel-handled models, followed by fiberglass and other composite handles.
The latest developments (that I'm aware of) are products like the Stiletto (http://www.stiletto.com/p-80-ti-bone-iii-hammer-with-milled-...), which leverage materials like titanium to reduce weight while maintaining driving power, and include a replaceable steel face to prolong hammer life and allow using different faces for different applications.
Modern hammers with advanced material properties and functions can cost hundreds of dollars, but deliver much higher efficiency with less fatigue and a longer life. I compare that with the Sears hammer in my grandfather's garage and see a whole new generation of evolution.
There's a great article about hammer history at Fine Homebuilding: https://www.finehomebuilding.com/project-guides/framing/hamm...
edited: Fix link formatting.
I'm happy to see so many different people here in addition to programmers, techies, VC etc.
I work on (mostly non-critical) medical devices and I would like to remind that regulatory is there for a purpose.
If anything the 737 Max fiasco should remind people what can happen when regulatory is considered a cost that need to be cut in a field where there can be some hazards, and where some people in the chain do not have the best interest of the public in mind.
And yes, in the medical industry too, there can be some people who care more about optimizing profits than about patients.
Maybe there are some undue regulatory rules, but hopefully there are not the majority.
In the case of what I work on, regulatory does not prevent us from using state of the art CPUs and GPUs, so yes R&D may need somehow longer cycles from consumer electronics to get a return of investment, but let's be honest it is not too much scandalous to get some features a few years after you get similar things in consumer electronics, especially in cases where there are diminishing returns of improving X or Y.
And yes it is easier to build things when you don't have to care about e.g. ability to disinfect materials, you can cope with more bugs, etc.
UX/UI has the same issues. Everything is a metaphor anyway. You don't get to choose whether your interface is a metaphor, because there is no other option for interfaces. You only get to choose the type of metaphor, and its affordances - from hand-editing binary in a "file" (...which is also a metaphor) to voice recognition.
There are some good points in the article, but they're maybe 10% of the way to a full understanding of this issue. Most of the complaints are about inconsistencies and expert-level operation (written scripting) vs beginner-level operation. But there's also a point about contextual metadata.
Modern operating systems are pretty bad at all of the above, but that's because designing intuitive and powerful interfaces that incorporate expert-level features with some workable built-in intelligence - and preferably some form of composability - is incredibly hard.
It's so hard it's barely been attempted, never mind done successfully. So most operations in userland are explicitly task-oriented. Their settings are customisable, but not the menu of operations on offer.
As a non-expert if you want to rename a folder full of files, you buy a file renamer. You don't try to write a script, because even trivial scripting requires a level of comfort with abstractions that most users simply don't have.
Experts do have that skill level, but they can already use $scripting_lang.
It's possible to imagine an OS that would be more open-ended and wouldn't silo data inside task-oriented applications. But this runs into huge problems with efficient representations and the most appropriate schema for each domain, and just the concept on its own is far outside anything most users would want to deal with.
A lot of the critics of lack of innovation in computer UX design don’t want incremental improvements of the existing building blocks of modern UIs, they want to tear it all down and start from scratch. They want VR interfaces, Jeff Raskins The Humane Environment, Button-less UI, etc. They don't care about better hammers, they want nail screwdrivers or handle-less hammers.
Something that seems to be so simple, and has existed for thousands of years, can still be made better. I'm not a professional carpenter, but I've used a hammer a lot to do things like framing, and can confirm that many of these innovations are meaningful in function, not just form.
If you take a hammer from 1920 and lay it next to the most jazzed up hammer from 2020, they would be recognised as the same tool/having the same general purpose. A carpenter from 1920 wouldn't need to change the way he used a hammer if he picked up the 2020 model, even if the 2020 model might enable new ways of actually using it (or improve old ways of using it).
So while there is evolution and development going on, we're not replacing the hammer metaphor as it were.
The WIMP model has also seen evolution and refinement, but it's still recognisable as the same model. I think the analogy holds.
So, what's the line between inventing and refining?
If the idea behind a hammer is to use the momentum of a relatively large mass to drive a relatively small mass into a material, then the idea of a piece of steel on a handle is just the simplest thing you can manufacture as admittedly a versatile one but not necessarily the best one. If your task as the user is to join two materials together then hammer and nail won’t necessarily even look like hammer and nail (glue, screws). If the goal is to separate material like you might with a chisel, depending on the material you might not be using a manual hammer but something that looks very different, like a saw, a file, a jackhammer, etc.
What the person who mentioned the evolution of framing hammers is pointing out refinement of the hammer as it is. Creating a tool better suited to the user’s task is closer to what TFA is about.
It's not like we're bashing nails with bricks and calling it an MVP replacement to the hammer.
What you described isn't innovation, its iteration.
The point is the essential form and function has remained the same for thousands of years. Knives, forks, spoons etc. are still knives, forks, spoons etc.
Anyway my point is that if you change all hammers in the world overnight (like software does) you better have done a good job of century-testing your changes in all situations. If your reasoning is just “it gets old”, well, this site’s rules do not allow me to express what I think of that.
[1] https://duckduckgo.com/?t=ffsb&q=hammer+nail+magnet&iax=imag...
Which does explain why OSHA says you have to wear safety glasses when nailing.
How "many of these tasks" can they reliably help you do? They screw up even the simplest tasks like setting a timer.
Software does radically different things, things as different as, say, hammering and opening cans. It is difficult for me to believe that the WIMP interface as we know it is actually optimal for all those different software tasks.
I mean, sure, you could probably open a can with a claw hammer, if you used some care, and you might be even able to drive a nail with a can opener.
You wouldn't want to, though.
Note that we still drive cars by using steering wheels and foot pedals. We haven't gone to some "click on the menu item" interface, even though such an interface could easily be written for many modern cars.
Put me in the camp that believes that UIs are stuck in a rut, and need to be fundamentally rethought.
Raskin's humane interface had some interesting ideas, though it does not seem to have caught on.
Web does not value menus and window manipulations either. I don't get it too, tiling window manager optimizes geometry, multiple desktops available by shortcut.
Shell is a manual mode of automation tool. It stores history, I can easily call previous command, combine several commands into new one.
I have no idea how to find out what I can do with Alexa, or which particular magic phrasing Alexa will understand.
My personal biggest issue, as means of illustration, is that I have no idea how to play the latest episode of something on the BBC app, rather than continuing from where I left off.
I'm sure there is a way, but none of my "natural language" attempts are recognised, and I can't find any way to find out what the true commands might be. Given that I mostly listen to news shows while doing something else (and hence rarely finish a particular episode) this makes the whole system near useless.
I may be missing something basic, or if you have any tips on the discoverability of Alexa commands, I'd be very grateful. But in my experience, the discoverability of voice commands is the worst I've ever come across; at least with CLI you have man pages, and with a GUI, even in the worst case of no documentation and obscure icons, there are buttons to explore through trial and error.
Not sure how bad/good Alexa is, but everyone (myself included) in my household are talking to Google and Siri all the time to do tasks that would have taken multiple clicks on a screen, and a bunch of typing. A huge reduction in friction. The state of the art isn't perfect, but as it improves, it's undoubtedly taking UX in a direction that is popular and desirable to consumers.
If you look at a lot of interfaces that are built for a specialized power user (e.g. cashiers), they avoid pointers and have keys for everything. Also, AutoCAD, the last I used it, looked to be centered around command-line primacy.
Magit[1] is another modern example of a TUI done right: discoverable, good dwim[2] inference that doesn't get in the way of experts, plus an escape hatch for typing out the exact git commands for those 5% usecases.
[2] do what I mean
I'm not saying that keyboard-based operation is superior in all cases, but a good keyboard-centric interface can eliminate the need to acquire a target (e.g. menu/toolbar item) for the most common operations because there's a hotkey. Well-understood operations can go almost at the speed of thought (either the operator's or the machine's).
I can say that this talk of using the keyboard being so fascinating that it takes up significant mental resources to be not represent my experience using and seeing others use keyboard-centric interfaces. When I use magit, or when I was operating the minilab I mentioned above, I don't have to think about what key to press to do the thing I want. I am in fact "so disengaged [with the mechanics of manipulating the interface] that [I] have been able to continue thinking about the task they are trying to accomplish". Competitive StarCraft is another example that illustrates the same point without relying on personal anecdote.
It might be possible to do a smoother and more effective version now that we have CSS3 and all these cool transformations available.
I imagine the next revolution in UI will be because our computers change form and present in a completely different way, for example a virtual assistant that lives in the cloud and talks to you via AR visualisations and plain old speech.
Revolutions are not usually a reworking of the dominant mode but a displacement to another medium - e.g. iphone replacing computers for many people.
Or maybe known-good-enough: We evolved this specific design through a path-dependent fashion, so it could have been different had other designs survived, but nobody else has come up with a new UX paradigm which is sufficiently better to displace it yet.
Various kinds of large dinosaurs were dominant for millions of years, and birds still exist.
Flat design is kind of like an extreme version of this. It's easy to build and change when needed.
UX, like evolution, once it goes down one particular path, tends to get stuck there, fiddling with the details at best. Radical innovation becomes really hard to effect: in evolution’s case because any new feature can only extend/adapt what is already there; in UI’s case because users tend to reject anything that doesn’t fit into what they already know.
It’s the distinction between stability and stagnancy. Stability is good in that it’s predictable; its benefit vs cost ratio is known. Stagnancy is not so hot: that ratio cannot (or will not) improve. WIMP is both stable and stagnant; trapped by its own early success with no obvious path forward.
.
Very relevant: after an early 8-bit dalliance I cut my adult teeth on Macs. Some of WIMP’s productivity gains were significant, but in other aspects it was just the same (or more!) drudge work in a cutsier skin. it wasn’t until I taught myself automation (via frustration and AppleScript) that I really put a decent dent in the latter.
And these were automations that built on my existing understanding of WIMP applications (unlike, say, the nix CLI which ignores all that knowledge and invents a whole new unrelated world entirely from scratch). All the Models were exactly the same; all my knowledge of how to manipulate my data in those apps was fully transferrable, not to mention all my existing documents. The only difference was the View-Controller I was using: RPC vs GUI. And whenever I got to a point in my workflow where it was easier/necessary to do something manually, I could freely switch back and forth between those two UIs.
Achieving 10x productivity gains over WIMP on frequent repetitive tasks is embarrassingly trivial* with even modest automations. The hard part is creating an automation UX that’s efficient and accessible to the large majority of less/non-technical users (AppleScript failed, but at least it tried).
.
When will we see another attempt? Dog knows. Voice tech like Siri is obviously trying, but is starting from the hardest end of the problem and trying to work back from there.
I believe there’s much quicker, easier pickings to be had by revisiting the AppleScript strategy—“server” applications exposing multiple View-Controllers for different interaction modes, and a really simple, textual “client” command language along the lines of Papert’s Logo (which 8 year-olds could learn how to use and compose), combined with modern auto-suggest, auto-correct, auto-complete to provide the transparency and discoverability that traditional CLIs fail so hard at.
The written word has 10,000 years of learning and practice behind it. And the most powerful word in the world is the word that expresses exactly what you want to say, whenever you want to say it. If that’s not an opportunity for some smart young coders with a desire to make a better world for all, I don’t know what is. You just gotta know history is all.
--
“It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes.” – Keith Braithwaite
What Shortcuts does undeniably have is youth, looks, and an established following; and never underestimate the value of those. AppleScript may be built on a better technical foundation, but that don’t mean squat if it can’t bums on seats. And the bottom fell out the AppleScript market a decade ago.
However, being an outside product is absolutely no disadvantage. I’ll rate a passionate team of third-party devs with a vision over in-house chair-warmers going through vague motions with zero direction or objective. Being within Apple can be a huge advantage in that it offers prime positioning within the OS itself; but that’s of no use if you’ve got no clue how to deliver a desirable product and sell it to customers in the first place (<cough>Soghoian</cough>).
Whatever the strengths and weaknesses of their product, the Shortcuts team cut their teeth and proved themselves out in the real world. I don’t doubt Apple bought WorkflowHQ as much to get those people as their product. As change of blood goes that was badly overdue.
Alternately, you can say that UX design stabilized on a known good pattern.
This reminds me of how some people will refer to stable software projects that only receive the occasional security patch as "abandoned". They're not abandoned, they're just stable.