
Step #         : Reference #2
Step Title     : Whats a good interface?
File Name      : intrface.txt
Author         : Michael Preslar / E_Maus
Author Note    : Things to consider when making your program..
Example Source : none
Date           : September 30th, 1998
Length         : 7 pages

  ======================= Whats a good interface? ==========================
<editors note: This following section isnt necessary reading to learn
 Pascal. However, it does contain a few good points about a program's
 interface. A few programs are used as examples here. They are copyright
 of their respective owners.>

Thats a hard question to answer. No matter what I say, it depends on you, the
programmer, and the end-users. However, since this guide is BBS bound, it is
somewhat easy to "assume" a few things. Not to mention, there are a few
universal rules that could (not should) be followed.

1.) Change is good.. most of the time.
    I would think that everyone has played the door games Legend of the Red
    Dragon (LORD) and LORD2. The change in interface from LORD to LORD2 is
    very dramatic. LORD uses a "menued" interface (hit "F" to fight monsters,
    "I" for the inn, "B" for the bank, etc etc), while LORD2 has a "mapped"
    interface (the player moves a little 'man' around an ANSI map with his
    arrow keys). Change like that is good. Why? First some background
    information..

    As far as Im concerned, LORD is the best door game of all time. It was
    the first RPG door, got the most distribution, easy to play, the "plot"
    (wasnt really there.. just kill the dragon) was simple, used next to no
    system resources (simple game. none needed), etc etc. And apparently Im
    not the only person to think like this. A million other door authors used
    the same interface. Used it so much, in fact, it got very old, and good
    games werent played much since they were "LORD clones"

    LORD2, in my opinion, is the next best game. Although it actually has
    different plotlines (some not so simple.. I still havent cleared Barak's
    name), and it holds a LOT more power as a game engine, it didnt get as
    much distribution due to the skrinking BBS population (damn WWW). Since
    it has a lot of power behind it, it uses more system resources, etc etc.
    Now this interface is being copied, and the same thing is happening.
    Good games arent being played since theyre "clones".

    That kind of change in interface is good. It introduces something new
    into the world. When LORD2 came out, it was the hottest thing on the
    market. People everywhere wanted to see this new "map" game. Keep in
    mind that this wasnt the first use of "maps" in door games. I believe
    Arrowbridge holds that title.

    So when would change be bad? Take for example a sysop chaning BBS
    software. The users had gotten used to the old software. This new
    software, is exactly that: new. To the current users anyway. Ive changed
    BBS softwares 3 times in my 4 years as a sysop. Each time, I lost users.
    Id set the new software up before the switch, and even convert the user
    base if i could. But since the bbs had a new look and feel, well..

    When is no change good or bad? Take for example the LORD clones. Thats
    a good example of "no change" and bad. These could be good games, but
    since they have the same look and feel, they werent played much. Now,
    take for example a game using the menued interface but has a different
    look and feel. For instance, "Dawn of the Hunted". This game plays a lot
    like LORD in that you hit this key to do this, that key for that, but
    its set in the future, and has different inside options (no banks,
    when you fight an opposing player, you fight a hologram instead, etc).
    Meaning, it uses the same interface, but plays differently. Thats good.

2.) Easy to use, yet not lacking in power.
    Lets take a look at a utility meant for the WildCat! BBS software. I
    believe it was called PostMaster. It let the sysop import a text file
    into the WildCat! message base from the command line. This is a very
    powerful program in that you can set every message flag, do echo, normal
    or *.msg mail, set who its to and from, and other options from the
    command line. Thats good. However, since it cant use a configuration
    file, you have to know every parameter you wanted to use. Thats bad.

    If the program had both the ability to use a config file, and accept
    the command line, it wouldnt be listed here.

3.) Look at the pretty colors, mom!
    This is something else to consider. Again, lets use LORD and LORD2 for
    examples. LORD uses a simple color set: brown and green. LORD2 uses all
    the colors of the possible 16. The simple color set helps people to
    identify with each program. When using a larger color set, the colors
    should all be used in the same places. Generally, menued interfaces have
    simple sets, while more intricate interfaces like maps use more. Keep
    in mind, however, that not all colors show up on other people's screens
    as they do yours.

4.) How many submenus?
    If the program your working on isnt a door, and isnt designed for one
    specific purpose, its more than likely going to have a menued interface.
    Take into consideration the configuration utility for WildCat! bbs
    software (makewild.exe), and the "bbs mail to or from e-mail" utility
    TransX.  MakeWild lets the sysop set security levels, make new file and
    message areas, set hardware information, etc about the bbs. TransX lets
    the sysop export his bbs mail to internet e-mail, or import it vice versa.

    Although MakeWild is a powerful program, it has a max of 2 submenus under
    every menu option. This interface is very clean looking, and everything
    is right there under the sysop's fingertips. However, the sysop has to
    know what everything means.

    TransX itself is an awesome utility that lets sysops take advantage of
    the internet. The program txsetup.exe lets the sysop configure the
    program. Im not sure exactly what the max number of submenus is, but I
    believe its 5. This interface isnt necessarily clean, yet it divides
    everything up better. If the sysop doesnt quite know what an option does,
    he can look at the other options on the submenu and "guess". In the event
    the sysop has it setup and running, but wants to go back and change
    something, he has to know where it is, or he could be looking for it for
    awhile.

5.) No submenus?
    What if the program youre working on will only have one purpose? For
    instance, a program I made called CCi-List.exe. It took the nodelist
    for CyberCrime International (CCi) and made an output file that had
    each bbs's name, sysop, area code and area. Then it made another output
    file that had statistical information about the network based on the
    nodelist. The only people that have copies of the program are me and the
    CCi headguy, Mitch Waas. Mitch runs the program, and then puts the
    output files in his distribution archives.

    Configuration? None needed. Since the nodelist will always contain the
    same information, I hardcoded everything. The only thing thats not
    hardcoded is the input file. This is taken from the command line. That
    makes for very easy to use (just run the executable), yet doesnt cut any
    power from the program. The only thing I really had to worry about, as
    far as the interface is concerned, was what Mitch would see while the
    program was running.

    In an instance like this, Id suggest progress bars. Why? Well, if there
    werent any, and the program locked up, how would you know? Not to
    mention, progress bars dont add a lot to the overall executable size.
    Case in point: LordNet for LORD. When you ran the inbound.exe or
    outbound.exe programs, youd get a full screen of stuff, although only a
    few things changed. That adds a lot to the executable size, and isnt
    really needed.

6.) SVGA or text? mouse, keyboard, joystick, or Luke's light sabre?
    Finally.. when designing your program's interface, make sure not to
    over do it. For instance.. the DDCONFIG.exe program included with the
    DDPlus door driver kit. The programmer could include the program with
    his door, and itd make the door's configuration file for him. Nice thing.
    However, it runs on vga/svga type systems <maybe cga as well. not sure>
    and has mouse support. Why?! Granted it looks nice, and runs well, but
    for what purpose do you need such an interface to answer a few questions?

