pixiebrix
Move extension action buttons to sidebar
Context
- The extension action buttons: Save/Reset/Remove have been in the same place since the initial release of the Page Editor
- They are very far away from the selected entity in the sidebar that they actually affect
- People often mistake them for the "Remove" brick button
- The save button is used much more frequently than the reset/remove button
- Now that we've added Blueprint support in the Page Editor, their behavior is inconsistent/confusing. For example: clicking "Save" on an extension in the blueprint will save all extensions within that blueprint (and the blueprint itself)
Implementation Sketch
- [ ] Remove buttons from current location
- [ ] Add Save button to sidebar
- [ ] More actions button
- [ ] Slide animation on toggling more actions
Considerations
- For extensions within a blueprint, some are available on the blueprint, whereas some are available on the extension
- Blueprint: 1) Reset, 2) Delete, 3) Save
- Extension: 1) Remove from Blueprint, 2) Reset
- For singleton/standalone extensions:
- Extension: 1) Add to Blueprint, 2) Delete, 3) Reset, 4) Save
Open Questions
- To confirm: should Reset go on the extension or the blueprint? Both? What is the current behavior of reset that's implemented
- Will people be able to tell the difference between the unsaved change indicator and the save button?
Current UX
Figma Links
- https://www.figma.com/file/RGcBtgkFHIBczxhKPKtaE5/Page-Editor?node-id=774%3A24680
Out of Scope
- The vertical line UI in the "Prefix"
@icugideon could you add any links I missed to the Figma? I'm having problems finding the prototype in Figma at the moment
Also, please call out any other considerations/questions that we should clarify together with @BLoe
@BLoe we should make sure we're on the same page on which buttons to show and what the effects are. I think you also had a spreadsheet with the different combinations?
I think the only potentially controversial ones are the Extension in Blueprint cases?
- Singleton Extension (New)
- Save: create new extension
- Move to Blueprint: move/copy to blueprint
- Remove: remove locally (no way to recover)
- Singleton Extension (Existing)
- Save: save locally and in cloud
- Reset: clear unsaved changes. (Revert to currently installed local version
- Move to Blueprint: move/copy to blueprint
- Remove: remove locally, keep on cloud. In future, should prompt user if they want to also remove from cloud?
- Blueprint (New): does not exists. Blueprints are always persisted
- Blueprint (Existing)
- Save: save blueprint and all extensions
- Reset: reset to the local installed state (which might be different content than what's on cloud)
- Remove: remove locally. Any unsaved changes and unsaved added extensions are lost forever
- Extension in Blueprint (Existing)
- Remove from blueprint
- Reset: reset to current local state for the extension
- Remove: remove from blueprint and locally
- Extension in Blueprint (New)
- Remove from blueprint
- Remove: remove from blueprint and delete
Ok cool, so the main change is that we won't be showing a save button on extensions inside blueprints, just on the blueprint itself, right?
Ok cool, so the main change is that we won't be showing a save button on extensions inside blueprints, just on the blueprint itself, right?
I think so? The reset behavior as described is the current reset behavior?
Ah, ok, so we also want to change it so that, when you click reset, it only resets that extension, not the whole blueprint.
ok, so we also want to change it so that, when you click reset, it only resets that extension, not the whole blueprint
The goal of this ticket is to make the icon location consistent with the scope of the action.
If we don't have reset implemented for an individual extension within a blueprint, we can leave that button off. It's a nice to have, but not worth holding up this ticket to add that behavior