[CharlieDigital]

    > instant UX

I do not get the hype. At all.

"Local first" and "instant UX" are the least of my concerns when it comes to project management. "Easy to find things" and "good visibility" are far more important. Such a weird thing to index on.

I might interact with the project management tool a few times a day. If I'm so frequently accessing it as an IC or an EM that "instant UX" becomes a selling point, then I'm doing something wrong with my day.

[virgil_disgr4ce]

UI performance is "a weird thing to index on"?

[CharlieDigital]

Yes? If that's the primary selling point for a project manager versus being just a really damn good project manager with good visibility?

I've never used a project manager and thought to myself "I want to switch because this is too slow". Even Jira. But I have thought to myself "It's too difficult to build a good workflow with this tool" or "It's too much work to surface good visibility".

This is not a first-person shooter. I don't care if it's 8ms vs 50ms or even 200ms; I want a product that indexes on being really great at visibility.

It's like indexing your buying decision for a minivan on whether it can do the quarter mile at 110MPH @ 12 seconds. Sure, I need enough power and acceleration, but just about any minivan on the market is going to do an acceptable and safe speed and if I'm shopping for a minivan, its 1/4 mile time is very low on the list. It's a minivan; how often am I drag racing in it? The buyer of the minivan has a purpose for buying the minivan (safety, comfort, space, cost, fuel economy, etc.) and trap speed is probably not one of them.

It's a task manager. Repeat that and see how silly it sounds to sweat a few ms interaction speed for a thing you should be touching only a few times a day max. I'm buying the tool that has the best visibility and requires the least amount of interaction from me to get the information I need.

[asoneth]

> any minivan on the market is going to do an acceptable and safe speed

Growing up my folks had an old Winnebago van that took 2+ minutes to hit 60mph which made highway merges a white-knuckle affair, especially uphill. Performance was a criteria they considered when buying their next minivan. Whereas modern minivans all have an acceptable acceleration -- it's still important, it's just no longer one you need to think about.

However, not all modern interfaces provide an acceptable response time, so it's absolutely a valid criteria.

As an example, we switched to a SaaS version of Jira recently and things became about an order of magnitude slower. Performing a search now takes >2000ms, opening a filter dropdown takes ~1500ms, filtering the dropdown contents takes another ~1500ms. The performance makes using it a qualitatively different experience. Whereas people used to make edits live during meetings I've noticed more people just jotting changes down in notebooks or Excel spreadsheets to (hopefully remember to) make the updates after the meeting. Those who do still update it live during meetings often voice frustration or sometimes unintentionally perform an operation twice because there was no feedback that it worked the first time.

Going from ~2000ms to ~200ms per UI operation is an enormous improvement. But past that point there are diminishing returns: from ~200ms to ~20ms is less necessary unless it's a game or drawing tool, and going from 20ms to 2ms is typically overoptimization.

[dustingetz]

2000ms isn’t network latency, it’s the db query. Moving a slow query from the cloud (high compute, fast network under your control) to the client (low compute, unreliable network, not under your control) is not going to make it faster and you’ve damaged reliability. All to save 50ms network latency.

[asoneth]

I'm not saying local first will help or hinder UI latency, merely that UI latency is indeed a valid evaluation criteria for software.

[ajoseps]

I mostly agree with you on this but JIRA tends to push the envelope in terms of unresponsiveness of its UX. As an IC I only really use it to create/update/search tickets but I find myself waiting a half to couple of seconds for certain flows, especially for finding old tickets.

Not quite the same as responsiveness but editing text fields in JIRA have a tendency of not saving in progress work if you accidentally escape out. Also hyperlinking between the visual and text mode is pretty annoying since you can easily forget which mode you’re in.

Honestly as I type these out there are more and more frustrations I can think of with JIRA. Will we ever move away? Not anytime soon. It integrates with everything and that’s hard to replace.

It’s still frustrating though.

[PinkSheep]

I urge you to try and set your display to 25 Hz. I don't quite feel it yet at 30 Hz, although the latter is more widely available as an option.

It all depends on what we do consider "good enough". 200ms total page render time would be "blazing fast" for me already. I've just clicked around Github (supposed to be globally fast, can we agree?) and the SPA page changes are 1-1.5s to complete.

To continue my example above, your computer peripherals are probably good enough. Have you considered what it would be like with a garbage-tier mouse? Similarly, maybe you wouldn't notice the difference to a better mouse. I do, because a standard office mouse is not the pace I'm moving at. (No, I'm not some the Flash, I am just fast and precise with my mouse.)

If anything, this gives us a glimpse of what's possible. The latency benchmark[1] of text editors has given us something to think about. In the past decade (already?!) that article was probably the sole reason for drawing public attention to this topic[2] . For example, JetBrains have since put considerable work into improving their IDEs (IntelliJ IDEA etc). They had called it "zero latency" mode.

[1]: https://pavelfatin.com/typing-with-pleasure/ [2]: small study from 2023 https://dl.acm.org/doi/fullHtml/10.1145/3626705.3627784

[rokob]

Yeah but Jira is a good example of where the culture building the software shows they don’t give a shit about performance or usability. They tend to go together. I agree the talk about Linear being good because it is fast is weird but I think a lot of people who say that are actually saying the workflows are sensible and the ux is good. The feeling of speed is partially because you don’t have to click 17 times to do something simple.

[tuckerman]

I think there is a mismatch between most commenters on HN and who is making purchasing decisions for something like Linear: it would the PGM/TPM org or leadership pushing it and they are touching the tool a lot more often. Even if a small speed up ultimately doesn't make a difference in productivity, the perceived snapiness makes it feel "better/more modern" than what they currently have.

That said, I really enjoy Linear (it reminds me a lot of buganizer at Google). The speed isn't something I notice much at all, it's more the workflow/features/feel.

[physicles]

There is a certain point where UX responsiveness has a huge impact on how the product gets used.

I hate Jira with a burning passion simply because it is slow where I live (in China, with a VPN). Even minor interactions, like clicking on a task’s description to edit it, takes about 2 seconds. Opening a task from a list takes around 5 seconds.

The result is that I and my coworkers avoid using Jira unless we really have to. Ad-hoc work that wasn’t planned as part of the sprint just doesn’t get tracked because doing so is unreasonably painful.

[nwienert]

Actually it's both instant UX and far simpler code. With Zero I define a table schema, relationships, and permissions in beautifully simple code, then I also write my queries including relations with a nice typed query-builder, and I get not just instant UX but also perfectly fetched and synced data with permissions and mutations that are fully consistent without any extra thought.

Doing that with any other system, sync-engine or not, requires a huge mess of code and ends up implementing some sort of ad-hoc glue code to make even a part of this work.

I'm building an app right now with it and I'm currently so much further ahead in development than I could be with any other setup, with no bugs or messy code.

Your choice is either 100% server-side like v1 Rails, or some sort of ad-hoc sync/update system. My argument is either you should stick 100% server side, or go all the way client properly with a good sync engine. It's the middle part that sucks, and while there's a chunk of apps that benefit from fully server, it's not really an argument that you can build much faster responding apps client-side and that users generally prefer it, rightly so.