Live data from Hacker News

Chat is a bad UI pattern for development tools

danieldelaney.net

121–130 of 432 posts

Re: Chat is a bad UI pattern for development tools

#121
post #88

Earlier quoted context omitted.

Email threads seem better for documenting and searching correspondence. The last counter argument I read got buried on Discord or Slack somewhere.

Isn't this entirely an implementation detail of slack and discord search? What about email makes it more searchable fundamentally? The meta data if both platforms is essentially the same, no?

What makes email more useful in general is that each email is a separate object that you can organize in any way you want, i.e. move, copy, rename, sort into folders, attach as a file to any calendar entry, todo item, etc., or indeed to any other email. You can forward them to any other recipient, you can add and remove any recipient to and from the conversation at any time. It is conceptually powerful and flexible in a similar way that files in a file system are a powerful and flexible way to organize data. And it is easy to understand.

While all of these features could in principle be realized in a chat system as well, in practice they don’t provide that flexibility and power.

Another usability feature of emails is that they have a subject line. This allows to meaningfully list emails in a compact fashion. In a desktop interface, you can easily view and visually grep 50 emails or more at once in a mail folder or list of search results (in something like Outlook or Thunderbird or Mutt). This allows working with emails more efficiently than with a chat view where you can only see a few messages at once, and only of the same thread or channel.

Yet another usability feature of emails is that each email has its own read/unread status. This, again, is facilitated by each email being its own separate data object, and by the separation between subject and body, which allows the read status to be unambiguously bound to “opening” the email, or to navigating in the list of emails alongside a preview pane. And you can mark any email as unread again. In chats, the granularity of read/unread is the whole chat, whether you’ve actually read all of it or not. You can’t easily track what you’ve read or not in an automated way as with email, other than by that coarse-grained linear time-based property of when you last visited the channel.

Re: Chat is a bad UI pattern for development tools

#123
I don't think Daniel's point is that Chat is generically a clunky UI and therefore Cursor cannot possibly exist. I think he's saying that to fully specify what a given computer program should do, you have to provide all kinds of details, and human language is too compressed and too sloppy to always include those details. For example, you might say "make a logon screen" but there are an infinite number of ways this could be done and until you answer a lot of questions you may not get what you want.

If you asked me two or three years ago I would have strongly agreed with this theory. I used to point out that every line of code was a decision made by a programmer and that programming languages were just better ways to convey all those decisions than human language because they eliminated ambiguity and were much terser.

I changed my mind when I saw how LLMs work. They tend to fill in the ambiguity with good defaults that are somewhere between "how everybody does it" and "how a reasonably bright junior programmer would do it".

So you say "give me a log on screen" and you get something pretty normal with Username and Password and a decent UI and some decent color choices and it works fine.

If you wanted to provide more details, you could tell it to use the background color #f9f9f9, but a part of what surprised my and caused me to change my mind on this matter was that you could also leave that out and you wouldn't get an error; you wouldn't get white text on white background; you would get a decent color that might be #f9f9f9 or might be #a1a1a1 but you saved a lot of time by not thinking about that level of detail and you got a good result.

Re: Chat is a bad UI pattern for development tools

#124
post #52

I'm growing to the idea that chat is a bad UI pattern, period. It is a great record of correspondence, I think. But it is a terrible UI for doing anything. In large, I assert this is because the best way to do something is to do that thing. There can be correspondence around the thing, but the artifacts that you are building are separate things. You could probably take this further and say that narrative is a terribl…

Similar thing I've run into lately, chat is horrible for tracking issues and tasks. When people try to use it that way, it becomes absolute chaos after awhile.

Re: Chat is a bad UI pattern for development tools

#125
It's interesting we view Email and Chat so differently. Some companies run on chat (e.g. Slack), while most companies run on email.

Emails are so similar to Chat, except we're used to writing in long-form, and we're not expecting sub-minute replies.

Maybe emails are going to be the new chat?

I've been experimenting with "email-like" interfaces (that encourage you to write more / specify more), take longer to get back to you, and go out to LLMs. I think this works well for tools like Deep Research where you expect them to take minutes to hours.

Re: Chat is a bad UI pattern for development tools

#126
This has been the thesis behind our product since the beginning (~3 years), before a lot of the current hype took hold. I'm excited to see it gain more recognition.

Chat is single threaded and ephemeral. Documents are versioned, multi-threaded, and a source of truth. Although chat is not appropriate as the source of truth, it's very effective for single-threaded discussions about documents. This is how people use requirements documents today. Each comment on a doc is a localized chat. It's an excellent interface when targeted.

Re: Chat is a bad UI pattern for development tools

#127
post #52

I'm growing to the idea that chat is a bad UI pattern, period. It is a great record of correspondence, I think. But it is a terrible UI for doing anything. In large, I assert this is because the best way to do something is to do that thing. There can be correspondence around the thing, but the artifacts that you are building are separate things. You could probably take this further and say that narrative is a terribl…

Email threads seem better for documenting and searching correspondence. The last counter argument I read got buried on Discord or Slack somewhere.

Oh, how nice it must be to complain about Slack. Try using Teams and you will never want to complain about Slack again.

Re: Chat is a bad UI pattern for development tools

#129

I'm surprised that the article (and comments) haven't mentioned Cursor. Agreed that copy pasting context in and out of ChatGPT isn't the fastest workflow. But Cursor has been a major speed up in the way I write code. And it's primarily through a chat interface, but with a few QOL hacks that make it way faster: 1. Output gets applied to your file in a git-diff style. So you can approve/deny changes. 2. It (kinda) has…

Instead of Cursor I would recommend two open source alternatives that you can combine: https://www.continue.dev/ and https://github.com/cline/cline

Re: Chat is a bad UI pattern for development tools

#130
post #80

Earlier quoted context omitted.

I even think it's bad for generalized communication (ie. Slack/Teams/Discord/etc.) that isn't completely throwaway. Email is better in every single way for anything that might ever be relevant to review again or be filtered due to too much going on.

Anything that needs to be filtered for viewing again pretty much needs version control. Email largely fails at that, as hard as other correspondence systems. That said, we have common workflows that use email to build reviewed artifacts. People love complaining about the email workflow of git, but it is demonstrably better than any chat program for what it is doing.

I don't think I agree with this. Sure, many things should be versioned, but I don't think most correspondence requires it, which is emails primarily purpose.
Post reply on HN