Actions

Semester of Code 2014

From LimeSurvey Manual

Welcome

Welcome Semester of Code Student aspirants!

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. However, if you have your own idea for a project discuss your awesome idea with us in our forums, mailing list or at #limesurvey on irc.freenode.net. Then submit your proposal. Good Luck (:biggrin:)

Project ideas

Refactor all question types to a modular OOP format

If you look at the LimeSurvey source code (yii branch) you will notice that the code for the question types is strewn across the application.

The goal of this task is to rewrite all question types to be objects, primarily inherited from one or more base question objects. A question type should have methods for display (several types of display like front ent/printable survey), response saving, configuration, statistics, etc.

Skills

  • Extensive knowledge of PHP & Yii framework
  • Very good kownledge of LimeSurvey inner workings
  • Very good OOP knowledge

Difficulty

  • Hard

Probable Mentors Sam Mousa (sammousa)

User Interface Improvements and Backend Tidy Ups

Help improve LimeSurvey's usability and flexibility through a range of small tasks such as:

  • develop improved 'bulk' question handling UI
  • Tidy up input values on public surveys by moving required values from html inputs to javascript variables

The idea is to provide ways of updating and modifying multiple questions, or multiple groups in one go. Often in a survey a user will need to make parallel changes to 5 or 6 questions all at once across a range of different groups. Being able to select various elements of questions, and then select a range of questions to edit would dramatically improve LimeSurvey's usability from the administrators perspective.

Skills

PHP, SQL, Yii, Authentication protocols (openID, CAS, LDAP-bind, ...)

Difficulty

Medium

Probable Mentors

Jason Cleeland (jcleeland)

Custom Report Generation

The task is to make a module which will generate custom reports. Module should be able to do these things(at least) :-

  • Creating various types of reports i.e. using tables, pie charts, graphs and bar-charts to name few.
  • The resulting charts and other illustrations should be easy to read and understand, and should include the ability to export into standard office suites.
  • Reports can be general or survey specific.
    • General in the sense that it should show basic findings of a general survey graphically like number of users completing the survey, average time taken to complete the survey, average number of correct responses etc.
    • Survey specific results should also be addressed properly e.g. how many users choose first option as there answer of a particular question, how many users didn't answer a specific question etc.

Skills

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter, jQuery. Strong mathematical background will help!

Difficulty

Moderate

Probable mentors

Carsten Schmitz (c_schmitz)

Jason Cleeland (jcleeland)

Diogo Gonçalves (dionet)

Enhance ExpressionScript

Starting with LimeSurvey 1.92, all of the front-end (survey-taking) processing is now managed using ExpressionScript (EM). EM implements a safe subset of PHP syntax so that authors can write complex equations. It is integrated into LimeSuvey to control navigation (branching via relevance), validation, and tailoring/piping of content. Although it is quite powerful, users are already asking for enhancements.

  1. Add a GUI for ExpressionScript
    • Background: LimeSurvey has a nice GUI for building conditions, but it does not support complex equations such as those available within EM. EM does have robust syntax highlighting after an equation is saved, which makes it easy to fix any syntax errors. Hoever, users would like a GUI to ease authoring of equations.
    • Strategy - use CodeMirror - see here
      • Create CodeMirror syntax file to do appropriate syntax highlighting (use C as base language), ensuring that CodeMirror knows the set of valid operators
      • Use CodeMirror API to let it know the names of registered function and variable names
      • Utilize auto-complete, ideally letting users see and choose among the availalbe function syntaxes (e.g. when a function can take several paameters).
      • Auto-completion of variable names should show the question and question type to make it easier for users to pick the correct variable.
  1. Support subquestion-level Relevance
    • Background: EM already supports user-entered relevance equations at the group and question levels. It also generates subquestion-level relevance for features like array_filter. Users would like to be able ot add additional relevance criteria at the subquestion level.
    • Strategy:
      • Add a relevance column to the display of subquestions, and ensure entered relevance is saved the to database (the data model is already OK)
      • Refactor createFieldMap() (or its successor) to read subquestion-level relevance into the run-time data structures so that passed to EM
      • Enhance EM's subquestion-level data structures to hold subquestion-level releavance
      • Update EM's _ValidateQuestion() and JavaScript generation functions to AND any manually-entered subquestion-level relevance equations with that auto-generated for array_filter and array_filter_exclude
      • Update ShowSurveyLogicFile() to show subquestion-level relevance equations ***Rigorously unit and regresssion test these changes.
  1. Add Sub-question-level Validation
    • Background: The question-level validation supports regular-expression-based validation of each subquestion. Users would like to have subquestion-level validation to implement things like a question for collecting user contact information, where there are different validation criteria for address parts (e.g. city, state, postal code) and phone numbers.
    • Strategy: Similar to subquestion-level relevance
      • Add data entry fields for regular expression validation at the subquestion level, and ensure saved to database (which already has a preg field at the subquestion level)
      • Ensure EM gets access to the new preg values (via upgrade to createFieldMap)
      • Upgrade EM _ValidateQuesation() and function for generation of validation equations to include these new critiera. EM already supports validation at the subquestion level (and changes the CSS style to show fields that fail this validation)
      • Upgrade ShowSurveyLogicFile() to show subquestion-level validation rules
      • Rigorously unit and regresssion test these changes.
  1. Add Sub-question-level mandatory criteria
    • Background: Many users have asked, via the forums, for ways to make parts of a multi-part questions mandatory, but make other parts optional. LimeSurvey already provides many options, such as minimum and maxium numbers of answers; but users have asked for more fine-grained control, and currently can only achieve that via custom JavaScript.
    • Strategy: Similar to subquestion-level relevance
      • Add checkbox to indicate mandatory status at the subquestion level
  1. Add native support for input-masks at the question and subquestion level
    • Background: One of the commonly used work-arounds deals with input masks, such as the jQuery meimomask plugin.
    • Strategy:
      • Add mask attribute at question and subquestion level
      • Have EM generate needed JavaScript code to create and manage those masks
  1. Add EM reporting functions (tables)
    • Background: There is commonly request for enhancemnt of the print answers table at the end of the survey. Some users want to generate custom reports mid-survey.
    • Strategy:
      • Implement showAllResponsesExcept(attributeList,attributeTitleList,questionList) function. questionList = list of question identifiers; attributeList = pipe-delimited list of attributes (like question#, title, text, type - so you can decide what to show); attributeTitleList = pipe-delimited list of table headers, so can internationalize the report.
      • Implement showTheseResponses(attributeList,attributeTitleList,questionList) function. questionList = list of question identifiers; attributeList = pipe-delimited list of attributes (like question#, title, text, type - so you can decide what to show); attributeTitleList = pipe-delimited list of table headers, so can internationalize the report.
  1. Add better EM support for operations on array type questions
    • Background: Many of the EM validation rules are effectively statements like count the number of empty subquestions, or sum the values of the subquestions. EM generates these functions itself, so there is no burden on the user, even if there ar dozens of sub-quetions. However, manual editing of these questions is cumbersom. Users could benefit from special variables to access all of the elements of a question so that they could write functions like (sum(this) == 10)) and have it be expanded to (sum(q1_1, q1_2, ..., q1_N) == 10). Note, there is already a "this" variable, but it does not apply to subquestions.
    • Strategy:
      • Extend EM so that "this" variable gets expanded into a comma separate list of subquestion references if there are subquestions. Have this expansion carry the suffix, so this.valueNAOK would become q_1.valueNAOK, q_2.valueNAOK, ..., q_N.valueNAOK.
      • This macro expansion should occur in group.php (e.g. in the process of generating JavaScript), rather than having this variable be resolved at run-time within JavaScript.
      • Provide similar array-expansion macros for all variables (not just "this") - such as qcode_vars.*. This would also functions like sum(qcode_vars.NAOK), count(qcode_vars.NAOK), implode(' ', qcode_vars.valueNAOK)
      • For questions with comments, create macros like qcode_vars_nc and qcode_vars_oc for no-comments and only-comments
      • For arrays that might need row or column-level processing, create aliases like qcode_rowname_vars and qcode_colname_vars so can expand each. This would let us replace the current system for generating row and column sums with equations like sum(qcode_rowname_vars.NAOK) and be sure that the sums will honor array_filter and array_filter_exclude.
  1. Add EM functions to validate data entry against value sets managed by Enterprise Vocabulary Systems
    • Background: Healthcare and biological sciences increasing use large controlled vocabularies, terminologies, or ontologies. Data entry systems for such domains require validation against those vocabularies. Large open-source projects, like LexEVS and Apelon DTS provide open APIs to access that content. Such tools let one validate diagnostic codes, and even do incremental search into those vocabularies as one types. The main open projects are standardizing on the CTS-2 (Clinical Terminology Services-2) specification.
    • Strategy:
      • Create EM-compatible PHP and JavaScript functions to access CTS-2 compliant EVS systems
      • Should include question and subquestion-level validation rules to validate the final entry. Currently, thre are em_validation_q and em_validation_sq advanced quation attributes for validating questions and subquestions based upon calls to external functions. It may be desirable to support custom subquestion-level validation to validate each subquestion against different value sets. If so, can follow the model of adding subquestion-level validation and relevance. Alternatively, may be desirable to add subquestion-level advanced question options (if LimeSurvey community feels that there may be enough such extensions that such customization should be stored in a general attribute table rather than making the questions table wider).
      • Should also include ability to do incremetal searches into the value sets

Skills

PHP, SQL, PHP Debugging (e.g. xdebug), Yii, LimeSurvey's ExpressionScript and code-base in general

Difficulty

Medium to Hard

Probable Mentors

Thomas White (TMSWhite)

Optimize LimeSurvey for Long Surveys (and better performance and maintenance in general)

Although LimeSurvey is excellent for short and mid-length surveys, it is not optimized for surveys with hundreds or thousands of questions - such as those used by epidemiologists or in clinical trials. This project would tackle each of those main limitations. Those sub-tasks, and the development strategy include:

  1. Support for more than 1000 database columns
    • Background: LS creates a horizontal table for survey data collection, and such tables often are limited to at most 1000 columns
    • Strategies:
      • Remove unneeded columns from horizontal table (e.g. type 'X')
      • Conditionally remove unneeded equation columns (e.g. let users specify a prefix for variable names that should not be stored)
      • Add option for Entity Attribute Value data model for data collection (which can support unlimited number of columns. See details here.
  1. Memory and Code Optimization
    • Background: LS loads the survey definition data model into several different data structures, such that it uses at least twice as much storage as it really needs. ExpressionScript now holds all of the instrument definition data, so the other data stores are no longer needed.
    • Strategy
      • Remove need for buildsurveysession() - gap analysis to add in any missing content to EM
      • Remove need for createFieldMap() - similar gap analysis
      • Normalize EM data structures to avoid internal duplication (and refactor code to use normalized structures) (and document new data structures so that future developers know which to use, and how to use them)
        • gInfo - renaming of groupSeqInfo, plus add missing group-level attributes (relevance, description)
        • qInfo - renaming of questionSeq2relevance, plus add any missing attributes from $fieldarray; remove aid, sqid; move grelevance to gInfo
        • aInfo - for storing answer arrays?
        • sqInfo - renaming of q2subqInfo, indexed on sgqa(?); remove content gleaned from gInfo and qInfo
        • gStatus - renaming of indexGseq - make hold only dynamic values; so move gtext and gname to gInfo; also remove gRelInfo, keeping any unique variables it contains
        • qStatus - renaming of indexQseq - make hold only dynamic values; so move qtext, qhelp, gtext, gname to qInfo
        • sqStatus - renaming of subQrelInfo - make hold only dynamic values
        • groupRelevanceInfo - consolidate into indexGseq?
        • knownVars - instead of copying content, use reference to gInfo and qInfo (e.g. remove question, relevance, grelevance, qcode, ansList, ansArray, onlynum).
        • varNameAttr - remove; generate on the fly from gInfo, qInfo, and knownVars
        • alias2varName - remove; generate on the fly from knownVars
      • Refactor EM so that stores normalized copies of secondary language text
      • Optionally load only current group for each page transition rather than holding entire survey definition in memory
      • Refactor EM for consistent variable naming
        • e.g. questionId => qid; groupNum => gid; groupSeq => gseq; questionSeq => qseq
  1. Run-Time Performance Optimization
    • Background: qanda.php loads the content to create the questions and answers. It used to do this by separate database queries per question.
    • Strategy
      • Refactor qanda.php to remove queries (like for "other", or subquestion text) - have it get that information from EM
      • Refactor LS so that language switching does not require a re-load of the core logic, but just the new language content (and that it gets this from EM)
      • Refactor replacements.php and EM
        • Should only need to call replacements.php once per page, so set those valeus as locally static in EM per page.
        • Refactor group.php to pass {QUESTION_*} via replacements array, rather than as globals passed to templatereplace
  1. Design-Time Performance Optimization
    • Background: LS used to only load the information from the data model that was needed for the given question or group. EM had to load the entire data model to properly syntax highlight everything. This can lead to some performance degradation in very long surveys
    • Strategy:
      • Add methods to EM to just load changes to model as questions or groups are added, removed, or updated
      • Pass those updates into EM internals so that syntax highlighting continues to be correct
      • Ensure that admin pages only call the subset of EM functions needed to do accurate syntax highlighting.
  1. Optimizations for Rapid Development
    • Background: LS has a nice GUI for editing single questions at a time. However, it is not optimized to make changes to multiple questions at a time. Some competitor systems let authors design surveys using an Excel template (e.g. so that they can do bulk find and replace, or easily copy similar portions or answer lists). Short of a full-blown AJAX-enabled admin system, this has the highest throughput potential
    • Strategy:
      • Create an Excel data model that would work for importing surveys
      • Create import and validation routines from that model
      • A similar model, which could be extended for LS, is noted here.
  1. Performance Validation
    • Load test surveys of varying lenghts
    • Identify performance and memory bottlenecks
    • Idenfity minimum memory requirements for certain survey lengths and concurrent user volumes
    • Propose strategy to overcome those performance issues

Skills

PHP, SQL, PHP Debugging (e.g. xdebug), Yii, LimeSurvey's ExpressionScript and code-base in general, Load testing tool (e.g. webload), PHP Profiler

Difficulty

Medium to Hard

Probable Mentors

Thomas White (TMSWhite)

Convert templates to twig.

In 2.1 we will be rendering surveys and the administrative interface using Twig.↵ Currently we have templates that contain HTML code combined with our own simple templating engine (survey templates)↵

Skills CSS, HTML, TWIG (http://twig.sensiolabs.org/)

Difficulty easy-medium.

Probable Mentors Sam (sammousa)


Implement coding style checks. We should have some tools top automatically check our code to obey some (to be defined) coding standards. Having a single coding standard which is obeyed by all (non-third-party) code improves readability for all developers.

Skills PHP

Difficulty medium

Probable Mentors Sam (sammousa)


Update installer to build database from scratch using Yii's DBMS independent functions.

Currently we are forced to maintain a separate installation script for each supported DBMS. Using an installer that does not contain any DBMS specific code allows us to support more DBMSes, while at the same time reducing maintenance costs (costs == time).

Skills PHP, SQL, Yii, testing

Difficulty medium

Probable Mentors Sam (sammousa)


Plugin system event documentation generator.

The plugin system we introduced in 2.05 creates many different events. Currently developers need to manually document each event in the wiki; ideally the events would be documented in the source code and an automated solution would extract this and create the corresponding documentation in the wiki.

Skills PHP

Difficulty medium

Probable Mentors Sam (sammousa)


Improve the LimeSurvey admin screen and related work-flow

At the LimeSurvey admin backend we need to make more use of modern technologies like Ajax and need to re-work some of the work-flow for certain actions. Furthermore, the GUI needs to be polished.

Here are the tasks in detail:

1. Implement ajax popup dialog at token overview table when adding a survey participant

The LimeSurvey admin backend already supports jqgrid features for the token overview screen. But when adding a new token entry, a new page is used which is old fashioned and could be far more user friendly when switching to a jQuery popup dialogue. That's what we need your help with!

Task Steps: 

   Have a look at the jqgrid docs at http://www.trirand.com/jqgridwiki/doku.php(external link)
   Look at the current dialog when adding a token. This one should appear in a jQuery popup dialog instead. After the record was added, the new record should be shown first in the grid (grid needs to re-sorted by ID descending) so that the user automatically sees the new entry on top.
   When editing a record current inline editing is used - this has to be changed to using the popup dialog, too.


2. Improve work flow of the "send invitation/reminder" feature

Currently, when sending email invitations or reminders, you don't see the scope of concerned data sets (some have already received an invitation/reminder, some might have opted out, some might have a missing token/email address). The user sees the list of email receivers AFTER having sent the emails which is not that good. Your task is to present these details up front.

Task Steps: 

   Create a simple test survey and create a token table which is filled with 2-3 test data sets.
   Have a look at the "send email invitation/reminder" feature and note the single work flow steps when sending these emails.
   The work-flow should be changed so that when clicking "send email invitations/reminders", a list of people who will receive the email is created up front so the user can look into the details.
   By default a checked checkbox is shown in front of each listed user who will receive an email .
   A button "send emails to selected users" is placed on top.
   Furthermore, you should add a "list people who will NOT receive the email" link below which shows this different list when being clicked (default = hidden). That second list of users who will NOT receive an email contains users sorted by status like
       "invitation already received" (invitations) / "max number of reminders already sent" (reminders)
       "missing token"
       "missing email"
       "opted out"
       anythingh else you can think of


3a. Add a "Check for duplicates" function at the token admin screen

A check for duplicate token data already exists for the CSV import feature. This is not sufficient because user A might import data from a CSV file and user B might add token data later manually, which might lead to duplicate entries. That's why we need a new function which is called by clicking a certain icon on the admin screen. Here is what this new function should do:

Task Steps: 

   Create a simple test survey and create a token table which is filled with 2-3 test data sets.
   Have a look at the ducplicate check function which is used when importing token data from a CSV file.
   Talk to your mentor where at the admin interface a new icon for the duplicate token check can be added and how it might look like. Afterwards, add the icon and link to the new feature.
   Create a new view which is shown after the button was clicked. This view should contain columns the user wants to check for duplicates. We need at least:
       First name
       Last name
       Email
       Token
   For each column ticked at this screen, the script should check the whole token data for duplicates.
   Extend the current view to show the duplicates below the filter options described above. It should include a tabular overview similar to the standard token list which lists only duplicate entries. If only "email" was selected previously, the overview should be sorted by email, if only "last name" was checked, it should be sorted by last name and so on. If several filters were clicked, the data should be sorted by last name
   For each data set, mark the according cell where duplicate data was found with a red border.
   Add buttons and a function to delete and edit a certain data set at the table of duplicate entries. These features already exist at the standard token overview, so no need to re-invent the wheel.


3b. Add sorting and edit/delete token functionality to "Check for duplicates" function at the token admin screen

Once the "Add a 'Check for duplicates' function at the token admin screen" (3a) task was completed, a next step is to add some additional functionality to the screen which lists the duplicates. Here are the details:

Task Steps: 

   Install LimeSurvey - Create a simple test survey and create a token table which is filled with 2-3 test data sets.
   Have a look at the ducplicate check function it supports checking for duplicates based on:
       First name
       Last name
       Email
       Token
   For each column ticked at this screen, the script checks the whole token data for duplicates.
   Your task is to extend the current view which lists the duplicates: If only "email" was selected previously, the overview should be sorted by email, if only "last name" was checked, it should be sorted by last name and so on. If several filters were clicked, the data should be sorted by last name.
   Add buttons and a function to delete and edit a certain data set at the table of duplicate entries. These features already exist at the standard token overview, so no need to re-invent the wheel.


4. Token section workflow improvements

There are some sections at the LimeSurvey admin backend like the token part at which workflow improvements can be added, e. g. when switching to the token admin screen you don't see a list of available tokens. You have to click on the "Display Tokens" icon first.

Task Steps: 

   Create or import a simple survey and add 2-3 token entries.
   Search the code for the snippet which is called when a user calls the token admin screen.
   Change the code so that a user is automatically directed to the list of tokens.


5. Improve "Add answer options" GUI

There are some sections at the LimeSurvey admin backend like the survey designer at which workflow improvements can be added, e. g. when adding new answer options and clicking into the answer text field, you have to manually delete the "Some example subquestion" text (For further answer options the text is deleted automatically when clicking into the input field.).

Task Steps: 

   Create a simple survey and add a "list radio" question. You are then asked to add answer options.
   Search the code for the snippet which is called when a user adds answer options.
   Add some Javascript to automatically delete the text once a user clicks into the input field.


6a. User management workflow improvement

There are some sections at the LimeSurvey admin backend like when adding users at which workflow improvements can be added, e. g. after having added a new user there is a summary screen showing the username and email address. You can then click the "set user permissions" button which leads you to the next logical step of setting the permissions for this user (a user without any permissions set doesn't make much sense). This work flow can be improved by removing the step in between.

Task Steps: 

   Install LimeSurvey - Add a new user to check the work flow details.
   Search the code for the snippet which is responsible of showing the summary screen with username and email address.
   Change the code so that the summary is shown as a pop up (see pop up when renaming a survey for example) and lead the user directly to the admin screen where permissions for the newly added user can be set.


6b. User rights management workflow improvement

There are some sections at the LimeSurvey admin backend like when setting user rights at which workflow improvements can be added, e. g. after having added user rights there is a summary screen showing "User permissions were updated successfully.". Only following option is to click the "continue" button which leads him to the user overview. This work flow can be improved by showing the feedback as a pop up and redirecting the user to the next step of setting template rights

Task Steps: 

   Install LimeSurvey - Add a new user and add user rights to check the work flow details.
   Search the code for the snippet which is responsible of showing the "User permissions were updated successfully." summary.
   Change the code so that the summary is shown as a pop up (see pop up when renaming a survey for example) and lead the user directly to the admin screen where template permissions for the newly added user can be set.


Skills PHP, JavaScript/jQuery, HTML, CSS

Difficulty Easy to medium

Probable Mentors Mazi, c_schmitz


Idea template

Describe the idea here in general terms

Skills

Explain what sort of coding skills would be needed for a student to implement this project

Difficulty

Explain the level of difficulty involved

Probable Mentors

Put your name (and tag) here if you are willing to mentor a student for this idea

More information

Getting started

Check out our 'Get started' page for setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

Frequently Asked Questions

Check out our GSoC FAQ page.

Retrieved from "http://www.limesurvey.org/manual/index.php?title=Semester_of_Code_2014&oldid=146170"