@faraday said in UX: It's time for The Talk:
-
Sensible Command Names - Why is the OOC profile command named +finger? Or the build command 'dig'? Or the private chat command 'page'?
-
Consistency - The mixed up mash of coded systems on most MUs often leads to bizarre inconsistencies - like one command uses subject=message
and another uses subject/message
.
-
Redundancy - +help versus help or +desc versus @desc anyone? MU systems overlay on the base hardcode implementation, so you end up with multiple ways to do similar things. Which is sort of related to...
-
Command Prefixes - Why is it @desc versus +where versus quit?
These. All of these right fucking here. And it goes far, far, far deeper than even that.
Another (non-MUSH) example of shitty UX despite having decent functionality: Git. For many of the same reasons here.
Now I personally know that a lot of this stuff has historical roots. +finger from the unix command, @/+ prefixes for softcode vs hardcode. But when you look at it as an outsider it's un-intuitive, needlessly complex, and just plain goofy.
The @ vs. + vs. . vs bare thing never had an excuse except POSSIBLY the hardcode vs. softcode divide if there's no way to override hardcode commands in softcode. But ... a few questions even if that hardcode/softcode divide needs to be kept:
- Why prefixes at all? Why is it so necessary to TELL people that they're using soft-coded commands instead of hard-coded? Is it really so necessary to have
+finger
instead of finger
? What does the "+" add there at all?
- I can see, if I squint right, how @desc me=foo makes sense to distinguish a property from a command, but why is it @ for some and & for others? Pick one and stick with it, dammit! Or even better just make setting a command!
set <property> <target> <foo>
. And to read it get <source> <property>
and to read it in code get(<source>, <property>)
and so on.
@Derp is right in that there is a certain level of complexity you cannot reduce below. But that's the essential complexity of a problem domain. What's at issue in shitty UXes (like that of MUSHing) is the unnecessary incidental complexity typified by unexpected naming, unnecessary duplication, bizarre naming schemes, etc.
Nobody (sane and/or knowledgeable) is clamouring for a reduction of essential complexity (because this is impossible). But there's a whole lot of work that could be done to eliminate the incidental complexity of MU*ing, even sticking with the servers as-is.
But I do agree with @HelloProject that you can make at least the basic versions simple.
And that's the other issue in UX design. Identifying the most common use cases and streamlining it for those to be efficient and simple. If 99.44% of the time an attack is roll d20 add attack subtract defense, that should be what happens when you type the attack
command by itself. If you have to add modifiers for uncommon situations, a raw attack
should still work exactly as the most common circumstance holds.
The same is true for all parts of the MU: chat systems, bulletin boards, jobs systems, scene management, etc.: the common should be the default.