Posts made by WTFE

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

This sounds very logical and straightforward.

It's purest bullshit when you look at actual UX research.

Countering example: Git. Git has incredible amounts of documentation. Even just inside Git itself do git --help and you get a list of common commands and pointers to complete lists, concept guides, etc. Every piece of information you need is right there in front of you a few keystrokes away.

And yet…

Git is an unusable piece of shit. It has more tutorials, guidebooks, full-on instructional web sites devoted to it than I have ever seen from what is, in the end, actually a pretty minor piece of software development tooling. And the reason for this? Its commands are utter shit.

There are inconsistencies and gotchas at every level in that festering pile of dung. The first one that fucks you up if you're at all familiar with English is that git pull is not the opposite of git push. No, the opposite of git push is git fetch. This may seem like a minor hitch (because it is), but each such minor hitch adds incidental complexity to a domain that has plenty of essential complexity already. (Git's underlying model is powerful, but necessarily quite complicated.) And it gets worse. That pull/push/fetch thing? You can totally fuck up your work if you use pull in place of fetch. And if you happen to use more than one DSCM, you will use pull in place of fetch more than once because literally every other SCM in existence has pull and push as the opposing paired commands. (Now, you can recover your lost work when you fuck it up. Just make sure you make a tar ball of your whole repository because you're now fucking with commands that are even worse in terms of UX, that are rarely used so not likely to be well-understood, and you stand to lose not just your work of the past few hours but potentially all of your private branches.)

And the pull/push/fetch thing is one example. There's entire web sites devoted to illustrating the myriad of "gotcha!" command structures in Git. Some of them are very dangerous gotchas where Git will silently do something that's utterly insane. If that insanity happens at about the same point that Git decides to run the garbage collector on your repository, you can and WILL lose months and months of work.

(There is a reason why I use Git exclusively as a means of downloading code from projects and for nothing else.)

And remember, this is in one of the most thoroughly-documented packages I've seen in ages. Every one of the "gotchas" is lovingly documented. No exceptions.

TL;DR: documentation doesn't make up for shit UX. Good documentation is a necessary component of a good UX, but it cannot replace a good UX.

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

@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?

No, seriously. Enjoy your DOS box. I won't begrudge you the joy that CONFIG.SYS so clearly brings to your life.

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

Enjoy your DOS box.

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

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

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

Then let me explain from history: Because @commands.

I believe the very first +command was Firelizard Mail, an object-driven messaging system from before the days of a Master Room, before user-defined attributes. It was an amazing feat of coding in a limited system, and it eventually became +mail, especially when we got Brandymail.

So we have '@dig', '@link', and all those @-commands which have to do with server-changing functions. Then you have 'page' and 'move' and 'pose' which are all user-facing server commands. Perhaps '+mail' should have been one, but we created a third category: User-created commands.

And it's a category that's absolutely meaningless to the user. The user shouldn't have to give a flying fuck if "mail" is a built-in command or a user-created command. It shouldn't make any fucking difference to the the UX. (If it does, you fucked up the command.)

In part, I've invited this discussion. '+' is silly, but it's silly nowadays, not silly then.

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.

"QUIT IT, you moron!

Accidentally forget the opening quote and ... oh, right. Nothing happens.

... I have no idea what you're talking about here. I suppose that no, this doesn't look familiar.

The retro-explanation for "+" being a good thing was:

Nobody starts a pose with +. So it's a lot harder to accidentally run a fucking command when just trying to RP.

So I alluded to what happens if you pose something that begins with a command (QUIT in this case) and accidentally forget the opening quote. (Hint: nothing.)

And this also flies in the face of the number of built-in commands that don't start with @ or + anyway like look or page or … The "reasoning" is bullshit and is reverse justification for a stupid design decision.

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

Because people need to know where the documentation for this command lives. It's really that simple.

This flies directly in the face of several games I've played where help gave you help for all the commands. Including the built-in ones. And where +help gave you exactly the same help files.

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

NOW you are doing what @HelloProject was talking about. This is thinking like a coder. New players have no way to know what those properties are.

New players shouldn't have to know. That's the entire fucking point! They should know that if they want to have a description for their character they set description me I'm too sexy for my shirt. This can be documented. In about the same way that @desc is, in fact. New users will have a general idea of what "setting" something means. They've "set" the time on their phone or their computer or their VCR if they're really advanced. None of them will know what @desc me= means.

These commands exist, with their own help files, to explain that.

And you can document set and get as well. And you can document description and character generation and a whole host of other stuff in ways that are actually useful. I mean seriously, do you believe new users who've never MUSHed before will think "I know, I'll just type help @desc so I can figure out how to describe my character!"

Plenty of us use &whatever me=stuff, but a newbie doesn'the necessarily know what properties the hardcode already knows versus arbitrary attributes.

help attributes
help universal attributes
help basic commands and attributes
help newbies
help new to MUSH
.
.
.

Any one of which is better than help @desc.

As for the 'common being the default', in many ways, this is already the case.

And in most ways that you encounter when first thrown into a MUSH it is not.

What is 'common' to one player is wholly subjective and vastly different depending on experience and investment.

What is "common" is something that can be trivially identified by monitoring command usage and seeing which patterns show up most often. HCI 101 stuff here, now.

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

As to why + commands work, not only are we A) used to them but B) Nobody starts a pose with +. So it's a lot harder to accidentally run a fucking command when just trying to RP.

This is almost certainly a retroactive explanation.

ahelp anews brief DOING drop examine enter events follow get give go index leave LOGOUT look move news page pose QUIT read rules say score teach think unfollow use whisper WHO with

Any of those look familiar?

"QUIT IT, you moron!

Accidentally forget the opening quote and ... oh, right. Nothing happens. Except a badly uninformative error message. Because commands have syntax and the odds of you matching that syntax in a random pose are negligible.

@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:

1. 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?
2. 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.

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

Sidenote: @WTFE strictly speaking and syntaxical sugar aside. Mushcode has the same lamba support as any other string based scripting language as it can pass along arbitrary strings and call eval()

So leaving aside the part that makes lambdas useful (and you haven't addressed closures) it's just like having lambdas!

Lua:

function addxplus3(x)
  local z = x + 3
  return function (y)
    return z + y
  end
end

add5plus3 = addxplus3(5)
print(add5plus3(3))  -- 11
x = 100              -- what happens when we change "x"?
print(add5plus3(3))  -- 11

MUSHcode:

???

From my reading of it, there's no convenient way to do the equivalent in MUSHcode. Doing that code in MUSHcode would be about as painful and as error-prone as doing the equivalent in, say, Rexx or in C. It's doable in both those languages because ANYTHING you can express in one Turing-complete language can be expressed in another modulo hardware limitations, etc. (if you'd like I'll put up the Rexx version), but it's painful, it's error-prone, and thus it's something that's going to be avoided as a result.

"Store this function as a string and call eval()" (roughly how I'd do the Rexx equivalent) is theoretically very similar to the above, but its the very lack of that syntax sugar is why nobody would ever actually use it.

Syntax is nothing. Syntax is everything. Both statements are true.

No. Bane and the douche who co-ran the previous WORA (who shall remain nameless) did. Oh, and the fact that it really added nothing whatsoever to having WORA itself also kind of ruined it.

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

I think I'll benefit a lot from using Evennia and learning Python rather than doing MUSHCode.

I think this is likely accurate. I can't think of any non-MUSHing advantage to learning MUSHcode. Further, learning MUSHcode is a non-trivial venture that's fraught with frustration and WTFery with very little useful support provided compared to the reams of books and blogs and videos forums and user groups and ... that you can get for Python.

In the modern era of MUSH servers you can, to varying degrees, get to use Python (or other scripting languages) through hacky external language interfaces, but these are slapdash compared to writing natively. MUSHcode is pretty much its own ghetto in this regard.

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

But you likely do have a point with the resources. I guess this is why Evennia exists now. I'm making my game with Evennia.

I really, really, really had high hopes for Evennia, but I found it had a couple of crippling problems:

1. The process for installing it is idiotic. I eventually got an installation sort of running. I think. (I'm not sure if it was properly and completely installed because by the time I finally reached that stage of being able to log in I'd lost all interest in using it.) Even old-school code bases like PennMUSH or Rhost were easier to install!
2. The documentation reads like the documentation at Oracle's site for Java SE. It's filled to the brim with over-engineering and turgid prose that I keep handy on my bedside table for those sleepless nights.

Now for the scale of that installation and documentation problem: I currently code embedded systems for a living. One of the smaller MCUs that I use has over 1200 pages of documentation that was written by engineers. ITALIAN engineers. Who painfully obviously have a few issues with writing in English. In total the chips I use from this company have documentation that exceeds 3000 pages. And that's just the MCUs. Each peripheral device I use has manuals that range anywhere from 20 pages in length to 900. (Many of the "peripherals" are MCUs in their own right that just have permanently-burned firmware.)

Further, for my home usage (not work), I use F/OSS tools instead of commercial ones. Documentation for F/OSS tooling is notoriously terrible and the tools rarely, if ever, are designed to actually work together coherently. My compiler is GCC and my assembler is GAS. (These two work well together, and they both work fine with GNU's link editor.) My debugger is GDB and I use OpenOCD as a bridge between GDB and my chips' debug modules so I can actually flash and debug my code. As an added "fuck you", GDB is scripted in Python while OpenOCD is scripted in Tcl (and the link editor has its own fucked-up scripting format for moving things around).

Just the infrastructure coding in any given project--the code that exists solely to bind together the various tools I have to use in something resembling coherent whole--is typically several hundred to thousand lines of Rexx scripts I cook up for each project (though, to be fair, most of it is cribbed from other projects and I push a lot of common code into a cookbook library).

It's a total fucking mess. And I find it easier than installing Evennia was.

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

As somebody who knows 0 about code, I assume MUSH code is archaic and sort of hack-jobbed, since it varies wildly from game to game, and outside of the copy/paste WoD games or FS3 games, etc, MUs flat out have 'custom code' that somebody just made in their free time.

MUSHcode is a Lisp written by someone who took a Lisp course and didn't really understand it. (He probably got a C+ in his course.) It's a functional language in which user-supplied functions are second-class citizens. (What do I mean by this? Using the results of a built-in function in look like [function(parameter1, parameter2)] where user-supplied functions have to be stored on some object somewhere like this &SOME_POINTLESS_NAME object=FUNCTION CODE GOES HERE and is called like this (using its results): [u(object/SOME_POINTLESS_NAME, parameter1, parameter2)]. What's that? You want lambdas? Closures? BWAAAAAAAAAAAAAAAAHAHAHAHAHAHAHA! He'd have had to have understood those from his Lisp course to have thought of implementing them!

And that's only the lowest level of the problems with the language. The larger scale issues are that MUSHcode resists modularization, so it's actually hard to make shareable code that someone who isn't steeped in the language can use in a "plug and play" fashion. Some attempts have been made at this--heroic attempts whose champions are honoured as they reside in Happy Dale Sanitorium charging up staircases and blowing trumpets--but they really don't work well because out of the box they're pretty vanilla and bland, and customizing them requires, you guessed it, someone steeped in the language. (And because of that resisting modularization thing, using code from more than one source starts exponentially increasing the risk of brought-in code clashing in unexpected and surprising ways.)

Factor into this the added problems that there are three major dialects of the language (Penn, MUX, Rhost) with incompatibilities both subtle and grotesque, that the language was built on a today-bizarre foundation of queued resource management, that the servers all have weird limitations (often based on that queuing system) in unexpected places that requires baffling code to work around, and that until recently code was jealously guarded instead of shared (Rhost once had an NDA you had to sign if you wanted to use it!) and you have a perfect storm of ... well, random hackery and "NIH"-based clusterfucks.

Not to insult anybody or anything, but I'm going to go out on a limb and just say MUD coders are probably better coders, or at least have way more time to code.

Nah. MUD coders just have more access to better tooling for their code bases beginning with the fact that most MUDs are coded in languages for which there are a myriad of resources for learning and a myriad of ways of finding code (that won't break existing code!) to bring in for reuse.

Personally, I find culture variances between muds/MUSHes pretty curious. Little things like how a huge chunk of the MUSH population can't be fucking assed to read the bboard even once a week, where MUDs have forums/etc dedicated to the game and people are commenting about things on the game hourly, nevermind in-game noteboards that get checked p.much every time you log in.

See, that, to me, is one of the turn-offs of MUDding: if you want to play a MUD you pretty much have to dedicate your life to the fucker or get left behind. (By which I mean "killed" of course.)

Well, that and the endless grinding that MUDs seemed to always demand. There was a MUD I tried that advertised itself as "RPI" and bragged about how it was SO ROLE-PLAYING-ONLY! And it was. Even the in-game help was mostly IC. When I made my character I had to interact IC with one of the "helper staff" types (actual IC counsellor positions!) who did a commendable job of guiding me through how to get into the game. Only one problem: here was a typical segment of that help session:

Helper (H): So what kinds of things did you have in mind for your future in our city?
Me (M): Well, I was thinking of learning to be some kind of healer or maybe an apothecary.
H: Commendable choices! Laudable, really!
H (OOC): We really do need more healers. You should get to the sewers and kill rats.
M: (OOC): What?
H (OOC): To get enough experience that you can train as a healer.
M (OOC): <hangs up>

OK, I wasn't quite that abrupt, but that was a serious "wut" followed by a "LOL" moment for me. In this game that prided itself on how IC everything was, beginning characters, each man, woman, or child of them, had to basically start off by going to the sewers to kill automated rats to get experience and money so that they could do the things they ICly (and OOCly, obviously) actually wanted to do.

And that was one of the better MUDs I tried. Bad ones like that Sciorsiecieasceaisareas one (that actually wanted money at one point!) made you micromanage eating. If you didn't make enough money (by grinding, natch!) to buy food or, alternatively, hunt (by grinding, natch!) enough food you died. Travel times were enforced, so if you had to go somewhere to do the grinding you needed to do to live, you could (and I did) die along the way trying to get the food. And this was lauded as "true role-playing" by its advocates when I did the "WTF!?" thing on channels.

So, you know, all that culture shock you had at MUSHes? Guess what happens a lot when people go the other way...

OH GOD NO MY EYES!

(SFW. NSFS.)

@Coin No sarcasm intended. Jains are Nazi assholes.

@Coin said in RL Anger:

If you fly the Swastika as a flag, you're a Nazi.

So, I've added a bit of extra batshit insanity to my life:

That's two different approaches to three-player Chinese Chess.

@Tinuviel said in A Constructive Thread About People We Might Not Like:

For the record, I call United Statesians 'Lower Canadians'.

I call them "Canada's Rejects". Well, the Cajuns anyway, at least.