Chat is a bad UI pattern for development tools

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 terrible way to build things. It can be a great way to communicate them, but being a separate entity, it is not necessarily good at making any artifacts.

As a written form of "stream of consciousness", it seems to have a lot of value to me. It's noisy, inefficient & meandering -- all the things those polished artifacts are not -- but it's also where you can explore new avenues without worrying about succinctness or completeness. It's like the first draft of a manuscript.

Midjourney is an interesting case study in this I think, building their product UI as a discord bot. It was interesting to be sure, but I always felt like I was fighting the "interface" to get things done. It certainly wasn't all bad, and I think if I used it more it might even be great, but as someone who doesn't use Discord other than that and only rarely generated images, I had to read the docs every time I wanted to generate an image, which is a ridiculous amount of friction.

I don't know, I'm in Slack all day with colleagues, I quite like having the additional ChatGPT colleague (even better I can be quite rude/terse in my messages with 'them').

Incidentally I think that's also a good model for how much to trust the output - you might have a colleague who knows enough about X to think they can answer your question, but they're not necessarily right, you don't blindly trust it. You take it as a pointer, or try the suggestion (but not surprised if it turns out it doesn't work), etc.

There has recently been a pretty large UI inclusion for midjourney directly inside Discord which has the option of being used instead of the text input.

As is often the case in these sorts of thingsz your milage may vary for the more complex settings.

Certainly, it can have its use. But I question if it is stronger than previous generative techniques for creating many things. There have been strong tools that you could, for example, draw a box and say this should be a house. Add N rooms. This room should be a bathroom. Add windows to these rooms. Add required subfloor and plumbing.

Even with game development. Level editors have a good history for being how people actually make games. Some quite good ones, I should add.

For website development, many template based systems worked quite well. People seem hellbent on never acknowledging that form builders of the late 90s did, in fact, work.

Is it a bit nicer that you can do everything through a dialog? I'm sure it is a great for people that think that way.

Oh, do not take my comment as a "chat bots shouldn't exist." That is not at all my intent. I just think it is a bad interface for building things that are self contained in the same chat log.

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.

Voice messages within a chat UI is even worse. I can't search it, I can't listen to it in the same situations I can read a message.

I wish I could block them within all these chat apps.

"Sorry, you can't bother to send voice messages to this person."

Email threads seem better for documenting and searching correspondence.

The last counter argument I read got buried on Discord or Slack somewhere.

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.

Oh dear lord yes. I am always baffled when I hear that some folks send voice memos to people.

Discord and slack baffle me. I liked them specifically because they were more ephemeral than other options. Which, seems at odds with how people want them to be? Why?

I'm curious if you find their new website interface more tractable--there's some inherent friction to the prompting in either case, but I'd like to know if the Discord chat interface can be overcome by using a different interface or if the issue is more intrinsic.

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?

Can't say for everyone, but I have terrible memory and rely heavily on the chat history (and other tools) to keep my mental model in shape.

Here, ephemeral means "this conversation might as well never had happened", so why waste time on that?

I suspect it has to do with mental models. For my model, at large, conversations are worthless. Anyone that tries to hold you to a conversation from weeks ago that didn't secure a stronger commitment is almost certainly flying loose and more than willing to selectively choose what they want to be committed to.

Does that mean I can't have some pleasure in conversing about things? Of course not. But, I also enjoy some pleasure there from the low stakes and value that a conversation has. It should be safe to be wrong. If you have a conversation spot where being wrong is not safe, then I question what is the advantage of that over trying to adopt a legalese framework for all of your communication?

Preach!

I’ve been saying this since 2018

Were these ever ephemeral? Are you misremembering history free IRC chat rooms?

Fair that they were probably less ephemeral than I have them in my mental model. Which, as you guessed, was largely from them taking up the same spot as a slack (edit: I meant irc) instance in my mind. Slack, in particular, often had policies applied so that messages were deleted after a set time frame. I remember people complaining, but that seemed legit to me and fit my model.

I also confess this model of ephemeral conversation is amusing in this specific website. Which I also largely view as a clubhouse conversation that is also best viewed as ephemeral. But it is clearly held for far longer than that idea would lead me to think.

Personally, when I send an email, I feel less time pressure to respond, so I more carefully craft my responses. The metadata is similar enough, but the actual data in email/forums is usually better.

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.

Yeah, this is something I didn't make clear on my post. Chat between people is the same bad UI. People read in the aggression that they bring to their reading. And get mad at people who are legit trying to understand something.

You have some of the same problems with email, of course. Losing threading, in particular, made things worse. It was a "chatification of email" that caused people to lean in to email being bad. Amusing that we are now seeing chat applications rise to replace email.

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

I like the idea of having a chat program, the issue is that it's horrible to have a bunch of chat programs all integrated into every application you use that are separate and incompatible with each other.

I really don't like the idea of chatting with an AI though. There are better ways to interface with AIs and the focus on chat is making people forget that.

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.

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.

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

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.

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 diagrams were meant to take us). This would still require actual programming knowledge to evaluate and fix what the bot has built

- Formal requirement specification that is sufficiently rigorous to be tested against automatically. This might go some way towards removing the requirement to know how to code, but the technical challenge would simply shift to knowing the specification language

I think this depends very much on how you use the tools.

My experience with email is that people have subject lines, email explicitly identifies to and cc recipients; email is threaded; email often has quotes/excerpting/highlighting from prior parts of the thread.

On the other hand, most chat usage I see is dependent on temporal aspects for threading (people under-utilize platform features for replies etc), tagging is generally only done to ping people to attract attention, chat groups are frequently reused for multiple different purposes.

Leaping to a point-in-time within a chat stream is often a bad user experience, with having to scroll up and down through unrelated stuff to find what you’re looking for.

Stuff in email is just massively more discoverable for me.

> It can be a great way to communicate them

It's usually not. Narrative is a famously flawed way to communicate or record the real world.

It's great for generating engagement, though.

Disclaimer: Haven't used the tools a lot yet, just a bit. So if I say something that already exists, forgive me.

TLDR: Targeted edits and prompts / Heads Up Display

It should probably be more like an overlay (and hooked into context menus with suggestions, inline context bubbles when you want more context for a code block) and make use of an IDE problems view. The problems view would have to be enhanced to allow it to add problems that spanned multiple files, however.

Probably like the Rust compiler output style, but on steroids.

There would likely be some chatting required, but it should all be at a particular site in the code and then go into some history bank where you can view every topic you've discussed.

For authoring, I think an interactive drawing might be better, allowing you to click on specific areas and then use shorter phrasing to make an adjustment instead of having an argument in some chat to the left of your screen about specificity of your request.

Multi-point / click with minimal prompt. It should understand based on what I clicked what the context is without me having to explain it.

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. Not to mention side conversations can influence the results, without being explicitly stated in the email thread.

  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.

With apologies to Bill Buxton: "Every interface is best at something and worst at something else."

Chat is a great UI pattern for ephemeral conversation. It's why we get on the phone or on DM to talk with people while collaborating on documents, and don't just sit there making isolated edits to some Google Doc.

It's great because it can go all over the place and the humans get to decide which part of that conversation is meaningful and which isn't, and then put that in the document.

It's also obviously not enough: you still need documents!

But this isn't an "either-or" case. It's a "both" case.

No, it has to do with context. In an email you will frequently have to provide more context for your answers to make sense. Chat is a conversation, which search drops you straight into, may with AI you could get placed at an appropriate starting point, but you're still reading a conversation. It's much easier to get dropped into a correspondence. To me the difference is like reading someones letter, vs. overhearing a conversation in a bus.

This obvious assumes that who ever wrote the email isn't a madman, who insist on using emails like it was a chat.

I'd challenge if this is specific to coding? If you want to get a result that is largely like a repertoire of examples used in a training set, chat is probably workable? This is true for music. Visual art. Buildings. Anything, really?

But, if you want to start doing "domain specific" edits to the artifacts that are made, you are almost certainly going to want something like the app builders idea. Down thread, I mention how this is a lot like procedural generative techniques for game levels and such. Such that I think I am in agreement with your first bullet?

Similarly, if you want to make music with an instrument, it will be hard to ignore playing with said instrument more directly. I suspect some people can create things using chat as an interface. I just also suspect directly touching the artifacts at play is going to be more powerful.

I think I agree with the point on formal requirements. Not sure how that really applies to chat as an interface? I think it is hoping for a "laws of robotics" style that can have a test to confirm them? Reality could surprise me, but I always viewed that as largely a fiction item.

I really don't get why people are so happy about Slack (never used Discord). The interface is awful, it barely functions as a chat client, yet people adds bots, automation and use it as a repository for documentation. Honestly it would be better if history was deleted weekly or something, just to prevent people from storing things in Slack.

I think fictional narratives that aim to capture inner monologue are famously flawed. I think narrative tours of things can be good. I'm not clear if "narrated tours" are a specific genre, sadly. :(

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/

"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.

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.

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

> 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.

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.

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

> Narrative is a famously flawed way to communicate or record the real world.

...and yet with it's flaws, it's the most flexible in conveying meaning. A Ted Chiang interview was on the HN frontpage a few days ago, in it, he mentions that humans created multiple precise, unambiguous communication modes like equations used in mathematical papers and proofs. But those same papers are not 100% equations, the mathematicians have to fall back to flawed language to describe and provide context because those formal languages only capture a smaller range of human thought compared to natural language.

This is not to say chat has the best ergonomics for development - it's not, but one has to remember that the tools are based on Large Language Models whose one-trick is manipulating language. Better ergonomics would likely come from models trained or fine-tuned on AST-tokens and diffs. They'd still need to modulate on language (understanding requirements, hints, variable names,and authoring comments, commits and/or PRs).

I hard disagree. Don't have a conversation? Ask someone who does to forward it. Email lets the user control how to organize conversations. Want to stuff a conversation in a folder? Sure. Use tags religiously? Go for it. Have one big pile and rely on full-text search and metadata queries? You bet. Only the last of these is possible with the vast majority of IM platforms because the medium just doesn't allow for any other paradigm.

The fact that there's a subject header alone leads people to both stay on topic and have better thought out messages.

I agree that email threads could have better UX. Part of that is the clients insistence on appending the previous message to every reply. This is completely optional though and should probably be turned off by default for simple replies.

Yup, I agree there. Email is a horrible means of collaborating on changes in general, but doubly so in realtime. But so is IM.

Talk to AI chat as if you would talk to junior developer at your company and tell it to do something that you need.

I think it is brilliant. On another hand I caught myself many times writing prompts to colleagues. Although it made requirements of what I need so much clearer for them.

We need an LSP like protocol for AI, so that we can amortize the configuration over every place we want such an integration. AISP?

That comment made sense 3 years ago. LLMs already solved "intuitive understanding", and the realtime multimodal variants (e.g. the thing behind "Advanced Voice" in ChatGPT app) handle tone of voice in both directions. As for nonverbal cues, I don't know yet - I got live video enabled in ChatGPT only few days ago and didn't have time to test it, but I would be surprised if it couldn't read the basics of body language at this point.

Talking to a computer still sucks as an user interface - not because a computer can't communicate on multiple channels the way people do, as it can do it now too. It sucks for the same reason talking to people sucks as an user interface - because the kind of tasks we use computers for (and that aren't just talking with/to/at other people via electronic means) are better handle by doing than by talking about them. We need an interface to operate a tool, not an interface to an agent that operates a tool for us.

As an example, consider driving (as in, realtime control - not just "getting from point A to B"): a chat interface to driving would suck just as badly as being a backseat driver sucks for both people in the car. In contrast, a steering wheel, instead of being a bandwidth-limiting indirection, is an anti-indirection - not only it lets you control the machine with your body, the control is direct enough that over time your brain learns to abstract it away, and the car becomes an extension of your body. We need more of tangible interfaces like that with computers.

The steering wheel case, of course, would fail with "AI-level smarts" - but that still doesn't mean we should embrace talking to computers. A good analogy is dance - it's an interaction between two independently smart agents exploring an activity together, and as they do it enough, it becomes fluid.

So dance, IMO, is the steering wheel analogy for AI-powered interfaces, and that is the space we need to explore more.

That's fine.

Email is really powerful but people simply aren't good at taking advantage of it and it varies by email client. Doing some IT work at a startup made this pretty clear to me. I found Slack was much more intuitive for people.

Both systems rely on the savviness of the users for the best experience and I just think email is losing the UX war. Given how terrible people seem to be at communicating I think it's a pretty important factor to consider.

I think this could reasonably be addressed, and several startups have. The trouble is that the default email clients (gmail, outlook, etc.) don't really try to make it any better.

I've also generally had the opposite experience, a huge amount of business offices live and breath in email (mostly Outlook, but I'm sure it varies). Startups tend to run fast and lean, but as soon as you have some threshold of people, email is king.

I think they're working on it? MCP: https://www.anthropic.com/news/model-context-protocol

> We need an interface to operate a tool, not an interface to an agent that operates a tool for us.

Excellent comment and it gets to the heart of something I've had trouble clearly articulating: We've slowly lost the concept that a computer is a tool that the user wields and commands to do things. Now, a computer has its own mind and agency, and we "request" it to do things and "communicate" with it, and ask it to run this and don't run that.

Now, we're negotiating and pleading with the man inside of the computer, Mr. Computer, who has its own goals and ambitions that don't necessarily align with your own as a user. It runs what it wants to run, and if that upsets you, user, well tough shit! Instead of waiting for a command and then faithfully executing it, Mr. Computer is off doing whatever the hell he wants, running system applications in the background, updating this and that, sending you notifications, and occasionally asking you for permission to do even more. And here you are as the user, hobbled and increasingly forced to "chat" with it to get it to do what you want.

Even turning your computer off! You used to throw a hardware switch that interrupts the power to the main board, and _sayonara_ Mr. Computer! Now, the switch does nothing but send an impassioned plea to the operating system to pretty please, with sugar on top, when you're not busy could you possibly power off the computer (or mostly power it off, because off doesn't even mean off anymore).

I think this gets to how a lot of these conversations go past each other? A chat interface for getting a ride from a car is almost certainly doable? So long as the itinerary and other details remain separate things? At large, you are basically using a chat bot to be a travel agent, no?

But, as you say, a chat interface would be a terrible way to actively drive a car. And that is a different thing, but I'm growing convinced many will focus on the first idea while staving off the complaints of the latter.

In another thread, I assert that chat is probably a fine way to order up something that fits a repertoire that trained a bot. But, I don't think sticking to the chat window is the best way to interface with what it delivers. You almost certainly want to be much more actively "hands on" in very domain specific ways with the artifacts produced.

We used outlook and slack. Business primarily operated via outlook as most communication was unsurprisingly external. Most but not all internal was slack.

I'm not hating on email, it has a lot of good properties and still serves a purpose. Every office appears to have some kind anti-slack vigilante. It's really not that bad.

Lets toss in a minimum number of [digital] signatures.

> Specifically I’m thinking of AI image generation

I heavily disagree here, chat - or really text - is a horrible UI for image generation, unless you have almost zero idea of what you want to achieve and you don't really care about the final results.

Typing "make the bar a bit more like a fizzbuzz" in some textbox is awful UX compared to, say, clicking on the "bar" and selecting "fizzbuzz" or drag-and-dropping "fizzbuzz" on the "bar" or really anything that takes advantage of the fact we're interacting with a graphical environment to do work on graphics.

In fact it is a horrible UI for anything, except perhaps chatbots and tasks that have to do with text like grammar correction, altering writing styles, etc.

It is helpful for impressing people (especially people with money) though.

I have magic sauce that I haven't spilled yet.

We had this problem in our organization circa 20 years back so I built a ticketing system, now each conversation exists as its own object, and "the same thing being discussed twice" has the opportunity to be merged into one, etc. That seems to have helped a lot with our internal conversations.

This is one reason I love what Bret Victor has been doing with Dynamic Land[1]. He's really been doing in on trying to engage as many senses as possible, and make the whole system understandable. One of his big points is that the future in technology is helping us understand more, not defer our understanding to something else.

[1] https://dynamicland.org/

EDIT: love your analogy to dance!

Accessing Thunderbird via JDBC from my favorite SQL client was so convenient. No messaging app search is even remotely close to what a simple SELECT/WHERE can do. Old Skype versions also stored chat info in an SQLite db. I wish I'd still have SQL access to my messages.

Slack is way worse than Teams. I honestly rather dislike both and rather use email only, but will pick Teams over Slack any time.

This is a great observation. I've mostly thought of it, not in relation to AI, but in relation to the way Apple and to a lesser extent, Microsoft, act like they are the owners of the computers we "buy." An update will be installed now. Your silly user applications will be closed by force if necessary. System stability depends on it!

The modern OS values the system's theoretical 'system health' metrics far above things like "whether the user can use it to do some user task."

Another great example is how you can't boot a modern Mac laptop, on AC power, until it has decided its battery is sufficiently charged. Why? None of your business.

Anyway to get back on topic, this is an interesting connection you've made, the software vendor will perhaps delegate decisions like "is the user allowed to log into the computer at this time" or "is a reboot mandatory" to an "agent" running on the computer. If we're lucky we'll get to talk to that agent to plead our case, but my guess is Apple and Microsoft will decide we aren't qualified to have input to the decisions.

An example of where this is going is Apple's so-called "System Integrity Protection"[1] which is essentially an access level to system files that's even higher than root. It's Apple arrogantly protecting "their" system from the user, even from the root user:

    System Integrity Protection is designed to allow modification of these protected parts only by processes that are signed by Apple and have special entitlements to write to system files, such as Apple software updates and Apple installers.

Only Apple can be trusted to operate what is supposed to be your computer.

1: https://support.apple.com/en-us/102149

Which is why I love my freebsd installation (and before that Alpine Linux) and why I develop on a VM on macOS. I can trivially modify the system components to get the behavior that I need. I consider macOS as a step up from ChromeOS, but not a general purpose computer OS. Latest annoyance was the fact that signing out of Books.app signs you out of the App Store (I didn’t want epubs to be synced).

That's no reason to not discuss potentially cool ideas, unless you think their input is so indispensable that any debate is futile without them.

> Now, a computer has its own mind and agency, and we "request" it to do things and "communicate" with it, and ask it to run this and don't run that.

FWIW this happens what happens with modern steering wheels as well. Power steering is its own complicated subsystem that isn't just about user input. It has many more failure modes than an old-fashioned, analog steering wheel. The reason folks feel like "Mr. Computer" has a mind of its own is because of the mismatch between user desire and effect. This is a UX problem.

I also think chat and RAG are the biggest two UX paradigms we've spent exploring when it comes to LLMs. It's probably worth folks exploring other UX for LLMs that are enabling for the user. Suggestions in documents and code seem to be a UX that more people enjoy using but even then there's a mismatch.

I've yet to see any AI/LLM produce code that withstands even basic scrutiny.

Their website UI is great. Discord is nigh unusable

NC DMV replaced their regular forms with a chat bot and it's horrible. Takes forever to complete tasks that used to take less than a minute because of the fake interaction and fake typing. Just give me a damn form to pay my taxes or request a custom plate.

Email has the stigma of all the junk/grey mail, spam and scam attempts that come in via it - people want to not have to filter through as much of that and for the most part these chat apps solve that problem.

It doesn't help that Outlook's search capabilities have gotten effectively useless - I can type in search terms that I'm literally looking at in my inbox and have it return no results, or have it return dozens of hits without the search terms involved at all. I don't have that problem with Slack or Teams.

However, I think you are right overall on email being better overall for what people end up using chat apps for.

My preferences are the opposite, but my mental frame is more about utility than about safety. I'm not worried about someone fishing for something I said that could be construed as commitment or admission - they can just as easily do that with e-mail[0]. For me, conversations can be extremely valuable, and I gravitate towards people and places where that's a common case. HN is one of such places - the comment threads here are conversations (half-way in form between chat and e-mail), and they often are valuable, as people often share deep insights, interesting ideas, worthwhile advice and useful facts. Because they're valuable, my instinct is that they need to be preserved, so that myself and others can find those gems again, or (re)discover them when searching for solutions, or read again to reevaluate, etc.

So now imagine such (idealized) HN threads transplanted to Discord or Slack. Same people, same topics, same insights, just unrolling in the form of a regular chat. All that value, briefly there to partake in, and then forever lost after however much time it takes for it to get pushed up a few screens worth of lines in the chat log. People don't habitually scroll back very far on a regular basis (and the UI of most chat platforms starts to rapidly break down if you try), and the lack of defined structure (bounded conversations labeled by a topic) plus weak search tools means you're unlikely to find a conversation again even if you know where and when it took place.

That, plus ephemeral nature of casual chat means not just the platform, but also some of the users expect it to quickly disappear, leading to what I consider anti-features such as the ability to unilaterally edit or unsend any message at arbitrary time in the future. It takes just one participant deciding, for whatever reason, to mass-delete their past messages, for many conversations to lose most of their value forever.

--

[0] - Especially that the traditional communication style, both private and business, is overly verbose. Quite like a chat, in fact, but between characters in a theatrical play - everyone has longer lines.

Yeah this is part of why RTO is not an entirely terrible idea. Remote work has these downsides -- working with another person over a computer link sucks pretty hard, no matter how you do it (not saying WFH doesn't have other very real upsides).

> But, I don't think sticking to the chat window is the best way to interface with what it delivers. You almost certainly want to be much more actively "hands on" in very domain specific ways with the artifacts produced.

Yes, this is what I've also tried to hint at in my comment, but failed part-way. In most of the cases I can imagine chat interface to be fine (or even ideal), it's really only good as a starting point. Take two examples based on your reply:

1) Getting a car ride. "Computer, order me a cab home" is a good start. It's even OK if I then get asked to narrow it down between several different services/fares (next time I'll remember to specify that up front). But if I want to inspect the route (or perhaps adjust it, in a hypothetical service that supports it), I'd already prefer an interactive map I can scroll and zoom, with PoIs I can tap on to get their details, than to continue a verbal chat.

2) Ordering food in a fast food restaurant. I'm fine starting it with a conversation if I know what I want. However, getting back the order summary in prose (or worse, read out loud) would already be taxing, and if I wanted to make final adjustments, I'd beg for buttons and numeric input boxes. And, in case I don't know what I want, or what is available (and at what prices), a chat interface is a non-starter. Interactive menu is a must.

You sum this up perfectly:

> You almost certainly want to be much more actively "hands on" in very domain specific ways with the artifacts produced.

Chat may be great to get that first artifact, but afterwards, there's almost always a more hands-on interface that would be much better.

> Typing "make the bar a bit more like a fizzbuzz" in some textbox is awful UX compared to, say, clicking on the "bar" and selecting "fizzbuzz" or drag-and-dropping "fizzbuzz" on the "bar" or really anything that takes advantage of the fact we're interacting with a graphical environment to do work on graphics.

That assumes that you have a UX capable of determining what you're clicking on in the generated image (which we could call a given if we assume a sufficiently capable AI model since we're already instructing it to alter the thing), and also that it can determine from your click that you've intended to click on the "foo" not the "greeble" that is on the foo or the shadow covering that part of the foo or anything else that might be in the same Z stack as your intended target. Pixel bitching adventure games come to mind as an example of how badly this can go for us. And yes, this is solvable, Squeak has a UI where repeatedly clicking in the same spot will iterate through the list of possibilities in that Z stack. But it could also get really messy really quickly.

Then we have to assume that your UX will be able to generate an entire list of possible things you might want to be able to to do with that thing that you've clicked, including adding to it, removing it, removing part of it, moving it, transforming its dimensions, altering its colors, altering the material surface and on and on and on. And that list of possibilities needs to be navigable and searchable in a way that's faster than just typing "make the bar more like a fizzbuzz" into a context aware chat box.

Again, I'm not arguing the chat interface should be the only interface. In fact, as you point out we're using a graphical system, it would be great if you could click on things or select them and have the system work on too. It should be able to take additional input than just chat. But I still think for iterating on a fuzzy idea, a chat UI is a useful tool.

Oh, apologies, I meant my post to be a highlight of how I agree with you! Your post is great!

Agreed.

I'm actually in an awkward position where I was very supportive of RTO two years ago, but have since become very reliant on some things I could not do with a rigid RTO policy.

Regardless of RTO or WFH, patience and persistence remain vital qualities.

I think this is fair. And I should be clear that I'm not so worried about someone digging to find something stupid I said here on HN. Or in a chat. I'm more thinking about people that are afraid of saying something stupid, to the point that they just don't engage.

I think my mental model is more for chat rooms to take the place of coffee room chats. Ideally, some of those do push on something to happen. I'm not sure that forcing them into the threaded structure of conversations really helps, though?

Maybe it is based on the aim? If the goal is a simulacrum of human contact, then I think ephemeral makes a ton of sense.

I also kind of miss the old tradition of having a "flamewars" topic in newsgroups. I don't particularly love yelling at each other, but I do hate that people can't bring up some topics.

(I also miss some old fun newsgroups. I recall college had Haiku and a few other silly restrictive style groups that were just flat fun.)

In Slack people don't even consistently use threads, because they are not forced to, so conversations are strewn all over the place, interleaved with one another. Slack has no model of a discussion in the first place.

So you mean like collaborating on a document? Modern word processors are versioned, or you can use text and your own VCS, same as with your code.

Is your issue that you want to discuss the thing you are collaborating on outside of the tool you are creating it in?

This feels inline with my point? Versioning of documents is better done using other tools. Correspondence is fine over email.

We have some tools integrated with email to help version control things. But the actual version control is, strictly, not the emails.

It's the opposite in my experience, it's the best parts of IRC and the history is gold. Storing things in Slack is one of the most useful bits of it. I've seen several multi-billion dollar companies built most of their collaboration across offices around Slack.

This is, to put it mildly, a minority opinion. I don't hate Teams as much as most people do but my old (big and small) companies had both Slack and Teams and about 40% of employees had Teams statuses of "ping me on Slack I refuse to use Teams".

Yes, you'd need something that is more involved than a textbox, but this is/can be part of AI research too: computer vision is a very old topic in AI research after all.

About how the exact UI will be for multiple objects, this is something that multiple professional tools - like 3D engines or editors - already do. A common solution (aside from the multiple click you mentioned) is to use a modifier key like Alt+click to show a list of the items under the mouse. An AI system could also show alternative interpretations of what is clicked.

> Again, I'm not arguing the chat interface should be the only interface.

The main issue here is that current AIs are trained using chat-like interactivity at their core with everything else being a "wrapper" around the chat parts, when it should be the other way around.

how? scrolling up a conversation takes hours, this alone makes me cry if i have to use it

The idea of chat interfaces always seemed to be to disguise available functionality.

It's a CLI without the integrity. When you bought a 386, it came with a big book that said "MS-DOS 4.01" and enumerated the 75 commands you can type at the C:\> prompt and actually make something useful happen.

When you argue with ChatGPT, its whole business is to not tell you what those 75 commands are. Maybe your prompt fits its core competency and you'll get exactly what you wanted. Maybe it's hammering what you said into a shape it can parse and producing marginal garbage. Maybe it's going to hallucinate from nothing. But it's going to hide that behind a bunch of cute language and hopefully you'll just keep pulling the gacha and blaming yourself if it's not right.

> scrolling up a conversation takes hours, this alone makes me cry if i have to use it

Funnily, this is the exact same issue I have with Slack.