Reorganize Seravo plugin and move it outside of Tools

[cr0vy]

Template of the Seravo Plugin page found now from dev/introduce-control-panel branch.

Current states:

• Includes land page and a few example submenus
• Include dashboard widget, which use own class / code file

Needs to brainstorming:

• Button position in left side panel
  • After the "Settings" menu?
  • Before the "Tools" menu?
• Name
  • Control Center?
    • I use currently this in dev/introduce-control-panel branch
  • sPanel or Seravo Panel?
    • Some resellers need the whitelabel.
  • Others?
• Style
• What content will be in dashboard widget?
  • Welcome text, which replace WordPress default "Welcome" box?
  • Seravo Blog content?

Blockers:

• Page which still use older postbox:
  • Mails
  • Shadows
• Using non-postbox page:
  • Domains

Dashboard Widget:

Control Center:

[ottok]

This needs to be fixed first I believe: https://github.com/Seravo/seravo-plugin/issues/228

[ottok]

Name suggestions for custom top-level menu item:

• Seravo Tools
• Seravo Toolbox
• Seravo Control Panel
• ..or just Seravo?

Menu idea:

• Seravo Toolbox
  • Site status
  • Upkeep
  • Security
  • Domains
  • Email
  • Development

[cr0vy]

I made concept pictures, which shows postboxes with a new placement. At the same time I used redesign picture of the shadows postbox, which find already from another issue.

Admin menu:

Site status:

Upkeep:

Logs:

Security:

Domains:

Mails:

Development:

[ottok]

Looks good! Is this layout now the same as was in the August 2018 plans?

[ottok]

Recap of discussion today: @cr0vy can proceed with re-organizing the pages and boxes, but do it under the current Tools menu without introducing a new Seravo Toolbox top level menu.

Introducing the new top level menu will be the last step and only done once white label issues are solved.

[ottok]

We need to figure out some way to make Seravo postboxes that are larger. Everything simply cannot fix into the same tiny metaboxes. Some content needs more screen estate.

[l3ku]

Is having larger postboxes the best solution for this? The original implementation idea for postboxes was to provide easy support for multiple small tools to the same page because many pages needed multiple small tools separated from each other, but now it has been extended for almost every plugin feature for some reason. I am starting to think that maybe postboxes are not such a good UI experience for users after all, because they tend to have a messy, uneven layout. Maybe we should design some kind of unified admin page GUI for different pages and use postboxes only where suitable (or remove them if there is no use-case for them anymore). For pages with a lot of content, we could also use tabs:

[ottok]

Using tabs "hides" information, I am not terribly keen on that. I'd prefer that we keep using postboxes but that there would be an option to put some content in larger postboxes as well.

[l3ku]

Using tabs "hides" information, I am not terribly keen on that. I'd prefer that we keep using postboxes but that there would be an option to put some content in larger postboxes as well.

Yes, it is probably a matter of opinion. But I think that having tabs for these kinds of pages would be much better even though they would hide some information, which could also be a good thing, because the user is presented with a huge amount of information at once to his/her face.

This also does not utilize the screen area very nicely, but this is an actual use case for the wider postbox:

[annijpesonen]

I have to agree with Leo on this one. I think about it as a comparison to a web page: there is no point putting all the information to the front page there either, because there is a limit in what the user can digest at one time. And based on my experience, it is always better to go for the solution that looks simple and airy and not crowded, because things get lost in the crowd. This also has an accessibility point of view, a full screen is pretty repulsive and hard to perceive.

So, by dividing the information/contect clearly to separate entities (tabs) we would actually be helping our users to find the information they need easier without a risk of overloading them.

[ottok]

Dashboard has full width box, can we repeat that?

[l3ku]

Dashboard has full width box, can we repeat that?

Yes, that can be implemented but then the full-width box will always has to be on top of the other postboxes. In the WP dashboard it is implemented as a dismissible welcome notification rather than postbox, so it makes sense to have it above the actual dashboard postboxes below because it can also be closed by clicking "Sulje". But in our case, do we want to have a section of full-width postboxes before the other smaller postboxes?

[l3ku]

Something like this?

[l3ku]

On a smaller screen resolution:

The top full-width postboxes are not movable. While this does in my opinion look better than having many small postboxes crammed, it forces us to have wider content first on the page. It also goes against the initial idea of postboxes being small simple tools that are related to each other in some way (like the database page tools).

[l3ku]

Pros and cons of postboxes: + easy for developers to create a neat(ish) looking page without a lot of code + well suited for many small tools (like in WP dashboard) + movable by the user - not very customizable layout - design looks unclean when there are postboxes with varying length content - a lot of screen space is not used when only having 1-2 postboxes on one page - wide content does not fit into smaller postboxes - all information is presented at once to the user - Many different AJAX spinners loading content at once and the postboxes having to resize at different times when the content is received looks messy

Having tabs could make it possible that only a single tab content would be loaded when the tab is active instead of everything on the page.

[l3ku]

Tabs are quite easily implementable, as WP core has built-in styles for .nav-tab and the pagination can be done with e.g. a ?tab=updates query param. However, the postboxes have been designed in a way which assumes that all postboxes registered to a page should be shown at once. That will need some tinkering if we keep to wish using postboxes, but with tabs enabled.

[cr0vy]

The current code from dev-samuli-postbox branch can produce two columns and the standard four columns for postboxes page.

Difference of Security and Backups add_submenu_page functions in dev-seravo-toolbox branch:

    add_submenu_page(
        'tools.php',
        __('Security', 'seravo'),
        __('Security', 'seravo'),
        'manage_options',
        'security_page',
        'Seravo\seravo_postboxes_page'
    );

    add_submenu_page(
        'tools.php',
        __('Backups', 'seravo'),
        __('Backups', 'seravo'),
        'manage_options',
        'backups_page',
        'Seravo\seravo_two_column_postboxes_page'
    );

[cr0vy]

Current status of the issue:

• Postboxes are already reorganized on new subpages
• Waiting for the new Seravo Toolbox menu

[ottok]

@nuuttitoivola @elguitar @JoosuaKoskinen This issue needs an status update

[nuuttitoivola]

The current status as of version 1.9.20 is that the Seravo plugin categories can still be found from under WordPress admin -> Tools.

Some categories have been merged and renamed for clarity.

[elguitar]

To close this issue, all the seravo-plugin specific pages should be moved from Tools to Seravo Toolkit or something similar

[sjaks]

There is now an active branch custom-toolbox with Seravo specific tools under their own menu page.

Seravo menu page is created with

add_menu_page( 
        __( 'Site Status', 'seravotools' ),
        'Seravo Tools',
        'manage_options',
        'seravotools',
        'Seravo\seravo_postboxes_page',
        1
);

Pages can be put under that page by using seravotools as the parent and seravo-tools_page_*_page as the postbox screen id.

I will do more experimenting on this on the upcoming week.

[sjaks]

Menu page name is now Site Toolkit in the dev branch. This is one of the most important factors in this change so it has to be thoroughly thought about. The default landing page of the menu is now Site Status because making an extra front page page seems unnecessary.

[ottok]

What is the plan here? It is good to experiment, but don't jump to implementation before there is a solid plan.

Should it be called "Seravo Tools" and visible as a separate menu only if SWD API says reseller=null?

How do we fetch and cache that data so that page load is not dependent on SWD API speed?

[sjaks]

@ottok using menu title "Seravo Tools" is a good idea if reseller=null. Moving the menu items under the default Tools page is possible. The implementation would require changing the postboxes' target page on the fly. When deciding this, it should be considered if a separate menu should always be created but named according to SWD API.

WordPress transient API provides a nice platform for caching the reseller info. The data should probably be fetched at site launch but whether it should be updated at some intervals is a matter to consider more in depth. The interval can be long but using just cache expiration date might be a problem since it could take a long time for changes to take place after changing the reseller data.

[ottok]

Maybe we would call it "Seravo Tools" by default, and if reseller != null then swap the "Seravo" part for the reseller name (with initial capital added and domain suffix removed)?

[sjaks]

@ottok That's what initially came to my mind. From implementation standpoint that's a straight-forward way to do it and I think is the best way to do it.

When saving the reseller name somewhere, the name could be formatted then.

[ottok]

How about saving the reseller name in a transient, eg. seravo_reseller_name? Transients are OK, they work even if object-cache.php is disabled. Transients are not always enabled in development, but that does not matter, we don't need the custom Seravo Tools menu in development.

Note that in shadows the SWD API is not available, and the menu with this design would always just show "Seravo Tools" unless there was a transient copied over from production.

[sjaks]

Transients should be used. The menu name should default to something generic (Seravo Tools) and be altered according to the transient.

There's this old branch https://github.com/Seravo/seravo-plugin/tree/fix/custom-toolbox with some preliminary changes. It should still work and can be extended with the transient functionality.