Future AmigaOS GUI

[mdwh2]

teotwin wrote:
4. My proudest idea is also the visually smallest one. The super gadget replaces all of the resize, maximise, minimise, move to front/back buttons on windows. The idea is that the different click you can do on it will perform all of the same functions, i.e:

I think the fact that it's visually the smallest one is a problem - what happens when it's covered by another window? At the least, it should be possible to move a window to front by clicking anywhere on a window (preferably with a doubleclick - I can't stand Windows' single-click-to-front). And being able to resize on any boundary is useful too (as someone else says, for situations whether the window is partly off-screen - talking of which, is it known if this will be possible in OS4?)

And I think menus at the top of the screen are better than within windows (it's quicker and easier to shoot the mouse to the top of the screen than it is to guide it in to menus attached to windows).

[mdwh2]

teotwin wrote:
@mdwh2
Thats a problem that already exists for all of the window gadgets anyway, the multi-gadget would not try to solve this, all its doing is reducing the number of gadgets and clutter.

True, it's not a bad idea, but operations such as bringing-to-front, moving and/or resizing (preferably all of them) need to additionally be possible over a larger area than just a single gadget (eg, the title bar, boundary or preferably the entire window). The idea of using a key modifier to move/resize by clicking anywhere within the window is a good one (although I'd still like to keep the more standard methods of moving and resizing by clicking on the titlebar/boundary, without having to use a key modifier).

[mdwh2]

SnowBord wrote:
2. The theory being you can get access to your most frequently used commands... hence do stuff quicker.
The goal is to increase the learnability of the package by new users by hiding a zillion potentially confusing options.  Again, increasing learnability is a HCI plus.

Except that when you've used an interface for a while, many people I would say (at least, I do) find their way quickly to the menu option (or button come to that) based on the position. If the position is likely to change randomly, then I either have to carefully read each item everytime I choose an option, or risk clicking on the wrong items.

Thankfully this option can be switched off, but I found it one of the more annoying Windows "features".

Other things I dislike about the Windows GUI:

- Menu items on windows - it's quicker to access menu options when you can just shoot the mouse up to the top of the screen.

- Scrollbar arrows being the complete opposite end of the scrollbar. It means that if I want to 'fine-tune' the position, I have to move the mouse a long distance when I overshoot.

- Also on scrollbars, the fact that the window/scrollbar reverts to its original position if you move the mouse too far away from the scrollbar. I never understood why they did this. Countless times I've scrolled through a large amount of data, and then had to redo it because I had moved the mouse a bit too far just as I release the button.

[mdwh2]

teotwin wrote:
Yes ive seen thode examples before, and there are many many more examples of bad application gui designs. But that is it, they are looking at *applications*, we are trying to focus on the underlying toolkit used to display those applications. Nothing will stop coders making bad ui decisions, and thank god some of the MS teams that do the gui's for the apps are not resonsible for the gui for the OS. At least coders should be given the proper tools for creating good interfaces. As much as amiga lovers hate to admit it, windows IS far ahead in term of gui layout. You can pick at the irrelevant crap specific apps they have screwed up but the fact still remains that the underlying gui toolkit has firmly kicked aos's but over the years and we are still tryingt o catch up. Hence our suggestions.

I still prefer MUI over Windows in various areas, so I wouldn't say it's a clear cut case that Windows kicks AOS' butt. One area where I think the Windows toolkit lets down programmers is the area of making resizable windows. Of course, it is possible to have resizable windows in Windows, and this is the case where they are obviously needed. But countless times I've seen various options windows which aren't resizable - sometimes they don't need it, but sometimes they do have some small textbox or list which I'd love to make larger, but I can't (random examples off the top of my head: the Advanced tab under Internet Explorer options, or the View Logs window on mirc). On the other hand, every MUI window is resizable (and it looks like this is true of Reaction, though I've never programmed it so I'm not sure how it works). On a similar note is the problem that unresizable windows are less likely to cope well with things like different font sizes and so on. This just isn't a problem under MUI. There seem to be various reasons for this:

- "Visual" tools such as "Visual" C++ encourage designing windows with fixed coordinates (ie, point and click create gadgets at the specified position). Visual tools are less common on the Amiga, and no sane programmer wants to hand code interfaces with specified X,Y values;)
- Imo, I prefer the MUI mechanism for creating resizable interfaces (you're saying things like "place these gadgets in a row", and then leaving MUI to work out the resizing, where as in Borland Builder, it's slightly more fiddly given different Anchor and Align properties to the gadgets - and I never worked out how to do it in Visual C++, though I presume it is possible somehow..).
- Lastly, windows *have* to be resizable in MUI (unless MUI determines that this isn't necessary - maybe it's possible to force non-resizable windows, but it doesn't come by default). Under Windows, programmers are often more likely to opt for the easier non-resizable windows.

ps, I welcomed the idea of borderless buttons, they say (in your quote) it just common sense to have borders, do they give any reasoning? I find the borders irritating, add clutter and are completely uneeded. And its not just microsoft doing it, look at adobe's latest offerings, etc etc. If its such a bad idea why has osx and linux adopted it? Dont put to much faith in things just because they bash MS.

One problem with borderless buttons/menus is that it's less obvious what is part of the interface, and what is just text. Okay, in practice I know what a menu under Windows looks like, so it doesn't seem to matter, but this something that could make things harder for newbies. Occasionally I've found websites which redefine the links so that they don't appear underlined, and I often find those very hard to navigate, having to randomly click on text, not knowing what's a link, and what isn't.

I don't know why Apple, Microsoft, etc copy even the bad ideas off of each other.. I wish they didn't.