What thought processes do "Real Programmers" go through when creating a program?

[Al Smith]

Hi,
All my programs previously have been just for me. I didn't really need a "User Interface", i.e. Form. They were formless, no option buttons, no text boxes, etc.
I'm now trying to create programs that other people can use and I'm finding this most difficult. I'll spend hours trying to get the Form just right and then start actually programming. Then I find I should have used option buttons instead of check boxes.

How do "Real Programmers" go about creating a program?

Al.




------------------
A computer is a tool, not a toy.
<A HREF="mailto:asmith3914@aol.com
asmith@spxateg.com">asmith3914@aol.com
asmith@spxateg.com</A>

[ermingut]

I create several programs not just for me. And I can't seems to get basic idea how programs may "look and feel".

But I have one advantage. I convince my sister to test my programs. And he finds bugs where I will newer think of. And this is quite good way to create user friendly program for me.

Ermin!

[ermingut]

Not he - she!!!

[SteveCRM]

I don't worry about the interface at first, I make my game, then go back and worry about graphics, and setup. Otherwise, I will spend the whole evening working and only get the title screen done!

Steve

The thing I do when I create a program from scratch is draw it all up on paper as to what the program idea will look like. I then from there break it down on paper as to what each interface of the program will look like. Mind you, sometimes in mid programming I have come across something better along the way and then I may have to redraw my program interface for a particular area. But thats not that hard. I then from there redraw everything in a aflowchart and break down each button etc. Sometimes I just wing it at this point, but it does work and I have done it several times.

The project I am into now is just for fun and it's using ideas from multiple users, so I can't just sit and draw this up. But I do have the basic "outline" of the program drawn up.

Bottom line - Get pencil and paper - It will save you time in the long run.


------------------
John T. Mieske
Star Trek LCARS programmer

Knight Vision Enterprises
kvision@gate.net

[MartinLiss]

Knight_Vision's suggestions are good ones. You should also try to have someone review your plans for your UI. All you need for that is a drawing or a blackboard and chalk. You might actually do it twice, at least once with a potential user, and again with another programmer. I also suggest you buy a book named Doing Objects in Microsoft Visual Basic by Deborah Kurata. Not only does it explain OOP (Object Oriented Programming) very well, but it also devotes several chapters to the design process.

------------------
Marty
Why is it called lipstick if you can still move your lips?

[chrisjk]

I don't use paper - but I imagine what I want the form to look like and the controls that should be used...that way you can easily change it if you hit a problem! :).

As for what type of control to use when, think about this:

text box: allow the user to enter free text with no (or little) constraint, like their name
option groups: when you have at most a few choices that you want the user to select from, e.g. Male or Female
combo boxes If you have slightly more choices, e.g. digestive biscuits, wholemeal biscuits, milk chocolate biscuits, plain chocolate biscuits, rich tea biscuits
list boxes when you have many choices the user must select from...e.g. name of every street in your city
check boxes simply if you want the user to say "yes" to something, usually an option...e.g. "Show this form at startup"

once you get the idea, you can immediately figure out what control to use - takes practice I guess.

If you want the form to look good, stick to the Windows look, keep it simple, line your controls with each other as much as possible, put a label next to every control so the user knows what to enter (esp. text boxes), consider using "What's This" help.

Group related controls into frames, e.g. all your address text boxes could go in one frame, simply labeled "Address" rather than labelling all of them.

A good thing to do certainly is buy a book about it. There is nothing more annoying than a program not explaining things and not being easy to guess. You might also like to inform the user of activity over long periods of waiting. e.g. if your app is downloading file from the internet, show a progress bar. People hate it when the app "appears" to have stopped responding.

Hope these suggestions are of use to you

Kind Regards,

------------------
- Chris
chris.kilhams@btinternet.com
If it ain't broke - don't fix it :)


[This message has been edited by chrisjk (edited 01-24-2000).]

[mystiq]

I just go with the wind, so to speak, on all my programs, and it works nicely :-) Aside from the fact that i've done many personal programs with pretty interfaces, but 3 recent public projects are successful from the interface point of view.

I really just think of what I need, put the controls on the form, and arrange them so it's easy to find what you need. Only recently i found that I may have to redesign the Options interface for a program I have, but only because the code behind it isn't functioning (properly) anymore. I only used pencil and paper once to tell you the truth :) and it was for a terribly complicated ANSI color engine when I knew more about rocket science than string parsing.

My programs, no matter who the intended audience is, i'll do anything for a "Wow!" on someone's face when they run it for the first time, and so far I must say i'm pretty successful. I've been doing UI's since my first project because the first thing a person sees is the interface, not the algorithm you spent 5 hours coding last night when you had a paper due :) But not to say the code isn't important too. Ok, im rambling now. Bottom line is just stick with what you need, keep it simple and everyone's happy.


------------------
-Mystiq

[DiGiTaIErRoR]

Just remember this: most people want to be entertained. What this means? They like a pretty interface, yet simplicity, and above all working code! If you have these then your program writes itself!

------------------
DiGiTaIErRoR

[Al Smith]

Hi,
Thanks for all your input. Although putting an idea on paper might not be as satisfying as actually programming I think the frustration it avoids might be well worth it.
After a while maybe I'll be able program "on the fly".

I have a coffee cup with several computer programming sayings. One of them is Golub's laws of computerdom:

A carelessly planned program takes three times longer to complete than expected; A carefully planned program will take only twice as long.

Thanks again,
Al.


------------------
A computer is a tool, not a toy.
<A HREF="mailto:asmith3914@aol.com
asmith@spxateg.com">asmith3914@aol.com
asmith@spxateg.com</A>

[SteveCRM]

Knight_Vision has a good idea, if you don't want to use paper, recommend a white board. They erase easily, and you can sketch without wasting paper. I find it VERY useful.

Steve (Good Luck :))

[JeffSM]

If you don't know how to begin then look other similar programs, then you'll think about make better them.

I use to make my programs "look" like Microsoft, 'case others people are alredy used to work with them.

I suggest you to do like ermingut that pass to another fellow test. Give to thoose people that are not your close friend 'cause they 'll say "it's wonderfull" even if it's a sheet!

Well, the most important, is write messages and labels that are easyly for people, that don't know the application, understand what you think when you did. Leonardo DaVinci used to think from 5 points of view - I DO IT TOO - It's works!!!

But the great success is take one user of your application and talk to him and tell him about your idea for each thing that you did and ask him for good texts messages and labels that will be understood for people from his kind of work (trabalho in portuguese). Exemple: Ask a doctor, a laywer, a quimical, etc.

It's good remember that WE KNOW what WE DID, BUT THE USER DON'T KNOW WHAT WE THINK (when we did), THEY KNOW WHAT THEY UNDERSTAND ABOUT WHAT WE WROTE IN EACH FORM!

I spend about 60% of the time improving forms, I've read that a good program spend 80% of your resources in interface.

Jeffeson

[slashandburn]

Always Keep your program to the origonal specs.

[Jimlin41]

I usually start with an interface that works for me. This means command buttons and text boxes placed in strange places. Everything still has it's original captions. I only rename their Names for my convenience in coding. The form looks ugly and completely unorganized but it works for me.
Then I go about programming. I make sure that my code works first and then when I'm done, I make everything nice by aligning objects and typing their captions, etc.

Well, glad i'm not the only one with the pencil and paper idea.. LOL

JimLin and a few of you others, I see that you work with the interface first then work on the program. Do you just "wing it" so to speak and hope that you can make a decent program first? or do you draw your design out first? U didn't really specify this. I'm just curious. ;)

After I draw it up on paper, I then work on the backbone of the program BEFORE I work on the interface (Or Graphic). The reason? It's because, sometimes down the road while your making this project, you'll realize that the design or graphic you had in mind, may not work like you think. So what I do is make the hard code part of the code first (Not always, but most of the time I do this.. ) then I work around the code that has been made by putting in the graphics or "Interface". Make sense? I been doing it this way for years now and it's proven to work everytime. :)

Hope this helps...


------------------
John T. Mieske
Star Trek LCARS programmer

Knight Vision Enterprises
kvision@gate.net