sidebar organization, flow chart

[xhdong-umd]

For the relationship of each tab, is my below understanding correct?

Import Data         -> visualization        -> model selection     --> home range -> overlap
                     --> filter outlier                            --> occurrence
                     --> time subsetting                           --> speed

                                            -> map (with home range will have more info)

The first line is the main flow, the 2nd/3rd are optional directions.

I adjusted the sidebar a little bit just by playing with css. The color is not optimal yet, but I think the indentation can serve some purpose. All the indented items need the parent item be finished first.

[xhdong-umd]

How about this? The green badge may not be needed. I adjusted the menu order a little bit, basically the root level are main steps, any subitems are optional and always need the parent item first.

I think we don't really need a flow chart.

[xhdong-umd]

As for color coding the advanced features, I reviewed the app and didn't find an obvious separate of "advanced features". There are some extra tabs in control box that may not be needed for beginner, but they are in non-default tabs already.

I think the app need learning anyway, it's not possible for a new user just start the app and go through it without any learning.

[chfleming]

I'm not sure about the indentation of the "advanced" features, because it makes them look like sub-steps of the main steps. Also, with the extra words on the green cue get things wordy.

I would do things more subtly, like

• Import Data
• Visualization
• Filter Outliers
• Time Subsetting
• Model selection
• Home Range
• Overlap
• Occurrence
• Speed & Distance
• Map

or maybe just by coloring the symbols before the words.

[xhdong-umd]

I agree with your choice, here are some style plus some color. I'm not sure about the color for optional items as there is no obvious hint on which color is optional. Making them gray will be too much.

It's not easy to modify them elegantly, as menuitem doesn't support any additional style parameter, I have to create item then modify them.

[chfleming]

Aesthetically, that looks nice.

I would desaturate the color of the "advanced" icons so that they pop out less than that of the primary features, but I agree that making them completely grey would be too much.

[xhdong-umd]

With color slightly adjusted

[jmcalabrese]

I think this is going in a good direction, but I think the designation of core vs optional steps is a bit arbitrary and the focus on home range estimation a bit rigid.

One idea would be to offer the user a choice of a couple of different common analysis goals as tick boxes, like "Home range estimation", "Home range overlap estimation", "Movement model selection", "Occurrence estimation", etc... This could be in a separate box on the Import page, one box down from the top (between App options and Local data import).

Ticking a particular analysis goal would color code the required steps in the side bar green, and the optional steps blue. Home range estimation could be the default (like you have above). You could also add a third color, say red, and use it highlight the steps that are neither required, nor optional (like speed/distance if your analysis goal is home range estimation) for the chosen analysis goal.

I think something like that would be both beginner friendly, and flexible enough to not be limiting.

[jmcalabrese]

It might also be a good idea to add a switch to turn the above-described "analysis guide" feature off for the more advanced user that already knows how to work with the app.

[xhdong-umd]

Showing colors dynamically depend on selection is possible but will be much more complex to implement. And I'm not sure coloring itself is enough for this purpose (which need a coding theme to be learned) -- for a special mode, we may as well just hide all irrelevant menu items all together...

I think users need to have some basic understanding for any task anyway. It will be a little bit too much to expect user to just open the app without any preparation and can click and get everything under guidance within app itself. We actually have way more documentation and help text in app than a regular user will consume, if users ever read them it should not be problem, if users don't read them then more efforts on "easy to use" are not really make much difference.

[NoonanM]

One option would be to have a very obvious text box on the front page that explains the workflow, and mentions that help buttons are available on every page if help is needed.

I've also noticed that a lot of the import data page is currently taken up by the table of ctmm datasets. We use those data a lot in our testing, but most users probably won't be interested in them. Maybe that table can be shifted lower down so that the initial thing users will see is a little bit less cluttered.

[xhdong-umd]

Yes we could place a help button on sidebar for this. And I can also try to minimize the ctmm data box by default.

[xhdong-umd]

I made the two movebank boxes to be only visible when user actually logged in movebank, thus the default 1st page is cleaner.

I can make the ctmm package internal data box to be collapsed by default, but not sure about this. @jmcalabrese @chfleming What do you think?

[chfleming]

I would put the "Import from ctmm package" after "Import from Movebank".

[xhdong-umd]

Also added a help button in sidebar

If we put import from ctmm after movebank, there could be total of 3 boxes when user are importing from movebank, and the last box was direct import movebank data and go to next page, so it will be a little bit strange if we put ctmm after them.

[xhdong-umd]

If you think import from ctmm can be minimized, we can simply collapse it by default.

[xhdong-umd]

I'm also thinking maybe I should use same color for upload/import from ctmm/import from movebank because they are alternatives.

[chfleming]

I would have "Import from Movebank" before "Import from ctmm" and both of those two collapsed. But I don't think I understand

there could be total of 3 boxes when user are importing from movebank, and the last box was direct import movebank data and go to next page

[xhdong-umd]

When user is selecting movebank studies and downloaded data, the last box can import it into app and go to next page directly.

If we put ctmm box after movebank, we have to insert it into some position between these 3 boxes, and I don't see an optimal position here (in the middle of movebank boxes will interrupt the flow, in the end will break the "direct import to next page" concept).

[jmcalabrese]

@xhdong-umd We can discuss the technical difficulty in implementing dynamic coloring of sidebar entries, but I still do not think the current static coloring scheme makes sense.

The "core steps" are going to be defined by the user's goals. For example, if the user only wants to look at their data on a map, which would be a perfectly legitimate use of the app, all they need are "import" and "map". If that is what they really want to do, then they should not be compelled to waste their time with model selection and home range analysis. As a further example, if the user's goal is "occurrence", then "home range" is an unnecessary step. I get that "home range" will probably be the most popular choice, but I think the visual guidance that we give needs to be more flexible than that.

I disagree with your argument that dynamic coloring of the sidebar is not enough, and that a special app mode would instead be necessary. The user will, of course, have to do a bit of reading and thinking before using the app, and should have an idea of what they want to accomplish with the app. The point of the "analysis guide" I mentioned above is to quickly orient the user based on their analysis goal. The visual analysis guide can and should be supplemented by a help entry that explains the workflow and how it can change with the analysis goals. I do not think that the guidance needs to be any more complicated than that.

Also, the total amount of documentation available is not the issue here. What matters is how quickly a new user, who is reasonably well prepared to use the app (i.e., they know what their goal is and have a rough idea of the steps involved), can feel comfortable and make progress with the app.

As for your concern about the user needing to learn a color scheme, that is true, but I don't think it is a dealbreaker. The user has to learn lots of new things upon opening the app the first time anyway. Furthermore, the fact that you've already implemented a static color scheme contradicts the argument that said color scheme will be too hard for the user to learn. It is already there, and I think it looks nice. The only issue is that it is too rigid and assumes too much about what the user wants to do.

In terms of implementation, I think there should be a box at or near the top of the import page called "Analysis guide". In that box should be the check boxes with the different analysis goals, as well as an "off" switch. A brief description in the box could inform the user to choose their analysis goal, and that the required steps to reach their goal will then be highlighted in green. This should be augmented by a dedicated help button called "Workflow overview", displayed prominently in that box, that provides a more detailed explanation of the color scheme and how it changes with different analysis goals. I noticed that something along these lines is in the new help button at the bottom of the sidebar, but I don't like that placement, and I think it needs to be labelled differently, hence the suggestion for a dedicated "Workflow overview" button.

Another implementation possibility would be to have a dedicated "Analysis guide" page that automatically opens upon first start up of the app, with the option to not show that page on subsequent start ups. However, I'm partial to just adding a box on the import page.

Upon further thought, I think the color scheme should be two colors, like it is now. I think adding a third color, like I had previously suggested, will probably make things harder to understand without adding much value. Also, I think the default setting for Analysis guide should be "off". This has a couple of advantages. First, the app will work the way it always has by default, so more experienced users won't be bothered/annoyed by the analysis guide. Second, we do not assume a priori that we know what the user wants to do. Third, upon making their choice, the user will see the coloring change dynamically, which I think will be pretty intuitive. I.e., if the base color is the blue you're currently using, then upon selection of an analysis goal, the required steps turn green. I think that is easy to understand, and should be easy to follow.

We can discuss further on the phone if you want to get into the details of implementation.

[xhdong-umd]

@jmcalabrese I agree with your points, implementing dynamic color is possible just need more efforts.

For implementation details

• let's call steps needed as "main steps", other steps as "optional steps"
• we style main steps with bold text and green icon, optional steps with italic text and blue icon
• We add a Analysis guide box below the app option box, above the import boxes or should we call it Analysis Workflow?
• Inside the box, we need an option to turn it off. I think we can just add a selection to be "All Analysis" which don't differentiate main/optional steps

I need more input about the actual options:

• all analysis: all steps same style as main
• visualization: just visualization and map?
• Home range estimation: model+home range + map?
• Home range overlap estimation: model + home range + overlap + map?
• Movement model selection: model?
• Occurrence estimation: model + occurrence? And speed? I'm not sure of all possible options here. Maybe we only list important ones, which are major ones you want to include?

[jmcalabrese]

@xhdong-umd I agree with your first three bullet points under "implementation details". As for how to turn the analysis guide off, I think the convention that the app follows for check boxes is "check to enable", so simply having no analysis goal selected (the default) as "off" would be consistent with that convention. Similarly, I would prefer all sidebar elements to following the optional step style when the guide is off.

As for the actual options, just get a couple of obvious ones like "plot raw data" (import, visualization, map), "home range" (import, visualization, models, home range, map), and "occurrence" (import, visualization, models, occurrence) in there for the first draft. Once the mechanics are working correctly, we can discuss how extensive the list should be.

[xhdong-umd]

@jmcalabrese I think the different options should not be shown as checkbox, because checkbox can be multiple selected. We probably want a radio button, then we need an option to turn it off, thus I was thinking "all analysis" and trying to make all steps as main style.

[xhdong-umd]

I build a basic mode list as follows. Master branch is updated. The help text hasn't been updated yet. I'll update it after all details are finalized.

[chfleming]

I wouldn't make the choices exclusive (check box rather than radio button), and I would have the default be visualization and home range.

[xhdong-umd]

If using checkbox, that means user can select multiple modes? Then we just take the union of them?

[chfleming]

Yes, and I would have the "All" button check every other button.

[xhdong-umd]

A check box that will check other check boxes? Then should unchecking it unchecking others?

I am not sure that would be a good design as this is not the normal behavior....

[chfleming]

I would have unchecking "All" not do anything. Alternatively, we could not have an "All" button. This only highlights analysis steps. It doesn't make them go away.

[xhdong-umd]

Previously I want to use radio button because I thought we cannot have multiple choices on analysis mode. Now I realized we can and that's valid scenario, then we should use checkbox.

With checkbox there is no need for "all" option. "all" option is only needed in radio button and actually conflict with checkbox concepts.

So we are back to Justin's original plan, any checkbox will highlight some steps, nothing checked means nothing highlighted. We should stress this is just a guide to highlight steps, we never turn anything on/off with this guide.

[xhdong-umd]

Master updated to checkbox without all, default to be all optional.

[xhdong-umd]

Cloud version is also updated.

[jmcalabrese]

@xhdong-umd I like the first pass at the analysis guide, thanks for implementing it!

In terms of filling out the options for the analysis guide, I suggest:

• Plot Raw Data (import, Viz, Map)
• Model Selection (Import, Viz, Models)
• Home Range (Import, Viz, Models, Home Range, Map)
• Home Range Overlap (as for Home Range + Overlap)
• Occurrence (Import, Viz, Models, Occurrence)
• Speed/Distance (Import, Viz, Models, Speed)

[jmcalabrese]

As for the text in the Analysis Guide box, I suggest: "Select analysis goal(s) to see required steps highlighted in the sidebar"

In terms of the text in the help popup in the analysis guide section, I suggest:

How to use the analysis guide:

• Each item in the sidebar is a step in the app's workflow.
• Selecting an analysis goal or goals will highlight the required workflow steps in boldface text with a green icon.
• Each highlighted step should be completed in a linear sequence, from the top of the sidebar to the bottom.
• The analysis guide is optional, and is intended to help the beginning user get used to how the app works. It does not enable or disable any analysis steps, but simply provides visual cues. More experienced users can skip the analysis guide altogether, and go straight to the workflow steps they wish to perform.

[jmcalabrese]

@xhdong-umd When you get the chance, could you please work in the changes I suggested in my 2 above-listed comments?

Please let me know when you've pushed those changes to master and shinyapps.io. I'd like to finalize the paper revisions this coming week. Thanks.

[xhdong-umd]

Sorry, somehow I missed the notifications from this issue thus I was updating other issue but didn't see them.

Done with the above and added help button to vignettes box per your suggestion. Master and cloud updated.

I have to add a new package to use different checkbox styles, as the shiny default one will not align them in 2nd row when wrapped. They are still not aligned per column, but I think this is the best we can get, unless we put them vertically in single column, which can take too much space.

[jmcalabrese]

@xhdong-umd Thanks for updating. I think the alignment with the checkboxes is fine for now, and I'm not worried about an additional dependency.

[jmcalabrese]

Just noticed the "speed/distance" checkbox in the analysis guide doesn't actually highlight the speed/distance entry in the sidebar, but it does highlight all of the prerequisite steps before then. All other analysis guide entries work as intended.

[xhdong-umd]

Sorry that was caused by a typo. Fixed.

[NoonanM]

I was just testing the app. For completeness, I think it would be worth having another checkbox for the outlier filtering and time subsetting pages called "Data processing".

[xhdong-umd]

Yes this is easy to add. @jmcalabrese @chfleming should I go ahead and add it?

[xhdong-umd]

Added it as first option. Or should I put it after plot raw data? or last?

[chfleming]

The order looks fine. I would refer to "Plot Raw Data" as "Plot locations".

[xhdong-umd]

Changed and updated master branch.

[xhdong-umd]

I forgot this need to include import as first step too. Fixed