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!


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.


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.


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.


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.

  • 47
    “… opt everyone into the responsive views by default” Thank you! I don’t know why, but I run into situations where I get the mobile page every so often and I have to get all the way down to the footer, put on my reading glasses and find the tiny text link for full site which at least usually comes up with responsiveness enabled. Just thinking about the mobile view going away is a QOL improvement for me. – ColleenV Jul 19 at 19:43
  • 3
    How "high up" are user profiles on your prioritization? I find that those pages are the only thing I still use the mobile view for, as the responsive design is fully "zoomed out" (for lack of a better term), making links difficult to click and other info different to find – caird coinheringaahing Jul 19 at 19:45
  • 17
    THANK YOU! The old mobile view is horrible to use, and my phone keeps resetting back to the mobile view on certain sites. This is a huge QOL improvement for me too – Zoe the 1337 Princess Jul 19 at 19:50
  • 7
    @cairdcoinheringaahing It'll happen before the question/questions view, but after all the easier stuff. Our prioritization will be influenced by lots of simple but incredibly boring reasons—so not committing too publicly to a specific order. There is a lot of work to get those profiles fully responsive. A majority of the profile isn't built using Stacks components so we need to first refactor, then implement responsiveness, and then finally kill the mobile views. – Aaron Shekey Jul 19 at 19:58
  • 15
    This is good news. My only complaint is the "unship" terminology; pls take the mobile views into a dark alleyway and return alone, kthnxbye – Shog9 Jul 19 at 22:15
  • 36
    This is terrible news. The responsive pages are oversized and filled with bloat. Look how on your own screenshot there you can't even show all the icons in the top bar! Until you fix all the glaring issues, please don't remove the mobile design which actually works and is useable. – curiousdannii Jul 19 at 22:46
  • 1
    "While you don’t quite get fully responsive layouts for free..." - I don't quite understand that. Why don't you get them for free? – Xnero Jul 19 at 22:51
  • 2
    @curiousdannii the post seems pretty clear to me that the dedicated mobile views aren't going to actually be removed until everything is properly responsive. Some pages just won't default to the mobile view right now. – TheWanderer Jul 19 at 23:36
  • 7
    @TheWanderer The problem is that the "responsive" pages are terribly designed, and waste so much screen space. – curiousdannii Jul 19 at 23:39
  • 2
    @TheWanderer Indeed, but it's hard to feel optimistic when they haven't felt the need to fix it in all the years it's been like this. – curiousdannii Jul 20 at 0:03
  • 6
    Quick, slightly silly clarification - this is for the main sites only right? I'd be quite annoyed if I lost my mobile chat views – Journeyman Geek Jul 20 at 0:41
  • 3
    @Luuklag We've raised the limit to 3 for the time being (see the sidebar actually has all three currently). – Catija Jul 20 at 19:19
  • 5
    "For example, by using Stacks, our designers and engineers get dark mode for free." You mean you charge some people for dark mode?! Genius... – TylerH Jul 21 at 16:27
  • 2
    That was really well written dude. There are very few UX people worth a toss. (TBC, just like there are very few programmers worth a toss!) Bravo. – Fattie yesterday
  • 2
    @user59748 the pages are network wide. There's little here that's SO only. – Catija 13 hours ago

Can we increase information density on the responsive site on mobile?

All the padding on the desktop site is fine for a large screen, but there's a lot of wasted space on mobile. This is the single reason I keep going back to the mobile site, as I can see so much more information on screen without having to keep scrolling.

For example:

  • Ask Question is in a weird place, wasting an entire heading height.
  • The name of the site doesn't need to be such a big logo.
  • The text of the question goes all the way to the left edge on the mobile site, but is thinner on the responsive site. I know answers were already shifted over, but it's by less than the responsive site — again, lots of padding causing less content to be visible.
  • The font size is much larger unnecessarily, not just for the question title but the normal body font too!
  • Even little things like the size of the voting buttons or the date/view count being too prominent below the title contribute to less content area.

Overall less information density makes it a pain to use. I can't even see the user profile in this example, let alone two of the comments below the question!

In landscape, everything becomes huge. I can see the entire question body on the mobile site, whereas on the responsive site people on the other side of the room could now read the question from my screen.

Small buttons aren't an issue when they've got an appropriate layout — not everything has to be desktop scaled! If we scroll down a little on the responsive site, we can compare the simple spaced out horizontal row on the mobile site with the compressed columns on the responsive site. Despite the buttons being the same size, it's clear the the horizontal row is preferable to the one that puts ‘delete’ and ‘follow’ just a couple points distance away.

  • 34
    Yes, yes, yes please! Leaving the mobile views behind is great, but I would love to be able to maintain the smaller scroll distance and higher information density from mobile on the responsive view. – zcoop98 Jul 19 at 20:43
  • 20
    Lots of refinements to be had, for sure. We've gotta find a better home for that ask a question button. However, there are some pros to that responsive view regardless of scrolling. We can see some question stats, and we also get a community theme. Our mobile-only views have some tiny buttons for being optimized for mobile. There's a balance for sure. ✌️ – Aaron Shekey Jul 19 at 20:46
  • 29
    @Aaron I understand and I see the benefits, but for me currently the benefits do not outweigh the downsides. I just want to make sure such things are considered before the mobile site is removed completely (I've added another set of screenshots), as these issues have existed for a long time but we've always had the mobile site to switch to. – grg Jul 19 at 20:52
  • 9
    Don't forget the obnoxious triple hamburger menus! I'm astonished so many people prefer the responsive design. It wastes so much space. – curiousdannii Jul 19 at 22:50
  • 1
    Yeah, I'm still using the "mobile view" for exactly that reason. Especially when quickly moderating /questions the new view doesn't work quite well. – Jonas Wilms Jul 20 at 9:21
  • While you make fair points, I honestly don't think it's worth keeping a mobile site. If you can see a little less on the responsive site, scroll. Just slide your finger up the screen and voila! More stuff appears. It's not hard to do. Maintaining an entirely separate site to overcome this "problem" however, that is hard to do. It makes no sense. – Vincent Jul 20 at 16:06
  • 4
    @Vincent I’m not at all suggesting keeping the mobile site. I’m asking that the benefits of the mobile site be brought to the responsive site — just some well overdue CSS changes, for when we no longer have the choice. – grg Jul 20 at 16:27
  • @grg Ah. My bad. – Vincent Jul 20 at 17:11
  • @Vincent If you feel my answer could be improved to make this clearer feel free to edit. – grg Jul 20 at 17:12
  • 8
    This is especially true for code blocks. They're even narrower than the post itself, on my phone I can read only maybe 15 characters on each line of code without scrolling horizontally. And when you rotate the phone, all the text scales, so you see the same amount! – Cris Luengo Jul 20 at 22:59
  • 2
    @Cris How could I forget about landscape! Added to the answer, thanks. Code blocks also don't wrap on the responsive site, though I suspect people are more split on whether that's a good thing. – grg Jul 21 at 5:40
  • 3
    Personally I would like to see a lot less padding/margins on the desktop site, too. – TylerH Jul 21 at 16:29
  • There is a lot of wasted space on desktop as well, depending on your resolution. The sides show an awful lot of white for me by default. – Mast Jul 21 at 16:53
  • @Mast I can't say that padding is good on large screen either. Problem is, large screens have huge variety DPI that not always properly reported to system and can be changed by user settings, and browsers behind them have variety of quirks related to determining padding "this doesn't work that way because it wasn't guaranteed by spec". WHile targeting mobile users, which mostly would just browse anyway, desktop and mixed platforms users, who actually write most of the answers, get annoyed by too sparse "empty" pages and huge holes between lines of "modern", "material" view of today's fashion. – Swift Jul 22 at 6:51
  • @Mast what looks on one combination of browser, screen and modern UI design, looks awful on other. I ran onto website that was designed by someone with 4K screen. ANd that was Support Site of relatively active social network (SecondLife). On my 1080 there 1cm gaps between lines. On his they are 2mm :P While more or less fixed now, the site got still that "a lot of whitespace" look – Swift Jul 22 at 6:53

Can reducing the bandwidth of page loads please be made a higher priority?

As I posted 1.5 years ago, one of the key uses for the mobile site was so that users on slow Internet connections (dial-up, 2G, any connection less than 1 megabit/s) could access the site and have it load in reasonable time, while the full site (at least at the time) would take extremely long to load as lots of assets that occupy lots of kilobytes would have to be loaded.

To quote from that post:

Basically, mobile data providers in India offer "unlimited" data, and limit daily usage to between 1-1.5 GB per day. Beyond that, your speeds are reduced to much, much slower speeds (in my case, 64 kbps, which is just a tad faster than dial-up). You might think, you're not likely to use so much data in a day, as you can use Wi-Fi, right? Unfortunately, my relatives and (mostly) everyone living in the suburbs have disconnected their home broadband connections (DSL only) in favor of doing everything over mobile LTE data.

I maxed out my mobile data allowance quite a bit during my trip. While (I'll be honest) I was using the Internet too much sometimes, most of the time it was because I accidentally left some background process running on my laptop (which would be tethered to my phone), partially or fully depleting my allowance early in the day. The responsive site simply would not load over the slowed Internet connection. The mobile site, on the other hand, would load relatively quickly and be almost completely usable on the slow connection. I'd like to be able to access the network even if my connection ends up slowed.

As per the staff answer there:

As I said above, the mobile views are eventually going to be removed. But in so doing, we definitely do not want a regression of functionality and performance for users.

The post mentions slimming down HTML to reduce overall bandwidth consumption. However, has there been any research done on SE's end as to further assets (not only HTML, but also images, sprites, CSS, JS snippets, etc.) that can be slimmed down so they have a smaller file size? This also applies to faster connections, especially those that are limited by overall data consumption, e.g. the 1.5 GB per day limit I mention in the previous post.

Judging from the votes on an agreeing answer, I think this is important for quite a few users. To quote from there:

You don't have to maintain two sites, but you do need to work through what happens on bad connections and make sure everything is still usable. More than just users in India will thank you, this will even be a noticeable benefit to people on good solid broadband connections too!

(Yes, I know the staff answer asked for more details, but I had already left India at the time I posted that, and so couldn't provide them.)

  • 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? – Catija Jul 19 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). – Sonic the Anonymous Hedgehog Jul 19 at 20:15
  • 14
    @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. – zcoop98 Jul 19 at 20:27
  • 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. – Sebastian Simon Jul 19 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. – Sonic the Anonymous Hedgehog Jul 19 at 20:34
  • 5
    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. – Sebastian Simon Jul 19 at 20:43
  • 4
    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 – Journeyman Geek Jul 21 at 2:05
  • @JourneymanGeek Only had a 28.8k modem handy? – Sonic the Anonymous Hedgehog Jul 21 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. – Journeyman Geek Jul 21 at 2:24
  • 6
    This is a good reason to aggressively block ads! – Victor Stafusa Jul 21 at 6:39
  • @VictorStafusa If only Chrome for Android and iOS supported extensions... – TylerH Jul 21 at 16:30
  • 5
    @TylerH Firefox for Android does, hint hint, nudge nudge. – Mast Jul 21 at 16:57
  • 2
    @Mast There are also separate apps that block ads across all apps, such as Blokada, which I use. – Sonic the Anonymous Hedgehog Jul 21 at 18:09
  • @Mast Yes, I use it sometimes, but there are things/sites that Chrome mobile just handles better, unfortunately. – TylerH Jul 21 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 – JonasCz 7 hours ago

The switch to opting everyone into the responsive views by default has been long-awaited for me. It was a somewhat frustrating experience to have to scroll to the page footer and click the "full site" button (a button that is really tiny, I'll add) to switch to it anytime the website deities deemed my phone unworthy and stuck me with the mobile-web view. Thank you for this, seriously.

Your continued work with Stacks and making everything fully responsive has really paid off, as operating SE on my phone is kind of a walk in the park nowadays. The review queues, which used to be somewhat difficult to use, are easy to navigate with the mobile friendly changes you made. Various UI elements are simply easier to read in this view than the mobile-web view, not to mention the responsive site just looks better.

Despite this obviously being a very welcome change for me personally, I do appreciate that you're giving us a heads-up and slowly disabling mobile-web pages, and with a sizable amount of time between now and your timeline's end date (~5 months). Thanks for the notice!

  • 1
    What browser do you use on mobile? All the ones I am familiar with (which isn't many, granted, just Firefox, Chrome and duckduckgo browser on Android) have a very easily accessible toggle to switch to desktop sites. I haven't used that link in many years. – terdon Jul 19 at 20:45
  • @terdon I use Chrome, but awhile ago I had tried toggling on the "Request desktop site" button for MSE and the responsiveness was super hosed, presumably because I didn't use the avenue expected (clicking "Full site"). I went ahead and tried it just now, and the page was super zoomed out and looked kinda bad. I'm using a Google Pixel 3a, FWIW. – Spevacus Jul 19 at 20:52
  • 5
    Well, you just blew my mind. I always used the toggle and have simply believed that the whole "responsive" thing is crap. I just tried switching via the link in the footer and it looks so much better, I can't believe it! It had never occurred to me that there would be a difference. It's obvious in retrospect, the mobile browser will be spoofing its ID string and pretending to be a desktop, but I never knew! Thanks! – terdon Jul 19 at 20:58
  • 2
    @terdon I'm not certain, but "Request desktop site" likely does something along the lines of emulating a larger display as well. A desktop browser still receives the responsive "mobile" view if you shrink the width enough :-) – Ryan M Jul 19 at 21:26
  • @terdon every time I use that, the browser tells the site my full display resolution and so everything shows at 1440p on a 6" display. – TheWanderer Jul 19 at 23:37

Can we please stop redirecting mobile users to the mobile site immediately, rather than waiting until it's completely removed?

Currently, users who browse the site from a mobile device are redirected to the mobile view, and must click an explicit link to access the full site. Worse, the cookie that said link sets has an annoying habit of expiring every now and then, which results in mobile users being suddenly redirected back to the mobile view even if they've clicked to access the full view even earlier.

If the mobile view isn't receiving any more bug fixes during this meantime, it's important that any existing or future bugs not be shown by default to most people. I think it's important that this redirect be removed immediately, rather than delaying it for when the mobile view is removed altogether. This way, such bugs are only visible to those who explicitly access the mobile site.

  • How does this align with your other answer here? – Luuklag Jul 20 at 6:50
  • 2
    @Luuklag This is asking for the removal of the redirect, not the mobile site itself. The site should still be accessible manually in the interim period. – Sonic the Anonymous Hedgehog Jul 20 at 6:51
  • 2
    So, you are concerned about bandwith, but want people to load the large site first, before giving them the option to switch to the smaller site. I think there are way more elegant solutions here. 1. stop the cookie from expiring, 2. Post a banner on top of the mobile site, redirecting to this post, en the full site view. – Luuklag Jul 20 at 7:13
  • 2
    @Luuklag That button need only be clicked once, at which point the mobile view will load for subsequent loads. Besides, if the full site has some of its components downsized, it'll be a moot point. – Sonic the Anonymous Hedgehog Jul 20 at 7:14

Just want to add my support to this decision and thank you for it. For a long time I experienced frustration with this practice of websites serving a scaled-down, feature-limited version of their sites, sometimes obvious by the dedicated URI like m.example.com. Often I tried doing a "request desktop version" and it didn't work and I was stuck with the mobile version. But I have seen a gradual recent move to responsive design instead, just like you're doing, which is good news.

By the way, I noticed that on my mobile in landscape mode (832px X 306px) stackoverflow.com/questions shows a limited version, compared to my tabled in portrait mode (810px X 968px), without being signed in. In other words, the mobile has less horizontal information, even though it's actually wider. I suppose that's one of the issues you're going to fix with this project, as you explained, so thank you and good luck with it!

New contributor
Nagev is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 1
    You do know that there is a "full site" link in the footer of every page, right? – Luuklag Jul 21 at 9:28
  • 3
    Yes, I do. This wasn't a complaint or a request for help. Just an example of why it is better to make the "full site" the default, and a "thank you" note for doing it. Apologies if it confused or bothered anyone. – Nagev Jul 21 at 9:37
  • @Luuklag which is often inaccessible because of "ignore touch" margin on bottom of screen, e.g. in MUI +Chrome, you have to hit into 1mm spot. That margin is there to provide gesture "grip" afaik. Also hitting that link erases whatever you already wrote. By the way on screen larger than 6" there is no need for mobile view, desktop site works perfectly, resolution often is even bigger than average "office" desktop. Maybe there is portable way to determine capabilities of devices. Currently tablets, netbooks and smol phones are in same category. – Swift Jul 22 at 6:59
  • You may be referring to Wikipedia. Isn't there an (easy) workaround to avoid the "m." prefix (not a rhetorical question)? – P.Mort. - forgot Clay Shirky_q Jul 22 at 14:03
  • No, never seen that on Wikipedia, didn't even know it was mentioned there. I don't know what workaround that is, but I remember trying everything I could think of, manually changing the URI, doing "request desktop version", but it constantly redirected to the "m" version. I am not talking about stackoverflow by the way. I think I had better luck with Edge on my tablet, but I digress... – Nagev Jul 23 at 21:58

The current responsive view works fine on my own cellphone, but its got a pretty nice screen.

What screen resolutions are y'all supporting now that there's no dedicated mobile view (which was pretty good on potato grade screens) and what'll you be testing against?

  • 4
    We do our best to support down to 320px, which is the original iPhone SE—my favorite device of all time. Will we support that in n years? Hard to say. – Aaron Shekey yesterday

What about http://stackexchange.com (the “Hot Network Questions”)? Its lack of mobile/responsive view is the only reason I still have the ancient Stack Exchange mobile app installed.

For reference, here’s what that page looks like for me:

Cropped Pixel 3 screenshot of stackexchange.com

… clearly not usable.

  • 1
    What would you like to use that page for? – Luuklag 14 hours ago
  • @Luuklag I don’t understand the question. – Konrad Rudolph 14 hours ago
  • 1
    You say you can't use the page, but to me its a perfectly clear page, even when on mobile without its design being responsive. So what would need to change? – Luuklag 14 hours ago
  • 2
    @Luuklag Just look at the screenshot: the text is unusably small. You can barely read it, or tap the links. In fact, sometimes the font is slightly bigger (so that might be why it seems usable to you). Try going to another page — at least for me, the font size seemingly-randomly switches between different pages. – Konrad Rudolph 14 hours ago

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .