Bigger buttons

[MBSchneider]

Lindsay had wanted the links to display as buttons for:

• Organizations 'create' action
• Venues 'create' action
• Organization show page actions 'Show Linked Calendars' and 'Link a New Calendar'

My thought was just to classes in the Sass files to style like buttons - let me know if that's a good way to go, or if there is a better way to do it.

[mbijon]

Looks like the right way to do it with CSS styles.

But this is almost the same code just copied 2x into different parts of the
CSS libs. What happens if we want buttons elsewhere, or to move these links
to other sections of the app?

To accommodate that it might be better to put these styles into a new .btn
class in the app-wide SCSS. Then we can apply button styli g to links
anywhere & only have one copy of this code to load.

[dhedlund]

This is one of those tickets where doing a set of buttons that look nice in context of where they're placed is going to be difficult. On the sidenav specifically, there is limited room horizontally; any text that wraps due to the buttons will have lines spaced too far apart. It looks mostly okay for a "create" button (as you've implemented) because none of the text wraps, but it would look bad if this was done on any of the show pages where there are multiple actions.

I'm also not sure that this ticket is necessary once there's a subnav row for navigation similar to what calagator.org has. This navigation was started as part of commit c2dab8d but later reverted as feedback suggested additional UI design was necessary and I ran out of creative momentum (see the with_subnav branch).

Technical Feedback

• Avoid using new fonts unless you're introducing something that needs to stand out differently. Lucida Grande is only available on OS X and Safari and doesn't have any fallback font families listed.
• Nit: Try to use #hex colors instead of rgb(...) if possible for consistency with the rest of the stylesheets unless you need to introduce an alpha channel.
• It's almost impossible to use CSS to emulate a button consistent with native buttons across each browser. It might be possible to just change these links to be buttons in the view code, but I would recommend this as a last resort (see theming reasons in my comment below). Font size/family/color aside, the color of the new buttons are quite a bit darker than the real buttons for me in chrome and are a completely different color than the newsletter signup button in Firefox (but that's because I use a dark color scheme which inverts the colors of my buttons in Firefox -- just pointing out how much they change). The only way to really get consistency is to explicitly set all of properties for both the native buttons and fake buttons, including foreground, background, gradients, etc. Even then, some browsers might prevent you from overriding some properties. I can push your changes to to the staging environment if you want to do any cross-platform browser testing to verify button styling.

@mbijon The way I structured the CSS and views does not really lend itself well to global CSS classes that tag elements for styles (i.e. "add .btn to make it look like a button"). It's structured so the classes and IDs help describe the structure of the document. The reasoning behind this was so that we could more easily reuse view files across multiple themes by only overriding the CSS which is an asset, packaged and delivered separately to the HTML / view code. In this case, another theme (i.e. calagator) might not want the links to look like buttons, which would require knowing and overriding all of the button props to undo the styling. The equivalent of what you're suggesting could be done with sass/scss mixins though. I did not make very good use of mixins when building out the CSS; this is something that could definitely be improved on.

[mbijon]

@dhedlund, I agree with your goal of abstracting appearance and structure. That would support distribution of theme-like CSS bundles so people can customize & share frontend UI better.

...but I'm not sure :class => 'action-btn' + the styles duplicated to .show-sources, .add-source meet your goal either. The former is close to my general .btn class, while the 2nd uses a specific class like you're aiming for.

How about?

Adding a class .action-link that gets applied to all links of this type through the whole site? (including .show-sources, .add-source) Then the styles by @MBSchneider could be de-duped & more easily removed, extended, customized by site owners by either adjusting the styles or removing a semantic but more-general class.

Or, instead of .action-link, name that class something like .wiki-actions-add. Then that + .show-sources, .add-source would semantically match each per-link case.

---

Any thoughts @MBSchneider? I think the 2nd option would just mean renaming one of your styles & get this done faster.

[dhedlund]

@mbijon Sounds good to me.

[MBSchneider]

Thanks for all the feedback!

This sounds good - I think I know what you're getting at. I'll be in with
Lindsay most of the day tomorrow to work on ActivateHub stuff, so I'll put
that together and send a pull request.

On Thu, Apr 10, 2014 at 9:30 PM, Daniel Hedlund [email protected]:

@mbijon https://github.com/mbijon Sounds good to me.

Reply to this email directly or view it on GitHubhttps://github.com//pull/76#issuecomment-40169924
.

Matthew Schneider
LinkedIn: www.linkedin.com/in/mbschneider
[email protected]
(206) 276-7942