[wp-trac] [WordPress Trac] #60992: Plugin management: AJAX plugin activation consequences

[WordPress Trac]

#60992: Plugin management: AJAX plugin activation consequences
-------------------------------------------------+-------------------------
 Reporter:  jeherve                              |       Owner:  jorbin
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  6.5.3
Component:  Plugins                              |     Version:  6.5
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch needs-testing has-         |     Focuses:
  testing-info needs-design-feedback commit      |
  i18n-change fixed-major dev-reviewed           |
-------------------------------------------------+-------------------------

Comment (by smub):

 I appreciate the core team working to add a Refresh button here, but I
 feel this is adding extra friction and complexity for beginners / non-
 techy users.

 One of the best parts about WordPress is that we have always prioritized
 in building for the 95%  but unfortunately in this situation, we have
 regressed in our values and are catering to the needs of 1% at the expense
 of adding friction and complexity for the larger user base.

 Based on my experience working with beginner users, vast majority of users
 and site owners **DO NOT** bulk install plugins and most don't have a clue
 of what WP CLI even is.

 Heck installing even a single plugin and configuring it to work properly
 is a tall order for many.

 This is why a guided onboarding wizard, some sort of visible walk through,
 tooltips or admin notice is needed immediately to help the user Get
 Started. It also has to be prominent enough, so a new user who's not
 familiar with the UI of WP admin can identify what they should do next.

 All of this is fairly normal behavior in mobile apps, SaaS platforms, and
 frankly most other software that's built today. When you first get a New
 Mac, you have an onboarding wizard. It doesn't require you to refresh a
 screen or click a button to see what you'll be greeted with next. Getting
 a new Mac is similar to setting up a new website.

 When you install plugins on your Mac (i.e Dropbox or another extension),
 it's done ONE at a time -- most normal folks / beginners don't multi-task
 in the way a Pro user might. And as you'd expect, any app that you
 install, in this example Dropbox will open up a guided setup wizard (which
 in plugins we call onboarding wizards). This ensures that your computer
 can sync to the cloud and your files are secure.

 This is the behavior that any user who uses any type of modern technology
 has come to expect. Most folks DO NOT use the command prompt, and GUI
 exists for a reason -- to make technology accessible to all.

 It's completely normal and I'd say expected from the majority of users
 (who are non-techies) that when they install a plugin like WooCommerce or
 another, that they are immediately taken to the NEXT step like we used to,
 so they can accomplish the job that needs to be done (i.e add a store to
 their site). We need to learn from the Jobs to Be Done Framework here.

 IMO as the first step, it'd be better for us to REVERT to the old way
 where the activation allows the plugins to trigger the onboarding wizard
 vs. requiring a user action of any sort (like it was done before).

 Yes in the short-term, this breaks the dependency challenge which is of
 course an important concern. I know this because Thomas at AM built TGMPA
 library, but in an attempt to fix a problem that's small on a relative
 scale, we're creating a much bigger problem right now which affects the
 ease of use of the most critical aspect of the WordPress platform (plugin
 ecosystem).

 Long term, it would be ideal for us to think of a solution that looks at
 plugin installation and activation with different jobs to be done
 framework / use-case in mind. For example, we should think about bulk
 activation experience differently because bulk activation is the smaller
 use-case here ... and perhaps we can allow plugin authors a function / way
 to deal with a different type of experience for "Power Users" who are
 performing bulk tasks on sites. Along the line, we can think of a
 different filter / hook for dependency plugin user experience / flow.
 Batching all plugin installs & activation as one user experience is akin
 to taking an hammer and treating every problem like a nail.

 We need to work together and uphold the values that made WordPress as good
 as it is today by ensuring that we always prioritize the needs of 95% and
 that ease of use for non-techy / avg. user remains central in every
 decision that we make. We're doing this in many areas of the WordPress
 project right now such as the Block Editor which is bringing the project
 forward as well as the Data Liberation initiative, but unfortunately in
 this plugin activation scenario we have seen regression. We shouldn't be
 afraid to undo / rollback to fix the problem we introduced vs. settling
 for a less than ideal solution.

 I have left the same comment on #61040 since that's where the discussion
 has moved on to but also adding the comment here since this ticket is
 followed by more individuals with the power to perhaps undo vs. pushing
 the change above live in the next release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60992#comment:95>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform