Beyond skinning, think of those who invest in training. Even if not a formalized program, folks build up organizational knowledge about how to interact with a UI.
Certainly there is a range of change types that are more or less disruptive; I definitely don't want to attempt to speak about most of the boundaries on that since I am not a UX designer. That said, if we call something a "redesign" it implies to me a level of change that will require downstream folks to relearn how to interact with the system. On Wed, Jan 6, 2016 at 3:34 PM, Joe Witt <joe.w...@gmail.com> wrote: > ...I was definitely in the same camp of this is ok until Simon's > email. If we do alter their existing layout in that it could look > messy I do think that makes it major. > > To Tony's point if we make a change that would make existing custom UI > extensions look different then it too is major. > > To Tony's other point regarding skinning we do not presently have any > skinning support. It is probably worth discussing but for now I think > we should document in our version commitment document that this is not > something which is supported. If skinning support is desirable we > should plan for that. > > In short, I do see some compelling reasons to put this in the 1.0 release. > > On a related note we have some pretty cool things on the feature > list/roadmap. I think we're in a much better place now to plan ahead > for these things than we have been and it is a good logical > progression for the community to do some good roadmap planning. I'll > try to get Tony's roadmap wiki page filled in and send that out to > initiate a good discussion. *Hopefully* this week. > > Thanks > Joe > > On Wed, Jan 6, 2016 at 4:16 PM, Tony Kurc <trk...@gmail.com> wrote: >> Is there is a possibility of folks having skinned or extended the UI? Would >> these changes be expected to work on minor version revisions? >> >> On Wed, Jan 6, 2016 at 4:14 PM, Simon Ball <sb...@hortonworks.com> wrote: >> >>> The new UI looks fantastic, and seems to be heading in a very good >>> direction. >>> >>> One thought I have is around the upgrade experience. Given that we will >>> likely end up with different sized elements to the existing UI, people may >>> find existing flow layouts end up somewhat jumbled with the repositioning >>> of elements. This should be easy to solve, with a migration the existing >>> attributes to a transformed (proportionally scaled?) coordinate system. >>> >>> Impact of this may be limited, but for early adopters who’ve put a lot of >>> investment into their layouts, it has the potential to end up making a mess >>> if we don’t provide some sort of migration. >>> >>> An alternative would be to limit the design to follow the existing >>> bounding box dimensions, but I think this would be a shame, and preclude >>> some of the lovely visual improvements that are emerging in the new mockups. >>> >>> Simon >>> >>> > On 6 Jan 2016, at 20:29, Mark Payne <marka...@hotmail.com> wrote: >>> > >>> > I think we could certainly do that, where we create a separate branch to >>> make all those changes. >>> > However, I do think that comes with some downsides. >>> > >>> > The UI codebase would likely be very different. Any change that is made >>> to the 0.x baseline would >>> > have to be made in two codebases, and if the 1.x branch is very >>> different, git rebases and the like may not >>> > work very well and trying to keep those changes in sync can quickly >>> become a rather large burden and be >>> > very error-prone. >>> > >>> > We've also been talking about revamping the UI since around version >>> 0.2.0. It's been in discussions for >>> > quite a long time, and it's just taken a while to come to fruition. >>> > >>> > Additionally, the new design, I believe, will provide a far better user >>> experience for low-resolution displays >>> > by providing the docked panels instead of letting everything rest at the >>> top of the screen, as well as high >>> > resolution displays by providing different types of components and >>> getting rid of some of those gradients. >>> > >>> > While I can understand the idea of "This is a major change so it should >>> wait until 1.0.0," I also think that since >>> > it provides the same functionality and is not breaking in any way, it is >>> not necessary to do so. >>> > >>> > Some key points that I believe we will need for 1.0.0 include >>> multi-tenant capabilities as well as HA. Changes to >>> > the UI I think could be accomplished quite a bit before those >>> capabilities are addressed. So while we could >>> > bench the changes on a branch for quite a while for 1.0.0, I don't >>> believe it's really necessary and I think that >>> > the pros outweigh the cons in this case. >>> > >>> > So I'm a +1 for introducing these changes in 0.6.0 and not waiting for a >>> 1.0.0 release. >>> > >>> > Thanks >>> > -Mark >>> > >>> > >>> >> On Jan 6, 2016, at 3:10 PM, Sean Busbey <bus...@apache.org> wrote: >>> >> >>> >> Doesn't this mean we could start moving towards 1.0 by keeping these >>> >> UI changes isolated in an appropriate branch and make the completion >>> >> of multitentant dataflow (and whatever other features) the complete >>> >> marker? >>> >> >>> >> If we need the UI in a distributable form, e.g. so that we can start >>> >> gathering feedback, we can do that by having a 1.0.0-alpha or the >>> >> like. >>> >> >>> >> On Wed, Jan 6, 2016 at 1:40 PM, Matt Gilman <matt.c.gil...@gmail.com> >>> wrote: >>> >>> Tony, >>> >>> >>> >>> That is correct. The UI redesign is necessary for a 1.0 feature. >>> >>> Additionally, the UI changes are limited to styling and positioning of >>> >>> certain elements for controlling the dataflow. >>> >>> >>> >>> Matt >>> >>> >>> >>> On Wed, Jan 6, 2016 at 2:33 PM, Tony Kurc <trk...@gmail.com> wrote: >>> >>> >>> >>>> Matt, >>> >>>> I'm not sure I followed. I think you said we have two things: >>> >>>> A) ui redesign >>> >>>> B) multi-tenant dataflow >>> >>>> >>> >>>> We need A before B, and B will be in 1.0, so we need A in a release >>> before >>> >>>> 1.0. >>> >>>> >>> >>>> >>> >>>> Tony >>> >>>> >>> >>>> On Wed, Jan 6, 2016 at 2:17 PM, Matt Gilman <matt.c.gil...@gmail.com> >>> >>>> wrote: >>> >>>> >>> >>>>> One of the items that's needed to go over the 1.0 cliff is support >>> for >>> >>>>> multi-tenant dataflows. Scoping user authorization to portions of a >>> >>>>> dataflow will require a major bump due to API changes and the like. >>> Part >>> >>>> of >>> >>>>> the motivation for this UI redesign is laying the foundation for that >>> >>>>> effort. Additionally, we'll get the added benefit of supporting a >>> more >>> >>>>> responsive layout and modernized look and feel in the meantime. >>> >>>>> >>> >>>>> Matt >>> >>>>> >>> >>>>> On Wed, Jan 6, 2016 at 1:28 PM, Sean Busbey <bus...@cloudera.com> >>> wrote: >>> >>>>> >>> >>>>>> +1 to "UI redesign warrants a major version increment" >>> >>>>>> >>> >>>>>> I know that we're "pre 1.0", but this sounds like it's time to >>> figure >>> >>>> out >>> >>>>>> what we need to include to go over that cliff. >>> >>>>>> >>> >>>>>> On Wed, Jan 6, 2016 at 12:22 PM, Tony Kurc <trk...@gmail.com> >>> wrote: >>> >>>>>> >>> >>>>>>> Looks great so far! >>> >>>>>>> >>> >>>>>>> I saw the target release of 0.6, which surprised me a bit. I would >>> >>>> have >>> >>>>>>> expected this significant of a change would warrant a major release >>> >>>>>>> increment. >>> >>>>>>> >>> >>>>>>> On Wed, Jan 6, 2016 at 1:08 PM, Rob Moran <rmo...@gmail.com> >>> wrote: >>> >>>>>>> >>> >>>>>>>> Greetings NiFi community, >>> >>>>>>>> >>> >>>>>>>> NIFI-1323 [1] has been mentioned in (at least one) previous >>> thread. >>> >>>>> In >>> >>>>>>> case >>> >>>>>>>> you are unaware, it involves beginning work on a series of UI >>> >>>>>>> improvements. >>> >>>>>>>> >>> >>>>>>>> I'd like to point your attention to the wiki page [2] where you >>> can >>> >>>>>> read >>> >>>>>>> up >>> >>>>>>>> on factors that are driving this effort. >>> >>>>>>>> >>> >>>>>>>> [1] https://issues.apache.org/jira/browse/NIFI-1323 >>> >>>>>>>> [2] >>> >>>>>>>> >>> >>>>>> >>> >>>> >>> https://cwiki.apache.org/confluence/display/NIFI/Redesign+User+Interface >>> >>>>>>>> >>> >>>>>>>> Thanks, >>> >>>>>>>> Rob >>> >>>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Sean >>> >>>>>> >>> >>>>> >>> >>>> >>> > >>> > >>> >>>
