The current UI provided by migrate_ui is developer-oriented - the work in #1826112: Wizard framework will be exposing the migrate UI to non-technical users, so we need to expose a simpler UI for them. I will be introducing a new permission level, 'advanced migration information' - the existing 'migration information' permission will show the most basic status information and Import and Rollback buttons, while the advanced version will provide a full UI (which probably will get a few tweaks along the way as well).


mikeryan’s picture

Issue tags: +Migrate 2.6

Tagging for 2.6.

mikeryan’s picture

Title: Add advanced UI permission » Support basic and advanced UIs

Broadening the scope - the permission was committed to the wizard_api branch, which has now been merged to 7.x-2.x, with some elements of the UI hidden for the basic permission. We still need to put a fair amount of thought into how to support both non-technical users looking to just import as easily as possible, and developers needing detailed information on the state of their migrations.

mikeryan’s picture

I'm making progress on this - I'd like to point out that I'm making changes to the language around migration in the UI. From my recent blog post:

One big issue is terminology - with more serious UX attention on Migrate, we want to present clear non-technical terms to end users. But, to preserve good DX, the terminology developers see ideally should reflect that used in the API. A primary example is the word "Migrate" itself - for the end-user scenarios we're looking at, "Import" is preferable, and even from a development scenario in the long run thinking of this API as providing import services would be preferable - but for now, with Migrate 2, the word Migrate is thoroughly embedded everywhere, and it would be confusing for developers to deal with things that are called "migrations" in the code and, say, "importers" on the front end. It may be, though, that we will ask the developers to bite the bullet on this one, because trying to maintain two front-end terminologies will be even uglier.

So, I'm moving in this directions, using import-centric language where I can. One important terminology change, given that migration groups are becoming more prominent, is to represent migration groups as "Import jobs" and individual migrations as "Import tasks". The main dashboard will now list the jobs, and operations can be performed on the job as a whole - clicking on a job name will go to a page listing the tasks for that job (looking much like the old dashboard, restricted to a single group).

Feedback welcome - I figure I'll be committing my current work to the wizard_api branch within a day or two.

moshe weitzman’s picture

I'm a little hesitant to move away from the word Migrate and introduce 'Import' even in limited cases. Import only communicates what happens in Drupal. Migrate encompasses the whole process, including the Source. We are not just importing into Drupal, we are importing FROM something, and thats what 'Migrate ' emphasizes.

Also, the legacy issue is significant. We have great mindshare with the word 'Migrate' and I'm loathe to muddle it.

mikeryan’s picture

I've talked to Moshe and he makes some good points on maintaining the Migrate language. I'm still leaning towards moving towards import-centric language at the moment though. I've committed the work I've done along those lines to the wizard_api branch to get some community feedback, and am pursuing getting some formal UX design input as well.

mikeryan’s picture

This remains open - I need to make a review of where the UI stands now, and figure out exactly where the boundary between basic and advanced should lie (i.e., what things should be hidden for basic users). But in the meantime, one thing I'd like to resolve here is the terminology.

See comment #3 and below for my original reasoning - the Migrate module is currently used exclusively (or nearly exclusively) to bring data into Drupal - i.e., for import. Thus, the "import" language seems more specific and clearer, especially for non-technical users.

However, as I contemplate the next generation of Migrate for Drupal 8, I see that the underlying architecture, with its source and destination abstractions, can handle moving data from anywhere to anywhere - it's only when a destination represents a Drupal object that it's really an "import". I can visualize most of the functionality of the current Migrate framework really being more general than Drupal - a framework that could be part of Symfony, or at least a Packagist package. At that level, the "migrate" language makes more sense - the "import" language would be more appropriate in a higher-level framework designed for pulling data into Drupal - a WordPress Import, a Jive Import, a Ning Import, etc.

So, unless someone makes a compelling case for sticking with the "new" import language for Migrate 2.6, I'll be going back in the "migrate" direction. I know this will cause some whiplash for those who are closely tracking -dev (and have some recent day-job projects that would be affected), but I'm now thinking this is best in the long term.

Along with the migrate/import question, I'm thinking of going back to the "groups" concept in the UI instead of "jobs" - this will lend more consistency between the UI and API. I think I will stick with "tasks" to describe specific migrations, though - calling something "a migration" isn't clear at all, and also seems a better way to describe those MigrationBase-derived cases which don't actually move data.

mikeryan’s picture

Reverted to "migrate"-centric language in place of "import"-centric language.

havran’s picture

I think you are miss one line or latest commit (

In line 208 should be `admin/content/migrate...` in path:

      l($display_name, "admin/content/migrate/jobs/$group_name/$machine_name");
mikeryan’s picture

I've committed that fix, thanks for catching that.

mikeryan’s picture

Status: Active » Fixed

Renamed "jobs" back to "groups"

That's it for now on this, I think. There are still questions in my mind over what the "basic" permission should and shouldn't see, but let's get this out into a beta release and get feedback on that (in fresh issues).

Automatically closed -- issue fixed for 2 weeks with no activity.