Fields are ALL the same size.

Pilgrims Patriots Pioneers

When adding a date or any number things, such as adding one to a Source, and the field is a long as a landing strip.

As the owner of a software company, I know how easily people are confused... especially by the size of a field.

If a small field is needed, such as for a date or for an ID, the field should be an appropriate size.

Please fix the fields to match the data they are to hold.

A standard, default size for all data fields is, in a word, unsatisfactory.

Gordon Collett

One of the greatest features of Family Tree is the tremendous efforts the programmers have put into allowing all researchers from all countries in an expanding number of languages to enter in to the database whatever they need to fully document their family history. Part of this is realizing that programmers in the past have done a pretty poor job of predicting what someone may need when they created data entry forms that were restricted in either size, allowable contents, or, worst of all, a list of standard values one was required to pick from.

For example, the original PAF for Mac allowed only a four part place name and each part was restricted to sixteen characters. For some parts of the world this was horribly insufficient.

The date and place fields as seen in the edit boxes are the same size but even their current length hides the fact that both accept probably as much information as anyone could ever possibly need. I'm not sure of the exact count, but this allows users to enter full, complete information about their relatives. There is no need to make the date field shorter than the place name and further obscure that it can hold much more information than the current editing field can show at one time:

You might say, "But no one would ever really need that much room." How do you know? I certainly don't know all date formats or all place name formats in all cultures through all of history.

Julia Szent-Györgyi

I suppose fields meant for only a PID could be made fairly short, since as far as I know, those strings are not translated into other scripts even if the interface language is changed, but for everything else, better too long than too short. And I can only think of two places where a PID is the only possible input: the "by ID" tabs on Find and its derivatives (such as your profile source box's Attach buttons), and Merge By ID. I don't think having an input field as wide as the popup really harms anything on either of those.