Modal dialogs are making their way into core and this could have a great impact on UX strategy for all of Drupal. In general modals are useful for allowing a user who is engaged in a primary task objective to temporarily carry out a ‘secondary’ task in an additional ‘window’.
The SiteBuilding Usability Initiative video released last month illustrates the general concept.
The key to maximizing the success of this core development effort is to factor in the various usage contexts that modals can be applied to. Determining the usage context requires identifying:
- the individual UIs where a modal can be used
- the type of modal that is required to support the task
The second item, the modal type, requires some strategic design work. The fact that modals can be classified into types means that certain parameters can be preset into suitable patterns. At the implementation level, the individual types can be captured in 'wrappers' as illustrated here:
In this illustration, the base dialog builder creates the HTML using a fixed set of variables, passed in as parameters. Three of these parameters are required (title, prompt, actions) while the others are optional (auxiliary form, extra help, associated icon).
Each wrapper type identifies a ‘recipe’ for determining which parameters to use and what their values would be. Depending on the needs of a given wrapper (modal type) variables can be immutable or entirely replaceable or partially fixed. For example, a partially fixed variable could be used for the Title by using a placeholder to allow a specific name to be used (e.g. 'Confirm Delete Article' or 'Confirm Delete Field' etc.). This is an area of control for UX design and allows the implementation of interaction patterns or rules.
The UX benefit of this is that can have consistency where we need consistency (e.g. all confirmation dialog types use the same pattern and thus more easily recognized by users.) A key development benefit is simpler function calls which can lead to wider adoption across core and contrib modules.
As I understand it, the wrapper layer could be done after the Dec 1 feature freeze. In the meantime, is this an agreeable strategy for getting optimum UX benefits from this new core feature?
I've posted a comment that describes this from a more technical perspective on [meta] Decide on where to use modal dialogs. You may want to comment there too.