Every few weeks Pi hits #1 here and I quietly grumble "mine does that too, but with lovely graphics.", so I'm saying it out loud: <a href="https://github.com/juggler-ai/juggler" rel="nofollow">https://github.com/juggler-ai/juggler
Like Pi, it's plugins all the way down, provider-agnostic, minimal system prompts, threaded sub-agents, code-mode, multi-client remote sessions, worktrees, a context window you can actually see and edit, etc etc
Where Pi is way ahead is the plugin ecosystem, and that takes people, which is hard to get amid the current deluge of agent action. So if there's any spare oxygen trailing off this thread, I'd love any Pi-heads who fancy a bit of GUI action to come and kick the tyres..
My personal quiet grumbling is that everyone got on the TUI bandwagon without any rational reason. I find it borderline psychotic. Or maybe humans are much more like sheep than we care to admit: we just follow the flock into the (UI) ravine. So your GUI is a nice escape.
That doesn't mean you need a TUI! Juggler runs in headless terminals and VMs - you run it as a headless server process, and it serves the exact same desktop GUI via HTTP to any number of clients
It does seem like devs are splitting into the TUI and GUI tribes. Like tabs and spaces. We will probably never reconcile our differences or learn to empathise with the other side.
> And to be honest: what do you even need from a harness\agent for it to have a gui?
Oh, it's just so much nicer! Personally I'm a graphics/typography nerd, so just having nice fonts, smooth movement, use of sizes, colours and graphics to differentiate and display types of information...
Some people obviously don't care about this kind of look and feel nicety, but even so a GUI has so many more opportunities for displaying information in a clear but dense way.
You can choose any font you want for your terminal, but only one at a time!
The native format of LLM interactions is markdown, and showing that in a terminal is a poor imitation of what it looks like rendered properly.
An interesting thing you can do in juggler is ask the LLM to reply in HTML instead of markdown, and they can then do things like illustrate points visually for you. LLMs are actually great at being able to express things visually to the user, but being stuck in terminals so much, people haven't really leaned on that very much
I won't say Pi looks particularly impressive, but for example OpenCode looks beautiful to me and I prefer it to any graphical interface. The screenshots of your tool are nice but they feel like too much. With a good TUI like OpenCode and even Pi (which is decent) I fell like the code is front and foremost.
> And to be honest: what do you even need from a harness\agent for it to have a gui?
Nothing absolute that I couldn't live without. But TUI is essentially a design written for the lowest common denominator. It doesn't matter that I have had high resolution displays for years, average TUI is designed as if I'm using computer older than me.
I live in an office when I'm at work. Doesn't mean it's a great experience.
I love the terminal for terminal things. I'm not convinced agenetic coding is best implemented in a terminal - for it to work well, you're basically reinventing a toolkit wheel. Why not just use a nice graphical toolkit? It feels a bit like the current trend for pixelated graphics - both retro and worse.
if only there were a way to tunnel web servers over that very SSH connection and use a proper web UI, something HN has always been obsessed with.... oh well i guess we're stuck with a VT100! :( there's nothing we can do!
I'm currently using an R-studio server session running on a server half way around the world, via a gui web interface. It's fast and smooth. How on earth could that be?
I've specifically designed juggler to do exactly that.
You run it on some headless machine, and point your browser at the HTTP server it creates to see the full GUI. It uses Yjs to make that connection as efficent as possible, and it works great.
The desktop app is literally doing the same thing internally - it runs a headless server process and serves the GUI to its own window. But you can stretch that over a network and it's the same experience.
I can even connect to it via a TURN server, from my phone on a cell signal, and although it's not as snappy as running locally, it works pretty well.
Or maybe people genuinely like TUIs? Most folks came of age after the TUI had already lost popularity to the eye candy and only recently learned the merits of the terminal. I personally have always loved a good TUI and enjoy the terminal. I can’t count the number of people who worked in a TUI and were pushed to a modern GUI say (usually in the 00’s) how much more productive they were in the TUI version.
What would you say are the merits of the terminal that a TUI encapsulates?
My opinion is that TUI is just a GUI with less fidelity. Being composed of text characters provides no additional benefit other than a retro style. The benefits of the terminal are outside of TUIs - composing scripts, piping data, bash etc.
Text interfaces can offer precision and breadth of tooling that guis don't.
I do a fair amount of CAD so I'll use that example. Nobody who uses CAD professionally is clicking all the little buttons for tools. They're using commands, shortcuts, scripts, etc.
A GUI is slow and clunky. A textual interface, once learned, has way more degrees of freedom.
I don't think anyone referring to GUI means 'no commands/shortcuts/scripts', like, all of those that all CAD programs are GUIs that have commands, shortcuts, etc.
My two cents is that having all of your text be monospaced is not really ideal for agentic workflows where you do in fact read a lot of prose and in the future may want diagrams, rendered from a full browser's capabilities, etc.
I think I like the aesthetic of using a TUI because it makes me feel more like whatever 'real programmer' means to me... but I recognize its also cope.
> They're using commands, shortcuts, scripts, etc.
Yes, power users often use shortcuts and automation, but how is that an argument against GUIs?
It simply depends a lot on the actual task. Certain things absolutely require a (high fidelity) graphical interface. Other things can be done just as well (and with less distraction) in a simple TUI. You can't generalize.
have you ever used, for example, vs code or Excel? both have robust GUI and keyboard capabilities. Andexcel has vba and now python and other scripting, and vscode is eminently extensible.
One small example - ChatGTP desktop intercepts highlighted text selection with "Ask ChatGTP" bubble. I have my own app that materializes a menu on highlighted text, but ChatGTP blocks it. No issues with that in the terminal. I am not a terminal junkie, but these opinionated paper cuts are annoying.
Vim keybindings, one of the most powerful and widely supported ways of interacting with information, basically impose the "grid of text" nature that define TUIs anyway, so my message prompt has to look like a terminal. The rest of the UI can be whatever, but grid-of-text works well for structured output, especially code blocks, as well.
TUIs compose with tmux. Pi's homepage says "use tmux" twice on it. It fits right into an already-mature ecosystem including a clipboard (powered by Vim visual / line / block mode) and easy integration with shells, editors, and other tools. GUIs generally have to re-invent all those wheels (tabs, splits, sessions, etc.) and it never integrates as well with other tools in a totally cross-platform way.
> What would you say are the merits of the terminal that a TUI encapsulates?
GUI scripting is still not a thing today. That's the biggest issue with GUIs.
Plus the mouse is genuinely bad for ergonomics.
Plus if you type _fast_ then TUIs are a great starting point.
Plus what's the equivalent of scrollback for a bunch of mouse clicks?
Plus TUIs are much more I/O efficient, which means running them over ssh/mosh/whatever is a great option.
Plus the shell is a programming language -- the GUI isn't just hard to macro-record/script: it doesn't even have a programming language you'd use for that.
All the agentic coding models are multimodal and can understand pictures quite well. I routinely paste in primitive paint drawings to augment my textual descriptions and show an agent what I mean, and it seems pretty effective. This can be to rough out a UI layout but it can also be useful in pure backend work drawing diagrams, or in any domain where code manipulates geometric data.
For an example, see my MSPaint drawings in the README (scroll near the bottom) for this tiny little project: <a href="https://github.com/rspeele/meshorient" rel="nofollow">https://github.com/rspeele/meshorient
I redrew those for the README but IIRC, I drew something similar when explaining how the feature would work to the agent.
And in reverse, after describing an architecture or an algorithm to it, I'll sometimes ask it to draw a diagram for me to demonstrate its understanding. If it draws the picture in line with what I intended, I conclude that it has gained the necessary context to proceed. If not, I know I explained something wrong or at least insufficiently and need to provide clarification. There are some domains where a picture is worth a thousand words.
It also helps cut through the Claudese. "Your decision is needed for one edge case, found by the gate. When a T-joint meets an endcap that the mesher solves by a fan, should this bisect a fan slice or raise a warning?" I'm sorry Claude, I am not from Missouri but you are going to have to Show Me this one with a picture.
Of course you can save pictures to files and open them with external tools, but it's nicer to have them inlined into the chat history when that's exactly what they are: part of the conversation.
It's not just text, it's structured text. It often contains tables, sections, lots of things that can be drawn much more nicely.
And in juggler (and probably other harnesses too) the LLM can reply in HTML. So if I'm planning e.g. some UI changes, I might ask it "show me what this button will look like" and it'll reply with a picture of that thing in its response. No temp files to open or clean up, and fewer tokens burned
i love vim and i love vim-tmux-navigator keybinds letting me navigate quickly between panes in my terminal: ctrl-{h,j,k,l} to switch panes. i love that tui agents fit right in among my shells and vims. i love that my setup works just as well on my machine and on any remote machine over ssh or mosh. i’ve been working like this since 2012. although i did start using vscode for $DAYJOB since our devex team supports it (has good vim keybinds at least)
Our architecture team started with vscode and windows because it’s “how it’s been done” but within a year they all migrated to ghostty or another terminal on Mac because it’s so much faster and efficient.
im with you. I have tried all the TUIs and immediately bounce off of them due to how utterly awful even just basic operations like text editing are. I use Vscode copilot chat because in the before-times I was perfectly happy with vscode. I cannot comprehend how people can now give all of that up for TUIs. It also has its Agents Window, Copilot CLI etc... and you can use any api keys, subscriptions etc... that you want.
And, of course, most of the tools have created their own GUIs anyway, which are far worse than VS Code (even when they've forked VSCode itself!)
I think the "borderline psychotic" phrasing is apt.
Pi is a great project, and people love it for good reason, I have nothing negative to say about it or its fans. I'm just trying to do something that appeals to the more GUI-oriented folks. And yes, I'd really love to know if there's something that's making people bounce off the product, because it may be trivial to fix!
I grew up running and calling dialup BBSs, learning to program in the MS DOS shell world with QBasic and Turbo Pascal "IDE"s, dialing up and later telnetting into a Lynx browser (early on when I couldn't afford a PPP link with lawn mowing money).. the "terminal" and thereby TUI applications (they weren't called that at the time as far as I know, but that's definitely what they were) are home, for at least me. I just wish more TUIs had single keystroke hotkeys (indicated by the hotkey's letter in the menu item title being a different color or intensity) like the old BBS and other menus. I could login and download a QWK packet quicker than the time it took for the modem to finish the DTMF tones. I'm excited about how many new things allow me to stay in the interface my brain formed around. YMMV
I don't actually know what you're referring to, but from context I can guess that you're referring to something like the Juno dialup "at&t" links they used to actually send the emails. The PPP L/P were encoded in the .into files and they were great free PPP links while they lasted.
Most GUIs can't be navigated by a fluent keybind system. And if they do have keybinds, they are their own, and not consistent with what others use, or you can't modify them. And then there is the issue of making it hard to run multiple copies at the same time (I can't just click the app icon again to start a second copy, Juggler does solve for this though), nor can I keep two copies together side by side easily. Being able to copy and paste text is hit or miss.
I love good GUI apps. They are hard to do well.
Juggler, for example, already collides with a Keyboard Shortcut I use across the desktop, so CMD + J can't be used. It also uses CMD + / for keyboard shortcuts? Tha's a choice. It doesn't respect Mac's preferences/settings shortcut (CMD + ,)
You can be on a chat window, and there is no way without using the mouse that I see where you can start typing into the chat box. Juggler tells me to type / and I can run a command. I type / and nothing happens. What that really means is I have to use my mouse to put the cursor in the small chat box down below.
This isn't to say Juggler is bad. Rather, it's got a long way to go for the GUI to be something that has the fluency of something like vim.
TUIs generally have to solve for that. You have to offer up those features. You can't rely on laziness. So at the very least, there generally are keyboard shortcuts and they need to be obvious.
Feel free to think that people don't have a rational reason for TUIs, but it buys you a lot for free. And this isn't an indictment on Juggler. It works. It's functional. It doesn't feel natural, nor does it respect conventions.
I totally get it. Lots of people, like you, love to set up their perfect custom, key-driven environment, and tune everything just how they want it. These tend to be the TUI fans.
I've never felt that urge, I've always been happier using Visual Studio / Xcode / VScode with default key bindings, and focused on other things. I'd rather click things inefficiently with a mouse than invest effort learning keypresses. Neither of us are wrong or right, but I think I'm trying to cater for my tribe on this project!
fwiw, you can cater to both. It's not an exclusive thing. Having a gui is not bad. It's just effort to make it good. Take for example the CMD + , not opening settings/preferences on Mac. That's convention on the platform.
> I totally get it. Lots of people, like you, love to set up their perfect custom, key-driven environment, and tune everything just how they want it.
No, you don't "get it." Like me? I don't want to set things up. I don't want to customize. I thrive off convention. And there are apps that follow these conventions. They do this out of respect for people who enjoy the defaults they enjoy elsewhere in other applications.
> I've always been happier using Visual Studio / Xcode / VScode with default key bindings
That's not true though, because you don't even use the same default/convention key bindings they use. By doing things your own way, you are making it so it's harder for your users to adopt your application.
> "mine does that too, but with lovely graphics.",
But it doesn't. You don't care about the little things, so how are you going to get the bigger things correct?
Listen, it's great that you built a tool that you love. I love doing that, too. But if you want users, you have to respect them. And that means making it easier for them to use your app.
And if our app just doesn't work because / doesn't do what it says it's going to do, that's an issue. And if your app doesn't allow for customizing keyboard shortcuts, it's disrespecting users who have those set for something else.
> but I think I'm trying to cater for my tribe on this project!
Just realize that tribe is juggler-ai users, or people who don't use defaults. People who are fine with default key bindings, can't effectively use your app.
I'm not a cowboy arbitrarily making up random shortcuts. A major goal here is for a user to get near-as-dammit the same UI in a desktop app and in a remote browser. So all these shortcut choices have been a compromise between:
- what different people might expect the default to be (on mac/windows/linux/all kinds of apps)
- what a browser already uses (on mac/windows/linux/chrome/firefox/safari/etc)
- what people might have overridden random window managers and custom OS shortcuts
- what tasks are common enough that they deserve an easy-to-reach/remember key in spite of other factors
- choosing groups of shortcuts where you want the keys to be related (e.g. navigation) despite some being taken on some platforms
I obviously want the least surprising UX, and if this was just an app on one platform, it'd be easier. I've had to build a multi-platform shortcut manager that changes depending on the client, while trying to also keep as many as possible constant.
And yes, allowing users to customise the shortcuts is obviously on my list, but a) I wanted to let the app settle in and make sure I've got the right data model for storing key shortcuts first, and b) other more urgent features..
BTW `cmd+/` is the default "show the key shortcuts" in most chat environments like discord, slack, teams, google docs etc. These are much more relevant to juggler's UX when it comes to default shortcuts than things like VScode!
(...but yes, I had forgotten to add a desktop-app-only binding for `cmd+,`, so thanks for mentioning that - I've sorted that out now..)
Well juggler literally does that - you run it headlessly on some machine (docker, whatever), it opens a HTTP port, and you can control it remotely with the exact same desktop GUI that you'd see if you ran it locally. (The desktop app is actually just running a headless process internally and serving it to its own window via HTTP).
I work over SSH often from various other OSs, TUIs don't need any additional abstractions to make that work, I just SSH in from any computer/OS and everything works. All I need is SSH and the terminal based apps. It's not psychotic, it's literally a feature that cannot be found with GUIs.
hate to make a "me too" comment but TUIs working over ssh is what makes them so great. Also, when combined with something like screen it's icing on the cake.
julesrms · · focus · HN ↗
Like Pi, it's plugins all the way down, provider-agnostic, minimal system prompts, threaded sub-agents, code-mode, multi-client remote sessions, worktrees, a context window you can actually see and edit, etc etc
Where Pi is way ahead is the plugin ecosystem, and that takes people, which is hard to get amid the current deluge of agent action. So if there's any spare oxygen trailing off this thread, I'd love any Pi-heads who fancy a bit of GUI action to come and kick the tyres..
jonenst · · focus · HN ↗
KolmogorovComp · · focus · HN ↗
jon23d · · focus · HN ↗
julesrms · · focus · HN ↗
kraktoos · · focus · HN ↗
julesrms · · focus · HN ↗
konart · · focus · HN ↗
I hardly use anything aside from neovim and a browser. (okay corporate Mattermost fork and video terminal too).
For me switching between different cli\tui tools feels like a continuation of whatever I was doing, while going to something GUIsh is not.
And to be honest: what do you even need from a harness\agent for it to have a gui?
julesrms · · focus · HN ↗
Oh, it's just so much nicer! Personally I'm a graphics/typography nerd, so just having nice fonts, smooth movement, use of sizes, colours and graphics to differentiate and display types of information... Some people obviously don't care about this kind of look and feel nicety, but even so a GUI has so many more opportunities for displaying information in a clear but dense way.
konart · · focus · HN ↗
They can even show images these days.
Some of the elements can't be recreated 1 to 1 ofc, like borders with delicate margin\padding adjustment, but this is about it I think.
To each his own, yeah. From my experiment GUIs tend to overcomplicate things and display too much info you didn't need in the first place.
konart · · focus · HN ↗
experience
voakbasda · · focus · HN ↗
albondiga90210 · · focus · HN ↗
julesrms · · focus · HN ↗
The native format of LLM interactions is markdown, and showing that in a terminal is a poor imitation of what it looks like rendered properly.
An interesting thing you can do in juggler is ask the LLM to reply in HTML instead of markdown, and they can then do things like illustrate points visually for you. LLMs are actually great at being able to express things visually to the user, but being stuck in terminals so much, people haven't really leaned on that very much
maupin · · focus · HN ↗
flaunf221 · · focus · HN ↗
Nothing absolute that I couldn't live without. But TUI is essentially a design written for the lowest common denominator. It doesn't matter that I have had high resolution displays for years, average TUI is designed as if I'm using computer older than me.
epihelix · · focus · HN ↗
I love the terminal for terminal things. I'm not convinced agenetic coding is best implemented in a terminal - for it to work well, you're basically reinventing a toolkit wheel. Why not just use a nice graphical toolkit? It feels a bit like the current trend for pixelated graphics - both retro and worse.
lionkor · · focus · HN ↗
8aKXcbOAOz · · focus · HN ↗
svennek · · focus · HN ↗
KetoManx64 · · focus · HN ↗
epihelix · · focus · HN ↗
julesrms · · focus · HN ↗
You run it on some headless machine, and point your browser at the HTTP server it creates to see the full GUI. It uses Yjs to make that connection as efficent as possible, and it works great.
The desktop app is literally doing the same thing internally - it runs a headless server process and serves the GUI to its own window. But you can stretch that over a network and it's the same experience.
I can even connect to it via a TURN server, from my phone on a cell signal, and although it's not as snappy as running locally, it works pretty well.
lionkor · · focus · HN ↗
grosswait · · focus · HN ↗
almostarockstar · · focus · HN ↗
My opinion is that TUI is just a GUI with less fidelity. Being composed of text characters provides no additional benefit other than a retro style. The benefits of the terminal are outside of TUIs - composing scripts, piping data, bash etc.
idiotsecant · · focus · HN ↗
I do a fair amount of CAD so I'll use that example. Nobody who uses CAD professionally is clicking all the little buttons for tools. They're using commands, shortcuts, scripts, etc.
A GUI is slow and clunky. A textual interface, once learned, has way more degrees of freedom.
kaibee · · focus · HN ↗
My two cents is that having all of your text be monospaced is not really ideal for agentic workflows where you do in fact read a lot of prose and in the future may want diagrams, rendered from a full browser's capabilities, etc.
I think I like the aesthetic of using a TUI because it makes me feel more like whatever 'real programmer' means to me... but I recognize its also cope.
spacechild1 · · focus · HN ↗
Yes, power users often use shortcuts and automation, but how is that an argument against GUIs?
It simply depends a lot on the actual task. Certain things absolutely require a (high fidelity) graphical interface. Other things can be done just as well (and with less distraction) in a simple TUI. You can't generalize.
nchmy · · focus · HN ↗
stasomatic · · focus · HN ↗
bloppe · · focus · HN ↗
TUIs compose with tmux. Pi's homepage says "use tmux" twice on it. It fits right into an already-mature ecosystem including a clipboard (powered by Vim visual / line / block mode) and easy integration with shells, editors, and other tools. GUIs generally have to re-invent all those wheels (tabs, splits, sessions, etc.) and it never integrates as well with other tools in a totally cross-platform way.
cryptonector · · focus · HN ↗
GUI scripting is still not a thing today. That's the biggest issue with GUIs.
Plus the mouse is genuinely bad for ergonomics.
Plus if you type _fast_ then TUIs are a great starting point.
Plus what's the equivalent of scrollback for a bunch of mouse clicks?
Plus TUIs are much more I/O efficient, which means running them over ssh/mosh/whatever is a great option.
Plus the shell is a programming language -- the GUI isn't just hard to macro-record/script: it doesn't even have a programming language you'd use for that.
nilamo · · focus · HN ↗
rspeele · · focus · HN ↗
For an example, see my MSPaint drawings in the README (scroll near the bottom) for this tiny little project: <a href="https://github.com/rspeele/meshorient" rel="nofollow">https://github.com/rspeele/meshorient
I redrew those for the README but IIRC, I drew something similar when explaining how the feature would work to the agent.
And in reverse, after describing an architecture or an algorithm to it, I'll sometimes ask it to draw a diagram for me to demonstrate its understanding. If it draws the picture in line with what I intended, I conclude that it has gained the necessary context to proceed. If not, I know I explained something wrong or at least insufficiently and need to provide clarification. There are some domains where a picture is worth a thousand words.
It also helps cut through the Claudese. "Your decision is needed for one edge case, found by the gate. When a T-joint meets an endcap that the mesher solves by a fan, should this bisect a fan slice or raise a warning?" I'm sorry Claude, I am not from Missouri but you are going to have to Show Me this one with a picture.
Of course you can save pictures to files and open them with external tools, but it's nicer to have them inlined into the chat history when that's exactly what they are: part of the conversation.
julesrms · · focus · HN ↗
And in juggler (and probably other harnesses too) the LLM can reply in HTML. So if I'm planning e.g. some UI changes, I might ask it "show me what this button will look like" and it'll reply with a picture of that thing in its response. No temp files to open or clean up, and fewer tokens burned
jitl · · focus · HN ↗
ramgine · · focus · HN ↗
nchmy · · focus · HN ↗
And, of course, most of the tools have created their own GUIs anyway, which are far worse than VS Code (even when they've forked VSCode itself!)
I think the "borderline psychotic" phrasing is apt.
wookmaster · · focus · HN ↗
julesrms · · focus · HN ↗
Pi is a great project, and people love it for good reason, I have nothing negative to say about it or its fans. I'm just trying to do something that appeals to the more GUI-oriented folks. And yes, I'd really love to know if there's something that's making people bounce off the product, because it may be trivial to fix!
boie0025 · · focus · HN ↗
ljosifov · · focus · HN ↗
boie0025 · · focus · HN ↗
boie0025 · · focus · HN ↗
jasonlotito · · focus · HN ↗
I love good GUI apps. They are hard to do well.
Juggler, for example, already collides with a Keyboard Shortcut I use across the desktop, so CMD + J can't be used. It also uses CMD + / for keyboard shortcuts? Tha's a choice. It doesn't respect Mac's preferences/settings shortcut (CMD + ,)
You can be on a chat window, and there is no way without using the mouse that I see where you can start typing into the chat box. Juggler tells me to type / and I can run a command. I type / and nothing happens. What that really means is I have to use my mouse to put the cursor in the small chat box down below.
This isn't to say Juggler is bad. Rather, it's got a long way to go for the GUI to be something that has the fluency of something like vim.
TUIs generally have to solve for that. You have to offer up those features. You can't rely on laziness. So at the very least, there generally are keyboard shortcuts and they need to be obvious.
Feel free to think that people don't have a rational reason for TUIs, but it buys you a lot for free. And this isn't an indictment on Juggler. It works. It's functional. It doesn't feel natural, nor does it respect conventions.
julesrms · · focus · HN ↗
I've never felt that urge, I've always been happier using Visual Studio / Xcode / VScode with default key bindings, and focused on other things. I'd rather click things inefficiently with a mouse than invest effort learning keypresses. Neither of us are wrong or right, but I think I'm trying to cater for my tribe on this project!
jasonlotito · · focus · HN ↗
> I totally get it. Lots of people, like you, love to set up their perfect custom, key-driven environment, and tune everything just how they want it.
No, you don't "get it." Like me? I don't want to set things up. I don't want to customize. I thrive off convention. And there are apps that follow these conventions. They do this out of respect for people who enjoy the defaults they enjoy elsewhere in other applications.
> I've always been happier using Visual Studio / Xcode / VScode with default key bindings
That's not true though, because you don't even use the same default/convention key bindings they use. By doing things your own way, you are making it so it's harder for your users to adopt your application.
> "mine does that too, but with lovely graphics.",
But it doesn't. You don't care about the little things, so how are you going to get the bigger things correct?
Listen, it's great that you built a tool that you love. I love doing that, too. But if you want users, you have to respect them. And that means making it easier for them to use your app.
And if our app just doesn't work because / doesn't do what it says it's going to do, that's an issue. And if your app doesn't allow for customizing keyboard shortcuts, it's disrespecting users who have those set for something else.
> but I think I'm trying to cater for my tribe on this project!
Just realize that tribe is juggler-ai users, or people who don't use defaults. People who are fine with default key bindings, can't effectively use your app.
julesrms · · focus · HN ↗
I wish that was true!
I'm not a cowboy arbitrarily making up random shortcuts. A major goal here is for a user to get near-as-dammit the same UI in a desktop app and in a remote browser. So all these shortcut choices have been a compromise between:
- what different people might expect the default to be (on mac/windows/linux/all kinds of apps)
- what a browser already uses (on mac/windows/linux/chrome/firefox/safari/etc)
- what people might have overridden random window managers and custom OS shortcuts
- what tasks are common enough that they deserve an easy-to-reach/remember key in spite of other factors
- choosing groups of shortcuts where you want the keys to be related (e.g. navigation) despite some being taken on some platforms
I obviously want the least surprising UX, and if this was just an app on one platform, it'd be easier. I've had to build a multi-platform shortcut manager that changes depending on the client, while trying to also keep as many as possible constant.
And yes, allowing users to customise the shortcuts is obviously on my list, but a) I wanted to let the app settle in and make sure I've got the right data model for storing key shortcuts first, and b) other more urgent features..
BTW `cmd+/` is the default "show the key shortcuts" in most chat environments like discord, slack, teams, google docs etc. These are much more relevant to juggler's UX when it comes to default shortcuts than things like VScode!
(...but yes, I had forgotten to add a desktop-app-only binding for `cmd+,`, so thanks for mentioning that - I've sorted that out now..)
multiplegeorges · · focus · HN ↗
How can a GUI replicate this workflow? I know it could, technically, but not as easily.
julesrms · · focus · HN ↗
multiplegeorges · · focus · HN ↗
TJTorola · · focus · HN ↗
chasd00 · · focus · HN ↗
Fidelix · · focus · HN ↗
Cursor has this, and there are others that can attach to ssh or open their UI via a tunnel or web interface.
SSH is mighty convenient though, so I am not necessarily saying your point is incorrect.
nijave · · focus · HN ↗
sznio · · focus · HN ↗
feffe · · focus · HN ↗
unrented7977 · · focus · HN ↗
cryptonector · · focus · HN ↗
Wut?