Saba surveys in a portlet

Saba provides several portlets with the out of the box installation of the Learning Management System, but one missing and topping the list of requests from the customer community is a portlet for displaying surveys. If you have ever published a survey, you know how little accessible surveys are to end users: click on My Learning tab, then Evaluations & Surveys menu and again on Surveys, then eventually you see a list of your surveys. Not great, if what you need is to draw the attention of your student to a public survey. What's better page than the student's dashboard page then!

In my previous article, I've already addressed a specific case of integrating a third party survey tool in a portlet for publishing quick and anonymous surveys. In this article I'll present an easy technique for publishing the Saba built-in surveys in a portlet and make them accessible to end users in just a click!

Overview of Surveys

Saba provides a framework for obtaining feedback from learners in the form of surveys. A survey is a questionnaire with one or more questions that is used to gather feedback from specified respondents. Surveys can be assigned to both internal people (i.e. employees) and external people (i.e. clients). Designated respondents can always choose to accept or decline a survey.

The stages and roles involved in creation and delivery of a survey are:

• Creation: People Administrators create a survey, attach a questionnaire, define the distribution list, and publish it. Survey is sent to participants in the distribution list for approval and assessment.
• Progression: Raters accept the survey request and complete the survey or decline the survey request. A participant can also choose to remain anonymous, but answer the survey.
• Completion: Saba automatically accumulates the assessment results and sends a survey closure notification to the owner after the expiry of the due date.

The Survey Management page displays a list of all surveys and their statuses. A survey can have the following statuses:

• Draft: A survey is created and is saved for later edits, not published.
• In Progress: A survey is published and sent to respondents.
• Completed: A survey is closed.

Once a survey is published, it is available in the My Learning > Evaluations & Surveys tab of the Home module to learners designated as respondents for the survey. The respondents can choose to accept or decline the survey, and, if the former, then eventually take and complete it by answering all questions in the survey.

The Survey Portlet

The purpose of the survey portlet is to list In Progress surveys to nominated users directly in their home dashboard. Draft and completed surveys won't be displayed. A portlet should be used for providing a shortcut to a more structured and complete area of the Saba system, and it should not be used as a replacement for an existing functionality. For this reason, I decided to create a very specific version of the portlet with some reduced functionality (as compared to the regular page from where users can access surveys), but with the added benefit of fitting within the limited space of a portlet and offering a one-click access to published surveys.

The starting point of any new portlet, as we learned in my previous article, is to create a Portlet Page Manager. This is a Java class that extends the AbstractPortletPageManager interface and implements the PortletPageManager abstract class. By doing this, we have all the wiring ready, and what is left to do is simply to override the init method and specify the Saba WDK page that is responsible for displaying the actual portlet on the screen.

public class SabaSurveyPortletPageManager
   extends AbstractPortletPageManager
   implements PortletPageManager
{
   @Override
   protected void init() throws SabaException
   {
      registerPage("showDefaultDisplay",
         "/custom/portlets/surveysForRater.rdf");
   }
}

The fully qualified name of the SabaSurveyPortletPageManager class will be used for the PageManagerClass parameter when creating a new portlet in Saba.

The name of the controller page is /custom/portlets/surveysForRater.rdf. This is not coincidental. The regular Saba page that is used for displaying surveys to end users is /common/survey/surveysForRater.rdf. All I have done has been to simply make a copy of that page into the /custom/portlets folder of the alternative source code and then modify it to fit the purpose of the survey portlet.

If you look at the standard Surveys page, you will notice that the page displays survey information that we can hide in our portlet, to save space and reduce the clutter on the screen.
Specifically, we do not need the Current and Completed tabs, as we are only displaying In Progress surveys. Also, in the survey list, we probably can get along without Description, Created On and Created By. We also do not want the user to modify, print or export the list of surveys, so we can get rid of these links on the top right corner of the survey table.

This is the original page with all the mentioned columns and links:

And this is the layout of the portlet that we want to obtain:

Let's go in order then and remove the tabs on top that allow to switch between Current and Completed surveys. When doing this kind of page "surgery", I typically look first at the view page (the page with the .xsl extension) and see where that control is displayed:
Within the surveysForRater.xsl page I can easily spot these lines of a table row:

<tr>
   <td colspan="2">
      <xsl:apply-templates select="$wdkWidget[@name='surveyStatusMultiSelect']"/>
   </td>
</tr>

That's your widget. Copy the surveyStatusMultiSelect name, we need it later, and delete all the above lines from your view page. Job done!

Now let's find this control in the model page (the page with the .xml extension) and remove it from there as well. Search for "surveyStatusMultiSelect" in the surveysForRater.xml page until you find this line:

<wdk:multisection name="surveyStatusMultiSelect">

That's your multi-section widget. Feel free to remove the entire tag, including its content. And again job done!

Now the columns. To get rid of extra columns in the survey table, we have to look for a the FinderResult widget identified by the <wdk:finderResult> tag, within the <wdk:widgets> section.

<wdk:widgets>
  <wdk:finderResult name="surveyResults">

This is the widget that displays the list of surveys assigned to a user in a table format. There is a special instruction that you can use for removing an existing column, which is applied to the widget by entering as many <removeDisplayColumn> tags as needed. To remove the Description column, for example, just add the following XML tag to any place within the FinderResult widget (I typically add these instructions after the list of columns to display and before the definition of the sorting order, but the actual position is not really relevant).

<removeDisplayColumn>
  <name>description</name>
</removeDisplayColumn>

Repeat the same instruction also for the Created On and Created By columns and, congratulations, job done!

Lastly, we want to remove the links to print, export and modify the table. There are specific instructions for that, as documented in the Saba Application Developer's Guide, that you can apply by specifying the following simple tags:

<print>false</print>

<export>false</export>

<modifyTable>false</modifyTable>

Once again, job done, all changes have been applied to the model page.

The final touch

Are we done then? Well, yes and no. Publish these pages and launch a survey. You will see a pop-up like this one opening, containing all sections and questions of the survey.

When you submit (or exit) this pop-up, Saba refreshes the launching page (i.e. the page from where you clicked on the Launch link) to reflect any changes introduced by completing the survey (very likely, if you complete the survey, its status moves to Completed and therefore it disappears from the list of In Progress surveys in the portlet). If you launch the survey from within the portlet and then close the survey pop-up window, however, the launching page reloads but a wrong page is displayed. Actually, it's not a wrong page but it is the standard survey page that you typically find in My Learning > Evaluations & Surveys > Surveys. So what's happening is that the pop-up window doesn't know whether the survey has been launched from the standard page or from the portlet. Reason for that is that... ehm... unfortunately, the address of the launching page has been hard-coded in the view page (bad bad practice Saba, come on!) so we have to modify it to make it work for the portlet and have the dashboard page reloaded (and hence our survey portlet with it) rather than the standard survey page.

Look for this JavaScript code in the view page, that performs the refresh of the launching page:

function submitForm()
{
wdkFrameworkSubmit("/common/survey/surveysForRater.rdf");
}

As you can see, the full name of the /common/survey/surveysForRater.rdf page is specified, which, as we know, is the standard page for displaying surveys to users.
We want to replace it with our portlet page, but we cannot just specify the full name of the /custom/portlets/surveysForRater.rdf page here, otherwise we would reload only the portlet page outside of the dashboard portal. We do need to specify the portal page that, once refreshed, will reload all portlets in turn.

function submitForm()
{
  wdkFrameworkSubmit("/platform/presentation/portal/portalDriver.rdf");
}

That works, but yes, it still stinks of hard-coded page name in a view page, which is against the MVC principles (page navigation should only be responsibility of the controller page, and never of the view). A more elegant way to resolve this problem is to introduce a link reference in the controller page and have the view point to that reference rather than the full survey page name. But this is another story...