Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

design application with singe page  RSS feed

Sandeep Malhotra
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to design the save approach for an application which is basically question answer application (similar to online Visa application). This application has one particular page where we ask total between 30 to 40 questions from user. With screen design, we only ask one question at a time, and in the end, we show them a summary page of what they answered with Submit button.
Since there is no Save button during answering these questions, we would like to save data at different stages during answering questions in this page so that user data doesn’t lose all answers if they exit for any reason and come back.

There are two ways to design this,

First, I can save data (answer) after each question. However, this will increase database hits significantly. Also, user can change their answer which may need to clear down already answered questions. Therefore, this approach doesn’t look reasonable

Second, I can define different save point in this page. For instance, after answer question ‘x’, I will save data in to the database on backend. However, the problem with this approach is that the save point is tightly coupling with the specific question. If developer move or restructure this question in future, it will affect the save point.

I am using the JSF bean and therefore, all the questions are defined in the backing bean. I would like to know your thoughts what the best design for this kind of scenario is.
Tim Holloway
Posts: 18660
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is basically the "Wizard" approach to data entry, and it is something that JSF was specifically designed to make easier.

Essentially, when filling out an application form on the web, you have 2 extremes:

1. Put the whole application form on a single web page.

2. Put each data field on a separate web page.

There there's the compromise approach.

3. Group related data elements into topics and put each topic on a separate web page.

I usually favor #3. An entire application on a single page often is hard on the eyes, typically requires scrolling, and since it's all on one form, chances are higher that the entire set of data won't get saved and there will be no point to resume from.

Putting each item on its own page requires a lot of tedious and repetitious page designs, requires more server overhead, and slows down the user, since anything that submits data to the server introduces a fairly long wait for the data to validate and any applicable page navigation to be done.

The "Goldilocks" approach is a useful one. More data gets saved, it's easier on the user and it adds the possibility that when later data is entered in a topic screen that makes the user rethink and want to change other data in the topic, there's less need to bounce back and forth between pages.

So typically what I have would be a set of pages of topics, with sequential navigation between them. To that, I'd add direct navigation for the benefit of people re-entering the app who want to revise earlier data as well as the ability to jump directly to the point where their previous session left off. Often tabs or menus are provided to make it easier to jump between topics. Whenever leaving a topic, of course, you'd update the backend database.

And finally, I always like to provide a summary display page where the form is displayed in its entirety for review and possible printing. By using CSS, you can make such a page "printer friendly". Often there's an existing or conceptual paper form that the app mimics, so that's what this page would resemble.

To support all this, typically there'd be a master session-scope navigator backing bean shared between the various topic pages and it would contain the current page navigation context and the form data. When using an ORM such as Hibernate, JPA, or EJBs, this form would also anchor the database entity objects. Otherwise, if the form is simple enough, it might contain field values directly. Although you'd have a Session Scope master bean for managing the workflow, individual topic pages might also use "helper" backing beans, which would generally be in View Scope.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!