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