I just realized something...

[wyrd]

I hate toying with GUI interfaces. I always spend hours upon hours moving stuff around to get it to look "good". Then of course, doing this takes away from the real programming that I should be doing.. argh. Maybe if it wasnt so easy to make a GUI interface with .NET Id at least get some feeling of accomplishment, but since it is easy it leaves a void as if I did nothing at all.

Maybe from now on Ill just make various assemblies that do something with console interfaces and let someone else do the GUI stuff.

Is this so odd? Anyone else like me?

 

[Threads]

Sometimes designing the interface helps me decide how the program is going to work if it is just a small job with no set requirements. heh

Maybe Im weird, but I like designing the GUI interfaces, although I sometimes do spend too much time getting everything perfect. In those times, I just slap controls on, name them, then do the coding and sometimes arrange things afterwards.

 

[Nerseus]

I love doing GUI. I dont spend nearly the time "toying" anymore - I let others figure it out then do it all at once. Well, first I design the GUI, sans any code. I bring screenshots of this to meetings so that our analysts can see what the screens might look like. That helps flush out any problems early on, and before Ive spent too much designing a screen the way *I* think it should work. Im over my "I know better than you" attitude -- the analysts are going to change them 10 times, then the real users are going to change them 10 more. I wait til they get at least 5 or 10 changes queued up before I go back and do any tweaking. In the meantime, the specs are being finished and I can start designing the code (defining whatever it needs to get written before I start writing it). Then I code it. It doesnt sound as fun as sitting down and making a GUI and adding code, but it saves a ton of time later.

-nerseus

 

[wyrd]

... Wait a minute. You design the GUI before designing/writing code? Is that a preference to the work place, you, or just in general how its done? Ive always been under the impression that in the work place the program was coded (class libraries etc) with everything the program would need, then the GUI was designed then basically "plugged in" to the code, that way it was easy to change (or totally re-do) the GUI later on. Maybe I need to start seriously changing the way I do things.

 

[TechnoTone]

We often create a program prototype to demonstrate how it will work and how the user interface will look. We find this is an excellent way to communicate to the non-tekkie types. This prototype can then be tweaked until everybody is happy. The prototype then becomes the basis of the actual program.

 

[Threads]

One reason I sometimes design a GUI first is that if Im doing a special project for a client, I am trying to win the approval to move forward with the project... A good looking GUI can sometimes go further than the technical information for a client that doesnt know a floppy disk from a hard disk.

There is no specified way it must be done where I work (plus I am in charge of other programmers), but it seems everyone I have talked to likes to at least have the basic GUI designed so they know what they are shooting for. For smaller projects especially, it seems to be a good way to show what the requirements are and what kind of information is needed at what steps.

There have been cases where I went ahead and designed some of the back-bone code to do the work of a program because we werent sure where the project was going yet... I knew the back-end code I could use no matter what direction the project went, so I coded the C++ wrappers, and the VB classes, and all that before moving ahead. A week later it turned out to be easier than we thought it would be since we went away from the idea that the client would be able to write their own scripts using Javascript/VBScript and moved to an interface where the input was controlled. Anyway.... Im rambling again. heh

 

[Heiko]

Just my 2c.

ALWAYS start with the GUI.
ALWAYS discuss the GUI with user representatives before coding.

Algorithms can under most circumstances be adapted to the users expectations.

The users expectations can hardly ever be adapted to elegant code.


Of course, this is for "user-centric" applications.
With "computing"-centric applications Id start with discussing the usage if the system, and then try to figure out interfaces between the UI-layer and the computing-layer.

 

[Nerseus]

There are many books on the "right" way to design. Theyre usually geared towards larger projects so they may not be appropriate for ALL projects, especially smaller, single form type of applications.

If youre developing for a client, its good to start with a screenshot so that you can discuss what will have to be included. Its not important to have the layout exactly right and theres usually NO code. Its just a point of reference when building up a functional spec, which includes exactly what the program (or a form, or even just a tab on a form) will do, will show, will save or not save, etc. From that spec you can write your objects, or at least start designing them from a high level. After that, you can go in start writing code. We usually have a junior level programmer do the GUI since its mostly renaming controls, adding events, etc. The more senior developers code the components, web services, DataSet schemas, etc. When the juniors get done, the seniors do code reviews to make sure the juniors didnt do anything crazy

On smaller projects, I still start with a basic GUI. I may or may not rename controls in the beginning. I hate spending 20 minutes renaming them and then deleting half or moving them around or whatever - I hate that rework. Once I have the screenshot close to what I want, then I can stub out code. For me, that means creating functions (minus any code) with comments to let me know what each function will do. Each is marked with "// TODO" which in C# shows up in the Task List, so that I can easily go back and put all the code in.

-Nerseus