The UI layout of the app is the next step. I was referred to JustInMind recently and found it to be very helpful in designing the UI. The first step was to determine all of the screens/pop up questions/UI elements for the app - not the look and feel, but what questions to be asked and what are the possible actions and results. If you have a team, using the pro service makes a lot of sense, but the free lifetime version is extremely useful.
I separate the Look and Feel, as what JustInMind has for UI elements verses AppStuido do not exactly match up. And there doesn’t appear to be a way to “transfer” your work between them. So no real sense in spending any time with Look and Feel in JustInMind.
Once I had the UI concept going, I automatically start thinking about how it’s going to be implemented. I have one additional assumption. The App will all have the same basic screen layout - header, menu, footer, and an area to present questions (including the login).
So this question comes down to:
Is it best to make one form object and modify the contents of the presentation area in the form object with each new question formatted as needed based on question type.
OR
Should there be a form for each type of question format, and then only the contents of the question itself would change and the program would change forms as needed based on the question format.
Another way to think of this question is: When would you use multiple forms in an app?
I think if I were doing it, I would store all the questions on the server (so they can be changed and/or translated), I’d then get the language from the device and query appropriate questions from the server and stick all those questions into an array of objects.
var Questions = [];
var q1 = {qNum: 1, qType: "true-false", question: "Do you really wanna?", ans: {1: "Yes", 2: "No"};
Questions[] = q1;
From there, I’d manage the display and answering of the questions like a wizard. After each answered question, you record the answer, erase the content of the div, build the html for the next question and insert that into the div.
By maintaining head/tail pointers (head is first question, tail is last) you can allow users to navigate backwards (i.e. go back 3 questions) to change an answer and then go forward skipping or changing already answered questions.
Something like this:
// JavaScript Document
var currentQues = 1;
var totalQues = 10;
function onQuestionsPageReady()
{
$('.Ques div').on("swipeleft", function () {
$(this).removeClass("active");
$(this).addClass("inactive");
// see if we wrap or are at the end
if(currentQues == totalQues )
currentQues = 1; // wrap to first Ques
else
currentQues++; // go to next Ques
$("#Ques" +currentQues).removeClass("inactive");
$("#Ques" +currentQues).addClass("active");
});
$('.Ques div').on("swiperight", function () {
$(this).removeClass("active");
$(this).addClass("inactive");
// see if we wrap (backwards)
if(currentQues == 1 )
currentQues = totalQues; // wrap to last Ques
else
currentQues--; // go to previous Ques
$("#Ques" +currentQues).removeClass("inactive");
$("#Ques" +currentQues).addClass("active");
});
// send it to the server
$('#endQuestion').on("click", function () {
// send answers to the server
});
}
Phil, thanks. Yes, the question sets were going to be downloaded from the server.
To put your answer into AppStudio terms: you are suggesting using a single Form Object and just change out the Presentation Area of the Form Object. This approach, after I wrote this question, did seem to be the best alternative. With a consistent screen layout, why redraw anything other than the section that changed.
I’d agree - based in the information here, I’d go with a single form as well. (You might want other forms for settings, help, and other stuff not directly involving questions).
The concept of a single form and “repaint” the guts of the form (the question/answer portion in this case) at run time sounds good up front. However, this doesn’t really help those who are using AppStudio for it’s UI IDE - it’s nice to see what the UI Elements are going to look like in the IDE - development and styling go much quicker.
I have 12 different layouts planned in my case. So there’s no way to hide and unhide all of the possibilities on one form and see what is going on in the IDE. But I still want one master form, so I only have to define the header and other page elements once, not to mention repainting an entire form that is basically the same is time consuming at a minimum.
My idea is define 12 additional forms in AppStudio, one for each layout. But these forms will never be displayed. Instead they will be templates for each of the layouts to be embedded into the master form. In the code, instead of changing forms, we will copy the HTML from the appropriate template for the question layout and insert it into the master form.