Terminal Mode

1

Thought I’d start a discussion here on using terminal mode, since I couldn’t find a specific forum for that.

If using it with JAWS, the two most important things to remember is that Alt-Insert-V calls up the Braille View mode where you switch between wrapped, cropped, buffered, translation, annotation, and several other modes. It is supposed to default to the appropriate mode based on context. And the other thing to remember is finding documentation. It’s in JAWS help under multi-line Braille which is a topic under the main Braille topic, and it is followed by Split Braille which also has multi-line information.

To connect the thing, it’s a HID Braille display, and you won’t find Monarch under the list of Braille displays when you choose Add Braille display under Options-Braille.

It’s kind of like a treasure hunt getting it to work. I love-love solving problems like this so it wasn’t frustrating for me, but it could be for others.

If you are trying to figure out what keys do what, remember JAWS and NVDA too have a key describer; Insert-1, the 1 on your regular keyboard, not the numeric pad.

And JAWS keyboard manager and NVDA’s input gestures dialogs will let you add keystrokes, or see what keystrokes are used to activate a particular ccommand. And keystrokes include what you press on the Monarch too.

The most fun I’ve had with terminal mode is looking at tabular data, especially if the columns are narrow. My boss sent me a spreadsheet where all the columns were wide and filled with only text, and that didn’t work so well, but when there are short codes or numbers, it works great. If you create a table, too it makes finding errors faster using the Monarch to go up and down columns. I often use Word’s “convert text to table” feature and need to check the conversion worked as expected and the appropriate data is in the appropriate columns.

My feature request is to turn off the Braille keyboard. When I am reading I often hit it by mistake; it’s so close to the display. That’s a feature I use on my Brailliant. I turn it back on when I need to type regularly in Braille, but since I read more than type, I often keep it off for days.

More later, let’s see what others say.

2

So I was proofing my previous post, after I posted it and noticed I couldn’t pan through it completely. I could pan for the first twenty lines, and after that, it just refused to pan. I think it only panned to what was visible onscreen and not through that entire post. Or JAWS doesn’t know how many lines are showing on the Monarch. Reading Hive posts is a good way to test out the flakiness of panning.

I think one feature request I’d like is one that many programmers’ editors have. It’s a keystroke to move the line that currently has focus to the top, middle or bottom of the display. For example, if panning failed, I could arrow down to the last line read, issue that keystroke and now it would be at the very top of the display. Or if I wanted to see the last ten lines of a document, I’d go to the bottom and hit the keystroke to position my display to the bottom, so that the last of the document that would fit on the Monarch would be revealed.

Interesting, now as I type this, the Monarch display is completely blank; I think JAWS cannot track focuss, or maybe I have to fool with linking the Braille cursor to the system focus. More experimenting is definitely valuable.

3

Hi Deborah! What kind of cable did you use to connect the Monarch? I tried a USB to USB-C and that didn’t seem to work. Thank you!

4

I used a cable that came with the NLS eReader.

5

I also found the cable that comes with the Brailliant works as well.

Seems like with the expense of this device, it should just come with an appropriate cable. I mean, most Braille displays already do.

On a different topic related to terminal mode – I was typing using the Monarch last night, taking notes in real-time during a meeting.
And I noticed I could only see the current line I was typing. And if I panned up, then my cursor moved.
At first I thought it was a Monarch problem, but it was a bug in my own understanding of how Braille works with a screen reader.
Braille can be “linked” what NVDA calls “tethered” to either the system focus or some review cursor or not to anything. I was using JAWS, and Braille was set so that if I moved the Braille cursor, the system cursor also moved; if I moved the system cursor, the Braille also moved.
This worked well when I used my NLS eReader with JAWS and even a Focus or Brailliant. (These displays belong to my employer, I’m not rich!!!)
Anyway, with only one line of Braille I found it convenient to always keep Braille tethered.
But with multi-line Braille, that doesn’t really work. It’s good when editing to have the screen reader set to have Braille link with the system cursor, but don’t move the system cursor when you pan Braille.
Even so, in many applications, if you are at the bottom of some text you are editing, you only see the final line on the display because I don’t think multi-line Braille is still fully implemented, at least when in wrapped mode.
But if I ensure the setting “active cursor follows Braille” is unchecked, which is the default, then I can pan and not move my focus.
Tethering options for NVDA are under Braille in settings-preferences. They are similar, but not completely identical, so it’s best to experiment before you need Braille for something important, such as taking notes when you want to have speech disabled.

I have found the cropped mode works great when tables mostly have numbers or codes, but my coworkers love to prepare spreadsheets full of columns of text. I guess sighted people find it more convenient to use Excel to arrange text rather than Word when it is more like a text database. And Monarch pans of course, but when a column is wide and full of text it would be better if we actually saw only one column at a time, instead of pieces of two or three columns. That could be yet another mode; stay in the current cell.

I have liked that it is easy to jump in to one of the other applications, for example to take notes and return to terminal mode, and honestly, taking notes with one of the native editors is better than trying to use Notepad or Word to do so, especially if you have to jump back and forth in your document.

I also tried writing code using Terminal mode and Visual studio code working with 8-dot traditional computer Braille, and the experience was very, very nice! I’m a hobby programmer, so I don’t have deadlines and bosses to worry about when I’m coding, but if you aren’t that lucky, it can take some getting used to, but if you get things set up right you can scroll through code, seeing where blocks are indented and working more like a sighted person would.

I was working with Python, so I set VSCode to indent tabs by only two spaces to get as much code on the display as possible.

Then, to format it for easier reading for sighted people, I could run it through the “Black” formatter – python people will know what I mean. If you work in another language, it can be useful to have a formatter that makes the code easier for sighted people to read when you need to share it. But with only 32 characters on a line, you want, while developing, to have as much Braille real estate at your fingertips!

JAWS can also be configured to set the number of pixels per space, and though I didn’t need to do that, I’ve found it was useful at other times to track indents.

The Monarch also seems to work well with the actual Windows terminal, that is the command prompt, where you type commands in to Windows. It’s nice to see a larger portion of the screen, but be sure to not tether the focus to follow Braille so you can pan without hassle.

The other thing when writing code or working with the Windows console – the command line – is to set JAWS to line mode for those applications rather than structured mode, and Monarch will automatically be set to wrapped. This gives the best results.

I’ll continue to experiment. I’m taking an advanced python class in January and the Monarch will be at my side and help me master even more!

6

Yesterday, I used the Monarch to present at the APH National coding symposium. I had notepad open with my notes while rehearsing, and was able to pan back and forth relatively quickly.

A few issues I found was that panning is kind of rigid. If for example, I know I have to go down five lines to get to something, the display won’t necessarily pan unless I’ve crossed what is the equivalent of ten lines of Braille. So I converted my notes to HTML and panning seemed to be much more fluid in HTML. So when I actually presented, I used HTML to read my notes.

But ideally, I’d like more fine-grained control. For example if I pressed H to jump to the next heading, it would have been great if now the first line of that heading appeared at the top of the display.

I think we have to rethink how panning works with multi-line Braille based on the current application. It’s going to be different with spreadsheets vs browsing.

Also, and I’ve mentioned this before, there needs to be a way you can ask Monarch to show the current line either at the top, bottom or the middle of your display. There are times you want to review what’s above the current line, or what’s below it or even what’s around it.

I guess all this is controlled by the screen reader, so maybe I should share these ideas with them. I don’t know who to contact though; it’s not like they have a discussion forum.

A last issue is that in most editors, like Word when you want to find some text, the find dialog stays open even after the result is located. This works for sighted people who are looking at the search pane and their document simultaneously.

But with the monarch, you want to be positioned on your search results not in the Find dialog, so you have to press F6 a few times to return your focus to your document. And with the slow refresh it’s kind of painful.

With Visual Studio code, we blind folks have a pending feature request to close the find dialog after a search result is located so focus lands back in the editor. I know this is not a Monarch issue, but it still makes working with most editors kind of clunky if you are jumping around a lot.

It’s one reason HTML works better if you just want to read and search because screen readers can search for a phrase and position you there directly.