Wiki/Report of Meeting 2023-03-30

Report of Meeting 2023-03-30

Present: Ed Gottsman, Dave Lambert, Devon McCormick, Raul Miller, and Bob Therriault

A transcript of this meeting follows this summary.

1. We started off with Ed's fourth demo of the new J wiki browser. This version includes search of forum posts and is drawing its information from the site directly, not from a cached version. Devon suggested a good intro explanation of the interface would help. Ed said that his goal was to make the interface so obvious that the introduction could be kept minimal. Ed reiterated that all of the interaction wth some exception is based on hovering to minimize friction for the user. https://www.youtube.com/watch?v=IVtyjobPleA
2. Discussion whether there would be an issue with having a 100Mb cache to feed the system instead of live. Dave asked how often. Ed noted that there was not really a difference in speed of access between cache and internet, except in searches. Cache search time is milliseconds, internet search is about 2 seconds depending on connection. Bob wondered if having pages displayed on hover would create a few more orders of magnitude traffic on the site for each user. Raul did not think that the load would be volume of requests because text is being sent and that would be small compared to a video feed. Bob suggested that hovering might run from cache, but clicking on the page will go to the site and provide full interactivity including editing of a page for logged in users. Ed said for Mac's he has put in a double click that will load a page in a third party browser window, he has not found how to make it cross platform yet. Bob pointed out that a downloaded cache also provides access without internet connection. Ed suggested we see if there is an impact before we decide. Devon agreed "Don't optimize too soon".
3. Bob reflected that this browser has made access so quick that it has changed the way that he has looked at the wiki. Such quick access has changed the way that Bob has looked at categories. In the past the category pages provided content that would provide a context for the pages, https://code.jsoftware.com/wiki/Category:Reference_R but such quick access means that the category content is less important. Raul pointed out that if you are not using Ed's wiki browser you would still need the content on the page. Bob said that category content might be generated by ChatGPT as it does a decent job of summarizing when reviewed for accuracy. The categories do become more important because the structure they provide is the basis of the J wiki browser. The J wiki browser is based in jQt, but there is nothing that keeps it from being browser based other than having the expertise to develop it. Not all web developers are that focussed on fast interaction, but game developers may be a direction to go. Having had a chance to play with the interface, Bob asked when this might be available to the J wiki group and Ed suggested a week or two.
4. Raul suggested that the interface should still show when something is clickable. Ed said with hovering everything is clickable, but clicking is not necessary. Raul suggested a click would hold the position of the selection box, but the text would change colour to blue when you hover over it, indicating it can be clicked. Bob suggested that the clicking of the box would also set the history of the web view so you could access the clicked box. Bob wondered if this would load pages that were touched in transit would show up as well. Bob wondered if it was possible to set a time limit for the page so that transit pages would not be picked up and put on the display list.
5. Dave asked a question about using the graphic animation on a raspberry pi for an art installation. Not wiki related, but if you are interested in this you might check the transcript.

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 general 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 6th, 2023.

Transcript of meeting

Ed begins the demo:

Alright, so there have been a few changes.

One that's really mostly of interest to Bob or other people doing serious curatorial work is that when you touch a category like community, for example, we load up the corresponding category page from the wiki.

At this point it would be good to mention that I am not using caching anymore.

There is no local cache of web pages of HTML.

I actually went ahead and built a database of not only the wiki, but also all the forum posts, and even compressed it got as high as 60 megabytes, and that's without a full text index, which is what I was planning to do next.

That just struck me as unwieldy.

I'm happy to have a conversation about that.

I know Bob has got an alternate perspective on the situation, but this particular version does not use a cache, and its database is under 2 megabytes compressed, so it's much more tractable.

But as you move from category to category, we load up the corresponding category page.

Everything else still behaves the way it used to in that regard.

I got all the forums up, so JBeta, JChat, JDatabase, JGeneral, JProgramming, and JSource.

I did find - so I lied to you last week when I said that everything would fit.

There is a post from 2016 that I now cannot find.

I thought it was in January of 2016.

Oh, maybe, yeah, this one almost doesn't fit.

There's another one that goes right off the page, so I do need to come up with another mechanism for showing the forums some sort of scrolling mechanism or paging mechanism.

This isn't going to fly in the general case of the forums.

Another thing that's different is search.

So for search I am using the remote services, and I search not just the wiki but I also search the forums.

So if you go looking for, say, "diadic transpose", so the words that you typed in actually become part of the table of contents on the left for reasons that we'll get to in a moment.

You get two separate sets of search results.

These are the wiki search results and they look.

.

.

I decided just to show them in the order in which they come back from the search engine on the assumption that that's the order, that's relevance ordered.

If that's not true, somebody let me know, but I assume that's the case.

So you can load up each of them and turn or jump around.

But I also show forum results ordered again in the order in which they came back within each forum.

So if you don't think JChat is likely to have anything interesting on dyadic transpose you might jump directly to JProgramming and see what the results look like.

Now the reason I put it into the table of contents that way is that I figure there's no reason search results should be ephemeral.

So if you're looking for other things, say random fixed seed.

We'll go ahead and add that to the table of contents as well, and you'll get the results for that.

So in a sense you can think of this table of contents as being a window into the entire JSoftware website, not just code.

jsoftware.

com, the wiki, but also www.

jsoftware.

com, which is where the forum posts are hosted at this point.

You essentially get a single integrated view into all of that material, plus all the searches that you've done.

If they start to pile up and they're becoming less interesting to you, we do have a clear searches button that will take them all away, but you should feel free to go ahead and put new searches in whenever you wish.

So Ed, what's the significance of the red bar and the kind of gray line there.

It looks like a histogram.

Sure, so the red bars are document counts for the corresponding section of the table of contents.

Community has a boatload of documents because it has a fair number of children.

Actually the big contributor is user groups, the New York City J users group meeting notes that work that bar wide.

By contrast, blogs is pretty modest, so its bar is fairly small, the framework is larger, and so on.

The gray bar is your scroll bar, so if you move your mouse into the gray bar area, the gray bar turns violet, and that's how you scroll up and down the table of contents.

So that's where you are.

That's where you are, and then if you move out, the bar turns gray again, and you can navigate from subcategory to subcategory.

So does the length indicate anything there.

Length of what.

It's a little gray line on top of the red line looking up above there and they're different lengths.

Oh, that's just a representation of the text of the category.

So the gray lines that you see up here are just meant to take the place of the text, the words.

So it's literally a character count for the title.

It's a pixel count.

I look at how wide the phrase would be in pixels and I draw a gray line that's that width.

It's just an orientation visual, not to surprise you, mechanism that apparently isn't working very well because it wasn't obvious what was going on.

Maybe if they were darker, the same color as the text.

One of the other things I'll point out is when you're in the white section, that's when you click and make your selection.

If you go back over to the gray section and drag the white, the selection will stay and it'll be that darker blue.

So yeah, yeah, yeah, I see.

Yeah, okay.

Which I don't think is a bad thing.

You just have to remember to go over to white to select.

You won't be able to select in the gray.

Yeah, I'm the wrong guy to pass judgment on this mechanism, but I got used to it pretty quick and it seems fairly natural to me now.

The one thing that bothers me is that if you do go up you actually wind up selecting the collapsed categories and that doesn't work very well.

Then move over, it jumps and it's not at all obvious what just happened to you.

What I think I'd like to do is animate that paging up or paging down to wherever you touched the gray rectangle, so it's a little less disorienting when it happens, but that's a minor thing.

That's about it for this week.

Questions or comments I'd be very happy to take at this point.

It looks really nice.

I think maybe just an intro page explaining what you just said, the significance of the bars would be good.

What I need to do is implement it better so I don't need an explanation page.

I take your point, but it's not exactly the point that you're making, I guess.

I just need to do a better job presenting it visually, I think.

so you've given me something to think about and I appreciate that.

One thing that might help for me, that violet color is very subtle on my screen.

I almost can't see it.

When you point it out to me, I know look for it, but until then I couldn't tell it from an artifact of my vision.

Gotcha.

All right, well I don't want anybody questioning their sanity, so all right, Maybe I'll try - I will try - making it darker.

The other place - move your cursor off it and back onto it because you get the effect of it graying and then changing color.

Right, but I think the point David was making is that it's just too subtle a transition, and if you don't happen to be watching when it happens you might miss that there was a change.

So one of the things I did in the most recent version was I darkened the horizontal bars bars to make them stand out a little more.

There's no reason why I can't increase the intensity of the currently violet bar and or violet stripe and make it more visible.

And one other suggestion I have.

Some of the time these names are clickable and it brings up a page and other times they're not.

I would suggest when they are clickable, use the blue color that's normally used for hyperlinks so that people will know that they'll have some intuition there.

So this is something that doesn't come across very well in a demo, unfortunately.

It's something you only realize when you use it.

There is no clicking in this interface, with one exception that I haven't shown you.

There is only hovering.

I've got a whole philosophical thing about that that that we could get into, but really everything or almost everything should bring up something.

I mean exceptions would be search or I don't really have anything to show you.

But actually even though like what since you put in the categories so that they display, I think everything you hover hover over displays something.

Almost everything.

Search does not, New Voke obviously does.

Well, New Voke doesn't really.

Oh yeah, I made a reference page for New Voke.

Hover over search for a second.

Beg your pardon.

Hover over search for a second.

I think you'll see it changes.

There.

Yeah, I think that may be an accident to be honest.

Yeah, David, I take your point.

I think the answer is probably to make sure that no matter what you hover over something reasonable pops up, because I think we could probably do that, and then we wouldn't need to distinguish between two different types of links, or as I think of them, sensitive spots.

And just from recognizing voices, I might guess that that's Raul that's asking those questions.

Oh, Raul, I'm sorry.

I beg your pardon.

I didn't even know that you were on.

I can't see any video at this point, because I guess you don't when you're sharing your screen unless you You don't have a sidebar.

Well, you'll either have a sidebar or you'll have a drop down that is maybe compressed right now.

I see.

And if you find it and you click on it, you'll see all of us.

Well, that'll be nifty.

Yeah.

And it's either a sidebar.

I'm seeing it right now as a sidebar, but I've also seen it as a pop up if I'm going full screen.

I think I'm going to save that for another time.

I'm not obviously seeing what the answer is.

Does anybody want to kick around the question of whether to have a probably 100 megabyte cache that would have to be downloaded.

It doesn't seem totally ridiculous, maybe slightly, but.

.

.

How often.

Well, true.

The other question is, what's the incremental benefit.

When I was fooling with the cache at some point earlier on in the exercise, I was struck by how the cache was not much faster than loading up pages from the server on the connection I had in the United States.

I think what's going on there is that in that particular scenario I suspect that the true cost, the bulk of the cost, was not the line time or the server time.

The bulk of the cost was the parsing in rendering time in the browser or in the web view.

That you're sort of stuck with, whether you're using a local cache or pulling pages off a server.

I haven't done any formal measurement.

I'm not even sure how I'd do it really to be sure about that, but my guess is that the incremental benefit of downloading that 100 megabyte file however often, would be pretty modest.

The other reason for doing it.

.

.

Now I've got.

.

.

How do I get rid of this.

The other reason for doing it would be to be able to do local searches, which I was very enamored of.

I'm not as convinced of that anymore either.

These are.

.

.

Well, you mentioned threading off search last week as a way of keeping the application responsive, but 1000, 2000, okay so it's under two seconds to get results back for both the forums and the wiki.

I'm not sure that 100 megabyte file is worth it to get searches down to say 100 milliseconds.

Yeah, it doesn't sound like it if that's the difference.

Well the other thing I'm thinking about is right now we've got the answer to this maybe immaterial because of I'm not sure what's in your cache.

Are all the web pages in your cache.

When I had a cache all the wiki pages were in it and all the forum posts were in it.

And that was the 60 megabytes, is that right.

Yeah.

So what I'm thinking is right now we've got something that whenever you hover it goes out and grabs that page and it's very responsive, which is excellent.

What I'm looking at is what does that mean to the server.

You're moving your mouse around is hitting the server a lot of times.

That's true.

That's an interesting point that I admit I never thought about.

And so what I was thinking on my walk today was that you've mentioned that hover, you know, you're predominantly hover, which I am entirely in favour of because it's so responsive.

It's so quick.

It changes how you look at the information.

But I'll be interested to see what we haven't seen that you use click for.

But from my memory, what you previously heard that when you click on something, that's when you kind of lock that page.

So you go to other pages, you can always get back to page that you clicked on, is that right.

That is right, and I'll sort of.

.

.

So for example, if we go to community IRC bots, I wonder what that was about.

Normally if you wanted to say scroll this web page, you couldn't.

I would love to be able to scroll it in place, so right now operate my mouse wheel for example and just scroll that page.

That would be ideal.

I can't talk to the web view that way as far as I know, so that's not possible.

What you can do is if you click, which I just did, as Bob said, you lock down that page and even though hovering loads up other pages, it's your default now.

So if you come over here to the web view, the Community IRC bots page is the one that will load up and you can then scroll it.

I'm not sure I would be too concerned about the load.

I definitely, I mean, it's a concern and I'd try and get information on it, like talking to Chris or something, but it's going to be so small compared to like a video stream in terms of at least volume of information.

The overhead is going to be number of requests rather than volume and throughput, I think.

So I'm not sure that I'd worry too much at this stage about that issue.

It's something you might want to circle back on later though.

I guess another consideration is that I think just by default by being on the web you're taking advantage of caching services.

So it might actually I know that that's probably not true now that I think about it.

I don't think JE software is behind a CDN, although maybe it should be.

Maybe we should chip in some money and give them a CDN support.

I guess, Bob, the other perspective on this is I would love to give Chris that problem.

I would love to drive traffic to the point where the server or the service would need to be upgraded.

That's not a serious point.

That's a humorous point.

I'll tell I'll tell you my solution then.

My solution is when you hover you'd be hitting everything that's cached.

When you click on something you go up to the website.

And what would that achieve.

It would mean you could hover to your heart's content.

It's not even going to the server, nothing, no traffic.

When you.

.

.

The first hit would have to go, I mean if you don't have it in cache already you'd have to.

.

.

When you put, well no, I mean, unless you're downloading the entire site, you're going to have to load the pages at some point.

No, that's what I'm saying is you would download the entire site, that's the 60 megabyte or 100 megabyte file we're talking about.

You do that once.

It has the potential to be out of date, which is one drawback, but if you click on a page, you will go to the site and actually retrieve what's there.

So that clicking would be a way of getting the most recent version if you were concerned.

Yes.

I see.

And it would also give you in full web interactivity when you clicked on something.

You lost me.

You could edit in it.

Oh I think.

.

.

You could edit if you clicked on it.

I think you.

.

.

Oh you know there is one other thing that it does that I forgot to mention.

So I don't know, Bob, if you've tried to log in in the web view.

No, I haven't done that yet.

No.

All right, it might be worth a try, but the other thing is now I implemented something where if you double click it loads up the current page in Safari on the Mac.

There was a marvelous post about how to do this cross-platform that unfortunately didn't work, but it will work for Safari on the Mac at this point.

The event that's triggering that is a double click, right.

Double click, yeah.

And then it automatically goes to whatever your default browser is, which you can set.

No, unfortunately the only code I could find launched Safari.

It's Safari and you can only do it on a Mac at this point.

I've run into one or two things where I need to make them cross-platform.

and right now they only work on a Mac.

And that is one of them.

- Well, anyway, my solution to the, how we would use the cache is you might download, you, well, you could also, I mean, if you want to get really fancy, you could download an increment so that when you had a current cache and you decided to refresh, it would only refresh the recent changes up to the point.

- Right, right.

- So you could reduce traffic that way too.

But the point being that if you click on something, no longer going to the cache, you're automatically going out to the web and pulling right off the server.

Now the advantage to having it on site is you actually can be off grid.

You don't have to be hooked into everything.

That is a whole separate thing.

We would have to decide that that was a buyer value, as it were, that people wanted to be off grid and still have access to this.

We might, in fact, decide that.

That's true.

I just, for myself, for development, even the amount of downloading that I have to do just to build the local database that I've got, which is much, much smaller, is a significant delay.

I was finding it quite frustrating.

I was trying to imagine asking somebody to live with that worse by an order of magnitude, or two.

Yeah, no, I agree with you, because I did the same thing in your early versions, and it's manageable, but you don't want to have to go through that every time you get into this thing.

Right.

But if you had something on your computer that had already been downloaded once, True, true.

You're just as quick and you don't have to.

.

.

Well, again, it's a good point.

We can talk to Chris and see whether the volume of hits is an issue, not just the volume of information.

Right, and I guess one way we could approach this is to say, let's see if we have a problem.

Yeah.

So if we deliver this and Chris says "uncle," at that point maybe we think about alternate approaches including an enormous local cache.

Well it's good not to optimize too early.

Exactly, don't tune too soon as they say.

Yeah, now something I did notice the very first time I opened this up and was going off the server and everything, the first thing I noticed, the first area that I noticed was that I didn't have access to the forums.

So it actually told me that the, I got in once and then the next time I tried, it told me the page was not available.

And I didn't know whether this was something that had been set up with the forum site that if you were trying, because I was going through a number of different pages and it may just have been a fluke that at some point that server was down at that time I was testing because I've never seen it again.

That's why I have run into similar problems actually, Bob, with the forums.

What seems to be going on is that if you try to get in with HTTP, you will sometimes have a problem.

You'll be rejected.

I was running into that with the links I was building in my database.

I was using HTTP links because that's what the forum uses when it's linking to its own material in a set of search results, for example.

if you use HTTPS, which I do now exclusively for the forums, for everything, it goes through.

I've never had a problem that way.

And it's transient, is it, when it was HTTP.

Because I didn't notice it all the time.

No, sometimes it would work.

Typically I found it would not, but you're right, sometimes it did.

I guess that's it in terms of what I hope to do next.

There are a number of bugs that I hope to fix.

I'm going to try to come up with a scrolling mechanism for forums, or a mechanism for managing large numbers of posts in a subject, and I'll respond to offline requests.

Bob has been pretty good about finding things that are wrong and making requests for new features, and I really appreciate that.

And that's it.

Thanks very much.

Not wanting to constrain you, but I think you could use the same language for the forum posts as you're using on your left table with the lines, and only show up when you're hovering over Yeah, I think that that could work probably pretty well, and obviously it's something that people would already have become accustomed to if they were going to become accustomed to it at all.

Exactly.

Yeah, I may well do that.

Yeah, that's what I was thinking is it's a form that you see once and it's repeated, and it wouldn't take any more training, and it would also extend if you happen to get to a year where there was more posts, more threads than you could accommodate, you could do the same thing.

Yes, yes, yeah, I'm starting to have visions of a reusable user interface component.

We'll see how that goes.

Okay, yeah, just an idea.

Thank you.

Yeah, so amazing work, great work.

I can't thank you enough because it's actually changed the whole way I've looked at what I've been doing with the wiki.

Because what your tool does there is it reduces the friction to a point where finding stuff is no longer the main challenge in the wiki.

It's the categorization to know how you're going to get to this stuff.

Because you can get there so quickly that there's not a cost to going down the wrong rabbit hole.

You swing over your back and you're back out again.

So you can, and with the search mechanisms, you can isolate what you're looking for and suddenly the wiki becomes a lot more accessible.

Bob that's great to hear, that's really good, that was my goal, so thank you.

No, I guess I better fix the bugs.

So I said my first part, I'll let anybody else respond to that and see what they think.

Oh, drop the mic.

I think it's awesome.

Okay, so now my second part of it is it's caused me to reevaluate what I'm doing with the categories because it's out of that when you can move so quickly between categories, categories are still really important because that's the structure of your whole search mechanism.

The better they can be chosen, the better that all works.

But having a landing page that supplies context, not really that necessary anymore, because you're going to be able to get out of it so quick.

Well, that depends on your, I mean, if it's coming into your browser, that landing page is still useful.

If you're on a web browser, you're not using this application.

Oh, I see.

Yeah, well, I guess what I'm saying is I would encourage people to use the application.

I think that that's sure to get into it.

But that's, that's going to be that's gonna be the old guard.

That's not gonna be the new people.

- Yeah, I guess that's true.

- We do still live in a world where whatever we deliver has to work on 1024 by 768.

That will be with us for a while.

- And categories are useful for the vocabulary problem that we call things by different names.

And there are a bunch of things that fall under say linear algebra, which don't say linear algebra anywhere in them.

No, and just so I'm clear, I'm not saying I'm getting rid of the categories.

I think the categories become more important.

I'm saying the context that I'm putting on the category page becomes less important.

And the context, building those category pages was going to be a significant amount of work.

And I'm not sure everybody would be willing to dive in there and try and figure out the things to encapsulate on a category page to get a summation.

I mean, honestly, I was also looking at chat GPT, because that's the sort of thing that apparently does fairly well as summaries.

And it might be enough that you could go down, pull a section out, get a reasonable summary and you paste it in, it would still be a lot of work.

So but the categories I think become more important.

And the reason is because the categories become the spine which Ed's browser exists on.

And so the more efficient those can be and the more clear those can be, the more efficient Ed's browser can be.

And you're absolutely right, Devin.

There can be pages that don't have anything to do with what you're searching for.

But if they've got the right category on them, it will show up under that category because those pages can show up in multiple places.

They don't have to be tied to one category.

Right now, they largely are with anything other people have added to it, because I've added a category to every single page that's in the category tree.

But we can add more places in the category tree that those pages fit.

And that's, I think, to me, right now the curation is working on that problem, not so much building content on the category page itself.

But to Raul's point, you still need that for the web, the sort of vanilla web user that's still of interest.

No, that's a good point.

I hadn't considered that.

Yeah.

I think asking chatGPT to take a run at the problem is probably a very good idea because you're right.

That's a lot of paragraphs you'd have to write and a lot of material you'd have to review manually.

Yeah.

When I started thinking this way, that light at the end of the tunnel got a little bigger.

- Yeah, right.

(laughing) - But anyway, that was how, and I'll definitely think about the fact that if a person is not using this browser, but I suppose the other thing is, there's not really a reason this browser couldn't be a JavaScript browser, right.

It could be WASM.

- Absolutely could.

All the major browsers have enough graphical oomph to deliver this experience.

There's no question about it.

The problem is you'd have to write in JavaScript or TypeScript or something like that, which I made a vow not to do a couple of years ago.

I've done enough of that.

- And the advantage I've always found working with the web view in JQT is that it's consistent.

So you're not trying to cross browser off Safari or Opera or Chrome.

That is pretty much a solved problem these days.

If you're using the canvas and you use one of the frameworks like Angular or whatever and TypeScript, they've hidden, they've managed to hide most of the inter-browser differences, so that part doesn't seem to be as much of a problem as it was a decade ago.

If we were to go that direction, and I'm not suggesting you're going to be the one to do it, Ed, just if it's possible, maybe we can find something you can put it that direction.

Then we would just put that page on the server.

Is that how it would be done.

Yeah, it would just be another page in the Jsoftcore.

com server.

Then you would access the wiki through that window.

Yeah, you'd have the equivalent of a.

.

.

I don't.

.

.

I think it's an iframe.

I don't remember quite how it's done, but it would effectively be the same architecture as I'm using with a canvas on the left and a web view of some sort on the right.

Yeah.

Well, I would say that, you know, in the spirit of what you guys were saying, you know, don't tune too soon.

It's worth keeping that in mind, because if the JQT gets very successful and turns out to be the way to do it, then I think it would make sense then to make it available to people who would just be browsing anyway.

Why give them an inferior experience when what you're trying to do is dazzle them with what they can do.

Yeah, that's certainly true.

I think that delivering it in the web is by far the better solution.

It's just certainly for prototyping, it will be a spectacularly expensive way to do it compared to the current approach.

As I say, you'd have to find somebody else if you actually wanted to deliver a product in that architecture.

But as you say, with your prototyping, I think there's a lot of web developers that could take that and actually put it together relatively easy, because that's what's in their area.

It's the designing and the "what are we talking to.

" and stuff, and for them they'd be getting a solved problem.

It would.

The universe of web developers who could build this is actually pretty small, you really need to find the game developers, the web game developers.

That's not nearly as big a group as the group of web developers as a whole.

But yeah, it could certainly be done.

And that's because the speed of your interactions and everything are more akin to games as opposed to.

.

.

Very few people, very few web developers do serious Canvas work.

It's not a common thing, but the game developers do.

Well, keep that in mind.

Again, I would say see how it goes, and if there's good take-up, you might decide to make that investment.

That's entirely possible.

We're still at the prototyping stage.

I don't want to think too hard about delivery quite yet.

So the next question I've got for you is, I've had the benefit of playing with some of these prototypes.

Do I send it out to the other people on the Wiki group and say, "Do you want to have a game.

I'll play with this and see what you think and then go feed back to you.

" Is that….

I'm very happy to do that.

In fact, eager.

I would like to delay another week or two while I knock some things out.

So you've made some points that I still… some bug reports that I still feel I need to fix.

So I'd like to go another round or two with you and then yeah, I'd be very happy to expand the circle of people who are experimenting with it.

Yeah, it looks about ready to release on a beta sort of thing.

Oh, I would not go nearly that far, Devon, although I appreciate the vote of confidence.

Thank you, that's great.

But I would characterize it as early alpha at this point.

- I'd give it a strong alpha myself, 'cause I played with it.

So, I mean, it's very close to beta, but just because you're knocking rough edges off now, you're not.

- Okay, I'm confused about the direction here.

- Well, the alpha is the very first, right.

- Oh, okay.

- It's raw.

And then you get to beta where you're testing before you release it out to everybody else.

And-- - Okay, that's what I meant in alpha.

Yeah, yeah, and it's a strong alpha, because I think there's just a few things you've got to tune.

Things that I notice that other people may not because of the way I'm using it.

Well, you are the ideal user for this, actually.

Your requirements are more stringent than.

.

.

Your requirements as a curator are more stringent than the typical users, so I very much appreciate having the opportunity to go, you know, sort of cycle through this with you.

So yeah, if we could give it another week or two, then I'd be very happy.

If anyone else is interested, I'd be very happy if you sent it around.

Okay, that sounds great because I think we get some more eyes on it.

People have some interesting perceptions.

You made the point about rough edges, you're right.

I'm really out of big ideas.

So yeah, if we can get some more eyeballs and hands on it, I think that might be inspirational.

I'd very much look forward to that.

when something's clickable you should make it blue just so people can see that clicking is likely to mean something.

In a sense everything and nothing is clickable.

I mean if clicking has special significance.

Clicking takes you somewhere I think.

That's one of the things that I need to work on.

I don't like that click interaction, click to lock the page.

It actually, for reasons that I don't need to get into, I'd like to come up with a better mechanism than that.

That's one of the things I want to work on.

Something that's a little more obvious, something where I don't have to put help at the beginning, that says if you click it will lock the page, and here's what I mean by locking the page.

That's just not a conversation that I think is productive to have, so I'd like to fix that.

Double-clicking to launch a browser, I'm not entirely happy with either.

I think I'd like to have some other mechanism than that, something more visible and visual and obvious that was apparent to people.

That's another thing I'd like to fix.

When you click to lock a page, would it be.

.

.

it's going to take a bit of screen real estate, but if there was an area that actually put in that, like changed that URL, and just next to it said "default" or something like that.

Yeah.

What I was saying is you have a you have a blue rectangle around the current least selected page the currently displayed page Yeah, but you don't have anything that and when you in the current thing, um You blue would always be underneath the the um, the cursor when the cursor is in in an area where that could happen And when you click that it would split the the blue would still follow the cursor and the and the rectangle would stay behind on the And so that just seemed to me evocative user interface.

I understand you might want to replace it, but for what we've got now, I think that just feels right.

Right.

The question would be how would you know to click.

Well, blue is currently clickable.

I mean, that's the thing people do a lot of.

They see blue, they click on it.

Yeah, that's true.

What about if you had two shades of blue, a lighter blue and a darker blue.

Given the prevalence of blue-green color blindness, it might be such a great idea.

No, I'm talking about shades, not hue, but shades.

So that you could actually tell it would be on a gray scale, you can see the difference between the two.

It would be just really a darker blue.

And so when you hover, it would be this lighter blue indicating everything is clickable.

But when you click on it and select, that box is a darker blue and it's left there and the lighter blue around wherever you want.

- Well, I mean, conceptually, only the thing that the mouse is over is clickable.

The other ones aren't clickable until your mouse is over.

That was what I was thinking.

It wouldn't be that the whole, everything that is on the page is clickable because that's not really reflective of the way that the UI works.

- So you do the same thing, except you wouldn't use two colors of boxes.

You'd have the target-- - I have a blue box.

Blue box is what is currently being displayed.

And that would, and then the lettering would be blue for when, for whatever is over, the mouse is over, that could take that box.

And so when it's, when you click it and the box is over, it frees up, the box was now gonna, that might be where you might wanna do the shade shift.

But I was focusing more on giving the person a hint that flicking is an interesting activity.

And for that, having mouse over text be the same color as hyperlink seems like the right way to go.

- Right, so the text would change color when the mouse moved over it.

- Yeah.

- And it would go back to its other color, right.

- Right.

- When the mouse is not over, it would go back to the original color, yeah.

And so you'd have this double thing happening.

You'd have your sliding window going up and down.

And when your mouse goes over one of the texts, they change color to blue.

And if you click on it, you get a box.

- If, you know, the box is gonna be there.

Box is gonna match whatever is always gonna be there.

- Yeah.

- The box indicates this is, here's the correlation with the right-hand side, the web view.

So when you don't have something frozen, the box is just gonna follow just like the text.

when you click on the blue text, the box is going to stay behind and the blue is still going to be underneath the cursor.

So what I'm thinking is why not just have the box show up when you click.

It doesn't have to be there.

Your mouseover could be blue, right.

Blue the lettering.

And it would be changing the window.

And if you click on it, that window would be locked in for.

.

.

I guess that would work.

Well, and the way you would know it would be locked in is that window would then show up maybe on similar dark blue in a small text thing with the URL saying.

.

.

Or on the border.

Yeah, yeah.

So that the dark blue of the box on the text and the dark blue around the URL and default might be enough to give the people.

.

.

Oh, that's what it's going to default back to.

So let me ask this.

Suppose that we kept a history of the pages that you've paused on long enough to load, and that history is a drop-down menu on top of the WebView.

And the WebView being the main display box.

The box on the right.

Yeah, yeah.

So you're hovering around loading pages and you decide, "Hey, that's a good one," and you mouse over to get to it, and along the way you touch other labels so other pages are potentially loading.

But you get to the web view and you go up to the history menu and you drop it down, and there right near the top is the page that you were interested in, the most recent page.

Sorry, among the most recent pages near the top of the menu is the page that you were interested in.

You select it and it loads up in the web view.

You're now in the web view, so you're not hovering over any more links.

Yeah, but in a time from when you left the page you're interested in, you're hovering over it, you would have to have some length of time that you'd be able to scan over those other potential and not include them, right.

No, you'd include all of them.

So what might happen is that the page you were interested in might not be at the very top of the history menu.

It might be a couple of items down.

If you move the mouse quickly over to the web view, you're going to maybe touch one or two other links along the way that might successfully load.

So when you click on that history menu, the page you want might not be the first or the second, but it's probably the third or the fourth.

Would it be possible to have.

.

.

I'm just trying to think of whether it's even conceptually possible, but essentially if the mouse is over one of those links, say less than a second, it doesn't go in that history.

Ah, yes, very good.

And then you could move around, you move maybe more quickly, but then the thing is tuning that second.

Is a second reasonable.

Should it be a half second.

That's good.

That's the second that you spend actually scanning the page and indicating that you're interested enough that it's worth hanging on to in an ephemeral sort of history.

Yeah, I like that.

Moving there, you wouldn't, if you did stop on another page and sat there, well then that would go in the history too.

Yeah, that's good.

I like that.

You got your eye.

Actually from there we could have a button right above the web view that would say launch in Safari or launch in a browser or whatever.

I could leave the double clicking in because it's convenient, but you wouldn't actually need to know about it to get the functionality.

Yeah, that would be a good option.

As you say, the shortcut is double clicking if you know it.

But that's the challenge of a lot of Apple interfaces.

It's amazing things you can do, but most people don't know about what you can do with it.

Three fingers, man.

Three fingers.

And it used to be deep touch as well.

I mean, there were so many things coming at you.

I always try it again every once in a while to see if they've brought it back, but not so far.

I think it's gone.

I don't think developers were used to it.

Like Clippy.

Oh, well.

Yeah, it might come back with AI.

All right, thank you all very much.

I really appreciate the discussion.

It's extremely helpful.

Well, thank you for all the work.

As I said, I really think this is going to change the way the Wiki goes forward.

I sent an email to Eric just because he was saying, "How much longer do you want to keep with this.

Are you losing enthusiasm.

" I said, "You know, this is the The second big thing that's kind of come out of the wiki group is this browser because it's changed the way you look at the wiki, which I think is really significant.

But the first one was the J playground.

And both those things wouldn't have happened if we hadn't been working on the wiki.

Because it was the group that got the ideas together that got people enthused enough to go off and do something significant.

So if that alone, if this becomes a bit of a garden that things grow up, you can select, I think it's worth curating.

It's worth curating and I'm not happy with it.

I'm not frustrated with it or anything.

Good.

But again, when something like this comes up, it really, it brings me up a level because it's really good.

There's a, it's a whole new way of looking at something that I spent the last 15 months looking at.

(laughing) And I think that's great 'cause I didn't have to come up with it.

(laughing) Yeah, so I guess we're into anything else anybody wants to discuss, if there's anything else or what we've discussed already.

We've got another seven minutes left.

- Okay, this is a great opportunity.

So I would like to enter an art show tomorrow.

Tomorrow's coming up and what I've got is I solve the diffusion equation with moving, slowly moving sources and sinks.

And I do it for each color, R, G and B, and then combine them and just draw the matrix.

So this works great satisfactorily to me on big computer.

And then I, but I, but I'm not, okay, but I need a way to display it and hang it on a wall.

So what I've got is a monitor with a Raspberry Pi behind it.

Because I mean, we have pads and stuff, but out of date or I don't know how to use this Apple stuff.

Anyway, I find running into problems with the Raspberry Pi And those things that work on a big computer don't always, don't seem to work on the Pi.

Right, so my original implementation had this Iverson software draw child using JQT.

That doesn't seem to work on the Raspberry Pi.

So ViewMat is another way to go because I've got a two-dimensional matrix.

But then I fill a page with hundreds of ViewMats and that doesn't work so well.

So I just found about CloseAll, but in most recent tests at about 7 p.

m.

tonight, Closeall gave me some error.

I think that's what it was on the Raspberry Pi.

Anyway, so I'm looking for a way to display, I'm looking for ideas for how to display a matrix that changes with time and nicely.

- Are you using JHS on the Raspberry Pi.

- No, I'm not, I'm QT.

- Just J console.

- I, well, yeah, and then, right.

Hmm.

I could use JHS.

I mean.

.

.

Well, the advantage I think of JHS is it's based in web.

So if the Raspberry Pi can show web pages okay, then that's JHS in your displays.

okay, I have very little experience with JHS, but it, all I've seen so far is it comes up with a console and that's great for for me, but I haven't tried pictures.

All right, so maybe JHS is a way to go.

I mean, fundamentally, if I haven't used J, I haven't used View Mat on J console, so I was just, mostly I was just trying to figure out the start, you know, where you're at, so I can be relevant.

It's kind of, I can't, if I suggest something and it has nothing to do with where you're at, it'd be kind of silly.

It sounds like you want to clear the session though.

Exactly.

And I think that should be possible, but I need to know what your session is before I could even begin looking at how to do that.

So, you know, if it's a terminal emulator, that's different from if it's a browser.

Well, okay, well, you know, the Raspberry Pi runs Linux, so.

.

.

Is the Linux console.

Yeah, web browsers, so.

.

.

Well, it is JHS.

No, I'm using JQT.

- Are you using JQT on the Raspberry Pi.

- Right.

It took me a few days to get the right version of the operating system.

We had QT4.

- Oh, so when you do a viewmet, it pops up a new window every time is what you're saying.

- Right.

- Gotcha.

Okay.

One thing to check before I go too far into looking how to shut a window, I think that's possible.

But on Rosetta code, there's some animated demos.

And I wonder if those work on the Raspberry Pi.

Because if they do, that would be another route.

Let me look up one real quick here.

Let's see.

Ah.

Code.

Let's try.

I'm having problems remembering what to search for.

The other thing, David, I just went over and looked at JHS.

There is under tours, if you load up your JHS, you'll get a web browser window.

Under tours, there's one specifically for Canvas.

And that seems to me that might be the area that you're looking to do if you're looking a matrices display and colors changing.

Canvas is the right thing, yeah.

I posted a link in the chat.

See if that works on your Raspberry Pi, the J implementation there.

Okay.

And when I opened up JHS, it's under the tour menu and it's canvas.

It's about halfway down.

I haven't gone through it, but my guess is there should be things there that would be useful for you if you were going to use JHS.

Great.

All right, I'll try these things.

Thanks.

And good luck with the art display.

That sounds quite innovative.

That's good.

Good stuff.

- Okay, so I'll post the code eventually on the site and so it'll be able to run it or whatnot.

- Is it interactive or is it just set up to, I shouldn't say just, is it set up to be able to just develop colors and move them around the screen.

- Yeah, that's the idea.

I mean, it could be interactive if I had a touch screen, right, to drag the sources around, you know, a lot of one touch per hour or something.

It's quite slow.

You know, the exhibit runs for a week or something, a month, I don't know.

And the idea is that you might watch it and it might change.

And if you come back the next day, it's completely different.

- Yeah.

That's cool.

That's a very cool idea.

Big concept.

- It's not noticeably changing within a short time.

- Well, it does when I run it on the big computer.

(laughs) - I see, okay.

- Yeah, so I submit each, a thread per color, right.

And then I can combine them.

So I solve, right.

So I solve the heat equation or diffusion equations, same thing on, for each color, as I said.

- And how does the Raspberry, I mean, this might be the issue.

How does the Raspberry Pi handle threads.

- It doesn't.

- Yeah.

- So it's not a threaded application on the Pi.

- Yeah.

So you just sequentially work through the colors, I guess over and over again.

Is that how you.

Yeah, yeah, yeah.

Well, neat stuff.

Anyway, that was the direction I thought things would go and thank you for that.

That's great.

I guess until next week and you can hoist another Guinness for me there, Ed, whenever you wish.

I'll hoist them over here and I'll think of you.

Again, thanks for all the work.

Thanks to everybody for coming on and giving the feedback.

This is important.

And I think it's, again, I feel kind of like when I was watching J Playground takeoff, you get excited for what you're going to see the next week.

That's a lot of fun.

Okay.

Well, great work.

Everybody be safe.

Bye bye.