> I went ahead and updated the username length to 20 character maximum. Let me know if you think I should increase that. So, apparently, emails allow up to 64 characters for the username (the part before the @-sign). Twitter now allows 50 characters, with its previous 15-character limit based in its previous nature of being SMS-driven. I see no reason not to up the limit to somewhere up in that range. There's also the concern of the minimum username length. Is there any particular reason to set it as high as 3 characters? > I would love to get your feedback on other parts as well if you are interested. :) I was going to write out a short list initially, but it didn't seem necessary. Now that you ask... 1. There's no immediately-obvious way to sign up, as there is with signing in. Whether registering an account right now is easy is irrelevant: it's best to provide the user with the initial opportunity to do so. User comes in, sees that registering is possible, tries it out – maybe they find the message of "Midnight is in alpha, key is required", but at least they know where to go. 1.1. Consider using two different terms for registration and logging in. There's this confusing-ass trend of "sign in" + "sign up" where you have exert effort to focus in order to distinguish which is which because the two look similar enough for your brain to mix them up unless they're in the focal point of your vision. Consider distinct wording. Apparently "log in" + "register" is not cool anymore, even though it works very well. How about "sign in" + "make an account"? "Log in" + "Make a blog"? 2. The main screen is in two-column layout, while Entries are single-column. Consider making both single-column, to avoid post-switch confusion: it's temporary but unpleasant. 3. The "midnight moon" symbol in the corner of the page is excellent. It even scales with the zoom level, which is a very nice detail. Keep it, whatever you do, unless you come up with something that's decidedly better. 4. Make sure to distinguish Entry body from whatever reference it makes. At the very least, mention that these are the references made by the Entry: this gives immediate clarity at very little cost otherwise. 4.1. Also make sure that the "next"/"previous" links are meaningful. You can't immediately tell what the "Previous" link is to when it's below References: is it the previous Entry? is it the previous page of References? is it previous on some form of bookmark list? Minimalism is good and all, but when it obscures meaning, you may want to consider employing a different practice. You want knobs and bells that most users can easily and immediately tell apart and use intentionally. 5. I would advise separating body text from Entry titling. Let users make in-Entry Markdown titles that don't affect the Entry's overall title. While I can see the appeal of using top-level heading from the body, there isn't a structure in the Entry making (as far as I can tell) that makes good use of it. It's a feature that dangles in the air, and it's confusing by default: I'd expect to have a separate input field where I'd name the Entry I'm making, and I'd also expect to be able to use semantic leveling in the body of my Entry starting from the top level (single #), rather than from level 2 (##). 6. Consider giving multiple inputs a meaningful amount of spacing, perhaps like this, with `0.5em`. 7. The HTML structure could use a little polishing. You're using `<section>` elements for simple pocketing of content, which is not its purpose. `<section>` is meant to be the foundation of semanic HTML structuring; while there are no tools to use it yet, it is its stated purpose, along with many other HTML5 elements, like `<main>` or `<header>`. Don't use it where you simply want to group two elements together, like in the sign-up page's `<form>`: use `<div>` for that. 7.1. The way I understand it, the best way to use `<section>`s is by making it a wrapper for related contextual elements. You can use `<article>` to hold the body of the Entry, and use `<section>`s for each heading-separated part of the text: `<section>` → `<hN>` + `<p>` + `<img>` + `<blockquote>` + whatever other content element there is. 7.2. Avoid empty elements for spacing. Add margins and padding to `:first-child`, or `:first-of-type`, or `:last-of-type` pseudo-elements, or to the wrapper elements themselves, or to the next element after the one you want to add space after (e.g. `section + section`). 8. Consider using `<time>` element for dates. 9. Consider adding some form of subtle delineation between Entries of a list. Fading out is good, but there's order in knowing where exactly it ends when you're faced with two Entries one after another.
This. Is. Amazing! I cannot thank you enough for taking the time to write such an in-depth and to-the-point feedback. I'm lucky to have found you, and will make sure to read through each point. One that I'd love to hear more about is the double-column layout. Actually, I changed it yesterday. Here is a version that had only a single column: https://midnight-39fob05tw.vercel.app/ Do you think this one is better? My main motivation was on bigger screen, to show more content at once, but I'm not sure it adds much value.
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.