[jboss-jira] [JBoss JIRA] (DROOLS-2728) UX for custom data-types modal

Guilherme Carreiro (JIRA) issues at jboss.org
Fri Jul 13 10:50:00 EDT 2018


    [ https://issues.jboss.org/browse/DROOLS-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605089#comment-13605089 ] 

Guilherme Carreiro edited comment on DROOLS-2728 at 7/13/18 10:49 AM:
----------------------------------------------------------------------

Hi [~uxdlc],

We're trying to solve two big issues with this dialog: I) the definition of a simple (basic) data type; and II) the definition of a structured data type.

The first one is kind of easy, we just need to provide to the user an input and a select, in order to capture the name and the type of a simple data type. Here some examples of four simple data types:
 !Screen Shot 2018-07-13 at 11.26.43 AM.png|thumbnail! 

The second problem is a little bit more difficult. Because the user needs to be able to define complex data types, with nested structures. For example, the user can create a data type called Person with 3 nested fields (they are simple data types):
- Person
    -- name (Text)
    -- age (Number)
    -- email (Text)

Additionally, a structured data type can have other complex nested data types, like:
- Person
    -- name (Text)
    -- age (Number)
    -- email (Text)
    -- address (Address)
        --- street (Text)
        --- city (Text)
        --- country (Text)

The approach that you adopted to solve the scenario above was to express these nested levels using text:
 !Screen Shot 2018-07-13 at 11.34.15 AM.png|thumbnail! 

..which is pretty interesting. But, the example that we're handling here has only one level of nesting (Address), and Edson is concerned about situations where we're going to have many levels of nesting in many fields. Something like this:

- Person
    -- name (Text)
    -- age (Number)
    -- email (Text)
    -- address (Address)
        --- Something (Something)
            ---- field1 (Text)
            ---- field2 (Text)
            ---- field3 (Text)
            ---- field4 (Text)
            ---- field5 (Text)
            ---- field6 (Text)
            ---- field7 (Text)
            ---- field8 (Text)
            ---- Something (Something)
                ----- field1 (Text)
                ----- field2 (Text)
                ----- field3 (Text)
                ----- field4 (Text)
                ----- field5 (Text)
                ----- field6 (Text)
                ----- field7 (Text)
                ----- field8 (Text)
                ----- Something (Something)
                    ------ field1 (Text)
                    ------ field2 (Text)
                    ------ field3 (Text)
                    ------ field4 (Text)
                    ------ field5 (Text)
                    ------ field6 (Text)
                    ------ Something (Something)
                        ------ field1 (Text)
                        ------ Something (Something)
                            ------- field1 (Text)

Edson thinks that the user should be able to: a) navigate between levels; b) expand/collapse nested types; c) create complex data structures easily.

That said, we need a different approach to handle this kind of complex structure. Maybe we could adopt the tree view prototypes and improve it, maybe we could use a breadcrumb to navigate between levels, or maybe we can have another idea :)


was (Author: karreiro):
Hi [~uxdlc],

We're trying to solve two big issues with this dialog: I) the definition of a simple (basic) data type; and II) the definition of a structured data type.

The first one is kind of easy, we just need to provide to the user an input and a select, in order to capture the name and the type of a simple data type. Here some examples of four simple data types:
 !Screen Shot 2018-07-13 at 11.26.43 AM.png|thumbnail! 

The second problem is a little bit more difficult. Because the user needs to be able to define complex data types, with nested structures. For example, the user can create a data type called Person with 3 nested fields (that are simple data types):
- Person
    -- name (Text)
    -- age (Number)
    -- email (Text)

Additionally, a structured data type can have other complex nested data types, like:
- Person
    -- name (Text)
    -- age (Number)
    -- email (Text)
    -- address (Address)
        --- street (Text)
        --- city (Text)
        --- country (Text)

The approach that you adopted to solve the scenario above was to express these nested levels using text:
 !Screen Shot 2018-07-13 at 11.34.15 AM.png|thumbnail! 

..which is pretty interesting. But, the example that we're handling here has only one level of nesting (Address), and Edson is concerned about situations where we're going to have many levels of nesting in many fields. Something like this:

- Person
    -- name (Text)
    -- age (Number)
    -- email (Text)
    -- address (Address)
        --- Something (Something)
            ---- field1 (Text)
            ---- field2 (Text)
            ---- field3 (Text)
            ---- field4 (Text)
            ---- field5 (Text)
            ---- field6 (Text)
            ---- field7 (Text)
            ---- field8 (Text)
            ---- Something (Something)
                ----- field1 (Text)
                ----- field2 (Text)
                ----- field3 (Text)
                ----- field4 (Text)
                ----- field5 (Text)
                ----- field6 (Text)
                ----- field7 (Text)
                ----- field8 (Text)
                ----- Something (Something)
                    ------ field1 (Text)
                    ------ field2 (Text)
                    ------ field3 (Text)
                    ------ field4 (Text)
                    ------ field5 (Text)
                    ------ field6 (Text)
                    ------ Something (Something)
                        ------ field1 (Text)
                        ------ Something (Something)
                            ------- field1 (Text)

Edson thinks that the user should be able to: a) navigate between levels; b) expand/collapse nested types; c) create complex data structures easily.

That said, we need a different approach to handle this kind of complex structure. Maybe we could adopt the tree view prototypes and improve it, maybe we could use a breadcrumb to navigate between levels, or maybe we can have another idea :)

> UX for custom data-types modal 
> -------------------------------
>
>                 Key: DROOLS-2728
>                 URL: https://issues.jboss.org/browse/DROOLS-2728
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam, drools-tools
>         Attachments: DROOLS-2700.png, Screen Shot 2018-07-13 at 11.26.43 AM.png, Screen Shot 2018-07-13 at 11.34.15 AM.png, nested.png, prop-panel.png
>
>
> As a practitioner I want to be able to define Data Types(ItemDefinition) throughDMN editor UI, by: 
> - selecting an existing data type
> - creating a new one
> - editing an existing data type
> - deleting an existing data type
> so that I can use this data type to make some decision.
> Notes (functional requirements)
> * solution that supports PHIR and MISMO schema models and similarly complex models.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


More information about the jboss-jira mailing list