Search

Here's a fresh take on a new admin interface, using a much flatter style:

alt text

Let me know if there is any interest and I can try to throw a repository together on Github.

Pretty cool, like this.

Great!!

I setup a basic repository with LESS, Grunt, as well as the CSS files with instructions. Feel free to fork, update, improve and spread the word!

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

Awesome!

Grunt

Perfect... :)

Quoting from the Symphony 2.4 thread as I found this topic on Jonathan’s admin theme.

Here are some screens:

Entry Table: http://cl.ly/image/2F3d2S302Y2y

Entry View: http://cl.ly/image/2Z3L0145172T

Entry Footer: http://cl.ly/image/2637111g2o1k

Debug: http://cl.ly/image/1P0d2m2v221L

My Github repo has the LESS files used to create the override. If we go this route, we could clean up core and use Grunt with LESS or SASS to create a single minified admin stylesheet used for the bulk of the modules, adding in separate files (for login, debug, etc.) where appropriate.

Nice. I like the not-so-small text size (I've been meaning to do myself a simple CSS override for this for a while), and the flatter look seems to be more in line with Symphony Factory.

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.

Sorry guys, can't understand how am I supposed to use these files. I renamed the provided css files from admin_css_override.css to admin.css and overwritten over the default admin.css file, but I see no changes.

Thanks for any hint

I agree with @jdsimcoe

I've fiddled with CSS overrides for the backend before, and never found a flat alternative to be more usable - and that's one of the main reasons I like giving my clients Symphony :)

What I'd really like to see (and something I'll be doing myself at some point soon) is a more contemporary approach for the form elements. The fields are too constricted with slightly too much contrast, I think it negatively effects the flow of the entry pages. But we're mostly just talking about a little extra padding here and there.

Options like 'Toggle switch' for the checkbox would go a long way to improving the UX of the backend as well (quite often I find checkboxes look a bit dumped in). Just some little touches to enhance the form elements really, as that's mostly what you're working with as an end-user.

We minimise and concatenate CSS now, so just replacing the CSS isn't enough. You need to re-run grunt to affect change.

Ok I placed the Symphony-Admin/ folder within the extensions/, run grunt which generated two files_override.css. I suppose I should place those within the symphony/assets/ folder?

Manaus: install admin-css-override and overwrite the CSS file bundled in that extension with the compiled files in my repo.

@jdsimcoe Did it, lovely!! Thanks

So @Nils and @nathanhornsby. What is Symphony Core Team's end goal with a redesign? I have a paid client that wants a better responsive admin theme for editing on mobile. I have found that with Editor for Symphony enabled it seriously messes up viewing, scrolling and editing on iOS devices, particularly.

That being said, I am not precious about going Flat Design merely for the sake of have a "Flat Design". I really want to get something that looks fresh, represents the Symphony brand, but more importantly improves the functionality of navigation on desktop and mobile.

Having used Craft CMS on a recent project I really enjoy the streamlined feel of their admin panel, removing lots of the borders between navigation sections and really simplifying things. They do add depth via subtle drop shadows, but it all looks very tightly integrated:

Craft CMS Admin Panel

Obviously I don't want to create something that just looks like Craft, but it stood as a good example of clear design that seems to hold up well in the context of backend editing.

I have also found in my testing with ProcessWire that they have a similar backend experience to Craft that really works well:

ProcessWire Admin

I guess I wanted to reach out to everyone before I invest a lot of work into something custom to see if this work is something that could be paired with the Core admin interface to give a better experience for the whole community.

What are your guys' thoughts and concerns? I know lots of people have opinions here and I really want to make this better and give it back to the whole community.

This page has some better examples of the new ProcessWire admin panel in works. It has some nice variations and ideas to glean from.

Just my 2 cents here, as we customise for clients.

If there is to be a redesign, then from a 'make it easy to customise' perspective, we need to use Sass moving forward.

I know some personal opinions are against it, but to make colours, fonts, sizes, line-heights etc easy to modify, then it has to be done.

We have a frontend kit here at work that I put together on top of Bourbon, Neat and Bitters (all at http://bourbon.io) and it has made making frontend builds very very fast.

We're already part way there with such broken out css files, so why not take the leap and just do it?

It's also my opinion, that the shipped version should remain as greybox as it is now. But, with the addition of easy to customise variables in Sass, a developer can colour it as they see fit for specific client builds.

If there is to be a redesign, then from a 'make it easy to customise' perspective, we need to use Sass moving forward. - @designermonkey

I agree, although I use LESS. My front-end developer uses SASS though… so I appreciate it's probably a better option :p

I think the responsive aspect is the most important - we haven't built a non-responsive site in… 3 years? And although backend management doesn't always come with an 'on the go' requirement, it's unfortunate to have that aspect of the site remain as fixed-width. The good news is that nothing about it really provides any issues for a responsive approach. Some of the tables will have to remain scrollable, but almost everything else would naturally collapse quite well. It's just grunt-work, little problem solving.

Although I like your examples @jdsimcoe - I actually preferred the more subtle changes you were poking at on Github - along with some subtle form improvements and a responsive grid I think that'd do the job (IMO). I actually like how neutral Symphony is, and the way it's structured, so I'd like that to persist (again, IMO).

Some of it will be familiarity though of course… or stockholm syndrome… maybe a bit of both :p

But my personal intrests are:

  • Responsive
  • Slightly prettier form elements

@designermonkey:

If there is to be a redesign, then from a 'make it easy to customise' perspective, we need to use Sass moving forward.

I whole-heartedly agree.

We have a frontend kit here at work that I put together on top of Bourbon, Neat and Bitters (all at http://bourbon.io) and it has made making frontend builds very very fast.

I've done the same and built a Gulp setup that makes building and LiveReloading lightning fast.

It's also my opinion, that the shipped version should remain as greybox as it is now. But, with the addition of easy to customise variables in Sass, a developer can colour it as they see fit for specific client builds.

I agree again here. I think @nathanhornsby has the same thought and I like that direction of making it customizable easily with color variables in Sass.

@nathanhornsby:

Although I like your examples @jdsimcoe - I actually preferred the more subtle changes you were poking at on Github - along with some subtle form improvements and a responsive grid I think that'd do the job (IMO). I actually like how neutral Symphony is, and the way it's structured, so I'd like that to persist (again, IMO).

I agree with this sentiment. My thought here is to really do nothing client-specific. Although it will ultimately be for a client, my goals are to get the front-end to a better place for all and then to make it even easier for a developer to plug into the Gulp setup and do a rebuild of the front-end after tweaking some variables.

If you hand me your form element updates I will begin porting the CSS files into Sass and setting up a much better build system that will enable the Core team or whoever to make much better incremental updates.

Is the best way for me to go about this to fork the Symphony/integration repo/branch and offer my work as a pull request?

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