UX: It's time for The Talk

[SparklesTheClown]

@Sparks I actually had no idea. I thought +mail was just some shit people made up for no reason.

[Sparks]

@HelloProject As far as I know, +mail was actually one of the very first softcoded commands, and as such is actually responsible for the + prefix as well. (Someone correct me if I'm wrong?)

[Roz]

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

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

Why, though? Apart from "this player will go and play another game eventually," which I don't actually feel is a reason why this is apparently a 100% necessity? Like, I don't accept the baseline assumption here that because there are multiple games, they are required to have specific things in common.

I've staffed on a game that had a large amount of new players who were entirely new to MU*s, and @faraday is right: the help vs +help thing, the whole command structure, was a nightmare to try and explain. And you can't just tell people "oh one is hardcode and one is softcode," because that doesn't mean anything to them, either. And yeah, we had extensive intro/help documentation to combat this, but the fact is that the sort of fundamental baseline for MUSH functionality is super confusing.

[Ganymede]

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

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.

On most games, I use the same commands:

Desc
Who/Where
Mail
BB
Page
Pose
@emit

That's all. That's why it was pretty easy for me to get used to Evennia or Ares.

I get that some people are turned off by the incongruent command syntaxes between games. Maybe I'm an old fart who's just so used to this sort of gaming that I don't have to spend more than three seconds to figure out how to use basic commands. Or maybe it's because I also read the applicable help files and the wiki, and use the Newbie channel. Sure, I've given up on games because I don't like the system employed -- I'm looking at you, Unisystem -- but I can't say I've ever, ever, ever been turned off because I had to use +mail instead of @mail, no matter how much I may grouse about it.

If you want to do something, put some effort into it. Giving up on a game because it happens to use + or @ prefixes is sort of like refusing to play Final Fantasy XV because of its active combat system. It took me a little while to get used to BSG:U's entire code, but I never bitched or complained or just left because I wasn't immediately immersed in awesome RP.

[SparklesTheClown]

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

but I never bitched or complained or just left because I wasn't immediately immersed in awesome RP.

But this is inherently the mindset of a seasoned MUer, like you said. From the outside looking in, this is a confusing mess.

I started MUing in 2005, some of this shit still doesn't make any goddamned sense to me. Even now I frequently fuck up if I should add a + in front of stuff depending on what game I'm on, have to remember what games I can actually use a freaking percent sign in channel conversation on, and just a ton of minor bullshit that just gets super annoying to deal with and never really gets any better.

My intent with this thread was never to claim that MUDs are perfect, because, again, there's a reason I don't really play them anymore. But I still hold to the idea that MUDs are, in general, not a mess when it comes to quality of life shit. Like, even entirely ignoring combat stuff for a moment, there's just so many little annoyances that I don't understand the necessity for.

If someone wants to code macros because they're used to public having a + sign or whatever, fine, let them, but like, I don't see how as a hobby we can constantly go "Oh this hobby is dead because MMOs" or "because people don't text RP anymore (BIGGEST FUCKING LIE EVER TOLD)", when we have all of these fixable things that are clear barriers to entry, but we argue that it's fine because we're arguably used to it.

I get that not everyone who makes a MU is making it with the intent of pulling people in from outside of it, especially due to the unwarranted pessimistic outlook that people have on this idea that people aren't interested in joining, but like, people can't act like all of this irritating command confusion and random inconveniences don't at least have something to do with why it might be intimidating to some people who actually do manage to find a hobby that no one bothers to advertise.

[faraday]

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

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.

My mail system doesn't simplify any of the basic mail structure, but it included a variety of features: a meld of quickmail and composition, enhanced mailing lists, better mail sorting and retraction, mail archive, automatic 'sent mail', quasi-threaded replies, and - most importantly from my code's perspective - the ability to send mail from a function to better integrate with the other coded systems.

Now maybe some or all of this exists in Penn now but at the time it didn't. It's just another example of what I keep talking about -- the most basic use cases are identical to the built-in systems to make the transition easier, but it provides additional features beyond them. Now maybe that's not enough value for you - that's your prerogative. But it is for me, and it's my code, so...

[SparklesTheClown]

@faraday

I'm gonna admit that I've never been able to figure out mail code beyond the basic function of just sending stuff to multiple people.

After that it pretty much turns into alien technology.

But I don't doubt the usefulness of the extra features. If anything, this exemplifies what I was saying earlier. I can use the basic functions without knowing how all the crazy advanced shit that's way over my head works.

[Thenomain]

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

@Sparks I actually had no idea. I thought +mail was just some shit people made up for no reason.

Do you have me on Ignore or something?!

Ahem, what I mean is...

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

I'm gonna admit that I've never been able to figure out mail code beyond the basic function of just sending stuff to multiple people.

After that it pretty much turns into alien technology.

Mail had requests made of it. They were implemented. Not using a tool is not bad design; bad design is a tool that is not easy to use as intended.

If you don't want to use mailing lists, fine. If you do and have a vague understanding of what mailing lists do and still can't work out how to use it, that's a potential problem.

Or in other words: I complain about man pages all the time, but I realize that it's my not understanding the underlying technology, not the man page. I want a howto. Good luck learning Linux system administration with just man pages!

[SparklesTheClown]

@Thenomain

I don't consider advanced features to be bad design, I'm saying that mail, despite the fact that I find it a bit clunky, is somewhat an example of good design.

It seems to be more or less as simple as it can be, at its very basic function, but if you choose, you can go deeper into its functionality.

However, not going deeper into learning its functionality doesn't affect your enjoyment of the game or use of the tool.

This is good design.

[Thenomain]

@HelloProject

My other point was that after certain complexity you need education beyond help files. I tried to play a Lords and Ladies game and I was not helped by anyone, and my frustration was called out as trolling. Only one person even tried to help get me educated, and most people were scoffing at the idea that the game could focus more on it,

Situations like this will happen no matter how good the design. I used to spend hours a day educating people on the iOS interface, more or less the simplest interface a computer has managed to get, and one of the most perfect examples of UX/UI. And still it was difficult for some people,

That's why UX is an entire degree program. Like Library Science, it is strange and most people don't know what it's for but if you're any good then you can make bank. I am not such a person. I wish I was.

The point of all this is that design can only go so far. I think you realize that, but I've started down this path and so I wanted to get to the end. That's it. The end.

[SparklesTheClown]

@Thenomain

This is true. Honestly a part of what inspired me to make this thread is because I've been doing a lot of research into UX stuff, as I try to prepare to do coding as a career. My bizarre fascination with marketing made me very fascinated by how UX stuff affects the way people interact with the game, how quickly they can get into playing it, and even if just looking at it keeps them from even trying it.

Also, iOS on an actual Mac confuses the shit out of me, because folders don't work the way I expect them to work >_>.

[Thenomain]

@HelloProject

<whispering>iOS is for the iPhone and iPad, not the Macs.</whispering>

[SparklesTheClown]

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

@HelloProject

<whispering>iOS is for the iPhone and iPad, not the Macs.</whispering>

Oh. Well, that's just depressing then.

[Lithium]

@faraday All of the things you responded to are a problem with /documentation/ not coding. You can change the documentation, get people pointed in the right direction so they know of the + commands and then... guess what? Your whole UX 101 thing is solved.

Done.

It's all about presentation and documentation rather than what the coded command /is/.

[Paris]

@EMDA I'll look into updating that, though it won't be immediate. We've updated help and added information/functionality to existing things as players have requested them.

Part of it is that we inherited the DB, with various custom code that did not all have help written for it, and so are modifying and updating it as we catch them or someone says it's not intuitive.

It's not as good as being in-game immediately, but I will work on a list of basic and in-depth commands for the wiki, and put a link to it in the ooc room.

[Paris]

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

I've staffed on a game that had a large amount of new players who were entirely new to MU*s, and @faraday is right: the help vs +help thing, the whole command structure, was a nightmare to try and explain.

Aside from the complaint here, we (at F&L) have a lot of folks who are new to MUSHing, and have had decent retention, by actively helping and explaining.

[faraday]

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

@faraday All of the things you responded to are a problem with /documentation/ not coding. You can change the documentation, get people pointed in the right direction so they know of the + commands and then... guess what? Your whole UX 101 thing is solved.

Done.

It's all about presentation and documentation rather than what the coded command /is/.

Actually, documentation is widely regarded as the very last line of defense for UX. If your UX is so poor that you require the documentation for basic operations, you've failed.

[Lithium]

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

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

@faraday All of the things you responded to are a problem with /documentation/ not coding. You can change the documentation, get people pointed in the right direction so they know of the + commands and then... guess what? Your whole UX 101 thing is solved.

Done.

It's all about presentation and documentation rather than what the coded command /is/.

Actually, documentation is widely regarded as the very last line of defense for UX. If your UX is so poor that you require the documentation for basic operations, you've failed.

No.

This is wrong.

There absolutely /has/ to be documentation because we must assume that there will be people connecting who are unfamiliar with the whole genre. There are those who also will need documentation for the various commands. This is a simple fact of life.

There is no such thing as a system that is completely intuitive that /everyone/ will get and be able to use instinctively. It just doesn't happen. With /any/ code base. The documentation may be in a newbie start sequence, a guide, or just room descriptions but instruction is /absolutely/ required because there is the possibility of someone completely new to the genre showing up.

Because we all must code our own stuff to fit the game we are making, there is absolutely a requirement to document those commands just so people know /how/ to play the game.

Documentation is not some evil thing. /BAD/ documentation sucks. /GOOD/ documentation is awesome.

[ThatGuyThere]

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

@ThatGuyThere 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.

Yes but most of the conversation in this thread is how to make things simpler and more newbie friendly not on expanding functionality. If it becomes a choice of drawing new players or retaining functionality I have now it is a sucker bet which one I vote for. Create a "who" that I can with switches or however get both results sure great, but odds are one of the versions we have now will just get whacked and we will be left with less functionality not more.

[faraday]

@Lithium I didn't say documentation was evil or unnecessary. But I would challenge you to find a UX book on the planet that tells you to fix UX problems with documentation. (And I've read a lot of them.) Your #1 goal with software is to make it as intuitive as possible so the documentation is unnecessary. When was the last time you cracked open the manual for a PC or web app?