Closed Bug 727927 Opened 12 years ago Closed 12 years ago

[One Mozilla] Review "Sandstone" Mozilla Websites' Style Guide

Categories

(www.mozilla.org :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: christine.brodigan, Unassigned)

References

()

Details

Attachments

(2 files)

Opening this bug to gather feedback on Sandstone, before assets are committed for Phase 1., for webdev, ux, product, website teams, and eventually community members to use.

Meet Sandstone: http://people.mozilla.org/~smartell/sandstone/

Goal: Provide your feedback, including recommendations for CSS, items not included, items included that you have questions.

Needed: someone from each team to review and provide feedback -

UX
Product
WebDev 
Websites
WebProd

Anyone else?

Since there are so many reviewers, a note on feedback:

This is a first pass at a big audacious solution, and the hard part is ahead as we pushing through, improving glacially, scraping on to see what might happen around that corner ahead.

Your feedback will lead the team out of a thicket, optimism intact. We appreciate that!
This might be nit-picking, but since we seem to be using LESS anyway (YAY!) we could do better than having a grid that requires totally non-semantic classes like ".one-col" and ".gutter-bottom-48" and ".mozilla-red" by using mixins.

See http://semantic.gs/ for a great example. It allows you to have nicely presentational things in your CSS, while reducing repetition and making grids easy, but not requiring presentational classes to leak into the HTML.
(In reply to James Socol [:jsocol, :james] from comment #1)
> This might be nit-picking, but since we seem to be using LESS anyway (YAY!)
> we could do better than having a grid that requires totally non-semantic
> classes like ".one-col" and ".gutter-bottom-48" and ".mozilla-red" by using
> mixins.
> 
> See http://semantic.gs/ for a great example. It allows you to have nicely
> presentational things in your CSS, while reducing repetition and making
> grids easy, but not requiring presentational classes to leak into the HTML.

Don't go by my hack job of a page for how the framework should be implemented. :)  The intent was to show the website for the framework we're going to be using so if there was an urgent need to make a site responsive it could be done before everything is set in stone. The Less CSS is still being worked out.
(In reply to Sean Martell from comment #2)
> Don't go by my hack job of a page for how the framework should be
> implemented. :)  The intent was to show the website for the framework we're
> going to be using so if there was an urgent need to make a site responsive
> it could be done before everything is set in stone. The Less CSS is still
> being worked out.

Ah, OK. The site made it sound like the decision to use the Less Framework had already been made, and its insistence on things like '.bigger' bugs me. It also seems to have been replaced by Frameless: http://framelessgrid.com/
The grid has been chosen and is what all our PSDs are being built on going forward, so yes that has been chosen, but we're making our own Less CSS system of tags.
(In reply to James Socol [:jsocol, :james] from comment #3)
> Ah, OK. The site made it sound like the decision to use the Less Framework
> had already been made, and its insistence on things like '.bigger' bugs me.
> It also seems to have been replaced by Frameless: http://framelessgrid.com/

We have looked at the frameless grid too, but I think we're ok with the Less grid. It's not even really a CSS framework - it's just a suggested set of column sizes. There's not even really any meaningful code provided.

I do love the idea of adding the column sizes as LESS mixins though - I'm working on the LESS implementation and will try that.
As someone who'se got an interest in design & type, but is very much not capable of executing, I'm excited about the possibilities here!

I have a few questions which I think are primarily documentation questions:

 - Twitter's bootstrap is all the rage, and I expect has influenced this project.  It'd be good I think to a) acknowledge the heritage if it exists, and if it isn't acknowledge the co-occurence -- this work isn't being done in a vacuum; b) explain why bootstrap is or isn't used, or what the differences are between Sandstone's ambitions and Bootstrap's.

 - In particular, Sandstone seems to be focusing on "websites" rather than webapps (e.g. fewer widgets), and seems to be a from-the-ground-up effort -- which means that people like me who love to use existing design templates are going to ask questions about "when can we expect such-and-such".  So understanding the roadmap would be useful.

 - totally subjective and ill-informed feedback, take it for what it costs: i really like Open Sans, but the serif body typeface doesn't feel like it 'fits' -- maybe i just need to get used to it.
Thanks for the feedback!

>  - Twitter's bootstrap is all the rage, and I expect has influenced this
> project.  It'd be good I think to a) acknowledge the heritage if it exists,
> and if it isn't acknowledge the co-occurence -- this work isn't being done
> in a vacuum; b) explain why bootstrap is or isn't used, or what the
> differences are between Sandstone's ambitions and Bootstrap's.

The Bootstrap vs. Less Framework choice was discussed before we finally decided on an in-house baked Less Framework / Less CSS hybrid for Mozilla. When researching the options it seemed as if Bootstrap was an amazing system for prototyping, but since the style hinges heavily on the style of another company (Twitter), why not simply create our own system and avoid having to reskin once a prototype site was in place?


>  - In particular, Sandstone seems to be focusing on "websites" rather than
> webapps (e.g. fewer widgets), and seems to be a from-the-ground-up effort --
> which means that people like me who love to use existing design templates
> are going to ask questions about "when can we expect such-and-such".  So
> understanding the roadmap would be useful.

Sandstone is more about the style than the scaffolding. We needed a system to build on when designing our sites and the Less framework grid has a preferred gutter/column flow to it. My thoughts are that if you feel more comfortable with Bootstrap as a responsive framework for apps or even sites with specific functionality, there's no reason that it can't be used and then Mozilla style elements introduced at a later date.  We just thought that having our own in-house system as default was perhaps a more flexible route for our needs.

>  - totally subjective and ill-informed feedback, take it for what it costs:
> i really like Open Sans, but the serif body typeface doesn't feel like it
> 'fits' -- maybe i just need to get used to it.

We don't want to strictly enforce a set style, and Sandstone is our offering as a default style for Mozilla properties. It can be adapted and altered for other usage scenarios and the only would-be-nice-to-remain-constant features would be a) responsive grid if web based b) mozilla universal tab.  If another body/headline font is preferred for an app, by all means feel free to use another. I know when it comes to campaigns and landing pages, we'll be straying from Open Sans depending on the tone we want to set.

As I say, this is simply a default style that we'll be using when focusing on our top tier sites and we offer it as an opportunity to align with those properties.  Beyond that, feel free to shape it as you see fit! :)
David, thanks for the great questions & feedback!

re: Twitter's Bootstrap

Sandstone echos the concept of having a frontend toolkit for rapidly developing Mozilla websites. As Sean mentioned above, based on feedback from a number of Mozilla webdevs the technology is just a little different. This reminds me that I need to blog about this over on http://onemozilla.org

The One Mozilla websites' initiative is rolling out a number of assets for everyone's consumption this quarter, Sandstone is one, here are a few others:

*Universal responsive blog theme for all wordpress sites to use with areas for customization. We're very excited about this, because the Mozilla blog universe is a vast one of many looks and feels that confuses journalists, users, and Mozillians (paid staff and community). 

Follow Bug 720579  and Bug 725692 (here's a sample of what Craig is working from http://www.seanmartell.com/test_blog/ )

*Universal social assets for all websites, also available for community members to use on their sites, a joint effort by Privacy, Legal, Security, WebDev, WebProd and Creative teams

Follow Bug 725759

*Tabzilla, which has launched, but now we're working on getting the many sites out their to begin using it. Sites like webfwd.org have already reported an increase in traffic from the tab, and in the coming weeks we'll be infusing it with snippets, and scheduling promotions for Mozilla teams, products, and projects.

*Bedrock, the backend powering mozilla.org, mozilla.org/firefox, mozilla.org/thunderbird, and subsites like Mozilla Spaces, Privacy, Press Center, and many others. Follow the roadmap over on https://wiki.mozilla.org/Mozilla.com/Bedrock


re: Roadmaps

We're working to keep up with documentation across all of these efforts, here are a few handy links with more coming soon:

Overview - https://wiki.mozilla.org/One-Mozilla-Project
Design & Frontend Roadmap - https://wiki.mozilla.org/One-Mozilla-Project/Visual-Design
Backend Roadmap - https://wiki.mozilla.org/Mozilla.com/Bedrock

re: Serif/Sans Serif

The serif/san serif debate has been going on since Roman Times :-) (literally!) I used to tackle this debate designing websites for public schools and universities where we had to be 508 compliant:

Serifs do a few cool things . . . 

- guide the horizontal “flow” of the eyes v. sans serif which can contribute to vertical stress
- increase spacing between letters and words to aid legibility
- increase contrast (and irregularity) between different letters to improve identification.
- help bind characters into cohesive ‘word wholes’ which helps a lot with body text

For fun and a lot of excellent research on this topic: http://alexpoole.info/which-are-more-legible-serif-or-sans-serif-typefaces

<3 that you asked this, and <3 Sean's creative direction and thought process.

Please keep the questions and feedback coming, and if you would like to join in the weekly One Mozilla Thursday call @ 10:30AM PT, send me an email and I'll zimbra you up.
Google uses the Open Sans font for their Chrome sites.
It's better to choose another font to build our own branding.

https://www.google.com/intl/en/chrome/business/browser/
https://chrome.google.com/webstore/category/home?hl=en
As a bit of a type(In reply to mcbmoz from comment #8)
> David, thanks for the great questions & feedback!

Heh -- as a bit of a type nerd, I wanted to clarify -- I understand a fair bit about type and serif/sans serif distinctions.  My very minor point in comment #6 was just that the particular serif font didn't feel like it fit with the particular sans serif used, but I'll defer to typographers.
(In reply to mcbmoz from comment #8)
> re: Serif/Sans Serif
> Serifs do a few cool things . . . 
> 
> - guide the horizontal “flow” of the eyes v. sans serif which can contribute
> to vertical stress
> - increase spacing between letters and words to aid legibility
> - increase contrast (and irregularity) between different letters to improve
> identification.
> - help bind characters into cohesive ‘word wholes’ which helps a lot with
> body text
> 
> For fun and a lot of excellent research on this topic:
> http://alexpoole.info/which-are-more-legible-serif-or-sans-serif-typefaces


Thanks a lot for linking to the page, Chrissie. Looking at this, it seems the bullet points you copied are examples of those common misconceptions that Alex actually disproves in the very same article. Of course he also dispels as myth almost everything I thought to be true about Sans-Serif ;), so thanks for linking to it and saving us from a lot of fruitless debates.

Reading the research on that page, it seems like there is a single thing that really has any measurable effect on perceived legibility: familiarity.

"Many studies conducted in the past did indeed find a preference for serif typefaces ( Tinker, 1963 ; Zachrisson, 1965 ). However, Tinker commented that perceived legibility was due to a great extent to familiarity with the typeface. 40 years ago sans serif typefaces were not as common as they are now, and if these studies were repeated, it would not be surprising to find completely different results."

In fact I took a look at the top 100 websites according to Alexa, of those 100 only 4 use a serif typeface for body text. That probably means that in todays online world people are most familiar with sans-serif and will therefor be better at reading it. This is really the only thing that seems to have an effect, and if that is true, we should at least take it into consideration when we lay the foundation for how Mozilla websites will work across the board, instead of continuing using Georgia because we have done so in the past.
Kadir, Alex's article is a seminal one for the wonderful research and the fact that for every study there is an opposing study :-) 

If you're passionate about san serif, you should keep on that path, which brings me back to the first principal of the bug, gathering feedback on the content inside Sandstone, since we're building it out for Mozilla consumption. 

Sandstone is not being forced on anyone, it's a front-end development and branding tool for you to use and adapt I think Sean said it best up in comment 7, but here's the part I'm referring to:

We don't want to strictly enforce a set style, and Sandstone is our offering as a default style for Mozilla properties. It can be adapted and altered for other usage scenarios and the only would-be-nice-to-remain-constant features would be a) responsive grid if web based b) mozilla universal tab.  If another body/headline font is preferred for an app, by all means feel free to use another. I know when it comes to campaigns and landing pages, we'll be straying from Open Sans depending on the tone we want to set.

As I say, this is simply a default style that we'll be using when focusing on our top tier sites and we offer it as an opportunity to align with those properties.  Beyond that, feel free to shape it as you see fit! :)
(In reply to David Ascher (:davida) from comment #10)
> As a bit of a type(In reply to mcbmoz from comment #8)
> > David, thanks for the great questions & feedback!
> 
> Heh -- as a bit of a type nerd, I wanted to clarify -- I understand a fair
> bit about type and serif/sans serif distinctions.  My very minor point in
> comment #6 was just that the particular serif font didn't feel like it fit
> with the particular sans serif used, but I'll defer to typographers.

David - we may indeed be able to find a better fit with another font and Open Sans (I pair it with Calluna by @exljbris, of Museo Sans fame on my blog - http://blog.seanmartell.com/) but within the current time restraints and meeting our goals, we are launching with Georgia. Due to our L10N requirements and the need for an open font, we went with what we know for launch. Since updating the text will be a change of 1-2 lines of code in Less CSS, we can definitely research and test some options at a later date that meet the above needs.

Kadir - As for Serif vs Sans Serif, SUMO is currently using Georgia as its body text font. I'm curious as to whether or not there is any feedback/bug showing concern for that font on the current build of the site?

I know there will always be debate versus serif vs sans serif, and both have their pros and cons. Our style is now locked down and being built, so we'll stick with Georgia for now and thanks to Less CSS we can very easily change 1-2 lines of code to test some options after further research down the road.
Briefly (have to run and catch a flight): looks awesome. My only typography nit-pick: insufficient contrast between headers and body (Open Sans light vs Georgia), as alluded to by others. But we can compensate by using increasing the differences in size and color... or stick with all Open Sans in some instances, as also stated.

Re: the roadmap (which I'm seeing for the first time): you guys are rock stars. Every designer in the org should be thanking you profusely :) I'm looking forward to extending these design guidelines—and general standards of excellence—into product UX, in letter and spirit.
Attached image Sandstone on Windows
One thing I am worried about deploying Open Sans light as a webfont is how it will look under Windows with font smoothing on or off. ClearType tends to make type looks lighter and its edge more jagged when compared to OS X.

In this example—rendered using Firefox running on Windows XP and ClearType font smoothing turned on—the “anemic” rendering has made the sub-navigation menu and smaller headlines less readable. Imagine being someone with visual impairment or of old age trying to read through these bits.
(In reply to Kohei Yoshino from comment #9)
> Google uses the Open Sans font for their Chrome sites.
> It's better to choose another font to build our own branding.

I agree. If I am allowed to propose an alternative, I would look at Deja Vu Sans.

Deja Vu has:
* Similar typographic features: humanist, linear, open counters, etc.
* Similar spacing, so lines of type won’t need much refitting
* An extralight weight, which is similar to the light weight we’re currently using
* Been hinted so it renders well in all platform (which includes Linux) on fairly small sizes (10–14px)
* A fairly complete glyph coverage, so l10n efforts won’t have to resort to using different fonts and can maintain stylistic consistency
* A generous license
* Is an openly developed project, like ours (https://dejavu.svn.sourceforge.net)
Just want to weigh in here on Open Sans. 

We're going to continue to use it going forward. I'm fine with others using it as well. I don't think "they did it first" is something we need to be concerned with in this case as it isn't the font of our product brands, it is the web font we choose for our headline styles. Meta is still our product type.
(In reply to James Socol [:jsocol, :james] from comment #3)
> (In reply to Sean Martell from comment #2)
> > Don't go by my hack job of a page for how the framework should be
> > implemented. :)  The intent was to show the website for the framework we're
> > going to be using so if there was an urgent need to make a site responsive
> > it could be done before everything is set in stone. The Less CSS is still
> > being worked out.
> 
> Ah, OK. The site made it sound like the decision to use the Less Framework
> had already been made, and its insistence on things like '.bigger' bugs me.
> It also seems to have been replaced by Frameless: http://framelessgrid.com/

James,

I'm using a Frameless implementation in my marketplace UI prototypes. The framework is about 6 lines of LESS. It's amazing. You can use a .width(<# of cols>); mixin to accomplish the grid sizing.


As for the whole Open Sans thing, it's my opinion that Mozilla's style and personality is distinct enough from Google's that our choice of typeface won't be an issue.


I'm taking a look at the overall proposal tonight. I think there's a lot of good in there, but I'd love to get my nits in now :)

Thanks for the amazing work on this, Sean!
Thanks Sean and Chrissie for designing a good-looking piece of work! Hope you don’t mind my feedbacks.
I looked at the Sandstone theme and the thing red fonts are hard to read for me. I'm running Debian Testing.
Blocks: 729756
I'm going to leave this open for a few more days, but we're moving to implementation on Bug 729756

Thanks!
Just some thoughts I had - there are three scenarios I can think of that the new design and guidelines might be relevant to:

1. Long-term Mozilla sites that use the same styles as the sandstone one

2. Short-term campaign/marketing Mozilla sites that use elements of the new design but have freedom for other parts to be different (such as fonts, layout, content, etc. - Firefox Flicks is a good example)

3. Mozilla applications where they aren't just websites but product where buttons, forms, etc. may maintain a consistent look and feel and differ from a campaign site (e.g. a form for a product probably won't look the same as a form in a campaign).

Ideally, we have a git repository that has three branches for these scenarios that a developer can easily use in a project they are working on and not have to customize too much. This would basically be the 'Mozilla bootstraps' for various sites. Currently we have django-moz-header/footer but the content is out of date with the new changes.
Yep! Agreed.

We're going to be building an integrated brand + web + product style guide which will have links to our assets.mozilla.org repository once live as well as full code packages most likely on Github (Tabzilla is already there). For templating, the goal is to have something similar to what Bootstrap offers in terms of a documentation/example site.

We've already been talking about how we're going to standardize similar elements across web + product and that will come about with this new style guide.

More to come!
Let's definitely talk about this next week at the flux work week. I'd like to tackle the problem of django-moz-header and start these projects.
Resolving this bug as the Style Guide templates, assets etc., have been defined and are now being developed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.