gemcopeland / personal-website Goto Github PK

Adding this since it was a todo on the Readme

Issue is that if we pull in a bunch of screenshots for the block hover style, could be an enormous page size

Need a focus state for buttons, links, that sort of thing

The pagination.pageNumber is zero-indexed. According to the docs, we should be able to do something like:

permalink: "/writing/{% if pagination.pageNumber > 0 %}p{{ pagination.pageNumber + 1 }}/{% endif %}index.html"

However incrementation doesn’t seem to work (see 11ty/eleventy#760). Until it does, we’re going to have to live with:

/writing/
/writing/p1
/writing/p2
etc.

Even though that means that /writing/p1 is actually page 2. I’m going to leave this open so that we can track how things go with the issue raised in Eleventy.

This is going to be kind of irrelevant for /writing, it’s more important for the homepage / CV.

See rough lists below based on the current design. I’m using schema.org terms for the time being, and a lot might not be strictly necessary but are worth discussing.

Relevant for homepage/footer or just generally (see schema.org/person):

• affiliation
• colleagues (or maybe follows?)
• email
• hasCredential
• hasOccupation
• hasOfferCatalog
• jobTitle
• knowsAbout
• memberOf
• name
• telephone
• workLocation
• worksFor
• description
• image
• sameAs

Would need to figure out how to work in past employment / events. Might be that we actually define the homepage as a WebPage itemtype with Person (the site owner, @GemCopeland in this case obvi!) as the about and author properties.

Other types that may be relevant for this site:

• Organization (for past employers)
• Event (for past residencies, etc.)
• Article (for case studies)
• Blog and BlogPosting

Shouldn’t do all of it because that will be prohibitive, but we can use schema.org as a jumping off point at least.

@GemCopeland Could you add one “weird” screen size to your designs that would indicate how a “thinking” block scales at that size? An example might be a landscape iPad screen, so something around 1024px wide.

If we go with a single column of blocks at that screen size, the blocks feel kind of massive. But if we go for a double column at that size, we’d have to do some text truncation that I don’t think we could do properly without getting really hacky, which I’d prefer to avoid.

Might also be best to just discuss this over a call, so could wait till then as well!

Hooked this up quickly, it’s kind of a mess. Sort it out!

Was going to try to keep it super simple, mostly targeting elements directly since this might make it more digestable to someone who is new to CSS, but it is leading to some gnarly selectors.

Let’s go with BEM and introduce a few utility classes here and there.

Let’s also try to use SASS. Was kind of avoiding it initially (again, for the sake of being a little more beginner-friendly) but it’s leading to a lot of repetition. Also, we could then maybe use SASS variables instead of CSS variables which will give us slightly deeper browser support.

This is high-priority since it’s going to be a lot nicer to make design-related changes once this is done.

• A starting point w/ Eleventy: https://github.com/maxboeck/eleventy-webmentions
• For reference, see also: 11ty/eleventy#57

More about what webmentions are here: https://indieweb.org/Webmention

Let’s discuss!

@piperhaywood Is this even possible with the way we're using Markdown excepts?

Is this good practice?

Media hosting is always an issue with static sites. There’s a limit to how many big ol’ files you can / should store in a repo.

Right now, our concern is images. As in the Readme:

We discussed how to host videos, but decided that this will be implemented in the future as it's not essential. The main consideration is that embedding something from Youtube also means adding tracking to the site, which we want to avoid at all costs.

So, when it comes to images, we considered a CDN. Many CDNs have the advantage of being able to resize images on the fly which means we would have more elegant loading options. But they can be fiddly to use / set-up and usually come at an additional cost.

We might be able to use Are.na. The advantages are that @GemCopeland already uses it heavily, so there’s not going to be a learning curve involved in adding images in this way, and she is already an Are.na supporter so is contributing towards that service. The disadvantage is that we probably won’t be able to resize any images on the fly, but this isn’t a major problem since the designs don’t currently require any enormous images.

From initial tests it seems like Are.na will work for this, so that’s the assumption we’ll work with for the time being.

Create some basic utility classes like .hide and add documentation to README so their usage is clear.

In particular, @GemCopeland might use that on the Writing nav item in the initial version of the site.

Taken from the readme

Need to consider a little further how this could be done.

Possible to do thumbnail idea as per #7?

@GemCopeland, my initial thinking is:

• Eleventy for static site generation
• Are.na for your images, using the API to generate your Thinking content
• Netlify for hosting the site files (not media) and SSL
• Netlify Functions for API authentication

And of course GitHub for the repo and for the documentation on how to get set up, authorship, etc.

A few relevant Eleventy docs according to conversations we’ve had recently:

• Frontmatter
• Tutorials (indicates how we could extend things in the future, particularly search)

We’d probably use this repo as a jumping off point, it’s a basic Eleventy blog made by the guy who started Eleventy.

What do you think? If that seems like a decent jumping-off point, I could get the unstyled structure sketched out on a branch so that we can demo it. We should be able to look at all demos in Netlify on dummy URLs once we get it hooked up.

Possibly in the markup, possibly in JSON. Related to #1

If we go down the route of having Thinking as a separate page on mobile, we'll need to work out what to do if people navigate directly there on desktop. One idea would be to simply reverse the two panels.

Dropped this b/c I was having trouble accessing the excerpt w/in a loop, turns out it is as simple as post.data.page.excerpt.

Very small thing, but could you align the baseline of the small date with the baseline of the rest of the text?

Looking at it now, I think we should only display a description text if there is one in the Info field, rather than pulling in the text from the first text block. Mainly because it is truncating almost all of them, and they don't really make sense. I also like the way it looks without any text too.

Use cases are:

• Previous / next post
• Previous / next page of posts in feed (main feed, tag feed, and search results)

It can probably all be as simple as the forwards / backwards arrow you currently have, but could also be different.

Not sure why this is happening.

There are a few considerations here. One is design: where would a link go?

Another is feasibility in terms of the stack (see #14). It should work with Eleventy (see repo) but we should try to configure the build accordingly so that adding RSS isn’t too much of a headache.

Personally, I think it would be cool to include it!

Accessible colours? There are a bunch of tools online you could try to test this with.

@piperhaywood You have probably explained it to me already, but what's the system behind which blocks display on the Thinking panel?

I'm confused because the ones in the Spinners channel are the newest blocks, but in My Work they're the oldest ones.

This issue is to collect ideas for accessibility enhancements.

For example, should we include an “increase contrast” toggle in the footer?

I've added a subtext line to a few of my activity files (e.g. Integrated, Walker), but it doesn't display on staging. Could you take a look? I can't work out why.

The activity in Current and Upcoming seems to be ordered from furthest away to soonest, but I think it should be the other way around. However, once it moves to the Previous section it should be listed as most recent to oldest. Does that make sense?

Search is tough on this type of site, but it is possible! Here is a tutorial that we could start with (geared towards Eleventy): https://www.hawksworx.com/blog/adding-search-to-a-jamstack-site/

We might be able to have DuckDuckGo be the fallback instead of Google.

I've added another post and realised that I could definitely do with another style for H1's.

We spoke about making this more visual but adding a grid of small thumbnails. This would function to add some more visual interest to the page, and give people a better overview of the contents.

This will probably just include “skip to main content” near the top and “back to top” after each post. Could simply look the same as the “read more” button, just need to know where they should go if/when they’re tabbed to.

Related to #4

@GemCopeland We need some way to display page titles for “default” pages. You may not have many such pages, but one that you will definitely have is a 404 page.

Do you want it to look similar to a single blog post, maybe something along the lines of:

Gemma Copeland – 404 error

Or it could just be similar to your heading style on the homepage and come at the top of the content (so similar to “About” in your current homepage design)

The initial designs indicated a footer across the whole homepage, but I don’t think we can achieve this without some really hacky stuff. Have currently hooked it up so that it resides beneath the “homepage” panel on large screens.

To review / discuss!

@GemCopeland We should chat a little more about this. I think we should do it, but we might need to set a cookie since ideally, the user’s setting should be “remembered” if they continue to browse the site. Is that cool? You’ll probably need to include it in your “details” section.

It’d be worth having a brief overview about how best to handle markup in Markdown. Let’s discuss!

Is there a way we can display the correct formatting on the Arena Info excepts?

Need to double-check the font license to see whether or not we need to include credits in any specific places.

@GemCopeland This is low-priority, but will need to get done at some point. I’m going to assign this to you. Could you update this thread with any info you find, and then we can incorporate it as necessary? Might be that your footer note is sufficient.

Compilation currently takes 5-9 seconds for 22 files, which is crazy long. This is probably because it tries to recompile the Arena blocks every time. Consider adding a blog-specific server setting that could be used for writing and omits the Arena blocks.

eFlux has a neat loading pattern that @GemCopeland is interested in:

We discussed the approach used on e-flux, which loads a simple ASCII pattern first before loading the images. They have a separate source for this patterned background.

Medium as well. Medium loads a tiny thumbnail which they scale up and blur with CSS, replacing with the large image when it’s loaded.

We’ll probably go down the eFlux route due to #12.

Current possibilities include small tiled background images, CSS patterns, and gradient backgrounds. The last is probably the one we’re most excited about currently. Would probably use the two main site colours initially and as an enhancement, allow @GemCopeland to choose the colours on an image-by-image basis.

Any of this functionality would probably require a slightly modified Markdown parser since at minimum, we would need the output to be something like:

<img class="lazyload" alt="This is the alt" data-src="https://gemmacope.land/image.jpg" width="300" height="200">

Perhaps consider the way that Kirby handles images in Kirbytext (read more). The syntax for the above would be:

(image: https://gemmacope.land/image.jpg alt: This is the alt width: 300 height: 200 imgclass: lazyload)

Of course, Markdown does support HTML markup so perhaps it’s worth keeping that in mind for the initial version.

Eleventy doesn’t support paginated tag archives currently. This is because you have to use Eleventy’s pagination to create tag archives. The trouble with this is that we can’t then apply normal pagination on top of this.

This isn’t a dealbreaker, but it’s worth keeping in mind since it could lead to some really long pages. Probably a good reason to do some sort of image lazyloading.