Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chat is a bad UI pattern for development tools

danieldelaney.net

Post reply on HN
Print view View original

161–170 of 432 posts

Re: Chat is a bad UI pattern for development tools

#161

Post by gagik_co »

taeric wrote: 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…

I think “correspondence UX” can be bad UX but there’s nothing inherently wrong with chat UI.

I created the tetr app[1] which is basically “chat UI for everything”. I did that because I used to message myself notes and wanted to expand it to many more things. There’s not much back and forth, usually 1 input and instant output (no AI), still acting like a chat.

I think there’s a lot of intuitiveness with chat UI and it can be a flexible medium for sharing different information in a similar format, minimizing context switching. That’s my philosophy with tetr anyhow.

[1] https://tetr.app/

Re: Chat is a bad UI pattern for development tools

#162

Post by swiftcoder »

staplers wrote: post #148
t_mann wrote: post #131

Earlier quoted context omitted.

Ok, but what is a good pattern to leverage AI tools for coding (assuming that they have some value there, which I think most people would agree with now)? I could see two distinct approaches: - "App builders" that use some combination of drag&drop UI builders, and design docs for architecture, workflows,... and let the UI guess what needs to be built "under the hood" (a little bit in the spirit of where UML class dia…

Ok, but what is a good pattern to leverage AI tools for coding? Actual product stakeholders are not likely to spill their magic sauce and give free consultancy.

"Actual product stakeholders" in this space clearly don't actually have any magic sauce to spill. Everyone is building more or less the same chat-based workflows on the same set of 3rd-party LLMs.

The space is ripe for folks with actual domain expertise to design an appropriate AI workflow for their domain.

Re: Chat is a bad UI pattern for development tools

#163

Post by goosejuice »

packetlost wrote: post #72
taeric wrote: 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…

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.

I've had the opposite experience.

I have never had any issue finding information in slack with history going back nearly a decade. The only issue I have with Slack is a people problem where most communication is siloed in private channels and DMs.

Email threads are incredibly hard to follow though. The UX is rough and it shows.

Re: Chat is a bad UI pattern for development tools

#164

Post by tpmoney »

taeric wrote: 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…

I disagree. Chat is a fantastic UI for getting an AI to generate something vague. Specifically I’m thinking of AI image generation. A chat UI is a great interface for iterating on an image and dialing it in over a series of iterations. The key here is that the AI model needs to keep context both of the image generation history and that chat history.

I think this applies to any “fuzzy generation” scenario. It certainly shouldn’t be the only tool, and (at least as it stands today) isn’t good enough to finalize and fine tune the final result, but a series of “a foo with a bar” “slightly less orange” “make the bar a bit more like a fizzbuzz” interactions with a good chat UI can really get a good 80% solution.

But like all new toys, AI and AI chat will be hammered into a few thousand places where it makes no sense until the hype dies down and we come up with rules and guidelines for where it does and doesn’t work

Re: Chat is a bad UI pattern for development tools

#165

Post by kmoser »

al_borland wrote: post #147
dapperdrake wrote: post #76

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.

I find things get buried just as easily in email. People on my team are constantly resending each other emails, because they can’t find the thread. This is why, if something is important, I take it out of email and put it into a document people can reference. The latest and correct information from all the decisions in the thread can also be collected in one place, so everyone reading doesn’t have to figure it out. N…

> This is why, if something is important, I take it out of email and put it into a document people can reference.

This is how things should be done, regardless of which medium is used to discuss the project. Without isolating and aggregating the final decision of each thread, there is no way to determine what everybody has agreed upon as the final product without looking back, which quickly becomes onerous.

Things get messy when you start having different versions of each feature, but that doesn't change the concept of using email/Slack/Discord/text/etc. for discussion and a separate "living" document for formalizing those decisions.

Re: Chat is a bad UI pattern for development tools

#166

Post by taeric »

packetlost wrote: post #130
taeric wrote: post #80

Earlier quoted context omitted.

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.

Agreed if it is correspondence that we are talking about. So, agreed I'm probably too strong that anything needing filtering and such is bad.

I'm thinking of things that are assembled. The correspondence that went into the assembly is largely of historical interest, but not necessarily one of current use.

Re: Chat is a bad UI pattern for development tools

#167

Post by 1ucky »

aylmao wrote: post #117
SoftTalker wrote: post #110

Earlier quoted context omitted.

Yes, agree. Chatting with a computer has all the worst attributes of talking to a person, without any of the intuitive understanding, nonverbal cues, even tone of voice, that all add meaning when two human beings talk to each other.

I would also call it having all the worst attributes of a CLI, without the succinctness, OS integration, and program composability of one.

You should check out out MCP by Anthropic, which solves some of the issues you mentioned.

Re: Chat is a bad UI pattern for development tools

#169

Post by ygouzerh »

stitched2gethr wrote: post #136
themanmaran wrote: post #99

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…

I think this misses the point. It seems like the author is saying we should move from imperative instructions to a declarative document that describes what the software should do. Imperative: - write a HTTP server that serves jokes - add a healthcheck endpoint - add TLS and change the serving port to 443 Declarative: - a HTTP server that serves jokes - contains a healthcheck endpoint - supports TLS on port 443 The di…

Good explanation! As an open-reflexion: will a declarative document be as detailed as the imperative version? Often between the specs that the product team is providing (that we can consider as the "descriptive" document) and the implementation, many sub specs have been created by the tech team that uncovered some important implementation details. It's like a Rabbit Hole.

For example, for a signup page, we could have: - Declarative: Signup the user using their email address - Imperative: To do the same, we will need to implement the smtp library, which means discovering that we need an SMTP server, so now we need to choose which one. And when purchasing an SMTP Server plan, we discover that there are rate limit, so now we need to add some bot protection to our signup page (IP Rate Limit only? ReCaptcha? Cloudflare bot protection?), etc

Which means that at the end, the imperative code way is kind of like the ultimate implementation specs.

Re: Chat is a bad UI pattern for development tools

#170

Post by fragmede »

> People call them “great for prototyping,” which means “don’t use this for anything real.”

Eh, that's just copium because we all have a vested monetary interest in them not being useful for "anything real", whatever that means. If it turns out that there useful for "real things", then then entire industry would get turned on its head. (hint: they're useful for "real" things), though putting the entire codebase into the context window doesn't currently work. Aider works past this by passing the directory tree and filenames as context, so the LLM guess that /cloud/scope/cluster.go is where the cluster scope code lives and ask for that specific file to get added to the context and you can ask it to add, say, logging code to that file.

Post reply on HN