Some more love on document editing

Ideas & Features
1

I’m happy that blocks are being implemented in doc views, they are a must. However, the rich text editing I think needs a bit more improvements, as it’s not as smooth as I wanted to be. Most of these are just small things and might be subjective, but it’s something I would like:

  1. Major one - allow indentation when pressing tab for any element. I hate that I can’t indent normal text or checkboxes. Here’s how coda does it Loom | Free Screen & Video Recording Software | Loom

  2. [FIXED - BUG] - when you’re on a checkbox item and press enter, it creates a new empty checkbox. However, sometimes the next time you press enter, either creates another empty checkbox (not desired) either removes the checkbox to add a new normal, non-checkbox item. Creating empty checkbox items is not desired and not consistent. Here’s an ex. Loom | Free Screen & Video Recording Software | Loom

  3. Allow text color change, not just highlights.

  4. [FIXED] Maybe just a personal preference, but heading should be much more distinguishable from normal text. H3 is barely distinguishable, makes thinks harder to read. Maybe increase the size a bit of all headers and bold them. The bottom margin of the headers should be a bit larger, makes things easier to read.

  5. Collapsible icon can be just a tiny bit bigger and have some hover action, feels a bit better when i see in Coda that highlights the arrow when i hover over it. I also like the arrow animation when I click on it.

  6. [DONE] Icon picker for left sidebar items :slight_smile: I know we can simply copy-paste an icon from the web and put it on the beginning of the view name, but would be much better to simply let us pick an icon. You already have the icon picker so…

To be completely honest, I tend to go to Coda for building documents to share with the team, they look cleaner (bigger bolder headers just an example) and are easier to edit. We really want to ditch Coda to not keep things in multiple places, but there are little things like that that keeps us going back to them.

1 Like
2

I agree with the general sentiment about the document editing feeling a bit rough around the edges. Here are a few other items I’ve come across:

2 Likes
3

Related:

And - could we please have:

  • underlining (oddly preserved when pasted, though unsupported by the editor)
  • left/centered/right alignment (lost when pasting, and unsupported in the editor)
4

I agree with the potential value of some of these things, to be sure. Others may be down to personal preference, and it makes me wonder then if Fibery team should consider some kind of global CSS modifier per-workspace, that admins can adjust to affect all users of that workspace. This would address issues like header styling, at the least, as well as fonts, size/visibility of sidebar items, etc. All of which are issues/requests here in the forums somewhere, and each of which may be different in preference for different users/teams.

3 Likes
5

letting us set a global css applied to workspace would be huge in terms of personalization. For ex. i might prefer a light sidebar instead of darker one, or i would want the items list to have no borders, etc… It might be an overkill for some, but would give a next level customization option.

2 Likes
6

Jumping on the CSS-request bandwagon – I would love it if every entity field was tagged (in the HTML) with classes for its containing Type, Fibery type, and field name. This would make it much easier to customize specific fields; e.g., columns in a Table view, based on the field (and not dependent on column order).

7

I also agree. I think this is the way to go in the short term until some more UI customization tools/interface could be offered.

I can understand Fibery team’s hesitation to opening up this “Pandora’s box” as there will be a flood of themes (some great, some very poorly done) and it will likely distract the larger community from the main focus (I feel roam suffers from this). But even knowing this flexibility is being built into the design and a possibility in the near future would give everyone some reassurance that their particular UI styling woes can be sorted out :slight_smile:

I’ve also notice this omission, although ctrl+u at least works!

2 Likes
8

That sounds a bit intense to implement and maintain, if I’m not mistaken. Do you really need per-type CSS customization?

9

Another big one I remembered today while a wrote features spec is the sub-items numbering. If we have numbered items, sub-items are also numbers. It’s more natural to have letters there. Another thing is that I can’t change the sub-item to be just simple non-ordered/ non-numbered items… they are always numbers. I might want to be checkboxes or normal items.

[Later edit] Following up on last matter, would be super nice if on sub-items when we type “1.” to change the sub-items to numbering, when we type “” to checkboxes and * to normal items …basically like it works when we’re not editing under an item.

To be completely honest, if they just straight up copy the full document editing behaviour from Coda it would be superb.

1 Like
10

My thought was to just convert Type IDs and entity IDs to class names, and add to the appropriate HTML elements - seems like that should be pretty easy to implement.

1 Like
11

Hmm OK. I’m honestly not sure, so you may be right.

12

And these don’t actually need to be CSS classes – they could just as effectively be custom HTML attributes, as long as we can create selectors to match and style them.

Maybe something like: fibery-typeid="..." and fibery-entityid="..."

2 Likes
13

I am now upvoting this largely because of the first request, for indenting. I especially want this for checkboxes. If this should be its own feature request to vote on, then fair enough.

1 Like
14

Any progress here?

6 months passed and none of the issues we listed here were addressed. The document experience is pretty poor even after so long time…

No checkbox indentation, checkboxes bug still present, you can’t combine ordered lists with non-ordered sub-lists or checkboxes and vice-versa, can’t use other type of order style like letters or greek letters, h3 looks almost the same as normal text and so on.

1 Like
15

Hold on, we will get to it soon!

1 Like
16

We could cut down on some of the forum chatter if there were links in the topics here to where we could track an issue’s status and ETA. :bulb:

17

baby steps… WIP
2022-05-20 14.52.33

4 Likes
18

New user here - given all the really amazing features in Fibery, I was kind of surprised to find limits on rich text formatting (font size, color, underline, alignment) - is there a roadmap or an ETA for these features?

1 Like
19

Underlining is possible with Ctrl-U.

It is not possible to set the font colour, but you can set the background colour for a section of text.
firefox_2O6r2zb62M

No ETA on alignment I’m afraid.

20

tbh from my limited markdown experience most limitations are coming from the markdown “standard” which is usually implemented in many different flavours depending on platform anyways. there’s a nice pdf/markdown formatting framework I don’t recall the name of, but should be quite popular and easy to find.

we circumvent aligntment using /2 for two-column layouts, for instance. pasting/writing text, embeds/links images in there. It works rather quickly and nicely once you get used to it:

The advantage being that you can easily adjust right vs left or even standard “non-column” widths or images, embeds using the vertical on-hover bars on center and sides: this enables something that’s rarely possible with most markdown web-apps, like dropbox paper etc. You can quickly adjust desired sizes, visibility and content… even to full screen width where appropriate leveraging screen real estate to usual desktop screens, outside of the habitual A4/letter analog restrictions and sizes.

I find it really nice so far: Just make sure to individually “Copy image” or re-paste image content from external sources to enforce actual native embed inside of fibery’s cdn/api. Else you might be in for a small (but correctable) shocker/surprise when (after days/weeks) your external discord etc. copypastes disappear from your local download/cache and therefore… your fibery markdown docs as well. Especially when copypasting full txt+image data… initially appearing to work “perfectly”.

We obviously use coloring, bold etc. as well. One nitpick is that some keyboard layouts will not support all the “markdown” edit-bar functions: but it’s still extremely pleasant and fast.

Another interesting leverage I started using within dynamic content-index is ----- (copypasted) hyphen separators (as H1-H4) above H1-H4 titles or sections enabling you an extra “layer”/separator for the already very useful and clean dynamic auto-index. Giving you an extra level of clarity and control/separation and structuring.

Imho people should not misunderstand or compare markdown to regular text-editors: Most of what I understood from the request can actually already be achieved with Fibery’s current MD implementation: And actually way faster and more pleasantly than subpar Word-like Text-Editors with their decade-old, atrocious legacy, non-async alignment or paragraph popups and whatnot.

Especially if you look at MD as an imprecise “rendition” somewhat separating function from precise content, similar to how other mark-down languages like HTML/CSS are used to decouple logic from appearance.

What would be most critical imho is not an attempt to expect or force MD into something it simply isn’t: A Word-like text-editor. While obviously still expending or leveraging the strengths of what it is natively meant to actually be.

But ensure that we get more control in MD-import/export or PDF/HTML generation to actually have more control into reliable and controllable PDF- or printed outputs. Like working paper/output/media css tags etc. Once things and export implementations are under control, the internal/MD “word-expectation” automatically becomes less of an issue anyways: Markdown is a markup/markdown language, hence the name. It is not meant to be… Word.

On the backend side of things improved PDF/HTML export functionality, control and reliability should be possible to be achieved without reinventing the wheel, but using “Pandoc”, which is the framework aforementioned, specialized in PDF/HTML(?) and markdown format-conversions. If not already in use.

We should not focus on regular Word-Editor renditions. For Print/Prepress or just regular Text-Editing the workflow is simply atrocious and precision is still unreliable. If one expected/needed sub-mm precision there would unfortunately not be any reasonable way around Adobe Indesign, for instance. Which is yet another beast and always was in subscription-model/pricing as well as current TOS-update controversies.

Try out /2 for two-column, imho! :slight_smile:

To clarify: All aspects are very much valid. This response is obviously/mainly directed towards the indentation or alignment limitations. Even Word et al. have atrocious handling of “Indentation” → It would almost require rather advanced Indesign, and shortcut-based, i.e. “hanging” indentations akin to Indesign. Else they become very unreliable and cumbersome. In classic implementations it’s also very easy to almost “imprison” your data/indent-structures due to unexpected results in editing etc. It’s that… bad.

You could probably even try to achieve superfast indents/styling/separation via 2-col as well. (Leaving one empty) and adjusting by preference.

From a typographic perspective I disagree with increased header-margins/paddings as well as making them bold by default. All it costs is a “ctrl+b” shortcut for the users to decide. Very basic and more modern DTP/typo founded principles indicate “proximity” for logical and visual cohesion. If the default Header-Margin/Padding were increased further than they already are, things would actually become worse: not better. They should be reduced, not increased. Preferably via user control: Which also has to be weighted against MD/Standards and ideology/functionality, as well as exporting/Printing etc.

Direct Paper output and printing works rather well, better than I expected. Even when “Ctrl + A” + Print-Selection Printing from comments etc.

► In terms of markdown or current/potential implementation: Indendation implementation should be based or extended from current “multi-column” and vertical adjustment bars: while providing dicts with different, saveable/editable indent naming/templates (key-value pairs)… akin to user-adjustable singleselect-fields… preferably with a new, working kb-layout conforming shortcut. This would enable aligning/reliability of multiple/custom indentation-preferences and values. (Numeric input and/or V-Bar adjustment)… while being faster and more reliable for larger documents, or accidental indendation-“overwrites” than even the best/classic word-implementation. Especially when a document-scoped indent-value-template could be selected as default for current/newly created indents.

2 Likes