Demo Improvements Round 2
rloganiv opened this issue · comments
-
The demo is nice for someone who is familiar with your method already, but it's very inaccessible for someone who doesn't and therefore doesn't serve as a very good education/promotion tool. I would recommend adding a few paragraphs of explanatory text in the style of an accessible blog post, explaining how to use the demo, what the method could be used for, and how it works at a very simplified high level.
-
I'm not sure I understand the need to have evaluation instances when using the manual input. I think the interactive demo is nice because it lets people see and play with the algorithm interactively, so having to come up with a set of evaluation points seems more cumbersome than helpful. If you do want to keep it, I'd change the free-form eval label fields to be dropdowns populated by the available labels. Also, I assume that "Train accuracy" should be "Evaluation accuracy?"
-
I recommend pre-populating the fields with a simple default example. This can go a long way in building the user's intuition of how the demo works.
-
The fact that labels have to be single tokens is unfortunate for our purposes. Maybe this is too ambitious, but maybe the error message could suggest a few possible synonyms from wordnet that are single tokens?
-
The yellow highlighting of the predicted score makes the text unreadable. I'd make the background a darker version of the color, and would use green rather than yellow.
-
Add a train button so that the training script doesn't run prematurely after adjusting a single parameter or example.
-
I'd put the training parameters above the template section. Right now when you open the demo, it seems like you have to read and understand the whole template section in order to use the demo, when in reality only a minority of advanced users will likely play with the template. Moving it below the training parameters might help mitigate that impression.
I added a train button earlier, however it did not play nicely with caching. Because streamlit processes each line of code sequentially, it appears that you cannot place a button before an interactive widget like our test prompt at the end.
New issues:
- Drop down doesn't work for manual input
- Cached model predictions disapper - move the current trigger stuff before training and pass as an argument into the function for live update. Output the trigger + predictions at the end and render using a seperate fct.