Change Details

# Preamble Each ZObject key (node) has an inline "mode switcher", to allow the key representation to be changed, which is a necessary but relatively rare use case. Currently we use a drop-down with four options. Sometimes, if the key has content, two of these are disabled. Pros: * This uses little space * Options are visibly mutually intelligible Cons: * No opportunity for explanation of what these are for and why * Not clear why you can or can't do certain actions. * No "undo" option if you've done something and now decide you don't want to. We should improve this area. # Design proposal Remove the mode switcher in favor of a programmatic understanding of the mode based on the selected type. Here's an example in which an editor wants to edit the "Family" key of the object `Calbovista subsculpta` which is of type `Mushroom`: 1. When they open expert mode (accordion with a grey background) they can see that the type of "Family" is `Reference` and that the below `Value` is select/dropdown where they can select or search any other object that can be referenced. 2. They want to change the type because they know there's an existing function that returns the family of a mushroom given the mushroom name. 3. Once they select the function `Mushroom family name` we can assume that the mode is going to be a function call `f(x)`, and the form below will dynamically change to serve this specific purpose. {F35413457} Other examples can be found under the "Edit mode" section of [[ https://www.figma.com/file/uNBSv1e4ceA8tGNr29R9vp/Default-component?node-id=1843%3A23161 | this Figma file ]].

# Preamble Each ZObject key (node) has an inline "mode switcher", to allow the key representation to be changed, which is a necessary but relatively rare use case. Currently we use a drop-down with four options. Sometimes, if the key has content, two of these are disabled. Pros: * This uses little space * Options are visibly mutually intelligible Cons: * No opportunity for explanation of what these are for and why * Not clear why you can or can't do certain actions. * No "undo" option if you've done something and now decide you don't want to. We should improve this area. # Design proposal Swap the mode switcher in favor of a limited type selector. Here's are some examples in which an editor wants to edit a key that needs to be of type string. They can select type string (for mode literal), select type function (for mode function call that returns a string), or type reference (for mode reference that reference an existing string object). There's also type argument for the objects that require it. Every selection will dynamically change the presented UI, eg. for type string we will display an input filed, for type function we will display a function lookup. ### Edit key of type string {F35521491} ### Change key from type string to type reference {F35521492} ### Change key from type string to type function {F35521493} Other examples can be found under the "Edit mode" section of [[ https://www.figma.com/file/uNBSv1e4ceA8tGNr29R9vp/Default-component?node-id=1842%3A22316 | this Figma file ]]. --- # Some other ideas If we believe that the type selector (aka mode switcher) needs more explanations, we could leverage the dropdown menu real estate to give additional information on the different types (final copy to be defined). {F35521517}

# Preamble Each ZObject key (node) has an inline "mode switcher", to allow the key representation to be changed, which is a necessary but relatively rare use case. Currently we use a drop-down with four options. Sometimes, if the key has content, two of these are disabled. Pros: * This uses little space * Options are visibly mutually intelligible Cons: * No opportunity for explanation of what these are for and why * Not clear why you can or can't do certain actions. * No "undo" option if you've done something and now decide you don't want to. We should improve this area. # Design proposal RemoveSwap the mode switcher in favor of a programmatic understanding of the mode based on the selected type.limited type selector. Here's are some examples in which an editor wants to edit a key that needs to be of type string. They can select type string (for mode literal), select type function (for mode function call that returns a string), or type reference (for mode reference that reference an existing string object). There's also type argument for the objects that require it. Every selection will dynamically change the presented UI, eg. for type string we will display an input filed, Here's an example in which an editor wants to edit the "Family" key of the object `Calbovista subsculpta` which is of type `Mushroom`:for type function we will display a function lookup. 1. When they open expert mode (accordion with a grey background) they can see that the type of "Family" is `Reference` and that the below `Value` is select/dropdown where they can select or search any other object that can be referenced. 2. They want to change the type because they know there's an existing function that returns the family of a mushroom given the mushroom name. 3. Once they select the function `Mushroom family name` we can assume that the mode is going to be a function call `f(x)`, and the form below will dynamically change to serve this specific purpose.### Edit key of type string {F35521491} ### Change key from type string to type reference {F35521492} ### Change key from type string to type function {F35521493} Other examples can be found under the "Edit mode" section of [[ https://www.figma.com/file/uNBSv1e4ceA8tGNr29R9vp/Default-component?node-id=1842%3A22316 | this Figma file ]]. --- # Some other ideas {F35413457}If we believe that the type selector (aka mode switcher) needs more explanations, we could leverage the dropdown menu real estate to give additional information on the different types (final copy to be defined). Other examples can be found under the "Edit mode" section of [[ https://www.figma.com/file/uNBSv1e4ceA8tGNr29R9vp/Default-component?node-id=1843%3A23161 | this Figma file ]].{F35521517}