|
I see a lot of applications where the opposite is the case: Lots of effort to make the application look cool, at the expense of usability. One example is Creative PlayCenter. Another is Windows XP. Those fade-in menus and fat space wasting title bars just make the UI harder to use.
|
|
|
|
|
I agree with your comments regarding XP. The first thing I do to "kneecap" Windows is get rid of the stupid fade effects and then I reduce the title bars to the minimum size possible. The XP UI looks like it was designed for three year olds.
|
|
|
|
|
Anonymous wrote:
The XP UI looks like it was designed for three year olds.
It was designed for its target audience: the typical PC user.
Read into that what you will.
Putting the laughter back into slaughter
|
|
|
|
|
From my experience, there is a huge gap between graphical design (anti-usability) and human interface design (usability). When you mix the two, you get a massive release of vocal energy that exists solely for the purpose of giving developers and analysts splitting headaches.
I deal more with developing web-based applications; the current project (6th release, 3 years of development) *must* be compatible with browsers all the way back to NS 4.x. Due to this, she scope of our ability to produce a good UI has been crippled from the start.
In my opinion, usability is the real issue, and the graphical design is but a small part of creating a good usable application.
Please forgive the following... I just got home from a one hour commute after an 11 hour (mandatory unpaid overtime) day of fixing design defects that would have never been existed had things been done correctly during prototyping. I need to vent.
<rant style="frustrated">
My employer started by contracting with Human Factors International. Combined with our designers, a good visual standard for the application was produced. All was good.
Flash forward three years to current day: we still religiously conform to the original design standards. The site looks nice until you try to use it... the (business) analysts have gained control over the flow of the application. They did not consider the flow of the application in the context of usability.
For example, we have forms that scroll across multiple pages that refresh without warning to become longer as data is entered and options are selected. And God forbid you try to use the back button...
Then the designers ended up getting transfered out of our department or let go for openly disagreeing with the higher-up analysts (who have political power to leverage). Prototyping has nearly been abandoned, the powers that be say it takes too much time. The work that previously took four weeks for three dedicated designers and developers has been relegated to a single VB programmer that has only basic HTML experience, no graphic editing experience, and is quite passive.
!!!
</rant>
It's been a bad day
|
|
|
|
|
Feel free to rant - I think this is valuable information for those of us who want to avoid these conflicts. So you are saying the analysts are screwing things up? What is their upper most criteria for the design - what is their guiding principle that is messing things up? How did they gain control in the first place?
J.
----------------------------
|
|
|
|
|
First a disclaimer, on a person-to-person level, the analysts I work with are good people. Many of them are friends, and they work very hard to do their jobs. I am upset because, in my (strong )opinion, I disagree with the many of the decisions that have directed and changed the course of our project.
To set the stage, the analysts with the company I work for have following significant function:
Define requirements
Research business issues
Estimate time to complete tasks
Maintain the project schedule
A few of the analysts can be indistiguishable from project managers at times.
Your last question first. Specifically within the company I work for, I stated that the analysts have political power based on two facts: the senior analysts that are a half-step below management have been with the company for many years, in a sense they have achieved tenure. They have an immense and intimate knowledge of the internal workings of the company and have developed a network of friends that reach high into upper management.
Most will listen to advice and recommendations that contradict with their decisions, but a few don't take well to challenges. And watch out if you actually prove one of them wrong. I have witnessed one analyst in particular run through a vendetta that caused a valuable co-worker to be forced to transfer to other departments because he was willing to stand up to her and challenge her decisions that he believed we not healthy for the project. I have been in this person's sights a few times myself, but I have my own defenses that have held out so far.
In a more general light, a software project (especially an enterprise-level application) is birthed, lives, and dies by its requirements. The analysts control the creation and evolution of these requirements.
The requirements birth the project because they crystalize and express the solution to a "need", the provide the rationalization needed to acquire funding.
I say the project "lives" by the requirements because requirements can be very fluid. The flow and evolve as new information is processed, the project is evaluated, new stakeholders come on board, and feature and scope creep sink their claws into the application.
A project can die by the requirements in a few ways:
- the requirements can get out of control, causing the project to bloat until it is killed.
- the requirements can be insufficient which often leads to a dead project that does not meet the expectations or needs of the stakeholders.
- and, more rarely, the project succeeds and continues until it is no longer needed or has been superceeded by a new effort.
Now for your first question: I think the guiding principle that has messed thing up is their willingness to blindly follow a process that is broken; to be afraid or unwilling to commit to the time needed to fix the bad process; and the willingness to burn hundereds of hours (that translate to $$) in an attempt to fix the symptoms caused by a broken process. (not to mention that the blame for these bloated expenditures fall upon the developers and implementation team who dance to the requirements...)
Their upper criteria for design is the aforementioned standards document. It specifys the page layout and spacing to the pixel, details what fonts, colors, and embellishment are used for what text, etc.
The problem here is that the visual layout of the page is a small part of the overall usability of the application. It is important, but meaningless if the rest of the factors that affect usability are poorly considered and implemented.
To expand on my earlier example of the page form that runs on forever: it is an electronic version of a pre-exisiting paper form (financial). I don't know how they ended up at the established solution, but the decision was made to completely replicate the layout of paper forms on the website as accurately as possible.
The electronic forms are now massive, difficult to navigate, and confusing. Complex interactions between form elements are processed and validated on the server-side. The code needed to handle these monster forms can be unbelievable.
The general consensus among the developers is that the forms should have been split across multiple pages divided by purpose... enter you demographic information here, contact info here, financial information here, references here, etc. These pages could be weaved together more intelligently depending on what the user wanted to do... if they just wanted to update their contact information, they wouldn't have to deal with looking at sixty or seventy un-related form fields.
Myself and the other Dev Leads try to raise these issues, but either we are told to concern ourselves with the implementation and leave usability to the experts, or worse, they agree with us then tell us we can't fix it because it would take too much time.
This kind of division would have made the application much easier to debug and reuse as well... we often repeat common sections in the various forms like demographics and contact info. Instead of having a single point to deal with this data, it is spread across multiple forms and application components. The amount of duplicated effort is astounding. The effect this has on the time it take to maintain, test, debug, and fix problems is sad and discouraging.
I think our project is going to succeed (it is already in production for 2 years), but it is already proving to be a pain to use. The thing is, it is less of a pain that the paper-process, and our competitor's solutions are even worse than ours (they had to rush a product to market to compete with ours). So as funny as it sounds, the customers praise our application, unaware of how good it could truly be.
|
|
|
|
|
Not being able to afford a graphic designer, I do all my own UI work. I've found the trick is to keep it simple.
Listening to user-feedback is very important too - they are the ones who are going to use it in anger so it is very important to take their ideas on board.
Of course the best way to figure out if you've got a good UI is to sit and try and use your own program for a couple of days. You'll soon see if you've got a useable UI.
Michael
'Logic, my dear Zoe, merely enables one to be wrong with authority.' - The Doctor: The Wheel in Space
|
|
|
|
|
"I know what I'm doing, and can do it myself!"
*¨¨`)
¸¸.·´ ¸.·*¨¨`)
(¸¸.·* ¸ .·*
¸¸.·*
(¸¸.~~> Joel Holdsworth.
|
|
|
|
|
I agree , though some of my colleagues might not
|
|
|
|
|
I agree... I chose the second option on the poll, because sometimes we get a graph designer to develop the GUI... however, many times they don't get the point and wander off on less important things. I know that GUI is a very important part of a professional app (since it is what the user sees and interacts with), but it must not get in the way of functionallity.
|
|
|
|
|
Ahhh... but what good is the functionality if the user cannot use it effectively? Also, what may seem less important to you, may be very important to the user.
|
|
|
|
|
Totally... I certanly agree. I allways work from the user up for app design. My point is that just getting a designer does not guarantee that the app will be really user oriented and functional. The designer must be "trained" in app design first (and even some programming) so he/she know how things work inside...
|
|
|
|
|
Anonymous wrote:
but what good is the functionality if the user cannot use it effectively?
Please define "effectivly".
A command-line based interface can be extremly effective. And there are a lot of users who want to get the job done while not being annoyed by visual fuss like absurdly skinned buttons.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
Yep, I choose option 4.
Jason King
|
|
|
|
|
Yep, another for option 4. Surprised it was missing. First time I have not been able to vote.
Rocky <><
www.GotTheAnswerToSpam.com
|
|
|
|
|
Just because we are programmers doesn't mean we don't do a professional job. The UI may be secondary but it still gets an awful lot of work put into it. I have become really quite good at layout and ease of use (even if I say so myself ). There are always numerous ways the user can do the same thing so they can work how they want to.
So we do not need to bring in outsiders to get it right.
Its right to start with!
Roger Allen
Sonork 100.10016
Death come early, death come late,
It takes us all, there is no reason.
For every purpose under heaven,
To each a turn, to each a season.
A time to weep and a time to sigh,
A time to laugh and a time to cry,
A time to be born and a time to die.
Dust to dust and ashes to ashes,
And so I end my song.
|
|
|
|
|
The UI is *not* secondary. It is as important, perhaps even more important, than the stuff the user does not see. Just try to sell an app that may do what it was designed to do but is lacking in the UI department to Mac users. You would not stand a chance. Mac users tear applications with poor UI design to shreds, regardless of any other redeeming values of that app. Windows users seem to be more tolerant. I think all developers who design Windows apps should have to do a tour of duty on the Mac OS first to learn about human interface
|
|
|
|
|
A graphic designer is that person who uses Photoshop a lot and is normally hired to make the UI look cool - shaded bitmaps etc.
UI design is about usability, standards, etc. Two completely diffent things.
|
|
|
|
|
I agree, but the same doesn't always apply for designing Web applications. Sometimes making an application more usable can be aided by the skills of a graphic artist.
|
|
|
|
|
In most cases the graphic artist make the application more appealing, not more usable.
|
|
|
|
|
...when you're in the narrow but popular scope of Windows end-user application software at any rate. What, you think those buttons are made out of sheet metal?
The UI is for getting input from the user, and presenting output to the user. If you think sans-serif text on a gray background is the be-all/end-all of information presentation, then i wish your days in UI design to be short and painful. Hiring a graphic designer should get you someone who knows how to to convey that information to the user as efficiently as possible, utilizing text style, color, positioning, etc. to achieve these ends. And if you can work some good aesthetics in there too, well... it'll look good on your advertising materials then.
That said, putting rounded purple corners on the borders of everything doesn't necessarily accomplish much. Direct your effort where it's needed.
A servant to formulaic ways.
Shog9
|
|
|
|
|
"If you think sans-serif text on a gray background is the be-all/end-all of information presentation"
The simple fact is that sans-serif text on a gray background is easier to read. Using fancy colour schemes only makes the UI look cool, they don't do anything to improve usablity.
Not that I have anything against a cool looking UI, as long as it doesn't make the UI harder to use.
|
|
|
|
|
Anomonous wrote:
The simple fact is that sans-serif text on a gray background is easier to read.
Bullshit.
How many books do you see with gray paper?
How about data entry terminals? Seems to me they tend to go with [amber|green] serif on black as a rule.
What about billboards, order information during TV informercials, roadsigns?
What about Windows 3.0 / the original MacOS?
Black sans-serif text on gray was someone's idea of a "fancy colour scheme" at one point - dig out some old magazines if you're not old enough to remember, and check out all the columnists gushing over OS/2 and then Windows95's "3D / Etched" look.
There are two points you can honestly make in favor of black+sserif+gray: it is low-contrast, so it doesn't distract you from higher contrast areas of your app (good for menus/sidebars), and it is the default appearance for most Windows apps.
So if you're lazy and only do menus, you just may get away with black+sserif+gray.
A servant to formulaic ways.
Shog9
|
|
|
|
|
Well, depends on the shade of grey. For instance this text box that I'm writing in is fine. Of course a really dark grey would be bad, but also you can see many examples of bad contrast between text and background: just look at the Windows titlebar!
|
|
|
|
|
Quite true. Notice how each version of Windows since 95 has lightened the shade of gray used on most UI elements?
A servant to formulaic ways.
Shog9
|
|
|
|
|