I'm A Grumpy Cat: An open letter to Alex
-
Bonus granted for a flying tank.
-
Hey, I wasn't gonna do this, but I'll do it anyway. I've got nothing better to do, after all.
I am ready to concede that Discourse may be a poor fit for you personally, it would make me sad if you gave up on it
It's not just a poor fit for Lorne. It appears to be a poor fit for a significant percentage of the population here. Moreover, it is, I would argue, a poor fit for its intended purpose.I may sound like a prick to you with the whole scrollbar thing, but I am honestly trying to figure out what particular use cases we are missing out on and improve on them. Chucking all the topics in pure html form in the stream is impractical, traditional paging is a problem we set out to solve with the product.
I think we all understand by now that Discourse was written with one major conceit - the idea that we should do away with "traditional" paging, and replace it with infinite scrolling. We also understand that you're not willing to spend any time making your *existing* paged interface work (hence your claims that it would require heyooooje amounts of work developing a "plugin"). I suspect this latter is because you, in your hear of hearts, know it would rapidly replace the infinite scrolling interface you've poured your heart and soul into, and pinned your hopes on.In some circumstances, infinite scrolling could be considered an optimal solution[1]; in cases where you don't really care where you are, or (given the current absence of a workable bookmarking solution) where you don't want to come back to a particular place. However, for forum usage, it's not optimal - indeed, it's far from it.
Now, the drive for infinite scrolling is largely driven by the rise of the tablet and mobile phone - browsing forums on these devices is a pain in the ass because you're usually trying to negotiate an interface intended for the relatively precise pointing of a mouse, but with great fat fleshy protruberances[2]. The solution to this issue is relatively simple, and involves simplifying the interface, removing information, removing controls. Not because that information and those controls aren't useful, but because, if they were large enough to be interacted with on a touch device, they would drown out the actual information you're trying to present. It's a one-way transform, and that's why applications like tapatalk can exist - it's possible to take the output of (for example) phpBB and make it tolerable on an iPhone, but it's not possible to go the other way, to take something intended for touch use and make it tolerable on the desktop[3].
That's part of the reason Discourse is such a bad fit here.
The next reason is because the world isn't perfect. We can't do what [1] implies - bandwidth, memory and processing power are finite. So rather than loading an entire thread, you must only load a portion of a thread at a time. And the way you go about this, in order to fake actual infinite scrolling, breaks the user's expectation of what the browser does, in many ways. You're breaking the way that the browser works, for one site. You're breaking the way the OS works, for one site.
Specifically - you're breaking the scrollbar, and Lorne's already partially explained why the OS implementation is far better than anything you could hope to implement - what (IIRC) he missed is that, of necessity, you're still leaving the scrollbar in place, and this causes confusion; you are providing the user with 2 potentially conflicting pieces of information, and the one that would usually be definitive is the one that's actually wrong. That's a massive WTF in itself[4]. Not to mention that your combo scroll place widget is, itself, displaying inaccurate information, does not have easily discernible function, and is hard to use with fingers - indeed, not only does it provide limited hitboxes, it's unintuitive and a whole heap worse to use with fingers than the expected scrolling mechanism on touch (see [2]). Congratulations. Not only have you broken scrolling on the desktop, but the real world breaks scrolling on touch and your workaround for both is pretty much unusable for any realistic use case.
You break the expected behaviour of search. No, your thread search isn't up to scratch, and you've broken the OS implementation. Woops. More confusion for the user, more "no this thing that you can use everywhere else can't be used on this site"
You've removed UI elements and information that would be useful, in order to fit your fat finger vision. As I've said, this is a one way transform, and trying to fix it with keyboard shortcuts doesn't work either - those shortcuts are arbitrary by definition, not discoverable, and, again, [2]
You're breaking the browser's history. Christ alone knows why you're doing that, but it's inadmissible.
And that's the problem. Infinite scrolling isn't at fault itself, it's largely the necessary workarounds for infinite scrolling's total impossibility that are at fault. That's what breaks everything. You've produced a piece of software that's technically pretty good, it's got a lot less security holes[5] and all-out bugs than most pre-release dynamic back ends have - but the fact it clashes with everything people expect, not only from sites in general, or even discussion sites in particular, but with the way their computar-machien works overall, makes it a pile of shit. Granted, it's a technically competent pile of shit, but that doesn't make people more willing to plunge their heads into it. Because it's still shit, and you don't plunge your head into shit.
There's a lot to hate about CS, phpBB[6], etc, they are all, in one way or another, flawed. But they are usable,
As for the shit flinging - well, that's your fucking problem. As you said yourself,
@sam said:It is just the way stuff goes sometimes
Simon
[edit - What the fuck? these were supposed to be footnotes, and at one point they worked. The fuck with Markdown.][1] Assuming infinite bandwidth, processing power and memory - load up 100% of a "thread" instantly, don't crash browser.
[2] It is, therefore, quite sad that the majority of the "fixes" you're trying to put in place for infinite scrolling on the desktop will be just as frustrating with finger prodding interfaces as the interface you're trying to replace.
[3] Ringing any "Windows 8" bells here?
[4] You could probably bring scrollbar sizing back relatively easily - at a topic level, store an average post height, and update this every time a post is added to the topic. Then add placeholder elements to the rendered topic for each "unloaded" post, with their size dynamically set to the average post height. This would fix the "relative position in the thread" issue, but wouldn't allow "scrubbing". I dont know about you, but when I'm navigating large documents, I often scrub the scrollbar and drop in when I see recognised "shapes" in the document - I follow the "form" of the content, as well as the content itself. So it may well not be anything close to a solution - it's still very WTF-worthy
[5] Which is not to say you're clean, but hey.
[6] Particularly phpBB. What's to love? It's written in PHP, and uses mySQL. It's a festering pool of vomit. But it works.
-
when I'm navigating large documents, I often scrub the scrollbar and drop in when I see recognised "shapes" in the document - I follow the "form" of the content, as well as the content itself
I can do that right now, even with dynamic loading/unloading.
I even described that I did it in another thread:
http://what.thedailywtf.com/t/discourse-and-our-reaction-to-it/344/191?u=dhromed
So... we do the same thing, but for some magic reason when I scroll in the thread it works in that quick-scan way for me, but when you scroll it does not?
-
it's largely the necessary workarounds for infinite scrolling's total impossibility that are at fault.
+1
I don't really have a problem reading one thread with infiniscroll, but I also just opened five search result threads in tabs, and it fucking froze and skipped the video in another window. The CPU usage of DC is very bad. But I suppose, that'll be hypothetically fixed with The New Version Of Ember?
-
The CPU usage of DC is very bad.
I haven't dived into the source as of yet, but this piques my curiosity. I don't see any heavy lifting for this site, especially nothing that should continue to happen when you're not actively using a tab (maybe pinging the server for updates but come on, that's network IO-bound).
How is it wasting so many cycles, doing what?
-
Near as I can tell, it's doing:
a) tons of ajax requests
b) putting tons of HTML in the dom
c) lots of peripheral stuffWe know a) is not a CPU hit but a time hit which translates to "slow" regardless.
And b) may be a massive CPU hit depending on the intricacies of the insertion method. I believe there was some strange variation between dumping a string in innerHTML or making dom nodes an appendChilding them. People who've done more with this obviously know better than I what the tradeoffs are.I have not even a slight inkling how heavy c) could be.
-
There's two things that break it.
Frist! is the old "finite bandwidth, finite processing power" thing - there's a fuckload of ajax requests and DOM manipulation going on, and it's simply not smooth. Scroll out of the "loaded" zone, and there's a pause, a hiccup, call it what you will. It breaks.
The second issue may be limited to an audience of "me", but I do all the pointery stuff using a graphics tablet. So, grab the scrollbar thumb with my pen (absolute pointer + hand-eye feedback == enormously accurate and very fast, even on very small hitboxes), drag it down the screen, and not only does the ajax cause a glitch, it moves the scrollbar's thumb back towards the middle of the window. But my pointer, being absolute, is no longer on the scrollbar's thumb... Basically, I can't scrub with my setup.
-
bsolute pointer + hand-eye feedback == enormously accurate and very fast
Indeed.
Better than a mouse.
Man, imagine scrolling DC with a gamepad.
... it would probably be perfect,
-
I can do that right now, even with dynamic loading/unloading.
Doesn't work for me - if I grab the thumb and move it near the top, it waits there for a bit, then jumps an arbitrary amount down - and if this happens while I'm still (slowly) moving the thumb, it'll start jumping up and down erratically. Something similar happens if I move it near the end.
-
Doesn't work for me - if I grab the thumb and move it near the top, it waits there for a bit, then jumps an arbitrary amount down - and if this happens while I'm still (slowly) moving the thumb, it'll start jumping up and down erratically. Something similar happens if I move it near the end.
This. And @dhromed, if you can't repro on this thread, try it on one of the bigger threads (300+ posts). You'll definitely see it there.
-
@Lorne_Kates said:
Fuck, WHEN something was said is just as important as what was said, because it gives context.
…
"I just had the best whiskey". Was that posted at night, so the person is having a night cap? First thing in the morning, so they need to go to an AA meeting? In the middle of the workday, so they work at Inedo? Context is lost.
Not that I'm overly fond of the "n <somethings> ago" approach, but context is lost anyway. After all, you don't know what timezone I'm in, so "@ 22:42" doesn't necessarily mean it's twenty to eleven in the evening and I've just got home from the pub. Unless you're suggesting displaying the poster's declared (or worse, determined from ip address) local time on the post, which would be a WTF in itself.
-
Not that I'm overly fond of the "n <somethings> ago" approach, but context is lost anyway. After all, you don't know what timezone I'm in, so "@ 22:42" doesn't necessarily mean it's twenty to eleven in the evening and I've just got home from the pub. Unless you're suggesting displaying the poster's declared (or worse, determined from ip address) local time on the post, which would be a WTF in itself.
And this is further complicated by the fact that people lie. Seriously, you think everyone would be honest about where they are?
-
And this is further complicated by the fact that people lie. Seriously, you think everyone would be honest about where they are?
Bug: When I lie to Discourse about my location, Discourse lies to me about the time.
Workaround: Stop being such a lying liar who lies.
-
Bug: When I lie to Discourse about my location, Discourse lies to me about the time.
Workaround: Stop being such a lying liar who lies.Well, that works for me, but how do I know someone else isn't lying? Huh? How? This is an important, existential question that must be answered!!!
On a more serious note, you should also consider someone who's taking a vacation. To use @Lorne_Kates's example of "I just had a whiskey". Let's say I live in California, and I post that at 10 AM Pacific Time. Now, @Lorne_Kates thinks I need to join AA, even though I'm traveling in Ireland where it's 6 PM, a perfectly reasonable time for a whiskey. Of course, for someone in Ireland, pretty much any time could be considered a reasonable time for a whiskey.
-
Let's say I live in California, and I post that at 10 AM Pacific Time. Now, @Lorne_Kates thinks I need to join AA, even though I'm traveling in Ireland where it's 6 PM, a perfectly reasonable time for a whiskey. Of course, for someone in Ireland, pretty much any time could be considered a reasonable time for a whiskey.
I always understood that forums showed you times in your local time, not the posters' local time.
-
I always understood that forums showed you times in your local time, not the posters' local time.
I believe that's the standard. But from @Lorne_Kates's example, it appears that he wants to see not only when someone posted, but also where they are. Otherwise his example wouldn't make anymore sense than my own:
@Lorne_Kates said:
Right, it's impossible. Information is lost. And not just time information (though it is), but context. "I just had the best whiskey". Was that posted at night, so the person is having a night cap? First thing in the morning, so they need to go to an AA meeting? In the middle of the workday, so they work at Inedo? Context is lost. You are intentionally destroying information.
-
if you can't repro on this thread, try it on one of the bigger threads (300+ posts). You'll definitely see it there.
Yeah, got repro.
Somehow doesn't interfere much with my ability to scroll.
-
[size=39]Size 39[/size]
[size=40]Size 40[/size]
[size=41]Size 41[/size]
-
Not that I'm overly fond of the "n ago" approach, but context is lost anyway.
Fine, here's another example. Just substitute 'years' for 'hours' or 'days' or anything.
"Just visited the site of the World Trade Center. Snuck out a souvenir, don't tell anyone ;) " - Posted 13 years ago. Am I an excited tourist with a I heart NYC shirt who just took some awesome photos, or a creepy graverobber?
-
Both?
Yeah, I know, x [units] ago is lossy, and easily fixable. But it's frankly trivial and pointless to consider when the whole damn site is lossy compared to other solutions, and a lot of it isn't easily fixable. Fixing that would be arranging deckchairs on the Titanic. Or rather, polishing the doorstep whilst the elephant in the room is inside shitting on the carpet and diddling your mom with its prehensile member.
-
@Lorne_Kates said:
Fine, here's another example. Just substitute 'years' for 'hours' or 'days' or anything.
The lack of precision is no problem at all; hover over the time indicator to get something precise. If the rendering of a server timestamp to something readable by you is done in the browser, it'll be in your local timezone (or whatever you've told your computer to use, in which case you've got your own private WTF and it's not DC's fault at all).
If the rendering of the precise time is server side with no adapting to the user's timezone, that would suck. (You can't guess from IP, and the Preferences page lacks sufficient info as the
Locationfield is unvalidated.) Yet I suspect they don't do that; they're already doing a heroic quantity of javascript tinkering…What happens when you use a phone or tablet? I'm currently keeping my use of this site on something beefier, so I'm curious how the inherent lack of hover causes things to change (if at all).
-
hover over the time indicator to get something precise
Just tell me how to do that from a mobile device or tablet.
@dkf said:What happens when you use a phone or tablet?
Besides the site running even slower than on the desktop and being a drain on the battery (as you said in another thread, their CPU usage is high), the "X ago" is only that text and not even a link like it is on the desktop.Other changes: reply as a topic is gone, hover effects are (rightly) not there, clicking on the profile picture or the username goes straight to the profile instead of any "popup", you can't tell at all if the click you did is loading anything until a few seconds pass (unless you can see the tab, as you'll see the title change).
-
Basically, I can't scrub with my setup.
We are not philosophically against doing something that Slack and a few other apps do and getting rid of the scrollbar and replacing it with our own scrollbar. Its something we are happy to experiment with. Personally, I would prefer it, it could provide additional hinting and allow for some real fast scrubbing of large topics (and has some advantages on tablets cause you can control way better when js fires). But, it is a can of worms cause we would have to implement acceleration as well, mouse wheel support and so on.
@codinghorror does note that the scrollbar now indicates when the next time is we will load posts, however this is totally solvable with a custom scrollbar, you can hint differently.
However, if there is a philosophical objection to having a stream where some stuff is NOT in the DOM which you are unwilling to compromise on, then I am not sure we can make you happy.
Yes we can make your pen usage fine on huge topics, yes we can make search function in a way better way. But, no there is no practical way of keeping 10K posts in a DOM, it just will not work.
a) tons of ajax requests
The ajax requests do not map directly to slowness, the main reason stuff may feel a bit slow is client side rendering, we pull reasonably big chunks off the server, even under typical use.
-
Specifically - you're breaking the scrollbar, and Lorne's already partially explained why the OS implementation is far better than anything you could hope to implement - what (IIRC) he missed is that, of necessity, you're still leaving the scrollbar in place, and this causes confusion; you are providing the user with 2 potentially conflicting pieces of information, and the one that would usually be definitive is the one that's actually wrong
Two observations, and this goes out to @sam as well:-
The scrollbar is massively suppressed in OS X and iOS already. It's not even visible most of the time. So to argue that the scrollbar, in a world of infinite content (can you get to the end of the Internet?) is this hugely massively important bit of UI, just doesn't make sense to me. If it's so important, why would Apple go so far to suppress it?
I barely look at the scroll bar most of the time, it's way over on the right side far out of my field of view. The signals of "reaching the end" and "how much of this is there" are usually visible on the screen right where I'm looking, directly in my field of view. Not way over in right field where I never look.
-
The actual behavior of the scrollbar is about the same as it is on paginated interfaces. You reach the bottom and you have to do something to load more content. In the case of Discourse, you do nothing but touch the bottom and it's all automatic. Like Jay Leno said, eat all the Doritos you want, we'll make more. But the trigger case of "reached the end of this chunk of content" is identical for the scrollbar in both cases.
You break the expected behaviour of search.
Again, debatable. If I search on the current page, does that search the entire topic? That's not true on paginated forums. You're only searching the current page. So if I want to find out who said "albacore" I have to load page 1, search, load page 2, search, load page 3, search.. repeat for every page in the topic. If that's expected behavior, the status quo, then it sucks. It's not something to be mindlessly defended as "welp that's the way we've always done it and who are you to say it should ever be otherwise", it's something that should be improved.trying to fix it with keyboard shortcuts
Nope. We start with shortcuts for power users and extend to the UI as we go based on actual usage numbers, and what people actually use versus what they say they use. I don't know if you know this, but users are lying bastards.You're breaking the browser's history
You know what else breaks the browser's history? Gmail. Good thing nobody uses that piece of crap, right?
We practice complaint driven development at Discourse, across multiple instances, dozens of them. Guess how many people, across 12+ active Discourse instances that I personally monitor, complain about broken browser history ala GMail? Hardly anyone.
I do all the pointery stuff using a graphics tablet. So, grab the scrollbar thumb with my pen (absolute pointer + hand-eye feedback == enormously accurate and very fast, even on very small hitboxes), drag it down the screen, and not only does the ajax cause a glitch, it moves the scrollbar's thumb back towards the middle of the window. But my pointer, being absolute, is no longer on the scrollbar's thumb... Basically, I can't scrub with my setup.
OK, so for the .0000001% of our users who are using a tablet with a stylus? And isn't the stylus on PC basically mouse emulation?
-
-
Nope. We start with shortcuts for power users and extend to the UI as we go based on actual usage numbers, and what people actually use versus what they say they use. I don't know if you know this, but users are lying bastards.
So, you make it available only to power users, only on desktops/laptops, with limited discoverability, and then decide whether to make it generally available based on actual use? Sounds like a good way to never make new features available for general use. I prefer to introduce features for general use, track their usage over a period of time, and restrict the less popular ones to power users only. Obviously, you would occasionally need to make exceptions for features that should never be generally be available, but that's the way design goes.
-
So, you make it available only to power users, only on desktops/laptops, with limited discoverability, and then decide whether to make it generally available based on actual use?
We didn't even have a mobile design for ~10 months after launch. At all. And mobile is kind of important, wouldn't you say, to the future of all computing? Maybe just a little? A tiny bit?We made that choice because the devices with real keyboards attached tend to be the place where most of the content (read: typing) is generated. So it's our primary audience, but the secondary (mobile/tablet) is equally important, and arguably more important over the 10 year timeline of the project we're working from.
-
If it's so important, why would Apple go so far to suppress it?
Filed Under: Fox Butterfield, is that you?
-
-
replacing it with our own scrollbar
And roll your own crypto while you're at it!
Look, do I really need to make one of those flow charts where every decision branches back to the same solution? Implement optional pagination, you don't have to waste time coming up with half-baked solutions to not quite re-implement features you've taken away just to avoid doing pagination.
Infinite scrolling and scroll bars cannot work. Will not work. Anyone who wants infinite scrolling does not want a scroll bar. Anyone who wants a scroll bar does not want infinite scrolling.
Re-implementing browser/OS UI controls. Wow.
-
BTW, I do owe @apapadimoulis a reply to the points raised in his reply. Just acknowledging I read them letting it brew/
-
You know what else breaks the browser's history? Gmail. Good thing nobody uses that piece of crap, right?
So, Google does it, and that makes it OK? Don't think so...
-
@Lorne_Kates said:
Re-implementing browser/OS UI controls. Wow.
This actually quite common, for example:
Why do this crazy, you ask?
Well besides all browsers implementing select boxes in horribly inconsistent ways, they lack features. Features that make them easier to use.
In a similar fashion, I don't think the scroll bar is a perfect fit for infinniscroll, it can be improved.
A the moment it denotes the "estimated" height of currently loaded posts in memory, that is far from perfect and leaves some jittering, additionally we could decorate that area on click with more visual cues to ease topic navigation. If we were to render stuff in a fixed panel and control scrolling ourselves we can eliminate a large amount of jitter you see when posts render. That would improve usability.
That said, I am talking about an experiment here, not a concrete plan.
I admit, pagination has its advantages (I also think it has its disadvantage), however we are foremost focusing on
-
Repeated requests we are hearing from users of our system, there are thousands of installs out there (including many paid installs), this is the first time we have experienced the violent hate towards infiniscroll.
-
As a product designed for the next 10 years of the web we are building a "rich", "cutting edge" JavaScript app. Not a Motherfucking Website. We need to focus on our key UI first and foremost. We need to focus on our platform (hence my offers to help guide people interested in building pagination).
You have to understand that we would much prefer focus effort on speeding up rendering, removing jitter, improving navigation... than building a whole other system we need to support.
We can not dedicate engineering effort towards pagination until 1) is met.
-
-
tufty said:
You break the expected behaviour of search.Again, debatable
No it's not.
If I search on the current page, does that search the entire topic?
Why are you asking? Of course it does.The user hits CTRL F (or a custom variant thereof) and is viewing what you gave him; a theoretically complete view of that entire topic/page/thread/wtf.
He scrolls up and down and marvels that he gets to see the entire TPTWTF without having to page, then searches and it only applies to a tiny letterbox on the thread? Tell us what the "not found" message is going to say. Perhaps;"Your search text was not found. Well, when I say it wasn't found, I mean we didn't find it a virtual page or two above this and roughly the same belowish. Try scrolling a bit, then try the exact same search. And then keep going. You never know - YOU MIGHT GET LUCKY! - go on, try it, you know it's some fun in your otherwise dreary day" ??
It's about expected behaviour - you're the one who insisted on farming up the entire topic in a single "page"...
-
Seriously though, who the fuck uses scrollbars anymore anyway when there is a mousewheel handy.
Other than the crap styling, I haven't found browsing these forums as odious as the screamers would have you believe. Although since this is my first post on this particular forum I haven't really exercised the reported bugs in any real way. Mainly the ones I see are the slightly dodgy or arbitrary idea of which topics it thinks are new or unread.
Fix the bugs and the styling, and this place is workable. Fuck the scrollbar, we don't need it.
Edit: Although I would like the post counts back.
-
Try scrolling a bit, then try the exact same search.
But scrolling dismisses the find box, which has bitten me several times as I keep trying to type in it and end up going back a page or some such.
-
Ermmmm.... if I'm on page 1 of the Thread That Shall Not Be Named, ctrl-F ain't gonna find shit on page 50, yah? So the browser baked in search isn't really useful in the first place
-
Page search and site search are two separate, complementary pieces of functionality. In the former, I expect to be able to type in an exact phrase and quickly zip to each occurrence on the page and see it highlighted in real time. In the latter, I expect it to be a little more "fuzzy" and present me with a list of matches without moving my current viewport around. Both kinds of search should be readily available, neither is a suitable replacement for the other.
-
I admit the number of times I've searched a page on the old forum is literally zero, so obviously that's not a use case for me.
Although surely it can't be to difficult to create some plugin (or whatever Discourse does) to present some widgety thing to do what you (and others) need. That way it could actually even be more useful in that it could navigate through all the instances in the topic (unlike the limitation of the old paged way which only does the current page)...
meh... anyway just thinking aloud. I've got too much work to do and I'm wasting time
-
That's the point. Here, a topic is presented as a single page so it's counter-intuitive to expect a CTRL-F or similar search to only search an ephemeral virtual window onto that text.
By the way, technically, I don't get why this is a big deal. Ajax call back to base to search the topic, then they already have the ability to show the topic focused on a specific reply.
-
Page search and site search are two separate, complementary pieces of functionality.
There's also topic search, which is like a restricted form of site search. Discourse does site and topic search quite well, but because it pretends that a topic is all on one page, there is a natural user expectation to be able to use page search as a topic search.Life is unfair. Power users doubly so.
-
I agree with this. Post count is an important proxy metric for trust-ability and important on forums. Similar to reputation on stackoverflow (yes, rep is way, way better, but it simply isn't available on forums).
Actually, Discourse does have this "like" button on each post. Counting likes might work pretty well as reputation. Including the "gamification" aspect, because earning likes takes writing witty posts and that's pretty close to the point.
The total number of posts would still have to come into play, because someone with 10 posts and 100 likes is likely a smart newbie while getting 100 likes over 10000 posts does not really mean much.
-
and the jumping to where I stopped reading is, frankly, awesome
It would be if it was more discoverable.
Normally when I need to look up something earlier or later in the thread, I mark a block of text and then use the scrollbar to come back using quick vgrep. But here it fails, because click on the scrollbar is considered a click and cancels the selection (while on non-ajax pages the selection remains). I also did not find any way to jump back after using the up arrow for looking at the post something is a reply to.
-
Normally when I need to look up something earlier or later in the thread, I mark a block of text and then use the scrollbar to come back using quick vgrep. But here it fails, because click on the scrollbar is considered a click and cancels the selection (while on non-ajax pages the selection remains). I also did not find any way to jump back after using the up arrow for looking at the post something is a reply to
That's true, but this is different that what I was talking about. OTOH, you can bookmark things, so you can come right back that way. No doubt there are others, but that one works no matter where or when you want to come back.
-
Not that I'm overly fond of the "n ago" approach, but context is lost anyway. After all, you don't know what timezone I'm in, so "@ 22:42" doesn't necessarily mean it's twenty to eleven in the evening and I've just got home from the pub. Unless you're suggesting displaying the poster's declared (or worse, determined from ip address) local time on the post, which would be a WTF in itself.
Lying is a non-issue. The server-side timestamp is recorded (ideally a timestamp independant of timezones, like seconds since unix epoch). This value is converted into a a human-readable (according to user preference) string.
If people lie about heir timezone they see all the posts as if they were in another timezone. Their problem not mine.
-
@Lorne_Kates said:
Infinite scrolling and scroll bars cannot work. Will not work.
Yet it still works no worse than pagination. With pagination you just don't expect it to work.
@Lorne_Kates said:
Anyone who wants infinite scrolling does not want a scroll bar. Anyone who wants a scroll bar does not want infinite scrolling.
I want a scrollbar and I don't have it with pagination. Because with pagination, the only thing the scrollbar tells me is how far down this page I am, but absolutely nothing about where I am down the whole content. And in most forums, I don't even see which page I am on when I am down in the middle of it.
So I want infinite scrolling and I want scrollbar. And I believe it can be improved to work rather decently there. It can't be fixed with pagination at all.
Note: I am in no way affiliated with Discourse and this is my first experience with it. I came here, read your arguments and tried moving around a bit. And realized it just works no worse than pagination for me. Not perfect, but not worse.
-
OTOH, you can bookmark things, so you can come right back that way.
Yeah, I noticed the bookmark flag. But I don't see how to come back to it (still talking about the case of going to peek at some other post way above and returning to the spot I was 5 seconds ago).
-
If people lie about heir timezone they see all the posts as if they were in another timezone. Their problem not mine.
I suspect you missed the point here.
The issue is that when you see two posts marked "@ 22:42", refering to your 22:42, it tells you absolutely nothing about what was poster's time.
For example I am writing this post at 14:31. If you see any other time (it's there in tooltip), you don't have the right context.
-
Yeah, I noticed the bookmark flag. But I don't see how to come back to it (still talking about the case of going to peek at some other post way above and returning to the spot I was 5 seconds ago).
It's not obvious, I guess, but you have a Bookmarks entry in the menu on the left side of the page when you go to your profile.
On the old forum, I would often simply open a different tab and do whatever I needed to do there. Then I could come back and I was right where I left off.
-
It's not obvious, I guess, but you have a Bookmarks entry in the menu on the left side of the page when you go to your profile.
That makes it useful for returning where I was yesterday, but not where I was 5 seconds ago. Fine.
On the old forum, I would often simply open a different tab and do whatever I needed to do there. Then I could come back and I was right where I left off.
Which fortunately turns out to work here fine too.
-
You know what else breaks the browser's history? Gmail. Good thing nobody uses that piece of crap, right?
You know, the expected behavior for Gmail would be:- View a page of the inbox or a folder or a label, get a history item
- View an email thread, get a history item
- Scroll through an email thread, don't get any history items
Which is how it works. That's not broken, that's how the history works on generally any site, by design. When a page "loads", you get a new history item. Gmail is no different.
How Discourse works is different. While not broken per se, it is very, very spammy. The point that Gmail doesn't put in history items (reading through an email thread), Discourse does, so if I, in one go, read a 300 post
threadtopic, I now have 300 history items thrown in my browser history instead of just 1.That is effectively where I believe @tufty is saying you're breaking the browser history. Only the initial view into a topic should put in a history item, not every post I look at.
