Revise Project Details page

[stephaniesimms]

UX wireframes @JEK-III : http://h90c3m.axshare.com/#g=1&p=write_plan Functional Specification (global spec for all write plan pages): Implement with a non-table layout; attach labels to input fields Related issues for write plan pages #494 #495 #497 #498

Revise the main plan writing pages per wireframes. blue notepad functional spec for Page Title at top of page, use "Project Title" field on the Create Plan page

First tab is renamed "Project Details." Blue notepad icons in wireframe contain functional specs:

• prepopulate Project Title and Funder from Create plan page
• prepopulate Principal Investigator Name, ORCID, email w/info in user profile
• check Data Contact person same as PI (default); if user unchecks display Name and Email fields for different Data Contact

Guidance selections move to right of Project Details, also described in related issue #495 for Write Plan page. Note blue notepad functional specs:

• guidance choices to display
• add selector box at bottom to search for additional guidance from Org list; options to type ahead or "See full list"

[briri]

I started work on this one a while ago but then refocused to finish the CSS rewrite. Here's a list of what has been done so far:

• Added a data_contact_email and data_contact_phone field to the plans table and page.
• Added rake task to extract emails and phone numbers from the existing data_contact field
• Switched over from tables to fieldset in the form
• Added a visibility section (has since been moved to the 'share' tab)

@sjDCC and @stephaniesimms the latest wireframe has removed the data contact phone number. There are valid phone numbers though in the dmponline data. They are currently stored in the one data_contact field (e.g. John Doe, t: +12345678, e: john.doe@institution.org). I have a script that was extracting these values and placing them in the appropriate field. Should I update that script to leave the phone number in the name field or does it make sense to add a phone field back to the page.

Things left to do:

• Move the visibility section to the 'share' tab
• Remove the data_contact_phone field from the DB and add any new ones (wait for response before removing the column) and update rake task
• Copy over the 'mock plan' checkbox and JS from the create plan page
• Implement the guidance portion

[briri]

Adding a auto-complete or regular dropdown to the guidance section would be problematic @JEK-III because the guidance groups are associated with an organization and displayed in a hierarchical manner. We will need to re-evaluate if we want to provide some search/filter mechanism. For now the link just displays the remaining list of guidance groups

I replaced the old text area with a tinymce form.

[stephaniesimms]

Functionality works as expected @briri

@JEK-III please note any additional styling suggestions. i have the following changes to request:

• Remove boldface for field names in all plan creation (for multiple templates from same funder), writing, sharing, etc pages
• Remove colon after each field name
• Be consistent w/capitalization of only first word for field names "Project title"
• (mostly) all caps for "ID" and "ORCID iD" (latter is an official name)
• standardize the width(s) for entry boxes, ideally make them the same as wireframes which present 2 different sizes
• make a shorter line break separating upper project details from PI details (see wireframes - this is just to help organize info visually but it's all part of project metadata/details)

[briri]

moving some of these comments to the ticket reserved from broad styling changes. labels styling is defined in one place now so we can achieve site-wide consistency.

Do we want all required fields to use the '(required)' text instead of an asterisk?

[JEK-III]

The explicit '(required)' label is generally better as long as a substantial minority of fields are required. Or vice-versa: in the user profile, it's '(optional)' instead for the one optional field. Unless we have any forms with a bunch of both (which I don't think we do), I'd recommend using '(required)' over asterisks throughout.

[stephaniesimms]

Thanks for moving things around @briri . Just to clarify: please make labels plain text w/no colons for site-wide consistency.

And we should consider @JEK-III 's points re (required) vs. asterisks if we decide to implement some way to flag required questions while writing a plan. I think we want to be consistent there as well and asterisks might be the easiest way to go. We use red asterisks in the DMPTool currently. @sjDCC do you have thoughts on this?

[sjDCC]

@briri - regarding phone numbers, if there's existing data in DMPonline for this field it would be better to leave it in, unless it's not much data. @vyruss can you query how many phone numbers we have saved please?

[sjDCC]

@stephaniesimms Regarding "Be consistent w/capitalization of every word for field names" I think it would be better with just first one capitalised unless a later term needed a capital e.g. ID. "Plan Guidance Configuration" looks a bit weird all capital to me, but maybe that's a setting we have for headings?

The compulsory questions feature is parked for now but sure to raise its head again at some point. I think in this context, asterisks would be best rather than stating (required) or (optional) in fields. With that in mind, I think we should stay with asterisks for now in case. If we switch and then choose to implement this, we'd need to change back for consistency.

[vyruss]

@sjDCC it's hard to gauge as data entry is all over the place and people have data_contact values like Mark Knopfler ext. 4321 and s0134317@sms.ed.ac.uk, but a good guesstimate (more than 5 numeric digits appear in the field) indicates around 700 out of 3000 plans with data_contact filled in have phone numbers.

[sjDCC]

That's more than I would have thought..

Taking a look at our fields, the entry is for "project data contact" not phone number specifically, so many of those entries are probably student emails or other info. I'd misread this before and thought we had a specific phone number field. Or did we used to have this, hence having so many numbers?

@briri given that the data is messy it's probably best to just dump the phone number in the name field, unless you think the script can reliably extract phone numbers in which case we could add a phone field back to the page?

[stephaniesimms]

@sjDCC Good -then lets go with capitalizing the first word of field names only, e.g., "Plan guidance configuration". And we can do asterisks for required fields. I'll add these to the General Styling issue for consistent application across the tool.

re phone numbers on the Project Details page, the real question is whether it's customary and/or required by funders or institutions to provide this info as part of the data contact details? If so we should keep the field on the page as part of project metadata. In the US, data contact name and email are all that's required by funders, publishers, et al.

[sjDCC]

@stephaniesimms No, phone numbers are not customarily asked by funders as part of DMPs. The MRC template does, but most don't ask for a specific data contact. I assume we had included a phone number field, hence there being so many in our data.

Given that there is so much existing data for this it's probably worth retaining field, unless it's too difficult to backtrack and get the data separated out again to fit. If so, just have a general contact / email field

[vyruss]

@sjDCC @stephaniesimms I think it would be good to add separate email and phone no. fields in addition to the existing generic "data contact" textfield - and we can worry about sifting through our existing data with a script and extracting those with a script at a later stage.

[stephaniesimms]

it should be easy enough to separate the data. the key question here is deciding what we want to collect as Project Details (project metadata), which should be defined by with what funders, publishers, others ask researchers to provide. so if MRC asks for a phone number, we should retain the field on this page in addition to a data contact email. but if no one asks for a phone number then just an email field is sufficient. we should also be thinking about this in the context of collecting appropriate, structured info for machine-actionable DMPs .

[sjDCC]

Not entirely sure what change has been here. If we've agreed to add phone field this is still to do. We may also need to adjust how we write ORCID iD. I think what I've just written is what @stephaniesimms recommended for edit profile page.

Otherwise looking good. I like that the orcid prepopulates

[stephaniesimms]

@JEK-III please update the wireframe w/"Phone" field under PI and Data Contact Person.

@briri

• Add Phone field per updated wireframe
• Field headings for "ID" and "ORCID iD" need caps
• Entry boxes for all fields should probably span the full width so content is visible (screenshot below); i.e., standardize them to Project title and text editor box width

[JEK-III]

Wireframes updated with phone #.

Re: entry field width, I agree that the contact info fields should all be the same length for tidiness, but they shouldn't necessarily span all of the available space. Users infer the length of response expected from the length of the entry field. The ORCiD field, for instance, shouldn't be 3x the length of an ORCiD. Of course, we don't know how long names or email addresses will be, but we can make a guess at an average (common wisdom is 25 characters for an email address), then add 50% to 100% for breathing room. All that said, I'd fix the width for all of the contact info fields to something between the current Name and Email fields.

[briri]

These changes are in the latest PR #548 but not yet deployed:

• Added phone number
• Fixed ORCID label
• Adjusted input box sizes. I have set them to a percentage width to accommodate various screen sizes. I did cap their min/max size though so that they don't get ridiculously small or large :)

[briri]

Uncomment out the guidance selection section.

[briri]

Alright, I reviewed the ticket and here's what's left to do:

• Fix spacing between the 'mock/test project' checkbox and the input elements above and below it. It currently encroaches on 'Funder'
• Make sure that only the first word in the field labels is capitalized (except for 'ORCID iD' which is the official name for that)
• Finish implementing the guidance section. Note that it may be difficult to introduce a typeahead style autocomplete box like we use for Orgs since this list deals with a combination of Org name and Guidance Name (e.g. University of Edinburgh: Roslin Institute vs University of Somewhere Else: Somewhere Else guidance). If it proves to be very difficult I would recommend coming back to the team with a recommendation on an alternative implementation (e.g. a modal window that lists out all of the possibilities in several columns.
• Please also move the migrate:plan_data_contacts rake task to the bugfix.rake rake task (maybe also rename that file to 'upgrade.rake') and add it as a task that gets run for v1.0. This extracts phone numbers and emails out of the old DMP contact info field and places them in the appropriate new columns and would need to be run by anyone upgrading.

[stephaniesimms]

thanks @briri ! closing this issue and final pieces replaced with #943