Fig: Visual Apps and Shortcuts for Your Terminal

by DanielKehoe • 6 years ago

102 56 6 years ago

I personally don't see the point. If you want a GUI for some commands, why not just get GUI apps which do those things? Why try to bolt a GUI onto a CLI, especially one that works by pasting commands back into a CLI? You're relying on fig to develop UIs for all of your frequently used commands, and if you don't like fig's UIs for certain commands, you're SOL until they let you make your own UIs, and at that point it's basically an OS with an App Store. If you want a productivity boost from eliminating repeated commands, you're better off writing aliases or bash scripts for your personal use, in my opinion.

Side note: I think the title should reflect the name of the service, Fig.

SllX2• 6 years ago

It’s a half step between getting some Terminal functionality without necessarily having to be fluent in the Terminal. I think the idea is for it to be an option expanding choice without having to necessarily seek out a GUI that will provide an interface to all of the functionality you need. If something is missing, well the Terminal is right there.

square_usual2• 6 years ago

Given that the service seems to be aimed at developers, I don't see it as being an option for people who aren't "fluent in the Terminal". I don't see any commands they support that necessarily have to be done in the terminal, either, since such things as git, ffmpeg, psql etc have great GUIs available for nearly all use cases. If you're not a developer, you're better off downloading specific apps instead of using fig, and if you're a developer, I don't see how fig helps you over binding your own aliases or writing scripts for specific tasks.

DanielKehoe• 6 years ago

(updated the title)

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

oezi2• 6 years ago

I worked on this idea in 2003 [1] and we envisioned it to help a lot with discoverability and consequently learning curve. Our idea was more interactive in that editing in the UI would immediately be reflected in the terminal and vice versa. A power user would just type the whole command from memory but still have the ability to click a checkbox to add that rare/elusive switch. Beginners could do everything in the UI but quickly learn from seeing the command line string being built.

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

mschrage10• 6 years ago

This is really interesting! I think that the scalable approach like you proposed in your thesis makes a lot of sense, but comes at some cost to the user experience.

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.

scottfr• 6 years ago

If you want a GUI for some commands, why not just get GUI apps which do those things? Why try to bolt a GUI onto a CLI, especially one that works by pasting commands back into a CLI?

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.

mschrage10• 6 years ago

The value for me has been the ability to easily bounce back and forth between levels of abstraction. Sometimes you need the granularity the shell provides, but other times it's nice to lean back on a more opinionated workflow. Sort of like the difference between deploying with Heroku versus managing everything with Kubernetes.

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)

mahaganapati• 6 years ago

To me the logo looks like a pear instead of a fig

leetrout• 6 years ago

I think it’s the pear emoji https://www.iemoji.com/view/emoji/602/food-drink/pear

trevyn• 6 years ago

Unfortunately, it's gotten to the point where adding anything proprietary to the workflow is a liability.

29athrowaway• 6 years ago

Just a reminder that Dialog/Zenity/KDialog can be used to create "friendly" user interfaces to scripts.

edfletcher_t137• 6 years ago

I use a terminal because it is NOT a GUI, significantly improving productivity once learned. I cannot grok this, it feels like a step in precisely the other direction.

mschrage10• 6 years ago

When you know the commands by memory, the terminal is hands-down the fastest way of interfacing with a computer. The trouble is when you're using a new command or toolchain and don't know the commands by heart.

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.

rbosinger• 6 years ago

I can see the power in a future OS interface that really combined the terminal and GUI in a powerful way. Maybe this is a good start to thinking about that.

kitotik• 6 years ago

Plan9 is the future past.

totetsu2• 6 years ago

I think we are going to go the way of Semantic ML https://stadia.dev/blog/creating-game-ai-using-mostly-englis... Being able to use natural language to send commands.

bitwize2• 6 years ago

Holy crap, Emacs really is from the future: https://news.ycombinator.com/item?id=23112030

laumars2• 6 years ago

So this is basically just an Electron terminal emulator with some shortcuts included? You can already do all this in a fair few existing terminal emulators, not to mention shell aliases et al. I mean I get the problem space they’re trying to solve but the landing page is so hyperbolic I’m put off investing any time to see if this actually has usability gains over what the team already do use

ashkante• 6 years ago

Not to mention, it being Electron could[1] mean a memory hog. Granted, not all Electron apps are, but after seeing a GUI git client which ate up 800MiB+, I'm very skeptical about this technology. I don't want a shell, a chat client, a git client and an editor to take up 3-4GiB of my RAM...

[1] I can't claim that without testing, but it's a good possibility when it comes to Electron.

rvz• 6 years ago

"Electron" and I stopped reading and closed the Fig website. Aside from using it to over-engineer this non issue of terminals (Already solved via GUI) it has been superseded by aliases, autocomplete and automation.

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.

mthoms2• 6 years ago

There's no Electron involved.

I'm aghast at the level of toxicity and quick-judgment in the hacker community. It's really disappointing.

mschrage10• 6 years ago

Completely agree about Electron - it's really heavy. That's why we built Fig as a Swift app.

Also, just to clarify, Fig isn't a terminal emulator itself. It attaches to whichever one you currently use.

laumars2• 6 years ago

Your landing page does an absolutely terrible job explaining anything about your product though. I assume this is aimed at engineers and technical managers rather than non-technical folk (because why would a non-technical manager be using the terminal)? The fact I had to scroll 5 pages (on iOS Safari), past multiple elevator pitches, FAANG “testimonials” (who cares if a couple of engineers in Google liked your Github repo?) and sign up pages just to see a single screenshot, and not even one that does a good job at demonstrating your product, shows just how out of whack the landing page is with your target audience.

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

foreigner• 6 years ago

The initial example with curl looks very compelling. I like that it's not a replacement for the CLI, just a graphical way to build the CLI commands. Seems like a much better way of learning arcane command line arguments than the searching through man pages that I do now.

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.

totetsu2• 6 years ago

Should call it Fig leaf, because you're hiding the best bits.

self_awareness2• 6 years ago

I have no idea what it is. The main page is really terrible in telling me how it even looks like, I don't even know why I would want this.

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

danellis• 6 years ago

Try reloading the page. There's a (pointlessly animated) video right on the front page that shows exactly what it does.

Direct link: https://withfig.com/video/final.mp4

self_awareness2• 6 years ago

Uh, you're right. I had to click an empty portion of the screen and click 'Play', then the video showed up. Thanks.

mschrage10• 6 years ago

Thanks for posting this. I've been meaning to compress the mp4, but hadn't gotten around to it just yet.

nobody9999• 6 years ago

Firstly, the webpage bluescreened my Windows 7 box in Firefox ESR twice with Javascript disabled.

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.

GeneralMaximus• 6 years ago

I really like this idea!

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.

pcr9103034• 6 years ago

Wow, HN is really harsh on the idea of merging CLIs and GUIs...

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.

egwor• 6 years ago

I think the problem is that historically when people have done this they've made a total mess of it, and inevitably it doesn't support all options so the GUI always plays catch up (and no one is interested in keeping the GUI up to date).

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?)

pcr9103034• 6 years ago

I think the problem is that historically when people have done this they've made a total mess of it, and inevitably it doesn't support all options so the GUI always plays catch up (and no one is interested in keeping the GUI up to date).
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.

blitmap• 6 years ago

Lightbulb: GUI applications traditionally exchange data between each other (like CLI piping) by saving to disk or offering data via a drag and drop protocol. I wonder if there would be value in having an application that visually allows you to construct a pipeline from application to application.

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.

bitwize2• 6 years ago

Wow, HN is really harsh on the idea of merging CLIs and GUIs...

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

fmajid• 6 years ago

MPW (Macintosh Programmer’s Workshop) had a feature like that, called commandos IIRC, over 30 years ago. It did not set the world afire.

Furthermore, a closed-source solution is a non-starter.

The fish shell has an interesting feature where it parses man pages to autocomplete commands.

pixxel• 6 years ago

I should have closed the tab when I saw the boast of Facebook/Google/Microsoft logos and the words "trusted by". But I thought I'd join the waiting list to see the product in action. So I give my email, I'm then whisked away to TypeForm's website and I have to fill out a fucking form which starts by demanding my full name. I'm not giving an "online survey service" any of my details just to join a waiting list.

beshrkayali• 6 years ago

It might not be directly related to this, but I think it's way better for learners to actually read the docs/manpage and then try to craft the command themselves (getting it wrong a couple of times as well). This is kind of like copy/pasting the answer, which solves the immediate problem but is terrible for learning what's going on or how it works.

ipsum2• 6 years ago

"TRUSTED BY ENGINEERS AT WORLD CLASS COMPANIES". This is embarrassing. Please stop doing this - just because a friend from a FAANG company installed your app, doesn't mean its trusted by any company, or that anyone would use it on their internal codebase.

mschrage10• 6 years ago

You're totally right. We're deleting it from our site now. Change should be pushed in a few minutes.

fragmede• 6 years ago

Developers are allergic to feeling like they're being marketed to, as GP comment proves. That doesn't mean it's a bad marketing direction, just that more specificity is needed.

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

mschrage10• 6 years ago

Hey HN! I'm Matt Schrage, one of the cofounders of Fig.

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.

pcr9103034• 6 years ago

I'm very happy to see it's a Swift/native app! One request, I would love to see an API (JS or a native bundle or anything) so that I can write native UIs, not just ones in WKWebViews as I personally think having native UIs are important.

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!

mschrage10• 6 years ago

Yeah, these are both great ideas.

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!

wayneftw• 6 years ago

Nice work!

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

mschrage10• 6 years ago

This is a great question. We spent a lot of time making sure the Fig can be driven from the keyboard.

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.

filmgirlcw• 6 years ago

For whatever hate this is getting, I like the idea a lot and signed-up and hope to be able to play with this. I can already think of a ton of apps I would build/use with something like this -- not just for me, but for demos/tutorials/documentation I make for other users.

Keep doing your thing! It's a good idea!

Fig: Visual Apps and Shortcuts for Your Terminal

Related Stories