Open DiegoPino opened 4 years ago
To get the conversation started w/r/t to the first item here: I think a change that could significantly improve the ingest workflow is what you stated last: making the functionality of the buttons more explicit to inform the user exactly what the button(s) is/are doing. Something like "Save Metadata" vs. "Save Digital Object" (the first persists all the metadata and the latter uploads the object into the repository).
@DiegoPino Sorry in advance for this note, a little bit more general about webform and ingesting. I was talking few minutes ago with Anna about this and my first question was: do we really need a so complex webform for ingesting? Anna answered me absolutely yes! Why? Well, we have to consider two mainly needs: Cultural Heritage and Institutional Repositories. The last one is the reason for “user ready” webforms because Horizon2020 requires institutions load publications onto an IR before any other private/public editors, so institution’s researchers are to be able to independently load/ingesting own documents onto Archipelago by a friendly/simple/clear webforms. Maybe we need a second step where Librarian check/edit and approve what user done before make it public/restricted available. Regarding Cultural Heritage Preservation, which is more my focus, we have a different workflow. In this case the main actors are System Manager, Librarian and Digitization Staff. The first one manage files ingesting by batch scripts or something like IMI while Librarian load/edit metadata by electronic sheet or IMI, so for this kind of use webforms are not so important.
@giancarlobi Thanks for these cases, it is good to remember that batch ingest means Webform use will be for other, specific cases. Your example strikes me because our most recent Archipelago deployment provided a similar workflow (on a much smaller scale!!) - user-entered webform content goes to approval by curator/Librarian. Thinking about these stages can help us. For example the Draft/Published Node Save button is strange now, appearing on multiple wizard pages.
This is a hard issue because descriptive metadata holds almost anything (good thing!), there is no inherent UI coherence about how to interact.
More soon after talks tomorrow with Diego and Mitchell.
One analogy discussed was something like a "Save Progress" button when using a wizard for an ingest workflow. This allows a user to enter as much information about an object or collection, reach a "stopping" point, Save Progress, then return when they have more time, etc. to fully Save or Complete their ingest.
(Moving my note here since it's directly related to making webform workflow more helpful and not so much related to the topic of issue #41 ) @DiegoPino @giancarlobi, continuing off the third "•" in this comment from issue #41
Perhaps a simple way we could make the "Descriptive Metadata" Webform more helpful / useful / intuitive would be by directly employing the Drupal Help boxes to sort of guide users through where they can go to make modifications and/or provide short explanations for more context on what is happening inside the webform. Since "Descriptive Metadata" is the demo Webform that ships default, by nature, we sort of have to have a very vanilla Webform that almost imposes certain use cases. Fortunately for this project we do have some use cases where people want to really open up the Archipelago box, ignore the vanilla webform and move things around before getting started. Though, it seems we've run into more instances of users wanting to sort of know how everything is working (in other words, "upload and go") before they start tugging on patch cables and wires.
@mitchellkeaney my fear is we could end putting videos/help boxes for things that will be/could be customized. If people, e.g change some fields, the help boxes will still be around and not match. But! Webform has also non input elements. What if you write/bring that help into the webform itself?
dang, did not even think about the help boxes staying static, haha... 🤦 Can you give me an example of non-input elements in the webform, I'm sure what you mean by that? But ultimately, yes - I can write up these help suggestions to be added in one way or another!
Webform (elements) has Markup elements. Those serve as ways of outputting data/design/info without expecting people to add anything. The Webform docs are quite good (best ones i have seen in Drupal https://www.drupal.org/docs/8/modules/webform/webform-features#s-elements
perfect, thank you for linking this!
The Problem
Our webforms integration works by dynamically loading a Webform, with a special Webform Handler from inside a Widget logic. Since Every widget is also loaded inside a wrapper, Node Entity Specific form, we have Basically Two different "Save" buttons.
What we want
We want a few things here, most related to the Issue at hand, but also a bit wider into the Webform integration thing (like Ajax used, what happens if they don't want ajax?) and this leads to different tasks and solutions: 1.- We want to research use cases/empiric workflows using the current code. Like what are the normal operation steps on ingesting an Object. Are we displaying/hidding enough functionality so Users don't get confused by the fact there is "Saving Metadata" action, and a "Save the whole Node" action and both are different buttons? Other ones
So this first part is building use cases, building webforms and Form modes and testing them thoroughly, annotating issues, bugs, problems and in general worklow expectations v/s reality
2.- We want a more (as an Widget setting) seamless ingest experience, which in my opinion means:
3.- As part of this task, we want Webform to "inform" data to other Fields and their Form widgets, in specific The
Node
Label. Because theNode
Label displays its own widget (breaking the natural rendering order and making some people angry), butNode
Label is required and a must for an ingest (If we plainly hide it?Ingest simply dies!) we need to add code to our Webform widget and settings so any Webform Element (our own internal Webform "title" input) can feed, on Node Save its value into the Node Label. This could be even done more generically for other Node Fields too.This is a large and super-duper important Issue. I feel we have come pretty far with this but now we need to become Webform Pros and Form API wizards. No more time to loose and all this is needed. I would say from this one at least 4-5 Pulls can come out, but also a full set of Webform Research experience and long UI/UX driven conversations. I can share in the comments some Code pointers to get this started.
@marlo-longley @mitchellkeaney @giancarlobi