I decided to take on the project because I couldn’t find any resources when I first approached the topic1. A feature of the guide that’s worth mentioning is the ability to fill in the blanks with missing code, compile and run the resulted whole, and see the rendered product, for a more interactive learning experience.
I’ve spent a lot of efforts on the guide, so I welcome feedback in general, especially if something is broken. Feel free to post here or open an issue on the GitHub repo.
I was hopelessly uneducated on how emoji really works. The helpful people on Elm Slack reached out to me and asked why I need to replace emoji text with images, when apps can directly render emoji unicode. Long story short, it turned out that my main browser, Brave, despite being good for privacy, has been failing to render the colored versions of emojis. So whenever I think of emoji unicode, I thought it’s the primitive version of emoji like these ones:
I reached the conclusion that my algorithm is relevant for compatibility. Many apps like Slack and Discourse do seem to swap emoji unicode with images, if browser doesn’t render emojis in color. GitHub is known to do this. Or in cases where one needs to replace emoji indicators like :smile: with emoji unicodes or images. The Slack conversation is here: https://elmlang.slack.com/archives/C0K384K4Y/p1634244030195400.
Some known issues currently:
Compiling code can be slow or time out because the VPS I’m renting isn’t powerful. If the server gets multiple requests, invoking multiple Elm compilers seems to take up all of its memory. Setting up a swap file wasn’t successful, and I’m contacting support over this.
This is nice, it explains why you were asking how to build a similar service as Ellie on Slack: it’s to power your interactive blog post!
I enjoyed it, but some critical feedback:
Usually, when I am reading an instructional blog post, I don’t expect have to “do work”. It was not at all clear to me that I had to type things into the input boxes
That leads me to the next piece of feedback: the styling of your blog post is quite lacking. I’m certainly no professional designer, but there’s no good indication that I’m supposed to interact with things and what the outcome is. And there are three types of interaction, none of which is explained:
Implement a full function which gets compiled (inputs with “Compile”)
Implement a partial Elm syntax (the Maybe. and Tuple.)
Implement a valid Elm expression that replaces the ???
It’s unclear which input replaces which ??? in the code block itself.Also, the fact that the code block and the input aren’t visible in the same view means I have to constantly scroll up and down to see what’s going on. Perhaps consider allowing changing the code block inline (i.e. make the ??? editable directly), or place the code block side-by-side (horizontally) with the prose? The latter suggestion wouldn’t work well on mobile devices, though.
Compile times are insanely slow, but I know you’ve mentioned in the first post that this is something you’re looking to address.
Love to see where you take this, it’s really quite amazing!
Hey! Sorry for the late reply. And thank you very much for such a detailed feedback I really needed perspectives other than my own.
The only indication for inputting code is textual instruction. Paired with the default text input box from elm-ui, the sign of interaction is indeed pretty weak. I wanted to implement what you suggested, the inline code editing similar to https://www.haskell.org/. However I seriously lacked the CSS skill to do anything outside of elm-ui. If I catch up with that, it will probably solve the ambiguity of which code is being edited, the inadequate vertical space, and help indicate interaction, maybe with some other help.
My initial plan about where I’m taking this is likely a blog series on implementing a full emoji solution, including parsing, displaying, emoji picker and so on. However, as shown from what I’ve edited in the “Updates” section of this post, I didn’t know people can directly type emoji already I haven’t planned much yet, but if I’m moving forward with this series, I probably need to think about and address the use cases first.
The concept and implementation of interactive guide can certainly be used on new topics as well. Although as much as I’d like it, it seems dangerous to replicate the idea on a backend language? User can do a lot more with a backend language, then a frontend one. I could limit input length, but I worry if someone may still find a short, clever piece of backend code to run and compromise the server.
I do wonder if there are similar blogs. It will be fun if I find one.
I really needed perspectives other than my own.
I haven’t planned much yet, but if I’m moving forward with this series, I probably need to think about and address the use cases first.