Fullscreen Form Interface

An experimental fullscreen form concept where the idea is to allow distraction-free form filling with some fancy animations when moving between form fields.
FullscreenForm

From our monthly sponsor: Automate manual QA and catch visual bugs with Percy’s all-in-one visual testing and review platform.

Today we’d like to share a fullscreen form concept with you. The idea is to extend the minimal form concept and only show one question or form field at a time in fullscreen. The user can enter data in a distraction-free way and it allows to add some fancy animations for the fields. Once all the fields have been filled or moved through, we show a summary in the final step. Here the input data can still be reviewed and corrected. In this final step the form can also be submitted.

Please note that this is a highly experimental component and it was only tested with the latest browsers that support animations, 3D transforms and HTML5 form elements.

The form has a couple of elements: the form fields (each being shown individually), a dot navigation on the right side (this allows to go back to already filled questions), a number indicator that shows the current step in the form, a continue button that will move to the next field, some details inside of the form fields, like a info icon and a couple of custom inputs, like the fullscreen color picker from the Inspiration for Custom Select Elements post.

The following show the initial view of the form:

FullscreenForm01

Here’s an example of the info tooltip and a filled email field:
FullscreenForm02_infoexample

For smaller screens we have a different layout with adjusted elements:
FullscreenForm03_Mobile
Image credit: Flat iPhone by UIPixels.com

When all fields have been navigated through, we reach the final review step where the form can be corrected and submitted:
FullscreenForm04_Review

The main idea behind the implementation was to take each field (in our case a list item of an ordered list) and display one at a time. When navigating to the next or previous field, animation classes are applied to the exiting and coming fields which make the inner parts (i.e. the label and input) move up or down with delays.

The form script has a couple of options, mainly to show/hide the control elements and a callback for when the review state is reached:

// show progress bar
ctrlProgress : true,

// show navigation dots
ctrlNavDots : true,

// show [current field]/[total fields] status
ctrlNavPosition : true,

// reached the review and submit step
onReview : function() { return false; }

The data-attribute data-input-trigger used in a field (i.e. a list element in our custom form), will trigger the form to move to the next field if the respective input of that field has been entered, meaning, a value was selected.

We hope you enjoyed this experiment and find it inspiring!

Tagged with:

ML is a freelance web designer and developer with a passion for interaction design. She studied Cognitive Science and Computational Logic and has a weakness for the smell of freshly ground peppercorns.

http://www.codrops.com

Receive our bi-weekly Collective or official newsletter right in your inbox.

CSS Reference

Learn about all important CSS properties from the basics with our extensive and easy-to-read CSS Reference.

It doesn't matter if you are a beginner or intermediate, start learning CSS now.

Feedback 149

Comments are closed.
  1. The look and the feel are great . . . i know it’s experimental, but this is so good it deserves to be used as soon as possible. So i guess, a fallback for non-modern browsers in the meantime 🙂

  2. When I am using a radio button input, the radio buttons do not appear. Is that intentional?

    • Hi Ben,
      sorry, I should have added another class for the custom radio inputs that we are using. I fixed it and default radio inputs should show up now. Thanks a lot for your feedback,
      cheers, ML

  3. Any tips on how to easily make this form dynamic (depending on which checkboxes could be selected, etc)?

  4. You are obviously a very talented developer Mary, but stuff like this is never, ever something I would do in any real site (I know, I know, this is a “playground”). It’s essentially a bastardized slider with single inputs in each “slide”. I never have any context on the values I eventually will need to fill out, and I cannot navigate back until I enter values.

    The code is cool but not so much the idea itself.

    • Hi Chris,
      thanks for your comment, but you’ll need to explain yourself better because I’m not quite understanding what you mean with “not having a context”. In my opinion, this is a very interesting way of offering a user a distraction-free way of entering his data, obviously, in a previously given context. This is an idea for a component which would make part of a website (i.e. a registration, a check-out process, a survey, you name it, etc. ). You can navigate back if the field that you are currently filling is not obligatory and you can review your data in the final step. A form like this requires a lot of adaption to its purpose and context, of course, there are so many things to be considered. But I wouldn’t slash the entire idea like that, give it a chance…
      Thanks for your feedback, cheers, ML

    • By “context” I meant to say that I would want to see this in relation to an entire interface. Do you really see this removing global navigation, etc. that establish where someone is at in the application? From your example, I suppose that you do and that it’s “fullscreen.” So I’d like to know whether you do intend it to function that way. If so, I don’t think a form is a worthy reason to remove that much crucial interface content.

      I’m all for new paradigms, but when you place a form inside a slider (which that is at the end of the day what this is), I highly doubt using it lacks any serious cognitive friction. I can’t see until the very end what the full range of inputs I need to supply and can’t make decisions about how to use it. I for one couldn’t use pre-form filler tools like 1Password/LastPass with something like this, and for me that would turn me away instantly.

      A few other potential usability issues:

      1. No keyboard support as it stands right now (tabbing between fields easily). It’s very convoluted right now.
      2. The marker for required fields is very faint, and a lot of current thinking is to instead mark optional fields
      3. Instead of faint indicators on the right to progress, it needs descriptive labels, which is a problem with most sliders
      4. I think the decision to not allow someone to move back without filling out a required field is a mistake. The only time those errors should happen is on attempting to leave an input (with inline validation) or on submit.
      5. You instruct to “hit enter” to advance, but that doesn’t work in your color “slide.” (I continue to harp on it as a slider because that pattern has a lot of the problems I see in something like this as well)
      6. Also “hitting enter” in your textarea obviously enters spaces. So in general, the advice to “press enter” doesn’t hold consistently.
      7. Your review screen is essentially an entirely rebuilt form itself. So I end up building 2 forms.

      I don’t want to detract from the attempt and your obvious technical acumen. I just know how many developers can get excited about something like this but lack critical reflection on its actual use and implementation with potential usability issues.

    • Hi Chris,
      as for the “context”, I’m not providing that. As I mentioned before, this is a component (and it’s very experimental which you seem to neglect here and it’s very easy to really pick on various details, but it’s also easy to take the code and build upon it ;))… I still don’t get why you believe that this would take the user out of any context; I don’t think that users are that stupid. You don’t intend to display all application actions in your UI either, do you? Minimal design requires to carefully think about what you need to show and what you can leave out and you can’t tell me that viewing the entire form interface during all the time is crucial in every case.
      Any UI and UX designer will be able to tell you that not providing the view on the full range of inputs can actually be desired in many cases. If that’s beneficial for whatever your goal is in collecting data from the user is worth investigating and you can read the comments on the Minimal Form Interface for an interesting discussion on that.

      The term “slider” is really really misplaced here and using it just because things are moving around, is quite arbitrary and inadequate in my opinion.

      There are a million potential usability issues, even in classic forms; forms are one of the most complex user interface components that exists. That’s of course no reason to neglect these things so here are some points that I’d like to mention regarding your list:

      • Required fields marker: I’m not sure what that has to do with this specific form; this is a general issue with any form. As for the color, you can change it.
      • Descriptive labels are not always necessary, especially within a short form (remember, minimal…); but if you’d like to add labels to the navigation dots, that’s surely quite straightforward to implement.
      • After going through all kinds of possible scenarios with required fields and moving forwards and backwards, we’ve decided on not allowing to leave a required field empty once its reached. This avoids a lot of inconsistent cases like when the user deletes a required input of a previously filled one. In my opinion it’s not a mistake. What exactly is wrong with it, you haven’t mentioned.
      • The color picker is based on the classic select element. Once you select a color you have to unfocus it; that allows to hit enter and move on. Same holds for the textarea where it’s obviously necessary to allow to hit ENTER for a CR and not to move on.
      • It’s the same form! You should at least have a look at the code and markup before you say something plain wrong like that…

      I believe that it’s time to re-think the classical form input and move on to new “paradigms”, and the “fullscreen” form is definitely one of my favorite candidates for that.
      Cheers, ML

    • I was plain wrong on the 2 forms, I apologize.

      I do not want to detract from how impressed I am with your technical ability. I have been and will continue to be a long time subscriber.

    • Chris, you seam to have no imagination whatsoever. Glad you seemed to suck up to Mary in your last post here. She created something wonderful. What you do with it is entirely up to you. The key here is to at least start thinking outside the tradition box.

    • as is done for coming to my mail?
      // y como hago para que el formulario llegue a mi mail ?

    • Realy need this.
      done for coming to my ouwn mail?
      // y como hago para que este formulario llegue a mi correo… ?

  5. Very cool! I think the continue button would be better if placed underneath the the inputs… maybe the pagination dots too? I’m on a 27″ iMac though.

  6. I like this a lot- I kept trying to push the tab button when trying to get to the next field, since I do that so often in forms. Might be worth looking into as an optional functionality?

    • Thanks Tod,
      yes Typeform is really great and a lot of our prototype is based on a concept like that. I think it is also a great example of how forms like that can make filling a form more fun.
      Cheers, ML.

  7. I think the concept is great, but the lack of a natural keyboard flow leads people using this to do additional work for screen reader user. Trying VoiceOver on Mac, I was able to read the first question, but then tabbing takes me to the continue button and keeps me there. Upon hitting continue, the user should actually be focused on the label for the next question so a screen reader can pick it up. The idea of autofocus doesn’t work, but if you use the label’s FOR attribute, you achieve the same idea.

    Dynamic interaction like this is great, but we need to keep in mind that not all users use the web the same way. Personally, this type of animation actually makes me ill. Being responsive is great because it works for people zoomed in, but keyboard and screen reader user will struggle.

  8. Great demo, but I’d like to see some form validation implemented here. The fact that my email was just ‘example’ and my budget ‘hello world’ isn’t the most inspiring I’m sure. Otherwise really good work! 🙂