Show HN: Retool: Excel-like, with higher order primitives
retool.in
retool.in
Retool is a visual programming language, like Excel. But instead of cells being the base unit, widgets are. Widgets are prebuilt React views, and you can edit their properties. They can pull data from SQL queries, and other widgets. The page we made is an example of what you can do.
If you're curious how it works, here are the docs: https://docs.retool.in.
Any feedback or questions welcome! :)
Would love to see a client-side model abstract layer(in javascript) to dealing with API stuff.
The other thing is, it doesn't really fit. Your usage of beige on white isn't that poppin. Switch it up!
I remember when I first saw Notion: it was beautiful! And the widget picker was exactly what we needed -- it acts as an index for all the widgets, with a short description for each. So I decided to steal the idea. None of the code here was copied (or even referenced). I think that when there are good design patterns (e.g. tabs), stealing an idea is okay.
In this case, I think that I might've been a bit too lazy, as you noted. I think we should've thought a bit more about the design. Thanks for the feedback! We'll get it changed in our next version. (My excuse is that we only switched to this widget picker overnight, and really really wanted to do a show hn today)
Specifically for your product, you might want to change a few things.
* 1: It's fairly busy when I click the demo. I'm overwhelmed by your "do you need help" real-time chat widget, which overlays your sidebar blocking out some functionality, and container3[2] which has 3 options.
* 2: I shouldn't even be seeing "container 3", as an end-user, or any integer primary keys.
* 3: I'm presuming "container3" is what your users want to interface with first. In which one do "I" pick? The second box of the two is particularly out of place, as the end-user hasn't had time to explore your app, so how could they even have questions or comments?
* 4: The side-bar gets overlapped by your interactive pop-up for help on my laptop for that chat feature, making a busy layout even more busy. Again, I haven't had time to explore your app, so how could I have questions? Do some mouse-movement analysis or something, and use that to determine if they're exploring the app productively or blindly clicking around in confusion. If the latter, then perhaps pop up the chat modal.
* 5: The column names aren't "humanized". 'first_name', 'last_name'. Even worse, "store_id" is a numerical value, rather than the actual store name.
* 6: On the initial load, there is no customer pre-populated. So not only does it have no content in those containers, but there are some display components which are clearly not supposed to be there[1]. (The more conventional way would be to have a details modal pop-up when you do select a user.)
* 7: Overall, the interface is unconventional and awkward for a standard user coming from any 'data-driven' app they'd use at their day job. I.e., you have both an overview table and then a details table below, which drills-down into two different detail levels (an overview of the customer, then their specific rental details). As a store manager, I probably want to see either the customers summary information (net revenue per month) or a list of specific titles they rented. Not both at the same time. As it stands you have 3 different levels of data being presented at once.
* Edit: Speak of the devil. I've never used Notion before, but I signed up for it and it has a "Clippy" right there. I guess they probably grew up with the same software I did haha. Their product isn't particularly powerful or groundbreaking (compared to say, what Asana was at the time) but I'm guessing that I'm not their target audience (seems like "yet-another-Trello/Evernote hybrid-with-an-Electron-app").
I'm guessing their target demographic is "John working sales at Dunder-Mufflin paper" who needs a central repository of his customers and purchasing habits ('Sally's Flowers is about to run out of stock', I should give her a call). Or John's manager, Tina, who wants to see aggregate statistics on how her team is doing with that new re-targeting email campaign software, she used 20% of her budget on. Are her 6 sales guys producing enough of a sales increase that the monthly fees are generating sufficient ROI?
I probably wouldn't pay for their software, but again I'm an emacs power user who's written thousands of lines of elisp on top of org-mode to centralize all of my information/aggregate analysis. Regardless, their interfacing tutorial animated helper is a prime case study of 'how to introduce someone to your product' without overwhelming them. But if they're your direct market competitor, it'd be quite questionable to "borrow" that flow. You're on tenuous ground as it is with your layout + widgets.
I don't use web apps out of principle if I can't at least pay to purchase a license to host it locally (Atlassian style), as I've been burned by tons of acquire-hire-kills. As such, I'm not sure what the ecosystem is like and if "Ivan" type animated helpers are commonplace. If they aren't, HN users take note -- this is a prime example of how to introduce your new users to your software.
---
[0] Both are pretty much 'abandonware' at this point, so I have no problem telling you to go pirate it.
I can imagine keyboard support wasn't the highest priority in getting all of this stuff to work though, so not complaining, but I think it would make this a lot more appealing to power-users.
How and why should I trust a brand-new startup? Doubly so when they don't even list security in their docs.
tl;dr; I love the idea, looks like a great implementation, please let me demo (and then ideally purchase) an on-prem version.
Security is definitely a concern when we have access to your data. In the coming week, we'll definitely open-source the backend and allow it to be deployed via Docker. We're also thinking about doing a complete on-prem solution -- email me if you're interested! (email in HN profile)
Thanks for the feedback!
+ write privacy / security policies to guarantee we never see nor touch your data; coming soon
I can't wrap my head around this perspective. To me, they are one of the biggest UI successes in computing history.
Spreadsheets provide an extremely approachable interface for managing data. A 2D grid is easy for people to understand. Entering data is easy: you click a cell, then type. And that is literally all you need to know in order to get some use out of spreadsheet software -- you're just using it as a dumb tabular data store, but it turns out that there are lots and lots of common scenarios where a dumb tabular data store is all you need.
That's where lots of people stop learning about spreadsheets, of course. But that's fine, because the software is still providing utility for those people. And for the fraction of those people who are inquisitive enough to want the software to do more, they can start extending the basic metaphors they learned coming in the door with additional power -- sorting, filtering, functions -- without having to learn new interfaces at each step along the way. Then some subset of those people will discover that there's actually a scripting language under the hood, which gives them even more power.
If you wanted to design an interface that provided the widest possible funnel for picking up new users, while simultaneously letting those users power up to new levels of capability as seamlessly as possible, you would have to work really, really hard to come up with a better solution than the spreadsheet.
Excel is close to good, but it can never be actually good because it's got decades of workflow to protect.
Tables (or lists in previous versions) solve that issue nicely.
"When you have a data range that is not formatted as a table, Excel will automatically convert it to a table when you select a table style."
https://support.office.com/en-us/article/Format-an-Excel-tab...
If Excel is falling down for you with only that many rows, it's possible that you're using one or more 'volatile' Excel functions (ones that are recalculated whenever any cell in the sheet changes, e.g. OFFSET() or INDIRECT()).
I find that filling down with a function like VLOOKUP(), whilst you have multi filters on, is the real killer. And yes you can rethink your workflow so this is not necessary, but if you have to do that you have immediately reduced the utility of Excel, which is easy manipulation. If you have to 'paste special' your subset into a new sheet first, then it means you can't easily test different filters or scenarios. If I have to do something more complex to get my answers, then I would begin my manipulations in sql instead.
I still find that once Excel gets anywhere near its row limit (circa 1M), there is a big increase in memory usage, which I have found can cause a big slow down on ordinary desktops that normal office workers have (i3/i5 4GB ram). Curiously (and without extensive testing) I feel this is much worse in later versions of Excel (after 2007 and the BIG change), and my Excel colleagues agree.
1) As you say, you can use INDEX/MATCH instead of VLOOKUP. I only choose the latter if I'm 100% sure I'm not going to save the sheet. I don't know whether VLOOKUP has performance problems, but at some point someone's going to insert a column and break the references.
2) I've never had a filter (I presume you mean filtering on the content of columns by clicking on the column headers) which affects the value of a formula. I tend to have one-way data flow: inputs are clearly marked (ideally, but not always, on their own sheet(s)), and you use filtering only on output sheets.
I'm not sure about RAM usage. I use Excel much less these days for things with that many rows.
That's a testament to how bad _other_ solutions are. For most people, the UX for Excel is far superior to that of SQL, matplotlib, ggplot2, sed/awk, CRM tools, ...
Excel suffers a lot due to the fact that its core computational model has been static for decades. While Microsoft has been good at adding commands that manipulate the grid, it's not been nearly as good at enhancing what the grid itself is capable of computing. Just to illustrate, I'm continually annoyed that 'sort' and 'histogram' are menu commands and not concepts that can be expressed with an array formula. (Although it could theoretically be done with a UDF written in VBA.)
But that specific example aside, my frustration is really that the Excel expression language is the beginnings of a good dynamic functional programming language, but is missing most of the good stuff from that paradigm. (Non-scalar values, local bindings, higher order functions, custom functions aside from UDFs, etc.)
What's maybe most frustrating about this is that Microsoft Research (Simon Peyton-Jones) has done several talks suggesting how it might be done. Microsoft is definitely aware of the possibilities... they've just chosen to direct their priorities elsewhere.
https://www.slideshare.net/kfrdbs/peyton-jones
https://www.microsoft.com/en-us/research/publication/improvi...
One thing that I noticed while paying attention to the sluggishness was that customer information view showed the previous data until new data arrived when selecting another customer. I would consider that fairly bad thing, especially as there are no indicators that the data is not actually valid.
I think a natural extension to this system would be to add a form builder or something that adds the ability to modify/submit data. Combined with something like AWS Lambda (and other AWS services) you could build quite powerful "applications" with relative ease.
- local data -- good point -- will switch that up so the demo goes faster in future
- no loading indicators -- thanks! I think I've used the tool so much I've now gotten used to it, but this is definitely something we'll add in our next release
- form building -- interesting. We were thinking about doing API queries to modify data, but that would require backend code. Were also thinking about just having a database local to retool -- so you can take notes on your customers, say.
We're using it but it's not flexible enough, and the code editing sucks. I think there's definitely a market out there for this thing, so I hope you succeed at what you do, and do the best you can.
Multiple sources is very much needed, and definitely a way to edit all the code in a code editor (i.e. plaintext only, no drag and drop). We have 40 branches and maintain a separate dashboard for all 40 branches. Having to edit manually all 40 of them sucks. I want to copy the code for 1 dashboard and do find+replace - I don't want to use the drag and drop and so on.
Some comments, wish you all the best
I think editing by code is definitely better when you have 40 separate branches. What if your datasource (e.g. postgres instance) was a variable, and you could change this for each branch? Perhaps forking would also be useful, if there were specific charts you needed for each branch?
I think this is something that we're interested in building -- do you mind sending me an email at hn@davidh.su? Would love to chat more. Thanks!
We will embed Tableau for the analytics, so why not embedding a tool for data input?
Integration with different data sources will be key though.
I agree that data integrations are key. I think that postgres is a start, but for a tool like this to be widely useful, we have to be able to consume and write to various APIs, in a way nontechnical people will be able to understand.
Also, this looks similar in functionality to ChartIO and Mode, do you have a summary of how this is differentiated?
Edit: I wanted to add: great work!
I think that Chartio and Mode are very good answering questions, and exploring data. If your problem is "what is our CAGR since 2015", Chartio is good for that. Mode, I think, is more similar to us, and certainly better for data analysis. I think, however, that we are more customizable than Mode -- imagine writing a search box in Mode, for example, in order to drill in deep on a certain customer's orders.
I think we're more about building apps that would be rote coding otherwise (e.g. building a CRUD app to manage orders), or empowering non-engineers to build and maintain these apps themselves. Instead of hiring more engineers, what if you made everybody in your company able to quickly build simple software? I think Excel has been very empowering, and we want to do the same.
Great UI and concept. Can't wait to use this if I can find time.
"Build tools in minutes, not days." is not clear. What is a "tool"? To build a "tool" using a "widget" is a perfect nonspecific thing to do. Also, what is Launchaco?
Still, I like it a lot, seems to be a much better solution than all those KPI dashboards and also to people using https://www.blockspring.com/ to get database data into spreadsheets.
EDIT: good feedback on the messaging -- thanks! launchaco is a static landing page generator I just used (after posting this) to generate a landing page -- working through kinks right now! (I noticed a lot of people were landing in the app, clicking around, and bouncing, so maybe a landing page would be a better way of explaining things)
Our goal to let ordinary people build the tools they want, much like Excel has. To that end, I think we're missing these features:
- input and store data, instead of connecting to a postgres db - build wrappers around APIs so you can pull in / write data to/from anywhere - make it as non-technical as possible, but building a GUI query editor, and possibly changing the widget templating syntax
Warning, plays a sound to make you notice a fake chat message in the corner. That's scammy.
I can't argue much, I use Ghostery and also this host list which means I usually don't see those things: https://github.com/StevenBlack/hosts
I feel Ghostery has been very transparent about its use of data and has been clear about what I opt into and out of with any given update.
Good looking out though!
Edit: we also changed the URL from https://demo.retool.in/demo by submitter's request.