Enhance the review request blank state user experience
Review Request #10928 — Created Feb. 29, 2020 and updated
The review request page when the user creates a new draft to publish their changes
is empty at first unless some fields have been populated by RB Tools such as
the commit summary and description. However, not always these fields are populated
and the user is subjected to a mostly empty page. This can be a confusing user
experience where one may not know which fields are required to post a change,
what kind of content is needed for the different inputs, and where to add new files
to the request. These changes will help clarify the user experience on this page
to make it more friendly, and easier to understand what changes are needed to make
on this request before posting their work.These changes include,
- The addition of a edit icon to the file attachment area and to make it render by
default on review request drafts
- Creating a file attachment box area where users can click a button or drag and
drop a file into, making it easier to figure out where/how to add files to a request
- Changing the banner to include a checkbox group that holds all the required fields
that need to be filled out before posting a change
- Disabling the publish button until all the required checkboxes have been checked off
- Randomizing of placeholder texts from the Python backend
- Rendering of placeholder texts on various configured review request fields so the
user can understand what kind of input they need to make into a fieldRefer to the screenshot (version 2) for what it looks like so far.
Manual Tests
- Using rbt post, check if the review request page renders properly with the
placeholder text, checkbox banner group, and file attachment areas shown
- Using the new review request page, check the same above scenario
- Placeholder text is rendered with a gray font color if the page is editable
by the user and if there is no previously saved value
- If there is a previously saved value, it renders with the blank font color
- Checkbox group in the draft banner has all the required fields from the
review request page
- Publish button stays disabled until the user has checked off all the required
check boxes
- Publish button renders disabled at first even when the page first renders if the
review request is not public yet and if the request is being edited on first save
- Placeholder text is randomly being changed from the python backend
- Placeholder text is being rendered if there is no previously saved value
- File attachment area is shown be default if the request is editable
- File attachment area is responsive on mobile even after adding/deleting files
- File attachment area is hidden if the request is not editable and if no files
exist for the review request
- All fields are keyboard accessibleUnit Tests
- Publish button is disabled when all required checkboxes are not checked off
- Publish button is enabled when all required checkboxes are checked off or
there are no required fields in the page
- File attachment area is shown by default if the review request is editable
- File attachment area is hidden if there are no attachments and the review
request is non-editable
- Python backend returns the proper required fields from RB default settings
- Placeholder text is rendered if there is no previously saved text
- Placeholder text is not rendered if there is previously saved text
Summary | ID | Author |
---|---|---|
43488401dce78b6d41e3d1e9e9d92a9c4c5d3f39 | bui1@ualberta.ca |
Description | From | Last Updated |
---|---|---|
I think the placeholder for new items should go at the end of the list. This is where new items … |
david | |
There's some hilarious irony in these placeholders recommending limiting to 50 characters and wrapping to 72, then blasting past those … |
david | |
E501 line too long (93 > 79 characters) |
reviewbot | |
E501 line too long (93 > 79 characters) |
reviewbot | |
E501 line too long (84 > 79 characters) |
reviewbot | |
E501 line too long (93 > 79 characters) |
reviewbot | |
E114 indentation is not a multiple of four (comment) |
reviewbot | |
E501 line too long (84 > 79 characters) |
reviewbot | |
E501 line too long (93 > 79 characters) |
reviewbot | |
E114 indentation is not a multiple of four (comment) |
reviewbot | |
E501 line too long (83 > 79 characters) |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E501 line too long (83 > 79 characters) |
reviewbot | |
E501 line too long (83 > 79 characters) |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E501 line too long (83 > 79 characters) |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E501 line too long (83 > 79 characters) |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E502 the backslash is redundant between brackets |
reviewbot | |
E501 line too long (83 > 79 characters) |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E127 continuation line over-indented for visual indent |
reviewbot | |
E127 continuation line over-indented for visual indent |
reviewbot | |
E127 continuation line over-indented for visual indent |
reviewbot | |
E127 continuation line over-indented for visual indent |
reviewbot | |
E127 continuation line over-indented for visual indent |
reviewbot | |
E127 continuation line over-indented for visual indent |
reviewbot | |
E999 SyntaxError: invalid syntax |
reviewbot | |
E113 unexpected indentation |
reviewbot | |
E113 unexpected indentation |
reviewbot | |
can we use BEM for the class name? |
hxqlin | |
is it possible to use one of the greys from reviewboard/static/rb/css/ui/colors.less ? |
hxqlin | |
i think this class should follow the BEM naming conventions and maybe be clearer about what it's used for eg. … |
hxqlin | |
from the screenshot, the container looks about the same size as the thumbnails and might share some of the same … |
hxqlin | |
i think we should be using BEM here for the class names too |
hxqlin | |
i think the padding should use variables like in reviewboard/static/rb/css/ui/page-sidebar.less |
hxqlin | |
missing documentation for this function |
hxqlin | |
missing documentation |
hxqlin | |
getting the element by appending the target value to the id selector and using jQuery to search for that feels … |
hxqlin | |
What about discarding "Fill out the" in the label? It seems kinda repetitive when every item in the list has … |
LittleGrey | |
should value be "Click to browse"? (ie. first letter capitalized) |
hxqlin | |
i think this would be better named as this._$editButton because it can be clicked and its role is button |
hxqlin | |
i think this could just be called this._$editIcon since it's actually referring to the icon |
hxqlin | |
from the other variables defined before this one, i think the id should be suffixed with -action to be consistent |
hxqlin | |
i think this.$el.removeClass('placeholder-text') would be clearer |
hxqlin | |
i think this.$el.addClass('placeholder-text') would be clearer |
hxqlin | |
this.$el.removeClass('placeholder-text') |
hxqlin | |
this.$el.addClass('placeholder-text') |
hxqlin | |
We generally want to use parens for wrapping long things rather than continuation characters: base_placeholder_text = ( '... ' '... … |
david | |
Parens instead of \ |
david | |
Parens here too. |
david | |
We use the name "Base" to indicate that the class will be inherited from. In this case I think "ReviewRequestFieldRequirements" … |
david | |
This should have a trailing comma at the end. Please also keep the keys in alphabetical order. |
david | |
Please put this blank line back. |
david | |
Should have two blank lines on either side of the top-level block. |
david | |
Add a blank line here, please. |
david | |
Since we're changing this, let's take the opportunity to move these to the new colors definitions. @file-attachment-bg: #rb-ns-ui.colors[@white]; @file-attachment-overlay-bg: #rb-ns-ui.colors[@grey-90]; … |
david | |
Don't need to add this line. |
david | |
This should be in the imperative mood rather than passive ("Change the publish..." instead of "Changes") |
david | |
Please wrap this line to 80 columns. |
david | |
Please add a blank line between these two. We also like to make sure any jQuery-type variable starts with $, … |
david | |
Please use single-quotes instead of double. |
david | |
This can be a one-liner, and we can also use jQuery's eq method to simplify the selector: this.$buttons.eq(0).prop( 'disabled', this.requiredCheckboxes.length … |
david | |
There are a few things in here. First, since we're in ES6, we can use template strings (note the backticks). … |
david | |
This line can just be this._changePublishButtonState() |
david | |
In ES6 files, we have a much better way of formatting text like this: this._$attachments.prepend(dedent` <div class="rb-c-file-upload-container"> <div> <p>Drop file … |
david | |
In jQuery calls when creating a new (single) element, you don't need the closing tag. |
david | |
Wrap to 80 columns please. |
david | |
Wrap to 80 columns. |
david | |
Add a blank line in here. |
david | |
Wrap to 80 columns. |
david | |
Add a blank line in here. |
david | |
Wrap to 80 columns. |
david | |
Perhaps I'm reading this wrong, but won't this actually write the placeholder text to the database? Don't we want to … |
david | |
E302 expected 2 blank lines, found 1 |
reviewbot | |
W292 no newline at end of file |
reviewbot | |
E303 too many blank lines (2) |
reviewbot | |
E303 too many blank lines (2) |
reviewbot |
- Commits:
-
Summary ID Author 407eac7374f3719a146e34688d717cdc97724eb7 bui1@ualberta.ca 1891c462ca2d1d09a2aff5c84574a3c66cd40b20 bui1@ualberta.ca - Diff:
-
Revision 2 (+140 -32)
- Summary:
-
WIP Explore codebase for the review request blank state projectWIP Enhance the review request blank state user experience
- Description:
-
~ Add a edit icon beside the files section title as a way to test out solutions.
~ - Add a edit icon to the file attachment area and made it open by default on review request drafts
+ - Created a file attachment box area where users can click a button or drag and drop a file into
+ - Changed the banner to include a checkbox group that holds all the required fields that need to be filled out
+ - Disabled the publish button until all the checkboxes have been checked off
+ - Experimented with how placeholder text is going to work and look like
~ Default Fields are defined in
builtin_fields.py
,fields.py
is defines field behaviour,~ review_request_box.js
gets all the fields in the review request and renders it to theReviewRequestEditorView.es6.js
.~ review_request_box.html
is where the draft review request template page is defined.~ Refer to the screenshot for what it looks like so far
~ ~ TODO
+ - Figure out how to add reviewer group/people to the checkbox group if the field itself isn't required but + it's table header (reviewers) is + - Fix up file attachment area so the box doesn't stretch when attempting to drag and drop + - Finalize placeholder text behaviour and styling + - Make sure files attach to the right hand side of the file drop container and not the left + - Unit Tests - Commits:
-
Summary ID Author 1891c462ca2d1d09a2aff5c84574a3c66cd40b20 bui1@ualberta.ca f9bb8cc3a2f2515c4cc0f62e262623fcb2c32428 bui1@ualberta.ca - Diff:
-
Revision 3 (+402 -44)
- Added Files:
- Description:
-
- Add a edit icon to the file attachment area and made it open by default on review request drafts
- Created a file attachment box area where users can click a button or drag and drop a file into
- Changed the banner to include a checkbox group that holds all the required fields that need to be filled out
- Disabled the publish button until all the checkboxes have been checked off
- Experimented with how placeholder text is going to work and look like
Refer to the screenshot for what it looks like so far
TODO
- Figure out how to add reviewer group/people to the checkbox group if the field itself isn't required but it's table header (reviewers) is - - Fix up file attachment area so the box doesn't stretch when attempting to drag and drop - Finalize placeholder text behaviour and styling - - Make sure files attach to the right hand side of the file drop container and not the left - Unit Tests - Commits:
-
Summary ID Author f9bb8cc3a2f2515c4cc0f62e262623fcb2c32428 bui1@ualberta.ca f8b68f5733b92dde02a5570f6a778e7bbf197ba7 bui1@ualberta.ca - Diff:
-
Revision 4 (+424 -54)
- Description:
-
- Add a edit icon to the file attachment area and made it open by default on review request drafts
- Created a file attachment box area where users can click a button or drag and drop a file into
- Changed the banner to include a checkbox group that holds all the required fields that need to be filled out
- Disabled the publish button until all the checkboxes have been checked off
- Experimented with how placeholder text is going to work and look like
Refer to the screenshot for what it looks like so far
TODO
~ - Figure out how to add reviewer group/people to the checkbox group if the field itself isn't required but ~ it's table header (reviewers) is ~ - Server side rendering of required fields ~ - Fix placeholder text styling in editable/non-editable use cases - - Finalize placeholder text behaviour and styling - Unit Tests - Commits:
-
Summary ID Author f8b68f5733b92dde02a5570f6a778e7bbf197ba7 bui1@ualberta.ca 12eb05b1e848b185165f600eebd965e3a02a1319 bui1@ualberta.ca - Diff:
-
Revision 5 (+484 -52)
- Removed Files:
- Added Files:
- Description:
-
- Add a edit icon to the file attachment area and made it open by default on review request drafts
- Created a file attachment box area where users can click a button or drag and drop a file into
- Changed the banner to include a checkbox group that holds all the required fields that need to be filled out
- Disabled the publish button until all the checkboxes have been checked off
- Experimented with how placeholder text is going to work and look like
Refer to the screenshot for what it looks like so far
TODO
- - Server side rendering of required fields - Fix placeholder text styling in editable/non-editable use cases - Unit Tests - Commits:
-
Summary ID Author 12eb05b1e848b185165f600eebd965e3a02a1319 bui1@ualberta.ca 31715fda29f824550b3bd7e41b5a94141c7a805c bui1@ualberta.ca - Diff:
-
Revision 6 (+496 -54)
Checks run (1 failed, 1 succeeded)
flake8
- Summary:
-
WIP Enhance the review request blank state user experienceEnhance the review request blank state user experience
- Description:
-
~ - Add a edit icon to the file attachment area and made it open by default on review request drafts
~ - Created a file attachment box area where users can click a button or drag and drop a file into
~ - Changed the banner to include a checkbox group that holds all the required fields that need to be filled out
~ - Disabled the publish button until all the checkboxes have been checked off
~ - Experimented with how placeholder text is going to work and look like
~ The review request page when the user creates a new draft to publish their changes
~ is empty at first unless some fields have been populated by RB Tools such as ~ the commit summary and description. However, not always these fields are populated ~ and the user is subjected to a mostly empty page. This can be a confusing user ~ experience where one may not know which fields are required to post a change, + what kind of content is needed for the differnent inputs, and where to add new files + to the request. These changes will help clarify the user experience on this page + to make it more friendly, and more easy to understand what changes are needed to make + on this request before posting their work. ~ Refer to the screenshot for what it looks like so far
~ These changes include,
+ - The addition of a edit icon to the file attachment area and to mkee it render by + default on review request drafts + - Creating a file attachment box area where users can click a button or drag and + drop a file into, making it easier to figure out where/how to add files to a request + - Changing the banner to include a checkbox group that holds all the required fields + that need to be filled out before posting a change + - Disabling the publish button until all the required checkboxes have been checked off + - Randomizing of placeholder texts from the Python backend + - Rendering of placeholder texts on various configured review request fields so the + user can understand what kind of input they need to make into a field ~ TODO
~ Refer to the screenshot for what it looks like so far.
- - Fix placeholder text styling in editable/non-editable use cases - - Unit Tests - Testing Done:
-
+ Manual Tests
+ - Using rbt post, check if the review request page renders properly with the + placeholder text, checkbox banner group, and file attachment areas shown + - Using the new review request page, check the same above scenario + - Placeholder text is rendered with a gray font color if the page is editable + by the user and if there is no previously saved value + - If there is a previously saved value, it renders with the blank font color + - Checkbox group in the draft banner has all the required fields from the + review request page + - Publish button stays disabled until the user has checked off all the required + check boxes + - Publish button renders disabled at first even when the page first renders if the + review request is not public yet and if the request is being edited on first save + - Placeholder text is randomly being changed from the python backend + - Placeholder text is being rendered if there is no previously saved value + - File attachment area is shown be defualt if the request is editable + - File attachment area is responsive on mobile even after adding/deleting files + - File attachment area is hidden if the request is not editable and if no files + exist for the review request + - All fields are keyboard accessible + + Unit Test
+ - WIP after the code changes have been reviewed - Commits:
-
Summary ID Author 31715fda29f824550b3bd7e41b5a94141c7a805c bui1@ualberta.ca f1bcd10742d6e17fb63f8286075547a8990dbdbe bui1@ualberta.ca - Diff:
-
Revision 7 (+492 -40)
- Removed Files:
- Added Files:
Checks run (1 failed, 1 succeeded)
flake8
- Description:
-
The review request page when the user creates a new draft to publish their changes
is empty at first unless some fields have been populated by RB Tools such as the commit summary and description. However, not always these fields are populated and the user is subjected to a mostly empty page. This can be a confusing user experience where one may not know which fields are required to post a change, what kind of content is needed for the differnent inputs, and where to add new files to the request. These changes will help clarify the user experience on this page to make it more friendly, and more easy to understand what changes are needed to make on this request before posting their work. These changes include,
~ - The addition of a edit icon to the file attachment area and to mkee it render by ~ - The addition of a edit icon to the file attachment area and to make it render by default on review request drafts - Creating a file attachment box area where users can click a button or drag and drop a file into, making it easier to figure out where/how to add files to a request - Changing the banner to include a checkbox group that holds all the required fields that need to be filled out before posting a change - Disabling the publish button until all the required checkboxes have been checked off - Randomizing of placeholder texts from the Python backend - Rendering of placeholder texts on various configured review request fields so the user can understand what kind of input they need to make into a field Refer to the screenshot for what it looks like so far.
- Testing Done:
-
Manual Tests
- Using rbt post, check if the review request page renders properly with the placeholder text, checkbox banner group, and file attachment areas shown - Using the new review request page, check the same above scenario - Placeholder text is rendered with a gray font color if the page is editable by the user and if there is no previously saved value - If there is a previously saved value, it renders with the blank font color - Checkbox group in the draft banner has all the required fields from the review request page - Publish button stays disabled until the user has checked off all the required check boxes - Publish button renders disabled at first even when the page first renders if the review request is not public yet and if the request is being edited on first save - Placeholder text is randomly being changed from the python backend - Placeholder text is being rendered if there is no previously saved value ~ - File attachment area is shown be defualt if the request is editable ~ - File attachment area is shown be default if the request is editable - File attachment area is responsive on mobile even after adding/deleting files - File attachment area is hidden if the request is not editable and if no files exist for the review request - All fields are keyboard accessible Unit Test
- WIP after the code changes have been reviewed
- Commits:
-
Summary ID Author f1bcd10742d6e17fb63f8286075547a8990dbdbe bui1@ualberta.ca 6310ce133cbdc0da7dd0535f9470164d0c593475 bui1@ualberta.ca - Diff:
-
Revision 8 (+498 -40)
- Description:
-
The review request page when the user creates a new draft to publish their changes
is empty at first unless some fields have been populated by RB Tools such as the commit summary and description. However, not always these fields are populated and the user is subjected to a mostly empty page. This can be a confusing user experience where one may not know which fields are required to post a change, ~ what kind of content is needed for the differnent inputs, and where to add new files ~ what kind of content is needed for the different inputs, and where to add new files to the request. These changes will help clarify the user experience on this page ~ to make it more friendly, and more easy to understand what changes are needed to make ~ to make it more friendly, and easier to understand what changes are needed to make on this request before posting their work. These changes include,
- The addition of a edit icon to the file attachment area and to make it render by default on review request drafts - Creating a file attachment box area where users can click a button or drag and drop a file into, making it easier to figure out where/how to add files to a request - Changing the banner to include a checkbox group that holds all the required fields that need to be filled out before posting a change - Disabling the publish button until all the required checkboxes have been checked off - Randomizing of placeholder texts from the Python backend - Rendering of placeholder texts on various configured review request fields so the user can understand what kind of input they need to make into a field Refer to the screenshot for what it looks like so far.
- Commits:
-
Summary ID Author 6310ce133cbdc0da7dd0535f9470164d0c593475 bui1@ualberta.ca 2677163585482dc391802fd2532d6102fff62ab8 bui1@ualberta.ca - Diff:
-
Revision 9 (+502 -40)
- Commits:
-
Summary ID Author 2677163585482dc391802fd2532d6102fff62ab8 bui1@ualberta.ca 6ca93d1dadee2e7853a0a010f33307480dfeb35f bui1@ualberta.ca - Diff:
-
Revision 10 (+498 -40)
- Commits:
-
Summary ID Author 6ca93d1dadee2e7853a0a010f33307480dfeb35f bui1@ualberta.ca 35b9a2b93ad5a3646be5fe1900521fa5101f6fb7 bui1@ualberta.ca - Diff:
-
Revision 11 (+498 -40)
Checks run (2 succeeded)
- Commits:
-
Summary ID Author 35b9a2b93ad5a3646be5fe1900521fa5101f6fb7 bui1@ualberta.ca 7144a57866d12e1529c21c12217dc3188dbbae43 bui1@ualberta.ca - Diff:
-
Revision 12 (+498 -34)
Checks run (2 succeeded)
-
looking good! i think it would be nice to have a more complete screenshot (ie. without cutting off the top navigation bar) so we can get the full effect of the new banner, especially because it adds so much vertical space
-
-
-
i think this class should follow the BEM naming conventions and maybe be clearer about what it's used for eg.
rb-c-file-upload-container
-file-area-container
made me think that it's just used for showing a file or something like that -
from the screenshot, the container looks about the same size as the thumbnails and might share some of the same properties right? are there constants defined for any of these properties that we can use?
-
-
-
-
-
getting the element by appending the target value to the id selector and using jQuery to search for that feels kind of hacky - is it not possible to get the element from the event itself?
-
-
i think this would be better named as
this._$editButton
because it can be clicked and its role is button -
-
from the other variables defined before this one, i think the id should be suffixed with
-action
to be consistent -
-
-
-
- Commits:
-
Summary ID Author 7144a57866d12e1529c21c12217dc3188dbbae43 bui1@ualberta.ca 75301c447ba633b50bd6dfc489bfe2117a6bf16b bui1@ualberta.ca - Diff:
-
Revision 13 (+970 -454)
Checks run (2 succeeded)
- Testing Done:
-
Manual Tests
- Using rbt post, check if the review request page renders properly with the placeholder text, checkbox banner group, and file attachment areas shown - Using the new review request page, check the same above scenario - Placeholder text is rendered with a gray font color if the page is editable by the user and if there is no previously saved value - If there is a previously saved value, it renders with the blank font color - Checkbox group in the draft banner has all the required fields from the review request page - Publish button stays disabled until the user has checked off all the required check boxes - Publish button renders disabled at first even when the page first renders if the review request is not public yet and if the request is being edited on first save - Placeholder text is randomly being changed from the python backend - Placeholder text is being rendered if there is no previously saved value - File attachment area is shown be default if the request is editable - File attachment area is responsive on mobile even after adding/deleting files - File attachment area is hidden if the request is not editable and if no files exist for the review request - All fields are keyboard accessible ~ Unit Test
~ - WIP after the code changes have been reviewed ~ Unit Test WIP
~ - Publish button is disabled when all required checkboxes are not checked off + - Publish button is enabled when all required checkboxes are checked off or + there are no required fields in the page + - File attachment area is shown by default if the review request is editable + - File attachment area is hidden if there are no attachments and the review + request is non-editable - Commits:
-
Summary ID Author 75301c447ba633b50bd6dfc489bfe2117a6bf16b bui1@ualberta.ca 5326ce99e167c8a53b723963bde40e01b9bebf97 bui1@ualberta.ca - Diff:
-
Revision 14 (+1140 -476)
Checks run (2 succeeded)
-
-
I think the placeholder for new items should go at the end of the list. This is where new items show up, so it's like you're "filling in" the dashed box with the thing you're uploading.
-
There's some hilarious irony in these placeholders recommending limiting to 50 characters and wrapping to 72, then blasting past those limits.
Rather than suggesting those in the text (while we think they're good ideas, and enforce them for our stuff, not everyone does), let's just show by example what good lengths are.
-
We generally want to use parens for wrapping long things rather than continuation characters:
base_placeholder_text = ( '... ' '... ' '...')
-
-
-
-
We use the name "Base" to indicate that the class will be inherited from. In this case I think "ReviewRequestFieldRequirements" might be more appropriate.
But I don't think we even need a new class for this--this isn't Java. A function (
get_review_request_required_fields
, maybe?) would be better.Will need a docstring whichever way you go.
-
-
-
-
-
Since we're changing this, let's take the opportunity to move these to the new colors definitions.
@file-attachment-bg: #rb-ns-ui.colors[@white]; @file-attachment-overlay-bg: #rb-ns-ui.colors[@grey-90]; @file-attachment-overlay-border-color: #rb-ns-ui.colors[@grey-80]; ... @file-attachment-border-color: #rb-ns-ui.colors[@grey-60];
-
-
This should be in the imperative mood rather than passive ("Change the publish..." instead of "Changes")
-
-
Please add a blank line between these two.
We also like to make sure any jQuery-type variable starts with $, so
$checkbox
for the name. -
-
This can be a one-liner, and we can also use jQuery's
eq
method to simplify the selector:this.$buttons.eq(0).prop( 'disabled', this.requiredCheckboxes.length !== this.numberOfBoxesChecked);
-
There are a few things in here.
First, since we're in ES6, we can use template strings (note the backticks).
We should also not use the name "class", since it's a reserved word.
Finally, anything inside a call to
gettext
must be a literal. It can't be computed due to the way the gettext scanner works. Fortunately, there's a formatter we can use:id: `${fieldName}-banner-checkbox`, className: 'banner-checkbox', label: interpolate(gettext('Fill out the %s field'), [fieldName]),
-
-
In ES6 files, we have a much better way of formatting text like this:
this._$attachments.prepend(dedent` <div class="rb-c-file-upload-container"> <div> <p>Drop file attachments here</p> <p>or</p> <input type="button" id="select-file-for-review-action" value="Click to browse"> </div> </div> `);
That said, we should probably also wrap this in
_.template
and pass all the user-visible text in as variables that are wrapped ingettext()
to enable localization of this UI. -
-
-
-
-
-
-
-
Perhaps I'm reading this wrong, but won't this actually write the placeholder text to the database? Don't we want to write an empty string instead?
- Description:
-
The review request page when the user creates a new draft to publish their changes
is empty at first unless some fields have been populated by RB Tools such as the commit summary and description. However, not always these fields are populated and the user is subjected to a mostly empty page. This can be a confusing user experience where one may not know which fields are required to post a change, what kind of content is needed for the different inputs, and where to add new files to the request. These changes will help clarify the user experience on this page to make it more friendly, and easier to understand what changes are needed to make on this request before posting their work. These changes include,
- The addition of a edit icon to the file attachment area and to make it render by default on review request drafts - Creating a file attachment box area where users can click a button or drag and drop a file into, making it easier to figure out where/how to add files to a request - Changing the banner to include a checkbox group that holds all the required fields that need to be filled out before posting a change - Disabling the publish button until all the required checkboxes have been checked off - Randomizing of placeholder texts from the Python backend - Rendering of placeholder texts on various configured review request fields so the user can understand what kind of input they need to make into a field ~ Refer to the screenshot for what it looks like so far.
~ Refer to the screenshot (version 2) for what it looks like so far.
- Commits:
-
Summary ID Author 5326ce99e167c8a53b723963bde40e01b9bebf97 bui1@ualberta.ca e8815bf1971a8b621efab065b54f2f9fefb83403 bui1@ualberta.ca - Diff:
-
Revision 15 (+1184 -468)
-
Screen Shot 2020-03-24 at 2.01.39 PM.png: Review Request UI ChangesVersion 1 - Review Request Blank State UI Changes - Added Files:
- Commits:
-
Summary ID Author e8815bf1971a8b621efab065b54f2f9fefb83403 bui1@ualberta.ca f3111b61170ca4e0b6b350173c6704e8ee3db3a3 bui1@ualberta.ca - Diff:
-
Revision 16 (+1186 -468)
Checks run (2 succeeded)
- Testing Done:
-
Manual Tests
- Using rbt post, check if the review request page renders properly with the placeholder text, checkbox banner group, and file attachment areas shown - Using the new review request page, check the same above scenario - Placeholder text is rendered with a gray font color if the page is editable by the user and if there is no previously saved value - If there is a previously saved value, it renders with the blank font color - Checkbox group in the draft banner has all the required fields from the review request page - Publish button stays disabled until the user has checked off all the required check boxes - Publish button renders disabled at first even when the page first renders if the review request is not public yet and if the request is being edited on first save - Placeholder text is randomly being changed from the python backend - Placeholder text is being rendered if there is no previously saved value - File attachment area is shown be default if the request is editable - File attachment area is responsive on mobile even after adding/deleting files - File attachment area is hidden if the request is not editable and if no files exist for the review request - All fields are keyboard accessible ~ Unit Test WIP
~ Unit Tests WIP
- Publish button is disabled when all required checkboxes are not checked off - Publish button is enabled when all required checkboxes are checked off or there are no required fields in the page - File attachment area is shown by default if the review request is editable - File attachment area is hidden if there are no attachments and the review ~ request is non-editable ~ request is non-editable + - Python backend returns the proper required fields from RB default settings + - WIP Placeholder text is rendered if there is no previously saved text + - WIP Placeholder text is not rendered if there is previously saved text - Commits:
-
Summary ID Author f3111b61170ca4e0b6b350173c6704e8ee3db3a3 bui1@ualberta.ca 6af3ecb0ebe73806c660b9ee47ab7e30bbd834e6 bui1@ualberta.ca - Diff:
-
Revision 17 (+1300 -468)
- Testing Done:
-
Manual Tests
- Using rbt post, check if the review request page renders properly with the placeholder text, checkbox banner group, and file attachment areas shown - Using the new review request page, check the same above scenario - Placeholder text is rendered with a gray font color if the page is editable by the user and if there is no previously saved value - If there is a previously saved value, it renders with the blank font color - Checkbox group in the draft banner has all the required fields from the review request page - Publish button stays disabled until the user has checked off all the required check boxes - Publish button renders disabled at first even when the page first renders if the review request is not public yet and if the request is being edited on first save - Placeholder text is randomly being changed from the python backend - Placeholder text is being rendered if there is no previously saved value - File attachment area is shown be default if the request is editable - File attachment area is responsive on mobile even after adding/deleting files - File attachment area is hidden if the request is not editable and if no files exist for the review request - All fields are keyboard accessible ~ Unit Tests WIP
~ Unit Tests
- Publish button is disabled when all required checkboxes are not checked off - Publish button is enabled when all required checkboxes are checked off or there are no required fields in the page - File attachment area is shown by default if the review request is editable - File attachment area is hidden if there are no attachments and the review request is non-editable - Python backend returns the proper required fields from RB default settings ~ - WIP Placeholder text is rendered if there is no previously saved text ~ - WIP Placeholder text is not rendered if there is previously saved text ~ - Placeholder text is rendered if there is no previously saved text ~ - Placeholder text is not rendered if there is previously saved text - Commits:
-
Summary ID Author 6af3ecb0ebe73806c660b9ee47ab7e30bbd834e6 bui1@ualberta.ca 07437d959ae488eb2d5700ccb19412ca29a101a1 bui1@ualberta.ca - Diff:
-
Revision 18 (+1294 -468)
- Commits:
-
Summary ID Author 07437d959ae488eb2d5700ccb19412ca29a101a1 bui1@ualberta.ca 43488401dce78b6d41e3d1e9e9d92a9c4c5d3f39 bui1@ualberta.ca - Diff:
-
Revision 19 (+1292 -468)