Mike Thomsen,

The Ui is being standardized on Angular. NiFi is currently running
AngularJS v1.5.11 while NiFi Registry is running Angular v4.4.6.

On Fri, Feb 23, 2018 at 8:23 AM, Scott Aslan <scottyas...@gmail.com> wrote:

> Micheal M.,
>
> A *Design System* is a collection of utilities, components, and
> guidelines which define the overall structure and experience of an
> application(s). Fluid is the name of this design system.
>
>
>
> On Thu, Feb 22, 2018 at 1:44 PM, Michael Moser <moser...@gmail.com> wrote:
>
>>  There are compelling pros and easily identifiable cons to placing UI
>> components into their own project.  I don't have anything to add there.
>>
>> Please, however, consider a different name.  "Fluid Design System" is
>> generic to the point of giving no cognitive clue about what it actually
>> is.  And without that clue, it's no different than a shorter made-up word.
>> Also, a quick Google search doesn't indicate that it's an industry
>> accepted
>> phrase that conveys meaning.
>>
>> Consider:
>>
>> Fluidifi
>> NiFi Fluid UI
>> NiFi UI Components
>> NiFi FDS
>>
>> Thanks,
>> -- Mike
>>
>>
>> On Thu, Feb 22, 2018 at 1:43 PM, Scott Aslan <scottyas...@gmail.com>
>> wrote:
>>
>> > Joe,
>> >
>> > Yes, extract out the FDS.
>> >
>> > As for a release schedule, I don't think there would need to be one. We
>> > would put out new releases as needed for new features or components.
>> These
>> > releases would be totally independent of NiFi or NiFi Registry. The
>> > intention with this project is to follow semantic versioning and avoid
>> > making breaking changes so using this library in NiFi or the NiFi
>> Registry
>> > would be as simple as updating the version number in the package.json
>> and
>> > rebuilding the application.
>> >
>> > As for validation of releases I have a couple of ideas. I envisioned
>> this
>> > code base would follow a RTC paradigm and the initial release of this
>> FDS
>> > NgModule would include unit test coverage of all the existing
>> > features/components/utils. Any new features/components/utils would
>> require
>> > adequate test coverage before being merged to NiFi FDS master. We could
>> > also provide a demo application that users can build and deploy locally
>> to
>> > allow for human verification or even e2e testing...
>> >
>> > I took the liberty of standing up a repo to give everyone a better idea
>> of
>> > what we are all talking about.
>> > https://github.com/scottyaslan/fluid-design-system
>> >
>> > Since no server or backend is required to run these UI/UX components I
>> also
>> > stood a demo of this as a github.io page here:
>> > https://scottyaslan.github.io/fluid-design-system/
>> > <https://scottyaslan.github.io/fluid-design-system/>
>> >
>> > -Scotty
>> >
>> > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <joe.w...@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 <scottyas...@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
>> > >
>> >
>>
>
>

Reply via email to