search

getify / emdash

Simple blogging with node/iojs + GitHub.
36 stars 1 forks source link

Start exploring designs for base theme #2

Open dotproto opened 8 years ago

dotproto commented 8 years ago

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

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

dotproto commented 8 years ago

A couple quick thoughts on fonts

dotproto commented 8 years ago

@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 commented 8 years ago

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

dotproto commented 8 years ago

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/

Critique

Stylistically there are several things I like about this blog.

A couple points I'm less fond of.

getify commented 8 years ago

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:

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 commented 8 years ago

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.

getify commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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