To summarize where we're at ... Proposed approaches (summary):
- Establish a default read-only view whereby an operator can enable edit mode. Use confirmation dialogs for deletes. - Keep the current model but add support for ‘undo’. - Let the user choose whether to lock their view or not as user preference. - For delete add more protections to make accidents less likely and for movement provide an explicit ‘move action’. The idea of locking seems to have some strong views on both sides and both sides have even been argued by the same people (i now count myself among that group). It looks like a consensus view there though is: - Try to make panning the view of the flow and moving components on the flow two specific/discrete actions to avoid accidental movement. - Add support for undo - Provide sufficient dialog/protection for delete cases. This preserves the model whereby we generally trust that the user will do the right thing and we’ll do more to help them and that when they don’t they will learn and have help to promptly restore a good state. How do folks feel about that? Thanks Joe On Tue, Aug 11, 2015 at 5:11 AM, Alex Moundalexis <[email protected]> wrote: > Counterpoint, accidents happen; I prefer to enable users to learn from > mistakes and exercise more care next time. You can't remove every mildly > sharp edge without impacting experienced operators; resist the urge at a few > comments to dumb down the tool. > > If some protection is added to the UI, suggest an option for "expert mode" > that retains original functionality... that way experienced operators aren't > affected. > > Alex Moundalexis > Senior Solutions Architect > Cloudera Partner Engineering > > Sent from a mobile device; please excuse brevity. > > On Aug 7, 2015 10:31 PM, "Joe Witt" <[email protected]> wrote: >> >> Team, >> >> We've been hearing from users of nifi that it is too easy to >> accidentally move something on the flow or delete large portions of >> the flow. This is the case when panning the screen for example and >> accidentally having a processor selected instead. >> >> What is worth consideration then is the notion of making the flow >> 'read-only' by default. In this case the user would need to >> explicitly 'enable edit mode'. We would then also support a >> confirmation dialog or similar construct whenever deleting components >> on the flow. >> >> Anyone have a strong objection to this concept? If so, do you have an >> alternative in mind that would help avoid accidental movement? >> >> Thanks >> Joe
