The development principals behind McMyAdmin.

December 24, 2012 at 2:54 PMPhonicUK

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

Ben asks:

"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.

LACDH asks:

"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).

Jimmy asks:

"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.

Posted in: McMyAdmin

Tags: ,

Why the Minecraft community picking YAML as the standard configuration file format was a mistake.

December 8, 2012 at 8:13 PMPhonicUK

This is a mixture of opinion and rant about why YAML is not well suited for the way the Minecraft community uses it, and how bad plugin developers are making the problem worse.

YAML (Yet Another Markup Language) is a relatively new markup language. It's goal is to be human friendly way to serialize data. With YAML you can represent a piece of data that can be understood easily by a piece of software and also easily readable by a human. As something for humans to write however, it's not so great.

Compare the following three snippets:

1)

Joe:
    interests: [video games, movies]
    full name: Joe Bloggs
    age: 25

2)

Joe:
    interests: 
       - 'video games'
       - 'movies'
    'full name': 'Joe Bloggs'
    age: 25

3)

{
  "Joe": {
    "interests": [
      "video games", 
      "movies"
    ], 
    "age": 25, 
    "full name": "Joe Bloggs"
  }
}

So right away there are a number of problems:

  • All three of them represent exactly the same data, yet they look very different. A YAML parser will give the exact same result for all 3 of them.
  • You can't tell just by looking at it whether or not I used tabs or spaces unless you're using a text editor which specifically highlights the difference.
  • You can't mix-and-match certain styles in the same document, even though they may look very similar.
The keen eyed among you will notice that #3 is also valid JSON as well as YAML. Also note that in example #2, you can increase the amount of indentation for Joe's interests to any amount you like, and it's absolutely fine as long as they are both the same. The single quotes are also entirely optional, you could have 'video games' with quotes and movies without quotes and it'd be perfectly valid.
 
The problem is that with so much variation and style, writing proper YAML can get tricky very quickly, especially for larger documents. With something like XML it's harder to go wrong as the format is much more rigid.
 
Largely the community as a whole has settled on the 2nd style shown, and you'd think that'd be the end of it.
 
The remaining problems are not so much down to YAML, but the behaviour of Minecraft plugin developers.
 
A number of plugins, instead of using a full YAML parser - instead have their own parser that only works with a very specific style. They are no longer using YAML but merely a extremely restricted subset.
 
The following are the kind of bad behaviours exhibited by some plugins:
 
  • Mandating certain levels of indentation (2/4 spaces) even though the YAML spec doesn't care as long as it's consistent within the document.
  • Failing for lists if they either do or don't have enclosing single quotes (even though it's valid regardless)
  • Not supporting the square bracket syntax for lists (as seen in example #1)
  • Insisting that strings either don't or do have single quotes around them, despite the spec allowing either (or even for you to mix freely, as you may need to quote integer values that are meant to be strings, but not something that is definitely a string)
  • Requiring that elements are in a certain order (swapping around the age and full name for example causing the plugin to crash)
YAML is a very flexible format, deliberately so because it's made for humans. Yet some plugin developers feel the need to completely throw that out the window.
 
If a more rigid format like XML was used then it seems less likely that developers would be trying to write poor implementations based on the subset of YAML they happen to like.

Posted in: Minecraft | Servers

Tags: