We just merged a new chat UI, and it’s available in Cody for VS Code prerelease builds now.
Please share feedback and issues! It will ship in the next release build at the end of May, and then after that to Cody for JetBrains and Cody Web.
2 Likes
First post!
Bug: Pressing Opt/Alt+Enter submits the chat with context. It is intended to submit without context.
1 Like
I love this new direction of the chat design! I’m failing to use the Opt+> shortcut on macOS, is that supposed to be option-anglebracket or option-rightarrow?
@olafurpg That Opt+> keyboard shortcut is broken on macOS. Will find another one since that is apparently reserved by the OS.
Brooooo, why 
you were on such a roll with new features…and then…this 
Having the input at the bottom is intuitive because it’s how everybody is used to using a chat. The input is always at the bottom at the screen.
Honestly, my first reaction was to ping Ado and Justin cause I genuinely thought this was a bug.
Asides from that, putting it above the help information, actually just made it look like an image that was a new part of the “welcome to Cody” and it took me longer than I care to admit, to even find it.
I’m all for radical design ideas, but yeah, can we get a “switch”/“toggle” to put it back at the bottom? (At least while you’re testing the new layout/design)
1 Like
Heh. 
I appreciate the feedback! See the PR description at new transcript/message "stream" UI by sqs · Pull Request #4209 · sourcegraph/cody · GitHub for some more detailed reasons why we think this notebook-like flow is better. We might be wrong still, and this also might be something that users differ on. (For example, my wife still hates when iOS Safari moved the address bar to the bottom. But I loved it.)
You can switch back to the release build on the marketplace to get the old layout for another 10 days. I hope we can iterate on this design and make you love it, though.
- Agree on the help message feeling weird
- Agree on it not standing out clearly enough where you need to type
- As you use it a bit more and “try it on”, what else is painful? How can we make it better?
Please keep the feedback coming!
Followup:
Pressing enter once didn’t seem to do anything to send the chat message.
Pressing it again did this:
Once I noticed the “Ask followup” box that is not part of it…I got this:
This is incredibly unintuitive. Having to click into a completely new chat input, is cumbersome and offputting. Not to mention, the input stays in the previous chat input box, so unless you happen to physically move it to the new, you’re gonna be editing the last one (which, pressing enter to send a message has a noticable delay)
Example of what I mean
Thanks for the feedback on input focus. You can press Tab (or the keyboard shortcut mentioned, which is currently broken on macOS and will be fixed soon) to focus the followup input.
But yeah, I agree this is a rough part of the new UI and we need to work on it. Will do!
Also, might be just me on this one, but the “Run” button - looks kinda old/web1.0, plus should it not say “Send” not “Run” to align with the conversational style of the input?
3 Likes
I love the change that allows us to edit previous prompts in-place!
Some minor UI feedback:
- If new messages are to be added below the current input box, I personally think the initial welcome message should go above the input box.
- I found the new icon for Enhanced Context a tad confusing. I initially thought it was removed because of the icon change, and the new icon doesn’t look intuitive to me. Maybe a regular file clip or a plus icon would be more fitting?
2 Likes
Just thinking (spitballing, really)…How about a “Theme”/“Layout” manager where the user can move elements around (maybe a .css file or whatever would make the most sense)?
Some of this might be very subjective and unfiltered:
- Overall I think the Input box is way more discoverable
- It doesn’t feel intuitive at all to me to after submitting a message we keep the input active, have the conversation unfold below it, and then have another new “input box” appear below that. Just assume the conversation has started and I’m going to continue below. I do feel it’s an improvement to show a full edit UI in place when editing a previous message which before would jump you all the way down to the input box and I got lost more than once.
- Related to the above, if I hit enter and then enter again while response is generating it seems to fire a second request and no response is ever shown.
- I can’t discover the (send without context opt+enter) because the hotkey is only shown after I’m already pressing opt. I feel a split button with a dropdown arrow would maybe make more sense here where the default is “send” but then you can discover there’s more things you can do?
- Discoverability of lines ranges still isn’t there? I’m also really missing a way to modify an existing file range/symbol without removing the whole mention. Especially if I could click the mention and it takes me there so I can check it’s the correct range and adjust accordingly.
- Related I’m missing an explicit @here/@this. I know we pick it up automatically but sometimes I want to ask a question like
what does @this meanand not use automatic context. And the right click “add selection to chat” not only forces me to use the mouse it also doesn’t seem to work anymore with the new chat UI? - I didn’t recognize the context logo as anything. Maybe a graph symbol makes more sense (connecting the dots?). Also if that’s our primary differentiating feature make it nice and colorful if we’re using it?
- I think there needs to be some visual separation between the @ and the other buttons just like how in slack there’s a slight vertical bar between including text content | visual content | commands. Because the @ (including content) doesn’t feel related to the ctx/model selector (configuration).
- Scroll jumps up in long conversation to some seemingly random point in the chat after submitting a new message
- New mentions are always added at the end not where my current cursor is.
- I can’t redo changes (cmd+shift+z) to message input which is especially annoying since ctrl+z also jumps between different inputs (e.g. all past messages) meaning I frequently undo other unintended messages. And even if I don’t submit that edited message it still forever shows the edited message in those cases
- Run does not feel like a intuitive Action button message. Send, Say maybe, but not Run.
3 Likes
There’s a bunch of UI changes still to do here, but keep the feedback coming! Thank you so much for giving it a go.
Moving focus to the follow-up is an interesting one, because that might jump you way down to the end of the LLM response message, and then you’d have to scroll back up to read it from the top. With short messages and tall screens it does feel odd not to auto-move the focus.
I would say even for longer messages I expect the input focus to release from what I typed before. There’s simply no situation where it’s intuitive to me that after I type and hit enter if I now type again it alters my just submitted message
1 Like
I agree with @Kynlo and @RXminuS that the new UI is very unfamiliar.
-
The input box on the bottom seems way more discoverable even though the chat stream flows from top to bottom. Most (if not all) chatbot or messaging app users are used to the input field at the bottom. Positioning it at the top would appear unusual and even inconvenient for the user. Unless you have super innovative ideas that allow you to “re-educate” the user.
-
Editing chat messages in the middle of a conversation will break the non-destructive workflow. In my opinion, a non-destructive workflow is important especially with fetched context in a bound use-case. It only makes sense if the fetched context will be updated through the conversation, though it is advisable to start a new chat either. With editing message in-between a feature like thread or conversation branching would make sense.
-
Including the buttons in the text field container also seems undiscoverable as they do not look like buttons. For new users this hurts UX.
-
Switching new models between a lasting conversation should be marked with a remarkable visible note, such that the user knows that the context is set to zero.
-
Line Ranges seems also be broken as well as the
My 2cts
1 Like
Thanks all for the feeedback (@PriNova @Kynlo @RXminuS @beatrix). There’s lots of good specific things we need to improve, and we’re on it. Will post progress here.
As for the overall new way this UI works (from the top instead of single input at bottom), I know it is a change and is different from most other chats. Cody chat is kinda like a chat, kinda like search, and kinda like a notebook. The latter 2 (search and notebooks) generally flow down from the top. We might be wrong here, but if we are right, there is a lot of stuff that the search/notebooks concept will let us build that would be quite tough with the input at the bottom. For example, we’d like to start showing more intent-detection and instant results as you type, and we want to make it easy for you to refine your chat/context really easily so you can get the best result. This is tough if “edit” is modal and requires your eyes to jump between the top and bottom of the chat view.
1 Like
I think the issue here is the assumption that people are using Cody in a different way than it was originally designed (coding assistant with a fluid conversational flow, Vs notebook style input window).
I obviously don’t have the metrics or data to back up my thinking here, but the entire product revolved around being able to easily and dynamically converse with a chosen LLM to get what you wanted from your “assistant”.
All of the marketing for Cody, sets it up as an assistant, not an AI notebook (which, in my view, could actually just be an entirely different product). I’m absolutely not against a notebook style AI within VSCode, but I do feel like there has been a misstep because that could have been it’s very own product, giving Sourcegraph the edge on both the conversational style that users have signed up for, and the secondary product of notebooks (which could, of course, be expanded into a web-version to compete with other notebook services).
It might also be a good idea for you to perhaps host a Q&A/Townhall live stream or something similar (even just using stages on the discord) to hone in on how the current user base is using Cody, and where people think changes should be made, because again, although the change that’s happening is, in itself, not a terrible idea, it has basically completely changed the “soul” of Cody and turned into a different product than the one people signed up for.
4 Likes
For me, it’s not even so much that the input is at the top. I can see how that’s similar to starting a new Jupiter notebook. It’s more that when I execute a cell in that Notebook it also jumps to below where the execution result happens. This means there’s always a logical ordering to things And a focus on new information and next steps. Whereas now we keep distracting the user with UI around old info.
Similarly I find it really frustrating that I have to keep scrolling now while the response is generating.
@PriNova I actually think that the destructive chats are fantastic because you can jump back in a conversation and steer its course to a better outcome. And as long as we inject context, based on that point in time, I don’t really see an issue.
Also agree with @Kynlo that we should not make chat something it is not. There are many execution flows about a notebook that would be very different. For instance, I could run any cell out of order But they would still use variables and data set in cells below as long as they were executed before