Separating UX from Functionality (Design Patterns!)

Sparks

So, since UX design seems to be heavily on people's minds at the moment (see the UX Talk thread), I have a more practical question: what about separating the UX from the functionality?

Some folks don't get bboards (which are modeled after old dialup BBSes in some ways, or maybe Usenet) and would prefer a web-based forum. Others want their posts accessible right there on-game. So why shouldn't we abstract the data? Boil it down into boards and posts, add a reply function if you want to reply directly to a post, and expose the boards and 'threads' on a website?

Then you can have your old-school +bbread or @bb/read type functionality on-game, alongside a phpBB-type web forum. They have the same backing store, the same read/unread flags, the same permissions checks. Just a matter of preference as

Couldn't we do this with other things? @mail/+mail and a webmail interface? One practical example is Arx having +finger type information available on the website as well as on-game, or @faraday putting chargen and combat setup onto the web portal of the game rather than just in-game commands. (Chargen and character application seems a major, major win to move to the web, in particular.)

This is a reasonably common model of development as it is; many will recognize the concept of "models" (data) and "views" (UX). It takes some thought ahead-of-time to separate your backing model from the front-end UX view, but when done right, I think there are benefits to doing so.

(This is heavily on my mind because I'm writing the aforementioned bboard module for Evennia right now, as mentioned elsewhere, and about to move on to a chargen toolkit and some other things. Filling out an Evennia toolbox for whatever future projects crop up.)

Does anyone else think this is a useful expenditure of time, designing things on a pattern like model/view? Are there other patterns you think would work better for a modern MU*-ish game?

SparklesTheClown

I certainly think this is would be useful, especially for bringing in new people from outside the hobby. Making a lot of things like chargen and such, web based, removes a lot of barrier to entry in my opinion.

faraday

@Sparks In principle I agree that that's the "correct" way to do it. I didn't go that route personally for Ares because I have no intention of supporting both a web UI and an in-game UI for most stuff. Chargen is a notable exception. The complexity of supporting two independent views and making sure everything melds together is just... no.

Thenomain

@faraday said in Separating UX from Functionality (Design Patterns!):

The complexity of supporting two independent views and making sure everything melds together is just... no.

Then expose the data through direct methods (external database) or an API.

Easy, now all someone needs to do is write MediaWiki plug-ins, right?

Right?

... Heeellloooooo?

Sparks

@faraday said in Separating UX from Functionality (Design Patterns!):

The complexity of supporting two independent views and making sure everything melds together is just... no.

I never claimed to be sane... <_<

Groth

@faraday said in Separating UX from Functionality (Design Patterns!):

@Sparks In principle I agree that that's the "correct" way to do it. I didn't go that route personally for Ares because I have no intention of supporting both a web UI and an in-game UI for most stuff. Chargen is a notable exception. The complexity of supporting two independent views and making sure everything melds together is just... no.

Eh. As long as you follow a good MVC oriented design paradigm (such as the one Evennia is built upon with Django) you should have a pretty easy time supporting any number of different views.

faraday

Personally I'm quite comfortable and familiar with MVC, but most MU coders are hobbyists. Simplicity is more important that design patterns IMHO.

Compare having everything in a single command handler:

  class FooCmd
      def handle
           parse the input
           do something
           emit something (usually to the enactor)
      end
  end

Versus having a model, a controller, and multiple views. Self-contained is way simpler.

And that doesn't even address having to learn all the web technologies now (javascript, rest API, whatever) on top of the base MU code.

Someday I will do a completely web-based game, but I have decided that trying to support both web and telnet interfaces runs contrary to the design goals of Ares. If folks want to do that with Evennia, best of luck to them.

Sparks

@faraday said in Separating UX from Functionality (Design Patterns!):

Personally I'm quite comfortable and familiar with MVC, but most MU coders are hobbyists. Simplicity is more important that design patterns IMHO.

Compare having everything in a single command handler:
  class FooCmd
      def handle
           parse the input
           do something
           emit something (usually to the enactor)
      end
  end
Versus having a model, a controller, and multiple views. Self-contained is way simpler.

Fair. I suppose it depends entirely on what you're doing. If, for instance, FooCmd is part of a bboard system, you already need a model for the Boards, for the Posts, etc., and so there's no real harm in making both a "commands" view and a "web" view. Similarly, for chargen, you probably already effectively have a model for the character, so there's no reason you can't just make two separate views into it.

For basic commands, it makes no sense, no.

For systems, which are probably going to include something model-like whether or not you actually design them deliberately as such...

WTFE

In general when I start a new project I divide the issues up into several boxes: PD, DS, SI, HI, and NY.

PD: Problem Domain
This is the code for the actual functionality. If you're calculating artillery trajectories, this is where you put your kinematics code. If you're writing a chess engine, this is where you put your move tree pruning. If you're writing control firmware for ABS systems, this is where you link your sensors to your actuators via your PID controller. (This happens to also be the code that is most likely going to require few to no changes even if changing platforms.)

DS: Data Storage
This is where you map the data needed by the PD code into how you plan to persist it. This is where you have your flat file reader, your database integration layer, your file system handling, etc. It may be mildly system-specific: you may need minor changes in file systems when moving from Windows to Linux, say, or from SQL Server to MySQL, but the code here will be generally stable as long as you don't profoundly change your persistence model.

SI: System Integration
This is where you toss the stuff that's not related to data storage but is variable across systems. Your concurrency mechanism maps from your model to the native model here. Your network interaction layers are in here. Even your I/O primitives could be found here depending on the precise nature of your PD.

HI: Human Interaction
Whether command line or GUI or VR or whatever else is dreamed up, you put this into a separate box. If your PD code has any code related to human interaction in it, you've done fucked up and you've locked yourself into a single mode of interaction for no good reason. (Most software, sadly, has done fucked up in this regard.)

NY: Not Yet
This is the box where features that would be cool but that you're not going to put into this release go. Why don't you just toss them out and deal with them later? Because knowing that you're going to put a feature in will have you thinking of how you'll put it in and leave you room in your design for that later feature expansion. If you just toss out the NY features without thinking about how they'd fit in in the future you're opening a can of whoop-ass on your own code base.

Now, not all software has all five boxes filled. An embedded sensor monitor, for example, may not have an HI component at all: its controller will have that. And your HI and PD might be the same thing if your software is, say, a GUI framework library. But in general an overwhelming majority of software would be well-served by using this simple model.

And here's the thing.

Even beginners and hobbyists would be well-served by doing this boxing. Because separation of concerns makes for simpler code bases, not more complicated ones. But it does mean you have to think before you type. Which is the major distinction between "programming" and "coding".

This, @Ashen-Shugar, is incidentally why I don't think there's actually a clash between supporting the CONFIG.SYS-lovers and the WIMP-lovers in properly-constructed software. The issue isn't that it's impossible to support CLI and GUI and whatever in the same program or program suite. It's that most software is written by people who can't imagine that it's even possible.

Rook

@Sparks
@Ashen-Shugar and I started out working on this, but I lost interest for various reasons, none of them really technical. I wroted a threaded BBoard and he and I were talking about externalizing the data to a webstore (probably db) via the hooks and functionality he is building in Rhost. I might pick it back up at some time (at least to externalize game updates, announcements, things like that).

The idea was to web-app the Requests/Ticket system, too.

Sparks

For those who are curious what I meant about doing something as both bboards and and a web forum, here is a short little example.

surreality

@Sparks That is highly neat. I know there was something (TR, I think?) that allowed +jobs to get archived to a BBoard of some kind, but I don't know how current it is or how reproducible it ever is/was.

I'd be curious to know how possible (or not) this would be with TinyMUX, but at this point it's really just idle curiosity.

Groth

@surreality
I'm not too familiar with TinyMux but assuming it has the same database backend support that Penn has, it should be reasonably trivial since all you need to do is make it store the bbposts in the database rather then on a gameobject. It's one of those things we always talked about doing but never got around to implement since there was always other things on the to-do list.

@Sparks
If you made a functional prototype it I commend you. One of the issues with trying to do it within the classical MUSH platforms was that you would need the web forum to insert the posts in, a nice thing about using Evennia is that you can have the web part fully integrated rather then try to hack yourself into phpbb.

surreality

@Groth I know it's possible to integrate mediawiki with TinyMUX in some interesting ways, and there are forum extensions for it, but that unfortunately doesn't allow for things like private forums for job archiving or similar, so far as I know, due to basic mediawiki limitations. (Read: almost everything is public.) Also just not sure how it would handle the extension or read it, unfortunately.

Sparks

@Groth said in Separating UX from Functionality (Design Patterns!):

@surreality
I'm not too familiar with TinyMux but assuming it has the same database backend support that Penn has, it should be reasonably trivial since all you need to do is make it store the bbposts in the database rather then on a gameobject. It's one of those things we always talked about doing but never got around to implement since there was always other things on the to-do list.

On Firan, I wrote an @invision command which let posts be made to the Invision web forum for the game, via the SQL interface. This was used to archive rulings and other stuff; the normal board installation on game was modified to use it for a few boards.

It worked, but you didn't have things like sharing the read/unread state between the two.

It doesn't work against current Invision, I'm certain, because Invision changed their schema; it would need some rewriting.

@Sparks
If you made a functional prototype it I commend you. One of the issues with trying to do it within the classical MUSH platforms was that you would need the web forum to insert the posts in, a nice thing about using Evennia is that you can have the web part fully integrated rather then try to hack yourself into phpbb.

Yeah, the one linked above is the Evennia prototype that I talked about on IRC. I probably want to add a few things (like the ability to flag a spammy board as not shown on web, etc.), And I'm still not sure about monospace font for the post content. But it demonstrates nicely what I mean about doing something on both interfaces.

Lithium

@surreality Re- Jobs to bboard.

I know it can be done with TinyMUX using anomaly jobs. Was something I was looking into setting up as well.

Apos

@Sparks said in Separating UX from Functionality (Design Patterns!):

Yeah, the one linked above is the Evennia prototype that I talked about on IRC. I probably want to add a few things (like the ability to flag a spammy board as not shown on web, etc.), And I'm still not sure about monospace font for the post content. But it demonstrates nicely what I mean about doing something on both interfaces.

I really like it. Generally speaking, the more things shared between web and in game, the happier I am. I think beyond convenience for players, it really does go a great way to making a MU more accessible.

Griatch

@Sparks prototype is indeed looking very cool. There are Django bb apps but this of course has the advantage of being adapted to Evennia - and I guarantee no third party app offers an in-game text-only version of the same thing! Hope you may consider it as an Evennia contrib as some point.
.
Griatch

RnMissionRun

@Sparks said in Separating UX from Functionality (Design Patterns!):

For those who are curious what I meant about doing something as both bboards and and a web forum, here is a short little example.

This looks very interesting. I just started a project to create a Myrddin's style BBS for Evennia but I do not have the expertise to integrate it with a web forum. Am looking forward to seeing the finished product in action!

Sparks

@Griatch said in Separating UX from Functionality (Design Patterns!):

@Sparks prototype is indeed looking very cool. There are Django bb apps but this of course has the advantage of being adapted to Evennia - and I guarantee no third party app offers an in-game text-only version of the same thing! Hope you may consider it as an Evennia contrib as some point.
.
Griatch

I plan to. I have some last cleanup I want to do, maybe this weekend, and then I'll throw it up on GitHub for others to poke at. It was my first major Evennia thing and so probably could stand some improvement.