Feat: Consolidate note metadata in a single icon

[gravelfreeman]

The metadata below the note title currently takes up quite a lot of space for information that most users probably don't need to see all the time.

• Creation date
• Last edited date
• Word count

They could all stay inside the existing information panel instead of being permanently displayed.

The information icon could simply be moved before the Folder and Tags:

I think Poznote's default view should stick to a less is more approach. A cleaner interface feels less overwhelming for new users, while the extra information remains only one click away when needed.

There is also some duplication here, since note information can already be opened from this menu:

I would keep this menu focused on global options and general help, such as keyboard shortcuts and Markdown syntax, while keeping note-specific information in one dedicated place.

[timothepoznanski]

They already stay within the existing information panel, and the three pieces of information can be hidden separately via Element Visibility, like almost everything in PN.

I agree with the “less is more” approach, but I was worried new users might not realize these infos can be displayed, so I’d rather show them by default and let users hide them if they don’t need them.

Same for the information button: I was afraid users might not know they can click it to see the note info, so I kept it in the bottom-right menu since it takes up virtually no space.

[gravelfreeman]

I was worried new users might not realize these infos can be displayed

I think a nice long-term solution could be to introduce presets during the new-user setup, where users can choose how they want the editor to look.

Those presets could later be configured per workspace. For example, when I'm doing lab documentation, I probably don't need dates or word counts visible. For a school workspace, I could use a Student preset that displays that information by default.

That said, I see this as a P10-type feature. I wouldn't spend development time on it until the core application and editor are very solid.

---

For now, I still think the metadata is visually a bit heavy. At minimum, I would suggest:

• Using subtle, greyed-out text
• Reducing the font size
• Centering it at the bottom of the screen in a floating footer
• Giving the footer a transparent background
• Keeping its overall footprint as small as possible
• Adding a simple toggle in the settings to disable the footer entirely, since Visibility of elements is currently a bit too deep in the settings for something this common

In my experience, users also tend not to work at the very bottom of the screen most of the time. Because of that, an always-visible footer feels less intrusive than metadata that is rarely needed but permanently displayed directly under the note title.

Same for the information button: I was afraid users might not know they can click it to see the note info, so I kept it in the bottom-right menu since it takes up virtually no space.

I would try to keep each menu and toolbar focused on a clear purpose 😈

Header toolbar

Represents controls related to the current note.

Sub-header toolbar

Represents sorting and organization options for the note.

Text-formatting toolbar

Represents text formatting options.

Left-side toolbar

Represents global Poznote features and options, such as appearance, documentation, AI, etc.

Footer

Could represent live, dynamic metadata, such as word count, dates, and similar information.

Following the same idea, I think this would also be a good opportunity to simplify the top toolbar.

Some options modify the file tree, even though the user isn't interacting with it. Since those actions already exist there, I would remove them from the note toolbar.

For the same reason, I would also remove the Delete icon from the toolbar:

I would also move Insert Markdown into the / menu, since it feels more closely related to editor content than note-level controls:

That would leave a much smaller [...] submenu. The remaining actions could potentially become direct toolbar icons instead.

I would then group these three related actions under a single Share / Export submenu:

• Share this note
• Download
• Print

They all serve a similar purpose: getting the note out of Poznote in one form or another.

This would reduce the number of visible icons while also grouping related actions more clearly.

[timothepoznanski]

Thanks for the detailed write-up, there is a lot in there so I'll go through it in order.

On the metadata line: it is already in small greyed-out text (12px, muted colour). I'd rather not move it to a floating footer: the bottom of the screen already holds the edge buttons on desktop and the keyboard bar on mobile, and a footer floating over the note would cover text on long notes, whereas the line under the title scrolls away with it.

What I do take from your point is that six separate checkboxes in Element visibility is too deep for something this common, so a single switch that hides the whole line in one click makes sense and I'll look at adding it. Presets per workspace are a nice idea, and I agree with you that it is not for now.

On the Information entry in the bottom-right menu, I'll keep it for the moment for the discoverability reason I gave above, it costs nothing in space.

On the toolbar, I agree with the principle that each menu should only hold what relates to the part of the UI you are touching, it is the rule I already follow for the tree menu. Shortcut, Duplicate, Move and Archive in the note menu are indeed duplicates of the tree menu, so I'll check whether they can go without leaving mobile users with no way to reach them. Moving Insert Markdown to the / menu is a good idea too, it is about the content, not the note.

I'll keep Delete in the toolbar though, it is used too often to be one more click away. Same for grouping Share, Download and Print: I see the logic, but Share is a one-click action today and I don't want to put it behind a submenu.

[gravelfreeman]

it is already in small greyed-out text (12px, muted colour)

I'm not sure what happened, but I still had the larger font size from before, so it looked huge on my end. Disabling all of them and then re-enabling them fixed it for me.

I'd rather not move it to a floating footer

Yeah, maybe a centered footer isn't ideal for the reasons you pointed out. I remember someone asking for the word count, and I thought they might like seeing it at all times without having to scroll all the way back to the top and then find their place again in the document. That's why I was referring to it as a live metadata section.

I would suggest by default showing only the last edited date and total word count. I would leave the created date, lines/chars count disabled by default.

I think this is looking very good :

Just noticed there's a bullet separator before the [i] icon. I don't think it belongs there, since the icon isn't part of the metadata list. I'd use whitespace instead to separate the text metadata from the interactive action button.

On the Information entry in the bottom-right menu, I'll keep it for the moment for the discoverability reason I gave above, it costs nothing in space.

Is there any particular reason why it's not in the toolbar anymore? I think it was in the [...] menu before.

I'll keep Delete in the toolbar though, it is used too often to be one more click away.

I'm surprised to read that. I guess we all have different workflows 😄

For me, the bin icon represents a fairly important and destructive action. I understand if you want to keep it there, though I would suggest moving it in the [...] dropdown.

Same for grouping Share, Download and Print: I see the logic, but Share is a one-click action today and I don't want to put it behind a submenu.

Toolbars isn't an easy horse to ride when you try to make it efficient to interact with. It's crazy how easy it is to get lost even with few buttons. If you're interested those are good ui/ux docs and I'd also be intrigued to feed an Ai with it and ask it against the codebase and see what they propose 😄

https://fluent2.microsoft.design/components/web/react/core/toolbar/usage
https://developer.apple.com/design/human-interface-guidelines/toolbars

Both of our visions are doable just by grouping types without drop downs which is even better than my original idea.

Maybe just adding some grouping to both toolbars would help shape things.

[timothepoznanski]

I've implemented the suggestions I found relevant.