Start exploring designs for base theme

[dotproto]

"start thinking about an initial template/theme for posts, admin, etc."

https://twitter.com/getify/status/668919348858253312

[dotproto]

A couple quick thoughts on fonts

• Avoid excessive use of web fonts. Try to keep non-system fonts limited to one or two type faces.
• Explore async font loading strategies to improve first load UX
• Some resources for additional reading
  • https://css-tricks.com/preventing-the-performance-hit-from-custom-fonts/
  • https://vimeo.com/73473648

[dotproto]

@getify do you have any blogs, designs, or sites that you really like? I have my own biases that I can certainly run with, but you're customer/project lead.

FWIW, I'm inclined towards something simple/minimalistic. Medium is the elephant in the room, but I'm not wild about their use of a sans serif font for headers and serif font for body copy -- I'd probably explore sticking with a ~~sans~~ serif font everywhere.

For licensing reasons I'm going to start exploring fonts on Google Fonts. I'm not sure if there are any other good resources out there for free (gratis and libre) web fonts.

Edit: Meant to say I'd try a serif font everywhere. My thinking is that people tend to have an easier time reading (printed) content using serif fonts. With high DPI screens and your tendency to write long form content on http://blog.getify.com/, I think a serif font would work better. Regardless of serif or sans serif, as a reader I'd prefer consistency between the headers and body copy.

[getify]

+1 on all this! will come back to provide more thoughts shortly.

[dotproto]

While doing some research regarding the question of legitiblity of (sans) serif fonts, I couldn't hlep but notice that this blog uses two of the fonts I was evaluating from Google Fonts: http://alexpoole.info/blog/which-are-more-legible-serif-or-sans-serif-typefaces/

• Headlines appear in Bitter
• Body copy appears in Lora

Critique

Stylistically there are several things I like about this blog.

• Anecdotal, but body copy feels easy to read and I flowed through content easily.
• Images are center aligned and caption text is visually offset with italics and a slight color change.
• Headlines and body copy are not true black. Headlines are darker than body copy (7% luminosity on headers, 20% on the body copy).
• I really like that selected text is a pale yellow, as if it was highlighted with a highlighter.

A couple points I'm less fond of.

• I'd like to see a larger top margin on H4 elements. H1-3 have 2x more margin on top than bottom, but H4 is identical on both sides. This makes some subsections harder to read as they're less visually distinct.
• I'm not wild about the double border effect on images. There's a 5px #F3F3F3 border surrounded by a 1px #DDD. For comparison, Medium images have no border.
• Image captions can stretch the full width of an article. They should be constrained to either the image width or simply a static width smaller than the body copy.
• Rather than image captions being italic, I'd rather them be noticeably lighter than the body copy and in a smaller font. Again, for comparison Medium captions are sans serif 14px high while the body copy is serif 21px high.
• The references blocks are a little strong. I think I'd approach this by putting all references in a single block and dividing them with HR tags.

[getify]

I completely agree with your assessments here. I like the simple style of that blog as a good starting theme for emdash. I'd add two additional critiques:

• I'd like the body text to be 18px instead of 17px. I like the line-height of 28px, but perhaps it should bump up to 29px with that change too?
• Given that these styles are being set with pixels, it screams "not responsive". I'm for sure no expert here, but it seems those should be being set in ems or rems or something like that? I do see they're using media-queries with breakpoints, but it still seems like using px is old-school design. Or not?

Which brings up another point: is it possible to have a single theme that will work well for all the screen sizes, or do we need to have one theme for "large screen" and one for "small screen"? Anecdotally, that's what my current blog has, but mostly because that seemed my only option within the constraints of my existing WP theme(s) and plugins.

And if we are going to have different default themes for various screen size breakpoints, we need to research server-side detection options.

Keep in mind, some people will choose the static-page only option, in which case they'd either have to be able to pick a single theme to use for all pages, or we'd have to have client-side JS to either automatically pick a theme or provide end-users some JS-based selector widget to pick/toggle.

[dotproto]

Which brings up another point: is it possible to have a single theme that will work well for all the screen sizes, or do we need to have one theme for "large screen" and one for "small screen"? Anecdotally, that's what my current blog has

Absolutely. We can accomplish this with either resolution-specific stylesheets or a single stylesheet with several @media queries. Okay, they both technically use media queries, but whatever.

For future reference, here are the CSS stylesheets blog.getify.com currently loads for mobile and desktop.

• mobile: http://blog.getify.com/wp-content/themes/responsive-mobile/css/style.css?ver=0.0.7 (backup)
• desktop: http://blog.getify.com/wp-content/themes/black-n-white/style.css (backup)

[getify]

It should be noted that it's possible that we might not just need different CSS between "full" and "small", but also perhaps different (simpler) html templates.

[dotproto]

Ah. After your comment about the static only I was assuming there would be a single base theme covers all devices sizes. The HTML would be structured to treat CSS as a progressive enhancement and allow for flexibility in how content is displayed. That is, ideally we'd be able to re-order or hide/show content as necessary for different device sizes. I also assumed that the elements hidden from mobile devices would be content like a sidebar, thus have a minimal # of bytes wasted. Thats a lot of assumptions on my part, of course.

In a completely static site, ideally the experience would be as robust and device agnostic as possible. As such, those assumptions feel like a good set of tenants, no?

[getify]

I think all of those assumptions make sense for a default theme.

But the system we build for managing themes, and renderings (html and css), and deployment -- all that needs to account for the most sophisticated user needs/desires that we care to handle. Some users may very well want different html as well as different css.

We need to decide if that's something emdash should support (I kinda think it should), and if so, how.

[dotproto]

Okay, I get where you're coming from. I was assuming a crawl, walk, run style dev cycle where we'd start with determining the core need and how do we get that up and running as quickly as possible.

It sounds like you want the basic design implementation (which includes media queries, CSS files, etc.) to be a sub-feature of the theme story, and themes are dependent on the application's architecture, correct?

Perhaps we should create a new issue to start discussing some of these architectural issues.

[getify]

I think it's reasonable to consider where steps 2 and 3 are likely to go so we don't paint ourselves into a corner for step 1.

[dotproto]

With regard to the your feedback about the page size, here's the most recent version I'm playing with: https://htmlpreview.github.io/?https://github.com/svincent/emdash/blob/30286374b394f3b9b62980fad293f32501a51150/style/void.html

For sizing I'm using all rem and em. The only pixel dimension I've specified is for the initial font size at your request :wink:

HEAD version: https://htmlpreview.github.io/?https://github.com/svincent/emdash/blob/gh-pages/style/void.html