I’d highly suggest removing the custom scrolling / scroll bar logic with your hamburger menu on mobile (and probably redesigning the site to avoid the hamburger menu all together — it’s an anti-pattern). The non-standard nature means I lose all the natural momentum scrolling I get on iOS by default, the scroll bars can’t be moved like I’m expecting, and it makes the whole site feel janky and not usable.

What’s the alternative to a hamburger menu that you would recommend for mobile? It’s a very common ux. For example, target, Walmart, and amazon all have a hamburger menu on mobile.

If you notice no Apple app has a hamburger menu, nor does their website on mobile. Hamburger menus hide all the details, with no predictability as to what might be there or that you should need to click on it (the icon tells you nothing). There’s plenty written out there about this issue.

It’s not clear to me exactly what one might want out of a mobile version of this site given the information overload. That would be my first consideration versus assuming it should be 1:1 with just a slightly different layout.

But if it is to contain the same information, I’d suggest it would be better to have a dedicated page that organizes all the different possible settings by topic or module, or even by “beginner to advanced” tuning. Such a directory can then easily be understood because to get there it would have a primary hero labeled button/link telling you what you’re about to see (the current page is mostly videos and some pretext for the site but all the actual value is hidden by the hamburger menu). You can always flip back to that, knowing that the browser will retain the scrolling history to go back to your previous place (which a hamburger menu doesn’t necessarily do).

Another style would be to have a chapter type layout where you can advance along some existing narrative (like beginner to advanced), much like FreeBSD documentation does (from memory).

All of this could also benefit from a search at the top that would let you random access what you’re looking for.

As someone else suggested here, another style would be to think about recommended configurations for typical usage patterns.. on VMs with X type workload vs Y, letting you directly lookup what you want in a hierarchically organized layout on a flat single page, or using drop downs/segmented controls to configure from the set of possible options. Then you could just punch in your actual needs and out would pop recommendations that hopefully had some insight and further guidance to back them up.

Just some ideas from the top of my head. The main principal behind all of this is to avoid sticking everything where you don’t know where to put it in a hamburger menu, and instead making your information architecture explicit and predictable.

What do you call this thing on the upper left at apple.com? https://imgur.com/a/pm3kOUq

Looks like a hamburger to me. It opens a menu when you click on it.

Feeling shame for my own company! Wow! It’s marketing that runs that versus the actual designers (to my knowledge), and I wish they hadn’t resorted to that.

Heh. Thanks for the honesty. I can probably get on board with an anti-hamburger movement, but consistency matters.

Thanks for all the feedback. We will definitely take this into account for future reviews of the UI.

I think you can put maybe 2 (3 in extreme cases) links at the top of a mobile page. That's it. Which most sites use for a call to action. (buy, call us, specialty forms, etc...)

Everything else _has_ to be somewhere. Doesn't it? So, behind a menu seems like the only consistent and logical place.

I feel like your argument is for "apps" not "websites".

The hamburger itself isn’t so bad here as the horribly janky and broken custom scrolling, which is broken on desktop as well.

Why not make preset configurations for various RDS machine types. 90% of users running on AWS RDS repeating same steps to get same results.

If it would be this straightforward, why doesn't Postgres do this directly?

There is the misconception that tuning Postgres is just about the memory and CPUs. It's also a lot about the usage patterns, whether you use or not a connection pooler in front (note: you should), about your OLTP-ish or OLAP-ish pattern, about the disk speed, disk technology, types of queries that you do.... it's, unfortunately, not simple at all.

And the problem is that it's easy to think "oh, even if I get it close to right and maybe improve performance by 20% instead of 50%, that's still ok". But the problem is that a bad tuning may decrease your performance significantly. So it's a matter not to take it lightly.

Amazing work, I wish every service was covered like this!

Some feedback/things I'd like to see (or not see):

- Make the Comments section collapsible, right now it takes 1/4 of the screen

- Filtering by categories is kinda confusing, since filters affect both the left sidebar as well as the main view I'd expect the filtering UI to sit on top of both

- Better visibility/categorization for parameters that can only be set via command line

out of curiousity what did you use to make the site? Reminds me of Rust's mdbook.

It's custom made.