You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Scott Aslan <sc...@gmail.com> on 2018/03/01 15:07:47 UTC
Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid
Design System
Hello MikeM/everyone,
One of the questions brought up in this discussion was centered around what
a design system is. I stumbled upon a really great article this morning on
this exact topic. It also links to several other really great articles and
will help us all to understand.
https://uxplanet.org/design-systems-in-2016-5415a660b29
Also, I was thinking about the name.... what does everyone think about
naming this sub-project NiFi Design System?
-Scotty
On Fri, Feb 23, 2018 at 10:20 AM, Scott Aslan <sc...@gmail.com> wrote:
> TonyK,
>
> The intent is to use this this NgModule in NiFi Registry and eventually
> NiFi. However, this would be released under ASLv2 so yes other projects
> could use it.
>
> On Thu, Feb 22, 2018 at 10:46 PM, Tony Kurc <tk...@apache.org> wrote:
>
>> Is some of the thinking that projects other than nifi projects would use
>> this?
>>
>> On Feb 22, 2018 10:00 PM, "Scott Aslan" <sc...@gmail.com> wrote:
>>
>> > Sivaprasanna,
>> >
>> > I am not sure I follow exactly what you are saying...
>> >
>> > NiFi Registry would no longer continue to host a copy of the FDS
>> NgModule.
>> > Instead, NiFi Registry would just add the NiFi FDS sub-project as a
>> client
>> > side dependency in its package.json. This would be analogous to how NiFi
>> > Registry depends on Angular Material, etc. npm supports the ability to
>> > download published packages which are current with the latest stable
>> > release of a package. npm *also* supports the ability to develop off
>> > of the *master
>> > branch (or any other branch really)* of the NiFi FDS. An example of this
>> > can be found in the github.io demo here
>> > <https://github.com/scottyaslan/fluid-design-system/blob/gh-
>> pages/package.
>> > json#L45>
>> > . By placing that dependency in the package.json for the NiFi Registry
>> each
>> > subsequent clean build would automatically download the latest master
>> > branch of the NiFi FDS sub-project and developers can leverages the
>> latest
>> > NiFi FDS components.
>> >
>> > This also brings up a good point about release management. I have also
>> > included a prototype of one possible implementation of automating the
>> > tagging of a branch and automatically updating release version numbers
>> etc.
>> > leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with
>> the
>> > described grunt task.
>> >
>> > [1]
>> > https://github.com/scottyaslan/fluid-design-system/blob/
>> master/Gruntfile.
>> > js#L47
>> >
>> > [2] https://github.com/scottyaslan/fluid-design-system/tree/FDS-
>> 0.0.1-RC.0
>> >
>> > On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna <
>> sivaprasanna246@gmail.com>
>> > wrote:
>> >
>> > > I agree with Matt. With clear documentation and guides, contributions
>> on
>> > > the sub-projects can be streamlined and be ensured that the necessary
>> > > changes are already available on the core project i.e NiFi. One
>> challenge
>> > > is that the committer of the sub-project should have the courtesy to
>> > check
>> > > wether the supporting changes are made available to the core project
>> and
>> > > track its status but given how contributions are being handled in
>> > > nifi-registry project, I don’t think it’s going to be that much of a
>> > > headache.
>> > >
>> > > We could also add to the helper doc mentioning that if the
>> contribution
>> > is
>> > > going to affect a core component, the contributor needs to add the
>> JIRA
>> > id
>> > > of the core project’s supporting changes in the sub-projects’ issue
>> > > description.
>> > >
>> > > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman <matt.c.gilman@gmail.com
>> >
>> > > wrote:
>> > >
>> > > > Joe, Joe,
>> > > >
>> > > > Regarding the release process... I think it could be similar to how
>> > folks
>> > > > verified and validated the NiFi Registry release. Guidance was given
>> > in a
>> > > > helper guide regarding how to obtain/build a branch or PR that
>> > references
>> > > > the new components. For the Registry release, there was a PR for
>> NiFi
>> > > that
>> > > > had the supporting changes already available.
>> > > >
>> > > > We may have this issue any time we release new versions that depend
>> on
>> > > > another (sub)project.
>> > > >
>> > > > Matt
>> > > >
>> > > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall <
>> jpercivall@apache.org
>> > >
>> > > > wrote:
>> > > >
>> > > > > Scott,
>> > > > >
>> > > > > Definitely like the direction of standardizing NiFi and Registry
>> > around
>> > > > the
>> > > > > same set of components, so the user has a common UX. Is there
>> > precedent
>> > > > for
>> > > > > creating a new sub-project just for common components/modules to
>> be
>> > > used
>> > > > by
>> > > > > the top-level, and it's other sub-projects? My concerns are
>> similar
>> > to
>> > > > > Joe's. Along those lines, if the core problems we're trying to
>> > address
>> > > is
>> > > > > the release process and distribution, is there a less
>> "heavy-weight"
>> > > > > avenue?
>> > > > >
>> > > > > In the past, we've also talked about pulling out the core NiFi
>> > > framework
>> > > > to
>> > > > > be shared between NiFi and MiNiFi-Java for similar reasons. How
>> we go
>> > > > about
>> > > > > solving this for the UI could be used a model for the core
>> framework
>> > as
>> > > > > well.
>> > > > >
>> > > > > - Joe
>> > > > >
>> > > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <
>> > mikerthomsen@gmail.com
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > > > Also, what sort of framework is the UI being standardized on?
>> > > Angular?
>> > > > > > React? Something else?
>> > > > > >
>> > > > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <jo...@gmail.com>
>> > > wrote:
>> > > > > >
>> > > > > > > Scott
>> > > > > > >
>> > > > > > > Ok so extract out the fluid design work you started with NiFi
>> > > > Registry
>> > > > > > > to its own codebase which can be rev'd and published to NPM
>> > making
>> > > it
>> > > > > > > easier to consume/reuse across NiFi projects and offers better
>> > > > > > > consistency. This sounds interesting.
>> > > > > > >
>> > > > > > > In thinking through the additional community effort or the
>> effort
>> > > > > > > trade-off:
>> > > > > > > How often do you anticipate we'd be doing releases (and thus
>> > > > > > > validation/voting) for this?
>> > > > > > > How often would those differ from when we'd want to do a NiFi
>> or
>> > > NiFi
>> > > > > > > Registry release?
>> > > > > > > How do you envision the community would be able to help
>> > > vet/validate
>> > > > > > > releases of these modules?
>> > > > > > >
>> > > > > > > Thanks
>> > > > > > > Joe
>> > > > > > >
>> > > > > > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <
>> > > scottyaslan@gmail.com>
>> > > > > > > wrote:
>> > > > > > > > NiFi Community,
>> > > > > > > >
>> > > > > > > > I'd like to initiate a discussion around creating a
>> sub-project
>> > > of
>> > > > > NiFi
>> > > > > > > to
>> > > > > > > > encompass the Fluid Design System NgModule created during
>> the
>> > > > > > development
>> > > > > > > > of the NiFi Registry. A possible name for this sub-project
>> is
>> > > > simply
>> > > > > > > > "NiFi Fluid
>> > > > > > > > Design System". The idea would be to create a sub-project
>> that
>> > > > > > > distributes
>> > > > > > > > an atomic set of high quality, reuse-able, theme-able, and
>> > > testable
>> > > > > > UI/UX
>> > > > > > > > components, fonts, and other JS modules for use across the
>> > > various
>> > > > > web
>> > > > > > > > applications throughout the NiFi universe (uNiFiverse???).
>> Both
>> > > > NiFi
>> > > > > > and
>> > > > > > > > NiFi Registry web applications would eventually leverage
>> this
>> > > > module
>> > > > > > via
>> > > > > > > > npm. This approach will enable us to provide our users with
>> a
>> > > > > > consistent
>> > > > > > > > experience across web applications. Creating a sub-project
>> > would
>> > > > also
>> > > > > > > allow
>> > > > > > > > the FDS code to evolve independently of NiFi/NiFi registry
>> and
>> > be
>> > > > > > > released
>> > > > > > > > on it's own timeline. In addition, it would make tracking
>> > > > issues/work
>> > > > > > > much
>> > > > > > > > clearer through a separate JIRA.
>> > > > > > > >
>> > > > > > > > Please discuss and provide and thoughts or feedback.
>> > > > > > > >
>> > > > > > > > Thanks,
>> > > > > > > >
>> > > > > > > > Scotty
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > *Joe Percivall*
>> > > > > linkedin.com/in/Percivall
>> > > > > e: jpercivall@apache.com
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid
Design System
Posted by Scott Aslan <sc...@gmail.com>.
Sivaprasanna,
I don't think we want to use color to describe this sub project since the
theme (colors) of the UX components will be configurable.
Kevin/MattG,
"Fluid" made sense to me for its tie to NiFi terminology. Also, the
components are meant to be responsive in order to support different screen
sizes and the theme of the components are configurable (fluid) as well. As
far as including the "Design System" in the title I do think this is a
helpful description for UI/UX developers/designers.
If no one has any other questions then I will go ahead and kick off a
vote...
-Scotty
On Thu, Mar 1, 2018 at 2:14 PM, Kevin Doran <kd...@apache.org> wrote:
> I like NiFi Design System. A bit "boring" perhaps, but probably the most
> self-descriptive project name for newcomers.
>
> I like Fluid Design System as well if the intent is to be more generic,
> indicating that it is not intended just for NiFi projects but can be
> utilized anywhere (but "fluid" has a tie in to NiFi terminology as well).
>
> Thanks for the links to other examples - that was helpful as I don't have
> much background / knowledge in modern UX development.
>
> Kevin
>
> On 3/1/18, 10:08, "Scott Aslan" <sc...@gmail.com> wrote:
>
> Hello MikeM/everyone,
>
> One of the questions brought up in this discussion was centered around
> what
> a design system is. I stumbled upon a really great article this
> morning on
> this exact topic. It also links to several other really great articles
> and
> will help us all to understand.
> https://uxplanet.org/design-systems-in-2016-5415a660b29
>
> Also, I was thinking about the name.... what does everyone think about
> naming this sub-project NiFi Design System?
>
> -Scotty
>
> On Fri, Feb 23, 2018 at 10:20 AM, Scott Aslan <sc...@gmail.com>
> wrote:
>
> > TonyK,
> >
> > The intent is to use this this NgModule in NiFi Registry and
> eventually
> > NiFi. However, this would be released under ASLv2 so yes other
> projects
> > could use it.
> >
> > On Thu, Feb 22, 2018 at 10:46 PM, Tony Kurc <tk...@apache.org>
> wrote:
> >
> >> Is some of the thinking that projects other than nifi projects
> would use
> >> this?
> >>
> >> On Feb 22, 2018 10:00 PM, "Scott Aslan" <sc...@gmail.com>
> wrote:
> >>
> >> > Sivaprasanna,
> >> >
> >> > I am not sure I follow exactly what you are saying...
> >> >
> >> > NiFi Registry would no longer continue to host a copy of the FDS
> >> NgModule.
> >> > Instead, NiFi Registry would just add the NiFi FDS sub-project as
> a
> >> client
> >> > side dependency in its package.json. This would be analogous to
> how NiFi
> >> > Registry depends on Angular Material, etc. npm supports the
> ability to
> >> > download published packages which are current with the latest
> stable
> >> > release of a package. npm *also* supports the ability to develop
> off
> >> > of the *master
> >> > branch (or any other branch really)* of the NiFi FDS. An example
> of this
> >> > can be found in the github.io demo here
> >> > <https://github.com/scottyaslan/fluid-design-system/blob/gh-
> >> pages/package.
> >> > json#L45>
> >> > . By placing that dependency in the package.json for the NiFi
> Registry
> >> each
> >> > subsequent clean build would automatically download the latest
> master
> >> > branch of the NiFi FDS sub-project and developers can leverages
> the
> >> latest
> >> > NiFi FDS components.
> >> >
> >> > This also brings up a good point about release management. I have
> also
> >> > included a prototype of one possible implementation of automating
> the
> >> > tagging of a branch and automatically updating release version
> numbers
> >> etc.
> >> > leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created
> with
> >> the
> >> > described grunt task.
> >> >
> >> > [1]
> >> > https://github.com/scottyaslan/fluid-design-system/blob/
> >> master/Gruntfile.
> >> > js#L47
> >> >
> >> > [2] https://github.com/scottyaslan/fluid-design-system/tree/FDS-
> >> 0.0.1-RC.0
> >> >
> >> > On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna <
> >> sivaprasanna246@gmail.com>
> >> > wrote:
> >> >
> >> > > I agree with Matt. With clear documentation and guides,
> contributions
> >> on
> >> > > the sub-projects can be streamlined and be ensured that the
> necessary
> >> > > changes are already available on the core project i.e NiFi. One
> >> challenge
> >> > > is that the committer of the sub-project should have the
> courtesy to
> >> > check
> >> > > wether the supporting changes are made available to the core
> project
> >> and
> >> > > track its status but given how contributions are being handled
> in
> >> > > nifi-registry project, I don’t think it’s going to be that much
> of a
> >> > > headache.
> >> > >
> >> > > We could also add to the helper doc mentioning that if the
> >> contribution
> >> > is
> >> > > going to affect a core component, the contributor needs to add
> the
> >> JIRA
> >> > id
> >> > > of the core project’s supporting changes in the sub-projects’
> issue
> >> > > description.
> >> > >
> >> > > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman <
> matt.c.gilman@gmail.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > Joe, Joe,
> >> > > >
> >> > > > Regarding the release process... I think it could be similar
> to how
> >> > folks
> >> > > > verified and validated the NiFi Registry release. Guidance
> was given
> >> > in a
> >> > > > helper guide regarding how to obtain/build a branch or PR that
> >> > references
> >> > > > the new components. For the Registry release, there was a PR
> for
> >> NiFi
> >> > > that
> >> > > > had the supporting changes already available.
> >> > > >
> >> > > > We may have this issue any time we release new versions that
> depend
> >> on
> >> > > > another (sub)project.
> >> > > >
> >> > > > Matt
> >> > > >
> >> > > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall <
> >> jpercivall@apache.org
> >> > >
> >> > > > wrote:
> >> > > >
> >> > > > > Scott,
> >> > > > >
> >> > > > > Definitely like the direction of standardizing NiFi and
> Registry
> >> > around
> >> > > > the
> >> > > > > same set of components, so the user has a common UX. Is
> there
> >> > precedent
> >> > > > for
> >> > > > > creating a new sub-project just for common
> components/modules to
> >> be
> >> > > used
> >> > > > by
> >> > > > > the top-level, and it's other sub-projects? My concerns are
> >> similar
> >> > to
> >> > > > > Joe's. Along those lines, if the core problems we're trying
> to
> >> > address
> >> > > is
> >> > > > > the release process and distribution, is there a less
> >> "heavy-weight"
> >> > > > > avenue?
> >> > > > >
> >> > > > > In the past, we've also talked about pulling out the core
> NiFi
> >> > > framework
> >> > > > to
> >> > > > > be shared between NiFi and MiNiFi-Java for similar reasons.
> How
> >> we go
> >> > > > about
> >> > > > > solving this for the UI could be used a model for the core
> >> framework
> >> > as
> >> > > > > well.
> >> > > > >
> >> > > > > - Joe
> >> > > > >
> >> > > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <
> >> > mikerthomsen@gmail.com
> >> > > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Also, what sort of framework is the UI being standardized
> on?
> >> > > Angular?
> >> > > > > > React? Something else?
> >> > > > > >
> >> > > > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <
> joe.witt@gmail.com>
> >> > > wrote:
> >> > > > > >
> >> > > > > > > Scott
> >> > > > > > >
> >> > > > > > > Ok so extract out the fluid design work you started
> with NiFi
> >> > > > Registry
> >> > > > > > > to its own codebase which can be rev'd and published to
> NPM
> >> > making
> >> > > it
> >> > > > > > > easier to consume/reuse across NiFi projects and offers
> better
> >> > > > > > > consistency. This sounds interesting.
> >> > > > > > >
> >> > > > > > > In thinking through the additional community effort or
> the
> >> effort
> >> > > > > > > trade-off:
> >> > > > > > > How often do you anticipate we'd be doing releases (and
> thus
> >> > > > > > > validation/voting) for this?
> >> > > > > > > How often would those differ from when we'd want to do
> a NiFi
> >> or
> >> > > NiFi
> >> > > > > > > Registry release?
> >> > > > > > > How do you envision the community would be able to help
> >> > > vet/validate
> >> > > > > > > releases of these modules?
> >> > > > > > >
> >> > > > > > > Thanks
> >> > > > > > > Joe
> >> > > > > > >
> >> > > > > > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <
> >> > > scottyaslan@gmail.com>
> >> > > > > > > wrote:
> >> > > > > > > > NiFi Community,
> >> > > > > > > >
> >> > > > > > > > I'd like to initiate a discussion around creating a
> >> sub-project
> >> > > of
> >> > > > > NiFi
> >> > > > > > > to
> >> > > > > > > > encompass the Fluid Design System NgModule created
> during
> >> the
> >> > > > > > development
> >> > > > > > > > of the NiFi Registry. A possible name for this
> sub-project
> >> is
> >> > > > simply
> >> > > > > > > > "NiFi Fluid
> >> > > > > > > > Design System". The idea would be to create a
> sub-project
> >> that
> >> > > > > > > distributes
> >> > > > > > > > an atomic set of high quality, reuse-able,
> theme-able, and
> >> > > testable
> >> > > > > > UI/UX
> >> > > > > > > > components, fonts, and other JS modules for use
> across the
> >> > > various
> >> > > > > web
> >> > > > > > > > applications throughout the NiFi universe
> (uNiFiverse???).
> >> Both
> >> > > > NiFi
> >> > > > > > and
> >> > > > > > > > NiFi Registry web applications would eventually
> leverage
> >> this
> >> > > > module
> >> > > > > > via
> >> > > > > > > > npm. This approach will enable us to provide our
> users with
> >> a
> >> > > > > > consistent
> >> > > > > > > > experience across web applications. Creating a
> sub-project
> >> > would
> >> > > > also
> >> > > > > > > allow
> >> > > > > > > > the FDS code to evolve independently of NiFi/NiFi
> registry
> >> and
> >> > be
> >> > > > > > > released
> >> > > > > > > > on it's own timeline. In addition, it would make
> tracking
> >> > > > issues/work
> >> > > > > > > much
> >> > > > > > > > clearer through a separate JIRA.
> >> > > > > > > >
> >> > > > > > > > Please discuss and provide and thoughts or feedback.
> >> > > > > > > >
> >> > > > > > > > Thanks,
> >> > > > > > > >
> >> > > > > > > > Scotty
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > *Joe Percivall*
> >> > > > > linkedin.com/in/Percivall
> >> > > > > e: jpercivall@apache.com
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
>
>
>
Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid
Design System
Posted by Matt Gilman <ma...@gmail.com>.
I would agree with Kevin. I like both NiFi Design System and Fluid Design
System. My only hesitation on the latter would be the similarity to the
Microsoft Fluent Design System. Anyways, happy to see this progress and
look forward to when we can incorporate it into the NiFi UI.
Matt
On Thu, Mar 1, 2018 at 2:14 PM, Kevin Doran <kd...@apache.org> wrote:
> I like NiFi Design System. A bit "boring" perhaps, but probably the most
> self-descriptive project name for newcomers.
>
> I like Fluid Design System as well if the intent is to be more generic,
> indicating that it is not intended just for NiFi projects but can be
> utilized anywhere (but "fluid" has a tie in to NiFi terminology as well).
>
> Thanks for the links to other examples - that was helpful as I don't have
> much background / knowledge in modern UX development.
>
> Kevin
>
> On 3/1/18, 10:08, "Scott Aslan" <sc...@gmail.com> wrote:
>
> Hello MikeM/everyone,
>
> One of the questions brought up in this discussion was centered around
> what
> a design system is. I stumbled upon a really great article this
> morning on
> this exact topic. It also links to several other really great articles
> and
> will help us all to understand.
> https://uxplanet.org/design-systems-in-2016-5415a660b29
>
> Also, I was thinking about the name.... what does everyone think about
> naming this sub-project NiFi Design System?
>
> -Scotty
>
> On Fri, Feb 23, 2018 at 10:20 AM, Scott Aslan <sc...@gmail.com>
> wrote:
>
> > TonyK,
> >
> > The intent is to use this this NgModule in NiFi Registry and
> eventually
> > NiFi. However, this would be released under ASLv2 so yes other
> projects
> > could use it.
> >
> > On Thu, Feb 22, 2018 at 10:46 PM, Tony Kurc <tk...@apache.org>
> wrote:
> >
> >> Is some of the thinking that projects other than nifi projects
> would use
> >> this?
> >>
> >> On Feb 22, 2018 10:00 PM, "Scott Aslan" <sc...@gmail.com>
> wrote:
> >>
> >> > Sivaprasanna,
> >> >
> >> > I am not sure I follow exactly what you are saying...
> >> >
> >> > NiFi Registry would no longer continue to host a copy of the FDS
> >> NgModule.
> >> > Instead, NiFi Registry would just add the NiFi FDS sub-project as
> a
> >> client
> >> > side dependency in its package.json. This would be analogous to
> how NiFi
> >> > Registry depends on Angular Material, etc. npm supports the
> ability to
> >> > download published packages which are current with the latest
> stable
> >> > release of a package. npm *also* supports the ability to develop
> off
> >> > of the *master
> >> > branch (or any other branch really)* of the NiFi FDS. An example
> of this
> >> > can be found in the github.io demo here
> >> > <https://github.com/scottyaslan/fluid-design-system/blob/gh-
> >> pages/package.
> >> > json#L45>
> >> > . By placing that dependency in the package.json for the NiFi
> Registry
> >> each
> >> > subsequent clean build would automatically download the latest
> master
> >> > branch of the NiFi FDS sub-project and developers can leverages
> the
> >> latest
> >> > NiFi FDS components.
> >> >
> >> > This also brings up a good point about release management. I have
> also
> >> > included a prototype of one possible implementation of automating
> the
> >> > tagging of a branch and automatically updating release version
> numbers
> >> etc.
> >> > leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created
> with
> >> the
> >> > described grunt task.
> >> >
> >> > [1]
> >> > https://github.com/scottyaslan/fluid-design-system/blob/
> >> master/Gruntfile.
> >> > js#L47
> >> >
> >> > [2] https://github.com/scottyaslan/fluid-design-system/tree/FDS-
> >> 0.0.1-RC.0
> >> >
> >> > On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna <
> >> sivaprasanna246@gmail.com>
> >> > wrote:
> >> >
> >> > > I agree with Matt. With clear documentation and guides,
> contributions
> >> on
> >> > > the sub-projects can be streamlined and be ensured that the
> necessary
> >> > > changes are already available on the core project i.e NiFi. One
> >> challenge
> >> > > is that the committer of the sub-project should have the
> courtesy to
> >> > check
> >> > > wether the supporting changes are made available to the core
> project
> >> and
> >> > > track its status but given how contributions are being handled
> in
> >> > > nifi-registry project, I don’t think it’s going to be that much
> of a
> >> > > headache.
> >> > >
> >> > > We could also add to the helper doc mentioning that if the
> >> contribution
> >> > is
> >> > > going to affect a core component, the contributor needs to add
> the
> >> JIRA
> >> > id
> >> > > of the core project’s supporting changes in the sub-projects’
> issue
> >> > > description.
> >> > >
> >> > > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman <
> matt.c.gilman@gmail.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > Joe, Joe,
> >> > > >
> >> > > > Regarding the release process... I think it could be similar
> to how
> >> > folks
> >> > > > verified and validated the NiFi Registry release. Guidance
> was given
> >> > in a
> >> > > > helper guide regarding how to obtain/build a branch or PR that
> >> > references
> >> > > > the new components. For the Registry release, there was a PR
> for
> >> NiFi
> >> > > that
> >> > > > had the supporting changes already available.
> >> > > >
> >> > > > We may have this issue any time we release new versions that
> depend
> >> on
> >> > > > another (sub)project.
> >> > > >
> >> > > > Matt
> >> > > >
> >> > > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall <
> >> jpercivall@apache.org
> >> > >
> >> > > > wrote:
> >> > > >
> >> > > > > Scott,
> >> > > > >
> >> > > > > Definitely like the direction of standardizing NiFi and
> Registry
> >> > around
> >> > > > the
> >> > > > > same set of components, so the user has a common UX. Is
> there
> >> > precedent
> >> > > > for
> >> > > > > creating a new sub-project just for common
> components/modules to
> >> be
> >> > > used
> >> > > > by
> >> > > > > the top-level, and it's other sub-projects? My concerns are
> >> similar
> >> > to
> >> > > > > Joe's. Along those lines, if the core problems we're trying
> to
> >> > address
> >> > > is
> >> > > > > the release process and distribution, is there a less
> >> "heavy-weight"
> >> > > > > avenue?
> >> > > > >
> >> > > > > In the past, we've also talked about pulling out the core
> NiFi
> >> > > framework
> >> > > > to
> >> > > > > be shared between NiFi and MiNiFi-Java for similar reasons.
> How
> >> we go
> >> > > > about
> >> > > > > solving this for the UI could be used a model for the core
> >> framework
> >> > as
> >> > > > > well.
> >> > > > >
> >> > > > > - Joe
> >> > > > >
> >> > > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <
> >> > mikerthomsen@gmail.com
> >> > > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Also, what sort of framework is the UI being standardized
> on?
> >> > > Angular?
> >> > > > > > React? Something else?
> >> > > > > >
> >> > > > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <
> joe.witt@gmail.com>
> >> > > wrote:
> >> > > > > >
> >> > > > > > > Scott
> >> > > > > > >
> >> > > > > > > Ok so extract out the fluid design work you started
> with NiFi
> >> > > > Registry
> >> > > > > > > to its own codebase which can be rev'd and published to
> NPM
> >> > making
> >> > > it
> >> > > > > > > easier to consume/reuse across NiFi projects and offers
> better
> >> > > > > > > consistency. This sounds interesting.
> >> > > > > > >
> >> > > > > > > In thinking through the additional community effort or
> the
> >> effort
> >> > > > > > > trade-off:
> >> > > > > > > How often do you anticipate we'd be doing releases (and
> thus
> >> > > > > > > validation/voting) for this?
> >> > > > > > > How often would those differ from when we'd want to do
> a NiFi
> >> or
> >> > > NiFi
> >> > > > > > > Registry release?
> >> > > > > > > How do you envision the community would be able to help
> >> > > vet/validate
> >> > > > > > > releases of these modules?
> >> > > > > > >
> >> > > > > > > Thanks
> >> > > > > > > Joe
> >> > > > > > >
> >> > > > > > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <
> >> > > scottyaslan@gmail.com>
> >> > > > > > > wrote:
> >> > > > > > > > NiFi Community,
> >> > > > > > > >
> >> > > > > > > > I'd like to initiate a discussion around creating a
> >> sub-project
> >> > > of
> >> > > > > NiFi
> >> > > > > > > to
> >> > > > > > > > encompass the Fluid Design System NgModule created
> during
> >> the
> >> > > > > > development
> >> > > > > > > > of the NiFi Registry. A possible name for this
> sub-project
> >> is
> >> > > > simply
> >> > > > > > > > "NiFi Fluid
> >> > > > > > > > Design System". The idea would be to create a
> sub-project
> >> that
> >> > > > > > > distributes
> >> > > > > > > > an atomic set of high quality, reuse-able,
> theme-able, and
> >> > > testable
> >> > > > > > UI/UX
> >> > > > > > > > components, fonts, and other JS modules for use
> across the
> >> > > various
> >> > > > > web
> >> > > > > > > > applications throughout the NiFi universe
> (uNiFiverse???).
> >> Both
> >> > > > NiFi
> >> > > > > > and
> >> > > > > > > > NiFi Registry web applications would eventually
> leverage
> >> this
> >> > > > module
> >> > > > > > via
> >> > > > > > > > npm. This approach will enable us to provide our
> users with
> >> a
> >> > > > > > consistent
> >> > > > > > > > experience across web applications. Creating a
> sub-project
> >> > would
> >> > > > also
> >> > > > > > > allow
> >> > > > > > > > the FDS code to evolve independently of NiFi/NiFi
> registry
> >> and
> >> > be
> >> > > > > > > released
> >> > > > > > > > on it's own timeline. In addition, it would make
> tracking
> >> > > > issues/work
> >> > > > > > > much
> >> > > > > > > > clearer through a separate JIRA.
> >> > > > > > > >
> >> > > > > > > > Please discuss and provide and thoughts or feedback.
> >> > > > > > > >
> >> > > > > > > > Thanks,
> >> > > > > > > >
> >> > > > > > > > Scotty
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > *Joe Percivall*
> >> > > > > linkedin.com/in/Percivall
> >> > > > > e: jpercivall@apache.com
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
>
>
>
Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid
Design System
Posted by Kevin Doran <kd...@apache.org>.
I like NiFi Design System. A bit "boring" perhaps, but probably the most self-descriptive project name for newcomers.
I like Fluid Design System as well if the intent is to be more generic, indicating that it is not intended just for NiFi projects but can be utilized anywhere (but "fluid" has a tie in to NiFi terminology as well).
Thanks for the links to other examples - that was helpful as I don't have much background / knowledge in modern UX development.
Kevin
On 3/1/18, 10:08, "Scott Aslan" <sc...@gmail.com> wrote:
Hello MikeM/everyone,
One of the questions brought up in this discussion was centered around what
a design system is. I stumbled upon a really great article this morning on
this exact topic. It also links to several other really great articles and
will help us all to understand.
https://uxplanet.org/design-systems-in-2016-5415a660b29
Also, I was thinking about the name.... what does everyone think about
naming this sub-project NiFi Design System?
-Scotty
On Fri, Feb 23, 2018 at 10:20 AM, Scott Aslan <sc...@gmail.com> wrote:
> TonyK,
>
> The intent is to use this this NgModule in NiFi Registry and eventually
> NiFi. However, this would be released under ASLv2 so yes other projects
> could use it.
>
> On Thu, Feb 22, 2018 at 10:46 PM, Tony Kurc <tk...@apache.org> wrote:
>
>> Is some of the thinking that projects other than nifi projects would use
>> this?
>>
>> On Feb 22, 2018 10:00 PM, "Scott Aslan" <sc...@gmail.com> wrote:
>>
>> > Sivaprasanna,
>> >
>> > I am not sure I follow exactly what you are saying...
>> >
>> > NiFi Registry would no longer continue to host a copy of the FDS
>> NgModule.
>> > Instead, NiFi Registry would just add the NiFi FDS sub-project as a
>> client
>> > side dependency in its package.json. This would be analogous to how NiFi
>> > Registry depends on Angular Material, etc. npm supports the ability to
>> > download published packages which are current with the latest stable
>> > release of a package. npm *also* supports the ability to develop off
>> > of the *master
>> > branch (or any other branch really)* of the NiFi FDS. An example of this
>> > can be found in the github.io demo here
>> > <https://github.com/scottyaslan/fluid-design-system/blob/gh-
>> pages/package.
>> > json#L45>
>> > . By placing that dependency in the package.json for the NiFi Registry
>> each
>> > subsequent clean build would automatically download the latest master
>> > branch of the NiFi FDS sub-project and developers can leverages the
>> latest
>> > NiFi FDS components.
>> >
>> > This also brings up a good point about release management. I have also
>> > included a prototype of one possible implementation of automating the
>> > tagging of a branch and automatically updating release version numbers
>> etc.
>> > leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with
>> the
>> > described grunt task.
>> >
>> > [1]
>> > https://github.com/scottyaslan/fluid-design-system/blob/
>> master/Gruntfile.
>> > js#L47
>> >
>> > [2] https://github.com/scottyaslan/fluid-design-system/tree/FDS-
>> 0.0.1-RC.0
>> >
>> > On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna <
>> sivaprasanna246@gmail.com>
>> > wrote:
>> >
>> > > I agree with Matt. With clear documentation and guides, contributions
>> on
>> > > the sub-projects can be streamlined and be ensured that the necessary
>> > > changes are already available on the core project i.e NiFi. One
>> challenge
>> > > is that the committer of the sub-project should have the courtesy to
>> > check
>> > > wether the supporting changes are made available to the core project
>> and
>> > > track its status but given how contributions are being handled in
>> > > nifi-registry project, I don’t think it’s going to be that much of a
>> > > headache.
>> > >
>> > > We could also add to the helper doc mentioning that if the
>> contribution
>> > is
>> > > going to affect a core component, the contributor needs to add the
>> JIRA
>> > id
>> > > of the core project’s supporting changes in the sub-projects’ issue
>> > > description.
>> > >
>> > > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman <matt.c.gilman@gmail.com
>> >
>> > > wrote:
>> > >
>> > > > Joe, Joe,
>> > > >
>> > > > Regarding the release process... I think it could be similar to how
>> > folks
>> > > > verified and validated the NiFi Registry release. Guidance was given
>> > in a
>> > > > helper guide regarding how to obtain/build a branch or PR that
>> > references
>> > > > the new components. For the Registry release, there was a PR for
>> NiFi
>> > > that
>> > > > had the supporting changes already available.
>> > > >
>> > > > We may have this issue any time we release new versions that depend
>> on
>> > > > another (sub)project.
>> > > >
>> > > > Matt
>> > > >
>> > > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall <
>> jpercivall@apache.org
>> > >
>> > > > wrote:
>> > > >
>> > > > > Scott,
>> > > > >
>> > > > > Definitely like the direction of standardizing NiFi and Registry
>> > around
>> > > > the
>> > > > > same set of components, so the user has a common UX. Is there
>> > precedent
>> > > > for
>> > > > > creating a new sub-project just for common components/modules to
>> be
>> > > used
>> > > > by
>> > > > > the top-level, and it's other sub-projects? My concerns are
>> similar
>> > to
>> > > > > Joe's. Along those lines, if the core problems we're trying to
>> > address
>> > > is
>> > > > > the release process and distribution, is there a less
>> "heavy-weight"
>> > > > > avenue?
>> > > > >
>> > > > > In the past, we've also talked about pulling out the core NiFi
>> > > framework
>> > > > to
>> > > > > be shared between NiFi and MiNiFi-Java for similar reasons. How
>> we go
>> > > > about
>> > > > > solving this for the UI could be used a model for the core
>> framework
>> > as
>> > > > > well.
>> > > > >
>> > > > > - Joe
>> > > > >
>> > > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <
>> > mikerthomsen@gmail.com
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > > > Also, what sort of framework is the UI being standardized on?
>> > > Angular?
>> > > > > > React? Something else?
>> > > > > >
>> > > > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <jo...@gmail.com>
>> > > wrote:
>> > > > > >
>> > > > > > > Scott
>> > > > > > >
>> > > > > > > Ok so extract out the fluid design work you started with NiFi
>> > > > Registry
>> > > > > > > to its own codebase which can be rev'd and published to NPM
>> > making
>> > > it
>> > > > > > > easier to consume/reuse across NiFi projects and offers better
>> > > > > > > consistency. This sounds interesting.
>> > > > > > >
>> > > > > > > In thinking through the additional community effort or the
>> effort
>> > > > > > > trade-off:
>> > > > > > > How often do you anticipate we'd be doing releases (and thus
>> > > > > > > validation/voting) for this?
>> > > > > > > How often would those differ from when we'd want to do a NiFi
>> or
>> > > NiFi
>> > > > > > > Registry release?
>> > > > > > > How do you envision the community would be able to help
>> > > vet/validate
>> > > > > > > releases of these modules?
>> > > > > > >
>> > > > > > > Thanks
>> > > > > > > Joe
>> > > > > > >
>> > > > > > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <
>> > > scottyaslan@gmail.com>
>> > > > > > > wrote:
>> > > > > > > > NiFi Community,
>> > > > > > > >
>> > > > > > > > I'd like to initiate a discussion around creating a
>> sub-project
>> > > of
>> > > > > NiFi
>> > > > > > > to
>> > > > > > > > encompass the Fluid Design System NgModule created during
>> the
>> > > > > > development
>> > > > > > > > of the NiFi Registry. A possible name for this sub-project
>> is
>> > > > simply
>> > > > > > > > "NiFi Fluid
>> > > > > > > > Design System". The idea would be to create a sub-project
>> that
>> > > > > > > distributes
>> > > > > > > > an atomic set of high quality, reuse-able, theme-able, and
>> > > testable
>> > > > > > UI/UX
>> > > > > > > > components, fonts, and other JS modules for use across the
>> > > various
>> > > > > web
>> > > > > > > > applications throughout the NiFi universe (uNiFiverse???).
>> Both
>> > > > NiFi
>> > > > > > and
>> > > > > > > > NiFi Registry web applications would eventually leverage
>> this
>> > > > module
>> > > > > > via
>> > > > > > > > npm. This approach will enable us to provide our users with
>> a
>> > > > > > consistent
>> > > > > > > > experience across web applications. Creating a sub-project
>> > would
>> > > > also
>> > > > > > > allow
>> > > > > > > > the FDS code to evolve independently of NiFi/NiFi registry
>> and
>> > be
>> > > > > > > released
>> > > > > > > > on it's own timeline. In addition, it would make tracking
>> > > > issues/work
>> > > > > > > much
>> > > > > > > > clearer through a separate JIRA.
>> > > > > > > >
>> > > > > > > > Please discuss and provide and thoughts or feedback.
>> > > > > > > >
>> > > > > > > > Thanks,
>> > > > > > > >
>> > > > > > > > Scotty
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > *Joe Percivall*
>> > > > > linkedin.com/in/Percivall
>> > > > > e: jpercivall@apache.com
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid
Design System
Posted by Sivaprasanna <si...@gmail.com>.
A couple of names I came up with:
1. chalk
2. depth
3. dew
4. cyan
5. mint
On Thu, Mar 1, 2018 at 8:37 PM, Scott Aslan <sc...@gmail.com> wrote:
> Hello MikeM/everyone,
>
> One of the questions brought up in this discussion was centered around what
> a design system is. I stumbled upon a really great article this morning on
> this exact topic. It also links to several other really great articles and
> will help us all to understand.
> https://uxplanet.org/design-systems-in-2016-5415a660b29
>
> Also, I was thinking about the name.... what does everyone think about
> naming this sub-project NiFi Design System?
>
> -Scotty
>
> On Fri, Feb 23, 2018 at 10:20 AM, Scott Aslan <sc...@gmail.com>
> wrote:
>
> > TonyK,
> >
> > The intent is to use this this NgModule in NiFi Registry and eventually
> > NiFi. However, this would be released under ASLv2 so yes other projects
> > could use it.
> >
> > On Thu, Feb 22, 2018 at 10:46 PM, Tony Kurc <tk...@apache.org> wrote:
> >
> >> Is some of the thinking that projects other than nifi projects would use
> >> this?
> >>
> >> On Feb 22, 2018 10:00 PM, "Scott Aslan" <sc...@gmail.com> wrote:
> >>
> >> > Sivaprasanna,
> >> >
> >> > I am not sure I follow exactly what you are saying...
> >> >
> >> > NiFi Registry would no longer continue to host a copy of the FDS
> >> NgModule.
> >> > Instead, NiFi Registry would just add the NiFi FDS sub-project as a
> >> client
> >> > side dependency in its package.json. This would be analogous to how
> NiFi
> >> > Registry depends on Angular Material, etc. npm supports the ability to
> >> > download published packages which are current with the latest stable
> >> > release of a package. npm *also* supports the ability to develop off
> >> > of the *master
> >> > branch (or any other branch really)* of the NiFi FDS. An example of
> this
> >> > can be found in the github.io demo here
> >> > <https://github.com/scottyaslan/fluid-design-system/blob/gh-
> >> pages/package.
> >> > json#L45>
> >> > . By placing that dependency in the package.json for the NiFi Registry
> >> each
> >> > subsequent clean build would automatically download the latest master
> >> > branch of the NiFi FDS sub-project and developers can leverages the
> >> latest
> >> > NiFi FDS components.
> >> >
> >> > This also brings up a good point about release management. I have also
> >> > included a prototype of one possible implementation of automating the
> >> > tagging of a branch and automatically updating release version numbers
> >> etc.
> >> > leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with
> >> the
> >> > described grunt task.
> >> >
> >> > [1]
> >> > https://github.com/scottyaslan/fluid-design-system/blob/
> >> master/Gruntfile.
> >> > js#L47
> >> >
> >> > [2] https://github.com/scottyaslan/fluid-design-system/tree/FDS-
> >> 0.0.1-RC.0
> >> >
> >> > On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna <
> >> sivaprasanna246@gmail.com>
> >> > wrote:
> >> >
> >> > > I agree with Matt. With clear documentation and guides,
> contributions
> >> on
> >> > > the sub-projects can be streamlined and be ensured that the
> necessary
> >> > > changes are already available on the core project i.e NiFi. One
> >> challenge
> >> > > is that the committer of the sub-project should have the courtesy to
> >> > check
> >> > > wether the supporting changes are made available to the core project
> >> and
> >> > > track its status but given how contributions are being handled in
> >> > > nifi-registry project, I don’t think it’s going to be that much of a
> >> > > headache.
> >> > >
> >> > > We could also add to the helper doc mentioning that if the
> >> contribution
> >> > is
> >> > > going to affect a core component, the contributor needs to add the
> >> JIRA
> >> > id
> >> > > of the core project’s supporting changes in the sub-projects’ issue
> >> > > description.
> >> > >
> >> > > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman <
> matt.c.gilman@gmail.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > Joe, Joe,
> >> > > >
> >> > > > Regarding the release process... I think it could be similar to
> how
> >> > folks
> >> > > > verified and validated the NiFi Registry release. Guidance was
> given
> >> > in a
> >> > > > helper guide regarding how to obtain/build a branch or PR that
> >> > references
> >> > > > the new components. For the Registry release, there was a PR for
> >> NiFi
> >> > > that
> >> > > > had the supporting changes already available.
> >> > > >
> >> > > > We may have this issue any time we release new versions that
> depend
> >> on
> >> > > > another (sub)project.
> >> > > >
> >> > > > Matt
> >> > > >
> >> > > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall <
> >> jpercivall@apache.org
> >> > >
> >> > > > wrote:
> >> > > >
> >> > > > > Scott,
> >> > > > >
> >> > > > > Definitely like the direction of standardizing NiFi and Registry
> >> > around
> >> > > > the
> >> > > > > same set of components, so the user has a common UX. Is there
> >> > precedent
> >> > > > for
> >> > > > > creating a new sub-project just for common components/modules to
> >> be
> >> > > used
> >> > > > by
> >> > > > > the top-level, and it's other sub-projects? My concerns are
> >> similar
> >> > to
> >> > > > > Joe's. Along those lines, if the core problems we're trying to
> >> > address
> >> > > is
> >> > > > > the release process and distribution, is there a less
> >> "heavy-weight"
> >> > > > > avenue?
> >> > > > >
> >> > > > > In the past, we've also talked about pulling out the core NiFi
> >> > > framework
> >> > > > to
> >> > > > > be shared between NiFi and MiNiFi-Java for similar reasons. How
> >> we go
> >> > > > about
> >> > > > > solving this for the UI could be used a model for the core
> >> framework
> >> > as
> >> > > > > well.
> >> > > > >
> >> > > > > - Joe
> >> > > > >
> >> > > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <
> >> > mikerthomsen@gmail.com
> >> > > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Also, what sort of framework is the UI being standardized on?
> >> > > Angular?
> >> > > > > > React? Something else?
> >> > > > > >
> >> > > > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <
> joe.witt@gmail.com>
> >> > > wrote:
> >> > > > > >
> >> > > > > > > Scott
> >> > > > > > >
> >> > > > > > > Ok so extract out the fluid design work you started with
> NiFi
> >> > > > Registry
> >> > > > > > > to its own codebase which can be rev'd and published to NPM
> >> > making
> >> > > it
> >> > > > > > > easier to consume/reuse across NiFi projects and offers
> better
> >> > > > > > > consistency. This sounds interesting.
> >> > > > > > >
> >> > > > > > > In thinking through the additional community effort or the
> >> effort
> >> > > > > > > trade-off:
> >> > > > > > > How often do you anticipate we'd be doing releases (and thus
> >> > > > > > > validation/voting) for this?
> >> > > > > > > How often would those differ from when we'd want to do a
> NiFi
> >> or
> >> > > NiFi
> >> > > > > > > Registry release?
> >> > > > > > > How do you envision the community would be able to help
> >> > > vet/validate
> >> > > > > > > releases of these modules?
> >> > > > > > >
> >> > > > > > > Thanks
> >> > > > > > > Joe
> >> > > > > > >
> >> > > > > > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <
> >> > > scottyaslan@gmail.com>
> >> > > > > > > wrote:
> >> > > > > > > > NiFi Community,
> >> > > > > > > >
> >> > > > > > > > I'd like to initiate a discussion around creating a
> >> sub-project
> >> > > of
> >> > > > > NiFi
> >> > > > > > > to
> >> > > > > > > > encompass the Fluid Design System NgModule created during
> >> the
> >> > > > > > development
> >> > > > > > > > of the NiFi Registry. A possible name for this sub-project
> >> is
> >> > > > simply
> >> > > > > > > > "NiFi Fluid
> >> > > > > > > > Design System". The idea would be to create a sub-project
> >> that
> >> > > > > > > distributes
> >> > > > > > > > an atomic set of high quality, reuse-able, theme-able, and
> >> > > testable
> >> > > > > > UI/UX
> >> > > > > > > > components, fonts, and other JS modules for use across the
> >> > > various
> >> > > > > web
> >> > > > > > > > applications throughout the NiFi universe (uNiFiverse???).
> >> Both
> >> > > > NiFi
> >> > > > > > and
> >> > > > > > > > NiFi Registry web applications would eventually leverage
> >> this
> >> > > > module
> >> > > > > > via
> >> > > > > > > > npm. This approach will enable us to provide our users
> with
> >> a
> >> > > > > > consistent
> >> > > > > > > > experience across web applications. Creating a sub-project
> >> > would
> >> > > > also
> >> > > > > > > allow
> >> > > > > > > > the FDS code to evolve independently of NiFi/NiFi registry
> >> and
> >> > be
> >> > > > > > > released
> >> > > > > > > > on it's own timeline. In addition, it would make tracking
> >> > > > issues/work
> >> > > > > > > much
> >> > > > > > > > clearer through a separate JIRA.
> >> > > > > > > >
> >> > > > > > > > Please discuss and provide and thoughts or feedback.
> >> > > > > > > >
> >> > > > > > > > Thanks,
> >> > > > > > > >
> >> > > > > > > > Scotty
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > *Joe Percivall*
> >> > > > > linkedin.com/in/Percivall
> >> > > > > e: jpercivall@apache.com
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>