Log Step: UX Design

[syndesis-bot]

@sjcox-rh	2017-11-14	UX Design

Please reference https://docs.google.com/document/d/15qq-mIf_EAV2bEgbg44zXDMTI-ev1QChGriiwlulRA0/edit

Designs for adding a log step in integration workflow. As a citizen user, I would like to add one or more steps to an integration flow that allow me to log context around the processing of the integration.

Also have to design how and where the user will view these logs. Also comes with log viewer.

[amysueg]

@sjcox-rh is working on this - adding her to the issue

[paoloantinori]

Hi, I'm checking the stories currently still in Inbox column for Spring 24. https://github.com/syndesisio/syndesis/issues#boards?milestones=Sprint%2024%232018-02-16&repos=105563335

Do you have any update on this?

thank you

[amysueg]

@sjcox-rh - this is the last one to ask for your input. thanks SJ!

[sjcox-rh]

@paoloantinori Sharing designs with UX team tomorrow to get initial feedback. Then will share designs for rest of team!

fyi, @amysueg

[paoloantinori]

hi @sjcox-rh do you have any update on this?

[sjcox-rh]

Here are initial designs for the log step. Please let me know if you have any comments on questions. Since this is the first round, I'm sure there will be some updates needed. I referenced the Log brain dump doc from last year so not sure if there have been any changes on requirements. Last I checked it was still relevant.

@iocanel, since you have been working on the POC was hoping to get your input on this.

fyi, @paoloantinori @chirino @kcbabo @rhuss @amysueg @michael-coker @seanforyou23

[kcbabo]

Thanks for creating the initial designs, SJ! My comments:

• There should not be a dropdown for log level.
• There should not be a preview window unless this is just a static example of what the log content will look like.
• The input for the custom text option needs to be much larger. A multi-line text area would be good.
• I don't think we need a custom editor tab. The custom text input should be enough on the main tab.

[gashcrumb]

Not sure what we have at the backend to support validate?

We could just make the custom text input a text area. Later on we could probably also consider making the text area a fancier editor. Most likely then we're pretty close to not having to write a custom page which would save us a lot of time on the UI side.

[kcbabo]

I think we originally said we could hang a validate method off of the REST API that took a Simple language expression and just did an eval on it to validate syntax. I'm fine with punting that if we don't have time. Agree that avoiding a custom page and saving time would be optimal.

[sjcox-rh]

@kcbabo @gashcrumb

I made the changes you suggested. Removed custom editor option along with Validate action. Replaced the drop down with check boxs for log level. Also provided 2 options for the updated designs.

Option 1:

Option 2:

[kcbabo]

Hey @sjcox-rh The new designs still have the log level (Errors, Warning, etc.). That should be removed completely.

Based on the conversation with Stan, I don't think we need a Preview pane.

[sjcox-rh]

@kcbabo sorry for the confusion, I'll remove those. So jsut to confirm, the only content we will show is "Select the log entry content" with the 3 options via checkboxes and the custom text input field?

[kcbabo]

Yep, that sounds good.

[iocanel]

For message header, it doesn't really make sense to have it as a checkbox. It should be a text-field, in which the user should enter one or more headers that need to be displayed.

[kcbabo]

So "Message Header" should actually be "Message Headers". The idea is that checking that box will dump all message headers to the log. If a user wants to log a specific header value they can use simple language expression in the custom text entry.

[iocanel]

Makes sense!
Do we have any plans for exchange properties?

[kcbabo]

We could rename the checkbox as "Message Context" and print both headers and properties. I don't think we want to add separate checkboxes for headers and properties - users won't have any idea what those mean.

[iocanel]

Sounds great!

…

On 02.27.18, Keith Babo wrote: We could rename the checkbox as "Message Context" and print both headers and properties. I don't think we want to add separate checkboxes for headers and properties - users won't have any idea what those mean. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #332 (comment)

[sjcox-rh]

PR created! Please review issue #1852

[amysueg]

@sjcox-rh - ok to close this issue now?

[sjcox-rh]

@amysueg yup! I'll close it now.