Consolidate drag and drop / in-place edit / enable / collapse widget behaviors

[cbeer]

In #2484, we're consolidating the markup for the various widgets that provide drag and drop / in-place edit / enable / collapse behaviors (pre-work for eventual a11y things in sul-dlss/exhibits#1629). Now that the code is all in one place, I wonder if there's an opportunity to make the behaviors across these areas more consistent.

Examples

(ignoring the one with different styling that came out of exhibits, and the weird vertical alignment):

1) About pages > Contacts

• Move the non-title information into an element below the title (e.g. as sort does it)

I'm not comfortable with this because it seems like it will increase the overall height of the panel and more importantly, take away from the fact that the current layout (thumbnail side-by-side with the title and other info) provides a nice representation of how the final contact info is presented in the sidebar. Moving the non-title info into a section below the title will visually separate the pieces that are meant to be seen as a group. I'm not opposed to trying it to see how it turns out, but I think the current layout works well as is.

2) Browse Categories

• Move the View/Edit/Delete links to the right?
• Move the description into an element below the title (e.g. as sort does it)

It might be worth moving the links to the right to gain the consistency benefit, but I'm unsure about whether the description should go into the below-title element versus just putting it where the View/Edit/Delete links are now. My concern with using the below-title element is that it will make all the panels taller, and waste space in the top element (i.e., I don't think we want the thumbnail any smaller, so we'll be leaving empty space below the item count, while adding new space for the below-title element). The current layout makes good use of the available space (keeping in mind many realistic descriptions are more than the single line as in your screenshot) but I'm open to seeing how it works to get the benefit of the relocated links.

3) Pages

• [ ] Display thumbnails? Good idea. This might encourage use of the Pages widget because it will be more clear how to use it if you've already provided thumbnails for your pages (although since you add the thumbnails in a different way compared to the About and Browse thumbnails, it still might not be as easy to figure out). I would do this in a layout very similar to the About contact panel.

4) Search fields

• [ ] Add "Restore Default behavior? Good idea.

5) Sort fields

• [ ] Add "Restore Default behavior? Good idea.
• Should the sort description be togglable (e.g. as facet fields do it)?

Not sure about this. The facets are toggleable because they have seldom-used options that make sense to hide from the initial view. The sort descriptions seem more immediately useful to help the user understand what each one is (the ones in your screenshot are self-explanatory, but ones in real exhibits seem more complex). I'm not sure it is a good idea to hide those descriptions behind a toggle.

6) Facet fields

I think we should consider adding the "Restore default" button to these as well, but to do that consistently we'll need to rethink how the current info is displayed, which could be part of the design work needed for #2449.

7) Appearance > Main menu

[ggeisler]

@cbeer @camillevilla I edited the original ticket description with my comments in italics (and make a checkbox for the things that seem definitely good to do).

I support the overall goal of being more consistent but when you think about the purpose of each of these panels, there is quite a bit of variation, which makes using the same layout less clearly beneficial from a UX point of view. Hopefully my comments explain what I mean, but basically it feels like in some cases we'd have to give up some UX benefit to get more complete code consistency, and I'm not sure that's the best tradeoff.

But to the extent you're willing to experiment with some of the cases I'm uncertain about, I'm happy to take a look and reevaluate.

[camillevilla]

👍 Sounds good, @ggeisler. The work in #2484 is just focused on extracting from the widgets as-is. @cbeer decided that the other work mentioned in this ticket (e.g. Adding "Restore default" behavior to some widgets) will happen in separate PRs.