Looks very professional! The new links are very sensible in the modern web, I quite like it.
And it all still works very well with the Dark Reader extension, lol.
Looks very impressive! What is missing on the mobile version is the fixed menu at the top of window. It would be great to have a menu in fixed position in the top and a quick scroll up button in mobile version. But still looks very cool!
Looks modern enough. One caveat, the scroller at the top, with the examples. I don’t think a scroller (or carousel, or however you want to call it) is the right medium for this. The examples are not a simple one liners that leave an impression, but a bit more complex for the speed in which they fly by.
The other issue is that even if you focus on them, these should’ve been picked by someone totally new to Erlang. The examples are verbose and highlight elements that, once you know some Erlang, you can appreciate. To someone who is new to the language (who is, I’m assuming, the target audience of this part of the site), they are way too verbose, cluttered and mostly nonsensical as even the simplest of them assume understanding of Erlang syntax and semantics. It’s a nice effort, but wholly misdirected. I can go into details if needed.
I agree that the current carousel examples are not perfect, but I have not yet come up with anything better.
Before talking about what we can do to make things better, I just want to make sure that you have seen that there are two different variants of the examples. One for small screens (i.e. mobile) and one for large screens.
My goal with the examples was to showcase some example Erlang code that would interest the viewer to learn more about Erlang. They are not meant to teach anything, but rather showcase what is possible. The idea is borrowed from the python and haskell websites.
Do you have any ideas about what examples would be better to show?
On the desktop it’s not a major issue, seeing that I can hover upon it with the mouse, but on a mobile there’s maybe a need to make it not move automatically, maybe stop if the user click on the arrow indicating they want to focus on one slide.
At least you chose a better contrast than the python’s, that ones unreadable. I checked both mobile and desktop, and I think mobile is better. It’s a less-is-more approach to me since the idea is not to carpet bomb but to make surgical strikes. The mobile example of the factorial is better, for example. Everyone who learned to program knows about factorial, being the most common example of recursion, so the example is as intuitive as you can get. Anything further (comments, list comprehension) just ads information that the user will either won’t get or ignore.
Same with the higher-order function example, the mobile one is good, the desktop one, less so.
Now, Light-weight processes. Honestly, I wouldn’t even go there, mobile or desktop. I’m trying to think what would an Erlang newbie get from this and I don’t think they would. In my opinion, have a bullet-point slide “concurrency built in! small, encapsulated light-weight processes!” stuff like that, would make it better.
Finally, the map-reduce one, I really can’t tell, to me its too verbose, either version, but I don’t have any suggestion to improve it or a better example.
We use the Bootstrap Carousel the default there is that the carousel pauses for a while when you touch it on a mobile device. Not sure how intuitive or normal that behavior is, but I’d hope the bootstrap team has chosen a default most people are used to.
One of the most unique things about Erlang though is the way that light-weight processes work. Don’t you think that deserves an example of some sort? Or maybe we should show-case the error handling?, though that is even more complex…
I’m not an expert in What People Think, but I believe most people who come to Erlang do it because they hear it’s the bee’s knees in all things concurrency. I really don’t know if there is a need to show it unlike other elements, but I could be way wrong here. My argument is that the code does not do much to convey why it’s better, rather how it’s been written. To me, it would be better presented as bullet points, for the appeal to an interested side, since they will not gain any understanding of the why it’s a unique and great concept from the code. It’s open for debate.
