@SiriusXT
What is your motivation?

Showing pageUrl always is a bad move. You are stealing scarce vertical space on a desktop with no gain in a return.

@contributor In the original ribbon, having a page URL would take up vertical space by default.
In the new Info bar, however, it is part of the note itself and moves upward as the note scrolls vertically, rather than being fixed.

@contributor In the original ribbon, having a page URL would take up vertical space by default.

@SiriusXT
In the original ribbon, the page URL is displayed only in one tab the ribbon (Info)

In your PR, it is displayed on EVERY tab of the ribbon

In the new Info bar, however, it is part of the note itself and moves upward as the note scrolls vertically, rather than being fixed.

It still consumes space when you don't scroll.

Update: hiding it when with scroll is good one, I was too quick with "no gain" statement

Still, the old pageUrl approach has this advantage:

• You read a note, scrolled down few pages
• You decide to open original web page (to view comments, updates or whatever)
• You click on a ribbon tab and click on a link without losing scroll position of your note
• You go back to your note and continue where you left off

On desktop you could argue: just scroll up, click, then scroll down, not big deal.

But what about mobile? It is absolutely insane to suggest this doing on mobile, instead of current perfect implementation:

Here is how things works on mobile now:

original page is ALWAYS one click away if you need it

just tap on ribbon tab to hide it if it distracts you

Please do not take it away

Aha, it seems you prefer the original way.
Or we could modify it like this: by default, let it still scroll with the note.
When Note Info is expanded, keep the Info bar (including the origin URL and shared URL) always visible.

Here is how things works on mobile now

@contributor ,

Last time I've checked there's no ribbon on mobile.

Here is how things works on mobile now

@contributor ,

Last time I've checked there's no ribbon on mobile.

Rigth.The screenshots are from my build. No ribbon in the official release, but there is no reason not to have one. I could send a PR

@contributor This CSS is quite helpful:

.note-split:has(.note-info-widget) .content-header-widget {
    position: fixed;
}

When Note Info is displayed, the Info bar becomes fixed.

When Note Info is expanded, keep the Info bar (including the origin URL and shared URL) always visible.

ShareURL is different.
The only reason to dislpay it is to say:
"Hey, user. Don't forget this not is shared. Don't write your passwords here"

With that purpose in mind, let's consider our option:

• always visible (sucks, takes space, but is strong security reminder)
• new approach (hide with the scroll, better for reading, sucks for security - user scrolled down and forgot shared status)

Neither one is good.

What would work better - just link with text "Shared" in location indicated by a green mark (applicable both for desktop and mobile):

• security reminer - checked
• no extra vertical space - checked

And in any case, please consider "Clipped from" wording instead of current overly verbose "This note was originally taken from"

@eliandoran

By the way, current Edit Note bar already has the same problem (even worse) of losing context/scroll position as new pageUrl will have.

Here is the problem: You reading a long read-only note, found a small type, want to fix, and… Now you can't. Or rather don't want to bother with going up, turning on edit mode, and the FINDING the place to edit.

I'm getting “atlassian confluence" flashbacks, when you were supposed to used it on a work, but UX was unbearable exactly because of this friction to turn on edit mode and then go back and find the place you wanted to edit in a huge document/table

Previous floating edit button was perfect. Maybe even unique in this regard with its scroll to previous (almost exact) position feature. Heck, even github does n't have this, which kinda forces me to keep an issue text or comment small enough to have ... menu reachable without scrolling when I need to edit the text.

New bar is not good for all of the cases:

• edit button
• pageUrl
• shared reminder

The existence of two ribbon tabs that both use an info icon is confusing, and it’s an issue that should be addressed.

This could be resolved either by using an info bar, as @SiriusXT suggested, or by moving it to the “Note Info” tab. I don’t see any reason for the origin URL to have its own dedicated ribbon tab.

@eliandoran

By the way, current Edit Note bar already has the same problem (even worse) of losing context/scroll position as new pageUrl will have.

Here is the problem: You reading a long read-only note, found a small type, want to fix, and… Now you can't. Or rather don't want to bother with going up, turning on edit mode, and the FINDING the place to edit.

I'm getting “atlassian confluence" flashbacks, when you were supposed to used it on a work, but UX was unbearable exactly because of this friction to turn on edit mode and then go back and find the place you wanted to edit in a huge document/table

Previous floating edit button was perfect. Maybe even unique in this regard with its scroll to previous (almost exact) position feature. Heck, even github does n't have this, which kinda forces me to keep an issue text or comment small enough to have ... menu reachable without scrolling when I need to edit the text.

New bar is not good for all of the cases:

* edit button

* pageUrl

* shared reminder

The previous floating edit button had a flaw. For new users, it wasn’t immediately clear that a note was read-only, how to edit it, or why it had become read-only in the first place. That’s why I introduced the Edit Note bar.

And yes, I agree the current implementation can cause you to lose context or scroll position when you try to tap the edit button. I had planned to make the floating edit button reappear when the bar moved out of the viewport, but I didn’t manage to work on that before the last release.

I’m still deciding on the best way to keep the info bar accessible from any scroll position without making it intrusive. One option is to have the bar reappear when you slightly scroll up from your current position. This could be useful for other info bars as well, such as the one showing the note origin.

I think this PR can be merged once the info bars can be accessed without losing context or scroll position.

For new users, it wasn’t immediately clear that a note was read-only, how to edit it, or why it had become read-only in the first place.

@adoriandoran

This UI will be clean and functional:

• Make NotePropertiesTab ribbon available for mobile too
• If a note is read-only this tab will auto-show with edit button on that tab (above or below pageUrl)
• If a note is neither read-only nor has pageUrl the tab is not displayed.
• When the tab is displayed, user can close it or leave it to have ability to enter edit mode or navigate to original web site from any position in the note
• Put Shared link left to "Note revision" icon (like I posted above)

Make NotePropertiesTab ribbon available for mobile too

Actually, enable also Note Info tab which is always available and make ribbon presence consistent.

I run my instance with three tabs enabled for mobile:

• Note Info (to see date created/modified)
• Note Properties (to see pageUrl)
• Edited Notes (I use custom grouping and sorting to show edited notes in full note height - this prevents reluctance to move notes out of inbox to proper place in the tree without losing easy access or forgetting about them)

Works perfectly and don't consume space when tabs are closed.

Just replace Note Properties icon to something else to avoid having two i's on screen.

This could be default.
Ideally, user could select which tabs to show in mobile layout via settings or just options in db

Ideally, user could select which tabs to show in mobile layout via settings or just options in db

And not only for mobile. I never find Similar notes tab to be usable, and would gladly filter it out on desktop

@adoriandoran

Another reason why edit note bar UI is not good:

My inbox note is not intended to be edited at all. It is just a container. And is read-only to prevent on screen keyboard on mobile to popup. Why would I want to see the bar at all?

For new users, it wasn’t immediately clear that a note was read-only, how to edit it, or why it had become read-only in the first place.

I think there is a conflation of two different cases:

• note is auto-set to read-only (by the app, for performance reasons)
• user is deliberately set #readonly attribute

UI can be different for that cases

@contributor ,

My inbox note is not intended to be edited at all. It is just a container

In this particular case, you can just change the Note Type from Text to Collection. This more clearly specifies the intent of a container.

UI can be different for that cases

I believe it already is, since there are two different messages depending on whether it was auto read-only or manually set.

In this particular case, you can just change the Note Type from Text to Collection

Yes, Collection type works perfectly for inbox. But for other read-only notes it may be not be suitable, as it adds its own text:

@contributor, thank you for your suggestions. The bar will be updated in the future releases to become less intrusive and to improve the UX as well.

Meanwhile, it's safe for you to hide it on the desktop client with some custom CSS. The “Edit note” command is always present in the (three dots) note menu.