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
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.
Built-in TailwindCSS:
Use TailwindCSS to streamline the design process and maintain consistency across components.
Facilitate rapid prototyping and customization.
Content Accessibility:
Enhance accessibility features (e.g., ARIA roles, proper semantic HTML).
Ensure the website meets WCAG standards.
Performance:
Optimize for fast load times and high Lighthouse scores.
Minimalist design with vibrant color accents and straightforward navigation.
Lightweight and performant, reflecting its core philosophy.
Action Plan
Research & Wireframes:
Collaborate with community members to identify core pain points and desired features.
Design wireframes/mockups for feedback.
Implementation:
Build the website using Next.js.
Integrate TailwindCSS for consistent and reusable styles.
Ensure full responsiveness and accessibility.
Content Migration:
Port existing blog posts, and community links to the new design.
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!
Welcome to the community @hich - it’s great to see you wanting to help improve things
I agree with what @garazdawi has said about maintenance, with any replacement ideally being easy to work on (I have no experience with Next or Nextra so can’t comment what moving to them would mean).
I think a lot of this will boil down to taste. Was your prototype based off a template? It is quite plain and does not have the same kind of identity or reflect the Erlang brand like the existing site does, hence personally I feel the current design does a good job in that regard - though perhaps just needs a few tweaks (mainly to spacing):
These feel more in-keeping with the Erlang brand to me (I actually suggested some of these tweaks when the site when live but they must have got lost in all the excitement, haha!) however a lot of this will boil down to taste and vary from person to person.
If you could alter your design to something like the above I think you might get people interested (assuming the Erlang team aren’t happy with Jekyll and want to move to something else). Either way I support the Erlang team in whatever they prefer
I understand your reasoning but it is based off of familiarity.
the current erlang website is stock bootstrap and basically has no identity.
the new website is much faster, more maintainable (MDX), and accessible.
and most importantly, it follows a common formula that all modern websites use which means it aligns more with user expectation.
hich, welcome to our community.
For your first posting to be so thorough, I congratulate you.
Should the community agree our website requires redesign, instead of javascript perhaps wxErlang could be a suitable choice? After all, the purpose of our website is to promote Erlang. One benefit of such a community endeavour might be updated documentation (eg. more wx usage examples in the manual). Thereby conferring an enduring benefit to all Erlang programmers.
I think there’s an important point going missing here. If (big if) the current site is too formulaic and lacking identity, and if (and only if) this is demonstrably(!) conversely affecting users and new adopters, then the way to fix that is not by having a developer choose a new template engine or styling system that they think looks nice. The way to fix it is for UX people to do some user research, do some functional design, follow up with actual user testing, then for visual designers to do some visual design, user-test again, and maybe then have some confidence that it will improve on what’s there. If there’s no time or funding to do all that, or (especially) if there aren’t any metrics to show that the existing site is failing new or existing users, then it seems churlish to dive in to an implementation without design of a new, basically also templated website. There’s no reason to resist an improved site; equally, there’s no reason to rush into replacing the existing one with no actual evidence that what’s proposed either is better-received or will be any more successful.
Functionality has to be the very top priority, agreed.
That includes functioning on elderly phones and tablets and laptops,
and functioning well. If the site is sluggish on my Rpi 4 I will be sad.
After that, accessibility.
I don’t see anything wrong with familiarity.
Think about supermarkets for a moment.
You go into the supermarket you’ve been using ever since your last move.
Bread isn’t where you expect it. It’s at the other end of the building.
Bacon isn’t in the same area as beef, lamb, and chicken, It’s over by cheese.
Speaking of cheese, the soft cheese with salmon isn’t anywhere any more.
Tinned beef and tinned spam are separated by racks of baked beans.
(These are all actual recent examples.)
When it comes to foraging, familiarity saves time.
When it comes to information seeking in a web site, familiarity saves time.
I can think of an excellent reason to renovate the Erlang web site,
and that is to say “hey, lookit what Erlang can do!”
That will backfire if the site is not very usable and performant.
if you wanna talk about bloat then try setting up the current website repo dev environment then try the new one, and see which one takes longer and requires more dependencies to render a simple static site.
Spoiler: the exising website requires 4-5 different technologies just to render HTML. Does that sound like bloat to you?
do you think it’s normal to require asdf to render some html pages?
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:
I understand but erlang is rarely used to render HTML
The erlang job market is almost entirely backend so it makes sense to delegate the static site to technologies that specialize in that and leave the erlang community to spend on their time on where the technology is actually being used in production which is backend
Rendering HTML is the job of the browser. Generating it is the job of the server and is very much within Erlang’s scope. I have zero comments about the technologies used to implement (build, maintain, operate) the current or any other web site. That is irrelevant to me as a user of the Erlang web site. What I care about is whether I can find the information and resources I need fairly quickly and whether other people with low or no visual acuity, or some kind of colour blindness, or hand tremor, or whatever can do so too, and whether the site puts strain on my low-end consumer bandwidth/quota, and whether the pages are choked with scripts and flashy video effects that put a strain on my browser. Can the site even work in black and white with scripts disabled? Can I use it comfortably on an RPi 4? Can it be navigated without a mouse or trackpad? (Some brilliant programmers can’t use them.). Can an open source information retrieval engine find all the text on all the pages so that there are search boxes to rely on?
I make no comment on the present site. I’ve never built a site of that size or doing everything it does, so the people who did it are obviously much better than me.
All my comments in this thread are the bleatings of a hungry sheep hoping for more hay and less barbed wire.
Even disregarding my earlier points about UX work, testing and design processes, which still stand, and jumping ahead to the rest of the discussion about implementation: to repeat my comment from the Github issue, what’s the rationale for using a React-based SPA framework, along with everything that entails for build processes maintenance, for what is essentially a static website? Why is that necessary or even desirable? Why not Hugo, or Jekyll (which as @garazdawi said on Github is already in place and has worked well for 5 years) - or any of a host of other static site generators?
Apart from anything else, the churn in React (e.g. it’s reducers, now it’s hooks, effects, what about routers, navigation, blessed tools, and so on and on) - let alone by extension the Javascript build/tooling world - means there’s almost certain to be more maintenance required than there is with the existing implementation. For an already-resource-constrained team, the fact that failing to keep up with deprecations and changes on every point release means storing up significant work and sometimes even refactors/rewrites at major releases, just to keep the project building. React is very much not the maintenance panacea it’s claimed to be. A static website doesn’t need to be a software project.
I understand it’s just my opinion, but as far as I can tell, there’s no need for a technical rewrite, and as already mentioned, if there is evidence that there are design or usability issues, then the fix is a design process, not a templated implementation of the SPA/CSS framework du jour. Again, only my opinion, but I think a more measured approach to any actually demonstrable evidence-based concerns about the existing site would better represent the Erlang community.
Just chiming in to say that I am happy to contribute to a redesign—after implementing, as @igorclark says, “a more measured approach to any actually demonstrable evidence-based concerns about the existing site.” Of course, functionality should be top priority. The question of maintainability is also crucial—and in that regard, it is important to consider the strengths, abilities, and interests of interested parties. Concerns about using things like node.js aside, it seems that few active members in the Erlang community are keen on using JavaScript in general. In short, maintainability means ensuring there are maintainers. To this point and also on a conceptual level, I also echo @kanga-roo in suggesting that a redesign should, at its core, promote Erlang. Tools matter. And so in my opinion wxErlang would be an excellent choice, as would other BEAM technologies. Elixir or even Gleam—languages that are certainly more grokkable if not familiar to many Erlang developers—both offer web application frameworks that one might consider for a project such as this.
First I checked https://www.erlang.org, to see that is “just” a publication web site. No highly interactive dynamic content, no flying saucers. It is all about publishing articles.
Next I looked at the proposal. And I see client side Javascript frameworks being proposed.
Client side javascript frameworks are good at applications with highly interactive use cases. The Erlang website is a website with content that is being published.
The design of a website is completely separate of the technology used to generate the HTML. CSS and HTML make the design, define the looks, and implement the accessibility.
Isn’t it an idea to just:
Make a design using CSS and HTML
Use a CMS to generate that HTML and maintain the (potentiall multilingual) content.
Generating the HTML also enables machine readable content. Personally I very much dislike web sites where the content can’t be read by simple crawlers. Server side generated HTML is also better for (non Google) web crawlers.
Erlang is great at generating HTML, it is just iodata.
And Erlang is great at serving thousands of parallel connections.
That is why we use Zotonic for building websites.
ImageMagick (we do want to have images, don’t we?)
I had to smile a bit when someone mentioned “just Node.js”. Installing Node.js comes with npm and a whole truck load of dependencies and a lot of Javascript packages.
Almost everybody is a better web site designer than me.
It is certain that you know a heck of a lot more about
current toolkits than I do. It’s like shoes. I could
not make a good shoe to save my life. That doesn’t mean
I can’t tell whether or where it is pinching. It’s the
reason for a republic: there is no way to choose good
leaders, and the populace are not trained to come up with
solutions. But the populace are the real experts on whether
things are working for them, and we need a way to make the
crummy leaders we get pay attention.
So don’t take this as any kind of aggressive response.
It’s a genuine question whose answer will educate me.
You say that the new site is
a better user experience
more accessible
easier to maintain
faster.
This is great. I guess there are actually two questions.
(1) HOW ARE YOU MEASURING these things?
I note that the spread of webmark scores for the browsers
I use (on the same system) is a factor of 2 and that the
fastest ones spew hundreds of OpenGL warnings on the console
during the test. Not that webmark addresses much of anything
that an Erlang web site should be doing, I’m just making
points about benchmarks, browsers, and speed != quality.
(2) I personally would much rather have plain text with
accurate information
correct vocabulary, grammar, spelling, and punctuation
than the most beautiful documentation available that is wrong.
For example, there’s a book I was thinking of buying about a
particular visualisation engine, but I found out today that
none of the examples work in the current release of that engine
and that the promised update isn’t on the market yet. For some
reason today, I’ve run into a heck of a lot of dead links, many
of which lead me to some sort of game in Thai. Question 2 is
WHAT ARE YOU DOING TO ENSURE THE ACCURACY OF THE SITE?
If I want something fancy schmancy that is plausible but wrong,
I might as well ask ChatGPT.
These are genuine questions that will do much to improve anything
I do to make a site. How to know whether the new site is better
than the old, and how to ensure that the site is worth visiting.
This is my beef with javadoc, edoc, and all the other things that
take the idea of literate programming and invert it.
The formatted documentation is often quite pretty, but not worth
having. I’m thinking of things like a timestamp class whose
documentation stated that the range of zone offsets was -12 hours
to +12 hours. I believe the upper limit is actually +14 hours.
I’m thinking of official documentation from a major company that
documented an option that did not in fact exist. There are two
kinds of documentation I trust: checked types and tested
examples (including test cases).
It’s not the job of a web site designer or a documentation
formatter author to provide types and tests, it’s the job of
technical writers (ideally). Getting the information right is
a huge and never-ending task, and the text needs to be
preserved as web and documentation frameworks are revised.
In all seriousness, when I am trying to solve a problem,
the only things I care about consciously are
can I afford to get to the information source
can I find the information I need there without too much pain
By the way, I’ve been through a web site redesign where the home-brew web site of an organisation was rebuilt by a professional
web site company with NO consultation with members or clients of
the organisation. (And no concessions to usability, over my loud
protests. Thankfully not an issue here, I understand.) The result
was a web site that was much more visually appealing and uniform in
style, but one in which the process for making corrections to
content was now intolerably prolonged, because we oiks weren’t
allowed to touch the site. The new site was also harder to
navigate than the old one, because the site designers didn’t really
know what the information needs of the users were. (We also had
in-house expertise in information retrieval, which was excluded
from the web site.)
Log analysis from the old site can tell you a lot about what
improvements need making, but it’s not easy.
Yep completely agree. The LAST thing I want to see an Erlang official web page developed in is node.js. There is excellent Erlang and Elixir technologies that are quite capable and appropriate. Zotonic looks pretty powerful. I know we do most all of our backend work and RESTful interfaces in Erlang and most of our web-based front end work in Elixir/LiveView. Kinda embarrassing to abandon our own tech stack for something that offers nothing better than what we have. Now a fixed static website using a static website generator would be fine and we’ve happily used those in the past.
