Jenkins UX

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Jenkins UX

Gus Reiber-2
At the end of last summer, my friend and co-worker, Tom Fennelly, along with the help of Kevin BurkeDaniel 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:
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Jenkins dev mailing list
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 <[hidden email]>
To: [hidden email]
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 BurkeDaniel 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:
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 [hidden email].
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 the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Surya Gaddipati
In reply to this post by Gus Reiber-2
Poor UI performance is the no1 complaint I get from our devs when I talk to them about jenkins. 

I would be really really interested in killing ajax polling all over jenkins UI and using servlet 3.0 for async stuff. 

I posted couple of threads earlier about Servlet 3.0 upgrade but it didn't receive much attention. 


On Wednesday, February 18, 2015 at 10:27:12 AM UTC-6, Gus Reiber wrote:
At the end of last summer, my friend and co-worker, <a href="https://github.com/tfennelly" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;">Tom Fennelly, along with the help of <a href="https://github.com/kevinburke" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;">Kevin Burke, <a href="https://github.com/daniel-beck" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;">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:
  • <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">User Interface Refresh: <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">http://jenkins-ci.org/node/501#disqus_thread
  • <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">Any comments on the UI changes in 1.572: <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c108db80-b171-4cee-b585-dcc03bd178d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Surya Gaddipati
In reply to this post by Gus Reiber-2
Oh wait KK responded to my servlet 3.0 upgrade thread. Its on the roadmap.

On Wednesday, February 18, 2015 at 10:27:12 AM UTC-6, Gus Reiber wrote:
At the end of last summer, my friend and co-worker, <a href="https://github.com/tfennelly" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;">Tom Fennelly, along with the help of <a href="https://github.com/kevinburke" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;">Kevin Burke, <a href="https://github.com/daniel-beck" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;">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:
  • <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">User Interface Refresh: <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">http://jenkins-ci.org/node/501#disqus_thread
  • <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">Any comments on the UI changes in 1.572: <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/62cdc892-659c-460f-9eec-e55c36332778%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Kanstantsin Shautsou-2
In reply to this post by Gus Reiber-2
Some thoughts:
- Some current forms need to be fixed, for example radioButton needs lazy-loading that must exclude massive pattern checks for SCMs during rendering /configure job page.
- Some forms should be extended to provide more convenient data-binding. For example ugly expandableTextbox that i forced to parse to List/Set objects from String and back, when i need multiline configuration. Some friendly multiline form will provide better UI and help plugins developers.
In general providing good forms in core can minimise chaos in plugins UIs. 

AFAIR visualisation for workflow is CloudBees Enterprise plugin.

On Wednesday, February 18, 2015 at 7:27:12 PM UTC+3, Gus Reiber wrote:
At the end of last summer, my friend and co-worker, <a href="https://github.com/tfennelly" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;">Tom Fennelly, along with the help of <a href="https://github.com/kevinburke" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;">Kevin Burke, <a href="https://github.com/daniel-beck" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;">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:
  • <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">User Interface Refresh: <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">http://jenkins-ci.org/node/501#disqus_thread
  • <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">Any comments on the UI changes in 1.572: <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d1aae159-e969-4f62-a770-b4c9486a69a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Gus Reiber-2
In reply to this post by Jenkins dev mailing list
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... ;^)

  1. 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?

  2. 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?

  3. 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 <[hidden email]> 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 <[hidden email]>
To: [hidden email]
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 BurkeDaniel 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:
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 [hidden email].
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 [hidden email].
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Ioannis Moutsatsos-2
In reply to this post by Gus Reiber-2
Gus thanks for opening this discussion on these ideas.

I am a Jenkins user and developer with a somewhat unusual pedigree. My main interest is using Jenkins as a workflow and integration engine for research applications in life-sciences and bioinformatics. 
Jenkins proved to be more than capable in this 'off the beaten path' application, but the user interface as it exists in the vanilla job build forms almost killed any prospect of advanced users since most web application users are used to richer controls and enhanced interactivity with their web application forms.

Enter the Uno-Choice plugin as discussed earlier in this thread by Bruno @kinow of the BioUno.org project.
Working with him we were able to significantly enhance the type and interactivity of some crucial UI controls so that we can now start building advanced web analytic applications on Jenkins.

I envision Jenkins job forms and reports with rich UI and we have just started scratching the surface (see some attached screenshots). I'm currently exploring how D3 graphical elements as well as Shiny R applications can be integrated and used from within Jenkins.
Please, keep an open mind toward integrating and learning from such rich graphical UI tools as you embark on additional Jenkins UI enhancements.

Thank you and all the great people at CloudBees for continuing to support and enhance Jenkins for all!

Best regards
Ioannis

On Wednesday, February 18, 2015 at 11:27:12 AM UTC-5, Gus Reiber wrote:
At the end of last summer, my friend and co-worker, <a href="https://github.com/tfennelly" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;">Tom Fennelly, along with the help of <a href="https://github.com/kevinburke" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;">Kevin Burke, <a href="https://github.com/daniel-beck" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;">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:
  • <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">User Interface Refresh: <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">http://jenkins-ci.org/node/501#disqus_thread
  • <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">Any comments on the UI changes in 1.572: <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/73bbb30e-862a-4c95-9c3f-6290a763bd82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Untitled_Clipping_021815_031758_PM.jpg (93K) Download Attachment
Untitled_Clipping_021815_031855_PM.jpg (110K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Gus Reiber-2
In reply to this post by Kanstantsin Shautsou-2
Thanks Kanstantsin,
  I see your concern as the converse of Brunos, namely the current Jelly controls are deficient in a number of ways making plugin development rough and as a result, constructing a polished finished UX is almost impossible.

I am taking notes of you specific examples.
...and you are correct about the workflow visualisation.

Can I ask you the same question I asked Bruno, namely, if you had to, could you choose between having 2 paths for building plugins, an old vs. new model approach, or accepting some degree of breakage for existing plugins as the component library is overhauled?

...or another way to ask the question, is UX and plugin UI building so important to you that tackling one of these options with your own plugins would be worth doing?



On Wed, Feb 18, 2015 at 10:47 AM, Kanstantsin Shautsou <[hidden email]> wrote:
Some thoughts:
- Some current forms need to be fixed, for example radioButton needs lazy-loading that must exclude massive pattern checks for SCMs during rendering /configure job page.
- Some forms should be extended to provide more convenient data-binding. For example ugly expandableTextbox that i forced to parse to List/Set objects from String and back, when i need multiline configuration. Some friendly multiline form will provide better UI and help plugins developers.
In general providing good forms in core can minimise chaos in plugins UIs. 

AFAIR visualisation for workflow is CloudBees Enterprise plugin.


On Wednesday, February 18, 2015 at 7:27:12 PM UTC+3, Gus Reiber wrote:
At the end of last summer, my friend and co-worker, Tom Fennelly, along with the help of Kevin BurkeDaniel 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:
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 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d1aae159-e969-4f62-a770-b4c9486a69a5%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXyQx8ut-mGKmm5jcPJ78GjDK0ES2wwy0DU4DZ9o%2BEWFKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Gus Reiber-2
In reply to this post by Ioannis Moutsatsos-2
Awesome.
Thanks Ioannis.

You are absolutely correct that we are stuck a bit in last decades web technologies as far as client-side user presentation is concerned.

Can I ask you or maybe Bruno, how are those graphs embedded into this page?
...and what page is this I am looking at (I am assuming it is a custom plugin action page or a specialized view for a custom item type)?

Looks like I need to go grab the plugin kick the tires directly.

On Wed, Feb 18, 2015 at 12:19 PM, Ioannis Moutsatsos <[hidden email]> wrote:
Gus thanks for opening this discussion on these ideas.

I am a Jenkins user and developer with a somewhat unusual pedigree. My main interest is using Jenkins as a workflow and integration engine for research applications in life-sciences and bioinformatics. 
Jenkins proved to be more than capable in this 'off the beaten path' application, but the user interface as it exists in the vanilla job build forms almost killed any prospect of advanced users since most web application users are used to richer controls and enhanced interactivity with their web application forms.

Enter the Uno-Choice plugin as discussed earlier in this thread by Bruno @kinow of the BioUno.org project.
Working with him we were able to significantly enhance the type and interactivity of some crucial UI controls so that we can now start building advanced web analytic applications on Jenkins.

I envision Jenkins job forms and reports with rich UI and we have just started scratching the surface (see some attached screenshots). I'm currently exploring how D3 graphical elements as well as Shiny R applications can be integrated and used from within Jenkins.
Please, keep an open mind toward integrating and learning from such rich graphical UI tools as you embark on additional Jenkins UI enhancements.

Thank you and all the great people at CloudBees for continuing to support and enhance Jenkins for all!

Best regards
Ioannis


On Wednesday, February 18, 2015 at 11:27:12 AM UTC-5, Gus Reiber wrote:
At the end of last summer, my friend and co-worker, Tom Fennelly, along with the help of Kevin BurkeDaniel 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:
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 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/73bbb30e-862a-4c95-9c3f-6290a763bd82%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXxeeNH0h8wuWuzQh5Cey0yn86NvShzW%3D1Kco4jfbsfK7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Jenkins dev mailing list
In reply to this post by Gus Reiber-2
Hi Gus. I have replied off-list with access to a Jenkins server where we tested the Uno Choice plug-in.

There you'll find several jobs configured to create dynamic parameters and even some graphs I think? (Ioannis feel free correct me if I'm wrong).

Will reply your questions when I arrive at home.

Thanks
Bruno


From: Gus Reiber <[hidden email]>
To: [hidden email]
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... ;^)

  1. 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?

  2. 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?

  3. 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 <[hidden email]> 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 <[hidden email]>
To: [hidden email]
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 BurkeDaniel 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:
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 [hidden email].
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 [hidden email].
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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/484314190.360820.1424291711303.JavaMail.yahoo%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Ioannis Moutsatsos-2
In reply to this post by Gus Reiber-2
Hi Gus;

The screenshots are from standard job build forms using Uno-Choice parameters. 
Especially the Uno-Choice Dynamic Reference parameter can directly render any arbitrary HTML. In one case (the screenshot with the chemical structure) it's a simple iframe displaying a widget from NCBI, in the other it's a locally rendered D3 interactive plot. 
The D3 graph configuration can be found here: http://162.243.246.75:8080/job/TEST_D3_SCATTERPLOT/configure

The most recent version of the plugin can be found here: https://groups.google.com/forum/#!topic/biouno-developers/REx4-sk_xSs

As we speak, we are in the process of releasing it to the Jenkins community.

Best regards
Ioannis

On Wednesday, February 18, 2015 at 3:31:35 PM UTC-5, Gus Reiber wrote:
Awesome.
Thanks Ioannis.

You are absolutely correct that we are stuck a bit in last decades web technologies as far as client-side user presentation is concerned.

Can I ask you or maybe Bruno, how are those graphs embedded into this page?
...and what page is this I am looking at (I am assuming it is a custom plugin action page or a specialized view for a custom item type)?

Looks like I need to go grab the plugin kick the tires directly.

On Wed, Feb 18, 2015 at 12:19 PM, Ioannis Moutsatsos <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="PD81Q-Mi2LkJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">imout...@...> wrote:
Gus thanks for opening this discussion on these ideas.

I am a Jenkins user and developer with a somewhat unusual pedigree. My main interest is using Jenkins as a workflow and integration engine for research applications in life-sciences and bioinformatics. 
Jenkins proved to be more than capable in this 'off the beaten path' application, but the user interface as it exists in the vanilla job build forms almost killed any prospect of advanced users since most web application users are used to richer controls and enhanced interactivity with their web application forms.

Enter the <a href="https://wiki.jenkins-ci.org/display/JENKINS/Uno+Choice+Plugin" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FUno%2BChoice%2BPlugin\46sa\75D\46sntz\0751\46usg\75AFQjCNG7Wt1l7xOXqQzcce-u5v0t-aS1bA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FUno%2BChoice%2BPlugin\46sa\75D\46sntz\0751\46usg\75AFQjCNG7Wt1l7xOXqQzcce-u5v0t-aS1bA';return true;">Uno-Choice plugin as discussed <a href="https://groups.google.com/forum/#!topic/jenkinsci-dev/qUBLhE-4ybY" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/qUBLhE-4ybY';return true;" onclick="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/qUBLhE-4ybY';return true;">earlier in this thread by Bruno @kinow of the<a href="http://BioUno.org" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2FBioUno.org\46sa\75D\46sntz\0751\46usg\75AFQjCNGKvxfOd0Wg-csp4QIvrya9fJ3aBQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2FBioUno.org\46sa\75D\46sntz\0751\46usg\75AFQjCNGKvxfOd0Wg-csp4QIvrya9fJ3aBQ';return true;"> BioUno.org project.
Working with him we were able to significantly enhance the type and interactivity of some crucial UI controls so that we can now start building advanced web analytic applications on Jenkins.

I <a href="https://groups.google.com/forum/#!topic/biouno-developers/uQSANvdkVG4" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/forum/#!topic/biouno-developers/uQSANvdkVG4';return true;" onclick="this.href='https://groups.google.com/forum/#!topic/biouno-developers/uQSANvdkVG4';return true;">envision Jenkins job forms and reports with rich UI and we have just started scratching the surface (see some attached screenshots). I'm currently exploring how D3 graphical elements as well as Shiny R applications can be integrated and used from within Jenkins.
Please, keep an open mind toward integrating and learning from such rich graphical UI tools as you embark on additional Jenkins UI enhancements.

Thank you and all the great people at CloudBees for continuing to support and enhance Jenkins for all!

Best regards
Ioannis


On Wednesday, February 18, 2015 at 11:27:12 AM UTC-5, Gus Reiber wrote:
At the end of last summer, my friend and co-worker, <a href="https://github.com/tfennelly" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;">Tom Fennelly, along with the help of <a href="https://github.com/kevinburke" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;">Kevin Burke, <a href="https://github.com/daniel-beck" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;">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:
  • <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">User Interface Refresh: <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">http://jenkins-ci.org/node/501#disqus_thread
  • <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">Any comments on the UI changes in 1.572: <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">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 a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe';return true;" onclick="this.href='https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe';return true;">https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="PD81Q-Mi2LkJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/73bbb30e-862a-4c95-9c3f-6290a763bd82%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/msgid/jenkinsci-dev/73bbb30e-862a-4c95-9c3f-6290a763bd82%40googlegroups.com?utm_medium\75email\46utm_source\75footer';return true;" onclick="this.href='https://groups.google.com/d/msgid/jenkinsci-dev/73bbb30e-862a-4c95-9c3f-6290a763bd82%40googlegroups.com?utm_medium\75email\46utm_source\75footer';return true;">https://groups.google.com/d/msgid/jenkinsci-dev/73bbb30e-862a-4c95-9c3f-6290a763bd82%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a2abb0fe-5839-460c-ac11-780daaa2a244%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Jenkins dev mailing list
In reply to this post by Gus Reiber-2
> 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 <[hidden email]>
To: [hidden email]
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... ;^)

  1. 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?

  2. 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?

  3. 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 <[hidden email]> 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 <[hidden email]>
To: [hidden email]
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 BurkeDaniel 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:
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 [hidden email].
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 [hidden email].
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 [hidden email].
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Tom Fennelly
In reply to this post by Gus Reiber-2
Great stuff here guys.

Hopefully we can translate some of these ideas into here into JIRA feature tasks (if not already in JIRA) for tracking (label "user-experience").

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/dcfbc084-2004-4a3d-bfc4-4161714f4db6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Ulli Hafner
In reply to this post by Gus Reiber-2
As I plug-in developer I would like to have more powerful UI building blocks that I can *easily* use. E.g., in my static analysis plug-in I’m currently using plain and old YUI tabs to categorize warnings by module, package, etc. Now that Tom improved the main view tabs in Jenkins core I also would love to improve these plug-in tabs in the same way. Is this feasible? How much effort does it take? What are the steps to do? etc. 

As you already mentioned, the job configuration is not very user friendly, especially if there are multiple Advanced, Add, Delete, etc. buttons. If the input field layout is complex then it is really hard to understand which button belongs to which group. Having some layout templates would help...

And finally what I also would like to see is the possibility to have a more appealing project view where trend graphs etc. could be rearranged (e.g., like the Jira dashboard). One of my students is planning to provide some views in a way similar to Sonar in his master thesis. Is this easy to achieve in Jenkins? Where should we start the work? Can we reuse some existing components/libraries? 

So my +1 for your path 2 and 3.

What I think is not so important is theming (but this might be a matter of taste). This works quite well for Jenkins core but as soon as other plugins are involved (and we have more than 1000) this is normally getting a mess. I would rather prefer to have *one* good looking theme for core *and* plugins. (This is quite similar to e.g. IOS themes where you get really beautiful new icons for the most important apps, but you still have a lot of other icons around that look totally misplaced in the new icon scheme). Here it would help if we would have some interested volunteers who would help plug-in developers to provide consistent icons.

Am 18.02.2015 um 17:27 schrieb Gus Reiber <[hidden email]>:

At the end of last summer, my friend and co-worker, Tom Fennelly, along with the help of Kevin BurkeDaniel 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:
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 [hidden email].
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 the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6CCEA8EC-7813-4740-A791-C9C0EB2C543E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc (506 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

slide
I completely agree with the configuration page stuff. Email-ext has so many options these days that whenever someone wants a new feature, I cry a little thinking about how its going to make the UI more of a mess. I'm definitely open to any ideas people have on improving it, but it would be nice to have some additional "widgets" to grab from the taglibs.

On Fri Feb 20 2015 at 4:57:29 PM Ulli Hafner <[hidden email]> wrote:
As I plug-in developer I would like to have more powerful UI building blocks that I can *easily* use. E.g., in my static analysis plug-in I’m currently using plain and old YUI tabs to categorize warnings by module, package, etc. Now that Tom improved the main view tabs in Jenkins core I also would love to improve these plug-in tabs in the same way. Is this feasible? How much effort does it take? What are the steps to do? etc. 

As you already mentioned, the job configuration is not very user friendly, especially if there are multiple Advanced, Add, Delete, etc. buttons. If the input field layout is complex then it is really hard to understand which button belongs to which group. Having some layout templates would help...

And finally what I also would like to see is the possibility to have a more appealing project view where trend graphs etc. could be rearranged (e.g., like the Jira dashboard). One of my students is planning to provide some views in a way similar to Sonar in his master thesis. Is this easy to achieve in Jenkins? Where should we start the work? Can we reuse some existing components/libraries? 

So my +1 for your path 2 and 3.

What I think is not so important is theming (but this might be a matter of taste). This works quite well for Jenkins core but as soon as other plugins are involved (and we have more than 1000) this is normally getting a mess. I would rather prefer to have *one* good looking theme for core *and* plugins. (This is quite similar to e.g. IOS themes where you get really beautiful new icons for the most important apps, but you still have a lot of other icons around that look totally misplaced in the new icon scheme). Here it would help if we would have some interested volunteers who would help plug-in developers to provide consistent icons.

Am 18.02.2015 um 17:27 schrieb Gus Reiber <[hidden email]>:

At the end of last summer, my friend and co-worker, Tom Fennelly, along with the help of Kevin BurkeDaniel 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:
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 [hidden email].
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 the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6CCEA8EC-7813-4740-A791-C9C0EB2C543E%40gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVd7ZHwLKxuMBuAGCpMbH8J%3Dsf8h3dyu8FC%3D2X29QNqesA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Tom Fennelly
Yes, I think everyone agrees that the config pages are a UX nightmare. We looked at changing how they are rendered by introducing <div> sections that are then collapsible. It was somewhat of a success but what frightened me off taking it further was the fact that it was inevitably going to break plugins. Since it was early days in my efforts to make improvements to the UI, I didn't want to start by breaking shit all over the place and in so doing, turn everyone off the idea of me (and others) attempting to "fix" the ui.

So on that note I would ask the Jenkins community how they would feel about making changes to how the config pages work where those changes could cause plugins to break, requiring them to be fixed in order to work again? I think there would need to be some level of community agreement on that before we'd attempt to do it.

@Uli ... it should be easy enough to render a set of tabs the same as the tabs on the standard Jenkins Home page since they're just a set of <div>s that are styled using CSS (pure CSS i.e. no javascript involved at all). If you inspect the source there you should be able to see what's required and easily replicate it for your plugin.

@Uli as for UI Themes, I'd be of the opinion that they're not just about making the UI nice. They can also be used in terms of providing accessibility features to Jenkins e.g. allowing visually impaired people to have a personalised/custom UI experience (bigger text... different colors etc) than other people using the same Jenkins instance. Aside from that, I think everyone has different ideas about what that "one good looking theme" would be, which is the problem and which is what makes themes more attractive for me.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4130e578-1341-4667-abdb-adc3f7368d3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Ioannis Moutsatsos-2
Hi Tom;

Great discussion and a nice brave world that you are revealing us through your work!

I know that the fear of the unexpected consequences is always an issue. However, given the benefits of improved an Configuration UI I think we should be willing to take on some breaking changes. I did it recently (for the Uno-Choice plugin we developed) and although I admit initially it was frightening, at the end I took the plunge and never regretted it since... 

I like the idea of collapsible sections. In fact I've used the Jenkins Collapsible Sections plugin to create easy to read project configuration reports. Nested and hierarchical structures (such as the config file behind the scenes) benefit from this visualization.

I'm attaching a pdf with a wire-frame of a possible configuration screen. What I'm envisioning is that you start with a basic layout of the project with the required elements. Then each element will display a drop down menu (similar to what is currently attached to projects lets say) that will allow you to add, insert and move semantically correct (driven perhaps by a xml schema for a Jenkins project) elements to the right place in the project

Perhaps if we can isolate where each parameter, build step, and publisher gets configured it will not be so ominous. So for whatever is currently selected we can show a detail of the configuration in what I'm showing as a bottom configuration tab.

Finally, having the ability to review a project configuration in a high level summary I think it is quite enabling. Whatever, we can do to enable this will be great. Perhaps this summary can easiy displayall project dependencies (plugins, versions,external scripts etc) so it can facilitate the transfer of these projects across servers.

Best regards
Ioannis

On Saturday, February 21, 2015 at 8:58:54 AM UTC-5, Tom Fennelly wrote:
Yes, I think everyone agrees that the config pages are a UX nightmare. We looked at changing how they are rendered by introducing <div> sections that are then collapsible. It was somewhat of a success but what frightened me off taking it further was the fact that it was inevitably going to break plugins. Since it was early days in my efforts to make improvements to the UI, I didn't want to start by breaking shit all over the place and in so doing, turn everyone off the idea of me (and others) attempting to "fix" the ui.

So on that note I would ask the Jenkins community how they would feel about making changes to how the config pages work where those changes could cause plugins to break, requiring them to be fixed in order to work again? I think there would need to be some level of community agreement on that before we'd attempt to do it.

@Uli ... it should be easy enough to render a set of tabs the same as the tabs on the standard Jenkins Home page since they're just a set of <div>s that are styled using CSS (pure CSS i.e. no javascript involved at all). If you inspect the source there you should be able to see what's required and easily replicate it for your plugin.

@Uli as for UI Themes, I'd be of the opinion that they're not just about making the UI nice. They can also be used in terms of providing accessibility features to Jenkins e.g. allowing visually impaired people to have a personalised/custom UI experience (bigger text... different colors etc) than other people using the same Jenkins instance. Aside from that, I think everyone has different ideas about what that "one good looking theme" would be, which is the problem and which is what makes themes more attractive for me.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/963e3b5b-2853-45e5-ba87-de06f625380c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Wireframe Jenkins Project Configuration -IKM.pdf (384K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Kanstantsin Shautsou-2
@Tom, divs, css and tab it's cool, but as not UI developer i will expect "building blocks" that will allow me just to use form and databinding. This will also allow enhance/fix problems only in this block that will automatically apply to other places. 

More thoughts.
- I think that other UI problem is maintainers/developers programming knowledge and lack of good documentation with good variants for them. After INFRA changes i hope people will finally be able to start enhancing documentation. 
Many plugins configurations are based on checkboxes, even -ETOOMANYCHECKBOXES in ui that leads to mess in UI and code. Maintainers are not bothering to ask any experienced jenkins devs to review their changes. Some PRs after good review ends with only few lines of change instead of many new classes and changes. 
Also jenkinsci plugin hosting for any jenkins plugin looks like a trash can  that ends with bad end-user experience in jenkins, i see many jenkins installations and many times i'm wasting time searching what plugin provided what configuration (because help files not created, or configuration names are the same, for example, maven builders from artifactory, maven and other plugins). (Should we create injected test for help files that will fail build?)

- Slide, I think email-ext absorbed many issues at once.
a) It obvious that everybody want configure job steps in any order and sending emails (or do any action) in any step. If freestyle job had had no such limitations and allow to reuse publishers, email-ext would have no implemented mix of cases in publisher (default template, for example, may exist in JobProperty).
b) AFAIR email-ext needs some better forms for some ui configurations
c) Some forms has very huge borders, intends, margins, etc. (repeatable-hetero-list?)
d) conditionals that are not provided in core and plugins implementing them and using i.e. flexible-publish loses different integrations because it not core.
This all pure API of core/freestyle that need to be enhanced and plugin developers inventing difficult code -> UI.
Wait, but workflow-plugin should resolve this issues? Do we need UI configuration now at all or should we configure jobs with coding in groovy workflow/DSL?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d3943d7e-4648-41af-9160-ca87b5825700%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Gus Reiber-2
In reply to this post by Ulli Hafner
@Ullrich -- I love your post, as it fits with my suspicions. Tom is right that a lot can be accomplished via CSS, not all of which is just window dressing, but the concern I share is that if the communities top concerns are things like screen performance, control complexity, and clarity of what the standards are and even how the component code works, it likely sends the wrong message when we invest in things like fonts and icons. Again, that isn't to say we shouldn't also look at the fonts and icons, but that can't be all we do. 

Ullrich, correct me if I am wrong, but it sounds like you would be willing to accept some level of plugin compatibility risk to see some improvement and modernization in the Jenkins UX and an enhancement to the tool set that allows for the construction of future UIs?




On Friday, February 20, 2015 at 3:57:28 PM UTC-8, Ullrich Hafner wrote:
As I plug-in developer I would like to have more powerful UI building blocks that I can *easily* use. E.g., in my static analysis plug-in I’m currently using plain and old YUI tabs to categorize warnings by module, package, etc. Now that Tom improved the main view tabs in Jenkins core I also would love to improve these plug-in tabs in the same way. Is this feasible? How much effort does it take? What are the steps to do? etc. 

As you already mentioned, the job configuration is not very user friendly, especially if there are multiple Advanced, Add, Delete, etc. buttons. If the input field layout is complex then it is really hard to understand which button belongs to which group. Having some layout templates would help...

And finally what I also would like to see is the possibility to have a more appealing project view where trend graphs etc. could be rearranged (e.g., like the Jira dashboard). One of my students is planning to provide some views in a way similar to Sonar in his master thesis. Is this easy to achieve in Jenkins? Where should we start the work? Can we reuse some existing components/libraries? 

So my +1 for your path 2 and 3.

What I think is not so important is theming (but this might be a matter of taste). This works quite well for Jenkins core but as soon as other plugins are involved (and we have more than 1000) this is normally getting a mess. I would rather prefer to have *one* good looking theme for core *and* plugins. (This is quite similar to e.g. IOS themes where you get really beautiful new icons for the most important apps, but you still have a lot of other icons around that look totally misplaced in the new icon scheme). Here it would help if we would have some interested volunteers who would help plug-in developers to provide consistent icons.

Am 18.02.2015 um 17:27 schrieb Gus Reiber <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="BJtQ23LD3cIJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">gre...@...>:

At the end of last summer, my friend and co-worker, <a href="https://github.com/tfennelly" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;">Tom Fennelly, along with the help of <a href="https://github.com/kevinburke" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;">Kevin Burke, <a href="https://github.com/daniel-beck" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;">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 <a href="http://Jenkins-ci.org" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2FJenkins-ci.org\46sa\75D\46sntz\0751\46usg\75AFQjCNH5Vthf-G5GjEkctcA_SaCill6Mig';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2FJenkins-ci.org\46sa\75D\46sntz\0751\46usg\75AFQjCNH5Vthf-G5GjEkctcA_SaCill6Mig';return true;">Jenkins-ci.org, and this thread from the Jenkinsci-users group:
  • <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">User Interface Refresh: <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">http://jenkins-ci.org/node/501#disqus_thread
  • <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">Any comments on the UI changes in 1.572: <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="BJtQ23LD3cIJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/83937142-c675-4260-92ab-1dd1be82ca03%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/msgid/jenkinsci-dev/83937142-c675-4260-92ab-1dd1be82ca03%40googlegroups.com?utm_medium\75email\46utm_source\75footer';return true;" onclick="this.href='https://groups.google.com/d/msgid/jenkinsci-dev/83937142-c675-4260-92ab-1dd1be82ca03%40googlegroups.com?utm_medium\75email\46utm_source\75footer';return true;">https://groups.google.com/d/msgid/jenkinsci-dev/83937142-c675-4260-92ab-1dd1be82ca03%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f08464f5-3532-4215-acb0-7d150c909651%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins UX

Gus Reiber-2
In reply to this post by Gus Reiber-2
@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, <a href="https://github.com/tfennelly" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly\46sa\75D\46sntz\0751\46usg\75AFQjCNHKAF2uFOHgIgkTZRI4iz5AfR5APw';return true;">Tom Fennelly, along with the help of <a href="https://github.com/kevinburke" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkevinburke\46sa\75D\46sntz\0751\46usg\75AFQjCNGSMBXllUNnh-Ik4ZJ1tOGGIz8CEw';return true;">Kevin Burke, <a href="https://github.com/daniel-beck" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdaniel-beck\46sa\75D\46sntz\0751\46usg\75AFQjCNG--aTDaZjlQ13LVlNSf5D2JS4lNw';return true;">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:
  • <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">User Interface Refresh: <a href="http://jenkins-ci.org/node/501#disqus_thread" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fjenkins-ci.org%2Fnode%2F501%23disqus_thread\46sa\75D\46sntz\0751\46usg\75AFQjCNFvWlQpnlmIm6n0JclPDrSoT5OeoQ';return true;">http://jenkins-ci.org/node/501#disqus_thread
  • <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">Any comments on the UI changes in 1.572: <a href="https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J';return true;">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 [hidden email].
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.
1234