Concerned about what's being lost in the de-branding of hydrangea

[Matthew Zumwalt]

Hello Hydra-UI group,

We've run into something that requires the attention & discussion of the Hydra UI group (that's you).  I apologize for the length of the email, but I want to give you all of the information I can.

I'm sending this email to the Hydra UI list because it deals with an area where I hope to rely on your perogative as the Hydra UI experts.  My best case scenario would be if you all tell me there's no need to worry and that I can tell projects like Hydrus and Hypatia  to proceed with the code base as it's currently configured.

Here's my concern: Much of the motivation for merging the Libra code back into Hydrangea was because Hydrangea looked clunky & incomplete while Libra looks clean and polished.  Looking at the debranded branch, I see all of the old clunky un-polishedness restored and none of the Libra polish retained.  I wonder if we've hosed 2 months of UI cleanup (and some page load optimizations) unnecessarily.

Before going into detail, I want to thank Jessie who sacrificed the majority of this past weekend working on removing the UVa branding from Hydrangea.  The commit logs on the debrand_uva branch on github are a testament to how much work he put into this.

The basic problem here is that the only directive that Jessie had to work from was "remove the UVA branding", which translated to "make it look like Blacklight again".  I don't think that's actually what we wanted to achieve, but it didn't occur to any of us that we should stop and define what we do want.

I've retained two branches in the Hydrangea git repository -- one with the UVA branding intact and one "debranded".  A side-by-side comparison is pretty stark. I will try to spin up a server with both versions of the code deployed for you to look at.  In the meantime, I'm attaching screenshots with "branded" and "debranded" versions of otherwise identical pages from hydrangea. 

We need a clear declaration of what aspects of the polished Libra UI should be retained in Hydrangea and which should be removed.  Depending on what you decide on this, we might have to back up and re-do the debranding that Jessie has already put substantial time into.  If we are going to back up and re-do the debranding, we need to know that ASAP.  With multiple teams blasting forward on post-libra code bases, every day that passes makes it harder to back out of this.

Please tell me there's no need to worry.  That would make things much easier.

Matt Zumwalt

MediaShelf, LLC

http://www.yourmediashelf.com

[Garrick Van Buren]

Matt,

Thanks for this message.

One of the challenges I continually bump up against in implementing a hydra head is getting the presentation layer to something that looks consistent with the rest of the sponsoring organization's web apps. 

Overall - Libra is in line with Virgo (UVa's other Blacklight app). Not the same - though you can tell - at a glance - they're from the same organization. Neither look like default Blacklight installs.

While hydrangea makes it very straight-forward to align the application logic and models with the project goals, doing the same on the presentation side is less so with the presentation layer. To achieve the same level of efficiency on the presentation layer - we need a blank, white, and otherwise plain, hydrangea theme. This theme should override all the implementation-specific branding (like Libra) as well as and project-specific branding (Blacklight).

Removing the UVA-specific colors, images, and messaging from Libra's should get us 90% of the way to this clean slate theme.

--

Garrick.

<branded- libra-oa:1 - Hydrangea_edit.png><branded- libra-oa:1 - Hydrangea_show.png><branded-Hydrangea_search_result-addwork.png><branded-Hydrangea_search.png><debranc- libra-oa:1 - Hydrus_edit.png><debranc- libra-oa:1 - Hydrus_show.png><debrand-Hydrus_search_result.png><debrand-Hydrus_search.png>

[Dan Brubaker Horst]

Matt,

I agree with Garrick that the desired effect of removing the UVa
branding from Libra would be more subtle than what is present in the
debrand_uva branch.

On the whole the Libra-derived views in the post-libra master branch
look much more refined than what was previously present in hydrangea.
For example, I much prefer having large forms be enumerated by step
rather than cramming the page into an accordion control.

I was hoping that the UVa specific styles would be extracted to create
a "clean-slate" while keeping the existing Libra-derived views largely
intact. If it would be helpful I would be happy to take a crack at
de-branding the current master branch to demonstrate what I mean.

-dan

[Jessie Keck]

Ok, I think that's fine.

The work that I did was really in two parts (although now that I look I interweaved these in the same commits).
1) Migrate all JS/CSS to plugins' assets.
2) Make the app look like Blacklight.

The work that I did to get the app to look like Blacklight was actually relatively small. The main components of that change was to remove the overridden application.html.erb file which in turn removed the loading of the CSS in the uva directory.

I think if we add that file back in (although I don't really recommend it) and then load the CSS in the uva directory the correct way then we should get back most if not all of the style in that debrand_uva branch.

This will allow us to retain both the UVa look and the work I did to migrate the CSS/JS to plugin assets.

Any thoughts? Should I just give this a go and see what happens? If yes, in which plugin does the uva css directory logically live?

- Jessie

[Garrick Van Buren]

I think the css file within the uva css directory should be re-named to something like: 'clean_slate.css' or 'plain.css' and be added to the assets directory of the primary plugin (hydra_repository ?).

Assuming placement in that plugin will cause this CSS file to effectively override any other styles in the base app.

--
Garrick.

[jcmeloni]

Hi -

Just wanted to offer some clarification or perspective on a few
points. These may or may not be useful for the discussion but I feel
(annoyingly) strongly about keeping these in focus because I know how
it's affecting our _own_ development.

First, I'll reiterate what I've said for a while now: we're not
finished with Libra development. We won't be in production until the
end of this month (which is only 2 weeks from now), and we are
actively working on little else besides Libra in our group right now
because there's a lot to do. What we're doing is evenly split
between:

a) optimizing and fixing several bits of functionality that were
broken or problematically unoptimized in the hydramerge branch that
Matt et al eventually wrestled into what's now Hydrangea (things like
file upload, permissions, embargo checks, etc -- not trivial or UVa-
specific)

b) UVa-specific UI refinement, and

c) additional features that might be UVa-specific or might not be,
pending later discussion with the group.

As I've said before, it was always our intention -- after we went into
production -- to begin the unbranding process, to rethink the
construction of the presentation layer (period), and to outline in
detail what we added or modified from the original Hydrangea so as to
discuss and determine additional features to contribute back to the
core. I also (still) recognize that Hydrus and Hypatia projects have
schedules that must be adhered to as well, but I'm looking ahead to
just how much work will be going back in and backtracking -- again --
just in a few weeks.

This is basically what Matt said himself: "With multiple teams

blasting forward on post-libra code bases, every day that passes makes

it harder to back out of this"...which is exactly my point except for
us it's not post-Libra -- it's just Libra, the thing that was supposed
to be a reference implementation _when we were into production_.

Or, as one of our developers said, he's foreseeing a near-future in
which he'll be overriding an old version of his own current work. It
just doesn't make a lot of sense to us, given resource constraints.
(to Matt's comment , " I wonder if we've hosed 2 months of UI cleanup
(and some page load optimizations) unnecessarily," our answer would be
"yes, pretty much, which is what we were going to try to avoid in a
few weeks.")

But that's neither here nor there at the moment, as we are essentially
ignoring everything (not that you all aren't lovely or we don't care
about you -- we do) that is not our current work on an already late
deliverable (e.g. first release of production Libra).

- Julie

Julie Meloni
Lead Technologist/Architect, Online Library Environment
University of Virginia Library
jcme...@virginia.edu // 434-243-1974


On Mar 17, 12:41 pm, Garrick Van Buren

> >>> Hydrangea_show.png><branded-Hydrangea_search_result-addwork.png><branded-Hy drangea_search.png><debranc-

[Jennifer Vine]

Matt said:

> The basic problem here is that the only directive that Jessie had to work from was "remove the UVA branding", which translated to "make it look like Blacklight again". I don't think that's actually what we wanted to achieve, but it didn't occur to any of us that we should stop and define what we do want.

Yeah, that.

My understanding was the same as Julie's - that we were going to wait until they had finished doing what they're doing, and then slide that most of that work back into Hydrangea. Visually, de-branding Libra could be almost as simple as stripping the header and footer.

Jessie is looking into re-applying the UVA styling for now, to see if we can regain the visual finesse without losing the other work he's done. But we still want this (from Julie's response):

> a) optimizing and fixing several bits of functionality that were
> broken or problematically unoptimized in the hydramerge branch that
> Matt et al eventually wrestled into what's now Hydrangea (things like
> file upload, permissions, embargo checks, etc -- not trivial or UVa-
> specific)

and how do we get it? It feels like we're doing a lot of stuff twice (or more).

JV

[Matthew Zumwalt]

I think I see a way to proceed.  

A primary motivator for the preemptive merge from Libra was to get the "clean slate" stuff that makes it easier to apply your own brand to the hydrangea code.  Based on Garrick's email, it sounds like most of that stuff is in a single css file that might eventually be called plain.css or clean_slate.css.

Here's my proposal:

# Jessie has patched the debrand_uva branch, restoring the UVA branding while retaining the work of moving all of the contents of the "public" directory down into plugin assets directories. I will apply that to hydrangea/master

# Once we have that in hydrangea/master, Garrick will take a look at removing the UVA logos, copyright, etc. and knocking the css styling back to a "blank" but tidy page.

These two steps give us something to safely proceed with for the next 6 weeks.

When Julie's team has Libra in production, they will then rearrange and debrand the Libra code.  While this sounds like a repetition of work, it's actually a new round of work.  As Julie mentioned, they are still working on many fixes to the javascript, html, and css.  We have a much clearer path for absorbing those fixes because they will only need to apply 1 month worth of changes rather than 5 months worth.

When the new Libra contributions are ready, I will work with them to apply those updates to the appropriate plugins and merge them into the shared code bases.  Jessie's work from this week will give us the initial indicators of where to move files to.  

Thanks to a helpful git tool, it will be relatively painless to apply the new Libra changes in six weeks, even if we have already updated the plugins to use Rails3 by then.

In the meantime, this group should work towards a clear resolution about what aspects of Libra we do & don't want to absorb.  We also need some resolution about how we want to be able to customize and brand Hydra UIs.  For example --

* Do we want to retain a Hydra application.html.erb that overrides the Blacklight application.html.erb?  

* Should we use YUI for grid layout?  Should we use a different framework?

* Do we want the plugins to retain their own copies of javascript libraries (ie. JQuery) or do we rely on the Hydra head to provide its own libraries in the public folder?

* To what extent do we want to rely on Blacklight?

* To what extent to we want to contribute code back to Blacklight that facilitates skinning/rebranding?

* How should edit views be segmented by default?  Should they have an accordion?  If so, how should it be styled?

Matt Zumwalt

MediaShelf, LLC

http://www.yourmediashelf.com

[jcmeloni]

Hi –

I’m cc’ing Tom on this because at some point he was dropped off the
conversation and quite frankly all of these issues affect Stanford
most directly at this moment in time – because the primary reason you
guys jumped on this merging thing way before _I_ would’ve been
comfortable doing it was to meet requirements for projects for which
MediaShelf is contracted.

I’m not going to keep repeating myself, except for this one last time:
the work we’ve done since you created hydramerge in mid-Feb is not
simply javascript, html, css; we’re still working in hydramerge right
now, actually, and not our own master, so you can see what we’ve done
in order to make core functionality of the app simply work as expected
(https://github.com/uvalib/libra-oa/commits/hydramerge) with a pretty
healthy list of things to fix in the next few days that are not simply
presentation (http://bit.ly/hBU6ZW).

I would assume Stanford and everyone else would want those things in
Hydrangea. We want them in Hydrangea. We will begin to look at code
rationalization and integration when we’re through. Knowing that our
time table is different than Stanford’s, waiting on us to do that is
not feasible. But starting from a point in the code a month ago won’t
get a good app out the door without a lot of pain. There’s a
middleground, somewhere, that Stanford folks should find for
themselves, armed with all the information and code.

As to the questions about general Hydra UI needs and needs
assessments? Yes, all good questions. But I know I can’t devote a
moment of thought to answers _for the group_ because we are neck deep
in simply trying to pull together a functioning application.

Believe me, I’m not trying to be contentious here. Not at all. I just
think that there’s some serious underestimation going on here – of the
codebase, of the work to be done, etc, and the right people – the
people whom it fundamentally affects _right now_ aren’t really having
a voice in this besides Jennifer’s very clear and direct questions
from earlier.

And now I will stop. For reals.

- Julie


On Mar 17, 7:14 pm, Matthew Zumwalt <matt.zumw...@yourmediashelf.com>
wrote:

> I think I see a way to proceed.  
>
> A primary motivator for the preemptive merge from Libra was to get the "clean slate" stuff that makes it easier to apply your own brand to the hydrangea code.  Based on Garrick's email, it sounds like most of that stuff is in a single css file that might eventually be called plain.css or clean_slate.css.
>
> Here's my proposal:
>
> # Jessie has patched the debrand_uva branch, restoring the UVA branding while retaining the work of moving all of the contents of the "public" directory down into plugin assets directories. I will apply that to hydrangea/master
>
> # Once we have that in hydrangea/master, Garrick will take a look at removing the UVA logos, copyright, etc. and knocking the css styling back to a "blank" but tidy page.
>
> These two steps give us something to safely proceed with for the next 6 weeks.
>
> When Julie's team has Libra in production, they will then rearrange and debrand the Libra code.  While this sounds like a repetition of work, it's actually a new round of work.  As Julie mentioned, they are still working on many fixes to the javascript, html, and css.  We have a much clearer path for absorbing those fixes because they will only need to apply 1 month worth of changes rather than 5 months worth.
>
> When the new Libra contributions are ready, I will work with them to apply those updates to the appropriate plugins and merge them into the shared code bases.  Jessie's work from this week will give us the initial indicators of where to move files to.  
>
> Thanks to a helpful git tool, it will be relatively painless to apply the new Libra changes in six weeks, even if we have already updated the plugins to use Rails3 by then.
>
> In the meantime, this group should work towards a clear resolution about what aspects of Libra we do & don't want to absorb.  We also need some resolution about how we want to be able to customize and brand Hydra UIs.  For example --
>
> * Do we want to retain a Hydra application.html.erb that overrides the Blacklight application.html.erb?  
> * Should we use YUI for grid layout?  Should we use a different framework?
> * Do we want the plugins to retain their own copies of javascript libraries (ie. JQuery) or do we rely on the Hydra head to provide its own libraries in the public folder?
> * To what extent do we want to rely on Blacklight?
> * To what extent to we want to contribute code back to Blacklight that facilitates skinning/rebranding?
> * How should edit views be segmented by default?  Should they have an accordion?  If so, how should it be styled?
>
> Matt Zumwalt

> MediaShelf, LLChttp://www.yourmediashelf.com

> >>> Hydrangea_show.png><branded-Hydrangea_search_result-addwork.png><branded-Hy drangea_search.png><debranc-

> >>> libra-oa:1 - Hydrus_edit.png><debranc- libra-oa:1 -
> >>> Hydrus_show.png><debrand-Hydrus_search_result.png><debrand-Hydrus_search.pn g>
>

[Garrick Van Buren]

* Do we want to retain a Hydra application.html.erb that overrides the Blacklight application.html.erb? 

* Should we use YUI for grid layout?  Should we use a different framework?

With Blacklight and its application.html.erb being YUI-based, these questions are very related. From the perspective of a clean slate / blank theme, I think there are approaches:

a) support YUI in Hydra as part of the blank theme, include a brief README_YUI on how the YUI classes are used specific to Hydra. The benefit is that Blacklight uses it so, Hydra might as well. And if we are - let's make sure we can help people use it better as well.

b) retain a Hydra-specific blank theme application.html.erb file without the YUI. The benefit here is applying a non-YUI-based existing look-and-feel. 

I don't have a clear sense of which of these 2 options would serve Hydra better long term. My bias is for the latter.

* Do we want the plugins to retain their own copies of javascript libraries (ie. JQuery) or do we rely on the Hydra head to provide its own libraries in the public folder?

I think the core javascript libraries should be retained in hydra_repository (assuming all Hydra heads will need at least hydra_repository_

* To what extent do we want to rely on Blacklight?

Matt could you rephrase this question?

* To what extent to we want to contribute code back to Blacklight that facilitates skinning/rebranding?

When Blacklight updated a month or so back it necessitated CSS changes in Hydra as well. I think it could benefit both projects to have a blank slate theme available - if not as a default. 

* How should edit views be segmented by default?  Should they have an accordion?  If so, how should it be styled?

I think all views should be as minimally styled as possible (white background, black test, blue links, etc). Accordions and other similar elements seem like implementation-specific UI decisions that don't belong in the blank slate version. 

--

Garrick.

[Tom Cramer]

Julie's outline of the changes that have gone into Libra relative to November's Hydrangea is helpful:

a) optimizing and fixing several bits of functionality that were broken or problematically unoptimized in the hydramerge branch that Matt et al eventually wrestled into what's now Hydrangea (things like file upload, permissions, embargo checks, etc -- not trivial or UVa-specific)

b) UVa-specific UI refinement, and 

c) additional features that might be UVa-specific or might not be, pending later discussion with the group.

In all three cases, even b) it seems to me, Libra is more refined and more advanced than Hydrangea, and represents a better starting point for us than Hydrangea. Given that Libra development isn't done and isn't going to be done imminently, that Hydrus & Hypatia development are already underway or need to start posthaste, it seems to me that starting from Libra in its current form now is, while not ideal, the best option before us. 

Wrt to b. the UVa-specific UI enhancements, I think they are unquestionably a step ahead of Hydrangea's. While there are some details and directions to sort (accordion, e.g.), to me I'd like to use even unfinished Libra as a starting point--as Jennifer says, "Visually, de-branding Libra could be almost as simple as stripping the header and footer." 

I guess this is a long way of stating that since we can't stand still, and we have to start somewhere, it makes sense to me to ride Libra's coattails for now, even as they are still in the process of being sewn... While this may mean two merges instead of one to get the best of Libra into Hydrus & Hypatia, at least the second one should be quicker & cleaner than one big, deferred merge might be. 

- Tom

On Mar 17, 2011, at 4:58 PM, Meloni, Julie (jcm7sb) wrote:

Hi –

 

I’m cc’ing Tom on this because at some point he was dropped off the conversation and quite frankly all of these issues affect Stanford most directly at this moment in time – because the primary reason you guys jumped on this merging thing way before _I_ would’ve been comfortable doing it was to meet requirements for projects for which MediaShelf is contracted.   

 

I’m not going to keep repeating myself, except for this one last time: the work we’ve done since you created hydramerge in mid-Feb is not simply javascript, html, css; we’re still working in hydramerge right now, actually, and not our own master, so you can see what we’ve done in order to make core functionality of the app simply work as expected (https://github.com/uvalib/libra-oa/commits/hydramerge) with a pretty healthy list of things to fix in the next few days that are not simply presentation (http://bit.ly/hBU6ZW).

 

I would assume Stanford and everyone else would want those things in Hydrangea. We want them in Hydrangea.  We will begin to look at code rationalization and integration when we’re through.  Knowing that our time table is different than Stanford’s, waiting on us to do that is not feasible.  But starting from a point in the code a month ago won’t get a good app out the door without a lot of pain. There’s a middleground, somewhere, that Stanford folks should find for themselves, armed with all the information and code.

 

As to the questions about general Hydra UI needs and needs assessments? Yes, all good questions.  But I know I can’t devote a moment of thought to answers _for the group_ because we are neck deep in simply trying to pull together a functioning application.

 

Believe me, I’m not trying to be contentious here. Not at all.  I just think that there’s some serious underestimation going on here – of the codebase, of the work to be done, etc, and the right people – the people whom it fundamentally affects _right now_ aren’t really having a voice in this besides Jennifer’s very clear and direct questions from earlier.

 

And now I will stop. For reals.

 

- Julie