Tap Forms 3.0 for family archive

[Thomas Bird]

I am writing to praise Tap Forms 3.0 highly, and to report a need for my use.

I am constructing a digital family archive, to be shared with family members on DVDs (for now). I am trying to follow consensus advice from archives’ and archivists’ websites; they have think in terms of 50 years. Following that advice as I understand it, my archive currently includes only uncompressed TIFFs for “single-page” items, (about 90%, so far) and PDF/A-1a files for “multi-page” items (about 10%). I do have a little audio and video, but I haven’t yet tried to work out the approach to those. The archive should be both platform-independent and application-independent. For my 50-year use case, simplicity appears to be high virtue.

The medium on which I copy the archive for users would include only:
(1) the TIFF and PDF files,
(2) some kind of overview and advice in a text file, and
(3) a flat file containing about 10 fields of who, when, where, what, annotations, and the file paths to the items, relative to the archive folder in which they reside.

For the user’s end, it seems that I should assume that there would be some compact, reasonably-priced, general-purpose database software, which would:
(1) with modest demands on skill and time, import the flat file records and make that file nicely, simply browsable/searchable. That’s the big one, but for user experience it’s also pretty important to:
(2) read the relative file path from the field in the flat file and, at least for the TIFFs, display enough of an image to appreciate it by itself and to decide whether to open the file, and
(3) at a click, open the file in the application assigned to it in the equivalent of Finder: at the moment, Preview and perhaps Adobe Reader for a fuller presentation of the accessibility features in the PDFs.

In that image (for a Mac), Tap Forms is a champion for item (1). It read my CSV file quickly and accurately, and displayed it nicely in the single-column format with the default layout. I changed field order a little, increased to 5 the number of fields in the single-column presentation, made and saved a few searches, some complex, and soon and easily had a quite satisfying, browsable result. If my user (great-grandchild?) were only going to browse the archive, s/he’d be nearly done, and happy. If she were going to start using the thing as her own archive, I could provide my pick lists in a text file; she would need only the barest cue to follow suit. It’s all Mac-elegant, jackrabbit quick, and highly organized and intuitive. I have looked at other databases and tried a few; none has been as easy and pleasing as Tap Forms.

So I am very happy, except for (2) and (3). Have I missed an option in Tap Forms? (I assume you would agree that for my use case I shouldn’t get into copies or aliases in Library folders.) If I have not missed an option, what are the prospects in your development plan? If none, is there something I could do to help you add this affordance to your development plan? Some way I could help, or make the project more attractive?

[Brendan]

Hi Thomas,

I’m glad you’re enjoying using Tap Forms for your Family Archive project.

It sounds like a File Attachment field would suit your needs for your external files. However, the way Tap Forms accesses them is by referencing the files from within its own sandboxed container. Which means, the following folder:

~/Library/Containers/com.tapforms.mac/Data/Documents/Share/Attachments

That’s your home folder’s Library folder by the way.

If your CSV file contains a reference to a file name and you’ve put the file in the above folder, then it should find it.

This will be for a single-file File Attachment field though.

Thanks!

Brendan

[Thomas Bird]

Brendan:

Thanks for your prompt rely. I messed about, found that my filenames needed to have “/Artifacts/” as their first part, imported the CSV, setting the field to single file attachment, copied the corresponding TIFF and PDF/A-1a files to user/Library/Data/Documents/Shared/Attachments, and it all hooked up and worked nicely.

Also explored photos: Included an “image” field in my CSV including only my filenames, imported the CSV, copied my TIFFS into user/Library/Data/Documents/Photos, and that all hooked up nicely, leaving me with questions, particularly about moving forward from here, adding more material to the archive:

When the photo control in Tap Forms brings in one of my TIFFs, it both renames the file and converts it to JPEG. So:

1. Does the renaming of files have any function other than to assure that each photo has a unique name? If I have used a systematic procedure to make sure that my TIFFs have unique names, e.g. “20130101tb002.tif” (date of intake plus my initials plus ordinal, easy in my scanner), do I lose any function, compared to Tap Forms’ naming?

2. I can’t let any application I use modify the TIFFs: uncompressed TIFF is an emphatically-recommended longevity strategy (for example see see James Kennedy’s book at http://archivehistory.jeksite.org/index.htm), and the TIFF metadata section is an option for preserving other information with the image. Because of the photo field’s nice display of large photo thumbnails, I’d a really happy camper if there could be a “use original” option in the photo field’s controls, that would bypass the re-naming and conversion (putting on me the obligation and problems of assuring unique file names). Any chance of that?

Tom

[Brendan]

Hi Thomas,

Yes, Tap Forms writes all photos as JPG files. This was most likely to work on iOS, so that’s why I chose JPG. Plus the file name is generated as a GUID (globally unique ID) to prevent collisions during sync.

I’ll consider modifying the Photo Size behaviour so it doesn’t convert to JPG. There is already an “Original” setting you can select, but that still writes the file out as a JPG, but it just maintains the dimensions of the original file.

Thanks,

Brendan

[Thomas Bird]

Thanks for your usual prompt response, and on the weekend at that. I should have guessed that I would WANT TF to give my files a GUID (never heard of that, but like the idea if I understand it). Sounds like a strategy to preserve connection between record and file through a lot of potential kinds of operations.

And I appreciate very much your considering a way around the conversion to JPG (maybe by a selling-point “archivists’ option”?). I’m thinking I’m not nearly the only person who has reason to want to conserve the original file.

For now, I can use the file attachments field, single file version, with its handy icon/button to open the file in the application assigned to it.

tb

[Brendan]

Yup, that would work (the File Attachment field type).

[Thomas Bird]

Brendan:

The attached screenshot shows that for my family history archive use the trade-off between the photo field and the file attachment field is fairly stark: The photo field’s large thumbnail effectively completes the presentation of the artifact. The full archival image is a click away. With the file attachment field, the presentation will be completed only after the image opens in its application. When I try to think like my intended user, the difference feels substantial.

So, I think I will work-around by downloading GUIDs and manually pasting them into the filename and the photo field–and hoping that you’ll be able to provide an option in the photo field to bypass the conversion to JPEGs.

Tom

p.s. I have been getting a lot of support for $35–thank you; hope my persistence is not too annoying. BTW–Searched for “history archive software.” There is a project offering free Windows software to small museums (http://www.musarch.com/), that I would try if I did or liked Windows. Found no parallel for Mac.

Attachments:

You must be logged in to view attached files.

[Author]

Posts