Search

I love the Symphony backend. But as I've been using it over the years, some things have come to frustrate me. So a while back I started work on a re-design.

I've been hesitant to bring up a lot of these things before as I either didn't think they were possible or I hadn't taken the time to think them through and articulate them enough.

While still feeling pretty inarticulate, I figured now is as good a time as any to share. So here is a recent, semi-functional initial version; a proof-of-concept only:

http://neithercorp.com/public/symui1/

The code is kinda ugly and doesn't use many current Symphony standards, but I hope it can add something to the on-going UI discussion and any feedback from the community would be invaluable.

Briefly, three main things have prompted this:

  • The disconnect between defining a section and organising its form fields (aka 'designing its UI')

  • Adding functionality (buttons etc) to a field quickly makes the publish page become cluttered and visually confusing.

  • Working with Pages and Data Sources seems unnecessarily complex; they needn't be separated.

There are many other tiny tweaks I've dreamt up over time, some of which are included here, many of which are not.

More detailed explanation following this for those who are interested.

Attachments:
symui1-screen.png

Here is a list of the main changes made in this initial mockup, numbered only for reference purposes, not in order of importance. From the most obvious:

  1. Slightly tweaked aesthetic
    The colour change of the header and menu are just my own personal preferences. The field design on the other hand…

  2. Fields have title bars
    This sprang from the above practical requirement: to extend the available functionality of the fields while maintaining clarity and definition of each distinct field. The primary result of this is a title bar on each field. Also…

  3. 3 new components per field: Title, bottom, help
    The right area of the title bar is reserved for buttons to extend functionality. Optional bottom bar and help tray allow for more useful things to be added without breaking the design. Not required but there if they're needed.

  4. Visual field grouping
    You can still just use one big group if you prefer, but here we have the option to group fields into visually distinct blocks with subtle dividers using <fieldset>.

  5. Notifications in header
    A small niggle of mine; the whole page is no longer moved 23px down, displacing buttons etc only to show a system message. These appear in the ample space beside the site title.

  6. Menu dropdown icons
    A tiny change which can currently be achieved by using the Don't Drop extension but I feel is so small and obvious that it ought to be in the core.

  7. 'Required' not 'optional'
    Another small change. Although I'm aware of the idea that 'optional' is less scary for end users, I think the usability and space gains from switching to the 'asterisk means required' model outweigh that advantage.

  8. 'Save Changes' at top
    A small usability improvement so end users can commit changes made to upper fields without needing to scroll down.

  9. Extra section functionality buttons
    Similar to the idea of providing areas for optional functionality in fields, but here applied to the section itself. Only included at bottom of page as these (are intended to) be for rarely-used functions.

  10. Contextual field placement & section editing
    Finally, possibly the most fundamental, backwards-compatibility-breaking change to solve the problem of section definition being separated from viewing the section publish page.
    An 'Edit Section' mode toggle at the top for administrators to perform contextual editing of fields as well as the section itself. 'Lock', 'Layout' and 'Settings' options. 'Layout' mode exposes drag handles allowing for easy rearranging. 'Settings' mode was intended to expose a fixed panel where both section and per-field settings are displayed (much like the current section editor) in a non-scrolling area so as to be visible anywhere on the page.

That last point has been giving me a bit of a headache when working through how it's best implemented. Currently the whole page slides over, though now I'm thinking this might be best contained below the header and navigation. But then this will require some js scroll testing to keep it fixed.

Also, it could better delineate between editing settings for the whole section and those of individual fields. I've been toying with the idea of scrapping this fixed side panel and having a tray animate open for section settings, splitting the line between the entry title area and the first fields, much like the dashboard extension does.
Then perhaps having settings for each field contained within themselves which can be exposed via a button where the drag handle is currently in 'Layout' mode.

Finally, being able to control columns on a per-fieldset basis is something I'd love but am not quite sure how to implement, especially with drag-and-drop. This could include a full-width group as well as the current 70-30 split option for each fieldset. Then also a separate 'sub' group to allow two fields to occupy the same line. Perhaps overkill but I have had cases myself where I would've loved to have had this option.

Phew. Thank you if you made it this far. Please have at it, I'm keen to hear people's thoughts.

Wow, great job.

Slightly tweaked aesthetic

The gradients and shadows could feel a little outdated very soon given the current 'flat design' trend.

Personally I'm not sure about it. I really like the modern look of this current trend aesthetically (if done right, which is difficult), but I also think usability is generally better when ui elements are a little more emphasized like in your draft.

I guess what we currently have (aesthetically) is a good compromise.

Fields have title bars 3 new components per field: Title, bottom, help

I really like the idea of having a cleaner and more consistent layout for different field types.

Visual field grouping

Another great point. We currently have extensions to group fields in tabs, but what if a project has more complex needs (like using tabs for grouping fields by language in a multilingual project)?

This really looks like a good solution to me. I guess it could even be implemented as an extension for proof of concept.

Notifications in header

Not sure if this is really a good solution, but I also find the current notifications a bit annoying sometimes.

Menu dropdown icons

Yes, please.

'Required' not 'optional'

Switching from optional to required is a good idea, but an asterisk might not be enough to clearly communicate this.

'Save Changes' at top

Yes, please.

Extra section functionality buttons Contextual field placement & section editing

Not sure about this. Could be useful for site admins, but also adds a lot of extra complexity to the edit screen for the core developers. And I imagine it would be really hard to get these things right, from a ui point of view.

There is definitely a lot to like about this. The in context moving of fields is a great idea, editing a section in this view could be a little tricky, but with the responsive nature of the section editor it's definitely not impossible.

I agree the gradients seem a step backward from the direction we'd like to head, but I do like the in contextual help.

Agree with the required/optional. I missed it until I read Jen's post.

Full width field is a neat idea, would create some interesting flows if you had other fields after it but at the end of the day that's the developers discretion if they want to do that.

Nice job overall. Thanks!

A lot of good ideas there!

I think the flat/not-flat aspect is still very much up for debate - you guys had any long discussions with average users, i.e. end-users about flat design? They don't tend to like it, often attaching adjectives like 'unfinished', 'lacking design' etc. - and stay well clear of any user commentary on Metro - you'll never want to draw an un-bevelled rectangle again. Don't get me wrong I love flat design, but I'm leaving the jury out for at least another 12 months before I accept it as a progression rather than a passing fad - as currently it's a designers aesthetic that most clients are only willing to go along with. I suppose the point to all that is that I wouldn't be too keen to latch on to a trend. What's been presented here (and what's present in the current Symphony UI) is arguably 'not-contemporary', but I think it's likely to appear more neutral (in taste) than a truly flat UI.

Leaving that to one side :)

I think the actual UI stuff here is very interesting though - I've mentioned a few times in the past that I really liked 'Fork CMS's' approach to backend design because it allows you to create an analogue of the front-end. To some extent I do that with Symphony, but a few extra bits I normally add with extensions would make the world of difference to the default build. The ability to separate and group fields could do with a little improvement, and I think this goes some way to addressing that. I use the content tabs extension a lot, but tabs have never felt the best way to handle things, I have a feeling that an accordion would work well with you design as a way to group and simplify the presentation (which can become very form-input heavy).

I also agree that working with 'components' can be a pain, at times. Certain workflows really bring the limitations to light and the back-and-forth can be tiring. I'm not sure I'm in a position to suggest improvements in that area as there are so many things to consider, but I definitely agree that it needs considering.

Anyway some good ideas!

I like the thought behind this!

Have a look at a thread going here about an admin theme I'm working on:

http://www.getsymphony.com/discuss/thread/102689/1/#position-8

It would be great to join up efforts to get this merged into Symphony core. I would like to see streamlining of backend assets, like single, minified CSS file and single, minified JS. Also, something done tackling responsive would be awesome.

What do you think?

Here is my latest comment here about flat/skeuo:

Thanks for the link. I think doing Flat for the sake of Flat is dumb... it needs to make sense for the environment. I'm not opposed to there being some depth to the interface, but honestly flat design is really just a re-iteration of classic Swiss fundamentals with clean, modern typefaces, bold color choices and allowing content to be king.

Thanks for all the feedback, people!

Firstly, on the topic of flat vs non-flat. I'm not too bothered honestly. Providing aesthetic considerations do not interfere with the usability of the backend.

Though I prefer an ultra-simplified (hence often flat) aesthetic in the frontend design I do, I'm not entirely convinced of its usefulness in a backend design.

My goal for developing this redesign was not primarily the visual side of things, more the functional aspect, though these two naturally overlap. So while things like rounded corners can be added or removed without changing the usability of the design at all, some other elements like gradients or (subtle) shadows can often add to visual clarity.

Ideally, it should be left up to the individual developer, with sensible defaults used in the core. As @brockpetrie recently mentioned here, an easily customizable and extendable design would be great. This is where the current Symphony backend is lacking and what the html structure of this design (in part) attempts to address.

Thinking along the lines of Bootstrap, it'd be great to have an extended set of pre-defined, visually consistent page and field elements which provide 'hooks' that developers can optionally use. So an extension developer can add extra buttons to their field or an admin developer can define a field with a customized help modal all without messing up the backend page.

Extending functionality while improving visual consistency. Sensible visual defaults which are easy to override and customize.

I would like to see streamlining of backend assets, like single, minified CSS file and single, minified JS. Also, something done tackling responsive would be awesome.

Already doing this with Grunt for the 2.4 beta...

Already doing this with Grunt for the 2.4 beta...

Nice, this is awesome! What are your thoughts around loading Javascript as a minified file from the footer? That seems to be a common way to speed page load times. Lots of sites recommend that. I created a Gruntfile yesterday in a client project to minify CSS and JS and it made the back-end way more responsive, with way less HTTP calls, even when loading JS from the <head>.

Also I'm porting my Symphony-FlatAdminTheme to Sass and trying to condense down the UI into a more uniform look that includes some responsive functionality. I've renamed it Symphony-AdminTheme and will be committing hopefully soon.

What are your thoughts around loading Javascript as a minified file from the footer? That seems to be a common way to speed page load times. Lots of sites recommend that.

Indeed, that's usually the way to go. But not sure if it's possible for the backend right now. We'll look into that for future releases.

Cool. Here is my new repo:

https://github.com/jsimcoe/Symphony-AdminTheme

Taking cues from the Symphony 2.4 thread I want to try to align my efforts at not just skinning the back-end but trying to re-think the UI and the way it is approached to improve usability.

Can you make some screenshots for the repo?

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details