A Companion to the X-Y Problem - The IKEA Effect - Page 1
Forum section: electronics / general

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 22, 2020, 11:57:22 am
content: (The X-Y problem:http://xyproblem.info/)https://stitcher.io/blog/the-ikea-effectIn context of forum activities -- remember to keep an open mind, many of us are ready to offer help but there's nothing worse than honest help that gets denied. It's common to bring a question about a proposed solution, but the better question is often the proposal itself: what is motivating that choice? Have other approaches been considered?A good lesson, in general, is to take humility in your accomplishments. Just starting out in something, you'll greatly overvalue your effort -- the difficulty curve is steep, and climbing it takes heroic effort. But once you've climbed to that point, the next stage will come that much easier, and so on. With time and dedication, you'll find that, what was once a heroic effort, is now a mere idle thought. This isn't to demean or trivialize your effort spent; follow the zen philosophy: just try not to get attached to things.Tim

author: Rerouter
author_rank: Super Contributor
timestamp: May 22, 2020, 12:16:20 pm
content: While I do catch myself falling back to the easier position, I've tried to build the habit of treating my past work like another persons work, If I did something crap in the past, call it like I would for anyone else and move on. makes things so much easier when someone is reviewing things, or making suggestions, if you treat it like someone elses work your going to come to agreement on feedback and corrections, as its no longer emotionally tied to yourself.Also can sometimes lead to fun doubletakes from colleagues when you say "yeah that ass hat Rerouter a few months back did this, what in the heck was he thinking there"

author: nctnico
author_rank: Super Contributor
timestamp: May 22, 2020, 01:29:07 pm
content: Quote from: T3sl4co1l on May 22, 2020, 11:57:22 amSuddenly I understand Chinese equipment marketing for putting out equipment which can be hacked...

author: Tomorokoshi
author_rank: Super Contributor
timestamp: May 22, 2020, 01:34:35 pm
content: It's interesting how those are variations of organizational foibles that have been covered in the past. "Not Invented Here" syndrome, any number of writings from Fred Brooks, Peopleware, etc. all view this problem through the lenses of the time.A corollary to the XY Problem is what I call "Jumping to Solutions", as distinct from "Jumping to Conclusions".Another red flag is use of the adverb "just" when describing the scope of a technical issue: "... then you just have to...", "... just have to write some software...", "... that's just a few days work...".

author: nfmax
author_rank: Super Contributor
timestamp: May 22, 2020, 01:48:59 pm
content: Quote from: Tomorokoshi on May 22, 2020, 01:34:35 pmAh yes! When I worked in military R&D, the name for that was "Solutioneering"

author: madires
author_rank: Super Contributor
timestamp: May 22, 2020, 02:11:02 pm
content: Doesn't this forum provide a good training on detecting and solving the X-Y problem?

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 22, 2020, 02:38:33 pm
content: It's a general behavior - we always tend to value more what we have invested time/money on. It's true for almost everything we do in life, and is largely why, for instance, we value more our own goods than our neighbours', or our own achievements more than those of others. If you don't, that's interesting, but you then must be *very* zen.That's not always in opposition with humility. There's a fine line between pride and arrogance, and generally between valuing and overvaluing. Yes, some people objectively overvalue something relatively basic they have done. Sometimes the overvalue factor is more subjective.Beyond the general points (XY problem and Ikea effect, both being indeed relatively common), I take it that you're expressing some kind of frustration:QuoteI agree this can be pretty annoying, and it happens on a regular basis. Especially on forums.To play devil's advocate though, wouldn't (/shouldn't) humility, here again, and a "zen" attitude make us sort of "immune" to our help attempts getting denied?

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: May 24, 2020, 04:31:48 pm
content: My last project had the Ikea Effect in spades. Every new programmer said more or less the same thing, "this code needs re-working from scratch". The legacy team would say, "no, we just need to port to new CPU" or "just need to adapt to new API". Turned out they had been doing the "just need to..." for 15 years, thus resulting in the spaghetti mess which was buggy as hell.Of course, the management always preferred the "just need to make this one small fix", over a bigger chunk of investment, thus perpetuating the mess. The code entered that "nearly working" zombie state, they surely ended up spending far more money that way.

author: duckduck
author_rank: Frequent Contributor
timestamp: May 26, 2020, 11:14:23 pm
content: Quote from: Tomorokoshi on May 22, 2020, 01:34:35 pmI started my career in IT as a retail computer tech. It didn't take long for me to figure out that "just" was a red flag word. "You just need to install this sound card driver." There were frequently major technical problems hiding behind that word.

author: Syntax Error
author_rank: Frequent Contributor
timestamp: May 27, 2020, 12:20:15 am
content: Possibilitization.Today's new methodology as embraced by the going forwards uptick team. The same bunch of -fleeks- who feel the need to scrum and re-imagine the agile paradigm. Thus preventing clients from discovering that continous integration really means, the software is un-tested and buggy.

author: tooki
author_rank: Super Contributor
timestamp: May 28, 2020, 07:55:08 pm
content: A closely related effect has long been known as “Not Invented Here” syndrome: the reluctance to use something built by others, in favor of rolling your own. NIH syndrome is responsible for countless instances of shitty user interfaces in software. Many developers take misplaced pride in doing everything from scratch, even things like drawing menus, buttons, and text boxes, rather than using the OS’s widgets. The result of this reinventing of the wheel is that they forgo the perfectly round wheels the OS provides, instead delivering 7-sides wheels with eccentric axles, since they haven’t had years of refinement and debugging. Genius!

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 28, 2020, 09:24:10 pm
content: Conversely -- when dealing with OS APIs, or compatibility layers (Qt, wxWidgets, etc.), or VMs (JDK's AWT or Swing, etc.), you have your choice of, well... not very good, crusty, messy, etc. I've heard complaints about Qt (crusty, messy?), worked with AWT and a bit of Swing myself (they're fine, honestly), not really worked with much Windows myself (it's a mess)... I'm not aware of any that is actually bottom-to-top coherent, nice, and compatible; the last one especially, since everyone else is a cluster.And yes that includes *nix, because *nix is not at all immune to the underlying phenomenon at play, indeed FOSS projects are likely more vulnerable if anything.It's... all but a proven theorem? that any sufficiently advanced codebase, API, toolkit, whatever -- is an incoherent mess, evolved over many years or decades, over thousands of systems and dozens of paradigms; you have your choice but they all suck.Really, this is about the point where software and politics overlap.You have your choice [from this small proscribed set of options], and they all suck.Tim

author: tooki
author_rank: Super Contributor
timestamp: May 29, 2020, 09:06:03 pm
content: The cross-platform GUI toolkits tend to be awful, since they cannot adhere to the minutiae of each target platform’s native behaviors. The OS native controls (at least on major platforms) have been fine-tuned and debugged over the years.Anyway, IMHO, 95% of the times developers want special functionality in a widget (the typical justification for doing a custom control), they would have been wiser to just use a standard control instead. Standard controls don’t surprise the user with unexpected behavior. And they’re reliable, compatible, and get many accessibility features for free.

author: nctnico
author_rank: Super Contributor
timestamp: May 29, 2020, 09:37:00 pm
content: Quote from: tooki on May 29, 2020, 09:06:03 pmwxWidgets uses the platform's own controls; it doesn't even provide controls unless the platform doesn't support a particular control natively. AFAIK on Qt you can choose between Qt's own look & feel and the ones from the platform. I wouldn't consider GTK to be a cross-platform GUI toolkit; it is more a band-aid to port a Unix application to Windows quickly but the result is mediocre at best. I agree that software should use the platform's own controls in order to create a uniform look and operation.

author: tooki
author_rank: Super Contributor
timestamp: May 30, 2020, 10:34:11 am
content: That all sounds nice and dandy, but it’s not just about the look of the controls. As you mention, they differ in operation, too. But more importantly, not all controls exist in every OS. MacOS in particular has a number of native controls with no Windows equivalent.I understand the appeal, to a developer, of a cross-platform GUI toolkit. But in practice they entail a LOT of sacrifices and compromises.

author: nctnico
author_rank: Super Contributor
timestamp: May 30, 2020, 12:22:01 pm
content: Quote from: tooki on May 30, 2020, 10:34:11 amNot with wxWidgets. wxWidgets is not made to just offer where OSses happen to have an overlap because the creators understand that that would lead to poor results. There is plenty of support for OS specific features.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 30, 2020, 02:36:47 pm
content: Quote from: tooki on May 30, 2020, 10:34:11 amI remember an article about that, which I found interesting. It basically concluded that cross-platform GUIs were often not a good idea, and that it was in the end often better to factor your code so that most of it can be made portable (and thus cross-platform), but that GUIs were often better dealt with with OS-specific code. Of course it all depends on the project, on the team, etc. Just keep in mind that (unless you're very familiar with one) using a cross-platform GUI toolkit often involves a relatively steep learning curve, then sometimes wasting days or weeks to figure out how to work around some limitations. Sometimes that time is better used writing dedicated GUI code for each targeted OS (not saying this is true in general either.)For a detailed (but certainly opiniated) summary:https://blog.royalsloth.eu/posts/sad-state-of-cross-platform-gui-frameworks/

author: Mr. Scram
author_rank: Super Contributor
timestamp: May 30, 2020, 02:57:11 pm
content: Much of it seems to boil down to that essential first step when dealing with questions: figure out what people are asking. Not just what they're asking, but what they're really asking. Reading between the lines is essential. I've learnt to deny perfectly valid requests because they feel off, until I'm either satisfied that the request makes sense or the requesting party does indeed understand the nature of their request. The false negative rate seems to be much lower than the false positive.Unfortunately people are often so helpful that they'll just dive in and start answering the wrong question, confusing the asking party and themselves.

author: madires
author_rank: Super Contributor
timestamp: May 30, 2020, 03:30:40 pm
content: It's also something you have to learn when you are providing pre-sales support as an engineer. It's crucial to understand what the customer actually wants to achieve, i.e. the whole story and not just some small task inside a larger project. You'll encounter the X-Y problem regularly. In those cases we've often found a more elegant and/or less expensive solution, or even overturned a concept completely, and the customer was extremely happy to get what he really wanted and not what he thought he would need.

author: NiHaoMike
author_rank: Super Contributor
timestamp: May 30, 2020, 04:50:08 pm
content: See this thread for a nice example:https://www.eevblog.com/forum/projects/calculating-heat-dissipation-requirements-for-high-pressure-compressor/?allOriginal statement of problem:QuoteDetail that suggested a more workable solution:QuoteI suggested a cheap pressure washer would allow a safer way to destructive test using water.

author: tooki
author_rank: Super Contributor
timestamp: May 30, 2020, 04:50:19 pm
content: Quote from: nctnico on May 30, 2020, 12:22:01 pmIf it lets you use OS-specific controls, then it means that what you design in it isn't actually cross-platform. I'm not exactly sure what it would accomplish if you have to design an OS-specific GUI anyway (which you should do). I took a look at it and it's a cross-platform toolkit using native controls, thus limiting you to the controls that exist inallthe supported platforms. (This is in no way unique or novel, many such systems have existed over the years.) I checked and it doesNOThave all the controls that natively exist in MacOS, and thus falls squarely under the "sacrifices and compromises" I was talking about.Besides, it is categorically impossible to design an application such that its design complies witheverytarget platform's GUI conventions, since they often contradict each other. It's not just about the colors of pixels. It's about how things work. It's about how things are worded. It's about where things go. So even if every platform had all the same controls (which they decidedly do not), and you could automagically make them take on the "skin" of the target platform, it still wouldn't be native. (For example, Windows developers typically do not understand the deep pervasiveness of drag-and-drop in Mac interaction patterns, with the result that things a Mac user expects to be draggable aren't, because they're not draggable on Windows, so the developer never even thought about making it so.)So, I chuck it onto the list of cross-platform development toolkits that people claim truly produce first-class "native" apps that, upon closer inspection, definitely does not. Not saying you can't makegoodapps with such a thing, but not first-class.

author: tooki
author_rank: Super Contributor
timestamp: May 30, 2020, 05:00:00 pm
content: Quote from: SiliconWizard on May 30, 2020, 02:36:47 pmI 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 arenative to that platform.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 30, 2020, 06:01:01 pm
content: Quote from: tooki on May 30, 2020, 05:00:00 pmUnfortunately, 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 30, 2020, 06:58:34 pm
content: Quote from: SiliconWizard on May 30, 2020, 06:01:01 pmIndeed. 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.

author: Mr. Scram
author_rank: Super Contributor
timestamp: May 30, 2020, 08:08:09 pm
content: I like how this thread has turned into an OS UI discussion on the first page, as if to illustrate part of the problem.

author: tooki
author_rank: Super Contributor
timestamp: May 30, 2020, 10:47:37 pm
content: Quote from: nctnico on May 30, 2020, 06:58:34 pmAh, the confident arrogance of people who havezerounderstanding of the thing they’re talking about ...

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 30, 2020, 11:18:28 pm
content: Quote from: Mr. Scram on May 30, 2020, 08:08:09 pmI mean, the OP kind of used it as an illustrative example, so that would happen.Tim

author: nctnico
author_rank: Super Contributor
timestamp: May 31, 2020, 12:31:35 am
content: Quote from: tooki on May 30, 2020, 10:47:37 pmYou 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.

author: tooki
author_rank: Super Contributor
timestamp: May 31, 2020, 11:36:19 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 31, 2020, 11:48:47 am
content: Quote from: tooki on May 31, 2020, 11:36:19 amThis claim seems to be based on a short cursory look at wxWidgets. Which controls are you missing precisely?

author: nfmax
author_rank: Super Contributor
timestamp: May 31, 2020, 02:02:55 pm
content: Quote from: tooki on May 31, 2020, 11:36:19 amDon't forget Excel was ported from MacOs to Windows, as the Mac version came first.

author: tooki
author_rank: Super Contributor
timestamp: May 31, 2020, 03:00:27 pm
content: Quote from: nfmax on May 31, 2020, 02:02:55 pmYep. 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.

author: tooki
author_rank: Super Contributor
timestamp: May 31, 2020, 03:02:29 pm
content: Quote from: nctnico on May 31, 2020, 11:48:47 amIt 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 31, 2020, 04:51:52 pm
content: Quote from: tooki on May 31, 2020, 03:02:29 pmAn 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 31, 2020, 07:13:48 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 31, 2020, 07:33:32 pm
content: Quote from: SiliconWizard on May 31, 2020, 07:13:48 pmThat 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.

author: tooki
author_rank: Super Contributor
timestamp: June 01, 2020, 08:54:27 pm
content: Quote from: nctnico on May 31, 2020, 04:51:52 pmIt’s not blind “prejudice”, it’s years of experience as a designerand 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 behaviorat 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’sat least200% 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 pmAll I’m saying — as a former UX designer who also spent years working at a software company — is that cross-platform environmentsdoentail some compromises and sacrifices. Your claim was that there arenone, 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 designersandskilled 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 respectyourlimits of subject knowledge, like that as a developer, you likely donothave as good an understanding of UI issues as a UI designer.

author: nctnico
author_rank: Super Contributor
timestamp: June 01, 2020, 10:12:30 pm
content: Quote from: tooki on June 01, 2020, 08:54:27 pmBut 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.

author: Syntax Error
author_rank: Frequent Contributor
timestamp: June 01, 2020, 10:34:10 pm
content: 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 shopshttps://www.bbc.co.uk/news/business-52874615Never mind the bollocks, here's the meat balls.