I'd like to know all the things that people hate in user interfaces - so that we can have a reference of all the things not to do :)
And anything you especially like in UI's too. Because negativity is a bad thing.
Printable View
I'd like to know all the things that people hate in user interfaces - so that we can have a reference of all the things not to do :)
And anything you especially like in UI's too. Because negativity is a bad thing.
Stuff I hate
1. Small fonts
2. Too many stuff on screen
3. Unorganised
4. No colour
Stuff thats good
1. Easy to navagate
2. Tooltips that give tips
3. Uses Windows theme
But too many different colors is bad too :)Quote:
Originally Posted by Andrew G
Any comments on behaviour ?
Same name on different forms that means different things is bad.
Too many forms open at the same time also not good or
Programs that force you to restart and if you don't they leave that damn huge box that sits in the middle of the screen and won't minimise
I hate:
Popups.
Flash.
Overdone graphics which makes navigation a task to figure out.
<marquee>
<blink>
<frameset>
Pages that don't work in FF.
Screwed up tab orders
Thanks for all the comments so far. Any more?
Personally, I LIKE:
- Consistency in appearance and behaviour, within itself and with the OS
- Easy navigation
- Customisability and extensibility
and I DISLIKE:
- Hidden buttons (things that do things without obviously being buttons)
- Clutter, but at the other end of the spectrum, also over-minimalisation
- Unresponsive or slow UIs
- Fonts that aren't Tahoma :D
Fontsizes that look like they are for the visually handicapped.
Too much crap on a form.
No organization.
Overdone graphics as a ploy to detract from the disfunctional interface.
Forms that to resize but not the controls leaving vast amounts of blank form realestate.
Programs that are slow or irresponsive to the users actions.
Inconsistancy.
Out of order tabbing.
Bad color combinations - ie
http://www.vbforums.com/attachment.p...chmentid=36756
:lol:
christmasy...
One of your own applications, I presume.Quote:
Originally Posted by RobDog888
Yes as i changed the 2 colors to the worst possible combinations to make my point. :D
You sure they weren't "client requirements"? :roflmfao:
I have seen things, so that'd sound believable. :sick:
Nope, just me making a point although maybe you only having 2 eyes lately has distored your view on things. :D
Mmm... distorted. ughghhghghgh :homer:
get your third eye back already..
Whos got mendhak's 3rd eye?
One of the best application I've ever seen. Its quickbooks.
i'm already confused by it..
Where do you start? :confused:
Is that Macromedia Flash or just stuff that flash on the screen?Quote:
Originally Posted by mendhak
Do you people refrain from using MsgBox?
And how about Flat vs 3D controls?
I prefer a style that is (by default) conformant to the user's operating system and active theme - unless you can make a custom-styled GUI that is equally clean and better looking :)
Message boxes - only when you have to. You be a lot friendlier and less obtrusive in giving the same information these days, with labels in appropriate places and things like balloon tooltips, which can replace message boxes that pertain to widget content as the tooltip does not get in the way.
This is your thread PG but I hope you don't mind me asking questions here. :)
When you said Active Theme I am thinking about the Current Theme in XP, am I right? You'll design your app based on the current theme of the user or let your app accomodate according to the theme of the user?
Go for it, it's all about good UI design anyways :)
I design my applications to accomodate the user's theme selection. If they are using XP-Metallic then my application will render in silver. If they are running XP-Homestead, then olive. If they are using XP-Classic or an older version of Windows, then it will render using the classic controls. Basically, it's about run-time flexibility - that includes changing theme on the fly (a broadcast message, WM_SYSCOLORCHANGE or something like that, notifies you of a theme change).
Then again, if you can make a really good looking, clean, usable skin for your app, that's fine too. It depends on what it is. For a media/entertainment application, skinning can work well. For a business application, skinning probably isn't a great idea, you should aim to fit in with the user's OS appearance so that the design isn't distracting from the use of the application.
The image mar_zim linked is a bit of too much clutter: there are too many main level menus and toolbar items.
Anyways, in general, a program I like:
- controls can be tabbed in good order (hey, I use keyboard often!)
- a lot of effort to small details, ie. filling up something automatically if it is possible, on-the-fly prevention of invalid data (instead of showing a messagebox warning when you push ok)...
- keeping things clear and simple looking without leaving out any features
- well organized windows and content so things are easy to find even if you haven't spent time learning it, relating to above
- familiar keyboard shortcuts, following Windows standards and most other programs
- wizards are great for bigger jobs: instead of one big cluttered window, you get a well guided tour to what you want to do
Humm... that is pretty much all general rules I follow in my design. I don't like skinning all that much. About the only program I use skinned is QCD (though its default theme is a perfect example of bad skinning - Soma Black is excellent once you learn how to use it).
I hate -
Buttons
Textboxes
Listboxes
Labels
Forms
RichTextBoxes
Common Dialogs
'Everything else.
Think you could whip me up an application to those standards ?
:lol:
I agreewith most of the people here though, Clutter, bad colour combos, and siorganisation with tab ordering.
I hate it when a program forces a user to interact with it such as a msgbox asking
Are you sure?
then
Are you sure you're sure?
I also hate programs that are scheduled to run (such as backup software) and when they do they bring their form to the front of everything else.
The cheap Backup software I have even gives me a message box telling me that no files needed to be backed up and stays running until I click OK.
Curiously how do you do it when you want to confirm something before actually doing it?Quote:
Originally Posted by moeur
I assume that if the user chose to do something then he really wanted to do it. I suppose for really dangerous acts then a confirmation can be performed, but the act of exiting a program is not in that class.
I've written a lot of programs for people who aren't computer savy and don't like computers. My philosophy is to require them to do as little as possible or they won't use the program.
Especially on repetitive tasks I try to minimize user input by guessing at default data values for them and not putting in confirmation messages.
Webforms
--Cursor Tails
--Music any other place besides the intro (and all 16 bit "ring-tone" music)
--Guestbooks
--Page Counters
Winforms
--Excessive TabControls
--Errors or validation issues only showing up in dialog boxes
--Programs that force full screen on load
--Buttons (or other user events) that will fire without changing the GUI at all (No "Please wait...", "In Progress..." or a bar)
--Basically any design that feels like the program is driving you instead of you driving it.
I let them do it w/o otice and provide "Undo" functionality.Quote:
Originally Posted by dee-u
90% of coders don't know bugger-all about GUI design. That is why QuickBooks sucks a fat one.
A GUI should take up as little overhead as possible, which means you need things like backbuffers and cached data and NOT creating graphics objects at runtime (unless you are doing control arrays which only need to be created at loadtime).
Its fine to do gradients as long as you have an idea of how clock-hungry they are.
Cache everything you can, RAM is cheap, CPU cycles are NOT cheap, remember that.
This and message boxes.Quote:
Originally Posted by demotivater
I hate loath and despise message boxes.
How about message alerts? :D
You've probably seen this, but it's a list on HTML Hell.
Sometimes though some users "accidentally" push buttons (e.g. closing the form before they have saved a record...) or their mouse goes haywire and a confirmations saves the day in such cases...Quote:
Originally Posted by moeur
In cases of saving records what approach do you do to "Undo" it?Quote:
Originally Posted by sevenhalo
What is your alternative for message boxes? Timed form that disappears automatically?Quote:
Originally Posted by Hack
Rollback.Quote:
In cases of saving records what approach do you do to "Undo" it?
You're holding them in transaction? When do you commit then?