When I create a new post, I have to publish and then edit it to get an option to add a title. The title box doesn’t appear on the initial posting page.
The title field should appear automatically after you type over 280 characters. The macOS app also has a separate option under View menu → Title to show the title. We’d like to add something similar everywhere, including on the web.
This is a troublesome user flow that doesn’t lean on any currently existing behaviour in terms of posting things online, that in turn causes confusion and a reduced user experience. Would you care to share some details on why it’s not always visible and marked as optional?
1 Like
In a nutshell, we think that always showing the title field makes it more difficult to start a blog post. Some people won’t know what the title should be, or they’ll overthink it, then maybe give up posting. So Micro.blog always starts with a simple text box, just start typing what you want to post, but still allows for a title if you want it, usually for longer posts.
I know this doesn’t match how everyone wants it to work. In my experience it’s still a good default for what we’re trying to do.
1 Like
Agree with this logic and I like they are sticking with it. Hence it is Micro.blog otherwise it would be just .blog 
Also, it’s not impossible to add a title as @Jeber realized. @Jezper
Maybe a good compromise might be making it an option in the three-dot menu (like categories, etc)?
1 Like
I can appreciate the sentiment of that, definitely, but I believe there’s a better UX solution to this than the current implementation. There are no established user patterns that enables UI elements by simply typing beyond an arbitrary number which makes discoverability of this “feature” very low. People are simply not used to that interface behavior.
You have the three dots, may I suggest like @rossk to add show title there, and that the setting of whatever you choose from this menu is saved as “your default”. It can all be hidden as default.
The posting UI should offer the flexibility of the features of your platform. I will have title and categories for all my posts, and the current feature set will be constant friction.
2 Likes
I hope this change doesn’t happen. The existing set-up is fine and unnecessary changes are just bloat. We already have plenty of bloated options available elsewhere.
My suggested change does not add bloat, it adds usability.
2 Likes
Another switch placed behind the three dots — which isn’t exactly a boon to discovery — is more weight with minimal improvement to use. I see that as bloat.
I have no idea if other people would be bothered by this — although any addition to the platform inevitably brings further potential for bugs and takes up more dev time and so on — and I am not going to claim anything about people’s expectations. Aside from anything else, I have spent exactly 0 seconds asking anybody about it or performing any sort of analysis to somehow work it out.
@Jezper, you say “People are simply not used to that interface behavior.” and I’m curious as to whether this is a problem based on any research you have done, or in your field of expertise, or if you have asked people about it? I’m asking because I think it would be great if there was a way to know about this.
For remembering the setting, the reason I’ve resisted this is because of this scenario: imagine someone usually posts short microblog posts without a title. Every once in a while, they want to put a title on their post, so they show the title field. Now it remembers it and the title field is always there even though they very rarely need. Of course, they could hide it again manually, but I don’t think someone is likely to do that.
Another solution would be to just have an explicit preference somewhere for people who really want the title field always visible. We try to avoid preferences but I think I’d be okay with that.
1 Like
Thanks for engaging! A three dot menu is much more of an established UI pattern for collecting more or other settings and features. Much more so than “keep typing to unlock additional functionality”.
Every line of code always adds the increased risk of bugs and dev time. It’s why startups usually outperforms enterprises on functional deliveries on any given time frame.
But back to the usability part. I do have experience in this. I’m a seasoned UX designer turned product manager and while I haven’t made any research for this specific topic, I have made a tremendous amount of user research and interviews on usability, user flows, interactions, ui patterns and design. And I’ve worked with yacht controls, car infotainment systems, a dozen apps and web services for both B2B and B2C for over 10 years now and over the years you pick up a good sense of general usability and a backpack full och general best pratices.
In general terms: A user that is able to do what they intended to do will get value out of that interaction. And for a user to be able to do what they intend, it is of highest importance to make sure they can figure out how to do it. And the shortest path to ease-of-use is to lean on what a user might already know. That way you don’t need to teach them as much.
A good framework of this comes from UX guru Jared Spool, about knowledge, I’ll paraphrase a little from memory:
From a user vs service interaction perspective, there are four levels of knowledge:
No knowledge (you know nothing about this system or any other system)
Current knowledge (you know nothing about this system but you’re familiar with other systems)
Target knowledge (you know enough about this system to get the ideal value out of it)
Full knowledge (you know every little thing about this system)
From a business perspective, you’re aiming for Target knowledge. Anything above that is good business and potentially loyal users the closer to full knowledge you get.
The easiest way to get to target knowledge is to lean on current knowledge. Design things in a way they intuitively understand, that functions like other things they are familiar with. If they try something that seems like it should work, they will respond very positively to your product if that works. That way you don’t need to teach them more new things than necessary.
A quick example is “pull to refresh”. It’s a feature that has gained enough traction that a user might try it in a list view if your service is expected to update its content. So if you design a product with a flow of articles or posts, the easiest way to get the user closer to target knowledge is to lean on current knowledge and implement functionality they know before you even told them. You could try implementing “shake to refresh” and you might be able to teach the user that is how it works, but it will both add friction (you need them to learn something new) and potentially have a customer journey dip (they feel awkward learning a new behavior when they expect something else). That’s a tough path to loyalty and increased user base.
And the key thing here: getting a user to target knowledge, that’s where they know enough about your product to understand what makes it unique and makes them use your product instead of something else. Ideally your product can lean so much on current knowledge that that is your target knowledge. That would mean they intuitively understand your product from the start and get the perfect value out of it.
Long post, sorry. But I love discussing these things!
4 Likes
Don’t apologise! That’s a fantastic post, and your generosity is appreciated. Aside from anything else I’m in the process of deciding to what extent I want to work on service products and in what way, so this was a great crash-course for better understanding product management.
1 Like
I’ve always wanted a way to display the title edit box either through a toggle, always on, that’s in the settings or in the post menu or similar because I’ve found having no title edit field means I have to put XXX into the post, copy that, and paste it again until I get the title, which seemed odd to me since I always want titles on my posts, even short posts.
1 Like
This workaround is not for everyone. But, if your browser has support for custom CSS, like Arc’s Boosts or User Style Sheet in Safari, the following snippet will make the title field always show.
#posting_title_container {
display: block !important;
}
I tried this and it works! Can something similar be done to show the categories and cross-posting options?
Extending on what @sod wrote, here’s a combined CSS.
#posting_title_container, #posting_categories, #posting_services {
display: block !important;
}
2 Likes
Woo hoo! Thanks, that worked.
cc: @kimberlyhirsh
An interesting but odd behavior - this works as intended in Safari but not if you add the site to the Dock (Sonoma feature) 
Yup, I removed my previous web view app and re-added it after updating the CSS. cc: @sod
The Safari browser settings (like user style sheets) have nothing to do with the settings of individual web apps, unfortunately. From Use Safari web apps on Mac:
A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. In this way, it keeps your browsing separate, similar to using a Safari profile. What you do in a web app stays in the web app.
I love that last sentence in the quote, by the way. 