Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In my app, one of the main feature is to complete 'forms'. One form contains a lot of read-only information, described by the following mockup.

enter image description here

On this UI everything is read-only:

  • Titles
  • descriptions which are dynamic for each form
  • then a list of bullets of 'steps' of the specific form (maybe small icons would be displayed instead of circles)
  • prop#Xes are additional information/properties for each list item

Submitting (entering values) of a form is done via the submit button, which displays a new UI for input-entering.

Almost everything is dynamic, so I'd display everything (besides the header/tabs and the buttons at the bottom) in a vertical scrollview.

Sometimes 1-3 special forms would be displayed to the user, this is reflected by the #1 concept.

Most of the time one form will be displayed for the user, so in those case there would be no header:

enter image description here

but, in the future, sometimes the forms would be assigned to days of the week, still allowing the user to complete any of them on any day:

enter image description here

As mentioned above I want the user to easily navigate between the forms, allowing him to quickly overview them and select the ones they want to complete.

My problem:

There are quite some information which describes why the specific form has been given to the user. This is one of the selling points of the app that it provides this information, so the user understands what's happening behind the scenes. Of course without this info the form is still sensible and has value, but this part adds an extra value to the software. This information consist of the following type of data:

enter image description here

This information is form-dependent, so each form has been generated based on different reasons!

I'm thinking about how to 'merge' these things together (the form and the 'additional data' information).

If I put every information on the form, then it will be very long, nobody will scroll down, nobody will see the 'why did s/he got that form' part.

Then I thought of putting this info to ViewPager, but that's not good, because I want to use the ViewPaging/swipe-ing to navigate between the currently issued forms.

Then I thought that I have an extra tab-control inside the form with 3 pages (form, reasons, stuff-you-need), but

  1. I don't like it

  2. It's against all guidelines to have 2 tabcontrols on the same page

Any help and kind advice is really appreciated!

share|improve this question
    
None of your form examples contain actual form fields so it's harder to visualize. Am I right in thinking that anything in a circle such as (1), (2) would be an individual form field? Also, what does 'prop#1' etc. refer to - does that mean the read-only form field hints? –  JonW Aug 6 '13 at 9:39
    
Also, I've edited your title so that it is an actual question related to the question text itself. Hope I've summarised it correctly. The title should be the actual question itself with the full text being the detailed breakdown. –  JonW Aug 6 '13 at 9:40
    
Thanks JonW, I edited the post and question also. Form-inputs are for different screen, the post is about displaying form info/instruction. –  Csabi Aug 6 '13 at 9:47

2 Answers 2

My suggestion in the mockup below. I would change the tabs for a side swipe menu (also triggered by a menu button) to provide the navigation between forms. Completeness of a form submission could be color-coded, and currently filled-in form should be indicated somehow in this case.

Regarding a form itself, I would split it into three steps:

  1. Initial form screen (description/welcome, it can be even optional) after which user goes to the actual form.
  2. Actual form screen(s) with a possibility to swipe between questions - one question per screen.
  3. Final form screen, including a summary and a button leading to next form (plus a degraded link to review questions).

Let me know if you like it and if it solves your concerns. Here comes the image:

enter image description here

share|improve this answer
    
Dominik: It seems it was a very bad choice to use the term 'form' in my case. There are no questions in my case. In my case a form is a workout, and the items are the exercises the user has to perform, the readonly dynamic text are instructions and information regarding the workout, so there isn't really a progress inside a form. I love your solution it is freaking awesome for a real form-scenario, but I guess in my case it might not be the best solution :/ –  Csabi Aug 6 '13 at 12:24

I would put those two info screens in two corresponding accordion-like components (I mean those that expand when you click on them).

If I don't get it wrong, form lengths are dynamic and chances are they will need some scrolling anyway, so I would put those two accordion-like items at the top of the form, inside its same scrollable component (so that they can scroll away and leave the space to the form).

This solution would give more relevance to the two info contents than, say, two smaller buttons that open a corresponding dialog. I'd say this second solution would be more suited to information that is not dynamic and that the user wouldn't find any more useful after a short while.

share|improve this answer
    
The form's content is more important than the 'why-did-you-get-this-form', and stuff-required for form' parts, wouldn't that be confusing that I display less important information first (even if they are collapsed), and then the most important one (form with title 1+2 and list items etc)? –  Csabi Aug 6 '13 at 10:55
    
then how about putting them below the form? one would still have to scroll down to reach the submit/skip buttons, so they wouldn't go unnoticed anyway. –  bigstones Aug 6 '13 at 11:08
    
Yes, but then it's a questions whether not showing submit/skip buttons always (if they are in the bottom of the scrollable area, they are not shown always) is a good approach or not... –  Csabi Aug 6 '13 at 11:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.