Differences

This shows you the differences between two versions of the page.

--- hortus:publish:projects [2026/04/07 11:19] – savino.frisardi
+++ hortus:publish:projects [2026/04/08 12:16] (current) – savino.frisardi
@@ Line 13: / Line 13: @@
 {{:hortus:publish:projectcreationpage.jpg?600|}}
+^ Field or option ^ Why it matters ^
+| **Project image and name** | These give the project its visual and textual identity in discovery lists and on the project landing page. A clear image and a descriptive name make the project easier to recognize, remember, and open from the Projects list. |
+| **Page type** | This classifies the item as a Project page or Tool, which affects how the page is interpreted in the Projects catalogue and how users understand its purpose at first glance. |
+| **Project level (Root / Child)** | This lets the team reflect the real structure of the research initiative. A Root project works as the main entry point; a Child project supports sub-teams, sub-workstreams, or thematic branches inside a larger programme. |
+| **Parent page (for child projects)** | When a project is created as a child project, the parent-page selection links it to the broader project hierarchy. This is useful for representing complex research organizations and showing how a focused sub-project belongs to a larger initiative. |
+| **Abstract** | The abstract is the core narrative summary of the project. It explains what the project is about, why it matters, and what users should understand before moving to contributors, resources, discussions, or folders. |
+| **Rich-text project description** | The project page is not limited to one short summary. It can be expanded into a structured presentation using rich-text content, which makes it possible to describe methods, objectives, datasets, teams, outputs, or use cases in a readable academic format. |
+^ Paragraphs^^
+| **Additional paragraphs / sections** | The New paragraph function allows maintainers to add as many structured sections as needed. This turns the project page into a true research landing page rather than a fixed single-text block, and supports long, well-organized presentations. |
+| **Paragraph labels / tags** | Labels help structure and scan the content inside the project page. They can highlight themes, methods, or concepts and make long descriptions easier to navigate visually. |
+| **Paragraph URLs** | URLs inserted at paragraph level allow the project to connect directly to supporting material such as documentation, repositories, institutional pages, forms, publications, or external services. |
+| **Paragraph images by URL** | Image URLs allow sections of the project description to be enriched with visual material. This helps make the page more attractive, supports communication, and gives maintainers a way to add contextual or illustrative multimedia elements. |
+^ Call To Actions buttons^^
+| **CTA buttons (Actions panel)** | The page supports multiple call-to-action buttons. These transform the project page from a static description into an actionable landing page by linking users to training, documentation, videos, surveys, repositories, registration forms, tools, or other internal or external destinations. |
+^ Fields^^
+| **Maintainer field** | This identifies the person responsible for the page. It strengthens accountability, clarifies ownership, and helps users understand who is curating or stewarding the project. |
+| **Copyright and copyright text** | These fields allow the project to state ownership and legal framing more explicitly. They are useful when the page represents institutional work, curated content, or material that should carry a formal rights statement. |
+| **License** | The license is essential for reuse. It tells users under what conditions the project content or linked materials may be reused, cited, or redistributed, and therefore supports responsible scholarly sharing. |
+| **Version** | The version field helps maintainers communicate project maturity or editorial state. It is useful when a project evolves over time and the team wants to signal whether the page is early-stage, updated, or formally stabilized. |
+| **Type / additional descriptive fields** | Fields such as type and similar descriptive metadata make the page more explicit and easier to interpret. They help keep the page usable not only as a presentation object but also as a structured catalogue object. |
+| **Optional metadata toggles** | The right-side panel shows optional fields that can be enabled only when needed. This is important because it lets maintainers keep the page light by default, while still supporting richer description when the project requires it. |
+| **Keywords** | Keywords improve discovery and reuse by making the project easier to find through filtering, search, and thematic navigation. |
+| **Languages** | The Languages field helps indicate the linguistic context of the project or its materials. This is especially useful in an international research environment and for multilingual projects or outputs. |
+| **Supported operating systems** | This is particularly relevant when the project page presents a digital tool or technical component. It helps users understand compatibility before they engage further. |
+| **Repository** | This field allows the project to point users toward a code repository, archival repository, or technical resource space. It is especially useful for software-oriented, data-oriented, or openly developed projects. |
+| **Support** | The Support field gives the project a clearer operational dimension by indicating where users should go for help, clarification, or technical assistance. |
+| **External link** | External links extend the project beyond the HORTUS page itself. They can connect the project to websites, forms, portals, datasets, documentation, or partner systems and therefore make the project page more useful as a gateway. |
-  * access project creation
+**Note on project-resource visibility**: when resources are associated with a project, they become part of that project’s contextual resource layer and can be exposed through the Resources tab. In hierarchical structures, child projects help organize related outputs inside a larger project framework, so resources can be presented in the relevant project or sub-project context depending on how the structure is configured.
-  * define:
-    * title
-    * description
-    * objectives
-  * add members
-  * link resources
-  * configure visibility and structure
-  * submit for moderation (if required)
+**In practice, the Create Project page lets a maintainer build not just a page, but a complete research landing space: visible, structured, reusable, and connected to people, resources, and actions.**
-Projects act as:
-  * research hubs
-  * organisational structures
-  * collaboration environments
 ----