MikeT,

Good question. Right now NiFi has a mix of design systems from Angular
Material, multiple jquery plugins (some of them custom and all of them have
their own approach to styling), jquery UI, and custom D3 visualizations. In
order to add a new UX feature in NiFi a developer needs to know each and
everyone of these different yet available widgets and when and how to use
them. The slider widget we use in NiFi is the jquery UI
https://jqueryui.com/slider/. However, the processors on the canvas are
custom visualizations (svg) drawn with D3 so the jquery UI slider will not
work in this case.

There is currently no documentation around when to use which design system
nor any documentation around adding custom controls to a processor but this
could certainly be something we can try to add some documentation around to
provide guidance to UI/UX contributors.

On Fri, Feb 23, 2018 at 8:42 AM, Joe Witt <joe.w...@gmail.com> wrote:

> MikeT
>
> Not disagreeing with your point about the UX/sliders for the case you
> mention - that would be cool - but as a heads up you can do what you
> describe today with RouteOnAttribute and specifying EL statements to
> cover the flowfile size ranges - would work pretty nicely.
>
> Thanks
>
> On Fri, Feb 23, 2018 at 8:41 AM, Mike Thomsen <mikerthom...@gmail.com>
> wrote:
> > Scott,
> >
> > Where does the UI/documentation stand on adding custom controls to
> > processors? That's a feature that I could see being really useful. An
> > example is a processor I've thought about writing called
> > RouteOnFlowfileSize that would let users define relationships based on
> > flowfile size ranges. Having sliders would be critical to making that
> > user-friendly.
> >
> > On Fri, Feb 23, 2018 at 8:28 AM, Scott Aslan <scottyas...@gmail.com>
> wrote:
> >
> >> 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