[GitHub] metron issue #737: METRON-1161: Add ability to edit parser command line opti...

[nickwallen <gi...@git.apache.org>]

Github user nickwallen commented on the issue:

    https://github.com/apache/metron/pull/737
  
    @merrimanr This will be uber useful.  Here are my initial reactions focusing on usability.  I am totally open to knocking some of these out as separate PRs, should that be a better approach.
    
    ### (1) Double Save Required
    
    A user is required to do a "double save" for the changes to hit Zookeeper.  When I click "Save" on the "Storm Settings" panel, it doesn't actually save anything yet.  I then have to click "Save" again on the parser edit panel.  Once I do this "double save", I can then see the settings take effect in Zookeeper.  
    
    This is counter-intuitive to me.  A button that saves "Save" should save things.
    
    ### (2) Unsaved Changes Indicator
    
    When the user changes a field in the "Storm Settings" panel, it would be nice to have an indication that there are unsaved changes.  This "unsaved change indicator" should stick around until we actually push the changes to Zookeeper.  I should not be able to exit the panel without a warning, if I have unsaved changes.  Right now, I can close the panel and lose all of my changes.  
    
    In this case, I think this is important because the "Save" and "Cancel" buttons show up "below the fold" and are not visible unless the user scrolls down.  On my first pass, I found myself making changes on the panel, clicking the X in the top-right corner because this is the only transition that is visible.  I then found that my changes were not saved.
    
    ### (3) What Now?
    
    Once the user saves changes on this panel, I think we need to provide some guidance to the user as to what to do next.  As a user I am left wondering; 
    * What just happened?  
    * How do I know that his action was successful?  
    * What do I need to do now?
    
    ### (4) Warning about Persistence
    
    We should have a warning that indicates under what conditions these settings will not persist.   Right now all we do is dump them in Zk.  So if Zk is restarted, we lose them, right?  Whatever does actually happen should be made clear to the user.
    
    ### (5) Reset to Defaults
    
    It would be nice to have a "Reset to Defaults" button of some sort.  I wanted to go back to what I had initially.  I tried to do this by erasing the value in each field and then saving.  All this did was set each value to 0, which is not the "reset to defaults" that I expected.
    
    ### (6) Blank Fields
    
    The `NUM_WORKERS` and `NUM_ACKERS` are blank, unlike all of the other configuration fields.



---