[fisensee]

I've found the part where the author talks about "arbitrarily overlapping windows" and "fancy icons" as "cute but not essential" pretty telling. Find me someone on the street and ask them if these things are "cute but not essential". Sometimes I feel like software engineers forget what world we live in. In the virtual world all these things are obviously not needed and wasting precious computing power on them is a disgrace to the "craftsmanship". In the real world most applications are made for flawed humans with needs and preferences which stem not from logic and reasoning but from emotions and experience. This doesn't excuse shoddy engineering in any way (everybody has some horror story of somebody not understanding runtime complexity or something, so there certainly is a lot of it). But especially with the examples the author brings up like text editors and operating systems I find these critic/plea severly lacking. Are the core features of ed and visual studio code the same? Absolutely, you edit text. Are the extra ressources used for visual studio code compared to ed a waste? For some people here probably, but I would bet quite a lot that for most the answer would be no. In the end I often find that discussions about optimatization are often more for people to show off and prove that they are a "real engineer" than any real concern about performance.

[II2II]

Is it really telling? A couple of things to consider:

- The original Macintosh did not use icons as heavily as software in 1995. From my vague recollections of 1995, the computers of today may even use fewer icons. (It was a time when there were icons on buttons, like a check-mark on an Okay button, and icons on individual menu items.)

- Even arbitrarily overlapping Windows seem less common these days. People have been maximizing applications for ages. These days, tiling is increasingly popular on desktops (e.g. Windows Snap) and people typically run apps full screen on mobile devices (with split screen, rather than floating window managers, being the only alternative). It's also worth noting that 1995 was part of the era of multiple document interfaces, which were arbitrarily overlapping windows inside of arbitrarily overlapping windows.

Wirth seems to be taking a far more extreme stance than the examples I have provided, yet the early years of the 1990's were also an era of excess. While 1995 Wirth would probably strongly disagree with the software of today, modern software looks austere compared to some of the software of the 1990's while the performance of modern hardware means the user is going to feel less of an impact due to the user interface.

[Groxx]

>It was a time when there were icons on buttons, like a check-mark on an Okay button, and icons on individual menu items.

tbh I wish we would go back to this. Even with the variation in styles, those icons provided language-agnostic "names" for things. If you're using a computer stuck in a different language / with different layout patterns, a checkmark in a primary position is much less ambiguous than having to guess if this is a yes/no/ok/cancel/abort/retry/fail/ignore of some kind.

[megameter]

Unfortunately, checkmarks aren't language agnostic - abstract iconography as a whole is a linguistic phenomenon. I'll just copy paste Wikipedia's notes(edit: HN breaks on the actual symbols so I'll link too):

It is common in Swedish schools for a to indicate that an answer is incorrect,[2][3][4] while "R", from the Swedish rätt, i.e., "correct", is used to indicate that an answer is correct.

In Finnish, stands for väärin, i.e., "wrong", due to its similarity to a slanted v. The opposite, "correct", is marked with {\displaystyle \cdot \!/\!\cdot }\cdot \!/\!\cdot , a slanted vertical line emphasized with two dots.[5]

In Japan[6] and Korea, the O mark is used instead of the check mark, and the X or mark are commonly used for wrong (alongside a triangle △ for entries that are problematic but not wholly incorrect).[citation needed]

In the Netherlands a 'V' is used to show that things are missing while the flourish of approval (or krul) is used for approving a section or sum.

In Brazil, the check character is used to indicate the "yes" concept. For example "yes, it was checked" or "yes, this is the right answer".

https://en.m.wikipedia.org/wiki/Check_mark

[Groxx]

Fair, there's next to nothing that's actually universal across all languages / cultures. I do always find the variations interesting though, thanks for the link!

[delusional]

Do you disagree that they aren't essential? Can you not do the computing without them?

Obviously you can, although you may not want to. That's exactly the point of the article. You WANT arbitrarily overlapping windows, but that comes at a cost. You HAVE to pay that cost if you WANT the feature.

In the very next chapter, the author even says as much: "Increase in complexity results in large part from our recent penchant for friendly user interaction."

What makes such a realization interesting is that if you don't need the "friendly user interaction", say you're making a POS system or some embedded device, you don't need all that extra complexity.

A lot of POS systems run full Windows systems. Do they NEED arbitrarily overlapping windows? If not, then why do they carry around that extra complexity?

[Koshkin]

"Essential" is such a loaded term, and talking about it can easily get us to a slippery slope. Like much else, this should be taken in context, and contexts abound.

For many use cases the (excellent) interface provided by, say, AS/400 (a.k.a. IBM i) is totally sufficient, but this fact alone does not mean that something like that should be used universally.

[tonyedgecombe]

>What makes such a realization interesting is that if you don't need the "friendly user interaction", say you're making a POS system or some embedded device, you don't need all that extra complexity.

Why would a POS system not require a friendly user interface.

This attitude towards users is why corporate software stinks so much, it's based on the idea that the developers have a captive audience so have no choice in the matter, they should just accept what they are given and stop complaining.

[pc86]

There's a difference between a "friendly user interface" (which is pretty clearly referring to the earliest points about design-heavy skeuomorphic icons and complex window management functionality) and a friendly, e.g. accessible and functional, user interface.

A POS system doesn't need window management, it doesn't need skeuomorphic design, and I'm sure there three or four dozen other features that come along with a full-blown Windows installation that are irrelevant to a functional, usable POS system.

[delusional]

The running example in my comment was overlapping windows. a POS system might not need windows, much less arbitrary overlapping ones. That was the specific "friendly user interaction" i was talking about.

I think you're taking me a bit out of context in order to talk about something you care about. I agree with you, so please don't hold me up as something I'm not.

[philipswood]

For context: keep in mind that the personal computer that Wirth and team built for ETH Zurich, project Oberon, was graphical, but eschewed overlapping windows for a paned interface and didn't buy into the skeuomorphic desktop WIMP metaphor.

So "arbitrarily overlapping windows" and "fancy icons" as "cute but not essential" may be telling, but is probably not telling what you thing it does.

[fisensee]

I agree, taking these quotes out of its time context is a bit silly but then again this is the implied intention of posting this here, right? Most people reading this and posting a comment will not be talking about the state of software in 1995 but today, using the article to show that the things described in it are still true/got worse. My comment itself was more of a quick reaction to the general sentiment in the comment section than a serious critic of the article itself.

Since I'm a huge fan of tiling windows managers and spend a lot of my time in terminal emulators as a power user I believe to understand his vision about computer usage and have a lot of admiration for what he and his colleagues were working on. But for the general population I believe he did not have the "right" idea (easy to say with almost 30 years of hindsight).

[badsectoracula]

It also should be noted that Oberon's UI (which you can try out by downloading the emulator from here[0]) might be an initial culture shock if you are used to a Windows-like interface, but when you learn how it works it actually is both very powerful and very consistent - which helps into usability since everything works the same way.

AFAIK Oberon was actually used by "regular people" at ETH Zurich for a long time.

(and a lot of people ran and still run their programs maximized anyway)

[0] http://www.projectoberon.com/

[Koshkin]

Mouse chording, ouch. (I firmly believe it is the worst idea in the history of personal computing.)

[philipswood]

Wasn't too bad to use.

Biggest gripe was finding a PC with a 3-buttoned mouse in the uni computer lab when it was full.

Being able to select, copy, paste and execute without touching a keyboard was cool.

(We used it a bit in a 3rd year computer science OS course)

[pjmlp]

People that worship the ACME editor might be of different point of view.

[nine_k]

Was the computer science professor Niklaus Wirth, a creator of several programming languages, a layman user of personal computers?

Why did Amiga, the series of computers beloved by artists and musicians, have overlapping windows and colorful icons?

[zozbot234]

> Why did Amiga, the series of computers beloved by artists and musicians, have overlapping windows and colorful icons?

To be fair, these things were computationally intensive at the time. The Amiga had a hardware blitter and very good color capabilities, so it could afford to show them off.

[nine_k]

The creators of Amiga introduced them, and added hardware support to make it performant. The only thing which felt sluggish in an Amiga was the floppy disk.

Likely these creators understood the importance of overlapping, draggable, resizeable windows for the audience, and the audience indeed enjoyed them. Same thing with the classic Mac.

If you tried a tiling WM, you realize that it requires learning, tweaking, and discipline. Those are expensive qualities to require from users; one should ask for limited amounts of them.

[zozbot234]

Overlapping windows also require learning and discipline, perhaps more so than tiled screen splits. We are just more used to the former than the latter.

[jhgb]

Amiga may have had some overlapping windows within a screen but it also had multiple screens with significantly restricted arrangement options, if memory serves me right.

[bitwize]

This is pretty much the standard issue "Ignorant/arrogant code jockeys have no idea how alone and scared us users are, and our need to be mollycoddled" rant.

It's Niklaus Wirth. He's the creator of Oberon, a language/OS/development environment which, while a bit idiosyncratic by our standards, is far more powerful than ed.

Oh, and while we're talking about the "real world", why do we never discuss the data entry clerks, sales associates, and customer service reps who learned to operate terminal-based F-key-driven UIs quite efficiently -- and were then forced on to graphical MFC, Java, or Web-based UIs with little thought given to efficient operation with the keyboard alone? The standard Macintosh-based WIMP paradigm is great for onboarding new users, but it's less good for efficient use by a trained operator when speed or volume is important.

Personally I find overlapping windows and icons to be more essential than... ugh... composited desktops. Translucent windows, drop shadows, and the "genie effect" are fun for half an hour tops, but these desktops consume additional processing power and memory and introduce latency! I'd rather go with a 90s style stacking WM.

[zozbot234]

> Translucent windows, drop shadows, and the "genie effect" are fun for half an hour tops, but these desktops consume additional processing power and memory and introduce latency

There's certainly some room for optimization in how desktops work today. I can see the obvious case for tear-free (v-synced) compositing when dealing expressly with full-screen (or close to full-screen) animation or full-screen video, since screen tearing is highly noticeable in these use cases. Wrt. everything else though, there's nothing wrong with rendering without vsync and avoiding that added latency. These optimizations can however be hard to make precise beyond very simple cases, like a single foregrounded full-screen app being enabled to take over the whole display. Tiled windows might be the next most obvious step.

[zozbot234]

Icons and square-ish buttons are convenient in mobile UI's because they make for good touch targets. At the same time, arbitrarily overlapping windows are replaced by tiled screen splits for much the same reason. So what's 'essential' will often depend on what the software is being used for.

[wtetzner]

> Find me someone on the street and ask them if these things are "cute but not essential".

Non-technical people seem to actually do better on e.g. an iPad without overlapping windows.

[joshuak]

It is also common trope that people say "but consider the typical user." I think both arguments are valid. At differing points in user skill level.

For example I would not expect a "typical user" to know or want to use a terminal to navigate directories, however as a more experienced user I know one can navigate much more quickly using a terminal than using the hunt and peck style of most file system GUIs.

Some things are useful before they can be made easy. Some things are easy that have more uses with more effort.

[zozbot234]

A good TUI-based file manager is way quicker than typical GUI's while still preserving much of the same intuition. Whether it's also quicker than the CLI depends on your use case; in some cases it can be.

[joshuak]

Even GUI's can be as fast or faster then terminal if it's not oriented around visually searching and selecting each step in the path.

[Koshkin]

Indeed, TUI and GUI are not mutually exclusive to begin with.