Blakeyrat pointing out NodeBB problems

[RaceProUK]

@boomzilla said:

But when you refuse to work around a third party bug? That you know about?

That's assuming it's even possible to do so. In this case, it isn't, not in any practical sense; Bootstrap 3 uses pixel sizes because it supports IE8, and it's pixel sizes that triggers the bug. The solution is to use em sizes instead, and that's what Bootstrap 4 uses. However, Bootstrap 4 is still a long way from production-ready; it's not even complete yet.
The other solution is to replace Bootstrap 3 with a framework that uses ems, but then you'll have to rewrite pretty much the entire front end HTML, and a considerable amount of CSS and JS as well. Or you could implement your own alternative to Bootstrap, but again you'd face the same issues.

When you're working on a project the size of NodeBB, what would you prefer they focus on? A framework for building the website, or the website itself? Frameworks exist to make development easier, by allowing us to focus on what matters, and offloading the drudge-work to something designed for drudge-work; if you have to do the drudge-work yourself, then that's less time and effort you can spend on the actual product.

@Maciejasjmj said:

Which is a wrong thing to do since it's completely unrelated to whether you're on a desktop or on a mobile.

Yes it is. But when it's impossible to do it the right way, there's no other choice.

@Maciejasjmj said:

Do all developers have social anxiety that prevents them from just asking what the user wants, and they prefer to use mental gymnastics to try and deduce what they most likely kinda would prefer?

Most users don't want to have to make the choice; all they want to see is the dancing kittens, and anything in their way just pisses them off. Also, what happens when they first visit? Do you always serve the desktop site, meaning mobile users get buttons 2 pixels high? Or do you always serve the mobile site, meaning desktop users get a touch-optimised interface for their keyboard and mouse? Or do you try to make the best guess you can, and serve up a device-appropriate design?

The situation we have right now is shit, I agree. But it's the best we have, so we have to make do as best we can.

[Maciejasjmj]

@Onyx said:

The problem is the amount of users that don't know what they want.

Those get the default, which is either forced desktop/mobile view, viewport sniffing, UA sniffing, whatever... It's not perfect, but it's fine to guess. But not giving the user an option to change the default is bad, and you should feel bad, despite what @boomzilla says.

[Maciejasjmj]

@RaceProUK said:

Or do you try to make the best guess you can, and serve up a device-appropriate design?

This - except you allow the user to correct the guess. A simple toaster when you first visit the site saying "hey, that's our desktop/mobile version, if you'd rather have the other one click here, and you can change it in your settings" is literally everything you need. It hurts no one, since most users can just safely ignore the message and get the version they have now, and that 10 or 1 or 0.1 percent who had the software guess wrong can still correct it.

[Luhmann]

@Onyx
I'm all for giving users an option ... but the default option should still be the website trying to figure out what to offer

[boomzilla]

@RaceProUK said:

When you're working on a project the size of NodeBB, what would you prefer they focus on?

Literally anything that Blakely isn't complaining about at this point.

But if you can't work around a bug, that doesn't mean you don't have a bug too. That you give it a low priority doesn't make it not a bug.

[RaceProUK]

@Maciejasjmj Now that is a solution. I do have two small refinements though:

1. Once dismissed (or it disappears by itself), it doesn't show again
2. The setting is stored using browser local storage, as it is device specific.

@boomzilla said:

But if you can't work around a bug, that doesn't mean you don't have a bug too.

I never claimed otherwise. All I've ever claimed is that the bug is in WebKit; all the Bootstrap and NodeBB stuff is side-effects.

[Luhmann]

@Maciejasjmj said:

But not giving the user an option to change the default is bad

So the major issue is that there is no way to switch between the mobile/desktop layout?

And the mobile layout not being as "pretty".

[boomzilla]

@RaceProUK said:

I never claimed otherwise

Duuuuuuuuuude. You said there was one bug and it in was WebKit.

[RaceProUK]

@boomzilla And?

[boomzilla]

@RaceProUK STFU.

I guess?

[Maciejasjmj]

@RaceProUK said:

Once dismissed (or it disappears by itself), it doesn't show again

Hence the "change it in settings later" part. You can bury that option wherever you want (although I personally would like a quick switch since there are devices for which both modes work under different circumstances), it just should be there.

And yeah, device-specific, that doesn't even need mentioning.

[Onyx]

@Maciejasjmj I suggested the exact same thing above and it got exactly zero feedback. I don't know what to take away from that, honestly.

[Maciejasjmj]

@Luhmann said:

And the mobile layout not being as "pretty".

The lack of preview and a modal full-screen editor makes it downright dysfunctional unless you have to use it.

It should really be a per-browser setting (and no, don't try to make it "responsive" - my desktop doesn't become a phone once I resize a window), and most importantly the user has the final say on which version is correct. No matter how much guesswork you do, they're the one who actually do know what's right for them.

[RaceProUK]

@boomzilla A bug doesn't have to be in a product to manifest in said product; the bug is perfectly capable of being in a dependency.

This is why I prefer to distinguish between 'bug' and 'issue': the issue of NodeBB's bad layout choice in WebKit browsers when browser zoom is on is caused by a bug in WebKit.

@Onyx said:

I don't know what to take away from that, honestly.

That you got lost in the noise of Blakey throwing a temper tantrum that a 3yo would find embarrassing.

[Maciejasjmj]

@Onyx said:

I suggested the exact same thing above and it got exactly zero feedback

Reading, barrier, etc. Could've missed it, or just read it too late to bother bringing it back to reply.

[Luhmann]

@Maciejasjmj said:

makes it downright dysfunctional

Discourse didn't have that either on mobile.

[Maciejasjmj]

@Luhmann and it sucked, your point?

Although at least it let you do selective quoting with composer open. Well, unless you were one of the lucky few for whom selective quoting didn't work at all.

[boomzilla]

@Maciejasjmj So far, selective quoting had been more consistent here. It was really hit or miss on discourse. A lot of times the reply pop-up just...wouldn't.

I haven't selected text and clicked the reply button and not bad out get quoted on here yet.

[izzion]

@Maciejasjmj said:

Or even better, ASK THE FUCKING USEEEEEEEEEEEER! Do all developers have social anxiety that prevents them from just asking what the user wants, and they prefer to use mental gymnastics to try and deduce what they most likely kinda would prefer?

Users don't know what they want.

To paraphrase the old saw, if Henry Ford had asked users what they wanted, they would have said a faster horse that ate less straw.

I won't disagree that the narrow width "mobile" view on desktop is a poor interface to interact with. But asking users is never the solution; the typical user either won't know what they want or won't want to be bothered with having to keep track of how to ask for one mode or the other.

[Luhmann]

@Maciejasjmj said:

your point?

You are bitching about something that doesn't work nice on competing platforms. There doesn't seem to be a perfect solution.

I have the impression the real problem in NodeBB is that the composer is bloated. There is a lot of white space all around. This is independent of the mobile/desktop discussion however since it applies to both layouts. It's just a bigger issue on the mobile one.

[blakeyrat]

@darkmatter said:

One thing being lost here is that part of the point of the responsive design is about having the content fit the viewport for all resolutions independent of device. And it does.

I have no objection to that.

The problem is forcing me to use a particular view I do not want and one that is not even remotely close to optimal for my device with no way to override that choice.

[blakeyrat]

@Maciejasjmj said:

BUT EVEN WHEN YOU DON'T MODIFY THE ZOOM THE SITE SWITCHES TO MOBILE VIEW WHEN YOU SNAP IT TO THE SIDE AND THAT'S SHITTY AND PROBABLY WRONG.

How... many... times... do you people have to have it spelled out?

RaceProUck is never going to understand this. Her brain is too small to contain the information. Give up.

[blakeyrat]

@Onyx said:

The problem is we have to design shit for the lowest common denominator.

I'm sorry, are you on the NodeJS team? Who is this suddenly-appearing "we"?

[Onyx]

@blakeyrat said:

Who is this suddenly-appearing "we"?

People who build web interfaces. Many of us use the same framework NodeBB does, for most likely the same reasons they do too.

[blakeyrat]

@Onyx said:

So they pick the desktop layout, it's completely unsuitable for their device and then they don't know how to switch it back. Or they get frustrated, forget / don't even consider that that's an option after the initial question and leave. Great, there goes a potential customer.

You're also just as likely to use a customer because they're sitting at a big-ass desktop computer and they get this weird full-screen text editing window, with no way to do multiple quotes, no preview pane (and of course it's not WYSIWYG, why would that exist here in 2016?), and they're going to say your website works like ASS. Which is true.

Sure, they could resize their window to make it go away. (Assuming they aren't using a 150%+ zoom, at which point they might not even have enough pixels in existence to make this go away), but what on the screen tells them that? Nothing. They just think the full-screen shitty editor is how the site works. Like I did before someone showed me a screenshot of what the desktop view was supposed to look like, and I have to use trial-and-error to figure out how to get into that view.

A SIMPLE LINK AT THE TOP OF THE PAGE READING, "You are currently in mobile view. Switch to desktop view?" would have alleviated this situation. Sure it's not the perfect solution; but at least that user isn't going to walk away thinking your product is useless shit.

And again: there are sites out there, like Fark.com, that do (AFAICT) a perfect job of detecting mobile devices with small screens. So don't tell me it's not possible, because I've seen it.

[blakeyrat]

@RaceProUK said:

Bootstrap 3 uses pixel sizes because it supports IE8, and it's pixel sizes that triggers the bug.

NOT THAT I'M SAYING PIXEL SIZE MATTERS BECAUSE THE NUMBER OF PIXELS HAS NOTHING TO DO WITH THIS BUG WE'RE DISCUSSING but

Your dumb explanation here kind of falls flat when we all know IE8 supports fucking ems in CSS. We're not so dumb that we'll fall for this. I've written a dozen sites that supported IE8 fine at a previous job and they used ems in the CSS.

The problem isn't IE8 support, although I'm sure that makes a great scapegoat. The problem is shitty dumb developers who are pushing broken frameworks.

[blakeyrat]

@RaceProUK said:

When you're working on a project the size of NodeBB, what would you prefer they focus on? A framework for building the website, or the website itself?

The whole thing is their product. It doesn't matter where the bug is. It's still a bug, and they're still shipping a bug, and they still need to fix it.

[blakeyrat]

@RaceProUK said:

Yes it is. But when it's impossible to do it the right way, there's no other choice.

1. I know a website that does it the right way, so this isn't fucking true.

2. Even IF you make the choice automatically in a buggy shitty awful way, fine, whatever. The problem is users can't override that automatic choice.

[Onyx]

@blakeyrat said:

A SIMPLE LINK AT THE TOP OF THE PAGE READING, "You are currently in mobile view. Switch to desktop view?" would have alleviated this situation.

I already suggested something similar. Actually, I tried to accommodate the user even more by providing a simple way for them to test things, back out from it if they don't like it, and I could save it into a cookie behind the scenes. Mind commenting on that before accusing me of not thinking of it first? Thanks.

@blakeyrat said:

The whole thing is their product. It doesn't matter where the bug is. It's still a bug, and they're still shipping a bug, and they still need to fix it.

Remember when you complained about not being able to work with tracking pixels because browsers are being assholes? Yeah, that's the same problem we have with device detection: browsers are assholes. Hell, W3C, as stupid as they are, actually added stuff to the standard that would help. But browsers are assholes, so we don't get to use it.

Either calm down or find a new trolling point, this one is getting tiring.

[blakeyrat]

@RaceProUK said:

The situation we have right now is shit, I agree.

THEN STOP DEFENDING THE BUGGY SOFTWARE AS IF BUGGY SOFTWARE IS OK!

Jesus.

It's fucking hard enough to find a SINGLE piece of software in 2016 that isn't a ball of stupid bugs, and then to make things worse dumbshits like you come into forums like this one and white-knight for the bugs! Why!? Do you benefit somehow from software being buggy? Or are you just a horrible person?

"Waaah! The bug's in the framework, not in our product!" is not a fucking excuse. When you ship the product, YOU SHIP THE PRODUCT. You're responsible for it. When you chose that framework, YOU ALSO CHOSE ITS BUGS. And now you have to fix them. Are there a lot? Are they difficult to fix? Well, then you should have been more selective when choosing your framework I guess.

[blakeyrat]

@RaceProUK said:

All I've ever claimed is that the bug is in WebKit;

There is a bug in WebKit, ENTIRELY UNRELATED TO THE ONE I'M TALKING ABOUT.

Wait why am I repeating this. You're too stupid to absorb the information. I can practically see the words bounding off your thick-ass skull.

[blakeyrat]

@Luhmann said:

And the mobile layout not being as "pretty".

I don't give a fuck that its pretty, I care that it's missing like 75% of the features of the forum. And doesn't have working error reporting when something fails.

[blakeyrat]

@RaceProUK said:

@boomzilla A bug doesn't have to be in a product to manifest in said product; the bug is perfectly capable of being in a dependency.

THAT IS NOT DIFFERENT THAN BEING IN THE PRODUCT!

Goddamned you're stupid.

[blakeyrat]

@Onyx said:

Many of us use the same framework NodeBB does, for most likely the same reasons they do too.

You don't give a shit that your products are buggy and broken?

Well. Congratulations I guess? You saved a few hours of labor, which you're going to need to spend ten times over later on when you finally figure out how dumb this framework's behavior is.

[Onyx]

@blakeyrat said:

You don't give a shit that your products are buggy and broken?

Suggest a better one. Or write a better one.

YOU WROTE SHIT FOR WEB! YOU KNOW HOW BROKEN THIS SHIT IS! THIS IS THE BEST WE CAN CURRENTLY FUCKING DO!

[blakeyrat]

@Onyx said:

I already suggested something similar.

Ok? Good job?

It's still a workaround, but it's a million times better than just leaving the site buggy forever.

@Onyx said:

Mind commenting on that before accusing me of not thinking of it first?

Commenting on what? And... what evidence do you have that you thought of it first? (EDIT: and when did I accuse you of anything at all? Much less "not thinking of this first". I scrolled up, there ain't no accusations there.)

Look, there's a million valid reasons to be pissed off at Blakeyrat, but I honestly have no idea what I'm not doing here that you think I should be doing. I didn't realize I was required to comment on every post. (I'm also 95% sure you did not think of that first, since I've seen in in websites going back a decade, but hey, whatever.)

I'm sorry you're offended, I guess? But I have absolutely no idea what you think I did to offend you.

@Onyx said:

Remember when you complained about not being able to work with tracking pixels because browsers are being assholes? Yeah, that's the same problem we have with device detection: browsers are assholes. Hell, W3C, as stupid as they are, actually added stuff to the standard that would help. But browsers are assholes, so we don't get to use it.

And yet, Fark.com does it perfectly. So don't tell me it can't be done. Because I've seen it done.

@Onyx said:

Either calm down or find a new trolling point, this one is getting tiring.

What trolling point? I'm just saying you can't excuse a bug in the product by saying, "oh the bug's actually in a dependency the product ships with." There's no difference between those two scenarios. Both involve you delivering the buggy product to the user.

RaceProUck keeps trying to white-knight for this bug by saying it's in Bootstrap and not NodeBB, I'm just trying (futile) to cram the point into her thick-ass skull that that doesn't matter.

That's not trolling. That's me trying to convey information to RaceProUck. And if I'm repeating it a lot, it's only because she's so fucking rock-stupid.

[blakeyrat]

@Onyx said:

Suggest a better one. Or write a better one.

YOU WROTE SHIT FOR WEB! YOU KNOW HOW BROKEN THIS SHIT IS! THIS IS THE BEST WE CAN CURRENTLY FUCKING DO!

Fark.com does it correctly, to repeat this point for seemingly the 57th time.

Find out what they're doing, and do that.

[blakeyrat]

New issue:

When you're watching a thread, the related notifications either:

1. Mark themselves as read, despite me not checking them in any way
2. If they didn't mark themselves as read they go to the wrong post. Not in the normal way that all notifications go to the wrong post, but if it says 5 people replied to the topic, it seems to go to the bottom-most post, and not the last unread post as you'd expect.

[Groaner]

@RaceProUK said:

By that logic, we'd be calling cars 'clouds of carbon dioxide and water vapour'

And nitrogen oxides, and traces of alkanes and aldehydes!

[ObjectMike]

@Maciejasjmj said:

@mikehurley said:

Have a site's main URL go to the desktop version. Have a m.foo.bar version for mobile. If you're on your mobile device just go to the m. URL. Don't try to magic the user to the right URL.

Bzzt. All internal links now throw you out of mobile mode and into desktop mode, or vice versa.

Why wouldn't the desktop URL send back desktop links and the mobile URL send back mobile links? I don't understand why it'd necessarily bounce you into the wrong mode, unless it was made wrong.

[RaceProUK]

@blakeyrat said:

RaceProUck keeps trying to white-knight for this bug by saying it's in Bootstrap and not NodeBB

WebKit, dear; please try to keep up

[blakeyrat]

@RaceProUK said:

WebKit, dear; please try to keep up

"It's not that one scapegoat, it's that other scapegoat! But either way the product's perfect and has no flaws or bugs."

[RaceProUK]

@blakeyrat said:

But either way the product's perfect and has no flaws or bugs.

Really? Well, I guess there's nothing to worry about then :)

[ObjectMike]

@RaceProUK said:

@blakeyrat Well, if you want to keep throwing a tantrum that even a three-year-old would baulk at, then there really is no helping you

I think in this case you're missing his point. He's claiming that using pixel sizes is defective by design. Pointing out that pixels are miscalculated in WebKit browsers is irrelevant to his point. Even if WebKit was working correctly in this regard, like FF and Edge, they would still be using a defective design in his view. I mostly agree, too.

[RaceProUK]

@mikehurley said:

He's claiming that using pixel sizes is defective by design.

Well, yeah; that's why Bootstrap 4 is chucking all the pixel sizes away and switching entirely to ems. The only reason pixels remained was IE8 compatibility. But Bootstrap 4 is under active development and a long way from production-ready, so in the interim, you have to deal with the fact it's done in pixels.

[ObjectMike]

@RaceProUK said:

@mikehurley said:

He's claiming that using pixel sizes is defective by design.

Well, yeah; that's why Bootstrap 4 is chucking all the pixel sizes away and switching entirely to ems. The only reason pixels remained was IE8 compatibility. But Bootstrap 4 is under active development and a long way from production-ready, so in the interim, you have to deal with the fact it's done in pixels.

How is that going to help? Isn't that still going to use display size to determine which view to give (which is what I meant and I think @blakeyrat meant when saying pixels)? So on a small window (say non-maximized), on my desktop OS, I'll get the mobile view instead of scrollbars to see the rest of the desktop content? It may fix it so the intended design works properly in WebKit and others, but the design is still defective.

[ChaosTheEternal]

@RaceProUK said:

The only reason pixels remained was IE8 compatibility.

Which, as Blakey pointed out, is wrong. Microsoft states that Internet Explorer has supported ems since IE3.

[RaceProUK]

@mikehurley said:

How is that going to help? Isn't that still going to use display size to determine which view to give

Yes, but it'll no longer use pixels to work it out, as everything will be relative to the base font size.

@ChaosTheEternal said:

Which, as Blakey pointed out, is wrong. Microsoft states that Internet Explorer has supported ems since IE3.

Then take it up with Bootstrap, where they say this:

Dropped IE8 support and moved to rem and em units. Dropping support for IE8 means we can take advantage of the best parts of CSS without being held back with CSS hacks or fallbacks. Pixels have been swapped for rems and ems where appropriate to make responsive typography and component sizing even easier. If you need IE8 support, keep using Bootstrap 3.

[Onyx]

@blakeyrat said:

Find out what they're doing, and do that.

Ok.

User-Agent sniffing. Hey, we already concluded that's a great idea, didn't we?

Oh, look, bug report: https://m.fark.com/

Open this on your desktop. Oh, you got the mobile site? Whoops. Sorry, I guess I shouldn't send links from mobile (yes, that's actually fixable with their system, but it's worth pointing out).

I don't have a range of devices at hand, but are you confident that will always do the right thing? I'm not. Also, they are effectively maintaining two versions of the site.

I did manage to find the link back to full version, so full marks there, I'm all for it on any site. But there, I broke it just by sending a link from one device to the other. I'm not lambasting them, I know it's a hard problem to solve, but is it perfect? No.

Oh, also, making the site more narrow results in a horizontal scrollbar, hiding the content, which is easily fixable by using something like Bootstrap (well, you can write it yourself too, but fuck that jazz, I already had enough with stupid positioning hacks) with right column setup. Does NodeBB do it properly? No, and I'm not defending NodeBB in any way when it comes to that. But it could do it by using the responsive classes better. Fark has no concept of it whatsoever.

[JazzyJosh]

@RaceProUK said:

Bootstrap 3 uses pixel sizes because it supports IE8, and it's pixel sizes that triggers the bug. The solution is to use em sizes instead, and that's what Bootstrap 4 uses.

Because it's really fucking hard to serve up different css based on the user-agent