I could completely be in the minority in what I’m about to say, but when I see phrases such as “The WordPress Admin,” I cringe a little.
Maybe I’m being a bit legalistic, but hear me out: All throughout the backend of WordPress, we see the phrase “Dashboard.” In fact, it’s the first menu item that we see.
Using The WordPress Admin
The thing is, when it comes to developing some type of common language that we use with our clients, I think it’s important to making sure that we’re be consistent with ourselves.
By that, I mean we should not be interchanging the words that we’re using – we should be consistent with the software and the terminology that it uses throughout.
The WordPress Dashboard
Otherwise, I think we run the risk of confusing the user and thus doing more damage than good when actually helping them.
As I said, perhaps I’m in the minority when it comes to thinking about these types of things – this doesn’t mean I’m going to change – but I think it’s worth food for thought, and that it’s worth maybe thinking about the next time you’re writing a blog post, some documentation, or having a conversation with someone for whom you’re working.
A Common Language
Ultimately, our goal should be able to make sure that we’re not only transitioning our users as smoothly as possibly, but introducing them into our own work as easily as possible without any surprises (which is yet another reason I’m such a fan of using things like the Settings API and the Theme Customizer versus custom dashboards).
But all of this is how I work and it’s ultimately my opinion. Curious on yours, so feel free to offer your input in the comments below.
Seriously – I’m interested in the whys and why nots of this.
I usually say Dashboard like you suggest, though I admit to slipping up sometimes and saying “admin” instead. I catch myself typing “admin” sometimes and correct it. Sometimes I miss it.
My angle is I try to speak with customers in a language that sounds less technical and more user friendly, and jives up with what they see in the software. So yeah, common language for the win.
Same here. This is actually a recent change that I’ve begun to make in my discussions and in my writing so, you know, old habits and all that.
Exactly :).
Isn’t the dashboard only the landing page ?
We’re in the “wp-admin” directory after all, admin makes sense for me. But I join you in the consistency part, it’s very important for the users
I was actually going to say the same thing; I thought the “Dashboard” was just the landing page and entirety is the “WordPress Admin Area/Interface/Whatever”.
I also thought this, although I would love a different phrase than “the WordPress Admin.”
The Codex (not great on this as a rule) calls it “your WordPress Administration Screen (Dashboard),” as well as the “Administration Screen.”
On point.
That certainly clears it up for us :).
Yeah – I mean, I’m not one to be afraid to admit that I’m completely off on this. It’s just that when working with clients and when documenting various things, this is what I’ve found to be most useful.
“Backend” seems to be another contender, too.
Definitely food for thought (at least for me).
“Backend” enters the conversion for me occasionally as well… but more often I find myself referring to the /wp-admin/ directory as “Your login area” when trying to guide a client to a certain section/function.
Nearly everyone has a login to something — bills, Gmail, Facebook, etc. — so that seems to be the most ubiquitous term I have found to date… your experience may vary, but that seems to work out the best for the most people involved. :)
I too am a bit confused on this. Its not immediately clear that the entire Administrative / Editorial interface is the “Dashboard” (Although I see plenty of documentation referring to it using that term) from the menu and titles, it could also just be the name of the first page with widgets and stats.
I also feel that its more analogous to a “Dashboard” after all, you look at your dashboard in the car for status, not to actually drive the car.
I agree, that the confusion is caused by inconsistency among ourselves, the WordPress community.
Agreed as has been pointed out by many of the comments here (which I’m glad people have taken time to share their opinion!).
I agree with this (which I’ve mentioned in an earlier response, as well).
Initially, I think so; however, I when I talk to other clients about navigating the backend, I rarely if ever say “Navigate to the wp-admin Posts page.”
Instead, I say “navigate to the Posts dashboard page.”
Nine times out of 10, the second one clicks. If I say something like “Use the admin page,” some aren’t even sure what admin is short for (I know, I know). Plus, it’s overloaded with the role ‘admin’ that we, as developers, as used to using.
Yes – whatever is being done, at least be consistent throughout the project and your communication.
I always have (and always will) refer to the WordPress Dashboard as “The Dashboard” – I find it weird to call it “The Admin” because it clearly says ‘Dashboard’ right there on the page. I also find it less confusing for non-techie people – ‘dashboard’ is, generally speaking, a more familiar term for most people for this kind of thing.
I find this kind of thing super important to get right and keep consistent – nice to see I’m not the only one :)
I haven’t always (as you can see from other comments), but it’s something that I’ve begun to adopt because it’s more user-friendly and I think it maps more to the user’s conceptual model.
At least that’s been my experience thus far. Things could always change.
Yeah, that’s always a nice feeling ;).
I’m guilty of this. I change what I call it based on who i’m talking to. I find that if I say WordPress Dashboard that the user could get confused in all sorts of ways. I’ve seen that word get confused with their WordPress.com dashboard or even appearance > widgets (some sort of os x leftovers). Often times it gets me close to where I want them to be: they’ll think I mean that actual Dashboard screen in their wp-admin but if I then say ok, go ahead and create a new post they’ll start make a quick draft. But.. it’s a start.
I usually end up saying WordPress Administrative Dashboard or WordPress Backend. That usually gets me there. But ultimately, yes, its’ a mess.
Same here. I also “code switch” and use different WP vocabularies depending who I am talking to. But I also try to help new users understand them all. Dashboard, Admin Menu, Admin Toolbar, and “Backend” (or is it “back end?”) take a little getting used to. Taxonomy and “post types” or “content types” are especially tough.
One thing that really seems to help new users is if you’re able to include them in a project in hands-on ways that passively teach these terms and concepts. For example, you can walk people through a content model to plan a project’s technical implementation and also its implications for editorial workflow. And you might discuss how to modify the Admin interface to best suit that workflow.
Yeah – I mean it really does depend on the audience to which you’re talking. I mean something like ‘non-hierarchical taxonomy’ is clear to one group of people but to another? No way.
And this is true across all industries. We all have are jargon – we just need to use it appropriately.
Aren’t we all? :)
I think it’s interesting that people will begin making a “Quick Draft.” I mean, it makes complete sense given that they’re on the literal Dashboard menu item and that widget is there; however, I also know a lot of people who turn that stuff off upon installation in order to mitigate clutter and make the ‘Posts’ menu option the only way to access the ability to create a post.
Yeah, I think those are good terms.
My clients are all casual users, beginners and bloggers. And whether I’m training one-on-one, or in a workshop, to new or old clients, it’s always been the dashboard. It’s what they most relate to. On occasion I throw in backend. The only time I mention “admin” is if they are using that cursed word for their username ;)
I was hoping you’d chime in, Bob, because I know that you have a different client base than those whom I work with and I was interested to hear what you had to offer.
So thanks for sharing this :).
I’m willing, but still have trouble finding clear phrasing for the location of things. If you say “Under Settings / Acme Plugin in the Dashboard”, is the fact that there is a Settings and a Dashboard section problematic?
I would say yes there is.
I have taken to re-arranging the Admin Menu to my own standard system which then gets modified to the task and role based needs of the end users. One thing I routinely do now is make nearly all “settings” links the concern of only a superadmin role, and I move them under the menu item they actually belong to. Some plugins already do this, others throw their settings under “Settings,” and some use “Tools.”
Sorry Dylan, I wasn’t too clear in my response. I think you are totally correct, it IS a problem that “Settings” are somewhat buried and lumped all together. Add many plugins and you’re have settings in a lot of different places and/or a very bloated Settings submenu. Who hasn’t installed a new plugin and then immediately thought — “oh crap, where is its settings panel, if it even has one?” So you look down the plugin list and maybe it has a settings link there or maybe it doesn’t.
And to derail this train a little bit – can someone please explain why the menu items in Settings are now alphabetized in this day and age? There must be some history there…..?
I think I’m missing something. Either we’re talking about a different Settings menu or we’re using different versions of WordPress….
:)
Right, so we have TWO issues: there’s not a way to find out where a plugin has put things, and not a standard way to describe those locations.
I think if plugins follow WordPress’s lead for where to place functionality in the menus, things stay fairly consistent. But it would be cool if you could see all the back end items a plugin has added. Hmm, I wonder if a plugin could do that?
As far as the term Dashboard goes, I think I just restated the issue that it is ambiguous whether it means the entire back end or just the section labeled Dashboard.
There are the WordPress Pointers (if I’m remembering the terminology correctly), but this is something that developers are actually discouraged from using, I think.
Still, some more complex plugins still use them, but I think it’d be a big pain to sit and have to work through them every time a new plugin is installed or activated.
Think about how many dialogs we dismiss during, say, an installation procedure just to get an app installed.
Yeah – based on the comments, there seems to be a bit of ambiguity around all of this. If nothing else, it makes for a fun discussion.
Not only that, some plugins will add their submenu option to ‘Settings’ where some add them to ‘Tools’ where others add them to their own top-level menu item.
This is something that I wish was a little more standard; however, I also know that larger, more complex plugins wouldn’t work as submenus, either so I know it’s not an easy problem to solve.
Maybe it’s best left to the admin user to decide.
Sometimes I “promote” or “demote” plugins in the Admin menu when I disagree with their default position. Usually it’s a demotion, but Postmatic gets a promotion. :-)
Do you mean the Dashboard user or…sorry. Bad joke. ;)
I do agree with you, though.
I use “Dashboard” mostly but with some clients, “The Admin Dashboard.” It’s important to remember that many clients do not know what WordPress is, so that their website is built on this piece of software is pretty irrelevant to them. For them, they have a website that they access to administer changes on that same website, they don’t think of their front-end website as WordPress, but just, their website; and so likewise, they don’t think of the website where they administer changes on the same address as WordPress.
I think that’s fair – I mean, the latter is probably the clearest when I think about it, although I have seen that the word ‘admin’ confuse some clients.
This is a good point and certainly worth remembering when working with others.
The dashboard is just a overview of the wp-admin. Settings, Plugins, Themes, Posts, Pages. None of these are children of the Dashboard menu item. No where within these sections is the Dashboard mentioned again accept as that singular overview page. It is a single section within a larger structure.
In my opinion, it is the WordPress admin section. Obviously not to be confused with the WordPress admin user.
I generally instruct someone to simply log into their site and then from the dashboard… do whatever.
I don’t necessarily disagree, though when I think of a Dashboard in the real world, I think of something that gives me the overview and controls needed to use the device that’s in my hand (be it something as small as a phone to as large as a car).
I’ve mentioned in a previous comment that I think ‘admin’ is confusing because that’s definitely less common than what other people will use, and it overloads with a user role that’s built into the User management system.
Haha, exactly! :)
I think this greatly depends on the user. Some are totally great at this; others, it’s not as easy, IMHO.
I totally agree.
I always use the term Dashboard.
Admin is the user role!
That’s how I’ve often thought about it, but many of the comments here are bringing up some compelling points, IMHO.
If we are to do the WordPress Way, ought we not take a cue from WordPress.com who, in the My Sites > Stats section, refers to it as WP Admin? But I call it the dashboard for reasons you mentioned, but also because not a have an administrator role.
I don’t necessarily think WordPress.com’s implementation of what they do defines “The WordPress Way.” Maybe this is content for another blog post, but I think of what the documentation defines as being the WordPress way.
WordPress.com is just one implementation of the open source software of WordPress. They’ve opted to go that route.
Some of us don’t – though some of us clearly do :).
*not all users have…
Good point. I’ve always called it wp admin but will switch. Much easier clients even though technically the dashboard is just the landing page.
I totally hear you on this. If you can somehow convince the world at large to suddenly value semantics, you’re a better man than I.
I struggle more with people who insist on using the terms “slider” and “carousel” interchangeably. They’re not the same thing but do I expect even just developer community to know the difference? No. They’re hopeless. Lol.
I am not a better man.
LOL, the optimism in this comment runneth over ;).
How about renaming the dashboard?…
function rename_dashboard( $menu ) {
$menu = str_ireplace( ‘Dashboard’, ‘Welcome’, $menu );
return $menu;
}
add_filter(‘gettext’, ‘rename_dashboard’);
add_filter(‘ngettext’, ‘rename_dashboard’);
Try submitting that as a suggestion or a patch for core. I doubt it’d even make it a day :).
Though it’s not a bad idea for custom installs, of course….
Ha ha! I’m working on a BuddyPress site for hiking trails and renamed Dashboard to Trailhead. Gonna use that in the new member instructions and work it into the site lexicon.
Not get at you, Tom, but this seems like an attempt to get people to use the language of the product instead of what generally applies in most software setups.
Admin is suitably generic for most people to understand. Dashboard means different things to different people depending on their experience.
And technically, I’ve always thought Dashboard referred specifically to the Admin area index page where Dashboard widgets live.
Thanks – though I don’t feel like you (or anyone) is getting at me :). I asked for feedback and I think everything that’s being shared is good stuff!
But you bring up an interesting point: What is the language of the product? There seems to be confusion even within the documentation as to what we should call it.
To some, sure. But, at the same time, I’ve had plenty of experience where clients have been more confused by the term ‘admin’ than Dashboard which is what prompted this whole post, anyway.
Totally a valid though. But then there’s also the other ‘Appearance > Widgets’ administration screen (or is it the Widgets Dashboard or the Appearance Dashboard where we manage our widgets, etc ;).
I’m really just being facetious with this last one ;).
Since we’re talking semantics, here’s how I break it down: WordPress Dashboard refers to the “back-end” UI. Which covers most cases for giving instruction about where to go for config etc. However if the context of the discussion involves things like the admin bar, admin user privileges or security settings as it relates to the wp-admin path, then to be semantically precise you’d have to switch between referencing the Dashboard and Admin as a whole. That can get confusing so it might be easier to use Admin as a catch all.
FWIW, this is how I’ve been treating it, as of late.
Exactly.
I’m beginning to think there’s no one silver bullet solution for the language we use when talking with our customers ;).
I actually think the fact that there’s a menu for “Dashboard” suggests that only that ONE page is the dashboard. In other industries, a “dashboard” is commonly a landing page where you can see an overview of information. It would make sense for the same to apply here.
I think the fact that everything is in the wp-admin directory would make “admin {something}” a better name. I always call it The Admin Panel.
Except that, again, “Panel” means something else specific in WordPress. Finding a word to come after “Admin” is tough, because it’s certainly not a “screen” either.
I think this is a valid and logical train of thought (as many others have followed as well). Perhaps I’ve just personally had trouble getting it translated with my own customers.
It’s something worth constantly evaluating, if nothing else :).
“The Admin Panel” sounds very all encompassing and “Panel” is another term that’s overloaded within the context of the Dashboard (or the Admin, whichever have you :) so that’s a whole other area in which language can get confusing.
The analogy to
wp-adminworks a little bit, I think, but we also throwmu-pluginsandupgradesintowp-contentwhich is confusing – I mean,upgradesnormally contains the actual scripts necessary to upgrade WordPress.Is that really content? Or do we leave that to
pluginsanduploads?I don’t really have an answer. Just shooting off more questions, really :).
I’ve wondered before why WordPress doesn’t have an official style guide. There are parts of the codex that define certain terminology, but that’s not necessarily helpful for talking or writing about WordPress.
There is one that’s slightly dated on GitHub, but I still find it useful.
If you’re talking about terminology and what terms are defined how, then that’s another thing. I think we’re still having to work on that :).
Well, you type into the URL field “/wp-admin” – so it’s clearly the “wp-admin site” or “Admin Site” as I call it.
Dashboard is only a part of the WordPress Admin Site. When telling some users to go to the Dashboard they do exactly this: They open the Dashboard page on the Admin Site…
I’ll start calling it “Dashboard” when the URL is “/wp-dashboard”, or a clear page title tells us that we should call it so ;-)
Exactly. “Dashboard” is not good, because you’re teaching them the wrong term. I wish they would label the whole Admin “the Dashboard” and solve this problem! Perfect term for it, if it didn’t already mean something else! “The Back End” is a coder term which also just sounds weird to normal people. I’ve wrestled with this for years, and don’t know of another term better than “the WordPress Admin area”.
But I sometimes refer to it as “WordPress” with clients! “Yes, sure, you can go into WordPress and put in a video yourself.” They know exactly what I mean!
You can go into WordPress — I actually really dig that terminology.
I disagree.
You type in
wp-contentfor certain things but far more things than ‘content’ live there. I mean, if you’re talking about a blog or a content management system, lots of media lives in theuploadsfolders, thepluginsand themu-pluginslive in the folder, and theupgradeseven live in the directory when an upgrade needs to happen.For some of these things, I think that you can certainly make a case that they belong in the
wp-contentdirectory, but for others I think that you can argue there could be a different place for them to do.That’s great! Seriously, I’m glad your clients and the people that you serve are able to navigate it so well.
I’ve not always had the best of luck with it so I’m just writing from personal experience.
Tom,
I sent a Jr. level WP developer through your TutsPlus course on plugin development. You use the word “Admin” more times than I could count! You even use it for file names, etc.
What’s up with that, brother? I respect you so I had to chime in with that lil’ observation.
Thanks!
I do! I should probably expand on this in a blog post, but I can summarize it quickly here (and you can read through the rest of the comments to see some of my other replies):
When I was recording the course, I was referring to it as the admin and that’s how I had been using it – Over time, my perspective changed with the more and more people I’ve worked. As such, I drafted up this post to generate some conversation around it.
I don’t mind at all that I once said one thing and am now questioning another. I’m just trying to grow in my field – that’s all :).
Thanks! I appreciate comments like this. Hopefully this comment answers it – a good observation to be sure (and, FWIW, I can show shots of other plugins where I’m using
dashboardin the filenames now :).Ha! This was a good conversation to have for sure.
I guess it’s also like the visitor-vs-user discussion some of us old folks used to have around the whiteboard.
The Tuts lesson was really good – hoping you do more of them.
I do plan to do more as time allows – right now, I don’t have any scheduled but maybe I’ll have another done before the end of the year.
…and I’ll be sure to use ‘Dashboard’ unless we have another term by them ;P.
Pretty sure that the Dashboard is just the landing page while the entire backend is called the WordPress Admin area.
If we go back to the DASH proposal for 3.8, it says:
whereas the MP6 proposal for 3.8 says:
Anyway, that’s what I’ve been using for years, although sometime I say the WordPress backend rather than WordPress admin area.. It would be good to get everyone using the same terminology though.
There’s certainly at least some consensus around this, but there also doesn’t seem to be one that’s solid enough to agree with the 3.8 Dash proposal you’ve mention or with the MP6 proposal.
Agreed!
The WordPress Dashboard is part of and found in the WordPress Admin. Why does anyone call it the backend? The backend is the LAMP/LEMP stack, that makes WordPress work.
I think ‘backend’ is something that different people refer to for different things.
Personally, I don’t think of those things as the backend. I think of them as the required software stack.
I concur… The comment wasn’t aimed at anyone in specific, but more of a general comment/question to the larger group.
Gotcha! Yeah, makes sense.
Check the video link out, in this tweet: https://twitter.com/bamajr/status/596875873346785281 it’s what I think of when I hear “WordPress Backend” I hope you find it as comical as I do
:giggle:
When discussing the dashboard, and in particular how one might navigate it related to ‘Roles and Capabilities’, I often use the term ‘Admin Dashboard’.
As we all (should) know, the ‘Admin Dashboard’ is markedly more robust than the ‘Subscriber Dashboard’.
Maybe we just need to combine the terms?
That said, I do not believe the WordPress Dashboard should be noted as the ‘Backend’, ever. That term to me means the files, the code. The ‘Dashboard’ is the WordPress GUI.
Agreed on both.
I dunno – I think that back-end is something that invokes a different thought to different users, to be honest.
No matter what the platform such as Jooml’r, WordPress, PrestaShop, done CS-Cart work, Magento or various .NET items I slap it all under the moniker of “administrative backend” and “administrative functions”. I am fringe, LOL.
Nice to meet you, fringe ;P
I start by calling it the “back-end.” If I get blank stares, I say “dashboard,” and if that doesn’t work, I say “you know, the admin.” Clients often relate the URL of the admin area (wp-admin) to its name.
I personally prefer back-end, but I kind of feel like people perceive the term as archaic or something.
This is interesting – I’m digging hearing how other people are relating to their clients with respect to this kind of stuff.
Huh. Never would’ve considered the term archaic. But what do I know? :)
Ha, yes this is true. I feel like the hyphenated “back-end” and “front-end”
are archaic, but “backend” and “frontend” seem like they’ve not yet arrived. They’re also look like verbs in the past tense, like “blackened.”
As the front/back boundary blurs it is less helpful and may become obsolete.
“Go into WordPress and click on….” seems like the most universal office-speak.
Actually “Control Panel” would probably be most suitable if it were a control panel in WP. Everyone understands “Control Panel” with a PC or Mac (linux folks prolly spit on that needing to add a few more syllables so it can be then shortened to “The BEACOPE” (Back End Administrative Control Options Panel Executive).
Users like consistency in what they use. They can get in a car and know, Steering Wheel, Brake Pedal, Gas Pedal, Transmission, Keys. Thats enough to get rolling. The fight to learn the radio, why their “dashboard” all of a sudden has 8 modes but does not play Halo may take time to grok.
When I first started learn photoshop it was clear to me that I needed Demoral or perhaps some codeine embedded chocolate chip cookies. It was clearly moved from the Mac which sent me into a understanding why Lasanga is layered. I was used to Corel. So NATURALLY this function should be in THAT menu. Its not. Where is it? Must be here? HELP? 20 Minutes later after searching for the info, “Ah! There it is!”. Cool… Now I need do this, that menu. Ummm… Nooooo….
Now I can operate both. At the same time. The trick is taping an index card to ones nose to separate on screen Windows and use a mouse on one and a drawing tablet on the other and if I need sip of coffee my feet have gotten really dexterous at operating a Keurig machine and getting the coffee cup to my local input port.
Alot of stuff I just dont get.
Today I had to find a nice sorta content container box look. I searched and searched like I always do. Everything looks so bland. Mind you, NOT the first time I have done this. Its like my “primer”, like on a lawnmower? Where you push the button five times, one hail Mary and hope it runs? Actually my snow blower is a better example, runs PERFECT in summer, spring and fall, come winter its says to me, “Sorry… Out of season”. Its a Cub Cadet. The dealer never told me that the name is “literal”… It hibernates come winter.
Anyways… I search Google images, web searches, Bing Bing Bing… Uninspired.
THEN I remember, OH! Illustrator business cards. I do this LIKE everytime. My workflow.
This was all for a friend WP site. He actually bought a template from Themeforest and wanted some enhancing. I looked at the template code. OH MY GOSH. WhAT! A! BaD HaIrDay. He’s like whats wrong whats wrong?
So I loaded up the front page, did a view source copied the entire source (he was looking very concerned). Went over to the W3C validator. Pasted. And told it “Chew”. Few seconds later, look, “The Encyclopedia Erronia” spits out.
He looks, says, “What all that?”. I said, “Those are all errors in validation of your website. From bad markup such as Div’s in Span’s (who does this?) to Lists elements with no parent tags, botched CSS was unread, 1437 errors as I recall.
Whats he say to me, “Does that mean Google wont put us in eventually?”.
“Can you fix it?”
I told him, “I am scared to touch it!”
He looked real serious now, “Are you serious? Your a programmer….”
I said look, “Ever been in an Earthquake?”
His eyes went all stark.
I said, “Your site is a programmers earthquake”.
Eyes went up.
I said, “You just keep adding more plugins, widgets and such and lets see how long it takes before you tweak out”.
I told him, tracking down all these errors would be a nightmare. The template code is at best a cobbled together piece of work. Cant tell which plugins are causing what.
Whats he say, “I dont get it.”
I told him to deactivate all plugins. Do a view source, go back to W3C, copy/paste the Encyclopedia Erronia and then contact the template operation and say, “This sucks”.
LOL.
I’ve always use “WP Admin” to refer to the admin. Then, if I want to refer to a specific screen like the dashboard, I’ll say, “Go to the Dashboard in your WP admin.” I’m always consistent and call things what they are. I never see any of my users confused.
The WP admin is the WP admin. It has screens (used to be referred to as panels, but that has changed). We actually had one of the core devs tell us to stick with that terminology when writing our book.
Anyway, the most important thing is to be consistent with your users.
That’s really cool to know – thanks for sharing that.
Bingo.
Hey Justin,
Do you only work with WordPress?
While we dont do lots of sites for others anymore back in the hay day we had several that had varied different applications. For example on like campaign sites there would be CRM, Joomla and at times things for exports, separate domain backup. The CRM stuff for example we used vTiger or SugarCRM and while both would integrate w/ Joomla the clients wanted them separate for secure purposes which makes sense with that type venue.
How do you refer to administrative function when many app’s are what create the site?
We’d just call it all “administrative back-end” and associate to the application and often even component. For example, say Woo Commerce is in a WP site, I’d refer to that as the “Woo Commerce Administrative Backend”.
WP is much easier for a user to cope with than Joomla but back then at least Joomla afforded more versatility. One of the things I miss thats not in WP is the module-suffix stuff. In Joomla modules are basically containers like widgets. A component, say a Events Scheduler is like an application unto itself. It has a default user output display can be used or not. Modules are assigned a named template position, say “right-sidebar” or “center-row” whatall. As Joomla parses down the template it includes any modules assigned to that module position name and page (so a module can appear on any page, all pages or just some).
But they can also have a suffix for CSS purposes. So say the event scheduler has a module showing upcoming events. And we need three permutations of that module. One we want a blue header on, one yellow for say “events coming in the next week” and then one red for whatall, this weekend.
We would take the event scheduler upcoming events display module make two copies of it. Assign all three to the various pages they need appear on. Then in each module set the CSS suffixes, “blue”, “yellow”, “red” accordingly. The CSS generated would attach that as a “-yellow” for example to the module CSS.
It allows a ton of styling differentiations most that even a webmaster can grok without every needing hit the codebase.
In WordPress I was thinking about this with all the customizer deal. Chip had pointed out “how many options are too many options” which makes one ponder why all the options are there. Dev’s put it all in there to control micro-aspects and not of a theme. Their beetch being everything from not enough real-estate to the customizer itself. As I said on WPT I took some cursory looks at customizer, looks good to me. Very good code in fact. Designing a UI to customize a UI (the theme) can be a toil I am sure. But that got me thinking in Joomla terms. While it might not suit all areas of WP for things such as widgets, plugins and even say content posts or post-formats it would add alot of styling capabilities.
How many “theme functions” that people build into the templates are style items based on widgets? or plugins? or post-types?
With Joomla a template (theme) will have lots of these “Canned” suffixes people can just type in. “red-opaque” or “rounded” or “rounded-top” etc. and the built in CSS takes care of the styling as these get affixed to a selector “recent-comments-rounded-top blue”
If WP themer’s are doing this via a theme interface and tons more then that is perhaps a bit easier on the webmaster but it really doesnt afford the flexibility and of course, a million theme options then face the user.
Instead, with Joomla themes they tend come with a documentation or PDF that has all the varieties available and of course, its easily extensible. If “Green” doesnt exist, but webmaster wants “green” whatall. With a theme customizer handling it they may not be able to do it without engaging in altering code. With a suffix they could simply copy/paste existing CSS (preferably well documented CSS) and make the scant alterations.
It would rid (hopefully) a zillion options in theme customization UI and move it to where it probably should be? I realize people could build this into posts, widgets, plugins and even a theme admin UI. Text box, type it in and saves out as an option or select/text combo box so existing ones could be selected or new ones types in and saved as options. But then WP would have those doing it and those not .vs. it being a built in deal.
What do you think?
I think WordPress is not much like Joomla Rick, and that’s a good thing.
Since my experience dates back to heavy use of other platforms as well — including MovableType, TextPattern, and Joomla which all contributed concepts and terms to WP — I’m also likely to use “backend” as the most universal term when there is more than one in use. I also stubbornly refer to “Category Archive Index” Pages and Templates in WordPress since that old MT terminology is more descriptive IMO.
Oh I agree completely…
Joomla is a webmasters nightmare. For a programmer, no big deal, I had no issues using it albeit rather cumbersome. In CMS’s I’ve worked with e107, Joomla, Drupal, WP, Joomla, Alfresco, Magnolia, Liferay, DotNetNuke and several that have waned.
What I was stating is the “module suffix” that FOR EXAMPLE Joomla has would cut buck on alot of overuse of “theme options” in WP and also at the sametime offer more flexibility to the end users who can at least do basic CSS.
Didn’t YooTheme do that with their widgets for the WP version of their theme framework?
It would be very difficult to standardize at this point with WP. Joomla has always had standard markup options for the HTML output of modules, but WordPress widgets are all over the map. Simply adding an arbitrary CSS class to them from a widget field wouldn’t work consistently if the widgets were not marked up with the same structure. You’d still have Clash of the Selectors with all the nonconforming stylesheets that other plugins load.
That’s the deeper problem there. But despite things like this, I have worse memories of all those other CMthings you mention…
We dumped building new Joomla stuff right around the time that RocketTheme and Yoo were deploying WP editions. So, not sure. Probably however.
I do see your point in respect to widgets but that would be at the choice of the authors. In J! most of the time the suffix simply pertains to the wrapper elements of say a module. The enclosing DIV’s.
Yes, clash can happen, but as I stated, its not the widget or plugin developer’s code per se. Its simply a wrapper that can be given suffixes. Its generally the theme (template in J! terms) authors who provide the base styles and the suffixes in the stylesheets to support their template. Its really not plugin or widget code (though of course it can be as well).
In respect to the other CMS’s mentioned, e107 wasnt horrid but again not really a user CMS. Liferay if you ever used it then you know what it is. Its not meant to be a user portal/CMS. Its meant to be admistrated. The users be they publishers, editors, reporters, disconnected physically corporations, offices have a consistent Internet/Intranet or both experience. It has the moxy where it counts, workflows for end users. Thats why entities such as PBS, Seagate, Disney, Amazon, eHarmony, Google, Toyota etc. use it. Some for outward presence, some for intranet, some both.
Magnolia and Alfresco sorta similar. Walmart uses Magnolia for example for their immense intranet. All these java based ones are considerable overkill for most small webmasters purposes. Yet, for enterprise still have issues being workable to any circumstance swiss army knives.
Presumably, this is why Adobe is going a sorta different route that others with “next gen online publishing”. If you have not saw an of the early stuff on it, amazing.
Can be a one man operation with the entire Adobe Creative Suite and their online publishing solution at your beck and call for under $30 a month. Or, you can have 5 or 10 or 100 of 500 people all across the world publishing “The Global News” with reporters, artists, layout, publishers, writers, events managers the works. Their workflow engine for the perhaps 3 minutes of video I saw is a gem. Drag persons user icon into what amounts to a flowchart in the workflow. Draw a few lines that represent work transport flows, constrain the options they have. Done.
If I were to do same in Joomla it’d take many many hours to do what was explained in 3 minutes and in actual time done in less than 1 minute. It also has groupings, group constraints etc. Click a group, up pops their “flow diagram”.
Need stan to help Julie with layout or perhaps train her. Drop Stan where she is, copy button her constraints. He’s done.
The creative cloud as it is now is just “step 1”. When they say “Creative Cloud” they mean a whole lot more than some storage and asset sharing etc. They mean creative cloud. In the video I saw for perhaps 6-7 minutes of it they showed a workgroup of college students using InDesign with what appeared to be some form of Flash on steroids yet no mention of what that actually was. The example shown was a rudimentary nuke power plant operations simulation published to a webpage (again, workflows etc all in place) and apparently was done in a matter of hours.
I’ve saw alot over 35+ years since CP/M 80 and MP/M, I dont think I have been floored in the last 20 years by much of anything. In the past year been floored twice. MS open sourcing its literal gem which stands as the basis of 90% + of all computing in the world now and seeing that video which a professor at our local university showed me as they will have curriculum in support of it.
Late to the party, but just wanted to agree. I typically tell my clients to, “go to the wp-admin.” But I’d love something that sounds better. I shy away from Dashboard because it does just sound like it’s only the landing page once you log in. However, I like what Bob said way above here, that is referring to it as Dashboard and sometimes as Backend.
I’d be happy with, “ok, please login to your WordPress Dashboard, and navigate to Pages.” I think that makes good sense.
Time to standardize this terminology.
Thanks.