[cap10morgan]

This highlights a common pitfall: If you “solve” a problem with a “temporary” solution, you lower the priority of the better solution below every unsolved problem. And there are always enough of those to ensure no one ever revisits the temporary solutions.

[jonny_eh]

I've noticed this in my career. The lesson is to not "ship" something until you're proud of it. Sometimes that's easier said than done though.

[Gormo]

Then perfectionism sets in, you wind up tweaking and adjusting every detail ad infinitum, and never ship anything.

Bird in the hand, worse is better, etc.

[jonny_eh]

Right! That's why I suggest "proud of" not "sure there are no flaws". If your level of "I'm proud of this thing" is "I can't think of any way to improve it" then you should probably recalibrate.

[Sander_Marechal]

"There is nothing more permanent than a temporary solution that works"

I have no idea where I heard that, but I use it often at work to ensure we don't ship temporary solutions but do it right the first time.

[pif]

> "There is nothing more permanent than a temporary solution that works"

> I use it often at work to ensure we ... do it right the first time.

If it works, you did it right!

[omegabravo]

I disagree, I consider that an absolute win of efficient engineering. Develop the feature enough that it lasts 30 years without needing to be fixed.

[sverhagen]

It has to be good enough. Was it? You could argue it was, because it survived that long. But it wasn't a standalone product, rather part of Windows, which was a (commercially) successful product because it was good or great enough. Some parts were better, some were worse. While not completely and utterly broken, I think the suggestion here is that the Format dialog fell in the "worse" camp. So, I'm not saying that it was okay because there were more important things to fix (that was true too, probably), but I'm saying that it was okay because there were enough equally important things that were done better/well enough.

[rbanffy]

I don't condemn it. I condemn the implementation that doesn't render it with the latest widgets and, instead, implements the same widgets that have been abandoned ages ago.

At any given time, there should be one code path to render an abstract UI definition to a screen. It might depend on screen capabilities or running environment or size, but it should be one, so you don't need to maintain and ship ancient unmaintained software.

[lproven]

> I condemn the implementation that doesn't render it with the latest widgets and, instead, implements the same widgets that have been abandoned ages ago.

Interestingly I think this generalises to the whole Windows Explorer.

The Explorer introduced in Win95 and later in NT 4 is a lovely bit of UI design. It introduced the Taskbar (never seen before, and no, the NeXT Dock is not a taskbar, and Acorn's Paul Fellows said NeXT's implementation was apparently derived from the Icon Bar in Acorn RISC OS -- NeXT hired an Acorn developer and he took his Archimedes with him to California). It introduced the Start Menu, with an elegant system of folders and shortcuts as its storage model, later imitated with the newly-customisable Apple Menu of MacOS 8 and later.

But in Win98, Microsoft bodged the Explorer with Active Desktop, which renders via Internet Explorer 4, so that MS could justify bundling IE4 with Windows to the US DOJ in court. That version is multithreaded, which is good, but it's also much bigger and much slower... because it renders via IE. That means new slowdowns and new ugliness, like windows of generic icons, which then get replaced with the correct icons as the renderer tries to catch up. So, they hid that, with an empty window and a flashlight scanning, while the HTML renderer tries to create a view of the Control Panel. It also added wallpapers in folder views, a horribly ugly idea.

And _that_ ugly version is what KDE ended up copying, rather than the cleaner quicker one that was first launched.

And KDE didn't notice and copy the nice neat and Unix-like "just display a Start Menu built from the contents of a directory" idea. It implemented a database instead, and so every successive start menu implementation copies that instead.

The ugly hack done for some other, non-technical reason ends up being the one that influences the successor designs, and the classic clean original implementation is forgotten.

In this case, the results are GNOME 2, MATE, KDE, Cinnamon, LXDE/LXQt, even much of Xfce...

[rbanffy]

I think the folder views is one of the most amazing ideas that I saw first in Windows with IE3. You don't build an e-mail client: you build a view that sees a folder full of e-mail messages (each one a file) and displays it as an e-mail reader. Add a service to send messages in your outbox and poll services to populate your inbox, a viewer and an editor for messages and you are set.

As for the renderer trying to catch up, it could be implemented as something that reads and caches all required graphic resources before attempting to render to the display, so that everything appears correct the first time.

As for the UI, it's fine if the current rendered uses HTML - you just build something that reads the abstract UI representation and outputs HTML for the window renderer.

[lproven]

> Windows with IE3

Which version of Windows?

I used IE3. It wasn't great. It came with MS Internet Mail and News.

https://web.archive.org/web/20110816052247/http://www.nwnetw...

I quite liked MSIMN, it was actually a pretty good client -- it just needed spam filtering, which it never got until it was a bloated mess.

> you build a view that sees a folder full of e-mail messages

BeOS mail did that, probably first.

But I don't remember MSIMN doing that.

It does sound just like a Maildir folder, though.

https://web.archive.org/web/19971012032244/http://www.qmail....

Maildir dates back to around the same time that Win95 was first released, and Win95 as shipped didn't have MSIMN. It had the Inbox client, designed to talk to MSN and Microsoft Mail.

https://en.wikipedia.org/wiki/Microsoft_Mail