|
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.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
