You should really make what Mastodon Variable Width | Userstyles.org do to default. I would also like to see a no-cap on how big a post can be. 500 chars are a bit low sometimes. It would be much better if you made them collapsible an show just the first 12-15 lines.
We’ve been through this a thousand times, and no, columns will be fixed width. The plan is to eventually support more columns than just 3. Also, the whole UX was designed around 500 characters, so I am not in favour of changing or removing that limit upstream.
I must have missed it. Was there a clear point of why it has to be fixed width? I get if you think it would complicate the code base e.t.c… but not if you personally think it is ugly. People are different and to me the default theme is very inefficient in using available screen estate. I like being able to read a full post without having to scroll. The Stylish solution above works pretty good though.
The thing is… right now people have started to number their posts (a lot) just to get around the limit. I think it would be a much saner solution to increase the character limit and make it collapsible. The timeline would look much nicer.
Also… are there a place where I could read about the full rationale behind the current UX? I am genuinely interested to get a fuller picture about it. If it was explained it would be easier to understand the current stance.
That would be awesome to read. I am still not convinced on the 500c. Twitter has the 140c limit in an effort to force people to be on point. A theory I don’t really agree on. People find workarounds and or don’t bother say anything at all. It hampers the convo a lot. Which is not really a good thing. 500c is a lot better but still carry some of the same problems. It doesn’t really improve the quality as it is not how people think. Anyway… that vision statement will be an interesting read.
Twitters 140 characters is not about forcing people to be on point necessarily. It’s a remnant from before we had smartphones (yes that was a thing), and it was developed to fit into an SMS which is 160c, but they gave 20c leaway for commands.
SMS was a big part of their marketing in the beginning.
That is not really the argument that is heard nowadays… Not to me anyway. I knew it had a relation to SMS but didn’t remember exactly how . Still… It doesn’t really change what I wanted to say. It doesn’t really improve conversation quality… it hampers it. Which I think is one of the reasons behind Twitters slow growth.
It sounds like what you want is a discussion board with live pull/push (like Discourse, which we’re using here), rather than Mastodon. The 500-char limit is IMO about twice as long as it needs to be, but it’s also one of Mastodon’s prime differentiators, so keeping it obviously makes sense.
Going longer than that risks defeating the entire purpose of having a service like Mastodon in the first place. Once you’re basically typing up entire posts, you might as well switch to a message board with proper markdown/bbcode/html for rich text formatting and proper notification support and proper digest functionality. Using Mastodon in that way is basically like deciding you want to paint the house with a hammer—it’s the wrong tool.
No, it would not in any way defeat its purpose. It would simply let people talk full sentences instead. Like you can on most other social network platforms. Something most people expect. Right now people have to do workarounds like chain posting, numbering e.t.c… Which is just cumbersome and clogs the timeline. Having a limit doesn’t really improve anything… (to what I have seen so far… I may be wrong)
500c is like having a car with square wheels… yes, it is different but it is not particularly good. It hampers the conversation. Mastodons main purpose is the fediverse. In other words giving back control to the user, decentralization and being open source. So I don’t really agree on your analogy although I see the point and appreciate your input.
If I may be so bold… There seem to be two points of discussion here, however inflexible/pointless to discuss:
I have no problem with the 500 char limit. I like it, in fact. If anyone needs more, they should start a blog. But I’ll refrain from saying why I like it (the argument for it) since Maloki has declared that point a terminated discussion.
But, as someone who is more informed about frontend design considerations than backend, the seeming suggestion that a 500 char limit defines a fixed layout is absurd. Just like it would be absurd to say a font-size needs fixed, if someone were to try and say that.
Here’s what I know… The web layout of Maston’s UI on my 13" MBP is bigger than the viewport of my screen when the window is maxed full-size. I don’t care what the reasons are, that should not be happening in a professional-grade web application. Your app should be adapting to my viewport. I should not have to buy a bigger screen to adapt to your app.
I would give a few ideas about how to fix it, but I’m sure they’ve been considered already and stubbornly decided against.
It’s kind of a small matter, because the break-out distance is about 50 pixels or so when max width, but it’s there, unnecessary, and would seem trivial to fix if the stance on fixed-width columns wasn’t so adamant.
As a result, I tend to favor using mobile apps, but, you know, details.
Mastodon default UI shows 4 columns right now, but it might be more (configurable) in the future, so the idea of horizontal scrolls and not being centered is baked in from the start.
It’s not that 500 chars defines a fixed layout, it’s that 350px is about perfect for displaying 500 characters of text given the current font size, in terms of how much your eyes need to move horizontally, and in terms of how much space each toot takes up vertically at most. Having a fixed width allows us to make some guarantees about how things look for everybody and design accordingly. When you resize the window down to the mobile layout breakpoint, you can get a glimpse of how it looks when the text is way wider than it needs to be, and perhaps you do not share my opinion but I think that looks really clumsy.
That’s exactly what I mean. You’re using character limit to determine column width based on font size (which I anticipated). I’m also well aware of ideal line lengths, etc, but they can be taken with a little salt, a weeeeee bit variation to get the right lovin’.
Your heart is in the right place, but the consideration is perhaps off. What looks the same for everybody is completely different from what works for everybody. You can’t make it look the same for everybody because the variances of different device builds is a moving target. Further, presentation is irrelevant against usability. Human-centered design 101.
This is troubling news too, because it suggests you’re designing the application based on desktop first instead of mobile first, when it should be the exact opposite, because that’s the way the world is now. More people use mobile devices to access the web. Right now the mobile apps for iOS are 5x more usable with their single-column designs than with the “broken” desktop layout. And you expect even more columns?
That is indeed a new design direction for a social platform, but I fear (without more knowledge of how/why) that it’s a bad decision for more adoption of Mastodon. At the very least, people will simply not use the desktop application. And you’ll be investing time/energy in building/maintaining a UI that people don’t like. Yes, it remains to be seen, but the idea of many columns scrolling horizontally does not sound user-friendly nor productive.
If that direction of many columns in the UI is based on the idea of managing multiple user accounts, then I’d say the expectation is contrary to what people really want, a way to autonomously delete obsolete user accounts so they can devote their focus to managing one main account. Why would I want more than 3 or 4 columns for one account?
As it is, I think 4 columns is too many; 3 would be ideal. E.g., putting the ‘home’ stream under the control buttons in column one, and making the toot editor a pop-over on the remaining 3 columns, just like this forum uses (though maybe not as wide). That would be nice, and make the editor more comfortable.
Getting back to the factors that influence the current 4 column layout, and your position of how it looks for people versus how it functions for people. Designing elements as fixed is no more consistent in approach than designing adaptive. You’re doing the same once and letting the devices of people interpret the code. The fact device A displays things a little different than device B is irrelevant if the app is functional on both devices.
So, instead of layout and elements with fixed attributes/units, try and use a mix of these ideas that work, if but rendered slightly differently per screen characteristics:
Adopt CSS Grid, with some Flexbox fallback for the laggard browsers (which are few at this point; maybe only the obscure open source options).
Use percentages on your columns.
Use rem units on your typeface.
Reduce the margins between your columns by half. (And maybe employ better use of background color to distinguish columns from gutters; the light on dark design is fine, but that doesn’t mean it has to be bi-tone and low contrast.)
Reduce the size of avatars (they are needlessly large in desktop view).
Allow text to wrap under avatars. The empty gap in a toot block under avatars is nearly a full 1/4 of the toot box window. A huge waste of column space. Hell, changing that alone would do wonders. (And consider giving users the preference to turn avatars off; using people handles only.)
On the idea of configurable column numbers… Maybe you should share what you have in mind there. I, personally, would refrain judgment that it’s a “bad” idea until I knew what the idea was, because maybe you have something revolutionary in mind that I can’t imagine. But I’m having a hard time imagining it, and, again, because it puts desktop thinking before mobile thinking. I’d hate to see busy developers go down a bad road. Even the social tech giants, with all their money and paid armies of designers/developers, make bad design decisions a lot of the time, having to change and revise when users let them know they fckd up.
I promise I won’t keep harping on about this. I’ve said what I think needs said. Let the big wheel turn and the pineapples roll.
Then a micro-blogging app is probably not what you need (hammer>nail). That said, a bunch of the other fediverse apps don’t bake in char limits, leaving it up to the instance admin to decide if they want to set one. Maybe what you’re looking for is something like Hubzilla, whose UX is designed around blog length posts? It federates with Matodon over both OStatus and ActivityPub.