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 <scottyas...@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" <scottyas...@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 < >> sivaprasanna...@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.gil...@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 < >> jperciv...@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 < >> > mikerthom...@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.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 >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > *Joe Percivall* >> > > > > linkedin.com/in/Percivall >> > > > > e: jperciv...@apache.com >> > > > > >> > > > >> > > >> > >> > >
