To me, it looks like a work of incompetent developers led by incompetent technical managers upon requirements of clueless and ignorant product managers.
GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick. Probably the best one of the bunch (Azure, AWS, Oracle, OVH, ...).
I guess it might speak to a solid, if somewhat slow, API.
https://www.hashicorp.com/resources/google-provider-new-terr...
Yep, already covered that under incompetence and cluelessness.
> GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick. Probably the best one of the bunch (Azure, AWS, Oracle, OVH, ...).
In that case, I would assume that backend team indeed consist of competent people, as opposed to web team. But TFA was about front end experience which is abysmal.
That's still incompetence. That counts as incompetence, too.
"This restaurant is filthy and full of bugs, but that's OK, because they're take-out only, so they're not optimizing for the same thing the average sit-down restaurant is. Sure, that place is disgusting, but the food in box still tasted pretty good..."
"This restaurant only has one table and 1 chair with a broken leg and gum stuck to the seat but that's ok because they're take-out only"
They managed to make a mess worse than JEE, the native layer took 10 years to finally use Android Modules, they keep fixing the header files, still don't have proper C++ bindings and force everyone to write JNI boilerplate by hand.
Microsoft did nail windows phone apis, 10 freaking years ago, too bad it didn't survive.
By now, it's too late to rewrite the whole thing from scratch, hence a new OS https://en.wikipedia.org/wiki/Google_Fuchsia
Others point this out, but Google just has no incentives to improve this UX. Think about who makes the decisions to use Google cloud and what criteria they are using.
The snappiness of the gcp ui is not likely to be near the top of their list
B2 large business is different than b2c or b2 small business
It's all about who is making the decisions
It indicates that speed is not a priority for management.
I know it's popular to shit on them, but Facebook (and to an extent Instagram). Despite all the expansion, and third part integrations, at least for me (13" MBP 2017, i7/16GB):
1. Everything "feels" like Facebook. 2. It's relatively quick. I can hop from posts, to events, no notifications.
I hardly use Facebook, except for marketplace, so I can't say for sure if users find the interface confusing, but the UI at the very least is well done.
Give me a cluttered UI that has everything available any day.
The situation with primevideo.com is strange, but it seems to have something to do with non-US territories?
Amazon's site works pretty well. Their product range is quite a mess to navigate but I've never been annoyed much by their front end. It seems pretty well engineered, eg. [1]
[1] https://bjk5.com/post/44698559168/breaking-down-amazons-mega...
I'd really like it if they added a way to thumb between commits in one click without page loads, kinda like flipping through pages of a book
* say you're on page A
* navigate to page B
* navigate to page C
* click your browser's back button, hoping to be back at page B
* the github UI screws up and keeps you on the same page while changing the URL in the address bar
* so you click back again
* now your on page A, completely skipping page B
* clicking forward takes you back to C
Additionally, GitHub is insanely slow. This page, for example, takes 3 seconds to load: https://github.com/Boemska/create-sas-app/commit/85224fe6622...
Couple broken history back/forward navigation with long page load times and GitHub is easily one of the most frustrating web sites to use.
Don't get me wrong, I'm not arguing that GitHub doesn't have value -- it most certainly does -- but that doesn't excuse bugginess and absurdly long page load times. If they fixed these problems it would be 100% awesome.
* say you're on page A, an open pull request
* merge the pull request
* switch to a different site entirely
* go back to github's page A
* notice how it shows the pull request as if it wasn't merged yet
* refresh the page and see the status switch to merged
I'm using Firefox and I've never tried reproducing this on Chromium.
Back and forward work great on GitHub. My mouse has additional buttons for these.
My machine: Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz, 128 GB RAM on Ubuntu Linux 20.04.
> My mouse has additional buttons for these.
Similar. As a sibling post mentions, the history hijacking does some nasty stuff -- unless you're lucky or something, I guess.
target's item pages are really good right now. I love the information density and layout on their site, which to me is suggestive of thoughtful human-oriented design rather than amazon's (highly effective) a/b test shit shoveling.
amazon has "ship-it" UI standards and a lot of variance in page section order (could be a/b testing, or just discrete developer teams).
they have lots of really interesting ideas scattered around for how they can reach customers with unique contextual information, but I have a hard time with how dynamic the layout is and they also don't know how to make good hero pages. too many over-compressed image banners and image tables.
amazon and github both have crappy search which is kind of interesting to me. amazon sort basically doesn't work either, for price or for rating. not sure why.
/ecommerce rant lol
which web frontend is good ? (except HN)
I'm not far from imagining a non so distant distopic future where everyone just gets used to slow, laggy, clunky websites and applications. Oh... wait...
1) tracked from the beginning so it is drained from the system merge by merge
2) architected in at the design level and not applied as a spell.
I really like what the rust team is doing with tracking rustc compilation times. Another reason that integration tests are the best tests.
Who says that if they experienced the software the same as a normal user, they would automatically improve its performance?
This may apply for parts of open source development, where developers work on stuff for their own use. But even they may have other priorities.
And as a commercial developer, your backlog is constantly full. You may have some leeway to choose what you work on, but there is absolutely no guarantee it will be performance, just because you personally experience bad performance.
The way to get performance improvements is to make it a business priority to measure and improve performance.
And for that, it is absolutely not necessary for developers to be slower in everything they do, just so they can experience their software's performance "realistically".
If a company has that information and doesn’t care, that’s one thing. There’s more than a handful of companies that just don’t have the information to even know if they should care.
I think most people would agree that we should use tooling to make it so that developers are aware of their blind spots, such as supporting systems with lower resources or a more inconsistent network. The Netflix blog had a nice post that included a tool they used to observe the UX under certain failure cases, which is a nice example of this [0].
[0] https://netflixtechblog.com/keeping-netflix-reliable-using-p...
The move to, "let's show them a pretty G spinner to compensate, because research shows that'll make them think it's fast" irks me to no end.
Learned this the hard way. Made an editor, everyone loved it. Added features, people loved it. Kept adding features...then it was called slow, bloated etc.
Everything seemed fine on my new-at-the-time iMac.
Went into a conference room where we had one of the first Intel MacBook Pros...there were portions of the editor where you could literally see things being redrawn. A night of optimizations later, performance was restored.
More realistically, they're serving up the assets from a web server on their machine. Which means that network I/O time is effectively nil.
When the PM views it with ideal network conditions they assume it's more than ready. At this point their focus is on shipping sooner so the next thing can be worked on. The devs can never talk them back. Users then complain on Twitter about the crappy perf.
This is a process and cultural failure too. The perf can be quantified and tracked to some extent. Even proxy metrics like the growth of assets over time can help.
Cultural events like poor handling of weekly demo days can create undue pressure on shipping poor implementations. Someone implements a great idea badly, it catches management attention (or helps the sales team), and next Monday it gets released. Over time this behavior can hurt customers and it always frustrates internal efforts to do the right things for perf.
The problem isn't people don't know. The problem is the software is drowning in layers of complexity and abstraction, and it's all in JavaScript not an optimized native language.
I would not be surprised if a lot of these problems could be traced back to developers having above-average network connections and super beefy computers. Combine that with fresh or minimal installs while testing the software, without lots of data that accumulated over month or years of use and in consequence they experience their products as super snappy.
Summary: they maybe never experience their products as a normal user would.