Embeddable Objects/fully expandable previews or another way to put it "create portal to object"

Feature Requests
, , ,
1

WHAT DO YOU RECOMMEND

Right now we can preview a link to another object and we have some choice over how that preview is displayed.

Let’s make it so that the preview can be fully expandable within the current document. For example, I have a note that contains a link to a list of book recommendations. From the preview I can see what exact it is and maybe small preview of what that “object” is whether a list/set, note, page, etc. ALmost like a window or a portal.

The user can then easily expand the object fully, within the currently open object. This could be done ad inifitium: If inside of the list of book recommendations, I have separate lists for fiction or nonfiction, in the note in which I’ve linked to the book list, I can full expand and edit the book list as though it’s the currently open object. I can then fully expand any objects within it, say I’m just interested in viewing the fiction books to add recommendation I heard, I can expand the books list object, then expand the fiction books object and add my recommendation

HOW COULD IT BE DONE

I think the preview interface that’s already integrated is the perfect building block. From there we allow the user to fully expand and edit that object from the preview pane.

There’s many ways to desribe this: portal, window, preview, etc. But I think portal is the most accurate. Window sounds nice but “wiindow” has already kinda been taken… by windows…

For portals to objects to be infinitely expandable - meaning one can have objects nested infinitely deeply yet view the entire contents of said objects from one frame/note, it would require a way to respect the page layout.

for example, if the preview is indented - that could make expanding the preview fully somewhat odd. The page may be a full fledged page and the indented preview would make restrict the width, which could lead to unexpected and undesirable behavior. Thus, if you’re going to make a fully expandable portal - it should be at the top level of the current object.

I also see a use case for example, a book list with two columns. Each column is actually a portal to a new list, one for fiction and one for non fiction.

In this case, in my main notes which I use to manage daily thoughts/tasks, I could make a portal to this book list, and from there, easily access and edit that object.

REAL WORLD USE CASES

Already described above

RECOMMENDED ALTERNATIVES

currently, you can link to objects, and you can add previews to objects. More options regarding how to tdisplay those previews could be a good stepping stone

ADDITIONAL CONTEXT

I believe there’s some over lap with Everything is a block and [nesting objects and sets inside each other(Nesting Objects/Sets inside each other - #7 by qualquertipo)

Nomenclature

I think words like “nesting” have connotations of indentation and hierarchy which can derive from such indentations: 3 levels nested, that’s a grandchild etc.

I think the most simple and obvious wording is “embed” or “embedded portal” or “embedded object” I kinda lean towards using “embed” as a shorthand for “embedded object”. Portal just serves as a useful frame of reference as to what exactly is going on. But I also like using “portal” as a shorthand. I’m open to improvements of the nomenclature of course. Calling something a portal just has a more intuitive sense to it. Embed is more connotative of the means, and portal is more connotative of the ends. One way we could put it: A portal is simply an object which is embedded in another object.

UI/UX Ideas

I believe it will be necessary for the width of the portal, when fully expanded, to match that of the current document. That or to allow the user to define the layout of the portal. My reasoning for this being that the portal should be able to contain portals of its own. These portals should also be fully expandable, while staying in the context of the main note. The example of adding a book or movie recommendation comes to mind.

So how do we show this? How does the user know they’re looking at a portal within the context of the current note?

I have a couple ideas that I think could be really effective:
One point of these ideas and the idea of portals in general is to keep context. I believe that the “physical” metaphor really helps maintain context. The folks working on Stack Next for example, are doing a good job of showing that the closer to a physical representation we can get, the easier it is to reason about.

Instead of theorizing, I will describe a common use case and what that will look like:

I have a “main notes” which is just daily stuff. It’s like the central hub of my note taking (this is actually how I personally use my notes programs). Within Main Notes, I have a portal to my “Books recommendations” page. This page has a portal to two other pages: “Non fiction books” and “fiction books”

Within my main note, the “Books recommendation” portal looks similar to how a preview looks now. A layer atop the main note foundation. I click to expand the books portal and the preview expands to fill the full width of the page but maintains that feeling of sitting atop the main note. I then select to expand the nonfiction section. This too sits atop the books recommendation page and expands fully. From there I type in my recommendation and maybe some notes about why I am interested in this book.

I then collapse the books recommendation section.

The view maintains a physical metaphor by layering as opposed to a nested hierarchy.

8 Likes
2

Super @ShawnSalat!

I assume you’ve explored the transclusion topics so I won’t burden your eyes.

Love the concise detail as to how it could be implemented, and distinguishable nomenclature. :raised_hands:

1 Like
3

You should definitely check/vote on other topics related to transclusion, as @Angelo mentioned.

Indeed what you mention is related to the “everything is a block” topic I raised long ago. In this more recent post I show how this works in practice in RemNote - if you watch the video you’ll see that the expanding behaviour is similar to what you are talking about (in this case there is no transclusion going on, but the principles are the same)

1 Like
4

I’ve upvoted all the transclusion/nesting feature requests that I’ve seen. I think we all have a similar vision, but different preferences as to the UX.

What you show in RemNote is something I’ve used with other similar note taking programs that turn everything into a bullet point. There’s a lot to like, and while the theory is quite similar, we are describing different ways to put it into practice.

My reasoning for wanting to be able to open the full preview inside the note is because of context. I believe when you zoom into a particular REM, the mental effect is that the context of the note you were in before is kind of cleared. And while REM and other such programs allow an infinite level of nesting, what I’m describing doesn’t technically require nesting in the sense that “nesting” requires indentation.

I believe the nomenclature “nesting” has a connotation of indentation. There’s also a connotation of hierarchy - parent child grandchild being connoted by the level of indentation. So the way I’d like to phrase what I’m describing here is more like an embedded portal. Or just an embed. What I’m proposing is the ability to have infinitely embedded “portals” or objects, without any need of nesting.

Ironically, the remote solution is very reliant on nesting, while the solution I’m proposing almost requires that the portals are not nested (Though I think that’s a UI hurdle that I don’t have the exact answer to at the moment). meaning to say that an embedded portal should be useable anywhere, but it begs the question as to what the UX will be if a person fully expands an embedded portal that’s nested say, three levels deep. It also begs the question if that is a remotely likely use case, as I see the embedded portals as more of an organizational concept.

So there’s some big differences between what I’m describing and the UX of a bullet point that can be infinitely zoomed such as in rem note:

  1. In fully expanding a preview/portal, one can very easily retain the context of the note they’re currently in.
  2. The embedding is done without need to navigate to another page. It’s more physical and maintains context.
    I believe this is important to one aspect that’s fundamental to any notes app: We want the least amount of friction between what’s in our brain and putting that into a note document in an organized manner. I think the physicality of a portal removes some of the friction - the physical metaphor makes it easier to reason about.

As a matter of fact, I think the UX are so distinct that they’re not exactly at odd with one another. There could be portals and this type of collapsible outline. There could be one inside of a portal for example. I think both ideas are great.

3 Likes
5

We’re definitely saying/wanting very similar things!

Not sure I follow the differences you mentioned…

I didn’t understand this:

Also not sure about the below, as in a system like RemNote you never need to navigate away from the context you’re in (you can, but don’t have to):

In the video (in the post I shared) I just stay in the same “page”

1 Like