UX: It's time for The Talk

[WTFE]

@faraday said in UX: It's time for The Talk:

I fail to see how extending the 'mail' command to do something more (what I'm suggesting) is any more confusing than disabling it and forcing players to use a +mail system instead (which is what people do today). The player doesn't care whether it's softcoded or hardcoded; they just want to send mail.

This. This right here. This is the fucking essence of UX 101.

Don't make the user care about irrelevant bullshit.

There's plenty of historical reasons (good or otherwise) for MUSHes to have a terrible UX. I get it. There's a lot of baggage here.

But…

This doesn't stop it from being a terrible UX! That's the part people have to get through their skulls. There's plenty of reasons why DOS was the way it was too, historically. It doesn't change the fact that DOS was a piece of shit that everybody was glad to see the back of … except for the DOS grognards who spouted a lot of the same shit that's being spouted here about how MUSHes do it right.

[WTFE]

@Lotherio said in UX: It's time for The Talk:

@WTFE said in UX: It's time for The Talk:

It has always been silly. There has never been a need for users to distinguish between hard-coded or soft-coded commands. There has been crappy software, maybe, which forced this distinction but ... that is the very DEFINITION of poor UX.

This made me laugh.

Aside from soft code varies from game to game? No reason at all to distinguish from hard-code, that is constant from game to game, and user commands, built within individuals game and unique (used to be) to those games?

I remember the days all users were expected to contribute their own content. Whether making rooms, their own vehicles, their own multi-descers, some new coded game for the game room, or new potential globals? Whether or not pool tables or bowling alley code on Mu*s was ever needed, users had liberty to make these and they did. So yes, there has been and still should be, a need to distinguish hard-code and soft-code commands.

Users should understand because WoD LA Nights has +taxi to get around, that doesn't mean CoD LA by Night will have any taxis at all. There is absolutely reason to distinguish.

You know what I found out the other day? Not every Windows computer has Microsoft Word installed on it. Nor do they all have Acrobat Reader or Photoshop or … well pretty much any application you can think of.

<sarcasm>Thankfully Windows tags all user-installed applications with a special sigil so that you can know which programs might not be available on another machine, otherwise there'd be mass confusion as people ask "where's Acrobat Reader" and get told "we have Foxit Reader" installed instead of Acrobat Reader". That would just blow their fucking minds.</sarcasm>

[Groth]

@WTFE
So in this analogy, the @commands and the default commands like WHO etc, are your windows explorer, internet explorer, notepad, windows volume control etc. Only that in MUSH their names are even more generic. If you tried to start notepad but instead got microsoft word, most people would get rather surprised.

While your + commands are your acrobat reader, photoshop etc. Only just like the default commands have very generic names, it's likely you want your taxi command to be named 'taxi' because that's vastly more convenient for the user to type out then 'Bobs Taxi 4.0'. You could always do this the Unix way and give your programs short and cutesy names like 'vim' and 'emacs' but how intuitive is that exactly?

So how do you now distinguish between the default mail which people expect to be there from your super special mail you wrote for this game in particular?

[WTFE]

Enjoy your DOS box.

[faraday]

@Groth said in UX: It's time for The Talk:

So how do you now distinguish between the default mail which people expect to be there from your super special mail you wrote for this game in particular?

You don't need to. Really, you don't. If you want to provide good UX for your players, then you will make the basic mail commands on your super-special custom mail program work the same as the built-in mail. Then it doesn't matter what additional features you provide.

As long as 'who' tells them who's online, they really don't care what it looks like. There's no reason to separate WHO or +who (other than the aforementioned historical reasons).

[Groth]

@faraday said in UX: It's time for The Talk:

@Groth said in UX: It's time for The Talk:

So how do you now distinguish between the default mail which people expect to be there from your super special mail you wrote for this game in particular?

You don't need to. Really, you don't. If you want to provide good UX for your players, then you will make the basic mail commands on your super-special custom mail program work the same as the basic mail. Then it doesn't matter what additional features you provide.

As long as 'who' tells them who's online, they really don't care what it looks like. There's no reason to separate WHO or +who (other than the aforementioned historical reasons).

One reason to keep the default WHO is that it allows the MU* scrapers to parse your player statistics if you care about being scraped, the default WHO also provides additional information to wizards and gods that most people don't bother replicating into the +who (since WHO does it).

[faraday]

@Groth If you want to sacrifice usability for your players in order to support a hypothetical MU* scraper or to avoid coding extra stuff into +who for admins, that's entirely your prerogative. But I will agree with @WTFE here and say: That doesn't mean it's good UX.

[Groth]

@faraday
Consider this. Why are people using the MUSH codebases at all? Why don't they just roll their own MUD code like people did before the MUSH codebases were around? Why do people advertise their game as a PennMUSH or TinyMux game rather then Bobs RPG?

[faraday]

@Groth Because the base game engine comes with a lot of basic functionality that you probably won't ever touch. Unless you really have some overwhelming hankering for a custom page command, or pose commands, or movement commands, or what-have-you. That doesn't mean you need to invent a whole other command notation for the things you do want to customize/change. But if you don't believe me, just stick with Penn/MUX and keep using + commands. Really, it makes no matter to me.

[Derp]

@Groth said in UX: It's time for The Talk:

Consider this. Why are people using the MUSH codebases at all?

I would like to follow this up with: Why do people continue to use the MUSH codebases at all, when there have been other people on this thread talking about Evennia and python-systems and things that you can just do in hardcode format?

Part of the user experience is recognizing that people are used to certain ways of doing things, and that these games are not isolated instances, but an entire class of game. @WTFE keeps frothing about good UX meaning that players need never worry about what comes with the game and what has been added to it, but as has been pointed out before, this is simply untrue. You absolutely need to know what comes with the game and what has been added to it because there is an almost 100% chance that the player of this game will eventually move to another game. (The +taxi thing is a perfect example of why users do need to know what comes with a game and what does not).

If it were one game, yes, I could see this argument being sensible, but this is a type of game that you are learning, and so this argument is nonsense.

[WTFE]

Enjoy your DOS box as well. It was made for you.

[faraday]

@Derp said in UX: It's time for The Talk:

If it were one game, yes, I could see this argument being sensible, but this is a type of game that you are learning, and so this argument is nonsense.

In my experience, that is quite simply untrue. Just look at how many players have successfully transitioned over to Arx (using Evennia) or BSGU (using Ares). I've had a bunch of players on Ares who don't even realize they're playing a different game server. They think it's just some kind of customized PennMUSH. It is absolutely possible to preserve 90% of the experience a player is used to while still expanding and simplifying that experience. It's called backwards compatibility and it's really not rocket science.

As for why more people aren't using them, there are a variety of reasons for that, not the least of which is that both are still in development.

[Bobotron]

@Groth
People have preferred codebases. I prefer Penn because I'm more familiar with the features and more of Penn's stuff is muscle memory for me (sticking a + in front of channels, though that's not required anymore). There's also a lot of people who won't touch other codebases even as a player (OH GOD THIS IS NOT MUX! is a common thing I have heard before), so... transparency I guess? Or a call to the people who like that codebase and might like the theme, so they're aware of what version of stuff they need/want/are comfortable with.

[Lotherio]

@WTFE said in UX: It's time for The Talk:

Enjoy your DOS box as well. It was made for you.

So it needs to come down to, bright, shiny, easy to use? Might as well be on an iPad or a Surface. We shouldn't even need clients, every game should be an approved App in the App store. If its broken, we should just be able to write a bad review, saying we get no support and we want the widget feature to work a certain way?

Because angry birds has revolutionized the game industry, every game should be angry birds but with a different skin.

Some people want different games with different features. Accepting Ares or Evennia or Mud as the game, and altering theme to tastes is fine and well, I support it, I personally enjoy Ares and will try Ares Mu*s when they start rolling. Am I going to attack the code base? No, I applaud there efforts.

Mu* and all those help files, was released at a time before internets and code schools on-line. They put all the damn information into the help files so you can make whatever you want, some people choose to put a + in front of some of that shit to identify it as unique to the system.

Imagine if they never put those help files in? Would there have been an increase in text games? Probably not, because it would have been 10 times more unfriendly then you all see it now with your 2017 hindsight glasses. Would a lot of the current developers of the new systems we're seeing now even have gotten into this 'hobby' to actually develop it?

News flash, people still use Unix and Linux for their operating systems. Why? Because if they don't like the pre-installed calculator app because it doesn't handle chaos math so well for their amateur meteorology hobby, they can find code that does or write/alter it themselves ... without writing a bad review of calculator app (whine, this calculator sucks, it doesn't do what I want to), or trying to find one that works just right.

News flash2, are the Unix people complaining about users? Man, all these app users and their demands for better UX, if they would just learn to code a little! Not as much as the app users apparently demanding a better UX.

This is a hobby, everyone is in it for enjoyment of the hobby. Do we need to continually insult people that have developed and will continue to develop?

[ThatGuyThere]

@faraday said in UX: It's time for The Talk:

As long as 'who' tells them who's online, they really don't care what it looks like. There's no reason to separate WHO or +who (other than the aforementioned historical reasons).

I will disagree with this depending on what information is on the +who which is different on each game. For example I like having both on Fallcoast for one reason. +who list connected played based on idle times so make for a god way to scan who is on and active. Standard WHO has the hard coded version of newest connects on top, which is really nice if I log on and am waiting for someone(s) particular to show up for a scene because with one command at a glance I can see who connected recently rather than having to check each character individually as I wait.
Unless you want to make it so the who list can be sortable by the person checking it i fail to see how having the same information presented in two different ways is a bad thing.

[faraday]

@ThatGuyThere said in UX: It's time for The Talk:

Unless you want to make it so the who list can be sortable by the person checking it i fail to see how having the same information presented in two different ways is a bad thing.

Those are valid reasons for expanding the functionality of the 'who' command, not for having two obscurely different versions of it. But that's just IMHO. If you're happy with the status quo, then there's no reason to change anything. Some of us aren't, though.

[Groth]

@faraday said in UX: It's time for The Talk:

Those are valid reasons for expanding the functionality of the 'who' command, not for having two obscurely different versions of it. But that's just IMHO. If you're happy with the status quo, then there's no reason to change anything. Some of us aren't, though.

I don't think any MUSH coder will argue that MUSH is an awesome platform however when you critique MUSH syntax and UX, I think it's important to remember what MUSH is actually designed to do otherwise you'll look a bit like someone complaining about a multi-tool being a poor hammer.

Yes if what you want to do is hammer nails, then the multi-tool isn't the best, or even a good choice. However that was also not what the multi-tool was designed to do.

MUSH is standard and a toolbox designed around allowing allowing the users to code almost anything from within the game itself. It's very convenient for most TTRPG to MU* translation games since it comes out of the box with everything you need to make a grid and roleplay, leaving most games to only need to install AnomalyJobs and a roller and they're good to go.

Being a standard is also convenient, because it means that regardless if you play Bob Mush or Alice Mush or Eve MUSH, you know the basic commands used to play the game all work the same way.

I really honestly fail to see how breaking that standard makes things more intuitive and once you do leave that standard, you may as well leave the entire way to Evennia or Ares or whatever floats your boat because I see absolutely no reason to use the Pennmush or TinyMux codebases if you plan to replace their core commands. Any talk of doing such things within the context of MUSHcode is to me insanity.

[EMDA]

@faraday said in UX: It's time for The Talk:

@Lithium said in UX: It's time for The Talk:

But +code? I don't see what's the big deal honestly.

You've obviously been playing for awhile so I'm sure it's no big deal to you. But put yourself in the shoes of a new player who's never MUSHed before. Imagine you're trying to learn this command set for the very first time.

I want to stress this point. I can understand people being comfortable/okay with the really weird command structure/code setup that seems frequent on MUSHes if they've been in it for a long time or they've actually had it develop over the time they've been playing, but from an outside perspective it's pretty daunting. The amount of disagreement on the rationale for different prefix symbols makes that kind of evident, but to illustrate:

If you want to move around in-character you use normal commands - n, s, e, w, or specific commands. You can look around with look. But if you want to see different joinable areas in the room you have to use +places. If you want to do a typical emote you can just pose or say, but if you want to write an emote that has your character's name in the middle you're breaking out a new prefix with @emit. You can look up other people's information with +finger but if you want to set your own you're editing attributes with &something = something IIRC. In a number of MUSHes you're going to have an inventory command that's probably not going to be used in favor of some other command with a +. You can use a channel name to chat to it, and comlist to see what you've set up, but @clist to view the public options. I think.

The helpfiles being pretty selective in how you access them doesn't help, either. You might get a helpfile for command before realizing you needed the +help for that command, since it's prefixed. I was looking at Fear and Loathing recently, and they have a damage +help that encompasses the +hurt and +heal commands (or equivalents, I don't remember if that's exactly what they're called). That file should, IMO, come up if you try to look up either of those commands, but doesn't. I don't know if that's a system limitation or just the game specifically, though. Then you have commands like +travel and +temproom mentioned by people without easily-accessible helpfiles, because maybe they were initially encountered on a different game or something.

All of that makes for a total hodgepodge if you're trying to learn it - you're basically trying to put three jigsaw puzzles together, plus one more if you're learning the system the game is based on as well instead of just how it integrates to the MUSH. I'd understand if a game went the way of, "@ is used for every OOC command", or something like that, but that seems uncommon. If you're using a jumble of different prefixes for any specific task - interacting with the grid/a room, interacting with another character IC, interacting with another player OOC - I think the drawbacks of that standard outweigh the supposed benefits.

I know, at least, there've been plenty of people that I've seen turn away from MUSHes that they'd probably enjoy and bring a lot to solely on account of the disjointed command structure to look for a more consistent alternative. Someone could definitely settle on the "just tough it out and memorize it" side of the fence, but I appreciate the intent of the thread in promoting some kind of streamlining.

[SparklesTheClown]

I'm just gonna say that I never saw what +mail contributed to anything. It's never been more simple than the hardcoded mail and always just seemed like an annoying new thing to learn. I've yet to see anyone adequately simplify mail in a way that justified having to learn entirely different annoying mail code rather than just keeping annoying mail code I actually know how to use.

I'm not suggesting that I know how to make mail simpler, just not to replace it with something that isn't particularly better and then I have to learn that too.

[Sparks]

@HelloProject said in UX: It's time for The Talk:

I'm just gonna say that I never saw what +mail contributed to anything. It's never been more simple than the hardcoded mail and always just seemed like an annoying new thing to learn. I've yet to see anyone adequately simplify mail in a way that justified having to learn entirely different annoying mail code rather than just keeping annoying mail code I actually know how to use.

I'm not suggesting that I know how to make mail simpler, just not to replace it with something that isn't particularly better and then I have to learn that too.

You're not wrong, but... +mail predates built-in mail, so some folks view the built-in hardcoded mail as learning "entirely different annoying mail code rather than just keeping the annoying mail code I actually know how to use".