A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am still a junior level programmer for a pretty large UK based company. When I am to write our software, I get as much freedom as desired to develop the internal logic. However, the GUI interface, by which I mean the relevant pop-ups, click behaviors, positioning of graphics etc. is fully dictated by James, The Big Boss.
Usually The Big Boss simply tells me the overall 'plan' which I develop in code. The GUI specifics are only settled on a couple of weeks after I finish the basic code. And frequently these specifics end up vastly different from the original GUI plans, which causes a lot of coding difficulties and makes the code a huge mess.
My questions are as follows:
1) Should the overall GUI not be settled on before the code is started. At this point the programmer has full control as to how things should behave GUI-wise and can code relevant scenarios as they come along for the viewing of the boss. Ultimately certain things will not work as expected from a GUI point of view, but more or less everything should fall in place. Worked appropriately, at no point should the developer have to completely change huge chunks of code because of radical changes to the logic of the GUI.
2) Am I wrong to complain? Ultimately our code ends up a mess due to these GUI changes. Keep in mind that we use VC++ such that the GUI is largely written as code. Also keep in mind that many of the changes are to move a button from FormA to FormD, or to make FormC a child of FormB. In these cases the logic and the GUI are kind of linked, such that the changes cause a lot of breaking to the logic.
3) Can the source logic be truly decoupled from the GUI in VC++? I am talking here about a complex project where data flows down many paths and is linked heavily to the interface.
Sunday, October 03, 2004
Well, I am not familiar with VC++, but as Shrek would say: Layers.
If you layer your software:
Business Object layer
(each layer only deals with the adjacent layers)
then if one layer changes you only have to change at most one other layer, preferably none at all if the abstraction is designed OK.
Plus, then you can cater for multiple UIs.
When you start you should a have a pretty good idea of what you're doing. If you're not, then, well ...
A GUI (screen shots) design is not something you want to present to stakeholders unless you're ready to spend your time in infinite useless meetings. You're better of with a demo. Still, you have to design your computer to user interaction before coding (well, you have to do a bit more before coding, but that goes beyond your question). Use cases are a good tool for that. Write your UC then look at the dependecies (the include and uses kind of) between them. You can easily figure out what the screen flow is and what controls each screen contains.
Monday, October 04, 2004
I think Joel mentions this elsewhere...
But you DON'T want a beautiful UI right off the bat. It gives the impression that the application is nearly complete. IMHO, have form elements that are purposely out of place to represent the stubbed out portions. Then replace those with the actual elements as those other parts come online.
It sculpturing at that point...
I don't know if it can help, but a few years ago I built a C++ program, for which we did not know the graphical toolkit at the beginning.
So the first version of the program was actually a console tool (a kind of interactive interpreter). Thus the logic could not be coupled with the GUI - at least at the beginning. And it was easier to test.
Tuesday, October 05, 2004
Dino wrote: "A GUI (screen shots) design is not something you want to present to stakeholders unless you're ready to spend your time in infinite useless meetings. You're better of with a demo."
I gues I don't understand the difference between "a GUI (screen shots) design" and "a demo" as far as how it will work as input to a GUI design/suggestions-gathering meeting with stakeholders. A demo for such a meeting is likely to be effectively just some screenshots with a bit of dynamic behavior (for instance, when you click on something it shows something else, rather than the presenter saying "if I clicked on this, you'd see this", and then going to the next screenshot.
Also, I found that having a few rounds of meetings to refine a UI - whether with a demo or screenshots - is very helpful, if in between you improve your demo/screenshots to reflect feedback. After a few you've got usually something a lot better.
1. Yes, presenting a screen shot (even ALL the screen shots) as you expect it to be will promote long-term wrangling. Problem here also is the only way to get ALL the screen shots is to have the application actually work, to some extent.
2. I don't think there is any other way to get agreement on what the application will 'look' like.
Possible alternative -- what you see is what you get. With 300 screen shots, they won't be ABLE to criticize every screen. After criticizing 20 screens, they'll be so tired they'll let the rest go.
Reality: User's don't get that tired. If they do, it's only for a short time, then they're back.
Friday, October 08, 2004
"Also keep in mind that many of the changes are to move a button from FormA to FormD, or to make FormC a child of FormB."
As a UI designer, these are the kinds of changes I expect to make pretty much on every project at any time, and at no cost of effort or misery for anyone, developers included. Why? Because these are the kinds of details that you often get wrong before you put a functioning GUI in front of users and stakeholders. Sure, you can avoid *some* of these mistakes by doing paper prototypes, but never all of them. In general, in building web apps, this isn't too much of a problem; I can't comment on VC++.
Other comments that suggest a layered approach to building are definitely right. Even in the visual and interaction design of the UI (that is, the way elements and widgets look and behave), designers can strive for a modular, "layered" approach: widget headers should be identical everywhere, buttons should behave the same everywhere, etc.
Sunday, October 10, 2004
I always like to put a "skinnable layer" on the front end. This allows end-users and other developers to "skin" your interface to look and feel any way they wish. Send the app out with a few "skins" to start with as examples. Using this method they can change the shape of the form and butons, etc, as well as any color scheme and window layering. Allow the user to dock and undock everything anywhere and allow those docked windows to look like anything and you quickly put to rest any UI interface changes as the interface should be very light without any processing other than
call some object in an abstraction layer;
Cruising along on Friday and I came across this:
"But you DON'T want a beautiful UI right off the bat. It gives the impression that the application is nearly complete. "
I'm more impressed all the time by what I read here.
The above DON'T has been the de facto standard DO that I have witnessed where I am.
I don't question at all which I think is correct. Especially knowing the pretty little UI for one of our apps is exactly what makes it run like crap for our unfortunate web users still on 56k or worse.
I am Jack's Friday fuming fun
Friday, October 15, 2004
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz