There is so much beauty in those screenshots. The more technology advances, the more elegant old machines appear.
Even though the UI's are largely text, in some ways they make a greater effort to communicate with the user than many of today's "best practices."
In this case, it's both big things like the verbosity of the command responses, and little things like the beautiful font with its crossed sevens. More information above the page scroll? The top of the window gets a jagged edge like a torn piece of paper. (The anti-skeuomorphic crowd should avert its eyes.)
Also notice how technical information is expressed in human terms. How much memory is left? 11,334 "words." I know that a word can also be a technical term, and I don't know if that's the context being used here, but there were other programs of the era that translated bytes into human-thinkable words, so it's possible that this is doing the same.
Along those same lines, notice how an unknown or unexpected time is expressed as "forever" and not %NAN% like I see everywhere from airport status boards to AppleTV. It reminds me of AmigaDOS, which in directory listings could report file access as "Yesterday at 6pm" or "Tuesday at 1:35am." This could even be extended. My friend's A1000 showed file dates like "Last Christmas."
It's a kind of attention to detail that is missing in higher systems today, even though today's machines have far more horsepower to make it happen.
I agree completely with the first half of your post.
However "about an hour ago", "last week", "a few years ago", etc. is really annoying in e.g. IM software or file managers. I always have a clock on my screen, and I much prefer having an exact timestamp from which I can quickly determine as much information as I need.
The notable exception to this preference is using the "halfling" mode of KDE Fuzzy Clock[0] (and clones) where the current time appears as, for example "Second Breakfast".
Yes! I hate reverse-relative time indicators, it is absolutely an anti-pattern.
In addition to what you mention, it screws up archival uses if you're not diligent - copy/paste or screenshot something, and if the date is at all contextually relevant... well, it isn't any more.
It depends on your use case. Not everyone needs the kind of granularity that comes with the usual directory listing.
For me, the older the file, the less granular I need the date shown. "Christmas Eve 2012" is a more useful date to me than "2012-12-25T01:42:09+00:00."
The 'words' in this case are a very technical term, as they are the smallest addressable element, in this case 40bit-long - one word can contain half of a CONS cell, two or one instructions, a 32bit integer, a pointer (normal and forwarding), an extended character, and 1-4 array elements (including 4 simple characters aka ASCII).
It reminds me of Emacs. Which seems approximately a virtualized Lisp machine. The pieces that are missing, like a typeface editor could probably be hacked up (and the reason it hasn't is that most people can't design better typefaces). Emacs calendar even has a human oriented interface. http://ftp.gnu.org/pub/old-gnu/Manuals/emacs-20.7/html_chapt...
Emacs + SLIME + Common Lisp was designed to be an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a Lisp Machine. And it succeeds admirably in that intent.
Back when I was an heavy UNIX user, in search of nice IDE like features, I settled with XEmacs because the community was more open minded regarding the integration of graphical capabilities.
If you're running Mac, I suggest the railwaycat fork, which is basically GNU emacs plus some quality of life features that RMS is against like applescript/os integration, smooth scrolling and nice fonts
> This is "Mac port" addition to GNU Emacs 26. This provides a native GUI support for Mac OS X 10.6 - macOS 10.15. Note that Emacs 23 and later already contain the official GUI support via the NS (Cocoa) port. So if it is good enough for you, then you don't need to try this.
> If you'd like to install with Homebrew, please
$ brew tap railwaycat/emacsmacport
and then
$ brew install emacs-mac
if you using cask
brew cask install emacs-mac or brew cask install emacs-mac-spacemacs-icon
To disable this tap, please:
$ brew untap railwaycat/emacsmacport
>There is so much beauty in those screenshots. The more technology advances, the more elegant old machines appear.
I believe there is a devolutionary effect in technology, it has been observed multiple times, which can be summarily described such that even though new technology supplants older tech, older tech still works: this serves only to frustrate the kids into making newer tech/redefining work.
Old machines don't really become less useful: the users needs change.
We can learn things from old, perfectly working tech. But around the edges of the zeitgeist, a lot of great old well worked and worn things get forgotten in the rush to new shine ..
It also feels like we've gone from a mode of thinking that computers should work for people to an era of people working for computers.
One ubiquitous example is when a web page asks for a phone number and it requires the input to be in a specific format. Considering how simple it is for a computer to strip out non-numeric information and reformat a string, this is mind-numbingly annoying to me.
We don't do this kind of thing for very good reasons.
The more rigid/precise but also guided the input, the less errors and misunderstandings can happen. The trade-off is very small and comes down to a very minor annoyance and in some cases there are only upsides because a more guided experience can be more convenient.
That fact nonwithstanding, users might be better served by having more "freedom of expression", e.g., by software that lets the user type any text into any field.
Of course, if the user doesn't succeed in entering a phone number when asked for a phone number, the user will probably need to confront that fact eventually (or fail to achieve what he or she set out to achieve) but it doesn't have to be during the typing into the field.
In fact, that is how web forms worked in the early and mid 1990s IIRC, and I have second-hand information that it was easy to get random users to interact productively with a web form during those years compared to how easy it was to get them to interact productively with other UIs, e.g., a form implemented in Windows 95.
Speaking of the 500, it says, "There was one task from that era you almost certainly wouldn’t have done on your Amiga though, and that was connect it to the Internet... Later Amigas received Internet abilities..."
The first Amiga was the A1000 — two years before the 500 — and was perfectly capable of internet communication. It's where I first saw a web browser. Sure, the connection was dialup, but so was everyone's back then.
Even though the UI's are largely text, in some ways they make a greater effort to communicate with the user than many of today's "best practices."
In this case, it's both big things like the verbosity of the command responses, and little things like the beautiful font with its crossed sevens. More information above the page scroll? The top of the window gets a jagged edge like a torn piece of paper. (The anti-skeuomorphic crowd should avert its eyes.)
Also notice how technical information is expressed in human terms. How much memory is left? 11,334 "words." I know that a word can also be a technical term, and I don't know if that's the context being used here, but there were other programs of the era that translated bytes into human-thinkable words, so it's possible that this is doing the same.
Along those same lines, notice how an unknown or unexpected time is expressed as "forever" and not %NAN% like I see everywhere from airport status boards to AppleTV. It reminds me of AmigaDOS, which in directory listings could report file access as "Yesterday at 6pm" or "Tuesday at 1:35am." This could even be extended. My friend's A1000 showed file dates like "Last Christmas."
It's a kind of attention to detail that is missing in higher systems today, even though today's machines have far more horsepower to make it happen.