My WIP menus extension

I’m doing a retake on Emily Short’s venerable Menus extension. My rewrite is pretty much a total overhaul which is going to be a new extension I hope people will want to use. I’ll tell you about it and then see if you have any comments.

Its overriding principle is - no more moving a cursor up and down to choose things. Every choice on the screen should be chooseable in 1 keypress. I had the beginnings of this system in Six’s help menu.

The default choices are labelled 1-9 (EDIT: and 0) then QWERTYUIOP (first row of letters). This is because I hate extra keypresses, and it’s also friendlier to anyone trying to do it by voice, sparing you from saying things like ‘up arrow, up arrow, up arrow, up arrow, up arrow, up arrow, enter, (GAAAAASP!)’. That means there are 20 choices by default, which I think is a lot. I haven’t seen a game with that many on one screen. If you want more, you’re also allowed to configure more letter keys to be more topics, though some are reserved for the control keys. F is always Forward, for instance, B is back, etc.

It introduces a pages concept. At boot time, all pages of text in your menus are number from 1-n, like pages of a book. You just have to decide where the divisions are as you build the menus. It’s easy to insert, move and remove entries later because you don’t have to number anything. Pages within topics are also numbered locally, so if you open a chapter in-game, you can see how many pages are in it. You can also see how many pages are in the whole volume at the start, if you want.

The menu structure mimics i7’s. Volume is the top menu, then there can be books, parts, chapters, sections. This means unlike Emily’s extension, you can’t have infinite levels - you can have 5. Though I’d suggest if you nest more than 5 levels in help menus, you might be going the wrong way.

There’s a breadcrumb trail showing your position in the system. You can also jump to the top menu level in one move at anytime, which was not possible with the old extension. But here you can switch to global mode on the fly, in which you can just move forward and back through the globally numbered pages without seeing any menus, like reading a kindle or something, if you want. Also you can switch back from global mode at any time and your position within the menu hierarchy will be reconstructed.

Contextually sensitive instructions appear in the status window depending on where you are.

This is about 90% programmed. I would make it z8 friendly except z8 seems to throw VMPrintBuffer errors really easily on even moderately long text strings appearing in the status line, and I can’t afford that (and depending on what people put in the menu system and their config choices, I can’t control it, either) so I expect to make this extension glulx only.

Something I haven’t done but am starting to consider is recreating the ‘one hint at a time’ mode from the old menus extension. It’s hard for me to do this because it’s my least favourite way of reading hints in the world and I just wish everyone would stop doing it, waaaah! That said, I understand this system may have a decade of useage and people might not want to see it disappear. Atm you can reproduce it in my system by putting hints on consecutive pages, but to reproduce the effect of listing them cumulatively, you would manually have to put the accumulated hints on each page (EG page 3 would contain the text of hints 1, 2 and 3. Obviously this is also wasteful in reproducing text.) Maybe I could add a flag that will print the preceding page’s content as well, hm…

Anyway, any thoughts about stuff that bugs you in theory about this extension, or that you think is awesome, or about VMPrintBuffer errors and z8 compatibility?

EDIT: Also, to try to help with namespace clashes, all the extensions new actions and variables have a prefix, like mc_ (for menu content). I might try to keep any variables that were also in Emily’s extension named the same as they were there for compatibility reasons.

  • Wade

I like one hint at a time mode. Please include it!

Otherwise, awesome. One-keypress menus are a good thing.

Done and done.

  • Wade

I am in favour of this. (The scrolling-menu system always struck me as awkward.)

I have similar plans for the built in menu extension, and I think it would be good if we could work together. I’ve been considering other input systems, and we can probably choose between them with use options.

Dannii, it’s near finished, so I’ll send you a copy once it’s done. Of course I haven’t written instructions yet, but functionally, I just need to squish the hints function back in and fix some of the contextual instructions. The rest is already working.

  • Wade

I suppose this will avoid that GROSS problem with menus repeating over and over in parchment transcripts?

It would help for sure!

Sounds very interesting. If you can have an option for menu choices in alphabetic sequence (A-Z) instead of “QWERTYIOP” that would be my preference.

Hi Zurl. All the letters after 1-9 and 0 are user customisable as is (and in truth, any key that’s used in the user interface) and I can probably add an option to use an A-Z arrangement. The catch is some letters are going to be reserved for controlling the menus:

  • F for forward and B for back. (I also allow the arrow keys, either up and down pair or left and right pair, but I’m making F and B mandatory, again to avoid speech-to-texters having to say 'right arrow’etc, which is more annoying for a single option than just saying ‘F’ or ‘B’.)
  • X to exit the menu system, bookmarking your place
  • M or something similar to jump to the top menu or page 1
  • L or, uh, something more logical, to toggle global mode on and off.

So the thing about going A-Z is that it’s got some holes punched in it - starting at B, then F, etc. I picked the QWERTY set to be free of any of the keys I’ve mentioned and with the idea of a physical logic of all the options being along the top of the keyboard, but obviously I also understand the psychological interest in wanting to go A+. (also, someone may use a DVORAK arrangement : :sunglasses: )…

But I’ve got a psych-experiment feeling, untested en masse, that the thing about choosing a menu option is — you see the option you want. Then you see the key name that’s next to it. Then you press that key. Being a keyboard user, you don’t find it more difficult to process the name of the key because it doesn’t happen to be preceded by the preceding letter in the alphabet or followed by the following letter.

Anyway, if anyone has other observations on this front, let me know.

  • Wade

Edit - Another thing I’ve been trying to do - in choosing the extra function keys like F and B and M and X - is keeping them all at least a key apart from each other physically, to help avoid finger slip accidents. But F and B are also nicely situated so two of your fingers can wiggle on them to move back and forth if you want to use them and not the arrow keys.

Or quertz, which is the standard in some countries (including Germany where I’m from). Or one of the other non-querty layouts that are the standard in some other countries (France uses azerty for example).

Basically what I’m saying is: please don’t hardcode assumptions about the used keyboard layout – not just for the sake of people that chose to use a non-standard keyboard layout, but also (and perhaps more importantly) for those who didn’t.

Right. The extension is written so that every letter key is redefinable in the table. I just have to start going somewhere in the alphabet in the default layout after I run out of number keys, so for now that’s QWERTY, based on its commonality. But if you write a game in a different language, you can alter any of the keys in the extension.

I should say that what is hardcoded isn’t the letters themselves (E.G. ‘F’ and ‘B’) but the menu functions. You have to at least assign a key to Back A Menu, a key to Leap To Top/Page 1, and a key to Mode Change.

  • Wade

I’m inclined to use N/P to keep consistency with old menus. With Esc to go back!

ESC is still go back. I guess I could go back to N and P – but rather than me talk anymore here, I’m about to (like within 20 mins, I think) put up a beta real object you can all criticise. Why talk about a theoretical object when you can talk about a real one? :slight_smile:

  • Wade

This doesn’t seem like it’d be true for blind players.

Downloadable beta attached.

So the author configurable options are set to their defaults in the beta. Instructions appear when you run it.

At the moment it’s just a silly menu of test topics vaguely related to space. They demonstrate the different features available and modes.

Comment on anything you don’t like the look of, placement of, absence or presence of, or that feels/seems weird to you. Don’t forget to try global mode. Also, any bugs you notice. Cheers.

I know it was Easter, but given how suggesty everybody was, I was kind of expecting instant feedback.

What I say now is - hold your paltry feedback! For I have blazed on without you!

The extension is already way better than beta 1 was.

A few things you can expect:

  • the QWERTY idea was nice in theory, but then I saw a menu which didn’t reach far into QWERTY territorty, and it looked like:

1, 2, 3, 4, 5, 6, 7, 8, 9, 0, Q, W

which was just weird. So I killed that idea and it now goes 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B , C etc… up to L. It’s friendly to Zurlocker, it’s friendly to the blind, etc.

  • Ala Dannii, I went back to N and P for next and previous, but you can use the arrow keys anytime.

  • There are many configurable options concerning whether various elements will appear in the status line, main window, or both, or neither.

  • Hint mode is still there. Toggleable options are still there.

  • Menus from the old extension convert pretty easily for the most part, you just glom blank columns to their left. Except hints. I had to make the hints fit into my new pagination system, so the old hint booklet tables (which were a different kind of table to all the other content) had to go.

  • Non-functional keypresses don’t cause a screen redraw in 90% of cases, meaning less transcript clutter.

  • Wade

Why not? Don’t they still have to read (hear) the option they want, and the symbol assigned to it, before they can know what to type, same as in the visual case?

Well, I’m not blind so I don’t know, but my feeling was that blind users don’t scan to the item they want to use and look at the letter next to it, but wait for the item to be read out in order. So if the letters associated with the items were in a crazy order it would be harder to keep track of.

Hey, thanks for making it “ZUrlocker friendly.”
I think the idea of 1-9, A-M is probably good enough for most cases. That lets you use N and P for Next and Previous instead of over-riding F and B for Forward and Back. I have been using Menus by Emily Short and found that to work pretty well (though I believe it uncovered some minor bugs in earlier versions of Frotz for iPad/iPhone, and it definitely felt a bit old school.) To the extent that you’re compatible with the prior system, I am happy to give it a shot in the coming weeks.

Where would I find the latest?