|
We got a couple different ones to help out. First, they were very good at designing graphics. Second, I knew Photoshop better than they did! One guy didn't know how to use the extraction tool, and another didn't know about drop shadows. 
In all cases, I ended up producing better icons, splash screens, and other screen gems that everyone agreed was much better.
My point is, to say that code geeks don't know good UI is BS. I've always prided myself on good UI and do a pretty damn good job. I know some other code geeks that fall under the same category.
This question didn't contain enough options and I'm disappointed. 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
...I suppose those results explain quite a lot
|
|
|
|
|
What about those who still make console apps ?
Regardz
Colin J Davies
* WARNING *
This could be addictive
The minion's version of "Catch ![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif) "
It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
|
|
|
|
|
Ok so most programmers have the artistic talents of a goldfish. I'm quite lucky cos i'm also an artist and have won 2 GUI awards in the past. Not all programmers are bad at design, everyone just assumes so
|
|
|
|
|
At our shop, the GUI design of our web and desktop app is done by a couple of seasoned developers, with feedback from key users. A good amount of thought goes into trying to provide an intuitive and consistent look and feel across both apps. Like others have remarked, I think the poll requires a 4th option.
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
I hired the top gun we used last year to fix all the problems the professionals caused.
Issues:
X Browser support non existant.
They used dreamweaver and the nested tables still drive us nuts.
No flexibility for long strings items wrap in strange places.
However the graphics were top notch.
Pamela Reinskou
VersusLaw Inc.
|
|
|
|
|
so for the first time in ages, I'm not voting.
It's loaded because, no, I don't hire a profession UI designer. What the hell do they know more than I know anyways, working directly with the customers?
Secondly, I do NOT slap UI designs together. Throughout my 20 years of programming, I have been repeatedly praised for making easy to use UI's--so much so, that users have said they haven't ever needed to look at a manual, and, the holy grail, marketing people can demonstrate my software with competence!
I also almost always design the UI first, as I find that UI design often drives significant portions of the interfacing between UI, business, and even data layers. If something is on the UI, it probably needs to be managed in the business layer and persist in the data layer, in some form or other. Approaching the design from both directions at once has been very helpful for me and provides the customer with some early working prototypes to test out the feel of the program.
Finally, while I think I understand the intent of the question, a graphic designer is not a UI designer. These are two very separate functions, in my mind. One is functional, the other is aesthetic. For example, when it comes to web design, my UI might be great (very functional and easy to use) but the graphic design of my site can really suck (lacking in eye candy) because I am definitely not a graphic designer. I may occasionally get graphic, but not with any artistic competence.
So, I have a question for you: when did you stop beating your wife?
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
I agree. I do the user interface on the products for our team. I would give my UI designs a B+ in terms of usability, and a C+ in terms of 'visual appeal' or esthetics. The biggest place for improvement for me is the graphics. I'm not an artist. As a result, I tend to pilfer bitmaps and icons from other sources, edit them to match my needs, and go from there. The end result is OK, but they lack a certain visual consistency.
Software Zen: delete this;
|
|
|
|
|
I always start from the front end too! This is frowned upon by most developers but I always find it works.
I start with the basic data and objects then see how users will use them. I then design the GUI in sections that relate to the processes a user will carry out. A big mistake many developers make is to transfer the data structure to the screen because thats how they see the structure of the app.
I always try to stick to a very simple rule:-
'If you can't do anything within 4 clicks then place that section of the GUI one level higher'
|
|
|
|
|
Same here. It's not like I only design the UI and work backward, making the functionality fit the UI. But I think about the customer. Heck, the automobile industry has been working this way (or at least saying they do) for a long time! It's building stuff for the target audience, and isn't that how you sell / distribute your work?!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Marc Clifton wrote:
So, I have a question for you: when did you stop beating your wife?
Improper question, it is based on the wrong assumption that I already stopped doing it. 
|
|
|
|
|
Unless you're talking about icons and bitmaps, most of the UI design sould be mechanically generated by business logics, hence by the same code that makes your application work properly.
The case of dialog boxes being really representative of this.
-MyttO
|
|
|
|
|
If you are writing something dead simple like a data entry mask for filling some database, yes.
Otherwise - no.
The GUI is all that the User has to look at the data yor application is providing. YOU (the developer, the one who knows about the data and what you can do with it) need to come up with a UI design that eneables the user to look at the data in a way that helps him to solve his problem.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
Don't you realize that business logics is the system modeled by at least two views: GUI and data structures.
There's no point to oppose the two aspects. They should come together like the two sides of a coin.
And by the way, no, I don't design things "dead simple" blablah... as you say, and yes, i make the GUI and the code consistent, because it's worth the initial pain, and it leads to the best results.
Offcourse, I remind you, I'm not talking about all this bitmaps part, like banners, splash screens, and icons, which requires totally different skills.
-MyttO
|
|
|
|
|
Sorry if I came across too harsh.
But this whole concept you mentioned, where the business logic forms the UI is simply not working in a scientific environment like the one I am working in. My company is producing instruments, and while it is trivial to display the data read by the instruments, the users do not want to see this data (for this, they could use Excel and make their own scripts). They want a tool to get the *information* in these data.
And often, making some new view possible, they immediatly want more of this change a handful of parameters and so on.
The main point is to have UI concepts flexible enough to integrate this type of extensions.
And yes, the bitmaps part is made almost completely by professionals (but we sometimes make a icon or two where it would take longer to explain what it does than drawing it).
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
I understand better your point of view.
It seems in your case, you get "measures" from physical instruments, then process them and display the result -- the valuable information -- using your GUI.
In my view, the Result is still a form of business logic, be it derived from the Measures, at a higher layer. This -- derived -- data layer would have a GUI counterpart I mentioned.
This would be a way to harmonize our opinions in your environment. Or am I totally wrong 
Anyway, my environment is quite analog on this approach, where the business logic is still of the user interest (business), while also dealing with more primitive abstruse data.
-MyttO
|
|
|
|
|
|
Wow, this poll misses the boat:
- Design encompasses everything: Software design, usability design, graphics design. If any one of the people doing these tasks tries to claim the mantle of "The Designer", trouble will ensue. A total system design considers all elements.
- The question is like asking "Do you still beat your wife?". Sometimes a software team may have a person with good visual design talents; in that case, "throwing it together yourself" is kind of condescending.
|
|
|
|
|
OK - it probably could have been worded better. The question was purely the look and feel in terms of colour, style, presentation. Usability is not something a programmer or graphic designer without knowledge of usability issues should be doing. It's also not about software design.
If you yourself have professional experience / skills in designing UI's then you are getting professional help - your own.
The survey was inspired by a long and heated conversation about how bad some applications look and how the average developer is (generalisation warning) very bad at graphic and layout design. We decided that it's probably time that the wrapping paper got as much attention as the box inside.
cheers,
Chris Maunder
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
