I think discoverability is a good motivation, especially for an app that has network, community, and the shared discussion as its pillars. Given the size of your audience at the time, however, I don't think it should be the main problem to solve. Go deep first: make sure all of the existing systems work well, and upgrade what is before going for what could be. Midnight is in alpha: people will forgive even drastic changes to the app, as long as you treat user data (Entries, References, profile info etc.) with respect. One idea in particular I've been following for a while: that most UI design on the Web is list design. The bottom line is: if you nail the list, the rest of it comes along easier and quicker because you've figured out the core of your design. It's even more appropriate in your case: you have a list of Entries, where each Entry is a "list" of contents. With a single-column design – any, not just yours – it's very much about expectation. You expect stuff to flow down around a single axis, and if something stands out, it must be important (like an error message), or it shouldn't attract that much attention (like a "Log out" prompt far into the corner). One thing that stands out to me is the fact that, without a scroll bar to the right (if the Entry is shorter than my screen height), the whole column shifts suddenly to the right. This is natural for such layout, but it's still a minor issue: people don't like it when things suddenly jump a few pixels away, especially if nothing changes from their perspective. My suggestion is to calculate scroll bar width if the scroll bar is present (i.e. if `offsetWidth` of `window` is greater than `clientWidth`), and add a special class to `<body>` if content height (plus whatever vertical padding and margins you may have set) is shorter than `window.clientHeight` (i.e. the viewport). That way, going between a long list of Entries on the main page and one particularly-short Entry won't shift its content visually. Naturally, don't forget to remove the special class if content height is greater than the viewport height. As a sidenote: consider replacing pixel-based width for content columns with `ch`-based. `ch` is the width of the font's `0` character ("advanced measure", I'm obligated to say, but for Web design concerns it's almost always its width). As Eric Meyer points out, it's not quite as precise as "the width of a character", but given that you're working with text, it's better than sizing with pixels. It's been suggested that the optimal length of a line (which, in our case, is also the width of the entire column) should be somewhere between 50 and 75 characters. Given Eric's observation that, on average, characters in fonts are ~25% wider than its corresponding `0`, and assuming we're aiming for the average of 60 characters per line, consider setting the width of your column to `45ch` and see where it leads you. Remember that it's all in service of readibility, so if it consistently feels off to you, tweak the values until reading is pleasant. I'd also like to leave this Nielsen Norman Group article here. It's a list of issues many applications have. No context for it, I just figured you might extract useful information for it.
I've paid close attention to the very accurate points you touched upon, and made a good deal of refactoring on the presentation side. > It's been suggested that the optimal length of a line (which, in our case, is also the width of the entire column) should be somewhere between 50 and 75 characters. Given Eric's observation that, on average, characters in fonts are ~25% wider than its corresponding `0`, and assuming we're aiming for the average of 60 characters per line, consider setting the width of your column to `45ch` and see where it leads you. Remember that it's all in service of readibility, so if it consistently feels off to you, tweak the values until reading is pleasant. This caught a lot my interest. I have two variations right now: https://midnight.pub/ (the main one) https://midnight-79pczempx.vercel.app/ (this one is 45ch) Would love to get your perspective on which one feels better to read in. I also wonder if you have some ideas on places I could potentially advertise to, in order to get onboard more people for the alpha and see at a little higher scale what usage could be like. You have been the greatest help so far on the project, much thanks for your time and expertise!
I think it works well with the `45ch` limit. I think what you have now in your regular app works better with articles and such, like Medium or Ghost, where texts could be long. Of course, I'm not the high authority on these matters; if people tell you that the column is too narrow, do take their voices into consideration: that's how you become better as a developer and a designer. > I also wonder if you have some ideas on places I could potentially advertise to I'm not much for a marketer. I just make things. If I made an app that I wanted to present to the world, I'd look for places where there's demand for what I made. If I make an app that's good for writing long texts, I'd show it to writers, journalists, bloggers, script writers... – anyone who could use such a thing. Seems like a reasonable thing to me: you want those to see it who could engage with it meaningfully. So my guess is: figure out what kind of an audience you want, and what kind of an audience Midnight's best suited for, and show up there with the app in hand. For scale, you could advertise to Product Hunt and post it as an alternative to other products.