Open ChristaBull opened 6 months ago
We use the same pattern on other projects. UX testing in those cases had issues calling the build page Edit. There were two problems with it.
Labels usually are not hard to change, figuring out what to change them to can be challenging.
Makes sense, the double edit is a little unique and I can see how it would be challenging to explain in a sentence. "Change" is another word I'd use before "Build".
Part of why I pointed this out (beyond my personal feelings about the term) was because we tried using "Build" for a similar action in an app my team created recently. When we engaged our UX team to test the app with users in PLD there was a lot of feedback about how they disliked the "build" button label.
Interesting, this is the first time I've ever heard negative feedback on the build label. I wonder if context plays a part in it.
Build is common in the Drupal ecosystem when you are going to a page where you will be editing sections. For example, this is the out-of-the-box webform UI:
then once you are on the build page
Yea, we got that feedback on a more traditional UI where the client was landing on a page with a bunch of items that they had the ability to manage. The feedback we got there was also just from one division and may not represent the larger ministry or the subset of users that would be Editors or Catalogue Managers.
I suspect a lot of our clients don't have a ton of experience in the Drupal ecosystem and going down multiple levels to edit so common terminology in the Drupal wouldn't be known. However, this might be something that is best testing in the future to see how it's landing with business users.
My team understands what it means so it's not slowing us down.
I second changing to something other than 'Build', for the same reason that users don't know (and shouldn't be required to know) the Drupal ecosystem. Also, catalogue editor roles are called editors for a reason, not 'catalogue builders'. The users coming there with this role are coming there to create and edit. We have already acknowledged that Drupal may not be our long term solution for a Catalogue so we should be flexible in the terms we are using.
Build and Edit is Drupal terminology and regardless of what the label is on the button where Build is currently, it's an education item because it's a two step process. This will be new to most users, I think, because most users will not have used a content management system before. I think we should leave "Edit" in the sections and consider changing "Build" only once there is evidence from a wider set of users that it is a barrier to use so I am putting this in the Icebox for now.
Think Aloud feedback supported the need for a change. I suggest we change "Build" to "Edit" and the editable section buttons each to an icon similar to:
What do you think @ChristaBull ?
Just an FYI that there will be two tabs on each node called "edit" then for admin users. Build is consistent with Drupal webforms UX.
Not quite sure what you mean, @joel-osc. Can you please give me a visual of the concern?
On a node's "build" page, e.g.: https://test.cat.data.fin.gov.bc.ca/node/17/build
This is what I am thinking of displaying to the end users because they struggle with "Build":
The top edit tab you have highlighted is called Build because there is already an Edit tab provided by Drupal core. That edit tab is still available to administrators by design, so if you make Build => Edit the administrators will have two tabs called Edit.
Thanks for the heads up. As a Catalogue administrator user, I don't see an Edit tab alongside the Build tab so I believe you're referring to the Drupal admin users. My primary concern is the end users (Catalogue editors and Catalogue managers) so I'll see if the Drupal admin users can live with that sort of change.
a Catalogue administrator user, I don't see an Edit tab alongside the Build tab so I believe you're referring to the Drupal admin users. My primary concern is the end users (Catalogue editors and Catalogue managers) so I'll see if the Drupal admin users can live with that sort of change.
I suspect we could just level the existing "Edit" buttons for the sections and it wouldn't cause confusion. However, the pencil icon, provided it has a label on it explaining it's to edit the section for accessibility, seems like it could communicate the same thing and sounds good to me.
@chrislaick and @danhgov please see comments above in the last couple of days.
As Drupal admin users, will it be a set back if you are logged in and see two Edit tabs instead of Build and Edit? Is it possible to only relabel "Build" to "Edit" for non-Drupal admin users? Looking at ways to make the Catalogue editor/manager/admin user experience more intuitive based on feedback received during user interviews.
@NicoledeGreef, I think that will be fine. I just tested, and indeed, it is only the "Administrator" role that currently sees the Edit tab, with regards to Metadata Record nodes. And only Chris, Kunal, Will, myself and "OP Admin" have accounts with that role.
Non administrator roles see at most these tabs:
Administrators see these:
Likely, what we'd do is to also change the current Edit tab to "Edit 1.0" or "Edit✏️", or something to just make it different and a bit less confusing for Administrators. Really, Openplus made the Build tab to essentially replace the Edit tab, so it isn't even something we should be using much.
Keep in mind that it's more than just changing the label on the tabs. We'd need to decide what rewording will (or won't) be happening in several places:
... And upon further reflection, I think we should leave "edit" in URLs as it is, as that is deeply ingrained in Drupal. The word "build" in the URL could be changed perhaps to "edit_overview". And I don't know if you are thinking of changing the word "Edit" that is on the blue buttons... I'd suggest we leave them alone, because when you click them, you go to the page that has "edit" in the URL . So you'd click the edit tab to get to the edit page (which in the URL would be 'edit_overview'), and then further have to click a blue Edit button to edit one of the sections, taking you the page that has 'edit' in the URL.
I was only thinking of changing the blue 'edit" section buttons to an icon that implies edit (a pencil as that is pretty common).
Definition of Done for this ticket:
I've also
@NicoledeGreef, moving the "Modify" (previously known as "Edit") buttons in closer to the headings is not an easy task, as they have been built as blocks, and their layout is baked into the page. I suggest we either leave them where they are, or move them to the left side of the sections they are associated with. This latter idea is my personal preference, as it will bring all the important textual data visually closer together, and get the column push-buttons out from the middle of things. i.e. Swapping columns 1 & 2 in this screenshot:
Code changes are in PR https://github.com/bcgov/MFIN-Data-Catalogue/pull/new/414--build-rename-to-edit
(Aug 27 noon: Merged to main, deploying to dev...)
@NicoledeGreef, this is deployed to Dev and Test.
You may find that you need to clear your browser cache, or at least use shift-ctrl-R to clear-cache for the page you're viewing -- or else you may still see the old 'Build' terminology.
I have only changed the word 'Edit' in the few places you asked me to. The word 'build' is used extensively in the code and in documentation around this project, so I've left the rest of these instances as-is, to avoid possibly causing a lot of new bugs - developers supporting this project will simply need to understand what a 'build' is, and the fact that we use 'edit' for it now.
Oh... that being said, do we now also need to change the user-facing documentation regarding this change? There is the wiki in github, but that is just for us, isn't it? Not sure if there actually is user-facing docs.
We decided today that we'd NOT switch columns 1 and 2, and in fact not move the 'Modify' buttons at all.
@NicoledeGreef, this is now merged, and is on Dev/Test.
Looks great - thanks @danhgov
Deployed to PROD.
User story
As a user I want to clearly identify how I make changes to records.
Describe the idea
Change the term "build" to "edit" so that the terminology aligns more with the action user wants to make.