Fig: Visual Apps and Shortcuts for Your Terminal(withfig.com)
withfig.com
Fig: Visual Apps and Shortcuts for Your Terminal
https://withfig.com/
58 コメント
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!
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!
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!
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!
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.)
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.)
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.
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.
I think i would make this way more obvious on the front page. I use the terminal in no small part so that i _don't_ have to reach for the mouse. What I saw in the animation made me think "OMG YOU'RE MISSING THE WHOLE POINT!!!"
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.
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.
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.
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 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?)
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 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.
> 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.
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.
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.
> 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...
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...
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.
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.
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"?
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"?
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
Direct link: https://withfig.com/video/final.mp4
Uh, you're right. I had to click an empty portion of the screen and click 'Play', then the video showed up. Thanks.
Thanks for posting this. I've been meaning to compress the mp4, but hadn't gotten around to it just yet.
"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.
You're totally right. We're deleting it from our site now. Change should be pushed in a few minutes.
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.)
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.)
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.
[deleted]
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.
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.
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.
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.
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.
Holy crap, Emacs really is from the future: https://news.ycombinator.com/item?id=23112030
Plan9 is the future past.
To me the logo looks like a pear instead of a fig
I think it’s the pear emoji https://www.iemoji.com/view/emoji/602/food-drink/pear
Just a reminder that Dialog/Zenity/KDialog can be used to create "friendly" user interfaces to scripts.
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.
Furthermore, a closed-source solution is a non-starter.
The fish shell has an interesting feature where it parses man pages to autocomplete commands.
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.
Side note: I think the title should reflect the name of the service, Fig.
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...
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...
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.
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.
It has been a long time, but I think we struggled most with:
- 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...
- 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...
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.
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.
I'm a developer and I think it'd be useful. I'm semi-fluent (conversational?) when it comes to CLIs, and this looks like a great way to recall stuff for less frequently used commands or edge cases.
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.
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.
I don’t disagree, on principle I think it is better to know your tools and know them well.
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.
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.
(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).
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).
> 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.
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.
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)
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)
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.
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.
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
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.
Also, just to clarify, Fig isn't a terminal emulator itself. It attaches to whichever one you currently use.
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”.
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”.
Well, TBF I grasped it quite quickly (although I viewed it on my MBP). The demonstration video on the top was quite useful to understand what it is (although I guess I leaved the tab long enough for the mp4 to load, they should compress the video - seems you couldn't see it due to load times), and the explanation that it works on any kind of terminal (including Terminal.app) implied that it's not another terminal but an add-on.
I guess they're not that polished yet as they were planing to do a Show HN...
I guess they're not that polished yet as they were planing to do a Show HN...
Honestly this is really useful feedback. I think the page might be broken on mobile. There should be a large video demonstrating the product at the top.(https://withfig.com/video/final.mp4)
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
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
FYI, the animations didn't work for me in MacOS Safari (with AdGuard extension, though I'm not sure thats the reason)
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.
[1] I can't claim that without testing, but it's a good possibility when it comes to Electron.
"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.
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.
There's no Electron involved.
I'm aghast at the level of toxicity and quick-judgment in the hacker community. It's really disappointing.
I'm aghast at the level of toxicity and quick-judgment in the hacker community. It's really disappointing.
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.
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!
Keep doing your thing! It's a good idea!
Unfortunately, it's gotten to the point where adding anything proprietary to the workflow is a liability.
Should call it Fig leaf, because you're hiding the best bits.
[deleted]
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.
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.
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.