A while back, one of my clients I was consulting with asked me about what sorts of the benefits by using SharePoint Survey over the 'Survey Monkey', which seems quite typical question the end-user will normally ask, before fully leveraging all those SharePoint 2010 related components.
Therefore, I prepare the following answers for his team:
- the SharePoint OOTB(Out-of-box) Survey component is not as rich as Survey Monkey. Survey Monkey was built specifically to do surveys and the success of the company depended on it. Hence they do all they can do do what is needed. In SharePoint, it is a great application for sophisticated questionnaires with lots of features; but it only does what it does. I suspect it there only to demonstrate the possibilities for developers.
- Users cannot go back a page if they want to change an answer to a question. They get stuck in a do-loop of errors that will not allow them to save. They'll have to go back and start over.
- If a user wants to change a response, they have to click through all of the pages and pages of responses they have already submitted to find the one that they want to change and then click through all the pages to get to the end to submit it.
- The Next | Save | Cancel button choices give the user the impression that if they click 'Save' they are done. You're not done until you click 'Finish' at the end.
- SharePoint Survey has no question or page numbering feature. Nor does it have a progress bar, or the capability to change the button labels as you can in Survey Monkey.
- Survey Monkey also gives you some additional question formats such as matrices. The only thing that comes close in SharePoint Survey is the rating scale.
- SharePoint Survey has the limitation over the exporting survey responses, but on the flip side, SharePoint survey can be fairly easy to integrate into the Business Chart web-part to populate the meaningful Business Intelligence dashboards.
As a result for that, he still chose the SharePoint survey components over the "Survey Monkey" simply because he loves the fact that he still can manipulate the survey data into the list-format or dashboard-style graph and charts.
Just ran into an interesting unconventional occasion for the current client I'm consulting with. For some company network policy reason, we are not allowed to do any development on the staging environment, not to mention, they don't even have a in-house development environment for us to deploy the WSP package to it directly by Visual Studio 2010.
It's not a huge deal of it, but the time-consuming bit is that we couldn't leverage the VS2010 integration development benefit to deploy the WSP or any feature to SharePoint 2010 farm/web/site/website through the integration environment. Instead, we have to go back to MOSS2007 old way to remote debug the development module from the local to the server.
Well, the following steps and hoops listed below is the approach I set up in order to get my environment ready to roll: (P.S. my local development environment is 32bit Windows XP operation System)
- Build a SharePoint2010 environment virtual machine (you know the drill otherwise you won't be here in the first place).
- Install VS2010 on the local machine (32bit), ideally, get the SharePoint 2010 SDK installed as well, which benefits you later on for sure.
- Export the hive [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0] from the virtual machine and install on the local machine.
- Copy all the files under (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\UserCode) from SharePoint 2010 to Visual Studio 2010
- Create an empty SharePoint 2010 project and reference 2 dlls back into the SharePoint solution file (Microsoft.SharePoint, Microsoft.SharePoint.Security) if this Visual Studio 2010 machine doesn't have SharePoint environment setup.
- Modify the project property (Build tab -> Platform target: x64), then fully ignore the build warnings (something like, it has switched to the different platform) It only displays this error if the local Visual Studio 2010 machine doesn't have 64bit enviornment, which is exactly what's happening on my-end.
- Run the command:
add-spsolution -LiteralPath "c:\solution\PackageFileName.wsp" add-spsolution -LiteralPath "c:\solution\ListPortalUsers.wsp"
install -spsolution -Identity "PackageFileName.wsp" -GACDeployment -WebApplication "http://RemoteSPInstallName"
To deactivate a Feature, run the following Windows PowerShell command using SharePoint Management Shell: a. retract solution
Uninstall-SPSolution -Identity -WebApplication
b. remove solution from farm
- Turn on the development dashboard to display the debugging traces. Using stsadm, you can run the following command to configure the Developer Dashboard:
STSADM –o setproperty –pn developer-dashboard –pv OnDemand
- SPMonitoredScope doesn't seem working on the remote Visual Studio stations (bomber!), but the rest seems all being up-running as intended.
As mentioned earlier, it's not the ideal development environment for SharePoint 2010 custom build, by which inevitably you lose a lot of built-in functionality you could simply pull off from VS2010 SharePoint project, not to mention, that time-consuming. However, if that's the client's corporate policy, I guess, that's the best solution I could come up with so far.