Giter Club home page Giter Club logo

jspsych-redux-gui's Introduction

jsPsych-Redux-GUI

A browser-based interface for creating experiments with jsPsych http://builder.jspsych.org/

Install - npm install
Development Server - npm run dev
Production Build - npm run build

jspsych-redux-gui's People

Contributors

dswallach avatar gavinq1 avatar jodeleeuw avatar kristiyip avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jspsych-redux-gui's Issues

DIY deploy

Generate package with all necessary files. They upload to server.

UI component for media element select

We need a way for the user to be able to select an image, audio, or video file when appropriate.

This is challenging to do right now because parameters like stimulus in the single-stim plugin accept either strings or image files. (One solution could be to split this plugin into two, so that the plugin choice determined the parameter set).

But this can be tested first on the single-audio plugin or the video plugin which both have parameters that only accept media elements.

Play options for experiment

->Play in window within browser
->Make preview window 'fullscreen'(full screen of app)
->Play in new tab with no controls(what the subject will see)

UI component for arrays

Some plugins require arrays to be entered. For example, this is a trial definition for the survey-likert plugin:

var likert_trial = {
      type: 'survey-likert',
      questions: ["I like vegetables.", "I like fruit."],
      required: true,
      labels: [
        ["Strongly Disagree", "Disagree", "Neutral", "Agree", "Strongly Agree"],
        ["Strongly Disagree", "Disagree", "Neutral", "Agree", "Strongly Agree"]
      ]
  };

This is especially challenging as a UI component given the nested arrays for the labels parameter.

For the questions parameter, I think a multi-line textbox makes some sense as a simple UI component. We can treat each line as a separate entry in the array.

Perhaps this can be the general solution for arrays.

We may need to think about some of the survey plugins more carefully, and perhaps even design more custom components for them. Perhaps there is some kind of change we can make to the plugin.info method that enables this kind of customization.

Actions defined in app.jsx

Most of the actions are defined in the actions.jsx file and then imported from that file into where else they're needed. In order for this to work these actions need to take in the store as a parameter. Each action needs to access the store and the store is defined in app.jsx, from there it is passed as a prop to every component that needs to call an action. This works fine for most cases, however for the actions that are called when the store is initially rendered, if they are passed the store as a prop, the start recursing infinitely for reason I don't understand. My solution to this so far has been to redefine those actions in app.jsx, since they are defined in the same file as the store, they can access the store without it needing to be passed in as an argument.

UI component for keycode entry

Key requirements

  • Easy to indicate separate key values in the array (some clear delimiter to separate array items)
  • Validates entries as key codes
  • Copy / paste support if possible

This material component does a nice job with the first requirement, but I don't think copy and paste will work.

We could also just use a text field and allow users to input keyboard characters as a string, and then we just take each character and map it to the corresponding key. This doesn't work as well for ENTER, SPACEBAR, and other keys with no single character. One solution could be to wrap those keys in an expression, so the entry ABC{SPACE} would allow A, B, C, and SPACEBAR to be pressed. This is a little less intuitive in some ways, but could meet all three requirements.

I think we should have a checkbox next to whatever the component is to select ALLKEYS.

Expired tokens

I just ran into a situation where an AWS token expired during my session and I therefore couldn't save any of the work that I had done.

Can we provide a method for reauthenticating without losing work?

(At least, I think that's what happened based on the console logs.)

How to use this

Is this still working? I received this error.

ERROR in ./src/common/reducers/Experiment/editor.js
Module not found: Error: Can't resolve '../../../../library/jsPsych/jsPsych.js' in 'E:\桌面\jsPsych-Redux-GUI-master\src\common\reducers\Experiment'
 @ ./src/common/reducers/Experiment/editor.js 39:32-81
 @ ./src/common/backend/deploy/index.js
 @ ./src/common/components/PreviewWindow/index.js
 @ ./src/common/components/App.js
 @ ./src/common/containers/AppContainer.js
 @ ./src/client/index.js
 @ multi babel-polyfill webpack-hot-middleware/client ./src/client/index.js

Load GUI

Either by entering code, going to URL or by accessing account

How are experiments created through the GUI structured?

Hello there,

I'm working on an app, BrainWaves, that will make heavy use of jspsych in order to allow students to perform and design their own neuroscience experiments.

I'm trying right now to design a system for reading timelines in my app so that they can be displayed through a jspsych-react component. I don't want to reinvent the wheel, however, and I'd like my app to be compatible with the other tools people will be using to create jsPsych experiments such as the Redux GUI.

One source of inspiration is the Experiment Factory experiments. However, I find the design of those experiments very rigid and imperative. I would like to move to a design that's more flexible and allows users to easily modify timeline parameters without code.

Because I'm using the same technologies as this GUI (React + Redux), I'd love to see what data structures are used when saving user-created timelines. Is there an example of that? I wasn't able to find anything briefly poking through the source code and playing with the app itself

Restructuring of the store

-------- DONE SO FAR --------
Reducers are now split up into multiple files, all in the src/reducers/ directory. Each property of the state of the store (e.g. trialTable, trialOrder, openTrial, etc...) has it's own reducers file name (propertyname)Reducers.jsx. These files are indexed in webpack.config.js, and are all imported into src/reducers/index.jsx.

// Combine all the different reducers into the store
const rootReducer = combineReducers({
    trialTable,
    trialOrder,
    openTrial,
    timelineOpen,
    pastStates,
    futureStates,
    dragged,
    over
});
export default rootReducer;

This file contains the combined reducer for the store. When an action dispatches a reducer to the store, combineReducers handles passing that reducer along to each property that has a matching reducer. For example when 'ADD_TRIAL' is dispatched, the reducer matching that string is called on both the trialTable prop

case 'ADD_TRIAL':
        // New trial's name 
        var newName = 'Trial_' + Object.keys(state).length;
        // Make the new trial from the default template.
        var newTrial = Object.assign({}, Trial);
        // Delete is okay as these shallow copies are not yet part
        // of the state. 
        delete newTrial['name'];
        delete newTrial['id'];
        // Add the new properties
        newTrial['id'] = action.id;
        newTrial['name'] = newName;

        // Create the new trial table
        var newState = Object.assign({}, state);
        newState[index] = newTrial;

        return newState;

and the trialOrder prop

case 'ADD_TRIAL':
        var newState = [
            ...state,
            action.id
        ];
        return newState;

The reducer for each prop, modifies only that prop, and returns it as its new state. combineReducers then grabs the updated props, and returns the new state with the modified properties.

Since each reducer is responsible for changing only it's property it is import that any logic that is relevant to mutliple reducers (if else statements, determining what trials to remove, etc...) happens in the action that calls the reducer and not in the reducer itself. This will avoid doing the same work multiple times when multiple properties of the store have matching cases for a particular reducer. REMOVE_TRIAL is a good example of this.
-- actionRemoveTrial --

// Action calling for a trial to be removed from trialList
// Affects: trialTable, trialOrder
export const actionRemoveTrial = (store) => {
    var state = store.getState();

    // Call back predicate for use by filter
    const isSelected = (trialID) => {
        state.trialTable[trialID].selected;
    };
    // List of trials to be removed
    var removeList = Object.keys(state.trialTable);
    removeList = removeList.filter(isSelected);

    actionArchiveState(store);
    store.dispatch({
        type: 'REMOVE_TRIAL',
        index: state.selected,
        state: state,
        toRemove: removeList
    });
};

Note how the comments for the action describes which properties of the store are
affected by the reducer this action calls. There may be a better way to indicate this but
I think it's important to indicate it for every action defined so that a programmer looking
at an action will know immediately what properties are affected inside of having to search
through every reducer's file.

-------- STILL TO DO --------
Identify and fix the errors currently appearing by testing for each property.

Allow cloud deploy without OSF token

I think it would be valuable to allow for cloud deployment without requiring an OSF token. In this case, the data would simply not be saved anywhere. This is useful for early stage testing and sharing, before data collection is ready to begin.

Cloud deploy

->Connect to AWS cloud account of the user through OAuth (I think this is possible….) and deploy the experiment to their ec2 instance. Spin up whatever backend database is needed to support this.

->After process is complete, give user instructions for accessing experiment and data.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.