ROOTS-L Archives

Archiver > ROOTS > 1989-02 > 0602707510


From: Alf Christophersen 02 45 41 97 <>
Subject: Letter from soc.roots on Usenet Netnews
Date: Sun, 5 Feb 89 19:45:10 ECT


>> Relayers notice:
>> Following is a text being transfered from the Usenet NetNews list soc.roots
>> I am not responsible in any way for any information or text which is
>> displayed in the following text.
>>
>> If you want to comment the following entry, please DO SEND THE letter either
>> to the list (ROOTS-L) or to the author of the original message, displayed
>> below. In ANY CASE, DO NOT SEND ANY COMMENTS OR LETTERS DIRECTLY TO ME, as
>> I have not written the letter and do not know what to do with your comment
>> except sending it to the list (ROOTS-L) which might not be in your interest.
>> Alf Chr. (Mail relayer btw. soc.roots and ROOTS-L, not opposite direction)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Path: ndsuvm1!cunyvm!nyser!njin!rutgers!mailrus!bbn!apple!well!tswift
From: (Theodore John Swift)
Newsgroups: soc.roots
Subject: More thoughts on PAF for the Macintosh
Message-ID: <>
Date: 3 Feb 89 02:03:52 GMT
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Reply-To: (Theodore John Swift)
References: <> <>
Lines: 137

(Carol J. Botteron) wrote:

>There is an Apple version of the PAF software but apparently no way as
>yet to convert files between Apple and Mac or IBM...

Can the Apple version of PAF export GEDCOM-format files? This might be a
path, if a tedious one. The problem with having a feature (e.g., Import or
Export) on one machine is that users will want it instantly on all the
others :-). Then the only problem is disk formats, or use modems or null-
modem cables (if you're that close) to send the files directly. Hmmm...

Thank you for filling out the descriptions of features; there was no way to
describe it all fully in one review. Generally, these were things I left
out for the sake of brevity, but you discovered many I wasn't aware of.

* Can Find Individual's Ancestor by:
(1) By the assigned ID number if you know it; this is fastest.
(2) By name.
(3) By information. <-forgot about this one.

* a command that dissolves the family but leaves all information intact.

> > Individual Screen-

>It [FR] keeps track of all the words you enter, not making a distinction
>between names and places.

I'd like to clarify that: The "confirm new word" record feature doesn't make
a distinction, but FR does, in that the words are in very distinct fields.

>I have not found any way to delete a word from the [known word] list.
>Next version?

Yes, I agree: There should be a way of editing the known word list. I
guess the programmers assumed that confirming the spelling once would
weed out *all* mistakes. Not so, as you discover after some research :-).

> >NAME CHANGES
>I have been cheating on this: if there are alternate spellings of the
>surname, I list it in parentheses as the second or third given name.
>This at least gets it onto the printed chart so it is easier to remember.

Yeah, but it's a bit ineligant. And there's the possible problem if the
person has *lots* of names. You can also put notes in the Notes screen,
but...

>BTW, it is OK to use parentheses and question marks as part of words.

Yes, isn't that a nice touch? Software is gradually getting more
sophisticated.

>I'd like to...change the font to something better than that loathsome
>Geneva (which is Apple's fault, not LDS's.)

Hey, for the screen, Geneva is just fine! And look at us: we're complaining
about typographical subtleties here; *that's* something you couldn't do a
few years ago!
I think the folks at LDS chose to limit the choice of fonts so they could
predict how much space text strings would take on screen. I don't mind it
so much, but I do mind FR dropping names and places without *trying* to make
some accomodations; the user shouldn't see machine limitations.

>Actually you have to be more specific than that about the date --
>"88" is ambiguous in genealogy.

Ok, ok, ok. No need to lecture; I was just using it as an example, and my
problems in FR were while using full years: "1988".

>One of my wishes -- either in the next version of PAF or as a DA that
>could be used with any program -- is a date calculator that would
> (1) convert old style dates (year beginning in March, 11 days slow,
> etc.) to new style.
> (2) calculate a person's birthdate from "Died March 2, 1843, aged 87
> years, 6 months,18 days."

Yes! A great idea. But some subtleties need to be considered: To be very
general, such a DA should accept whether you're dealing with dates when Britain
and her colonies switched from Julian to Gregorian, or other countries, which
switched at other times: Russia switched over to the "New" style only after
the 1917 revolution, I think (no flames please), and the Russian Orthodox
Church is still using the Julian calendar. Heck, it should also do conversions
to and from the Jewish calendar. Some of these "global" settings could be
available in an Options menu item, for instance. Hmmm...

> >To merge two files or portions of files, you EXPORT one in GEDCOM format,
> >then IMPORT it into the other.

>...I'd been hoping there was a more elegant way. Acually it would be nice
>to be able to link the two files so I wouldn't have to make changes twice...

Yes, the idea of "cut", "copy", and "paste" could be extended in PAF. It's
probably not that easy from a programming standpoint. User friendly-
programmer vicious :-). Actually, from watching over the shoulder of a friend
writing a Mac application, it's more a matter of thinking terribly hard about
how the application should behave, then the coding isn't all that bad.

>When I tried it, 11 aug1988 got the "improper date" box, but
>11aug 1988 came out NOV 1988, which could be a problem. I hope that
>the next release won't be confused by missing spaces when the month is
>in the middle (just a matter of distinguishing a letter from a number).

Yes, this shouldn't be too hard to fix. It may be that the "date parser"
grabs the 11, then throws out everything that follows up to the space.
That explains how 11 1988 becomes NOV 1988.

>Here's a Wish List item: I have trouble remembering county names. I'd
>like to be able to enter a town, county, and state; then later if I entered
>that town, a blank space, and the state, it would find the county.
>Probably impractical, but nice.

OK, campers! Anyone know of an example that'll screw this up? We all know
about Paris TX, Moscow ID, Lebanon OR, etc. But are there any cases of a
state with more than one town with the same name? I've heard that there are
two Cedars in BC, but don't quote me on it. Any others?

> >RESEARCH DATA FILER

>I haven't tried this yet because I can't really figure out what I
>would do with it.

My basic reaction, too. But I can see how it *might* be terribly useful.

>There does not seem to be a way to transfer information from it to FR.

Same here, and if there's no way, it's a serious problem. As I preached
before, the user shouldn't have to enter the same data twice. I think the
fine designers at "LDS Software" should make some basic changes. (Is there
anyone out there on the net listening?). Suggestions: Combine the Data and
Document tracking into one file, (or maybe someone could explain the
rationale for keeping them separate?), and make the entry screen a screen
rather than a modal dialog, so that the user has access to other applications
if s/he is pasting data from another programs.
--
Ted Swift "Why is there a watermelon there?"
{hplabs,lll-crg/lcc, pacbell} "I'll explain later"
!well!tswift - from "Buckaroo Banzaii"

This thread: