July 27, 2023 / Columns and :emoji: in documents, create DB faster

[antoniokov]

Add columns to docs layout

This feature has just graduated from the experimental status!

Try inserting /2 columns into a doc and build a compact dashboard with embedded Views. Or use /3 columns to compare several options in your project brief.

Insert :emoji: in rich text

We’ve noticed that many people never discover their OS emoji pickers (Windows+. and Ctrl+Cmd+Space), so we’ve added an alternative way. Anywhere in a doc, a rich-text Field, or a comment, put : and start typing the emoji name. The whole flow is keyboard-only and will quickly become automatic.

As you’ve probably noticed, we are big emoji fans! Now we want to convert all of you by making it easy to insert emojis into specs, notes, and discussions.

🧪 This is an experimental feature.
Please enable it via `Settings → Experimental Lab` and let us know what you think.

Create Database faster

Creating a DB is among the first things people do in Fibery, so we’ve polished the flow:

Before

1. Click to create a DB
2. ( the DB with an autogenerated name is being created, the UI is disabled)
3. Rename the DB
4. ( the DB is being renamed, the UI is disabled)
5. Ready

After

1. Click to create a DB
2. Give it a name
3. ( DB is being created)
4. Ready

As a bonus, we’ve also fixed a dozen issues related to DB rename and DB configuration.

Minor improvements

• Intercom integration now syncs custom Conversation attributes.
• Creating a Checkbox or Rich-Text Field now works on very large Databases (20,000+ rows) as well.

Fixed Bugs

• Pasted in rich editor content is also pasted in table and created new entities
• Wrong navigation by arrows in document contained references
• Error pop-up appears on deleting check-box type formula for a huge databases
• Fibery files: html files opened in new tab should not be evaluated but downloaded as file
• Copy of embedded view gets pasted when user types ‘/’ one line above
• When applying rules to a change, we should check rule filter, then execute rule, then proceed to next rule, etc.
• Wrong space is highlighted in left menu when user selects Import
• Wrong apps titled alignment for redesigned import in Firefox

[YvetteLans]

@antoniokov

This feature has just graduated from the experimental status!

Try inserting /2 columns into a doc and build a compact dashboard with embedded Views. Or use /3 columns to compare several options in your project brief.

Great release!

The columns are awesome So much possibilities! But we’re currently facing a problem

• We set up the documents/columns with wide view so that we have enough space
• For other users all content is shown in narrow view. And it seems that if you turn it into wide view and switch browser, then it goes to narrow again.
• Some column content (especially embedded views or 3/4 columns) look really odd in narrow view.
• Not every user (+ potential client in our situation as a partner) is aware of the ‘wide view switch’

Will there be a way in the near feature to default set documents to wide view or that you can choose what you prefer via settings?

Several solutions are possible; the most flexible one is off course ideal. But even when it’s not complete flexible, it would be nice to fix this somehow

And same for one panel navigation; would be ideal if that can be a default workspace setting so new users are not completely freaked out Since we’ve designed everything for one panel because that looks nicer with our set-up.

[mdubakov]

@YvetteLans

• We set up the documents/columns with wide view so that we have enough space
• For other users all content is shown in narrow view. And it seems that if you turn it into wide view and switch browser, then it goes to narrow again.
• Some column content (especially embedded views or 3/4 columns) look really odd in narrow view.
• Not every user (+ potential client in our situation as a partner) is aware of the ‘wide view switch’

Indeed it is a problem. Here is the most basic solution.

Width setting can be per document, not per user. In this case if you set it as wide it will be wide for all users. The downside is that a user (with edit permissions) can break the doc width for all other users as well. To alleviate this issue we can remove width icon and put width setting into … menu.

What do you think?

[YvetteLans]

@mdubakov

To alleviate this issue we can remove width icon and put width setting into … menu.

If possible, I can imagine that the following is best basic solution for now

• A setting to keep it as it is now → so that everybody who don’t like the idea of always small or always wide don’t get bothered by the change
• A setting to change it to always wide or always narrow for users that have more benefits of that setting

(like we have with panel navigation as well)

For our scenarios the wide view will suit in 90% of the use cases. When narrow view is more wanted, we can always use the columns to narrow the wide view (that’s not a bad workaround IMO)

But I can imagine if you’ve already made a lot of docs in narrow style, it’s not nice that all docs are changing, just because you want to build one wide dashboard or so.

In our case that’s not a problem because we’ve put all Wikis in databases instead of docs.

In further iterations it would be awesome to have more settings But in the meantime, this solves a lot I think.

EDIT: if I read your post again after an extra cup of coffee, I think you meant that you can set the wide view per doc (instead of preferences for all docs) → that would be awesome.

[JoelH]

@mdubakov

Width setting can be per document, not per user. In this case if you set it as wide it will be wide for all users. The downside is that a user (with edit permissions) can break the doc width for all other users as well. To alleviate this issue we can remove width icon and put width setting into … menu.

What do you think?

This would fit me perfectly.

Edit: I feel width per-document is fairly important to successfully build pages using columns. I feel like it’s not intuitive as it is now; for a long while I felt unsure but assumed the resize command was per-document. Also agree that as a user I would not think of others when hitting the resize command in front of me, so hiding the “per-document” setting behind … menu would intuitively make sense to me. I do think, as an editor, I would like some hint in the interface of the difference between these commands that would operate on different levels, if possible. Thanks for considering addressing this.

[YvetteLans]

@mdubakov

Width setting can be per document, not per user. In this case if you set it as wide it will be wide for all users. The downside is that a user (with edit permissions) can break the doc width for all other users as well. To alleviate this issue we can remove width icon and put width setting into … menu.

Would it be possible to have that same width setting for normal entities as well? We’re creating the Wiki via entities instead of docs (as far as I can see, Fibery’s guide is also entity based). Would be great if we can have full width.

Also, I’m currently experimenting with using entities for everything. Even menu items and navigation in the workspace. Since entities are best of both worlds; via rich text it feels like a document but you also have options to link applicable databases (in our case: relevant Wiki articles for a menu item).

Only bummer is that entities are always narrow width; therefor grid/tables with a lot of columns are not very UI friendly. Would be great if we could set the default width for an entity as well so that the user don’t need to expand views or use scroll bar and we can save them a few extra clicks It’s a lot of space that’s currently missing.