Survey Builder is a little different from typical APEX apps (if there even is such a thing as a typical APEX app). Here I want to describe a couple of requirements that shaped its design and the resulting APEX implementation. A great thing about APEX is that it comes with a number of fully functional packaged applications such as Survey Builder that you can use as-is, tweak to do what you want or just open up to see how it works. So feel free to install Survey Builder, unlock it, and follow along.
Creating and editing the questionnaire needs to be as effortless as possible. The questionnaire is made up of sections, sections have questions, and most questions have multiple choice answers. There are separate tables for each of those entities. A naive implementation would have a report page listing sections clicking a section would lead to a section details page and each section details page would have a report listing questions and so on. Editing the questionnaire would require a lot of navigation between pages and it would be hard to visualize the questionnaire as a whole. Master detail style pages would help but still wouldnâ€™t let you see the whole questionnaire at once. I wanted to use a document outline metaphor and have all editing done on a single page to eliminate navigating between pages. Details for sections, questions and answers are added/edited using dialogs. Reordering is done directly on the outline with drag and drop. The outline can be expanded or collapsed to see everything or focus in on just the area of interest.
APEX doesnâ€™t have an out-of-the-box UI control like that. I wouldnâ€™t expect any widget framework to have exactly what I was looking for. A tree comes close but I wanted full control over the rendering and behavior including full keyboard accessibility. Since the questionnaire is core functionality for any survey app, to me this is a case where it is worth the extra effort to create a custom UI control.
Filling out Questionnaires
Itâ€™s important to be respectful of peopleâ€™s time when they are taking your survey. For the survey author this means keeping the length of the questionnaire reasonable. For the survey software this means questionnaires must load quickly, be pleasant to look at, be usable and accessible, work with different devices and screen sizes, and save the response quickly.
The questionnaire is essentially a very simple web application. Itâ€™s just a web form with a few kinds of form fields. Survey Builder is responsible for creating any number of these simple questionnaire web applications.
At the intersection of simple constrained UI and fast load times I saw an ideal use case for a thin server web app. A thin server web app is one where all the markup is static (as opposed to generated for each request), data is inserted into the UI on the client side, and the interchange of data between client and server uses XMLHttpRequest (ajax).
If you look at any questionnaire page you will notice that it uses a normal APEX URL. All questionnaires are page Q, which is an alias for public page 100. The request field of the APEX URL identifies which questionnaire to return. The single parameter, code, is a unique code for each respondent in a random-sample survey. The URL is where any similarity with normal APEX pages ends. If you look at the page source you will notice that it is not a normal APEX page at all. The best indication is that the form action is not “wwv_flow.accept” and the standard hidden inputs such as pFlowId are not present.
When the questionnaire Submit button is pressed the answers are validated on the client side and if there are no errors an ajax request is sent to an AJAX callback page process on page 100. That process must also validate the answers. If all validations pass the answers are stored.
Each application is different. Some will require custom UI. Probably few will need to generate static pages. Even if the designs described above donâ€™t apply to your application I hope one take-away is that APEX is a very flexible and capable framework.