Closed stephaniesimms closed 6 years ago
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:
@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:
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.
Functionality works as expected @briri
@JEK-III please note any additional styling suggestions. i have the following changes to request:
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?
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.
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?
@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?
@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.
@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.
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?
@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.
@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
@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.
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 .
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
@JEK-III please update the wireframe w/"Phone" field under PI and Data Contact Person.
@briri
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.
These changes are in the latest PR #548 but not yet deployed:
Uncomment out the guidance selection section.
Alright, I reviewed the ticket and here's what's left to do:
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. thanks @briri ! closing this issue and final pieces replaced with #943
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:
Guidance selections move to right of Project Details, also described in related issue #495 for Write Plan page. Note blue notepad functional specs: