An image selector is not part of the base of wxWidgets indeed but it is available as a control from the samples which come with the (official) book and several other places. The same goes for many other controls and components. All in all it seems to me you are dismissing a very good solution based on prejudice. From a programmer's perspective the OS specific part of the user interface is an extremely thin layer which is very easy to adapt to OS specific requirements. People tend to overlook that and say 'it's all wrong' while in reality the amount of work needed to make some modifications is very small. Like painting a wall in a different color can make a huge difference. But you have to be able to see that the actual change is very minor. Microsoft didn't need to rewrite the UI for Mac for MS-Word; they only needed to add some MAC specific features. After all the workflow related part of the UI is the same. Modern Linux distributions have a whole bunch of different UI styles (including having the menu bar at the top of the screen) and it all works without needing to recompile a program.
The reason for that is that the requirements for the user interface elements an OS provides are the same for each OS. For example; it is not like a file is different on Linux, OSX and Windows. On every OS a file is stored in a directory so it has a path, filename and properties. Such an interface is easy to abstract. And in a way wxWidgets (and likely QT too) is doing exactly what you are proposing: have a core functionality (UI workflow) and use GUI specific solutions for the given OS. On the wxWidgets website it says: wxWidgets gives applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI.
PS: Yes, I know I'm harping on about wxWidgets a lot. It's just that I'm very intimately familiar with this cross platform framework and have used it for many projects with great success. My comments are probably true for Qt as well.
It’s not blind “prejudice”, it’s years of experience as a designer
and user (and user advocate). Time and time again, software written with cross-platform tools prove themselves to be poor “Mac citizens”, for example, by lacking the minutiae of Mac interaction patterns. Some of this is due to simply not giving a shit, some is due to the tool chain. (Yes, of course it’s also possible to make shitty apps using the native tools! :p Shitty designers gonna shit no matter what!) I’ve also had the experience of creating a good design, only to have the developers ruin it because their tool chain (and/or development resources or budget) couldn’t implement it properly.
I completely disagree with your assessment of the UI layer being thin. It’s true in the sense that it only makes up a small part of the code, and is perhaps the most easily exchanged layer. But a good UI requires the “engine” to be designed to support the UI. This is why, for example, it’s so challenging to retrofit a modern, interactive UI onto legacy systems like banking software. (Great example of this: airline booking. Almost all airlines use one of a few systems that go back many decades, which weren’t built for the types of interaction we expect today. Hence the rigid, slow interfaces so many airlines have.) Furthermore, a truly native-acting program doesn’t just look native, it acts native. Using the Mac as the example again, there are some interaction patterns that are common on Windows (and Linux) but really not on the Mac. And conversely (as I stated long ago) here are interaction patterns that are expected on the Mac (like pervasive drag and drop) that are uncommon on the others. This can mean needing to change the fundamental design of an app sometimes. In my experience, developers from the Windows world simply do not “get” that a proper port is more than skin deep. Typically, they struggle to understand the importance of the details of UI behavior
at all, never mind platform-specific nuance. (This is why Microsoft’s Ribbon UI specification not only is about 200 pages long, going into excruciating detail on every nuance and pixel, but also requires signing a license agreement, such that you agree to comply with every single mandatory behavior and appearance. Windows devs historically were not held to tight standards, so they were unaccustomed to sweating the details of a UI. The Mac world has different traditions in that regard, with UI details being a point of pride.)
I actually think MS Office is an impressive example of striking the right balance between commonality across platforms while also being “native” on those platforms.
FYI, you say “MS didn’t rewrite the UI for the Mac”, but actually that’s totally wrong. In fact, it’s
at least 200% wrong, insofar as MS first rewrote it for classic Mac OS (i.e. the “Mac Toolbox” API), then adapted that to the Carbon API (the Mac OS X “bridge” version of the old Toolbox API), and then later rewrote the entire UI from scratch in the Cocoa API (Mac OS X’s native GUI API) in order to become 64-bit. (Later still, the UI was rewritten again in UIKit for iOS.)
To get back on topic, an interesting corollary of the Ikea effect may also be what nctnico is kind of showing here: you may tend to stick to something you have used a lot in the past, even if you haven't designed it yourself. I think it's kind of similar, in that it reflects the investment you've put into it.
That is not the case. I clearly stated that the same goes for other (similar) solutions but that I can only really speak for the solution I know most of.
Actually the opposite is the case; people tend to follow their gut feeling instead of doing an objective in-depth investigation. They may have seen some bad results and then think an entire solution isn't good. I've seen that before as well in my own surroundings. Entire projects getting axed or customers getting seriously scared by (non technical) alarmists while the fix is very simple.
I don't want to attack tooki but his position is classic for what this thread is about. Not being a programmer but still insisting to know what tools a very experienced programmer should or should not use. In the end it isn't even the UI designer's problem what tools the programmers use; as long as the job gets done.
I'm not saying it is bad to raise flags but it is extremely important to know your limits on a subject. For example: every now and then I'm involved in projects which also include complex mechanics. I like mechanical stuff too and have no problem building mechanical 'things' on my own but I'm not an expert so I'm not going to question the tools & methods of the mechanical experts involved in the project. That would just generate noise.
All I’m saying — as a former UX designer who also spent years working at a software company — is that cross-platform environments
do entail some compromises and sacrifices. Your claim was that there are
none, and that’s simply not true. The compromises may well be acceptable for a given purpose.
Unfortunately, the developers typically seeking a write-once-run-everywhere solution are exactly the ones who won’t invest the time to do platform-specific UI tweaks. So even if wxwidgets supports doing that by adding a small amount of platform-specific code, it’s unlikely to happen in practice. (By the way, according to the devs I’ve worked with closely, I know far, far more about programming, APIs, etc than most designers.)
You may be dismissive of me because I’m not a developer, but what you’re missing is that if one wants to make truly excellent software, you need both skilled UI designers
and skilled programmers, working closely. If one doesn’t respect the other, the result will almost never achieve excellence. Good designers have to understand how code (and APIs) works, even if they’re not writing it themselves. (I completely disagree about not needing to know what tools are being used. This affects software at so many levels, and the limitations or characteristics of a tool or platform significantly inform how you design your software. A good designer understands the entire stack, from the software to the hardware. They don’t have to be an expert on every part of it, but they do need to understand them all enough to understand the implications on the UI. For example, you’d design an interface differently for something involving large files coming off slow storage or a WAN than you would if it were running smaller files off of fast storage or RAM.)
And good programmers need to respect that the designers aren’t saying these things for shits and giggles, there are sound reasons for both small and large design decisions, it’s not just to be a PITA, nor just to be pretty. Ultimately, the UI designer is the person advocating for the user. And what’s best for the user often entails extra work (sometimes a LOT of extra work!) for the developers.
An architect isn’t an engineer or builder, but he still has to have deep knowledge of building materials and some understanding of structural engineering. It’s the same situation with software and UI design.
And recognize and respect
your limits of subject knowledge, like that as a developer, you likely do
not have as good an understanding of UI issues as a UI designer.