Library repurpose and actualising Type for structuring info: Large Proposal for discussion

Attempting to merge, I played with the functions of type, layout, template, view.

My long messy attempt through mixing (if you are curious 😎)

A. MERGING TEMPLATE AND LAYOUT

Following the discussions of apply template to existing objectand layout/template, would the following make sense and work?

Templates is applying all contents. Layout is applying only the structure.

For example, Template object: ClassNote Title: Anytype Town Hall Date: 16 Nov 2023 Area: Anytype #Heading 1

  • For a template application: All above relations and their contents are applied.
  • For a layout application: only the relation type are applied to the objects, and favourite / pulled out relations / first block’s style are applied to canvas.

This way we can have both layout and templates but no addition thingy.

A1. HOW COULD IT BE DONE

For the purpose of reducing input steps, upon creation of object, template type application is prioritised. If there is applied template, prioritised layout application.

Prompt users of desired application method when apply template to existing object.

A2. REAL LIFE USE CASE

This enables users to switch between layout (created from template) for different purpose. e.g. FR new layout to show all relations of an object type for revision / overview purpose.

A3. PREREQUSITES

Current layout (e.g. heading, cover, action) can be applied to all object types. Theoretically speaking, this shouldn’t be difficult: cover is already a relation, action can be merged into a relation like ‘done’ relation; heading can be based on markdown/block/editor. Something like Layout as a Type / Custom user layouts


B. MERGING VIEW AND LAYOUT

The need to consider this merge is based on the idea to use layouts for different viewing purpose (A2) and FR Group by relations in kanban.

CURRENT MODEL IN THE MARKET TO REFERENCE

GitHub - marcusolsson/obsidian-projects: Plain text project planning in Obsidian


C. MERGING TEMPLATE/LAYOUT/VIEW AND TYPE

Multi-type will break the boundaries between object types. Templates would not be bounded by object type, we will have one less isolated thing anyway.

By merging template and type, the confusion between applying relations to a type or to a template could be resolved.

If we are to merge these two, we need to answer two things:

  1. What is type? Type could be the name of template
  2. How can Anytype remain to be Any’type’? Without devaluing the core concept of the software

So I rethink these concepts and how Anytype portrayed them. I hope I explained this idea clearly below :grinning:

Dear community, it’s time for a thinking party :tada:
Feel free to put forth your ideas​:bulb:and change anything :wink:

ANALYSIS OF CURRENT FRAMEWORK

Type contains relation type, templates and type item list, commonly used for types of physical object (e.g. books and bookmarks).

Template contains relation types and contents, block contents, block contents.

Layout contains editor/block/markdown structure.

View (e.g. Set/Graph/Object) contains canvas information, relation types and contents.

We can see a lot of overlapping managements, and that’s why people are confused and asking for upgrades to these feature (e.g. relations in template / type, type schema, Object type / Relation of type)

ALTERNATIVE UNDERSTANDING / ORGANISATION OF CONCEPTS

Every object contains some components, a canvas for placing the components, with a structure for presenting components.

If we actualise type as a call of (preset) information, we can ask Anytype to display required information. (Something like Tana?)

  1. Type as a list of components / elements
  • e.g. line divider, AuthorRelation, text blocks
  • Relation types (optionally with sequence or priority)
  1. Type as canvas / platform to work on e.g. Page, Graph/Whiteboard, Handwriting
  2. Type as structure of display
  • Taking callout as an example for structure, it stored information of colour, icon and as a block
  • Current PageLayout is also pre-defined structure with TitleBlock, CoverBlock, Layout Width; where NoteLayout omit TitleBlock
  • Card is another structure of displaying information
  • Are set/collection structure or canvas? Perhaps as long as there is no conflict in application, the boundaries of function / type can be loose. Callout can easily be added to the component list.
  • Every structure can be customised to be inline-able
  1. Type (e.g. positive as nature of type (which would also support text-based relation)
  • Nature of type provides information if a type will create conflicts with another type

Let’s bring Any’type’ to live.

This enables flexibility and versatility of templates/structure - to have simple and complex form for reuse. (Something like Obsidian Template - where templates can be applied wherever and whenever you want)

  • Simple type like ★★★☆☆ for RatingRelation
  • Complex type like books with author, local graph of people/characters, quote callout, inline collection of ideas, with

↑ This way Multi-type creates meaning beyond a relation because each type is requesting different information to display. This could also reduce the potential conflicts of inheritance, since it is user defined and used. For example,

  • Have BookType (Complex Type) as the base unit, we only need to have/add a FrictionTag for a NovelType (simple Type)
  • Apply RevisionType (Complex) which prioritise displaying information
  • Use BookmarkType, for an InterviewType contain InterviewerRelation and IntervieweeRelation, and ConversationType with editor/block with Person: Speech and alternating text colours. ← Multi-type

WHAT DO YOU RECOMMEND

What if we make/revitalise library as a place for users to structure and type control? Type Library (like app library) :thinking:

Something like a very simple version of Microsoft Publish(?) or mobile homescreen editing where people can fiddle around the location of components.

  • Allow creation of components/type or Add components to library when created at Object(?) ← where users input their contents / outside library
  • Allow customisation e.g. resize of block
  • Create some sort of component selection/addition to type (maybe drag and drop from a component pane)
  • Allow request of type at / menu

ADDITIONAL CONTEXTS

This would enable users to create type of all relations with customisation and format.

This should be in coherence with the concepts of everything is a block and atomic notes, for we are compressing the basic unit to a element level.

P.S. If this is not complicated enough for insights :crazy_face:, we can have exclusion or reduction of relation when a type is applied to another type.