Support basic and advanced UIs

Tagging for 2.6.

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.

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.

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.

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.

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

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

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).