RFC: Consistent UI with Katello

Hugh O. Brock hbrock at redhat.com
Tue Apr 3 14:41:10 UTC 2012


On Tue, Apr 03, 2012 at 03:08:51PM +0200, Jan Provaznik wrote:
> On 04/02/2012 11:04 PM, Matt Wagner wrote:
> >Hi all,
> >
> >Please take a look at this feature page:
> >https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Shared_UI_with_Katello
> >
> >It describes our efforts to develop a common look-and-feel with Katello.
> >Katello is sort of a sister project of ours, but right now we're more
> >like distant relatives that have only met a couple times at family
> >reunions. This feature describes our efforts to implement a common UI.
> >
> >I've broken this task out into three rough "phases" which you may have
> >seen referenced elsewhere:
> >
> >1.) Add a common header and footer that looks similar to the one Katello
> >is using. This is a quick (FSDO "quick") cosmetic similarity only, and
> >is tracked by #3066. I hope to have it wrapped up this week. There is a
> >screenshot of this at the bottom of the linked wiki feature page. (It
> >somehow got named "50.png")
> >
> >2.) Actually use the common template, so that our layout is consistent.
> >Katello does use HAML and SASS and whatnot like we do. Nonetheless, I
> >expect this to be a larger undertaking. This is hopefully in scope for
> >the next major (several-month) iteration that is coming up. We should
> >also pay attention to planning for Phase 3 at this point.
> >
> >3.) After we are using the common template, we want to move things over
> >to an actually-shared repository / package with Katello. We will
> >hopefully be using consistent stylesheets, graphics, JavaScript, and
> >possibly even a common application.haml. (We will, of course, have local
> >overrides for Conductor-specific tweaks.) The intention is to separate
> >this out as an RPM that we both depend on, and to use git submodules for
> >local development. If done right, this should eliminate duplications and
> >inadvertent deviations from common standards, but still leave us the
> >flexibility to do things differently when we want to do so on purpose.
> >This is likely to be a long-running task and might not be in place for
> >the next major iteration, though I do think it lends itself to small
> >steps.
> >
> >The wiki page on this is still a little bit sparse; I'm kind of curious
> >what people think should be expanded upon. I do have more subtasks
> >entered for #3030; see https://www.aeolusproject.org/redmine/issues/3030
> >if you're so inclined.
> >
> >-- Matt
> 
> One delicate question:
> Katello's UI doesn't work w/o JS. What is the plan about this? I
> believe both projects should choose same strategy about this
> (whatever option is chosen) - it doesn't make sense to support
> unobtrusive JS in Conductor if Katello will not support it.
> 
> This is probably more management question, but it would be nice to
> get answer sooner than later. Also because non-JS support affects
> controllers design, and there will be some changes in controllers
> soon because of API implementation.
> 
> Jan

I firmly believe non-JS support should continue to be a hard
requirement for us, both for US Govt. accessibility requirements and
because it's good coding practice.

Having said that I am also absolutely certain that we will not have
scope for that level of change to the Katello UI over the next year,
given the rest of the issues on the agenda. So I think we'll have to
live with the difference until then (which is really more or less OK,
given that we don't really know what shape the combined app will take
over time).

Take care,
--H

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey



More information about the aeolus-devel mailing list