first level selection of tagged objects - tag InfoBox about ghini.desktop

[tmyersdn]

Mario, I am assuming here that all tags are for important reasons, and I accept from @RoDuth previous comments that he sees tags as just a tool that works fine as it is. My guess is that Ross is used to a single user situation, and that tags are just there for him to look at when he has time, they are not part of data entry, they are just ephemeral flags to remind him of something. No one else looks at the tags, and the current system works fine. What I am suggesting below is a level of database work that Ross probably does not need or want.

What I am suggesting, is that in a multiuser system, tags may become a form of communication, I might make a tag and apply this to a number of items that I want be fixed:
eg
"new label": I want these 10 plants to get new plant labels in locations A, B & C
"prune": I want these 15 plants to be pruned in location B
"plant out": There are 20 accessions in the nursery ready to be planted in location A

This is why I am saying they would have a place on the summary table. So you can see when you log in if there is more tags for you to look at. In this case there would be 15 tags for plants and 20 tags for accessions and 45 tags for locations.

Even in a single user system, this would be a reminder that tags are active, and maybe should be looked at or removed.

[mfrasca]

it this is all, we can do it by stored queries, just adding a count to the button.
you add a %s in the label field and it will be substituted with the query count in the button label.

[tmyersdn]

yes, I think so, but would need to see how it looks and works, and of course to hear from @RoDuth

[mfrasca]

correction on my own statement. since tags are so much different than an object field, you do not select objects having a tag, you select a tag and it contains objects. it is a subtle but important difference.

there is no search involving tags other than as first level objects, as it would be for quantity (a property of plant):

NB please do notice the difference in status bar and object count.

so to offer the user an overview of how many objects are tagged by the different tags, I really need a new :tags page. if on the other hand I would follow my own previous suggestion, the object count in the stored query would always show 1 (one Tag being selected).

some comments on terms in what you wrote:

• "new label": I want these 10 plants to get new plant labels in locations A, B & C
• "prune": I want these 15 plants to be pruned in location B
• "plant out": There are 20 accessions in the nursery ready to be planted in location A

This is why I am saying they would have a place on the summary table. So you can see when you log in if there is more tags for you to look at. In this case there would be 15 tags for plants and 20 tags for accessions and 45 tags for locations.

you would have three tags, namely new label, prune, plant out, they would be tagging respectively 10 objects all of type Plant, 15 objects all of type Plant, 20 objects all of type Accession.
in our hypothetical new :tags overview window, you would not see any information about the tagged objects, only that there are as said per row x objects of type Y (or x objects of more than one type).
I could enhance the query language so —if you have an homogeneous tag— you could click on a row and get the tagged objects first level, not below the tag. (advantage of this is having the informative status bar filled in.)

plant where id in [1,2,3] is currently not supported, it's not difficult to implement, it is the way Tags work, it would not apply to tags tagging objects of more than one type.

[RoDuth]

All sounds fine to me, not sure I would use it, maybe in the future? As Tom says I don't have the same situation in terms of wanting to communicate to other database users.

Just one thought. Now that there are a few different views that we use and have different ways to get into, would it be good to have a button for each somewhere in the home screen? e.g. for :tags a button called "Tags", for :history a button for "History", same for :prefs... Just thinking out loud on this one. I can just see it where I open Ghini at the begining of the day and click History to see what has happened since I last looked (or Tags in Tom's situation)

[mfrasca]

just tried it out... you can add things like :prefs and :history in a stored query! 🍭

[RoDuth]

D'oh! Shouldn't think out loud 😄

I had already added those 2 as stored queries! One of the first I put in there. 😜

[mfrasca]

still reconsidering my own statements...

to offer the user an overview of how many objects are tagged by the different tags, I really need a new :tags page.

possibly not. if we enhance the SearchResults entry for tags, like we have done for most other objects, and we add a context menu entry.

the tag would inform how many objects it has tagged, and if they are all of the same class, you can select them first level, that is so that the status bar will be more informative. actually it can even offer as many context menu entries as the number of types tagged. like you have a tag tagging plants and species and you can open first level all plants or all species.

this is linked with the "previous page" command, where it would be nice if it the command would take you back to the previous result, but this is a different issue.

[mfrasca]

I think I will implement this by adding 'Tag' to the domains that can be searched.
as of now, you can get tags in the search view by searching by matching strings, since tag.name is included among the fields for the value list search strategy.
you cannot search the tags domain, neither implicitly with Tag like <whatever> nor explicitly with Tag where <whatever>.
if we provide the above, the software will be more uniform, and we will not need any extra command like the one of the subject of this issue.

[mfrasca]

the software can now:

• search the Tag domain (tag like %)
• test whether the value of a field is included in an explicit list (<domain> where <field> in <list>)

it still has no InfoBox for Tag objects. shall we just do that.
the infobox for tag x will show tag name and description, then a table, where the first column is a type name, the second is the amount of object of that type that are tagged with x. Cells in the second column can be clicked and you get, top level, the objects of that type, that are tagged with that tag.

[mfrasca]

combining the above, and adding the InfoBox for Tag objects:

this would happen clicking on the 2 cell (connected to Species objects).

[mfrasca]

I think this is just done and complete. if not please reopen and describe.