Tics (aka tic marks) should be visible under the slider bar.

See this sketch: http://img38.imageshack.us/img38/5295/10403feb10095848.gif

benefits: easy read, make it clear it's a slider with discrete values, catch where the handle is in respect to left and right limits.

Details:
type = multiple numerical input
options:
use slider layout = 1
slider min = 0
slider max = 10
slider accurancy = 1

It's more productive to show and review all conditions in a admin page.
Mantain them from there (Edit, add, delete) is considered a plus.

All possible transitions (of pages, of state) a survey can undergo by user interaction are:
- start
- resume a survey
- save the survey
- cancel and exit
- go prev
- go next
- end

The state of the art is a non-homogeneous implementation:
- Exit and clear = < a> tag with a fixed url carrying a crucial get parameter
- Load unfinished = < input> tag with type="submit" and crucial value "Load unfinished survey"
- Save = < input> tag with type="submit" and crucial value "saveall"
- < < prev = < input> tag with type="Submit" and crucial value "< < Prev"
- next>> = < input> tag with type="Submit" and crucial value "Next>>"
- start = < input> tag with type "Submit" and crucial value "movenext"
- end = < input> tag with type "submit". Value unknown at the time of writing this.

These should be harmonized: use the same tag and discriminate over one (single) parameter.

A new use case:
the client wants to validate and approve all questions textes before giving GO/NOGO to the launch. This includes also: question help text.

Rationale:
This is a likely checkpoint in a project. Since the questions are to be delivered to users, the client requests a final REVIEW/APPROVE to validate the textes before the launch.

The same applyes to groups. This time, the to-be-approved textes are: group title, group description.

Being able to edit the textes on-the-fly is considered a plus.

template.js is the natural place of all user javascripts

BASIC TEMPLATE has the peculiarity of not using template.js because it lacks the proper inclusion of it.

In the Template Editor, template.js is always shown, even if it's not called inside *pstpl. When editing BASIC template, you can edit template.js, bit it will not be loaded at runtime.

I suggest to make it crystal clear that this is the default behavior.
If not, the user may waste time in debug & design, until he notices that his javascripts are not there and fix the basic template.
Also, COPYING BASIC for your own work will result in inactivated template.js, so the issue reinforces itself in the copies/clones

Survey settings is composed of 2 pages:
1 Survey configs, with tuples (name-value) .e.g. Allow Saves Y/N
2 Survey textes, with survey title, welcome, endmsg.

The first part of settings are set at start of your work with a survey, and rarely fixed later.
The behaviour of a survey is technical choice, with a tendency of no change over time.

The second part is very frequently used, I believe it stays at the same level of questions and aswer, often modified for the same aesthetic or pratic reasons.

When chosing a question from the dropdown list at the admin panel you get some information about
- code
- question text
- quesdtion type
- label set
- mandatory?

What's missing is information about assigned question attributes. You always have to switch to the "edit question" screen to get information about assigned question attributes.

This is not very user friendly and a design problem which probably could be fixed easily.