[jboss-jira] [JBoss JIRA] (DROOLS-2888) Data Type UX - dialog enhancements: Add and Reorder

[Stetson Robinson (JIRA)]

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

Stetson Robinson edited comment on DROOLS-2888 at 8/20/18 2:06 PM:
-------------------------------------------------------------------

[~uxdlc], [~karreiro], Here's my proposed re-write of the data types help, based on my understanding:

Collapsed
"Data types determine the structure of the data used in DMN decision tables. You can use basic data types (example, Boolean) or you can use this dialog to create custom data types." View more >>"

Expanded
Data types determine the structure of the data used in DMN decision tables. You can use basic data types (example, Boolean) or you can use this dialog to create custom data types." 

Custom data types that you create in this dialog can be *Simple* or *Structured* data types:
• *Simple* data types have only a name and a type assignment. Example: "Age (Number)" 
• *Structured* data types contain fields and are more complex. A single type "Person" may define a number of fields within it. Example: "name (String), age (Number), email (String)."

View less >>


The main thing we want to watch for is passive, feature-centric language. We want instead user-centric language that speaks to the user and says exactly what the use can or must do.

Also, I'm not sure how we feel about linking to documentation from the UI, but our latest DMN document (to be retro-actively published to DM/PAM 7.0) describes each available data type and that will continue to be the case when this is released in 7.2. It won't be long before I have a fairly reliable 7.2 URL for that. I know with linking docs from UI there are gains (added info, doc promotion, better odds of user success) as well as losses (content out of sync, broken links) but it's a discussion that's being had around CCS. It sounds like there are ways to automate or otherwise facilitate the linking and syncing issue, but still a matter of optimal user success and opinion. This is also more prominent a discussion as community and product docs become single-sourced, and DMN will be the very first to do so :) I will be making this happen immediately after the new kie-docs repo structure is merged in the coming days/week-ish.

Just food for thought.

I should add also that we always want to specify "DMN decision tables", which are distinct (in supported features) from the guided or uploaded decision tables used elsewhere in the workbench. I know we know, but just a reminder for any communication to the user, to avoid confusion.



was (Author: stetson.robinson):
[~uxdlc], [~karreiro], Here's my proposed re-write of the data types help, based on my understanding:

Collapsed
"Data types determine the input and output values in DMN decision tables. You can use basic data types (example, Boolean) or you can use this dialog to create custom data types." View more >>"

Expanded
Data types determine the input and output values in DMN decision tables. You can use basic data types (example, Boolean) or you can use this dialog to create custom data types." 

Custom data types that you create in this dialog can be *Simple* or *Structured* data types:
• *Simple* data types have only a name and a type assignment. Example: "Age (Number)" 
• *Structured* data types contain fields and are more complex. A single type "Person" may define a number of fields within it. Example: "name (String), age (Number), email (String)."

For more information about DMN data types, see [Designing a decision service using DMN models|http://file.rdu.redhat.com/~sterobin/BXMSDOC-DMN_PAM/#dmn-data-types-ref_dmn-models]. (Temporary link)

View less >>


The main thing we want to watch for is passive, feature-centric language. We want instead user-centric language that speaks to the user and says exactly what the use can or must do.

Also, I'm not sure how we feel about linking to documentation from the UI, but our latest DMN document (to be retro-actively published to DM/PAM 7.0) describes each available data type and that will continue to be the case when this is released in 7.2. It won't be long before I have a fairly reliable 7.2 URL for that. I know with linking docs from UI there are gains (added info, doc promotion, better odds of user success) as well as losses (content out of sync, broken links) but it's a discussion that's being had around CCS. It sounds like there are ways to automate or otherwise facilitate the linking and syncing issue, but still a matter of optimal user success and opinion. This is also more prominent a discussion as community and product docs become single-sourced, and DMN will be the very first to do so :) I will be making this happen immediately after the new kie-docs repo structure is merged in the coming days/week-ish.

Just food for thought.

I should add also that we always want to specify "DMN decision tables", which are distinct (in supported features) from the guided or uploaded decision tables used elsewhere in the workbench. I know we know, but just a reminder for any communication to the user, to avoid confusion.


> Data Type UX - dialog enhancements: Add and Reorder 
> ----------------------------------------------------
>
>                 Key: DROOLS-2888
>                 URL: https://issues.jboss.org/browse/DROOLS-2888
>             Project: Drools
>          Issue Type: Story
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam, drools-tools
>         Attachments: Screen Shot 2018-08-17 at 4.29.29 PM.png, previous.gif, viewMoreLess.gif
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases: 
> As a user I want to: 
> * Add fields first to last, not last to first, in an ordered list to support the "reading" order of the fields so that I can simplify my workflow. 
> * Reorder the list of Custom data types so that I can arrange data types in a logical order.
> * Add list items in such a way that added Fields will be presented at the bottom of a structured list by default. 
> Functional considerations/ pre conditions: 
> * Fields will be presented at the bottom of a structured list by default. 
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> * Drag-n-drop be evaluated with regard to accessibility. 
> Verification conditions:
> * Scrum team and PO review. 



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