Last week, I met with Emma and Presley to discuss some of the desired behavior and features of the Python library, as well as the general status of SurveyMan. In terms of the Python library, the linguists want it to eventually provide R integration.

After Monday’s meeting, I started working on a simple Python surface representation for creating survey objects.  My current approach is to design a general skeleton of what the user sees, and to deal with any issues/scaling when they become relevant. Emma and I discussed two options for how a user of the library could create surveys; they could write a script to statically create the survey using the Python library, or I could write a repl that the user would interact with to define the survey components. I will address the issue of creating the survey once I have the survey component objects implemented.

I first created a simple outline of the behavior and attributes of Survey, Question, and Option objects, based on the previous Python and Java implementations. I began a code skeleton based on this outline, which I recently pushed to my repository on GitHub. After pushing, I attempted to implement some of the behavior, which lead to my changing the skeleton a bit. I added a new class called idGenerator meant to generate unique ids for the components, but I’m not sure it’s the right way to go about generating ids; I’m trying to figure out how to make it a static/singleton class so that there is just one instance which keeps track of which ids it has already assigned to components. I will post an update and maybe push again once I figure this issue out and have more of the functions implemented.

UPDATE: I have the id generator working, and have most of the functions implemented. I’m currently creating simply question, option, and survey objects to test that everything works properly so far. Pushing the current version to my repo.

During my spring semester, I am pursuing an independent study under Emma Tosch and Emery Berger of the PLASMA group at UMass. I will be contributing to the SurveyMan project, an automated system for the posting and management of online surveys. My work will involve improving the interface for the creation of surveys. My main goal for the semester is to produce a Python library which will produce a JSON version of the survey, to be passed to the SurveyMan system runtime.

The current format for designing surveys via CSV is not very intuitive, at least not from reading the specification alone without additional background. When trying to create test surveys over the summer, I ran into several situations where quotations and commas in question text lead to formatting issues. I remember having difficulty achieving the proper formatting using Excel, although I can’t remember exactly what the problem was; it may have had to do with the line ending characters. Simply from looking at the CSV specification, it is unclear (at least to me) how to create blocks. If the user wants to create blocks for the question, do they enter the desired block number in the BLOCK column of the question row? I am not familiar with how to specify the values as regular expressions, as shown in the specification, so I’m not sure what the example statements are doing. In terms of branching, I’m not sure I understand what the input of “2-tuple of block identifiers” is referring to. Are these meant to be the two blocks that represent each branch of the survey split? The “true”, “false”, “yes”, “no” values referenced in the regex example don’t make sense to me either, as they are not tuples. Additionally, the nested blocks seem like they could get confusing quickly. Mainly, some aspects of the survey, such as block notation and branching, should be a result of compilation, since users (such as myself) may find it unclear how to specify them properly without further explanation.

My contributions will include writing Python objects for the survey object which will have a notion of state. For example, a question object should “know” which other questions are valid branches. Other contributions include implementing a way to visualize the survey control flow, writing unit tests, and eventually publishing the resulting Python library. I will post these updates to my git repository and post to this blog throughout the semester to document my progress and any issues I encounter. Out of this, I hope to become familiar with the process of creating and testing software, and to gain exposure to other languages such as Javascript. By the end of the semester I hope to become a more self-sufficient member of the team (hopefully I’ll be competent enough to make contributions to the project without being handheld because I don’t know how to do anything).