Looking back, keeping this monthly journal has been both rewarding, and mildly stressful. The source of the stress is more of a psychological nature than a technical one. Writing isn't technically easy, no doubt, but more important, there seems to be a double-standard situation: with coding, which can also be challenging, when a task takes lots of time and energy, I perceive it as a reward signal: good work is being produced; but with writing, I still perceive it more or less as something that takes my time away, and the amount of time spent often seems more than necessary, and that makes keeping up this effort so taxing; Overtime isn't regarded as a positive effort, but rather a failure in time management.
But I'm not being fair. I can't deny that there have been many moments of enjoyment. The ultimate drive, I suppose, is the belief that my journey is a different one, and it is worthy of being recorded. There is no grandeur in it, just basic respect for a normal life.
That being said, the stress is also real, and its fundamental cause is that writing isn't my primary domain. However, I think there is a solution: what if I take care to make myself continuously aware of the benefits of writing, a unique set of benefits to the primary domain (and life in general) that is non-substitutable by other efforts? For starters, read what you wrote!
In addition, there is an intricate trade-off between writing smoothly and swiftly (by using all the familiar constructs and patterns), and writing deliberately and diligently (by learning and practicing more advanced expressions). The former cuts time, but is just not as rewarding, for it will gradually feel more and more like a routine; nevertheless, the latter can place tremendous pressure on the writer, as things often seem to be moving unnecessarily slow: why does a monthly review have to be so taxing? Therefore, there is a sweet spot between the two extremes that is yet to be found. Indeed, details and refinements often take a disproportional amount of time, in contrast to finishing a rough draft; this is kind of like coding, where getting an MVP to "work" might take surprisingly less time than bringing it to a highly polished and sophisticated quality in terms of performance and UX.
But in the end, I think the most important thing is, just keep at it. Enjoy those moments of rewards, learn to deal with the stresses, and try to optimize things and strike a balance. In fact, through this experience, I'm more convinced than ever that writing is an integral part of personal and career development. Reflection or introspection is important, and writing is one of the best implements. Yes, you can learn a lot by just doing things, but if you care to take some time off and think about what you just did, you might get extra insights otherwise hidden.
Summary
- Ported two practical functionalities from Projection to Arrow: 1) informative page title, and 2) search for AND-connected words, in addition to the existing "whole-phrase" search. They are basic and taken for granted, but through extended personal use, these two small features really stood out as the most missed UX details.
- Tried out Elm-UI, with the initial goal of replicating major UI structures of the current version, including a dual-pane layout with independent scrolling; with that accomplished, the real fun started, namely designing and implementing novel data viewing (e.g. filtering) features.
Elm-UI: Fun Indeed
The author of Elm-UI, Matthew Griffith (Matt), in his superb introductory talk, said he wanted to make UI work "fun", fun like Lego in particular. I'm no Lego player, but after I got the hang of Elm-UI, I couldn't agree more: it truly enabled developers to directly and intuitively code up what's in the head! The secret is, like Lego, there is no compounding effects when many simple pieces are put together to build something more complex. Matt made the bold statement in the talk that the main problem with Cascading Style Sheet was that it's cascading. It's the lack of true modularity (shielded from global setting) that makes CSS (esp. in large, production-grade frameworks) very tricky to change without breaking things. And that means it's very hard to get novel, custom designs by working on top of pre-existing CSS code. Indeed, in my previous experience with Bulma, the extent to which you get to have your own "style" is quite limited: basically, you only adjust sizes and colors, which I don't think really qualify as making custom designs. To be fair, it is still possible to build more complex structures from a mix of Bulma components, but that can easily become more of a burden than a shortcut. I think that is why some people are turning to very different approaches (such as Tailwind) when making fully custom designs. Elm-UI is also for making truly custom and novel UI designs, but like Elm, it is elegant.
But because Elm-UI is for custom work, I think a UI novice will most likely benefit from working with an existing, well-made CSS framework beforehand. Again, like film-making, UI design takes more artistry than mechanical skills; for instance, I doubt one could start creating pro-level UI after just reading a big book on CSS. Actually the whole point of Elm-UI is to show that, as long as you know how to design, you don't need to know CSS (because it is a suboptimal design toolkit, to say the least).
Personally, I think good design, besides innovations and inspirations, comes from excellence at two levels:
- the overall layout of a UI structure, and
- the visual details, including spatial/size relationships, color relationships, and decorations, e.g. border effects.
And I find Elm-UI highly ergonomic and effective at both. Its existence not only shows the brilliance of the author, but testifies once again the power of Elm and pure functional languages in general. It is a true blessing.
Hiccups
It did take some getting used to before I got comfortable enough with Elm-UI.
In particular, the very first stumbling block was about the explicit need for fill in order for certain layout designs to work as expected. Later on in the author's note, I read that every element is shrink by default, so e.g. if you don't width fill, then centerX or alignRight may not work, because the total horizontal space is by default all collapsed.
Another related tricky situation was encountered during my mission to replicate the aforementioned "dual-pane with independent scrolling" layout. After some trial and error, I realized that, without explicit height fill on both the scrollable element and its parent, setting scrollbarY would actually collapse the scrollable element, rendering it invisible (flexbox fun I suppose).
Lastly, I noticed that specifying padding and spacing on a wrappedRow couldn't be done reliably, where a row seem to behave perfectly in this regard. In the same note, I saw that it was among the "things that had been removed/deprecated":
wrappedRowandwrappedColumnare gone. From what I can see these cases don't show up very often. Removing them allows me to be cleaner with the internal style-elements code as well.
So I suppose after the initial release, users requested that they should stay. Unfortunately, it is probably a very tricky implementation, and my observation is likely to be one of the manifestations.
But so far, there have been no unresolvable issues, and overall, it is a delight to work with. Its superior simplicity and controllability enabled UI designers to swiftly and reliably get from the sketch (even in the head) to the actual implementation. This is very liberating, and not at all easy to achieve in CSS/SASS, even with many years of experience, according to some web developers.
Elm-UI is still very young, compared to CSS/SASS, just like Elm is young compared to JS. But I think what it brings right now already significantly outweighs the drawbacks such as its immaturity and small ecosystem. Since I care about my projects, writing highly maintainable code is paramount. I want to be able to improve things with confidence, even when extensive changes are required. Traditionally in web development, due to the maintainability problem, "rewriting from scratch" seems to be a fairly common "strategy" to evolve a project, and it is often done proudly! But that is clearly wasteful and unfortunate. For any non-trivial app, a big part of its value lies in the user-facing functionalities, rather than the technical architecture; and more often than not, porting all these existing features, with tremendous amount of details, to a brand-new foundation, is no smooth sailing. (We often see a new version of some popular app coming out, but only with a limited feature subset from the predecessor.)
I think what Elm-UI, as well as Elm, presents us, is an architecture that is forever "fit", such that no evolution requires its discard. Biology works in a similar way: how genetic code works is an architecture so basic, general, yet powerful, that this foundation is never challenged by the nature; throughout time, only the details have to be selected.