Syndesis: UX - Publish button visible even while publishing an integration - design v1.1

Created on 20 Jul 2018  路  9Comments  路  Source: syndesisio/syndesis

This is a...


[ ] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Documentation issue or request

The problem

While an Integration is in "Publishing" state, it still shows a "Publish button". This sounds a surprising option, that in my view, could lead an impatient user to keep pressing the button if things are just slightly slow

Screenshot


screenshot from 2018-07-20 10-12-18

cabug cadiscussion grouui grouuxd prip2

Most helpful comment

One note, that Edit button on the draft row is also going to be disabled as part of disabling editing for #3095

All 9 comments

@paoloantinori - are you talking about the "publish" button in the Draft row? I would suggest to style the button as disabled.

Also wanted to make sure that we don't have "start" in the kebab menu at the top right when publishing is in progress.
screen shot 2018-07-20 at 9 21 41 am

Hi @dongniwang yes, I was talking about the "publish" button in the draft row.

I agree with you on the UX improvement and I think they can be handled. How do we want to tackle this from a UX to Eng process pov?

Should we alter current design and we keep track of this as a minor version? like 1.1?
Or were these already defined and should we just file these as bugs?

Or should we just address these during the next major design review?

@amysueg any idea on what could be the best way to track this activity and being sure that we won't lose track of it?

@paoloantinori I checked the designs and it wasn't defined but instead of updating the designs and reviewing, I wonder if we can have a signoff for minor design changes such as this just in Github? That way we can treat it as a bug and move forward changing it?

Also, as far as tracking it on our end, what are your thoughts (@michael-coker @seanforyou23 @dongniwang) on adding a new column to our design tracker at the end called "Notes". Then we can add links to additional bugs/minor changes discussed based on the latest designs?

I'm cool with utilizing a new "notes" column, in an effort to remove the overhead of creating and approving new designs for minor changes like this.

One thing I wanted to keep a pulse on is, do we still plan to move the integrations to being tracked in the ngrx store? It would make for a much cleaner way to solve this problem, and there are several other places in the UI that could benefit from the same thing (dashboard integrations donut chart for example). This doesn't need to be addressed as part of this issue, just wanted to mention since it hasn't come up in a while.

@paoloantinori Discussed how to track minor design changes with the UX team, and we all agreed that for minor changes such as this, would be okay to discuss design changes within the git issue/bug and sign-off here.

We would then add a minor version of the specific design it's attached to in our design tracker that would link to the Git issue which includes the discussion (as opposed to Invision). A Notes or Summary column will be added to the tracker to caption a summary of the minor change. This allows us to keep track of the various versions and history of changes discussed.

FYI, @dongniwang @amysueg @michael-coker @seanforyou23

As for this specific issue, we all agree that it would be best to disable the "Publish" button during the publish state to solve this issue.

In addition, we need to remove the "Start" action from the kabob menu while an integration is in the publish state. We should keep the same behavior throughout the app where non applicable actions within a kabob menu is hidden rather than disabled.

Currently we are aware of three locations where the kabob menu lives:

Details Page
screen shot 2018-07-20 at 12 53 50 pm

List View
screen shot 2018-07-20 at 12 53 41 pm

Home Page
screen shot 2018-07-20 at 12 53 28 pm

Hi @sjcox-rh I'm okay with this workflow, thank you.

The only comment is that every enhancement is considered at risk in term of planning, since it may conflict with our pre-existing organization of work.

So engineering will try to include them, but this is a best-effort approach in the scope of an already existing Sprint.

Another thing: even minor corrections needs be signed off, at least from engineering, to confirm that they are doable on the technical side. Can you please reflect this pending/approved state in the table here: https://syndesisio.github.io/syndesis-ux/

@gashcrumb if you validate this design, we can consider to close this and keep track of development work here:

https://github.com/syndesisio/syndesis/issues/3180

Yep, sounds good to me!

One note, that Edit button on the draft row is also going to be disabled as part of disabling editing for #3095

Was this page helpful?
0 / 5 - 0 ratings