1. 105

  2. 30

    I’m glad eevee made this post. I wish I could file bugs against twitter’s webapp, but I suspect they have bigger problems on their hands.

    • js required for posts occasionally doesn’t load, forcing me to refresh the page repeatedly to post
    • no indication that you are viewing a cropped or uncropped version of a picture. I often click three times just to make sure I’m seeing all of something (often the missing part is in-image text which explains the picture to begin with)
    • unable to right-click embedded tweets (or links within them), meaning I can’t open them in a new tab, meaning I click and come back to the timeline and have to figure out where I was
    • unnecessary pop-ups/lightboxes/modals. they’re adding them into even more strange places over time: single tweets are now modals over the person’s profile. clicking “3 more replies” used to expand in-timeline, now it opens a modal for some reason
    • mobile.twitter.com loads a few recent tweets and presents cached tweets from the last time you loaded the page. sometimes there is an indication of a multi-day jump, sometimes not. this seems to go beyond ‘eventual consistency in the timeline’ and appears to be broken cache logic. it’s difficult to reload mobile.twitter.com “fresh” without the cached tweets
    • mobile.twitter.com does not show when a post has multiple images. it simply displays one and has no indication that there were more than one in the set
    • DMs on mobile.twitter.com are broken. it’s claimed I have 6 unread DMs since time immemorial

    Ones they’ve fixed:

    • clicking on a user used to spawn a modal, but now it goes to the user’s page as you’d expect. true to form they’ve added a useless hoverbox instead, but at least it doesn’t get in your way
    • it used to be confusing where to click to ‘expand’ a picture or video tweet and where to click to ‘collapse’ it. I recall a past when there was different unexpected behavior for either, but that seems to be consistent now.

    I have a lot more complaints against the UI but I should probably cap this to the serious ones…

    1. 17

      the most spiteful thing about this isn’t just that it destroyed usability (especially if you need to use a keyboard and can’t use a mouse, or use a screen reader) and makes websites unusable and slow – it’s that there are many applications where javascript in web pages is actually useful.

      for example, checking the checksum on a credit card number (so you don’t need to submit a typo’d credit card number and have to reenter everything on the page) (also you literally afaict never need to click on the “this is a visa” radio button, the card type can be identified with the number)

      also it was cool when twitter let you look at threaded tweets on a timeline/userpage without having to change URL or open up a horrid cringey lightbox, it was fast and useful and wasn’t too onerous, unlike the new lightboxes.

      i hope whoever invented those lightboxes for tweets has to use twitter on a computer that doesn’t have the latest CPU and doesn’t have 24 GB of memory and isn’t connected with a gigabit link to twitter.com. it is sufficient punishment.

      1. 16

        I recently used a Gopher site.

        It was - hands down - shockingly better at information presentation than, say, 80% of sites out there. And blazingly fast. I feel sad that smart and nerdy engineers built HTML/JS/CSS in the 90s. They had a chance for a better world, and chose to let the current dumpster fire start. Even HTTP has major problems.

        I’m so over the Web 2.0 and whatever jibber jabber is post 2.0 at this point. My home projects uniformly don’t use HTML as a presentation layer; I generally avoid using the “web stack” at work, because of the staggering non-design that continually causes problems.

        1. 13

          Web developers need to get back on their feet. It is perfectly possible to create websites which work fine without Javascript, but have a pinch of Javascript added to improve the experience. If I stumble upon a page using Javascript excessively, I am not likely to put up with this bullshit and move on. If you have a Mac Pro and a Gigabit landline, you don’t know what I’m talking about. However, less is better because many many people browse the web as thin clients, and not everybody has recent hardware. If you build your websites with non Javascript users in mind, you’ll most likely end up improving it for search engines automatically. Don’t start with the visual template, always start with the semantic template and build on top of that.

          And please, please stop the excessive Javascript bullshit. I don’t care about your “skills” to bloat a page to the point of insanity. It takes real skill to do the opposite: Do a lot with little, at best with non-excessive and proven Javascript functions and with “use strict;” to control what you do. While at it, please stop “compiling” your Javascript. Thank you!

          1. 8

            The memory usage of twitter.com brings my 2014 Chromebook to its knees. I can barely tolerate having that tab and an ssh window open at the same time; anything beyond that is not practical. It never reclaims memory from tweets that have scrolled out of sight, so I refresh it every ten minutes or so.

            I can actually do quite a bit on the Chromebook, as long as I don’t try to view Twitter.

            1. 10

              This is why I have started using Tweetdeck.

              • A lot of Javascript too, but not slow at all.
              • Not as feature-rich as Twitter.com, but still allows you to easily bail out to twitter.com for content that can’t be viewed through it.
              • Not a native client I have to install.
              • Owned by Twitter, so no sharing data with 3rd party.
              1. 2

                TweetDeck is (generally) better than the web version, unless your account is locked.

            2. 7

              I could not agree more with his criticism of re-implementing features that are intrinsic to the web in JavaScript to make them “prettier” or “more responsive” while breaking so much basic functionality. Here’s a favorite of mine, loading more search results with an AJAX request when you reach the bottom of a page rather than having pagination with “Previous” and “Next” links. One culprit of this is YouTube; I’ll often browse a channel’s videos, find one that I like and click on it. When I’m done watching, I’ll press the back button of my browser and I’m back at the top and I need to scroll down a bunch of times to get back to where I was. Something similar happened on Twitch.tv when I was looking for a highlight from 2-3 years ago on a channel: I spent a good 5 minutes just scrolling down to the bottom, waiting for more results to appear and scrolling again. If there had been something with page numbers like we see on many BBS, I could’ve jumped easily by 20 pages or even just change the URL to a large enough number and go from there.

              If I was a better writer, I’d make a quip about “those who forget web 1.0 are doomed to reimplement it, badly” or something to that effect. It’s especially frustrating when you consider that many of those “new and improved” web experiences require so much memory and CPU power that they are completely unusable on a laptop that’s a few years old.

              1. 3

                I could not agree more with his criticism of re-implementing features that are intrinsic to the web in JavaScript to make them “prettier” or “more responsive” while breaking so much basic functionality.

                Indeed. I have a special hatred for javascript scrollbars.

                1. 1

                  Infinite scrolling is like the new javascript scrollbars from 2003.

                  1. 1

                    I think sites doing everything themselves in WebGL+Canvas because “the dom is too slow” may be the latest addition to the list of possible reasons for “why is my laptop on fire?”.
                    Still a bit soon to tell. ;)

                2. 1

                  One solution that preserves both the convenience of infinite scroll and jumping to a given page (as well as saving your place on the page) would be keeping the page number in a URL fragment and incrementing it on infinite scroll. So far I’ve seen it used only in RES.

                3. 6

                  I used to use a RSS/Atom reader to view tweets but Twitter removed the ability to do so about a year ago. Afaik this is now only possible with a registered account and API key.

                  I have written a small tool called “tscrape” to scrape the Twitter user page and write the fields TAB-separated to stdout. It is written in C and has no external dependencies except make and a C compiler. Using a wrapper script and the standard UNIX utilities it should be trivial to display tweets any way you like.


                  curl -s 'https://twitter.com/lobsters' | tscrape
                  1. 12

                    I would like to back up what @lmm said and lost a few karma points for –

                    Any user who deliberately blocks JavaScript is not a user I am optimizing for.

                    The Web, in 2016, encompasses HTML, CSS, and JavaScript. Would I spend time debugging style or content placement issues for a user who applied their own global stylesheet over my site? Of course not! If someone had a Chrome extension that rearranged elements in my site’s DOM, would I field bug reports about broken pages? Hell no! Now why would I waste any cycles making sure my site works for able-bodied people with one of the three pillars of the Web disabled?

                    Note that I believe all sites should be usable as pure HTML for accessibility purposes. This is my exception to the above, and is not addressed in this article. It makes a convenient backstop too, as the aforementioned able-bodied JS-shunners – yes, who make up a tiny fraction of a percent of my users – can fire up /usr/bin/links and have the 1998 experience they were dreaming of.

                    1. 6

                      and lost a few karma points for

                      It’s really disappointing to see down votes for these opinions - no matter how much some disagree.

                      I’ve always been impressed at the level of discourse on this site. Trying to squelch a reasonable opinion - and it is reasonable - because it’s not shared is pretty shameful IMO. I just hope it’s a one-off and doesn’t represent a trend of where lobsters is headed.

                      1. 2

                        Ironically enough I do use a custom stylesheet, to turn off the max-widths a lot of sites seem to use these days. But when I break a site by doing that I see that as my problem and I don’t complain about it.

                      2. 13

                        It’s just not worth it. The people who block javascript or have it not work are a tiny fraction of a percent - they’re the kind of “bad customer” that you’re better off “firing”. And it sounds like the author hasn’t even stopped using twitter because of it!

                        1. 11

                          And it sounds like the author hasn’t even stopped using twitter because of it!

                          This is sad, as it reflects the reality of network effects.

                          Twitter/FB/everyone else could degrade our experiences significantly more and we’d still feel compelled to stay, because it’d be weird to not have a YouBook account. Essentially, it feels like we’re slowly ceding control of technological matters to non-technological users.

                          This is not what I signed up for.

                          1. 2

                            I can’t upvote this enough!
                            I pine for relocatable accounts. I don’t even care if they are distributed, just easier to import/export data into/out of. Why can’t I say, “I don’t like Facebook.com any more, I’m going to move my profile to MySpace2.com”. Ideally everyone’s links to me in all services would then update to point to me and old posts on my new provider. I know this is a big logistics problem and obviously no one has the Facebook software except Facebook for example. But I think something like this is an interesting dream. We have reasonable standards for viewing web pages and even servers talking to each other, yet migrating accounts between various services is still a sore point. And yes I do realise that everyone running Diaspora (Especially Google, Facebook et al) is pretty much never going to happen unfortunately.

                          2. 7

                            The problem here is JavaScript being overused and legitimately hurting usability, not “never use JS”. It’s stated in the article that some things here use JS and that’s fine, however it’s about JS that shouldn’t have to be used.

                            1. 3

                              If javascript is the easiest way to do something then why not use it? Unless you have some very specialized requirements, you’re already just assuming javascript as the baseline for anyone using your app. It’s really very rarely worth even memorizing or looking up which parts of your framework are going to result in using javascript and which aren’t.

                              1. 8

                                The trap is in thinking you can just throw JS at problems and be done with it.

                                You should be able to, but the browser is an extremely hostile execution environment. Rather than tilt at windmills saying, “well, people shouldn’t do x and y,” accept that JS has it’s own set of drawbacks, and use it when it genuinely improves the experience without sacrificing functionality for times when it fails, either due to browser configuration or other issues beyond your control.

                                No page is entitled to run JS. The beauty of the web is that the user-agent can make those decisions. The fact that this makes it harder to program for is not the user’s problem. Abdicating your responsibility to progressive enhancement is laziness.

                                Other platforms (iOS, Android) do not have these issues. I prefer programming them because they are more conceptually sound, move slower, use far less resources, and are easier to optimize for.

                                1. 3

                                  The user-agent can do what it likes. But the server can decide what it’s going to support. How much engineering effort is it worth for twitter to improve the experience for the tiny minority for whom JS won’t be running correctly (particularly when it seems like the non-JS experience wasn’t bad enough to drive this person away from twitter)? I don’t think it’s twitter who are tilting at windmills here.

                                  1. 3

                                    Of course. And this is one of the tensions with the web as an application delivery technology. And the general failures of UX the OP mentions are not really related to Javascript; but they are easier to inflict on one’s users because of the overall laxness of the web application stack. It would be very hard in Cocoa, for instance, to produce such implacably user-hostile behavior as stealing system-level keybindings, &c.

                                2. 6

                                  The thing here is that JavaScript in this example isn’t the easiest way to do it.

                                  1. 5

                                    In addition to what’s been said, I’m not sure why we’re thinking in therms of “if javascript is the easiest way to do something” instead of thinking “if this way of doing something is best for our users.” There are a few use-cases that aren’t being addressed by the “js for everything” mentality, and that does hurt some users.

                                3. 1

                                  My use of GitHub has greatly diminished since it mostly stopped working in my browser, as they don’t just require JavaScript, but the most recent and up-to-date JavaScript possible. Plus, they have some real competition, unlike Twitter.

                                4. 3

                                  For me, the twitter webapp currently displays any link preview as only 1-3 characters and then an ellipsis for both the title and the body. This makes all that space much less useful than just showing the URL, which is truly hard to do and I applaud twitter for working it out.

                                  1. 4

                                    100% agree. And it’s actually even worse with GitHub, for example.