Blocks Language Front End - GSOC15
52 views
Skip to first unread message
Akhil Singh
Mar 8, 2015, 3:10:20 AM3/8/15
to plasma-u...@googlegroups.com
Hello ,
I'm Akhil , currently pursuing my B-tech in International Institute of Information and Technology - Hyderabad.
I've Previously worked with Yourevent.co in building their android app(using parse sdk) , with scribd leaf in developing their admin site(group project). I consider myself a good programmer. I've also worked on projects related to C, java, php, mysql, web2py framework. I've gone through the idea page and found designing front end for surveys very intresting to work on. I assume that my previous experience would add on the project. I've cloned the runner repository and am going through the starter task. Any help would be great.
I would really love to work with PLASMA at UMass in developing surveyman and contribute to opensource community
Thank You.
eto...@gmail.com
Mar 9, 2015, 1:20:32 PM3/9/15
to plasma-u...@googlegroups.com
Hi Akhil,
We're excited to hear about your interests and skills and look forward to your application! If you have additional questions, post them here or in the IRC channel.
Some additional information about the project:
The Blocks fontend has some flexibility in terms of what's deliverable. There are really two parts of the task: how the types (blocks) compose (which should be written entirely in JS and may require augmenting surveyman.js, either by modifying the source code in that repository, or bolting on some functionality post-hoc, if you are sufficiently comfortable in JS), and the rendering (which I'd like to see in react.js).
The surveyman.js repository has three main "modules": survey.js, display.js, and interpreter.js. survey.js implements a subset of the survey language, found in the Java package edu.umass.cs.surveyman.survey. It takes a json representation of the survey (produced by edu.umass.cs.surveyman.survey.Survey's jsonize instance method) and parses that into JS objects. The key difference between surveyman.js and what we'd like to see is that surveyman.js expects a complete program -- think of the json that's passed to surveyman.js as the statically checked and compiled version of the survey.
The blocks frontend will be a kind of IDE for constructing surveys. As such, it will need rules for finding errors incrementally. The three composable objects are Blocks, Questions, and Options. Blocks may contain other blocks (subject to certain restrictions) or questions. Questions may only contain Options. Questions are unique in the survey; options are not. Options may not contain anything.
A block's type may be represented by a 2-tuple of a boolean and an enum. The boolean indicates whether the block may float (i.e., have its position swapped with another block at its nested level) and the enum indicates its branching policy. The branching policy must obey certain rules w.r.t. that block's subblocks. For example, a parent block may not contain two child blocks that have the type (_, ONE). (This type indicates that we don't care if the child blocks are floating -- we just care that the branching policy enum is not ONE).
We don't want users to have to specify these types themselves. Instead, we would like to infer them as the user adds components to the survey. Consider the scenario: A user adds a block with no questions and no subblocks. If this were a final survey, it would be an error, so we associate an error with an informative error message (e.g., "Block contains no subblocks nor questions") and attach that information to the particular block in error.
Now let the user add a question to that block. The block will now take on the type NONE (we'll ignore the floating part of the type for now). The question will not have any options associated with it, and so it will be treated as an instructional question. Suppose we now add an option that branches to another block (assume the target block's existence for now). After connecting the branch question to the target block, the system will upgrade the source block's branch type to ONE. If we add another branch question, it should upgrade the block's branch type to ALL (and ensure that there is a mapping between questions' options). If another question is added that does not branch, the block should be marked as being in violation of its type.
Regarding the visual component of this project, I'd like to use visual cues to denote types and control flow. For example, I'd like to see Blocks, Questions, and Options each have different shapes. The different Block and Question types could have different colors. I'd like to see the visual presentation be separate from the underlying logic of the system. That is, we know that there are some number of objects (3, in this case), and each object has some number of types. Any time we compose two objects, we should take the state of the program as an argument and a list of rules to tell us what the result of that composition should be. Although the above description of how this would work using the Javascript objects could be tightly coupled with the visual presentation, ideally I'd like to see a more general solution for the visual presentation.
Best,
Emma
We're excited to hear about your interests and skills and look forward to your application! If you have additional questions, post them here or in the IRC channel.
Some additional information about the project:
The Blocks fontend has some flexibility in terms of what's deliverable. There are really two parts of the task: how the types (blocks) compose (which should be written entirely in JS and may require augmenting surveyman.js, either by modifying the source code in that repository, or bolting on some functionality post-hoc, if you are sufficiently comfortable in JS), and the rendering (which I'd like to see in react.js).
The surveyman.js repository has three main "modules": survey.js, display.js, and interpreter.js. survey.js implements a subset of the survey language, found in the Java package edu.umass.cs.surveyman.survey. It takes a json representation of the survey (produced by edu.umass.cs.surveyman.survey.Survey's jsonize instance method) and parses that into JS objects. The key difference between surveyman.js and what we'd like to see is that surveyman.js expects a complete program -- think of the json that's passed to surveyman.js as the statically checked and compiled version of the survey.
The blocks frontend will be a kind of IDE for constructing surveys. As such, it will need rules for finding errors incrementally. The three composable objects are Blocks, Questions, and Options. Blocks may contain other blocks (subject to certain restrictions) or questions. Questions may only contain Options. Questions are unique in the survey; options are not. Options may not contain anything.
A block's type may be represented by a 2-tuple of a boolean and an enum. The boolean indicates whether the block may float (i.e., have its position swapped with another block at its nested level) and the enum indicates its branching policy. The branching policy must obey certain rules w.r.t. that block's subblocks. For example, a parent block may not contain two child blocks that have the type (_, ONE). (This type indicates that we don't care if the child blocks are floating -- we just care that the branching policy enum is not ONE).
We don't want users to have to specify these types themselves. Instead, we would like to infer them as the user adds components to the survey. Consider the scenario: A user adds a block with no questions and no subblocks. If this were a final survey, it would be an error, so we associate an error with an informative error message (e.g., "Block contains no subblocks nor questions") and attach that information to the particular block in error.
Now let the user add a question to that block. The block will now take on the type NONE (we'll ignore the floating part of the type for now). The question will not have any options associated with it, and so it will be treated as an instructional question. Suppose we now add an option that branches to another block (assume the target block's existence for now). After connecting the branch question to the target block, the system will upgrade the source block's branch type to ONE. If we add another branch question, it should upgrade the block's branch type to ALL (and ensure that there is a mapping between questions' options). If another question is added that does not branch, the block should be marked as being in violation of its type.
Regarding the visual component of this project, I'd like to use visual cues to denote types and control flow. For example, I'd like to see Blocks, Questions, and Options each have different shapes. The different Block and Question types could have different colors. I'd like to see the visual presentation be separate from the underlying logic of the system. That is, we know that there are some number of objects (3, in this case), and each object has some number of types. Any time we compose two objects, we should take the state of the program as an argument and a list of rules to tell us what the result of that composition should be. Although the above description of how this would work using the Javascript objects could be tightly coupled with the visual presentation, ideally I'd like to see a more general solution for the visual presentation.
Best,
Emma
Prakhar Srivastav
Mar 18, 2015, 1:39:24 PM3/18/15
to plasma-u...@googlegroups.com
Hi Emma,
Thanks for the detailed reply. Can you tell us how are you expecting the drag and drop interface to be submitted? Does it have to be integrated into the existing library or do you want to see a standalone version build in React?
Thanks!
Emma Tosch
Mar 18, 2015, 4:48:16 PM3/18/15
to plasma-u...@googlegroups.com
The drag and drop interface can be submitted as a link to a gist. It *does not* have to be integrated into the existing library. A standalone version in React that refers to dummy versions (i.e, not even as detailed as mocks) of the surveyman.js objects as needed will be fine!
Prakhar Srivastav
Mar 19, 2015, 1:54:13 AM3/19/15
to plasma-u...@googlegroups.com
Thanks for the clarification, Emma!
On Sunday, 8 March 2015 10:10:20 UTC+3, Akhil Singh wrote:
Reply all
Reply to author
Forward
0 new messages