Looks like a competitor to Retool, interesting. The focus on data permissions, mobile support, and push notifications is really interesting because none of those features are ones that Retool focuses on, I believe - those features being front and center makes me think Amazon has looked at the competition and wants to focus on what they offer that others don't, rather than just trying to be yet-another-tool in the space.
On the other hand, I absolutely loathe every single UI that has ever come out of AWS, and there is absolutely no chance I give the editor they've built here a shot without hearing lots of positive reactions first.
edit: actually going to pull back slightly on this comparison, since apparently Honeycomb is a little closer to something like Access, where there is a database _in_ the app, whereas Retool is built around connecting to an external data source (e.g. a SQL database). This surprised me because I assumed the entire reason you'd want an AWS version of this kind of tool is to integrate with the broader AWS ecosystem, like frictionless hookup to a DynamoDB or whatever. It may have this but just not spotlight it on the marketing pages?
>On the other hand, I absolutely loathe every single UI that has ever come out of AWS, and there is absolutely no chance I give the editor they've built here a shot without hearing lots of positive reactions first.
I agree so much with this. I hate the AWS console UI so, so much and It blows my mind that such a large company can't seem to even get on the same page about what color scheme or menu bar position they want to use.
But actually, I'm messing around with Honeycode right now and although I haven't gotten a chance to really dig deep and test the long-term usability of it, I have to say that so far it is gorgeous and intuitive. If the UI team that worked on this just completely took over the AWS console, I wouldn't complain.
Can someone smarter than me explain why the AWS UI is so off-putting? I also find myself just put off by AWS UIs.
I can't even figure out why I hate it so much. Looking at the screenshots though immediately filled me with the sense that this thing would just be awful to use. When I go back to the screenshots to try to find objective things I dislike about the UI, I can't really find anything. It seems to do the stuff a UI needs to do.
Maybe it's just a negative association with the look & feel of AWS UI, because most of the time when I'm interacting with AWS I'm trying to get a service I haven't used before up and running. Going back and forth between dense documentation and the UI, clicking and failing, and staring at a spinner spin for far too long.
Perhaps all those hours spent fighting with other pages that look so similar to this one has given me a subconscious dislike for all AWS UIs.
I seem to be the only person who likes the AWS UI. So here's my defense of it.
AWS is like the hardware store. Who thinks Home Depot is elegant? It's not. Who think their organization scheme is a thing of beauty? It's clunky and just functional.
But the idea is, when you go to Home Depot, you're there to get work done. The interior communicates that. The real work comes after you leave - Home Depot understands it's just a facilitator.
AWS did that.
I personally give credit to AWS for looking at Google, and learning. They could've had some high-handed PM come in and roar ITS TIME TO HAVE A UNIFIED DESIGN SCHEME and then forced everyone to deal with UI updates nonstop, you know the game of 'where did it go now,' 'oh, they moved it here.'
AWS went in the opposite direction. At the risk of ugliness, they give you the most bare bones UI, basically 'nudging' you as little as possible - a clean mapping of fields, to pages, to results. We know the downside: it can be unpleasant. But the upside is, it rarely changes, its consistent, and (aesthetic concerns aside) it gets the job done.
It seems a little weird to commend AWS for their design sense, but when you phrase it as their design goals, I vastly prefer them to Google or any other 'opinionated' service.
You're not alone, and thanks for putting into words what had been the back of my mind.
I could not care less about the aesthetics of their dashboard, when I'm on it I'm there to get something done and I never seem to have an issue with that.
This is such a strange comment to me. The issue with the AWS UI isn't that it's "ugly", the issue IMO is that it is the exact opposite of the things you claim it is.
> the most bare bones UI
The AWS UI is one of the most cluttered, complex, complete-opposite of "bare bones" of almost any web app I can think of, except for maybe Salesforce.
>basically 'nudging' you as little as possible - a clean mapping of fields, to pages, to results.
My largest gripe with AWS is that it does not have a clean mapping of fields/pages/results. The flow of getting to "results" in one AWS service is completely different from the flow of getting to "results" in another. The launch wizard for ECS, for example, doesn't even follow the same paradigm that the launch wizard for EC2 follows. One of them has a clear vertical layout with successive config pages, while the other has a mixed vertical/horizontal layout with sub-pages.
When doing something as basic as launching an EC2 instance, the AMI selection page has "Select" buttons next to each AMI on the right side of the page, and clicking one takes you directly to the next page. And then on that very next page, the instance type selection, the format has changed. Now the way you select something is by clicking a radio button (which is on the complete opposite left side of the page!) and then clicking "Next" at the bottom of the page. Why do these two pages require completely different models of interaction when they are essentially accomplishing the same thing?
Even within the VPC service for example, some pages have clusters of information that are right-aligned on the page, while others put the same information at the bottom of the page. Some pages have the "Create new resource" button on the top left, while others have them on the right side. I could keep going... It's the total opposite of "clear mapping of results" to me, and certainly isn't anything close to "consistent".
I don't think AWS "nudges you as little as possible", I think AWS nudges you a lot, but nudges you in completely different directions for every single service, causing you to feel bounced around like you're in a mosh pit when you're having to switch between EC2, CloudTrail, S3, etc.
Even in Home Depot they at least have uniformity in how they arrange their aisles. The nail aisle has little buckets where nails are arranged by a specific ordering system, typically by type of nail and size. If you go an aisle over to plumbing, the pipe joints are all arranged in similar little containers, also with a sensible ordering system typically by type of pipe and size. If you go to the paint aisle, the displays are different but you can still expect them to be arranged in a sensible ordering system, such as by type of paint and color.
If they went the AWS way, the aisle of nails would just be 2-3 large tubs with a bunch of individual nails thrown in, while the plumbing aisle would have things organized in small tubs alphabetically by the name of the manufacturer, while the paint aisle would be condensed like a newspaper with the pages in order of Bob's favorite colors. It would be chaos.
Sorry for the rant. I respect that you apparently like the UI, but it's weird to me that we have such opposite experiences. You say "Home Depot understands it's just a faclitator" and that AWS is too, and I totally agree. But my opinion is that AWS completely fails at effectively facilitating.
A bit of backround: a service typically builds their API first, and then builds the console as a front-end to that API. For most services, everything you can do in the console, you can do via an API call. (I assume Honeycomb is an exception to this.)
That API-first doctrine is at the heart of the underlying problems, which are:
1. Machine-friendly data models.
2. Distributed-friendly data models.
3. Deliberately independent and orthogonal services.
4. A vast range of customer needs over a console that doesn't itself make money.
AWS really does put effort into making their console useful for getting work done. You'll find some workflows that are pretty usable.
But when you get outside a handful of extremely common workflows that were technically convenient for a specific team to implement, those problems become dominant and the console becomes painful if not f*ing useless.
That's why (I suspect) you hate it.
> ... and staring at a spinner spin for far too long.
Oh yeah, fundamental cloud problem #5: "A few minutes" is absolutely forever when you're troubleshooting.
You probably didn't hate it the first or second time you opened it up. Only after recognizing that many operations are extremely sluggish did you start to build an aversion.
I think the same this can be said about JIRA and many other sluggish, enterprise-y tools. The UI design is typically more-or-less OK, it's the experience of clicking on things and having no idea when it will be done, why it's taking so long, or what a faster alternative is that makes you feel trapped.
The UI might not have major aesthetic problems but they could probably be more consistent between services.
I think you might have hit the main issue on the head though, unless you use a service regularly it's difficult to do much without the hefty manuals and while the services may be complex they could make the common or "beginner" paths more obvious.
Having sane defaults where possible and splitting basic and advanced settings could make it more accessible while allowing users to get familiar with the tools. Ideally a good UX should cater to a variety of proficienies and help users learn.
> If the UI team that worked on this just completely took over the AWS console, I wouldn't complain.
This is the fundamental misunderstanding. There is a centralized AWS console team/organization. They are responsible for the UI libraries, guidelines, common elements, mezzanine, etc, across all of AWS.
They dont write the actual "service pane" UX that you interact with when you start an EC2 instance or upload an S3 object. That surface area is so large, varied, and changes at a frantic velocity that there's no way a single team or group could ever keep up. Even a single "service" like EC2 or Systems Manager actually has multiple front end teams responsible for different portions of the UX or functionality.
You're right, and I did think of that after I clicked "reply". What I meant was that a company with so much resources doesn't seem to have that capability. Even with such a large size, I would imagine Amazon of all companies would have the resources to say "this is the design, now get on board" and make it happen.
This goes for other aspects of AWS as well, such as consistency in the way services report to CloudTrail or are referenced in CloudFormation. Overall there just seems to be little coordination amongst AWS teams, and that's always surprised me.
Teams at AWS are almost like individual companies of 5 - 15 people. When integrating with each other they do it in almost the same way external apps would. The frontend of each app is decided by each team using a shared library for UI styling and some guidelines.
This helps with iteration speed and not getting bogged down in middle management approval hell, but it does lead to inconsistency problems.
I have read this is the intended trade-off. They want each AWS service to release new features as quickly as possible. If they were required to coordinate with other teams on UI decisions, that would slow them down.
My first glance reads it to be more like airtable or even salesforce at some level, which to your point are the modern iterations of access / filemaker. Drag and drop all-in-one database and application designer that by virtue of being online and multi-user make them way more useful.
Yes my first thought was that this was like Airtable. One of these days one of these no-code solutions is going to actually stick, and I will stop getting paid to basically glue data from different systems together while browsing HN.
It's a fairly busy territory as it is, with at least 20 major enterprise players.
Microsoft PowerApps with PowerAutomate (formerly Flow, their Zapier/IFTTT) have a huge advantage of being bundled right into other licenses. SalesForce and ServiceNow have similar advantages. Quick Base[1] has to be considered the incumbent. Zoho, Oracle. And then the more independent Appian, Betty Blocks, Mendix, OutSystems.
This tends to be one space where consolidation and acquisitions aren't as popular, and the big players have built their own home grown products on top of their stacks. (counterpoint, Kony got snatched up by a fintech software services company, Temenos. Apple acquired Workflow which isnt quite the same thing but a tangent space.) In a lot of cases, its going to make way more sense to go with the Vendor that already provides other parts of your infrastructure. If you're an Oracle company, Oracle Apex is going to be simpler, which is the point of all these offerings. It makes a ton of sense for AWS to provide this naively on top of their already mature offerings.
It's also not a space I'd want to enter as an independent startup, from scratch, unless you are sure you can actually offer something better and different. Or, instead of a generic offering, your product is tailored to the specific processes and workflows of certain industries. At this point if you want to join this crowd, it would be a safer bet to hitch your ride to a specific tech company lacking this offering (if there is one left) and become so good that they want to acquire you. Or build a specific subfeature in this space, so one of them gobble you up and tack you onto their product (see 3rd link.) I would guess there is still room for some ERPs to be interested in tacking app builders on, like Infor.
[1] Somewhat shocked to not see Quick Base mentioned even once in this thread. It's a billion dollar company thats been offering this nonstop for 20 years, and is still relevant.
I agree. In our case we're focusing on gathering and sharing information securely (end-to-end encrypted) i.e. Typeform for PII[0] with information verification built-in. There are lots of use-cases for a tool that enables non-coders to incorporate that information collection into their business process (we believe).
Hi there! Founder of Retool (https://retool.com) here (and long-time HN reader). Agreed that Honeycode is adjacent to us. I think an interesting way of viewing the space [1] is who the product is for. There are lots of drag and drop app-builders (e.g. mendix, outsystems, bubble, msft powerapps, amazon honeycode, etc.), but they're all built for non-technical people. Their goal is to make programming more accessible to all. (Which I think is a very noble and very interesting goal!)
Our bet, however, is that code is here to stay, since code is actually a pretty efficient way of getting a computer to do something [2]. With that said, though, building specific types of apps (in our case, internal front-end apps today) is surprisingly difficult (have you tried recently!? you have to use react, redux, install 10+ npm modules, etc... just to make a front-end that has a table + POSTs back to your internal API!).
And so that's why we're building Retool for engineers, which has resulted in a few interesting decisions:
* we are not a system of record, since engineers don't like to move data around. We'll connect to your data, no matter where it is (e.g. postgres, a custom API, salesforce, etc.).
* we rely on the user knowing how to write code. I think this is interesting because low-code is good for getting to 50%, 60%, etc. But as you try to get closer and closer to 100%, it becomes harder and harder, since full customizability within a GUI (without code) is just hard (cf 2.). Retool lets you get to 60 - 70% of what you want very quickly, but then relies on you finishing the last ~30% with code, if you really want to. (We provide APIs, let you import custom React components, let you write JS anywhere [3] within {{ }}.
(If anybody is interested in working on this, please email me at david AT retool DOT com. I think there's really a small chance we can really change how business apps are built.)
1. Funnily enough, when we started Retool, there was no low-code / no-code space. If you look at our original Show HN (https://news.ycombinator.com/item?id=17725966), you'll see that nobody mentions "no code", "low code", or anything siilar. It's certainly been fun to watch a "trend" pick up around us, haha.
2. For example, imagine a switch statement. Very simple and concise in most languages, but incredibly hard to implement in a GUI. (A graph with nodes and edges, perhaps?)
3. We secure it by running all JS in a sandboxed iframe.
I guess RAD tools (now no-code) will never fade away from the market.
I bet you're getting a lot of traction on corporations that need to upgrade/replace internal tools.
I know, internal tools will always suck because:
1) your market changes faster than you can change your apps, so you're always lagging behind.
2) And technology moves faster than you can keep them to date. That's the reason we still have IE as corporate browser in most enterprises.
Also, 3) nowadays it's very hard to do both good frontend AND backend coding. Technologies diverged a lot since, say, Rails 2.0 (which is just 8 years away from now). And the barrier to compete is higher every day.
I'm curious if you see 3rd party vendors being useful in this space. e.g. one person consultancy that can use Retool to quickly build out internal apps for other orgs that aren't able to get any internal dev resources
I see this line of thought floated a lot. Go build a fully dynamic app used by internal teams with just those three tools and tell me how it goes after you've been maintaining and building on it for a while.
Those are good building blocks but they're simply not sufficient if you are building a 'Web App' and not a 'Website'.
Also I'll cut off the inevitable, "The web was not built for this and it shouldn't become a place for apps." The world disagrees, I disagree and most people developing on the web disagree.
And I'll raise that we should be moving more towards the web being the best universal distribution platform for software.
> We're talking about internal tooling for businesses here, this isn't necessary at all.
Why treat internal 'customers' any differently than forward facing ones? Building great internal tools can dramatically improve your teams' workflows and solve meaningful business problems.
As far as I can tell, this is being pitched to teams, not really general purpose applications (as I imagine a highly scalable DB being used for). The pricing is quite high on a per user basis and the 'tables' max out at 100k rows, so not useful for any larger scale data aggregation.
Agreed, a seemingly missing feature is how can lambdas or other AWS ecosystem components interact with this data? I could imagine systems where it's nice for "no-code" and "code" to interact cleanly.
On the other hand, I absolutely loathe every single UI that has ever come out of AWS, and there is absolutely no chance I give the editor they've built here a shot without hearing lots of positive reactions first.
edit: actually going to pull back slightly on this comparison, since apparently Honeycomb is a little closer to something like Access, where there is a database _in_ the app, whereas Retool is built around connecting to an external data source (e.g. a SQL database). This surprised me because I assumed the entire reason you'd want an AWS version of this kind of tool is to integrate with the broader AWS ecosystem, like frictionless hookup to a DynamoDB or whatever. It may have this but just not spotlight it on the marketing pages?