Design drafting

Posted in

#101 by yorhel
2019-03-15 at 10:37
Looks great, I'm loving the compact cards! Not sure the search bar really has to be that huge, though.
#102 by witchcapture
2019-03-17 at 00:35
Awesome. Good point, will compact the search bar down when I do the CSS.
#103 by witchcapture
2019-04-18 at 09:44
Quick update, I'm not dead! Moved to a new city and started a new job last month so I've been super busy, but will implement the CSS/HTML for the results page this month for sure :)
#104 by witchcapture
2019-05-01 at 09:43
All righty, PR up for the results/listing page: link
#105 by yorhel
2019-05-03 at 09:19
That looks awesome! Only issue at the moment is that it wastes a lot of space for widths between 992px and 1200px.

What did you base the popularity icon on? It looks good, but is that a flame or a hook? :D

As for different news, and the reason why I haven't been very active lately: I'm putting this rewrite on hold for a bit to rethink the approach. Some observations from our current progress:

- Backend: I've made a few changes compared to the current backend, and for the most part it seems to be an improvement. Not quite as significant as I had hoped, though, it's still tather messy and there's room for improvement. But it's... acceptable.
- Frontend/JS: Elm is pretty great, but it has major downsides with interacting with everything else. I've automated a large part of the data serialization/deserialization with the backend, but there's still room for improvement. My biggest annoyance with Elm is the integration on the page and the rest of the JS - the lightbox and other modals need quite a few workarounds.
- Frontend/HTML+CSS: I thought I could get used to the industry-standard boostrap-like div-soup, but I can't. It doesn't play nice with HTML DSLs (neither in Elm nor Perl), and I still can't fully keep track of which CSS affects which HTML.

As for Elm alternatives, I'm a big fan of the approach that Ocsigen has taken, but that project is seriously lacking in other aspects. I recently stumbled upon Phoenix LiveView and that looks *very* promising (I had been interested in Elixir/Phoenix before, but that may be the actual trigger to switch). Rust also looks like it has both the technology and the momentum to provide a similar development experience - without the network latency - e.g. with Sauron. Neither of those solutions are very mature at the moment, though, so I'll have to experient and wait it out a bit.

The HTML+CSS problem is one thing where I'm still looking for solutions. I'm a big fan of meaningful CSS and have used it with a few smaller projects. But that doesn't solve the problem of how to organize the CSS of a larger project like VNDB for maintainability. I'm looking if there's a nice approach for writing styled components on the backend, but failing that, a way to keep a closer link between the HTML and the CSS.

I hope I'm not disappointing you too much with this announcement. I mean, I always said that this was going to be a long-term project, but it looks like it'll take even longer still. I'm not aiming for perfection, but if we have to settle with "meh, it works", then there's little point in rewriting VNDB in the first place. The new layout is great in any case, and that'll definitely be reused!
#106 by witchcapture
2019-05-05 at 03:13
Ahh, true. Will fix that.

The popularity icon is a redrawn version of the "fire" icon from Font Awesome 5 :P Does it need to look more sharp and flame-y do you think?

Yeah, I see what you mean about the div soup. The long CSS class names definitely don't help either. I don't think I actually mentioned it anywhere, but the class names are BEM, by the way, which makes large-scale CSS a bit easier to maintain - and generally fits in well with component-based construction. Most of the reason for the large amount of divs is just because they are needed to construct the layout. Will have a think and see if I can reduce some of that.

Phoenix LiveView seems super neat. I remember watching the original presentation last year(?) and being really impressed, looks like it's come along even further since then. Phoenix itself and Elixir are really interesting too.

Have you considered/used React or Vue before? (of the two React is definitely much more FP-inspired). Mentioning these because it would be possible to build the entire interface with them (or just isolated parts), broken up in to components with co-located CSS, and potentially prerendered server-side for performance. Breaking things up in to components also allows you to hide awkward HTML away. Of course, JS isn't as nice of a language as Elixir/Rust/Ocaml are.

In theory at least, BEM should solve the problem of tying together components on the backend with the frontend CSS - e.g. for cards, .card is the component, .card__body etc are elements within the component and .card--white etc are modifiers on the component. However this is slightly complicated by the fact I've sometimes stuck other classes on BEM components e.g. a div with both .card and .vn-card, and the existence of helpers like mb-4 and d-flex.

Meaningful CSS looks interesting. Would definitely result in nicer markup. It's a very different approach from the current industry practices where HTML follows the CSS, reminds me a lot of things like CSS Zen Garden.

And nope, I completely understand that you want to get it right :) There's no rush, I won't be going anywhere.

I suppose for the next design things I'll be working on, might be better to mostly stick to mockups for now? Until we figure out how we're structuring the HTML/CSS :P. I'll try and come up with some ideas for that.

Some of the solutions might be dependent on how we construct the front-end - e.g. aphrodite linked above wouldn't make much sense unless the front end was rendered through JS, but there should be analogous ways of doing things.
#107 by yorhel
2019-05-05 at 08:44
Does it need to look more sharp and flame-y do you think?
It looks fine to me.

Have you considered/used React or Vue before?
Yeah... kind-of. Admittedly not very thouroughly. Client-side rendering is out of the question for a large part of the site, for the simple reason I want many parts of the site to be somewhat usable with JS disabled. I have a few doubts regarding server-side rendering with JS, partly because of the language, partly because of the ecosystem (avoiding the 1000+ unvetted/low-quality/possibly-insecure NPM dependencies can be a challenge, and I have trust issues), and partly because integrating JS into the rest of the backend is another challenge. Unless we go full-JS, but, uhm, you've seen how I write JS. :-)

Aphrodite looks good, and is indeed the kind of direction I've been thinking of. I believe the general idea can be ported to the backend without too much trouble. I've been looking for existing solutions in this space, but there's surprisingly few... more like nothing. With Phoenix I imagine the following could be possible:

defmodule VNDBWeb.CardStyle do
use VNDBWeb, :style

def style() do
"""
.card {
/* Mixin from a "global.css" or something */
@include generic-card-style;

& {
width: 50%;
}

h1 {
font-size: 20px;
}
}
"""
end
end

defmodule VNDBWeb.CardView do
use VNDBWeb, :view

def render(_conn, "card.html", assigns) do
~E"""
<article class="card">
<h1><%= assigns.title %></h1>
<section>
...
</section>
</article>
"""
end
end

# A "Controller" doesn't make much sense for a component, let's pretend this is a page instead
defmodule VNDBWeb.CardController do
def index(conn, _params) do
render(conn, "card.html", ..)
end
end

A build step could be used to fetch all the styles from the codebase and run it through SASS. Components can then be used in pages through the back-end. There's a lot of room for improvement in that example, but the basic idea ought to work and would help in keeping things organized, I think. There's also a few remaining challenges even if all of that does work, e.g. nesting components with meaningful css rules may get tricky, but that's a matter of experimentation and seeing what works.

I suppose for the next design things I'll be working on, might be better to mostly stick to mockups for now?
Continuing with the mockups is definitely a good idea. Some HTML+CSS here and there may also still be useful - it certainly won't hurt to have working code when migrating to a different structure. The final CSS rules aren't going to be radically different.
#108 by witchcapture
2019-07-06 at 01:57
That Phoenix idea looks like a pretty nice way of doing things :D

Not really sure what I should do next tbh - any ideas? Some options might be:

* Dark mode design variant
* Create a design system/component library to make everything more consistent - currently, e.g. the UI on VN page and the character details page has some significant differences and there's maybe not as much sharing of UI components as would be ideal.
* Try to fix the HTML/CSS soup (reduce the number of elements, classes, and class length, adopt some ideas from meaningful CSS - though it sounds like this might be better to wait until the new app structure is decided)
* Improve header design to decrease the amount of clicks needed, as discussed on earlier pages
#109 by yorhel
2019-07-06 at 09:03
Sorry for not giving any updates on this sooner, I've been working on too many projects at the same time.

I've played around with Phoenix and LiveView and, to be honest, I'm not super impressed. LiveView does not seem to be very composable (as in, can't just add some dynamic components to a page) and the amount of internal state that it exposes to the outside makes me a little uncomfortable from a security point of view. How the server-side state will scale to the VNDB visitor counts is also a bit of an unknown, but I suspect that wouldn't be a deal-breaker by itself.

So right now I'm thinking of compromising again: Stick with Perl/TUWF on the backend - it's still quite manageable, we can re-use a fair amount of code, I have a few small ideas for further improvements, and the above CSS idea will work just as well in Perl.

As for CSS organization: I've been looking into this a bit more, since meaningful CSS by itself doesn't really solve the problems with managing a large UI. One interesting thing I came across is Every Layout, which proposes new-ish layout techniques while trying to get rid of @media queries. I've not looked at this deeply enough to see if the claimed advantages really work out in practice, but I'm certainly intrigued. We'll probably still need BEM to sanely identify parts of the site, but cutting down on the element and modifier parts where they aren't strictly necessary may keep the HTML smaller and more manageable, I think.

(Actually, as I was typing this it occurred to me that, if the component CSS is going to be embedded in Perl anyway, it actually could integrate with the HTML DSL and we'd have proper server-side CSS modules. I'll go and experiment with this! ...but don't expect much from it, it's likely that this isn't any more usable than just sticking with BEM)

Finally, I think we can drop IE11 support and use CSS grid where that makes sense. IE11 is rapidly on the way out and may be dead enough by the time this project is fully finished.


As for what next, actually all those options are great. I wouldn't put a high priority on the dark mode until much later. Cleaning up the HTML/CSS combined with the reusable system/component library would be the most helpful at this point - I'd say the overal app structure should be determined more by how the UI and HTML/CSS is structured than the other way around, and whether the CSS is embedded inside Perl or in separate files is pretty much a mechanical transformation when the structures match. I'm also curious to hear your opinion on Every Layout.
#110 by witchcapture
2019-07-19 at 06:00
No worries, been really busy lately myself too :( Hopefully less busy soon.

I really like the ideas presented in Every Layout - we've been looking in to using them at work too and it seems promising. Some of the ideas presented seem to work much better with CSS variable support than without (e.g. sidebar), so dropping IE11 support would be great for that too.

Server side CSS modules could maybe cut down on the long class names at least, heh :P

All right, cool - will focus on cleanup and reusable components then!

Reply

You must be logged in to reply to this thread.