Closed simenandre closed 3 years ago
@cobraz what case do you want to be implemented, from AWS?
@cobraz who will add blogposts and other "quick" entries?
This may have something to say?
@dkostenko-orion What do you mean?
@seacurrent Which is an interesting question. @AnnaBjerk is probably one?
@AnnaBjerk What do you think, @AnnaBjerk? Would you be comfortable using Github to e.g. write blog posts? See above.
We can have multiple authors, but someone need to post. @AnnaBjerk is a great alternative. We could of course use Medium as well and link?
This not just about blogging, but all content on the site.
We can continue to use Medium for blogging, as we've done now, or move that to Github too (like Pulumi does it). Of course, by moving the blog to Github, we benefit from having review-cycles and more activity for non-developers on Github.
so to conclude; i vote for Github
@seacurrent Which is an interesting question. @AnnaBjerk is probably one?
@AnnaBjerk What do you think, @AnnaBjerk? Would you be comfortable using Github to e.g. write blog posts? See above.
I think that with some training I will be able to do that.
I vote for Github too
To summarize, what we're leaning towards is this:
@dkostenko-orion How do you think we can implement this? We probably want to make sure the structure is easy to understand for non-developers too. Ideas?
@dkostenko-orion and @AnnaBjerk, we probably want some documentation for new users too?
note: I've asked @AnneMatilde to give some feedback too – waiting for her thoughts :)
@cobraz I think first we need to decide how it should look:
In my opinion I really like the look of Sanity, and it seems really easy to post things – on the other hand I'm not that used to working in Github. I like the "what you see is what you get"-method.
In my opinion I really like the look of Sanity, and it seems really easy to post things – on the other hand, I'm not that used to working in Github. I like the "what you see is what you get"-method.
Right! which is the benefit of using Sanity by a long shot. That being said, we do have Markdown editors our staff can use for content creation. Knowing that, does that change your opinion?
@cobraz I think first we need to decide how it should look:
- If flexible and dynamic, then we need a voluminous parser to style each element at the stage of adding a content (for example, text size, image-to-text ratio, etc.)
- Another option is to create models (and with them examples for who will add content), and define the style separately for the model in the code (almost like in sanity)
What about using MDX? I am a big supporter of theme-ui which has great MDX support. Using MDX seems like a nice way of getting improved styling, but keep it easy for novice users. What do you think, @dkostenko-orion? Do you have any experience with that?
MDX is Markdown for the component era. It lets you write JSX embedded inside markdown. That’s a great combination because it allows you to use markdown’s often terse syntax (such as # heading) for the little things and JSX for more advanced components.
👆 The introduction to MDX.
For novice users: MDX is a way where you can bring predefined components into the Markdown format, like if you want a predefined newsletter signup form or maybe a branded call to action.
In the example below, I've written a makeshift blog that ends with a newsletter signup form.
---
title: Hello, world!
path: /blog/hello-world
date: 2021-03-22
---
import { NewsletterSignup } from '../components/newsletter-signup'
# Here comes Johnny!
We would love to have you signed up and ready to have your inbox
spammed down by our weekly newsletter!
<NewsletterSignup />
Notice a few things, what defines an MDX in comparison to a Markdown file is that
we can do import {} from ''
statements and we can add components (e.g. <NewsletterSignup />
).
Obviously, this adds complexity for novice users, but on the other hand. You can add components, you don't have too, meaning that new users don't have to learn this immediately.
Reference material:
Right! which is the benefit of using Sanity by a long shot. That being said, we do have Markdown editor our staff can use for content creation. Know that, does that change your opinion?
That does make it easier – so for a simple blog article that would be fine.
Btw, there are multiple editors for MDX too:
Other fun stuff, you can even create presentation decks with MDX. We can probably use Codespaces too 👍
Yes, MDX is great, @cobraz, but I think it won't be easy for non-developers to add content like that. On the other hand, at what stage will the style of the object on the page be determined, in advance or by the one who adds the content?
@dkostenko-orion Does the choice between Git & Sanity ( or something else) have an impact on time of delivery?
@seacurrent yes, but it is insignificant
Yes, MDX is great, @cobraz, but I think it won't be easy for non-developers to add content like that.
It's not as easy as Sanity, of course. But is it a «developers only» experience? We have to remember that we expect people at Bjerk to be able to use Github on a daily basis, including creating a pull request or setting up a Markdown file for documentation. This includes project managers, marketing etc.
On the other hand, at what stage will the style of the object on the page be determined, in advance or by the one who adds the content?
IMHO; Both. In blog posts, and when adding new pages to our website, we might create the style/design of the page whilst creating content. However, for now, we have all the pages created in advance.
I would love that everyone, not only developers, could create pages, blogs etc using Github and by training people on which components there are and how to write MDX they can design content easily.
I'll elaborate more on my answer from earlier.
I do agree with @cobraz on the fact that we do our work in GitHub and I think additionally it would be easier for me in the long run to continue working in GitHub instead of having more platforms to keep an eye on. So, with enough training I personally would choose to continue working in GitHub.
I'll take the freedom here to draw a conclusion that everyone agrees on GitHub. Please let me know if this is not the case. Otherwise, we can probably close this issue now?
Yes, it seems we all agree to continue with the Github option. However, I'd love to see a follow-up on this with a small implementation example. Would you like to do that @dkostenko-bjerk?
We could add a working example where we utilize MDX/etc/.. for a simple page/blog?
@cobraz Yes, of course
@cobraz @AnneMatilde @seacurrent @AnnaBjerk https://github.com/bjerkio/website/pull/77
I've checked #77. It's representative of how an MDX would look like.
Maybe @AnnaBjerk and @AnneMatilde can give some feedback on it?
Another thing we need to figure out is how to do localization (re #23). @dkostenko-bjerk do you have an idea here?
@cobraz I think we can use gatsby-plugin-intl
@dkostenko-orion Does the choice between Git & Sanity ( or something else) have an impact on time of delivery?
The GitHub will take one day longer to finish. Which means that, to make it on time for launch, we will have to make sure there are minimal bugs and fixes.
@cobraz what content besides projects needs to be done with markdown?
Closing this as we've decided (and we have a separate task to track removing Sanity)
First of all, using Sanity obviously adds to the complexity of the website. It was initially added because we want to give novice users the ability to add/edit content on our website, which can still be a valid point.
However, since then I've done some research to see which is the best options for Bjerk. I think its time to have an open discussion about this.
One benefit of removing Sanity would be that we'll be using Github for managing content, which means people who do marketing would also use Github for their day to day work. Another benefit would be having review-cycles (incl. CI/CD) for content work: look at how Pulumi do it.
Pros with Sanity
Pros with just Github
What else? What are your thoughts?
/cc @seacurrent @dkostenko-orion
fixes #72