> About Uno Choice, specifically, when you talk about crawling the page for job > parameters, does this happen in the create/config page, the dashboard/item > table, somewhere else, or all of the above? It happens in the forms for submitting jobs with parameters. For some parameter types, we need to get the **value** of other parameters. So that if the user changes the value, we will re-evaluate the parameter using the new entered value. > When you talk about a global JS object, I am guessing you mean the data model > of the config form, primarily. Not only that. Everything in the Jenkins UI that other plug-ins could be interested in using (e.g. I think the Queue UI elements would be another good example, for changing the length, formatting colours and icons of certain elements dynamically in the UI, etc). > If not, and you are scrapping data out of the dashboard table, I am still > assuming the data you are looking for is not here [ > https://ci.jenkins-ci.org/job/lib-jira-api/api/json ] or burried deep down > that tree, or it is, fetching it via ajax is either too onerus or too > non-performant to be worth the hassle? In the Uno Choice case, the data - values entered by users - are sometimes still not persisted in Jenkins. > you had to choose (and I am hoping you don't and won't) between accepting > some breakage or having a sort of split-canvas choice within Jenkins, which > would you choose? As a plug-in developer, I'd be fine with both. Just would take care to update the plug-in Wiki with information for users who wanted to update the plug-in. But from a user POV, I think it would be better without another thing to check for compatibility before updating or installing plug-ins. So I think the latter option would work best for me maybe? > Neither of these options seems very satisfying to me. Hopefully we will have other ideas. Maybe there're other choices that don't require breaking things and will allow us to improve the UX at same time :-) Bruno From: Gus Reiber <grei...@cloudbees.com> To: jenkinsci-dev@googlegroups.com Sent: Wednesday, February 18, 2015 6:05 PM Subject: Re: Jenkins UX Thanks for your feedback, Bruno.Your concern is exactly the concern that keeps me up at night. Thanks also for raising Uno Choice as an example.I am very much looking for specific examples of plugins with reasonable adoption that use the DOM to scrap bits and pieces of data out of Jenkins so I can get a test case list together. ...and your reward for you awesome feedback is 3 more questions from me... ;^) - About Uno Choice, specifically, when you talk about crawling the page for job parameters, does this happen in the create/config page, the dashboard/item table, somewhere else, or all of the above?
- When you talk about a global JS object, I am guessing you mean the data model of the config form, primarily. If not, and you are scrapping data out of the dashboard table, I am still assuming the data you are looking for is not here [ https://ci.jenkins-ci.org/job/lib-jira-api/api/json ] or burried deep down that tree, or it is, fetching it via ajax is either too onerus or too non-performant to be worth the hassle? - As I see it, for much of Jenkins plugin interoperation, and even some of its core functionality, there isn't really a programmatic API, but a set of facts about how Jenkins draws things on the screen that can be exploited to make features and components that share data in meaningful and interesting ways. The rub is that now to improve the UX in almost any meaningful way requires either changing that DOM (since that is what controls the rendering and GUI driven interactivity) and breaking those makeshift APIs, or establishing a new means for UI building that is completely independant of the past DOM. In that case plugins aren't broken, but a choice is required within Jenkins, work on an old canvas where old plugins work just fine, or work on the new canvas which starts without plugins, but is more capable. ....so my question here is if you had to choose (and I am hoping you don't and won't) between accepting some breakage or having a sort of split-canvas choice within Jenkins, which would you choose? Would you need more information before you could you even make such a choice? Neither of these options seems very satisfying to me. Thanks Again,Gus On Wed, Feb 18, 2015 at 9:12 AM, 'Bruno P. Kinoshita' via Jenkins Developers <jenkinsci-dev@googlegroups.com> wrote: Hello Gus, I heard good feedback on the new Jenkins UI. Kudos everyone involved! I don't really have much to contribute I think. But yesterday I posted to the dev-list about a new plug-in, Uno Choice, that is being used by researchers (both in academia and in industry). The plug-in relies utilizes HTML DOM elements to access job parameters. Should any of these elements gets changed due to UX enhancements, the plug-in would stop working. What I would like to have in order to avoid having this kind of issues, is something like global JS objects exposed by Jenkins - I'm not a JavaScript programmer, so I'm not completely sure that it is a good idea/practice. This way, plug-ins like Uno Choice could access parameters' elements, the Queue HTML elements, enable/disable buttons, without depending directly on any screen selector. More or less something like: # JS code used in the job parameter screen ```var parameters = Jenkins.parameters.all();var fields = parameters[0].getFields();var name = parameters[0].name;// internally Jenkins controls the selectors to access the parameters. Should any of these changes, plug-ins wouldn't be affected. ``` Not sure if that's the best option... My +1 :^) please continue the hard work on improving Jenkins UX. All the best, Bruno From: Gus Reiber <grei...@cloudbees.com> To: jenkinsci-dev@googlegroups.com Sent: Wednesday, February 18, 2015 2:27 PM Subject: Jenkins UX At the end of last summer, my friend and co-worker, Tom Fennelly, along with the help of Kevin Burke, 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 - Any comments on the UI changes in 1.572: 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: - 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. - 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. - 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: - 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)? - 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)? - 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)? - 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? - 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/83937142-c675-4260-92ab-1dd1be82ca03%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/62264246.276219.1424279521268.JavaMail.yahoo%40mail.yahoo.com. For more options, visit https://groups.google.com/d/optout. -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXy81GwUJNg%3DKz0OKP8nAeFsNKPiHTFZwvSHCvKiUfeXEA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1622481557.459144.1424305101361.JavaMail.yahoo%40mail.yahoo.com. For more options, visit https://groups.google.com/d/optout.
