Comment by nomdehn_180714 | Hacker News Reader

Comment by nomdehn_180714 | Hacker News Reader

Parent Full thread

I think your criticism misses the mark.

[1] You're answering an article that starts with a 45-second video of Slack opening (surely the worst offender among modern apps) with something about latencies measured in thousandths of a second.

[2] As Nielsen is focused on web apps and applications, this advice is less applicable to UI provided by the OS that you interact with all day in presumably familiar ways. Note that generally "directing user attention" isn't necessary in a shell: output always comes at the bottom. However, be sure to read the "Frequency: Don’t Get in the User’s Way" heading that includes almost verbatim the OP's points against animations that slow the user down.

[3] Yes, internationalization is still hard. At least for Terminal.app, this is basically a solved problem, but of course it's possible for terminal apps (ncurses etc) to need custom support. The situation with web tech is about the same, these things are solved for you if you stick with the basic technologies, but if you get fancy you may need more explicit support.

> 45-second video of Slack opening (surely the worst offender among modern apps

I hate to defend Slack as it's far from snappy, but comparing it to a console app seems hardly fair.

I wonder how much of it's slowness is due to network requests? I could make the argument that git is slow because when I clone a large repository it takes a while.

I do not see how that comparison is unfair. Terminal IRC clients, for example, accomplish the same exact functionality as Slack in a curses UI in a vastly faster way.

But somehow there's all these people that want to use Slack over Irssi.

Probably because IRC is an outdated protocol with inferior features to Slack and very few good open source options for connecting. For example:

* DCC is still unreliable.

* There is no audio connection option, which is quite popular in 2018.

* Channel history management is ad hoc

* Authentication is done in band, in plain text.

* "secured" channels rely on this bad authentication, and if they don't (perhaps electing to manage it themselves) network flaws can completely steal your channel.

* IRC isn't even particularly open source, many servers and networks have private patches that are not shared publicly.

IRC isn't better than slack. I agree with you that it's confusing why people suggest that it ought to be.

Also, most IRC networks are controlled by entities even more inscrutable than Slack's executive team and board. I can go look up who runs slack, I cannot actually find good details on who runs any given IRC network. I have no idea what I'm dealing with or how they're using my data. I have no legal recourse if I do discover bad behavior, and I'm forced by the ossified protocol to keep using their insecure authentication mechanisms which make abuse trivial.

> ... I cannot actually find good details on who runs any given IRC network. I have no idea what I'm dealing with or how they're using my data. I have no legal recourse if I do discover bad behavior...

Ah, the good old days of the Internet. You make me so nostalgic.

Back when I was a kid this sounded romantic. Now I just know it means that folks spy on me for fun.

As opposed to the non-anonymous internet?

Certainly I use a lot more software products by a lot more diverse sources that all have a lot more accountability to the consumer. This, at least, is a positive trend. One of the few good parts of the commerical software movement is more accountability and higher minimum standards for the consumer. I think that shows in trends in modern computer adoption.

Wouldn't say that IRC has the same exact functionality as Slack. But the Slack mobile app does, and it runs far better than the desktop version (starts up in 3 seconds on a low-powered device instead of 30 on a much faster machine).

I've read this opinion a few times and at one point (before trying mobile slack) I believed it. Is this true for iPhone users maybe?

I've used slack on mobile and I find it worse than the desktop version.

It starts slightly faster (10 seconds vs. almost 20) but navigating through channels is bad (and slower) and threads are completely unusable. It also runs my device hot like nothing else.

The faster startup speed isn't a big victory for me because it's still a factor of 10 away from what I would consider acceptable.

The "best" interface for slack, IMHO, is the web version, provided that you are already using Chrome.

This goes to the article's point about caching; a chat app -- of all programs -- should cache conversations for a fast boot up. Sure, _updating_ the conversations -- the "cloning" stage -- may take some time, but why should you have to wait for the network requests to complete before seeing your past conversations?

The git equivalent would be if you had to wait for git to do a fetch/pull every time you ran "ls" on a git-controlled folder. It would be insane, and no one would use git (or any other version control).

Don't get me wrong, Electron has a lot of issues. I think Slack should switch toolkits. But I don't see how we argue that a famously poorly implemented app is somehow indicative of the entire space of GUI apps and that a space equally fraught with UX issues is somehow obviously better.

Especally when we have excellent examples like VS Code, which is cheerfully giving neovim and emacs a run for their money and displacing longtime contenders like sublime, because it's genuinely quite good and plenty fast enough for most folks.

Yeah this was my takeaway as well. Category error - author didn't like electron apps, and therefore wants to dump GUIs in favor of terminals (which would slowly become GUIs with his improvements).

Slack's problems have zero to do with Electron.

I think maybe it's security problems have something to do with Electron.

However, I agree Slack's got a lot of issues that are just bad implementation choices.

It's obvious from the outside, isn't it. Hindsight is everything.

But the reality is is that Slack is an application made by a real company by real people/developers who all faced real constraints. Go build Slack for yourself, through the same history they have, and lets see what we come out with.

I hope someone takes your advice so that we can dump the slow bloated resource hog that is Slack :)

That's not really a fair comparison. Git changes but the version you have and are looking at is fixed. With slack the conversation changes and you can't let the user respond until they're up-to-date because if they did people would be on HN ripping Slack for causing confusion. Not only that but the messages can literally change from one moment to the next. What happens when a user deletes a message?

The equivalent with git would be having each directory be a submodule and someone is rewriting the history out from under you every few seconds.

For technical people it’s easy to assume we understand the problem especially when we see what looks like a questionable design choice but when we do this to applications we don’t have experience with it only hurts us collectively.

[1]:

Maybe you should read the article and see subsequent videos (e.g., animation jank) where we are in this time domain rather than skipping that part? TBF: the videos didn't play for me without opening them in a different tab. I'm not sure how they accomplished this, since typical embedding tags don't have this problem.

[2]: > As Nielsen is focused on web apps and applications, this advice is less applicable to UI provided by the OS that you interact with all day in presumably familiar ways.

Multiple interactions were offered in the article that were native apps that had animation. Principles of UX are not exactly the same between local and web, but the principles of how animation guides user attention and context are more universal than you make them out to be.

For example, I love to make fun of the 1pass animation but I think it does serve a valuable purpose: making sure the user has realized the environment is now authenticated as a result of password entry. A unique cue for that is a good idea.

> Note that generally "directing user attention" isn't necessary in a shell...

This is fantastically wrong!

We have a long history of working to make sure that user attention is directed in shells! From guidance on how to do a menu with highlighting (folks have settled on doing the chosen option in a select menu with inverse text and an extra glyph to keep degenerate cases like 1-tuples and 2-tuples from being ambiguous) to ongoing refinements to midnight commander.

Another example in a more command-line domain is silver searcher's bash integration, which makes history search a lot better.

And there is a whole world of UI around log aggregation, search and UI that extends onto the console and has seen rapid evolution over the last 5 years.

[3]:

> Yes, internationalization is still hard. At least for Terminal.app, this is basically a solved problem

It's really not. Lots of tooling breaks.

> he situation with web tech is about the same,

CSS makes this dramatically better on the web side, and we haven't even gotten to support for folks with physical differences that make precise keyboard input or traveling eyesight easy.

The web is WAY more accessible to non-english-speaking people, people with physical differences, and people with issues focusing in the way terminals must demand you do.

> The web is WAY more accessible to non-english-speaking people, people with physical differences, and people with issues focusing in the way terminals must demand you do.

A bunch of people (including Kay and Victor) have talked about this, but accessibility is only one part of the interface. Pieces of software that are productivity related should be easy to get started with and be accessible, but also allow you to become more productive. A lot of tools (like 1Password) focus on the former (accessibility to the lay user) but don't focus on the latter. This isn't some sort of unattainable ideal though: Excel and Powerpoint are great examples of tools that make it easy to just play around with as a beginner, but also to really reward power users.

And in the spirit of fairness and inclusivity to the console, Lotus 123!

Reply on news.ycombinator.com