Allow multiple users to collaborate on StoryMap themes

[SamGuilford]

Currently, StoryMap themes are owned by a single user. Published themes can be shared with other users through a shared-update group, but no one (not even an Administrator!) can edit or collaborate on a theme created by another user. It would be very useful if multiple users (on a design team, for instance) could collaborate on a theme that's shared with a shared-update group, like you can with a StoryMap.

[OwenGeo]

@SamGuilford -- While there isn't currently a menu option to open someone else's theme in theme builder, the permissions do allow it. As a workaround, you can just construct the theme builder link manually using the theme ID that you want to edit, like this:

https://storymaps.arcgis.com/themes/[theme-item-ID]/edit 

As long as you have the required privileges (either as an admin or member of a shared update group that contains the theme) then you'll be able to open the theme in theme builder and make changes.

Note that shared update groups do not give members the ability to publish a draft theme, but they can publish changes to an already shared theme.

[SamGuilford]

@OwenGeo I see! That does indeed work, and both publishers and non-publishers can edit. Thanks for the tip. Two questions:

1. Is there anywhere to get that item ID besides copying it out of the item page URL?

2. Is there a permanent solution in the works for this? It seems all it would take would be a button that would take you to that .../edit URL. We are working to set up best practice workflows for our entire organization, and while this is a nice workaround, it's not terribly convenient as a permanent solution. I'd be interested to know where this stands regarding development.

Thank you.

[OwenGeo]

@SamGuilford -- We don't have plans at the moment, but I believe this is the first feedback we've heard about this. Our initial thinking was that themes are so simple (there are only about a dozen things you can change), that collaboration on the same theme wasn't needed or valuable. Anyone could whip up a new version/variant of an existing theme in a few seconds, if needed.

Could you provide a little more information about how your team would collaboration on the same theme? What would the workflow be? What conditions would a non-owner or admin need/want to edit someone else's theme? We'd also need to provide a way for you to browse other people's themes, so It would be helpful to know how you would envision using this feature being used so we can better understand your request. 

Yep, the best place to get the item ID is from the item page URL.

[SamGuilford]

@OwenGeo - thanks for the replies.

We have teams that are set up to work collaboratively on content within shared-update groups, and a team might include a few designers and a supervisor. Two main benefits of this functionality would be:

1. Multiple users would be able to work on and tweak a theme, much like you can with a StoryMap. If multiple users on a team had to recreate a theme anytime they wanted to change something, they would have to take notes on the exact properties of the theme and then try to recreate it, or go back and forth and compare. These edits may be important to ensuring brand or design compliance and continuity. I understand theme options are fairly basic at the moment, but I assume there are plans to make them more complex?

2. Supervisors would be able to review and okay a theme before it goes public. Is there currently any official way for a user besides the creator to view an unpublished theme? At the moment I believe it would require an Administrator taking ownership, but ideally we wouldn't need to involve an Admin at all (I'm following another Community Idea that would allow group members besides Administrators to update sharing settings).

[OwenGeo]

@SamGuilford - Thanks for the additional info; this is helpful. There currently isn't an option to view someone else's unpublished theme (other than manually constructing the URL, if you have the proper permissions).

We'll monitor this idea for additional upvotes and comments to evaluate how to prioritize it for future consideration.

[PeterKnoop]

@OwenGeo - I am not sure that the model of requiring users to have to ask for each specific item type to support collaboration aligns with users' expectations.

Our users expect that it is possible for them to share content -- any content -- with a group of collaborators, such that those collaborators have the same ability to work with the content as they do. In other words, they are expecting to operate where the content is owned by the collaboration, not individual users. (When ArcGIS Online lets them down in this respect, it is a big pain point.)

In ArcGIS Online, collaboration is significantly more complicated than in other content-management system, and goes against the learned behaviors from most other similar systems. Instead of sharing a piece of content or a folder of content with a list of fellow collaborators (and specifying their privileges), you have to jump through all the hops of deciding what type of group to create (such as a Shared Update group to permit collaboration on content), managing membership of the group, and sharing the desired content with that group. 

Once users learn, however, that a Shared Update group is the workflow that enables their collaborators to have equivalent responsibilities (i.e., anyone can read/write the shared content), then users also have the expectation set that this will work for any content type. The seemingly random support or non-support for collaboration depending type of content confuses users to no end. 

Do we have to setup a scheduled Python notebook that looks for new content types added to ArcGIS Online, and when it detects one, it automatically posts an Idea that the new content type needs to support collaboration? 😉

For specific use cases regarding themes, we often have people working collaboratively on a project that have the same level of responsibility for all content. One day one person may need to edit the theme, another time someone else may need to. Or, in another case, one person is asked by another to double-check their changes before publishing the updated theme.

[OwenGeo]

@PeterKnoop - Thanks for providing this perspective. I totally get it, and I apologize this is a pain point.

Building software happens incrementally, so unfortunately everything doesn't come along for free when a new item type is added. Work must be done to add every option and feature, even if similar ones already exist in other items, and we need to prioritize our overall work. We initially did not prioritize collaboration on themes, but we did consider it would be something we'd probably come back to, and we are definitely hearing you and others on this thread who are expressing that this is a need!

For now, the workarounds mentioned above provide the ability for people who have the appropriate permissions to edit someone else's theme, and we'll look at making this more convenient and discoverable in a future update. We'll also keep your comments about consistency in mind as we build out other areas of ArcGIS StoryMaps. Thanks for the helpful feedback and letting us know this is important to you and your community!

[OwenGeo]

We have some enhancements to collaborating on themes slated for early Q2 to address the comments in this thread.

[OwenGeo]

This capability was added in March 2022. For more information see:

• Release notes—ArcGIS StoryMaps | Documentation
• What's New in ArcGIS StoryMaps (March 2022) (esri.com)