Tag Archives: Surveys

SharePoint 2010-Change Survey Option “Specify your own value:” to “Other:”

Recently I had a request from a business unit to change the Out of Box wording on a survey that employees were taking from the SharePoint standard of “Specify your own value:” to “Other:” which seemed fairly routine and something that could be done easily with a few lines of JavaScript, a quick Google search turned up some interesting an unique ways of doing this including:

  1. Changing the default.master page to include JavaScript and adding a function call in the body tag
    1. This of course would add a bit of overhead for every single page that uses the master page!
  2. Editing the ows.js file and editing the string
    1. Which works fine until the next update or patch and the ows.js file is overwritten, also never ever modify out of box .js!
  3. Using JQuery to find the exact field attribute (by name) and changing the text
    1. Really?  I need JQuery to do something simple like this?

I saw a couple other methods of achieving these results, all of them very bad, most of which made me cringe because it either went against my core belief that you never modify out of box code, you never add global functionality for specific items, or it goes against the lazy bone that believes everything should just be a simple cut and paste function without customization, if I can’t drop the functionality in as a web part then damn it I should be able to!  So I looked for a better way, surprisingly nobody seemed to hit upon this method, which utilizes our handy and ever trusty Content Editor Web Part…

  1. Open the site in SharePoint Designer 2010
  2. Go to the Lists and Libraries, and select the Survey you want to edit from the content window:
  3. Click on the “NewForm.aspx” file in your main content window:
  4. Now add a Content Editor Web Part right below the standard ListFormWebPart, like so…

Now, as for the content, it gets a bit tricky, you’ll want to go down to where the <Content> tag is for your Content Editor Web Part and add the following code between the brackets in the CDATA[]

<script type="text/javascript">
     var labels = document.getElementsByTagName("label");
     for(var i = 0; i <; labels.length; i++)
            if(labels[i].innerText == "Specify your own value:")
                 labels[i].innerText = "Other:";

EDIT: As you may see from the comments, I forgot about FireFox, so for those of you who like cut and paste, use the script below instead in order to work with FireFox as well by replacing the “innerText” with “innerHTML”

<script type="text/javascript">
     var labels = document.getElementsByTagName("label");
     for(var i = 0; i <; labels.length; i++)
            if(labels[i].innerHTML == "Specify your own value:")
                 labels[i].innerHTML = "Other:";


It should look like the following on your screen:


  1. Ok, save the NewForm.aspx page and you’re done.  Now when a user goes to take the survey, the ugly “Specify your own value:” is replaced with a nice friendly “Other:”


  2. Even better, because we used SharePoint web parts to achieve this, we only experience overhead on this specific page, we didn’t have to edit out of box code, and because we stayed within the normal confines of editing the NewForm.aspx it means our file doesn’t get UnGhosted!  Winner! 


SharePoint 2010–Allowing Anonymous Users to Answer Surveys

Recently I was asked to create an anonymous survey in SharePoint.  In many ways these are fairly annoying because SharePoint really wants to know who you are when you’re on the site, so you have to be careful about what features you utilize in your anonymous sites.  However, I think I’ve found a pretty straight forward way of addressing the issue as long as the company is comfortable with creating a separate web application that only allows anonymous access and doesn’t try to authenticate.  This site should only be used to house items that they want to have as anonymous access, so I tend to “portal” the functionality from the anonymous web app inside something like an intranet if needed.

First step is to create an anonymous web application for anonymous surveys.  There are several reasons for wanting to use this approach:

  • You have an external facing site where users don’t log in.
  • You have an internal web site and you want to be absolutely certain that user responses to a survey are 100% confidential and anonymous.
  • You want to use only the out-of-box capabilities of the SharePoint survey module.

However, realize that being anonymous does come with some drawbacks:

Multiple page surveys don’t work on an anonymous site

So what exactly does this mean? Well typically longer surveys will contain multiple pages and / or branching logic. In SharePoint when you respond to a survey that has multiple pages, SharePoint automatically saves the state of the survey when you move from one page to the next. It does this so that in case you lose connectivity while completing a long survey, you’ll be able to continue where you left off. It doesn’t really matter whether there might be better ways to implement this; the fact is that SharePoint writes the work-in-progress survey to the survey list when you move to another page in the survey. The problem is that SharePoint cannot write the incomplete survey to the list unless it can associate that survey with a particular user. If the user cannot log in at the point when they move to the next page, they won’t be able to continue with the survey.

Anonymous users can’t save progress

If the user is not logged in (i.e. anonymous) SharePoint will automatically request the user credentials. If the user is using IE (Internet Explorer) and the web site is in the Intranet zone, IE will by default automatically send through the user’s domain credentials and the user will be logged in (defeating the purpose of being anonymous). Alternatively the user will be prompted for credentials and if they don’t enter these credentials, they will be presented with an unauthorized dialog box:


If the user does log in, they will then move from the NewForm.aspx page to the EditForm.aspx page with the survey id as one of the query string parameters (e.g. …/EditForm.aspx?ID6&…). Since the survey is now in edit mode as opposed to new item mode, it stands to reason SharePoint needs to have the user context in order to retrieve that specific survey and to ensure the user can’t retrieve anyone else’s. The Create responses and edit responses that were created by the user setting on the Advanced Settings page of the survey has no mean unless the user is logged in:


If you want to edit the partially complete survey at this point, you simply have to be logged in.

Intranet sites are typically not anonymous

Another caveat is that Intranet sites are almost always not anonymous. To get around this you could set up a separate web site specifically for surveys where users could connect anonymously. This would entail something along these lines:

Create a new web application that supports Windows Authenticated users for survey administrators (e.g. http://survey.admin). This would normally be created in the Default zone. Create a top level site collection and grant specific permissions to the Survey Administrators so they are able to create new surveys on this site. You could further grant other permissions as necessary to any other users that may need to view survey responses or perform other actions on the site.

Extend the web application to another zone / IIS web site (e.g. to the Intranet zone on the http://survey site). Grant access to anonymous users for this zone, and remove access for Windows Authenticated users.


This will prevent users from being able to log into the http://survey web site using their Windows credentials, but survey administrators will still be able to log into the http://survey.admin web site to manage content as this is in a different zone.

Of course you still won’t be able to have multiple page surveys, but users will never be able to log into this site (http://survey) either accidently or automatically.

This method is the same approach you would typically take on an Internet facing site.

Once you have created the anonymous only web application, the next step is to create a survey like you normally would, remembering that features like branching logic will not work.

You could further enhance the user experience to create the perception of having multiple pages by incorporating some clever JavaScript / jQuery and css to show and hide sections on the survey as a user progresses through it. This would likely mean editing the NewForm.aspx page in SharePoint Designer for the specific survey you wanted to do this on. You’d then have to repeat the process for future surveys you wanted this functionality on.

After the survey has been created, you’re still not completely done.  You have to apply a little anonymous permissions magic in order to allow for anonymous users to actually contribute to the survey and fill it out…

Set advanced settings

On this screen, we set ‘Read Access’ to ‘All Responses’, ‘Edit Access’ to ‘Only their own’ and ‘Allow items from this survey to appear in search results’ to ‘No’. Setting read access to ‘All Responses’ seems a bit weird. After all, you will normally not want your anonymous users to see the responses of all other users. We will change this back later, but for some reason, it is necessary to select this option here.

Set Permissions

Next we go to the permissions screen:

The survey by default inherits the permissions from the site, but for anonymous surveys this will not do. By selecting ‘Edit Permissions’ from the ‘Actions’ menu, you can specify specific permissions for this survey.

The Setting menu has now appeared and from it, we choose ‘Anonymous Access’.

In this screen, make sure that the check boxes for ‘Add’ and ‘View’ are selected.

Set advanced settings again

If this is alright, we can go back to the ‘Advanced settings’ screen to set Read Access back to ‘Only their own’.

There, you’re set. The survey can be filled out by all anonymous users, but they cannot see each others entries. The information entered in these forms will be stored in the survey’s library and you can inspect each entry or view aggregated graphs of all entries. So what happened here? We first set the ‘Read Access’ to ‘All Responses’, because only then can we set the Anonymous Access settings (all check boxes will be greyed out otherwise). But after setting the permissions, we can safely turn access to all responses off again. This procedure is a bit odd, but it works.