nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charlie Frasure <charliefras...@gmail.com>
Subject Re: [DISCUSS] Feature proposal: Streamline visual flow design
Date Fri, 13 Nov 2015 19:58:43 GMT
Could we use a drag event for the connection action rather than a click
event?  That might help differentiate the two actions.

The inconsistency between double-clicking a process group and a process
would be similar to the inconsistency between creating a connection and
creating a process.  A different object type might be ok to have a
different behavior, especially seeing as a processor isn't a container of
sub-objects.  Opening a process group is intuitive to me; but I also have
double-clicked on processors more times than I care to admit to, trying to
get to the configuration screen.

Take all this for whatever it's worth; I would actually prefer that
connection objects don't go to the properties screen when they're created,
but just connect from the first flow.  A double-click would quickly get you
in to modify as needed, but would "just work" when building the "happy
path" for a file process.

On Fri, Nov 13, 2015 at 1:19 PM, Mark Petronic <markpetronic@gmail.com>
wrote:

> I see your point. Well, consider my thoughts just input to the larger
> puzzle. Better to have well thought out UX than not. Nice to see you
> thinking hard about it. :)
>
> On Fri, Nov 13, 2015 at 1:14 PM, Matt Gilman <matt.c.gilman@gmail.com>
> wrote:
>
>> I thought about that when I was writing my previous response. The concern
>> there is the amount of 'clickable' space across each type of configurable
>> component (not just processors) and how much precision would be required
>> depending on the current scale of the canvas. Just don't want to make it
>> more difficult by providing less real estate to click. But this wouldn't be
>> a show stopper.
>>
>> However, we do already have double click mapped to Enter a Processor
>> Group. So we wouldn't be able to use double click for configuring a Process
>> Group. Not sure we want to introduce inconsistency in actions across the
>> types of configurable components.
>>
>> On Fri, Nov 13, 2015 at 12:57 PM, Mark Petronic <markpetronic@gmail.com>
>> wrote:
>>
>>> Right now, when you move your mouse over the processor, that connection
>>> handle icon appears. If you double click it, nothing really happens. So,
>>> and this is just my thought, just keep that behavior the same and require
>>> the double click to be NOT over that icon if you want to open the config
>>> dialog. That 'seems' pretty natural and not a UX hack. Its like there are
>>> two layers. Layer one is the processor and layer two is the dragable
>>> connection handle on top of layer one. A user needs to at least know which
>>> one of these the double click is targeted against and aim accordingly.
>>>
>>> On Fri, Nov 13, 2015 at 12:33 PM, Matt Gilman <matt.c.gilman@gmail.com>
>>> wrote:
>>>
>>>> I'm not against the double click idea. However, my only
>>>> concern/hesitation is around the behavior if the double click happens over
>>>> the connection handle. A mouse down there initiates the begin of creating
a
>>>> connection by shifting the connection handle around your mouse (dragging
>>>> thereafter the connection handle moves with your mouse). If we'd continued
>>>> with this idea we'd likely need to make some changes around this behavior
>>>> to avoid confusion.
>>>>
>>>> On Fri, Nov 13, 2015 at 12:15 PM, Mark Petronic <markpetronic@gmail.com
>>>> > wrote:
>>>>
>>>>> +1 for double-click and open config dialog on processors. Seems most
>>>>> intuitive to a user.
>>>>>
>>>>> On Fri, Nov 13, 2015 at 12:11 PM, Andrew Grande <
>>>>> agrande@hortonworks.com> wrote:
>>>>>
>>>>>> I just had the same idea today. Would like to have double-click open
>>>>>> the Properties pane of a processor, this is the majority of use cases.
>>>>>>
>>>>>> I am against making the action customizable, though. This is a case
>>>>>> where less is more for a UX and provides a consistent experience
across all
>>>>>> deployments (just imaging if someone swapped start/stop and an operator
>>>>>> expected a Props screen. Oops!)
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> From: Charlie Frasure <charliefrasure@gmail.com>
>>>>>> Reply-To: "users@nifi.apache.org" <users@nifi.apache.org>
>>>>>> Date: Friday, November 13, 2015 at 9:13 AM
>>>>>> To: "users@nifi.apache.org" <users@nifi.apache.org>
>>>>>> Subject: Re: [DISCUSS] Feature proposal: Streamline visual flow
>>>>>> design
>>>>>>
>>>>>> Apologies, not sure how to properly respond to an old thread.  (Maybe
>>>>>> that's the idea.)  I was looking through the archives before posting
some
>>>>>> usability comments about the UI and turned up a couple of threads
in
>>>>>> September.
>>>>>>
>>>>>> If we did automatically open the configuration screen when a
>>>>>> processor was dropped on the canvas, a quick press of ESC seems to
back out
>>>>>> nicely.  A possible compromise for the processor configuration could
be a
>>>>>> double-click to open behavior, as it seems this action is not currently
>>>>>> assigned.  Better yet, a user-configurable double click action (start/stop,
>>>>>> configure, data provenance, etc) would be nice.
>>>>>>
>>>>>> The other enhancements mentioned would be great as well.
>>>>>>
>>>>>>
>>>>>> Rob Moran <rmo...@gmail.com> Subject Re: [DISCUSS] Feature
proposal:
>>>>>> Streamline visual flow design Date Thu, 10 Sep 2015 19:09:44 GMT
>>>>>>
>>>>>> So far there seems to be a couple in agreement to leave the add processor
>>>>>> behavior as is. My use of *inconsistency* was referring the simple
fact
>>>>>> that behavior is different. Add a processor - no dialog; draw a connection
>>>>>> - same type of dialog appears to take action. Perhaps we design a
more
>>>>>> intuitive way to quickly “configure” a connection when drawn.
It could be a
>>>>>> small in-place editor <http://ui-patterns.com/patterns/InplaceEditor>
that
>>>>>> appears when the connection is drawn allowing a quick, localized
>>>>>> configuration to take place.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message