Agreed on #3, I have been asking about it for a while, even got a decent number of upvotes here from the community: [Feature] Rename Connections - AP Team? - but no reply from any of the AP team
#5 is a great idea. A favourites panel or hub would be sweet.
That’s a lie…one thing that is not polished…is the two-finger scroll/panning trackpad gesture on my Macbook - navigating within a flow. I want it to function similar to the click/grab-and-pan gesture (within a flow), but for some weird reason, the two finger scroll does some weird visual stuff and doesn’t pan smoothly (which is an understatement). It’s quite annoying and almost unusable actually as a scrolling/panning method.
I’ve learned to avoid using the trackpad gesture, but it would make a big difference for day-to-day usability if this was fixed.
The best way I can describe it is laggy with a motion blur, instead of the smooth real-time panning when clicking and dragging.
Now I understand the scrollbar issue. I saw it in a screenshot before and it puzzled me, I thought the scrollbar is technically hidden. But it looks like it gets MUCH smaller in smaller screens so people don’t see it. We’ll work on a fix for this for sure!
In the first screenshot, where is the scrollbar though? It’s a smaller list so it should show up but I see nothing. Can you tell me more about this?
For me, the key areas that need improvement for Activepieces to feel like a polished product are:
Updating pieces: The need to rebuild flows due to outdated pieces is a significant pain point and definitly feels unpolished. Implementing the solution suggested in this thread would be a great start.
Dealing with files is really confusing right now. Are they links? Are they (binary) text? Both, sometimes? It’s not entirely clear, and although I managed to sort of figure it out based on how I expect things to be programmed in the back, it’s another prime example of an abstraction leak.
I first experienced it when trying to copy a Google Docs file, convert it to PDF and then use it as a Gmail attachment. This feels like a fairly simple common task, but ended up very frustrating, even as a technical user.
I’m still working on writing out some more coherent thoughts and constructive suggestions on this, Abdul asked if I could put it here in the meantime.
For the Google Drive “Read File” option, if a bit more information could be added to the output instead of just the URL (for example), that would be great.
This is another big one for me: the flow of data quickly becomes unmanageable, especially for non-technical users. I’d like to see things like local variables and (global) constants, for example to share a Google Drive folder ID across flows.
Flow-scoped storage tasks can be (ab)used as local variables, but it’s often tedious and/or counter-intuitive to use. (For example, using the result of a “Put” task as an input for something else.) I’d love to see a dedicated system for this that’s easier to manage, maintain and takes up less valuable screen real estate.
(Again, I’m still working on formulating some more coherent thoughts and suggestions!)
As a bit of extra perspective: the concept of a file being (stored at) a URL is often alien to non-technical users. They’re used to files being “a thing” that they can just throw around, expecting the recipient to just be able to deal with it.
This leads into another concept I’ve dunked in the Discord a while back (abstracting JSON/YAML as a piece’s “values”), but I (again) still need to write a more coherent proposal for it…
This is what I really appreciate about Activepieces - devs who act quickly and listen to the community. Please don’t see this thread solely as negative critique; the only reason people are taking the time to comment is because they believe in the product and want to help make it even better.
This is a weird combination of mixed signals for non-technical users. I absolutely see why it’s like this, an HTTP 400 is a valid response for a “succesful” request, but for an end-user the thing they wanted to happen has failed. Activepieces doesn’t always recognize this properly, which can lead to even weirder behavior down the line.
I’d like to see Activepieces become much more vigilant in this type of error handling, i.e. fail-fast in programmer’s terms. Deployed flows ideally don’t receive attention from humans, so errors could currently easily go unnoticed for extended periods of time. Error handling and resiliency is already incredibly hard to get right for even experienced programmers, I’d love to move as much of this burden to Activepieces rather than the (non-technical) users.
The “output values” idea I mentioned earlier could help with this, since it creates a clear “expected value”, which makes it much easier to detect when something weird happens.
Like @Dennis said, please don’t let my flood of (hopefuly constructive) criticism get to you, Activepieces is already a solid product with tons of potential to become the greatest in its class!
I’d also like to mention again that it’s 100% my intention to actually help contribute to these things rather than functioning as the classic “idea man”, but unfortunately health issues are a limiting factor at this point in time.
I meant revert to an auto-saved flow instance, not just a published instance.
For example, if you don’t ever publish a WIP flow but have been working on it for several days or even weeks, there’s no way to go back if you make a mistake.
This would also extend to undo/redo functionality which @Dennis mentioned.
No problem! I understand what you mean. Makes sense
Also not sure if it is mentioned but saving HTTP pieces would be amazing, I’ve set up quiet a lot of HTTP Pieces but have to set these up again for every flow. Saving these and reusing them would be amazing and saves a lot of time.
Besides that Pabbly has set-up something a while back where it is easier for users to create these HTTP pieces please see this video,