Currently if the user tries to add a tag to his task, the task dropdown list is searched and filtered based on what the user types. It is simple and beautiful! Love it!
However (the catch) if the user enters a term word followed by a " " (space character) then the dropdown list finds and returns no tags at all! :/
Desired behavior: I would like the " " (space character) to be treated as an OR operator. For instance, if user is searching for a tag named "Broussard Marketing", then user could type "Bro Mark" alternatively user could type "Bro* Mar*" if the use of the asterisk is programatically required inorder to treat the space character as an OR expression.
In other words, the way the filter currently works is beautiful. I love the partial word matching for beginning of words! However, way spaces are treated by the filter kills it from being really powerful.
Hi Matthew,
Let me double check what you meant: let’s say you want to search for tasks with the tag “Broussard Marketing.” You would like to be able to enter #Broussard Marketing or#Bro Mar in the search field to see results?
Crystal, Sep 29, 2017
Hi Matthew, Have you thought about just typing eg., "Leg" instead of "Dpt Leg"? This way Quire can list out "Dpt; Legal".
Crystal, Oct 5, 2017
Thanks!
Matthew Billiodeaux, Oct 2, 2017
Crystal I too am looking for an "or" operator when filtering lists by Tag. Unless I have missed something the way things work today Quire allows searches for Tasks that have multiple Tags and will show only Tasks that have ALL of the selected Tags.
I know that I can use the +Tag to do this filtering
What I am looking for is a filter / operator that will allow me to select Tasks that have ANY of the selected tags (Tag1 OR Tag2 OR Tag3 OR Tag4 .......)
Kjennings, Aug 30, 2019
Hi Matthew, Ah I see. Nice idea! We shall think about it. 😃
Crystal, Oct 2, 2017
Desired behavior...
M Billiodeaux, Sep 30, 2017
Hello Crystal, that is almost it, except I would want this ability in the place where user adds tags. Check out the attached gif in this post to see the current behavior.
In the next post I will show kind of what the desired behavior is.
M Billiodeaux, Sep 30, 2017
Hello again Crystal, and thank you for the continued updates/responses.
Just for the record, this whole request is prefaced on the balancing of this feature with the cost of implementation.
Here is a little background info on the workings of our organization (I think it will be helpful for you to understand the use case). Our organization has 15 locations (and growing), over 35 providers (and growing), 4 specialties, and about 5 departments. Therefore we have at our most basic level more than 60 tag options not to mention typical subject tags like "receipt" "lease" "employee contract" "bill", etc. So, the tag list will grow beyond the basic 60. Perhaps this is not representative of the average quire user, but just sharing our use case.
So, in order to keep the tags organized, I set up categorical prefixes on each tag: 1) "Loc" for location 2) "Dpt" for department 3) "Pro" for affected providers 4) "Co" for affected affiliates (if any), and 5) "Sbj" for subject (ex lease/ emp contract / policy / receipt ...).
This system is REALLY useful because if I am on the phone with, say, an insurance company, because of a particularly denied claim, then I can quickly do a search for the name of that insurance company (ex Co BCBS and Dpt Billing and Sbj Claims) resurrect all claim issues that can be handled by a billing agent, and knock them all out at once. Also, these tags (Billing and Claims) help distinguish billing claims from claims that exist in the legal department (which would be found via Dpt Legal Sbj Claims). (On a side note, the reason the tags are not just "legal claims" vs "billing claims" is because that would either duplicate information or limit our ability to efficiently filter all tasks by department tag. For example why put "legal claim" and "legal department" when the same result can be had by better granularity of the tags: "Dpt Legal", "Sbj: Claim", this way, a person can also find ALL claims in the company, regardless of the department that owns it).
The reason for prefixing each tag with the attribute grouping is three fold. 1) it helps organize the mess! having over 60 tags would look ugly, and be a bit unwieldy to look at, 2) it insures that abbreviations are MUCH less likely to overlap, and 3) it allows a user to apply a tag by process of elimination if they do not know the exact tag to apply (ie memory jog by seeing all docs / locations / previously used vendors / departments, etc).
Now having said all of that, I have considered the option of not categorizing our tags. But I do suffer with a bit of OCD, and the jumbled mess distracts me. So, I am admitting that I may be putting too much importance on the benefits of this feature.
BUT, I also think your programmers might find this easy enough to implement, and useful enough that the pro's of implementing it outweigh the costs of doing so. ...
My $.02! Thanks again for your consistent responses!
M Billiodeaux, Oct 6, 2017