I'm really trying to simplify the default theme. I don't care if it's fancy. I want it to work as a baseline without modification and then I want to make it as simple as possible to modify. Take primary navigation for a moment. It was more complicated but also more fragile. Now it's incredibly basic and a few additional rulesets and a little JS from now it will be better off for it. Want to include dozens of links? Go ahead.
There's a version running at ode.io now. I could be handling this testing much more elegantly of course. For example (as you may know) rather than having the new theme be the default, I could just rename it and then explicitly request the working theme as part of the URL. But I figure this is my prerogative for having an exceedingly unpopular project. :)
Ummm… The responsive styles are essentially broken at the moment because I've been renaming things. Currently only the "marquee" is intact. (That's the bit at the top that reads "A platform about you*"). If you'd like to see some of the additional styles I'm including for content (again, very basic) you I have a playground post here: https://ode.io/playground/testing-2_shy.html#testing-2_shy. (Shy posts are only visible when explicitly requested.)
What else… Oh it currently includes a very simple 12 column floated "grid". I want the floats, flexbox, and grid to all be options, without a lot of fuss. To do that I'm really trying to think in very basic terms.
This message was deleted
I think the whole thing might have to float in the center because it looks a little funny with just a max-width: 800px on it.
You can get it in the middle with margin-left and margin-right set as auto
This is with:body {
margin-left: auto;
margin-right: auto;
max-width: 900px;
}
This is a crazy hacky solution. My CSS is trial/mostly error, so I'm sure there's a better way to do this). The original looks great on mobile and tablet; I'm just worried that the text is too wide for desktop and laptop reading.
All of these suggestions are like "reverse" progressive enhancement -- so what looks good on mobile doesn't make it look worse on desktop.
I've been looking into things like Docker images, but it looks like it's more expensive to deploy with things like Docker and Kubernetes than it is to use a VPS or shared hosting. And with that in mind, even though it's no longer the late 2000s, shared hosting is a very compelling choice because with the right provider it can be cheap and robust, plus somebody else is handling OS security.
I'm not giving up on Docker just yet, but the learning curve is high.
And even though my current shared host is expensive (it's up to $16 a month), I can do an unlimited number of individual sites using either separate domains or subdomains. But if I "limit" myself to, say, five sites, NearlyFreeSpeech.net is a pretty good deal. I did a test this week with Unison (my file synchronization solution of choice), and NFSN does provide that, and I got it to work. On Hostgator, I had to find a package for CentOS 6 and install my own on the server side.
@passthejoe There is a max width. It's currently 1900px. There's a wrapper div around the whole thing. You can set the max-width to anything you like by just changing one CSS rule. One of the things I was going for is to make it so that every single rule, without exception, does what you'd think it does. The rulesets don't step on each other's toes. Space is controlled pretty deliberately. So for example vertical spacing is handled through bottom margins and top margins are typically zeroed, with the exception of headings. There shouldn't be any dangling extra space vertically or horizontally and the beginning and ends of things.
@passthejoe Yep, I have it centered. If you're not seeing that it's probably related to one of the broken or 1/2 broken media queries. Whatever it is, it will get fixed. This is what I'm seeing (no changes).
Just about everything can be directly changed with a single rule. If you want to change the background behind the wrapper, that's just the the background color on the body element
body {
background-color: #b3c2d0; /* #b3c2d0; – Light bluish grey */
color: #464545; /* #464545; – Med dark gray */
margin: 0;
}
@john_henry_twitter Thanks. Enjoy your vacation! Of course I'd love to have you poke around or help out. It will be at some stage shortly and then we can just keep working on it on and off going forward. That sort of iterative approach will get it where it needs to be I think.
On a 3000px Mac screen maybe users don't have the browser filling the screen, so the wideness of the type doesn't affect them, but on a "regular" laptop screen, which these days is often HD, the browser still pretty much fills the screen, and I'm having trouble following the line from one side to another.
@passthejoe Good feedback, thanks! Maybe instead I'll limit the width of a more interior element. If we're talking about a grid, I think it's probably a good idea not to broadly restrict the width, which would take away the ability to have wider (or more) side-by-side elements. Restricting line length of course makes a lot of sense! So when there's only a single element in a wide container like that it probably should take up all of the available space. Does that seem reasonable?
Look at how narrow the NY Times is making their text window: https://www.nytimes.com/2019/07/08/opinion/berlin-socialism-housing.html
Here's another design that I like:
https://getpocket.com/explore/item/secrets-of-ivy-league-tour-guides
I like the big body type -- it stands out. The thicker serif fonts are nice
Here is the "Get Pocket" home page that leads to more stories in this style: https://getpocket.com/explore/trending?src=top_navbar
I'm not as crazy about the home page as I am the individual items
I’m still unsatisfied with my WordPress install. I think I don’t like how WP handles adding functionality, and the close coupling of design and functionality within the theme. I have an old site which broke under php7 and I finally had to update the theme major version, and I really dislike that every design agency puts in a custom admin area for their theme.
I think I’d like to see a three part division of responsibility: a “style”, a “genre”, and “plugins”. Style would simply be the appearance, fonts, colors, etc. Genre would be most of what makes up a theme, and the “type” of site whether it be a blog, pages, or something more custom. Plugins would simply add functionality. Ideally they would all be tested and fully interoperable.
This would address some of my frustrations trying to use Hugo as well, everything is either just the base framework (e.g. templates, routing) or highly theme-specific.
This would address some of my frustrations trying to use Hugo as well, everything is either just the base framework (e.g. templates, routing) or highly theme-specific.
This is a lot like the way Ode works. A theme is a folder. That folder contains plain old html, css, javascript along with images and whatever else you want to include in your theme (icons, other design assets, etc). You can have as many of those themes as you like. One of the default and any of the others can be explicitly called as part of the URL. If I had a theme called "coffee" that was not the default then I could render a page using the coffee theme with an address like ode.io/some-category/post-name.coffee.
"Functionality" is not munged together with themes.
Extensions, called addins, are just a standalone folders containing a perl script. They are explicitly ordered by the site maintainers (literally you tack a number on to the addin folders name. So the Indexette addin running at ode.io is installed as 04Indexette. Ode recognizes a number of a number of addin routines:
01. inventory_ping_response,
02. replace_discover_posts,
03. replace_find_req_theme,
04. replace_interpolate,
05. replace_posts_sort,
06. manipulate_request,
08. pre_filter_posts,
09. filter_posts,
10. access_head_theme_early,
11. access_date_theme_early,
12. mod_post_file_before_read,
13. access_title_tags_and_body_early,
14. access_posts_theme_early,
15. access_foot_theme_early,
16. access_page_late,
Any addin can implement any or all of these routines. The only one required is inventory_ping_response. Ode runs through the addins directory and for each addin it finds it calls the inventory_ping_response routine to ask the addin if it should be run. If yes, Ode remembers which of the other routines are implemented. As Ode runs it gets to the point where all of the manipulate_request routines for example should be run. It then calls the manipulate_request routine for each addin that includes one in order. Each subsequent addin is unaware that earlier addins have run. There is no intermixing of addins.
It is true that there can be conflicts. For example replace_posts_sort changes the way that Ode sorts all of the posts for the site. If you had two addins installed both implementing a replace_posts_sort routine, the last one would win. The first one would change the sort routine, and the next would change it again, and then the posts would be sorted.
That's about it.
Content is stored in plain text files organized into folder hierarchies, just like a static site. The only difference is that the post files are just content, not all of the HTML that forms the framework of the page (duplicated for every file as you'd have with a static site).
Themes are separate from content. The posts are plugged into the theme.
Addins are completely separate. There are no references to addins in themes or vice versa.
It could be that an addin requires a specific theme be installed (along with possibly many others). For example the editedit addin allows posts to be edited in a browser. It comes with it's own theme that includes the form fields necessary to input the changes. So the theme is the interface for the addin. But then that special theme is just part of the addin.
As for Wordpress. I don't like it. :)
"Functionality" is not munged together with themes.
Extensions, called addins, are just a standalone folders containing a perl script. They are explicitly ordered by the site maintainers (literally you tack a number on to the addin folders name. So the Indexette addin running at ode.io is installed as 04Indexette. Ode recognizes a number of a number of addin routines:
01. inventory_ping_response,
02. replace_discover_posts,
03. replace_find_req_theme,
04. replace_interpolate,
05. replace_posts_sort,
06. manipulate_request,
08. pre_filter_posts,
09. filter_posts,
10. access_head_theme_early,
11. access_date_theme_early,
12. mod_post_file_before_read,
13. access_title_tags_and_body_early,
14. access_posts_theme_early,
15. access_foot_theme_early,
16. access_page_late,
Any addin can implement any or all of these routines. The only one required is inventory_ping_response. Ode runs through the addins directory and for each addin it finds it calls the inventory_ping_response routine to ask the addin if it should be run. If yes, Ode remembers which of the other routines are implemented. As Ode runs it gets to the point where all of the manipulate_request routines for example should be run. It then calls the manipulate_request routine for each addin that includes one in order. Each subsequent addin is unaware that earlier addins have run. There is no intermixing of addins.
It is true that there can be conflicts. For example replace_posts_sort changes the way that Ode sorts all of the posts for the site. If you had two addins installed both implementing a replace_posts_sort routine, the last one would win. The first one would change the sort routine, and the next would change it again, and then the posts would be sorted.
That's about it.
Content is stored in plain text files organized into folder hierarchies, just like a static site. The only difference is that the post files are just content, not all of the HTML that forms the framework of the page (duplicated for every file as you'd have with a static site).
Themes are separate from content. The posts are plugged into the theme.
Addins are completely separate. There are no references to addins in themes or vice versa.
It could be that an addin requires a specific theme be installed (along with possibly many others). For example the editedit addin allows posts to be edited in a browser. It comes with it's own theme that includes the form fields necessary to input the changes. So the theme is the interface for the addin. But then that special theme is just part of the addin.
As for Wordpress. I don't like it. :)
Here you go @john_henry_twitter https://ode.io/downloads/ode_releases/ode_current.zip
I wouldn't call it an alpha. It's the old version. It should work fine. There are detailed instructions included. You should only need Perl to get it going. Let me know if you have any trouble. Once it is running it shouldn't give any trouble. The few installs that are out there have been running for years.