Introduction to " MyAddress & Contact Data ! "

Address and contact information are the backbone of any business - but also of importance for most individual computer users.

After going through dozens of address book applications, organizers, PIMs and contact managers we have not found a package on the market which really  met our requirements (some features we wanted were always missing). Apart from the often clumsy screen design in many applications we have found that they are of not much use on notebooks and smaller screens (or when set to a higher screen resolution). We have also found that often some very basic features were missing which we considered necessary.

We decided therefore to design an application for ourselves (and during the development we came to the conclusion that our efforts should also be made available to others). A basic requirement was that the application should be compatible and  fit together with all the other building blocks we are developing.

We have started with the structure of the address book file on paper and thought very hard about each data field to be defined and if it would really fulfill the purpose intended. We also thought about how the data could be used by other software (labeling software for example) and about the not so obvious implications when addressing people in a foreign language. And much more .....
 

We are involved for a long time in computing and electronic data processing and know exactly how we have managed office tasks in the past (before there was even a PC or a calculator - yes, we can use a "slide ruler"). This has helped us a lot to create something useful.

For example: in applications of this kind there is usually a field SALUTATION

In its simplest form there is just a tick to be made for "Mr", "Mrs" etc. But this doesn't consider any use of salutations in foreign languages (Monsieur, Herr, Madame etc.). This design issue alone would make it difficult to modify an address book application for use in a non-English speaking environment in a reasonable time.

We have therefore used a so-called "file drop" box which can contain an unlimited number of salutations in any language (there is of course a file behind it which can be easily maintained). This ensures language independance wherever in the world someone is using our application. We also want to mention that you can mix different languages in the address formats for label printing and mail-merge. Everyone will be addressed correctly.

[The efforts to modify our supporting applications for other language environments has also been minimized.]

A   SALUTATION  field alone however doesn't guarantee that we have always the correct data for further processing. We had to apply some further thoughts  ...

To make practical use of the data stored in our address book application when using other applications (word processor, label printing etc.)  - we have defined two additional fields containing:

-  the form of address in letters
-  the form of address on labels, envelopes

These are two different formats and we have found these two additional fields a big help esp. for international use of the data collated with our application.

Normally when you perform a mail-merge with a word processor you can define the following merge fields in your document:   SALUTATION   and   LASTNAME  -  like ...

Dear <SALUTATION> <LASTNAME>     =    Dear Mr Miller            etc.
                                                                           Sehr geehrter Herr Miller (in German)

If you print labels based on the same underlying data then you would have printed on your labels:

Attn. Mr Miller
z.H. Herrn Miller

If we have a look at the German version we see that there is an additonal 'n' after the normal salutation in German ('Herr' stands for 'Mr'). There are many such small differences in various languages - this has made it necessary to have two different formats for letters and labels:

Letter format:        Dear Mr Miller
                            Sehr geehrter Herr Miller

Label format:        Attn. Mr Miller                   or:   Attention Mr Miller
                            z.H. Herrn Miller                or:   zu Händen Herrn Miller

When a mail-merge is performed the correct salutation will always be applied:

Instead of using something like:

Dear <SALUTATION> <LASTNAME>

in your document you would use the field:

<SALUTAT_LETTER>

when printing labels - you would use the field:

<SALUTAT_LABEL>

This approach is unique.
 

Some related subjects:

Mailmerge - an introduction how to get it right the easy way
Label Printing - a practical approach
 

We consider address and contact data as a core "business object" with other data complementing this approach (client data, supplier data etc.).

We have designed this "building block"  in such a way that a "map" can be allocated to a record - but also a "graphic" (plan, drawing, photo or other image) for immediate viewing plus there is the possibility to allocate an unlimited number of objects [ graphics (images, plans, drawings), documents of all kind ( .txt, .doc, .html, .pdf files etc.), also any other (media) file we can think of.

 Just have a look at the series of screenshots !

This approach extends the possible use of this module into many areas which could not be covered before by simple address book applications :
 

Real Estate businesses  are a good example ....

You can set up categories for properties and allocate the relevant vendor data to them. A map about the property location, an image of the property + further information and more photos, documents of all kind can also be allocated. It also means that there is finally some order in your files which are otherwise distributed everywhere on a hard disk (but not correctly allocated to a property record).

For this niche market there will be complementing modules available dealing with more specific vendor data, prospective client data and the real estate object itself. What they all have in common is data about addresses and contacts.

This module (together with "MyNet - ANYWHERE !") is also an excellent opportunity to manage the numerous files to maintain a real estate agents web site; not to mention the controlling of follow-ups.
 

Some other examples:
 
Police and Emergency Services

can use our application on individual PCs (but also on a network). Apart from the basic data in textual format they can store maps, photos plus having all related documentation in access (scanned documents, reports, detailed plans for a building for example).

Similar to mail-merge and label printing the accurate management of addresses and contacts is very important in this field.

Our application is of course not a system dealing with police or emergency specific requirements. However: what counts for the individual police station / police officer is that  tools like ours are actually available (and at hand to store data and retrieve information about local incidents etc.).
 
[ We have written the text above long before the tragic terror attacks in the USA on September 11, 2001. ]

Companies occupying office buildings  usually hold a lot of information about their staff in paper files and also computer files "in-house". One idea came us recently: if landlords, building administrators and government agencies would hold in an external and/or in a remote location at least some basic details for each person working in an office building then the relatives could be contacted easier in cases of fire or worse ....

Furthermore: for EACH person an unlimited number of "additional" objects (documents, maps where their relatives live, office floor plan where the person usually works etc.) can be allocated to each record.

[ Our application runs on all systems which fulfill the minimum requirements to run Win95 ( 8MB RAM, better are of course 16 MB or 32 MB, 486 processor (66 MHZ). Let's forget for a moment about all this update/upgrade nonsense which we hear for at least ten years now ! ]

What really counts in this case is solid access to relevant information everyone can handle with ease.

If this idea finds the necessary interest - and not only in the USA - we would like to donate a substantial part of the net profit from sales of this software into a fund which could contribute to a childs future (for example a kid who has lost his parents during the tragic attacks on September 11).

We would also make the sales statistics and cumulated funds public on this web site. 
 

General Practioners (and physicians of all kind)

can make use of our application to maintain essential core data about their patients and allocate the PAPER FILES - or at least parts of it - (if scanned).
 

Lawyers and other practioners in the legal field

They can maintain their client data and allocate so fairly any document to these clients. For this niche market there will also be complementing modules available dealing with more specific client data and the cases itself.
 

Some applications we have found on the market have limitations as far as the use of a word processor, an e-mail client etc. are concerned. This is not the case with our application(s). Whatever the object is you can always allocate the right viewer/executable application directly to the object.

It means when you have a .pdf file allocated to a certain address it will automatically be opened with the ACROBAT Reader when you click on the button for the external viewer application (you allocate the right viewer application when you setup the object allocation - it's quite simple actually; see the screenshots below).

We also recommend to save ALL your documents not only in the specific wordprocessor format (like a .doc file in Word for Windows) - but also at least as a .txt file (plain ASCII text) and as an .rtf file (rich text format). The space these files occupy is only a fraction of a .doc file for example.

[ But keep inserted "graphics" files in mind (esp. with .rtf files - always check in such cases the file size). ]

If you save your documents as a .txt file within the folder structure we suggested during the installation process then you can also use a "search" utility available from our tools menu to go through all the files in a directory - see also our text: install.txt.

If you save them as a .rtf file then you can avoid many incompatibilities between different word processor packages - nearly all of them allow you to read and save in the .rtf (rich text) format.
 
Some related subjects:

Mailmerge - an introduction how to get it right the easy way
Label Printing - a practical approach
 

We concentrate on "data" and the "information" we can retrieve from it.

In our applications we store information (data) about objects (documents, images etc.) and their storage location for example. The application(s) to present and process all sorts of objects (drawings, video, sounds, docs, photos etc.) are of secondary nature.

[ You can setup these applications separately, they work fine with the data provided by us - but they are not an integrated part of our applications. ]

This is similar to the separation of data and the programming tasks in computing nowadays (data independency). It means that you can use whatever image viewer, e-mail client etc. you like. The version also doesn't matter. If you have for example hundreds of documents written with the WRITE word processor from the old Windows 3.1 then you have certainly kept a copy of this little program and we recommend to install it as a "viewer" application. This is much more effective than opening th file with a newer word processor and maybe losing some of the original formatting etc.

This is also the "practical" approach we are talking about.

We have designed this module as generic as possible - but left the possibility open that third-party developers can design specific modules using the already existing data structures provided by us.

The MAILINGLIST application is a good example. Download an evaluation copy and the FREEWARE version from our "Download Products" page.

The Address Book module works together with all our other supporting applications.
 
Some related subjects:

Mailmerge - an introduction how to get it right the easy way
Label Printing - a practical approach