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.