Here's the problem: where should jAlbum pick up the values for the title and comment variables?
For probably 95% of users, that's easy - they enter their titles and comments within jAlbum, and that's the end of it. They don't enter things in metadata - in fact, they don't know what metadata are. So, the title should be picked up from the .info file for the image, and the comment from comments.properties. Just use what the user typed in.
But what about the other 5%? This is where jAlbum gets in trouble. It tries to guess where there might be title and comment material. It offers a few checkboxes, some of which are mislabeled (the checkbox labeled EXIF User actually grabs the field that is labeled EXIF Comment in the metadata list, for example). The comment source checkbox labeled xmp actually does more than deal with comments - it also triggers retrieval of title, keywords, flags, and ratings!
Then, just to make things more confusing, there's a combobox for Title source, with a couple of obsolete IPTC choices.
What a mess. It's time to stop trying to guess, and just let the user tell the core where to get its titles and comments.
There should be one panel called Title source. There should be perhaps half-a-dozen boxes in which the user can enter whatever metadata sources he wants. The first box should be pre-filled with the default: jAlbum title. The user can enter whatever he wants in the six boxes, even replacing the default if he chooses to. He can enter xmp.dc:title, or Iptc.By-line, or even Huffmann.Number of Tables. Let him choose whatever he pleases - the List metadata tool can show him the metadata labels that exist in his images.
Second panel, Comment source, first box prefilled with jAlbum comment. Again, he can enter anything he wants for the six boxes (or more likely, just enter one or two). He can enter Windows XP Comment, or xmp.dc:description, or even Nikon makernote.AF Type.
"Oh, but these metadata labels are so odd, and confusing!" So what? Anyone who's actually trying to use these fields will not be confused by any of this. He's got a built-in tool that will show him exactly what the field names are, which is a lot better than using inaccurate euphemisms for them, like JPEG (what field is that retrieving?).
After the basics are cleaned up, then think about offering a few more, maybe with only a couple of boxes to fill in, like sources for subject, keywords, ratings, and flags. But let the dust settle, first.
Given that I rename those various comment sources to something more meaningful, wouldn't you say it's better to have an editable list of button-style items to drag around than having to memorize different text strings? Another reason why I'm not that keen on allowing arbitrary text strings is that the data truly comes from different sources.
Given that I rename those various comment sources to something more meaningful....
You say that as if it's a good thing.
I look on my master list of available foods (list metadata), and determine that peanut butter is the one I want. Then I go to the grocery store (comment sources), and scan the shelves. There's a jar labeled legume paste. Hmmmm.... that's not what I'm looking for. But there's no peanut butter on the shelf.
...wouldn't you say it's better to have an editable list of button-style items to drag around than having to memorize different text strings?
Instead, we have to memorize the "translations" - what does this renamed item actually mean? Is there something in the listed metadata that matches this renamed field? I have to remember that the jAlbum core displays this metadata field as one thing in one place, but as something else in another place. If I have to go back to the wiki to look it up, that's a sign....
Another reason why I'm not that keen on allowing arbitrary text strings is that the data truly comes from different sources.
Not sure I follow you there. In my skins, at least the ones that support metadata display, I let users enter whatever strings they like. The standard, camera-provided EXIF fields are all available with a click, but beyond that, all they have to do is look at the metadata list, choose something, and enter it. The fact that they're coming from different sources doesn't really matter - they're all just a meta.get().
BTW, on the subject of having to memorize things....
Even though this was the subject of some discussion fairly recently, sitting here over my second cup of coffee, I can't tell you exactly what fields are going to be brought in by checking the xmp box under Comment sources. I would have to go look it up, or set up an elaborate test case.
"Well, surely the user will want x, y, and z." This is, once again, a case of software doing me a "favor" that I didn't ask for.
What about an alternative, for the ‘few’ using embedded metadata?
An option to export all of the metadata, for all images in a project, to an XML or CSV file. Then they can use Menu/File/Import/From database file to map whatever metadata they want to the appropriate XMP fields.
It would require a two step process, but for everybody else it would be less confusing. Too radical?
But it does touch on a radical suggestion I've made in another thread: support EXIF for camera-generated fields only (no comments, for example), and support xmp for everything else. Dump all of the other metadata fields - IPTC, Windows comments, etc., etc. Maybe provide a standalone utility application for copying the other stuff to xmp, with strong batch processing options. But within the jAlbum core, EXIF and xmp only.
If you do that, then you're in a situation in which you can rely on handy checkboxes or draggable lists in jAlbum itself.
What if I label these draggable "buttons" to less creative/translated names and instead call them names like Windows XP Comment, or xmp.dc:description ? Would't that be better than having the user memorize such text strings?
Where it gets complicated is trying to nail down the possibilities. Probably even worse for title than it is for comment - there are probably half-a-dozen IPTC candidates for that one, for example. I think it would still be a good idea to let the user enter at least one metadata identifier as the comment source, and one as the title source, to accommodate the various kinds of weirdness that are out there.
Not sure it's worth extending the flexibility to other things, like keywords. Even less clear when it comes to things like ratings. I'm not sure how one should handle those - perhaps just a single, user-enterable field for each?
What if I label these draggable "buttons" to less creative/translated names and instead call them names like Windows XP Comment, or xmp.dc:description ?
If you're going to do some better renaming, I'd suggest that the first choice in the comment sources be jAlbum comment and the first choice for title sources be jAlbum title. Users understand that they can enter a comment or title in jAlbum, and that jAlbum stores it somewhere. They may be only dimly aware that there's a comments.properties file or a .info file, and are even less aware that those are text files. The current jAlbum (Text file) seems to imply that they have to create a text file somewhere.
how many 'ordinary' amateur photographers using JA - do make an effort to put in specific fields (titles/descriptions) in meta data?. I do not think many at all (the automated stuff, like camera settings, gps, maybe copyright , yes) - but agree w JGromit verbal descriptive stuff think most input directly via JA.
wrt lightroom - well guess really many pro and enthusiast photographers uses it or similar high power tool. But how many 'ordinary' amateur photographers using JA, invest time /finances in such package? - again think not many.
I had at some point GIMP installed - but very rarely used it. Instead use JA simple tools out of the box (push light, contrast, etc, crop maybe) - if a little more like change of format/resample = done via IrfanView (installed anyway for external viewing photographs) - or maybe Corel photo paint if wanting to overlay stuff. Thing is for mr/mrs 'average' it has to be dead EASY to get the album out. Only rarely I find a specific use for a shot needing to nursed by a high power editing tool - or for that matter enter specific descriptive meta data (for my case actually has not happened yet ).
But jeez, at least get rid of the one option that keeps tripping up users. It happened again today. A user unchecked jAlbum (Text file) in the Comment sources box, and was then hopelessly puzzled about why his comments kept disappearing.
I can't think of any situation in which a user would not want jAlbum to use the comments he has manually entered. Why would anyone ever want to ignore the entered comments?
So, what to do? jAlbum should always look at comments.properties first. Period. It should not be possible to turn it off. If someone really, really doesn't want to use them, let him delete the file. The Comment sources box shouldn't have an entry for it at all - just use that list to start looking at metadata fields if there's no comment in comments.properties (i.e., if comment.trim() is an empty string).