'Reset Key' and 'Recommended next step' buttons for Guide tags

[loarie]

Kew is interested in using Guide tags as keys and one of the things they've requested are tools for easily reseting the tags (e.g. turning off all filters) and for navigating the user to the 'Recommended next step'

The 'Recommended next step' is calculated based on the tag choice that would maximumly discriminate the remaining set of taxa. Proceeding through these tags using the recommended steps simulates navigating through a dichotomous key

I assume the logic for these would be implemented client side on Android?

[kueda]

I'd prefer "Reset filters" and maybe just automatically show the recommended next step instead of adding yet another button. What's the algorithm for determining the recommended next filter?

[stevenpbachman]

Yes, reset filters sounds fine, and OK to just go to recommended next step, but I think the user needs to have a way to 'pass' if they don't have enough info to answer the recommended next step question or/and revert back to the last step and pick a feature that they can answer.

There is some documentation from Lucid (key software) about how it works, see link below, page 7.
http://www.lucidcentral.com/Portals/1/help/key_server/Lucid%20Key%20Server%20Online%20Player%20Help%20Documentation.pdf

Basically, a 'next best' character/feature is one that if used, would cause the list of remaining entities/taxa to be halved. I'm trying to find out if this has been documented in more detail somewhere else...

[kueda]

You can "pass" by just scrolling down. I don't think there's any need for additional UI. My impression is that the intent is to make this a little more like a key, but not replicate Lucid's functionality. They do have their own apps for that.

[loarie]

Ken-ichi - so your solution would be for the tags would automatically sort to display in order of 'recommendedness'? If that were the case, I agree, the user could just scroll through from top to bottom

[kueda]

Yes, sorry if that wasn't clear, Scott. Regarding the "recommended next couplet" algorithm, Lucid's docs are vague but roughly state they prioritize traits that divides the remaining taxa in half, which sort of makes sense from a computer scientist's perspective, but I actually prefer keys that exit quickly for obvious traits, so I might prefer the opposite: prioritize traits that divide the remaining taxa as unequally as possible, i.e. reject the outliers quickly before getting to the thorny, similar taxa.

[loarie]

curious what @stevenpbachman thinks, but I agree that the choice of next step does seem to be pretty subjective. For me the main thing I can think an algorithm would do that would always be helpful is to show steps with at least some discriminating power. For example, if I chose color=red in the following example, I wouldn't want to see #wings since this can't discriminate the remaining choices A&B

[stevenpbachman]

I think that leads nicely on to the 'prune redundant' feature that the Lucid keys and others also have. It does exactly what you've just described, takes away any characters that won't help you discriminate. This could happen at the same time as each 'best' feature is selected. But, back to the 'recommended next' algorithm, could we actually have both? KenIchi's outliers or the half/half approach. User could toggle. Feedback I'm getting from regular key users here is that in general they want to get down to a small set of choices very quickly and then browse through remaining taxa to get the final ID.

[loarie]

the only problem with that is that Ken-ichi and I are trying to find a way that this UI could work without a button. For example, imagine you tap on color=red, then it reorders the remaining choices and scrolls you to the next one. That would be sweet, but it would mean going with an algorithm rather than adding buttons. I'm sure alot has been written about these algorithms by others so it would be useful to see what people recommend rather than come up with something that works from scratch

[stevenpbachman]

Ok, I'm with you on trying to avoid complicating the UI. think my preference would be the half/half algorithm on the next best character, combined with the removal of redundant characters. If the next best characters are ordered in terms of equal ratio of taxa to unequal ratio, then you could still apply Kenichi's approach, but you'd be scrolling to the bottom of the list all the time, not ideal. I'll keep digging around to see what other regular key users think about these options.

[loarie]

Here's the eMonocot code for the NextBest algorithm that Steve found https://github.com/RBGKew/eMonocot/blob/master/emonocot-static/src/main/js/jsKey/keys.js#L848
as implemented here http://e-monocot.org/key/4#keyStarted

[budowski]

This looks like it could be implemented client-side only (no need for server side), is that right?
Anyhow, I have a couple of questions:

1. In general, the two visual (UI-wise) things that change here, while the users selects/de-selects tags are: Ordering of tags, scrolling the list to the next property type. Is that right? Do we want to add in more visual effects? (e.g. highlighting the current property name - e.g. highlighting the line that contains "Color").

Let's say we have the following properties: no. of legs; color; size.
2. What happens if the user selects legs, color, size (in that order), but then de-selects legs? What will get re-ordered and where will scroll to?
3. What happens if there isn't enough room in the tag list when trying to scroll? For example, if the user selects legs, color and when the app automatically scrolls the view to the last property (size), that property won't appear right at the top of the list, but somewhere in the middle since there isn't too much footer space below it (imagine trying to scroll the last item of a list view such that it'll appear at the top).

[stevenpbachman]

Just wondering if the tag categories e.g. colour, size etc. can be minimised/maximised with a tap rather than having all tags visualised at once, this could save space. The sequence would then be 1) guide opens with all tag categories showing, and best discriminator category is at top, possibly highlighted as 'next best' 2) tap to open up tag options for that category and select one or more options, 3) tap category to close and that triggers then next 'nextbest' category to be highlighted. Would that work? I guess the user might check and uncheck the options in one tag category if they changed their mind, in which case it wouldn't move to the next best.

[joellebel]

Here are just a few UI recommendations based off @budowski's feedback:

• I also tried a "Next Best Feature" button in the first mock up to see what that looks like. A shorter phrase will allow more room for a "Clear" button with the word "Clear" in it as the icon may be confusing.
• Added checkboxes to items to make them appear more tappable
• The "Clear" and "Recommend..." buttons would have a fixed position so they are always viewable especially during long scrolls
• When the user taps "Recommend..." button the next step is scrolled into place and highlighted in green. Remains green until a checkbox from a different feature is selected or the clear button is tapped. The user could also turn off the green by tapping the question if we wanted.
• The checkboxes would just be the standard Android checkboxes
• Added a "QTY" header so it's clear what those numbers represent
• Made the quantities gray. Currently they are green and that seems like they should take you to a different place than merely highlighting the row. The checkboxes now indicate tappability.
• Added a "Filter" icon in the upper left
• Used a photo icon instead of an info icon to indicate the tappable photo because what will appear after tapping it is a photo. Many users opt not to tap an info link because it may involved a lot of reading. The photo icon is a little more explicit in that you will be viewing a photo, but I'm not completely opposed to the info icon.

[joellebel]

1. What happens if there isn't enough room in the tag list when trying to scroll? For example, if the user selects legs, color and when the app automatically scrolls the view to the last property (size), that property won't appear right at the top of the list, but somewhere in the middle since there isn't too much footer space below it (imagine trying to scroll the last item of a list view such that it'll appear at the top).

That's ok because the highlight will indicate the recommended question

[joellebel]

I am not opposed to expandable collapsing features, but wanted to propose something that would allow us to work within our current model, thus saving some time on dev and design. I also like the idea of not having to first tap on a feature and then selecting an item. Many folks may not understand the feature/question without seeing the options as well.

[budowski]

@joellebel - This looks good :-)
Just a couple of follow up questions:

1. So when pressing "next step", the auto-scroll might skip a question/category, right?
2. (this one is also a question for @loarie) Should the order of the values for the recommended category be changed as well? (e.g. show tag values with more results at the top)

[loarie]

@budowski - I think @joellebel's designs just use scrolling to navigate the sidebar, no reordering. (which means auto-scrolling might scroll past a question)

[budowski]

Awesome - another question - @joellebel - we should also account for the info icon in the design - when pressed it should show the representative photo (see original description of the issue by @loarie )

[loarie]

I think those are the little image icons she included on the leftmost mock above in between 'yes' and '3'. joelle thought those icons would be clearer than the (i)'s in my mock

[joellebel]

@loarie Yes, you are right. Please also see #48 for a description of the interaction.

1. So when pressing "next step", the auto-scroll might skip a question/category, right?

Yes.

[budowski]

Got it - didn't notice (my bad).
So should I start working on this or is there anything else that needs to be discussed?

[joellebel]

Just wondering if anyone has any further comments. If not, I will begin creating the visual assets for @budowski. Thanks.

[stevenpbachman]

looks good to me :)

[budowski]

OK, I'm working on the algorithm implementation now - please tell me what you think:

int min_count = current_taxa_results.count;
for (current_tag in all_tags) {
    // Only look for tags that are not already used in the filter
    if (current_tag is not in selected_tags) {
        // See how many taxa are returned from using the current filter (while adding the current tag as well). 
        var taxa_results = filter_taxa(selected_tags + current_tag);
        if (taxa_results.count < min_count) and (taxa_results.count > 0) {
            // Found a new tag filters out the most results - this is our current recommended tag
            min_count = taxa_results.count;
            next_recommended_tag = current_tag;
        }
    }
}

return next_recommended_tag;

[budowski]

Note that this a simpler algorithm and not the same algorithm as in eMonocot, since they rely on types of information we do not have at the moment (correct me if I'm wrong) - for example, whether or not a trait is quantitative or categorical.

[kueda]

If you have all the tags loaded you could probably test a predicate to see if it's quantitative or not by seeing if the first tag having that predicate has a value that's a number.

Could you even do something simpler, like pre-generate counts for how many times each predicate is used, and instead of filtering an array of taxa by whether or not each taxon has a tag using the predicate, just choose the next predicate with the highest count? That way you iterate over all taxa once instead of each time you determine the next tag.

[budowski]

@kueda - but if we use, there would be some cases in which the recommended next tag won't help out in filtering the taxa - for example (similar to @loarie's example):

Tags/Taxa   A        B        C         D
Color      Red     Red      Blue      Blue
# Legs     4        4         4        2
# Wings    3        2         1        --

Let's say we first choose color = red (we'll have taxa A+B remaining). According to the algorithm you suggested, we'll choose number of legs next (still remaining with A+B for results) - but that won't help us narrow down the result list (but choosing number of legs will).

What do you think?

[loarie]

Hi Yaron,

I agree that the eMonocot algorithm seems too (overly?) complex to be useful.

Looking at your algorithm, I'm confused on line

var taxa_results = filter_taxa(selected_tags + current_tag);

Is current_tag the predicate (e.g. 'Color' using the above example of 'Color:Red,Red,Blue,Blue') or is current_tag the value (e.g. one of 'Color:Red' or 'Color:Blue')? Because it seems it should be the predicate since thats what we're optimizing, but it only seems like it would be possible to calculate taxa_results.count if you were computing taxa_results from one particular value (e.g. 2 taxa for 'Color:Red' and 2 taxa for 'Color:Blue').

But I might just be confused/confusing things here...

Alternatively, I came up with this idea for an algorithm that seems to work:
(0) As in your algorithm, only look for tags (predicates) that are not already used in the filter
(1) Choose the predicate with the maximum mean with finite variance of the taxa counts grouped by value
(2) Of these predicates choose the predicate with the minimum variance of the taxa counts grouped by value

For example, using your Color/Legs/Wings example

Predicate	A	B	C	D
Color	Red	Red	Blue	Blue
No. Legs	4	4	4	2
No. Wings	3	2	1	nil

these stats would be as follows (i.e. there are 2 taxa with Color:red, 2 taxa with Color:blue and 0 taxa with no Color value so the mean of [2,2]=2 and the variance of [2,2]=0 etc...):

Predicate	taxa counts grouped by value	taxa counts with no value	mean	variance
Color	[2,2]	0	2	0
No. Legs	[3,1]	0	2	2
No. Wings	[1,1,1]	1	1	0

Using this algorithm both Color and Legs have the maximum mean of 2, but since the variance of color is lower (0<2), it would choose Color.

Say I chose Color:Red - next the stats would be like this:

Predicate	taxa counts grouped by value	taxa counts with no value	mean	variance
No. Legs	[2]	0	2	nil
No. Wings	[1,1]	0	1	0

It would choose No. Wings which has the maximum mean with finite variance

Or if I had chose Color:Blue - next the stats would be like this:

Predicate	taxa counts grouped by value	taxa counts with no value	mean	variance
No. Legs	[1,1]	0	1	0
No. Wings	[1]	1	1	nil

It would choose No. Legs which has the maximum mean with finance variance

Which would have the desired effect of navigating you through the key like so:

I think this works in all the cases I've explored. And it has the advantage of being very simple to calculate. Is there something I'm missing with this approach?

[budowski]

@loarie - Awesome! This looks great :-)
Just one question:
How did you get to a nil value for the variance? How do we use "taxa counts with no value" in the calculation of the variance/mean?

[loarie]

I got a nil when n=1 (where n is the number of values) because dividing by (n-1) = 0. But I guess it might be easier to just test if n>1 rather than if variance != nil
mean = sum_{i=1}^n(xi)/n
variance = sum_{i=1}^n(xi-mean)^2/(n-1)

I didn't use the "taxa counts with no value" in calculating mean and variance - sorry if including them in the table added confusion

so for example for [1,1,1] n=3
mean = sum( [1,1,1])/3 = 1
variance = sum([1,1,1]-1)^2/(3-1) = ((1-1)^2 + (1-1)^2 + (1-1)^2) / 2 = 0

and for [3,1] n=2
mean = sum( [3,1])/2 = 2
variance = sum([3,1]-2)^2/(2-1) = ((3-2)^2 + (1-2)^2) / 1 = 2

[budowski]

Awesome, got it :-)
Will implement this way.

[stevenpbachman]

Looks like a sweet solution. Just wondering:

• Does maximum mean always win, even if variance is high?
• What if you have matching mean and variance, it just randomly selects?
• One thing I was wondering, will it suggest the ‘next best’ when you first open up the tags/predicates?

Thanks, Steve

[budowski]

1. I think so - @loarie ?
2. Yes.
3. Currently it doesn't do so. What do you guys think?

[loarie]

1. It does in the above - can you think of an example @stevenpbachman where that doesn't make the 'right' decision?
2. I envisioned the sidebar button behaving as it does now, and only on the new 'recomended next step' button navigating you to a optimized predicate. But I don't have strong feelings

[stevenpbachman]

1. just tried with a few other examples and it seems stable
2. happy to leave it up to the user to initiate the 'next best'. I guess they may already have a character in mind or starting point e.g. family and will want to scroll to that. Which now makes me think, how will the characters/predicates be ordered?

[budowski]

Currently the character/predicates are ordered by the way they appear in the guide's XML file. But of course we can sort them alphabetically, for example.
What do you think?

[stevenpbachman]

Maybe this is a small piece of functionality missing from the guide builder? You can sort the species in the guide, but not the tag category (characters/predicates) order. I would say leave the app as is and let it pick up the order as per the XML file as you say.

[joellebel]

The first pass is looking really good. After playing around with it a bit, I came up with a few tweaks to help with usability.

Screen 1: Next Step Highlight Tweak

The next recommended filter would be clearer, if its header was the inat green and the options had an inat green tint of 10% opacity. This will really help distinguish it from other filters with selected options. See below mock up. In this mock up, the user has selected "no" for "Present in Noca", then tapped "Recommended Next Step" and was scrolled to "Capable of rolling up?" which is now the active filter that needs an option selected.

Note the header of "Present in Noca" is still dark green and should remain dark green as long as it has an option selected. This will help the user to recognize which option is associated with its corresponding filter header.

Screen 2: 2nd Filter selected

In this mock up the second filter has been selected. Note the header (Capable of rolling up remains dark green) If the user deselects "yes", the header should go back to gray.

Screen 3: Disabled Recommended Button

Whenever there is no next recommended step or the user has deselected filters in the middle of the next step process which make it impossible for there to be a next step, the "Recommended Next Step" button should be disabled. See below mock up of the disabled button.

@budowski feel free to use the standard Android disabled state for the button.

Other Styling Tweaks

• Please make the highlighted option inat green at 30% opacity. I think right now it's at like 25%. This will help distiguish it more
• Please make the quantity numbers in the right column #404040
• Lastly, can we align the checkboxes to the first line of a multi-lined option? See below...

Current:

Proposed:

Bugs

I think I found a bug which I can certainly make a separate issue for, I just thought I'd bring it up here. I noticed if the first recommended next step is the last filter the list over scrolls and places the header of it under the "Recommended Next..." button

[kueda]

@budowski, if you can address Joelle's issues in a day then I'd say go for it, but if it looks like longer than that let's table them for now. I think they're all good ideas, but also think what you've got currently meets the original requirements.

[budowski]

I think I can make those changes within a day or so - will work on it and send you guys a new version to review.

[budowski]

OK, I've implemented the changes suggested by @joellebel - added it as a beta release.
(please tell me what you think)

[joellebel]

@budowski thanks! Will do!

[kueda]

Currently experiencing a bug in which after I click recommended next step,
every time I scroll the tag list it automatically scrolls back to the
recommended next step, which means I can't select any other tags. Thus
seems to happen for all guides.
On Sep 9, 2015 6:32 PM, "budowski" notifications@github.com wrote:

Closed #47 #47
via 163af94
163af94
.

—
Reply to this email directly or view it on GitHub
#47 (comment)
.

[budowski]

Weird - I'll look into this and fix (placed in beta). @kueda - could you please re-check to make sure it's working properly for you? Thanks

[budowski]

OK, fixed the issue

[joellebel]

Just tested on Android 4.0 and all is working for me. Will test on lollipop tomorrow when my Nexus 5 comes back from Colorado. (I accidentally left it there) Great stuff!