You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Joe Witt <jo...@gmail.com> on 2017/05/01 01:23:29 UTC
Re: [DISCUSS] Component deprecation annotation
Agreed on both the icon being preferable as the vehicle to show this
for processors on the graph instead of color and also in emphasizing
this during processor selection.
Thanks
On Sun, Apr 30, 2017 at 7:21 PM, Matt Burgess <ma...@gmail.com> wrote:
> Visual indication on existing processors is a good thing, but IMO we'll definitely need indication on the processor selection dialog, so the user will know that we suggest they choose an alternative.
>
> Regards,
> Matt
>
>> On Apr 30, 2017, at 7:12 PM, Jeff <jt...@gmail.com> wrote:
>>
>> I think an icon on the processor would be best to denote an upcoming
>> deprecation. That leaves all colors available to the flow design, since
>> any color may have specific meaning to any current flow out there.
>>
>>> On Sat, Apr 29, 2017 at 3:58 PM Juan Sequeiros <he...@gmail.com> wrote:
>>>
>>> In same train of though maybe make it default to some color other than
>>> white, instinct says red but that might be used to represent an important
>>> processor. So suggest maybe default beige?
>>>
>>>
>>> On Sat, Apr 29, 2017 at 8:20 AM Andy LoPresto <al...@gmail.com>
>>> wrote:
>>>
>>>> I'd leave the graphics work/decisions to someone like Rob Moran, but I
>>> see
>>>> it as similar to the restricted components -- an icon on the processors
>>> on
>>>> the canvas and the dialog to add components, with additional explanation
>>>> (and maybe a target release for full deprecation) in the help notes.
>>>>
>>>> Andy LoPresto
>>>> alopresto@apache.org
>>>> alopresto.apache@gmail.com
>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>>>
>>>>> On Apr 29, 2017, at 05:16, Andre <an...@fucs.org> wrote:
>>>>>
>>>>> dev,
>>>>>
>>>>> In light of the some recent deprecations (ListenLumberjack) and some
>>>>> potential deprecation (PutJMS/GetJMS) I started some progress on how to
>>>>> document the depreciation of NiFi components using annotations.
>>>>>
>>>>> In the absence of any better name I called the annotation
>>>>> @DeprecationWarning (so not overlap with Java's @Deprecated)
>>>>>
>>>>> The suggested modifications are part of PR#1718 and I am keen to hear
>>>> your
>>>>> thoughts.
>>>>>
>>>>> While the documentation can be displayed as part of the usage, however
>>> I
>>>>> would imagine the frequency a user browses to the usage pages will
>>> reduce
>>>>> as her/him becomes familiar with the components.
>>>>>
>>>>> In light of this it may be a good idea to use the web UI to highlight
>>> a
>>>>> processor has been deprecated.
>>>>>
>>>>> Would anyone suggest a way of doing so without disrupting the user
>>>>> experience?
>>>>>
>>>>> Cheers
>>>>
>>>
Re: [DISCUSS] Component deprecation annotation
Posted by Joseph Niemiec <jo...@gmail.com>.
It would be really nice if this could be part of a summary or bulletin list
that an Admin/Ops could check frequently to find out if any of the tenants
on the NiFi service are using deprecated processors//controllers.
On Mon, May 1, 2017 at 8:24 AM, Rob Moran <rm...@gmail.com> wrote:
> I agree on treating these as we do restricted ones. I will work on some
> recommendations for a unique icon that the chooser dialog can display as
> well as how to best carry that over onto the canvas component.
>
> It would also be nice to suggest the alternative in the UI, for example
> when the user hovers the deprecated icon in the Add Processor dialog,
> specifically call out the alternative(s) by name.
>
> Rob
>
> On Apr 30, 2017 10:05 PM, "Andre" <an...@fucs.org> wrote:
>
> All,
>
> Thank you for the feedback.
>
> I will extend the PR so that the required endpoints are in place but will
> leave the effective UI design to our UX experts.
>
> Hopefully I should be able to use the @Restricted as a basis for this work.
> Otherwise I will shout for some guidance.
>
> Cheers
>
>
> On Mon, May 1, 2017 at 11:23 AM, Joe Witt <jo...@gmail.com> wrote:
>
> > Agreed on both the icon being preferable as the vehicle to show this
> > for processors on the graph instead of color and also in emphasizing
> > this during processor selection.
> >
> > Thanks
> >
> > On Sun, Apr 30, 2017 at 7:21 PM, Matt Burgess <ma...@gmail.com>
> wrote:
> > > Visual indication on existing processors is a good thing, but IMO we'll
> > definitely need indication on the processor selection dialog, so the user
> > will know that we suggest they choose an alternative.
> > >
> > > Regards,
> > > Matt
> > >
> > >> On Apr 30, 2017, at 7:12 PM, Jeff <jt...@gmail.com> wrote:
> > >>
> > >> I think an icon on the processor would be best to denote an upcoming
> > >> deprecation. That leaves all colors available to the flow design,
> since
> > >> any color may have specific meaning to any current flow out there.
> > >>
> > >>> On Sat, Apr 29, 2017 at 3:58 PM Juan Sequeiros <he...@gmail.com>
> > wrote:
> > >>>
> > >>> In same train of though maybe make it default to some color other
> than
> > >>> white, instinct says red but that might be used to represent an
> > important
> > >>> processor. So suggest maybe default beige?
> > >>>
> > >>>
> > >>> On Sat, Apr 29, 2017 at 8:20 AM Andy LoPresto <
> > alopresto.apache@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> I'd leave the graphics work/decisions to someone like Rob Moran, but
> I
> > >>> see
> > >>>> it as similar to the restricted components -- an icon on the
> > processors
> > >>> on
> > >>>> the canvas and the dialog to add components, with additional
> > explanation
> > >>>> (and maybe a target release for full deprecation) in the help notes.
> > >>>>
> > >>>> Andy LoPresto
> > >>>> alopresto@apache.org
> > >>>> alopresto.apache@gmail.com
> > >>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> > >>>>
> > >>>>> On Apr 29, 2017, at 05:16, Andre <an...@fucs.org> wrote:
> > >>>>>
> > >>>>> dev,
> > >>>>>
> > >>>>> In light of the some recent deprecations (ListenLumberjack) and
> some
> > >>>>> potential deprecation (PutJMS/GetJMS) I started some progress on
> how
> > to
> > >>>>> document the depreciation of NiFi components using annotations.
> > >>>>>
> > >>>>> In the absence of any better name I called the annotation
> > >>>>> @DeprecationWarning (so not overlap with Java's @Deprecated)
> > >>>>>
> > >>>>> The suggested modifications are part of PR#1718 and I am keen to
> hear
> > >>>> your
> > >>>>> thoughts.
> > >>>>>
> > >>>>> While the documentation can be displayed as part of the usage,
> > however
> > >>> I
> > >>>>> would imagine the frequency a user browses to the usage pages will
> > >>> reduce
> > >>>>> as her/him becomes familiar with the components.
> > >>>>>
> > >>>>> In light of this it may be a good idea to use the web UI to
> > highlight
> > >>> a
> > >>>>> processor has been deprecated.
> > >>>>>
> > >>>>> Would anyone suggest a way of doing so without disrupting the user
> > >>>>> experience?
> > >>>>>
> > >>>>> Cheers
> > >>>>
> > >>>
> >
>
--
Joseph
Re: [DISCUSS] Component deprecation annotation
Posted by Rob Moran <rm...@gmail.com>.
I agree on treating these as we do restricted ones. I will work on some
recommendations for a unique icon that the chooser dialog can display as
well as how to best carry that over onto the canvas component.
It would also be nice to suggest the alternative in the UI, for example
when the user hovers the deprecated icon in the Add Processor dialog,
specifically call out the alternative(s) by name.
Rob
On Apr 30, 2017 10:05 PM, "Andre" <an...@fucs.org> wrote:
All,
Thank you for the feedback.
I will extend the PR so that the required endpoints are in place but will
leave the effective UI design to our UX experts.
Hopefully I should be able to use the @Restricted as a basis for this work.
Otherwise I will shout for some guidance.
Cheers
On Mon, May 1, 2017 at 11:23 AM, Joe Witt <jo...@gmail.com> wrote:
> Agreed on both the icon being preferable as the vehicle to show this
> for processors on the graph instead of color and also in emphasizing
> this during processor selection.
>
> Thanks
>
> On Sun, Apr 30, 2017 at 7:21 PM, Matt Burgess <ma...@gmail.com> wrote:
> > Visual indication on existing processors is a good thing, but IMO we'll
> definitely need indication on the processor selection dialog, so the user
> will know that we suggest they choose an alternative.
> >
> > Regards,
> > Matt
> >
> >> On Apr 30, 2017, at 7:12 PM, Jeff <jt...@gmail.com> wrote:
> >>
> >> I think an icon on the processor would be best to denote an upcoming
> >> deprecation. That leaves all colors available to the flow design,
since
> >> any color may have specific meaning to any current flow out there.
> >>
> >>> On Sat, Apr 29, 2017 at 3:58 PM Juan Sequeiros <he...@gmail.com>
> wrote:
> >>>
> >>> In same train of though maybe make it default to some color other than
> >>> white, instinct says red but that might be used to represent an
> important
> >>> processor. So suggest maybe default beige?
> >>>
> >>>
> >>> On Sat, Apr 29, 2017 at 8:20 AM Andy LoPresto <
> alopresto.apache@gmail.com>
> >>> wrote:
> >>>
> >>>> I'd leave the graphics work/decisions to someone like Rob Moran, but
I
> >>> see
> >>>> it as similar to the restricted components -- an icon on the
> processors
> >>> on
> >>>> the canvas and the dialog to add components, with additional
> explanation
> >>>> (and maybe a target release for full deprecation) in the help notes.
> >>>>
> >>>> Andy LoPresto
> >>>> alopresto@apache.org
> >>>> alopresto.apache@gmail.com
> >>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >>>>
> >>>>> On Apr 29, 2017, at 05:16, Andre <an...@fucs.org> wrote:
> >>>>>
> >>>>> dev,
> >>>>>
> >>>>> In light of the some recent deprecations (ListenLumberjack) and some
> >>>>> potential deprecation (PutJMS/GetJMS) I started some progress on how
> to
> >>>>> document the depreciation of NiFi components using annotations.
> >>>>>
> >>>>> In the absence of any better name I called the annotation
> >>>>> @DeprecationWarning (so not overlap with Java's @Deprecated)
> >>>>>
> >>>>> The suggested modifications are part of PR#1718 and I am keen to
hear
> >>>> your
> >>>>> thoughts.
> >>>>>
> >>>>> While the documentation can be displayed as part of the usage,
> however
> >>> I
> >>>>> would imagine the frequency a user browses to the usage pages will
> >>> reduce
> >>>>> as her/him becomes familiar with the components.
> >>>>>
> >>>>> In light of this it may be a good idea to use the web UI to
> highlight
> >>> a
> >>>>> processor has been deprecated.
> >>>>>
> >>>>> Would anyone suggest a way of doing so without disrupting the user
> >>>>> experience?
> >>>>>
> >>>>> Cheers
> >>>>
> >>>
>
Re: [DISCUSS] Component deprecation annotation
Posted by Andre <an...@fucs.org>.
All,
Thank you for the feedback.
I will extend the PR so that the required endpoints are in place but will
leave the effective UI design to our UX experts.
Hopefully I should be able to use the @Restricted as a basis for this work.
Otherwise I will shout for some guidance.
Cheers
On Mon, May 1, 2017 at 11:23 AM, Joe Witt <jo...@gmail.com> wrote:
> Agreed on both the icon being preferable as the vehicle to show this
> for processors on the graph instead of color and also in emphasizing
> this during processor selection.
>
> Thanks
>
> On Sun, Apr 30, 2017 at 7:21 PM, Matt Burgess <ma...@gmail.com> wrote:
> > Visual indication on existing processors is a good thing, but IMO we'll
> definitely need indication on the processor selection dialog, so the user
> will know that we suggest they choose an alternative.
> >
> > Regards,
> > Matt
> >
> >> On Apr 30, 2017, at 7:12 PM, Jeff <jt...@gmail.com> wrote:
> >>
> >> I think an icon on the processor would be best to denote an upcoming
> >> deprecation. That leaves all colors available to the flow design, since
> >> any color may have specific meaning to any current flow out there.
> >>
> >>> On Sat, Apr 29, 2017 at 3:58 PM Juan Sequeiros <he...@gmail.com>
> wrote:
> >>>
> >>> In same train of though maybe make it default to some color other than
> >>> white, instinct says red but that might be used to represent an
> important
> >>> processor. So suggest maybe default beige?
> >>>
> >>>
> >>> On Sat, Apr 29, 2017 at 8:20 AM Andy LoPresto <
> alopresto.apache@gmail.com>
> >>> wrote:
> >>>
> >>>> I'd leave the graphics work/decisions to someone like Rob Moran, but I
> >>> see
> >>>> it as similar to the restricted components -- an icon on the
> processors
> >>> on
> >>>> the canvas and the dialog to add components, with additional
> explanation
> >>>> (and maybe a target release for full deprecation) in the help notes.
> >>>>
> >>>> Andy LoPresto
> >>>> alopresto@apache.org
> >>>> alopresto.apache@gmail.com
> >>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >>>>
> >>>>> On Apr 29, 2017, at 05:16, Andre <an...@fucs.org> wrote:
> >>>>>
> >>>>> dev,
> >>>>>
> >>>>> In light of the some recent deprecations (ListenLumberjack) and some
> >>>>> potential deprecation (PutJMS/GetJMS) I started some progress on how
> to
> >>>>> document the depreciation of NiFi components using annotations.
> >>>>>
> >>>>> In the absence of any better name I called the annotation
> >>>>> @DeprecationWarning (so not overlap with Java's @Deprecated)
> >>>>>
> >>>>> The suggested modifications are part of PR#1718 and I am keen to hear
> >>>> your
> >>>>> thoughts.
> >>>>>
> >>>>> While the documentation can be displayed as part of the usage,
> however
> >>> I
> >>>>> would imagine the frequency a user browses to the usage pages will
> >>> reduce
> >>>>> as her/him becomes familiar with the components.
> >>>>>
> >>>>> In light of this it may be a good idea to use the web UI to
> highlight
> >>> a
> >>>>> processor has been deprecated.
> >>>>>
> >>>>> Would anyone suggest a way of doing so without disrupting the user
> >>>>> experience?
> >>>>>
> >>>>> Cheers
> >>>>
> >>>
>