ExpressionEngine certainly gets custom fields and channels right. That makes clients happy. But sometimes your client deserves a little more spit shine on your delivered product. Here, we’ll go over some ways you can provide a streamlined process for the client, and leave them with a gorgeous backend!
I can’t stress this one enough. 99% of your clients will love the much more modern layout and structure that a default ExpressionEngine 2.x install will bring. They will love it and thank you for it. Still… there is the problem of either the fact that it’s "so pink" — a problem I’ve never heard, myself — or perhaps the rounded edges just make it seem like such a structural departure from the 1.x flavor of EE that they just can't get past it. In any case, there's a solution, and it’s beyond easy to implement.
EllisLab recently stepped up their game by introducing a way for us to tweak the interface by means of an “override.css” file. Dropping a new CSS file of that very name into
/themes/cp_themes/default/ folder is all it takes. There's quite a few free versions out there — most notably Brian Litzinger's Nerdery Theme, Kyle Cotter's Sassy CP, and a few others — that will do the trick.
For my money though, Leevi Graham’s NSM Override.css file is the gold standard. The corporate-friendly edges and colors make ExpressionEngine's interface honestly feel like a natural progression in its visual appearance, instead of just a custom skin. Clients always love the look, and the $10 to purchase it is easily budgeted in each project.
With the advent of ExpressionEngine 2.x, we saw EllisLab incorporate a feature that I personally believe is responsible for EE’s widespread growth: Fieldtype APIs. Originally released for ExpressionEngine 1.x as FieldFrame by Brandon Kelly of Pixel & Tonic, the creative ways that have been discovered to manipulate and store data in our entries has caused ExpressionEngine to take huge leaps and bounds in terms of what is and isn‘t possible when we are dealing with our clients. Date pickers, drag and drop relationships and matrices of data are all possible thanks to the fantastic work of Brandon.
There was a rather large problem with the initial ExpressionEngine 2.x offering, however. It's radio buttons, checkboxes and other similar fieldtypes could not work with Brandon's excellent Matrix fieldtype. He rectified this by making the P&T Field Pack. This is a no-brainer. Whether or not you have Matrix implemented on your client's site, replace the corresponding default fields with the Field Pack's. If you need to install Matrix at a later point, you'll have saved yourself the hassle of changing your settings down the road.
The rest of the Dive Bar field types are sure to delight your client. P&T Switch is a fantastic binary system replacement for a regular On/Off radio group or checkbox. P&T Pill is a great way to allow your customer to avoid an extra step from using a standard select dropdown, especially if they only need two to three options. Finally, P&T List solves a rather old issue of mine, namely that of what to do when you need the multiple rows of data that Matrix provides, but only when in text form, and with no additional columns. The ability to create unordered or ordered lists on the fly for the client is a real blessing.
I see ExpressionEngine get a lot of guff on Twitter and other networks for the much-maligned Custom Publish Layout feature. While it has its own quirks — trying to make fields 50% of the width of the page usually results in me tearing out what's left of my hair — I find that clients will love you for extra time you spend tweaking their layouts for efficiency and cleanliness.
My first rule of thumb is to pare down the total number of tabs. Unless absolutely necessary, I try to have no more than 3 tabs, 4 if we’re keeping post revisions (which in general is a good idea). I do away with the Date tab, and move that information over to the Options tab. Same thing goes for the Categories tab, and I will often move the url_title field to the Options tab just so I don’t have to field another phone call from the client being concerned with why they can’t put spaces in that second field!
In general, if it’s an “optional” dataset that is not a custom field, I’ll place the dataset under the Options tab, unless a set of fields or datasets need to be separated and have attention called to them. Once again, this comes down to reducing the number of clicks a user has to go through on a regular basis.
I get that sometimes doing Custom Publish Layouts can be a pain. They're definitely not my favorite thing in the world to set up, but as designers and developers, we owe it to our clients to ensure that we are the ones that are burdened by this process, not them. We should make the whole thing feel like magic to them.
Of course, I've only begun to scratch the surface of what you can do for your clients in order to make their experience a fun and easy one. I know there are other addons out there that I haven't covered, notably EE Zoo's Flexible Admin, which allows you to create custom admin setups on a per member group basis. This is definitely worth looking into, and I know I'll be looking to add it and experiment with it in my next project.
What about you? I'm interested to find out what you like to do to customize your client's experience. Do you charge for the privelege, or do you consider that to be part of your regular setup? Sound off in the comments!
Christopher’s a kickass guy in San Francisco. He loves design, ExpressionEngine®, Craft, semantics, photography, cute things, & gaming, but not always at the same time.