UI implementation: could it be made easier to modify?

[grosscol]

Or they could stop messing around trying to make some great shiny UI and just make a

Descriptive summary

From the recent experience of trying to modify the Sufia7 (pre-rc) UI to meet a specific institutions needs has been the desire for:

clean, simple, easy to use, pure Bootstrap UI without a million partials that looks good and is super easy to overwrite

Expected behavior

As simple as possible set of partials and css.

Actual behavior

A myriad of partials and difficult to wrangle css.

Examples

Are there partials that are not being used in more than one view? Are there easier ways to style the pages (e.g. not using ids to indicate style?)

Discussion to follow.

[front-endian]

I can go into details later about all the problems we are having creating a custom Sufia UI with Sufia 7, but the punch line is that it would be possible for Sufia to have a good looking UI that is easy to use AND easy to overwrite. However, this would require a direction shift in development.

If instead of creating very specific designs with custom CSS to implement them, Sufia could just use Bootstrap for all of its styles. The end result could still be a great looking website with a high degree of usability and accessibility. The difference would be that because there are no custom styles it, would be very easy to restyle Sufia if an institution doesn't want the out of the box look. I am generally not a fan of pure Bootstrap websites, but for Sufia it seems like a perfect fit.

A side benefit would be that this would make it a lot easier to maintain Sufia (no CSS means no CSS bugs to fix). UX work on Sufia wouldn't have to focus on design as much and could instead just focus on the workflows and a clean user experience.

In addition, fewer views and cleaner views with better HTML would be a big boon for institutions who want to modify or customize the UI. The current HTML is messy, has semantic problems, and accessibility issues. Cleaner HTML would also make styling easier. Example: <div id="footer"> instead of simply <footer> is both less accessible and harder to style.

[jcoyne]

Sure, we should do that! I don't think anyone is against making it easier.

Are there partials that are not being used in more than one view?

If so, they are often the result of an implementation wanting to override a specific part of the view. Here's an example: https://github.com/WGBH/hydradam/blob/wgbh-master/app/views/generic_files/_show_actions.html.erb#L13

We're looking forward to your contributions that would help realize this vision. :wink:

[front-endian]

After the UI group comes out with their recommendations we should have a thread discussing how the front-end can be architected.

[mjgiarlo]

I love the idea, @justcolin, and I suspect you'll find a lot of support for this work.

I'm copying some of the folks who've been active on the UI WG so they can comment: @mtribone @elrayle @sfbetz @hackmastera

[jcoyne]

Should this really be a ticket? What's the criteria for "done"? When can we close it?

[front-endian]

This issue could be used to discuss what customization other groups have requested/done, and closed once the necessary architectural decisions have been made, or at least discussed. Personally I'd want to talk through a number of things before jumping into the codebase.

It could also be good to discuss the possibility of writing up a simple set of front-end coding guidelines for all contributors to reference. It could be pretty generic but would help establish what sorts of things to look for before accepting a pull request.

I am also if curious members of the UI WG would be okay with a more generic/minimalist Bootstrap look.

[jcoyne]

I'm not on the UI working group, but my preference is for Sufia to look polished immediately upon installation rather than have a plain bootstrap looking site.

[jcoyne]

If you aren't a fan of the sufia UI, what is drawing you to use Sufia? Why not build your own UI using curation_concerns-models or hydra-works? I really am curious as to your motivation.

[grosscol]

@jcoyne Originally, CC didn't exist when the project started. Zotero, browse-everything, trophies, transfers, ect... There is a laundry list of features that Sufia6 covered. So going with Sufia was always the plan, but with the understand that the UI did not look how we wanted.

[hackartisan]

So I'm on the UI group. Discussion of partials has gone only so far as needed to wrangle wireframes into issues (which were required by our charge). CSS structure has barely been discussed at all. These strike me as implementation-level decisions and the number 1 priority in making them should be ease of customization. The UI group on the whole greatly values customization, often in the form of configurable options, but well-structured partials would also seem important here. At the same time, the UI group has worked really hard to identify an interface design that will work well for a large variety of use cases.

It's hard to tell whether Colin wants to make the structure of the code (partials, CSS) easier to work with or has issues with the wireframes that the UI group has released, or maybe both. Those seem like very different discussions so please do clarify!

[front-endian]

I haven't dug too much into the wireframes, but am agnostic about them. This issue is focused on the structure of and patterns in the templates and CSS.

As long as the UI group is okay with everything using standard Bootstrap styles rather than tweaking things to look one particular way, then UI group's designs shouldn't effect ease of customization.

If the UI group is not okay with everything have the standard Bootstrap look, a lot of care will have to be taken in the custom CSS.

[jcoyne]

@justcolin can you give a concrete example on how sufia is not a "standard Bootstrap look" I'm not sure I understand what you mean by that.

[grosscol]

A path that might be satisfactory would be to have the standard Sufia use as unmodified/styled bootstrap as it can, and have a separate generator for a more polished look. That would provide incentive to keep the base simple and maintain a state where the UI customization requires modifying the fewest number of files.

[jcoyne]

Wouldn't that make an upgrade that changes the views rather difficult?

[front-endian]

Basically every CSS style in Sufia and Curation Concerns is what I mean by non-Bootstrap. Bootstrap's styles are easy to overwrite and the class names make it clear what is what. It's all the custom code and messy templates that are kicking my butt.

Examples of problems we are encountering include:

• Extensive use of ids in selectors (the best practice now is is never use ids in CSS selectors, only use them for JS, because they are so specific they make further modifications harder)
• Overly specific selectors caused by deeply nested SASS (generally people now edge away from nesting SASS as much as possible since it makes it too easy to write overly specific selectors that are hard to build on top of)
• Custom typefaces used throughout (not needed to make the site look good, slows load time, and even if we overwrite those styles, the typefaces are still downloaded)
• Lots of tiny tweaks to margins, padding, etc (when used as a wholistic layout system Bootstrap has well formatted margins that are easy to overwrite)

[front-endian]

If Sufia used no custom CSS (which is possible), had cleaner/more semantic markup, with easy to latch onto classes for each element, it would be very easy to customize it and not have to worry about breaking other parts of the website.

The only custom CSS that may be needed are a couple overwrites to Bootstraps's classes/reset to improve accessibility.

[front-endian]

I'll whip up some more concrete examples once we get our site released, since the slapped together initial interface for that is currently sucking all of my time.

[jcoyne]

Those examples that you've given all seem like good ideas to pursue. May I suggest you make each one a separate issue? It's easier to understand what you're suggesting when you break it down that way.

[jcoyne]

Extensive use of ids in selectors (the best practice now is is never use ids in CSS selectors, only use them for JS, because they are so specific they make further modifications harder)

I think this is a trade off for performance reasons: https://css-tricks.com/efficiently-rendering-css/

[jcoyne]

Custom typefaces used throughout (not needed to make the site look good

I think the designer who required that font would probably disagree with you.

Anyway, you should be able to override this partial such that it isn't downloaded. https://github.com/projecthydra/sufia/blob/a27d14608916436d679c54d68f567cd5b6092a23/app/views/layouts/_head_tag_content.html.erb#L2

Then if we put in a PR such that $headline_font: 'Lato', Verdana, Arial, Helvetica; and use that variable throughout, that should give you a way to customize the font you want to use without making it backwards incompatible for other users.

[front-endian]

Heh, designers and I get into many disagreements over typography. Making it easier to pull out those styles by redefining that variable should be more than good enough.

As for CSS performance (apologies for the long rant that follows), improving CSS selector performance is not a concern:

• Browsers have improved a lot since that article was written. If you dig into the numbers you'll see that the performance benefits from optimized CSS selectors are insignificant, especially when compared to other improvements one could make.
• Were we to be concerned with CSS performance (which we shouldn't be unless we are making heavy use of transform, box-shadow, opacity, gradient, etc) the current selectors that use id's are not better for performance..

Without any performance concerns, many have settled on not using ids since they are infinitely more specific than classes. Once an id is used, you always need to use at least as many ids to restyle that element, which leads to longer and longer selectors. If you only use classes and write short selectors things tend to be a lot easier to overwrite and maintain. This is why CSSLint flags ids as a problem and why OOCSS and SMACCS only use classes.

[front-endian]

Later this week I should have time to break things down into more specific issues.

[jcoyne]

I think class based selectors are fine. Keep in mind that Sufia was initially created in 2011, so the browser world has changed a fair amount in that time and not all the code has been updated to modern standards. Thanks for providing some articles to support your reasoning.

[mtribone]

I think that putting together some guidelines for HTML/CSS is a good idea. HTML and CSS are always in flux and collectively we may all not be writing the same way. In the past we've tried to make small, manageable changes to not overwhelm current adopters. And since we've had these epic jumps for the past couple years with features, features, features, we have yet to really tackle bloat or a lot of UI refactoring. There was a time when Sufia had 120 columns and each column was 8 pixels.

If we want Sufia to be a little more on the default side, I'm all for it. However, I'd like to know a little more about how it may affect other institutions who don't have the resources to customize. I haven't looked at how Sufia 7 has been coded just yet, but along the lines of what @justcolin is expressing we could take a heavy look at the views and their HTML/CSS to improve the code, customization, and accessibility. I think that everyone is just trying to get to green because so many people want this thing.

And @justcolin +1 for breaking down the issues based on your experience.

[mjgiarlo]

This is an excellent discussion, all, and I want to heartily :+1: the idea of breaking this down into multiple smaller, bite-sized issues. (I don't think any of us have cycles for another big release.) Thanks, y'all.

[front-endian]

Before I break this up into smaller requests: are we okay with the fact that many of these changes will break the view/stylesheets customizations for any existing sites Sufia 7 or Sufia 6 sites which update? It would be very hard—if not impossible—to get the views/stylesheets to meet contemporary standards without some more serious rewrites.

My two cents: given the fact that the UI group is coming up with new wireframes, I think most would expect their old views/stylesheets to not work anymore. At U-M we are treating our current Sufia 7 views/stylesheets as temporary patches until either Sufia's core stuff is improved or we do a total rewrite.

On Feb 22, 2016, at 12:09 PM, Michael J. Giarlo notifications@github.com wrote:

This is an excellent discussion, all, and I want to heartily the idea of breaking this down into multiple smaller, bite-sized issues. (I don't think any of us have cycles for another big release.) Thanks, y'all.

— Reply to this email directly or view it on GitHub.

[mtribone]

@justcolin I'm certainly good with the breakage for ScholarSphere. :+1:

[front-endian]

@mtribone: Great!

If no one else has objections to these changes causing views to break for existing Sufia installs that upgrade I'll start creating separate issues.

[mjgiarlo]

And as product owner, I give you my official blessing to take this further. May be worth discussing during a Hydra Tech call, or proposing to the hydra-tech mailing list once the idea has been fleshed out a bit more to give more folks a chance to sound off?

[mtribone]

@mjgiarlo @justcolin Yeah it would be good to hear from others about how/if it would impact their IR. I am looking forward to the work. Sufia 7 is going to be a big jump for folks, but perhaps this is the time to draw the line.

[mjgiarlo]

This was decomposed into more granular issues, which now should be made actionable. Closing this epic issue.