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 > > > > > >
