CLI. Command-Line Interface. That is, how you interface, how you give the system commands. It's a very specific technical term. You did not use a CLI to type your reply. So yes, he did say that he did not believe a CLI is necessary. He's almost certainly right.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos
@Thenomain Note: Roll20 has a CLI as well as buttons. Almost anything you can make a button for you can also input as a command. Especially when it comes to rolling dice but it's not /only/ a CLI.
This again though, is not only a change in code base, it's also a change in programs, gui, etc.
It's also one of the things I said would need to be done before there could be an entire UX overhaul. A complete change in code base.
Hello! Long time listener, first time caller...
@Lithium said in UX: It's time for The Talk:
@Thenomain Note: Roll20 has a CLI as well as buttons. Almost anything you can make a button for you can also input as a command. Especially when it comes to rolling dice but it's not /only/ a CLI.
This again though, is not only a change in code base, it's also a change in programs, gui, etc.
It's also one of the things I said would need to be done before there could be an entire UX overhaul. A complete change in code base.
Not... necessarily.
The issue is people are looking too far up at the 'big picture' and not toward the middle of the conceptual design.
Will it be nice to have a GUI interface to a mush? Absolutely.
How about a web page interface with the mush? Absolutely.
Will this require a top down rewrite to make happen? Not... necessarily.
It will take thinking outside the box and finding a way to do external tags to and from the mush to send async data to and from a mush to an outside application.
Can this be done? Absolutely. A lot of applications do this already, and they're nothing more than an extensive TCP/IP engine, so why can't mushes?
The answer. Of course they can. It just takes coding to wrap the feature set around this. Then once the feature set is done, hand it off for others to interface to it who have a bigger understanding of GUI, or html tools, or what have you.
I know my limitations. While I can keep up with most people at the back end development, I would not be the best at GUI design. I've not done that type of work for 17 years. And HTML I've rarely had a reason to work with. On or off the job. So no, I'm not the right person for an HTML or GUI front end.
But I can provide the tools to allow others the ability to do it, and that's what I'm doing.
There's no reason others who design codebases can't do the same.
@Ashen-Shugar said in UX: It's time for The Talk:
It will take thinking outside the box and finding a way to do external tags to and from the mush to send async data to and from a mush to an outside application.
Can this be done? Absolutely. A lot of applications do this already, and they're nothing more than an extensive TCP/IP engine, so why can't mushes?
The answer. Of course they can. It just takes coding to wrap the feature set around this. Then once the feature set is done, hand it off for others to interface to it who have a bigger understanding of GUI, or html tools, or what have you.
It's really easy to set things up to send data to and from the mush to an outside application. However if we're going to change the mush protocol and require new clients to be written, why do we even stay with telnet? If we switched from telnet to http/json we could have smart clients who are given information as data rather then raw text. It would know what represents the exits, what represents the players, what represents a pose and what's a command echo etc.
What is obvious to you may not be obvious to me and vice versa.
@Groth said in UX: It's time for The Talk:
@Ashen-Shugar said in UX: It's time for The Talk:
It will take thinking outside the box and finding a way to do external tags to and from the mush to send async data to and from a mush to an outside application.
Can this be done? Absolutely. A lot of applications do this already, and they're nothing more than an extensive TCP/IP engine, so why can't mushes?
The answer. Of course they can. It just takes coding to wrap the feature set around this. Then once the feature set is done, hand it off for others to interface to it who have a bigger understanding of GUI, or html tools, or what have you.
It's really easy to set things up to send data to and from the mush to an outside application. However if we're going to change the mush protocol and require new clients to be written, why do we even stay with telnet? If we switched from telnet to http/json we could have smart clients who are given information as data rather then raw text. It would know what represents the exits, what represents the players, what represents a pose and what's a command echo etc.
That's exactly what I'm going to do. I'm making an API that hits a separate port that allows HTTP GET and POST responses to PULL and PUSH data into and out of the mush.
Syntax via curl as a rough example (and yes, this is currently a working example on my dev site as I work with this):
curl -X POST --user "#123:MyPassword" -H "Exec: &FOO #345=bar;@emit whee;page wizard=test" http://mymush.com:12345
In the example, #123 is the dbref# you want to interface with (which can be room, exit, player, or thing, any valid dbref#), the MyPassword is the SHA2 hashed password for the API handler for that object (different from @password). It also defaults to localhost only unless you specify the API IP's (wildcarded) allowed for that dbref#, and it requires an API @power to work. The port 12345 is a separate port from the main mush port, and tags the connection API.
Using -X GET will work with functions only but should allow you to fetch pretty much any data within the game. Return values will be in a header -H "Return: <value>"
But that's the general design flow as it stands right now. Still a lot of tweaking and work, but the general under-hood work is already done. It uses headers only (no data), and uses standard HTML send/responses so anything that encapsulates url should work with it. So a fully working API engine.
@HelloProject said in UX: It's time for The Talk:
I don't really understand the hostility towards wanting to simplify something. To me it suggests at least a baseline level of defensive elitism that embraces the barrier to entry for new people into the hobby.
I'll be the first to say that "paying your dues" and learning how to deal with stuff that shouldn't be dealt with in the first place is bullshit. I've said repeatedly that not every game needs to be made with people new to the hobby in mind, because that's not really the intent of every single game.
Yeah, MUs have a terrible interface and format. A lot of people have been working for years to address it, so the only hostility I think you're seeing is by you totally ignoring that and speaking from a position of ignorance by calling people lazy without acknowledging their work, particularly when you just haven't done that work yet at all. Making a board post talking about a problem everyone knows exists is fun as an intellectual exercise, but I immediately think, 'sure, and?' since like... where's your new GUI that you've made and put on github for everyone to use. If you wanna dump in thousands of hours to give a shot at it, everyone will appreciate it, but if you aren't doing that work, then you aren't saying or doing anything new.
And I don't mean this unkindly, but if you put the work into it, you will always get more players than you can possibly want, as long as you invest the effort into making something fun and accessible. My playerbase is like, ten times what I wanted. I did not set out to make a big game at all, because it's a lot more fun to hands on GM for people than be an administrator for other GMs. Of course I want to make the game more accessible, but there's a damned good reason I haven't put out ads for the game in RP places that aren't MUs- there's simply no way I could ever support the amount of players that come in with the same experience I want players to have. I mean, maybe you'd enjoy being the head director to 10 senior GMs that each then oversee 10 other GMs and never, ever have any personal interaction with players if you are running a metaplot game for 2000 people, but I sure wouldn't. UX streamlining is a great goal but I'd much rather focus on providing the best experience to the people I have than inflating a count, and that's coming from someone with like 300 active players in a game with a very active metaplot.
some fucking idiot who people only like because he's good at taking credit for the work of everyone under him, just like every other fucking L&L headwiz.
I scrolled through over two dozen posts just to say that, given that this has devolved into insults, I've lost interest in reading.
@Rook said in UX: It's time for The Talk:
I scrolled through over two dozen posts just to say that, given that this has devolved into insults, I've lost interest in reading.
Then you stopped too soon.
Without making this thread, I wouldn't even know half of the things that are even happening, beyond the scope of what I know from my experience as a player.
I'd rather be wrong and learn something than ignorantly try to solve problems blindly while having no clue of where to even start on solving them. With this thread I actually have gotten a huge idea of what things people are trying to solve and what direction one would even go in on trying to solve certain issues.
Some people getting a bit angry, or some people constructively saying "Actually you're wrong", is not like a massive deal.
@HelloProject said in UX: It's time for The Talk:
Without making this thread, I wouldn't even know half of the things that are even happening, beyond the scope of what I know from my experience as a player.
I'd rather be wrong and learn something than ignorantly try to solve problems blindly while having no clue of where to even start on solving them. With this thread I actually have gotten a huge idea of what things people are trying to solve and what direction one would even go in on trying to solve certain issues.
Some people getting a bit angry, or some people constructively saying "Actually you're wrong", is not like a massive deal.
I honestly don't think this is so much people getting angry, as like... these are things that plenty of people have talked about way more specifically than what's being talked about here.
For instance, the client issue was described as 'relic tech from the 90's'.
Ok, cool.
What, specifically, about it do you think is relic tech from the 90's?
Or, even more helpfully, show us an example of things that you think would work better than what's already out there?
A lot of what's being discussed is cool and all, but it is seriously lacking in the department of specifics. And computers (and the people who work with them) don't do vague. Give them a specific thing to do, like, with a great amount of detail on
And they will create you something of beauty.
"I don't like it, it could be better," is ... well, just unhelpful, you know? 'More intuitive'. Show an example of what a system you've found to be more intuitive is (an actual, specific example, not: MUDs are way more intuitive. That helps nobody). Tell us about how you would change the look and layout of the client stuff to make it 'not relic tech from the nineties'. What menus would there be? How would they be organized? Etc.
This is the conversation where specificity is key, and we rarely ever get it, so Those Who Do end up spinning their wheels because they rarely think in Vague. People who think in Vague become artists, not computer scientists.
Racism isn't Tinkerbell. It doesn't need you to believe in it for it to exist.
Multiple people have responded with a variation of what you responded with, and then I responded with more specifics, and then we had a productive discussion.
I understand that it's a long thread, but I just wanted to point out that I've addressed this a number of times already.
@Ashen-Shugar said in UX: It's time for The Talk:
@Lithium said in UX: It's time for The Talk:
@Thenomain Note: Roll20 has a CLI as well as buttons. Almost anything you can make a button for you can also input as a command. Especially when it comes to rolling dice but it's not /only/ a CLI.
This again though, is not only a change in code base, it's also a change in programs, gui, etc.
It's also one of the things I said would need to be done before there could be an entire UX overhaul. A complete change in code base.
Not... necessarily.
The issue is people are looking too far up at the 'big picture' and not toward the middle of the conceptual design.
Will it be nice to have a GUI interface to a mush? Absolutely.
How about a web page interface with the mush? Absolutely.Will this require a top down rewrite to make happen? Not... necessarily.
It will take thinking outside the box and finding a way to do external tags to and from the mush to send async data to and from a mush to an outside application.
Can this be done? Absolutely. A lot of applications do this already, and they're nothing more than an extensive TCP/IP engine, so why can't mushes?
The answer. Of course they can. It just takes coding to wrap the feature set around this. Then once the feature set is done, hand it off for others to interface to it who have a bigger understanding of GUI, or html tools, or what have you.
I know my limitations.
I mostly code in MUX, I am self taught and have no formal code training at all.
I work within the tools of that platform, because it's what I know. My limitations are much sharper than yours, Groths, Theno's, Faradays, and who knows how many others.
So within my tools, I code as best I can. The answer for me is to code commands that are readily accessible and easily explained.
Even the tools you just explained adding to Rhost are not something within the realms of many code bases and thus, beyond my purview. To me that practically /is/ a top down re-write because it's languages and skills I don't have.
So I admit to being wrong about certain aspects of my posts, but to my perception that is still the truth. That is my reality because I am not a psychocoder, nor versed in multiple languages.
I noticed I was mentioned, then realized that was a lot of pages ago... 
I agree generally on there being opportunities to improve on UX in these games, but as usual it depends on the goal with your game. In Evennia's case we see people both from the Mud and Mush worlds (as well as some other sub genres). Some can't wait to replace Evennia's "mux-like" defaults for something they deem better in their view. Others instead complain that Evennia is not similar enough to their game of choice and do their damndest to reverse- port it.
Now, in Evennia's case the user can by default alias commands they don't like to something they prefer ( including remapping inputs, defaults etc), and store that with their player account. So at least in theory this allows users to make their ui experience more suitable to their tastes without coder intervention. Then again, the same is possible in most respectable clients so it's hardly revolutionary.
In the next Evennia version we are following Ares' lead and are allowing you to ignore prefixes you specify. So unless you explicitly create a command @desc, but call it just desc, then you could use @desc, +desc etc and it would all be identified as the same command. A small, but practical way to sidestep the legacy of those commands while retaining familiarity for the old hands (kudos to @faraday for the idea).
With the availability of web clients, I can't help but think we have only touched upon the possibilities with making awesome UI:s for this genre of games. Like @Ashen-Shugar I'm not primarily a front-end guy, but it's something I hope to explore further.
.
Griatch
I'm exploring front-end stuff more and more, since I'm pursuing it as a career. When I get better at it, I'll be happy to contribute ideas and such. And I'm using Evennia for my first MU, so I'm sure I'll have ideas.
@HelloProject That's awesome! Our current plan for expanding our web client gui is found here in our wiki if you hadn't seen it yet.
.
Griatch
@HelloProject said in UX: It's time for The Talk:
The point is, the more stuff you're gonna pile into a game, the lower the difficulty of actually using and figuring out how to use it needs to be. Think about how someone who has never been in a MU before would interact with your code. My first MU was Dragon Ball Evolution (they named it that before the shitty movie came out), a MUD. Everything made sense after a very short while.
This reminded me of what The Angry GM said when explaining why psionics suck in D&D: "Remember, complexity is the currency with which you buy depth. Complexity isn’t inherently bad, but complexity that doesn’t add depth is bad. "
Yeah, a drive-by referencing OP in a 14 page thread. Sue me. (SU* me?)
The dude from Extra Credits said the same thing.
I wonder who originated the quote, or if they're the same person (I've never read The Angry GM, but heard of them).
Either way, yeah, this is advice that I think people really need to keep in mind.
What @Lithium talks about is buy-in. People may remember the thread where we take @Griatch to task (fairly? unfairly? peanut brittle?) for not making Evennia friendly to non-coders. @Faraday is making Ares far simpler and easier to learn by looking at examples, while there is a coder who is writing a gigantic system for Evennia to allow more familiar in-game scripting. This is how most non-coders learn to code, via example and lead.
Bringing this back to the UX discussion, leading by example is fantastic. Building on what has come before to improve. I'm currently agonizing over a MUX command that I need to expand in a way I didn't plan, and I would rather spend a day or two agonizing and a day or two re-writing some code from scratch rather than do the easy thing, because the easy thing makes it more complex in a way that I don't think is intuitive or easy to remember.
To expand on @Jim-Nanban's game-design quote, there's another popular design quote, "Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away."
Also, in complex design, remember that a little redundancy means that people can decide how they want to approach it, and therefore will make it more approachable.
@HelloProject Angry usually sources his quotes, so that must be well-known in game design circles. He plays up the one-true-way-ism, but if you stick around you'll notice he's winking while giving some of the best explanation you've ever heard.
Another thing he brings up which is relatable is learning the core mechanic. Once you realize that just about everything in D&D is basically d20+Ability Bonus+Stat Bonus, you can make rulings instead of referring to rules. Just like on a MUD it's "verb action" or on TinyMUX it's "+verb[/option] target[=change]" you can make educated guesses on syntax versus reading +help file treatises. And it's when someone screws up the pattern--like +verb change=target/stat or saving throws or damned grappling horseshit mechanics--that things go haywire.
These are good points that I didn't consider. That consistency of patterns rather than making things crazy and all over the goddamned place (as is typical) might be just as intuitive as simplification.
CLI. Command-Line Interface. That is, how you interface, how you give the system commands. It's a very specific technical term. You did not use a CLI to type your reply. So yes, he did say that he did not believe a CLI is necessary. He's almost certainly right.
