On 02/23/2015 03:43 PM, Ralph Bean wrote:
On Wed, Feb 18, 2015 at 08:27:56AM +0530, Ratnadeep Debnath wrote:

On Tue, Feb 17, 2015 at 11:28 PM, Ralph Bean <rbean@redhat.com> wrote:
The demo is up on my website[1].

We have tons of apps run by Fedora Infrastructure and a long-time
complaint is that they have inconsistent theming, and no chrome that
ties them together -- that makes them look like they're all part of
the same thing.  Theming them consistently or adding a unifying chrome
would be awesome, but a very challenging and time-consuming task.
The way to go about will be to have base templates and static files as
a separate repository, where all the consistent look and feel related
work (navbar, forms, footer, etc.) goes.
Other projects can add this repo as a submodule and extend and
customize it as needed.
That would be awesome.  I agree that it's the right technical
solution.  There's a social element to the problem though, that we
all of our app developers haven't been able to settle on a common set
of tools, libs, and frameworks.  Some of us use bootstrap, some of us
use a 'koji.css' file that's been passed around, the qa-devel group
uses Zurb Foundation.. etc (we use different template engines as well.
Some jinja2, some mako, there are others).

Yeah, this is pretty much the big issue here. Just observing, it seems that a lot of the new stuff going forward is beginning to use bootstrap, so having a theme for that might be the way to go. For all the other stuff, having a implementation somewhere that we can "fork" and keep with the other apps might be the way to go. This will be a maintainece nightmare, but it really is the best way to go, IMHO.

If we force the apps to fit the theme, it makes the templates and other app code more unmaintainable, so my theory here is to take the unmaintainabilty hit in the CSS, as we can at least see "visually" if an app looks like what we want.

Also, very interested in getting this consistent look and feel working -- It might be a good first step here to try to identify what apps we are talking about, and what backends / templating systems they use.


Like I mention below, the hope with the prototype menu is that it can
be lightweight enough that it can work unintrusively in all those
environments -- that it can provide *some* commonality without trying
to force all these different development groups to make changes
they're unwilling to make.

This little prototype is an attempt at making a single line of
javascript that we could include in each app to add a floating button
that pulls up a menu taking you to other Fedora apps.  It could
potentially display other information like "how to join!" and "don't
forget to book your tickets for Flock!" and.. etc.  It falls short of
a unifying chrome, but I tried to make it simple enough that it won't
collide with the layouts and style of other pages.. something we could
actually deploy without exhausting ourselves.
The menu indeed looks nice. However, I have some concerns regarding
how new users will perceive it. Usually people are used to navbars and
sidebars in most websites. I think our menu content is much similar to
the navbar content at http://www.myntra.com/, top level menu items and
sub items for each top level item. http://www.myntra.com/ has
implemented the navbar with a lot of data in a very elegant way. We
can load the navbar as a separate snippet from our CDN. The cache in
the CDN gets invalidated and updated with changes happening for
Cool.  To get it work as a navbar at the top we'd have to be able to
get it to play nicely with all the other nav bars that all our other
apps have built-in already (they almost all have a navbar at the top
already, so we'd have to insert our DOM elements above it or.. do
something fancy).  I'm afraid it would break, but I'll try and mess
with it and see if I can come up with something.  I used the
'bottom-left' corner for the little button on this because I couldn't
think of a Fedora App that's using that real-estate for anything

design-team mailing list