I'm often asked how I decide to do things in McMyAdmin, or why I chose to implement some things or not others. So I'm going to try and give a little insight into how I do things or why I do things a certain way.
So these are some of the principles and ideas behind developing McMyAdmin:
"If users are hand-editing configuration files as part of day-to-day administration, you are doing something wrong".
Bare in mind that the context for this is in terms of your average user. Not a seasoned server administrator, but someone who doesn't know their FTP from their SCP and doesn't have a clue what a public and private key are.
It's quite a basic idea when it comes down to it - keep things simple. But this has several implications. What do you do when there is a configuration structure that doesn't translate well into a graphical interface?
What this usually means is that certain functionality is omitted in order to keep the user interface simple. Take the Users and Groups management for example, there is no per-user management at the moment. Why? Well you get the same result by creating a single group just for that one user, and it keeps the user interface and mental model very simple. Users belong to groups, and groups determine what the members of that group can and can't do. In addition it translates well into most other permission models relatively easily.
Similarly McMyAdmin deliberately lacks a file editor at the moment. I could at any moment put in a file browser (with safety restrictions to only allow editing of configuration files, etc) with a basic text editor, but for anyone but an experienced user this would deliver a very poor user experience when compared to the rest of McMyAdmin. Everywhere you look in McMyAdmin there are small indications about what something does. If you look at the settings for example each setting has a small description next to it explaining what the setting does, and it is impossible to give a 'wrong' value (since you're usually just picking from a predefined set of values). A 'dumb' text editor however leaves the user with no clue what is expected of them. In addition users who are advanced enough to know how to manage plain-text configuration files by hand are often quite happy to do so outside of the web interface (via SFTP/SCP).
In an ideal world, plugins/mods could include a meta-configuration file that specifies the format and acceptable values for a configuration file that a UI can be automatically derived from (and the feasibility of this is being investigated) but this does have an interesting set of challenges.
"Keeping 95% of your users very happy is more important than keeping 100% of your users marginally happy".
If you are but a mere mortal, time is a finite resource. So making sure that it's being used optimally is very important in the world of software development. In terms of McMyAdmin development what this translates to is having fewer features by only implementing those that the majority of users would use, but making sure they are well presented and thoroughly polished. Adding more features that very few users would use means less time making sure existing features are well rounded and pleasant to use.
Of course this comes with some trade offs. Power users would likely be more tolerant of features being slightly rough around the edges and would accept that if it meant getting an interesting new feature, but sometimes the cost of implementing a feature only used by a small number of users makes it uneconomical.
Sometimes however what happens is the feature appears much much later, with many alterations to the original idea in order to make it user friendly and something that feels pleasant to use. For example the new MCMA scheduler that allows tasks to be executed in response to certain events is very simple to use and allows for a lot of flexibility, but it went though many iterations before something usable came out as the end result.
"Consistency is key"
One of the things I'm often asked is why some settings from the server.properties file (like the server IP and port) are omitted from the web interface. The answer of course is for the hosting companies who don't want users to be trying to mess around with those settings. I'm then subsequently asked why I don't allow those settings normally and just hide them for those on hosting companies.
The issue here is consistency. If a user uses McMyAdmin locally or on a server to which they have full access and sees what can be done via the web interface, they would have a poor user experience if they used McMyAdmin on a managed host and found that certain features weren't there. This doesn't apply quite so much to the server IP and port since those are usually things that you set once and never need to touch again, but the idea is the same - keep things as similar as possible between different versions so that users have a consistent experience no matter what environment they use MCMA in.
There are a few exceptions to this of course, but with the sole exception of server sleeping (hosting providers can force sleeping to be enabled and disable the ability to turn it off) they are features that you never actually see in the web interface (things like using LDAP authentication)
Questions from Visitors
"Couldn't you put in a Advanced mode in the panel which does allow you to go more in depth with plugin configs?"
Well Ben, yes I could. But I don't for a moment think that 'normal' users would be discouraged from going and trying to use it and possibly making mistakes that negatively impact their server. Warnings don't go too far except to be a 'I told you so' point after the user has done something daft - for example the Permissions exporter setting gives you a massive full screen warning telling the user that their data is about to be overwritten and to take a backup if they want to keep it, and some still fail to do so only to be made to look really silly when you point out they were warned.
There is also the issue again of consistency. Hosting providers would almost certainly disable any advanced mode to keep support costs in check, so it'd deliver a poor experience to find that certain features were only sometimes available.
"So basically it's your way or the highway?"
That's a slightly blunt way of looking at it but it's parly true. I ultimately decide what goes into McMyAdmin and how, although Enterprise providers get a very heavy say in terms of features they need to run their businesses effectively.
But again extensions allow you to add things that I either haven't thought of, or have for whatever reason decided not to add (yet).
"I heard previously that MCMA will support multi-world backups. I've noticed that this hasn't been implemented yet. Is there something you're waiting on or another thing that's preventing this feature from being implemented?"
It is indeed getting it. It has been slow because it's been tricky to come up with a model for how users will configure multiple worlds. Multi-world support in McMyAdmin also includes support for permissions exporting and not just backups so that's been the bottleneck. I've been reluctant to add one but not the other due to user expectations.
The initial approach was to let users add worlds, then they'd add groups to the worlds, and users to the groups. The problem with this was it meant duplicating identical groups for different worlds too often and it was very laborious.
What I've settled for instead is that when you're editing a group you get to specify which worlds it's going to be applied to with a list of tick boxes for each world configured, and MCMA will automatically handle any configuration duplication as necessary to make it work. It's a tad tricky under the hood but it gives a very nice end-user experience.
If you have any more questions about why I decide to do things a certain way, please feel free to post a comment and I'll update this post with as good an answer as I can manage.