Yes I would risk some incompatibilities with plug-ins, because I’m normally 
updating my plug-ins quite often if there is such a core change. But here I can 
only speak for myself: this depends on the spare time of plug-in developers and 
not everybody has the time to adapt the code to the new frameworks. Just look 
at the release dates of the plug-ins and you will see that this might be a 
problem for some (or many?) plugins.

> Am 23.02.2015 um 18:21 schrieb Gus Reiber <[email protected]>:
> 
> @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 <[email protected] 
>> <javascript:>>:
>> 
>> At the end of last summer, my friend and co-worker, Tom Fennelly 
>> <https://github.com/tfennelly>, along with the help of Kevin Burke 
>> <https://github.com/kevinburke>, Daniel Beck 
>> <https://github.com/daniel-beck>, and others began the first steps of 
>> improving and modernizing the Jenkins user experience. In addition to some 
>> of the superficial enhancements, these changes are meant to add a bit of 
>> responsiveness and cross-device usability to the Jenkins GUI, as well as 
>> adding a means of creating and swapping new CSS based display themes. This 
>> effort is best summarized by this article from Jenkins-ci.org 
>> <http://jenkins-ci.org/>, and this thread from the Jenkinsci-users group:
>> User Interface Refresh <http://jenkins-ci.org/node/501#disqus_thread>: 
>> http://jenkins-ci.org/node/501#disqus_thread 
>> <http://jenkins-ci.org/node/501#disqus_thread>
>> Any comments on the UI changes in 1.572 
>> <https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J>:
>>  
>> https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J
>>  
>> <https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J>
>> As part of our second wave effort here at CloudBees, I am looking at ways of 
>> improving the usability of the Jelly based form controls used in the item 
>> creation and configuration pages and the responsiveness and interactivity of 
>> the main dashboard grid control.
>> 
>> In my investigations so far, I believe there are essentially 3 non-exclusive 
>> paths forward for enhancing these elements:
>> CSS only -- Building on the last round of enhancements, we can offer a set 
>> of theme extensions that will allow the Jenkins users and community to 
>> customize basic layout, iconography, and typeface to tailor Jenkins to their 
>> own tastes.
>> UI component expansion and refactoring -- By modifying and adding to the 
>> existing set of Jelly files and their corresponding data binding rules we 
>> can significantly modernize the way Jenkins views and configs draw 
>> themselves and potentially streamline plugin creation.
>> Client side MVC veneers -- In a manner similar to what CloudBees has 
>> recently done with the new Workflow visualization, we can rethink our 
>> approach to new feature UIs by using a REST API based architecture coupled 
>> with client-side rendering widgets. This would allow us to use newer 
>> framework libraries like Angular.js and newer component libraries like 
>> Bootstrap and JQuery UI to add greater richness to the Jenkins user 
>> experience.
>> These are likely not the only paths forward, but merely the first I can 
>> think of.  With that reality in mind, I am hoping to reach out to you the 
>> Jenkins community to help ground and sculpt our thinking about what is both 
>> possible and desirable.
>> 
>> If you are at all interested in the Jenkins user experience, I would love to 
>> get your feedback of any sort on this thread, which could be as simple as a 
>> "+1" or as involved as a PHD thesis or as much as you have time to type into 
>> a response box.
>> 
>> To the extent that it helps conversation along, I also have a handful of 
>> questions to which I would love responses:
>> For plugin builders, can you tell me a bit about creating the UI portion of 
>> your plugin (did you use the data binding form controls, what was hard, what 
>> did you have to invent)?
>> For regular Jenkins users, what are the UX areas of Jenkins you would most 
>> like to see improved (I think it is the item create/config and the 
>> dashboard/job list grid, but would love to hear others and general feedback)?
>> For UXers and other Jenkins contributors, how do my 3 forward paths seem 
>> (are there others, do you have experience with any yourself, do any seem 
>> scary)?
>> Has anyone tried to make their own themes with the new capabilities Tom has 
>> added or would you appreciate and handful of canned options to choose 
>> between?
>> Has anyone started using Workflow on a regular basis, and in particular used 
>> the new workflow progress visualization enough to offer feedback?
>> 
>> Again, if any of you all are at all interested in the Jenkins UX, we at 
>> CloudBees are interested in helping move this ball forward and would love to 
>> hear your feedback.
>> 
>> Thanks for your help,
>> Gus
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/83937142-c675-4260-92ab-1dd1be82ca03%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/83937142-c675-4260-92ab-1dd1be82ca03%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout 
>> <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 [email protected] 
> <mailto:[email protected]>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/f08464f5-3532-4215-acb0-7d150c909651%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/f08464f5-3532-4215-acb0-7d150c909651%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/712A9447-B9FE-47E7-815A-7BAEF96C86F3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to