Thanks for your thoughts, Travis!
I am cautious about having each type of collection seem like it’s own first-order element though. I think there’s a real risk of confusion with too many nouns that seem like they might be different things.
I agree that we should seek to minimize noun fatigue, and cultivate the user perspective that everything on this pane is really just a collection with added bits, not n new first-order things. I’m on board with trying to find a way to show them all at once, but I think their use cases are different enough that in practice people may want to see just tags, or just books, or at least sort a table by collection type. The tags-vs-everything-else difference is salient here, since IMO editing tags is likely to be an order-of-magnitude more frequent and lightweight interaction — maybe (ugh) Tags deserve their own dashboard pane, with all other collections displayed in another pane?
This might be too early for the level of planning at the moment, but I tend to prefer inline, scrollable content over a modal or wizard
I’m not excited about modals, exactly, but I think they might be appropriate here at least for the content editor, if not the metadata editor — it’s a hefty enough piece of UI, with its own scrolling panes, that I don’t think we want to place it within another scrolling pane. It feels like it should not be possible for the user to scroll away from this editor, because it’s annoying to accidentally do that (often when overscrolling sub-panes) and have to find your way back. I like your mockup of the inline metadata fields, and I think exploring that could lead to a better UI than I have now. At any rate, we can easily add or remove these things from modals, so no rush to make a decision now and IMO it’s no biggie either way. We should discuss this synchronously at some point – I’m especially interested in having a conversation about mobile support more generally.
We do [drag and drop] for ordering the Pub Block layout, but we could do a better job with the design of it.
I wish I had seen (or bothered to look for) this before rolling my own! I think we’re using two different drag-n-drop libraries, though I’d advocate for switching to
react-beautiful-dnd for all stuff like this from now on.
Anyway, I just came to drop this off — more refinements of the collections editor:
Our conversation with the MITP folks today gave us food for thought on how to approach the crossref/DOI/citations aspect of collections. In particular we need to decide:
- When does crossref submission happen? Is it a state (think checkbox) or an action (think button)?
- What implication does submitting a collection to crossref have for its constituent pubs? How do we communicate that to the user?
Kelly and Rachel didn’t have tons of pointed feedback on these questions — it seems like the need to explicitly deposit journal issue data as an object into Crossref isn’t really part of their workflow — but I think we got some good signal that the interface we’re building is in some sense sufficient and doesn’t have any huge blind spots. I’m going to punt on all of that for a little bit and focus on the implementation details of Collectins on the backend while we decide what our angle there is.