I’ve started using Tropy and find it intuitive and graceful. As I import images into the program, I’m weighing the relative merits of lists vs tags for organizing data. While this is a common enough issue in any organizational program or system, are there particular benefits to one approach or the other within Tropy?
That’s a good question! I think it depends very much on your particular project and your personal preference, but there are few differences in the way tags and lists work and, more importantly, planned features that may affect what is or isn’t possible with either of the two.
In my view, the main differences, current and future, are:
- Lists have an implicit order: when you view a list you can select the ‘position column’ (the first one) to sort the view based on this implicit order; currently the order is determined by the order in which you added items to the list.
- In the future, you might be able to change the order (inside a list) by dragging items up or down while sort by position is active.
- In the future we may add nested lists; there are no plans to add hierarchy to tags.
- You can assign colors to tags; not to lists.
- At the moment both lists and tags operate on whole items. There are some plans to allow you to apply tags within an item (e.g., at the photo, selection, and note levels). Lists will likely stay constrained to items.
- Tags are sorted alphabetically in the sidebar; whereas you can order the lists arbitrarily by dragging them up or down.
- At the moment all tags are listed in the sidebar; we might add a different widget to improve the display if there are many tags (similar to Zotero’s tag selector perhaps).
- Lists have higher precedence when searching: this means that you can use tags to filter within a list.
- When searching you can select more than one tag at the same time; whereas you can select only a single list at a time.
2 Likes
inukshuk gave you some really good thoughts; I’d suggest that using both tags and lists in conjunction is where you’ll get the most benefit.
For example, in my own Tropy project, I use lists primarily for structural organization–I have a list for Chapter 1, Chapter 2, etc. I tend to use tags more for thematic or more granular organization. For example, I have a tag called “Denmark” that I apply to every item that either is about someone from Denmark or is created by someone from Denmark. If I click on my Chapter 1 list, I can then click on “Denmark” in my tags list and see all the items tagged “Denmark” in Chapter 1. (Inukhsuk noted this above.)
So, using the principles inukshuk outlined above, I’d suggest you think of tags and lists not in opposition to each other, but in harmony with each other.
Thanks to you both for the replies. I concur with you, Abby, that lists and tags can be complementary, with lists serving as a higher level organization and tags providing for further refinement or filtering. Inukshuk mentioned the potential for nesting lists and so I’ll echo what I’ve read elsewhere in the forums that this would be a welcome tool to have available to users.
Hi there! I’m wanting to pull up all photos that have a combination of tags.
eg. all photos that have BOTH “bookplate” and “marginalia” tags. How can I do this?
Click on one of the tags first to select that tag exclusively, then hold the control key (or the command key on macOS) and click on the other tag: this will select the second tag while keeping the first one active. You should then see all items which have both tags (if you’re in a list, you’d only see items in that list).
1 Like
Hi,
thank you very much for all this useful information.
I strongly support the idea of being able “to change the order (inside a list) by dragging items up or down while sort by position is active.” as I work with a large number of images indexed in my text file, it would be very useful to being able to represent the same structure / order in word and tropy. what i mean is not only the chapter structure, but also the order in which references to images occur in the text.
Another feature request related to this (but far more difficult to realize I imagine) would then be some tool / interface that directly links the text file to the tropy projet. so for instance, a direct link from the text passage where the image is referenced to the image / medatada entry in tropy, or – the other way round – copying the image (with metadata) in the text file would definitely improve the workflow when working with large text/image projects.
We’re working on an API to access Tropy projects, i.e., Tropy will start a server to make the API available locally, but you could also host such a server separately to make a project available over a network / the Internet. Given such an API, ‘linking’ into a Tropy project from outside should be possible. For example, I could envision a simple export plugin (or maybe even something built-in) that let’s you copy items as links. In your case you would probably need something more customizable: for example, when you copy an item you’d copy an HTML snippet including text, a link to the photo (on your local disk) and a link to the item in Tropy (using the local API). If you paste this into an HTML document (or similar) you would then be able to display the image and follow the link (i.e., open the item in Tropy) on your local computer.
Thank you for your answer. This sounds good. To plan my project, it would be good to know if there is an approximate time frame for the programming of these features? can you say from which version on 1) the option of changing list orders and 2) the API will be integrated in the software?
You can follow progress on 1) by subscribing to this issue on GitHub; it’s currently part of our 1.6 milestone, but it may get pushed back if we don’t get to it (I really hope we’ll be able to work on it, but it’s not among the targets of the current dev-cycle so it might get bumped by other issues).
The API is a major component of the current dev cycle; an initial version of the API should become available this fall (i.e., Tropy 1.6.x or 1.7.0) with more work on it planned next year.