Core: Revamp admin interface

[dcsjapan]

_1 Upvote_ The Extensions page should be divided into categories so extensions will be easier to locate.

Possible categories to add:

• Authentication & Security
• Formatting (Markdown, BBcode, etc.)
• Language packs
• Themes
• Other

The Extension page will need to use composer.json tag info to determine which category an installed extension should be displayed under.

[luceos]

:+1:

[tobyzerner]

Perhaps extensions of the "themes" category should be shown on the Appearance page?

[luceos]

We can implement this once #764 has been implemented. It sends the type along with the extensions pushed into the view of the admin pages.

[tobyzerner]

Alright, I've got some mockups for this – but it's a bit more dramatic than simply dividing the extensions page into categories! It's a complete redesign of the admin interface.

A bit of preface: I've been noticing that the extension settings paradigm is a bit wonky. Some extensions add a pane to the sidebar (e.g. Tags), while others have a settings modal which isn't particularly discoverable, while others have nothing at all. What if we could unify this all to be simpler and more consistent?

Here goes...

The idea is that make the admin a single-page extension management interface, with each extension having its own predictable place to put settings, using the same paradigm as the core settings interfaces.

• Up the top, we've got the Dashboard widgets (yet to be implemented, #259). We'll probably still put off implementing that for a while as it's low priority.
• Moving down, we have a forum status box – online status, updates available, version information.
• Next, there's the first "category": Configuration. We get rid of the sidebar and shove the default admin interfaces in here (Basics, Permissions, Appearance, SMTP settings [#258]). There's also a "More" button which would open the extensions marketplace and filter by the "configuration" category. So you'd be able to install extensions which are purely admin/config-oriented, such as a "Backup" extension, and they'd appear here. Clicking on any of these icons will open a modal containing the interface.
• Then there's the second category: Features. Most extensions go here – extensions that add functionality to your forum. Again, there's an "Add a Feature" button which would open the marketplace. Clicking any of the icons opens a modal like so:

This modal contains two things: information about the extension, and its settings if it has any. So for some extensions it would just be the top part, with a description and links re: the extension, and the switch to enable/disable it. But for others, like Taxonomy, it contains their whole settings interface.

• The other categories work similarly (Authenticators and Languages).

Thoughts?

[dcsjapan]

Nice mockups! I like the idea of the bar graphs widget, I hope that happens eventually.

I'd suggest putting the status up on top, so admins won't have to scroll down past all their widgets (I'd assume there could be a lot of them) to see if any updates are available.

The idea of putting everything on one page, and using buttons to open configuration modals, would work very well if the dashboard is as uncluttered as the mockup. But when you consider that admins may want to put a lot of widgets on their dashboard, it will mean scrolling down every time they want to configure something. For that reason I think I'd prefer a tabs system that puts the dashboard and extensions on an even footing with the other configuration pages ... basically what we've got now, although the layout could maybe stand to be tweaked a bit. Maybe tabs across the top instead of down the side?

I love how the extensions are reduced to a simple grid of icon/buttons, but there's one bit of information that I feel is missing: we need some way to tell if an installed extension is enabled or not without having to open the modal first. (And I suspect some folks will want to be able to enable/disable extensions without opening the modal first, too.)

And ... how does one go about uninstalling extensions?

I've been noticing that the extension settings paradigm is a bit wonky. Some extensions add a pane to the sidebar (e.g. Tags), while others have a settings modal which isn't particularly discoverable, while others have nothing at all. What if we could unify this all to be simpler and more consistent?

I do like the idea of a unified modal infrastructure for the extensions! Your layout looks nice, but I'd like to see a little more room for the descriptive blurb. Would it be possible to put the "Enabled" toggle on the same line as the links (perhaps over by the right margin) and align the links with the bottom of the icon? Or something like that ...

_Off-topic: I like where you're going with the Taxonomy extension!_ :+1:

[franzliedke]

Very cool! What I like the most is the consistency across all these features / categories.

That said, there are some comments to be made:

• First off, I tend to agree with @dcsjapan if I understood him correctly: Separating the categories by tabs instead of panels may be a good idea.
• Also something that @dcsjapan already wrote: Even though it's very pretty, having only icons and title in the grid may not be enough. As has been mentioned in the forums, we probably need the description, too...

And finally, we need to make sure every possible extension will fit in with this paradigm. That's what I'm not entirely sure about... then again, I also don't have a concrete counter example...

[dcsjapan]

First off, I tend to agree with @dcsjapan if I understood him correctly: Separating the categories by tabs instead of panels may be a good idea.

I like how the different extension categories are grouped in the first mockup ... I'm just not sure handling the configurators in the same way will be the best way to go in the long run. I tend to find multiple configuration pages easier to grasp than a single page with a lot of modals. But maybe that's just me.

Even though it's very pretty, having only icons and title in the grid may not be enough. As has been mentioned in the forums, we probably need the description, too...

If users can get used to the idea that they can click on an icon to see a description (as well as links to things like appropriate support sites, bug trackers, source code, etc.), it should be possible to avoid cluttering up the extensions list with that information.

[Kakifrucht]

The mockups look amazing!
Maybe in order to facilitate the issues with having a more cluttered dashboard, one could add some anchor links that automatically scroll to the expected spot, instead of tabs.

[dcsjapan]

... one could add some anchor links that automatically scroll to the expected spot, instead of tabs.

That might be a good way around the problem! Incidentally ...

Perhaps extensions of the "themes" category should be shown on the Appearance page?

That wouldn't really work with the single-page style. I guess Themes would be another group?

[tobyzerner]

That wouldn't really work with the single-page style. I guess Themes would be another group?

Themes would probably be shown in the "Appearance" settings modal.

(Thanks for the feedback everyone, will respond in detail a bit later!)

[franzliedke]

If users can get used to the idea that they can click on an icon to see a description (as well as links to things like appropriate support sites, bug trackers, source code, etc.), it should be possible to avoid cluttering up the extensions list with that information.

Not sure whether that is discoverable enough. That said, it reminds me of an interesting alternative. It comes from iTunes, I believe. (Not sure if that's still the case, I haven't touched it in ages.) They used to have a similar grid of albums in the music list. When you clicked on an album (the thumbnail), a panel would open (essentially a new row in the grid, right below the clicked item) with the list of songs and other album details. This could be an option for a) showing more details and having quick controls, and b) to use instead of modals.

[luceos]

Not sure how this all works on mobile, especially the modal part. Perhaps still stick to a page instead of a modal to allow the utmost flexibility for extension developers?

[dcsjapan]

A couple more thoughts I thought I'd throw in here:

• Handling the configurators as modals adds an extra click to navigation: one click to open the modal, one click to close it. The tabbed pages approach is a bit more convenient when the admin just wants to quickly browse through the configuration pages and check settings or whatever.
• The tabbed pages approach opens up the possibility of listing all the pages in a submenu to the Administration command in the session menu, should you be inclined to do so. That would be handy when an admin wants to go directly from the front end to a specific page in the admin area (for example, when making custom CSS edits). This would be harder to do if the configurators are modals.

That's a couple more points in favor of the tabbed pages approach. That said, I'm intrigued by the idea that Franz posted:

It comes from iTunes, I believe. (Not sure if that's still the case, I haven't touched it in ages.) They used to have a similar grid of albums in the music list. When you clicked on an album (the thumbnail), a panel would open (essentially a new row in the grid, right below the clicked item) with the list of songs and other album details. This could be an option for a) showing more details and having quick controls, and b) to use instead of modals.

I've never used that view in iTunes, but it sounds like what Google and others do with images:

That's an interesting approach, as it offers a way around both the scrolling-past-the-huge-dashboard problem and the need for extra clicking entailed by modals. If we make the Dashboard itself another configurator and use this method, we could end up with something like this:

The layout needs a bit of work since I just hacked that in there, but you get the idea ... and you could of course use the same method to display the information and settings for extensions.

... One issue that needs to be solved is making it clear which configurator is selected, since the upward white triangle is pretty low-contrast. I've tried making the Dashboard icon black on orange, but that will only work for the monochromatic configurator icons. And what happens when when you select an icon that's in the first row of a group containing two or more rows of icons? Probably the expanded settings panel needs to have a different design from the white background being used to group icons. Or rather, the settings panel needs to fit within the white area ...

... Oh, and the "+ Add Widget" button would need to go inside the white frame ...

This style would also lend itself more readily than the modals to the submenu idea, should you wish to add that feature: selecting a specific configurator from the submenu would open the admin page and expand the configurator that was selected.

[franzliedke]

I'm with you on that one.

I think you got it right, but here's a proof of concept for the iTunes style layout that I was talking about:
https://jsfiddle.net/qgj44sqf/4/

Add some fancy animation and nice visuals, and this is ready ;)

[dcsjapan]

Add some fancy animation and nice visuals, and this is ready ;)

Yes, animating the opening of the settings panel really makes it work. :smile:

One thing that proof-of-concept does not do, that Google and others do, is close the settings panel when you click on the selected icon a second time. It would be nice to add that in (with animation, of course) along with a little [X] box in the upper right corner, for users who'd rather click one of those.

[tobyzerner]

Here's a thought: What if we scratch the idea of the "dashboard", and make each of what would've been "widgets" just another icon in the configuration section? So it would basically be like @dcsjapan's mockup, but "Dashboard" would be "Statistics", and there would be no "Add Widget" button. (Maybe we would want to drop the "configuration" title as well.)

Another question: Would any of the panes be expanded by default? Would it remember the one you last had open? Or would they all be collapsed to start with?

[franzliedke]

Having all of them collapsed wouldn't make sense. So yes, we either need to remember the last one or have a sensible / intelligent default.

A quick list of all categories with links to jump down to them (and open them immediately) would give you the overview you'd get from having them all collapsed by default.

[dcsjapan]

Replacing the dashboard with configurators sounds good. I like the idea of remembering the last one, at least until logout ... plus a sensible default if there is no remembered value.

A quick list of all categories with links to jump down to them (and open them immediately)

... could also be done as a submenu off the session menu, as I mentioned earlier. That makes it available even from the front end, for maximum convenience.

[tobyzerner]

New concept:

• Basically what we've got now, except we list extensions in the sidebar rather than on the "Extensions" page.

• The little ⚠️ icon indicates an extension hasn't been configured properly. An *️⃣ indicates there is an update available. A strikethrough indicates the extension is disabled.

• Use emoji flags for language pack icons.

• Not sure about the "discussion" / "moderation" extension categories. Could be a bit arbitrary?

• Display relevant permissions on each extension's own page.

[datitisev]

@tobscure What does the "Extensions" category in the Permissions section indicate? And "Contributors-only"?
Sorry if it's obvious...

And now I'll have to update AdminDashboard again... 🙄 😛
For the better 👌

[dcsjapan]

I like this idea ... it uses space much more efficiently. Perhaps you could make room for a larger version of the extension icon in the title bar of the upper right pane?

The little ⚠️ icon indicates an extension hasn't been configured properly. An *️⃣ indicates there is an update available. A strikethrough indicates the extension is disabled.

(I took the liberty of adding the emojis to your post.) Brilliant idea ... though I wonder if there isn't a better choice for the "update available" icon.

EDIT:

After looking at the screenshot at full magnification, I'm not to sure about the strikethrough. It makes the extension name harder to read at a glance, and you're splitting the extension status information between two locations (the extension name and the icon space to the right).

Would you be averse to adding status information for extensions that are enabled? You could do:

• 🍏 A big green dot for enabled, properly configured extensions. (That apple is a stand-in. 😛 )
• 🔴 A big red dot for disabled extensions. (Maybe change the color of the extension name too?)
• ⚠️ A warning sign for extensions that haven't been properly configured.
• ⬆️ An up arrow to indicate where an update is available.

The problem with this is that the update arrow would replace the green dot, obscuring the status. Maybe it could go to the left of the status indicator? ... Or you could have green and red up arrows, which would indicate both the extension's status and update availability.

Not sure about the "discussion" / "moderation" extension categories. Could be a bit arbitrary?

We could brainstorm about that for a bit ... I do like the idea of a category for moderator/admin utilities, but I get the feeling that there might be a better name for the "Discussions" category.

EDIT: Perhaps you could just call that section "Extensions". After all, you'll need some sort of catchall category for extensions that don't fit under any of the other categories.

Also, what happens to hybrid extensions ... such as an extension adds both moderation functionality and a discussion feature, or a language pack that contains theme info? I guess the author will get to choose which category it goes under?

What does the "Extensions" category in the Permissions section indicate? And "Contributors-only"?

@datitisev Those are tags. Below each are the permissions that apply to that tag. 😉

[datitisev]

@dcsjapan Oh. Facepalm incoming. Thanks for punching me with the obvious 😆 😛

[dcsjapan]

@datitisev No worries ... I also had to stare at those for a few seconds before I realized what they were.

Hmm ... the styling of that "Permissions" heading gives the impression that the section contains some sort of permissions relating to the Taxonomy extension, rather than settings pertaining to the tags. (And the fact that the tags under "Permissions" don't match those defined in the section above isn't helping.)

[dav-is]

permissions relating to the Taxonomy extension, rather than settings pertaining to the tags

Isn't it? Each permission has tag related settings

[tobyzerner]

@dcsjapan Sorry, it's a bad example because of that ambiguity, but @dav-is is correct — only the permissions pertaining to the current extension are displayed. So on the "Likes" extension page, you would only see the "Like posts" permission; the columns would be the same though.

Perhaps you could just call that section "Extensions". After all, you'll need some sort of catchall category for extensions that don't fit under any of the other categories.

Good thinking, let's do that.

Would you be averse to adding status information for extensions that are enabled?

That could work. Maybe green dot for enabled, red dot for disabled, yellow dot for enabled + update available?

[dcsjapan]

Sorry, it's a bad example because of that ambiguity, but @dav-is is correct — only the permissions pertaining to the current extension are displayed.

Oh, I see ... yeah, that makes more sense.

Maybe green dot for enabled, red dot for disabled, yellow dot for enabled + update available?

Would Flarum check for update availability of disabled extensions? If so, then the yellow dot would be ambiguous ... we couldn't see at a glance whether the extension is enabled or not.

[dav-is]

Would Flarum check for update availability of disabled extensions

Why would you want to update an extension if it's not being used?

[dcsjapan]

Why would you want to update an extension if it's not being used?

If it's an extension I disabled because it wasn't working, and I was waiting for that update ...

[tobyzerner]

Revision two:

@dcsjapan good point, we'll work something out

[dcsjapan]

Revision two:

I like this styling (divider lines instead of solid bars) better.

I'm not sure the top stuff needs to be centered, though ... and I kind of miss these things:

(Sorry about the blurred "Documentation" link ... I accidentally smeared it with the water brush.)

[tobyzerner]

I kind of miss these things

They would be accessible via the "..." button next to the extension name

[dav-is]

They would be accessible via the "..." button next to the extension name

Couldn't you just put them next to "beta.6"?

[dcsjapan]

I agree ... there's plenty of room up there, why not make it one less click to get at those links?

[rodymolenaar]

I, for what it's worth, also find the first header a better fit.

[dcsjapan]

@tobscure After comparing your Revision #2 with the admin panel in Kulga's sandbox server, I'm a bit concerned about how those permissions will work.

If you'll be putting Tags-specific permissions in the Tags display, does that mean those settings will not be displayed in the Permissions page? Or will they show up in both places?

In either case, the contents of the Permissions page will be greatly affected by Tags, as that extension adds the ability to set permissions that aren't specific to Tags on a per-tag basis. That fact will be hard to represent in the Tags setting page ... so I don't see the aim of displaying just the few specific permissions added by the extension.

Wouldn't it be best to keep all the permissions together on the Permissions page? That would make it easier for admins to get an accurate overview of how the permissions will interact with each other.

Alternate suggestion:

... Instead of displaying specific permissions at the bottom of an extension's settings page, you could simply present the admin with a list of permissions that are added or affected by the extension. (Also, you could add some information to the Permissions page to let admins know which extension each of the added permissions belongs to.)

[franzliedke]

I do like the new interface proposal as well,

My only concerns:

• This list could get very long, with lots of extensions installed (no matter how small they are). Or do I miss something?
• On the other end of the spectrum, some extensions may not need a tab here.

(Sorry if these things have been discussed already, I have a lot to catch up to.)

[dcsjapan]

This list could get very long, with lots of extensions installed (no matter how small they are). Or do I miss something?

That is a concern. Perhaps the category headings (EXTENSIONS, LANGUAGES, etc.) could have disclosure triangles, so admins wouldn't have to look at the whole list at once?

[dav-is]

disclosure triangles

I'm not a huge fan of those. I don't think anyone really uses them

[dcsjapan]

An accordion menu-style setup, then?

[mkarnicki]

I just read the entire thread. I find this a highly interesting discussion with a lot of great insights, you guys are seriously having a great brainstorm here. It did struck me though the issue was opened Jan 14 and last comment was made on Dec 29. I completely get this is a side/community-supported project, so no expectations here. I was just wondering whether this part is being actively worked on? Correct me if I'm wrong - assigning this to the 0.1.0 milestone means this is scheduled for the first stable version (of which ETA is unknown)? Thanks :)

[tobyzerner]

@mkarnicki Yes we'd like to get this in for stable (even in a preliminary form) as it will involve some API differences from what we currently have. It's not actively being worked on yet though.

@franzliedke This list could get very long, with lots of extensions installed (no matter how small they are). Or do I miss something?

It could, but since they will be sorted alphabetically I don't see it being too much of a problem. The sidebar will be scrollable, obviously. I like @dcsjapan's idea of giving the category headings disclosure triangles. We could also consider having a search box to filter-as-you-type in the future.

On the other end of the spectrum, some extensions may not need a tab here.

Yes, some extensions may have empty settings/permissions, apart from the header (ability to enable/disable the extension, update the extension, and view the extension details).

@dcsjapan If you'll be putting Tags-specific permissions in the Tags display, does that mean those settings will not be displayed in the Permissions page? Or will they show up in both places?

They would show up in both places. I'll have a think about your other ideas here.

[ghost]

@tobscure any more updates on this? This would be awesome!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!