Minor release today with some Whiteboard improvements and other things.
Whiteboard: flowchart shapes
Now you have more shapes to select from on Whiteboard View
Hide when empty per field setting in views
You can now selectively hide empty fields on most views with a new per-field setting. This feature allows you to hide fields that are empty and unnecessary while keeping others visible. Accessible through the “Fields” menu, simply click the “>” button next to a visible field and toggle the “Hide when empty” setting.
Table View totals are no longer experimental
Table View totals graduated from experimental. You can also hide aggregation per column:
Improvements
Switch field visualisation on Whiteboard
Enforce AI usage limits for Basic AI plan
Hubspot integration setup support filter by creation dates (along with the existing modification date)
Headers style updated in rich text fields and docs
Fixed Bugs
Whiteboard View:
Unlink option is not disabled for locked relation line
Copy option is available in relation line actions
Escape key doesn’t reset selected instrument when it is selected by mouse click
‘Connecting’ is hardly visible on dark Theme
Various bugs on Shape creation
Caret disappear on Text appearance change
Copy link to object redirects to wrong place
Color picker is broken
Oops error on timeline when create new entity via dragging in some case
Firefox: incorrect font-weight styles for headers in documents
This is probably too complicated to implement but any chance the empty fields could be grouped in a compact way, on the top or bottom, so that it’s easy to input the information and the non-empty fields therefore are more compactly seen?
I have a contracts database, but different types of contracts require different information, so there are many fields and depending on contract type many are empty.
The Contract Entity-View doesn’t look appealing, it’s too crowded.
Hiding empty fields would be already be very helpful regarding the looks, but then it would add complications for the regular user if he does want to input an information in an empty field.
And of course custom (filter-based) Entity Views would solve this problem, but if that’s not happening soon it would already be very helpful.
Thanks for the input, Eren_Turgut!
On the Entity View, “Hide when Empty” setting is going to be available for Fields in compact sections only (top section in 1-Column layout and Right panel in 2-Column layout), which means that they already will be grouped together and be easily accessible.
Are fields in the main section of an entity view (relation views) not going to have this option?
I thought the purpose of it was to remove the clutter from the entity view, and the main section is where that happens most. I think that would be the most effective UX improvement to make the interface less convoluted with empty fields taking space.
Currently I often combine databases in one field to prevent this, but that has the drawback of one field configuration to apply to all databases. I think this needs to be rethought.
Main section will not have this option for now, since it’s not clear how to manage Fields from there. But in order to remove clutter, we are working on introducing Entity Views - ability to slice views for different purposes/use cases
I love to see the progression on whiteboard view! Wondering if there are plans to upgrade whiteboard into a proper view. At the moment it is a weird mix between view and non view. (Not available in relation view, context filter, deleting doesn’t really delete, quickly creating entity of that database, etc.)
Changing it to a proper view is quite different in terms of functionality and use case.
Maybe a best of both worlds could be that within a whiteboard you can have a section which is a “proper view” filter in the section, apply context filters to the section, etc?
Wondering if this is a direction you guys are thinking of going in. Thanks!
Yeah, whiteboards are ‘content views’ in the same way documents are.
That is to say that they are canvases on which you can display a mix of entities/data views and non-structured data (for WB: shapes, arrows, text, etc. for Docs: text, callouts, code blocks, headings, etc.)
This is distinct from ‘data views’ (like boards, lists, tables, timelines, etc.) which are 100% structured data.
This means that the behaviour is slightly different than it is for data views. For example, if you had a table view showing tasks, as new tasks are created (e.g. by other users) they will show up in the table view (provided they fulfil the filter criteria).
With WBs, you have to choose which tasks to drop onto the board - nothing will happen if new tasks are created in the background.
It’s a tough one to design a good UX to make WBs behave like a data view, and overall, supporting dynamic updates to keep a WB ‘in sync’ with the state of the workspace as it changes, is pretty tricky.
Field Groups
Another suggestion with relative high UX impact is Field Groups.
Apart from easier collapsing and expanding multiple fields, it could be combined with: Field header size
The benefit of that is that you can make the header of a fieldgroup bigger, so that it stand out from normal field headers. My current issue with the entity view is also that there is no way for users to etiher group or emphasize a field header, because they all have the same small font. This would be incredibly helpful against visual/cognitive exhaustion of checking each field what its relevance or relative importance is in relation to other fields. Being able to adjust the font size of field headers wold be great, but if that is by default possible in field groups also, that would be such a relief.
But it would pretty cool. Imagine you can open an entity for “Department” and see the contextually filtered employees in whiteboard.
Maybe even having them non-draggable, but just openable and editable. The relation view and the auto layout is all there, manually filtering which entities to include exists too. I understand it would be a different type of thing, and could be confusing if replaced whiteboard, hence I suggested maybe adding the “data view” inside a whiteboard as a section. Then in context views it automatically makes this section. when the view is created. Not sure how many use cases there are to this, but it could be pretty neat!
I totally agree, and would love to see whiteboards (or specific sections of them) become more like data views (with filtering, colour coding, etc.).
The question then arises, if the layout is ‘fixed’ maybe it’s actually not a new feature of whiteboards, but actually a new type of data view (= ‘relation mind map view’)
These will be smart sections on whiteboard with predefined setup or actions (automations or buttons) and dynamic “fixed” layout. We discussing how to make them in our context and use them in relational view.
Basically, grouping certain Fields will be achievable by creating an Entity View. By it’s logic, it’s a group of Fields currently visible and laid out on Entity View the way you want them. We will add the possibility to quickly switch between Views as well.
Ah this is amazing!
Will there be the possibility of dynamically setting the default Entity View based on properties of the entity? Either via automation or some other method?
This would allow for a UX that is responsive to “subtypes”
Improvements
Fixed Bugs
