Project form refactoring features

[Billybobbonnet]

We will make a complete refactor of the project form to include the feedbacks of the scientific advisory board, referents, and project contacts. Feel free to suggest features in this ticket @saadilahlou @sluck-IEA @Sdbns

What's identified so far:

• We need to add the ability to list project participants. I'm thinking of sortable list of firstname, lastname, and institution. The sorting order will be used in the cite widget to sort authors names. The project leader would be by default the first name, but it should be editable at every level (creation or edition).
• I'll add a better error handling, at the project step label level. Display warnings only when the field loses focus.
• Fix the issue with the search strings remaining on the autocompletes and the various menu alignments. Same deal with project search filters.
• Continents not explicitly set but inherited from country choices should be stored to allow to match e.g. projects with worldwide as continent and France as country to be matched when searching for Europe.

What should be discussed:

• Add a way to somehow allow the projects leaders to setup their preferences in terms of both collaborations and contact. Shall we have a fine grained system (could be too complex)? Should we allow project contacts to deny contact requests?

[Sdbns]

I still have both a practical and visual problem with the disciplines (other than being able to tick them all at once). If I tick a lot of them, the main field lengthens as a result, it's not very practical and you get a little lost. Also we can be tempted to click on the small blue cross of the field to delete only the discipline that is aligned with it, but it deletes the whole selection. It is not clear that to delete a discipline it is necessary to go back to the drop-down menu to uncheck it.

I still don't have an idea how to make the experience simpler and more efficient but I thought it was important to raise it.

[Billybobbonnet]

I'll look into a "+ X more" solution. Thank you for reporting this.

Le mar. 12 mai 2020 à 09:41, Sdbns notifications@github.com a écrit :

I still have both a practical and visual problem with the disciplines (other than being able to tick them all at once). If I tick a lot of them, the main field lengthens as a result, it's not very practical and you get a little lost. Also we can be tempted to click on the small blue cross of the field to delete only the discipline that is aligned with it, but it deletes the whole selection. It is not clear that to delete a discipline it is necessary to go back to the drop-down menu to uncheck it.

I still don't have an idea how to make the experience simpler and more efficient but I thought it was important to raise it.

[image: PROJECT FORM] https://user-images.githubusercontent.com/64425631/81652635-585e3280-9434-11ea-8752-e9c864134bbd.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/WPRN/website/issues/23#issuecomment-627170917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB626EC36BVBOMNYAJ5IUQTRRD4RPANCNFSM4M4DDNEQ .

[sluck-IEA]

I think the project contact and the project leader must be distinguished. The leader should be designated right from start in the general info section, with a possibility to add other participants (first name, last name, institution). It should be clear that the names should be added as they must be listed in the citation. I do not know whether we should limit the number of participants, but for the citation maybe indicate that if there are three names or more it will only be the first participant + "et al."? The contact person could potentially not be a member of the project team, even if it may not often be the case.

[sluck-IEA]

I suggest project contacts should be able to opt for a digest, weekly mode of contact (rather than receive an e-mail for every contact request), but maybe not as a default option: they could change it after submitting their project, with their edition link.

[Sdbns]

I think the project contact and the project leader must be distinguished. The leader should be designated right from start in the general info section, with a possibility to add other participants (first name, last name, institution). It should be clear that the names should be added as they must be listed in the citation. I do not know whether we should limit the number of participants, but for the citation maybe indicate that if there are three names or more it will only be the first participant + "et al."? The contact person could potentially not be a member of the project team, even if it may not often be the case.

Agree! But we cannot make the fields project leader and participants, mandatory fields, as this would not fit with "call for projects" type initiatives where no individual is clearly identified behind.

[Sdbns]

It makes me think that the quote is absolutely not relevant for all types of projects. Wouldn't it be interesting if it only appeared for certain types?

That might complicate things even more, but it's just a thought in case it is possible.

[sluck-IEA]

I think the project contact and the project leader must be distinguished. The leader should be designated right from start in the general info section, with a possibility to add other participants (first name, last name, institution). It should be clear that the names should be added as they must be listed in the citation. I do not know whether we should limit the number of participants, but for the citation maybe indicate that if there are three names or more it will only be the first participant + "et al."? The contact person could potentially not be a member of the project team, even if it may not often be the case.

Agree! But we cannot make the fields project leader and participants, mandatory fields, as this would not fit with "call for projects" type initiatives where no individual is clearly identified behind.

Project leader and project contact should be mandatory fields (not other participants) but could also be the same person, it is just two different roles vis à vis WPRN

[Sdbns]

I think the project contact and the project leader must be distinguished. The leader should be designated right from start in the general info section, with a possibility to add other participants (first name, last name, institution). It should be clear that the names should be added as they must be listed in the citation. I do not know whether we should limit the number of participants, but for the citation maybe indicate that if there are three names or more it will only be the first participant + "et al."? The contact person could potentially not be a member of the project team, even if it may not often be the case.

Agree! But we cannot make the fields project leader and participants, mandatory fields, as this would not fit with "call for projects" type initiatives where no individual is clearly identified behind.

Project leader and project contact should be mandatory fields (not other participants) but could also be the same person, it is just two different roles vis à vis WPRN

It doesn't solve the problem for initiatives that don't have an identified contact unless the field is less precise than what we already have with Last Name, First Name and Institution. Could it be just one and a much wider field, leaving the possibility to mention only the institution? The downside is that it will be much less uniform in the end if we leave more freedom.

I just want to point out that it does show that the site is designed for projects as a priority and not for other initiatives launched by institutions. It remains to be seen whether we want to take everything into account or only focus on projects.

[Billybobbonnet]

Having distinct approaches depending on project type is a possible improvement that we considered but we must sum up what variations we offer based on project types.

We should limit them to avoid inconsistency in the project documents, but those we choose to enforce could and should be reused, e.g. :

• Multiple project participants feature is allowed only for some types of projects
• The cite widget feature is available only for some types of project
• The contact button could be available only for some projects (to discuss: what type, based on other variables like the number of contact requests...)
• Some project types imply a date and time. We could have a generic date/time for project event types, and a time interval for others, i.e. 2 date/time (e.g. seminars, call to research projects, etc.). The second date/time of intervals could be set to "indefinite" for e.g. calls for collaboration. The time based projects status would switch to "complete" once the date is past.
• The url field should be mandatory for some project types (website, video, policy, etc.)

The main issue with this feature is when multiple types are attached to a single project. Custom additional fields would accumulate and that could make the form too complex in terms of UX. That's why I suggest that we consider firsthand the variations implying a removal of a field and the simplest versions of the addition of fields.

As long as we maintain some consistency in the UX, we could go further in terms of type based customization in the project page. But that would be for another ticket (project page refactoring features?)

[sluck-IEA]

I do not know if it would be too complex to implement but one way to avoid the multi-criteria custom additional fields would be to make some project types incompatible with other project types, i.e. they cannot be selected together/can only be selected alone. I assume it is mostly research projects that can check several boxes. Calls for proposals cannot be seminars and publications at the same time (but we could add different types of calls in the list; calls for papers, for projects, for panels in conferences, etc. so that people do not feel the need to complete the information by clicking on another type).

[Billybobbonnet]

I do not know if it would be too complex to implement but one way to avoid the multi-criteria custom additional fields would be to make some project types incompatible with other project types,

It can be done without much trouble and it seems like a good idea. Note that I maybe will have to disable the removed types instead of removing them from the choices to avoid confusing users. It could be frustrating to them but worth it afaik.

It will require some work to make the whole incompatibility table of project types and their related extra fields. Could you start working on a google sheet? It would be very helpful to have to have a doc to summarize it. I'll try to help along the way, and I'm sure @saadilahlou and @Sdbns can help too.

[Sdbns]

yes ! of course

[Billybobbonnet]

We have a growing number of features, all relevant and needed. With the needs related to the Project page refactoring features issue, it becomes even bigger.

Here is an idea: what if we split the project definition in 2 parts?

The first one would include only the most needed information in order to verify it, i.e. contact related info, title, description, disciplines & thematics (to be completed). Lightweight and straightforward.

The second part would be introduced on the page where the contact user verify his/her email address. We keep the token based account free system, but the edit page allows to further define a project, team, attach files, etc. and is proposed directly after the email is validated.

[Sdbns]

Here is an idea: what if we split the project definition in 2 parts?

The first one would include only the most needed information in order to verify it, i.e. contact related info, title, description, disciplines & thematics (to be completed). Lightweight and straightforward.

The second part would be introduced on the page where the contact user verify his/her email address. We keep the token based account free system, but the edit page allows to further define a project, team, attach files, etc. and is proposed directly after the email is validated.

Could we make the first and last name fields of the contact not mandatory in the first part? If so, it seems like a good solution!

[sluck-IEA]

Right now I think the only 2 essential additions we have mentioned for the form are:

• Description of the team at the start of the form: leader + possibility to add other collaborators that will appear on the project page and in the citation: I think this is valid for every project type (even though for some projects the citation will be disabled). Right from the start of the form, the contributor should fill out : Project leader/first author : fields = First name, Last name, Institution (possibly name not mandatory in the case of calls for projects or contribution submitted by the organizing institution, not a specific individual) option Add Participants/authors: if selected, same fields First name, Last name, Institution. Question is how many collaborators can be added max. 5? And what impact on citation? (et al. when more than 2 authors/collaborators?). By default, contact names at the end of the form should be filled out with the names of the Project leader/first author.
• Possibility for some projects to add times and dates: to make it more simple, time interval and date/time should be dealt with together (like an android phone event creation): contributors must pick a start and an end date (and possibly times), but if there is only one date they just pick the same: from September 1 (option: 8:00) to September 1 (option: 18:00). This allows for one-day events as well as several-day events.

And the 2 other changes (mentioned in the previous two additions) in the submission form are

• Name of project leader and contact not mandatory in the case of calls
• Contact names at the end of the form should be filled out by default with the names of the Project leader/first author, but of course modifiable.

Plus 1 Consequence in the view mode of some project types (calls, others?): no citation