Revamp admin interface #746
Comments
|
👍 |
|
Perhaps extensions of the "themes" category should be shown on the Appearance page? |
|
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. |
|
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.
Thoughts? |
|
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 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! 👍 |
|
Very cool! What I like the most is the consistency across all these features / categories. That said, there are some comments to be made:
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... |
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.
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. |
|
The mockups look amazing! |
That might be a good way around the problem! Incidentally ...
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!) |
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. |
|
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? |
|
A couple more thoughts I thought I'd throw in here:
That's a couple more points in favor of the tabbed pages approach. That said, I'm intrigued by the idea that Franz posted:
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. |
|
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: Add some fancy animation and nice visuals, and this is ready ;) |
Yes, animating the opening of the settings panel really makes it work. 😄 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. |
|
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? |
|
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. |
|
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.
... 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
changed the title
Closes #268. Not going to bother with a preview SVG or anything fancy for now – we can think about that as part of #746. Right now it's just good to finally get this functionality in! Also need to think about apple-touch-icon, msTile stuff, and social sharing image. Not sure if this is all too much for core, but it's definitely too much for the current Appearance page layout. Again, something to think about as part of #746. Code is a bit rough around the edges, but figured there's not much point in using the command bus properly since #870.
|
New concept:
|
|
@tobscure What does the "Extensions" category in the Permissions section indicate? And "Contributors-only"? And now I'll have to update AdminDashboard again... 🙄 😛 |
|
@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.
Good thinking, let's do that.
That could work. Maybe green dot for enabled, red dot for disabled, yellow dot for enabled + update available? |
Oh, I see ... yeah, that makes more sense.
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. |
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 ... |
|
Revision two:
@dcsjapan good point, we'll work something out |
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.) |
They would be accessible via the "..." button next to the extension name |
Couldn't you just put them next to "beta.6"? |
|
I agree ... there's plenty of room up there, why not make it one less click to get at those links? |
|
I, for what it's worth, also find the first header a better fit. |
|
@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.) |
|
I do like the new interface proposal as well, My only concerns:
(Sorry if these things have been discussed already, I have a lot to catch up to.) |
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? |
I'm not a huge fan of those. I don't think anyone really uses them |
|
An accordion menu-style setup, then? |
|
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 :) |
|
@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.
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.
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).
They would show up in both places. I'll have a think about your other ideas here. |
|
@tobscure any more updates on this? This would be awesome! |
|
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. |
_1 Upvote_ The Extensions page should be divided into categories so extensions will be easier to locate.
Possible categories to add:
The Extension page will need to use composer.json tag info to determine which category an installed extension should be displayed under.
The text was updated successfully, but these errors were encountered: