patternfly-design
patternfly-design copied to clipboard
patternfly
Inline editable card
There are multiple “editor” experiences in the app services space that need a more efficient inline editing/edit mode behavior than what is currently supported in PF.
We’ve come up with a design solution that we like for edit mode but want to bring this over to PF for further input/design exploration. The main value of our proposal is that it gives users 1) the ability to quickly scan existing content entered in the editor without the visual noise of a ton of open form fields, 2) enables them to quickly make edits/jump across sections, 3) and gives visual focus to the section they are currently editing.
Our current solution presents the different “sections” of the editor in cards. The cards are read-only by default, but once a card is selected it toggles on the “edit mode.” Edit mode would be toggled off once another card is selected. Since users are typically making a large # of edits in an editor experience, we don’t want them to have to manually save each edit. The proposed designs assume that once a user exits each field, the content entered in each field at the time of exit would persist. The editors should have undo/redo controls in the page header that can undo each edit. In cases where there is autosave functionality implemented in the backend, there should also be an autosave indicator in the page header.
Some questions for further discussion: Our current designs rely heavily on card-based layouts (much like google forms). Should this interaction extend to tables, forms, etc.? Should this be a demo? I could see some other new components come out of a PF “editor” experience (autosave indicator, collaboration UI indicators, etc.).
Scorecard Editor Demo: https://user-images.githubusercontent.com/46571616/103569410-374fc380-4e95-11eb-8bbb-9301622fff41.mov
Apicurio Studio Editor Designs:
Apicurio Studio Marvel - Global Settings)
FYI @mcarrano @mceledonia @amysueg @manstis @lclay2
Based on conversation with @mcoker and @mceledonia we would want to allow inline edit to be applied to the content of a card upon click. This would be enabled in the React component. Styling of the card ideally would be the same as any other selectable card.
@lboehling we will get this on the PF roadmap. Is there a specific timeframe in which it is needed? I am also going to retitle this as "Inline editable card" to better reflect the enhancement we would make.
The only problem I see with the proposed design is some potential ambiguity about what will happen when you select a card. For your current use case the proposed design makes sense, but what if there was a different action associated with card selection. Had you considered adding a more explicit edit affordance to the header of the card to toggle the card into edit mode?
@mcarrano Personally speaking (having a real life use case and feedback) we want to avoid the need to explicitly enter editing mode as is the current pattern for inline editing. Users did not want to have explicit actions to edit a field nor commit or cancel the change. We are developing an editor and, if you consider the operation of (all?) most third party editors the User simply clicks on a field and changes it. Is it not sufficient for the developer using the pattern to determine what should happen when a card is selected (it could be to enter edit mode; it could be to perform the other action as you suggest, or it could be to do both)?
Based on meeting today with @manstis @maryshak1996 @lboehling @mcoker @mattnolting @amysueg we will define a general design approach that can be built as a new PatternFly demo. This should address affordances for entering/exiting edit mode, committing changes, and the possibility for undoing changes.
I have opened a parallel documentation issue for incorporating these changes into design guidelines. https://github.com/patternfly/patternfly-org/issues/2436
@mcarrano I chatted with @lboehling and we are going to divy up the work such that she will be working on some written documentation around guidance, and I will put together a designs for a demo that we should host. With product obligations on both of your ends, we will probably have to continue this into next sprint.
@lboehling I reviewed your document here: https://docs.google.com/document/d/1jTv9Ey8SAbE89nPf01T2FWhiHihi6iCAVKYW31Gueuk/edit?usp=sharing I think this is a great summary of the problem and potential solutions. After reading this I wonder if the thing we are wanting to expose is really a demo of Inline edit or a separate/new demo called "Editor." It definitely will make use of the Inline edit component but I can see that there are other elements at play to address what a page level editor experience might look like. Perhaps we can discuss again after you create another iteration of mockups.
cc @mmenestr
Per Oct 6 sprint planning - this has been deprioritized by product. May revisit at a future date.
@lboehling Any reason to keep this open? There has not been any activity for a long time.
I think we can close this. We can reference this issue if the effort ever gets picked back up. @mcarrano