The only time you should NOT be using a native control is when you have UX that demands something very custom. Or you're doing some multiplatform thing, in which case you should try and use a toolkit that can at least pretend to be native controls on all the platforms.

I believe Winamp became so popular because it had such a unique UI, that was also incredibly customizable. Compare that to Windows media player at the time...

On the flip side I want me email client, my desktop authoring tools and admin tools to all look and act the same.

Perhaps partly, but the UI was also useful compared to WMP. WMP was slow, bulky, and took up lots of screen real estate. WinAmp, while it was themed, was slim, but also packed far more control into a tinier space than WMP.

(The blue/grey theme that came later was far less performant; I mean the original dark green/black theme.)

And WinAmp would open & play literally any format under the sun. WMP was limited to something like MP3 and WMA. (And maybe WAV.)

When Winamp first came out, everything was single core. Decoding mp3 took a significant bite out available CPU. Winamp was relatively efficient in CPU in RAM, especially compared to WMP.

WMP plays anything the system has a codec for.

Making users care what codecs are and which are available on their system (and with no UI to even answer that question) is just another example of how bad some organizations are at UX.

That's how VLC became so popular. They realized "sorry, you don't have that codec" is only a bureaucrat's idea of good UX so they shipped every codec in software.

Ah, codecs. The biggest PITA on Windows in the 1990s/2000s. I went through two or three different videoplayers for the sole reason they shipped with whatever was needed to open just about any format out there. Meanwhile, trying to coerce WMP to open popular video formats was an exercise in futility...

> I believe Winamp became so popular because it had such a unique UI

Well, yes and no. Remember, Windows Media player used to be this:

https://www.windows-media-player.com/wp-content/uploads/2019...

and without system-installed codecs, which were hard to come by for something like MP3 files, it was basically useless; you could play MIDI files through your shitty OPL-3 FM synth and that's about it.

Winamp came with a remarkable set of capabilities: - A bunch of useful codecs out of the box - An extensible plugin system, with input, output, general, and visualization plugins - Skinnable UI

The secret sauce was the extensibility, really. You could kill hours just tweaking your Winamp, installing crazy audio effect plugins, and so forth. It was really a new breed of application for most users who were used to really business-like apps.

To corroborate your point, I loved fiddling with the Enhancer plugin:

https://i.imgur.com/DuxpATX.gif

It's what started my desire for better sound quality, pursuing better equipment and assembling my own crazy dsp stacks in order to... well, enhance sound quality, which I do to this day!

Dealing with equalizers, dynamics processors, crossover, convolvers/IR, applying hrtf/hrir found on the net, using room eq wizard to try and improve speaker/room response, buying a damn binaural microphone so I could make my own ears impulse responses... I ended up learning a lot about the subject, form such a tiny "seed"

The Winamp (classic) skinning was so brutally effective, considering how simple they were. AFAIK the bulk of the skin consisted of two or three .bmp-files which were spritesheet for all controls and fonts. Literally anyone could make one with a tiny bit of effort.

Now that screen resolutions vary quite a bit I suppose it wouldn't work as well as when all monitors were mediocre 800x600 or glorious high res 1024x768. Ah, the nostalgia.

> As a user, if an app doesn't have a native UI, I disregard it

I disagree rather strongly with this. You should use the UI elements that make sense. It doesn't make sense for Maya or Blender or Photoshop to constrain themselves to whatever Microsoft picked out for them to use. The palette of native widgets and native UX methods is woeful across all systems. It's constrained to the set of generic elements which are applicable to some theoretical business application, like Word or Excel (which, I must point out, could neither be implemented fully in terms of native UI widgets alone).

> If an app can't survive on its usefulness alone, it probably shouldn't exist.

Form follows function. And I would argue the opposite of the point you're making: if an app can exist purely in terms of native UI widgets, does it even need to exist? I can think of almost no useful apps outside of basic utility apps (file copying, patching, app installers, etc.) that are useful and fully native UI.

Parent here. I suppose my beliefs are more nuanced than what I specified in my post.

> You should use the UI elements that make sense. It doesn't make sense for Maya or Blender or Photoshop to constrain themselves to whatever Microsoft picked out for them to use.

The nuance in my beliefs is that if UI elements aren't available for the function, then apps should absolutely build custom UI. I agree with you there.

It's when you have a basic app that can entirely use native controls and chooses to forego them to do everything custom that I have a problem with.

For my particular example, we were building a cryptocurrency wallet for a new blockchain. It was simple enough to use entirely native controls but definitely didn't need a custom UI.

Arguably it's woeful because everyone goes off and does their own thing rather than having any notion of a shareable commons.

Photoshop definitely uses native UI:

http://wp.xin.at/wp-content/uploads/2017/08/photoshop-cs6-fu...

That said, I'm not entirely sure Photoshop makes a strong point for making custom UI controls, since besides the primary interaction of pointing and clicking on an image, everything else is either dialogs, menus, and toolbars --- all of which are available in the native UI.