Hacker News new | past | comments | ask | show | jobs | submit login

I really like the distinction of "density in time".

JIRA is a really visually dense application, but it's speed, as well as the number of different screens you normally need to click on makes it feel really sparse despite the dense visuals.




Call it what it is: slow. Slow software is bad software.


It's not just performance, it's also that the number of clicks to perform common actions is way too high because of feature bloat, extreme levels of customizability, and just plain bad design.


I very strongly prefer slow software that has a reasonable UI over fast software that does not, though.


I prefer fast software to support slow, deliberative humans. Slow software "gets in the way" instead of "making life easier."


No. Performance is a feature[0]. It's neither good or bad, it's often a desirable feature but it doesn't mean it's bad. A green screen UI will kick the shit out of any modern day web UI (compare old school Infor with a modern SFDC interface). However, it's just another feature, like the ability to create tabs on the UI or use a cursor to move across the screen (vs a keyboard) that contributes to the overall UX.

[0] - https://blog.codinghorror.com/performance-is-a-feature/


Unfortunately we’ve had several years of websites absolutely taking the piss when it comes to performance and deploying molasses slow dumpster fires.

A decent level of performance these days should be table stakes, and _high_ performance is a feature. Software that’s molasses slow _is bad software_ these days.


I with you. But maybe there's a line it crosses from feature to critical impediment?

A great example is YouTube in a web browser. My internet is 350 Mbps with 20-40ms latency. Trying to load YouTube in a new browser tab takes a few to several seconds and I'm forced to wait for it to load because the sign in link doesn't show up until the end of the seizure inducing re-render flashes. Safari, no add ons.

I can't believe it takes so long and I think less of Google as a company because of it. Them speeding it up is not a feature in that case. A trillion dollar technology company ought to provide fast as merely baseline. Anything less is them intentionally disregarding their customer.


Stable diffusion is essentially "slow", yet wildly popular so I'm not sure I agree.


Cutting edge supercomputer programs get judged by different standards from basic forms.

And when slow is the only option, people will wait.


Ding ding, you nailed my point.


Weird, because I completely agree with FridgeSeal.

Decent performance is table stakes outside of very special contexts, and software that can't manage it is bad.

Finding an exception doesn't make that stop being true in general.


Speed is always relative, otherwise it's a subjective, and thus less interesting metric (it's slow for you, not for me).

Stable diffusion is not relatively slow, because it has no alternative that is noticeably faster.


It’s fine to take time to crunch output. What needs to be fast is interaction. If it tells you “Hang on I’m working on it” I don’t think anyone minds that as long as you can leave it to cook while doing something else.


It's only turtle slow if you use their cloud version, onprem is reasonable (under 1s for any page, much faster for simpler ones).


Depends on your on-prem setup. I've worked on an instance that had tens of thousand users and it was very slow. At times unusable.

Also 1s is super slow given how much time you spend in the tool and how many clicks are required for many operations.


The places where Jira is dense it is extremely cluttered and difficult to parse. And then places where I’d like Jira to be dense, it’s inexplicably not.

I’m looking at a Kanban board right now. I have a 41 inch display and I can see a total of 9 issues at a time across three columns. And that’s with basically doing everything I can to maximize the space for the board and minimize how much chrome goes around it. I have no idea how anyone uses this thing on a laptop display. It’s awful.


> the number of different screens

Differance - the difference that makes a difference.

It's not just more, or density: you need to sum the cost of context switches, which depends on context size and continuity with prior, i.e., delta size, which in turn depends in part on relevance i.e., which parts really matter.

Design by committee (including one person over time) loses the natural continuity and integrity of an initial idea.


> Differance - the difference that makes a difference.

The first derivative of difference?


Yeah JIRA doesn’t appear to cache any of its information and doesn’t appear to make it’s information cache-friendly for a browser, so you end up accidentally clicking on another issue and then having to click back costing you 30 seconds (on work network).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: