Keyword list - proofreading requested!

[JeremyNicoll]

In Firefox it's impossible to read without clicking Fullscreen, and then when one does it scrolls slowly & when one reaches the foot of the text the page (or image or whatever it is) continues on & on. I pressed Esc to get out of full-screen.

Weirdly, a few looks later, it's stopped generating anything - I just get a blinking cursor.


I only went to the foot of the display to find out if you'd explained the meaning of terms like "<n-var>". I assumed "numeric var" but you also have the term "numeric" & it's not clear if there's a difference. I think those should be described at the top of the display.

[JeremyNicoll]

Even odder ... I'm seeing ASC described as "A nunction ..." on the original display but "A function ..." on the full-screen one. Edit: it's intermittent.

See: https://www.dropbox.com/scl/fi/lwwkqvg4 ... h7mwi&dl=0

[DDRM]

Any chance of having it as a text file?

D

[JeremyNicoll]

See my earlier post where I explained that it will be available as a text file eventually (once it's incorporated in a release), although as that file isn't intended for 'human consumption' it isn't nicely formatted into columns, or coloured, so it won't be as readable.

Here, in Firefox, the non-fullscreen display can be magnified or shrunk but only ever shows a small amount of text. I only just discovered that one can make it scroll up/down/sideways with the cursor keys. Maybe you should SAY that is possible?

When one does scroll it sideways one loses the column saying what keyword one is reading about, which doesn't help.

The full-screen display shows more, at least, but still needs to be scrolled sideways. Scrolling is far too slow.

AND .. it's full-screen. So one cannot read any other reference info at the same time, or make notes on anything.

For those who have the time to proof read it, a text file one could load into a text editor would be FAR quicker to read, IMO.

In any case, checking that the formatting, colouring, scrolling etc. are working correctly is every bit as important as the content, so I want it to be proofread as it will be seen in practice, albeit that it will be on a phone or tablet screen not a desktop browser.

If the presentation is a the same on a mobile, i think it'd be hard to use. I'd still (on such a machine) probably prefer text or HTML or PDF.

[JeremyNicoll]

I only just discovered that one can make it scroll up/down/sideways with the cursor keys. Maybe you should SAY that is possible?

Ridiculous!

There is nothing on the page that one gets in a browser that tells one that one is looking through a sort of portal at a large sheet of information; the first impression one gets is that the rendering process somehow didn't work.

YOU had/have the knowledge of how you'd generated the result & how it would behave, but you didn't share that. You just said there was some text that needed proofread. For someone expecting to see "just text" the fact that it was being generated is already peculiar.

No-one normally going to a website, who sees a picture of something expects it to scroll if there's no scrolbars providing a hint.

AND .. it's full-screen. So one cannot read any other reference info at the same time, or make notes on anything.

It's only fullscreen because you chose to make it fullscreen!

But you yourself suggested that people should view it fullscreen, in your very first post on the topic.

But on a mobile device there isn't any possibility of putting anything else in the screen at the same time anyway (discounting that recent versions of Android do support limited split-screen operation).

So what? In the first place you wanted people to proofread the text. Making it difficult for anyone to see the whole text didn't help. Even if you rendered it once, screenshotted that & posted the picture of the whole thing would have made it easier.

If the presentation is a the same on a mobile, i think it'd be hard to use. I'd still (on such a machine) probably prefer text or HTML or PDF.

You've already got access to the full, unabridged, BBC BASIC manual as both HTML and PDF (albeit that the PDF version is for BB4W rather than BBCSDL) so feel free to use those as you prefer.

You're missing the point. You asked us to look at this simple piece of text but told no-one how to make the whole thing visible.

Somehow you don't seem to have grasped that this isn't a replacement or substitute for the full manual, which will always be the best way of accessing information about BBC BASIC. This is an additional one-line-per-keyword summary to provide a quick reference without leaving the mobile app.

No, I completely understood that, right from the start. But you didn't explain how we should use the extremely non-standard viewer.

[JeremyNicoll]

I don't understand that at all, for me it's much easier to read in the form I linked to than as a text file: it's larger (at least, than the default text size I use in a text editor like Notepad) it's formatted into columns, and it's coloured.

I assume the amount of text one sees in the non-fullscreen view only depends on parameters you set, bearing in mind that on my laptop the visible text is only taking up a small propertion (a fifth?) of the screen. Using Firefox's shrink/magnify controls changes the size of the image but not the amount of text displayed.

Incidentally you didn't reply to my pont about no longer being able to see the keywords when one scrolls the view to the right. Here, in the non-fullscreen view I can position it so I can see neither keyword nor syntax info, so it's just a wodge of the central text.

For someone making occasional use of the file to check a single keyword /having/ to scroll the view sideways might not matter, but to proofread the whole thing one has to keep scrolling back & forth, for every line to see both ends and the middle.


In full-screen mode the resolution of the screen presumably does affect how much one sees. May if one has a high-res screen one sees a lot more? My laptop screen is (only) 1600 x 900.

I was about to test whether in full-screen mode one can right-click the image, or select an area to copy it elsewhere ... but the mouse pointer seems to get turned off. I sometimes have an old low-res monitor plugged into the laptop's VGA port; if that's in use having the Firefox window on the primary screen go full-screen makes the mouse unusable on the secondary screen. If I let the BB4W text go full-screen on the secondary monitor then the primary monitor is suddenly mouseless.

Preferring it as a text file is a bit like saying that you would rather write and edit a BBC BASIC program in a text editor than in an IDE with syntax colouring and automatic indentation!

If by "text editor" you mean something as featureless as Notepad, then yes. But a decent programmer's text editor has most of the features of your IDE plus all its other ones. I prefer to learn how to use & customise & program my editor & then use it for (nearly) everything.

I can understand that a text file would be needed in order to print it out in hard-copy format, so that it can be read away from a computer or mobile device, but apart from that I just can't see the value in a text file at all. Sorry.

Suppose one wanted to compare the way you'd worded some aspect of the text for one keyword with someting similar, or not, elsewhere in the list. Unless one accurately remembers where the other instance(s) were one can't find them. In a text editor you can use its file searching capabilities.

[JeremyNicoll]

I didn't say it was "just text". As I stated in the first post of the thread, this 'keywords' app is intended primarily for the mobile (Android and iOS) editions of BBC BASIC. In asking for it to be proofread I wanted to provide the closest experience to reading it on such a device as I could, because that would tease out problems with the interface as well as the textual content.

Yes, /I/ said it was "just text". But if it is /primarily/ for one set of devices, it's not exclusively so. I have no mobile device I could have run it on, so looking it it in a desaktop browser was my only option.

If I could have made it available in a form that you could have run on a mobile device that would have been even better, but it's not practical or convenient. If I'd uploaded the .bbc file and asked people to transfer it to their mobile device (most likely involving a USB connection to a desktop PC) and run it in BBC BASIC, how many would have actually bothered?

If you'd made it mobile-only, I would have deleted the email & moved on.

And as for giving 'instructions', for example on how to scroll it, people running it on their phone or tablet aren't going to have any 'instructions', they will be using their familiarity with the device and its interface to guide them.

Fair point, but the the problem was less one of wondering how to scroll it, more not realising it had to be scrolled. If something is scrollable I expect to see scrollbars to tell me that.

When using a mobile app how many times have you sought out and read 'instructions' (if indeed there are any) for scrolling or zooming? I would guess none!

Waell, I hardly use a mobile at all, except for receiving & sending SMSes, & rare phone-calls. But I think one's expectations using a mobile is that the limited view you have, of anything, likely scrolls. On a desktop it's different.

As for instructions ... that's why there's zillions of websites explaining how to do things in each edition of iOS & Android. There's certainly a need for documentation - hence books like "Android for Dummies".

I wanted them to proofread the text and to test the interface. I accept that the mobile interface, through the size of the screen if nothing else, may not be optimum for proofreading, but it's what the end-users of this app are going to experience. Its what I've used when reading it myself and it's been absolutely fine, I think you protest too much!

Yes, it's obvious you think that. What I don't understand - unless it's to do with screen resolution etc as mentioned in my other most recent reply - is why you don't have the problems I have.

I'm afraid I have no sympathy for somebody who sees text displayed on the screen, can see that it doesn't all fit in the window so must be scrollable, yet doesn't try any of the usual methods of scrolling (keyboard, mouse or touchscreen).

In Firefox, in non-fullscreen mode, PageUp/Down scroll the Firefox window, not the contents of your text display. in fullscreen those keys do nothing at all. While the mouse wheel will scroll the fullscreen display up & down, it won't scroll it sideways.

Why should the user have to experiment to find out how to do something, when you just TELL them that it's needed, & possible, with the cursor keys.

If the code that generates the picture of the text can identify the type of machine it's running on, you could simply generate the sentence "This text scrolls in any direction via cursor keys." at the top of the display, if it's on Windows.

[jeroen_soutberg]

After going through the list I have only a few trivial comments (as a retired copy editor):

Negative numbers: use an em-dash or similar instead of a hyphen for the minus sign?

ACS: 0-PI instead of 0 - PI (for consistency)

ADVAL(0): delete "(0-15 or more )" as it would need more explanation about the "more" to be helpful?

EOR/EOR=: if "the" and "a" are omitted, "performing" could be used for both descriptions, instead of "giving the" and "performing a"

EVAL: I never knew about <s-var>=EVAL(<string>), so I tried a$ = EVAL("65"), but that resulted in a type mismatch error?

INKEY$: the use of "string" without preceding "1-char" is confusing, but I could not think of an alternative fitting in the available space

INSTR: sub-string is hyphenated, but subroutine (under GOSUB) is not?

STR$: Split into separate entries for STR$ and STR$~ ?

WHILE: WHILE...ENDWHILE (3 dots, not 2) for consistency?

[hellomike]

It's very complete.
You could mention "COLOR" is also allowed conform the BBCSDL help.
COLOUR (COLOR)

Regards,
Mike

[jeroen_soutberg]

EVAL: I never knew about <s-var>=EVAL(<string>), so I tried a$ = EVAL("65"), but that resulted in a type mismatch error?

That's because evaluating "65" returns a number, not a string. Try this instead:

Code: Select all

a$ = EVAL("STR$(65)")
PRINT a$

Your other points are all noted and I will action them if I can. Your comments are exactly the kind of helpful, relevant, positive feedback that I wanted, and are greatly appreciated.

Thank you for the explanation; I am not sure I see the value of the string version, as it seems to need the STR$ ingredient [I tried a$ = EVAL("COS(2)") which gave me a type mismatch error, while a$ = EVAL("STR$(COS(2))") gave the desired result; a$ = STR$(EVAL("COS(2)") would seem more logical here]. Or do I miss something?