A Companion to the X-Y Problem - The IKEA Effect

[tooki]

I totally agree. For major apps, the best approach (from a usability standpoint) is to write a core "engine" in a shared language, then write completely native GUIs on each platform using developers and UX designers who are native to that platform.

Unfortunately, the "write once, run anywhere" paradigm has almost overtaken the whole software development world, so you usually have a very hard time convincing others of that.

Indeed. It costs way too much to write an OS specific UI. The advantage of cross-platform frameworks is that it is relatively easy to make an application which runs on every platform. Most of these frameworks go much further than just abstracting the GUI; most of the OS idiosynchronies are also covered. wxWidgets for example has a function which tells you where to store user and application data. Even between the various Windows platforms this is something which varies wildly. The same for threads and mutexes. Besides that wxWidgets offers many of the features the Boost library is providing. It is foolish the discard cross-platform frameworks because they don't support some corner cases out-of-the box. They are very useful even without aiming to ever port your application to a different platform.

Ah, the confident arrogance of people who have zero understanding of the thing they’re talking about ...

[T3sl4co1l]

I like how this thread has turned into an OS UI discussion on the first page, as if to illustrate part of the problem.

I mean, the OP kind of used it as an illustrative example, so that would happen.

Tim

[nctnico]

I totally agree. For major apps, the best approach (from a usability standpoint) is to write a core "engine" in a shared language, then write completely native GUIs on each platform using developers and UX designers who are native to that platform.

Unfortunately, the "write once, run anywhere" paradigm has almost overtaken the whole software development world, so you usually have a very hard time convincing others of that.

Indeed. It costs way too much to write an OS specific UI. The advantage of cross-platform frameworks is that it is relatively easy to make an application which runs on every platform. Most of these frameworks go much further than just abstracting the GUI; most of the OS idiosynchronies are also covered. wxWidgets for example has a function which tells you where to store user and application data. Even between the various Windows platforms this is something which varies wildly. The same for threads and mutexes. Besides that wxWidgets offers many of the features the Boost library is providing. It is foolish the discard cross-platform frameworks because they don't support some corner cases out-of-the box. They are very useful even without aiming to ever port your application to a different platform.

Ah, the confident arrogance of people who have zero understanding of the thing they’re talking about ...

You are probably right since I only have about 15 years of experience with writing cross platform applications using wxWidgets. The early versions of OSX where even shipped with wxWidgets. Go figure how unsuitable it is to write OSX applications. BTW I might have choosen QT as well but back then QT's license wasn't flexible enough for my taste.

Edit: something else to consider; in general you don't want an application to work radically different across platforms. Otherwise you'll need to maintain extra user manuals, train extra people, etc. Look at MS Office for OSX for example: the principles of the user interface are the same.

[tooki]

Writing ≠ designing. As a (former) user interface designer (and technical writer), I’m absolutely aware of the extra work that fully native user interfaces demand. The claim I am refuting is your claim that cross platform environments do not entail compromise. They absolutely do. If you can’t access the full range of controls on a platform, it’s a compromise.

I’m not disputing that cross-platform environments save tons of development work. But repeating the claim that it provides all the functionality of the native environments is simply incorrect.

FYI, MS Office is a perfect example of a cross-platform app done right, IMHO: it’s a portable “engine”, with platform-specific UI written natively on that platform. A perfect counterexample to a wxwidgets app. Microsoft learned the hard way (back in 1994 with Word 6 for Mac) that simply porting over the Windows interface doesn’t result in a native-feeling app, and users rejected it resoundingly. So they buckled down and rewrote the interface for the Mac version of Office, keeping all the core design the same (for ease of going back and forth, as you say), but making sure that it’s a full-fledged Mac app, with the details gotten right, so that it doesn’t feel like a Windows app. So while the core code is portable, the user interface code is not.

[nctnico]

Writing ≠ designing. As a (former) user interface designer (and technical writer), I’m absolutely aware of the extra work that fully native user interfaces demand. The claim I am refuting is your claim that cross platform environments do not entail compromise. They absolutely do. If you can’t access the full range of controls on a platform, it’s a compromise.

This claim seems to be based on a short cursory look at wxWidgets. Which controls are you missing precisely?

[nfmax]

FYI, MS Office is a perfect example of a cross-platform app done right, IMHO: it’s a portable “engine”, with platform-specific UI written natively on that platform. A perfect counterexample to a wxwidgets app. Microsoft learned the hard way (back in 1994 with Word 6 for Mac) that simply porting over the Windows interface doesn’t result in a native-feeling app, and users rejected it resoundingly. So they buckled down and rewrote the interface for the Mac version of Office, keeping all the core design the same (for ease of going back and forth, as you say), but making sure that it’s a full-fledged Mac app, with the details gotten right, so that it doesn’t feel like a Windows app. So while the core code is portable, the user interface code is not.

Don't forget Excel was ported from MacOs to Windows, as the Mac version came first.

[tooki]

FYI, MS Office is a perfect example of a cross-platform app done right, IMHO: it’s a portable “engine”, with platform-specific UI written natively on that platform. A perfect counterexample to a wxwidgets app. Microsoft learned the hard way (back in 1994 with Word 6 for Mac) that simply porting over the Windows interface doesn’t result in a native-feeling app, and users rejected it resoundingly. So they buckled down and rewrote the interface for the Mac version of Office, keeping all the core design the same (for ease of going back and forth, as you say), but making sure that it’s a full-fledged Mac app, with the details gotten right, so that it doesn’t feel like a Windows app. So while the core code is portable, the user interface code is not.

Don't forget Excel was ported from MacOs to Windows, as the Mac version came first.

Yep. PowerPoint, too.

In fact, there was Word for Mac before there was for Windows. (But Word for DOS was a smidgen earlier.)

However, with the 1994 release of Office, they replaced all the existing Mac versions (which had been totally independent from the Windows versions) with ports of the Windows versions. It did not land well. Hence why, for the 1998 edition, they really worked hard to create a proper Mac experience.

[tooki]

Writing ≠ designing. As a (former) user interface designer (and technical writer), I’m absolutely aware of the extra work that fully native user interfaces demand. The claim I am refuting is your claim that cross platform environments do not entail compromise. They absolutely do. If you can’t access the full range of controls on a platform, it’s a compromise.

This claim seems to be based on a short cursory look at wxWidgets. Which controls are you missing precisely?

It doesn’t take an in-depth examination of the API docs to determine whether “are all widgets present” is true or not, since a single missing widget suffices to disprove the claim. One that I looked for (because I know Windows doesn’t have it) is the “image well” control, and as expected it was not there. 

[nctnico]

Writing ≠ designing. As a (former) user interface designer (and technical writer), I’m absolutely aware of the extra work that fully native user interfaces demand. The claim I am refuting is your claim that cross platform environments do not entail compromise. They absolutely do. If you can’t access the full range of controls on a platform, it’s a compromise.

This claim seems to be based on a short cursory look at wxWidgets. Which controls are you missing precisely?

It doesn’t take an in-depth examination of the API docs to determine whether “are all widgets present” is true or not, since a single missing widget suffices to disprove the claim. One that I looked for (because I know Windows doesn’t have it) is the “image well” control, and as expected it was not there.

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.

[SiliconWizard]

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.

[nctnico]

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.

[tooki]

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. 

[nctnico]

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.

But the latter is motivated purely by financial reasons and not due to technical reasons. That is not the fault or limitation of using a cross-platform framework; that is simply the wrong conclusion. Companies use cross-platform frameworks to get to an application which runs on various platforms with the lowest investment. If a certain platform doesn't generate a large revenue stream it also means that a platform won't get most of the refinements for the OS even though from a technical point of view that is perfectly possible. That is just how capitalism works. wxWidgets (for example) puts nothing in the way of accessing OS specific features directly so what is left is needing someone to pay the bill. There are people who are using the native Windows ribbon interface in their wxWidgets applications. I just finished a project which needed a very particular user interface which is standard for a certain type of equipment. In the end the sky is the limit. Still, requiring seperate OS specific user interfaces isn't going to make things better because in the end this an even more expensive solution. It makes no financial sense to write, debug and maintain code which functionally does 99% the same 3 times.

And for sure there are legacy applications which don't (can't) adhere to modern standards due to their age and outdated UI design. But that still doesn't mean that using a cross-platform framework is bad. With a clear set of requirements from the start the application can be prepared for platform specific features while sharing what is similar. There will still be a huge benefit. It is utterly short-sighted to develop an application which can run on one platform only. And it has been this way for a long time. The companies that have anticipated increasing use of Linux and Mac are benefitting. Look at PCB design packages like Eagle and Kicad; they both can run on Linux and Mac while Altium is still working on porting their software.

[Syntax Error]

The real Ikea affect. This is what makes the British oh so BRITISH. No queue jumping in the UK, unless you're a VIP.

Coronavirus: Customers queue for hours as Ikea reopens 19 shops

https://www.bbc.co.uk/news/business-52874615

Never mind the bollocks, here's the meat balls.