Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
The configuration synchronization UI needs work. Issues include:
- It is just a list of that can get longer and longer.
- It is sorted by the order the import will occur.
- Special processes like module and theme installation and uninstallations are hidden in the core.extension diff
- Special processes like deleting field data before uninstalling modules are drupal_set_messages
- There is no confirmation form and the operation is certainly desctructive
- There is no clear indication when certain operations (field purge on module uninstall) may take a very long time.
Proposed resolution
- Reorder the tabs for the Config UI as follows:
Remaining tasks
DiscussDesignImplement
User interface changes
As listed in Proposed Resolution
API changes
None.
Beta phase evaluation
Issue category | Task because current UI works but is not as usable as it could be |
---|---|
Issue priority | Major because having a usable UI is important for D8 |
Prioritized changes | The main goal of this issue is usability. |
Disruption | Disruptive for contrib or custom if altering the config sync forms. The benefits outweigh this theoretical disruption. |
Comments
Comment #1
xjmYes, it does. :) There are probably existing issues related to this... somewhere...
Comment #2
xjmAlso adding @webchick's feedback re: warning the user about long-running batches.
Comment #3
Bojhan CreditAttribution: Bojhan commentedI wouldn't mind helping out with this but I need some more guidance.
Comment #4
moshe weitzman CreditAttribution: moshe weitzman commentedMaybe we shouold post some screenshots to the UX folks can do their thing.
Comment #5
yoroy CreditAttribution: yoroy commentedActually, I've been looking at this UI this week. Incomplete first notes:
On first visit, after creating a new content type:
- Title doesn't match the link I clicked. I click 'Configuration management' and end up on a page titled 'Synchronize'.
- The first thing I see is a warning that my current configuration has changed.
- Not clear what the difference is between single and full import/export
- Apparently, synchronisation is considered the most important use case?
- "Import configuration that is placed in your staging directory. All changes, deletions, renames, and additions are listed below." Well, the only changes listed on first visit are listed in the message above. Missing a hint as to where the staging directory might be.
I was thinking I could use the config manager to keep track of a content type I want to use when testing out D8, but it won't let me import an earlier export because it considered my site a new site (probably because I recreated the database in between?)
I uploaded the tar.gz of a complete export but got the error message as mentioned above.
- The lack of pointing out where the staging directory lives becomes serious now because apparently there's something there that won't work and I don't get a hint on how to remove it. Asking in IRC helps but that's not a solution :)
I have only worked with the import/export screens superficially:
- Single import/export has duplicate entries for 'Field' in the select list
- Generally lacking context, no hints given as to what you might be able to achieve on these screens
- The contents of the 'Advanced' fieldset might need a better description as to *why* you'd want to use this
- Full import/export screens are both very light on functionality, a single upload and a single download button
Comment #6
yoroy CreditAttribution: yoroy commentedSome user stories or scenarios for what people will want to do here would be helpful. When do I sync? When import, when export?
Comment #7
yoroy CreditAttribution: yoroy commentedI have a local setup of two sites now to experiment with. There's issues on each individual page (esp. the 'synchronize' screen can be confusing), but for now I wonder about the information architecture of the screens in this section. Why the main split between single and full? From playing a bit with importing and exporting changes, I find I first consider wether I want to import or export, and after that decide between full or single:
Comment #8
jhodgdon+1000 on that last idea.
What do we need to move forward on making this system at all usable? It's really kind of terrible right now.
Comment #9
yoroy CreditAttribution: yoroy commentedComment #10
jhodgdonAre changes to the UI going to happen soon? Because right now #1831798: Update hook_help() for config manager module is postponed on this issue. That is about making help blocks and the overall help page for the Config Manager module -- which is desperately needed, there's practically nothing there now. Should we go ahead there and then revise it if/when this is done, or wait for this issue to happen?
Comment #11
mtiftI really like the suggestion in #2247291-7: Reorder tabs in configuration UI, too
Comment #12
jhodgdonSo regarding the design in #7, ... on the related/child issue #2388867: Notifying user of config changes when config has never been synched makes no sense it has been brought up that the current Synchronize page has two purposes. Let's see if I can get this right... maybe more than two actually:
a) Notify you that config has changed since the last snapshot. [As noted on that related issue, this notification is very misleading after an initial site install, since it tells you a bunch of stuff has changed immediately after the install, just due to the stuff you configure during install or that is configured for you by the Standard profile.]
b) Bulk synchronize from staging to active, which has a side effect of making a new snapshot.
Also the bulk Import page, just to clarify: what it actually does is to un-archive a tgz file into the staging directory, and then drop you onto the Synchronize page so you can actually make the config you imported live. So in essence, the bulk "import" page doesn't really actually do anything to your config, unlike the single import page. And there's no help on the page to explain this... that's a separate issue being explored on #2203779: Improve wording of the configuration import form, which I'll mark as Related. But it may impact the idea of the new navigation, since really bulk Import is tied to Synchronize?
Comment #13
dawehnerI have to agree that the current grouping is super annoying ... You really often want a single export, but therefore you need to click twice.
With the new proposal in #8 you would save a single click here.
Comment #14
jhodgdonSo, another thought on the #7 design proposal.
I guess my basic question is whether most users will even use the Status/Synchronize page. It really only does something if you put config into the Active staging area, which is really kind of a subset of the bulk Import functionality. So maybe we should think again about the organization of pages, and put something else at the forefront?
Comment #15
Eli-TComment #16
Eli-TSimple patch that implements the renaming and moving of the tabs as proposed in #7
Comment #17
Eli-TNote also if the permissions are incorrect on the files in the config staging directory and the web server cannot read them, the error message
is displayed on the Synchronisation (or status) page. This is potentially confusing and could be expanded to cover the possibility that the webserver just can't read the config files.
Comment #18
Eli-TSet page title to Configuration management to be consistent with the link that takes you here from Configuration, as pointed out in #5 (includes changes from patch in #16)
Comment #19
alexpottComment #22
Eli-TThere are further issues with the solution as proposed and I think some further restructuring could add clarity for users.
Issues:
Therefore I propose that the Status (or Synchronize) tab actually be removed. The functionality of that page should be moved to the Import tab, which will now contain all the functionality to import both full and single configs, removing any need to rename the tabs or split Import Single and Upload Full in to their own tabs.
Comment #23
Eli-TNB tests expected to fail at this point.
Comment #24
ivanstegic CreditAttribution: ivanstegic at TEN7 commentedHi everyone, we (@Les Lim, @lexfunk, @JackProbst, @ColemanRollins, @jascote, @tiffdmoore and I) just spent about 2 hours talking through this issue, and #2203779: Improve wording of the configuration import form here in the office.
We all agreed with the idea that there needs to be some reorganization of the tabs. We applied the patch in #18, worked just fine, and we all agree that the best option moving forward is to remove the Status (Synchronize) tab, as mentioned in #22. Thoughts:
Comment #25
jhodgdonThis all sounds good. I'm slightly confused about where you'd go to see a diff of what you uploaded, though?
Comment #26
ivanstegic CreditAttribution: ivanstegic at TEN7 commentedI think that would be under "Import > Full", wouldn't it?
Comment #27
Eli-TYes, the diff of the upload is only relevant when performing a Full Import.
Comment #28
jhodgdonLet me rephrase. I thought there was a difference between the current Synchronize page and the Full Import page? I have never really been sure, but I thought so, since there are two pages now and they are definitely not the same. So it seems like we need to not lose this page entirely?
Comment #29
alexpott@jhodgdon the full import just lets you upload a file - which will let you do the sync - the proposal I think is to merge the two. Makes lots of sense to me.
Comment #30
Eli-TThere is definitely a difference between those two pages. I am proposing moving the operations you would carry out on the Synchronize page on to the Full Import page. Nothing would be lost, it will just be grouped together to make more sense.
The current flow for a full import is:
So at the point when the user is redirected from the Import tab, they still haven't completed an import. They've merely completed an upload. Then the import is actually completed on a tab called Synchronisation.
So the Import doesn't import, it merely uploads.
If we change the flow to
the import will be completed on a tab called Import. The Synchronisation page becomes redundant. The interface becomes simpler and is more meaningfully named.
Comment #31
jhodgdonExcellent. Thanks very much for the explanation! I had been confused about how Synch and Import were related; much less so now. And these changes make tons of sense to me.
I also think that landing on either Import or Export when you click through from Admin -> Configuration makes a lot more sense than landing on an incomprehensible Synchronize page. I use Export Single and Import Single a *lot* (while developing modules, or to share a View between sites or something like that), but I have no use for Synchronize yet (I think it is only for maintaining Dev -> Staging -> Live workflows).
One question though. Can advanced users bypass the Full Import screen by putting config files somewhere themselves? If so, is there a way for them to get to the "review differences and import all" screen, without first going through an Upload? And what if someone has used Upload, then went to do something else, can they get back to the "review differences and import all" screen?
I guess the workflow would be:
If you go to Import Full and there's already something in the staging area, show the "review differences and import" screen. If not, show the Upload screen. ??? maybe? And would there be a way to discard staged changes?
Comment #32
Eli-TI think it would be *slightly* different; show the upload controls whether there's something in the staging area or not. If there is something in the staging area, *also* show the review differences and import controls.
Comment #33
jhodgdonThat sounds like a good idea to me. If there's something already there, presumably/hopefully it will warn you before overwriting anyway. I would hope.
Comment #34
jhodgdonWe need to get this done... Eil-T are you still working on it?
Comment #35
Eli-TI am planning to work on this tomorrow evening.
Comment #36
Eli-TThis patch is functional and merges the Synch tab functionality in to the Full Import
Some clean-up still required and test adjustment but should illustrate whether this is the right approach.
Comment #38
Eli-TWith the patch above, flow for a full import is
1. Select config management
2. Takes you to Full Import by default
3. Select file and upload as usual
4. Review changes and import from the same screen
5. Receive confirmation that new config has been imported
6. If you don't import at this point, if you revisit the Full Import page in the future you still have the option to review and import.
Comment #39
Eli-TNew patch replacing the text which refers to redirecting to the import form with "'Uploaded configuration changes can be reviewed below before they are imported.'"
Also add the warning text "This will replace your previously uploaded configuration." if and only if config has previously been uploaded, is valid to import and differs from the site's current config.
Comment #40
jhodgdonThanks for all these screen shots! Looking good!
I had a few thoughts/suggestions about the UI text:
- We definitely need to lose the text at the top that says "Use the upload button below". That falls into the department of redundancy department.
- "Select your configuration export file" seems a bit weird to me, since you are importing. How about "Configuration archive" as the field title? Or whatever wording is used on the Full Export form to describe the file that is being exported.
- Some hook_help() text at the top of the Import page, explaining where you might get a configuration archive and what it is, would be helpful. I think it would also need to explain about the UUIDs that have to match in order for this import to even be allowed.
- I thought the upload field had a description saying what file types are supported, where did this go? Or maybe that was on a different issue, but I remember discussing it could be .tar.gz, .tgz, or one other format? Hm, seems like it is on a different issue. Oh yes, it's on #2203779: Improve wording of the configuration import form... why do we have two issues for this? Anyway the UI text is being discussed there; updates there need to make it onto this issue.
- "This will replace ... " warning should be in a confirm form rather than being on this page where people might not notice it. That is the standard way to warn users that something they are doing is destructive and/or permanent. I think the text should say "This will replace the configuration that was previously uploaded for import. Proceed?" or something like that.
- Hopefully the "Import all" button also has a confirm form, telling the user that their site configuration will be changed?
- "Uploaded configuration changes can be reviewed below before they are imported"... I am not sure I like the word "below" there, because they aren't below when you first get to this page. I think I would just remove"below".
Comment #41
Eli-TThis patch copies the string changes from the patch at https://www.drupal.org/node/2203779#comment-10047104 with the exception of the implementation of hook_help() on the config sync page, which no longer exists.
Comment #42
Eli-TRemoved
Superceded by #2203779
Implemented hook_help() with dummy text until we have words for here.
Thanks for pointing the issue, I missed it in the related list. Copying changes from there as we go now.
Will implement these two confirmation forms next. Do you think we should display the confirmation dialog for upload if there is a) no previously uploaded config, and if b) there is uploaded config but that matches the current active config? I think a case can be made that in those two scenarios it is not a destructive operation.
Superceded by #2203779
Comment #43
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedTriggering test bot.
The help text will be handled in #1831798: Update hook_help() for config manager module .
Comment #44
Eli-TTests anticipated to fail :)
Comment #48
jhodgdonRegarding the confirm forms, I agree that if there is no previous uploaded config, there is no need for the warning message. But I don't think you will be able to check whether the new config the person is trying to upload is the same as the previous upload? The confirm form should come before the upload takes place?
Comment #49
Eli-TWe don't have to. I just want to check if the previous upload is different to the active config.
Comment #50
jhodgdonOh, I misread that. Sounds like a good idea. :)
Comment #51
Eli-TJust realised we need to update this string too:
Comment #52
Eli-TConfirmation form for import step implemented, and rerolled after commit of #2203779.
Comment #53
Eli-TPutting to review to make sure nothing outside of config is broken by these changes.
Comment #55
Eli-TAnother thing to consider - there were separate permissions for 'synchronize configuration' and 'import configuration'. Now that they are grouped on to the same form, it feels like we should consolidate to just 'import configuration'.
Comment #56
Eli-TConsolidated 'synchronize configuration' and 'import configuration' permissions.
Fix tests.
Change Back to Synchronize Configuration to Back to Full Import.
Remove ConfigSync form and redundant routes.
Add title and confirm button text to import confirmation form.
Still need to implement the new hook_help changes in #1831798 but will wait for that to be complete and then adapt. Nevertheless, probably a good idea for someone else to cast their eyes over this.
I *haven't* implemented a confirm dialog for upload; after consideration I don't think it's particularly destructive as it will ony overwrite staged config.
Comment #58
Eli-TComment #59
Eli-TComment #61
jhodgdonAgreed on the "no confirm for upload" idea.
Comment #62
cilefen CreditAttribution: cilefen commentedI tried some renaming of page titles in a related issue #2513568-3: Relabel "Configuration Management". Those were out-of-scope in the other issue. The renames were:
Synchronize => Synchronize site configuration
Export => Export full site configuration
Import => Import full site configuration
Single import => Import single configuration
Single export => Export single configuration
Comment #63
Eli-TComment #64
Bojhan CreditAttribution: Bojhan commentedI am just reviewing this, below is a whole list of ideas and t
Import:
Export:
I don't really understand why in core we want to also support single export/import. Isn't that something that is better served in contrib? I can't imagine that these large dropdowns is really what you want.
Comment #65
Eli-TThis patch should fix the remaining tests with the current approach before https://www.drupal.org/node/2247291#comment-10069630 was written.
We need further input to decide whether all the changes suggested there need to happen - if so I probably won't be able to start on them for at least a week.
NB even though put to needs review, there is still a piece of placeholder text in hook_help that is awaiting https://www.drupal.org/node/1831798 to be completed before it can be adapted to the new organisation of forms so this shouldn't be committed yet.
Comment #66
jhodgdonOne or two responses to #64:
a)
Core doesn't currently have any easy way to tell what you have changed from defaults. I managed to get this working in my contrib module https://www.drupal.org/project/config_update but it was not exactly easy, and while I believe I suggested this for Core it was deemed 8.1 or later material, or else contrib... hence the contrib module.
b) Just to clarify: you cannot import or export configuration "by category". You can only import a single item. The "by category" lists mentioned in #64 are really the entity types of the config entities (plus "simple" for the config that isn't entities). You cannot export an entire entity type at once. On export, the type list is just to help you navigate through the hundreds of items you could export; on import, you have to know what type you have in order to validate the import.
So to me, "single" means "one config item", and if the wording were changed to "by category" or "by type", it would imply that I could import a whole subset of my config. It definitely does not do that.
c)
If we want to remove this to contrib, the above mentioned config contrib module would be a good home for it. To me that is essential functionality, where "me" means "a contrib module developer", because that is the best way to export the config I want to put into the config/install directory (like default views). But anyone who is not a contrib module developer probably doesn't need this (although this is the only way to export/import Views, which was a 7.x Views functionality I personally used quite a bit in my Site Builder For Hire role). ???
Anyway, I would be fine with removing it to my https://www.drupal.org/project/config_update module (which might then be better served by a different name, but oh well).
Comment #67
Eli-TComment #68
Eli-TReroll against latest 8.0.x
Comment #70
Eli-TTest fails because #1831798: Update hook_help() for config manager module refers to url('config.sync') on /admin/help/config, which has been removed in this patch.
Comment #71
Eli-TRemoves references to config.sync in config_help().
Removes references to default.services.yml and default.settings.php included in the patch in #2247291-68: Reorder tabs in configuration UI
Comment #72
Eli-TNB this isn't fit for merging right now as there is still a lorem ipsem string in config_help() for config.import_full that needs revisiting, but it's still a good time to review given the amount of work carried out so far.
Comment #73
alexpottI've had a look at the re-arrangement. Moving the upload form to the import all screen is difficult because it is making an assumption about the workflow. Also once you have config in staging to import having a very prominent upload button is confusing. We need to support at least two different workflows here - one where a user is using the config tarballs and one where configuration is moved to staging in another way.
Wrt to #64 - I don;t think we can remove the single/import export. Let's file a separate issue to improve how these pages work. This issue is about the organisation of the different tasks possible within "Configuration synchronization" and making sure that we support the different full import workflows.
Comment #74
jhodgdonSounds like this is Needs Work for #73?
Comment #75
Eli-TYep, thanks for the feedback @alexpott. I'll revert the combination of the import and synchronization tabs, but keep the tab reorganisation and the import confirmation form.
Comment #76
Eli-TTabs rearranged. Sync tab restored. Confirm form moved to sync tab.
Comment #77
Eli-TComment #78
Eli-TReroll against latest 8.0.x
Comment #79
Eli-TComment #81
Eli-TMany many test fixes (but not all)
Comment #83
jhodgdonLooks like you got all but 2 of them!
Comment #84
Eli-TI've been looking at this last night and today and can't fathom why the changes made are causing these last two tests to fail in this way. I have no more time to look at this today and possibly not for another few days so unassigning in case anyone else wants to pick up.
Comment #85
tim.plunkettThis needs to be on one line
Please revert all of these
There are a *lot* of out of scope changes here. Please try to revert all of those.
Also it seems it's failing because it's hitting the confirm form now instead of the previous action of just syncing.
Comment #86
Eli-TWith the @param changes, phpcs was complaining because the lines were > 80 chars, but didn't complain if they were split over two lines. What's the correct way to fix that? Or is my phpcs standards definition out of date?
I think the fail at line 96 occurs before that confirm form should make a difference?
Comment #87
tim.plunkettI don't use phpcs, and it often contradicts our coding standards.
Comment #88
Eli-TFix the source of the remaining test failures. Put to needs review to prove tests, but note out of scope changes in #85 still need addressing.
Comment #89
Eli-TPut back to needs work to address #85
Comment #90
Eli-TComment #91
Eli-TWrap Import in t() when defining tests.
Remove unused properties from classes where functionality has moved from Config Sync to Confirm Form.
Fix permission comments in tests.
Fix coding standards.
Add missing @param declarations.
Comment #92
Eli-TComment #93
Eli-TInterdiff to the last reviewed version.
Comment #94
alexpottTested import and export through the UI and everything is working nicely.
I think we should open a followup to discuss the single import / export UI since that came up in this issue. I also think we should open a followup to change the message on synchronisation page if the staging folder is empty. Since it should be different when there is nothing to import because it matches.
storer => store
We can now remove ConfigSyncForm::processBatch() and ConfigSyncForm::finishBatch() as they are no longer needed.
I know this is a copy and paste job but let's document that this is a batch callback. Let's copy and amend the docs for _node_access_rebuild_batch_finished
Comment #95
Eli-TComments in #94 addressed.
Comment #96
Eli-TComment #97
Eli-TComment #98
Eli-TRemove redundant
use Drupal\Core\Config\ConfigImporter;
from ConfigSync.php; not required now redundant ConfigSync::processBatch() and ConfigSync::finishBatch() have been removed.Comment #99
alexpottThanks for addressing everything from #94. I think this is good to go.
Comment #101
Eli-TGo home drupal.org, you are drunk.
#100 by d.o says
but the last submitted patch was configuration-2247291-98.patch, and that passed testing.
Comment #102
Eli-TComment #103
alexpottAdded beta evaluation.
Comment #104
alexpottComment #105
alexpottComment #106
alexpottComment #107
effulgentsia CreditAttribution: effulgentsia at Acquia commentedSince this is primarily about changing a UI, assigning to webchick for final review/commit.
Comment #108
Eli-TRetitle after conversation with @berdir in IRC
Comment #109
Eli-TFinal screenshots to clarify
Select Configuration Synchronisation from admin/config
Tabs structure now based on what you are doing first rather than how much you are doing
Import tab has subtabs Full and Single
As does export
All these processes work exactly as they did before with the exception of Synchronize. That now has an added confirmation step.
So assuming you already have a full config set you wish to import, select and upload it from /admin/config/development/configuration/full/import:
You are redirected to the Sync page as before, but this time after pressing Import All...
..you are presented with a confirmation form before the destructive operation of importing the configuration is carried out
Press import and the new config is imported, before you are redirected to the sync screen and confirmation
and we can see the effects of the config import
Comment #110
jhodgdonWow, great, thanks for the screenshots!
So... these screenshots really highlight that we are still using the word "import" in this UI for two or maybe even three different things, and Synchronize is only the page title and everywhere else in help/UI it says "Import. Here's what I mean:
a) On the Single Import page, Import means "Paste in some config YAML, and we'll put it directly into the active config".
b) On the Full Import page, Import in the help means "Upload a zip file, and we'll unzip it into your config staging directory" (the button is called Upload, which is good at least). This doesn't really seem all that related to the operation of Import on the Single import age. It really belongs grouped with the operation that is on Synchronize, I think, because it doesn't actually do anything to your site unless you also go to Synchronize. Really it's an Upload operation as part of Synchronize, right?
c) On the Synchronize page, which confusingly has no help or UI text aside from the page title that say "synchronize" on them (it all talks about importing), clicking the Import button means "Take the changes currently in your config staging directory, and put them into the active config". I have no idea why it is called Synchronize at all, because the help at the top and the button call it Import, and it's really the second step in the Full Import process (or I guess you could have uploaded the file separately).
So. This still seems pretty confusing. Is it out of scope to ask that we clear up the terminology and help so that they make more sense?
I think it would really make more sense to have:
Full import
- Synchronize tab that would be the current page that does the importing into active
- Upload tab that would be the current Import / Full page that uploads and unzips config into staging
Single import
Full export
Single export
(or those last two tabs could be as they are now, Full and Single tabs under Export)... Or maybe
Import
- Full import [what is currently called Synchronize]
- Full upload
- Single
Export
- Full
- Single
I don't know... but if we're sticking with a page called Synchronize, we should also update the page help so it uses that terminology, and ... that Full Import page should be called Upload and definitely belongs grouped with the Synchronize page.
Comment #111
Eli-TReturning to RTBC following discussion with @jhodgdon and @alexpott. Whilst there are further improvements that can be made in this area, this patch improves the UI and does not exacerbate any existing problems.
Comment #112
jhodgdonIf we commit this as-is, then I would suggest a followup where we:
a) Consolidate this further into two main tabs, Import and Export, with the following sub-tab structure:
Import
- Synchronize (with all language/buttons on this page changed from saying Import to Synchronize)
- Upload full (making sure it doesn't use "import" terminology to mean "upload and unzip a file", and making sure it mentions that after upload you need to synchronize)
- Single
Export
- Full
- Single
b) Update all the hook_help() [both module topic and page-level help] so it matches the UI and makes the terminology of Import, Synchronize, and Upload clear.
Comment #113
Eli-THaving slept on this, I don't think the disruption of changing the tab structure twice in two successive issues is worth it. So am happy to rework this in this issue if consensus can be agreed by all the relevant parties (webchick, yoroy, jhodgdon, alexpott) on the way forward.
Comment #114
yoroy CreditAttribution: yoroy as a volunteer commentedI think jhodgdons concerns are very valid. Especially about clearly differentiating between upload and actual syncing.
Not sure on wether that should be a follow up or not. I don't mind incremental progress, at 100+ comments in it may be better as a follow up?
Comment #115
tsvenson CreditAttribution: tsvenson as a volunteer commentedThis issue got to my attention from the #drupal-usability IRC channel.
Have read through the summary and comments from the screenshots i #109 and forward.
I think the choice of "Full" and "Single" can be cause to some confusion as a full synchronization is also a single (one time) synchronization workflow.
Change of words:
This should also help to improve readability for the information text as the distinction between "complete" and "individual" is clearer than "full" and "single" when comparing "A full synchronization" with "A single synchronization".
I'd be happy to do a screenshare review where someone with the backend knowledge can demonstrate and walk through the process involved for a user performing these actions.
Comment #116
jhodgdonSo... Another idea. The tab structure now, as well as the latest patch, is rather cumbersome if you navigate using the existing menu system -- requires a lot of clicks.
Would it be possible to just have one set of tabs rather than sub-tabs? Perhaps with names:
- Full update
- Upload archive
- Export archive
- Single update
- Single export
This would keep the 3 pages related to "full" operations together, and hopefully make it clearer by glancing at the tab names, that the thing you export (an archive) can then be uploaded, and then you can update the config from that (or you might have put the config in staging in another way and update from that).
Personally I don't like the term synchronize at all by the way... I really don't know what it means, and given that there's not any UI text or help that uses the term "synchronize", I think it's not a good match for what the page does... So I thought of "Update", and then changed the Single page to have the same name.
(bikeshed away!)
Comment #117
jhodgdonActually I like #115 too... so maybe the tab names could be:
* Complete update
* Upload archive
* Export archive
* Update item
* Export item
Comment #118
tim.plunkettIs "Update item" the new name for "Single import"? Because I use it to add config entities to the system, never tried updating an existing one...
Comment #119
jhodgdonGood point. Probably "Import item" would be better. Not sure if it would do an update actually.
Comment #121
Eli-TI've separated the confirmation dialog to #2572503: Add confirm dialog before full configuration import so that is not held back whilst the naming/arrangement of tabs is still being discussed.
Comment #122
Eli-TPatch to remove the confirm form from this issue now that's been moved to #2572503: Add confirm dialog before full configuration import.
This in no way is meant to disregard the suggestions by @jhodgdon, @yoroy and @tsvenson, just to cleanly split the two changes as they currently stand before doing further changes.
Comment #123
Eli-TComment #124
Bojhan CreditAttribution: Bojhan commented@jhodgdon I am wondering what is the minimal we can do given the time-frame. This UI can always be optimised, but I feel we've already had over #100 comments and with that arriving at a sensible direction that will improve the user experience. I am a little uncomfortable with the very drastic suggestions, of completely dropping the arrived at information architecture.
I think we should retain the information architecture split between uploading and exporting. Moving to a "tab" per action is a big departure, and I am not sure it will actually improve the overview we are trying to create. I would suggest to primarily focus on making the labels more usable.
Comment #125
ifrikPatch #122 looks good to me as it's very clearly seperates the different actions of importing and exporting, and only then let's the user choose between the same options (full or single) in both cases.
The hook_help text refers to the page titles by name so this either needs updating in this patch as well, or please post a follow-up issue as child of #1908570: [meta] Update or create hook_help() texts for D8 core modules.
Comment #126
Eli-T@ifriks I've reviewed the current hook_help() implementation and don't think it needs any changes. Whilst the tabs have been renamed and restructured, the page names themselves haven't, and only the page names are referred to in hook_help().
Comment #127
yoroy CreditAttribution: yoroy as a volunteer commentedIf we keep the tab organisation to what we arrived at and we update labels and texts in #2572537: Update the UI texts for the Configuration Manager module than this would be rtbc again. Is it practical to have a separate issue for the labels? I'm not so sure.
Comment #128
yoroy CreditAttribution: yoroy as a volunteer commentedEli-T and I discussed how to best move forward with this and its related issues (yay face to face sprints :-).
- The tab arrangement we arrived at is a solid improvement, and we should commit this. But:
- Add one more label change here because that's what we've already been doing here: rename the 'Full' and 'Single' tabs to 'Full archive' and 'Single item'.
- Further refine help texts, field labels etc. in #2572537: Update the UI texts for the Configuration Manager module
Comment #129
Eli-TPatch to implement based on #128
Comment #130
yoroy CreditAttribution: yoroy as a volunteer commentedTests pass, we're back to the earlier rtbc state with one additional change to the tab names as per #128.
#2572537: Update the UI texts for the Configuration Manager module and #2572503: Add confirm dialog before full configuration import are the followups, marking rtbc
Comment #131
alexpottGiven the amount of consensus building that has go on on this issue I think we're good to go. This makes the UI better and easier to understand and we have followups in place to continue the improvements. Committed 2c83881 and pushed to 8.0.x. Thanks!