Atlassian is one of those places that I just can't believe has gotten so widely used. Every single thing I've used that is an Atlassian product drives me nuts. I really don't understand how anyone at any point looked at Jira or Confluence or anything Atlassian puts out and said "yep, this is the best version of this thing I've seen, sign me up". I've been using JIRA for years now, and it never gets any easier or better. I can never find what I want, I can never remember how to do things. I have to assume it's just me since everyone uses these things though.
Because UI snappiness is not the only thing that matters.
One example: Jira integrates with _everything_. It really matters that you can create tickets from Slack, send email to the management when epics progress, see Github pull requests linked to tickets, and so on.
What's a better alternative to Jira? I've tried Trello and Asana. Trello is nice for personal stuff and small projects but it doesn't work well for bigger projects and teams. Asana has an infuriatingly unintuitive interface but that might just be my personal preference.
JIRA is used because it's been around a long time and until recently the competition was even worse. It's also gotten slower over time in my experience.
I guess I am older but pre jira things were so much worse that yeah... best version of this thing I’ve seen. Not that I love it but it’s functional and not an Oracle form or some ugly crud tool cookie cut for a process different than my teams.
As far as I understand it, it's because Jira is not made for developers. It's made for SCRUM and Project Managers that need fancy graphs and lots and lots of fields and processes. It's their reason for existence, so they have every incentive to make it so that developers do not understand.
That'd make complete sense. None of their products support Markdown really well. Each has its own weird way of handling code snippets. So many other tools support three backticks and boom, you're in a code-block.
Doing a small startup I forget about this nonsense sometimes. I could make more at a big company but when I read this I am glad to be doing what I am doing.
You’re probably using it wrong. Click your mouse on a non-interactive UI component and press “.”
Now you can find everything you want. You’re welcome.
I agree jira is terrible. Other bug trackers I’ve used are somehow worse. Does anyone have anything they can recommend with a straight face? (Github issues are missing too many features for me. Jira’s sql-style language is just too useful.)
I'm a jira power-user and your answer highlights my two main problems with it.
> Click your mouse on a non-interactive UI component
80% of the UI is interactive, but not marked as such. Have fun finding a 10px strip that won't turn into an edit workflow when clicked!
> Click your mouse on a non-interactive UI component and press “.”
Even using the keybindings (seriously everyone, hit "?" and look through them) events are lost. Want to create a subtask? It's not `.sub<enter>`, it's actually `.sub^H^Hsub^H^H^Hsub<enter><wait><tab><tab><give up and use mouse to focus a field, because it arbitrarily unfocuses fields>Title Of My Task<use mouse to find the submit button>`
They've done so much work to make it a quick UX but it's all for nothing when it randomly eats keystrokes and defocuses constantly. Maybe some of our add-ons are at fault, I'm interested in hearing if there are jira installs that aren't like mine.
AWS console is by far the slowest thing on my machine, web based or not.
I don’t use GCP or many other Google products though. I’m kind of shocked google managed to ship a framework slower than GWT. I always assumed anyone that used it for a few seconds would say “well, that was a fundamentally bad idea”, and not double down on whatever the heck Google was thinking.
That's what happens when you employ over-enthusiastic developers obsessed with their Javascript-framework-legacy. Things worked fast when HTML was the UI, and the logic was in the server.
It doesn't really matter how fast an uncached page load is for Facebook. Why would they optimize it? A user will only see that a few times a decade when they get a new computer. It would be like trying to shave seconds off of a native app install time.
User to Dev: the memory usage is excessive. Dev with 256 GB RAM to User: WFM
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.
I agree. I have a second, crummy old laptop for just this reason. I can't quite bring myself to develop on an underpowered machine, but it is useful to have one as a reference. Also, my phone is old because I'm a cheapskate, so that helps tremendously with assessing mobile performance.
>> I agree. I have a second, crummy old laptop for just this reason.
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.
Why is everyone assuming that just because someone works for Google has to be competent? Solving algorithmic puzzles is not an indicator or actual technical skills.
To me, it looks like a work of incompetent developers led by incompetent technical managers upon requirements of clueless and ignorant product managers.
Cloud service providers aren't really optimizing for the same thing that the average website is optimizing for. They're attempting to maximize their velocity, maximize their API stability, and make programmatic usage of their system as easy as possible.
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, ...).
> Cloud service providers aren't really optimizing for the same thing that the average website is optimizing for. They're attempting to maximize their velocity, maximize their API stability, and make programmatic usage of their system as easy as possible.
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.
They had some big outages over the last year. I’m therefore still skeptical to bet on them from a “backend” operations reliability standpoint also. To be fair I’m not sure they are doing worse than AWS though when looking into details. I’m thinking recent AWS Kinesis us-east issue - move fast and break things? Maybe uptime is more important than a gazillion new “feature” services. I also prefer good terraform provider stewardship over any “fancy” new cloudformation CDK or “beautiful” GUI actually. It’s complicated.
> Cloud service providers aren't really optimizing for the same thing that the average website is optimizing for. (snip) GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick.
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..."
I thought Terraform provider was developed/maintained by Hashicorp, not Google. Are Google employees actively involved? I also did encounter annoying issues (which have slowly been getting better though).
I guess it might speak to a solid, if somewhat slow, API.
Yeah they've got a nifty tool called Magic Modules that partially auto-generates the Terraform Provider (along with Ansible and InSpec) from the GCP API:
The puzzles make sure you can write the O(good) algorithm, knowing the coefficients is a question of experience and knowledge of the shoulders your code stands on.
I used to think Google hires only "top" developers. Lately I think they mostly hire average or below-average people which resulted in products of average or below-average quality.
I think by attributing it do incompetence you're missing the incentives problem.
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
Coding for Android has taught me that is definitely not the case.
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.
The Android base wasn't written by Google. Google bought the company that made Android 2 years after it was written. That's a lot of time to create a base system and a lot of time to create cruft.
Android is really the worst platform for developers. Context? Let's make a god object, and also create application context and activity context, and screw liskov substitution principle. Also create a library to fix all our bugs in all versions of the platform, but also have a shit ton of bugs.
Microsoft did nail windows phone apis, 10 freaking years ago, too bad it didn't survive.
I suspect there's something in that comment on above-average network connections - the people working on Google Cloud's UI are going to be doing so from Google networks, or over a Google VPN, which means they'll be seeing much lower latency to your average person who has to be bounced around their ISP network and then across a couple of peering providers before getting there.
This stuff is dead slow even on a fast machine with fast connections.
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.
There can be some more nuance to this. The devs can often see the problems, but know more optimization is needed. They've done everything to implement what a PM asked.
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.
This happens with web design a lot. I have a great monitor with a 1080p budget monitor on the side. It makes a huge difference when thinking about shadows, UI changes, etc which are almost invisible on the 1080p sometimes. I test my sites on both.
This is something that really concerns me about the new M1 based Macbooks. We as developers in the first world are very likely to be the first ones getting these, and this will make the gap with the average end user which usually does not have a mac a lot worse.
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...
As a developer you should 1) have the fastest possible code / test cycle - i.e. it's worth overpaying for faster machines 2) treat performance as a feature and formally measure it across configurations
I've worked for many companies, small and large, corporate and startups. None of them had performance as a priority, or even considered at the product level. Any minimal performance optimization or win we had was because a developer cared enough for it.... but maybe I'm the only one and just had bad luck with the product managers/owners I had.
I have seen the same basic cycle, management says don't focus on perf, just "knock out" (I despise this lingo) the features. They have this overconfidence, but flop on the next release and patronize the dev team about perf.
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.
We definitely promote performance as a primary (and a half) concern. Mainly because the alternative is throwing more money at servers and/or dealing with disgruntled customers. I wish we dedicated more resources to it but we also don't ignore it.
Oh! yes... certainly that was mi experience too. I was referring to frontend... where you won't pay for the performance, but your users will (by having to upgrade their compures and/or just suffering it)
The only companies I have worked for that really cared for performance were betting companies, because speed is money in that sector (esp. in live betting).
I don't think it is just that. Google is just shockingly bad at web frontend. All their properties are terrible, except maybe Youtube which I find quite agreeable. For example I just made a search on google.com, the most popular website in the world, and it can't even fit the content into this reasonably sized window [1].
As someone who regularly uses other e-commerce front ends, I find Amazon to be quite cluttered and messy. Also it‘s surprisingly difficult to quickly find a specific product.
I felt the same way with Amazon. Before then it was easy to navigate and finding the product that I want to buy. Now, I couldn't navigate it well like I did in the past. And asian-sounding names products took over first few pages of result which made it difficult to filter out. And they are crap quality products. It is easily to tell which products is made in. Hint the brand name is all capitalized.
One pet peeve I have is getting to prime video. They own primevideo.com, but it just tells you to watch on Amazon. It's also the first result when you search (on google) for amazon prime video. There's no direct url to get it (afaik).
PrimeVideo.com is the website (in addition to apps on mobile and living room devices like TVs and consoles) where customers outside of the US, UK, Germany, and Japan can watch Prime Video. In the aforementioned four countries, customers can watch Prime Video directly on their amazon.* retail website instead.
Really? Criticizing Google's frontends but praising GitHub and Amazon? If I had to pick a large tech company with a bad frontend Amazon would be top of the list. GitHub is not great either. I guess this kind of thing is just subjective though.
For one, they're using some sort of link / browser history hijacking (something like https://github.com/turbolinks/turbolinks, IIRC) which is buggy, for example:
* 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
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.
Github's site is really fast. Many of the pages it displays are dense with information and I think it displays everything well, for example viewing diffs in Github is very good, it smartly wraps all the text so you can view everything on the screen and everything loads fast. Try comparing it to Bitbucket's diff view, which can't wrap text amongst other things. It's light years better in comparison. It looks good at any window width with little wasted whitespace.
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]
Amazon is about the last site I'd use as an example of a good UX. They've clearly been working on making it better, as the account drop-down has shrunk, but the amount of items on this screen is such that it really should have its own search to navigate it. A simple thing like buying a new gift card for someone is surprisingly clunky.
github is great, both web and mobile (especially mobile). and their new homepage is great too.
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.
>Which large companies aren't bad at web frontend?
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.
Weirdly I'm observing the same behaviour as parent in Safari in macOS, and it really is baffling as the basic google.com website used to be pretty well & sensibly optimised.
uh, I'm using chrome on windows on a 2560x1440 monitor and have a horizontal scroll on google as well. I actually have power toy'd my windows to a 60/40 split because of this and other websites unable to display properly with 50% width, which I really don't feel should be a huge ask considering the website works fine on a phone.
Oh I'm sorry that Chrome, Google's own browser, is not suitable for viewing their own website. I guess it must be detecting that I am using Linux and breaking on purpose?
Youtube UI/UX is horrible, try moving items in a long playlist, it takes forever to drag scrolling. Imagine a search engine company that doesn't have a quick search inside a playlist. And you need browser extensions like Youtube HD to fix several issues. It has been this way for years.
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".
I’m unsure why the original idea seems silly, when it simply states a possible reason for this problem today. Giving a developer observability is the first step, that’s what they are pointing out —- some ways developers interface with features don’t include information that could deliver a higher value feature. A company can choose whether to deliver that higher quality or not with that information, ignorance removes that choice.
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].
> 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
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.
I use this UI all day, every day on a Ryzen 3900 with 12 cores, 24 threads, 32GB RAM, 300Mbps connection. It's always extremely slow, takes up obscene amounts of CPU and RAM. It's mind-boggling how they think, "this is ok".
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.
Here's a couple of tabs, one is a dashboard taking up 1.5GB RAM, the other is a k8s deployment page, taking up 1GB. It seems any tab takes up a ton of RAM. CPU also locks up completely in those tabs routinely. The chance that occurs correlates with how long a tab is open.
Yikes, didn't realize they had the indecency to drink their own kool-aid. Angular, really? No wonder! Come to think of it, it's maybe been around a year since I last saw one of those tell-tale "page finishes loading to a blank page for 20 seconds before finally rendering" Angular sites
I guess stuff like amp is good only to preach others. This garbage has been slow for ages. Also they keep throwing links to new stuff in their side bar without any rhyme or rhythm making navigation as annoying as possible.
Google's UI's in general are shockingly slow. I don't understand why my Google Drive and Gmail have input lag and choppy animations on my 5 year old xps13, it's not that hard to make navigating a filesystem or list of emails fast. Actually I do understand, it's because they want everything they build to be made in a massive javascript framework with shared components, which looks nice but runs like garbage on anything not modern.
It doesn't look nice. It looks a lot worse than 10-years ago. But it is more compatible with i18n/l10n and accessibility plugins and compatibile components across a dozen chat apps
Keep seems to have gotten slower and slower over the years too - the web version is practically unusable on mobile, not just because the UI design isn't responsive (!), but because it's so painfully slow.
Boggles the mind how Google web apps have performance issues like this.
Wait, you think https://mail.google.com/mail/mu, the mobile web version aka "superpudu" is slow? Can you tell me your device? It paints itself in only 400ms on my iphone. I actually prefer it over the app because it's so fast.
My comments were about Google Keep, not Gmail, though I do actually find the Gmail web app pretty slow too - it takes several seconds to send an email.
I didn't know there was some kind of secret mobile Web version of Gmail - I get a blank white page when I open your link on mobile tho (using Brave)?
Oh, I totally scanned passed "Keep" in your comment. The mobile web version of that does indeed seem a bit rough. It's been a while since I worked at Google but when I did, Keep was a one-engineer project so the amazing thing is it exists at all.
FYI you can still switch to the old design. When the fake loading screen (https://smitop.com/post/gmail-s-fake-loading-indicator/) is loading, click on the bottom on "Prefer old design". Then you can set that as default. It is an absolute must for me given how fast it is.
Note that objectively speaking the basic HTML gmail is slower in every aspect, except for the initial page load. Everything but the initial page load is slower. The main web app has extensive latency-hiding features that are key to Gmail's overall performance story. The basic HTML UI has none of these features. Every action in the basic UI takes half a second or more because it's a server round trip.
Example: load the basic HTML and enter a thread then return to the thread list. Returning to the thread list takes about 1 second. In the full gmail return to thread list takes no remote time, only local event handler CPU time, it's almost instantaneous.
Example 2: Open a thread in the basic UI and use "newer" or "older" to navigate to other threads. Every click takes ~1s. In the full Gmail UI navigate to adjacent thread takes almost no time, because the app pre-loads these threads in anticipation of you visiting them.
TL;DR the basic HTML gmail is good if your device is severely resource-poor and you just need to see if you have mail. For every other purpose it's worse.
The original design was done with function first and form received almost no attention which was typical for Google for a long time.
As design overall started to become more relevant in products Google started to push out their redesigns but it was done with form instead of function as the focus. They've never really re-designed anything to be better - their updates have usually made the product worse.
But without a strong design leader it's death by a thousand cuts because there are so many layers of management to getting anything done.
Yeah the Gmail UI has become absolute garbage lately.
The fact that i need to see a cute-dystopian loading animation for 2 seconds each time i reload the page is incredible.
Send plain HTML, then make JS take over after loading like most modern frameworks can do.
.. yes i really have to ditch Google ..
On a sidenote YT has also become a dystopian addiction machine - years ago you could easily curate what you saw, feeds, channels etc, now everything is controlled by the "google god skinner box algo" just like i feel Gmail is headed towards with all kinds of automated tools.
It still has the pseudo-vi key bindings that you can turn on in settings. I've been really satisfied with how fast it is to do anything because of the key commands + relatively quick response and autocomplete (except click on links because I have to turn off Vimium for Gmail).
The Inbox by Gmail version loaded instantly, had inline emails and loads of other cool features that got half-arsed forced into the older gmail codebase.
Google made a superior replacement to the current gmail experience and then just threw it away like it never existed.
I noticed this for last few years. Google stuffs been increasingly adding much JS in their stuff every year and that bogging down my system. Even loading Google Drive took average 6 second to fully load whereas it was about 3 seconds last year. YouTube is not quick to load anymore like it was before. And this is all in Chrome and other Chromium-based browsers.
It's all slow because it can be. People will put up with it because they have a virtual monopoly on all these free cloud services. What are people going to do, go back to saving locally and use something like LibreOffice?
The medium is the message. In some domains, slow and clunky feels like gravitas and reliability. Enterprise software. Enterprise recruiting software. AWS has a pretty slow, and clunky dashboard. AdSense is clunky. A lot of the biggest companies' flagship apps have a very bland "bureaucratic" look and feel. You may find it hard to believe, but Zuck wanted facebook to look like a government database for a long time, where you type in someone's name and see details about them. Engineers will probably scoff at these notions, because it seems to suggest that underlying their "real" engineering concerns, are implicit aesthetics they would neither say they agree with nor be aware of, but it's real. If you're deep in the medium, maybe you don't even see it as a medium anymore, and you don't realize its quirks.
Slow and clunky is also unreliable, it's did it go through?, did I click on that?Is it loading, or is my connection having troubles? Is the browser again?
Some of the ugliest Gov and Gov adjacent pages (e.g. tax collectors, some DMVs) are fast and prompt zero second guessing. They just work.
The slow and clunky I referenced don't have "loading semantics" issues, they all show loaders, action statuses, and many indicate connectivity and save progress for multipage sagas. But you are right that slow and clunky can be unreliable, but so can slick and snappy. Tho, neither of them have to be. In some domains, slick and snappy can feel insubstantial and off-key. It's interesting that the pages you reference are "consumer" products, not enterprise, so that's inline with how I think this goes. I think basically we're talking about orthogonal kinds of slow and clunky, yours is more the engineering focus of how it works, and mine is, like I said in the parent comment, about the aesthetics and the medium in a domain.
I have never seen anyone in government or big corporate (including management and HR) put down a site for being too fast to load or react. I've seen plenty of instances where they've railed on one for being sluggish or unresponsive...certainly aesthetics are important for a subset of enterprise users (namely those who have to drink/act like they've drunk the kool-aid), but most folks aren't idiots and can definitely feel when something is objectively slow.
I get if you feel that aesthetics are a deliberate adoption only of those kool aid drinkers and "idiots", but that viewpoint probably just contributes to how you can't see that aesthetics and medium are a thing, that people expect but are unaware of. Because you wouldn't want to see yourself as a kool aid drinker or idiot, right. Meaning you're blind to it's effects, which I'm not saying makes you say idiot. This dynamic happens everywhere. It's similar to how people choose familiarity, over what "objectively" is better. What you said matches what I'm saying about it. People can tell when something is slow and clunky, or slick and snappy, and while they may praise, or rail, it doesn't mean they will think slick and snappy works better, or feel more comfortable using it. This is why those big softwares don't violate your implicit expectations that they are slow and clunky.
Another thing is just because people complain (about their enterprise software, or country, or house, or romantic partner) does not mean they would switch. And just because they praise your slick and snappy startup enterprise app doesn't mean it will solve their problem better, doesn't mean they'll feel more comfortable using it, and doesn't mean they'll buy it.
I think my point emphasized aesthetics too much to the detriment of the main argument, so let me rephrase: aesthetics are also important if you want a of majority enterprise users to enjoy using your product (ask anyone who has had to deal with SAP). There will always be a few who love the brutalist or "power user" UI, but I think we're in agreement that visual appearance does matter.
With all that out of the way, the example I _wanted_ to raise above (but neglected to, apologies) with the "kool-aid" drinkers is that corporate users are absolutely aware of how fast and responsive something is _in addition_ to how it looks. I think many folks have been in a screen share or training session where the presenter has to awkwardly wait for an application they're "selling" to load or respond to input. Is the presenter oblivious to this latency? I'd say they are even more aware given the audience, if not flustered. That was the thrust of "people are not idiots".
WRT why people continue to use this software, I think you underestimate the impact of top-level purchasing/procurement and the captive enterprise audience. Those making purchasing decisions are less likely to use software after the sales demo and thus are not exposed to any UX or latency issues. Again. there is no idiocy or mal-intent here either, it's just an artifact of how bigcos operate.
I think I get what you're saying. So kool-aiders are the ones who, true believers or not, need to sing praises of software foisted upon them as a captive enterprise audience by an inefficient top-level purchasing/procurement system. So, people are not idiots, means that most people, even some non-zealot kool-aiders see things don't work and could be better in such situations.
I totally agree. I think what happened with us is, as is the case in most of these things, we were talking about orthogonal or parallel things.
I'm not assuming your agreement with my belief that aesthetic, even "brutalist" or "slow and clunky", will connote quality to a certain subset of users, enterprise being one example. I think your might have took it to mean I was saying "haha, therefore I think enterprise users are idiots." Which is not what I meant, but I get how you could see that. I don't think an aesthetic preference, even one which may on the face of it seem maladaptive, means people are idiots. I don't think it's a maladaptive preference, it's a natural thing, and there's reasons for it that work. I suppose it's a form of stereotyping, that allows people to form quick judgments from limited information.
And I'm aware of the research that says that a "good UI" can hide other problems, and be easier to use. So on the face of it, that would seem to say software with "slick and snappy" UX will be more prevalent, or at least be completely wiping the floor with the "slow and clunky" competition. But it's not -- at least not at the high end of the market that I care about. So this is an idea I have about that.
Actually, my criticism, if it was with any group, was with the developers who want the new shiny above all else, and seem to fail to see the practical benefits of practices done by bigcos, even when the success of those products is right in front of them. I think such blindness is stupid. But the developers are not stupid.
My back story is I, even when I wasn't someone who valued new and shiny above all else, once thought, "all I need to do is consumer-productize" enterprise apps and everyone will love them. But that's not all that's required. So I don't underestimate the sales process, I'm just coming at it from the point of view that aesthetics are a component of that decision, albeit an implicit and probably by necessity unspoken one (otherwise: "This UI looks too fancy and the app is too fast. We can't trust these guys, but the old-reliable, clunky and 80s-looking app we've been buying for 20 years just works great for what it is." ~~ but, hey, maybe people really do say that!).
I think you can sell the unfamiliar (product, narrative) using the familiar vehicle (product, narrative, aesthetic). So if you want to do something new, the best way is to serve it to people in a package they already like and are familiar with. I believe that as a general principle. But in this more specific case we're talking about here, I just think I see the importance of aesthetics and many other people miss it.
I could be wrong...I was wrong about what's required to develop enterprise apps, but I guess I see it as something (one of my hypothesis) that should guide how I develop software. Because I figure if I do that, it will save me worrying about stuff that doesn't matter (the new shiny slick and snappy), and I can concentrate on what matters (building what they want), and maybe even hack their psychology a bit (make it look like the old style apps they are already familiar with). It's OK if you think differently about it. It's my idea after all, I was just hoping to convince you a bit about it, not to convince myself more through consensus...I don't need that, but because I like the idea that maybe you can benefit from something I figured out, and I can "invite you into the cool club" of people in the know about this secret...
This is definitely not a joke, but yours is, right. There's plenty of ways to end up with slow and clunky without "writing while loops" haha... This is how i really feel it is.
I don’t know if I agree with you, but I think an example of what you’re describing is the TurboTax web UI. You’re shown multiple “loading screens” where things like “We’re looking everything over!” are said to the user. The user is given the impression that some kind of heavy lifting is happening, when that probably isn’t the case. For Intuit, it’s a marketing thing.
This is one of the first features a new GCE user is likely to use (if they're exploring the UI and haven't yet started using the CLI) - and it's broken out of the box. Amazing.
It's amateur hour over there when it comes to frontend development - it's not a web app where cross-platform/cross-browser testing takes place, it's a Chrome app.
I don't if this true but I have realized whenever I try to access google apps in firefox they are slow and sometimes breakdown but when I try to do it in chrome they just work fine.
Like I was trying to submit some work using google classroom on firefox it wasn't letting me upload the work but when I did it in chrome it just worked well
The conspiracy theorist in me wants to believe that this is not incompetence, but sabotage. Everyone uses Google products; if they work fast in chrome and slow on firefox, people will blame Firefox, not Google. And therefore will eventually switch to Chrome.
It's not intentional sabotage; it's positive feedback loops.
Using Chrome, your tooling experience developing software at Google is, maybe, 1% faster. Some of that is core (TBH, FF's engine is old and creaky and webkit-derived browsers out-perform it on all kinds of metrics, though FF has significantly closed the gap). Some of it is that teams develop for Chrome first, because it's the first browser shortcut available. Plus, Chrome has all kinds of extensions built in-house at Google to make your life easier, and those have to be rewritten from scratch if someone wants them for FF also.
So now when you're doing UI development and testing it, your first testbed is always Chrome, because it's what you're using as a developer. So bugs always get seen first in Chrome, and only seen in FF if your team has acceptance testing requirements or you happen to have a team member who uses FF. So the gap widens: now using Chrome in Google is, maybe, a 5% better experience, because you're that much less likely to hit bugs the developing team hasn't hit yet. And th positive feedback loop continues.
The only way I'm aware of to stop this is to force teams to put half their engineers on using FF as their primary browser, and I've never seen a team willing to do so.
FF has die-hard supporters inside Google, but few are so die-hard they're willing to intentionally slow down their own development velocity by using a less-supported browser. Google's too competitive to incentivize that.
(Note: this applies to bugs that crop up between OS platforms also, because that happens---sometimes, the details of Chrome on MacOS surface a bug that never shows up on Linux. Some teams do require one engineer at least to use Mac, because the MacOS userbase is big enough that there's financial incentive to not break it. FF has like 5% market share; there's no such incentive there).
Because (a) most of them predate the standardization of WebExtensions and (b) that API still isn't standardized enough to make building against it as cheap as building a chrome specific extension.
Feature-chasing. Firefox compatibility is a feature that nets them something like 5% of potential users. When they crunch the numbers, that's fewer than the 3 to 5 corporations they can get into their scope of market if they add the table-stakes features those corps require to consider GCP.
And Google's take on it is that a FF user can always switch to Chrome, since Chrome runs on all OSs that support FF.
FF support is, in theory, part of the acceptance criteria for new development, but it's not on the blocking list so it's not really part of the acceptance criteria.
Angular has tons of things you can do to have great performance. I'm guessing the Google Cloud team just aren't prioritizing performance over features.
404 comments
[ 2.6 ms ] story [ 275 ms ] threadOne example: Jira integrates with _everything_. It really matters that you can create tickets from Slack, send email to the management when epics progress, see Github pull requests linked to tickets, and so on.
We'll likely find something else once the self-hosted version expires in a couple of years, unless the cloud version gets up to speed.
Come to think of it, that's how Google became so popular too.
Now you can find everything you want. You’re welcome.
I agree jira is terrible. Other bug trackers I’ve used are somehow worse. Does anyone have anything they can recommend with a straight face? (Github issues are missing too many features for me. Jira’s sql-style language is just too useful.)
> Click your mouse on a non-interactive UI component
80% of the UI is interactive, but not marked as such. Have fun finding a 10px strip that won't turn into an edit workflow when clicked!
> Click your mouse on a non-interactive UI component and press “.”
Even using the keybindings (seriously everyone, hit "?" and look through them) events are lost. Want to create a subtask? It's not `.sub<enter>`, it's actually `.sub^H^Hsub^H^H^Hsub<enter><wait><tab><tab><give up and use mouse to focus a field, because it arbitrarily unfocuses fields>Title Of My Task<use mouse to find the submit button>`
They've done so much work to make it a quick UX but it's all for nothing when it randomly eats keystrokes and defocuses constantly. Maybe some of our add-ons are at fault, I'm interested in hearing if there are jira installs that aren't like mine.
https://gwt.googlesource.com/gwt/
I don’t use GCP or many other Google products though. I’m kind of shocked google managed to ship a framework slower than GWT. I always assumed anyone that used it for a few seconds would say “well, that was a fundamentally bad idea”, and not double down on whatever the heck Google was thinking.
You can make anything slow if you really try.
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.
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.
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, ...).
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"
I guess it might speak to a solid, if somewhat slow, API.
https://www.hashicorp.com/resources/google-provider-new-terr...
It indicates that speed is not a priority for management.
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
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.
By now, it's too late to rewrite the whole thing from scratch, hence a new OS https://en.wikipedia.org/wiki/Google_Fuchsia
Microsoft did nail windows phone apis, 10 freaking years ago, too bad it didn't survive.
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.
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.
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.
https://perf.rust-lang.org/status.html
[1] https://i.imgur.com/ER5yfbd.png
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?
* 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.
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.
* 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.
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
https://i.imgur.com/ZNKOkMN.png
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 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.
https://i.imgur.com/nIQdZU7.png
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...
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.
Googlers have been WFH since March on laptops and residential Internet & WiFi.
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.
https://imgur.com/a/i9L45ZM
https://cloud.google.com/
The new one had a bunch of useless white space and the app has a loading bar!
Wtf?!
Boggles the mind how Google web apps have performance issues like this.
I didn't know there was some kind of secret mobile Web version of Gmail - I get a blank white page when I open your link on mobile tho (using Brave)?
I thought it was a broken page at first.
Example: load the basic HTML and enter a thread then return to the thread list. Returning to the thread list takes about 1 second. In the full gmail return to thread list takes no remote time, only local event handler CPU time, it's almost instantaneous.
Example 2: Open a thread in the basic UI and use "newer" or "older" to navigate to other threads. Every click takes ~1s. In the full Gmail UI navigate to adjacent thread takes almost no time, because the app pre-loads these threads in anticipation of you visiting them.
TL;DR the basic HTML gmail is good if your device is severely resource-poor and you just need to see if you have mail. For every other purpose it's worse.
As design overall started to become more relevant in products Google started to push out their redesigns but it was done with form instead of function as the focus. They've never really re-designed anything to be better - their updates have usually made the product worse.
But without a strong design leader it's death by a thousand cuts because there are so many layers of management to getting anything done.
The fact that i need to see a cute-dystopian loading animation for 2 seconds each time i reload the page is incredible.
Send plain HTML, then make JS take over after loading like most modern frameworks can do.
.. yes i really have to ditch Google ..
On a sidenote YT has also become a dystopian addiction machine - years ago you could easily curate what you saw, feeds, channels etc, now everything is controlled by the "google god skinner box algo" just like i feel Gmail is headed towards with all kinds of automated tools.
They did the same thing for GC UI. They think it tricks the user into thinking it's fast, instead of making it fast.
Google made a superior replacement to the current gmail experience and then just threw it away like it never existed.
I enabled that a while back which makes navigating emails much more pleasant
Some of the ugliest Gov and Gov adjacent pages (e.g. tax collectors, some DMVs) are fast and prompt zero second guessing. They just work.
Another thing is just because people complain (about their enterprise software, or country, or house, or romantic partner) does not mean they would switch. And just because they praise your slick and snappy startup enterprise app doesn't mean it will solve their problem better, doesn't mean they'll feel more comfortable using it, and doesn't mean they'll buy it.
With all that out of the way, the example I _wanted_ to raise above (but neglected to, apologies) with the "kool-aid" drinkers is that corporate users are absolutely aware of how fast and responsive something is _in addition_ to how it looks. I think many folks have been in a screen share or training session where the presenter has to awkwardly wait for an application they're "selling" to load or respond to input. Is the presenter oblivious to this latency? I'd say they are even more aware given the audience, if not flustered. That was the thrust of "people are not idiots".
WRT why people continue to use this software, I think you underestimate the impact of top-level purchasing/procurement and the captive enterprise audience. Those making purchasing decisions are less likely to use software after the sales demo and thus are not exposed to any UX or latency issues. Again. there is no idiocy or mal-intent here either, it's just an artifact of how bigcos operate.
I totally agree. I think what happened with us is, as is the case in most of these things, we were talking about orthogonal or parallel things.
I'm not assuming your agreement with my belief that aesthetic, even "brutalist" or "slow and clunky", will connote quality to a certain subset of users, enterprise being one example. I think your might have took it to mean I was saying "haha, therefore I think enterprise users are idiots." Which is not what I meant, but I get how you could see that. I don't think an aesthetic preference, even one which may on the face of it seem maladaptive, means people are idiots. I don't think it's a maladaptive preference, it's a natural thing, and there's reasons for it that work. I suppose it's a form of stereotyping, that allows people to form quick judgments from limited information.
And I'm aware of the research that says that a "good UI" can hide other problems, and be easier to use. So on the face of it, that would seem to say software with "slick and snappy" UX will be more prevalent, or at least be completely wiping the floor with the "slow and clunky" competition. But it's not -- at least not at the high end of the market that I care about. So this is an idea I have about that.
Actually, my criticism, if it was with any group, was with the developers who want the new shiny above all else, and seem to fail to see the practical benefits of practices done by bigcos, even when the success of those products is right in front of them. I think such blindness is stupid. But the developers are not stupid.
My back story is I, even when I wasn't someone who valued new and shiny above all else, once thought, "all I need to do is consumer-productize" enterprise apps and everyone will love them. But that's not all that's required. So I don't underestimate the sales process, I'm just coming at it from the point of view that aesthetics are a component of that decision, albeit an implicit and probably by necessity unspoken one (otherwise: "This UI looks too fancy and the app is too fast. We can't trust these guys, but the old-reliable, clunky and 80s-looking app we've been buying for 20 years just works great for what it is." ~~ but, hey, maybe people really do say that!).
I think you can sell the unfamiliar (product, narrative) using the familiar vehicle (product, narrative, aesthetic). So if you want to do something new, the best way is to serve it to people in a package they already like and are familiar with. I believe that as a general principle. But in this more specific case we're talking about here, I just think I see the importance of aesthetics and many other people miss it.
I could be wrong...I was wrong about what's required to develop enterprise apps, but I guess I see it as something (one of my hypothesis) that should guide how I develop software. Because I figure if I do that, it will save me worrying about stuff that doesn't matter (the new shiny slick and snappy), and I can concentrate on what matters (building what they want), and maybe even hack their psychology a bit (make it look like the old style apps they are already familiar with). It's OK if you think differently about it. It's my idea after all, I was just hoping to convince you a bit about it, not to convince myself more through consensus...I don't need that, but because I like the idea that maybe you can benefit from something I figured out, and I can "invite you into the cool club" of people in the know about this secret...
I don’t think that is GCP’s problem, though.
Those are people that get what problem they are solving.
The memory usage of the webpage often exceeds 1GiB.
But otherwise the platform is good. So I suffer through.
But I agree it’s annoying.
https://github.com/webcompat/web-bugs/issues/61522
This is one of the first features a new GCE user is likely to use (if they're exploring the UI and haven't yet started using the CLI) - and it's broken out of the box. Amazing.
It's amateur hour over there when it comes to frontend development - it's not a web app where cross-platform/cross-browser testing takes place, it's a Chrome app.
Like I was trying to submit some work using google classroom on firefox it wasn't letting me upload the work but when I did it in chrome it just worked well
https://twitter.com/johnath/status/1116871246510264320
Good strategy to steal market share.
Using Chrome, your tooling experience developing software at Google is, maybe, 1% faster. Some of that is core (TBH, FF's engine is old and creaky and webkit-derived browsers out-perform it on all kinds of metrics, though FF has significantly closed the gap). Some of it is that teams develop for Chrome first, because it's the first browser shortcut available. Plus, Chrome has all kinds of extensions built in-house at Google to make your life easier, and those have to be rewritten from scratch if someone wants them for FF also.
So now when you're doing UI development and testing it, your first testbed is always Chrome, because it's what you're using as a developer. So bugs always get seen first in Chrome, and only seen in FF if your team has acceptance testing requirements or you happen to have a team member who uses FF. So the gap widens: now using Chrome in Google is, maybe, a 5% better experience, because you're that much less likely to hit bugs the developing team hasn't hit yet. And th positive feedback loop continues.
The only way I'm aware of to stop this is to force teams to put half their engineers on using FF as their primary browser, and I've never seen a team willing to do so.
FF has die-hard supporters inside Google, but few are so die-hard they're willing to intentionally slow down their own development velocity by using a less-supported browser. Google's too competitive to incentivize that.
(Note: this applies to bugs that crop up between OS platforms also, because that happens---sometimes, the details of Chrome on MacOS surface a bug that never shows up on Linux. Some teams do require one engineer at least to use Mac, because the MacOS userbase is big enough that there's financial incentive to not break it. FF has like 5% market share; there's no such incentive there).
What? Why are they not standard WebExtensions?
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
https://news.ycombinator.com/item?id=19669586
I left using chrome 3 years ago and I haven’t really missed out and I honestly love firefox
And Google's take on it is that a FF user can always switch to Chrome, since Chrome runs on all OSs that support FF.
FF support is, in theory, part of the acceptance criteria for new development, but it's not on the blocking list so it's not really part of the acceptance criteria.