You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Like featured sessions, projects also need a featured flag. However, the flag can only be set by website editors (not profile editors), a site-level membership type that needs to be defined in the membership ticket (#371, #401).
Since multiple projects can be featured but only one project can appear on the home page under the spotlight, a separate mechanism is required to pick the project. Candidate approaches:
The immediate next featured project (as determined by session dates) is always in the spotlight. This is the simplest implementation, but it has the drawback that if a small featured project precedes a large featured project, the small one will take priority even though users may be more interested in the large one.
Like the first, but projects are sorted as a function of both distance into the future (X-axis) and their importance (Y-axis; criteria and unit conversion TBD). The project with the larger angle on the left side of ◿ is sorted first. The lower left in ◿ presents the current moment, lower right the future date of the project, and upper right the Y-axis position of the project. What makes a project important? Participation headcount? Revenue? Past or current work-in-progress (aka "trending") performance? We don't know yet.
Build on the second, but also take into account other factors such as the user's location and the number of travelling participants in a project.
Approach 1 is a simple database query. Approach 2 will require periodic recalculation and caching and can be done every few hours. Approach 3 has an unknown per-user complexity. We may have to start with the first approach and keep the ticket open to achieve the second and third.
The text was updated successfully, but these errors were encountered:
Doesn't this also imply a featured_from? Also, what validations are necessary to ensure featured timestamps don't drift from project session timestamps?
Like featured sessions, projects also need a featured flag. However, the flag can only be set by website editors (not profile editors), a site-level membership type that needs to be defined in the membership ticket (#371, #401).
Since multiple projects can be featured but only one project can appear on the home page under the spotlight, a separate mechanism is required to pick the project. Candidate approaches:
The immediate next featured project (as determined by session dates) is always in the spotlight. This is the simplest implementation, but it has the drawback that if a small featured project precedes a large featured project, the small one will take priority even though users may be more interested in the large one.
Like the first, but projects are sorted as a function of both distance into the future (X-axis) and their importance (Y-axis; criteria and unit conversion TBD). The project with the larger angle on the left side of ◿ is sorted first. The lower left in ◿ presents the current moment, lower right the future date of the project, and upper right the Y-axis position of the project. What makes a project important? Participation headcount? Revenue? Past or current work-in-progress (aka "trending") performance? We don't know yet.
Build on the second, but also take into account other factors such as the user's location and the number of travelling participants in a project.
Approach 1 is a simple database query. Approach 2 will require periodic recalculation and caching and can be done every few hours. Approach 3 has an unknown per-user complexity. We may have to start with the first approach and keep the ticket open to achieve the second and third.
The text was updated successfully, but these errors were encountered: