Fig: Visual Apps and Shortcuts for Your Terminal
withfig.com
withfig.com
We were planning on launching on HN later on, so this caught us a bit off guard. (As someone noted, our 'Fig' icon is, in fact, an emoji pear). Still we're super excited to share what we've been working on.
Fig lets you connect web apps directly to your terminal. You can use Fig like a browser to get quick access to sites like Github, Stack Overflow, or Notion. You can also run apps built on the Fig.js runtime that integrate directly with your terminal. We want to be a low-cost abstraction. Use a Fig app when it's useful, drop back down to the shell when it's not.
I just wanted to respond to a couple of points.
The app is actually written in Swift: we're using a WKWebView under the hood but the majority of the codebase is native. Also because we aren't built on Electron, we don't need to bundle v8 and node along with the app, so the binary is pretty small (12mb).
Fig is extensible. The apps shown on the website (git, curl, and finder) are just a few examples of what is possible. You can check out the documentation at https://withfig.com/docs and build your own.
Fig works with the tools you already use - we integrate with any terminal emulator (iTerm, Terminal.app, Hyper, Alactritty, etc.). Previous attempts at building GUI terminals have required throwing away 50 years worth of tooling and transitioning to a new application entirely. Fig is built around the premise that in order to upgrade the terminal, changes must be backwards compatible.
Happy to answer any more questions and really appreciate the feedback we've gotten so far.
Also, (I've already written this on the TypeForm, but) I would like if Fig spits out information that can be useful to stdout/stderr. For example, user interaction can go to stderr and the result (I guess user commands?) can go to stdout. I understand this might be a bit hard as I guess Fig is working asynchronously - but maybe changing so that people can build on Fig with shell scripts might be better.
Thanks!
I was inspired to use web technologies for building the UI by this discussion (https://lobste.rs/s/vrb7qh/web_as_gui_toolkit). Ultimately, I want to port Fig to Linux and Windows, so having a UI layer that works cross platform is useful. But it would be very cool to enable access to native UI directly. (I'd love to chat with you about how this could work.)
Outputing to stdout and stderr doesn't happen right now, but is on the very near term roadmap. The ultimate goal is for web apps to slot in seamlessly to shell workflows, so getting this right is really important.
Thanks for your comments!
Can you operate the GUI entirely with the keyboard?
If not, I think it would be great if you could do things like:
- Use Ctrl+Tab to switch tabs.
- Use Tab to cycle focus over inputs.
- Use Keyboard Mnemonics (underlined letters) to focus on specific inputs.
If Fig can already do these things, I would update your demo video to show that because switching between CLI and GUI is very easy when you don't have to constantly pick up the mouse.
(Oh, didn't notice this was Mac only. Ewww. (Sorry.) I hate macOS precisely because operating it's GUI with a keyboard is the most painful experience of any OS.)
You can launch apps, search your shortcuts and toggle focus between the terminal and Fig all without touching the mouse. Our global hot key is CMD+I.
Each Fig app also has its own shortcuts. A few of the conventions we are trying to enforce across all of them are J and K for moving between inputs (tab also works) and the keyboard mnemonics you mentioned.
BUT if these visual additions didn't require me to reach for the mouse, _and_ were design with keyboard interaction as a primary input not an "well yeah you can also...." then yeah, count me as intrigued. Would love to play with it.
related note: the signup form doesn't work when you hit enter (single input forms usually do) and when you tab to highlight the submit button the halo is almost imperceptibly small.
I think that merging CLIs and GUIs have a great potential.
GUIs are superior than CLIs on interaction because it gives context of the current state and visual cues. (And no, TUIs aren't CLIs nor are they better than GUIs.) However users still use CLIs - the biggest advantage that CLIs have is that it allows various programs interact with each other, e.g. via piping. That's why we have CLI programs that's sole purposes that are communicating with GUI programs, for example almost every programmer's text editor ships with a binary that can i.e. reading from stdin, opening an temporary file, and spitting out to stdin (or at least gives the capability of doing that) so that we can use it in e.g. moreutils vipe.
It seems Fig is an product that allows the reverse, e.g. tying GUIs to CLIs so that people can use git, curl or other CLI programs in a more interaction-friendly way. I think this is has a great potential, if it's rightly executed (i.e. hopefully doesn't use Electron...?)
PS: The argument that 'every programmer knows how to use CLI, so this isn't needed' is just proving the point - programmers deserve better than an plain-text 1970-era interaction, yet we have to use the Terminal daily to accomplish something.
I think the example for this was the wget gui.
My take on this is that for beginners this is really useful. It can also help show you new options that you might not have been aware of. (Have you read the full man page?)
> I think the example for this was the wget gui.
Yeah, that's true, but I think it'll be easier than binding GUI to the CLI.
The reason CLIs could get this usefulness was because it mixes up user interaction with it's programming interface (which is ironically what people most hate). If you want to make a CLI program, you almost need to spit out useful information to stdout, which means I can extract info from sed. GUIs are much harsher to extracting information and there are some solutions like AppleScript, but it doesn't fly.
Which means, exposing the CLI's capabilities to GUIs are much easier than exposing the GUI's capabilities to CLIs. While Fig isn't taking this route, one could write an man-page parser (like how fish does for it's completion) and expose CLI functionality automatically and increase it's usefulness with human annotations.
> My take on this is that for beginners this is really useful. It can also help show you new options that you might not have been aware of. (Have you read the full man page?)
Yeah, agreed.
Something like an application called "Flow" where you drag the 1-window GIMP into Box A, then a photo-cataloguing app into Box B.
I could also see this being something doable from a system menu. You see a list of open applications and create a visual linkage/workflow between them.
I've also wanted a Wayland compositor feature where you drag data from 1 application to another, and the compositor jumps in to offer how to transform the data between them. Say if App-A only offers MP3s, and App-B only accepts FLAC, the compositor could trigger an app to negotiate transforming/re-encoding that data between apps (and then offer to App-B).
I have some bad, contrived examples here.
Maybe it's because the system that got it the most right with the Lisp machine, and nearly all subsequent attempts to reinvent this particular wheel turned out suspiciously square...
Some of the other examples like changing directories and the git client are less interesting for me - if I wanted to actually replace the CLI with a GUI there are better options.
I signed up for early access.
Is it a small web browser embedded into the terminal window? Or it's a different thing? No idea.
GUI wrappers for common tools? How do you create a GUI wrapper for 'bg'? With a form and 1 button named "Run"?
Direct link: https://withfig.com/video/final.mp4
If it really is just "my bff from high school that works at a FANG installed my software on their own personal time on their on personal laptop", then yeah, get rid of it.
But somewhere between one person at a FANG using the software professionally, and everyone at said FANG using the software (eg an HR ERP system like Workday), is an individual's personal threshold for what "used by a FANG" means to them. As long as it's reworded to be represented honestly then I'd keep it. FANGs are the gold standard for a reason, and the social proof gained by having your software used there is valuable to the segment of the population that gives it value. (The intersection of "the segment of the population that gives it value" and your target market, may (or may not) be an empty set, however.)
For instance, code signing and notarizing a Mac app is a huge pain. It's not the kind of thing I do all the time, but it took quite a while to figure it out. I spent a few hours piecing together StackOverflow answers, assorted blog posts, and the threads on Apple's Developer Forum before I got it to work. It would be great if this workflow could be encapsulated an app.
Furthermore, a closed-source solution is a non-starter.
The fish shell has an interesting feature where it parses man pages to autocomplete commands.
Side note: I think the title should reflect the name of the service, Fig.
We worked towards automatically generate the UI from man pages (prioritized from examples found online) rather than manually developing each tool. As a student project we did not get very far.
[1] http://www.mi.fu-berlin.de/wiki/pub/SE/ThesisCommandLine/Ski...
Rather than being 'smart' and automating everything, we want to make developing apps really easy and familiar.
I'm curious what the biggest challenges were for you with the project? Maybe we could build on your research.
- What is the best architecture to enable this? I think we struggled a lot with wanting to hook on the shell level where the commands are managed, the UI client where the user interface would have to be shown and terminal emulation where it is all key strokes and cursors.
Today I believe that this would really need something like the Language Server Protocol being implemented in bash itself. Today we have bash completion scripts, but still not something as comprehensive as needed.
- How to separate everything into reusable blocks? For instance extracting parameters from man pages, storing as generic config files, whether to offer a DSL for designing the UIs, etc. We did not want to be stuck with one particular terminal, such as KDE's Konsole (for which a student did another prototype [1] in German).
[1] https://www.inf.fu-berlin.de/inst/ag-se/theses/QuintelaGarci...
Two reasons why I would download this but not a full on GUIs for things:
1. There's a long tail of CLI tools I use just rarely enough that I can't justify downloading a whole application for something. I just don't need to run awk or sed that often. But if you aggregate "all terminal commands I need to Google usage for", then that adds up just enough to download a helper.
2. There are contexts in which I can't use a GUI. For example, sometimes I need to SSH into a headless server and update a Git repo or do something with sed and awk on a giant pile of logs that I don't want to transfer to my local machine.
At the same time I too once had to learn my tools, and I can empathize with those that just want to quickly get to work and don’t want to memorize every single command-line option, whether this tool uses one dash or two dashes, or single letters, whole words, was it a capital “A” or a lower case “a” to do the thing I want. Personally I won’t be using fig, but I could see why someone might try it. If it helps new developers learn the command line, or helps them get to the meat of working with code without feeling hindered by what they perceive as this old archaic interface, but they want to learn this thing eventually, there’s probably some value in that.
It's interesting to see a hybrid of a console and a GUI. For me I can see usefulness beyond a man page or Google search to see what flags are available for a command and then select flags. Plus there's benefit for users who are new to a terminal. I think we'll see more terminal/GUI hybrids like this (the Darklang "canvas" is an example).
Having both provides a smooth skill ramp for users. They can start using the GUI and over time they learn the analogous command line interface.
A GUI is also superior for discoverability compared to a command line interface even for experienced users.
Also, Fig is entirely extensible/customizable. This is probably the part I'm most excited about: anyone can build their own apps. All of the example apps on our site are written with the same API that is exposed to developers. (https://withfig.com/docs)
There are tons of CLI tools for which I've burned pretty much every flag that I'll ever need into my muscle memory. But there are far more tools that I use only ocassionally -- like mysqldump -- where I have to dig through a manpage or tutorial just to get basic tasks done.
Something like this built into my terminal would make my life so much easier. It's almost like a quick reference card or cheatsheet, except it's totally interactive.
Also, just to clarify, Fig isn't a terminal emulator itself. It attaches to whichever one you currently use.
As it is, I am a manager myself and looking at standardising some of our toolchain ahead of onboarding around 8 new engineers in September (4 of who will be graduates so might benefit from tools like this) and I gave up with the idea of this when I couldn’t extrapolate how we would use and integrate it into our existing workflows.
Frankly, it was frustrating to find something that went from “ohh this might be useful” to “I’ve read their content and I still have no idea how this thing works”.
I guess they're not that polished yet as they were planing to do a Show HN...
You're exactly the type of person we're trying to help, so we clearly need to communicate our value prop better!
If you have some time to chat, I'd love to talk. My email is matt [at] withfig.com
[1] I can't claim that without testing, but it's a good possibility when it comes to Electron.
No point using a double negative product.
> the landing page is so hyperbolic
Well its from the typical startup launch playbook:
Humaans + Flat UI + Emojis + "FAAMNG company testimonials" + "Contact Us/Sales" = 75% VC backed bullshit.
I'm aghast at the level of toxicity and quick-judgment in the hacker community. It's really disappointing.
Keep doing your thing! It's a good idea!
Secondly, this is a stupid idea. If you want to do something like this to help folks learn the CLI, a tool like SMIT/smitty (https://en.wikipedia.org/wiki/System_Management_Interface_To...) is the way to go.