Closed LynnMcRae closed 8 years ago
@LynnMcRae I would like to fix this. I need a clear understanding of what we are doing for modals globally. It feels like we have hijacked modal interactions in a couple of places.. Could you describe how modals should work. We don't seem to have any tests for this... that I can find. A few things I've uncovered:
off-hand, here are the answers to jack's questions above, including convoluted historical background...
x
or cancel
buttons (but not escape or click away). we use this in places where modals contain editable content (e.g. for editing datastream xml, though there might be other editable things that still use the regular modal). @LynnMcRae wanted this behavior so that it'd be harder to accidentally have work in progress disappear or get lost due to a mistaken click or key stroke (and IIRC, it turns out it's just a one of the bootstrap modal behavior settings). also, these modals save state unless they're closed via the cancel
button (not the x
, which just hides it). that was implemented initially because jessie and chris thought that disabling close on esc
would be difficult, and suggested using code similar to some searchworks code jessie was writing for hiding modals to save state instead of recreating them every time they were opened (i didn't discover the setting for disabling esc
/x
/clickaway until after the persistent version was implemented).i'll look at the code and the commit history later this afternoon and come up with better answers. also happy to pair on this stuff if that'd help, since some of that modal behavior is stuff that i implemented.
Thanks for the great context. Will work around that for now and try to clean up some of this.
A few additional questions:
Thanks!
I put the modals into two categories (restating much of what John summarized)
We know we have a, um, situation with the datastream modal, which changes from informational to edit with a link. If a modal can't change its stripe, can it be replaced on screen with a different modal? Some other approach?
Re persistent modal. If this exists to save state for an accidentally dismissed form, it would be nice to avoid the situation in the first place as described above. Otherwise sure, it's nice if you did some edits, accidentally closed the modal with a stray click or un-intended ESC, and found your edits there when you re-opened the modal immediately. I don't really know the scope of the persistence.
Where do we change the modal title now? I can see the double-header that originated this ticket to be a case, since a generic "more >>" is less desirable than knowing what facet you more-d
We have several different patterns right now on how the modals are implemented. I'm in the process of migrating us to a single pattern which I hope can accommodate these situations and alleviate the title, styling, and close issues without losing the work already put into this.
I imagine this will be resolved by your modal unification work, but just to enumerate some more of the inconsistencies and other issues.
Most modals have a sharp cornered red header resting on top of the round-cornered modal which looks odd to me. Some have left-justified titles, some are centered (preferred/default?)
We used to have a more integrated style, represented by the second half of the double-header that is the subject of this ticket.
Note SW does something similar, minus the red background
Finally, the blue-button form/dialogs are just a mess. Action controls are found in the form, sometimes multiple ones, as well at the bottom of forms. The internal dialog problems won't be fixed by modal unification alone, though I hope they won't get in the way. I'll work on separate tickets for individual dialogs.
This most recent mdal may be the closest to the controls we want, except for the redundant and ambiguous close-X in the header.
Open version also has good controls, albeit in a different style
Two red bars, differently rendered, both with an operable close X A bug perhaps, but not one that gets in the way.