[wp-trac] [WordPress Trac] #61040: Provide a framework for plugin onboarding experiences

[WordPress Trac]

#61040: Provide a framework for plugin onboarding experiences
-------------------------+------------------------------
 Reporter:  jorbin       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  administration
-------------------------+------------------------------

Comment (by costdev):

 @alanfuller The activation issue you had with WooCommerce seems to ne
 unrelated. That's not what was happening during testing.

 The `Install Now` button not being enbled after installing the
 dependencies is a known issue where work is intended to resolve that in
 6.6.

 > But what I really want is it to be simple - I select a plugin that
 requires another plugin why can't I just install (and activate ) them all
 - why should i have to go back and forth through modals one by one? Maybe
 there are use cases where the one by one activity is needed, but I would
 have thought the basic premise, I need two plugins lets get two plugins
 would be the default.

 The primary reasons are transparency and user control. Yes, a user could
 have control by clicking to install and activate the dependencies, but
 they won't know what those dependencies are or what they do. Even if not
 all users want to read the information, any user **should** be able to.

 > @smub We should work towards building the best workflow for the
 respective Jobs to Be Done. But before we do that, the best thing to do is
 to Revert until we come up with a user-friendly solution

 Reverting isn't a prerequisite to making improvements, and I think what we
 feel about the current flows shouldn't be the reason for a revert. We need
 to establish data that indicates how users are finding the flows after
 6.5.3.

 I understand that the flow isn't perfect, though there are limits to what
 we can do in a minor, and reverting a released major feature has impacts
 on backward compatibility, documentation, setting precedence, and
 contributor morale. There was ample time to explore, test and provide
 feedback on the feature before it was released, and the changes to UX were
 communicated through all the official channels. The QA channels and time
 period in WordPress have been established and known for a long time. The
 flows can be improved or changed without impacting backward compatibility,
 but we can't revert the whole feature without a backward compatibility
 break.

 Pre-release, reverting would be understandable as a first step, but post-
 release, balancing what's best for users isn't easy - as we all know - and
 we should consider how we can iterate before consider reverting as a last
 resort, rather than considering revert as the first step.

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