home *** CD-ROM | disk | FTP | other *** search
/ Amiga MA Magazine 1998 #3 / amigamamagazinepolishissue1998.iso / bazy / addresser / addresser.future < prev    next >
Text File  |  1992-11-21  |  9KB  |  158 lines
  1. ******************************************************************************
  2.                             Addresser Future Plans
  3.  
  4. ******************************************************************************
  5.  
  6. Here's a few ideas I have for the next revision.  Unfortunately, most of
  7. these features will require that the next version of Addresser be AmigaDOS
  8. 2.0 specific (i.e. It won't work with AmigaDOS 1.3 or earlier).  If you have
  9. any other ideas, please let me know.  Note: This is not a list of what will
  10. be in the next revision of Addresser, but what may be.  If I can implement
  11. the feature using a reasonable amount of memory and be relatively fast, it'll
  12. be in the next version.
  13.  
  14. - Support of graphics printer modes, you'll be able to use all available
  15.   AmigaDOS fonts, in whatever size you select, in Bold, Italic, Underline,
  16.   and (possibly) outline.  Wherever you want them, in whatever supported
  17.   resolution.  There will also be more support for built in printer fonts.
  18.   Once I completely figure out how an AmigaDOS printer driver works,
  19.   Addresser will be able to fully utilize most (if not all) of your printer's
  20.   special features.
  21.  
  22. - I'm thinking about making the Notes: field a full notepad that the user
  23.   can "pop" up, this will let the user type in whatever he/she wants without
  24.   having to worry about the size of the notes field.  This will also allow
  25.   people to add information like birthdays, fax numbers, etc.  Weather or
  26.   not this feature gets implemented depends on how hard or easy it is to
  27.   implement, and how much overhead is added to Addresser.  Another idea
  28.   along the same line that I'm seriously considering is having two viewing
  29.   modes which the user will be able to switch between.  One viewing mode
  30.   will show only a few important fields (i.e. name, address, phone number).
  31.   And the second viewing mode will display all available entry fields.
  32.  
  33. - Anyone got a good "closest match" search algorithm.  It was suggested to
  34.   me by a user, and it sounds like a really good idea.  Imagine typing what
  35.   you think the person's name is, and even though the name is not in the
  36.   list, it'll find the closest match to what you typed in for the search.
  37.   (i.e. Kelley will also match up with Kelly).
  38.  
  39. - Improved sorting system allowing ordering on almost any field.  This will
  40.   allow you to order on telephone numbers, etc.  The letter keys will also
  41.   be able to search on a defined field.
  42.  
  43. - Improved marking/grouping system allowing you to manipulate full groups
  44.   without marking them first, group records containing a field with a certain
  45.   text string (similar to search & mark, but it would be search & group for
  46.   a specified group).  If I can implement it, I am also thinking of
  47.   conditional marking (i.e. mark if state is MI and not in group 1
  48.   or group 5).
  49.  
  50. - You asked for it, you'll get it.  Multiple Address Books!!!!  If I can
  51.   implement a newer file structure with minimal hassle, the next Addresser
  52.   revision will definitely be able to handle multiple address books.  And
  53.   since I will try to take full advantage of AmigaDOS's new features, you'll
  54.   even be able to "Drag and Drop" a new book into Addresser whenever you
  55.   want.  Unfortunately, since this means a new file structure, it'll also
  56.   mean you'll have to use AdVert (again) to convert the names list (again).
  57.   (One of the disadvantages of not having foresight when first developing
  58.   software).
  59.  
  60. - How about a true ASCII text merge feature?  That's right, you create a
  61.   straight ASCII text file using your favorite text editor.  Then pass
  62.   it through Addresser.  Voila, mail merging without having to go through
  63.   the hassle of running a word processor.
  64.  
  65. - Speaking of merging, since I've been getting a lot of requests to add
  66.   support to a lot of different word processors, I'm thinking of implementing
  67.   merging as an external function (i.e. merge filters for each word processor
  68.   are their own little files that are loaded in when they're needed).  This
  69.   will not only make for a smaller merge requestor, but will also make
  70.   Addresser a little smaller and will let you the user select which word
  71.   processor merge formats you want, and which ones you don't.  (What good is
  72.   being able to create a Word(im)Perfect merge file when you don't have
  73.   Word(im)Perfect?)
  74.  
  75. - I hope to be able to create an easier way of putting together an address
  76.   format (one which you don't have to type so much, and check to be sure
  77.   you're typing the correct field name.)  Most likely, this will be a
  78.   "Drag and drop" type approach (i.e. you set up the format with the mouse
  79.   by moving the field names around).  If anyone's got a better idea, I'm
  80.   wide open to suggestions.
  81.  
  82. - How about user defined output types?  (what the heck does that mean???)
  83.   Well, instead of having to deal with the standard printer output Addresser
  84.   gives you (i.e. Envelopes, mailing labels, phone list, etc.), how about
  85.   you the user being able to create your own output types (say, for instance,
  86.   different envelope sizes, different mailing label sizes, etc.).
  87.  
  88. - One of the little things that may make typing names in easier would be
  89.   automatic formatting of phone numbers and postal/zip codes (i.e. just type
  90.   in the numbers 17055551212 and the number would automatically become
  91.   (705)555-1212 after pressing return on the field.)  Placing a 1 at the
  92.   beginning of the number would flag Addresser to make it a long distance
  93.   call (although it won't show the leading 1 in the field.)  Postal/Zip
  94.   codes would pretty much work the same way (i.e. Zip +4 codes would be
  95.   detected, and a hyphen would be placed before the last 4 digits.  If a
  96.   Canadian postal code is detected, a space would automatically be inserted
  97.   before the fourth digit.)  Anyone know of any other postal/zip code
  98.   formats?
  99.  
  100. - In keeping with postal regulations, wouldn't it be interesting to be able
  101.   to generate a postal bar code?  If I can get my hands on the U.S. and
  102.   Canadian standards for postal bar codes, I just may implement it.  The
  103.   Canadian system is easy, all I have to do is get the spacing correct.  It's
  104.   the U.S. one that's a bit tough.  (Again, users in countries other than
  105.   Canada and the U.S., if you know of your country's system, let me know how
  106.   it works, and I may implement it.)
  107.  
  108. - Since the next revision of Addresser will be AmigaDOS 2.0 only, I hope to
  109.   implement 2.0 specific features like an AREXX port, public screen support,
  110.   and much more (once I figure out what support is needed and how I can
  111.   implement them).  There is a good possibility that the next revision of
  112.   Addresser will be a commodity with all the features that are inherent with
  113.   it (i.e. hotkey activation, etc.)
  114.  
  115. - The dialer will probably undergo an overhaul, allowing Addresser to
  116.   determine the status of the call by watching for modem status messages
  117.   (i.e. Busy, Voice, Ring, etc.).  I also plan on adding a timer/toll counter
  118.   to the dialer (I may even be able to determine an approximate toll rate
  119.   based on your area code and the area code you are calling plus or minus
  120.   a fudge factor, this is getting really ambitious).  I hope to also
  121.   implement calling of all or marked names also (i.e. dial a home number, if
  122.   it's busy, or there's no answer, move on to the next name.)
  123.  
  124. - I hope to add some new fields to the next revision of Addresser, some that
  125.   are high on the list are: Salutation, Company position, FAX Number (this
  126.   field will be extra useful if I can implement an AREXX port.  Hopefully,
  127.   selecting the FAX number in the dialer will run your FAX modem software,
  128.   and set the modem to send documents, this field could also work as a BBS
  129.   number using an AREXX compatible terminal program like TERM).
  130.  
  131. - Also high on the list is a user definable field area.  This would allow
  132.   you the user to set up whatever other fields you may want (without me
  133.   having to go through the experience of re-writing the data structures and
  134.   re-compiling addresser).
  135.  
  136. - I won't mention names, but I have heard of Addresser users who have placed
  137.   Addresser on a network.  Well, I don't exactly know how it works on one,
  138.   but I am interested in improving Addresser's network support.  Anyone have
  139.   information on how the Amiga network software handles file and/or record
  140.   locking?
  141.  
  142. Like I said, this is a list of new features that may or may not be added to
  143. the next release of Addresser.  If you have any other ideas, please let me
  144. know, I am wide open to suggestions.
  145.  
  146. Corporate Amiga Types:
  147.  
  148.   If you have a product that supports mail merge or any other function that
  149. Addresser may be able to make use of, please let me know, I want to support
  150. your product also.  If Addresser does not support your product, please
  151. contact me (my current address is listed below), and I will add merge file
  152. support for the next revision.
  153.  
  154. Jeff Kelly 4455-1 
  155. Heritage Ct. SW 
  156. Grandville, MI  49418-2634
  157.  
  158. (616)249-9552