I must admit i hadn't considered how the layout of the graph may look if the components are made larger. I think if it would mess up the layout then 1.0 makes a lot more sense. If we can either auto-reposition the components though then it would be fine. Or perhaps, if we kept the components the same size, until 1.0 and at that point we could resize the components. That way, most of the changes would come into play for 0.6 and then in 1.0 we would provide additional styling. Though I don't know what kind of additional effort that may add...
> On Jan 6, 2016, at 4: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 >>>>>>>>> >>>>>>>> >>>>>>> >>>> >>>> >>> >>>
