jhhughes256 / comp_app Goto Github PK

Issue Description

The current implementation of slider reactivity worked well when all sliders were visible. Now the reactivity of sliders makes the transition between different sliders jarring, as once one slider is moved and the user changes to another slider they now have a slider that is on a value they never chose.

Potential Solutions

To fix this it may be better to store user slider values in an object (a matrix?). By doing this we can remember what the user has chosen previously and don't change their input based on what's happening on the backend. This would have the side effect of the app remembering every change the user makes, which I think may be a good thing.

If this is implemented, reset buttons would be nice. One on a composition level to remove all changes, and one on a slider level, to return the value stored in the reactive object that dictates the slider value to zero.

Issue Description

It is currently difficult to interpret how compositions have changed from baseline.

Suggested Feature

Present a column graph that shows the base composition and the changes that you have proposed. Bonus points if it's animated.

Issue Description

The difference between the two reallocation methods (one-for-one and one-for-remaining) is currently too ambiguous.

Requested Changes

• Use tick box to swap between the two methods
• When selecting one-for-one only allow one box to be pressed
• When selecting one-for-remaining only allow one column of boxes to be pressed
• Fade out sliders etc. so that user understands what they are changing
• Add pop-ups, warnings, so that user understands what they are changing

Issue Description

With the current reallocation function 05_reallocation_function.R it is possible for a composition to become negative.

Example

Run runApp("apps/heatmap_compositions") and click the bottom left button of the grid. Slide sleep to 120. MVPA is now a negative composition.

Issue Description

Final app will require the ability for the user to select which outcomes they would like to observe (read: which model to run). This will then need to be presented in the output.

Suggested Feature

A drag and drop interface may be beneficial. Early work has been done finding UI functions that allow drag and drop. shinyjqui seems promising as seen in apps/shinyjqui_dragdrop_order. Output would be displayed in the order the user desired, likely using renderTable() . Main text displaying overall benefit would be done using renderPrint() along with some HTML/CSS to make it looks nice.