Some thoughts:
- Usually CMS has dropdown menu where user can choose theme that he likes
- https://github.com/Dakota628/jenkins-clean-theme has 62 forks where 
everybody changed something, some people found new 
icons http://colebemis.com/feather/. What about some gallery or separate 
update center for UI challenges? Based on download statistics you can 
define what merge to core jenkins.


On Wednesday, May 28, 2014 12:24:26 PM UTC+3, Tom Fennelly wrote:
>
>
>
> On Tuesday, May 27, 2014 10:24:33 AM UTC+1, Tom Fennelly wrote:
>>
>>
>>
>> On Monday, May 26, 2014 8:08:28 PM UTC+1, Christopher wrote:
>>>
>>> As you may have seen, this is something Tyler did some work on during 
>>>
>> FOSDEM last year.  The basic prototype I saw at the time was pretty 
>>> decent, but as mentioned above and at the time, of course there's a 
>>> *lot* of backward- and plugin-compatibility to think about: 
>>> https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y 
>>>
>>
>> Thanks for pointing me at this.  I'll ping Tyler and ask him to pitch in. 
>>  In some ways I feel that this might be the only real way to make 
>> meaningful usability changes to Jenkins.  Maybe we could replace parts of 
>> the UI with a SPA ... do it bit-by-bit.
>>
>>
> I pinged that thread again asking Tyler for his thoughts on the 
> API<https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y>. 
>  To save you from linking there, here's what he said ...
>
> The biggest challenge to the API work IMO is that it's currently not 
>> RESTful, 
>> and is quite difficult to make RESTful in a way that a Backbone 
>> collection can 
>> easily consume from. 
>>
>> Part of the challenge is that Jenkins' datamodel is much more of a tree 
>> than 
>> most front-end toolkits are familiar with, but when you add added 
>> functionality 
>> from the plugins, modeling becomes extra tricky. 
>>
>> I'm still of the opinion that a simple Backbone app + basic REST API 
>> exposing 
>> jobs, builds, basic details, would be more than enough for a large 
>> percentage 
>> of use-cases. Putting my code where my mouth is, isn't something I've had 
>> time 
>> for unfortunately. 
>
> - R. Tyler Croy 
>
>
> I get what Tyler means about the API but, for me, that does not mean we 
> could not use it for a client-side app (including using it in SPA 
> frameworks like backbone, angularjs etc).  Sure it would mean you can't use 
> some of the niceness (e.g. REST $resource in angular etc).  I'd say we'd 
> need to have a discussion about whether or not we should even use one of 
> those frameworks in something like Jenkins.
>  
>

-- 
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].
For more options, visit https://groups.google.com/d/optout.

Reply via email to