https://www.limesurvey.org/api.php?action=feedcontributions&feedformat=atom&user=MacduyLimeSurvey Manual - User contributions [en]2026-08-11T14:53:49ZUser contributionsMediaWiki 1.43.9https://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2010&diff=2470Project ideas for GSOC 20102010-03-31T11:03:54Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Welcome=<br />
<br />
Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_eligibility eligible candidate] for the GSoC program.<br />
<br />
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 [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)<br />
<br />
=Project ideas=<br />
<br />
==Example Format...==<br />
<br />
Describe the idea here in general terms<br />
<br />
'''Skills'''<br />
<br />
Explain what sort of coding skills would be needed for a student to implement this project<br />
<br />
'''Difficulty'''<br />
<br />
Explain the level of difficulty involved<br />
<br />
'''Probable Mentors'''<br />
<br />
Put your name (and tag) here if you are willing to mentor a student for this idea<br />
<br />
==LimeSurvey 1: Email bounce tracking & handling of international email addresses==<br />
<br />
Currently there is no way to process email bounces of invitation or reminders in an automated way. If a bounce is received the administrator has to manually process every bounce - either by finding out a correct email address or removing the participant completely. Additionally it would be great if LimeSurvey could handle International email addressing - although the RFC for this kind of features are still experimental it would be great if we can be ahead of time. Primary goals of this task:<br />
<br />
- Create a facility to handle email bounces using various methods. Easier to install methods which run without CRON jobs and with a single email account - more advanced and safer methods which require certain email server setups. Make it quick and easy to configure and handle. Create followup actions in case an email is bounced. Differentiate between bounces and other 'away-messages'.<br />
<br />
- Extend the PHPmailer library and LimeSurvey so it can handle international email addressing (including configuration)<br />
<br />
Skills<br />
<br />
PHP, knowledge of email handling and RFCs, some HTML & JS<br />
<br />
Difficulty<br />
<br />
Medium<br />
<br />
Probable Mentors<br />
<br />
Carsten Schmitz (c_schmitz)<br />
<br />
Thibault LeMeur (lemeur)<br />
<br />
==LimeSurvey 1: File Upload question type==<br />
<br />
The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:<br />
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)<br />
*Extensive configuration options for the question type like<br />
**How many files are required, minimum and maxim number of files,<br />
**maximum/minimum upload size,<br />
**Allowed file types<br />
*Safe!! storage in the file system, checks for file contents<br />
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl<br />
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses<br />
*Provide possible hooks for third party processing tools<br />
<br />
'''Skills'''<br />
<br />
PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
c_schmitz (Carsten Schmitz)<br />
<br />
==LimeSurvey 1: Authentication framework==<br />
<br />
The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.<br />
<br />
The generic authentication framework must define the following services:<br />
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br />
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...<br />
* User provisionning:<br />
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).<br />
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey (only if the token for this user has not been already added).<br />
<br />
The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).<br />
<br />
'''Skills'''<br />
<br />
PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
lemeur (Thibault Le Meur)<br />
<br />
'''Want to know more'''<br />
<br />
Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br />
<br />
==LimeSurvey 2: Db Storage Engine==<br />
<br />
Develop an extensible plugin survey storage engine for LimeSurvey 2.<br />
<br />
<u>Description</u><br />
<br />
Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.<br />
<br />
For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.<br />
<br />
<u>Rationale</u><br />
<br />
Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey&rsquo;s functions we will the ease with which LimeSurvey can be developed in the long term.<br />
<br />
<u>Implementation</u><br />
<br />
This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.<br />
<br />
The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.<br />
<br />
<u>Requirements & Considerations</u><br />
<br />
The DB Engine must be able to do the following<br />
* ease development of additional '''question types, which will be developed as plugins'''<br />
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)<br />
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.<br />
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.<br />
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.<br />
* support survey resuming (where applicable)<br />
<br />
<u> Use Cases </u><br />
<br />
Think of these when writing your proposal<br />
# Questionnaire which has a special section displayed only if a user answers a chosen question in a specific way (i.e. branching)<br />
# Question on your favourite ice-cream, with an option "Other", upon which the user will be asked to enter his own choice (i.e. multi-datatype question types)<br />
# Questionnaire, which asks how many children you have and then loops a set of predefined questions that many times. (i.e. looping)<br />
<br />
<u> Your proposal </u><br />
<br />
Your proposal needs to be fairly detailed and must dig deep down to the implementation level, with good analysis of the performance. "Read the data from the user and store it in the database" is no good! How are you going to store it? What is the schema going to be? Does it satisfy the requirements, for branching, conditions, pluggable question types? Does it scale well? Is it efficient - what is the time complexity? Can I get summaries out of it in a reasonable time? All this needs to be addressed. Early submissions are accepted by both mentors and suggestions and comments will be given (:wink:).<br />
<br />
<u>Field Naming and Database Extensibility Methodologies</u><br />
<br />
An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to &lsquo;freeze&rsquo; the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn&rsquo;t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations &ndash; sometimes running up against database limitations regarding the number of fields per table.<br />
<br />
An alternative is a &lsquo;normalised&rsquo; database topology where a single table is created to store all survey responses &ndash; one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.<br />
<br />
In a perfect world LimeSurvey would allow users to choose either methodology &ndash; either at an installation level or even on a per-survey level.<br />
<br />
Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
jasebo (Jason Cleeland)<br />
<br />
macduy (Mac Duy Hai)<br />
<br />
==LimeSurvey 2: Template Editor==<br />
<br />
Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.<br />
<br />
'''Skills'''<br />
<br />
One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.<br />
<br />
'''Difficulty'''<br />
<br />
You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.<br />
<br />
'''Probable Mentors'''<br />
<br />
Mazi<br />
<br />
==LimeSurvey 2: Mini-projects==<br />
<br />
Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:<br />
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:<br />
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it. It should be able to clean up databases, revert files and basically be prepared for any eventuality.<br />
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error" (and excellent opportunity for a "Would you like to create it?" button)<br />
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.<br />
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.<br />
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.<br />
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List<br />
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.<br />
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality<br />
**'''Batch import:''' import users through CSV, XML, etc...<br />
**'''Batch processing:''' Add an interface to manipulate (add & modify) several users at once<br />
*'''Announcements:''' Make it easy to send customizable announcements to desired audience. Obviously, you don't want to send reminder e-mails to those people who've taken a survey already.<br />
**'''Filtering:''' Filter users on various suitable criteria<br />
**'''Templates:''' Design a template system announcement beyond a simple find-and-replace. We don't want you to build the next Smarty or Django templates replacement, but dazzle the users with something cool and usable<br />
**'''Management:''' Folders, counters,<br />
*'''Inbox:''' Build a system that would allow users to communicate among each other without the need for e-mail. ('''Not chat''')!<br />
**'''Message Type:''' Categorise the messages<br />
**'''Linking with Announcements:''' Use it as an alternative to e-mail.<br />
**'''E-mail notifications:''' Is it a good idea? How often is good? Allow people to choose if they want it?<br />
*'''Assignments''': Assignment is how a Survey is deployed. It can be time-restricted or region-restricted etc. Make improvements on the Assignment features and its design GUI.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JavaScript & jQuery, Creativity, UI Design<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Mac Duy Hai (macduy)<br />
<br />
==LimeSurvey 2: Template/Theme Editor==<br />
<br />
The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.<br />
<br />
The overview of the modules can be seen here:<br />
<br />
[[File:theme_roller.png]]<br />
<br />
It&rsquo;ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)<br />
<br />
The following mock-up will give us a better view:<br />
<br />
Moderate[[File:theme_editor_small.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==-LimeSurvey 2: Lime Survey Social - Facebook Application - <span style='color:#FF0000'>This project has no mentor!</span>==<br />
<br />
The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.<br />
<br />
The facebook has the following modules (we can add more. This is primary draft.)<br />
*All Survey related core features. (Create, Edit, Delete, Administer etc)<br />
*Gain reward points.<br />
*Use reward points to create more surveys.<br />
*Spread the surveys ...... and more<br />
<br />
The idea can be extended to other social networks<br />
<br />
[[File:fb_overview.png]]<br />
<br />
The mock-ups :<br />
<br />
[[File:facebook app.png]]<br />
<br />
[[File:canvas.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Facebook API.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Integration of Poll Questions <span style='color:#FF0000'>This project has no mentor!</span>==<br />
<br />
Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.<br />
<br />
The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback &ldquo;about the survey&rdquo; at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).<br />
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.<br />
<br />
A simple mock-up for this:<br />
<br />
[[File:chat.png]]<br />
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.<br />
<br />
We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Survey Community Project==<br />
<br />
Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.<br />
<br />
For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Web and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Jason Cleeland (jasebo)<br />
<br />
==LimeSurvey 2: Condition Engine==<br />
<br />
[[File:addNewCondition1.png]]<br />
<br />
Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...<br />
<br />
This projects will at least end up with:<br />
* A working GUI to design complex conditions:<br />
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br />
** an atomic condition representation can be<br />
<br />
<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight><br />
** an atomic condition editor will implement<br />
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br />
*** meta operators surch as 'Not displayed'<br />
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)<br />
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition<br />
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JQuery and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
Thibault Le Meur (lemeur)<br />
<br />
'''Want to know more'''<br />
<br />
Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine FAQ about this project]<br />
<br />
=We want your ideas!=<br />
<br />
What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.<br />
<br />
=More Information=<br />
<br />
==LimeSurvey Google's Summer of Code 2010==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010 Limesurvey GSoC 2010]<br />
<br />
An introduction to LimeSurvey and our application for this years Google Summer of Code<br />
<br />
==Getting Started==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC]<br />
<br />
How to Get Started With LimeSurvey:<br />
<br />
- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!<br />
<br />
==Frequently Asked Questions==<br />
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]<br />
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2010&diff=2471Project ideas for GSOC 20102010-03-31T11:01:53Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Welcome=<br />
<br />
Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_eligibility eligible candidate] for the GSoC program.<br />
<br />
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 [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)<br />
<br />
=Project ideas=<br />
<br />
==Example Format...==<br />
<br />
Describe the idea here in general terms<br />
<br />
'''Skills'''<br />
<br />
Explain what sort of coding skills would be needed for a student to implement this project<br />
<br />
'''Difficulty'''<br />
<br />
Explain the level of difficulty involved<br />
<br />
'''Probable Mentors'''<br />
<br />
Put your name (and tag) here if you are willing to mentor a student for this idea<br />
<br />
==LimeSurvey 1: Email bounce tracking & handling of international email addresses==<br />
<br />
Currently there is no way to process email bounces of invitation or reminders in an automated way. If a bounce is received the administrator has to manually process every bounce - either by finding out a correct email address or removing the participant completely. Additionally it would be great if LimeSurvey could handle International email addressing - although the RFC for this kind of features are still experimental it would be great if we can be ahead of time. Primary goals of this task:<br />
<br />
- Create a facility to handle email bounces using various methods. Easier to install methods which run without CRON jobs and with a single email account - more advanced and safer methods which require certain email server setups. Make it quick and easy to configure and handle. Create followup actions in case an email is bounced. Differentiate between bounces and other 'away-messages'.<br />
<br />
- Extend the PHPmailer library and LimeSurvey so it can handle international email addressing (including configuration)<br />
<br />
Skills<br />
<br />
PHP, knowledge of email handling and RFCs, some HTML & JS<br />
<br />
Difficulty<br />
<br />
Medium<br />
<br />
Probable Mentors<br />
<br />
Carsten Schmitz (c_schmitz)<br />
<br />
Thibault LeMeur (lemeur)<br />
<br />
==LimeSurvey 1: File Upload question type==<br />
<br />
The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:<br />
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)<br />
*Extensive configuration options for the question type like<br />
**How many files are required, minimum and maxim number of files,<br />
**maximum/minimum upload size,<br />
**Allowed file types<br />
*Safe!! storage in the file system, checks for file contents<br />
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl<br />
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses<br />
*Provide possible hooks for third party processing tools<br />
<br />
'''Skills'''<br />
<br />
PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
c_schmitz (Carsten Schmitz)<br />
<br />
==LimeSurvey 1: Authentication framework==<br />
<br />
The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.<br />
<br />
The generic authentication framework must define the following services:<br />
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br />
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...<br />
* User provisionning:<br />
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).<br />
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey (only if the token for this user has not been already added).<br />
<br />
The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).<br />
<br />
'''Skills'''<br />
<br />
PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
lemeur (Thibault Le Meur)<br />
<br />
'''Want to know more'''<br />
<br />
Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br />
<br />
==LimeSurvey 2: Db Storage Engine==<br />
<br />
Develop an extensible plugin survey storage engine for LimeSurvey 2.<br />
<br />
<u>Description</u><br />
<br />
Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.<br />
<br />
For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.<br />
<br />
<u>Rationale</u><br />
<br />
Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey&rsquo;s functions we will the ease with which LimeSurvey can be developed in the long term.<br />
<br />
<u>Implementation</u><br />
<br />
This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.<br />
<br />
The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.<br />
<br />
<u>Requirements & Considerations</u><br />
<br />
The DB Engine must be able to do the following<br />
* ease development of additional '''question types, which will be developed as plugins'''<br />
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)<br />
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.<br />
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.<br />
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.<br />
* support survey resuming (where applicable)<br />
<br />
<u> Use Cases </u><br />
<br />
Think of these when writing your proposal<br />
# Questionnaire which has a special section displayed only if a user answers a chosen question in a specific way (i.e. branching)<br />
# Question on your favourite ice-cream, with an option "Other", upon which the user will be asked to enter his own choice (i.e. multi-datatype question types)<br />
# Questionnaire, which asks how many children you have and then loops a set of predefined questions that many times. (i.e. looping)<br />
<br />
<u> Your proposal </u><br />
<br />
Your proposal needs to be fairly detailed and must dig deep down to the implementation level, with good analysis of the performance. "Read the data from the user and store it in the database" is no good! How are you going to store it? What is the schema going to be? Does it satisfy the requirements, for branching, conditions, pluggable question types? Does it scale well? Is it efficient - what is the time complexity? Can I get summaries out of it in a reasonable time? All this needs to be addressed. Early submissions are accepted by both mentors and suggestions and comments will be given (:wink:).<br />
<br />
<u>Field Naming and Database Extensibility Methodologies</u><br />
<br />
An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to &lsquo;freeze&rsquo; the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn&rsquo;t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations &ndash; sometimes running up against database limitations regarding the number of fields per table.<br />
<br />
An alternative is a &lsquo;normalised&rsquo; database topology where a single table is created to store all survey responses &ndash; one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.<br />
<br />
In a perfect world LimeSurvey would allow users to choose either methodology &ndash; either at an installation level or even on a per-survey level.<br />
<br />
Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
jasebo (Jason Cleeland)<br />
<br />
macduy (Mac Duy Hai)<br />
<br />
==LimeSurvey 2: Template Editor==<br />
<br />
Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.<br />
<br />
'''Skills'''<br />
<br />
One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.<br />
<br />
'''Difficulty'''<br />
<br />
You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.<br />
<br />
'''Probable Mentors'''<br />
<br />
Mazi<br />
<br />
==LimeSurvey 2: Mini-projects==<br />
<br />
Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:<br />
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:<br />
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it. It should be able to clean up databases, revert files and basically be prepared for any eventuality.<br />
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error" (and excellent opportunity for a "Would you like to create it?" button)<br />
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.<br />
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.<br />
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.<br />
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List<br />
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.<br />
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality<br />
**'''Batch import:''' import users through CSV, XML, etc...<br />
**'''Batch processing:''' Add an interface to manipulate (add & modify) several users at once<br />
*'''Announcements:''' Make it easy to send customizable announcements to desired audience. Obviously, you don't want to send reminder e-mails to those people who've taken a survey already.<br />
**'''Filtering:''' Filter users on various suitable criteria<br />
**'''Templates:''' Design a template system announcement beyond a simple find-and-replace. We don't want you to build the next Smarty or Django templates replacement, but dazzle the users with something cool and usable<br />
**'''Management:''' Folders, counters,<br />
*'''Inbox:''' Build a system that would allow users to communicate among each other without the need for e-mail. ('''Not chat''')!<br />
**'''Message Type:''' Categorise the messages<br />
**'''Linking with Announcements:''' Use it as an alternative to e-mail.<br />
**'''E-mail notifications:''' Is it a good idea? How often is good? Allow people to choose if they want it?<br />
*'''Assignments''': Assignment is how a Survey is deployed. It can be time-restricted or region-restricted etc. Make improvements on the Assignment features and its design GUI.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JavaScript & jQuery, Creativity, UI Design<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Mac Duy Hai (macduy)<br />
<br />
==LimeSurvey 2: Template/Theme Editor==<br />
<br />
The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.<br />
<br />
The overview of the modules can be seen here:<br />
<br />
[[File:theme_roller.png]]<br />
<br />
It&rsquo;ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)<br />
<br />
The following mock-up will give us a better view:<br />
<br />
Moderate[[File:theme_editor_small.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==-LimeSurvey 2: Lime Survey Social - Facebook Application - <span style='color:#FF0000'>This project has no mentor!</span>==<br />
<br />
The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.<br />
<br />
The facebook has the following modules (we can add more. This is primary draft.)<br />
*All Survey related core features. (Create, Edit, Delete, Administer etc)<br />
*Gain reward points.<br />
*Use reward points to create more surveys.<br />
*Spread the surveys ...... and more<br />
<br />
The idea can be extended to other social networks<br />
<br />
[[File:fb_overview.png]]<br />
<br />
The mock-ups :<br />
<br />
[[File:facebook app.png]]<br />
<br />
[[File:canvas.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Facebook API.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Integration of Poll Questions==<br />
<br />
Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.<br />
<br />
The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback &ldquo;about the survey&rdquo; at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).<br />
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.<br />
<br />
A simple mock-up for this:<br />
<br />
[[File:chat.png]]<br />
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.<br />
<br />
We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Survey Community Project==<br />
<br />
Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.<br />
<br />
For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Web and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Jason Cleeland (jasebo)<br />
<br />
==LimeSurvey 2: Condition Engine==<br />
<br />
[[File:addNewCondition1.png]]<br />
<br />
Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...<br />
<br />
This projects will at least end up with:<br />
* A working GUI to design complex conditions:<br />
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br />
** an atomic condition representation can be<br />
<br />
<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight><br />
** an atomic condition editor will implement<br />
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br />
*** meta operators surch as 'Not displayed'<br />
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)<br />
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition<br />
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JQuery and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
Thibault Le Meur (lemeur)<br />
<br />
'''Want to know more'''<br />
<br />
Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine FAQ about this project]<br />
<br />
=We want your ideas!=<br />
<br />
What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.<br />
<br />
=More Information=<br />
<br />
==LimeSurvey Google's Summer of Code 2010==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010 Limesurvey GSoC 2010]<br />
<br />
An introduction to LimeSurvey and our application for this years Google Summer of Code<br />
<br />
==Getting Started==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC]<br />
<br />
How to Get Started With LimeSurvey:<br />
<br />
- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!<br />
<br />
==Frequently Asked Questions==<br />
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]<br />
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2010&diff=2472Project ideas for GSOC 20102010-03-31T10:59:49Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Welcome=<br />
<br />
Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_eligibility eligible candidate] for the GSoC program.<br />
<br />
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 [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)<br />
<br />
=Project ideas=<br />
<br />
==Example Format...==<br />
<br />
Describe the idea here in general terms<br />
<br />
'''Skills'''<br />
<br />
Explain what sort of coding skills would be needed for a student to implement this project<br />
<br />
'''Difficulty'''<br />
<br />
Explain the level of difficulty involved<br />
<br />
'''Probable Mentors'''<br />
<br />
Put your name (and tag) here if you are willing to mentor a student for this idea<br />
<br />
==LimeSurvey 1: Email bounce tracking & handling of international email addresses==<br />
<br />
Currently there is no way to process email bounces of invitation or reminders in an automated way. If a bounce is received the administrator has to manually process every bounce - either by finding out a correct email address or removing the participant completely. Additionally it would be great if LimeSurvey could handle International email addressing - although the RFC for this kind of features are still experimental it would be great if we can be ahead of time. Primary goals of this task:<br />
<br />
- Create a facility to handle email bounces using various methods. Easier to install methods which run without CRON jobs and with a single email account - more advanced and safer methods which require certain email server setups. Make it quick and easy to configure and handle. Create followup actions in case an email is bounced. Differentiate between bounces and other 'away-messages'.<br />
<br />
- Extend the PHPmailer library and LimeSurvey so it can handle international email addressing (including configuration)<br />
<br />
Skills<br />
<br />
PHP, knowledge of email handling and RFCs, some HTML & JS<br />
<br />
Difficulty<br />
<br />
Medium<br />
<br />
Probable Mentors<br />
<br />
Carsten Schmitz (c_schmitz)<br />
<br />
Thibault LeMeur (lemeur)<br />
<br />
==LimeSurvey 1: File Upload question type==<br />
<br />
The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:<br />
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)<br />
*Extensive configuration options for the question type like<br />
**How many files are required, minimum and maxim number of files,<br />
**maximum/minimum upload size,<br />
**Allowed file types<br />
*Safe!! storage in the file system, checks for file contents<br />
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl<br />
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses<br />
*Provide possible hooks for third party processing tools<br />
<br />
'''Skills'''<br />
<br />
PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
c_schmitz (Carsten Schmitz)<br />
<br />
==LimeSurvey 1: Authentication framework==<br />
<br />
The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.<br />
<br />
The generic authentication framework must define the following services:<br />
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br />
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...<br />
* User provisionning:<br />
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).<br />
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey (only if the token for this user has not been already added).<br />
<br />
The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).<br />
<br />
'''Skills'''<br />
<br />
PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
lemeur (Thibault Le Meur)<br />
<br />
'''Want to know more'''<br />
<br />
Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br />
<br />
==LimeSurvey 2: Db Storage Engine==<br />
<br />
Develop an extensible plugin survey storage engine for LimeSurvey 2.<br />
<br />
<u>Description</u><br />
<br />
Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.<br />
<br />
For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.<br />
<br />
<u>Rationale</u><br />
<br />
Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey&rsquo;s functions we will the ease with which LimeSurvey can be developed in the long term.<br />
<br />
<u>Implementation</u><br />
<br />
This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.<br />
<br />
The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.<br />
<br />
<u>Requirements & Considerations</u><br />
<br />
The DB Engine must be able to do the following<br />
* ease development of additional '''question types, which will be developed as plugins'''<br />
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)<br />
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.<br />
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.<br />
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.<br />
* support survey resuming (where applicable)<br />
<br />
<u> Use Cases </u><br />
<br />
Think of these when writing your proposal<br />
# Questionnaire which has a special section displayed only if a user answers a chosen question in a specific way (i.e. branching)<br />
# Question on your favourite ice-cream, with an option "Other", upon which the user will be asked to enter his own choice (i.e. multi-datatype question types)<br />
# Questionnaire, which asks how many children you have and then loops a set of predefined questions that many times. (i.e. looping)<br />
<br />
<u> Your proposal </u><br />
<br />
Your proposal needs to be fairly detailed and must dig deep down to the implementation level, with good analysis of the performance. "Read the data from the user and store it in the database" is no good! How are you going to store it? What is the schema going to be? Does it satisfy the requirements, for branching, conditions, pluggable question types? Does it scale well? Is it efficient - what is the time complexity? Can I get summaries out of it in a reasonable time? All this needs to be addressed. Early submissions are accepted by both mentors and suggestions and comments will be given (:wink:).<br />
<br />
<u>Field Naming and Database Extensibility Methodologies</u><br />
<br />
An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to &lsquo;freeze&rsquo; the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn&rsquo;t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations &ndash; sometimes running up against database limitations regarding the number of fields per table.<br />
<br />
An alternative is a &lsquo;normalised&rsquo; database topology where a single table is created to store all survey responses &ndash; one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.<br />
<br />
In a perfect world LimeSurvey would allow users to choose either methodology &ndash; either at an installation level or even on a per-survey level.<br />
<br />
Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
jasebo (Jason Cleeland)<br />
<br />
macduy (Mac Duy Hai)<br />
<br />
==LimeSurvey 2: Template Editor==<br />
<br />
Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.<br />
<br />
'''Skills'''<br />
<br />
One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.<br />
<br />
'''Difficulty'''<br />
<br />
You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.<br />
<br />
'''Probable Mentors'''<br />
<br />
Mazi<br />
<br />
==LimeSurvey 2: Mini-projects==<br />
<br />
Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:<br />
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:<br />
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it. It should be able to clean up databases, revert files and basically be prepared for any eventuality.<br />
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error" (and excellent opportunity for a "Would you like to create it?" button)<br />
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.<br />
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.<br />
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.<br />
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List<br />
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.<br />
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality<br />
**'''Batch import:''' import users through CSV, XML, etc...<br />
**'''Batch processing:''' Add an interface to manipulate (add & modify) several users at once<br />
*'''Announcements:''' Make it easy to send customizable announcements to desired audience. Obviously, you don't want to send reminder e-mails to those people who've taken a survey already.<br />
**'''Filtering:''' Filter users on various suitable criteria<br />
**'''Templates:''' Design a template system announcement beyond a simple find-and-replace. We don't want you to build the next Smarty or Django templates replacement, but dazzle the users with something cool and usable<br />
**'''Management:''' Folders, counters,<br />
*'''Inbox:''' Build a system that would allow users to communicate among each other without the need for e-mail. ('''Not chat''')!<br />
**'''Message Type:''' Categorise the messages<br />
**'''Linking with Announcements:''' Use it as an alternative to e-mail.<br />
**'''E-mail notifications:''' Is it a good idea? How often is good? Allow people to choose if they want it?<br />
*'''Assignments''': Assignment is how a Survey is deployed. It can be time-restricted or region-restricted etc. Make improvements on the Assignment features and its design GUI.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JavaScript & jQuery, Creativity, UI Design<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Mac Duy Hai (macduy)<br />
<br />
==LimeSurvey 2: Template/Theme Editor==<br />
<br />
The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.<br />
<br />
The overview of the modules can be seen here:<br />
<br />
[[File:theme_roller.png]]<br />
<br />
It&rsquo;ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)<br />
<br />
The following mock-up will give us a better view:<br />
<br />
Moderate[[File:theme_editor_small.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Lime Survey Social - Facebook Application==<br />
<br />
The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.<br />
<br />
The facebook has the following modules (we can add more. This is primary draft.)<br />
*All Survey related core features. (Create, Edit, Delete, Administer etc)<br />
*Gain reward points.<br />
*Use reward points to create more surveys.<br />
*Spread the surveys ...... and more<br />
<br />
The idea can be extended to other social networks<br />
<br />
[[File:fb_overview.png]]<br />
<br />
The mock-ups :<br />
<br />
[[File:facebook app.png]]<br />
<br />
[[File:canvas.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Facebook API.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Integration of Poll Questions==<br />
<br />
Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.<br />
<br />
The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback &ldquo;about the survey&rdquo; at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).<br />
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.<br />
<br />
A simple mock-up for this:<br />
<br />
[[File:chat.png]]<br />
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.<br />
<br />
We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Survey Community Project==<br />
<br />
Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.<br />
<br />
For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Web and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Jason Cleeland (jasebo)<br />
<br />
==LimeSurvey 2: Condition Engine==<br />
<br />
[[File:addNewCondition1.png]]<br />
<br />
Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...<br />
<br />
This projects will at least end up with:<br />
* A working GUI to design complex conditions:<br />
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br />
** an atomic condition representation can be<br />
<br />
<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight><br />
** an atomic condition editor will implement<br />
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br />
*** meta operators surch as 'Not displayed'<br />
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)<br />
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition<br />
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JQuery and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
Thibault Le Meur (lemeur)<br />
<br />
'''Want to know more'''<br />
<br />
Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine FAQ about this project]<br />
<br />
=We want your ideas!=<br />
<br />
What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.<br />
<br />
=More Information=<br />
<br />
==LimeSurvey Google's Summer of Code 2010==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010 Limesurvey GSoC 2010]<br />
<br />
An introduction to LimeSurvey and our application for this years Google Summer of Code<br />
<br />
==Getting Started==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC]<br />
<br />
How to Get Started With LimeSurvey:<br />
<br />
- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!<br />
<br />
==Frequently Asked Questions==<br />
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]<br />
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2010&diff=2473Project ideas for GSOC 20102010-03-31T10:59:01Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Welcome=<br />
<br />
Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_eligibility eligible candidate] for the GSoC program.<br />
<br />
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 [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)<br />
<br />
=Project ideas=<br />
<br />
==Example Format...==<br />
<br />
Describe the idea here in general terms<br />
<br />
'''Skills'''<br />
<br />
Explain what sort of coding skills would be needed for a student to implement this project<br />
<br />
'''Difficulty'''<br />
<br />
Explain the level of difficulty involved<br />
<br />
'''Probable Mentors'''<br />
<br />
Put your name (and tag) here if you are willing to mentor a student for this idea<br />
<br />
==LimeSurvey 1: Email bounce tracking & handling of international email addresses==<br />
<br />
Currently there is no way to process email bounces of invitation or reminders in an automated way. If a bounce is received the administrator has to manually process every bounce - either by finding out a correct email address or removing the participant completely. Additionally it would be great if LimeSurvey could handle International email addressing - although the RFC for this kind of features are still experimental it would be great if we can be ahead of time. Primary goals of this task:<br />
<br />
- Create a facility to handle email bounces using various methods. Easier to install methods which run without CRON jobs and with a single email account - more advanced and safer methods which require certain email server setups. Make it quick and easy to configure and handle. Create followup actions in case an email is bounced. Differentiate between bounces and other 'away-messages'.<br />
<br />
- Extend the PHPmailer library and LimeSurvey so it can handle international email addressing (including configuration)<br />
<br />
Skills<br />
<br />
PHP, knowledge of email handling and RFCs, some HTML & JS<br />
<br />
Difficulty<br />
<br />
Medium<br />
<br />
Probable Mentors<br />
<br />
Carsten Schmitz (c_schmitz)<br />
<br />
Thibault LeMeur (lemeur)<br />
<br />
==LimeSurvey 1: File Upload question type==<br />
<br />
The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:<br />
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)<br />
*Extensive configuration options for the question type like<br />
**How many files are required, minimum and maxim number of files,<br />
**maximum/minimum upload size,<br />
**Allowed file types<br />
*Safe!! storage in the file system, checks for file contents<br />
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl<br />
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses<br />
*Provide possible hooks for third party processing tools<br />
<br />
'''Skills'''<br />
<br />
PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
c_schmitz (Carsten Schmitz)<br />
<br />
==LimeSurvey 1: Authentication framework==<br />
<br />
The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.<br />
<br />
The generic authentication framework must define the following services:<br />
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br />
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...<br />
* User provisionning:<br />
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).<br />
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey (only if the token for this user has not been already added).<br />
<br />
The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).<br />
<br />
'''Skills'''<br />
<br />
PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
lemeur (Thibault Le Meur)<br />
<br />
'''Want to know more'''<br />
<br />
Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br />
<br />
==LimeSurvey 2: Db Storage Engine==<br />
<br />
Develop an extensible plugin survey storage engine for LimeSurvey 2.<br />
<br />
<u>Description</u><br />
<br />
Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.<br />
<br />
For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.<br />
<br />
<u>Rationale</u><br />
<br />
Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey&rsquo;s functions we will the ease with which LimeSurvey can be developed in the long term.<br />
<br />
<u>Implementation</u><br />
<br />
This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.<br />
<br />
The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.<br />
<br />
<u>Requirements & Considerations</u><br />
<br />
The DB Engine must be able to do the following<br />
* ease development of additional '''question types, which will be developed as plugins'''<br />
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)<br />
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.<br />
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.<br />
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.<br />
* support survey resuming (where applicable)<br />
<br />
<u> Use Cases </u><br />
<br />
Think of these when writing your proposal<br />
# Questionnaire which has a special section displayed only if a user answers a chosen question in a specific way (i.e. branching)<br />
# Question on your favourite ice-cream, with an option "Other", upon which the user will be asked to enter his own choice (i.e. multi-datatype question types)<br />
# Questionnaire, which asks how many children you have and then loops a set of predefined questions that many times. (i.e. looping)<br />
<br />
<u> Your proposal </u><br />
<br />
Your proposal needs to be fairly detailed and must dig deep down to the implementation level, with good analysis of the performance. "Read the data from the user and store it in the database" is no good! How are you going to store it? What is the schema going to be? Does it satisfy the requirements, for branching, conditions, pluggable question types? Does it scale well? Is it efficient - what is the time complexity? Can I get summaries out of it in a reasonable time? All this needs to be addressed. Early submissions are accepted by both mentors and suggestions and comments will be given (:wink:).<br />
<br />
<u>Field Naming and Database Extensibility Methodologies</u><br />
<br />
An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to &lsquo;freeze&rsquo; the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn&rsquo;t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations &ndash; sometimes running up against database limitations regarding the number of fields per table.<br />
<br />
An alternative is a &lsquo;normalised&rsquo; database topology where a single table is created to store all survey responses &ndash; one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.<br />
<br />
In a perfect world LimeSurvey would allow users to choose either methodology &ndash; either at an installation level or even on a per-survey level.<br />
<br />
Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
jasebo (Jason Cleeland)<br />
<br />
macduy (Mac Duy Hai)<br />
<br />
==LimeSurvey 2: Template Editor==<br />
<br />
Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.<br />
<br />
'''Skills'''<br />
<br />
One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.<br />
<br />
'''Difficulty'''<br />
<br />
You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.<br />
<br />
'''Probable Mentors'''<br />
<br />
Mazi<br />
<br />
==LimeSurvey 2: Mini-projects==<br />
<br />
Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:<br />
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:<br />
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it. It should be able to clean up databases, revert files and basically be prepared for any eventuality.<br />
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error" (and excellent opportunity for a "Would you like to create it?" button)<br />
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.<br />
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.<br />
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.<br />
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List<br />
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.<br />
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality<br />
**'''Batch import:''' import users through CSV, XML, etc...<br />
**'''Batch processing:''' Add an interface to manipulate (add & modify) several users at once<br />
*'''Announcements:''' Make it easy to send customizable announcements to desired audience. Obviously, you don't want to send reminder e-mails to those people who've taken a survey already.<br />
**'''Filtering:''' Filter users on various suitable criteria<br />
**'''Templates:''' Design a template system announcement beyond a simple find-and-replace. We don't want you to build the next Smarty or Django templates replacement, but dazzle the users with something cool and usable<br />
**'''Management:''' Folders, counters,<br />
*'''Inbox:''' Build a system that would allow users to communicate among each other without the need for e-mail. ('''Not chat''')!<br />
**'''Message Type:''' Categorise the messages<br />
**'''Linking with Announcements:''' Use it as an alternative to e-mail.<br />
**'''E-mail notifications:''' Is it a good idea? How often is good? Allow people to choose if they want it?<br />
**'''Assignments''': Assignment is how a Survey is deployed. It can be time-restricted or region-restricted etc. Make improvements on the Assignment features and its design GUI.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JavaScript & jQuery, Creativity, UI Design<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Mac Duy Hai (macduy)<br />
<br />
==LimeSurvey 2: Template/Theme Editor==<br />
<br />
The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.<br />
<br />
The overview of the modules can be seen here:<br />
<br />
[[File:theme_roller.png]]<br />
<br />
It&rsquo;ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)<br />
<br />
The following mock-up will give us a better view:<br />
<br />
Moderate[[File:theme_editor_small.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Lime Survey Social - Facebook Application==<br />
<br />
The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.<br />
<br />
The facebook has the following modules (we can add more. This is primary draft.)<br />
*All Survey related core features. (Create, Edit, Delete, Administer etc)<br />
*Gain reward points.<br />
*Use reward points to create more surveys.<br />
*Spread the surveys ...... and more<br />
<br />
The idea can be extended to other social networks<br />
<br />
[[File:fb_overview.png]]<br />
<br />
The mock-ups :<br />
<br />
[[File:facebook app.png]]<br />
<br />
[[File:canvas.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Facebook API.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Integration of Poll Questions==<br />
<br />
Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.<br />
<br />
The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback &ldquo;about the survey&rdquo; at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).<br />
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.<br />
<br />
A simple mock-up for this:<br />
<br />
[[File:chat.png]]<br />
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.<br />
<br />
We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Survey Community Project==<br />
<br />
Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.<br />
<br />
For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Web and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Jason Cleeland (jasebo)<br />
<br />
==LimeSurvey 2: Condition Engine==<br />
<br />
[[File:addNewCondition1.png]]<br />
<br />
Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...<br />
<br />
This projects will at least end up with:<br />
* A working GUI to design complex conditions:<br />
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br />
** an atomic condition representation can be<br />
<br />
<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight><br />
** an atomic condition editor will implement<br />
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br />
*** meta operators surch as 'Not displayed'<br />
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)<br />
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition<br />
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JQuery and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
Thibault Le Meur (lemeur)<br />
<br />
'''Want to know more'''<br />
<br />
Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine FAQ about this project]<br />
<br />
=We want your ideas!=<br />
<br />
What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.<br />
<br />
=More Information=<br />
<br />
==LimeSurvey Google's Summer of Code 2010==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010 Limesurvey GSoC 2010]<br />
<br />
An introduction to LimeSurvey and our application for this years Google Summer of Code<br />
<br />
==Getting Started==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC]<br />
<br />
How to Get Started With LimeSurvey:<br />
<br />
- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!<br />
<br />
==Frequently Asked Questions==<br />
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]<br />
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=GSOC_2010_Condition_engine&diff=1418GSOC 2010 Condition engine2010-03-30T09:34:59Z<p>Macduy: </p>
<hr />
<div><br />
This page is dedicated to the GSOC2010 Condition Engine Project<br />
<br />
=FAQ=<br />
* Will I have to implement an RPN parser?<br />
<br />
In fact a first version of an RPN parser has already been integrated to LS2, ask macduy for more details (or check [[Expression engine for conditions]] to see how it works<br />
<br />
Anyway here is an interresting link with algorithms for Infix to Postfix conversions and Postfix to infix conversions.<br />
<br />
http://scriptasylum.com/tutorials/infix_postfix/infix_postfix.html<br />
* Why is this a difficult project ?<br />
<br />
We want a generic condition engine, able to support multiple kind of conditions. The conditions can be based on static values (predefined string or number) or variable values (context dependant values such as a previous answer, or a user-specific value, ...).<br />
<br />
We also want to make the GUI as user friendly as possible so that even if we can design complex conditions, simple conditions design doesn't become a hassle.<br />
<br />
Moreover, conditions may have several usage in LS2, not only helping design question branching but also helping design assessments and so on. This means that implementing conditions may require a lot of communication between the "condition engine" team and the other LS2 developpers.<br />
* Do I have to understand how LS1 implements conditions ?<br />
<br />
Understanding LS1 conditions is important because it will show you what is currently possible to do.<br />
<br />
However you don't have to understand how everything is implemented.<br />
<br />
Please carefully read [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey The conditions documentation for LS1]<br />
<br />
I would highly recommend setting several surveys with conditions and see how it works:<br />
<br />
- for question per page surveys, for group by group surveys, for all-in-one surveys: note how condition evaluation is either done on the server side, or on the client side<br />
<br />
- also try several kind of conditions:<br />
<br />
- conditions on previous answer compared to a static value or to another previous answer, conditions on token (user-dependant value),<br />
<br />
- understand the difference between a condition using "not answer" and "not displayed" (the latest is not supported in LS1)<br />
<br />
- think about a strategy for LS2 to better handle the "Chained conditions" issue and other [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey#Things_to_watch_out_for gotchas from LS1 conditions]<br />
* How does the condition engine relates to other parts of the LS2 core ?<br />
<br />
Conditions will be used in a variety of ways: question branching, assessments, ...<br />
<br />
What this means is that a condition will be mapped to an action.<br />
<br />
For instance:<br />
<br />
- in a question branching context: map the conditions to the "Display question XXX" action<br />
<br />
- in an assessment context: map condition to the "update assessment score YYY by exectuing the following arithmetic operation ..."<br />
<br />
For the question branching action, the condition engine, must:<br />
<br />
- understand how answers are stored (either in SESSION, in DB or even in the HTML page if the evaluation is done by Javascript)<br />
<br />
- understand how to access participant's specific data<br />
<br />
- understand how LS2 handles mandatory questions and how to alter this behaviour if the question is hidden<br />
<br />
- be able to reset an answer to "No answer" if a previously answered question becomes hidden because the participant changed his mind and modified a previous answer (see the deletenonvalue parameter).<br />
<br />
- understand how to mark a question as "Not displayed"</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2010&diff=2477Project ideas for GSOC 20102010-03-24T18:05:17Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Welcome=<br />
<br />
Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_eligibility eligible candidate] for the GSoC program.<br />
<br />
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 [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)<br />
<br />
=Project ideas=<br />
<br />
==Example Format...==<br />
<br />
Describe the idea here in general terms<br />
<br />
'''Skills'''<br />
<br />
Explain what sort of coding skills would be needed for a student to implement this project<br />
<br />
'''Difficulty'''<br />
<br />
Explain the level of difficulty involved<br />
<br />
'''Probable Mentors'''<br />
<br />
Put your name (and tag) here if you are willing to mentor a student for this idea<br />
<br />
==LimeSurvey 1: Email bounce tracking & handling of international email addresses==<br />
<br />
Currently there is no way to process email bounces of invitation or reminders in an automated way. If a bounce is received the administrator has to manually process every bounce - either by finding out a correct email address or removing the participant completely. Additionally it would be great if LimeSurvey could handle International email addressing - although the RFC for this kind of features are still experimental it would be great if we can be ahead of time. Primary goals of this task:<br />
<br />
- Create a facility to handle email bounces using various methods. Easier to install methods which run without CRON jobs and with a single email account - more advanced and safer methods which require certain email server setups. Make it quick and easy to configure and handle. Create followup actions in case an email is bounced. Differentiate between bounces and other 'away-messages'.<br />
<br />
- Extend the PHPmailer library and LimeSurvey so it can handle international email addressing (including configuration)<br />
<br />
Skills<br />
<br />
PHP, knowledge of email handling and RFCs, some HTML & JS<br />
<br />
Difficulty<br />
<br />
Medium<br />
<br />
Probable Mentors<br />
<br />
Carsten Schmitz (c_schmitz)<br />
<br />
Thibault LeMeur (lemeur)<br />
<br />
==LimeSurvey 1: File Upload question type==<br />
<br />
The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:<br />
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)<br />
*Extensive configuration options for the question type like<br />
**How many files are required, minimum and maxim number of files,<br />
**maximum/minimum upload size,<br />
**Allowed file types<br />
*Safe!! storage in the file system, checks for file contents<br />
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl<br />
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses<br />
*Provide possible hooks for third party processing tools<br />
<br />
'''Skills'''<br />
<br />
PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
c_schmitz (Carsten Schmitz)<br />
<br />
==LimeSurvey 1: Authentication framework==<br />
<br />
The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.<br />
<br />
The generic authentication framework must define the following services:<br />
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br />
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...<br />
* User provisionning:<br />
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).<br />
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey (only if the token for this user has not been already added).<br />
<br />
The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).<br />
<br />
'''Skills'''<br />
<br />
PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
lemeur (Thibault Le Meur)<br />
<br />
==LimeSurvey 2: Db Storage Engine==<br />
<br />
Develop an extensible plugin survey storage engine for LimeSurvey 2.<br />
<br />
<u>Description</u><br />
<br />
Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.<br />
<br />
For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.<br />
<br />
<u>Rationale</u><br />
<br />
Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey&rsquo;s functions we will the ease with which LimeSurvey can be developed in the long term.<br />
<br />
<u>Implementation</u><br />
<br />
This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.<br />
<br />
The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.<br />
<br />
<u>Requirements & Considerations</u><br />
<br />
The DB Engine must be able to do the following<br />
* ease development of additional '''question types, which will be developed as plugins'''<br />
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)<br />
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.<br />
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.<br />
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.<br />
* support survey resuming (where applicable)<br />
<br />
<u> Use Cases </u><br />
<br />
Think of these when writing your proposal<br />
# Questionnaire which has a special section displayed only if a user answers a chosen question in a specific way (i.e. branching)<br />
# Question on your favourite ice-cream, with an option "Other", upon which the user will be asked to enter his own choice (i.e. multi-datatype question types)<br />
# Questionnaire, which asks how many children you have and then loops a set of predefined questions that many times. (i.e. looping)<br />
<br />
<u> Your proposal </u><br />
<br />
Your proposal needs to be fairly detailed and must dig deep down to the implementation level, with good analysis of the performance. "Read the data from the user and store it in the database" is no good! How are you going to store it? What is the schema going to be? Does it satisfy the requirements, for branching, conditions, pluggable question types? Does it scale well? Is it efficient - what is the time complexity? Can I get summaries out of it in a reasonable time? All this needs to be addressed. Early submissions are accepted by both mentors and suggestions and comments will be given (:wink:).<br />
<br />
<u>Field Naming and Database Extensibility Methodologies</u><br />
<br />
An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to &lsquo;freeze&rsquo; the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn&rsquo;t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations &ndash; sometimes running up against database limitations regarding the number of fields per table.<br />
<br />
An alternative is a &lsquo;normalised&rsquo; database topology where a single table is created to store all survey responses &ndash; one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.<br />
<br />
In a perfect world LimeSurvey would allow users to choose either methodology &ndash; either at an installation level or even on a per-survey level.<br />
<br />
Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
jasebo (Jason Cleeland)<br />
<br />
macduy (Mac Duy Hai)<br />
<br />
==LimeSurvey 2: Template Editor==<br />
<br />
Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.<br />
<br />
'''Skills'''<br />
<br />
One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.<br />
<br />
'''Difficulty'''<br />
<br />
You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.<br />
<br />
'''Probable Mentors'''<br />
<br />
Mazi<br />
<br />
==LimeSurvey 2: Mini-projects==<br />
<br />
Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:<br />
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:<br />
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it<br />
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error"<br />
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.<br />
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.<br />
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.<br />
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List<br />
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.<br />
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality<br />
**'''Batch import:''' import users through CSV, XML, etc...<br />
**'''Batch processing:''' Add an interface to manipulate (add & modify) several users at once<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JavaScript & jQuery<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Mac Duy Hai (macduy)<br />
<br />
==LimeSurvey 2: Template/Theme Editor==<br />
<br />
The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.<br />
<br />
The overview of the modules can be seen here:<br />
<br />
[[File:theme_roller.png]]<br />
<br />
It&rsquo;ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)<br />
<br />
The following mock-up will give us a better view:<br />
<br />
Moderate[[File:theme_editor_small.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Lime Survey Social - Facebook Application==<br />
<br />
The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.<br />
<br />
The facebook has the following modules (we can add more. This is primary draft.)<br />
*All Survey related core features. (Create, Edit, Delete, Administer etc)<br />
*Gain reward points.<br />
*Use reward points to create more surveys.<br />
*Spread the surveys ...... and more<br />
<br />
The idea can be extended to other social networks<br />
<br />
[[File:fb_overview.png]]<br />
<br />
The mock-ups :<br />
<br />
[[File:facebook app.png]]<br />
<br />
[[File:canvas.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Facebook API.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Integration of Poll Questions==<br />
<br />
Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.<br />
<br />
The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback &ldquo;about the survey&rdquo; at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).<br />
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.<br />
<br />
A simple mock-up for this:<br />
<br />
[[File:chat.png]]<br />
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.<br />
<br />
We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Survey Community Project==<br />
<br />
Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.<br />
<br />
For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Web and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Jason Cleeland (jasebo)<br />
<br />
==LimeSurvey 2: Condition Engine==<br />
<br />
[[File:addNewCondition1.png]]<br />
<br />
Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...<br />
<br />
This projects will at least end up with:<br />
* A working GUI to design complex conditions:<br />
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br />
** an atomic condition representation can be<br />
<br />
<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight><br />
** an atomic condition editor will implement<br />
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br />
*** meta operators surch as 'Not displayed'<br />
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)<br />
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition<br />
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JQuery and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
Thibault Le Meur (lemeur)<br />
<br />
=We want your ideas!=<br />
<br />
What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.<br />
<br />
=More Information=<br />
<br />
==LimeSurvey Google's Summer of Code 2010==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010 Limesurvey GSoC 2010]<br />
<br />
An introduction to LimeSurvey and our application for this years Google Summer of Code<br />
<br />
==Getting Started==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC]<br />
<br />
How to Get Started With LimeSurvey:<br />
<br />
- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!<br />
<br />
==Frequently Asked Questions==<br />
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]<br />
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=LimeSurvey_2_development_demo_test_ride&diff=1878LimeSurvey 2 development demo test ride2010-03-22T17:24:03Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Access to the Developer's Demo website=<br />
<br />
'''URL:''' http://devdemo2.limesurvey.org<br />
<br />
'''Username:''' root<br />
<br />
'''Password:''' root<br />
<br />
=Testing the Dashboard=<br />
<br />
After successful log-in, click on '''Dashboard'''.<br />
<br />
==Notes:==<br />
* You are encouraged to break things, but '''don't delete stuff, except for''' the users with usernames ''jimmy01, jimmy02'' and ''jimmy03'', which you can recreate by importing them from a CSV file below (use the "CSV Import" tab of Users widget)<br />
* To access an example '''Survey Dashboard''', locate the '''Surveys''' widget, find and click on the survey called '''"Mandatory Survey"''' and click on "Dashboard" that appears in the 'action' row<br />
* You can drag and drop items from Users widget onto the Security Groups widget<br />
* Best viewed in Firefox<br />
<br />
<div class="simplebox">'''<span style='color:#FF0000'>Bug reports go to</span>''' http://bugs.limesurvey.org/, select "Bug Reports v2.x" category</div><br />
<br />
===File for testing User CSV Import: [[Media:users.csv|Download file]]===<br />
<br />
=Response Viewer=<br />
<br />
After you login, you can test the new Response Viewer by going to '''http://devdemo2.limesurvey.org/response_viewer/index/4''' ([http://devdemo2.limesurvey.org/response_viewer/index/4 link])<br />
<br />
= Screenshots=<br />
<br />
<div class="simplebox"><br />
<br />
'''Dashboard''' [[File:020809.jpg]]<br />
<br />
</div><br />
<br />
<div class="simplebox"><br />
<br />
'''Response Viewer''' [[File:ls-1708.jpg]]<br />
<br />
</div></div>Macduyhttps://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2010&diff=2479Project ideas for GSOC 20102010-03-21T21:16:03Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Welcome=<br />
<br />
Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_eligibility eligible candidate] for the GSoC program.<br />
<br />
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 [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)<br />
<br />
=Project ideas=<br />
<br />
==Example Format...==<br />
<br />
Describe the idea here in general terms<br />
<br />
'''Skills'''<br />
<br />
Explain what sort of coding skills would be needed for a student to implement this project<br />
<br />
'''Difficulty'''<br />
<br />
Explain the level of difficulty involved<br />
<br />
'''Probable Mentors'''<br />
<br />
Put your name (and tag) here if you are willing to mentor a student for this idea<br />
<br />
==LimeSurvey 1: File Upload question type==<br />
<br />
The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:<br />
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)<br />
*Extensive configuration options for the question type like<br />
**How many files are required, minimum and maxim number of files,<br />
**maximum/minimum upload size,<br />
**Allowed file types<br />
*Safe!! storage in the file system, checks for file contents<br />
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl<br />
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses<br />
*Provide possible hooks for third party processing tools<br />
<br />
'''Skills'''<br />
<br />
PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
c_schmitz (Carsten Schmitz)<br />
<br />
==LimeSurvey 1: Authentication framework==<br />
<br />
The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.<br />
<br />
The generic authentication framework must define the following services:<br />
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br />
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...<br />
* User provisionning:<br />
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).<br />
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey (only if the token for this user has not been already added).<br />
<br />
The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).<br />
<br />
'''Skills'''<br />
<br />
PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Probable Mentors'''<br />
<br />
lemeur (Thibault Le Meur)<br />
<br />
==LimeSurvey 2: Db Storage Engine==<br />
<br />
Develop an extensible plugin survey storage engine for LimeSurvey 2.<br />
<br />
<u>Description</u><br />
<br />
Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.<br />
<br />
For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.<br />
<br />
<u>Rationale</u><br />
<br />
Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey&rsquo;s functions we will the ease with which LimeSurvey can be developed in the long term.<br />
<br />
<u>Implementation</u><br />
<br />
This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.<br />
<br />
The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.<br />
<br />
<u>Requirements & Considerations</u><br />
<br />
The DB Engine must be able to do the following<br />
* ease development of additional '''question types, which will be developed as plugins'''<br />
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)<br />
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.<br />
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.<br />
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.<br />
* support survey resuming (where applicable)<br />
<br />
<u>Field Naming and Database Extensibility Methodologies</u><br />
<br />
An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to &lsquo;freeze&rsquo; the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn&rsquo;t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations &ndash; sometimes running up against database limitations regarding the number of fields per table.<br />
<br />
An alternative is a &lsquo;normalised&rsquo; database topology where a single table is created to store all survey responses &ndash; one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.<br />
<br />
In a perfect world LimeSurvey would allow users to choose either methodology &ndash; either at an installation level or even on a per-survey level.<br />
<br />
Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
jasebo (Jason Cleeland)<br />
<br />
macduy (Mac Duy Hai)<br />
<br />
==LimeSurvey 2: Template Editor==<br />
<br />
Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.<br />
<br />
'''Skills'''<br />
<br />
One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.<br />
<br />
'''Difficulty'''<br />
<br />
You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.<br />
<br />
'''Probable Mentors'''<br />
<br />
Mazi<br />
<br />
==LimeSurvey 2: Mini-projects==<br />
<br />
Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:<br />
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:<br />
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it<br />
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error"<br />
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.<br />
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.<br />
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.<br />
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List<br />
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.<br />
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality<br />
**'''Batch import:''' import users through CSV, XML, etc...<br />
**'''Batch processing:''' Add an interface to manipulate (add & modify) several users at once<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JavaScript & jQuery<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Mac Duy Hai (macduy)<br />
<br />
==LimeSurvey 2: Template/Theme Editor==<br />
<br />
The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.<br />
<br />
The overview of the modules can be seen here:<br />
<br />
[[File:theme_roller.png]]<br />
<br />
It&rsquo;ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)<br />
<br />
The following mock-up will give us a better view:<br />
<br />
Moderate[[File:theme_editor_small.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Lime Survey Social - Facebook Application==<br />
<br />
The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.<br />
<br />
The facebook has the following modules (we can add more. This is primary draft.)<br />
*All Survey related core features. (Create, Edit, Delete, Administer etc)<br />
*Gain reward points.<br />
*Use reward points to create more surveys.<br />
*Spread the surveys ...... and more<br />
<br />
The idea can be extended to other social networks<br />
<br />
[[File:fb_overview.png]]<br />
<br />
The mock-ups :<br />
<br />
[[File:facebook app.png]]<br />
<br />
[[File:canvas.png]]<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Facebook API.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Integration of Poll Questions==<br />
<br />
Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.<br />
<br />
The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback &ldquo;about the survey&rdquo; at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).<br />
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.<br />
<br />
A simple mock-up for this:<br />
<br />
[[File:chat.png]]<br />
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.<br />
<br />
We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
==LimeSurvey 2: Survey Community Project==<br />
<br />
Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.<br />
<br />
For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, Web and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
Moderate<br />
<br />
'''Probable Mentors'''<br />
<br />
Jason Cleeland (jasebo)<br />
<br />
==LimeSurvey 2: Condition Engine==<br />
<br />
[[File:addNewCondition1.png]]<br />
<br />
Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...<br />
<br />
This projects will at least end up with:<br />
* A working GUI to design complex conditions:<br />
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br />
** an atomic condition representation can be<br />
<br />
<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight><br />
** an atomic condition editor will implement<br />
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br />
*** meta operators surch as 'Not displayed'<br />
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)<br />
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition<br />
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).<br />
<br />
'''Skills'''<br />
<br />
PHP, CakePHP, JQuery and User Interface Design Skills<br />
<br />
'''Difficulty'''<br />
<br />
High<br />
<br />
'''Probable Mentors'''<br />
<br />
Thibault Le Meur (lemeur)<br />
<br />
=We want your ideas!=<br />
<br />
What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.<br />
<br />
=More Information=<br />
<br />
==LimeSurvey Google's Summer of Code 2010==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010 Limesurvey GSoC 2010]<br />
<br />
An introduction to LimeSurvey and our application for this years Google Summer of Code<br />
<br />
==Getting Started==<br />
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC]<br />
<br />
How to Get Started With LimeSurvey:<br />
<br />
- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!<br />
<br />
==Frequently Asked Questions==<br />
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]<br />
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=LimeSurvey_GSoC_2010&diff=2011LimeSurvey GSoC 20102010-03-07T01:38:01Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Google Summer of Code 2010=<br />
<br />
LimeSurvey is applying to be involved in the Google Summer of Code for 2010<br />
<br />
=General Information=<br />
<br />
Google has been continuously supporting Open Source Projects and students coming together since 2005 through its ''Google Summer of Code Programs''. GSoC 2010 has been announced and is On!<br />
<br />
LimeSurvey was accepted as a mentoring organisation for the first time in 2009, and is hopeful and excited about he opportunity to participate again in 2010. We plan to give students an excellent environment and platform to '''learn''' and most importantly to have '''fun''' (:lol:)!<br />
<br />
The LimeSurvey community, at the same time, will benefit by students' participation and fresh eyes and ideas.<br />
<br />
Find out more about our program in 2010 at [http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010&structure;=LimeSurvey+Development LimeSurvey GSoC 2010]<br />
<br />
==Google Summer of Code Program Information==<br />
<br />
Google Summer of Code is a great program both for Open Source organizations like LimeSurvey as well as students because it gives a platform where several tasks on Open Source Projects are done by students and students in return get a stipend from Google.<br />
<br />
There's a lot more information available in Google's Summer of Code [http://code.google.com/opensource/gsoc/2009/faqs.html FAQ] and [http://code.google.com/p/google-summer-of-code/ Knowledge Base]. You can also join #gsoc on irc.freenode.net to get feedback or ask questions about Google Summer of Code in real time.<br />
<br />
==LimeSurvey Specific Information==<br />
<br />
Welcome to the LimeSurvey Community (:biggrin:). LimeSurvey is an open source survey engine that allows people to create and deploy surveys (from marketing to academic to engineering applications). LimeSurvey is written in PHP and used by many high profile organizations including [https://wiki.ubuntu.com/ServerTeam '''Ubuntu Server Team'''], [http://foundation.gnome.org/ '''GNOME Foundation'''] and [http://www.vorarlberg.at/ '''Office of the Austrian Vorarlberg State Government''']<br />
<br />
Limesurvey is loved and used by many Universities, Students, Medical Institutes, non-profit organisations, marketing companies and more around the world. In the 2004 '''U.S. presidential election''', the [http://www.verifiedvoting.org/article.php?id=5207 '''Verified Voting Foundation'''] used PHPSurveyor (as LimeSurvey was then known) to gather data about voting irregularities. Sourceforge provide LimeSurvey as a free application for open source projects. LimeSurvey keeps turning up in new places.<br />
<br />
It's loved because it is free, flexible and constantly improving. It's constantly improving because it has a dedicated and committed team of developers who love the challenge and satisfaction of using and building such a tool.<br />
<br />
LimeSurvey is widely used. It has been directly downloaded from Sourceforge over '''130,000 times''' in the last 12 months alone, and is also distributed as a package in the '''Ubuntu Linux Distribution''', and included as a pre-installed application in many standard Web Hosting packages (such as '''Fantastico''').<br />
<br />
LimeSurvey is recognised as a leader in its field. On November 29, 2007 LimeSurvey won the '''1st prize award''' at the [http://www.trophees-du-libre.org/index.php?lang=en '''Les Troph&eacute;es du Libre'''] contest in the category Corporate Management. In 2008 LimeSurvey was nominated in the category Best Project for the Enterprise in the SourceForge.net '''Community Choice Awards 2008'''. LimeSurvey was succesful in being selected as a mentoring organisation for the Google Summer of Code in 2009.<br />
<br />
LimeSurvey is the biggest, most active and most exciting open source online survey project, and we're building on our success by creating a whole new version of the tool.<br />
<br />
LimeSurvey Version 2 is a whole new - built from the ground-up - version that will revolutionise online survey design and use.<br />
<br />
More importantly, it's a perfect opportunity for a GSoC student like yourself to get involved early in a project that has a strong history and an even stronger future. Our community is welcoming and fun. One of our students from 2009 has now become the project lead for LimeSurvey 2. It's a classic case of the student becoming a master!<br />
<br />
==GSoC Student Aspirants==<br />
<br />
Please visit our [http://docs.limesurvey.org/tiki-index.php?page=LimeSurvey+2+Project+Ideas+for+GSOC+2010 ideas page] and see if any idea interests you. If you have an idea of your own, then develop it. If any idea excites you, and you want to implement that feature during the summer of 2010, see how you can [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started get started] on it. Come and join us on the IRC channel on freenode (#limesurvey) and talk about what you want to do.<br />
<br />
==LimeSurvey Mentors==<br />
<br />
The following mentors are willing to Mentor students during Google Summer of Code 2010 program.<br />
<br />
Others who are willing to mentor can write their name and details below along with the Idea they are willing to mentor. '''Potential Mentors, please do not forget to put your ideas on the [http://docs.limesurvey.org/tiki-index.php?page=LimeSurvey+2+Project+Ideas+for+GSOC+2010 ideas page] and contact [mailto:jason@cleeland.org| program administrator]'''<br />
<br />
{|<br />
|<center>'''Mentor Name'''</center>||<center>'''Nick'''</center>||<center>'''Idea'''</center><br />
|-<br />
|<center>Jason Cleeland</center>||<center>jasebo</center>||<center>Currently Thinking About It</center><br />
|-<br />
|<center>Carsten Schmitz</center>||<center>c_schmitz</center>||<center>File upload question type in LimeSurvey 1</center><br />
|-<br />
|<center>Marcel Minke</center> <center>[http://docs.limesurvey.org/tiki-index.php?page=UserPage Mazi||Mazi]</center>||<center>Template editor?</center><br />
|-<br />
|<center>Mac Duy Hai</center>||<center>[[UserPage macduy||macduy]]</center>||<center>Database Storage Engine, Mini-projects</center><br />
|-<br />
|<br />
|}<br />
<br />
==More Information==<br />
<br />
===Getting Started===<br />
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started GSoC Getting Started]<br />
<br />
How to Get Started With LimeSurvey:<br />
<br />
- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!<br />
<br />
===Project Ideas Page===<br />
*[http://docs.limesurvey.org/tiki-index.php?page=LimeSurvey+2+Project+Ideas+for+GSOC+2010 GSoC Ideas Page]<br />
<br />
The LimeSurvey Community Ideas Page:<br />
<br />
- ideas that the community have come up with and would love to help you create<br />
<br />
===Frequently Asked Questions===<br />
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google Summer of Code Faqs]<br />
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=LimeSurvey_2_development_demo_test_ride&diff=1879LimeSurvey 2 development demo test ride2009-11-20T18:49:43Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Access to the Developer's Demo website=<br />
<br />
'''URL:''' http://devdemo2.limesurvey.org<br />
<br />
'''Username:''' root<br />
<br />
'''Password:''' root<br />
<br />
=Testing the Dashboard=<br />
<br />
After successful log-in, click on '''Dashboard'''.<br />
<br />
==Notes:==<br />
* You are encouraged to break things, but '''don't delete stuff, except for''' the users with usernames ''jimmy01, jimmy02'' and ''jimmy03'', which you can recreate by importing them from a CSV file below (use the "CSV Import" tab of Users widget)<br />
* To access an example '''Survey Dashboard''', locate the '''Surveys''' widget, find and click on the survey called '''"Mandatory Survey"''' and click on "Dashboard" that appears in the 'action' row<br />
* You can drag and drop items from Users widget onto the Security Groups widget<br />
* Best viewed in Firefox<br />
<br />
<div class="simplebox">'''<span style='color:#FF0000'>Bug reports go to</span>''' http://bugs.limesurvey.org/, select "Bug Reports v2.x" category</div><br />
<br />
===File for testing User CSV Import: [[Media:users.csv|Download file]]===<br />
<br />
=Response Viewer=<br />
<br />
After you login, you can test the new Response Viewer by going to '''http://devdemo2.limesurvey.org/response_viewer/index/4''' ([http://devdemo2.limesurvey.org/response_viewer/index/4 link])<br />
<br />
= Screenshots=<br />
<br />
<div class="simplebox"><br />
<br />
'''Dashboard''' [[File:020809.jpg]]<br />
<br />
</div><br />
<br />
<div class="simplebox"><br />
<br />
'''Response Viewer''' [[File:ls-1708.jpg]]<br />
<br />
</div></div>Macduyhttps://www.limesurvey.org/manual/index.php?title=Expression_engine_for_conditions&diff=4463Expression engine for conditions2009-09-16T19:27:31Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Introduction=<br />
<br />
A condition is simply a boolean expression, which may consist of several, not necessarily boolean, expression. When implementing a Conditions feature into LS2, it makes sense to look at the most basic building block of such a feature - expressions - and develop a powerful engine, that is be able to '''construct, evaluate, parse and store expressions, yet is isolated from its target application'''.<br />
<br />
=Constructing expressions=<br />
<br />
Expressions are built from strings representing the expression in postfix notation (also known as Reverse Polish Notation or RPN). Postfix notation is extremely simple to parse, compact, parenthesis-free, precedence unambiguous etc... it's just awesome. An expression, no matter how complicated, nested or how many variables it contains, can be compactly stored as a single string.<br />
<br />
Let's create a simple expression object, to evaluate '''(6 + 7) * 11 < 12*12''' (this is false by the way...)<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
$exp = ExpressionEngine::create("6 7 + 11 * 12 sqr <");<br />
<br />
</syntaxhighlight><br />
<br />
Individual tokens are separated by space. You can put as many spaces as you want, but always at least one. ''$exp'' now stores the expression and we can evaluate it by calling ''evaluate()'' on it<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
$exp->evaluate(); // returns FALSE<br />
<br />
</syntaxhighlight><br />
<br />
That's it. You can also construct an expression using classes provided by the engine. For example:<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
$exp = new LeqExpression(new ConstantExpression(12), new AddExpression(new ConstantExpression(10), new ConstantExpression(3)));<br />
<br />
$exp->evaluate(); // returns TRUE<br />
<br />
</syntaxhighlight><br />
<br />
Why would you want to construct an expression this way? Well, imagine you are writing an UI for the Conditions feature. You need to represent the currently build expression in a OOP way. You would use these expression classes provided for you. Then you'll need to convert it to postfix notation for storage. How would you do that? Easy:<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
$exp->toPostfix(); // returns "12 10 3 + <"<br />
<br />
</syntaxhighlight><br />
<br />
Expressions in postfix notation are generally hard for humans to comprehend. Can we convert to normal, infix notation, so that the user can read them? Sure:<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
$exp->toInfix(); // returns "(12<(10+3))"<br />
<br />
</syntaxhighlight><br />
<br />
=Variables=<br />
<br />
Expressions so far were constant and always returned the same value. Let's add variables. Variable names are prefixed by '''@''' in the postfix notation, and enclosed in '''{ }''' in infix notation. Variable names should not contain a space. Although the ExpressionEngine imposes no further restrictions, it's best to use sensible ones. ''@000'' is certainly a bad idea.<br />
<br />
Variables are late-bound, which means they are not resolved (their value is not evaluated) until the whole expression is evaluated. To attach values to the variable names, use '''ExpressionEngine::bind(array("variable_name" => "value" ...) )'''. For example:<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
$exp = ExpressionEngine::create("6 7 + 11 * @a sqr <");<br />
<br />
ExpressionEngine::bind(array("a" => 12));<br />
<br />
$exp->evaluate(); // Returns TRUE<br />
<br />
ExpressionEngine::bind(array("a" => 11));<br />
<br />
$exp->evaluate(); // Returns FALSE<br />
<br />
</syntaxhighlight><br />
<br />
Variables offer a simple but powerful gateway for passing data to expressions.<br />
<br />
=Strings=<br />
<br />
Strings are delimited using double quotes. To include double quotes inside the string, type them twice in a row.<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
echo ExpressionEngine::create('"She said: ""no"""')->evaluate();<br />
<br />
echo ExpressionEngine::createFromInfix('"She said: ""no"""')->evaluate();<br />
<br />
// prints twice: She said: "no"<br />
<br />
</syntaxhighlight><br />
<br />
Comparison operators work on strings as well. If expression on either side of the comparison operator is a string, the operator automatically performs a string-based comparison.<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
ExpressionEngine::createFromInfix('10<5')->evaluate(); // false<br />
<br />
ExpressionEngine::createFromInfix('"10"<"5"')->evaluate(); // true<br />
<br />
ExpressionEngine::createFromInfix('"10"<5')->evaluate(); // true<br />
<br />
</syntaxhighlight><br />
<br />
=Custom operators and Expressions=<br />
<br />
The ExpressionEngine comes with only basic operators, such as those for arithmetic, comparison and logic. However, it allows you to define your custom expressions and 'hooks' (called ''string literals''), that the parser will recognize and create. Also, there are several base classes providing you with boilerplate code (see code for details). There are no restrictions on Expression names, but again, if you bind 0 as your literal, you'll obviously run into problems.<br />
<br />
==IExpression==<br />
<br />
Every expression must be a subclass of the '''IExpression''' interface. It must implement these functions:<br />
*evaluate() - return expression value<br />
*toInfix() - return infix notation<br />
*toPrefix() - return postfix notation<br />
<br />
==Example custom expression==<br />
<br />
Let's create a sample custom expression. This one will be called '''Sparta''' and will always return 300. The code is:<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
/**<br />
* Defining some custom expression. This one always returns 300, because<br />
* THIS IS SPARTA!!!!!!!!<br />
*/<br />
<br />
class SpartaExpression implements IExpression {<br />
<br />
public function evaluate() {<br />
<br />
return 300;<br />
<br />
}<br />
<br />
public function toPrefix() {<br />
<br />
return "sparta";<br />
<br />
}<br />
<br />
public function toInfix() {<br />
<br />
return "sparta";<br />
<br />
}<br />
<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
Before being able to use, we need to register it with the ExpressionEngine.<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
ExpressionEngine::register('sparta');<br />
<br />
</syntaxhighlight><br />
<br />
The Engine will automatically look for SpartaExpression and add it to the list of recognized expression literals. We can now use our new expression:<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
$exp = ExpressionEngine::create("30 10 * sparta ==");<br />
<br />
$exp->evaluate(); // returns TRUE<br />
<br />
</syntaxhighlight><br />
<br />
==Example custom operator==<br />
<br />
Let's create an operator, which accepts two expressions and returns the one that's larger. We will make use of the abstract base class '''ABinaryExpression''', because this class implements the toInfix and toPrefix functions for us and it also defines a constructor for us, storing the first expression in the $left variable and the second one in $right. All we need to do is to provide a getLiteral() function, which should return the literal we want the operator to be recognized by.<br />
<br />
<syntaxhighlight lang="php" enclose="div"><br />
<br />
class MaxExpression extends ABinaryExpression {<br />
<br />
public function evaluate() {<br />
<br />
$left_value = $this->left->evaluate();<br />
<br />
$right_value = $this->right->evaluate();<br />
<br />
if ($left_value > $right_value) {<br />
<br />
return $left_value;<br />
<br />
} else {<br />
<br />
return $right_value;<br />
<br />
}<br />
<br />
}<br />
<br />
public function getLiteral() {<br />
<br />
return "max";<br />
<br />
}<br />
<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
Again, register the 'max' literal and the custom operator is good to go. Look at ABinaryExpression for more details.<br />
<br />
=Security and Safety=<br />
<br />
ExpressionEngine is extremely safe, because during parsing every literal is checked for existence and thus it is impossible to pass any harmful code. When implementing custom operators and expressions, it is advised they are checked for safety and don't perform any potentionally risky operations.<br />
<br />
=Concluding notes=<br />
<br />
Starting with an Expression Engine, there's still a long way to go in implementing a Conditions feature in LS2. However, hopefully the engine will provide a solid base, on which custom expression can be easily developed and maintained, and which lifts the burden of having to write boilerplate code, from the developers.<br />
<br />
Advanced users, who wouldn't like to rely on a GUI to build a Condition, would probably prefer to bust out some expressions by writing them manually in infix notation. Hence an infix-to-postfix parser would certainly come in handy. <strike>For those interested writing such a beast, this can be useful</strike> An infix notation parser has been implemented following this algorithm: http://en.wikipedia.org/wiki/Operator-precedence_parser</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=LimeSurvey_2_development_demo_test_ride&diff=1880LimeSurvey 2 development demo test ride2009-09-03T17:11:23Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
=Access to the Developer's Demo website=<br />
<br />
'''URL:''' http://devdemo2.limesurvey.org<br />
<br />
'''Username:''' root<br />
<br />
'''Password:''' test<br />
<br />
=Testing the Dashboard=<br />
<br />
After successful log-in, click on '''Dashboard'''.<br />
<br />
==Notes:==<br />
* You are encouraged to break things, but '''don't delete stuff, except for''' the users with usernames ''jimmy01, jimmy02'' and ''jimmy03'', which you can recreate by importing them from a CSV file below (use the "CSV Import" tab of Users widget)<br />
* To access an example '''Survey Dashboard''', locate the '''Surveys''' widget, find and click on the survey called '''"Mandatory Survey"''' and click on "Dashboard" that appears in the 'action' row<br />
* You can drag and drop items from Users widget onto the Security Groups widget<br />
* Best viewed in Firefox<br />
<br />
<div class="simplebox">'''<span style='color:#FF0000'>Bug reports go to</span>''' http://bugs.limesurvey.org/, select "Bug Reports v2.x" category</div><br />
<br />
===File for testing User CSV Import: [[Media:users.csv|Download file]]===<br />
<br />
=Response Viewer=<br />
<br />
After you login, you can test the new Response Viewer by going to '''http://devdemo2.limesurvey.org/response_viewer/index/4''' ([http://devdemo2.limesurvey.org/response_viewer/index/4 link])<br />
<br />
= Screenshots=<br />
<br />
<div class="simplebox"><br />
<br />
'''Dashboard''' [[File:020809.jpg]]<br />
<br />
</div><br />
<br />
<div class="simplebox"><br />
<br />
'''Response Viewer''' [[File:ls-1708.jpg]]<br />
<br />
</div></div>Macduyhttps://www.limesurvey.org/manual/index.php?title=GSOC_Dashboard_Project_Development_Log&diff=1422GSOC Dashboard Project Development Log2009-08-17T14:38:24Z<p>Macduy: </p>
<hr />
<div><br />
=-Widget Sharing=<br />
<br />
<div class="simplebox"><br />
<br />
1. To share, click the "Hands" pictogram:<br />
<br />
[[File:share.png]]<br />
<br />
2. Fill in dimensions (prefilled by default for your convenience)<br />
<br />
[[File:ls-29071.jpg]]<br />
<br />
3. Wheeeeeyyy!<br />
<br />
[[File:ls-29072.jpg]]</div><br />
<br />
=Screenshots=<br />
<br />
<div class="simplebox">[[File:020809.jpg]]<br />
<br />
'''From: 2th August 2009, r7404: Dashboard tabs, Widget Options, Better search, UI Cleanup'''<br />
<br />
</div><br />
<br />
<div class="simplebox">[[File:ls-2907.jpg]]<br />
<br />
'''From: 29th July 2009, r7364: ''' Grips, Drag'n'Drop, Beefed-up notifications<br />
<br />
</div><br />
<br />
=-Performance Review=<br />
<br />
<div class="simplebox"><br />
<br />
After Code Overhaul and jqGrid Data Prefetching, I'm proud to say that the Dashboard has great performance, loading fast almost independently of the number of widgets and out-performing the original static Admin Dashboard by miles, even when displaying 3x as many<br />
<br />
widgets.<br />
<br />
[[File:lsdb-perf2.png]]<br />
<br />
Notes:<br />
*''All tests used 4 jqGrid-enabled widgets per dashboard. CakePHP caching is disabled''<br />
*''All measurements are rough and made on my machine at different times. Account for cca 1-2 second uncertainty'':<br />
*'''''Total Requests''''': number of requests made to the server, i.e. initial page request + ajax requests<br />
*'''''Total Wait Time''''': amount of time between pressing 'Enter' in browser and having a fully functional dashboard (all controls active, all jqGrids loaded)<br />
<br />
==Benchmark==<br />
<br />
http://spreadsheets.google.com/pub?ke<br />
<br />
<span style='color:#FF0000'>Without Prefetching (estimated wait time)</span><br />
<br />
<span style='color:#0000FF'>With Prefetching (Total Request time as measured by DebugKit)</span><br />
<br />
</div><br />
<br />
=Links=<br />
*[https://www.ohloh.net/accounts/macduy/messages/timeline Timeline view]<br />
<br />
=Diary=<br />
<br />
====-May 14th - 17th====<br />
*Finished proposal<br />
*'''Experiment''': Execute a script from an inline script tag placed in a file, which is fetched through ajax - <span style='color:#00FF00'>success</span><br />
**''it is important that this works'': This keeps scripts small, modular, relevant in context, coherent in their tasks and they are only loaded when needed.<br />
**e.g.: ''In a page, a small central script detects if a dashboard is to be displayed - if so, it does a ajax-request for the 'dashboard' loader page, which contains an inline script loading the needed scripts. The parent page does not need to load or even know anything about these 'dashboard' scripts.''<br />
<br />
====-May 18th - 24th====<br />
*Using above mechanism, a sample dashboard has been dynamically loaded into the 'Workbench' (previously 'Dashboard') page.<br />
*HTML/CSS Reconstruction of the test widget<br />
*Chained widget loading (normal page -> loads dashboard -> loads widgets)<br />
*Widget implementation: widget as plugin controllers (access via ''/widgets/widget_type/action/parameter(s)'')<br />
<br />
====-May 25th - 31th====<br />
*top-level navigation, content switching with smooth transitions<br />
*OO implementation of Widgets in JS<br />
*Simple dashboard edit mode: Widget dragging.<br />
*Two-column layout; widgets can be moved inside and between them<br />
*Widgets remember position<br />
<br />
====-June 1st - 7th====<br />
*Dashboard communication protocol (see picture above)<br />
*'''Experiment''': Return widget content as XML, with content and script for execution - <span style='color:#00FF00'>success</span><br />
*Successfully implemented the Widget XML Format (see above)<br />
**content as well as scripts can be passed<br />
**script has default access to its widget only<br />
**scripts can be triggered at specified events, e.g. onload, onupdate...<br />
*Re-integrating jqGrid:<br />
**new method allows only pure data to be passed to jqGrid, with the widget creating the remaining markup and jtooltips dynamically<br />
<br />
====-June 29th - July 5th====<br />
*Dashboard XML<br />
*Merge of '''boot.js''' into '''dashboard.js'''<br />
*Context sensitive dashboard (parametrized dashboards)<br />
** Survey Summary widget for the Survey Dashboard<br />
*Add Widget dialog, process streamlined with the Dashboard Edit mode.<br />
*jqGrid automation (implemented as Dashboard 'extension')<br />
*jqGrid additions:<br />
**Quicksearch<br />
**Click-Drag selectors + Selection Presets<br />
*'''Widgets:''' Users, Surveys, Announcements<br />
<br />
====-June 6th - July 12th====<br />
*Dashboard ownership and security<br />
*'''Light GUI Skin'''<br />
**Widgets now draggable by default<br />
**Fluid witdh and height<br />
*'''Widgets''': Announcements, Assignments, Assignment groups<br />
*All widgets now support interactive deletion (i.e. displays a confirmation dialog)<br />
<br />
====-July 13th - July 19th====<br />
*'''Code Overhaul''' - consolidated all widgets into a single controller (Dashboard), leading to a performance improvement<br />
**Previously, initial loading of a dashboard required (1 + number of widgets) ajax requests.<br />
**Now, only 1 intial request is made per dashboard, regardless of the number of widgets present<br />
*Default dashboard now available at http://server/dashboard<br />
*'''jqGrid Data Prefetch''' - jqGrid-enabled widgets now prefetch the table data, thus using <span style='color:#FF0000'>only 1 request at the start!</span><br />
**Massive performance improvement, means a dashboard with 20 jqGrid-enabled widgets loads almost as fast as one with only few (''depending on server power'')<br />
**''For comparison, see the Performance Review section above''<br />
<br />
====July 20th - July 26th====<br />
*Standalone dashboards - ground work for cross-site widget and dashboard sharing<br />
**''Has few bugs, needs fixing''<br />
*simple Growl-like notifications ''(using blockUI)''<br />
*Ajax-based CSV User import<br />
*jqGrid Draggables<br />
**e.g. moving users to a different security group using drag-and-drop<br />
*[Widgets Design Document], [UI Meeting 7 (25th July)]<br />
<br />
====July 27th - August 2nd====<br />
*Dashboard initial auto-setup<br />
*'''Widget Sharing:''' click on the "Hands" pictogram (first icon) on the Widget header to display the "Share Widget" dialog<br />
*'''Widget Secondary Options/Secondary Navigation'''<br />
*'''Dashboard Snapshot:''' Single-click saving of widget options and preferences<br />
*'''Dashboard Tabs:''' in-page tabs, complete with Back/Forward browser navigation + Undo close tab feature<br />
*jqGrid Quicksearch: further improvements on the custom simplified search interface for jqGrids.<br />
<br />
====August 3rd - August 9th====<br />
*Bug fixing<br />
<br />
====August 10th - August 16th====<br />
*'''Response Viewer: ''(Side-project)''''' App for viewing and managing responses.<br />
<br />
[[File:ls-1708.jpg]]</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=UI_meeting_7_(25th_July)&diff=3512UI meeting 7 (25th July)2009-07-25T14:42:10Z<p>Macduy: </p>
<hr />
<div><br />
=Summary=<br />
<br />
<div class="simplebox"><br />
<br />
==Charting Library==<br />
*comparison of some charting libraries: [Comparison of different Charting Libraries]<br />
**probable candidate, at least for prototyping: ezComponent<br />
*LS2 graphs only for basic / less advanced analysis, for complex analysis users should consider exporting data and analysing in a different software of choice<br />
<br />
==Survey Dashboards==<br />
*Widget suggestions: [Widgets Design Document]<br />
*SDs should be able to display multiple content - e.g. a "Questions Breakdown" widget displays a brief summary, clicking on "More" would display a full report<br />
**Opening a new browser tab is unacceptable; AJAX methods are considered:<br />
***Dashboard Tabs: Use jQueryUI tabs to display new content in a new tab. May put strain on browser if too many 'tabs' opened.<br />
***Lightbox: Easy to integrate using current $.blockUI method, however they appear unprofessional and not suitable for large content<br />
***1 Tab Method: Have only one tab to display content, with a back button that erases the content and takes the user back to the SD. A usable compromise.<br />
<br />
</div><br />
<br />
=Meeting Log=<br />
<br />
==-Introductions==<br />
<br />
<nowiki><br />
<br />
[14:36] dhardisty: by the way -- the web based IRC interface is broken, giving 500 internal server error: http://www.limesurvey.org/component/option,com_wrapper/Itemid,112/lang,en/<br />
<br />
[14:37] ant:dhardisty: it's possible that some people want to come to the meeting from the UI meeting page but then hit the server error<br />
<br />
[14:39] Mazi|away: where is this URL linked?<br />
<br />
[14:40] anthony.:dhardisty: on this page: http://docs.limesurvey.org/tiki-index.php?page=UI+Meeting&structure;=LimeSurvey+Development<br />
<br />
dhardisty: THe part that starts:<br />
<br />
dhardisty: But I've never used IRC before!<br />
<br />
dhardisty: If you would like to attend, but didn't understand much of the above, don't worry! Just follow these steps:<br />
<br />
dhardisty: 1. Visit Limesurvey's live chat (external link)<br />
<br />
Mazi: I will correct the link. we updated joomla so some links are broken<br />
<br />
[14:42] dhardisty: great, thanks<br />
<br />
[14:43] Mazi: if you notice any other broken links: http://bugs.limesurvey.org/view.php?id=3462<br />
<br />
[14:56] anthony.:dhardisty: also, the UTC time converter link on the UI meeting page needs to be updated :P<br />
<br />
dhardisty: I just posted that to the bug tracking page you mentioned<br />
<br />
[14:57] Mazi: I edited the link, can you check if it's correct?<br />
<br />
[14:58] dhardisty: looks good now! thanks<br />
<br />
[14:59] dhardisty: i just deleted my note from the bug tracker<br />
<br />
Mazi: k<br />
<br />
[15:01] Mazi: dhardisty, did you read http://www.docs.limesurvey.org/Widgets+Design+Document and http://docs.limesurvey.org/tiki-index.php?page=Comparison+of+different+charting+libraries&structure;=LimeSurvey+Development<br />
<br />
[15:03] dhardisty: yes, I read the first and glanced at the 2nd. I will read the charting library comparison more carefully now<br />
<br />
[15:04] macduy: hi<br />
<br />
Mazi: hey<br />
<br />
dhardisty: hi<br />
<br />
[15:05] Mazi: macduy, do you know if Daniel will join us?<br />
<br />
macduy: he didn't say :( but he is usually up at this time<br />
<br />
macduy: I'll let him know<br />
<br />
</nowiki><br />
<br />
==-Charting Libraries - Choice Criteria==<br />
<br />
<nowiki><br />
<br />
macduy: so, charting libraries :)<br />
<br />
[15:06] Mazi: k, would be nice to have him at this meeting so we can disucss charts<br />
<br />
[15:07] macduy: just in general, what criteria do we need to consider when choosing one?<br />
<br />
macduy: and how are we integrating it with LS2<br />
<br />
Mazi: 2. supported types<br />
<br />
Mazi: 3. support<br />
<br />
Mazi: 4. developemnt, 1 developer is a risk<br />
<br />
Mazi: 5. documentation<br />
<br />
[15:08] Mazi: my 2 cents<br />
<br />
dhardisty: 6. Attractiveness / understandability of graphs<br />
<br />
Mazi: definately<br />
<br />
Mazi: maybe 7. scalability/flexibility<br />
<br />
macduy: what would users expect from the graphs?<br />
<br />
[15:09] macduy: we are certain we are not using flash (afaik), so that's a downside on interactivity :(<br />
<br />
dhardisty: simple, with big enough fonts to read easily<br />
<br />
[15:10] anthony.:Mazi: rhey have to be easy to read<br />
<br />
dhardisty: from my perspective, the mtChart graphs are too fancy for their own good. But maybe that's just me<br />
<br />
dhardisty: and probably mtChart can produce more simple graphs<br />
<br />
[15:11] dhardisty: I'm going to check out the websites for each of the graphing options<br />
<br />
[15:12] Mazi: what about the option to switch between different libraries, after all it's mainly just x-axis/y-axis data which has to be passed to the charting engine<br />
<br />
macduy: Mazi is always very keen on horizontal bar charts :)<br />
<br />
Mazi: ohh yeah!<br />
<br />
dhardisty: also, this is too much for most users I think, but for myself it would be nice to have error bars on the bar charts<br />
<br />
macduy: as a remark, note that you can produce simple graphs using plain HTML<br />
<br />
[15:13] anthony.:Mazi: they are more easily to read and make it easier when having several options because the chart grows in length and not in width<br />
<br />
dhardisty: but I can just export to statistical software to do that, so it's no big deal<br />
<br />
macduy: yeah<br />
<br />
[15:14] macduy: I think we should limit ourselves to displaying graphs with small range of choices<br />
<br />
Mazi: we also have to keep in midn that there is not much time left for coding<br />
<br />
dhardisty: right<br />
<br />
macduy: yeah :(<br />
<br />
Mazi: k.<br />
<br />
anthony.:Mazi: what do you think about the kind of charts to be used?<br />
<br />
[15:15] Mazi: in LS1 it's single choice questions = pie chart and multiple opions = bar charts<br />
<br />
macduy: is this the "Question breakdown" ?<br />
<br />
Mazi: I think we should keep this and offer a switch for the first case to be able to also use bar charts<br />
<br />
Mazi: yes, macduy<br />
<br />
[15:16] macduy: yeah, to keep it simple<br />
<br />
macduy: every question type decides what it's default type is<br />
<br />
macduy: but there always be a switcher right next to the graph<br />
<br />
dhardisty: yes, I think the option to be able to change from one to the other is important, but definitely a default<br />
<br />
dhardisty: sounds good<br />
<br />
</nowiki><br />
<br />
==-A look at LS1 Statistics==<br />
<br />
<nowiki><br />
<br />
[15:17] macduy: Mazi: do you have a screenshot of a LS1 statistics?<br />
<br />
anthony.:Mazi: sec<br />
<br />
dhardisty: one question/issue: what about the scale of the y-axis on bar graphs?<br />
<br />
Mazi: http://docs.limesurvey.org/tiki-index.php?page=Statistics&structure;=English+Instructions+for+LimeSurvey<br />
<br />
[15:18] Mazi: these are the old JPGraph stats at the screenshots<br />
<br />
dhardisty: sometimes people want it from zero to a little above the max, but sometimes they want to compare only the range of the different bars, to clear see differences<br />
<br />
Mazi: some pcharts bar charts: http://www.marcel-minke.de/ls180/statistics_user.php?sid=96315<br />
<br />
[15:19] anthony.:dhardisty: so, let's say you had a question about how tall your respondants are<br />
<br />
[15:20] dhardisty: you might want it to go from 0 meters to 2.5 meters, but maybe it's better to see only 1.5 meters to 2.5 meters<br />
<br />
Mazi: dhardisty, adjusting the Y-scale is a feature only very few users will need<br />
<br />
anthony.:Mazi: I would prefer to export data to other stats tools for this case<br />
<br />
[15:21] dhardisty: so I guess the y-axis will always be zero to a little above the maximum value, in that case?<br />
<br />
macduy: probably<br />
<br />
Mazi: yeah<br />
<br />
macduy: I'd say people get confused when the y-axis does not start at zero and can produce some illusions<br />
<br />
[15:22] anthony.:dhardisty: yeah<br />
<br />
macduy: Re: http://www.marcel-minke.de/ls180/statistics_user.php?sid=96315<br />
<br />
macduy: there is a table and a graph<br />
<br />
dhardisty: so this is something we should tell the programmer to do, right? because some graphing programs will set the minimum on the y-axis to be the minimum value<br />
<br />
macduy: I was considering using table as another "view", so that a user can switch between different graph types AND a table<br />
<br />
[15:24] dhardisty: yes, if it's easy, tables would be nice<br />
<br />
dhardisty: is it too much to have three types -- bar, pie, and table?<br />
<br />
Mazi: in general I prefer to have a data overview (table) plus a chart<br />
<br />
[15:25] anthony.:Mazi: in Limesurvey 1 the general statistics only contain a table and you have to tick a checkbox to also display graphs<br />
<br />
[15:26] Mazi: even better: show data on the left and the chart right beside the data<br />
<br />
dqminh: hi guys<br />
<br />
Mazi: hi daniel<br />
<br />
dhardisty: yeah, that's good<br />
<br />
dhardisty: d<br />
<br />
dhardisty: hi!<br />
<br />
Mazi: dqminh, maybe you can catch up reading the log: http://pastebin.com/m573bc7db<br />
<br />
[15:27] Mazi: and share your thoughts afterwards. we have discussed requirements for chosing a library and some general stuff<br />
<br />
Mazi: one of the next issues might be "filtering data"<br />
<br />
[15:28] holch: Good morning or good afternoon, everyone.<br />
<br />
dhardisty: hi<br />
<br />
Mazi: holch, see http://pastebin.com/m573bc7db<br />
<br />
holch: Sorry for being late, hat a little fight with my wireless network.<br />
<br />
holch: OK, I will have a look.<br />
<br />
[15:29] macduy: dhardisty, 3 types is alright imo<br />
<br />
[15:30] macduy: but table + graph side by side is a good choice too!<br />
<br />
macduy: there's one 1 issue which I haven't resolved yet:<br />
<br />
macduy: widgets are displayed in 2 columns side by side<br />
<br />
macduy: so they have limited width :/<br />
<br />
holch: I also think that we should not offer too much choice.<br />
<br />
[15:31] macduy: hi dqminh, hi holch<br />
<br />
Mazi: macduy, where is the problem? data at the left one, chart at the right side<br />
<br />
Mazi: using horizontal bar charts everything can grow in lenght<br />
<br />
holch: When I do reports, I usually use 2-3 types of charts. Bar charts (horizontal/vertical), pie charts and line charts.<br />
<br />
[15:32] macduy: k, but it would probably make sense to keep it in one widget<br />
<br />
Mazi: this can span both sectiosn I think?<br />
<br />
holch: What do you mean with that?<br />
<br />
[15:33] macduy: widget take 1/2 width of the dashboard<br />
<br />
dqminh: i like ezcomponents , it supports vertical bar charts + other types in the latest trunk<br />
<br />
dqminh: plus having a lot of people working on it<br />
<br />
holch: I think a stable base of developers is important.<br />
<br />
[15:34] holch: On the other hand, if the tool has everything that we need, is the future then still important?<br />
<br />
Mazi: from what I have seen so far<br />
<br />
[15:36] holch: Seems like my chat stopped somehow.<br />
<br />
holch: Or has no one said anything during 3 minutes?<br />
<br />
macduy: (think people are just silent)<br />
<br />
holch: Ahhh,....<br />
<br />
macduy: :)<br />
<br />
[15:37] Mazi: who knows how this is done in LS1?<br />
<br />
</nowiki><br />
<br />
==-Filtering Data==<br />
<br />
<nowiki><br />
<br />
holch: Filter data? What do you mean with filter data?<br />
<br />
dhardisty: I think he means: let's say you only want to see data from the females<br />
<br />
Mazi: filter results e.g. only show data for people who are male and answered Q3 = "blue"<br />
<br />
[15:38] macduy: I think I can place some filter controls at the start of the dashboard<br />
<br />
macduy: and then refresh the whole dashboard<br />
<br />
Mazi: short summary how this is done in LS1. we can then decide if it makes sense to use it in LS2, too...<br />
<br />
Mazi: there is a first screen which lists all questions and answers. questions can be checked by ticking a checkbox...<br />
<br />
[15:39] holch: I don't think that this is a functinality for the dashboard, that is already advanced reporting/analysis.<br />
<br />
Mazi: furthermore you can filter by certain answers. those are listed below the question at a list and can be checked (even multiple by holding down ctrl key).<br />
<br />
Mazi: depending on what was checked marked at teh fuirst screen data is filtered by SQL queries<br />
<br />
[15:40] Mazi: screenshot of the filter screen: http://docs.limesurvey.org/img/wiki_up/stats_1_823x525.gif<br />
<br />
Mazi: that's how it works in LS1<br />
<br />
[15:42] Mazi: it works quite well but the code is a mess<br />
<br />
Mazi: comments / ideas?<br />
<br />
dhardisty: someone mentioned that coding time is short -- maybe we just do simple graphs (of all the results) first, and add filtering afterwards?<br />
<br />
macduy: makes sense<br />
<br />
Mazi: fine with me<br />
<br />
[15:43] dhardisty: if the coding is a mess, let's not bring it from LS1<br />
<br />
dhardisty: I mean, not bring the coding<br />
<br />
macduy: ok, I think we need to refine the Survey Dashboard a bit<br />
<br />
dhardisty: filtering is nice, but one of the goals of LS2 is to have a usable codebase, right?<br />
<br />
[15:44] Mazi: dhardisty, problem in LS1 is just that everything is done within one file<br />
<br />
Mazi: the general concept works fine<br />
<br />
dhardisty: ah, ok<br />
<br />
[15:45] macduy: imho, we should keep the Question Breakdown widget simple<br />
<br />
macduy: after all, it is for a dashboard and that should give an overview<br />
<br />
macduy: not too much detail<br />
<br />
macduy: so a page like I think that http://www.marcel-minke.de/ls180/statistics_user.php?sid=96315 would<br />
<br />
[15:46] macduy: *so a page like http://www.marcel-minke.de/ls180/statistics_user.php?sid=96315<br />
<br />
macduy: would actually be a separate page<br />
<br />
macduy: because it would also be easy to print<br />
<br />
</nowiki><br />
<br />
==-Displaying multiple content in Dashboard - 1. Ajax tabs==<br />
<br />
<nowiki><br />
<br />
dqminh: macduy: did you consider having a tab for it<br />
<br />
dqminh: so 1 tab for overview<br />
<br />
dqminh: 1 tab for advance view<br />
<br />
macduy: damn! That'd be wicked sick<br />
<br />
macduy: Tabbed Dashboard :)<br />
<br />
[15:47] dhardisty: yeah, tabs are always nice<br />
<br />
dqminh: for advance view we just give them filtering function + data in table/graph<br />
<br />
dqminh: so no widget and such<br />
<br />
[15:48] holch: Sorry guys, have to leave.<br />
<br />
macduy: yeah, it would not be actually controlled by a widget<br />
<br />
macduy: ok, I'll post the discussion on web so you can catch up later<br />
<br />
[15:49] Mazi: bye holch<br />
<br />
macduy: bye<br />
<br />
dhardisty: bye<br />
<br />
[15:50] macduy: has someone used Google Analytics?<br />
<br />
dhardisty: I use it<br />
<br />
macduy: I think that's a great working UI<br />
<br />
Mazi: yeah!<br />
<br />
[15:51] macduy: I think we need to learn from that, instead of having a bunch of widgets<br />
<br />
dhardisty: yeah, it's very slick<br />
<br />
macduy: they have specific report pages<br />
<br />
macduy: and for each of those they offer a selection of widgets<br />
<br />
macduy: so that you can rehash your own report from these widgets, which would be your actual dashboard<br />
<br />
[15:52] macduy: which makes sense, because these widgets come from somewhere, as opposed to being on their own, displaying "some stuff"<br />
<br />
[15:53] macduy: so in our case of "Question Breakdown", what we try to achieve using a single widget, they do using a whole, fixed page<br />
<br />
[15:56] macduy: no? :)<br />
<br />
dhardisty: I'm not sure I follow 100% ("widgets" are not a normal part of my vocabulary), but are you suggesting that we do the filtering by clicking on parts of the results (for example, click on women in the gender graph) rather than using one thing to do all the filtering?<br />
<br />
Mazi: I like the idea but this only works for having 1 filter moption<br />
<br />
[15:57] dhardisty: not true, you can then click on other graphs<br />
<br />
Mazi: we should not stick too much to g analytics. it'&Auml;s nice and we can take over some ideas, but that's all<br />
<br />
dhardisty: so first you click on women, then on "blue"<br />
<br />
macduy: yeah, true, I think Survey statistics are a different kind<br />
<br />
Mazi: I see<br />
<br />
dhardisty: but for choosing more than one filter option, it would be tricky<br />
<br />
dhardisty: I'm just trying to understand macduy's suggestion<br />
<br />
macduy: I would stick with the LS1 style<br />
<br />
[15:58] Mazi: ...while having a general overview for beginners<br />
<br />
Mazi: and some options bar/pie charts at the background<br />
<br />
[15:59] dhardisty: sounds good<br />
<br />
macduy: and the tabs<br />
<br />
[16:00] Mazi: yep<br />
<br />
macduy: have widgets contain very summarized data<br />
<br />
macduy: with a sort of "more" link<br />
<br />
macduy: and that opens a new dashboard tab<br />
<br />
macduy: or a new browser tab?<br />
<br />
[16:01] Mazi: new windows might be iorritating<br />
<br />
macduy: ok<br />
<br />
dhardisty: yeah, advanced users can always easily open in a new browser tab if they want<br />
<br />
macduy: maybe we should start from the other end. Forget the technicalities and think what we would like to see<br />
<br />
[16:02] dqminh: what if the users open too many tab ?<br />
<br />
macduy: alert("You opened too many tabs!");<br />
<br />
[16:03] macduy: no seriously, what would be the problem?<br />
<br />
dqminh: the problem is some users might open too many tabs without knowing it ;)<br />
<br />
[16:04] macduy: would that strain the browser?<br />
<br />
macduy: (I presume we are talking about dashboard tabs)<br />
<br />
macduy: I think every widget would be allowed to open only 1 tab<br />
<br />
macduy: if he opens another one, it just refreshes<br />
<br />
[16:05] dqminh: the problem is how you display the tab selection on top<br />
<br />
[16:06] macduy: like in a browser, stacked vertically side by side<br />
<br />
macduy: I presume there's a jQueryUI plugin which will help me greatly to create this :)<br />
<br />
[16:07] macduy: the main survey dashboard would be presented as the first, default locked tab<br />
<br />
macduy: I just am not sure if this overall abuse of ajax is a good idea<br />
<br />
[16:08] macduy: say what if someone wanted to display just the tab? How does he know what URL to use?<br />
<br />
dqminh: yes, that will put too much strain on the browser<br />
<br />
macduy: and opening a new browser tab is irritating for users<br />
<br />
[16:09] dqminh: "more" kink will open a new browser/browser tab<br />
<br />
</nowiki><br />
<br />
==-Displaying multiple content in Dashboard - Other approaches==<br />
<br />
<nowiki><br />
<br />
dqminh: or a lightbox<br />
<br />
[16:10] macduy: I still think lightboxes are bit cheap :)<br />
<br />
[16:11] macduy: ok how about this:<br />
<br />
macduy: clicking on a more link will temporarily hide the dashboard and display the wanted content<br />
<br />
[16:12] macduy: so it will be something like a dashboard tab/lightbox combined<br />
<br />
macduy: because we won't do a page refresh<br />
<br />
macduy: and we lock the dashboard, by simply hiding it<br />
<br />
[16:13] macduy: there will be a back button, which then takes the user back to the dashboard<br />
<br />
dhardisty: sounds good<br />
<br />
dqminh: netvibes.com is a great site for tabbed + widgets<br />
<br />
macduy: note that some users would also expect to be able to hit the "back" button on their browsers<br />
<br />
[16:14] dhardisty: I have to go -- see you guys later!<br />
<br />
macduy: see ya<br />
<br />
Mazi: bye, I also have to leave<br />
<br />
Mazi: macduy, will you do the wiki update?<br />
<br />
macduy: kk, bye<br />
<br />
macduy: sure<br />
<br />
[16:15] Mazi: together with a summary<br />
<br />
macduy: thank you both for coming!<br />
<br />
Mazi: we really need to say "This is done that way!"<br />
<br />
dqminh: i will go and have my dinner ;(<br />
<br />
Mazi: to stop endless discussions. better start working on things and evaluate prototypes<br />
<br />
Mazi: expecially for statistics<br />
<br />
Mazi: that's my opinion<br />
<br />
[16:16] macduy: ok, Mazi your vote then:<br />
<br />
macduy: lightbox, dashboard tabs or the last thing I said<br />
<br />
macduy: whatever you say, I'll go smack it together right now!<br />
<br />
Mazi: the last one sounded cool. but you can judge better<br />
<br />
Mazi: lol<br />
<br />
[16:17] Mazi: dqminh, what do you think about having a first prototpye using ezComponents?<br />
<br />
Mazi: do you think you can set something up?<br />
<br />
[16:18] Mazi: cool<br />
<br />
macduy: k then, let's get to work<br />
<br />
[16:20] Mazi: dqminh? macduy?<br />
<br />
[16:21] macduy: ?<br />
<br />
macduy: I can get the Dashboard back-end<br />
<br />
macduy: but I will rely on dqminh integrating ezComps<br />
<br />
[16:23] Mazi: this way everybody doesn't have to downlaod the SVN version to take alook and it's better than screenshots<br />
<br />
[16:24] macduy: there's the demo2.limesurvey.org<br />
<br />
macduy: we could put some new code up there as soon as we the code is reasonably stable<br />
<br />
Mazi: this is for user taking a look at the "stable" old LS2 version<br />
<br />
</nowiki></div>Macduyhttps://www.limesurvey.org/manual/index.php?title=Widgets_design_document&diff=3728Widgets design document2009-07-21T16:12:10Z<p>Macduy: </p>
<hr />
<div><br />
This is a list of widgets, with design mock-ups (not final!) and brief description of information displayed. Each section represents a widget, each '''bolded statement''' represents a tab inside the widget. Other options are described in ''italics''.<br />
<br />
Note that some tabs might need better grouping. Some tabs may need to be considered as separate widgets and v.v.<br />
<br />
'''About Graphs'''<br />
<br />
Complicated graphs, such as bar charts, pie charts, line plots displaying lots of data and information will be generated using a PHP Charting library (denoted by <nowiki>[</nowiki>lib]). For simpler graphs (such as the Completion tab of Survey Summary widgets), it is advisable to use plain HTML + CSS (denoted by <nowiki>[</nowiki>HTML]).<br />
<br />
=Survey Summary=<br />
<br />
Displays brief summary information about a survey.<br />
*'''Completion:'''<br />
**Total number of responses, percentage completed, breakdown + graph <nowiki>[</nowiki>HTML]<br />
**(?) Additionally, time per response and time since last response<br />
**Mockup:[[File:Completion 1.jpg]]<br />
*'''Responders'''<br />
**A graph of responders per day, in the last timeframe<br />
**''timeframe can be: last day, last week, last month''<br />
<br />
=Responders=<br />
*'''Graph (needs a better name):'''<br />
**A graph of responders per day, perhaps more detailed and with more options<br />
**''e.g. selectable timeframe + filtering: show only completed..''<br />
*'''Country:'''<br />
**Country from which the response came from, displayed as a table || Country (+Flag) | Responses | % ||<br />
**Can be switched to a bar/pie chart <nowiki>[</nowiki>lib]<br />
<br />
=Individual Responses=<br />
*'''Table:'''<br />
**Table: || Response ID | Status (complete|saved|incomplete) | Date | Time taken ||<br />
**Clicking on a row reveals an 'action' bar, where user can select to view details of the response<br />
***This can either be a lightbox-type popup displaying further information (more space, but obtrusive lightbox)<br />
***or a subgrid, displayed inside the widget (less space, may cause more clutter)<br />
<br />
<div class="simplebox">[[File:Subgrid.jpg]](Example subgrid)</div><br />
<br />
<div class="simplebox">[[File:Lightbox popup.jpg]](Example Lightbox popup)</div><br />
<br />
=Technical=<br />
<br />
Displays technical data from responders.<br />
*'''Browser:'''<br />
**Browser used, display as table/bar/pie chart<br />
*'''Plugins:'''<br />
**Whether certain browser technologies were available: flash, cookies, javascript. Again, table/bar/pie chart as proportion of have/not have<br />
*'''Screen:'''<br />
**Screen resolution, maybe format as well. Table/bar/pie<br />
*'''OS:'''<br />
**OS used, Table/bar/pie, with breakdowns for different versions of certain OSes. Display as subgrid or some form of clever graph.<br />
<br />
=Local Time=<br />
<br />
Number of responses at a given time during the day. Might be useful to know at what time did the visitors take the survey.<br />
<br />
=Question Breakdown=<br />
<br />
Displays a table/list of all questions, with a breakdown of the answers given. Something like this:<br />
<br />
[[File:Responses.jpg]]<br />
<br />
Each question type needs to implement a way to display such a breakdown and certain question types (esp. those involving long text answers) can be tricky. Note how this has been solved in the above case (questions 3.Pluses and 4.Minuses). Screenshot from Webform drupal module)<br />
<br />
=Tag clouds=<br />
<br />
Basically, displays a selection of the above information as a tag cloud. Might be implemented as just another way of displaying data, along with bar/pie/table options.</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=UI_meeting_6_(11th_July)&diff=3511UI meeting 6 (11th July)2009-07-14T12:47:35Z<p>Macduy: </p>
<hr />
<div><br />
=Meeting Log=<br />
<br />
<nowiki><br />
<br />
[15:09] macduy: hi<br />
<br />
holch: Could you give me the link again?<br />
<br />
amit8-88: hello ;)<br />
<br />
holch: Hi Macduy!<br />
<br />
amit8-88: http://docs.limesurvey.org/tiki-index.php?page=amit_conditions_notes<br />
<br />
[15:10] macduy: Hi holch!<br />
<br />
holch: Thanks Amit, I will have a quick look.<br />
<br />
[15:11] amit8-88: ok<br />
<br />
[15:12] holch: Could you just tell me where this screen would show up?<br />
<br />
holch: I have problems to imagine it in the process of the survey building.<br />
<br />
macduy: it would be one of the steps when building a survey<br />
<br />
holch: Yes.<br />
<br />
macduy: 1. Add Questions => 2. Organize them => 3. Condition Builder<br />
<br />
amit8-88: yeah<br />
<br />
[15:13] holch: OK. So at the end of everything when you have the questionnaire in the right order, then you will create the conditioning?<br />
<br />
[15:14] amit8-88: yes<br />
<br />
macduy: once you have finalized your form, you can build conditions into it<br />
<br />
holch: Makes sense, but is slightly different to what I am used to.<br />
<br />
[15:15] amit8-88: yes it is very different than Ls1<br />
<br />
holch: I am trying to see right now, how it is done in LS1.<br />
<br />
amit8-88: AND/ Or are separated for much flexibility in adding conditions<br />
<br />
amit8-88: mainly the idea is to separate the conditions from actions<br />
<br />
[15:16] amit8-88: so that the code can be reusable and can be applied to tokens, other attributes etc<br />
<br />
holch: Yes, makes sense.<br />
<br />
[15:17] holch: Because those thingies repeat often.<br />
<br />
amit8-88: yes<br />
<br />
holch: OK, so let us go through the process.<br />
<br />
[15:18] holch: I have a question.<br />
<br />
holch: What is "connector" for.<br />
<br />
amit8-88: "connector " is used to apply AND/OR to the conditions<br />
<br />
[15:19] macduy: something that uniquely identifies the question<br />
<br />
[15:20] holch: OK.<br />
<br />
holch: What I was used to with globalpark, you could build different branches.<br />
<br />
holch: Which can be pretty easy.<br />
<br />
holch: Can I do that here too or do I need to give a condition to every question?<br />
<br />
[15:21] amit8-88: You mena branching questions ?<br />
<br />
amit8-88: mean*<br />
<br />
[15:22] amit8-88: Show Q1 only if Q2="APPLE"?<br />
<br />
amit8-88: this kind of things ?<br />
<br />
holch: Well, that would be impossible, right?<br />
<br />
[15:23] amit8-88: no its possible<br />
<br />
holch: Having a condition in Q2 for Q1?<br />
<br />
holch: You must be a wizard... ;-)<br />
<br />
[15:24] amit8-88: first we create a condition like if Q1="APPLE" and then choose the actions as SHOW Q2<br />
<br />
macduy: so you meant it the other way round ;)<br />
<br />
amit8-88: yeah<br />
<br />
[15:25] holch: So let me tell what I meant.<br />
<br />
macduy: although the condition builder would allow and execute such conditions like the above, it would just be stupid if someone did that<br />
<br />
holch: You have a bunch of questions that you will want to ask only, if the person is male, others only if the person is female.<br />
<br />
[15:26] holch: As I understand the conditions are applied on a question basis and the survey follows question per question.<br />
<br />
holch: So than I would have to apply the conditions to every single question that is for male only.<br />
<br />
[15:27] amit8-88: we can set conditions on users attributes too<br />
<br />
amit8-88: ;)<br />
<br />
holch: I know.<br />
<br />
[15:28] holch: what I mean is: do I have to apply the condition "show only when male" to every single question that is supposed to be for male only?<br />
<br />
amit8-88: ok then yes<br />
<br />
amit8-88: No in ls2 there is no concept of Show only ,<br />
<br />
[15:29] amit8-88: we first build the condition and then select what actions to follow<br />
<br />
macduy: so there would be an action "Show these question: "<br />
<br />
amit8-88: for the moment its only show question :)<br />
<br />
macduy: ?<br />
<br />
macduy: k<br />
<br />
amit8-88: yeah there will be<br />
<br />
amit8-88: ;)<br />
<br />
[15:31] holch: OK.<br />
<br />
[15:32] holch: But this condition designer is for the dummy or for the more experienced user?<br />
<br />
[15:33] amit8-88: well who ever takes it :)<br />
<br />
amit8-88: actually i was to design a simple and advanced versions of conditions builder<br />
<br />
holch: OK.<br />
<br />
holch: This is just for me to understand who it is directed to.<br />
<br />
[15:34] amit8-88: but i was very slow in my progress due to some problems<br />
<br />
amit8-88: so decided to put up a builder with max functionalities for now and can develop the other version later<br />
<br />
holch: OK.<br />
<br />
amit8-88: so you can say it is for advanced users ;)<br />
<br />
[15:36] holch: OK. that is what I had assumed.<br />
<br />
amit8-88: ;)<br />
<br />
[15:37] holch: What are the tabs for? Can you actually switch between those?<br />
<br />
amit8-88: no<br />
<br />
[15:39] holch: As I can see you can add more lines, so like "do that if that is 5 and this is green and the other one is 56", right?<br />
<br />
amit8-88: yes<br />
<br />
[15:40] holch: The negation and the brackets are necessary?<br />
<br />
[15:41] amit8-88: well they determine the expression to combine two AND or OR statements<br />
<br />
amit8-88: two or more *<br />
<br />
macduy: the biggest drawback in LS1 condition builder is that you couldn't get certain conditions to work<br />
<br />
holch: Yes, that is what I figured.<br />
<br />
[15:42] macduy: because you couldn't tell it which sub-conditions to evaluate first<br />
<br />
holch: And "Dummy" might not understand. But I think it is important to have.<br />
<br />
[15:43] holch: This condition builder will create code?<br />
<br />
holch: Code that we could show?<br />
<br />
macduy: yes, it will show an expression<br />
<br />
macduy: at least, I think that was the idea, right amit? :)<br />
<br />
[15:46] amit8-881: sorry got disconnected<br />
<br />
[15:47] amit8-881: I am facing lots of problems with my interent these days :(<br />
<br />
[15:49] macduy: we envision an advanced user wanting to edit/type in the condition himself<br />
<br />
[15:56] amit8-881: ok is the conditions screen fine ? views /suggestions/ comments ?<br />
<br />
[15:57] macduy: to be honest, I'm slightly reserved about those brackets<br />
<br />
macduy: is this is the advanced or the basic gui for conditions?<br />
<br />
[15:58] amit8-881: advanced<br />
<br />
macduy: the solution for the brackets is very likeable<br />
<br />
macduy: in that it's so simple to use<br />
<br />
amit8-881: the basic one will not have those brackets ... at least this is what I and lemuer have thought of<br />
<br />
macduy: yet, it won't be able to cover all cases<br />
<br />
[15:59] macduy: how would you build</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=Look_and_feel&diff=2158Look and feel2009-07-11T11:12:10Z<p>Macduy: </p>
<hr />
<div><br />
=Widgets Look'n'Feel Design Document=<br />
<br />
This document attempts to describe the general look'n'feel of the widgets, their interactions and workflows.<br />
<br />
==Proposal 2:==<br />
<br />
<div class="simplebox">'''Widget Chrome''': [http://www.flickr.com/photos/macduy/3573297659/ link]<br />
*content on white background, blends well with the rest of bright-coloured LimeSurvey interface<br />
*green header, large yet inobtrusive, marks the beginning of the widget<br />
*small arrows, indicate currently selected item and hints the user to the next navigation element.<br />
<br />
</div><br />
<br />
==Proposal 4:==<br />
<br />
Based on proposals 3 and 3.1<br />
<br />
[[File:Widget 4.jpg]]<br />
<br />
==Proposal 3:==<br />
<br />
<div class="simplebox"><br />
<br />
[[File:Widget 3.jpg]]<br />
*as minimalist as possible!<br />
*minimize the visual impact of the widget chrome, draw attention to actual contents and layout<br />
<br />
</div><br />
<br />
==Proposal 3.1:==<br />
<br />
<div class="simplebox"><br />
<br />
[[File:Widget 2.1.jpg]]<br />
*Even less.<br />
<br />
</div></div>Macduyhttps://www.limesurvey.org/manual/index.php?title=UI_meeting_5_(4th_July)&diff=3510UI meeting 5 (4th July)2009-07-05T14:19:00Z<p>Macduy: </p>
<hr />
<div><br />
=Summary=<br />
<br />
<div class="simplebox"><br />
<br />
==User/Participant:==<br />
*Regardless of implementation, concept separation is useful from UI point of view<br />
*Implementation-wise, 1 table 'user' will be used<br />
*Either use an additional 'type' column to distinguish, or make use of Security Groups<br />
*Make sure administrators can also participate (can be tricky, if we use second option from above point)<br />
<br />
<span style='color:#FF0000'>Terminilogy note:</span> When speaking of '''Surveys''' and '''Questionnaires''', they always mean the dictionary definition. Concepts used in LS2 are prepended with '''"ls2:"''' to avoid confusion. As an example, what we refer to Questionnaires in real world, is actually called ''Survey'' in LS2.<br />
<br />
==Questionnaire/Survey:==<br />
*'''''Questionnaire''''' = a form/set of questions<br />
*'''''Survey''''' = act of collecting information using Questionnaire(s) and obtaining results<br />
*Current LS2 implementation names these concepts differently, <span style='color:#ff0000'>we should decide once and for all how are we going to call these in our code!</span><br />
*Results should be bound to the Survey, not the Questionnaire!<br />
**Current implementation uses 'result_x' tables, where x is the id of the corresponding ls2:Survey. This is not a problem, as another column called 'assignment_id' is used to separate responses coming from differnt Surveys/ls2:Assignments. Just make sure that this column is never NULL.<br />
<br />
==Dashboard:==<br />
*Video preview: http://www.youtube.com/watch?v=nGk9k9XqlJ4<br />
<br />
=Next week:=<br />
<br />
Conditions, Conditions Builder, Invitations and Dashboard.<br />
<br />
=Meeting Log=<br />
<br />
==-Introductions==<br />
<br />
</nowiki><br />
<br />
[15:03] holch: good morning.<br />
<br />
[15:05] macduy: hi<br />
<br />
holch: Ahh, here you are...<br />
<br />
holch: Thought I might be almost alone like last time.<br />
<br />
holch: How are things going?<br />
<br />
holch: Thanks for the feedback, only just saw it now.<br />
<br />
[15:06] macduy: things are fine, hope you too!<br />
<br />
holch: One question: did you receive my email to the email list?<br />
<br />
holch: Yup. Tired but fine.<br />
<br />
macduy: 'tired' is appropriate :P<br />
<br />
macduy: which e-mail?<br />
<br />
holch: OK.<br />
<br />
holch: So it didn't work again?<br />
<br />
[15:07] macduy: I received one from last week<br />
<br />
holch: It was a reminder for todays meeting and I was hinting to give some feedback...<br />
<br />
holch: Last week?<br />
<br />
holch: I didn't write an email to the email list last week. At least it didn't work.<br />
<br />
macduy: oh sorry, no I did receive a reminder 2 days ago<br />
<br />
[15:08] macduy: we can still get some direct feedback now<br />
<br />
holch: Ahh, OK.<br />
<br />
macduy: let's see who's here<br />
<br />
macduy: Hi Jon, Amit, Josef :)<br />
<br />
[15:09] jwestfall: Hello!<br />
<br />
holch: So at least I know that it is working, because I didn't receive it,and there was no response, so I was not sure.<br />
<br />
holch: Who is Josef? El-Matador?<br />
<br />
macduy: (y)<br />
<br />
holch: OK.<br />
<br />
holch: Good to know.<br />
<br />
[15:10] jwestfall: Yea, sorry about not replying - busy week. Email is working though :)<br />
<br />
macduy: let's get started:<br />
<br />
holch: That is fine, you are here and you can reply now... ;-)<br />
<br />
[15:11] holch: Yup. I am ready.<br />
<br />
amit8-88: Hi guys<br />
<br />
holch: This time I can't stay that long, have a meeting at 12:00.<br />
<br />
holch: Hi Amit.<br />
<br />
macduy: holch, is that in 2 hours time?<br />
<br />
macduy: Hi Amit<br />
<br />
amit8-88: hi macduy, holch<br />
<br />
[15:12] holch: Yup.<br />
<br />
macduy: ok<br />
<br />
holch: But of course I would have to leave 30min before.<br />
<br />
holch: More or less.<br />
<br />
macduy: no worries, we'll keep it 1 hour long today<br />
<br />
</nowiki><br />
<br />
==-User/Participant==<br />
<br />
<nowiki><br />
<br />
macduy: topic #1: User/Participant<br />
<br />
holch: any feedback from the developers?<br />
<br />
[15:13] macduy: yep, there is general agreement of participants having varying levels of rights and anonymity inside the LS2 hierarchy<br />
<br />
holch: But they are part of "users", right?<br />
<br />
macduy: yes, we refer to them all as users<br />
<br />
amit8-88: yeah<br />
<br />
[15:14] holch: OK.<br />
<br />
macduy: the devs got hooked on a discussion about customizable attributes, so we'll see where that leads ;)<br />
<br />
holch: For the UI I would separate this a little more clearly though.<br />
<br />
macduy: yes, from UI point of view I think we envision a list of users and then a 'pool' of participants<br />
<br />
[15:15] macduy: to select from. From these people, we usually just retain minimum info, e.g. their e-mail address.<br />
<br />
holch: With participants being a special sort of users, who can only fill in data, etc.<br />
<br />
macduy: yep<br />
<br />
holch: Fine with me. Anything else.<br />
<br />
macduy: nope<br />
<br />
jwestfall: It would be nice though if the UI allowed admins to be 'participants' in some scenarios<br />
<br />
jwestfall: perhaps some sort of filtering in the UI that by default doesn't show them<br />
<br />
holch: What about the wording? Will Participants be called "participants"?<br />
<br />
[15:16] jwestfall: but could be toggled off so all users show up as pools<br />
<br />
macduy: I would definitely keep the word Participant<br />
<br />
macduy: there will be<br />
<br />
jwestfall: Yea, Participant is preferable to "subject" or respondant<br />
<br />
holch: I vote for Participants two. It is clear, everyone should understand immediately what a "participant" is.<br />
<br />
macduy: yep, definitely<br />
<br />
[15:17] holch: Yes, sometimes "subject" is used. I find it horrible...<br />
<br />
amit8-88: yep<br />
<br />
macduy: I imagine it will be something like "Choose your participants"<br />
<br />
amit8-88: participant is better :)<br />
<br />
jwestfall: Yea, there is a huge debate amid some psychologists over the "participant" vs. "subject" thing<br />
<br />
holch: OK. We fixed that.<br />
<br />
macduy: anything else on this matter?<br />
<br />
</nowiki><br />
<br />
==-Survey/Questionnaire==<br />
<br />
<nowiki><br />
<br />
[15:18] macduy: ok, topic #2: Survey/Questionnaire<br />
<br />
holch: Let psychologists discuss that. We choose the friendly version... ;-)<br />
<br />
holch: OK.<br />
<br />
holch: That might be more tricky, right?<br />
<br />
macduy: yep, as usual :P<br />
<br />
holch: I vote for separtating those two concepts, as you all know.<br />
<br />
holch: separating.<br />
<br />
macduy: in current LS2 implementation referred to Assignment/Survey<br />
<br />
[15:19] holch: seperating...<br />
<br />
holch: Now I got it.<br />
<br />
macduy: although I agree that Questionnaire makes much more sense in terms of naming<br />
<br />
holch: I think my "survey" concept is more ample than assignments.<br />
<br />
holch: You will store or the principal information about the project in Survey.<br />
<br />
[15:20] macduy: Yes, a Questionnaire is just a set/form of questions<br />
<br />
holch: There you will choose the group of participants, invite them, choose a questionnaire, choose a template, etc.<br />
<br />
macduy: exactly<br />
<br />
jwestfall: I vote for seperating the two as well<br />
<br />
macduy: please burn this into your minds :P<br />
<br />
holch: It would give you a lot of flexibility.<br />
<br />
[15:21] holch: What should we burn in our minds?<br />
<br />
jwestfall: especially if it could be designed to allow multiple questionnaires in 1 survey<br />
<br />
macduy: well, this separation concept ;)<br />
<br />
holch: I have it in my had. Question is: do the developers? ;-)<br />
<br />
macduy: (I was directing that more towards them ;) )<br />
<br />
[15:22] macduy: I have only one issue:<br />
<br />
holch: So the "questionnaire section" is pure for creating document with different questions.<br />
<br />
holch: Go on:<br />
<br />
macduy: as Mazi pointed out earlier, "Survey" as a term is stuck<br />
<br />
holch: Yes.<br />
<br />
holch: And we won't loose it.<br />
<br />
macduy: there are meny parts named like that in the code, that depend on it<br />
<br />
[15:23] holch: This means that the have coded survey in actual "questionnaire" parts?<br />
<br />
macduy: no, we have named everything, that in your book is called "questionnaire", a "survey"<br />
<br />
macduy: so purely a naming mishap<br />
<br />
holch: Well, how the developers call it, shouldn't be a major problem for the UI. Or are they visible in the html source code?<br />
<br />
[15:24] macduy: I think so<br />
<br />
macduy: it would be confusing even for us<br />
<br />
holch: Because to be honest, the average user will never go into the PHP code. And if he does, we can expect that he tries to understand it.<br />
<br />
macduy: because what the devs call a Survey is suddenly the UI people's name for an Assignment :)<br />
<br />
[15:25] holch: For theme development, this is something else. There it could be a little weired.<br />
<br />
holch: OK.<br />
<br />
holch: I see.<br />
<br />
macduy: so I would suggest we go for Survey Project/Survey<br />
<br />
holch: Well, it is not ideal, I have to admit.<br />
<br />
macduy: so do I<br />
<br />
macduy: but I think the term 'project' should work out well<br />
<br />
[15:26] macduy: people will immediately think - 'ah project, something big. It also involves a survey'<br />
<br />
holch: But, as it is separated from UI and developers and users this should be possible to overcome.<br />
<br />
macduy: it should be, but developers also write documentation for other developers to read<br />
<br />
holch: I like Survey Project, because it actually is a small "project management" section, what "survey" is.<br />
<br />
[15:27] macduy: Survey Project is majorly just a binder, that connects a questionnaire, bunch of people and a set of results<br />
<br />
holch: And there is no chance to "search & replace", right? :-)<br />
<br />
jwestfall: Well, survey/questionnaire is technically correct as per research methodology, however I agree that project/survey should be intuitive enough as a replacement.<br />
<br />
macduy: I understand that pedantically we are using the wrong terms<br />
<br />
[15:28] holch: Ah, now I get what you want. You want to get rid of questionnaire.<br />
<br />
holch: Hmm.<br />
<br />
macduy: I want to replace the term ;)<br />
<br />
holch: OK.<br />
<br />
holch: I didn't get that.<br />
<br />
holch: I thought you wanted to rename "survey" to "survey project".<br />
<br />
macduy: your concept is completely sound<br />
<br />
[15:29] macduy: hehe ok, to sum my point:<br />
<br />
macduy: In Real Worl:<br />
<br />
macduy: - Questionnaire = "A form/set of questions"<br />
<br />
macduy: - Survey = "A conduct of acquiring responses through a questionnaire"<br />
<br />
macduy: In LS2 World:<br />
<br />
macduy: - "Survey" = "A form/set of Questions"<br />
<br />
[15:30] macduy: - "Survey Project" = "A conduct of acquiring responses through the above"<br />
<br />
holch: Well, I would still use questionnaire and survey, but I guess we will have to compromise, somehow.<br />
<br />
macduy: I think we have to compromise<br />
<br />
holch: But the seperation wouldn't be that nice.<br />
<br />
macduy: I'll see if I get this discussion going again in the dev channel<br />
<br />
macduy: the separation would be exactly the same<br />
<br />
macduy: we just called it different things :P<br />
<br />
holch: You would have one or two surveys in a survey project.<br />
<br />
[15:31] macduy: true, it sounds a bit lame<br />
<br />
macduy: but let's stick to this for now<br />
<br />
holch: Look, I am the advocate what I think would be ideal. However, I understand that there are more stakeholders to LS2 than just the plain "user".<br />
<br />
[15:32] macduy: it really depends on what people imagine under the word "survey"<br />
<br />
holch: So if the developers require the questionnaires to be called "survey", I will have to live with it. ;-)<br />
<br />
macduy: e.g. to me, it could equally mean both the form with questions as well as the whole process.<br />
<br />
[15:33] holch: Yes, if there would be ONLY survey, I agree. but I am not sure how "survey" will work together with "survey project"<br />
<br />
macduy: if I were met with a program where the terms used were "survey" and "survey project" I would be happy to accept that by "survey" they probably mean the piece of paper ;)<br />
<br />
holch: Well, at the end of the day the users will accept anything.<br />
<br />
[15:34] holch: LS is free, they can't really complain... ;-)<br />
<br />
macduy: hehe, or move to a different app<br />
<br />
holch: Though they still might do. Mazi probably can tell some stories.<br />
<br />
holch: Well, there isn't really an alternative.<br />
<br />
macduy: he's away today, but we can ask him later<br />
<br />
[15:35] holch: Does anyone have news about the MITRE project? Should have been released a while ago.<br />
<br />
macduy: so for now, let's keep both Survey/Questionnaire and Survey Project/Survey terminology options in mind<br />
<br />
amit8-88: nope. I guess they still into it<br />
<br />
holch: I thought they were supposed to finalize it until Christmas last year? Thats what they told me.<br />
<br />
[15:36] jwestfall: Perhaps just "project / survey" would be better than "survey project" for users. Avoiding reuse of the word "survey" may be confusing.<br />
<br />
macduy: good point<br />
<br />
holch: Hmmm. I think it is getting worse.<br />
<br />
jwestfall: err... avoiding reuse may be LESS confusing<br />
<br />
holch: I can see your point, Jon.<br />
<br />
[15:37] holch: But then, they may ask them self "what the hell do I need a project for, when I have the survey section?"<br />
<br />
amit8-88: well I will still go with Survey/ Questionnaire :)<br />
<br />
holch: Amit is my man! Hahahaha.<br />
<br />
amit8-88: :)<br />
<br />
[15:38] macduy: what about Poll?<br />
<br />
jwestfall: Yea, that's possible - although the UI could give 'hints' to clarify things for users<br />
<br />
holch: Well, I guess we all agree that the ideal version (for now, maybe we find something even better?) would be questionnaire / survey.<br />
<br />
jwestfall: "Survey" (below, smaller type) "reusable set of questions"<br />
<br />
holch: But it seems like we will need to compromise here, due to the fact that we have started rather late with the UI meeting.<br />
<br />
jwestfall: "Project" (below, etc..) "one or more surveys given to participants"<br />
<br />
[15:39] macduy: maybe we should do a survey into this ;)<br />
<br />
jwestfall: Yea, questionnaire/survey would be great if devs can change to accomodate it<br />
<br />
holch: don't like poll.<br />
<br />
jwestfall: nobody likes poll<br />
<br />
holch: On the net more used for single questions<br />
<br />
[15:40] amit8-88: yeah they are majorly for single views<br />
<br />
macduy: yeah, but i mean use of LS to create polls<br />
<br />
holch: Well, a poll would be a single question questionnaire (or survey).<br />
<br />
macduy: where does that leave us if a user wants to create a poll, he would be creating a "Survey" with a "Questionnaire" containing 1 question<br />
<br />
holch: We don't need something special for it, do we?<br />
<br />
[15:41] macduy: nope<br />
<br />
holch: OK.<br />
<br />
macduy: ok, it's getting a bit muddled here<br />
<br />
jwestfall: Yea, but I don't think we should care - if someone uses LS2 for a one question poll, they are engaging in a huge amount of overkill<br />
<br />
holch: But this survey / questionnaire / survey project thing is already getting confusing here.<br />
<br />
macduy: maybe there can be a wizard that takes care of that, but let's leave that for future<br />
<br />
[15:42] macduy: as I say, I agree with survey/questionnaire<br />
<br />
macduy: as a concept<br />
<br />
macduy: and also with the naming<br />
<br />
holch: Well. what we need now is...<br />
<br />
holch: to fix something I think.<br />
<br />
jwestfall: Yea, right now to summarize, I think we'd all be happy if survey/questionnaire could be used as a concept and name, however if the devs demand it, we may have to go with survey project / survey<br />
<br />
holch: we shouldn't go on for two long with two different concepts.<br />
<br />
[15:43] macduy: to make sure: I'm just arguing about the terms here :)<br />
<br />
macduy: because I'm not sure how well the devs and seasoned LS1.x users will accept these<br />
<br />
holch: Good. Now it is up to the devolpers, if they think they can do this for the sake of the final user, or if it would complicate there work too much.<br />
<br />
macduy: but if we are not met with resistance, Survey/Questionnaire will get passed.<br />
<br />
jwestfall: at least we all agree on the concept!<br />
<br />
[15:44] holch: If it would be a payed project I would tell them to just accept it. But here we are talking about delevopers spending their spare time on this project.<br />
<br />
amit8-88: I guess Survey/Questionnaire should pass ;)<br />
<br />
macduy: we'll see ;)<br />
<br />
macduy: ok, let's forget naming now<br />
<br />
holch: Fingers crossed.<br />
<br />
macduy: to the concept:<br />
<br />
holch: next point on agenda?<br />
<br />
macduy: does that mean that results would be bound to a "Survey" rather than the "Questionnaire"?<br />
<br />
holch: Of course!<br />
<br />
[15:45] holch: questionnaire could have been created 5 years ago.<br />
<br />
holch: Of course somehow the questionnaire is also bound to the survey and the results.<br />
<br />
macduy: yep, but in simple relation diagrams<br />
<br />
holch: But it is basically only the form to get the results in the database.<br />
<br />
macduy: + conditions and other attributes directly related to the questionnaire<br />
<br />
[15:46] holch: Yes.<br />
<br />
holch: Because they could also be reusable.<br />
<br />
macduy: but things like questionnaire theme, publicity, anonymity, that should part of "Survey"<br />
<br />
holch: If someone needs different conditions, he needs a different questionnaire.<br />
<br />
macduy: yeah<br />
<br />
holch: Exactly.<br />
<br />
macduy: ok<br />
<br />
[15:47] macduy: that is pretty much taken care of by the current survey/assignment system<br />
<br />
holch: It would be ideal to be able to assign a different theme for each questionnaire in different surveys.<br />
<br />
macduy: yep<br />
<br />
macduy: so, to devs:<br />
<br />
holch: Because for example I have some multi-client projects, which are almost all run the same questionnaire, but different layouts (adapted to the CI).<br />
<br />
[15:48] macduy: CI?<br />
<br />
holch: Corporate Identity.<br />
<br />
macduy: ah I see<br />
<br />
macduy: yep<br />
<br />
holch: It is actually more the CD.<br />
<br />
holch: corporate design.<br />
<br />
holch: But every brand has different rules.<br />
<br />
holch: Logo top left, bottom right, whatever.<br />
<br />
[15:49] macduy: that can be tricky<br />
<br />
holch: Why?<br />
<br />
macduy: well, markup-wise<br />
<br />
macduy: our Survey Engine is being rewritten so we can address this issue<br />
<br />
holch: With the template system shouldn't be a problem?<br />
<br />
holch: It isn't now...<br />
<br />
macduy: nah, should not be<br />
<br />
macduy: forget what I wrote ;)<br />
<br />
[15:50] holch: However, what I would need could be overcome by simply copying a survey.<br />
<br />
holch: Not as slick, but also possible.<br />
<br />
macduy: also, can we decide on some notation please?<br />
<br />
holch: Notation?<br />
<br />
</nowiki><br />
<br />
==- End matters==<br />
<br />
<nowiki><br />
<br />
macduy: when we speak of Survey and Questionnaire, they mean what holch means<br />
<br />
macduy: or *write rather<br />
<br />
holch: ahh.<br />
<br />
[15:51] macduy: when I write ls2:Survey and ls2:Assignment, I mean what they mean in the current LS2 codebase<br />
<br />
macduy: to avoid confusion ;)<br />
<br />
holch: Good idea. ;-) For the minutes of the meeting.<br />
<br />
macduy: any other thoughts on LS2?<br />
<br />
jwestfall: yea, makes sense<br />
<br />
[15:52] macduy: *on Survey/Questionnaire<br />
<br />
holch: Where would we locate the templating system?<br />
<br />
holch: In "Questionnaires" or in "Surveys" or in its own section?<br />
<br />
macduy: hmm, that might involve writing your own code<br />
<br />
macduy: which means it might not be part of the visible UI<br />
<br />
holch: The creation and adinistration I mean.<br />
<br />
[15:53] holch: Thea assigning would have to be in "Survey".<br />
<br />
macduy: yes<br />
<br />
holch: OK, so there won't be an user interface for templates/themes, like in 1.8?<br />
<br />
[15:54] macduy: oh, maybe there should be then<br />
<br />
macduy: would probably be part of a "Later" category,<br />
<br />
holch: Honestly, I wouldn't need it. Have never used this part. External coding for themes should be fine.<br />
<br />
[15:55] macduy: ok. topic #2 closed<br />
<br />
holch: But some users with less experience in HTML, CSS and PHP would probably like the current approach.<br />
<br />
holch: OK.<br />
<br />
jwestfall: It's nice to have an editor for quick HTML changes<br />
<br />
holch: Jon, I agree.<br />
<br />
jwestfall: I'd vote to have it there in some capacity, doesn't have to be very robust<br />
<br />
macduy: well, we could develop something like the Blogspot's theming thing<br />
<br />
amit8-88: yeah but as macduy says it would be in later category<br />
<br />
macduy: we could really go a long way on that one, so let's just leave it for later<br />
<br />
[15:56] holch: That should be fine.<br />
<br />
jwestfall: OK<br />
<br />
[15:57] macduy: in other news: I'd like to post a preview of the LS2 dashboard to youtube on Monday<br />
<br />
holch: Cool. Any preview for us?<br />
<br />
macduy: any comments and suggestions would be welcome!<br />
<br />
amit8-88: nice!!<br />
<br />
macduy: holch: you mean a hands-on one?<br />
<br />
[15:58] holch: Anything. Screenshots, hands-on, whatever you have.<br />
<br />
holch: You have mentioned that you have different colour versions, right?<br />
<br />
holch: Dark and bright.<br />
<br />
macduy: I'll post the video on Monday and send links to the maillist<br />
<br />
holch: OK.<br />
<br />
macduy: holch: yes, but I'm currently working with dark only<br />
<br />
holch: OK.<br />
<br />
[15:59] macduy: alright then, shall we call it a day?<br />
<br />
[16:00] holch: If from your side there isn't anything else?<br />
<br />
holch: What will we have to discuss next week?<br />
<br />
macduy: good point<br />
<br />
holch: I might be not able to attend, but this is still unclear.<br />
<br />
amit8-88: maybe you can have some views on the conditions editor<br />
<br />
[16:01] holch: Have some client from the US over here for the whole week and I might have to entertain them on Saturday... ;-)<br />
<br />
macduy: invite them to the meeting :P<br />
<br />
amit8-88: lol<br />
<br />
macduy: Condition builder definitely<br />
<br />
holch: Nah, better not.<br />
<br />
holch: Condition builder. right. I promissed to have a look at this too.<br />
<br />
[16:02] jwestfall: Next week is dhardisty's week to attend, but if Condition builder is up, we both might be here ;)<br />
<br />
holch: Might be difficult this week though. Have interviews scheduled from Tuesday till Friday from around 8am till 9pm.<br />
<br />
[16:03] macduy: and Invitations<br />
<br />
holch: Maybe I can have look on it on sunday, but still have to translate guidelines. So, let's see.<br />
<br />
holch: I will try to give some feedback at least.<br />
<br />
holch: Yes, invitations is a interesting part.<br />
<br />
amit8-88: sure no problem<br />
<br />
holch: So, that's it then?<br />
<br />
macduy: so, next week: Conditions, Invitations and Dashboard-related stuff, if we have time<br />
<br />
[16:04] holch: Good.<br />
<br />
amit8-88: cool!!<br />
<br />
macduy: thanks everyone for attending! We kept it to 1 hour today :)<br />
<br />
amit8-88: hehe<br />
<br />
jwestfall: Bye ;)<br />
<br />
[16:05] macduy: everybody have a great weekend!<br />
<br />
holch: By, have a good weekend all!<br />
<br />
holch: off.<br />
<br />
macduy: Cyall<br />
<br />
amit8-88: bye!!<br />
<br />
amit8-88: have nice day<br />
<br />
</nowiki></div>Macduyhttps://www.limesurvey.org/manual/index.php?title=UI_meeting_1_(6th_June)&diff=3506UI meeting 1 (6th June)2009-06-27T15:27:23Z<p>Macduy: </p>
<hr />
<div><br />
<div class="simplebox"><span style='color:#FF0000'>'''Meeting outcome summary'''</span><br />
<br />
Current priority is to give LimeSurvey's interface a structure - i.e. given LS2 "engine", how do we build a "cockpit" that will expose the engine's features in an understandable, logical way? '''Holger agreed to receive e-mails from everyone, with description of possible User interactions with Limesurvey''', from which a structure of the interface will be created. Note this structure is purely semantic, not referring to graphical interface or HTML markup. '''This will be our starting point in developing a LS2 interface.'''<br />
<br />
Survey/Assignment concepts, though powerful, may seem confusing to most new users. Certain steps (e.g. Workflows/Wizards) should be taken to eradicate confusion and educate the users about these concept, when they need it.<br />
<br />
Other topics include creating mockups of workflows and designing wizards for beginner users.</div><br />
<br />
==Meeting Log==<br />
<br />
===-Introductions===<br />
<br />
<nowiki><br />
<br />
! [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp: #limesurvey-ui<br />
<br />
! macduy sets mode +tck ls2<br />
# The topic is 'LimeSurvey UI Meeting' (set by macduy)<br />
<br />
> Mazi|away has joined<br />
<br />
<div class="simplebox"> Mazi|away is now known as Mazi<br />
<br />
> amit8-88 has joined<br />
<br />
> dqminh has joined<br />
<br />
> holch has joined<br />
<br />
> El-Matador-69 has joined<br />
* El-Matador-69 * I hope you on't mind, if I listen your conversations<br />
* amit8-88 * not at all Josef<br />
* holch * Just one thing before we start: can I save this chat somehow?<br />
* macduy * umm, you can do a copy+paste<br />
* holch * So that I wont have to write stuff down...<br />
* dqminh * holch: sure. BUt what are you using ?<br />
* macduy * but don't worry, I'll do it on post on the wiki<br />
* dqminh * I'm logging already<br />
* holch * OK, that should be enough.<br />
<br />
> jaycburton has joined<br />
* jaycburton * There we go<br />
* holch * @Matador: the more the better.<br />
* macduy * let's start :)<br />
* holch * OK, I just wanted to give you a short idea of what I do.<br />
* holch * I am a consultant in market research, specialized on ebusiness.<br />
* holch * I am working on improving websites, by analyzing users evaluation.<br />
* El-Matador-69 * k - thx<br />
* macduy * thanks for your interest in LS2!<br />
* amit8-88 * great!!<br />
* holch * We do this or via onsite intercept surveys (thats why I am interested in LS) or personal indepth interviews in a studio (usability lab)<br />
* holch * What I notice a lot in open source software, despite often being a very good alternative to comercial stuff, it is often lacking in design and usability.<br />
<br />
</nowiki><br />
<br />
===-Impressions of LS2===<br />
<br />
<nowiki><br />
* holch * What I have seen from macduys mock ups, I think LS2 will not lack in the graphic design area.<br />
* holch * So that is already a good thing.<br />
* holch * But what often happens when a lot of people work on a project is that the information structure can get messed up.<br />
* macduy * yep, so would you agree LS2 needs more work on structure and presentation?<br />
* holch * That is not a fault of the designer or the developers, it is just a normal thing.<br />
* holch * Well, I was really looking forward to LS2 (quite a while now) and when the alpha was available I installed it.<br />
* macduy * please describe your impressions as a first time LS2 user<br />
* holch * Despite that it doesn't have many functions yet, I liked what I saw. However, I really got confused with navigation etc. So I thought, why not start now to give it a more logical structure? Because when I as quite inet and software savy guy get confused, what about others?<br />
* amit8-88 * ok<br />
* holch * Well, I wrote quite a long post about my impressions.<br />
* holch * First thing was, that there are many similiar "concepts" that might be confusing.<br />
* amit8-88 * can you point me to the post ?<br />
* amit8-88 * sorry I did not read it yet<br />
* holch * Like Dashboard and Home, Administration and einstellungen.<br />
* macduy * amit8-88: http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,27466/lang,en/<br />
* amit8-88 * thanks macduy :)<br />
* macduy * so the suggestion would be to merge Dashboard, Home and Administration into 1 "tab"?<br />
* holch * So, as you are still at the beginning I thought it would be important to define a little bit the structure.<br />
* macduy * sure, please elaborate<br />
* holch * I think we should talk about what a user would expect when he logs in. Just a normal user, not the admin.<br />
* holch * And this is nothing that I can decide...<br />
* holch * We might discuss it among the developers, but we could also ask "normal" users.<br />
* amit8-88 * El-Matador-69: can you help us on this ?<br />
* El-Matador-69 * I can just write mit 50cents<br />
* holch * For example, when I log onto a tool like this, I would expect to see the last surveys I have worked on, including the number of respondents that have started, and the ones that have finished.<br />
* holch * Wait: the surveys I have worked on and the ones that are in field.<br />
* jaycburton * Sort of a snapshot<br />
* El-Matador-69 * survey overview<br />
* holch * To give a quick start to the most important day to day work.<br />
* macduy * so, to generalize, a customized "Home" page<br />
* holch * Administration, User-Admin, Panel, etc. is something you usually don't need every day.<br />
* holch * Well, macduy, it doesn't nesessarily need to be customizable, though that would be ideal, especially for advanced users.<br />
* holch * But we should have something on the dashboard by default, that we would consider the most important aspects for the majority.<br />
* macduy * for new users, the dashboard would be built for them automatically<br />
* macduy * when they want/feel like it, they can customize it to their needs<br />
* holch * Everyone else, who is more experienced and knows what he needs already can customize it.<br />
* holch * Because if you don't do a lot of research, you might not know what is important for you, there we could help with our experience.<br />
* holch * There might be some out there, for who it would not fit, but we will have to live with it.<br />
* holch * But to give the whole LS2 a nice logical structure I would need to know what is planned.<br />
* macduy * so, main topic now: Structure of LS2<br />
* macduy * meaning how are individual actions a user can take structured within the navigation of LS2<br />
* holch * I know, there might be a lot more to come, but I think you guys have already loads of stuff planned and in the back of your head which might be implemented only in one or 2 years...<br />
* holch * Yes. Programing the different tools and functions is one thing, getting them together for a logical work flow and navigation is another.<br />
* holch * Limesurvey will have a lot of functions, I assume, based on LS 1.8...<br />
* macduy * let's take a practical example: you raised the question of Assignments before<br />
* holch * yes.<br />
* macduy * but now you understand?<br />
<br />
</nowiki><br />
<br />
===-Assignments===<br />
<br />
<nowiki><br />
* holch * assignment is such a thing that I just don't get.<br />
* macduy * ah :)<br />
* holch * No, not really.<br />
* macduy * so there we stumble on 1 important aspect<br />
* macduy * hiding of programmer's logic in presentation<br />
* holch * Yes. This might be due to me being used to other software as well. But I have seen in the answers to the post, that I am not the only one having problems with assignments.<br />
* macduy * as programmers, we should know how assignments work and how they interact with other parts<br />
* macduy * but as users, should they be introduced to the concept too<br />
* holch * Yes, that could be a solution.<br />
* macduy * or should the programmers code a layer for the users, so that they do not need to know about "assignments", at least not straight away?<br />
* holch * Well, what do you need the assignments exactly for? I assume I have a survey ready to start.<br />
* holch * So where do the assignments come in?<br />
* macduy * Assignments allow you to use a single survey many times<br />
* macduy * without losing track of the previous times you used the survey<br />
* holch * OK.<br />
* holch * This sounds an interesting feature.<br />
* Mazi * arent assignments also used to restrict access like with tokens in LS1?<br />
* macduy * yes<br />
* holch * This means I start a survey, run it for 2 weeks, stop it.<br />
* dqminh * yah, assignments are mainly used to control they way users access the survey<br />
* holch * Then i give it a new "assignment" and the same survey runs a second time and answers are saved in the same database, together with the old answers?<br />
* holch * dqminh, what does this mean?<br />
* Mazi * so if assignments are used for several different issues I think we should separate them instead of having one big assignment overview, what do you think?<br />
* holch * You see, it is already confusing among us, somehow...<br />
* dqminh * holch: it meant you can assign specific users for a survey, the activate and deactivate time of the survey.<br />
<br />
> jasebo has joined<br />
* holch * So it surely takes some time for a normal user to understand it. If there is no way around it, fine. But if we could make it easier for the user, the better.<br />
* jasebo * hi everyone<br />
* dqminh * hi jason ;)<br />
* Mazi * hi jason<br />
* jasebo * sorry I'mlate<br />
* holch * Ok, dqminh, this is an important part!<br />
* macduy * hi Jason<br />
* jaycburton * Hi Jason<br />
* holch * Hi Jason, no problem.<br />
* amit8-88 * hi Jason<br />
* macduy * the survey results actually retain the assignment they belong to<br />
* Mazi * regarding the workflow I think after having created a survey one next logical step can be to ask the user"do you want to restrict access to your survey" and then the user is redirect to the next screen to set assignments<br />
* macduy * so think of it as if you are collecting different SETS of data using 1 survey<br />
* holch * Well, I don't know if this is the right way, Mazi.<br />
* macduy * creating survey is like drafting it on a piece of paper<br />
* macduy * creating assignments is making copies of it and then sending it out to people<br />
* holch * We should get to it a different way: What kind of surveys can u imagine and what are the characteristics of those surveys?<br />
* holch * I am doing a lot of onsite surveys, recruiting respondets directly from a website by a layer poping up, asking every 10th (or whatever the contact rate is set to) user.<br />
* jasebo * I take you all read my post on the forum re: assignments?<br />
* macduy * I believe LS2 aims to cover all possible kinds of surveys? :P<br />
* holch * macduy: Look, this is a good concept...<br />
* holch * Right.<br />
* holch * This is why we should start there.<br />
* holch * What kind of surveys are possible...<br />
* holch * @Jason: Sorry, I didn't...<br />
* jasebo * trying to find it.. it was an explanation of how assignments were originally intended<br />
* jasebo * by the mitre team<br />
* macduy * simple polls, large surveys....<br />
* macduy * it could well work as an interface for entering data.<br />
* Mazi * Jason: http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,27466/lang,en/<br />
* holch * Macduy: But what is the difference of a simple poll and a large survey, basically nothing, except for the length.<br />
* macduy * exactly<br />
* jasebo * http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,27466/lang,en/#28197<br />
* macduy * we should make no assumptions about survey nature<br />
* Mazi * I think it would be nice to have a workflow chart in the wiki showing the current workflow. this way everyone has a clear overview about the current status and we can think about how/where to add addiotnal features like assignments, survey settings, ...<br />
* holch * Thanks Jason, I will try to read it later.<br />
* Mazi * the new workflow should then cover each possible kind of survey<br />
* macduy * holch: the idea is to provide a fairly linear workflow for newbie users<br />
* macduy * e.g.: http://www.marketcircle.com/images/v12/dl/tenways/4.png<br />
* holch * One thing could be to create predefined scenarios for beginners, but I never liked this very much...<br />
* Mazi * "linear", that's what we should aim to<br />
* macduy * hehe, why not?<br />
* jasebo * I dislike being too prescriptive<br />
* Mazi * together with a clear and widerspr&uuml;chlich<br />
* macduy * I agree that LS2 must absolutely remain a sandbox tool<br />
* Mazi * sorry, "clear and non-ambiguous maning"<br />
* Mazi * *naming<br />
* Mazi * ambiguous<br />
* holch * What we shouldn't do is to make LS2 too simple/restricted.<br />
* macduy * yet, for new users, they will be likely to look for "wizards" and other linear, step-by-step worflow<br />
* macduy * with low branching:<br />
* holch * It is aimed to be a leader in survey creating and administration I guess...<br />
* jasebo * hey... we could have this little pop-up paperclip thing that says "It looks like you're trying to write a survey"<br />
* macduy * :P<br />
<br />
</nowiki><br />
<br />
===-Wizards===<br />
<br />
<nowiki><br />
* macduy * say we have these 2 scenarios:<br />
* macduy * Scenario #1: New User<br />
* macduy * 1) new user logs in, sees his homepage, with a couple of links "What would you like to do"<br />
* macduy * 2) He clicks on the, say "create a survey"<br />
* macduy * 3) he<br />
* macduy * 3) he's taken to the survey creation page, with an indicator of his process and what's about to come next<br />
* macduy * (bit like the installer, with numbered steps)<br />
* amit8-88 * Survey Wizard ?<br />
* macduy * basically<br />
* macduy * At each step, he has a list of choices he can do<br />
* macduy * Scenario #2: Experienced user<br />
* holch * This could help for really, really new users.<br />
* Mazi * macduy, that's exactly what I'm thinking of (#1)<br />
* macduy * Mazi: yep<br />
* Mazi * holch, I guess about 80% of our users use limesurvey for just 1-2 surveys<br />
* macduy * but we the idea is to code it on-top, not as part of the code<br />
* Mazi * so there are lots of newbies<br />
* jasebo * macduy: spot on<br />
* macduy * What would an experienced user do, I imagine,<br />
* macduy * is to hop straight to the "Admin" page<br />
* macduy * and do everything himself<br />
* holch * Oh, good to know. Then easy to use is even more important.<br />
* jasebo * the biggest complaint about LS1 is the difficulty in understanding the UI at first<br />
* holch * Wait, wait! the admin page...<br />
* macduy * the hardest bit, I would say, be the transition in between. How do we teach the user to realize how he can reproduce the steps in the Wizard, without using the wizard?<br />
* macduy * I say "Admin" but I'd like to rename it ;)<br />
* macduy * to something like "Manage"<br />
* holch * Yes, LS1 is confusing, because every level looks the same...<br />
* jasebo * "Survey Management"<br />
* jasebo * holch: it seemed like a good idea at the time :)<br />
* macduy * please look at: http://i3.campaignmonitor.com/uploads/images/screenshots/resell/pay.png<br />
* Mazi * this survey manager has to cover all the steps of the "create new survey" wizzard<br />
* holch * Jason, I think the levels aren't that bad, it is just difficult to distinguish between a group, a question, a survey,... Levels are not clear emediately...<br />
* macduy * forget the tabs, but note the progress indicator and the clean heading, with just 4 links<br />
* Mazi * think of a newbie user who wantes to change questions after having passed the wizzard<br />
* macduy * ah, yeah :/<br />
* Mazi * will he use the wizzard again or use the "survey management" for his changes<br />
* Mazi * ?<br />
* holch * I think a wizard would be a solution, but if the standard "survey procedure" is simple enough, no one needs a wizard...<br />
* jasebo * the wizards should be intended for absolute newbies only<br />
* holch * I think we should spend our time on making the survey creation and survey management as simple as possible and every user will be able to use it immediately.<br />
* macduy * Mazi: emost probably a new wizard<br />
* jasebo * if you need a wizard after learning software, there's something wrong with the software<br />
* Mazi * what about having a wizzard for the first set up with clearly names steps and later the user can jump to each step using the survey manager?<br />
* Mazi * * "clearly named steps"<br />
* holch * So what are the "normal steps":<br />
* jasebo * has anyone here ever used the "context sensitive help" in LS1?<br />
* Mazi * never<br />
* amit8-88 * nope<br />
* macduy * ah, good idea!<br />
* holch * Creating a survey with questions, filters, quota, etc.<br />
* Mazi * we should use tooltips at LS2<br />
* holch * this would be step 1<br />
* macduy * LS2 has tooltips<br />
* macduy * to what extent they are helpful, haven't noticed<br />
* holch * Then you want someone to take part in the survey, and there the assignments come in I guess.<br />
* macduy * the wizard can explain at each step what's going on and how the user can later on do these steps himself<br />
* holch * You either want to send the survey to a restricted group of people via email, you recruite on a website (without restriction)<br />
* El-Matador-69 * yes<br />
* macduy * or both :)<br />
* macduy * => 2 assignments<br />
* holch * Both what?<br />
* Mazi * I agree: "the wizard can explain at each step what's going on and how the user can later on do these steps himself"<br />
* macduy * e.g. "Step 3: adding questions - you are now adding questions. you may return to this survey and edit the questions at any time, by doing blah blah blah"<br />
* holch * Ahh, ok. 2 assignments. Does this really happen in the real world?<br />
* macduy * holch: I guess that very unlikely<br />
* macduy * but there will be companies that would consider it vital<br />
* jasebo * holch: what do you mean?<br />
* holch * Why?<br />
* macduy * e.g.<br />
* macduy * a company has 2 departments<br />
* macduy * each using the same survey<br />
* macduy * they don<br />
* macduy * don't want results from both departments to mix together, for obvious reasons<br />
* macduy * hence they create two assignments.<br />
* holch * OK.<br />
* macduy * I'd say that's the power behind assignments<br />
* holch * Makes sense. We would have created just a copy of the survey or would have added a variable to the survey url, that we would have saved in the database for analysis.<br />
* macduy * exactly<br />
* macduy * but the same way I have explained how assignments work<br />
* macduy * we need to do it for all the users<br />
* macduy * teach time what assignments are, at the right time, when they need it<br />
* holch * Yes, OK. Assignments are a good idea. Question is, will it be used by a lot of people without long explanations.<br />
* jasebo * the name is bad<br />
* holch * Exactly, if we need to teach them, something is wrong.<br />
* jasebo * assignments are what you get from your teacher at school<br />
* jasebo * :)<br />
* macduy * :D<br />
* holch * Hahaha.<br />
* macduy * the name is definitely confusing<br />
* amit8-88 * :P<br />
* jasebo * but the concept is good<br />
* holch * The problem with assignments is, that they cover many different aspects.<br />
* macduy * ?<br />
* holch * So it is hard to find one word for it...<br />
* macduy * hehe<br />
* macduy * I<br />
* amit8-88 * yep<br />
* macduy * I'd summarize it as: survey reuse<br />
* amit8-88 * Share Survey<br />
* macduy * :S<br />
* jasebo * I think of the survey creation as "what", and the assignments as "who"<br />
* holch * I could use assignments for different "waves" of a survey, I could use it for specific "groups" of respondents...<br />
* jasebo * distribution?<br />
* macduy * yet that is still not quite precise :/<br />
* holch * Why not avoiding the assignments for the user and keep it a developer thing?<br />
* macduy * I think of "Surveys" as piece of paper and "Assignments" as people going around with those pieces of paper :)<br />
* macduy * holch: that's what I've been considering too<br />
* holch * And give them different concepts in different situations?<br />
* macduy * it could be a new wizard<br />
* holch * What about invitations?<br />
* macduy * "Would you like to reuse on of your surveys?"<br />
* holch * It is basically what you do.<br />
* Mazi * can we split up the assigments into it's single functions? or is this deeply tied in the code?<br />
* macduy * Mazi: what do you mean?<br />
* holch * Or you have to go one step back and rethink what a survey is.<br />
* holch * Because right now we are talking about a questionnaire, when we talk about surveys.<br />
* jasebo * assignments involves 1) Assignment groups, and 2) Applying those groups to a survey<br />
* macduy * 3) public/private<br />
* Mazi * well, there are different usages for assignments (as far as I got it). why not splitting this up into single features with different names instead of having it put together at "assigments"?<br />
* holch * Assignment = survey, Survey = questionnaire.<br />
* holch * Survey= once, questionnaire = reusable.<br />
* macduy * hmmm<br />
* macduy * I see where you're going, but let's see<br />
* holch * because at the moment we are always talking about surveys. But the first step of the survey is creating the questionnaire...<br />
* macduy * yes<br />
* amit8-88 * yeah<br />
* holch * at least in LS, before you have to design the survey.<br />
* holch * So may be we should separate Questionnaire building and survey taking/admin. Just an idea.<br />
* macduy * well, that's what we have right now :)<br />
* macduy * except Questionnaires are called "Surveys" and Surveys are called "Assignments"<br />
* holch * Exactly...<br />
* holch * But if you look at it, surveys are the assignments.<br />
* jasebo * I've missed the questionnaire/survey discussion<br />
* jasebo * are you saying a "questionnaire" is a collection of questions, and a survey is the application of those questions to a group of people?<br />
* holch * Exactly.<br />
* Mazi * jasebo, log: http://pastebin.com/m6147fc53<br />
* holch * You can easily use the same questionnaire twice, but you hardly can do the same survey again (other time, other participants, etc.)<br />
* jasebo * I see<br />
<br />
</nowiki><br />
<br />
===-Survey/Assignment Workflow===<br />
<br />
<nowiki><br />
* El-Matador-69 * I like the phrase "survey structure"<br />
* holch * So there are 3 important parts of LS:<br />
* holch * Questionnaire 'programming'<br />
* holch * Survey taking<br />
* holch * Online reporting<br />
* holch * In the future maybe something like panel administration...<br />
* jasebo * panel administration fits in with the assignment groups<br />
* holch * Well, I think assigments are more like chosing a group of respondents from a panel.<br />
* holch * But there is more to panel administration than that.<br />
* jasebo * well, panels could be expanded later :)<br />
* jasebo * but that's part of the reason for the assignment/assignment group paradigm<br />
* holch * I know, thats why i said in the future...;)<br />
* macduy * seems like panels can be built on thop of that<br />
* holch * And now that I have understood what assignments are for, I am totally in favor of them.<br />
* holch * But just not as "assignments" ;)<br />
* macduy * "Targets"?<br />
* jasebo * so a survey is the combination of a questionnaire, and an assignment?<br />
* holch * But a normal user will have a hard time with it. I am sure an intelligent user will eventually find out what assigments are, but it is not immediately clear.<br />
* jasebo * "Tokens"? :-P<br />
* holch * Hmm.<br />
* holch * hahahaha.<br />
* macduy * lol<br />
* dqminh * :p<br />
* Mazi * I like the "what" and "who" idea. could be a basement for the workflow<br />
* holch * I never got the token thing as well...<br />
* macduy * :D<br />
* macduy * you're not alone ;)<br />
* jasebo hides face in shame<br />
* holch * So how to others do this.<br />
* macduy * is everyone opposed to the name "Assignemnts"?<br />
* holch * Jason: you don't have to be ashamed for having created such a powerful survey tool.<br />
* macduy * I dunno, it makes sense to say "I assign this survey to these bunch of people"<br />
* holch * But now I think it is time bring it out of the geek corner... :)<br />
* holch * Yes, macduy, when you use this sentence it makes sense.<br />
* jasebo * macduy: I think the Mitre people thought of it more like when user x logged in, they'd find they had a new assignment to fill out a survey<br />
* macduy * ahhhh<br />
* macduy * I see now<br />
* jasebo * so it was an assignment from the survey participants view<br />
* holch * jasebo: don't confuse me...<br />
* macduy * holch: everything you understand is still right ;)<br />
* macduy * it's just so happens that you can view it from both angles<br />
* jasebo * yes<br />
* holch * I know, I was just joking.<br />
* macduy * which for me is a good enough reason to retain the word "assignment"<br />
* holch * And I totally agree that we need those assignments. We just have to fit them into LS UI, so that it is clear on first sight (at least for 80-90%) of the users, what they are for.<br />
* macduy * [ ;) I also looked at the LS2 database, where the word "assignment" appears about 20 times :D ]<br />
* jasebo * I was just thinking about that.. thinking.. we could change the name any time we wanted<br />
* macduy * holch: I agree. Assignments are powerful but as with any powerful tool, we need to teach people how to use it ;)<br />
* jasebo * then I thought.. oh.. all the models, etc. all contain "assignment"<br />
* macduy * it's not a problem to expose a different name for the end-user<br />
* holch * Well, I wish maze a lot of fun on the new "what are assignments" forum...<br />
* macduy * it's only a question of the programmers being able to remember that "Target" is actually Assignment in the code etc..<br />
* dqminh * retaining the word "assignment" is ok for me, however imo the current workflow of setting up survey and assignment separately is not intuitive<br />
* macduy * not at al<br />
* jasebo * workflow wiki page would be a good idea<br />
* holch * dqminh: I think it is good to have them separated somehow, but they must integrate with each other.<br />
* macduy * as mentioned earlier<br />
* jasebo * there's some branching involved with assignments<br />
* macduy * this should be taken by the wizard<br />
* jasebo * if you want to 'assign' your survey to a group of users, you need that group to be created first<br />
* holch * Branching?<br />
* holch * exactly.<br />
* macduy * jasebo: nothing ajax can't sort out ;)<br />
* dqminh * holch: yah, you probably want it to be separate when you are maintaining existing survey, not creating new one.<br />
* holch * Where would the group be created?<br />
* holch * dqminh: exactly.<br />
* jasebo * that's the "assignment groups"<br />
* holch * OK.<br />
* jasebo * so many users would want to import a list of people at this stage<br />
* jasebo * others would want to choose a gruop they'd already created<br />
* jasebo * and the rest might just choose to make it public<br />
* holch * Sorry I do not have the LS2 installation on this computer. I thought I have, but I think I installed it on my work computer.<br />
* macduy * holch: demo2.limesurvey.org<br />
* macduy * user/pass: test/test<br />
* Mazi * jasebo, all these options should be put into a workflow chart<br />
* Mazi * ...for the wizzard...<br />
* holch * thanks!<br />
* macduy * btw, previous work: http://www.docs.limesurvey.org/tiki-index.php?page=Interaction+Design+Mockups&structure;=LimeSurvey+Development<br />
* Mazi * ...after that we ca think of how to map each wizzard step at the survey manager<br />
* macduy * yep<br />
* macduy * but I hope you'd agree with me<br />
* Mazi * ah, never seen that wiki page. will be a good start<br />
* macduy * the wizard should be coded on top of LS2, i.e. it will only relate parts that are already there, together<br />
* macduy * so what we really need to concentrate on now<br />
* macduy * is to define the LS2 navigation structure<br />
<br />
</nowiki><br />
<br />
===-Semantic/Interface Structure===<br />
<br />
<nowiki><br />
* macduy * which brings us to the original topic :)<br />
* holch * yes.<br />
* holch * :)<br />
* macduy * currently, the presentation code is horrid<br />
* macduy * it uses an awful lot of repetition<br />
* jasebo * macduy: what do you mean by presentation code?<br />
* macduy * HTML markup<br />
* holch * What I see is that there are different "concepts" that we will need to define and structure: Questionnaires, surveys, assignments, respondents, reporting.<br />
* macduy * e,.g. one page starts with <h1>, another with <h2>...<br />
* holch * This is for the day to day.<br />
* jasebo * macduy: I see<br />
* holch * and then we have stuff like Administration, etc., that we should separate somehow.<br />
* dqminh * regarding the HTML markup, we could use elements to separate them, but again, that not the main topic I think :p<br />
* macduy * also, except for the heading, you may notice that most navigational elements lack consistency<br />
* macduy * there is no "Secondary Navigation" element. We only have the top header ("Primary Navigation") and that's it<br />
* holch * Well, but discussion about primary and secondary navigation is already a step ahead.<br />
* macduy * :) hehe, sorry<br />
* macduy * just some things to keep in mind<br />
* holch * We should first define, what we need to structure.<br />
* holch * What navigations elements will there be.<br />
* macduy * so, as you said previously<br />
* holch * That#s what I wanted to hear from every member of the team. What needs to be in the navigation: just a little brainstorming.<br />
* macduy * i.e.:<br />
* holch * Send me an email with everything that you want to have in the navigation.<br />
* holch * Unstructured!<br />
* macduy * 1) Identify different user concepts (i.e. entities such as: Survey, Assignment, User),<br />
* holch * holger@rothemund.org<br />
* macduy * 2) Identify actions how the user can interact with them<br />
* Mazi * navigation: survey manager, assignments, general survey settings, logout<br />
* holch * Every part of LS2, could be future things too.<br />
* macduy * we need to take a step back<br />
* macduy * look at the engine, see what it can do and built a cockpit out of that<br />
* holch * exactly.<br />
* macduy * is that what you mean, holch?<br />
* holch * yes.<br />
* macduy * ok<br />
* macduy * we'll write a wiki article and post you the link<br />
* jasebo * Navigation: Dashboard/Home | Surveys | Questionnaires | Distribution | People | Settings | Logout<br />
* holch * No wiki! sometimes colaboration can destroy everything, because all will sooner or later adapt stuff of others...<br />
* macduy * :O<br />
* holch * Just an email from everyone who would like to send one.<br />
* macduy * are you sure about this?<br />
* Mazi * k, let's all send holch an email<br />
* holch * Then I bring the stuff together and then we can put it on the wiki. But the collection of ideas often is more fruitful, when it is first done alone.<br />
* amit8-88 * ok<br />
* jasebo * I think a wiki page for workflows would be a good thing to have<br />
* holch * Later we have to work together to bring it all togheter.<br />
* jasebo * not for collaboration, but as a collection point for workflows<br />
* macduy * OK, another summary:<br />
* holch * And try to be abstract. Don't think too much "limesurveyish"<br />
* macduy * :D that'll be hard<br />
* macduy * anyway, summarize:<br />
* jasebo * holch: limesurvey is my life<br />
* holch * I know. But I never said it won't hurt...<br />
* holch * :)<br />
* jasebo * holch: will you send an email to the dev list asking for comments, or do you just want it from us here?<br />
* holch * you can put it on the dev list. I was wondering if we shouldn't involve some normal users as well?<br />
* macduy * they've got the wiki<br />
* jasebo * post in the forum?<br />
* jasebo * run a survey?<br />
* holch * I was thinking of collecting some items/elements that we would need in LS2, in everyones own words. And you guys are probably so involved with the LS wording and thinking, that we won't get much out of the box thinking, those not much new...<br />
* holch * no offence... ;-)<br />
* holch * Just trying to optimize, while we still can. And LS2 is a very good oportunity.<br />
* macduy * LS1 has lots of features<br />
* jasebo * I agree, would be great to get users input<br />
* holch * By the way: does someone know a online card sorting tool that is any good?<br />
* macduy * and I'm sure the wizards of LS1 here will have a long enough list of things LS2 should do ;)<br />
* macduy * holch: ?<br />
* holch * macduy: Don't know what card sorting is?<br />
* holch * Or what's the "?" for?<br />
* macduy * I'm not sure what card sorting is<br />
* holch * It is a usability tecnicque...<br />
* macduy * ah, just checked wikipedia<br />
* holch * to make groups of elements.<br />
* macduy * are you suggesting we let the users make the categorisation?<br />
* holch * Allows you to understand a little bit better how users "think", which mental models they apply to information.<br />
* macduy * ah, I c<br />
* holch * Well, at least I would consider to listen to how their "brain works".<br />
* macduy * hehe ok<br />
* macduy * so is that what you intend to do with our e-mail suggestions?<br />
* holch * Because it often happens that designers and developers are in their little work, where everything makes perfect sence, but users just think different.<br />
* jasebo * holch: users are wrong<br />
* holch * macduy: this is the first step.<br />
* holch * Hahaha.<br />
* macduy * ah, but would you agree that if devs/designers go towards user<br />
* jasebo * :D<br />
* macduy * the user should invest the effort to go our way too?<br />
* macduy * so as to find the middle ground<br />
* macduy * it is already hard enough for developers and designers to walk the same way<br />
* jasebo * remember that beginner users are different to advanced users<br />
* jasebo * and advanced users are much more like developers in their contempt for beginners<br />
* macduy * :O<br />
* holch * jason: yes, and this taks doesn't mean that we will use exactly what the users suggested.<br />
* macduy * ah ok<br />
* jasebo * and intermediate users just complain a lot<br />
* holch * You will probably see that there are various different mental models out there.<br />
* dqminh * holch: http://www.optimalsort.com -- is this what you need ;)<br />
<br />
</nowiki><br />
<br />
===-Templating Admin Interface===<br />
<br />
<nowiki><br />
* holch * If I would have to have a guess, there are probably 3-4 main models and serveral different ones.<br />
* holch * Yeah I know optimalsort, but they charge you... :-)<br />
* macduy * do we want to cater for all of them :)<br />
* dqminh * hmm, they provide free account.I'm not sure about their capabilities as I nerver used card sorting before :D<br />
* holch * But if we can get one logical one, that makes sense, than we are lucky.<br />
* holch * Usually those mental concepts are understood also by other users, it is just not their primary one.<br />
* Mazi * what do you think of creating 2-3 designs for the main navigation bar and then ask for the users input which they prefer?<br />
* holch * Mazi: this could be a good idea, but this is something we can only do in the future, when we know what has to be in the navigation and how to group the different aspects.<br />
* Mazi * althought this is diffucult without having any functionality<br />
* Mazi * agrre!<br />
* holch * Well, there would have to be some functionality at least...<br />
* macduy * the current primary goal is to establish a LS2 interface structure<br />
* macduy * not a graphical one, but semantical one, it that makes sense :)<br />
* macduy * save markup and pretty rounded corners for later<br />
* holch * Exactly: because design will always be something to discuss about anyway.<br />
* holch * Someone loves it, others don't .<br />
* macduy * yep, and graphical presentation would go to waste if the underlying interface it is presenting is crap<br />
* holch * Off topic: is there a plan to have a template system for LS2 (not the questionnaire templates)<br />
* macduy * for the GUI?<br />
* holch * yes, white label...<br />
* holch * kind of.<br />
* macduy * erm, I'd say no :)<br />
* holch * OK:<br />
* macduy * different CSS at most<br />
* Mazi * holch, one can switch between different templates in LS2 already<br />
* holch * For companies it would be interesting.<br />
* macduy * holch: I see<br />
* Mazi * althought there is no template designer, just shipped templates<br />
* macduy * but that would be covered in CSS<br />
* holch * Can you?<br />
* macduy * Mazi: those are survey templates<br />
* macduy * Mazi: they are absolutely customizable, it even has it's own template engine<br />
* Mazi * ahh, sorry. you were talking about admin interface?<br />
* macduy * yeah<br />
* holch * Ahhh, survey templates are vital! LS2 templating would be something optional.<br />
* Mazi * k, got it :)<br />
* holch * What you really should consider is whitelabeling the online reporting.<br />
* jasebo * ls2 admin templating would be nice, we should keep it in mind as we go<br />
* holch * Could be a simple templating.<br />
* dqminh * there's themes concept in Cake, but I would vote not for it in the near future.<br />
* macduy * jasebo, holch: it's a great idea, but I'd say CSS and different images is as far as we'd want to go<br />
* holch * Nothing major, but being able to put your logo in, having your colours...<br />
* macduy * so, CSS :)<br />
* holch * That would be fine.<br />
* macduy * when you said template engine, I assumed, placing navigation in a completely different place, making it vertical, upside-down...<br />
* holch * But for online reporting I consider it very important, when you want to get more "professional"<br />
* macduy * online reporting.. you mean public statistics?<br />
* holch * Macduy, I don't think this would be important.<br />
* jasebo * macduh, dqminh: no, not the near future - but again, knowing it may happen later can affect design decisions bnow<br />
* holch * Well, it depends on what you mean with public statistics.<br />
* macduy * dqminh, elaborate :)<br />
* holch * For me public statistics is not important at all.<br />
* dqminh * elaborate about themes ? :D<br />
* holch * I can't show survey results to everyone.<br />
* dqminh * from what I understand, themes is a different set of views, js , css , ...<br />
* holch * I want to have "assignments" for the access to the results.<br />
* dqminh * so you can define completely different layouts with themes<br />
<br />
</nowiki><br />
<br />
===-Online Reporting/Public Statistics===<br />
<br />
<nowiki><br />
* macduy * dqminh, I meant on public statistics ;)<br />
* macduy * but wait, I'm confused<br />
* macduy * holch: give examples of what you mean by "online reporting"<br />
* macduy * it doesn't quite fit with anything I've seen so far<br />
* holch * That's what most of other survey tools call the presentation of the survey results (and sometimes the survey progress).<br />
* holch * E.g.: I am running a survey with n=1000 for over a month. But the client wants to see some results already after one week. I grant him access to the "online reporting" and he can get a first glimpse at the results.<br />
* dqminh * presentation of results in LS2 is separating into public ( which is available for end users ) and admin statistics<br />
* holch * I think if you want to go a step ahead you would need something in between.<br />
* holch * Or can you restrict the public part to certain users?<br />
* dqminh * we can.<br />
* holch * Because often you can give results to the public (basically all internet users), but you don't want to give a client access to your survey administration.<br />
* holch * so you need something to restrict public statistics.<br />
* holch * Because "public statistics" sounds like accessible for everyone to me.<br />
* Mazi * dqminh, there should be a password protected statistics feature for surveys not using public stats<br />
* dqminh * jasebo: did LS1 have this feature already ? Restricting statistics to part of users ?<br />
* Mazi * these is a feature often requested in the forum, having the ability to pass a password/login protected link to survey statistics to someone else<br />
* Mazi * dqminh, this feature does not exist in LS1<br />
* holch * Exactly: Just allowing access to a group of users, and only to the statistics, not the rest of LS2.<br />
* jasebo * dqminh: not statistics specifically, just access to browsing results<br />
* dqminh * Mazi: i see. Of course we can do that.<br />
* holch * Reporting/statistics should be separated totally from the rest of LS2<br />
* Mazi * great, please put it on your list :-)<br />
* Mazi * that's what we (dqminh) are upt to<br />
* holch * Perfect.<br />
<br />
</nowiki><br />
<br />
!!!-End/Summary<br />
<br />
<nowiki><br />
* holch * Look, I will try to make up some structuring for the content, based on your input that you send me via email. Then we can discuss it and see the advantages and disadvantages of the structure, etc.<br />
* macduy * holch, can you give us an example of what format you expect?<br />
* Mazi * @all, what do you think about weekly LS2 UI meetings for the next weeks until we have set up the general structure?<br />
* jasebo * agree<br />
* holch * From your side I would prefer it to be quite open and individual. I want the view of each of you on LS (no matter if others think it is stupid). In your own (and best simple) words.<br />
* macduy * ok<br />
* amit8-88 * ok<br />
* macduy * in simple, avoid using any limesurvey-related terms?<br />
* jaycburton * Pardon my interruption. I have a little league baseball tournament game to coach in less than two hours. Can someone please email me the log once the meeting is over? TIA. And GO DIAMONDBACKS!<br />
* holch * Give me this list of LS2 elements. Describe how you see it, how you would structure it, whatever I can get. I will try to work trough this (on an individual basis) and then I will try to join it somehow.<br />
* macduy * Jay, np<br />
<br />
< El-Matador-69 has disconnected (Success)<br />
* macduy * I<br />
* macduy * I'm copying the log onto the wiki right now as we speak :)<br />
* jasebo * lol: cya jacyburton<br />
* macduy * cya Jay<br />
* holch * Later we are getting back to "colaboration". But as I said. sometimes it is better to listen to the individuals first.<br />
* jasebo * go Diamonbacks. I'm your number one Aussie fan<br />
* macduy * holch: be sure to play around with LS2 in the mean time too ;)<br />
<br />
< jaycburton has disconnected ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")<br />
* dqminh * cya later jaycburton ;)<br />
* amit8-88 * cya jay<br />
* jasebo * I'm off too.. it's past midnight<br />
* jasebo * I'm about to turn into a pumpkin<br />
* amit8-88 * good night jasebo<br />
* holch * Yes, I will will. I will also play with the 1.85 RC3, because we can learn a lot from the old tool.<br />
* Mazi * bye jason<br />
* macduy * oh noes, cye Jason<br />
* holch * What works, what doesn't.<br />
* holch * Good night!<br />
* holch * I will have lunch soon... hahahaha.<br />
* macduy * :D<br />
<br />
< jasebo has disconnected ("flies off to the RW")<br />
* macduy * first meetings always longer ;)<br />
* macduy * ok, so next week, is everybody happy with timing?<br />
* amit8-88 * yeah :)<br />
* holch * No problem. I enjoyed it.<br />
* Mazi * I'll see if I can attend but in general time is fine<br />
* holch * Next week I won#t be able to make it.<br />
* macduy * sure ;)<br />
* holch * I'll be traveling (most probably) from Thursday to Sunday.<br />
* Mazi * if holch is not availbe we should think about having the next meeting in 2 weeks?!<br />
* macduy * in 2 weeks...<br />
* holch * OK.<br />
* macduy * depends, if there's something urgent...<br />
* holch * Send me an reminder... ;)<br />
* macduy * but 2 weeks is fine ;)<br />
* macduy * I'll register this channel then<br />
* amit8-88 * ok<br />
* macduy * the key is "ls2"<br />
* Mazi * macduy, will you send an email to the mailinglist about next and regular meetings?<br />
* macduy * sure, will do next week<br />
* holch * I will try to work a little on what you will send me as your views of LS2.<br />
* holch * Maybe I can send some file for you to discuss.<br />
* macduy * thanks everyone for making it and attending :)<br />
* Mazi * macduy or holch, can someone summarize the results of this meeting?<br />
* holch * Hahaha, not much results today, right?<br />
* Mazi * always got for everyone just reading the docs to have some kind of conclusion<br />
* macduy * general brainstorming :)<br />
* holch * Have to think on how to structure this process a little more.<br />
* macduy * lemme have a go:<br />
* holch * Never had so many "clients" working with me on the same project...<br />
* macduy * 1) Assignments/Survey Workflow needs work<br />
* holch * And the users I can control better... :D<br />
* macduy * 2) Think about Wizards and Workflows<br />
* macduy * 3) Send holch entities of LS2 and actions they can perform<br />
* macduy * 4) construct a semantic structure in near future<br />
* macduy * all from me :), anyone else?<br />
<br />
</nowiki></div>Macduyhttps://www.limesurvey.org/manual/index.php?title=UI_meeting_3_(20th_June)&diff=3508UI meeting 3 (20th June)2009-06-22T13:39:16Z<p>Macduy: </p>
<hr />
<div><br />
= Summary=<br />
<br />
<div class="simplebox">''(by macduy)''<br />
* Distinction between a '''"Questionnaire"''' (a form containing questions) and a '''"Survey"''' (the act of collecting data using a Questionnaire). In current LS2 implementation referred to as Survey and Assignment respectively. '''New intuitive terms are needed! It should be clear that a Questionnaire is a component of Survey'''<br />
* Use '''"invite"''' instead of '''"assign"''', as it sounds more friendly and less technical, less raw.<br />
* Participants:<br />
** add, delete, edit, create lists/groups<br />
* Invitations:<br />
** Quick Invite: e.g. using e-mails<br />
** Add previous participants, already in the system<br />
* Statistics/Reporting page:<br />
** Survey Stats (# of respondents, recent activity etc.)<br />
** Survey results<br />
** Panel features (e.g. responses from participants of age > 25 etc.) - FUTURE<br />
<br />
</div><br />
<br />
=- Meeting Log=<br />
<br />
'''dhardisty:''' hi<br />
<br />
'''holch:''' Good morning everyone!<br />
<br />
'''dhardisty:''' morning!<br />
<br />
'''holch:''' Sorry for being late. But I tried to get in for the last 30 minutes.<br />
<br />
'''holch:''' Finally figured out some way.<br />
<br />
'''dhardisty:''' I think the time is pretty early for you and me, eh? Especially after being out late on Friday night here in NY...<br />
<br />
'''dhardisty:''' No one has said anything until you got here<br />
<br />
'''holch:''' I think it is worse for you.<br />
<br />
'''holch:''' For me 9 is OK.<br />
<br />
'''dhardisty:''' so I think it's just you and me for now<br />
<br />
'''dhardisty:''' yeah, 8am here<br />
<br />
'''holch:''' Is it?<br />
<br />
'''dhardisty:''' soon I'm going to Seattle for 3 weeks<br />
<br />
'''dhardisty:''' where it would be 5am<br />
<br />
'''holch:''' That's OK.<br />
<br />
'''holch:''' Oh, that is bad. Maybe we can check who will join on a regular basis and then set the timing.<br />
<br />
'''dhardisty:''' especially if it's just you and me at the meetings =P<br />
<br />
'''holch:''' How was the last meeting? I read through the log, but...<br />
<br />
'''holch:''' 1st meeting was quite difficult to follow.<br />
<br />
'''dhardisty:''' basically just introducing ourselves (Columbia)<br />
<br />
'''holch:''' Everyone was full of ideas and they were just firing.<br />
<br />
'''dhardisty:''' and we agreed that you were in charge ;)<br />
<br />
'''holch:''' Which is good, but it was really hard to follow and keep controll...<br />
<br />
'''holch:''' Look, I don't need to be in charge. I think this is a team thing.<br />
<br />
'''dhardisty:''' at the last meeting, we agreed that the first step was to work on the "general application structure"<br />
<br />
'''holch:''' But anyway. Let's talk business...<br />
<br />
'''dhardisty:''' and not worry about the details of everything until after that<br />
<br />
'''holch:''' Yes, I think this is important. We need to structure the whole thing a little bit.<br />
<br />
'''holch:''' I thought about several navigations instead of one, as it is right now.<br />
<br />
'''holch:''' I would take all the general admin stuff out of the main navigation and put it on a secondary navigation.<br />
<br />
'''dhardisty:''' we basically had 4 people at the last meeting -- me, my friend Jon (also from Columbia), and two developers<br />
<br />
'''dhardisty:''' I think that's a good idea, because admin stuff isn't used very often<br />
<br />
'''holch:''' OK. The first time it was quite full... I can't remember how many of us were there, but the kept on coming and leaving... :-)<br />
<br />
'''holch:''' Exactly.<br />
<br />
'''holch:''' You don't change the general settings of your installation everyday. Nor do you add/edit users on a daily basis or change your profile...<br />
<br />
'''holch:''' So lets take this out of the way of the normal user.<br />
<br />
'''holch:''' What are the main features?<br />
<br />
'''dhardisty:''' you mean, the main features of LimeSurvey2?<br />
<br />
'''holch:''' I think there are 3 big areas, I don't know if you agree.<br />
<br />
'''holch:''' 1. Surveys (I would call them questionnaires anyway)<br />
<br />
'''holch:''' 2. Respondents or survey related<br />
<br />
'''holch:''' 3. Reporting / results / statistics<br />
<br />
'''holch:''' Anything else you could think of?<br />
<br />
'''dhardisty:''' yeah, sounds good<br />
<br />
'''holch:''' Because currently LS uses survey for anything.<br />
<br />
'''holch:''' But from my point of few most time it is questionnaires they are talking about.<br />
<br />
'''holch:''' For me a questionnaire is the List fo questions, with all filters, answer options, etc.<br />
<br />
'''dhardisty:''' in this case, though, they may be attached to the word survey, because it is the title afterall, Limesurvey, ;)<br />
<br />
'''holch:''' A survey is when you send that questionnaire out to people. But I might be wrong.<br />
<br />
'''dhardisty:''' I'll read up definitions a bit right now<br />
<br />
'''holch:''' Well, I don't think we should skip the word survey.<br />
<br />
'''holch:''' I just would distinguish between questionnaires and surveys.<br />
<br />
'''holch:''' A questionnaire could be used for several surveys, a survey can have several questionnaires.<br />
<br />
'''holch:''' I think "survey" is the real "assignment"... :-)<br />
<br />
'''dhardisty:''' ha, nice idea!<br />
<br />
'''dhardisty:''' here's the Oxford English dictionary definition for survey:<br />
<br />
'''dhardisty:''' A systematic collection and analysis of data relating to the attitudes, living conditions, opinions, etc., of a population, usu. taken from a representative sample of the latter; freq. = POLL n.1 7d. Also preceded by a defining word, as (public) opinion survey, social survey:''' see under the first element.<br />
<br />
'''holch:''' Well, I think this definition is a little "narrow minded", but it sums it up, more or less...<br />
<br />
'''dhardisty:''' I don't know if it will fit with what LS2 normally does, but the questionnaire & survey breakdown you proposed would fit what we do (in our research at Columbia) very well<br />
<br />
'''dhardisty:''' we do different surveys<br />
<br />
'''dhardisty:''' and each survey is composed of several questionnaires<br />
<br />
'''dhardisty:''' one might be a demographic questionnaire<br />
<br />
'''holch:''' It would fit with what I do as well.<br />
<br />
'''dhardisty:''' and we might use this same demographic questionnaire in each survey<br />
<br />
'''holch:''' Right. That is what I am talking about.<br />
<br />
'''holch:''' A questionnaire turns (more or less) into a survey, once you "assign" respondents to it.<br />
<br />
'''dhardisty:''' So, at least in the way that we use LimeSurvey, I support your breakdown and terminology 100% :)<br />
<br />
'''holch:''' You can use the questionnaire over time, for waves of a survey too.<br />
<br />
'''holch:''' While the survey itself is changing (e.g different respondents, or different time), the questionnaire might be reused for comparability.<br />
<br />
'''holch:''' So if we would split this up, what would we need in "Questionnaires"?<br />
<br />
'''dhardisty:''' 1. Create new questionnaire<br />
<br />
'''holch:''' Create/edit/delete<br />
<br />
'''dhardisty:''' 2. Edit questionnaire<br />
<br />
'''dhardisty:''' yes<br />
<br />
'''holch:''' OK. An overview of the questionnaires would be nice.<br />
<br />
'''holch:''' The survey thingy is a little bit more difficult to grab.<br />
<br />
'''dhardisty:''' Maybe we call the section "survey respondents"<br />
<br />
'''dhardisty:''' and in this section we put "token" management as well as "assignments"<br />
<br />
'''dhardisty:''' (but with better names)<br />
<br />
'''holch:''' Would be an option.<br />
<br />
'''holch:''' I am not sure if the LS team will be too happy with it. As you said, they use survey for years now. If we take the survey too much out of it... ;-)<br />
<br />
'''holch:''' So what would be in this section?<br />
<br />
'''dhardisty:''' yes, especially because we are the upstart newcomers ;)<br />
<br />
'''holch:''' 1. Overview of surveys / active surveys / own surveys<br />
<br />
'''holch:''' Exactly.<br />
<br />
'''dhardisty:''' 2. Invite people to surveys<br />
<br />
'''holch:''' I am not sure if it is good to suggest such an "extreme" step.<br />
<br />
'''holch:''' I like "invite" a lot more than "assign".<br />
<br />
'''dhardisty:''' yes, me too<br />
<br />
'''holch:''' Inviting is what we are doing, not assigning.<br />
<br />
'''holch:''' Soons like the respondents are obligated...<br />
<br />
'''dhardisty:''' like it is a homework assignment or something<br />
<br />
'''holch:''' This would lead me to a 4 steps approach:''' Questionnaires, Surveys, Respondents, Reporting<br />
<br />
'''dhardisty:''' 3. Monitor survey invitations (?)<br />
<br />
'''holch:''' This is an important one!<br />
<br />
'''dhardisty:''' yes, to see the response rate, etc -- but maybe this goes in reporting<br />
<br />
'''dhardisty:''' or maybe both<br />
<br />
'''dhardisty:''' anyway, I think the 4 categories sound good<br />
<br />
'''holch:''' No, I think response rates are not reporting.<br />
<br />
'''You are now known as Mazi<br />
<br />
'''holch:''' Or at least they should also be connected to the surveys.<br />
<br />
'''holch:''' Hi Mazi.<br />
<br />
'''dhardisty:''' hello!<br />
<br />
'''Mazi:''' Hi @all<br />
<br />
'''dhardisty:''' it's just us three -- nice to have a dev here!<br />
<br />
'''holch:''' Or better:''' High you 2... :-)<br />
<br />
'''Mazi:''' just reading up the log...<br />
<br />
'''holch:''' OK.<br />
<br />
'''Mazi:''' ...a short note about survey vs questionnaire:''' this might become difficult for suppoort because user might ahve problem to idfferentiate...<br />
<br />
'''dhardisty:''' we UI people are running amok and changing everything ;)<br />
<br />
'''Mazi:''' if we have a wokrflow not showing survey AND questionaire at one screen this will be fine.<br />
<br />
'''Mazi:''' the app has to guide the user<br />
<br />
'''Mazi:''' so he doesn't wonder about the word survey/questionnaire<br />
<br />
'''holch:''' Mazi:''' actually I think users differentiate, but old LS users might be confused at the beginning.<br />
<br />
'''holch:''' But we would be really consequent, I agree.<br />
<br />
'''Mazi:''' I also agree to rename assignements to invitations<br />
<br />
'''holch:''' I am aware that this might be difficult.<br />
<br />
'''holch:''' But I would give it a try in a small test.<br />
<br />
'''Mazi:''' holch, there might be problems when having two terms.<br />
<br />
'''holch:''' Well, you need 2 terms, because it is 2 different things.<br />
<br />
'''Mazi:''' right now I can't think of two suitable translations in German. what about other languages which might only use one word for this<br />
<br />
'''Mazi:''' might raise problems<br />
<br />
'''holch:''' Maybe we need to rethink the survey vs. questionnaire wording.<br />
<br />
'''Mazi:''' just my 2 cents<br />
<br />
'''holch:''' Fragebogen, Umfrage<br />
<br />
'''dhardisty:''' Maybe then we have "surveys" and "survey components" or soemthing like that? So that one term is obviously a subcomponent of the other<br />
<br />
'''Mazi:''' k, this fits. not sure about other languages though<br />
<br />
'''dhardisty:''' I don't have the best solution, but ideally the words should clearly demonstrate the relationship between the concepts<br />
<br />
'''Mazi:''' components might be a good approach<br />
<br />
'''holch:''' Questionario, encuesta<br />
<br />
'''holch:''' questionario, pesquisa (PT)<br />
<br />
'''Mazi:''' holch, what do you think about the "components" suggestion? It also makes clear how these parts are depending on each other<br />
<br />
'''holch:''' Hmm, first problem:''' I don't really know what the survey and what the survey components are?<br />
<br />
'''holch:''' Again, a survey is the whole project.<br />
<br />
'''dhardisty:''' basically, "survey component" = "questionnaire"<br />
<br />
'''Mazi:''' would be nice to have some more input on this, El-Matador-69, dqminh, what do you think?<br />
<br />
'''Mazi:''' dhardisty, I agree<br />
<br />
'''holch:''' Hmmm, to be honest, for me it would be clearer to have survey vs. questionnaire. because everyone should know what a questionnaire is. If the would use survey synonimous, then at that point the would have to think for a second.<br />
<br />
'''dhardisty:''' they haven't said anything since I got here an hour ago, so you may be waiting awhile for their response ;)<br />
<br />
'''holch:''' But it should be clear soon, what is the difference between a survey and a questionnaire.<br />
<br />
'''holch:''' my 2 cents.<br />
<br />
'''Mazi:''' holch, I also agree to your arguments. as long as we don't have survey and quest. in the same menu/navigation element it will be fine<br />
<br />
'''holch:''' But at least we agree, that we have to separate the "project" (survey) from the "questionnaire" (or survey component)...<br />
<br />
'''Mazi:''' as said, the workflow has to be clear to the user like creating a survey first and then adding survey components/questionnaires<br />
<br />
'''holch:''' Actually I think it will only work if the ARE in the same navigation.<br />
<br />
'''holch:''' Because people who did not distinguish between the two aspects, would have notice that there must be a difference obviously.<br />
<br />
'''Mazi:''' holch, I'm very interested in c_schmitz and jasebos (LS2 head developers) opinions about this differentiation.<br />
<br />
'''holch:''' If you use it on different levels, mixing the two, then we will be in real trouble.<br />
<br />
'''Mazi:''' we also have to take a look at this from the developers view<br />
<br />
'''holch:''' Mazi:''' me too. ;-)<br />
<br />
'''holch:''' And I am totally aware that it might be difficult to convince them. But I would try.<br />
<br />
'''Mazi:''' to see in what extend such a separation is posible at all or if the core engine has to be rewritten for this<br />
<br />
'''holch:''' But I would also like to hear comments from less experienced people with LS. Because at the end it is them using it. The hardcore user will get used to anything anyway.<br />
<br />
'''Mazi:''' holch, can you send an email to the mailing list about this to a) ask for other opinions and b) ask c_schmitz/jasbo about it?<br />
<br />
'''holch:''' And let me get this straight:''' I am not here to change everything. I would if it makes sense and the others agree, but I don't to cause trouble in the team.<br />
<br />
'''dhardisty:''' as I mentioned last week, I can get the reactions of many naive users here<br />
<br />
'''Mazi:''' holch, I totally understand<br />
<br />
'''Mazi:''' dhardisty, that would be great. other opinions are always helpful<br />
<br />
'''holch:''' Mazi, I will try to note all that down, what we were talking today, try to make a little "concept" and send it around, asking for opinions.<br />
<br />
'''Mazi:''' thanks, holch!<br />
<br />
'''dhardisty:''' yeah, thanks!<br />
<br />
'''Mazi:''' and sorry for interrupting your discusion<br />
<br />
'''holch:''' It might cause a little controversy, but that is OK, I think. Because it would make everyone think.<br />
<br />
'''dhardisty:''' haha, not at all!<br />
<br />
'''dhardisty:''' it is much better to have a dev here<br />
<br />
'''dhardisty:''' so no interruption at all<br />
<br />
'''holch:''' Mazi, by the way, thank you for the email with your view of LS.<br />
<br />
'''Mazi:''' no problem<br />
<br />
'''holch:''' You were one of 2. ;-)<br />
<br />
'''Mazi:''' 2? that sucks.<br />
<br />
'''holch:''' Well, its OK.<br />
<br />
'''Mazi:''' but there has already been an email to the list about this, right?<br />
<br />
'''Mazi:''' ...aksing for feedback<br />
<br />
'''holch:''' Answers in general were very "LS" anyway. Yes there has been an email, I think.<br />
<br />
'''holch:''' But anyway. I think I will change strategy.<br />
<br />
'''holch:''' I will think about an alternative concept, I will propose it and THIS will create responses for sure... :-)<br />
<br />
'''Mazi:''' holch, I will send another email to the list, asking for feedback to be forwarded to you<br />
<br />
'''holch:''' No, Mazi, I think it is OK.<br />
<br />
'''Mazi:''' 2 responses from my point of view are not enough, but you know better<br />
<br />
'''Mazi:''' with some pushng it might be easy to get more feedback<br />
<br />
'''holch:''' I think once I have send that concept, it is easier for everyone to participate. My first request was probably too "abstract", because I wanted you guys to go back to the basics and think out of the box. Didn't really work as expected, so we will try it an other way.<br />
<br />
'''Mazi:''' I agree.<br />
<br />
'''holch:''' I think once there is a list of areas and actions it will be easier for them to start the feedback.<br />
<br />
'''Mazi:''' definately<br />
<br />
'''holch:''' And if it is critizing my concepts, that is fine.<br />
<br />
'''Mazi:''' ;-)<br />
<br />
'''Mazi:''' so let's continue with the next topic if this can be considered as "done"<br />
<br />
'''holch:''' At least they think about it and have to search for alternatives.<br />
<br />
'''holch:''' Yes.<br />
<br />
'''holch:''' So, what about the area "respondents"?<br />
<br />
'''holch:''' add new respondents<br />
<br />
'''holch:''' create a list of respondents<br />
<br />
'''Mazi:''' the second meaning of "assignments" :-)<br />
<br />
'''holch:''' Exactly.<br />
<br />
'''holch:''' But isn't it clearer?<br />
<br />
'''holch:''' I think everyone will understand it.<br />
<br />
'''dhardisty:''' yes<br />
<br />
'''Mazi:''' I vote for "participants"<br />
<br />
'''holch:''' participants is good.<br />
<br />
'''Mazi:''' even more clearer from my point of view<br />
<br />
'''holch:''' Better than respondents.<br />
<br />
'''dhardisty:''' sure, participants is great for us<br />
<br />
'''Mazi:''' fine<br />
<br />
'''dhardisty:''' because in psychology research we call them participants all the time<br />
<br />
'''holch:''' Not 100% exact either, but closer than respondents.<br />
<br />
'''Mazi:''' is there anything in detail that has to be discussed about "participants"?<br />
<br />
'''holch:''' Probably "invites" would be probably more exact, but anyway.<br />
<br />
'''Mazi:''' from my point of view this should be the next step after having created the first survey using the wizzard. to create a list of participants or set the survey to open acces<br />
<br />
'''holch:''' Hmm, no, I think participants/respondents/invites would be quite straight forward:<br />
<br />
'''holch:''' But wasn't it agreed that the wizard will come only later?<br />
<br />
'''dhardisty:''' we could have participants within the invitations section<br />
<br />
'''holch:''' In this case I would try to make the general structure as good as possible and then think about wether we need a wizard anyway.<br />
<br />
'''holch:''' If the structure is straight forward, a wizard would probably counterproductive anyway.<br />
<br />
'''dhardisty:''' so we have four sections on the top level (?):''' questionnaires/survey-components, surveys, invitations, and results<br />
<br />
'''holch:''' I think priority one is, to make a logical structure which 95% of the users will undersand immediately or without major problems,.<br />
<br />
'''dhardisty:''' and participants (making groups of them, etc) goes within the invitations section<br />
<br />
'''dhardisty:''' (?)<br />
<br />
'''dhardisty:''' yes holch -- I agree that we should worry about the basic structure first<br />
<br />
'''holch:''' Hmmm, yes, it would me more or less like this.<br />
<br />
'''dhardisty:''' and don't think about the wizard until afterwords<br />
<br />
'''dhardisty:''' once we have the basic design in place, then we can consider whether or not to use a wizard<br />
<br />
'''holch:''' And there would be a secondary navigation, where the whole general administration and user admin would be.<br />
<br />
'''dhardisty:''' right<br />
<br />
'''holch:''' So in the invitation section, what would we need?<br />
<br />
'''holch:''' I think this is the most difficult section.<br />
<br />
'''holch:''' Because my respondent section would have been simple, and the survey section more complicated. By naming it invitation there would be moved some stuff from the survey section to invitation.<br />
<br />
'''dhardisty:''' right<br />
<br />
'''holch:''' Participants:''' add, delete, edit participants / create lists, groups of participants<br />
<br />
'''dhardisty:''' So in the invitation section, you have:<br />
<br />
'''dhardisty:''' yes<br />
<br />
'''dhardisty:''' plus also create / track invitations<br />
<br />
'''holch:''' OK.<br />
<br />
'''dhardisty:''' so you think that create and track invitations should go in with surveys?<br />
<br />
'''Mazi:''' holch, LS2 is designed to have a real panel system, much better than the token stuff in LS1<br />
<br />
'''Mazi:''' this should be kept in mind for the invitation part<br />
<br />
'''holch:''' Hmm, either that, or have an own section. Don't know if this makes it more complicated.<br />
<br />
'''holch:''' But if we have a "participants" section, we would also have a little "panel software" already.<br />
<br />
'''holch:''' This could become quite huge in the future.<br />
<br />
'''Mazi:''' I'm also thinking about the possibility of assigning people depening on their user data like "only user older than 25, only males"...<br />
<br />
'''holch:''' With a lot of features...<br />
<br />
'''Mazi:''' ...but that's future stuff<br />
<br />
'''holch:''' Exactly. That would be a panel<br />
<br />
'''holch:''' You are right. But a basic panel function would be needed from the beginning. Of course without all the segmentation stuff, but at least a list of participants and the possibility to group them.<br />
<br />
'''Mazi:''' sure<br />
<br />
'''Mazi:''' I'm not sure if it's useful to already discuss layout details right now. I always like having 2-3 designs and discuss details based on this. what do you think?<br />
<br />
'''holch:''' But if we could keep this quite separated from the beginning, I think it would be easier to implement the more advanced panel functions later.<br />
<br />
'''Mazi:''' It's a pity that macduy isn't with us today...<br />
<br />
'''holch:''' It's OK. I think we made a bigger step ahead today then the first time.<br />
<br />
'''Mazi:''' I think it might be useful to have two parts:''' 1. add participants together with their data and 2. have a screen to assign people to surveys<br />
<br />
'''holch:''' Mazi, I don't get this one...<br />
<br />
'''Mazi:''' 2. should be kept simple so that user who only run one survey can easily assign all availabpe participants to a survey at once with one click<br />
<br />
'''dhardisty:''' I think he is proposing that we split "participants" and "invitations" into separate sections<br />
<br />
'''Mazi:''' exactly<br />
<br />
'''holch:''' Definetly.<br />
<br />
'''Mazi:''' first screen to get the panel data, second screen to assign people to survys<br />
<br />
'''Mazi:''' fine<br />
<br />
'''dhardisty:''' that's fine with me -- it is a logical separation<br />
<br />
'''holch:''' I would also not require to add every participant necessarily to the general list of participants.<br />
<br />
'''Mazi:''' ? please explain?<br />
<br />
'''holch:''' While this might be very interesting for many surveys, sometimes you have a list of people that you know you won't use again. So just upload an CSV and thats it.<br />
<br />
'''dhardisty:''' or better yet:''' copy and paste their emails into a text box<br />
<br />
'''holch:''' Then for others it might be interesting to have them in your list of participants for future surveys --> add them to the panel.<br />
<br />
'''dhardisty:''' making a csv file is hard for some people<br />
<br />
'''Mazi:''' I see. there have to be functions to easily group participants and delete / add groups and assign them<br />
<br />
'''holch:''' OK, copy and paste is fine, uploading an excel sheet is OK, adding one by one...<br />
<br />
'''Mazi:''' dhardisty, I like the import by adding a simpel list of emaila dresses<br />
<br />
'''holch:''' But honestly, I would either put the invitation process in the survey section, or I would have an extra section for the invitations.<br />
<br />
'''Mazi:''' why?<br />
<br />
'''dhardisty:''' I think maybe what holch means is this:''' when you go to invitations, you have two options. One is a "quick invite" where you just put in email addresses. The other is where you select participants (or groups of participants) that you have previously entered in the participants section<br />
<br />
'''holch:''' Because the invitation has usually to do with the survey.<br />
<br />
'''Mazi:''' holch, that's the problem:''' to offer both, panel functionalty AND easy to use interface for one time users<br />
<br />
'''holch:''' I would like to have a simple area where you just take care of the details of your participants.<br />
<br />
'''Mazi:''' dhardisty, yet another great idea :-)<br />
<br />
'''holch:''' Then you can select the ones you want to have in the survey and create a "group" or "list", you name it.<br />
<br />
'''dhardisty:''' not my idea, but thanks ;)<br />
<br />
'''holch:''' Then from the survey section you can either choose one of those groups or just paste the emails.<br />
<br />
'''Mazi:''' yeah, this will get tricky when talking about the details later, holch<br />
<br />
'''Mazi:''' has to be put into the workflow "somehow"<br />
<br />
'''holch:''' I think it is quite easy to put in the work flow.<br />
<br />
'''Mazi:''' I think we need some forking at that point<br />
<br />
'''holch:''' You create a survey, add a questionnaire to the survey, add participants to the survey.<br />
<br />
'''holch:''' You can either decide to create a new questionnaire, or use an existing one.<br />
<br />
'''holch:''' Or you can add new participants for this survey, or add new ones.<br />
<br />
'''holch:''' And there are surveys, where you just have a link, and don't need to send invitations to specific users.<br />
<br />
'''holch:''' So there you are flexible.<br />
<br />
'''Mazi:''' holch, are you familiar with creating workflow diagrams?<br />
<br />
'''Mazi:''' would be great to see this on paper<br />
<br />
'''Mazi:''' makes it easier to share with others and to discuss details<br />
<br />
'''holch:''' Mazi, I had started this last saturday, to bring my thoughts down on paper, but couldn't finish. I will try to come up with something this week so we can discuss it next saturday.<br />
<br />
'''Mazi:''' that would be great!<br />
<br />
'''holch:''' Not last, but the one before.<br />
<br />
'''holch:''' Of course.<br />
<br />
'''holch:''' What about reporting, statistics, results section?<br />
<br />
'''Mazi:''' we also need someone to sum up this meeting at the wiki. macduy did this before, maybe he can do so again.<br />
<br />
'''Mazi:''' that's important for other user who didn't participate so the knwo what we have come up to<br />
<br />
'''Mazi:''' I will create the according wiki pages so holch can add the workflow ther<br />
<br />
'''holch:''' Well, I can write a short sum up, because we can't go into the details anyway.<br />
<br />
'''Mazi:''' would be great<br />
<br />
'''dhardisty:''' so, in this section, we have:''' view results, export results, compare results (?)<br />
<br />
'''dhardisty:''' what else?<br />
<br />
'''dhardisty:''' maybe compare is too much<br />
<br />
'''Mazi:''' agree, let's leave out compare<br />
<br />
'''Mazi:''' can we call this "survey statistics" in general<br />
<br />
'''Mazi:''' dqminh, that's your part!<br />
<br />
'''dhardisty:''' sure, but then what is the difference between view results and "survey statistics"?<br />
<br />
'''holch:''' Well, to be honest, I don't like statistics.<br />
<br />
'''Mazi:''' we can have a different wording<br />
<br />
'''dhardisty:''' maybe one is browsing individual responses, and the other is summary stats?<br />
<br />
'''dhardisty:''' I'm not arguing the wording -- I don't even know the concepts yet<br />
<br />
'''holch:''' Because there are the survey statistics (invitations, started interviews, finished interviews, etc.) and then the actual results of the survey.<br />
<br />
'''dhardisty:''' of what you have planned<br />
<br />
'''dqminh:''' statistics will include simple overview of the survey results:''' like % completed, number of people taken the survey, result's diagram for each question.<br />
<br />
'''Mazi:''' dhardisty, dqminh is working on the statistics part to show results of a survey<br />
<br />
'''dqminh:''' result is more like exporting the whole result into a file.<br />
<br />
'''holch:''' Compare results, what do you refere to with that?<br />
<br />
'''dhardisty:''' I think it is probably too complicated, but I was thinking if you have different groups of participants you want to compare<br />
<br />
'''dhardisty:''' or different surveys to compare<br />
<br />
'''dhardisty:''' like for pre and post test<br />
<br />
'''dhardisty:''' or maybe compare men and women<br />
<br />
'''dhardisty:''' but I think that is too much<br />
<br />
'''holch:''' This would be a very advanced killer feature.<br />
<br />
'''holch:''' Even many big ones don't offer this.<br />
<br />
'''dhardisty:''' those of us who need to do that can do it in a statistics package<br />
<br />
'''dhardisty:''' maybe we just put this on a wish list for "some day"<br />
<br />
'''dhardisty:''' and when LS2 is super popular and gets lots of funding, then we add it ;)<br />
<br />
'''holch:''' But if we could get an advanced tabulation feature one day, LS would be getting so much more users.<br />
<br />
'''dqminh:''' possible ;) I logged it already :D<br />
<br />
'''holch:''' Thats fine. We need to note this ideas down.<br />
<br />
'''holch:''' Even if they are not for now.<br />
<br />
'''Mazi:''' holch, what do you mean by "tabulation feature"? a kind of filter like "only show results of people who answered Q2=male"?<br />
<br />
'''holch:''' So we will put the following into "results/statistics/reporting":<br />
<br />
'''holch:''' Well, cross tabs would be the term I was thinking of.<br />
<br />
'''holch:''' Having a table showing total results, and results for special groups side by side.<br />
<br />
'''Mazi:''' let's put this on dqminh's list (if it's not already listed)<br />
<br />
'''holch:''' Eg. Overall satisfaction:''' First column = all respondents, second column = male, 3rd column = female, 4th column = 15-20 year olds, etc.<br />
<br />
'''dqminh:''' Mazi, I havent thought about that before. However we did have the group concept already.<br />
<br />
'''Mazi:''' holch, this will be quite complicated to implement. lt's only put it on the list for later and see to what extend the group feature can cover this<br />
<br />
'''Mazi:''' It's = let's<br />
<br />
'''holch:''' I know. That was just thinking about future...<br />
<br />
'''Mazi:''' fine<br />
<br />
'''Mazi:''' let's continue with "So we will put the following into "results/statistics/reporting":"<br />
<br />
'''holch:''' "survey statistics" like invitations send, interviews started, interviews finished, abortion statistics, etc.<br />
<br />
'''holch:''' "survey results":''' tables, graphs for each question, later maybe advanded cross tabluation features (what we had discussed right now)<br />
<br />
'''dhardisty:''' and "export results"<br />
<br />
'''holch:''' "export results/data/answers". I would make this also accessible from the survey section.<br />
<br />
'''holch:''' Something else, maybe you can help me...<br />
<br />
'''dhardisty:''' "export" is a familiar term for all of us, but maybe we should call it "download" instead? that might be better for brand new users<br />
<br />
'''dhardisty:''' "download results"? Or is export common and understandable enough for new people? Maybe it's fine<br />
<br />
'''holch:''' I am looking for a good wording for "user administration" with in the general LS administration section. I wouldn't want to have another "admin" within the admin.<br />
<br />
'''dhardisty:''' I'm just brainstorming here<br />
<br />
'''holch:''' Download sounds good.<br />
<br />
'''holch:''' but export isn't that bad either...<br />
<br />
'''dqminh:''' export is more familiar with users I guess. Excel and OO both use Export ...<br />
<br />
'''holch:''' We will see.<br />
<br />
'''Mazi:''' I vote for export because this is the term used in LS1<br />
<br />
'''holch:''' This is a good one for actual normal users.<br />
<br />
'''dhardisty:''' ok, sounds good<br />
<br />
'''dhardisty:''' so back to what we call the "user admin":<br />
<br />
'''holch:''' Well, first you export the data you want, then you download the file.<br />
<br />
'''dhardisty:''' (including settings, permissions...)<br />
<br />
'''holch:''' This is how it works in Globalpark.<br />
<br />
'''holch:''' Because it gives you some flexibility.<br />
<br />
'''Mazi:''' about "user admin":''' the wording should always clearly differentiate between "participant" and "user" which might be another admin with less rights<br />
<br />
'''holch:''' In the export part, you decide what you want to select, which responses (all, only the complete ones), the whole survey or only some answers, etc.<br />
<br />
'''Mazi:''' when having a "user xxx" menu entry it always has to be clear what is meant by this<br />
<br />
'''holch:''' Mazi, I totally agree.<br />
<br />
'''holch:''' But for me it is quite clear. User=person using LS. Participant/respondent = person giving responses to a survey.<br />
<br />
'''Mazi:''' is there another term for "user" = person with LS admin rights?<br />
<br />
'''holch:''' Hmm, Limesurfer...<br />
<br />
'''Mazi:''' lol<br />
<br />
'''holch:''' :-)<br />
<br />
'''Mazi:''' Limenist<br />
<br />
'''Mazi:''' Limemenist<br />
<br />
'''Mazi:''' Limer<br />
<br />
'''holch:''' Participants only have contact with LS via the questionnaire. The usually don't even know what LS is.<br />
<br />
'''Mazi:''' I vote for "limer" ;-)<br />
<br />
'''holch:''' I would stick with "user" vs. "participant"<br />
<br />
'''Mazi:''' fie with me<br />
<br />
'''Mazi:''' *fine<br />
<br />
'''El-Matador-691 has disconnected:''' Read error:''' 110 (Connection timed out)<br />
<br />
'''dhardisty:''' I agree<br />
<br />
'''holch:''' As we will put the admin in a different navigation, we should not run into trouble.<br />
<br />
'''Mazi:''' looks promising<br />
<br />
'''Mazi:''' any other topic for today?<br />
<br />
'''holch:''' User can be and admin, a normal user (can only do certain things) or a "client" who can only see results.<br />
<br />
'''holch:''' But this would be something for the rights management.<br />
<br />
'''Mazi:''' yeah<br />
<br />
'''Mazi:''' dqminh, what time is it at your location?<br />
<br />
'''dhardisty:''' so you are suggesting two separate admins? survey admin and user admin?<br />
<br />
'''holch:''' No, I don't think so.<br />
<br />
'''holch:''' Should be 10:10.<br />
<br />
'''Mazi:''' am/pm?<br />
<br />
'''dqminh:''' Mazi, 10:10 pm<br />
<br />
'''holch:''' Here it is 11:10.<br />
<br />
'''holch:''' 10:10 am...<br />
<br />
'''Mazi:''' we can think about starting the next UI meeting an hour later<br />
<br />
'''holch:''' Ahhhh, I thought you were talking about dhardisty.<br />
<br />
'''Mazi:''' should be fine for most people?!<br />
<br />
'''holch:''' For me this would be OK.<br />
<br />
'''dhardisty:''' it is 10:11am here<br />
<br />
'''dhardisty:''' soon I will be in Seattle for 3 weeks<br />
<br />
'''dhardisty:''' 3 hours earlier there<br />
<br />
'''holch:''' I think dhardisty would be more than happy about 1 more hour.<br />
<br />
'''dqminh:''' fine for me ;)<br />
<br />
'''dhardisty:''' but next week I will be at a bachelor party<br />
<br />
'''holch:''' OK.<br />
<br />
'''dhardisty:''' so I think I will have to miss next week, sorry<br />
<br />
'''dhardisty:''' I'll be in a hotel<br />
<br />
'''Mazi:''' 10 am is quite early for lazy PH.D. students<br />
<br />
'''dhardisty:''' probably with a big hangover from the previous night<br />
<br />
'''holch:''' That is fine. We all have our lifes...<br />
<br />
'''dhardisty:''' plus the normal noon time is 5am there<br />
<br />
'''dhardisty:''' haha, yes<br />
<br />
'''dhardisty:''' I do my best work at night, so I normally stay up quite late. Also, by the way, my friend Jon will be at the UI meetings sometimes<br />
<br />
'''dhardisty:''' we plan to "tag team"<br />
<br />
'''dhardisty:''' so he will come to the next meeting instead of me<br />
<br />
'''Mazi:''' sound cool.<br />
<br />
'''holch:''' dhardisty, I will try to send you a document during this week, so you can give your feedback and it can be discussed next time.<br />
<br />
'''dhardisty:''' ok, great<br />
<br />
'''Mazi:''' I will send an email to the mailing list and update the wiki<br />
<br />
'''Mazi:''' ..about the new schedule<br />
<br />
'''Mazi:''' holch, I will also tell macduy to create a new wiki page for todays wiki where you can upload files<br />
<br />
'''holch:''' Mazi, if I can make it and have dhardistys feedback, I will contact you to send the document around, so we can discuss it next saturday, OK?<br />
<br />
'''holch:''' OK, uploading is even better.<br />
<br />
'''Mazi:''' holch, uploading and email to the mailing list is best<br />
<br />
'''holch:''' Can I save this chat somehow?<br />
<br />
'''Mazi:''' I will add the logs to the wiki as soon as the page is set up and I can also email it to you<br />
<br />
'''dhardisty:''' copy and paste ;)<br />
<br />
'''holch:''' Na, I am able to copy and paste... hhehhehehe<br />
<br />
'''holch:''' OK, does this mean we are through?<br />
<br />
'''Mazi:''' fine. any other tasks to be allocated?</div>Macduyhttps://www.limesurvey.org/manual/index.php?title=GSOC09_dashboard_project&diff=1434GSOC09 dashboard project2009-05-25T11:50:13Z<p>Macduy: </p>
<hr />
<div><br />
__TOC__<br />
<br />
<div class="simplebox"><center>img/wiki_up/ls2_dashboard_ui.jpg </center><br />
<br />
Aim of the project is to create a widget-based customisable dashboard for LimeSurvey2 administrators, allowing them to get an overview of any information inside LimeSurvey2. The widgets, from which the dashboard is constructed from, will be customizable, interactive, reusable and have a consistent design.<br />
<br />
</div><br />
<br />
-=Widgets for Limesurvey 2!=-<br />
<br />
{cookie}<br />
<br />
= Implementation Ideas=<br />
<br />
== Paradigms==<br />
<br />
The widget UI will be based on the following paradigms:<br />
*Display information concisely and cleanly<br />
*Dynamic content - allow sorting of tables, display extra information in mouse tooltips etc.<br />
*Multi-content capable, i.e. be able to switch between related content within one widget, using AJAX (see below)<br />
*Minimal "chrome": each widget has a title, control box, a first-level navigation, second-level navigation and optionally a third-level *navigation, giving the user a powerful ways to navigate information without too much interface clutter (see mockup).<br />
*remember which information it has been displaying last time<br />
*work uniformly in major browsers (IE6+, FF2+, Safari 3+, Chrome, Opera 9+)<br />
<br />
== Implementation notes==<br />
<br />
Some ideas and notes about the implementation:<br />
*In the MVC pattern, the Widget will be a Model, with a View implementation that display different modes of the widgets (not different views!), i.e. most likely the settings mode and the display mode. This basic view will also draw the chrome. Each widget will thus be built using this Base View.<br />
*Each specific widget then subclasses the base Widget model, specifying the navigation links and other widget-specific options<br />
*Each of these links then displays content that corresponds to a LimeSurvey View, e.g. "display all surveys" View etc. Access is automatically controlled by the ACL. By clicking these links, the widget will request them using AJAX.<br />
*Content, that will be displayed by the widget might need certain pre-processing, hence WidgetAdapters will be created to "mash" retrieved information from a View into widget-friendly format. (Alternatively, each Model could provide certain Views specially designed for display in widgets)<br />
*The widget provides interface to interact with information, e.g. filter them or display extra information on demand. WidgetAdapters here will act the other way, converting these actions into URL requests and processing the result.<br />
<br />
=NAU Diagram (Not A UML Diagram)=<br />
<br />
[[File:Dashboard.png]]<br />
<br />
=Implementation Description=<br />
<br />
'''''Note:''' Despite the diagram above, implementation details are likely to change during the development stage.''<br />
<br />
==Widget Base Class==<br />
<br />
Widget base class is the Model-View-Controller trio, that implements the widget behaviour and data storage. Two tables will be created: '''Widgets''' for keeping track of individual widgets existing inside the system and '''WidgetTypes''' the different widget types available in the system.<br />
<br />
==Dashboard Class==<br />
<br />
Dashboard acts as a container for the widgets, retrieving and managing them.<br />
<br />
=Action Plan=<br />
<br />
== Outline==<br />
<br />
Main deliverables:<br />
*Context-free dashboard (do not depend on the current page - admin's dashboard)<br />
*Context-sensitive dashboard (widget display depends on the current view)<br />
*Implement widgets for administration and survey management<br />
*Integration with other modules (e.g. statistics)<br />
*External dashboard, for placing widgets outside LimeSurvey<br />
<br />
== Milestones==<br />
<br />
More detailed plan for coding. More coding will be done during in the second half of GSOC, due to study constraints in the first half.<br />
<br />
{|<br />
|'''Date''' (approx) || '''Milestone'''<br />
|-<br />
|31th May||Complete a basic skeleton framework loading dashboards and widgets<br />
|-<br />
|7th June||Implement few basic widgets, as replacement for the current Admin page<br />
|-<br />
|14th June||Context-sensitive dashboard<br />
|-<br />
|21th June||Skinning, cross-browser<br />
|-<br />
|28th June||**EXAMS**<br />
|-<br />
|5th July||Implementing widgets, wrap up scripts and code for presentation<br />
|-<br />
|<br />
|}<br />
<br />
{|<br />
|'''Date''' (approx) || '''Milestone'''<br />
|-<br />
|12th July||Implementing widgets<br />
|-<br />
|19th July||Widget 'back-side': widget and dashboard options, customization; External Dashboard<br />
|-<br />
|26th July||Develop External dashboards and widgets<br />
|-<br />
|2th August||Integration with other modules (Statistics)<br />
|-<br />
|9th August||Integration/doing the odd bits :)<br />
|-<br />
|16th August|| Wrap up<br />
|-<br />
|<br />
|}<br />
<br />
Testing and documentation will be done throughout the development.<br />
<br />
==Development Log==<br />
<br />
News and updates on development of this feature are recorded on [[GSOC Dashboard Project Development Log]]. Production timeline is logged on [https://www.ohloh.net/accounts/macduy/messages/timeline ohloh]<br />
<br />
=Links=<br />
*[http://socghop.appspot.com/student_proposal/show/google/gsoc2009/macduy/t123850575163 Original proposal]<br />
*[http://micron.me.uk/test/ls2_widgets/index.html First (Basic) Prototype]</div>Macduy