Symphony.

A new extension, “Dashboard” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Nick, thanks for your efforts - this is a huge step forward!

Here are some thoughts on the redirection problem and on the general concept that came up while trying the Dashboard:

• I’m not sure how much I like the idea that the interface to create new panels is integrated in the Dashboard itself. My main concern is that unexperienced users will get confused and mess up things: the less they can do, the better.
• Why not remove the Create Panel button and replace it with a Reorder button that enables panel reordering?
• If panels were not managed inside the Dashboard, they need to be handled somewhere else.
• The only way we know to realise a correct Dashboard redirection is using a section. So why don’t we transform the Dashboard into a “real pseudo” section?

What’s a “real pseudo” section?

• There is a section called Dashboard that will be automatically set as the primary section for all users (and thus be loaded after logging in or browsing to /symphony/).
• This section would be a clean section without fields. The overview page will be replaced with the Dashboard display
• All panel related settings could be handled in a hijacked section editor interface: we could just use the layout and replace the select box with the fields with a select box with the panels.

What do you think?

Re-using the Section editor is a cunning idea and one I had considered. However I was put off for several reasons:

• the section editor is a complex beast, and would involve a lot of code duplication from the content.blueprintssections.php file
• using a lightbox was an experiment for myself more than anything, to see how well it works as a UI concept within Symphony
• I’m not keen on the existing “duplicator” used in the section editor, and using a new solution should make it easier to update Dashboard to Symphony 3 in the future (rather than rewrite elements that rely on core components that have subsequently been removed)

However I do think I’ll integrate your other points:

• there should be a button to toggle drag/drop
• the Create Panel and Edit buttons should only be visible to Developer users (not Authors)
• I’ll make it look for a section named “Dashboard” which can be used as a “hook”. Perhaps the extension should auto-install this section (easily done) with a relatively unique name such as “Dashboard Redirect” or “Dashboard Placeholder” (in case there is already a section named “Dashboard”)

Nick = Legend.

• using a lightbox was an experiment for myself more than anything, to see how well it works as a UI concept within Symphony

I see :) It’s a good reason - but I’m not sure if I’m convinced of this kind of lightbox in the backend context. Lightboxes are great as they offer an extra layer, a special stage on top of everything else, but they often just point out that the actual interface was not capable to handle the given content.

• The section editor is a complex beast, and would involve a lot of code duplication from the content.blueprintssections.php file
• I’m not keen on the existing “duplicator” used in the section editor, and using a new solution should make it easier to update Dashboard to Symphony 3 in the future (rather than rewrite elements that rely on core components that have subsequently been removed)

I see your points here.

I’m currently having some issues with paths (my install is in a subdomain) and a few ideas that I will add to my fork and send you a pull request.

I see :) It’s a good reason - but I’m not sure if I’m convinced of this kind of lightbox in the backend context. Lightboxes are great as they offer an extra layer, a special stage on top of everything else, but they often just point out that the actual interface was not capable to handle the given content.

I second Nils in that.

Lightboxes are great as they offer an extra layer, a special stage on top of everything else, but they often just point out that the actual interface was not capable to handle the given content.

It’s not always the case, however I agree that in this context using a “classic” page would be a more coherent solution.

Very awesome work, Nick!

Without wanting to get into the debate here… I’d much rather use a lightbox than a cumbersome duplicator UI. And as a developer I’d much rather use a lightbox than implement a cumbersome custom UI. I’m a lazy developer — I’ll take a shortcut if I can.

however I agree that in this context using a “classic” page would be a more coherent solution.

Can you explain why? In addition to my rationale above I’d suggest that a lightbox works well in this situation because:

• you don’t lose context of where you are. The Dashboard is perceived as a “flat” thing (a one-page summary) so to me it makes sense to have a “flat” editing hierarchy, not something you drill into to make edits. The panels are re-ordered with drag/drop in-situ, so it makes sense for them to be edited in-situ. I was tempted by a “flip” effect so the panel flips over to reveal configuration options (like Dashboard widgets in OSX) however a lightbox is the more appropriate web equivalent
• the configuration of a panel involves minimum of two and maximum of four or five form widgets (input, select). These fit nicely into a lightbox and aren’t sufficient to warrant an entirely new page for editing them

To be more constructive (kind of) …
What about prepending or appending the Dashboard Panel Editor to the Dashboard? Same technique, but loading the Editor into the page itself and not into a new layer/lightbox.

you don’t lose context of where you are. The Dashboard is perceived as a “flat” thing (a one-page summary) so to me it makes sense to have a “flat” editing hierarchy, not something you drill into to make edits. The panels are re-ordered with drag/drop in-situ, so it makes sense for them to be edited in-situ. I was tempted by a “flip” effect so the panel flips over to reveal configuration options (like Dashboard widgets in OSX) however a lightbox is the more appropriate web equivalent

Yes, but then every section page in the backend should follow the same rules. Say you have a list of Articles in the Articles page. Re-ordering works in-situ, while editing or adding new entries takes the user to a new page. Given that you don’t know how many fields an entry is made of, you can’t make any assumptions on whether to use a modal window or a static page.

I think the same applies for the Dashboard. In fact, if new extensions subscribe to the Dashboard delegates, it might happen that new panel types require more additional space. In that case, a modal window with a scrollbar is not a good choice as it makes the experience of editing/creating panels a bit annoying.

As a sidenote: I can’t manage to add panels to the dashboard. Every time I click to the “Create Panel” button a “Error 404” message is displayed. Am I missing something?

Every time I click to the “Create Panel” button a “Error 404” message is displayed.

Hrmm that’s odd. The JavaScript isn’t particularly forgiving right now, so if you have Symphony installed in a sub-directory it won’t work (i.e. it’s currently using an absolute path to /symphony/...). That might be it.

In fact, if new extensions subscribe to the Dashboard delegates, it might happen that new panel types require more additional space

We could just make the lightbox bigger. Or demand the user buys a bigger screen?

(But seriously, yes, fair point well made.)

It’s good to break out of the “Symphony way” every so often — not everything fits nicely into the master/detail paradigm.

I was thinking about something like an inline display:

(this is a really, really rough sketch)

if you have Symphony installed in a sub-directory it won’t work (i.e. it’s currently using an absolute path to /symphony/…). That might be it.

Ah yes, that was it! Thank you for the quick reply, now it works :)

As an example, this is what I get on Chromium (Linux, 1280x1024) while creating a RSS Feed Reader panel:

While things like this can be easily fixed with minimum efforts, image what would happen if the Save button was totally hidden. I’d be frustrating to scroll down every time I need to create/save that type of panel.

It’s good to break out of the “Symphony way” every so often — not everything fits nicely into the master/detail paradigm.

I agree. I love using modal windows, but I also think that there are very few pratical applications for them.

I was thinking about something like an inline display

Yeah that could work. The only non-trivial part would be getting the HTML, since the HTML is built at runtime when editing each panel (PHP inserts values and selects options etc.) but this could be done via an AJAX request that returns the built HTML, and then the form opens up.

As your sketch shows though, you run into the usual Symphony problem of flexible width layouts where input fields that should be narrow, grow very wide. Perhaps a few max-width rules wouldn’t go amiss.

So I managed to get around the path issues for installs in subdomains but there are a few strange things happening:

• Adding panels does not work when a page is in maintenance.
• Adding an HTML panel open the RSS panel.
• Adding a Data Source to Table panel crashes the site.

Adding panels does not work when a page is in maintenance.

I can add panels when the site is in maintenance mode, but the maintenance mode alert is shown inside the lightbox (bug). If you’re using a Symphony page in an RSS/HTML panel URL and the site is in maintenance then presently it doesn’t pass the Symphony authentication details along with the request. The same bug was in the HTML Panel field until I added code to pass the PHPSESSID along with the request.

Adding an HTML panel open the RSS panel.

I can’t recreate this, the correct panels appear on my version. The two configs are similar looking.

Adding a Data Source to Table panel crashes the site.

Oh dear. Any errors?