Wiki/Report of Meeting 2024-04-04

Report of Meeting 2024-03-28

Present: Ed Gottsman and Bob Therriault

Full transcripts of this meeting are now available below on this wiki page.

1) Ed says all quiet on the J Viewer front. The next update will either a bug fix or an announcement that recent forums are incorporated. Bob asked if there were a potential with Eric's J server in the cloud. Ed said at this point the J Viewer lives in JQt and he has not been able to do a stand-alone version. He has looked at Norman Drinkwater's paper https://code.jsoftware.com/wiki/Guides/J9_Standalone , but has not been able to get it up and running. Ed wonders if the instructions may need to be updated for the new versions. Even nicer might be a web based platform. Bob wondered about cross browser issues, but Ed thought that the various frameworks such as Angular have largely solved this problem. He thinks that the challenge would be getting so much information back and forth from the server.

2) Bob showed the work that he has done with customizing the category tree view. He showed Category Essays R3 https://code.jsoftware.com/wiki/Category:Essays_R.3 and sub-category Language Concepts R3.1 https://code.jsoftware.com/wiki/Category:Language_Concepts_R.3.1 where he had hidden sub-categories and only displayed pages. It is a table view and Bob would like to try in a grid display to allow for a more flexible delivery. The table includes tool-tips of the Category descriptions and is a collapsible table. There was confusion over the fact that the table did not include all of the categories as it was just a mockup. There was a discussion about what the new version delivered that the previous side category tree had not. Ed wondered if the pages must be displayed on the bottom of the page. Bob felt it could be done with a grid format.

3) Bob explained that he wants to create the complete category tree as a template which allows the correction to be done in one template that will be reflected throughout the wiki. Bob hoped that if the grid format works within the template, it would make the display of the category more effective in its use of space. Ed wondered if the page could be displayed adjacent to the entry in the tree so that the user did not have to leave that page to view the contents. Ed thought that may result in pages that are overloaded with data, Bob thought that something like this had been done with templates and variables in the Primer, but did not know for sure. Ed would like the link to a category to show the pages attached adjacent to that category. Possibly have all the links hidden in a div that would be visible when you click on the link. Ed felt that this would be at the data limit of MediaWiki pages. Bob hopes that the template might take the page url and send back the page links for that page. So each template instance would have only the information applicable to that page. Ed wondered if you could open up multiple categories and Bob thought it would not be doable because that would mean that every link would have all of the attached pages and the data limit would be an issue.

4) Ed felt that the biggest challenge was to make the category tree display as dense as possible so that it does not take up too much screen real estate. Ed wondered if extension were an option and Bob cited Raul's insight that we don't have a way to fix extensions, so we would be relying on third parties for support.

5) Ed proposed a page that has a vertical set of links that are the Category tree display that allows you to display a page beside the link. This is similar to the way that the early J viewer had with its expanding category column. (Editors note: This may be possible with a tree view that is included with every page from a template that opens the content of the page for each instance. This could be a recursive well since it would be displaying the contents of the page which includes the template itself). Bob wondered if having the tree horizontal instead of vertical might be more efficient use of space.

6) Bob feels the first step is to explore the limitations of templates and grid formats. If this works then the prototype can be developed until the user interface is polished enough. Ideally the target is to have the categories show up at the top level with the pages at a bottom level and a display of the selected page in between. This is ambitious and Ed said that if JavaScript was required he could apply his skills to the problem.

For access to previous meeting reports https://code.jsoftware.com/wiki/Wiki_Development If you would like to participate in the development of the J wiki please contact us on the J forum and we will get you an invitation to the next J wiki meeting held on Thursdays at 23:00 (UTC) Next meeting is April 4, 2024.

Transcript

Sure.

I really didn't give an agenda item to you, but is there anything new with the J viewer?

No, nothing at all.

All is quiet.

I didn't send out a monthly update

because there was no update to be sent.

Probably the next update will be either a bug report or the news

that the forum is once again being indexed.

I don't anticipate either of those things in the near future,

but we shall see.

So is there big holdups on the forum,

or you just have other priorities

you have to attend to?

Other priorities to attend to, yeah.

It has not bubbled up to the top yet.

I think if there was anything else,

there's the J server in the cloud.

I don't think it really affects you, but it might.

I don't know.

No, it's-- I mean, in order-- the way the J viewer works,

it has to live in JQT.

So there has to be an interpreter available.

I'm not actually real happy about that.

I spent some time months and months ago

trying to make a standalone J application using

Norman Drinkwater's guidance.

And that did not--

for reasons I was never quite able to tease apart,

that did not go well.

So I gave up on that and decided just to do an add-on.

But it really is annoying to have--

to live in JQT and have there be sort of a--

it's not ambiguity because everything is always decided.

But to have sort of confusion between what's the tool

and what's JQT.

And I could do stuff in my application that

would mess with the tool.

And I can do stuff in the tool that

would mess with whatever application you're building.

Namespace stuff, this kind of thing.

And that may say more about my own understanding

of the environment than anything else.

But it's definitely something I've noticed.

So that business with the timer, for example,

where it was possible to either hijack my timer

or be affected by my timer.

However you want to look at it.

That was fixable.

But I think there are probably other things

that are less fixable if you're living in the same family

of namespaces.

Well, I think that's the key to it.

It's the namespace.

If you give it a separate locale, it should--

I did.

I do.

Yeah.

Yeah.

But I mean, I notice things in my own development

when I'm doing WD.

My WD stuff and the JViewer WD stuff

sometimes come into conflict.

I really am keeping a separate namespace for the JViewer.

I'm not sure exactly what's going on.

But every once in a while, I have to kill the environment

and start over again.

So these are mysteries that if I dived into them,

I could probably fix.

But I'd be even happier if I could just

have a separate application that lived in its own address

space and its own set of namespaces.

And Norman Drinkwater's paper, his essay,

seemed to point in that direction

if I understood it properly.

But again, I wasn't able to get to the end of it.

Yeah.

And I haven't dug very deeply into this,

but I've heard of people running multiple instances of J

on the same computer, not different versions,

like same version but multiple instances.

I think Devin's done that.

Yeah.

In which case, if you started up one version,

like an instance of a version, and you made it headless,

so you didn't have an IDE for it--

But I need a user interface.

But that would be your WD.

Would be running off that.

Where is the WD running?

It's running off the J instance.

Like you can close the terminal window.

Something has to be driving graphics on the screen.

Who's doing that?

Your interactions with your screen are doing that, right?

Yeah, but who's running WD?

In other words, I understand having the J engine sitting up

somewhere.

Yeah.

But who's running the WD library to put blocks of pixels

up on the screen?

It comes in with the J instance.

OK, so I'm running JQT.

Yeah.

I've got my same problem then, which

is that JQT is hosting both the add-on

and whatever development work you're doing.

And that's the problem.

OK, so I guess the question is, I

had thought people were actually running a separate instance.

In which case, there'd be the J engine and JQT

running in one thing.

And then you run a separate instance.

And you've got the same thing running separately.

Well, that, in effect, is what Norman Drinkwater's paper

outlines.

And it's just very hard to get to the end of that paper.

And if I understood Raul correctly,

there are some issues with versions

where Norman's instructions may need some love with respect

to the latest versions of J and of JQT.

So I would love to run a separate instance of J and JQT.

And actually, Raul has asked for that.

Or at one point opined that it would be a good thing to have.

And I'm just not quite sure how to get there.

That's all.

Yeah.

But as you're saying, if you did have that separate,

all you need to do is then turn off the terminal window.

And then you've just got your screen sitting there,

running merrily away on its independently.

Right.

Yeah.

Right.

And it could just sit there as an application.

You could run a separate stuff with J.

And then you just have a window that you click to

and you can do your search.

You would think it wouldn't be that hard.

Yeah.

But the directions that Norman put together

are fairly involved.

OK.

I don't understand the environment in question

well enough to know, to appreciate why.

I'm sure there are good reasons for it.

But again, I just couldn't get to the end.

But yeah, a separate app would be nice.

Even nicer in some ways would be a web page,

as long as we're dreaming.

Yeah, you made the point though, the web pages

are hard to be consistent because every browser has

a different view.

Well, that is certainly true.

But the various frameworks like React and Angular and Vue

and so on do a pretty good job of hiding

the various inconsistencies across browsers.

So I think that's a solvable problem or a problem

we could successfully sidestep.

The deeper problems have to do with--

what should we call it?

It's basically speed.

So if you look at Apple cart, for example,

it achieves tremendous speed because all the data is local.

But there's not that much data.

A couple of megabytes maybe of APL code and comments

and then some simple search logic.

But if you want to have a gigabyte of data

and a real search engine that'll do stemming and so on,

it's not really possible to keep that locally on a web page.

You would have to hit a server.

So your architecture would get more complicated.

You'd have to get into the server web service

business, which you can do.

But now you have uptime constraints or requirements.

And you've got to maintain it and make sure it's performing

properly over time.

And that is involved.

Yeah.

And while we're dreaming, that's possibly

where the J in the cloud may end up going.

Well, that's where it is.

Yeah.

Yeah.

But you'd have to have that infrastructure to maintain it.

Well, that is effectively what Eric has signed up for.

Yeah.

It's to maintain a server in the face of repeated user requests

that are pounding on it all the time.

Yeah.

And he's apparently comfortable doing that,

for which I admire him greatly.

I am less so.

Yeah.

Yeah.

Well, it's a process.

It's a process.

It's true.

Yeah.

So what have you got in the way of category pages?

I have done-- I've actually got a fair amount of work done

today.

I'll show you.

Oh, good.

Yeah, let's see.

I'm pretty happy with it.

So--

Cool.

Let's-- yeah, let's share a screen.

So we're back to the standard reference page.

And there's really nothing new here.

But what I did is I decided to see

if I could create something closer to what we were aiming

for in the last meeting.

And so I took essays, which had subcategories.

And this is what I did with them.

Right.

Oh.

Now, this is just roughed in.

These are just all the pages that are attached to essays.

You no longer have the tree, category tree up on the side.

What I've done and clicked on this,

I can expand the category site map.

Now, all I've done is for the essays level.

But in its full version, it would

have essays and everything back up to the home category

sitting in this.

So there's a lot of information.

But I have the ability to go laterally

as I go deeper, which is a nicer way to do it.

This is just built with tables.

So it's kind of boxy.

But I think I would be able to do it with a grid format.

And a grid format's more flexible.

Because as things move around, they'll

actually shift and make better use of the space.

So you might have--

if you had more categories, you might

have these boxes overlap.

So language concepts might just be sitting in here

with a slight overlap.

And you sort of had the full thing.

You could also have it, if you wanted, to have this.

Right now, it's set up to do--

well, I was able to put the tooltips in.

So when I hover over it, I get a tooltip.

And if you can't use tooltips-- so for instance,

you've got a touchpad or something--

if you click on this, you get the same information.

Oh.

Hmm.

So I'm somewhat at sea here.

So language concepts, math, puzzles, and games.

So if we go back to the page that

had the outline on it on the right, so the main category

page--

Yeah, any one of these, say, J articles.

Right, so essays.

So if we look at--

no.

There's articles.

Essays now looks different.

So if you want to see something with the category--

Essays looked exactly right.

Please back up to the main category hierarchy

on the right.

I'll go to Essays then.

Thank you.

Essays.

No.

No.

[LAUGHS]

Or you can expand it to this, but that's not--

No, no, no.

Maybe it's reference that I want.

Try reference.

That's what I went back to, yeah?

That's what I want.

Stop.

Stop right there.

So if I look at Essays on the right, in the outline,

I see exactly the same information

that you were showing me in that table.

So I'm confused as to why I have to go somewhere to see that

and dig yet to see that table.

OK.

We have exactly the same information.

So the thing where you see the same information,

if I'm correct, is you're seeing it here,

a link that goes to the essay page,

and here, a link that goes to the essay page.

Is that what you're saying?

No, I'm not really worried about the stuff in the center.

I'm really only worried about the tree on the right,

the outline on the right.

It seems like everything I need to know.

Why would I have to go somewhere--

OK.

So if I click on Essays, I can see all the pages associated

with Essays.

But I lose my outline.

I lose my category hierarchy at this point.

Why is that?

It will be right here.

But that's not it.

It's not it right now.

You mean that table?

No, no.

It's not it right now.

Why isn't it in the right margin where it was before?

Well, because the right margin where it was before

doesn't give me the ability to do tooltips.

It doesn't give me ability to do a narrower structure of this.

So it's the same information.

Like, right now, it's not the same information,

because it doesn't include everything above Essays.

But the plan is that it would include the same information

that you'd have in here.

It's just all we're seeing is this part of the view

right now.

In the future, you would see all of this.

Why not just show it in the outline as it is now?

I mean, it's complete in the outline right now.

And it looks to me like you are showing tooltips

when you hover over labels.

When I hover over labels, all it's telling me

is where I'll go.

So it's saying, category databases are .2.2.

That's all it's telling me.

Yeah.

So--

So when I go to this Essays page and I hover over it,

I choose to--

Why do I have to learn a new view of the structure?

I guess that's my question.

We've got this, what strikes me as a perfectly adequate view

of the structure in the outline on the right.

And now you're telling me, well, we're

going to have this new view of the structure.

We're going to throw away the view that you got used to.

And we're going to give you this new view to learn.

And I'm confused about that.

You got used to that view.

Most people are used to--

You're going to get rid of it?

What's that?

You're going to get rid of it?

Yeah.

Oh, so it goes away.

There will be no more outline tree.

This will be the outline tree.

I see.

And it will include the whole tree.

So for instance, I did expand and do the same thing

with language concepts.

So if I click on language concepts, I can expand.

And you see, it tells me I'm on language concepts.

And it's got the same information.

And I can go back to writings about J, math topics

from combinatory statistics.

If you want to know what at play with J is,

it's Eugene McDonald's popular series in Vector.

Miscellaneous is we didn't know quite where to put this stuff.

If you can't hover, you click expand.

And it's got the same information.

And this will be how you can access the whole tree.

If you want it to go away, hit collapse.

If you wanted to go to any one of these,

you would just click, say, on this.

And now you're back there.

I'm really confused.

All right.

I-- may I ask, what is wrong with the outline

that you built on the right, which I like a lot because it

is so comprehensive and so succinct?

Well, what this does that it can't

is that it-- this does tooltips.

So you can have a look ahead that

will tell you more about essays when you hover over essays.

This tells you where you are in the tree.

Whatever is black is going to be the position in the tree

that you're at right now.

I'm disoriented.

I can't see the tree anymore.

No, you can't because I haven't--

I haven't had time to put the entire tree into this yet.

OK.

So I'm showing you a subset as a working prototype.

OK, and then mixed in with this is

all the pages associated with the current node in the tree.

Correct.

This-- this-- this node has these pages attached to it.

When I go to this node or this page,

again, I will have exactly the same tree here.

Again, it will do more than essays.

It'll have the whole tree sitting in there.

But in here will be all the pages associated

with language concepts.

Can you put the pages--

so as it stands now, it looks like the pages

will be at the very bottom of the tree.

Is that right?

As it stands now, that's what it will do, yeah.

Does it have to?

I haven't tried otherwise.

I'm not sure that it would have to.

Could it go to the right?

There's a tree on the left, pages on the right.

It could.

I think you start losing--

as this number of pages--

yeah, you start-- I mean, I could play around with that.

The places I'm going to go with this right now,

or I'm looking to explore further,

one is to not use this in a table format,

but to put it in a grid format.

And if I do that, then I would also

be able to put this in a grid format.

And I think that gives me a lot of flexibility.

So side by side is quite possibly an option.

Right.

The other thing that is key, because I

would have to put this whole page or this whole tree

on every page.

And so if I was having to make a change to the tree,

it would be necessary to go in and change every single page.

There's no way you can do that.

But what I can do is I can make that--

this-- into a template.

And if I make it into a template,

because it's generic information across the whole website,

I just have to go change the template,

and it will display differently on every page.

May I ask this?

I'm a little-- so we're sort of--

I'm opening a parenthesis here with your permission.

Could you click Expand on a few of those items?

Sure.

So it strikes me-- yeah, like right there.

Hm.

I wonder if we could get away with not having tooltips

or expand buttons at all, and just put the expanded

definitions next to the category headlines.

So I'm struck by puzzles and games using

J to create and solve puzzles.

That's so nice that I don't have to drill down

to get that information.

Right.

So are these samples, or how are these specified,

and is it a lot of work?

It's just specified-- essentially, what I'm doing

is I'm creating a link, and then a span.

And in the span, it has a title, which is this information.

And then the content of the span is the same information.

So that means that when I highlight this,

I'm getting the same information as I have here.

So once I've decided what I want to put in there,

it's just putting it in two places within that link.

And it's very--

I can take the collapse and the expand out,

or I can have everything open up--

open with everything open.

The challenge I find, or I think I would find with that,

is when you think about the entire tree--

this just being a subtree--

but if you flipped on the entire tree

and everything opened up at once,

you've got a lot of scrolling to go through to find

what you want to find.

Maybe not.

So on a phone, I will grant you, you

might have a lot of scrolling.

What if you widened the table that you can't see

me pointing with my cursor?

So widen it out this way.

Yeah.

So that all of your expansions fit on a single line.

So it wouldn't cost you anything extra

in terms of vertical area, vertical distance,

to show all the expansions.

So that problem goes away.

To some extent, it does.

It probably goes away--

what we were talking about using a grid display,

because I could interleave.

I think if I'm stuck with a table,

it doesn't go away, because I think

I end up with probably four or five categories deep.

Yeah.

But with the grid, I should be able to interleave them.

Yeah, you don't want to be tabbing out

the distance of the parent to show the children.

Yeah, exactly.

If that's what you mean by interleaving.

That's what I mean by--

Agreed.

If these slid over--

Just a little bit.

Yeah, so it was just an overlap.

You can see it would be an indent.

Say you go half this width, and you do that five times,

you probably come up to about here.

You'd have the rest of this as a single line.

It doesn't even need to be half the width.

A few pixels is probably plenty.

I mean, you just need to show indention, and that's fine.

So here's what you could do then.

And I'm pushing on the boundaries here,

and I recognize that, and I apologize

but it's just struck me.

So you don't show--

I asked to show the pages on the right,

but that's actually a crappy solution.

And the reason for that is you'd have to somehow line the page

titles up with the category label to which they belonged.

Right?

In other words, if I'm 2/3 of the way down the tree,

and I click on a category, I don't

want the page titles to show up at the top of the page.

I have to scroll all the way up to find them and select them.

That's wrong.

So now I need to be very smart and somehow make

them appear right next to, to the right of, the category

label I just clicked.

And that's probably pretty tricky.

Plus, you don't have as much room on the right

as you used to because of what I said a moment ago, which is,

let's expand the tree so that we can

show the full description associated with each headline

in one line.

So here's my suggestion.

When you click on language concepts,

when you click on math or puzzles and games,

I would suggest that the table, the nodes below puzzles

and games, let's say, shift downwards

and the pages appear immediately below the puzzles

and games entry in the grid.

Do you see what I mean?

Yeah.

Is that doable, do you think?

I have to look into it.

I'm not saying it's not doable, but--

I grant that it's tricky.

Yeah, it could be.

It could, it may just be a question of--

oops, sorry, excuse me.

Zoom, no, what's going on?

I'm not seeing anything aberrant.

I am.

Let me tell you.

Oh, how interesting.

All right, it may just be a matter

of constructing a grid that contains all the pages,

actually.

And this may be infeasible from a performance perspective,

all of which are hidden by default.

So each set of pages is sitting in a hidden div

underneath or as part of the grid

that you've created to encompass the category tree.

And when I click on a category name,

that sets the div to be visible.

And it appears and takes up space

where it wasn't doing so before.

And it's immediately below whatever the category label is

that was just clicked.

And then that would--

I mean, essentially, what I hear you saying

is that this collapse and expand,

if it had the same functionality as this button,

the collapse and expand, when I clicked on this,

instead of going to puzzles and games,

it would show me all the pages in puzzles and games

immediately below.

That's exactly right.

And you no longer need the collapse and expand links.

They go away.

You wouldn't need this information?

No, you have that information.

But you've widened the tree, the tree table, the tree grid,

so that you can show most, not perhaps all,

but most of the explanations on a single line.

So it doesn't explode the height of the grid--

excuse me, the height of the tree.

OK, I got you.

So what would happen would be this

would be shown all the time.

Yes.

Yeah.

And then clicking on this would toggle these pages.

There would be a split in the display here.

Algorithms and displays would rock it down

to the bottom of the page.

But I would see all the pages in here

that were attached to puzzles and games, for instance.

That's what I'm thinking.

Yeah.

It comes down to, I think, how flexible the grid is.

And it's pretty flexible.

It's pretty flexible.

What's that?

It's pretty flexible.

Yeah, no, it's pretty flexible.

Yeah.

I have to be able to--

OK, again, another layer that I'm thinking of right now

is the fact that it's going to come from a template.

So that I have to be able to, when I click on that,

that I would like the information from the puzzles

and games page, please, even though the template is sitting

on its own in another page.

I think I can do that.

I'm thinking that that's not how you do it.

OK.

I'm sorry.

That's probably a perfectly good way to do it.

I don't know enough about this environment

to comment really one way or another.

But the other way you could do it,

that I'm fairly sure would work, is to have--

OK, so assume for a moment we can ignore performance.

You could have all of the page links for all of the pages

sitting in the grid.

Yeah.

They'd all be hidden.

Yeah.

And only when you clicked on Add Play with Jay

would one div containing a bunch of page links

be set to visible.

Now, the problem with that, and it

may make the whole idea infeasible and stupid,

is that that page would be quite large.

You would definitely feel it when you were loading it up.

Yeah.

I mean, honestly, would it be that much larger

than a page that had a couple of photographs on it?

Probably, yeah.

You'll notice that MediaWiki is careful never

to show more than 200 pages associated with a category.

Yeah.

You have to jump to another page to get the next 200.

Yeah.

It's sensitive to that problem.

OK.

So your notion of somehow loading up

another page's worth of page links makes sense.

I don't know how to do it offhand.

I'm not enough of an HTML programmer, I guess,

or much of any.

But if you could make that work, that would be great.

If I go to Primer, this is what I did with that.

And so when we look at these pages,

you can see that I've got this red highlight.

This is the page that I'm on.

Sure.

This is a template.

So what I do is I send the information from this page

back to the template, saying, this is the page.

And the template can say, oh, if that's the page,

I will highlight this number here.

Right.

And so a similar thing would be with here.

The only difference would be when I click on this,

it's a template.

It knows what that page is.

I can send the ID.

And I should be able to generate the information that's

down here to come back and display at that point.

The same way as I could generate which of these to circle.

All right, I'm going to trust you implicitly on this.

At least I think that's the way I would approach it.

Because then when I click, all I'm doing

is loading the same up to 200 pages,

the same as I would to open the other page.

There's no difference there.

And the challenge is to be able to put it between these.

But again, I think with Grid, I can do that.

Great.

And then, of course, this information

would be sitting there all the time anyway.

And all that happens here is you would be toggling in and out.

Showing pages.

Showing pages from those, yeah.

Now, if you actually wanted to go to that part of the tree,

you wouldn't be able to, right?

You'd only be able to see the pages attached

to that part of the tree.

You can see the rest of that tree by scrolling down, right?

Right.

The rest of the tree is visible in the rest of this box, yeah.

Right.

So you can scroll past the visible pages

that you've just toggled on.

Absolutely, yeah.

And see the rest of the tree.

And they would show up below.

And in fact, you can toggle on multiple categories pages

if you want to.

I don't think there's any reason to limit you in that regard.

I think there might be.

OK.

I think that might be something you can't do.

Because I'd be running multiple instances of the same template.

Oh, OK.

On that.

And that might be an issue.

That might confuse it.

Might not.

But it would be the same as I went back to this page

that I happened to have two chapters open at the same time.

And I had two of these highlighted.

I'm not sure that would work.

I'll defer to you on that.

It strikes me that it would be kind of nifty

if I could have multiple categories pages open at once.

But it's not required, I don't think.

So I'm sure that would be fine.

Yeah.

But it might be doable.

I'm just trying to think through my head where the itch would be.

Yeah, of course.

Yeah.

Of course.

The other thing that it would still show you

is the fact that it's in black here tells you

that this is the page you are on.

And these are the pages that would be attached to it.

Yeah, but you don't need that.

Because you can see immediately--

I don't think you need that.

Because you can see immediately below the category link,

the category label, the pages.

And it's pretty clear what's going on.

The category-- you mean this, the pages

and category essays are?

This one?

Yeah, language concepts of J. I don't necessarily

need the category label language concepts to be highlighted.

Because immediately below that label

are all the pages that I just turned on.

All the page labels that I just turned on.

It's a minor point.

If highlighting turns out to be an issue,

I wouldn't worry about it, I guess, is all I'm saying.

I don't think it is.

I think, to me, it's kind of a useful thing.

Because in a large tree structure,

you would be able to spot the place you

are in that tree right away.

Yeah, although you'll also see all the pages,

page labels immediately below that category label, right?

I mean--

When you click on it.

Oh, you're distinguishing between-- OK,

what would it mean to select the category label

but not see the pages?

Well, that's what I was kind of asking,

is you get away from the ability to move around the tree

because you see the whole tree there.

Well, that's the whole point, is that tree navigation

is essentially scrolling rather than clicking

to sort of get a worm's eye view as you navigate steadily

downwards.

And it works for us because our tree isn't really all that big.

It would work in the general case of millions of categories,

obviously.

But I think it works for us.

So the challenge for you, I guess,

is going to be to keep the tree as compact

in the vertical direction as possible

so that it's very dense in that regard.

And scrolling really takes you a great distance

as you go from page to page.

So you can see a lot.

What about that MediaWiki extension

that would show the beginnings of a page

when you hovered over a link?

Is that figuring into your thinking at all at this point,

or is that a bridge too far at this point?

Well, I think the point that Raoul kind of raised

is one that sort of pushed me back off the foam plate.

I stepped out of the batter's box

when he said, if we're using extensions,

we don't really have a way to debug them.

What did he mean by that exactly?

I think what he meant is you put in an extension.

If something goes wrong with it, we

don't have the mechanism within our MediaWiki

to be able to go in and figure out what's wrong and fix it.

We're relying on the developers of the extension.

Do we use any extensions now?

I don't believe we do.

Although we use some built-in features that

did start out as extensions.

Right, that's a little different.

Yeah, the category trees started out

as an extension in around 2010.

And now they've become part of the language.

So with the caveat that if something went wrong,

we would be stuck with an extension.

And we might have to either remove the extension,

in which case the functionality goes away.

Yeah, but that's the worst case, right?

Well, actually, the worst case is

it provides functionality that actually you really, really

don't want.

And you can't get rid of it.

That's the worst case.

Come on, you can certainly retract the extension.

You're not having to deploy it.

You are not stuck with it.

No, I know, I know.

What I'm saying, though, is it can

be worse than just taking it away

if it's creating problems for you.

Right, but if it's creating problems for you,

you take it away.

Yeah, exactly.

We go through a difficult patch potentially with some users,

but it's easily fixed.

Exactly.

OK, I was just curious.

So I guess what I wonder now--

Like your idea with the hovering and seeing what pages,

I don't think you could get in a hover enough information

to make all of that information--

and there could be more if there are categories with more pages--

usable for you.

I grant that.

I absolutely grant that.

Yeah.

I have a question.

So I'm wondering a little bit how far we can push this.

What if-- and let's ignore phones for the moment,

although I love phones, and we will come back to them.

What if pages and category essays

on language concepts of J, what if the grid containing

the page labels was not multi-column?

It was just one column linear underneath the essays link,

the essays category label link?

Linear horizontally?

Linear vertically.

OK.

And essays isn't even a link anymore.

It's just a toggle that turns page labels on and off, right?

Don't go anywhere.

The way you're going with it, yes.

Yeah, right now it does a bit more than that, but yeah.

Yeah, but I've zipped way off in a direction,

and that's where I'm living at the moment.

So if you'll indulge me, I'd appreciate it.

What if, and again, on computer screens, big screens,

when you clicked on array thinking, which

is the second item in a linear single column

vertical list of page names, an iframe to the right

showed the page array thinking?

And the iframe would be what, roughly sort of half screen

sort of an idea?

No, it would take up the whole-- it would take up, I don't know,

on a computer screen it looks like about 5/6 of the width.

OK.

And the height would be--

I mean, you'd have to think about this.

It's a little--

It's a little bit of a problem.

I mean, you'd have to think about this.

It's a little tricky and painful.

But you'd want to position it so that it was--

its top was level with the page label.

Put it that way.

So if you've got a 200 page label list,

and you scroll down to the 175th label, which

might be essays type, and you click on it,

that'll show the essays type page immediately

to the right of the essays type label.

And the top of the essays type page

will be level with the essays type label.

Do you see what I mean?

Yeah.

And the list is vertical.

And the list is vertical in one column.

Yeah.

Is that shit, or does it have a chance of possibly working?

Either from the point of view of usability

or from the point of view of implementation.

Both are interesting questions.

The challenge I see there--

and I don't really have an answer to your questions

because I haven't had a chance to explore it.

But the challenge I would see would

be in the amount of information that's going to be on the page.

Oh, usability.

Yeah.

I'm just thinking if I click--

now, I'll click on this.

It's going to go to a different page.

But this is what's on that page.

Sure.

So you're talking about now what would happen

is this page would line up.

The top of this page would have an iframe that lined up

with the link to array thinking.

I'm guessing it would push all the other pages down.

All the other page labels down?

All the other page--

No?

No, it would not necessarily.

On a computer screen, it wouldn't need to.

On a phone, it might need to.

On a computer screen, it wouldn't need to.

So that's kind of nifty, right?

You can click on page, page label, page label, page label,

page label, and load up page after page without having--

this is just me trying to recreate the J

viewer on the browser.

I don't have to go back and go forward and go back

and go forward, that waste of time.

But if you--

OK, so for instance, if you say clicked on array manipulation,

so now there's going to be a window that lines up

with the top of this here, right?

Yep, and it goes all the way to the right margin.

All the way to the right margin.

If you click on array thinking, it's

going to be below this window then, right?

No, you can only see one page at a time.

OK.

Make that a restriction.

OK.

So when you were talking about opening multiple pages,

it's multiple pages sequentially.

It's not in parallel.

Well, I'm not talking about-- yes,

I'm talking about opening multiple pages sequentially.

For categories, I was thinking you

could open multiple sets of page labels at a time,

but I'm not married to that.

I take your point about templates.

Yeah, for opening pages associated with page labels,

one at a time.

Just trying to think of what that looks like in a template.

Essentially, would be a template that

included every page of the wiki.

But when I click on something, it

can go tell me what page it wants.

I'm still going to need to position that page,

unless you were willing to not have it line up

with what you clicked on, but instead just

be an iframe that sits in a standard position.

That's tricky if you've got a couple of hundred pages or more.

Yeah, it is if they're all vertical.

Yeah.

What about if you didn't put them vertically,

you put them horizontally so that you could

make use of the wider space, and you might have

six or seven columns of these?

And then it would only maybe be, oh, maybe at most 20 lines

deep.

Sure, and then the page underneath the whole--

The page would show up underneath it

when you clicked on it.

Yeah.

That's not bad.

I don't think that's bad.

And then when you clicked on a different page,

you'd have a different picture show up underneath.

Yeah.

I think from the point of a template,

that's probably more doable.

All right.

Because I'd be sending the information

to the same spot every time.

All I'd be doing is changing the--

URL.

The URL that I send it.

Yeah, that strikes me as perfectly OK.

Yeah.

OK.

I'll look into that.

All right.

Just trying to think of--

I recognize that it may not be doable

for any number of reasons.

And I'm certainly prepared to accept that gracefully.

My prime direction right now is to get it working as a template

and get it working as a grid.

Yeah.

Because if I can do both those things,

then it just becomes a matter of prototyping.

Right.

So it's currently a table rather than a grid?

Yeah, it's currently a table.

And in order to show language concepts the same as essays,

I actually copied the table that's in essays

over to language concepts.

I haven't done a template yet.

Yeah.

And I didn't do that, say, for math.

So math just shows up.

And it's got the subcategories the way they were before.

They're not taken out.

Right.

But I do kind of--

when you were talking about keeping the whole category

tree on every page, I actually do like that.

Oh, good.

Well, and then it's just a matter of--

one thing that I do find a little bit irritating

is every time you go to a new page, it's collapsed.

Yeah.

And needs to be expanded.

But the alternative is that you've

got the entire category tree showing up

at the top of every page.

I suppose the other alternative, though,

is to put it at the bottom of underneath these pages.

But for the approach I outlined, that problem

doesn't obtain or does it?

From the approach you were doing,

you're actually moving these pages,

the links to the pages, into the category tree.

In effect, yes.

That's right.

Although only one-- I'm acknowledging

that only one set of page labels will be visible at a time.

And then only one of those pages visible in the iframe.

Exactly.

Yeah.

The advantage of putting it underneath

is that you would see all the pages when

you went to this category page.

You would see all the pages linked to this category page

immediately.

And then underneath, you would see

something that had the entire map of everything

and would let you look at the different pages

without going to them.

Yes.

Yes.

So in essence, this would become a bit of a cloud curated

by whoever set the categories.

And then underneath would be more of a user exploratorium.

It's all there.

You can pick the pages you want to see.

Yeah.

And you can scroll to the categories you want to see.

You can scroll to the categories you want to see.

And when you click on that category,

it opens up the pages that are available in that category.

And when you click on one of those pages,

it shows underneath that, that page under display.

So Bob, I've never seen anything like this on the web.

It's either because it's a really bad idea

or because nobody's thought of it.

And I'm agnostic as to which of those it is.

I think the only way to find out will be to do it

and see how people react.

Yeah.

Yeah.

As I said, I think the next step is

to get it into the grid format and the template

and then see what constraints or possibilities that opens up.

But as you were saying, the grid's flexible.

It absolutely is.

And it means that I can move these things around,

make them responsive, but also move different things

to different parts.

Because as soon as a thing's got an ID or a class on a page,

I can position that within a grid.

So you're not locked to where you're seeing things.

You can put them in different spots.

Right.

Cool.

I do like the idea of having the cloud of links,

for lack of a better term, above the fold

on the top part of the page.

Agreed.

Yeah.

And so having the other part down below

would be something you could go in and find out about.

But when you go to that page, you probably

just want to see primarily the links, the pages that

are linked to it.

Well, you could also scroll a little bit

on a larger computer screen.

Obviously, the phone experience would be different.

But you can scroll down a little bit

so that the page labels are in the top half of your display.

And clicking on each page label in turn

will show you the first half page of the corresponding page

content immediately below, or below all the page links.

So that's nice, right?

That's a very pleasant way rapidly

to scan the page contents of a hierarchy label,

of a category label.

Yeah.

I think with the pages, though, you're--

oh, I don't know.

I might be wrong.

So is it possible that if, say, you

clicked on one of these pages, you

would end up opening up a window between this group

and the tree display underneath?

You absolutely would.

That's exactly what would happen.

Yeah.

And if you could do that with the tree display,

there's no reason you couldn't do it with this.

I would think, yeah.

I mean, it's all grids.

Yeah.

The one difference is this actually isn't a template.

Oh.

It's being generated by MediaWiki.

Well, you might find yourself in a position

where you have to generate it.

Yeah.

I-- in a former life, I did a fair amount

of JavaScript programming.

I would be happy to lend my shoulder to the wheel

or whatever the right expression is.

Yeah.

Well, it might come down to that because I could--

I'd be exploring with JavaScript,

and that's not an efficient way to approach it.

I'd learn a lot, but I'd grow older in the process.

Right.

Exactly.

Learning experiences, those of us

who have achieved a certain age understand that they are not

always to be embraced.

It's really true.

Well, at a certain point, people are

going to want to see things done.

Yeah, exactly.

And when all I can point to is, well,

I'm a lot smarter about this stuff than I used to be.

That's probably not a tangible benefit to most users.

I made a strategic error with a manager of mine

100 years ago who said, would you like to do this?

I said, it would be a challenge.

And my response was, so is septic tank work.

And that did not go over well, shall we say.

I used to just rely on the, if you want me to do this,

you could just tell me what I'm going to drop.

Yeah, right.

[LAUGHTER]

Because my time is full, and you want

to put a priority in this, I have no problem with that.

And it's full of things you want me to do.

Yeah, you have to decide which of these other things

isn't so important.

Yeah, yeah.

And then I'll do this one, because it's more important.

No, they're all important.

Well, we have a challenge.

Yeah, right.

Yeah.

Well, I can give it to somebody else to do.

No, no, I want you to do it.

Same as all these other things that you want me to do.

Yeah.

I think that was how I left my last job.

Oh, dear.

OK.

Well, it was just an ongoing-- this was continually

a friction point, right?

And at a certain point, neither of us were enjoying it anymore,

and the message wasn't getting through.

Right, right, right.

So I pulled the plug and found out

there was challenges when I wasn't around to do things.

Yeah.

Yeah, right.

Well, I have once again the feeling

that I have contributed problems but no solutions,

for which I apologize.

I wouldn't say you should feel that way.

I die.

Because the reason I got into this whole area with where

I am was because of what we did last week.

I really wouldn't have gone down that direction.

Right.

Right?

So similarly, if I build this out,

get the templates and stuff going,

we'll be another step ahead.

I'm not sure how much time I'll have in the next week to do it,

but I'll see what I can come up with.

Yeah.

That would be great.

I think it would be totally cool if we could get to the point

where the web interface feels an awful lot like the JViewer

interface in the sense that your structure and context

and your content are all visible at once.

And we get away from this webby notion of going somewhere

and coming back and losing your context

and having to recover your context.

Yeah.

When you return to your origin, I just

think that would be really wild if you could pull that off,

for whatever it's worth.

That's a good image to hold.

Thanks.

I appreciate that.

Yeah.

Yeah.

All right.

OK.

So I'll see you next week.

Hopefully see you in a week.

All right.

Thanks awfully, Bob.

Take care.

You as well.

Be well.