Webclient brainstorm

Griatch edited this page Jan 23, 2017 · 12 revisions
Clone this wiki locally

Ideas for a future webclient gui

This is a brainstorming whitepage. Add your own comments in a named section below.

Relates to the activity happening relating to the Webclient extensions task #614.

Griatch Jan 23, 2017

These are my ideas for the functionality of Evennia's webclient in the (possibly distant) future. It assumes the webclient options have been implemented as per #1172.

Mockup 1

The idea of the GUI is based around panes (a "window" feels like something that pops open). These are areas of the window of the type you would see from a javascript library like Split.js. Each pane has a separator with a handle for resizing it.

Each pane has an icon for opening a dropdown menu (see next mockup image).

Above image could show the default setup; mimicking the traditional telnet mud client setup. There should be at least one input pane (but you could add multiple). The Input pane has the icon for launching the main webclient options window. Alternatively the options icon could hover transparently in the upper left, "above" all panes.

The main webclient options window should have an option for hiding all GUI customization icons (the draggable handles of panes and the dropdown menu) for users who does not want to have to worry about changing things accidentally. Devs not wanting to offer players the ability to customize their client GUIs could maybe just set it up the way they want and then turn the gui controls off on the javascript level.

Mockup 2

The dropdown menu allows for splitting each pane horizontally and vertically.

Mockup 3

Each pane is "tagged" with what data will be sent to it. It could accept more than one type of tagged data. Just which tags are available is different for each game (and should be reported by the server).

For example, the server could send the return of the "look" command as

    msg("you see ...", {"pane": "look"})

If one (or more) of the panes is set to receive "look" data, all such will go there. If no pane is assigned to "look", this text will end up in the pane(s) with the "Unassigned" designation. It might be necessary to enforce that at least one window has the "unassigned" designation in order to not lose output without a clear pane target. By contrast the pane tagged with "All" receives all output regardless of if it is also being sent to other panes.

Another thing that came to mind is logging. It might be an idea to tie a given log file to a specific pane (panes?) to limit spam in the log (it might be one reason for having a pane with the "All" tag, for those wanting to log everything). This could also be set in the dropdown menu or in the webclient options window, maybe.

Comments?

titeuf87 Jan 23, 2017

That way of splitting panes seems easy to manage while still being powerful at the same time. It's certainly a lot more flexible than what I had in mind.

This is a quick sketch of what I was thinking about:

=====================
Options           [x]
=====================
help:         [popup]
map:       [top left]
channels: [top right]
look:   [main output]

But that's not as good as Griatch's proposal.

The panes themselves can work differently depending on the content though:

  • channel messages: when someone talks on a channel, the output text needs to be appended to the text already shown.
  • inventory: this pane should clear its output every time the inventory is displayed, so old inventory is not displayed. Also what about dropping items? As long as the player doesn't check its inventory then that pane won't be updated, unless more OOB data is added to track the inventory.
  • help/look: those pane should probably also clear their content before displaying new content.

logging: do you mean have a "save to log" item in the pane menu?

Griatch Jan 23, 2017

It makes sense that different types of panes would have different functionality. I was thinking that something like inventory would be very specific to a given game. But titeuf87 has a point - maybe you can get a rather generalized behavior just by defining if a pane should replace or append to the existing data.

As for the updating of inventory when dropping items, not sure if that can be generalized, but I guess drop/get commands could be wired to do that.

As for logging - yes I picture a "save to log" thing in the menu. The problem is just where to save the log. I think at least for an initial setup, one could maybe set the logging file path in the webclient options and just append logs from all the panes marked for logging to that same file.