Proposal: Redesign Erlang Website with Modern Design Principles

[hichemfantar]

Edit: Hosted prototype https://erlang-website.vercel.app/
Prototype Repo: https://github.com/hichemfantar/erlang-website

Description

The current Erlang website, while functional, could benefit from a modern refresh to better represent the vibrant and evolving Erlang community. This proposal aims to rebuild the website using modern design principles with TailwindCSS for styling, ensuring a visually appealing, highly responsive, and developer-friendly experience.

---

Objectives

1. Modern Design:
   • Clean, intuitive UI that resonates with both new and experienced developers.
   • Improved navigation and content hierarchy for easy access to learning resources, documentation, and community links.
2. Built-in TailwindCSS:
   • Use TailwindCSS to streamline the design process and maintain consistency across components.
   • Facilitate rapid prototyping and customization.
3. Content Accessibility:
   • Enhance accessibility features (e.g., ARIA roles, proper semantic HTML).
   • Ensure the website meets WCAG standards.
4. Performance:
   • Optimize for fast load times and high Lighthouse scores.

---

Proposed Stack

• Frameworks: Next.js with Nextra
• Styling: TailwindCSS
• Deployment: Vercel or GH Pages (via Next Static Generation).

---

Inspiration

Here are some examples of modern and visually compelling developer websites:

• React.js

  • Clean layout with a strong focus on interactivity and learning resources.
  • Great use of Tailwind for styling consistency

• Vue.js

  • Consistent design with clear navigation and call-to-actions.
  • Developer-friendly tone and design.

• Astro

  • Modern and approachable aesthetic with bold typography and animations.
  • Well-structured layout for documentation and blog content.

• Vite.js

  • Minimalist design with vibrant color accents and straightforward navigation.
  • Lightweight and performant, reflecting its core philosophy.

---

Action Plan

1. Research & Wireframes:
   • Collaborate with community members to identify core pain points and desired features.
   • Design wireframes/mockups for feedback.
2. Implementation:
   • Build the website using Next.js.
   • Integrate TailwindCSS for consistent and reusable styles.
   • Ensure full responsiveness and accessibility.
3. Content Migration:
   • Port existing blog posts, and community links to the new design.
4. Testing & Feedback:
   • Conduct usability testing with community members.
   • Gather and incorporate feedback for iterations.

---

Community Involvement

This redesign is a collaborative effort. We encourage contributions from designers, developers, and accessibility experts to make the new website a proud representation of the Erlang community.

---

Expected Outcome

A sleek, modern, and accessible Erlang website that attracts new users, supports the community, and highlights the capabilities of the language and its ecosystem.

Feel free to suggest additional features or share feedback! 😊

[garazdawi]

Hello!

We welcome all the help we can get, as none of us maintaining this site know much/anything about web development.

When implementing this version of erlang.org 5 years ago, the first prototype was in Next.js using SSG, but I decided to use Jekyll instead hoping that it would lead to an easier to maintain website. Not sure if it was the right decision or not, but it has worked well for us in the past 5 years. After choosing Jekyll, others have suggested we use Hugo or even Docusaurus.

Any re-design will have to focus on maintainability, as both we and other non-web developers have to be able to do updates without too much of an effort. I would not mind changing CSS framework from Bootstrap to Tailwind, as that seems to be what everyone has settled on right now.

One pain point that you will find is that members of the Erlang community rarely have web-development as their main focus, so getting the wider community interested might prove difficult.

Maybe a good start would be to do a post on https://erlangforums.com asking if anyone else is interested in helping out and then go from there. I will try to help out as much as I can, but I don't have a lot of time to spend on this.

[hichemfantar]

Thanks for the detailed reponse!
I'm working on a prototype and I'll share it soon here and in the forums 🚀

[hichemfantar]

@garazdawi here's the prototype, let me know what you think

[garazdawi]

I’ll take a more thorough look on Monday, but my initial reaction is that I like it. I assume you created it using next.js? Can I have a look at the source?

[hichemfantar]

Great to hear, it’s next js and mostly markdown so it’s super easy to maintain.
Source https://github.com/hichemfantar/erlang-website

[hichemfantar]

@garazdawi i could use your input on how to handle EEPs

should we just move them to the same repo and render them directly as markdown?

This will eliminate the need for a different repo and we can get rid of the gh actions

[garazdawi]

They need to be in a separate repo as we want the discussions and contents to be separate from the main website.

I've not had time to look anything today, I'll see if I can find time tomorrow.

[hichemfantar]

having them in a separate repo is no issue, the new website supports rendering remote content

[hichemfantar]

@garazdawi included a few eeps as examples https://erlang-website.vercel.app/eep

my proposed solution is to include a script that clones the eeps markdown folder then render them directly as local files.
then you can rerun the script to sync with the eeps repo. this is a good solution because if the eeps repo ever goes down, there's still a copy in the website repo.

[hichemfantar]

@garazdawi should we go through with this? most of the hard work is done already

[garazdawi]

Hello! Sorry for the delay in answering.

My main concern regarding this is long-term maintainance, I like the new design and don't have any opinion on the tooling. We need to have a website that we either can maintain ourselves or can trust in the cummunity to maintain over the next decade or so. Therefore we need to get more people involved in this in order for us to not have to rely on you, nor that you will have to feel any pressure to keep maintaining it long after you have lost interest.

So if you can gather some more people that want to help out, preferably people that are active in the Erlang community already, we can start working on converting the site.

If you don't want to/cannot gather more people to join, then maybe a compromise would be possible? Can we convert only the css+html to the new layout, but keep the current jekyll tooling? That was we can maintain the site while still getting a new look and feel.

[hichemfantar]

thanks for the detailed response. feel free to cc anyone you think might be interested in working on the project.

also the current setup reduces the number of technologies from ruby, jekyll, and nodejs to simply next/node. it greatly simplifies the dev process and is much more customizable since it relies on MDX which is markdown that is easily customisable with JSX.

should i focus on the erlang forums to find collaborators or are there other channels you recommend?

[garazdawi]

should i focus on the erlang forums to find collaborators or are there other channels you recommend?

I would start there atleast. Maybe ask on the Elixir forums as well, as it is a larger forum and there might be people there that are interested in helping out.

[asabil]

Funnily enough, my friend @jprieur and I, were just talking about whether we should put in some time to try to help improving the Erlang website.

My personal feedback on this is that the approach @hichemfantar went with is very good, and would strongly recommend pursuing something similar. I believe the website should be relatively easy to maintain as it is mostly (extended) markdown documents, and seems much easier to work with than the current Jekyll setup.

Styling wise, I would personally reduce some of the effects, such as the one on hover over the logo and the download button.

[hichemfantar]

a potential contributor suddenly appears!
Thanks for the feedback, about the logo and cta button effects, they're pretty enough to improve the feel of the website and subtle enough not to distract.

for example, the logo hover effect is to properly convey to the user that they're hovering over the logo and that it's clickable (good ux).
there's very few cta buttons like the download button so the animation gives it a little life.

these little things give the website some character and it doesn't feel like just another static site.

also the animations can be disabled when the user has reduced motion settings in their OS

[hichemfantar]

btw the website is pretty much 90% done, i just need to add some custom react components for the dynamic stuff like the download menu and some other stuff and we're good to go.

once the website has feature parity with the old one, i can create a branch in the current repo then we can merge with main.
we just need to create a branch with the legacy version of the website for preservation and we should be good to go!

[hichemfantar]

@asabil @jprieur would you be willing to contribute to future development of the new website?
i can point to good react/next resources that will get you up to speed pretty quickly if you're interested.

[lpil]

Given the rate of change within the Next and the much more niche Nextra ecosystem compared to the much older and very-static Jekyll ecosystem I am a little concerned this will make the site more difficult to maintain over the next 10 years rather than easier. As far as I'm aware we don't have much Next related experience on-hand.

I've been looking through the Nextra documentation and the prototype looks almost exactly the same as the default template for Nextra. I think we would be losing a lot of charm and character if we were to move from the "Erlang" style of the existing site to a generic template.
If we do rewrite the website I think we should aim to still have a distinct visual brand afterwards, like we do today.

[bcardarella]

This is really nice 😄

[hichemfantar]

one point to mention:

You need to have the following tools installed to build the current erlang.org site:

• GNU make 4.1 or later
• ruby 3.3.0 or later
• bundler 2.5.6 or later
• nodejs 20.11.1 or later
• erlang 26 or later
• xsltproc

You need to have the following tools installed to build the new erlang.org site:

• Node.js

[hichemfantar]

The design isn't final and we can definitely work to make it more personalized to the Erlang brand.
but first we need to agree on the tech stack

[igorclark]

What's the rationale for using a React-based SPA framework, along with everything that entails for build processes and maintenance, for what is essentially a static website?

[hichemfantar]

@igorclark next.js does static site generation and server side rendering, while also supporting SPA paradigms.
The build process is pretty straightforward, run npm run build and you get a static build with an html page for every page in the website.

check my previous point on how simplified the tech stack is with just node.js, it's down from 6 technologies to only 1

[lpil]

It is only one language toolchain to install, but the overall dependency tree is much larger, and the dependencies are younger and have API changes with much greater frequency.

For me the ideal would be a site that can be built with just standard Erlang tools. I wager that would be the most approachable for us Erlangers.

[bcardarella]

Considering this is a pure marketing site, I don't think there's a real need to bikesheed over the tool used to build it. You could go host on WP, Drupal, or any other big CMS as well and it doesn't really matter as long as it doesn't get in the way of the team maintaining it.

[lpil]

That's precisely what I'm getting at. Moving from a mature and stable tool to a young and volatile one seems to go against the "don't get in the way long-term" goal, and runs contrary to the wider Elixir+Erlang move away from the npm ecosystem for stability reasons.

[Benjamin-Philip]

Personally, I don't even see the necessity to move away from the current Jekyll site. I think all that's needed is to maybe refresh the stylesheets and also switch from bootstrap to the standalone Tailwindcss binary (killing the nodejs/npm dep with it).

Switching stacks seems to a lot of effort for contributors as well as for the OTP team who need to get accustomed to a new system, when all they need is website to make the occasional announcement.

[hichemfantar]

the existing website already has a decently sized lock file https://github.com/erlang/erlang-org/blob/master/package-lock.json that's not so different in size from the one in my proposed project

also the existing website also uses React a bit.

I don't know why y'all think having to install 6 technologies and managing them via asdf is more maintainable than a next.js project. You can easily lock the deps if you want things to stay as they are for future installs.

even @garazdawi said he considered moving the site to next.js at one point so i presume even he felt the pain of the current setup

[Benjamin-Philip]

the existing website already has a decently sized lock file https://github.com/erlang/erlang-org/blob/master/package-lock.json that's not so different in size from the one in my proposed project

also the existing website also uses React a bit.

I don't know why y'all think having to install 6 technologies and managing them via asdf is more maintainable than a next.js project. You can easily lock the deps if you want things to stay as they are for future installs.

I think you are missing the point everyone's making. Installing 6 technologies is not the real pain point - you can always write a Dockerfile or a Nix derivation for that. The point is:

• We're wary of Nextra's stability, its obscurity, and if it will even be maintained 5-10 yrs into the future
• The OTP Team and most potential contributors are not frontend devs and lack the time to keep in touch with JS and its ecosystem for the sake of this website
• Rewrites are hard and take time and effort from all parties involved

he considered moving the site to next.js at one point so i presume even he felt the pain of the current setup

I think you misread. He mentioned that the prototype was written in Next and that he moved away from it. I'm also unsure what are the paint points you are referring to, since he clearly mentions it's worked well:

When implementing this version of erlang.org 5 years ago, the first prototype was in Next.js using SSG, but I decided to use Jekyll instead hoping that it would lead to an easier to maintain website. Not sure if it was the right decision or not, but it has worked well for us in the past 5 years. After choosing Jekyll, others have suggested we use Hugo or even Docusaurus.

I'm sure there are ways the website can improve, and we appreciate your enthusiasm to contribute. This is a personal opinion, and @garazdawi may disagree, but I feel that all that's needed is incremental improvements to make what we already have better.

[igorclark]

Thanks @Benjamin-Philip, I just nearly finished a dissertation on this 😬 but you beat me to it with a much neater and more concise version.

I have no decision power here and this is my personal opinion too, but for the record, as someone who cares about erlang, I agree 100%.

[hichemfantar]

Docusaurus is also an option if Nextra is the issue

[hichemfantar]

I understand the community's desire to use Erlang tech for the website.
If eventually the decision is made to use Erlang tech then I'm willing to work with the team to make it happen.
Same applies for next.js and docusaurus. I'm willing to work on improving the site either way.

[asabil]

@hichemfantar sorry, been traveling last week and had too much on my plate. I am very happy to help maintain/fix the website if @garazdawi agrees.

I am very familiar with JavaScript/TypeScript as well as web technologies in general.

Most discussions in this thread have unfortunately been bike-shedding around which technologies to use. The main topics we should address should imho be:

1. Who is the target audience of the Erlang website?
2. How can we improve the messaging/content around the Erlang website to better serve the audience identified in (1)?
3. How can we make sure that the Erlang/OTP core team can easily publish content within this new framework?
4. Do we need any help/support from other initiatives within the Erlang ecosystem to achieve the above?

In other words, I would rather start by sketching a "map" of the website and what kind of content it should host before even talking about how to implement it.

[hichemfantar]

@asabil that's great to hear! feel free to tag anyone else who might be interested in joining the effort

[igorclark]

@asabil there's been a lot of discussion on the forum which definitely wasn't "bikeshedding", rather issues about maintainability and (equally importantly) UX and user reqs which didn't really get addresssed there or here, so personally I'm super glad to read your post - an Erlang community member with web skills, functional design/user-focus awareness AND time available to work on it?! That's basically a unicorn. Amazing. Thank you 🙏

[osbre]

I must admit that the idea of a redesign has once crossed my mind. Here is a screenshot of what I got to back then:

It was a quick draft via Vitepress with slight customization applied. I kinda liked the idea of that layout but it didn't feel "right" yet (needs many iterations and fresh experimentation)

---

I'd be happy to join and contribute where I can (Tailwind CSS, design choice ideas). So far I think the current homepage design shared by @hichemfantar looks rather generic, or as @lpil put it, "lacks charm and character".

I feel at ease using a simple static site generator instead of Next.js and its fast-changing JavaScript ecosystem. Tailwind CSS and HTML components work anywhere, and the site does not need any JavaScript except for small interactivity bits such as the search box.

[221V]

there are no any real reason for use heavy-monstruous javascript frameworks instead of simple static website :)
that is just fashion for madness with that js frameworks, imho

lets keep erlang website lightweight, please

css is really enaught for redesign, no needs megabytes of js shit for simple website

maybe more useful for erlang users will be focusing onto optimising erlang compiler/runtime, huh?
there are the field for work, really no needs megabytes of js shit for simple website

thank you

[hichemfantar]

The prototype is meant to showcase the ease of maintenance via mdx and customization via tailwind.
It’s not meant to show off design, that’s something subjective and there are many things we can add to make it unique (it’s also a community effort)
The main reason I created this proposal was because when I wanted to make improvements and saw the 6 technology setup needed, I felt it was over complicated and I was discouraged from setting it up.

[hichemfantar]

@osbre @221V next.js is a static site generator

[hichemfantar]

Here's a showcase of projects built with Nextra