[jbosstools-fuse-dev] [jbosstools-fuse-dev - 4] new transformation wizard

[Brian Fitzpatrick]

Yup. I'll start working on this. My daughter needs a tetanus shot (stepped on a piece of metal in the back yard) and I have a chiropractic appointment to put my shoulder back where it needs to be, but will otherwise be here and get out more mockups. 

--Fitz

_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, Tooling
JBoss by Red Hat

----- Original Message -----
From: "Keith Babo" <kbabo at redhat.com>
To: "Brian Fitzpatrick" <bfitzpat at redhat.com>, "John Verhaeg" <verhaeg at icloud.com>
Cc: jbosstools-fuse-dev at lists.jboss.org
Sent: Friday, March 20, 2015 10:40:50 AM
Subject: Re: [jbosstools-fuse-dev] [jbosstools-fuse-dev - 4] new	transformation wizard

Yes, definitely.  The mockup that Brian sent initially was just an example of what it would look like for Java.

Brian  - can you add some mockups for the other types.  I want to suggest a subtle change in what we ask for as well.

In the “Types Transformed” section on page 1, I think the values for each dropdown should be:

- Java
- XML
- JSON
- Other

The user is indicating here what the type of data is that they will be transforming, not the file type that describes that data (that comes later).  The question that is being answered here is “What data format, if any, should be used for mapping input and output?”.

On page 2 and page 3, we can then ask the user to point to the file that describes their data.  Here’s what the UI would look like for each case:

Java
Model type : type browser to select class
XML
Type definition : radio buttons with options “XML Schema” and “XML Instance Document"
File path : resource browser filtered based on type selected above (*.xsd or *.xml)
JSON
Type definition : radio buttons with options “JSON Schema” and “JSON Instance Document"
File path : resource browser filtered to show *.json
Other
Data Format Id : drop-down with values pulled from data formats defined in Camel configuration
Model type : type browser to select model class

Putting options like “JSON Schema” on the first page is a bit awkward, because the user is not transforming from JSON Schema to some other format.  They are transforming from JSON and they are potentially choosing to describe that data using JSON Schema.  There’s a difference and I think that the question on page 1 should be simple/uncluttered and really just ask about the types being used.

regards,
keith


> On Mar 19, 2015, at 7:37 PM, John Verhaeg <verhaeg at icloud.com> wrote:
> 
> This demonstrates what the current data formats would look like, but for "other" there'd also be an additional text field for the data format, right?
> 
> 
> 
>> On Mar 19, 2015, at 3:23 PM, Brian Fitzpatrick <bfitzpat at redhat.com <mailto:bfitzpat at redhat.com>> wrote:
>> 
>> I've put together a quick mockup of some screens for the "Java to Java" case...
>> 
>> Let me know how close I am...
>> 
>> _______________________________
>> Brian Fitzpatrick (aka "Fitz")
>> Senior Software Engineer, Tooling
>> JBoss by Red Hat
>> 
>> ----- Original Message -----
>> From: "Keith Babo" <kbabo at redhat.com>
>> To: "Johnny Verhaeg" <verhaeg at icloud.com>
>> Cc: jbosstools-fuse-dev at lists.jboss.org
>> Sent: Thursday, March 19, 2015 1:55:21 PM
>> Subject: Re: [jbosstools-fuse-dev] [jbosstools-fuse-dev - 4] new    transformation wizard
>> 
>> 
>>>> On Mar 19, 2015, at 3:33 PM, Johnny Verhaeg <verhaeg at icloud.com> wrote:
>>>> One immediate gotcha here is that the potential list of types supported by data formats is unbounded - a user can create their own data format to handle any type of custom/proprietary/unique data.  This means we will always have to have an “Other” category.
>>> 
>>> I guess I’m still a little confused about where and when some of this occurs.  Wouldn’t the user need to define the custom Camel data format and generate the associated model classes before they specify/select it in our wizard?
>> 
>> In the case of “Other”, yes, that’s exactly what they would do.
>> 
>>> 
>>>> Another gotcha is what if a file extension is not a deterministic factor in selecting a data format, e.g. the delimiters for a variable length data format are specified in a .xml file?  By asking the user on page 1 what type of data we are dealing with, we have the possibility to customize the source/target pages and just focus on the requirements for that type.  IOW, I think we will likely move away from trying to guess the type based on the file extension and instead ask the type first and then customize the configuration page in the wizard for that type.
>>> 
>>> This makes sense to me, too.  Sounds like maybe this means we should move the type field “before" the path field at a minimum, regardless of whether that means “above” on the same page, or by itself on the first page with the path fields on following pages.
>> 
>> With the proposed change, the type is on the first page in the [Source Type]  —>  [Target Type] row.  Those would be drop-downs like we have today.  The path would no longer be on the first page and would be configuration that is entered on the following pages.
>> 
>>> If they end up on the same page after all this, I would still attempt to auto-select the type if the user happens to choose the path first, but that’s just a little extra candy.
>> 
>> True, but I think they should be on separate pages.
>> 
>>> 
>>>> The promise I mentioned earlier is that it would be nice for our own purposes if there was a standard way to plug new “configurators” in for types as we add them (e.g. CSV).  Makes things faster for us and potentially allows a user to declare an extension which can configure their own custom formats.
>>>> 
>>>> BTW, moving to a wizard where there’s a dedicated page will help in cases where the configuration of the data format requires more user input; the ones we have today are very simple because all questions can be answered using the schema or instance doc.
>>> 
>>> I’m certainly not against having multiple pages in the wizard in general, assuming something calls for that (including just busyness).  I’m just trying to make sure we’re really at that point right now.
>> 
>> Discussing this has already produced more ideas, so continue to fire away with questions/ideas!  
>> 
>> ~ keith
>> 
>> 
>> 
>> _______________________________________________
>> jbosstools-fuse-dev mailing list
>> jbosstools-fuse-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-fuse-dev
>> <New Fuse Transformer Wizard.pdf>