Closed anishTP closed 2 months ago
Folders are a relatively poor form of categorization and should be avoided:
There are better ways to organize content, discussed in #1421.
My bad, I misread the implication of the term "folder" here. Nevertheless, #1421 discusses how this can be achieved. Community editors cannot be expected to list related related projects as an operational flow -- if there was existing intent to do this, they would have already been doing this in the project description, as we've seen for listing sponsors before formal support was added.
Additional context: An operational flow that was requested was to have sub-projects within a parent project. This was mainly to avoid creating accounts as line-extensions of existing accounts. But sub-projects implies some kind of hierarchy in the chain - account>project>sub-project. And it also opens up issues of participant information sharing between parent and sub-projects. The sub-project in its current implementation is more of a navigational link between projects than one where there is information sharing. Hence, it makes more sense to rename this to related projects and allow editors to list projects that are related by topic or format. Having content tagging in place is no doubt a better way to do this. But it would be better to have manual workflow in place that renders the content in a proper hierarchy before we get the automated version in place.
Sub-projects were introduced as a way to isolate the workspace for track editors in a multi-track event. This requirement faded before Funnel had participant management, and Boxoffice never used it, so sub-projects remain under-specced. #2006 proposes to use sub-projects for participant isolation, removing the many redundant models introduced for Boxoffice.
Sub-projects are not a suitable mechanism for topic categorisation. Since a sub-project can only have one parent project, the parent project is effectively a folder. This makes sub-projects unsuitable for expressing relatedness. They can only be used to represent exclusive containment -- such as tracks within a larger event.
Issue: The current implementation of sub-projects allows any number of projects to link to a project as a parent. However the parent project lists only one child as a 'Related event'. Inside parent project page(with 3 child projects):
Inside child project
Instances that are exclusive containment would also include projects that are made for session rehearsals, workshops that need participant isolation, pre-event seminars or meetups etc? In such cases there is no difference in having them as a separate project or listing them as a sub-project since participant isolation is the main requirement. But linking them to a parent does make sense.
However the parent project lists only one child as a 'Related event'
This is a bug. Since sub-projects were intended to represent tracks, all sub-projects should be listed with equal priority, ordered by date if they start at different times. Pre-events were not originally expected, but if they are part of the use case now, they should be de-prioritised in display. I'm not comfortable adding pre-events as an expected use case though as it will lead to abuse of sub-projects for topic categorisation.
Instances that are exclusive containment would also include projects that are made for session rehearsals, workshops that need participant isolation, pre-event seminars or meetups etc? In such cases there is no difference in having them as a separate project or listing them as a sub-project since participant isolation is the main requirement. But linking them to a parent does make sense.
Yes. In addition, marking a project as a sub-project should hide it from the account's list of projects (expected current behaviour; if deviating, that's a bug). This design could be revised to instead show the parent project as a panel with a header, with the sub-projects listed as cards within.
Feature overview
The project page is semantically related to a folder inside a file explorer. It houses content of a certain kind in the form of submissions and all other contextual information. This 'folder' is located within an account that has many such 'folders'. Some of them are related to each more than others. Currently there is no means of associating the projects/folders that have related content. Project pages are more or less an endpoint on the website as far as content discovery is concerned. However users who land on a project page are going to be interested in other projects that have related content. This brings up the need for displaying information about related projects in the project landing page.
Information Hierarchy
As far as information hierarchy on the project page is concerned a 'related project' section would come lower down the hierarchy when compared to the other project-specific information on the page. Hence it reasonable to assume that this section would appear lower down the page. As a secondary point of navigation, all related project can be listed inside a separate tab in the sub-navbar on the project page. The pieces of information from the related projects that are of interest to the user are mostly present in the project card component. So, this component can be reused for the purpose of listing all related projects in this section.
Affordances
Users The 'related projects' section enables the user to navigate to various project pages listed in this section. In case the number of related projects exceeds four, 'view all' button takes the user to the 'related projects' page where all related projects will be visible.
Editorial The project editor can choose from any public accounts, the projects they wish to list under the 'related projects' section. The projects will be displayed in the order in which they are listed by the editor. These actions will be available to the editor in the projects settings menu.