Latest Contributions by PeterKnoop

While the submit button and navigation bar can currently be hidden by using URL parameters, it would be great if this was surfaced more directly and easily in the Web Designer user interface. There are already on/off toggles under Appearance --> Layout Element for the header, description, and footer. It would be helpful to have toggles there as well for the submit button and navigation bar. Others have already shared some example use cases as to why one would want to hide the submit button, such as, Suppress Survey123 Form Submit Button. Our interest here is to improve the user experience of workflows for embedding Survey123 in other sites. For example, embedding a single choice question in a StoryMap being used in education or for training, such as: (Rules are configured for the first Single-choice question to show whether the user's answer is correct or incorrect using a couple of subsequent Note type questions. As is often desired for self-assessment, this gives the user immediate feedback, perhaps with a hint or link if they are wrong, a chance to answer again, and no need to formally submit an answer to the survey.) Currently this requires the author to understand how to use Survey123's URL parameters. Adding hide=submit,navbar to their survey's URL does what is needed. That approach, however, presents a barrier to the typical users who want to author StoryMaps like this with surveys for self-assessment. They are comfortable with figuring out the Web Designer user experience, but not with implementing URL parameters. If the ability to toggle on/off the navigation bar and submit button were directly available in the Web Designer, then they could simply cut-and-paste their survey's URL and use it as-is, which would allow them to do all of their work within the standard user interfaces of Survey123 and StoryMaps.     ... View more

When embedding a Survey123 form in another website, such as a StoryMap, it would be nice if it was possible for the background color of the main page to show through. This would help when one desires a user experience where the survey appears visually well-integrated with the rest of the page content, rather than as something separate and distinct. Perhaps this is achievable by adding an Opacity setting to the rest of the Color options for Content and Web Page in the survey's Appearance? Similar to the existing Opacity setting for the Content Background Color in Appearance. If the page in which you are embedding the survey has a white background, like the default Summit theme of StoryMaps, then you can achieve good visual integration by setting the survey's Web Page Background Color to white too. If you use a different StoryMap theme that has a non-white background color, like Ridgeline or Mesa, then you could also set the survey's Web Page Background Color to match. It would be simpler, however, if you didn't have to worry about exactly matching colors, and could use transparency instead so that it always matched, even if you changed themes.     ... View more

The 3 November 2021 StoryMaps Update added the feature: "When a story is published, its first few paragraphs are added to its ArcGIS item description." An unfortunate side effect of this new functionality is that if a user crafted their own Description prior to 3 November, then it now gets wiped out when they next publish their StoryMap. If they go back and fix their Description, it is overwritten again the next time they publish their story. This loss of content is not a behavior users are expecting, nor does it appear to be desired by any of our users. It seems others are experiencing similar issues with this change as well, such as @JosZwambach1 notes in Description overwritten by storymap.   Also, this a behavior that is not shared with other item types in ArcGIS Online, which contributes to the confusion. What is the rationale for StoryMaps overwritten the Description in Item Details, in particular if a user has already provided their own content for it? Is there some benefit this enables that we are overlooking? We would like to have full control over this field returned to the user.  Perhaps if there is a good reason to have StoryMaps populate the Description field with a story excerpt, then that could be an option controlled per item by the user, with the default being no overwriting? Or, perhaps the auto-updating during story publication should only happen if a user has not manually modified the Description already? ... View more