Add byline to articles - issue #5

[madrilene]

• Added authors global data (just contains Tobie as an author, but having this data globally available is useful for other components too)
• Added a new include (avatar.njk coupled with the authors global data)
• Added a new filter to calculate reading time
• built out the byline: #5

[netlify[bot]]

✅ Deploy Preview for unlockopen-com-v4 ready!

Name	Link
🔨 Latest commit	e4b79671ad9dbbca5f689f92534512f819026159
🔍 Latest deploy log	https://app.netlify.com/sites/unlockopen-com-v4/deploys/66509f445e778400081d9e36
😎 Deploy Preview	https://deploy-preview-34--unlockopen-com-v4.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[tobie]

Lets use updatedOn (Ruby on Rails convention I won't forget) for both lastEdit and lastUpdated unless there's a reason to use two different terms.

[tobie]

Also, what's the reasoning behind this?

[madrilene]

Lets use updatedOn (Ruby on Rails convention I won't forget) for both lastEdit and lastUpdated unless there's a reason to use two different terms.

I try to keep strings out of the template. If it's only used once in this template, I'd store them in the front matter, if it might be useful in more places I store it in the global data directory. lastUpdated represents the string "Last updated", while lastEdit references the date in the front matter - I used different names to not mix them up / confuse. I could name one updatedOn and the other "updatedOnString", but if you prefer something else just let me know.

[madrilene]

Also, what's the reasoning behind this?

This is because of the law of proximity: objects that are close together are perceived as more related than objects that are farther apart. It's about guiding users' perceptions of which elements belong together and which are separate.

S: to group items that are very closely related, such as menu items, the title with the subtitle/lede, the paragraphs, the image and its caption.

M: separates the meta block /byline from the subtitle/lede, as this area is more standalone.

L:
is used to give the image more space and let it stand out as a focal point.

In general, I try to achieve a well balanced, open, uncluttered look, improve readability and establish a clear visual hierarchy.

This spacing strategy is sometimes a little intuitive, and it might be the right choice to use an M distance between byline and image to assign the image more strongly to the header area.

Also note that fonts have unique characteristics defined by its metrics, which include aspects like ascent, descent, leading, etc. These metrics determine how the font is displayed and how much (vertical) space it occupies. There are some more factors that play into it (the browser with line-height scaling), but there is some additional vertical space that each character occupies.

Our font is pretty well set up as you can see in bigger sizes, the vertical space aligns well with ascenders and descenders.

[tobie]

Lets use updatedOn (Ruby on Rails convention I won't forget) for both lastEdit and lastUpdated unless there's a reason to use two different terms.

I try to keep strings out of the template. If it's only used once in this template, I'd store them in the front matter, if it might be useful in more places I store it in the global data directory. lastUpdated represents the string "Last updated", while lastEdit references the date in the front matter - I used different names to not mix them up / confuse. I could name one updatedOn and the other "updatedOnString", but if you prefer something else just let me know.

OK, I get it now. What's the rationale for extracting strings? I'm never going to make this website multi-lingual. This adds quite a layer of indirection and complexity. What are the benefits?

[madrilene]

Lets use updatedOn (Ruby on Rails convention I won't forget) for both lastEdit and lastUpdated unless there's a reason to use two different terms.

I try to keep strings out of the template. If it's only used once in this template, I'd store them in the front matter, if it might be useful in more places I store it in the global data directory. lastUpdated represents the string "Last updated", while lastEdit references the date in the front matter - I used different names to not mix them up / confuse. I could name one updatedOn and the other "updatedOnString", but if you prefer something else just let me know.

OK, I get it now. What's the rationale for extracting strings? I'm never going to make this website multi-lingual. This adds quite a layer of indirection and complexity. What are the benefits?

Just my personal preference. If I expect that I might have to use a string in more than one place, I put it in global data so that I can change the string for all instances.

[tobie]

At the risk of insisting, I'd much prefer we kept things as simple as possible and just put test in the template until there's a very good reason not to. this really helps with cognitive load and maintenance.

[madrilene]

At the risk of insisting, I'd much prefer we kept things as simple as possible and just put test in the template until there's a very good reason not to. this really helps with cognitive load and maintenance.

You can always insist! But what you mean now, is putting the text right where it appears? Did that in the next commit.