Why not use MUI?

I must admit that MUI is a very clever piece of programming. And basically, I like the idea of a fully user-configureable GUI very much. But in my opinion, visual feedback and intuitivity are more important features of a GUI than configurability. And it is in these areas that MUI scores very badly.

Visual feedback

Intuition and BOOPSI gadgets give immediate visual feedback when the user plays with them. This is due to the fact that the gadget imagery update is done by the input task, not by the application. The only circumstance in which there is no immediate visual feedback, is when some program has switched off multitasking, but that's not a normal condition.
With MUI, all feedback is done in the application's context. This effectively means cooperative multitasking instead of preemptive multitasking. And this cooperative "multitasking" is exactly why most Amiga owners dislike MS-Windows. For the very same reason many Amiga owners (me included) don't like MUI.

To understand the consequences, imagine an application that is busy performing a task that takes a considerable amount of time. Meanwhile, it offers the user an interface to affect the current task (a common example is a cancel button). It checks the user input every second.
Or imagine an application busy performing a short task, taking less than a second. The GUI isn't disabled, allowing the user to select another GUI element during this short time. This user action is than queued for a fraction of a second until the application is ready to process it. This is of course the way most applications work.

Both are examples of totally acceptable application response, providing that there is immediate visual feedback for the user action. There is a difference between the visual feedback of a user action, and the application response to that action. The former must be immediate, while the latter in general may take a short time, up to a second or so, without confusing the user. (Depending of the kind of application, of course.) MUI applications treat visual feedback as being an application response, thereby failing miserably.

It should be obvious that blocking user input entirely and showing a busy pointer, like some people suggest, is not an option at all in the above examples.

I realize some gadtools gadgets have the same behaveour as MUI gadgets, and that's one of the reasons why I don't like gadtools very much, either. But at least gadtools buttons give immediate feedback.

Intuitivity

Gadtools offers a cycle gadget, . Click anywhere in the gadget, and the next option is selected. You may like or may not like this kind of gadget, but the behaveour exists and is part of the Amiga look and feel.

MUI offers a gadget that looks exactly the same, but behaves differently. Click in the text part of the gadget, and nothing happens. Just a quick flash of a pop-up menu. I have clicked many times on gadgets of this kind and wondered why nothing changes before I realized it was a MUI application so this kind of gadget behaves differently.

The most important rule in GUI design is: be consistent. Gadgets that look the same must behave the same. Gadgets that behave differently must look different. MUI fails to be consistent with the Amiga OS look and feel.

I am aware that there are commodities that change the behaveour of the Gadtools cycle gadget into a pop-up menu. Basically these commodities suffer from the same fault: it changes the behaveour of the gadget but not its appearance.

More intuitivity

Fortunately, MUI 3.x has left the silly behaveour of configuring all your MUI applications from one preference program. But still, configuring your MUI application can be very difficult and not obvious for the casual MUI user. The best example of this is the ever returning question in many Amiga newsgroups: How do I get AMosaic to run on its own screen? I believe that the 18 (eighteen!) steps to perform to accomplish this, are far too many.

And even if the way configuring MUI aspects of an application is improved, there are still many MUI applications offering two settings requesters - one for the MUI aspects, and one for the application's own parameters. This is also confusing. For the user, a system like MUI should be transparent. The user should not need to know which aspect is controlled by MUI, and which by the application itself.

Minor objections

Size and speed

Many people complain that MUI is big and slow. Many other people say you can't expect a 1 MB, 8 MHz 68000 machine to run modern applications, and the things MUI offers is well worth the extra resource cost.

Fact is, MUI takes up memory and CPU time, which makes it bigger and slower than no MUI at all. If you don't give much about fancy looking gadgets, MUI rapidly becomes too big and too slow.

Shareware

MUI is shareware. And MUI applications need MUI, it is not an option.

I want the user to have a choice which extras he or she wants to buy.

Flames?

Don't flame me about this. I won't read it. If you are a MUI lover, well, there are at least three MUI based browsers available. Use one of them instead of AWeb.