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.
> NiFi Fluid UI
> NiFi UI Components
> NiFi FDS
> -- Mike
> On Thu, Feb 22, 2018 at 1:43 PM, Scott Aslan <scottyas...@gmail.com>
> > 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.
> > 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
> > 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
> > adequate test coverage before being merged to NiFi FDS master. We could
> > also provide a demo application that users can build and deploy locally
> > allow for human verification or even e2e testing...
> > I took the liberty of standing up a repo to give everyone a better idea
> > 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
> > 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
> > > 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
> > > > 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
> > >