@All, I was able to grab some of KK's time on Friday. The meeting had two halves, the first was a strategic discussion about the breadth of changes we might want to attempt and how those changes should be phased in, and the second was a tactical discussion about how to start making progress now.
For the strategic bit, I put to KK Tom and my concern about fragile nature of the existing jelly based components, and how even slight changes to the DOM they draw can lead to some very unexpected breaks both in plugins and in existing core features. But then, I turned myself around and also argued that we will eventually need to change or replace these components, compatibility issues or not, because in addition to their awkward unattractiveness, some have architectural performance problems, and none of them fit with the modern UI libraries and best practices that are prevalent in web UIs today. My conclusion was that we needed to set up some sort of parallel path approach for Jenkins UIs. One that remained largely unchanged and allowed existing plugins to function as they do and a new path that we at CloudBees would write all our new components with and for, that community members could also adopt or not adopt, down the road, as they see fit. KK only bought half of that... He has seen the UX issues and heard from other sources a diagnosis similar to mine, but what he didn't like was the idea of parallel paths. His reasoning what that if existing UI framework has problems those problems need to be fixed, not just left on the side as someone elses problems. His conclusion was we/I should man-up and fix the core. My belief is that the correct fixes to the core still involve two parts. For the FIX aspect, I think step one is to figure out how to adjust the DOM that the Jelly tags generate to be more semantically correct (what I mean by that is that the HTML that hits the browser really needs to follow the same sort of good encapsulation principles that any other well formed XML document would follow, rather than a ton of tags dedicated to the screen position of elements). This isn't the only problem many of the jelly controls have by a long shot, but until they are better encapsulated, they are almost impossible to work on atomically and the ocean just becomes too big to swim in. In making these first round of changes we will also need to detangle hudson-behaviors.js, which is the main JS file, written with a mix of native JS, prototype.js, and YUI. Hopefully in doing so, some of the screen performance issues can also get sorted out and use of newer libraries like JQuery with the jelly controls will become more feasible. ..but... There will be some breakage. So we at CloudBees and we in the community will need to coordinate the right time and people to perform this operation. For the EXPAND aspect, the discussion became more tactical. We at CloudBees are in the process of investing heavily in JoC and Workflow. These pieces are going to have reasonably significant UI requirements and we, like you all, need better tools to build them. To address these tactical needs, KK helped me put together a new plugin, 'ui-control-plugin', on gitHub. At the moment, there is very little to show here, so I am not posting a link, but the idea is that this plugin will eventually contain both a set of new jelly controls as well as a new MVC framework for making more robust full canvas style views and widgets. A decent portion of Tom's awesome work is likely to be the first inhabitants of this set. Hopefully it goes without saying that all this work is in the early stages and I am pushing out this information as the details are still being worked out specifically to collect input from you all to shape this work in progress. Assuming this continues to be the prevailing wind direction, I am expecting that in the not too distant future, we will be looking to solicit even more help and feedback from the community, particular in coordinating the FIX pieces of our UI puzzle. We will also be interested testing help for the EXPAND piece. ...so again and as always, your thoughtful feedback is greatly appreciated. Gus On Wednesday, February 18, 2015 at 8:27:12 AM UTC-8, Gus Reiber wrote: > > At the end of last summer, my friend and co-worker, Tom Fennelly > <https://github.com/tfennelly>, along with the help of Kevin Burke > <https://github.com/kevinburke>, Daniel Beck > <https://github.com/daniel-beck>, and others began the first steps of > improving and modernizing the Jenkins user experience. In addition to some > of the superficial enhancements, these changes are meant to add a bit of > responsiveness and cross-device usability to the Jenkins GUI, as well as > adding a means of creating and swapping new CSS based display themes. This > effort is best summarized by this article from Jenkins-ci.org, and this > thread from the Jenkinsci-users group: > > - *User Interface Refresh > <http://jenkins-ci.org/node/501#disqus_thread>:* > http://jenkins-ci.org/node/501#disqus_thread > - *Any comments on the UI changes in 1.572 > > <https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J>:* > > > https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J > > As part of our second wave effort here at CloudBees, I am looking at ways > of improving the usability of the Jelly based form controls used in the > item creation and configuration pages and the responsiveness and > interactivity of the main dashboard grid control. > > In my investigations so far, I believe there are essentially 3 > non-exclusive paths forward for enhancing these elements: > > 1. *CSS only --* Building on the last round of enhancements, we can > offer a set of theme extensions that will allow the Jenkins users and > community to customize basic layout, iconography, and typeface to tailor > Jenkins to their own tastes. > 2. *UI component expansion and refactoring --* By modifying and adding > to the existing set of Jelly files and their corresponding data binding > rules we can significantly modernize the way Jenkins views and configs > draw > themselves and potentially streamline plugin creation. > 3. *Client side MVC veneers --* In a manner similar to what CloudBees > has recently done with the new Workflow visualization, we can rethink our > approach to new feature UIs by using a REST API based architecture coupled > with client-side rendering widgets. This would allow us to use newer > framework libraries like Angular.js and newer component libraries like > Bootstrap and JQuery UI to add greater richness to the Jenkins user > experience. > > These are likely not the only paths forward, but merely the first I can > think of. With that reality in mind, I am hoping to reach out to you the > Jenkins community to help ground and sculpt our thinking about what is both > possible and desirable. > > If you are at all interested in the Jenkins user experience, I would love > to get your feedback of any sort on this thread, which could be as simple > as a "+1" or as involved as a PHD thesis or as much as you have time to > type into a response box. > > To the extent that it helps conversation along, I also have a handful of > questions to which I would love responses: > > 1. For plugin builders, can you tell me a bit about creating the UI > portion of your plugin (did you use the data binding form controls, what > was hard, what did you have to invent)? > 2. For regular Jenkins users, what are the UX areas of Jenkins you > would most like to see improved (I think it is the item create/config and > the dashboard/job list grid, but would love to hear others and general > feedback)? > 3. For UXers and other Jenkins contributors, how do my 3 forward paths > seem (are there others, do you have experience with any yourself, do any > seem scary)? > 4. Has anyone tried to make their own themes with the new capabilities > Tom has added or would you appreciate and handful of canned options to > choose between? > 5. Has anyone started using Workflow on a regular basis, and in > particular used the new workflow progress visualization enough to offer > feedback? > > > Again, if any of you all are at all interested in the Jenkins UX, we at > CloudBees are interested in helping move this ball forward and would love > to hear your feedback. > > Thanks for your help, > Gus > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3f42ee15-1e70-4b9a-97ca-0f6f01caf2ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
