| General > General Technical Chat |
| A Companion to the X-Y Problem - The IKEA Effect |
| << < (8/8) |
| nctnico:
--- Quote from: SiliconWizard on May 31, 2020, 07:13:48 pm ---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. --- End quote --- 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:
--- Quote from: nctnico on May 31, 2020, 04:51:52 pm ---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. --- End quote --- 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.) --- Quote from: nctnico on May 31, 2020, 07:33:32 pm --- --- Quote from: SiliconWizard on May 31, 2020, 07:13:48 pm ---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. --- End quote --- 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. --- End quote --- 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:
--- Quote from: tooki on June 01, 2020, 08:54:27 pm --- --- Quote from: nctnico on May 31, 2020, 07:33:32 pm --- --- Quote from: SiliconWizard on May 31, 2020, 07:13:48 pm ---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. --- End quote --- 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. --- End quote --- 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. --- End quote --- 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. >:( 8) :P :) :-* ^-^ :-X :) :box: :=\ |O |
| Navigation |
| Message Index |
| Previous page |