search

makebrainwaves / BrainWaves

An easy-to-use platform for EEG experimentation in the classroom
MIT License
60 stars 26 forks source link

overwrite appState for built-in experiments #99

Closed teonbrooks closed 4 years ago

teonbrooks commented 4 years ago

Currently, we look for the appState.json to load the experiment state in the app. for built-in experiments, we should overwrite the state and only use the the local appState for customize experiments. @Yury-Shevchenko, what are your thoughts?

jdpigeon commented 4 years ago

Could you describe the reason for not wanting to use the saved appState for custom experiments? The appState.json-based progress saving feature should work for any type of experiment as long as the state of the experiment can be described in the Redux store.

If we're not able to store labjs experiment state in Redux (it just has to be serializable), then there are workarounds, but keeping the entire app state in Redux would definitely be desirable from an architecture perspective.

teonbrooks commented 4 years ago

i was actually saying the opposite: we should use the appState only for custom experiments and not for the built-in ones. for example, the copytext for the template experiments has changed but if you haven't cleared your Workspace of the old appState, the screens are presented empty instead of with the default text. it's actually not that pressing of a change, may not even be worth more than having instructions that if you have an older version of the app, then clear the experiment workspace folder.

jdpigeon commented 4 years ago

Oh! Sorry, I must have misread. That makes a lot more sense.

Are you guys putting multiple experiments into the same workspace? IIRC (boy it's actually been a long time), each workspace is designed to host one individual experiment, which is why it's got that one app.json supporting a single experimen flow.

teonbrooks commented 4 years ago

yep, that is still the case. here's how the update experiment/workspace flow works:

as i was writing, one thing came to mind is that if we enforce that even a template experiment has to have a new unique experiment, this would solve all the problems, and it would be good practice for students to name their project. hmm, maybe that's actually the way to go. i think that is how the flow used to be, maybe?

sdikker commented 4 years ago

I’m all for forcing people in to conscious filenaming!

Suzanne Dikker +1-212-920-4348 Sent from mobile

On Nov 15, 2019, at 10:59 AM, Teon L Brooks notifications@github.com wrote:

yep, that is still the case. here's how the update experiment/workspace flow works:

we have four template experiments: visual search, faces/houses, stroop, multitasking. if you were to select the template experiment, it creates a workspace with the template name and everything is stored there. if you select to customize that template, you give it a name, and then everything is stored under that workspace. as i was writing, one thing came to mind is that if we enforce that even a template experiment has to have a new unique experiment, this would solve all the problems, and it would be good practice for students to name their project. hmm, maybe that's actually the way to go. i think that is how the flow used to be, maybe?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Yury-Shevchenko commented 4 years ago

Sorry for not responding before, was at a conference. My initial thought was that after we agree on the descriptions and parameters of template experiments, they will be fixed for future experiments. I am afraid, overwriting the state might confuse a user, if the user has worked with the experiment and suddenly finds out that it is changed. I like the idea of enforcing creation of a new unique experiment even for experiment templates. That would be great to hear your ideas of how the user interface should look like in this case. In the current moment, when I click on the experiment card on the main page, I already start the template experiment. If the user is enforced at this stage to give the name to the project, that would be strange to have a button "Customize" inside that asks again for a unique project name. Shall we then have two buttons on the experiment card on the main page, like "Customize" and "Run experiment"?

sdikker commented 4 years ago

Is kim seeing these interactions? We had definitely thought about this in our initial designs. I’ll go back to see.

Suzanne Dikker +1-212-920-4348 Sent from mobile

On Nov 20, 2019, at 6:17 AM, Yury-Shevchenko notifications@github.com wrote:

Sorry for not responding before, was at a conference. My initial thought was that after we agree on the descriptions and parameters of template experiments, they will be fixed for future experiments. I am afraid, overwriting the state might confuse a user, if the user has worked with the experiment and suddenly finds out that it is changed. I like the idea of enforcing creation of a new unique experiment even for experiment templates. That would be great to hear your ideas of how the user interface should look like in this case. In the current moment, when I click on the experiment card on the main page, I already start the template experiment. If the user is enforced at this stage to give the name to the project, that would be strange to have a button "Customize" inside that asks again for a unique project name. Shall we then have two buttons on the experiment card on the main page, like "Customize" and "Run experiment"?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

jdpigeon commented 4 years ago

I like the idea of enforcing creation of a new unique experiment even for experiment templates.

I like this idea too and think it vibes most correctly with the design we had a year ago. When creating a new experiment of any type, the user should be prompted with a text box to create a conscious filename

teonbrooks commented 4 years ago

we decided to: