Skip to main content
Meta Stack Exchange

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

Required fields*

Deprecating our mobile views

Update 2

On March 2, 2022 we removed the Mobile button from the footer. This means the mobile views are removed entirely from Stack Overflow. Last week, we also removed the Disable Responsiveness button. With that, I’ve now marked this post as 🎉

Update 1

On Feb 14, 2022 we removed one of the last mobile views—the question page. When you visit a question, you will now be shown the responsive version instead. We will be following up to remove the Disable Responsiveness and the Mobile button in the footer. When that happens, this will be filed as .

Original post

I’m Aaron Shekey. I’m a product designer at Stack Overflow, working on our design system, Stacks. At the time of writing this, I’ve been chipping away at our front-end for 4 years. You may recognize my name and face from previous announcements like: Dark mode, fonts, post formatting, blockquotes, or the #1 feature (削除) everyone (削除ここまで) no one has asked for, confetti 🎉.

Stacks powers a bunch of our site—more each day. It’s a way for us to quickly build or refactor all kinds of features. Stacks has a ton of components like buttons and navigation, popovers, even a full-featured editor. It also has features itself. For example, by using Stacks, our designers and engineers get dark mode for free.

Stacks is also responsive by design. While you don’t quite get fully responsive layouts for free, it’s super easy to build views that scale to all viewports, regardless of device or window size. Traditionally, our approach to mobile devices was serving an entirely separate site that is loaded based on your user agent string. If our backend thinks you’re on a mobile device, we’ll show you a different view from if we think you’re on a laptop.

This creates a couple of issues. First, if you’re adding a feature to an existing part of the site, you have to build two separate front-ends—one for mobile, and the other for our desktop view. This introduces more opportunities for bugs, and has even introduced some security holes over the years. Our teams are full of busy humans, and it’s tough to execute, test, and deliver a single website, let alone separate ones.

Second, this creates an inconsistent experience for our user. The mobile views are generally more simple than the desktop views. Certain features have been left out of mobile over the years, others were shipped and unshipped. Others just never got built for mobile users. Over the years, the aesthetics between the two views have drifted.

Also, the mobile site is barely themed when visiting our Stack Exchange network sites. Lame!

Landscape

Currently, high volume views still have a unique mobile and desktop view. If you load some questions on your mobile device, chances are it’ll show:

If you’re signed in to our site, and you’ve enabled responsiveness, it looks like this:

Instead of maintaining both of these, we’re going to unship the mobile view and opt everyone into the responsive views by default. Along the way, we plan on improving the responsive views we show.

Tasks

Reduce page weight

One of the benefits of a mobile-only view is that they can be a much smaller page load. This is the result of a mobile-first approach, but often comes at the cost of removing features.

In order to go fully responsive for all users, we’ll need to explore alternate designs that reduce overall page weight for all visitors, while maintaining desktop features on mobile.

For example, as it’s currently built, the footer we serve every user is surprisingly big from a page weight standpoint. We’ll need some design refinements to reduce the amount of HTML we’re serving over the wire while maintaining discoverability and search engine optimization. One possibility is serving parts of the footer asynchronously, only after the user has interacted with it.

Build responsive views where they don’t exist

Other views like user profiles simply don’t have a responsive view yet, since these pages haven’t been invested in recently. We’ll have to figure out how to handle navigation at the smallest breakpoints while maintaining all the desktop features.

Prioritization

You may have noticed that we’ve already killed a few mobile-only views. All the log in and sign up pages are now fully responsive—serving the single responsive view for each. Other pages like /users and /tags have recently switched to responsive as well. We’re going to first convert the easiest, least often visited pages first. Heck, some of these pages even we didn’t know existed.

Then, we’ll start addressing those known page weight issues by implementing light design changes, and refactoring more views to use Stacks components. Once that happens we can start killing mobile views of more highly visited views.

Ultimately, we’ll be leaving views like /questions and the individual question view to the very end. Then, when all mobile views are deleted, each user, regardless of device, will be seeing a single fully-responsive site.

Timeline

We hope to be done with this by the end of 2021. The Stacks team has a few engineers working on this nearly full time. We still have to introduce new features, fix bugs, and ship new versions of Stacks, but it’s something we’re working on in earnest—we don’t plan on setting it aside until it’s done.

We’ll be adding on existing and future mobile-only bug reports and pointing to this post since those views are getting unshipped.

Answer*

Draft saved
Draft discarded
Cancel
16
  • 9
    Maybe I'm missing it but the question seems to explicitly cite that slimming down the responsive view is necessary and even gives the example of the footer being hefty to download. Is there something about the question that you feel doesn't address this issue? Commented Jul 19, 2021 at 20:13
  • 6
    @Catija It wasn't clear to me that that was mostly referring to bandwidth, but rather client-side loading (as in CPU performance to render a particular HTML). While there was a reference to reducing HTML size, it didn't say anything about assets (e.g. images), which have a much larger size than HTML (on the whole). Commented Jul 19, 2021 at 20:15
  • 19
    @Sonic Not sure if it counts for all that much, but I work with front end web professionally, and I definitely read "page weight", "smaller page load", and "reduc[ing] the amount of HTML we’re serving over the wire" in the post as referring to bandwidth concerns almost exclusively... in addition, CPU performance for loading web pages just isn't a big concern or constraint in this area; that's an extremely uncommon bottleneck. I totally agree with highlighting this concern though, it's a really major one. Commented Jul 19, 2021 at 20:27
  • 1
    Most graphical assets on Stack Exchange are SVGs, but some site themes do use PNGs. The SVGs look quite well-optimized already. Some PNGs can still be optimized using tools like Trimage (PNGCrush, OptiPNG, etc.), e.g. the header and footer graphic here on MSE (by 49.5 %, from 31.1 KB to 15.7 KB). But then again, the MSE header background can also be remade as an SVG. Some other PNGs are already maximally optimized. Commented Jul 19, 2021 at 20:31
  • 5
    @zcoop98 I have several old computers running modern operating systems; on such systems, the speed test shows a fast connection, but it takes time because the CPU has to render the page. Also, the staff answer to my prior question mainly talks about that, so I thought Aaron was talking of the same here. Commented Jul 19, 2021 at 20:34
  • 8
    Another thing that can be optimized: raster graphics are often served with a higher resolution to devices with high-DPI screens, which of course requires more bandwidth. Fortunately, there’s a <picture> element supported in all of Stack Exchange’s supported browsers which addresses this issue. Currently, Stack Exchange doesn’t seem to use it. Commented Jul 19, 2021 at 20:43
  • 7
    Back in 2012, I spent a couple of weeks with what was literally a 16-20 kbps connection. While that's extreme, testing against what you might expect to be a reasonably potato connection. There's tools that simulate these IIRC - and might be worth looking at. As a bonus, a fast site on a slow connection is even faster site on a fast connection Commented Jul 21, 2021 at 2:05
  • @JourneymanGeek Only had a 28.8k modem handy? Commented Jul 21, 2021 at 2:09
  • 1
    Crappy CDMA dongle thing actually. I would not consider this a reasonable baseline in 2021 of course, I didn't in 2012 - but working out what is the worst worth supporting would be a good idea. Commented Jul 21, 2021 at 2:24
  • 7
    This is a good reason to aggressively block ads! Commented Jul 21, 2021 at 6:39
  • @VictorStafusa If only Chrome for Android and iOS supported extensions... Commented Jul 21, 2021 at 16:30
  • 6
    @TylerH Firefox for Android does, hint hint, nudge nudge. Commented Jul 21, 2021 at 16:57
  • 2
    @Mast There are also separate apps that block ads across all apps, such as Blokada, which I use. Commented Jul 21, 2021 at 18:09
  • @Mast Yes, I use it sometimes, but there are things/sites that Chrome mobile just handles better, unfortunately. Commented Jul 21, 2021 at 18:25
  • And if you don't like mobile Firefox, there are Chromium forks which do enable real extension support on Android. Kiwi Browser is one open-source one, although it's usually a couple of Chromium versions behind. @TylerH Commented Jul 26, 2021 at 17:53

AltStyle によって変換されたページ (->オリジナル) /