Select to view content in your preferred language

Multiple Draft Versions for One ExB Project

236
1
2 weeks ago
Status: Open
DanMakridakis
Occasional Contributor

Idea Summary:

Implement a feature in Experience Builder that allows users to create multiple drafts for the same map project, similar to version states and virtual copies in Adobe Lightroom. This would enable users to test different configurations, revert to the current published version, and manage multiple drafts seamlessly.

Current Limitations:

  1. Irreversible Changes:
    • Once a draft is altered for testing new functionality, there is no way to revert back if it doesn't work.
  2. Inefficient Testing Workflow:
    • Testing new configurations often requires creating a copy of the app. Any successful changes then need to be manually replicated in the authoritative version.
    • Alternatively, publishing the copy as the new authoritative version necessitates notifying stakeholders of the link change, adding to the administrative burden.

Proposal for Experience Builder:

Inspired by Adobe Lightroom’s version control(i), Experience Builder should incorporate a system that allows for the creation and management of multiple drafts of the same project. Each draft version would reference the same AGOL item ID, eliminating the need to notify stakeholders of link changes when a copy draft becomes the authoritative version. This system would provide the ability to revert to the current published state or previous versions if a draft proves unsatisfactory.

Functionality Details:

  1. Draft Creation and Management:

    • Users can create multiple virtual drafts, each with its own unique version ID but sharing the same project item ID.
    • A dropdown list in the Builder interface allows users to switch between different named version states.
    • If storage is an issue, virtual drafts can be limited to maybe 5 per project.
  2. Version Control:

    • Each version has its own JSON script storing all configurations.
    • Users can name each version to promote organized version management.
    • Users can overwrite the published version with any selected draft.
    • The version ID of the published draft is stored in the item description for reference.
  3. Reversion Capability:

    • Users can revert to the current published version at any time to generate a new virtual draft.
    • The published version remains read-only to ensure it can always be a fallback option.
    • Edits to the published versions JSON through AGOL Assistant would be pushed to the read-only version in Builder allowing users to update data sources and see those changes appear in Builder.
  4. Seamless Integration:

    • The system would work seamlessly with the existing item ID structure in AGOL, ensuring that links remain consistent regardless of the number of drafts created.

Benefits:

  • Flexibility: Users can experiment with multiple configurations without risk, knowing they can revert to any previous state.
  • Consistency: Maintaining a single item ID for all drafts and versions avoids the need for updating stakeholders on link changes.
  • Efficiency: Streamlined version control reduces the complexity and time involved in managing project drafts.

Conclusion: By incorporating a feature akin to virtual drafts and version states found in Adobe Lightroom, Experience Builder can greatly enhance its flexibility, consistency, and efficiency. This improvement would empower users to manage their projects more effectively, freely experiment with different configurations, and reduce the risk associated with making changes to critical applications.

 

i - Adobe Lightroom Footnote:

In Adobe Lightroom, users can create multiple version states for an image and revert to any state at any time. They can also create virtual copies of the same image, each with its own version history, while only one actual image file exists on the computer. Each virtual copy generates a new text file that dictates Lightroom on how to apply the edits for that copy.

1 Comment
DeanMoiler

Hi @DanMakridakis,

Great and well documented suggestion. Essentially it takes my idea, and extends it to allow for multiple versions to be edited for the same ExB application, rather than simply reverting the "editable draft version" to the published copy.

I think being able to create multiple versions of a single app would be incredibly useful as you may want to take an app in one or another direction (e.g. different section/view configurations), while referencing the same content, which would be simplified if not creating multiple clones of the same app, with different IDs. Great idea.