UX: It's time for The Talk
-
@faraday said in UX: It's time for The Talk:
@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?
The UX issue with MUSH starts right at step 1) when you're asked to install this really quirky client designed in the 1990's that doesn't even have proper window managers. Then at step 2) You're expected to handle everything through pure CLI and now any hope of being intuitive has been thrown right out the window.
What is obvious to you may not be obvious to me and vice versa.
-
@Groth Yes, so by all means let's do nothing at all to make things as good as they can be given the limitations of the technology. I've said my peace. I'm out.
-
@faraday Recently. I am very particular about my web apps because so much can be done with them and I must know what it is or isn't going to be accessing. PC documentation, recently, when I was learning a new piece of hardware. Even when just considering motherboard variations reading the documentation for what RAM can be used, what socket is necessary etc is absolutely vital.
Heck even someone not knowing that you have to put the ram into different colored slots for dual channel ram to work could potentially bust a computer.
All of these complaints about UX seem to me to be more complaints about uniformity. There's some desire that every game has exactly the same commands so that once learned they don't need to do any more learning at all.
That isn't going to happen.
As for some commands being monstrous? Sure, absolutely. Depending on the system being converted they're an absolute necessity. Other systems not so much. That depends entirely on the complexity of the system in place because (as was said before) certain games are a port of a table top ruleset which means to make it work sometimes coded commands are complex.
If anything that just says the system isn't a good fit, but if the game theme/type needs that system then that's what it's going to take.
A home made system has a lot more flexibility in that it can be /designed/ to work within the limits of the codebases we're using, which makes commands less monstrous, which makes it easier to use.
Those still require documentation on how to use them to begin with. You still need documentation on the system so that you know how the game /plays/.
There's no really getting around this.
To think otherwise is to assume someone can instantly pick up how to play a tabletop game without reading any of the rules, and be awesome at it. Most of the time that's not how it's going to work. It doesn't even work right in complete GUI games.
Take WoW for instance. For how long did Hunters think they needed INT gear because they had a mana pool? In old school EverQuest how many people refused to allow Rangers to tank for groups while leveling because they didn't wear plate but they had tools for doing so?
In the end much of this whole thread has been arguing two separate things. System. Design.
Many if not most of the 'issues' being attributed to UX are actually systemic in nature. There's no way to do a complete UX revamp without addressing that simple fact.
Many people play these games because they /like/ the system being used, as well as the theme.
As for the code, how many statements are there that people can't even tell they're not using a MUX/MUSH code base on say ARX or BSGU? That means to at least some extent the commands are familiar, and in that respect, just as 'bad' as many other games out there. So.. yay for UX updates?
-
@Groth said in UX: It's time for The Talk:
The UX issue with MUSH starts right at step 1) when you're asked to install this really quirky client designed in the 1990's that doesn't even have proper window managers.
This actually raises a very good question: Why don't we ever see people coding alternatives to MUSHClient with more intuitive functionality?
Like, if I code such a thing will I get arrested?
-
@HelloProject
Serious question: what would you do to make the functionality more intuitive? There's very little you can do to, say, map commands to buttons because all of that is a per-MUSH basis (though you CAN do this with personalized softcode, which some games used to have tutorials on doing). -
@HelloProject said in UX: It's time for The Talk:
@Groth said in UX: It's time for The Talk:
The UX issue with MUSH starts right at step 1) when you're asked to install this really quirky client designed in the 1990's that doesn't even have proper window managers.
This actually raises a very good question: Why don't we ever see people coding alternatives to MUSHClient with more intuitive functionality?
What, you mean like Atlantis for the Mac? Like Potato running on Python?
Like, if I code such a thing will I get arrested?
If you want the love and adoration that @Sparks gets (well, from me at least), then yes, you will get arrested with attention. Windows needs an updated client so much that it hurts.
-
@faraday said in UX: It's time for The Talk:
@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?
And how many of those books are specifically talking about creating an intuitive GUI? Mu*s are command line games. There is no such thing as an 'intuitive' command line anything. It starts and ends with help. About the best you could hope for in that regard would be to have it as a clickable link through something like Pueblo, I would imagine, or putting the help documentation right in the room, which is essentially 'type me'.
I cannot imagine an 'intuitive' way to create a command line anything.
Racism isn't Tinkerbell. It doesn't need you to believe in it for it to exist.
-
@Bobotron said in UX: It's time for The Talk:
@HelloProject
Serious question: what would you do to make the functionality more intuitive? There's very little you can do to, say, map commands to buttons because all of that is a per-MUSH basis (though you CAN do this with personalized softcode, which some games used to have tutorials on doing).Sane tabbing, as someone noted. Actual functional goddamned URL clicking that doesn't require a MU to enable it. A command log that doesn't need shadow commands to clutter your window just so that you don't lose a command you entered. A GUI that you can't accidentally fuck up because you accidentally moved it and then things got stuck in some crazy ass way. Removing the random features like that shit where you're suddenly typing in reverse that I then have to remember how to shut off.
I'd probably also build in a more intuitive logging system. MUSHClient has very good and programmable functionality and such, but it's not easily customizable unless you like legitimately know what the hell you're doing. I'd also try to make it easier to pop out channels to new windows. MUSHClient has this functionality, or at least I know a plugin did, but it's not easy to do, I'd want to make it easy to do. That along would significantly improve logs, in my opinion. Also maybe incorporate some intuitive material design into all of this so that it's not like dealing with a relic from the 90s.
There's probably plenty more that can be done that I'm not even thinking of at the moment.
I again don't doubt many of MUSHClient's features, but they're clunky unless you go into it like "I'M GONNA MASTER USING THIS CLIENT!!!". I want to simplify a lot of shit, because MUSHClient can do a lot of shit that's just difficult to figure out how to make happen without a whole goddamned tutorial.
-
@Thenomain, I really do think he must have you on ignore.
@HelloProject, let's take this piece by piece I guess:
- Define 'sane tabbing'.
- Potato, among others, has clickable URLs by default. I would almost bet anything Atlantis does too.
- Re: Shadow Commands - what? I don't even know what that means, but ctrl+up, ctrl+down, and Ctrl+z are all things in Potato.
- I have no idea what you've been doing to create GUI issues like that, but Jesus, dude. I've been doing this a couple years now and have never done that. Like... I think you have to be seriously trying to mess it up like that.
- More Intuitive logging system -- okay, that's a good start. I can live with that.
- Pop out spawns and other such -- @Sparks has a whole thread on this already. There are good ideas there.
- Incorporate intuitive material design -- what? You keep talking about a relic from the 90's, but you haven't so far mentioned what is relic-y about it. Talk to us. This whole system is a relic from, what, the 60's, 70's?
Most people don't use most of the features of any client. Like... fact. They have ten million cool things they can do, but it's like... grandma types a note in MIcrosoft word, prints it, closes it. That's about the same level that most users get with their client.
And if you think MushClient is bad, do this on TinyFugue. I dare you.
Racism isn't Tinkerbell. It doesn't need you to believe in it for it to exist.
-
@Derp Or trying to play a mud on raw telnet before zugg built zMud. Heh.
I used TF, but I have no real good feelings about it. When I found SimpleMU I used that forever until recently switching to Potato.
These are clients though, and I agree, I have no idea how the heck they are breaking mushclient like that...
-
@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.SYSso clearly brings to your life. -
@Derp said in UX: It's time for The Talk:
@Thenomain, I really do think he must have you on ignore.
I don't have him on ignore, I just have never tried Potato because I didn't know it was a Windows client (I never looked into it, I probably lumped it in with something else).
@HelloProject, let's take this piece by piece I guess:
- Define 'sane tabbing'.
You know, like, tabs that you can actually use like modern GUI tabs, like literally any client with tabs lets you do. Pull one out into a separate window so that you can, GASP, look at two MUs without opening up an entirely new instance of your client. Or change the order of your tabs, just, super, super basic stuff these days.
- Potato, among others, has clickable URLs by default. I would almost bet anything Atlantis does too.
I've never used Atlantis because I've never had a Mac, and I assumed Potato wasn't for Windows for reasons I'm not entirely sure of.
- Re: Shadow Commands - what? I don't even know what that means, but ctrl+up, ctrl+down, and Ctrl+z are all things in Potato.
You have to turn "command echo" on in MUSHClient in order to enable your input history. Which means that every single thing you type creates this sort of "shadow" input right behind it. It makes no goddamned sense that you can't have input history without enabling that.
- I have no idea what you've been doing to create GUI issues like that, but Jesus, dude. I've been doing this a couple years now and have never done that. Like... I think you have to be seriously trying to mess it up like that.
I don't know either, but the random shit I've accidentally made MUSHClient do have made me wonder why the hell any of these things are features. Who needs the feature of "type words in reverse"?
- Incorporate intuitive material design -- what? You keep talking about a relic from the 90's, but you haven't so far mentioned what is relic-y about it. Talk to us. This whole system is a relic from, what, the 60's, 70's?
Just, the client look, feel, and general way that it functions, it's like using ancient 90s technology. I understand that our hobby is old as shit and predates me even knowing how to pee into a toilet, but it wouldn't hurt to modernize the look and feel of the client. This is something I'd feel fairly capable of.
Most people don't use most of the features of any client. Like... fact. They have ten million cool things they can do, but it's like... grandma types a note in MIcrosoft word, prints it, closes it. That's about the same level that most users get with their client.
The reason I don't use the features in MUSHClient is because they're really damned hard to use. I'll find something cool once and then just totally forget all the crazy ass steps it took to do it. I don't expect everyone to use every feature, but it'd be cool if some of the more useful features (like the pop out windows) had a super obvious way to access and use them.
And if you think MushClient is bad, do this on TinyFugue. I dare you.
I don't think MUSHClient is bad, just that it's, like, clearly a relic of the past.
Ugh now I sound like I'm gentrifying MUSHClient and I hate myself.
-
You know, I just deleted a post that in part berated you for being unhelpful, using you as an example of what happens when people push for change via complaints then complain when people don't cater to them. Surprise! People don't cater to assholes, and it makes it harder to do the right thing!
This is me changing my mind and making a post just to point you out as someone who may know what they're doing but has no interest in helping the hobby.
When you get this way, you are no constructive, all criticism. Go you.
That is all.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
@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 --helpand 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 pullis not the opposite ofgit push. No, the opposite ofgit pushisgit 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.
-
@Derp said in UX: It's time for The Talk:
I cannot imagine an 'intuitive' way to create a command line anything.
Proof by lack of imagination…
The very first book I read on what would later be termed "UX" was called something like Human Factors in Computer Interaction. It was written in either the late 1960s or the early 1970s. I read it in the early 1980s, long before everything and their dog had GUIs.
It had three chapters or so devoted specifically to how to structure command systems so they could be learned quickly and be built up upon from easily-learned basics.
It amazes me how little of a sense of history programmers and programmer-wannabes have given how little history programming has as a discipline. Electronics engineers are familiar with history that stretches back something like two centuries. Mechanical engineers have to learn a history that stretches back to the dawn of civilization. Software developers have about 70 years of history--tops!--to concern themselves with and are utterly fucking ignorant of anything that's older than six weeks.
-
@Thenomain said in UX: It's time for The Talk:
This is me changing my mind and making a post just to point you out as someone who may know what they're doing but has no interest in helping the hobby.
The hobby has absolutely zero interest in being helped. Look in this thread: a bunch of grognards being told "you know, this could be made simpler" are frothing at the mouth about how it's ABSOLUTELY ESSENTIAL that there be bizarre prefixes in front of commands because ... REASONS! DIFFERENT, CONTRADICTORY REASONS!
This hobby is dead.
So I amuse myself by poking at the grognards and watching them say utterly idiotic things from a perspective of complete ignorance. It passes the time.
-
re: Intuitive command line.
I don't know if we count MUDs and stuff as a command line interface? but the thing is, MUDs are very intuitive once you get the basic jist of how they work.
Like, when I first started playing them, I started to realize how the commands work, because I picked up on the general pattern. Like, no tutorial actually told me to type "open door", but because of how everything else worked, it just made sense to type that, and it worked.
Not every game was that intuitive, but this is just to say, being text doesn't instantly = no intuitive design.
-
@WTFE said in UX: It's time for The Talk:
@Thenomain said in UX: It's time for The Talk:
This is me changing my mind and making a post just to point you out as someone who may know what they're doing but has no interest in helping the hobby.
The hobby has absolutely zero interest in being helped. Look in this thread: a bunch of grognards being told "you know, this could be made simpler" are frothing at the mouth about how it's ABSOLUTELY ESSENTIAL that there be bizarre prefixes in front of commands because ... REASONS! DIFFERENT, CONTRADICTORY REASONS!
It's easy to pick and choose what you want from noise. I've been picking and choosing more interesting iterations of discussions, watching movement made not on this thread but seeing how people react to the changes that have been made. You've specifically ignored my agreeing with you in order to wank all over the parts you don't like all for your own ego.
Grognard is you.
This hobby is dead.
Then get out of our way to plant flowers in its corpse and make something of it. You know nothing, Jon Snow.
So I amuse myself by poking at the grognards and watching them say utterly idiotic things from a perspective of complete ignorance. It passes the time.
As you've been a teacher, I find your attitude toward people making mistakes and learning from them reprehensible. If you're not interested in education, then get out of my attempt to find a solution and be a grognard in the Hog Pit where your attitude belongs.
-
@WTFE said in UX: It's time for The Talk:
The hobby has absolutely zero interest in being helped. Look in this thread: a bunch of grognards being told "you know, this could be made simpler" are frothing at the mouth about how it's ABSOLUTELY ESSENTIAL that there be bizarre prefixes in front of commands because ... REASONS! DIFFERENT, CONTRADICTORY REASONS!
This, the bold, is you asserting via hyperbole something no one has ever said; necessary yes, essential is a word I don't recall using or seeing used, fine difference. Starting to feel like arguments between MUD and MUSH all over.
Some have said there was reason to distinguish hard and soft code and remains to be a reason (it will very from game to game). I've said I look forward to what's to come. I'm a fan of Ares I can't wait to see what themes are spun off this system. Do I think it should be the only system. No. The same reason there shouldn't be one MUD or one MUSH. MUD was static, you had to know hard code or figure it out, MUSH opened some doors for variability and gave instructions (help files) for how to do this. Will new interface and new Mu*/web-based interface change things. Probably, probably in good ways, will you bitch about it. You already have, because going to hard puts the system back to static, whatever the designer puts into the system is there unless folks learn a new version of code. And as hobbyists, most of us, who don't code or compute for a living, we lack the interest to spend years learning again.
That + was added and some folks enjoyed that distinction happened. Not out of crappy design as you call it. That they didn't use the hardcode to add to that .txt help file and make it all system help versus separate +help is just what it is. It became easier I imagine to write soft code for some, because again as a hobbyist, many that do not code for a living, they learned code in the system and didn't want to spend years again learning hard code.
This hobby is dead.
I imagine someone said this about MUDs when MUSH happened, and look, MUDS are as ever popular as they've always been, weird. I imagine in some way, MUSH will remain the 90s tragic vampire writers who love prose over game system, I'll probably remain in that boat, and these developments of making simpler Mu* specific game systems and focusing on hardcore again for easy port and adaptability may open a few doors. Will it attract new players by the boatload; probably not.
No matter how shiny the box, there will still be learning curves. Dealing with other arguments like pose order vs 3pr, dealing with the game system 'dice' are more a guideline vs following the the dice where the roll, is it a 'game' or an 'interactive story telling system' where story is more important than fate of the dice. There are many more hurdles for new players aside from UX.
I'm just a surge protector doing my job, sir.
-
Your answer is far more calm and logical (and more awesome) than mine, but I think we should both admit that we're saying this not to change his mind, but to educate others on @WTFE's flaws. He is shit-posting. He has said the hobby is dying for over ten years. Even as Wora and Soapbox have changed around him, he hasn't. The irony.
So my post was an Open Letter to Everyone: Read these posts, file away the information, ignore WTFE's cretin persona, smile politely and nod, continue with being constructive.
