metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Allen <n...@nickallen.org>
Subject Re: [DISCUSS] How should Management UI save changes?
Date Mon, 02 Oct 2017 18:30:51 GMT
> Maybe change the text on the button on the primary panel to "write"
instead of "save"?

Another option would be to call it "Apply".


> Also, I want wider child panels in the management UI if at all possible.  Especially
the "RAW JSON" feels cramped.

Yes, I agree.  It seems to odd to me that the main work area in the
Management UI is presented as a side panel that consumes a minority portion
of the screen real estate.




On Thu, Sep 28, 2017 at 12:30 PM Laurens Vets <laurens@daemon.be> wrote:

> Maybe change the text on the button on the primary panel to "write"
> instead of "save"?
>
> Also, I want wider child panels in the management UI if at all possible.
> Especially the "RAW JSON" feels cramped.
>
> On 2017-09-20 14:37, Ryan Merriman wrote:
> > Recently @nickwallen brought up some good points about the usability of
> > the
> > Management UI here:
> > https://github.com/apache/metron/pull/737#issuecomment-330632113.  The
> > issues he brings up apply to all child panels so I think it makes sense
> > to
> > agree on a common approach and apply it to all of them.
> >
> > Most child panels have a save button that saves changes to the local
> > (browser) copy of the config.  The save button on the primary panel
> > persists the changes to zookeeper and closes all panels.  Should we
> > change
> > the buttons or button text?  What should the different buttons do?  One
> > idea could be to just skip saving to a local copy, meaning hitting the
> > save
> > button persists changes in that panel to zookeeper.  Another idea could
> > be
> > to get rid of the save buttons on child panels and changes to the form
> > would immediately update the local copy.  In this case we would likely
> > need
> > an indicator that there are changes to be saved (or should we have that
> > no
> > matter what?).  Other ideas?
> >
> > There is also the issue of being able to discard changes and go back to
> > what they were before.  Now you can close a child or primary panel but
> > you
> > discard all changes in that panel and all changes period in the case of
> > the
> > primary panel.  We could be to expose a revert link or button for each
> > form
> > input (a lot of work probably).  Other ideas?
> >
> > Ryan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message