5

My devs are currently working on a form that appears in a modal dialog- it was pretty big to begin with, but now they've added some fields and it's hanging off the screen- now they want to adjust the css to compact the form, which will leave it mismatched with the rest of the application. The reason it's been implemented as a modal dialog is so the user won't lose their place in the search results after clicking on one of them to edit, so I can see they have a valid reason for wanting to do it this way, still, having a modal window so large it either needs to have it's styles squashed or some kind of scroll implemented just doesn't sit well with me either. How big is too big when it comes to modal dialog forms? Should I have them split it into a multi-part form or just squash everything like the engineers want??

2 Answers 2

4

Functional excess is something you deal with on daily basis, especially as the project gets closer to something I call 'climax' (when Client gets wild and wants to put everything s/he did not consider before - meaning 'additional requirements' rather than errors at the phase of analyzing and planning functionality).

Regarding modal size itself, I would say you get too close to "too big" when any of these situations occur:

  • the physical size of the modal is so big that it obscures most of the main system interface and user loses the context of it being a part of the bigger system.

  • the functionality of the modal is so rich that (again) user loses the connection between the modal and the outer part of the interface; this also happens in case of too long multi-step processes packed into modals.

  • you find it impossible (or extremely hard) to fit within the smallest screen resolution considered in your requirements (like 1280x800 or 1024x768).

But don't worry, you can balance the above, by e.g. mixing some trickery, for example:

  • trying to limit the modal functionality to the most important features
  • moving some features to another modal, triggering two different modals from the main interface (of course if it is logically pissible to group features like this)
  • splitting the form into 2 steps (3 at most; however this depends on the system, what does it do, what is the importance of the features enclosed in the modal)
  • grouping the most important features in the first step and making the other one(s) optional
  • using CSS to pack more in the modal (but very carefully, not letting this jeopardize the whole UX, in other words not making it too packed with elements that would be too small and too difficult to understand/use for the user)

I would do this in this order. If any of these is not be possible to implement, I would skip to another one; if applying one is not enough, I would move to another one as well, to improve the solution.

1
  • Up vote just for functional excess and Climax!
    – Itumac
    Aug 28, 2013 at 21:42
6

I think Trello has an interesting solution to this which I have copied to one of my own projects. You can scroll the modal without affecting the scrolling of the interface in the background.

The width and position of the modal still lets you see whats behind it which gives you a sense of context.

This way you can keep the style of your form elements consistent without squashing anything in.

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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