Support branded screens in AspireUpdate powered sites

[asirota]

When AspireUpdate rewrite is turned on let's decorate the following screens

1 plugins -> add new plugin 2 installed plugins screen 3 themes -> add new theme 4 installed themes screen

Also implement kill switch to turn off all branding -

LETS_GO_VOLTRON_FORCE = true turns branding on, false turns it of

See various fun quotes https://www.quotes.net/movies/voltron%3A_defender_of_the_universe_108550

Put this quote somewhere deep in the UI or even the code

From days of long ago, from uncharted regions of the universe, comes a legend; the legend of Voltron, Defender of the Universe, a mighty robot, loved by good, feared by evil. As Voltron's legend grew, peace settled across the galaxy. On Planet Earth, a Galaxy Alliance was formed. Together with the good planets of the solar system, they maintained peace throughout the universe, until a new horrible menace threatened the galaxy. Voltron was needed once more. This is the story of the super force of space explorers, specially trained and sent by the Alliance to bring back Voltron, Defender of the Universe!

[costdev]

Do we have any designers who can post visuals to implement?

From there, we can outline the necessary approaches (CSS seems appropriate for now, but others may be suitable for some parts).

It would be good to ensure we maintain the brand and utilize the various skillsets of the contributor base.

[JamieWalkerSTF]

Is this the type of design you're looking for? To what extent is AspirePress overwriting the content? ie, are the reviews still coming from wordpress.org?

See here for the Figma: https://www.figma.com/design/RdiaFxFv1cSAe1ZxWbgjm3/AspirePress-UI-2024?node-id=1-5&m=dev&t=EzqR8dsG38TIkX1l-1

[asirota]

That's so corporate. A little intrusive too on the content which is coming from our own repo. How about more like a fun badge with our logo and some edging around the borders?

[JamieWalkerSTF]

A badge like this?

[JamieWalkerSTF]

Option 3

[asirota]

I think that would be too much on every Plugin. Can you use the logo assets from #ap-website? @kylek14 has them.

Maybe some decoration outside the plugin lists

[kylek14]

We'd probably be better off just putting a banner on the overall plugin repo page or just a text stating "Powered by AspirePress" or "Plugin Marketplace: api.aspirepress.org"

[thisanastasiya]

A color hue would be a better instant indicator, with the small text. Otherwise text-only can be missed. Just a lighter blue, something like #dfe9f1 to replace #f0f0f1

[JamieWalkerSTF]

A couple more ideas:

[costdev]

Below the filters "Featured", "Popular", etc. There is a line that changes depending on the filter. For example, "Plugins extend and expand"...

We can add whatever we want before, after, or instead of these lines.

Now, since this issue is about branding, I think the wording in these lines could be discussed in a different issue, but we could still put something like a "Powered by AspirePress" button / text / text with linked logo just above the line of text.

This means we can illustrate which parts are powered by AspirePress. e.g. Don't include it on "Favorites" unless/until we power that (we could potentially power this in future, but that's another discussion).

Thoughts?

[ipajen]

There is a text: ”Plugins extend and expand the functionality of WordPress. You may install plugins in the WordPress Plugin Directory right from here, or upload a plugin in .zip format by clicking the button at the top of this page.”

that make me thinking. Instead of Powered by, maybe its should be distributed by? As its still the WP plugin directory or? And how could the branding look like with AP plugin directory + WP plugin directory distrubuted by AP.

[namithj]

Obviously we have to take out the "Wordpress Plugin Directory" part as we will eventually be serving more than that.

[costdev]

That's why I'm thinking that's the most appropriate place for branding - We can hook into the area and either add to, or replace the existing output for each tab based on our current impact on that tab.

When AspirePress affects a tab's API response in any way:

1. If the tab's text doesn't need to change, just add AspirePress branding by hooking before the text's output.

Example:

// Each $tab should be targeted directly.

// Use a priority of 9 since the default priority is 10.
add_action( "install_plugins_{$tab}", 'ap_display_branding' , 9 );

2. If the tab's text does need to change, replace the text with AspirePress branding and new text by unhooking Core's callback and hooking our own.

Example:

// Each $tab should be targeted directly.

remove_action( "install_plugins_{$tab}", 'display_plugins_table' );
// Set a priority of 9 so AspirePress' output appears before other plugins that may do something here.
add_action( "install_plugins_{$tab}", 'ap_display_plugins_table', 9 );

When AspirePress doesn't affect a tab's API response in any way: Don't show AspirePress branding at all.

References

• Core's default hooks for these tabs

[lilacpixel]

A suggestion: since the branding needs to appear in a number of locations, could we use the WordPress admin bar for this? A number of plugins hook into this space already, it's relatively static (so we don't need to account for the differences between, say, theme pages and plugins pages), and it could be utilized as a quick button toggle, much in the same way as maintenance mode plugins tend to operate. I've thrown together a very quick demo in Figma:

(The mountain icon is just something I grabbed from Font Awesome and can be swapped out, of course 😊)

You can test the proposed toggle functionality in the prototype:

https://www.figma.com/proto/FffNH3AYOFusxPybNcKRz5/AspirePress?page-id=0%3A1&node-id=1-2&node-type=canvas&viewport=156%2C94%2C1&t=09YQVMqwHF0zRPJN-1&scaling=min-zoom&content-scaling=fixed

Would love to hear your thoughts!

[namithj]

When we take out "Featured", "Popular", "recommended" and "Favorites" tabs, nothing remains. We will need to add something there so as not to break the design and anything which might hook onto those tabs.

[namithj]

@asirota Lets split this into two issues / discussions. One for Branding and another for the plugin and theme tabs, labels and the info paragraph underneath. The tab part needs to be worked on irrespective of the branding part

[asirota]

So branding is just assets and design. The other is actual UI functionality changes right?

I like the admin bar toggle. Does it work or just reflect the current state?

[lilacpixel]

I like the admin bar toggle. Does it work or just reflect the current state?

I envisioned it as a functional toggle, but I'm not sure how feasible that might be in practice! If it needs to be display-only, removing the toggle icon on the right side seems like the simplest solution.

I've updated the prototype to show both variants (accessible from the sidebar), as well as to replace the default mountain icon with the AspirePress logo.

https://www.figma.com/proto/FffNH3AYOFusxPybNcKRz5/AspirePress?page-id=0%3A1&node-id=1-2&node-type=canvas&viewport=197%2C-4%2C1&t=KE9VFR4NEoyRA8gy-1&scaling=min-zoom&content-scaling=fixed&show-proto-sidebar=1&starting-point-node-id=1%3A2

[costdev]

One note about a toggle is that the AP_ENABLE constant, when set to true, should presumably take precedence and the toggle should not be available.

If that's the case, then we could either have the toggle available only if AP_ENABLE is false, or we can forego a toggle and just link the button to the settings.

Functionally speaking, toggling could maybe just be an AJAX request to toggle the 'enable' option of the plugin, followed by a page refresh.

[asirota]

Anyone want to take on the issue to do the toggle as described by @lilacpixel and @costdev ?

[namithj]

Can you open a new issue for the fields, we discussed disabling any fields set in config file in the UI but never implemented that.

The plan was to grey out (disable) the field and give a visual indication that this field is preset in the config file and hence not editable.

[asirota]

Can you open a new issue for the fields, we discussed disabling any fields set in config file in the UI but never implemented that.

The plan was to grey out (disable) the field and give a visual indication that this field is preset in the config file and hence not editable.

Please clarify -- I am lost here what fields?

[namithj]

When something is set via the config file the corresponding option should not be user editable. Currently we allow user editing but doesn't use that input which can be confusing. Need to give visual cue regarding this.

[costdev]

Anyone want to take on the issue to do the toggle as described by @lilacpixel and @costdev ?

@asirota You can go ahead and assign me for this one. I've asked @lilacpixel in Slack to send me through the asset used in the prototype and I can get onto this tomorrow.

[namithj]

Let's not rush to do the toggle in the adminbar. This is not a feature we want people turning on and off, it's a set and forget setting and normal users won't even understand what that toggle does.

I would say Let's finalise the branding discussion before getting into implementing.

[asirota]

Let's implement the toggle and then decide whether to include it or not via a PR. No reason we can't add it for now as a potential part of the branding. I like being able to toggle stuff like this and gives it prominence. There's a global branding toggle that can turn all of this off but it's a good idea I think.

[namithj]

Would this obey the NO_UI setting?

[asirota]

When something is set via the config file the corresponding option should not be user editable. Currently we allow user editing but doesn't use that input which can be confusing. Need to give visual cue regarding this.

Absolutely -- the LETS_GO_VOLTRON_FORCE branding kill switch

[asirota]

I'm ok to have a full PR around branding that would include this if the team decided it was a good idea. I am not super attached to the admin bar toggle, but so far it's the best thing I have seen as a short cut to turn on rewrite rules and gives the plugin some visibility in the UI. I wonder if there is admin bar guidelines as to what goes there and what doesn't?

[namithj]

I am not a fan of that toggle

1) The plugin is not supposed to be toggled like that, it should be a set and forget system and it will lead to issues Eg - Someone installs real ACF and toggle the plugin off, they will be served the fake on (ie SCF), also down the road the versions of the plugins served from w.org and mirrors will vary and it will create issues when the plugin is toggled off like this.
When someone goes to the plugin admin page and does and action it's a different thing. If we keep a toy on the table and a toddler plays with it and breaks it, the fault is on the person who kept it there.

2) action elements there is not convention

[namithj]

If we indeed want something there we can add a link to the plugin admin page there and may be change color of the link button to blue to show it's turned on. BUT to turn it off someone has to click it, visit the plugin admin page and toggle the plugin off

[namithj]

If the no UI toggle is on, none of this should appear

[costdev]

I concur that while the plugin's features can be toggled, there's no need for such a prominent toggle feature and it may lead to unexpected/unintended user behaviour.

The admin bar can get quite busy on websites as, along with admin notices or a top-level menu item, it can be a "go-to" way to advertise a plugin's existence on a site.

One of the things I found to be really nice about AspireUpdate when I first activated it is that it didn't have a top-level menu item. It was where I expected it to be -> Dashboard -> Beneath Updates. Sure, it could have been in Settings or Tools, but the fact it wasn't obnoxious was refreshing.

Since the plugin isn't used on every screen of the admin area, it seems possibly over the top to include branding on every screen. At the moment, I'm thinking that putting branding only on the pages/tabs that are affected by the plugin, and only when appropriate settings are in place, would be my preference.

[namithj]

That's how the issue was created. Ie An overlay in some corner and may be a different color scheme for pages where the plugin actually makes a difference. There is elegance in minimalism.

[costdev]

Minimalism works for me here too. Changing the scheme may be a bit much depending on how it's done - noting that the selected admin color scheme may need to be considered there.

Part of me thinks just "Powered by " above the tab descriptions on plugin-install.php (Plugins > Add New Plugin), theme-install.php (Themes -> Add New Theme) and on update-core.php (Dashboard -> Updates) would be enough.

[lilacpixel]

Thanks for the feedback! I'd be glad to mock up some subtle branding for individual pages to replace the admin bar indicator. Any thoughts on if or how it might be possible to place an element on the same row as the page heading, ideally before the buttons (to keep the delineation between "display" and "interactive")? Would we be overriding whole template files in /wp-admin? From a quick glance at themes.php, I didn't see anything in that area that looked terribly hookable, but I defer to those of you who have more experience in modifying admin pages 😸

[costdev]

It'll likely require JS or CSS to insert between the title and the button.

[lilacpixel]

Here's one possibility for a simple image-based AspireUpdate indicator (as shown on a mockup of the installed themes page):

My main concern here is making sure that screen reader users can still access the current AspireUpdate status. Maybe we could hook into the admin bar and add some screen-readable "Powered by AspireUpdate" text that's hidden from sighted users? The default admin CSS provides the .screen-reader-text class for this, but is there a better way?

I also threw together a version that uses the admin_notices hook, just for the sake of comparison!

Figma prototype for both versions (accessible via the sidebar):

https://www.figma.com/proto/FffNH3AYOFusxPybNcKRz5/AspirePress?page-id=26%3A12&node-id=26-13&node-type=canvas&viewport=1353%2C654%2C1&t=pxScpoxp5TOTcPp5-1&scaling=min-zoom&content-scaling=fixed&show-proto-sidebar=1&starting-point-node-id=26%3A13

[asirota]

@lilacpixel I added a couple of small comments in your figma about AspireUpdate. Should be AspirePress, the project, rather than the plugin that powers the updates

Here's an idea - -

What if the action buttons in the UI slighlty change hue or tone to our darker colour on the logo? There are action buttons in the UI that could change color like this?

[lilacpixel]

Thanks, @asirota, made those fixes! 😄

Ooh, I like the idea of a UI recolor! Since that WordPress medium blue (#2271B1) is used on both light and dark backgrounds, I had a hard time simply swapping it out for the darker AspirePress blue, but could we use the same blue to replace, say, the UI's default dark gray? It's a pretty similar tone, and I think it does add a bit of interest!

I added a separate flow to Figma to illustrate the difference in the full UI:

https://www.figma.com/proto/FffNH3AYOFusxPybNcKRz5/AspirePress?page-id=26%3A12&node-id=51-230&node-type=frame&viewport=1083%2C767%2C1&t=Ob1bNmR5CZPGKzGJ-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=51%3A230&show-proto-sidebar=1

[costdev]

I think rebranding the whole UI / large parts of it is a bit too much. Remember that each user can set an admin scheme from their profile (Users > Profile - apply one to check it out if unfamilar). IMO, we should avoid overriding those bits with the branding so user preference is honoured while still being informed of when AspireUpdate is in operation on certain screens.

[lilacpixel]

I think rebranding the whole UI is a bit too much. Remember that each user can set an admin scheme from their profile (Users > Profile - apply one to check it out if unfamilar). IMO, we should avoid overriding those bits with the branding so user preference is honoured while still being informed of when AspireUpdate is in operation on certain screens.

Definitely, we would not want to force this type of change (for one, ignoring user preference for color scheme would be an accessibility issue)! I was thinking of it more in terms of setting a new default, which would be overridden by any change in the user's settings. That said, I don't feel strongly about it--just presenting some different options for discussion ☺️

[asirota]

Leaving it at just the badge you made then is fine for now. My main concern from the UI perspective is simply this:

If someone uses the dashboard and the plugin was installed for them they should quickly know somehow that their experience will be slightly different. Certain tabs are missing. Possibly a different result set for searches. A badge can help to identify that difference but I wonder if that's enough.

[lilacpixel]

I think that there's still a case to be made here for an admin bar solution. As I mentioned upthread, we don't necessarily need to employ a toggle--we can just use the admin bar's real estate to display an indication of the current status. There are a couple of advantages to using the admin bar:

• It's hookable, so we can serve HTML directly to the user, which is better for accessibility (and performance, in the case of a JS-based alternative).
• The location suggests that it's information that's relevant to the entire site, rather than localized to specific features. If an active install of AspirePress would significantly alter the look and feel of multiple areas of the backend, from a UX perspective, we should try to indicate its presence as prominently as possible.

If we were to make the indicator clickable, we could simply redirect the user to the relevant page for administrating settings, rather than making it a direct toggle. This might address some of the concerns over folks toggling it arbitrarily rather than setting and forgetting. (Perhaps there could even be a setting for disabling interactivity entirely, so the status indicator would be present, but it wouldn't be clickable at all.)

I've tried my hand at another admin bar prototype that's a bit less interactive in appearance! I'm imagining that mobile will have a similar look, just significantly compressed--I need to break for lunch, but I'll add those prototypes once I'm able to get back to my desk 😊

https://www.figma.com/proto/FffNH3AYOFusxPybNcKRz5/AspirePress?page-id=0%3A1&node-id=55-153&node-type=frame&viewport=112%2C127%2C1&t=3Np5VOxbTSDjSgXH-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=55%3A153&show-proto-sidebar=1

Would love to hear everyone's thoughts on all of the above!

[ipajen]

Personally I don’t like the admin bar as got so many plugins doing it already so it starts to get full.

How come we don’t just place the setting where we got the other settings? With default on.

[namithj]

What if we make the default Wordpress logo in the admin bar triple the width and replace it with a Wordpress empowered by Aspirepress logo?

PS : I don't like doing it.

[asirota]

Haha @namithj you're just asking for trouble. But I'd like to see a design with this anyways.

[lilacpixel]

Oh boy… 😆 Here are a few more comps that use the WP logo space (bottom three in the sidebar menu):

https://www.figma.com/proto/FffNH3AYOFusxPybNcKRz5/AspirePress?page-id=57%3A275&node-id=62-276&node-type=frame&viewport=885%2C482%2C1&t=eYGUvqWgWGcdnL0I-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=62%3A276&show-proto-sidebar=1

[costdev]

The plugin pulls installs/updates from a different source, it's not a fork - let's not go for the one that replaces the WordPress logo :sweat_smile:

[costdev]

The location suggests that it's information that's relevant to the entire site, rather than localized to specific features. If an active install of AspirePress would significantly alter the look and feel of multiple areas of the backend, from a UX perspective, we should try to indicate its presence as prominently as possible.

I believe this is incorrect. The plugin is designed to provide configuration for an alternative source for installing or updating WordPress, plugins, themes, etc. rather than significantly altering the UI across the site. It shouldn't really be significantlt altering the look/feel of those screens IMO. Some branding and messaging to indicate it's status and impact on a given screen seems more suitable to me.

These are the screens noted in the original issue description:

1. Plugins -> Add New Plugin
2. Plugins -> Installed Plugins
3. Appearance -> Themes -> Add New Theme
4. Appearance -> Themes

I would also add:

5. Dashboard -> Updates