New article on OS4coding: "Common GUI Design Problems"

Developers, this is just to let you know that I have published a new article on OS4coding.net. Enjoy!

Edit: Fixed news headline.

@trixie

A pretty interesting article even for normal users, it should be on top of any docs section imho, mate how about uploading it on wiki.amigaos.net ?

@samo79Quote:
That is the plan, as soon as I learn how to upload pictures in the wiki :)

Thanks!

On GoldED, perhaps the undo placement is meant to be right handed, which even on a German keyboard doesn't quite go well as rcommand z.

But let ASL be, I think it's absolutely liked, not just comparatively with other systems.

@trixie

Nice article.

At work I'm busy converting approximately 800 "legacy" screens to GUI and I'm constantly bashing my junior devs over basic UI principles.

Some people "get it" and some just never will.

Having these standards in writing and with lots of examples helps a lot. Some people are very visual learners so the more visible examples the better.

It sounds like you will be updating the UISG wiki? I have a printed copy of the Amiga UI style guide here. Is this a rare item?

FYI my most recent UI-related books are Tuft's "The Visual Display of Quantitative Information" and "Information Dashboard Design - The Effective Visual Communication of Data" by Steven Few. Can you tell I'm doing some BI work? I like Few's book.

Cheers!

@Thematic

RAmiga-U makes more sense for Undo (it's also next to Y which is the common shortcut for Redo). Z is the common cross-platform Undo shortcut, but I have no idea why. It seems more sensible to have "clear selection" on Z, then Select All can go on A (Save as doesn't really need a shortcut key anyway, most people want to quickly save over the existing file, if you're doing save as that's more typing/clicks than a shortcut will save you in the first place).

Actually, that's what Workbench does, and I'm surprised that wasn't held up as a style guide violating example.

@chris

I'd really like the OS dev team to pick up the discussion about standardized hotkeys. The guidelines need updating, that's what I was trying to hint at in the article.

Ideally, the Intuition menu system could receive an overhaul in the key shortcuts department. Currently only RAmiga-combinations are reserved for menu commands, which I find rather limiting. Would be nice if the menu system also supported special keys like Del, Ins, Help, F1... etc.

@trixie

Quote:

As well as RAmiga+Shift+Key, RAmiga+Ctrl+Key, RAmiga+Alt+Key etc.

Might be a good idea to raise this in the Feature Requests bit on the official forums.

@Chris

Makes good sense.

@trixie

Your article is very interesting.
I hope you will write again about gui.

Thanks
YesCop

@yescop

Thanks. I always (almost only) write about GUIs so it's highly probable.

@trixie
Nice article... but your post gives absolutely no clue what the article is about. That seems as bad as some of the GUI mistakes you complain about!

I'll give potential readers a hint, it is titled "Common GUI Design Problems".

@ChrisH

Good point

@Trixie
Nice article (as usual).

Quote:

Just use ToolBox/Upload File (left bottom of the main wiki page). There is direct link on.

I.e. you choice that, then just upload it like "almighty_boing_ball.jpg", and from article do:

Quote:

There is examples from wiki as well:

Quote:

In other words all the uploaded files puts in one place, and you can do list of all the wiki files as well, just from articles use name of need it one. And for some real-live examples you always can choice "edit" of any page with images to see how it done as well :)

@Trixie
Just re-read article one more time and while i always was in hope someday whole "prefs" will be updated and reconstructed, i think at least we can create few BZs for enhancements .. I think how "AHI" could be called then, if there is already "sound", which are for boot sounds and system sounds. Imho, its stays like this now, because its all should be combined and be done right. I.e. now its 2 separate prefs programs (prefs:ahi done on mui, and prefs:sound on reaction), before renaming anything to anything, it should be just one single prefs, called "sound", where 2 first tabs are tabs from AHI, and third one that "Sound" one. I assume (i hope) that was the reasons why it wasn't renamed to something less cryptic.

So for that one imho should be just prefs:sound with merge those 2 in.

Next one "ASL", to what should it be renamed ? Something like "requesters" looks even more cryptic , as no amiga users, and no new comers will get what it mean (what requesters ? to what ? when ?)

@kas1e

Quote:
Absolutely: AHI and Sound should be one, ReAction-based preferences program. I even volunteered to write it but no one's going to give you access to OS components source code, so there goes third-party initiative.

Quote:
Still, "Requesters" is 100% better than "ASL".

Quote:

Absolutly not. They aren't more than superficially related. Sound prefs sets up alert behaviour, which might use a screen flash, a beep or a sample (with boot sound bolted on as an extra) and AHI sets up the sound hardware (which in principle at least might be done by something other than AHI).

If you wanted to merge the contents of Sound with another prefs then probably the alerts should go in GUI prefs and the boot sound possibly in Workbench.

@Andy
Quote:

And still absolutely yes :))

For user all what sound/music related should be in one single prefs. That logical. That easy. That understandable for everyone. Why i should go to one prefs (ahi) to setup low-level stuff, and then, again, i should go to another prefs (sound), to setup system/boot sounds ? Wtf is logic are ?

When user first time come to os, and will see one single prefs (let's call it "audio") in one of tab of which he can setup all that low-level ahi stuff, and in another all those boot/system sounds : that all sounds logical and as should be.

Putting context of sound to anything else , will add a lot more mess to prefs which we have now. Specially putting it to that "Gui" prefs: one hell of cryptic stuff for experience users only already (which should be reduced and simplified a lot).

The reason not to just merge anything with anything, but make os prefs looks clean for newbes. And all sound / music related settings should be in one single preference which can be called as "audio".

I.e. that "Audio" prefs will be reaction based prefs with 3 tabs. First two what we have in ahi, and third one what we have now in sound. Absolutely logical, and all the stuff related to audio in one prefs.

Quote:

So what ? We know it. Its just should be in one prefs. Because all audio related prefs should be in one prefs. There absolutly no needs to mess heads of users who first time try aos. And there is really no needs to have 2 separate prefs one of which carry about lowlevel stuff, and another about system sounds.

In end of all who will design such a prefs, can do everything right, so all will looks logical and as it should be (where system sounds settings, and where sound card settings). Its just mess as it now and make no sense to have 2 separate preferences both of which related to audio. Maybe from technical side you found it logical, but for users its just should't be like this.

After such a merge, I would probably spend a few silly moments looking for "AHI", but I don't regard that as a good reason not to do it.

But since I tend to start it from shell anyway, that's a job for 'alias'.

@kas1e

Audio might be better name for AHI I'd agree.


But lets test your logic re merging sound prefs with AHI

How do I stop my screen from flashing every time I make a mistake or type up to the end of the line or whichever event triggers this type of alert?

Goto Audio? Huh but it's not making a sound. (in fact even Sound prefs is confusing here)

The system Beep is a GUI thing and should be somewhere related to that.

The thing the simple logic simplifictaion you espouse is not so cut and dried, sounds in sound gui in gui printers in printers, sure but then the system beep is a GUI thing that need not use sound, should it go in both? That would be doubly confusing.

In reality clear documetation and a little bit of learning will get you sorted, it does take long to work out what does what.