Release 260 Discussion Thread - August 2023

Hi Everyone!

Release 260 introduces new features that improve App building efficiency, shop floor setup, and more.

View the Full 260 Release Notes Here.

Let us know your thoughts and questions below!


Regarding the new “Toasts” for app editor notifications, will they be timed and automatically go away or will it need to be removed manually?

It seems like they do not automatically go away after some time and it is inconvenient visually and functionally (the messages appear over the close button within the trigger editor).

Hi David!

Thank you for the feedback. The toasts do have to be closed out manually. I do hear your frustration with how that can be an inconvenient user experience. I have shared your feedback with the design team!

I like to support dsun in this point.

This is really annoying.

  1. It is blocking content and functionality (Publish, Run, Settings, History, Help…) why?
  2. It is stacking up and blocking even more content. (Back, Forward, Step Tab, App Tab)
  3. Its not disappearing (only if its more than 3).

On the display device page, you cant even create a device or edit the top display device after searching for it:

You should center them on the Header (there is no content on the top) and make them disappear.

1 Like

Hi @dsun , @thorsten.langner - thanks for the feedback on the new toasts. I can understand how this would be annoying. As we introduced these, we also shifted a number of messages (“_ updated successfully”, “_ copied”, etc.) to a new lighter-weight component centered at the bottom, which will be used moving forward for low-priority messages that don’t require your immediate action or attention, and will continue to autodismiss.
Unfortunately, in the screenshots you shared, it looks like we missed a few messages that should have been transitioned to that new lightweight component. We’re actively working on addressing those, and will have a fix out shortly.

Hi @kimberly,

after some time with this update, I want to metion another thing.

I like the Recents section on the Apps page a lot.
However, I dont understand, why it is not the default view, when entering the Apps page.
I currently have a list of all folders and apps on the left and the same list on the main page. This is redundant and unnecessary.

Having the recents section preselected would be a much bigger advantage.

Hi @jasmine.chan ,

I recognize the new surface showing the apps in a treeview.
BUT the detail view of an app has to small and not adjustable column widths. If the app name is longer than the width, I can’t see the full title.

In the treeview you should also include the app names for better and faster navigation, because an app is also a folder for its steps.

the UI is not the same for the position of the elements: so the “search” function is for
apps: left top, an input field
tables: right top, an input field
connectors: right top, an input field
table API: right, 2nd row, search button
existing connectors: right, 2nd row, search button

Regards Chris

There is a soluton in Release 261
Release 261 Discussion Thread - September 2023 - Announcements - Tulip Community

I don’t agree. I find it much cleaner with only the folders. I guess thats personal preference.

I totaly agree… It should always be a column on the left for navigation, a main window right for the content, a search bar on the top left or middle section, a filter for any column of the content…
The proportions should also be similar…

:slight_smile: You’ll see consistency in this list pattern begin to roll out on all related pages across the platform over the next few months as we make updates.

I’ve really appreciated the fixes to the Toasts! Thank you for the work.

I have one last request before the Toasts would be perfect in my mind:
Currently, some toasts still show up on the top right of the app editor and they do not automatically go away. I think that is okay IF we could be provided more context on the issue at hand. For example, I get an error message when I try to paste a button trigger into a step or a step trigger into a button. The error message is very vague and I get confused easily when working with multiple different types of triggers. I do not know whether that error message is current or from a previous click.

I don’t mind having to close out that error message, but I would like to be confident that the error message was dealt with OR irrelevant before I remove it. I think this could be solved by either providing more context of what trigger in which scenario the error occurred in and/or provide a timestamp at which this error message was produced. What do you think?