Wiki/Report of Meeting 2023-04-13

Report of Meeting 2023-04-13

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

Full transcripts of this meeting are now available on the its wiki page. https://code.jsoftware.com/wiki/Wiki/Report_of_Meeting_2023-04-13

1. We started off with Ed's sixth demo of the new J wiki browser. As much of this is visual the video can be watched here. https://www.youtube.com/watch?v=uo7j1Gyl2og Ed has added an area for tags which he suggests are the best representation of the user defined categories. He has grouped these categories into alphabetical groups which have a more manageable size which can be further probed
2. The next topic was the way to represent forums. There was a discussion between Bob and Ed about the way that the interface for the forums could be organized to allow quick access through years to months to threads and then to posts. Raul suggested that a click and hold interaction that would freeze interaction until you release in the new position. This would be used to reduce unwanted hover selection. Ed wishes to explore the hover mode as far as possible because it encourages information exploration.
3. Ed felt that there are two use cases for the forums. One is to find the most recent posts and that case is supported well. The second case is browsing through threads the way that you would browse through a magazine. Ed wonders if there is another use case. Raul suggests that the structure of the forum does not lend itself to use cases beyond those two. Bob relayed that his son, Stephen, who has education in UX and design, felt that the search and the speed of access was the most powerful aspect of the interface. Ed pointed out that not all posts show up in the search, although they do if browsed in the thread. ED confesses that he has found that the current interface allows him to browse the threads in a way that is quite pleasant.
4. Bob suggested using the entering of the labels to restart the timer, as it seems to pick up entering more quickly than leaving a label. Ed suggested that that is done with a quarter second lag which could be tuned. The right side of the screen does not have a lag, but the web based right side which has a lag anyway has a quarter second lag. Raul suggested an accordion of the months below the years. That may be too many to represent visually, since it would be a couple of hundred entries. Raul further suggested an accordion for the years as well as the months with a zoom slider similar to the vertical table of contents. Ed's solution of opening a gap in the months below the years
5. Ed asked if there could be some design support provided, as his expertise is in programming and not design. Bob said he could get in touch with Stephen to get some support. Ed said he was looking for information on colour palette.
6. Ed is currently looking for a way to partition the 'public' wiki information from information such as bookmarks that might be more 'personal'. Ed is considering whether this could be done on one database or if it requires two. Is the current protocol to ask permission before writing to a file? Bob felt that as long as you are writing to the temp file and it is information that the user generates, such as bookmarks, that should not be a problem that the user is storing their information in their own file. Raul wondered about how much we could know about the user's machine and that could lead to problems. Also that the files be managed in one folder, possibly titled 'J wiki browser', that has the files that the user would know not to remove that folder. Ed prefers having one database file to retrieve debugging information more easily. Raul suggested writing 'personal' information to a J file, clobbering the database and then read the 'personal' information back into the database to repopulate the 'private' information.

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

Transcript

So, as usual, and I think this is just a hazard of building things, when you start out, all the work you do results in something new and exciting.

I should ask, can you see my screen?

Yes.

Okay.

But the more you build, the more any change you make is incremental as a percentage of what you've already got. So there's not a lot new. The only thing I will, although we do have some things to talk about, the only thing I will mention is tags. So, tags are, it's like we just, as I understand it, categories. They're not any different categories as we usually understand them. they just don't participate in your category tree, so they're freestanding in that sense, at least for now. They may start building up their own little mini trees, but for now they're flat. And they're represented here. Initially we had, I think there were about 300 of them, and they were simply a flat list where I'm mousing it now. And that was just too long. That didn't make any... that just didn't work as an experience to my mind. So what happens now is I simply take every 15th category, add an ellipsis to it, and then show the 15 categories underneath that sort of synthetic, synthetic category On the right so it's just now part of the table of contents like any other part of the table of contents They don't behave any differently The other thing is Bob you and I are still going back and forth How to handle The forums and I'm It's one of these things where a picture is worth a lot of words, so you had some thought I managed to wrap my arms around a couple of them. So for example, the ears are now in descending order rather than ascending order. One of the things, I'm not sure whether to be happy about this or not, one of the things about a hover-based interface is that it's a lot more sensitive to any mouse movements you might make. where typically when we are operating user interface, it's pretty safe to move the mouse around without clicking or dragging. As long as you don't click or drag, nothing much usually changes with a hover-based interface on this, and there have been huge changes based on small mouse movements, because if you touch a sensitive area, a lot can change. So I stacked the years on top of the months here, and that initially was, for me at least, quite annoying, because if you picked a year and then you moused down to interact with posts, you would go over the months, and you would mouse on a month, and there was an 11 or 12 chance that you clobbered the posts you wanted to look at. and that was bad. So I came up with this desperation mechanism where the months get out of the way and leave a gap where you can come down as you move from year to year. But Bob, from the exchanges we've had, you've got something much more than this in mind, and you seem to have a notion of sort of traversing the from left to right as you move the mouse. And I'd like to understand that. I'll first ask if there are any questions or anything that I've shown so far. And then I would like to talk about that. I'd like us to get to the point where we're both happy with this. I have no further questions and I'm looking forward to the discussion on the forums.

- Let's do that then, if you could go ahead.

Start talking.

- Okay, so I probably haven't communicated it very well, but if you took the line that 23 is on for the years and lowered that line right so it's level vertically with J programming. So when you come out of J programming, you're right on the years. And then underneath that is the months, and then underneath that is the, just as it is now.

- So the years and the months would shift altitude based on which, oh how interesting.

- Because as you come out right now, you're going to go over one of those items. You're not interested in them, but you're gonna go over them, right?

- You might be interested in them.

- Well you might, but it's unlikely, right? You're more likely to want to select off of year and month. I think. And there's nothing keeping you from going year, month, and dropping down.

- Unless you're going after the current thing, which is where you usually start out at. If you're looking for a recent post, it's where you're at. If you're looking for a historical post, you wanna dive back into history.

- Right, but you see, that would be the advantage of lowering that year level, so it's right across from, in this case J programming. So you could go back and forth across the years. You're not going to hop on to a more current posting because you're right in the year. So you could go back to whatever year you want, drop down to the month, and then you can drop down further into this particular, into the particular threads that you're interested in. And then from there you can go to the right and select a particular post in that thread. And what I had originally thought of, like and I don't, I think the solution you came up with which is the horizontal one, that actually works pretty well. The original idea I had was you do that instead vertically. So that you'd have a line vertical of the years there. And then next to that would be vertical, well actually you would have a line of the years followed by the months that were available followed by the next year. And you'd do that the same way as your other columns. So it would become an index into the year month. So it would be in one line. You'd see 23 April, March, February, January. And then you'd see 22, the 12 months. You'd see 21, the 12 months, all the way back to '05. And then when you got to whatever level you wanted, you would move across to the threads, go through the threads, go across to whatever post on the threads you'd go across. And the trick with this is you're absolutely right. You have to get a line out of the way to be able to really do it efficiently.

- I have another idea that might or might not be horrible for how to approach this issue.

- Okay.

- Which is currently it's a Hover system. And we have the idea that you click on something freeze that one in place. How about if instead of clicking on something to freeze something in place, clicking anywhere in the left-hand pane freezes everything, as long as you're in the left-hand pane, as long as you have the mouse down? I think I need to repeat that one layer of detail on that. If it's frozen, as long as they stay in the left margin. Right, but I'm saying what if we change that? Okay. So as long as you're anywhere on the left hand, the ISI graph, or ISI draw, whatever you're currently using for that, as long as you're there, having the mouse down means that you're not, the Hoover is disabled, whatever you currently got selected there stays selected until you let it up, and you're using Hover again, or until you leave the window, in which case it doesn't matter. So you click down to select and then you can drag across all these other windows. It won't do anything until you release and then you'll be into the next window. Is that right? Right. The only downside I see to that currently is there's that quirk where we don't know if they release outside the window. So you have to click inside the window again to unfreeze it, I guess, if you let it up. But other than that, which is a document, you can solve that by documentation, maybe, but it's a little bit...

It's a huge change in the interaction, and I'm not quite clear what it would be buying us, I guess. Well, what it buys us is the ability to go over arbitrary pieces of that interface without changing what you're looking at. We can do that by just moving to a click-based interface. And I hate to be difficult, but I'm going to be. What I want to do is see how far we can push this non-click velocity. And it's possible it will break before we're finished. And I've accepted that. I want to see how far you can push just hovering. And it has its frustrations, and Bob has mentioned this and I recognize it, but it is a style of interaction that we are accustomed to. It's how drop-down hierarchical menus work. And we manage to navigate them okay. It's not ever the primary user interface mechanism, I grant you that. But I would like to see how far we can push it. And the reason for that is that I think we've all been, because the web is so slow and disorienting, we've all been habituated to hesitate to collect it. And for that reason, I think the web actively discourages information exploration at some level. And I would like to sidestep that, if at all possible. We're all very comfortable hovering on things. Hovering is a safe thing to do. And what I'd like to see is whether we can build a whole interface that's based exclusively on this very safe thing that we're all comfortable doing. doing, and perhaps in that way encourage information exploration. I apologize for not having mentioned this before, it's something that's... I've always had it in the back of my mind, if only gradually, you articulated it to myself, but now I am articulating it.

Actually, I think if you haven't articulated it before, I've certainly got that impression. So, it's been systematically there.

I do have to say, I am still unclear on what you're looking for. It really sounds as if what will be happening is that the years and the months that are used to navigate the forums would actually change altitude as you move to the forum. Yeah. Interesting. So what, suppose I were down here at J Beta, let's say. The year would be right here where users define key to the JR. And then what would be above it?

You could, I'm not sure. At this point I'm thinking I don't have anything to put in above it. It's dead space right now, but that doesn't mean it couldn't be used for something if we thought something might be useful to put above it. What would be below it would be what you're selecting, you know, year by year, and then below that would be months.

I want to return to something Raul said. I think there are two use cases for hovering on the forums. The first use case is "what's the latest?" and we should support that, and I try to. So you always select the most recent year and the most recent month where you pick a forum. So it's always... right now it's April of 2023. And that's one case that I think should be supported and is right now. And then the second case is historical browsing. This is not really how you would search. This is how you would leaf through a magazine while you're sitting on the couch, which is another image I like to have, a cover-based interface, if it's not casual. And that also, I think, is supported by this approach, because you can, in fact, go directly from selecting a forum on the margin to picking a year, picking a month. So I feel like, is there another use case that I'm missing here that isn't covered by the interface?

Well, if you're in the forums, the issue is that the information structure doesn't really support other use cases. We have search and we have dates, but we don't have a designed hierarchy other than that. So unless maybe we go take, maybe we can do something with titles. I don't know, titles across all time and look for common words and build a cloud out of that or something. We don't really have, it's not really organized for browsing. It's a time series thing.

When my son looked at this interface over the Easter weekend, he came and visited and he's got a background in UX and some design stuff. He was really impressed with it. He was super impressed with how fast it was. And when I showed him the search, he said, "Well, that's what people are going to use." Just done. Like, I mean, that's what you would use. The other stuff he said, and he kind of pushed it back on me. He says, "The other information you've got there is all the categories. You're going to have to be really clear about what categories you're choosing and choose categories that allow people to naturally navigate." He says, "That's a tricky process." But he says, "The search is exactly what everybody would use. It's just so quick and it zeroes in." So when we get back to talking about the forums, the fact that the forums show up in the search means that you're gonna do a text search and those forums, that's what you're gonna be looking for most of the time. I don't think you're gonna browse the forums because I don't think as Raul puts out, there's so much information and it's organized by year and month and maybe a title of a thread. But past that, it's really not organized because it comes in as it comes in.

- The threads are useful though. Often when you're reading a message, you need to see earlier and later messages in the thread to understand what they're talking about. And you have access to that this way. And you would have access to that as well on a search. But you don't, in fact, and that's actually a really interesting point. When you do a search and you find a forum post in J programming, If the rest of the thread, if the posts from the rest of the thread also match the search, then you get them and that's nice. But if there are posts in the thread that don't match, they're not going to show up.

Ah, gotcha.

Right, so maybe there's something that could be done here, somewhere, I'm not sure where. Well actually I would say that's a feature, not a bug. Because if I do a search, I don't want to go to a part of a thread that doesn't mention what I'm looking for. Sure, but there may be some context early on in the thread that's of interest. Like what problem was this, what problem were they trying to solve, in fact? A lot of that actually shows up in the thread, so it just so happens that the way people reply, it includes the earlier post. So maybe this isn't really a problem. But if you do get a post where somebody doesn't set that up so the previous post isn't there, When you go down to the bottom of the thread, you can then actually, by clicking on the web view itself, go back or forward through the thread, because that's always there, right?

That's true. But that's the clicking thing that I'm so... Yeah, but I think by the time you move over to the web view, you're in the zone where you are clicking, right? I think you kind of have to give that. What I wonder is, could we come up with an experience where we made the entire thread available within the search results in such a way that it wasn't intrusive or annoying? In other words, these are not in fact search results, but you do have access to them if you want it, easy access to them if you want it, in the context of the left side of the interface. So, if I understand what you're saying is what would happen is if you had a text search that matched something in that thread, what you would do is put the thread in instead of the specific post that mentioned that text.

Well, you put the specific post in because you do want to be able to zero in on the hit. but somehow I know not how there would be immediate easy access to the entire thread as if you were you know as if you were using a standard even here on the standard one you don't have the entire thread you just had the spread within that month? No, it's buggy, but I do try to grab the ball, Raul. Okay. Yeah, so I'll occasionally, this one looks like it's working, but I do get all of the authors. I'm having a little trouble, occasionally the URL that I build is inaccurate in the month that it selects, so you'll get a, You'll get no hint loaded in the browser. But the framework is there to show the entire thread, and that works, and to load any element of the thread, and that's fun. But I will fix it.

I would actually also dispute the notion that people won't browse old forum posts. I find myself doing it when I should be programming. It is sufficiently easy now that you just go from month to month or year to year and run your eye down the posts and maybe there's something interesting. How often there is in my experience.

And actually I think your format now works quite well for that. You can see the titles of the thread and other than expanding what that text is, which actually I don't see advantage to because if you hover over it, it's gonna show up in the web view. So, I mean, I don't... (indistinct)

- I'm sorry, I interrupted, I saw a button.

- Yeah, no, no, I know I got distracted by that too because I was wondering what was going on with that too. But yeah, so what I'm saying is I think your format right now works well for browsing. Because you're seeing the information, as much information as you're going to see on a thread without going into the individual postings is down your left side. And the individual postings are on your right side. And when you hover over that thread, it's gonna grab, I think usually the top of the thread, doesn't it? Most recent?

Oh, that's the idea. Yeah. So this should be the middle.

Yeah, exactly. And that's what you're going to want to do if you're browsing. And then you can move over to the individual posts. But you see what the advantage is there. You can just hover over the thread title and you're going to see the post in your web view. So... Yeah, you'll see that's the... Yeah. It's going to be there so you don't need to put it anyplace else.

Oh, I'm sorry.

What I'm saying is in your columns for your hover area, you don't have to have any more information because your column for your thread is going to take the top of that thread and show it to you in your web view. So there's no need to put more information in the column. That is probably true, yeah, I'll go along with that. So in that way your view here is fairly uncluttered.

I appreciate that and I think I would agree. I'm still struggling a little bit with the idea of moving... I do like this notion of malleable user interfaces, I think I wrote to you about that at some point in the passing, Bob. And I would like to experiment, or at least think about the notion of moving the years in response to where you're hovering, which forum you're hovering on, because of the intriguing idea. I'm going to need to think about it with some more analytical concern about losing the real estate above. I have a pretty spacious screen but not everybody has a screen that's spacious. I'd be the first to not explore it.

Well, I have been thinking about, I have a comment on Raul solution, which is to click and hold down, and then the changes aren't responsive while the mouse is held down until you release on another point, and then it's responsive again. I think the challenge with that is quite often that's used in the language as dragging something. And we're not going to be dragging anything. So that's one thing that would be different in this interface to somebody who's used to to clicking on something and dragging it across. Clicking would basically cause your mouse not to trick on the hover until you go up and release it and then it would be hovering again. But the other thing I'm thinking is the other way around it is still our one second delay so that if we're over a part less than a second, it doesn't register. Or probably less than that. say less than half a second.

Yeah, I've got it down to I think a quarter second now, which may be too short. Well, we can... That's the idea. Yeah, yeah. That's why I believe it's part of the theory. So if you're on Essays for Mutations, and Bob, I did use that air gap mechanism that you mentioned, where I added an extra view in between, and it works most of the time. It picks up the mouse event So you'll notice I went Actually Selective scripts cardjet cards generator, but we're still looking at essays permutation So I was on scripts cards generator for less than a quarter second it got selected But I wasn't on it long enough to Load up a page, so we're still in the page that I picked from over here I think.

- And so what I guess I'm wondering is on each of your buttons, if you could stop your timer when an enter the area for the mouse happens. So you're not concerned about leaving the area, you're concerned about entering the area and then you would start the timer again. What would be the effect of that be?

- It means that you don't have to wait for a second or a quarter of a second. You don't have to be over the site for a quarter of a second to tell it, I don't want this one. If by the time you hit the next site, you enter the next site, restarts the timer. It's just, it's, oh, you didn't want that one. And now it restarts the timer. If you stay over that one, it's gonna change to that site. If you're moving through, it's gonna, it's gonna, I guess in terms of what the computer is seeing is, it's gonna see enter, not interested. And as you enter the next column, it's gonna go, oh, you weren't interested in the previous one. Oh, you weren't interested in the previous one. And then if you stop and hover for more than a quarter of a second or whatever, it's gonna say, okay, I'll switch to that one. Your delay is a quarter of a second and it's-- (indistinct) Well I think he's triggering it on the timer being over the button for his length of time and if it's less than that it doesn't pick it up. But if you go through it, it has to realize that it's gone through. It seems to be very quick on picking up entering. And my guess is because we're not doing any timers with entering. And so what I'm thinking is if we reset a timer on entering, it'll just be just as quick and we'll know...

That's what's happening. That's what's happening? When you enter, when you touch a label, we start a quarter second timer. Every time you move to another label, we restart that timer. Right.

Okay.

So you said, it's only when you pause for at least a quarter second that we load up So if we get that, if we tune that time maybe a bit, because if you think about it, because it's not dead in the time that you're moving between, because each time you do an enter it restarts the timer. If you go say from J programming when you're in your forums and you go across to do your Your year say you go up and through it shouldn't change anything Right it's as you enter the new year It's it's gonna go. Okay. You didn't want the last one You didn't want the last one the same way if you came down It should do the same thing with the months. You may not have to move the months out of the way. Oh Because you're not on them for that long There are two different things happening, maybe that's a source of confusion There's selecting structure which is instant And there's selecting content which takes a quarter second

So the left side of the screen is instantly responsive. That's your structure. So yeah Right side of the screen because we're dealing with the web, but it's slow is has got that quarter second timer on it I'm a little reluctant to have the left side of the screen become unresponsive I want it to be like a video game. I live with the fact that the right That's just like in the big city. There's nothing we can do about that. Yeah. Yeah this How about this? For the top nav, instead of it being a two-layer thing, have it be a horizontal accordion which combines month and year. And it's still a vertical thing for year over month, but it accordions just like on the left side, except for it's a horizontal accordion instead of a vertical accordion.

So it would be, if I hovered over 22, the months would be inserted between 22 and 21. Right, there would be 12 22s, with a month label underneath it. Got it.

And then if I wanted to move rapidly from 23 to 14, would I have to go through 12 times? Yeah, but it's an accordion, just like you have on the left side. except it's a horizontal accordion. So the ones that aren't close, you just see a little little bar indicating that it's there, and you have a magnifying glass showing the ones that are near where your mouse is. Isn't that interesting? Huh. So let's see, so that's 25, 18 times 12.

So that's a couple of hundred for J programming, that would probably be a couple of hundred elements to scroll through. I think that might be too many. The same thing that drove us to put subcategories in tags, which was that there were a couple of hundred tag categories, a few hundred tag categories. would it help to have two levels of magnification? Like you have... Well, that in effect is what we've got now. But I mean, instead of it being... Here it's two levels, but it's not magnification. It's one level that's an accordion, another level that's a different kind of hierarchy.

Right.

As opposed to what I was thinking, or trying to think, or trying to say, is have two levels of accordion up at the top. you have a near horizon and a far horizon, and the far horizon is just lumps. Right, I guess my response was trying to get to the idea that we have a far horizon in the top now in the form of years, and a near horizon in the bottom in the form of months. Maybe I'm not fully seeing what it is that you're describing, for which I apologize. Maybe it's a bad idea, but you said you're talking about on the order of a couple thousand elements in the accordion, you know, exposed elements.

>> A hundred. Well, time. Yeah, okay. Okay, and I was thinking you have maybe six that are current and then a pictograph representation of the nearest 20, 30, 60, whatever, something nearby, and then just a blank space outside of that for ones that are not close. I like the idea... I mean the nice thing about some sort of magnification accordion scrolling mechanism is that we could get it down to one dimension, and that would mean that you could more easily move through time, you could move through time across a single line rather than having to go from top to bottom to navigate. And that's, as you point out, Raul, exactly what we're doing here, and that, based on a user group of exactly two people, seems to work okay.

What about if what we did, instead of showing every year over its month, you would see 23 and then centered under 23 would be, well, 22 would have 12 months under it. But you would, I'm just trying to think of how you would do this. You'd have to have them spaced out more. So you would still do an accordion effect, but you're only going between 23 and 22, but there would be a gap between 23 and 22, so you could actually have the months expand underneath you. And you might not see all the months, but within the range of between the space between 23 and 22, you could have enough space that going one direction would pull you all the way back, say from January to April, and going the other way towards 21 might give you all the ones between August to September.

- I think I see what you're saying.

- Yeah.

- I'm struggling a little bit with the problem that was told me at this point.

- Well, I think it, what I think it gets around is that you might be able to leave your months and your years at the top, because as you go over, as you go over your hover, you're not gonna be switching things all over the place, and you may not need to move your months around. If, when you're on that section of the years, you've got the months that you want underneath you, And you can move to those months without moving off them, essentially. So... But I have a problem still, where I see something that I was interested in because I was hovering on 21. Yeah. So I'm interested in the bug report, for example. Yeah. Is moving down going to a month? Yes, but my way of thinking, and we may not have the sensitivity and positioning to do this, My way of thinking is by moving the mouse from one side to the other while you're over a year, will allow you to put the month that you want under that number. Yeah, and then you would just drop straight through that month to the bug report. That in effect is Raul's solution, where the entire months and the years are effectively on a single line. Right, the difference... It just so happens that you're filling the mugs in a second line, but you wouldn't actually need to. Merely by being at the right distance between 22 and 21 you would have picked August.

Exactly.

You wouldn't need to touch August down below. That's right.

So I think, okay, from two directions we've come to a similar solution. The difference from RAL's solution is mine would only have 18 entries at the top line. No, no, it would have 18 visible entries on the top line. Right, and so that's where I'm saying we may not have the gradation, we may not have the sensitivity to be able to control that easily, You just need them to space them enough apart that you could move back and forth between while you were hovered on something and have the months float back and forth for you. And they would be on an accordion underneath you. Right. Right.

Yeah, I don't know if we've got enough pixels to make that work for the date ranges we have to support.

Yeah, no, no, I agree. That would be the question. It's sort of a parallel to what I've... Go ahead, please.

Oh, I would just say, to me it's sort of a parallel of what we've got on the furthest left table of contents, where now when we go up and slide up and down, when our mouse over something, that's what it's going to be highlighted, that's what it's focusing on. We don't need to go out to the white section, right? That's true. The only reason, you and I have talked about going back and forth on this, the only reason for the white section is that I think of the scroll stripe as being your course navigation, And the white section is being your fine navigation. And I think the longer the list gets, the more appreciated you'll be that there are two different navigation mechanisms in this whole list. So you can get into the neighborhood you're interested in, but it is very sensitive. It's very easy to pick the wrong thing as you're moving to the right. It's kind of nice that it's rolling stuff in the white section. I think that depends on how magnified you are. When you make, yeah, yeah.

And you don't need to see, like, what you're seeing now I think is great, that number, I think that gives you some variety. But if it doesn't give you the scrolling you need, I think you could magnify in a bit more because what happens when you get to the top is you reach your level but then you can still go up and get nuvok right I really like that interface um good I'm glad and so I guess what I'm saying is when I'm going ahead no I was I was just asking that you go ahead because I'm still a little bit confused. Well, the same thing that I'm seeing on the leftmost table of contents, if you think about that same thing happening across the years, except that that same sort of thing would happen, so your year would expand, but what would expand below would be the months of that year. year. Right. No, I think, yeah, I think it could be done. The only open question is, on a typical screen, can we support 12 months out of the year for, you know, '05 to '23? And I don't know. My intuition is that we can't easily, that it would be too frustrating, too finicky, but I could be wrong about that. I am going to think about that, for sure.

I think, from what I've got in my mind's eye, I think we'd only need to expand to four months out of any group. And as you moved to side to side, that four months would shift through the year. And the rest would be just lines.

No, no, because the presumption then, or the problem then is that I will clobber when I move down from the year through that four-month segment. I have a three in four chance of picking the wrong month when I do that. But you should, depending on, again, I think the challenge is how finally we can, we don't want to get so fine with the mouth movement that nobody can do it. And I think that's what I'm bouncing up against. So that I could position it so the right month is under the right year and then I just drop straight down. But I don't know that it's easy enough to differentiate between the months when I'm on a year. Even if they're expanded, I'm not sure I can do that.

- Here's another very, here's a completely different way of tackling this problem that doesn't accord you at the top, which is whatever month is selected is the month that is directly underneath the year when you first select the year. Then when you go down, you're not changing anything. You're going down and moving horizontally if you want one of the different months. I guess the reason to be a little nervous about that would be if I'm trying systematically to go through the posts, either picking a year and then going through by month, or picking a month and then going through by year. Right, if you lose the ability to pick a month and then pick a year, and you lose that with the accordion also.

Yeah, true.

The question is, how important is that approach?

Maybe not very. Yeah, that's true.

Interesting. Yeah, but pick the month that's correctly beneath you. Of course, right now you're attempting to open a gap so that you could go straight down, I guess. Well, that was the idea, was to make it safe, to avoid the clobber problem by changing the palette a little bit, the selection palette a little bit. And I am in fact arbitrarily picking December for you every time you move to a new year, so I'm violating my own notion there. probably shouldn't be doing that. If you pick August of '13 and then you go to '14, it should probably remain August. I've got a lot to think about now, and I appreciate that. I'll let that simmer and see what I can come up with. Were there any other... Oh, Bob, I did ask you, and you responded positively, but I wasn't sure whether anything... whether there was any chance that anything might happen with it. If it's not obvious to everybody concerned, I am not a visual person, and I wondered about the prospect of getting some sort of graphic design help.

I can talk to Stephen about it and have him run through and take a, give a survey of it and see what he thinks. He's got a good eye, he does a lot of design for what he does, So I think he, at least as a first pass, if we wanted to go further than that, we might have to try and pull somebody in who is a professional willing to put, you know, a fair amount of time in on it. Having said that, I was going to say, having said that, I help pay for his education, so I think he kind of, you know, owes me.

Yeah, absolutely. I need maybe six dollars, you know. I've got maybe six things happening on the screen. I've got fonts, I've got the selection rectangles, the scroll stripes, the histograms, the bar cards. I just can't juggle that many colours, and maybe somebody with a better eye could. Yeah, no, I think that's something... Yeah, first pass could be great.

I guess the question I've got is, is that where you are right now? Do you think that that design is getting in the way of your functionality, or do you think something you do when your functionality is more... It's strictly a matter of... Oh, I'm sorry.

I, at this point, feel like... and maybe I'm misguided... we're pretty close. I don't see the design making major changes. It's entirely possible that we'll come up with a different approach to the time navigator performance. I think we're pretty close on everything else. If Steven could just spend... I'm not looking for a redesign. What I'm looking for is colors for the elements that I'm pretty sure we're going to have, and that I feel are pretty solid. And probably a a way to use the style and the color to draw you through the right process, so that if there's a way to link things by color, that would make more sense than those kind of things. Yeah, although even that might be a little too ambitious. I would be happy just with something that didn't assault the eye, which is where I think we are now. Just better colors. And if he feels more ambitious, if he's got suggestions on layout and interaction, I would love to hear them for sure, but I'm not looking to take up a lot of this time. Just something so that when you see a screenshot of the thing, your first reaction isn't "what the hell is that? What's going on there?" which is the reaction that I have to it at this point. One thing that I did draw from his initial look at it was currently the way it's set up, we're not focusing on search enough.

Well, we do have a whole field dedicated to it. We do, but that's something where I think if we were to look at design, we might highlight that area. It might be a slightly bigger field, it might be a more prominent colour, that kind of stuff, just because I think that that's how most people use it.

All right, yeah, as I say, any suggestions whatsoever would be extremely welcome. But where I'm... the point of departure for me is better colors. But any additional thoughts that you might have, I would be very grateful for.

And I'm guessing the frames per second is just diagnostic really more than anything else, right? It's going to disappear.

Yeah, I don't think we would need to keep it. I have it there to keep me honest. so as things... I see that numbers start to drop, I become concerned. But yeah, the frames per second would probably go in the final version. The other thing I'm thinking about... so the way this works is there's a database, it happens to be SQLite in the background, and it's got the table of contents and all of the all the rest of the structure. It's got all the forums in it and so on. And then as you do searches, it's augmented. So that database which you downloaded from Jsoftware.com at some point, presumably, which I send you occasionally, Bob, It's being augmented on disk. And when you visit pages, your history is automatically being augmented. That's kept in the database, so everything is kept in the database. And then the problem is, if you download a new version of the database, it's going to clobber your searches, your recently visited pages, and I'm also going to do bookmarks, I think, at some point. It will clobber those as well. those as well. So I'm trying to figure out how to migrate. And I had thought that I would start to use this somehow start to juggle an additional file or an additional database and full of search results and recently visited pages and bookmarks and merge them on the fly and so you help me in memory, you have your memory database that was emerging the two. I don't know, maybe that's the right answer, I'm not sure. What is the etiquette on juggling files in the temp directory? I'm assuming that this database that I've described would live on the person's temp directory. If you're going to start creating files on their file system on the fly. Do you ask for permission for that? Is that not something one does? What are my options here?

I did something similar to this in the very first iteration I did of my video lab, since I thought it'll be useful if people could make notes as they're watching these things, and those notes would be permanent on their computer. As it worked out, I was, you know, overthinking the whole thing and I was doing too much much work and nobody was going to use them. But I figured if I asked permission at the initial making of notes that I was going to write to their file and it was going to be them writing their stuff to their file. That's the one difference to what you're going to be doing, although if it's bookmarks, they're going to want to put those bookmarks in. I'm trying to think of anything else. It's essentially giving them permission to create a cookie file except that we're doing it in J, and that's the information you're going to use in the future, right? Okay, let me think about that. This morning it occurred to me that I might be able to do it without a separate file. Where you... there'll be a button somewhere to download the latest cache image, and I think what you might do is within the application grab all of the ancillary data out of the database, put it in memory, download the new cache, and then write all that data to the new cache database that was just downloaded. So if you were swinging through vines you're letting go of one vine before you've actually grasp the next one because if the application crashes at a awkward moment you're going to lose all that information. But what it would let them do is avoid creating separate files on their hard disk entirely. There would only ever be one database file.

I see three issues that to think about there. One is is disk whole issues which we generally don't have a lot of insight on because we don't have actually that part of the OS from Jay very well. One is namespace issues you know something wants to go and clean stuff up manually knowing what's cleanable and what was the third one? I guess there was a recovery issue that you just mentioned, if things go bad, being in a quick to start state when you come back. And at some point, because of our limited abilities to anticipate what the user intends and what their machine is like, we're going to mess up in some cases. You want to minimize those.

Could you say more about the namespace? What's that? I'm sorry, I thought you were... Oh, yeah, no. Can you say a little more about that?

Oh, the namespace issue is if you have more than one file that you're working with, how do you show to the user that any other files are connected with it, or how does the user decide that that file is going to stay or go. It's that kind of issue. If they're coming at this from outside of the application, looking at it from the operating system, how do they make sense of what they're seeing? Right, good point. And then you might use it to keep it to one file. You can keep it to one file. You can also create a subdirectory and do all your stuff in there. You can use a common prefix, which is kind of similar to a subdirectory. There's a lot of it's I was just about to be having good names for things. Yeah, okay.

- What about if, you know, using the subdirectory, you create one folder, but in the folder there are two files. One's the db file that everybody would get that's from the J site. The other file is the personal stuff for that person. And when you go to update, you're only gonna update the database from the J site. The other one wouldn't be touched, and it sits in one folder that might be labeled JWiki browser or whatever. So that they'll know that's where it is. It's not going to be moving all over the place. It's one folder, but it's allowed to be two files. One's for personal stuff, and the other is for the stuff that will be updated as the wiki changes.

Right.

Yeah, that's where I started, or where I found myself at some point. really like the single file solution for debugging purposes. So if they do run into a problem, if the application exhibits inappropriate behavior of some sort, I can just say send me the database file. And it's got everything. In addition to, it's got the original data that they downloaded, it's got all their searches, all their recent stuff, all their bookmarks, and And it's got a log that I write, an activity log and a crash log table, to which I write constantly as the application is running. Yes, Bob, your activity is being monitored. And if you run into something really peculiar, the first thing I would do is ask you to send me the database file. And I really like that model. I like the simplicity and robustness of it, of it and would prefer to stay away from directories and from juggling multiple files if I can avoid it.

But wouldn't you prefer just to ask not for the database file because that's not changing. Ask for the file that's changing, which would be the personal file. That's where the log would be.

No, two points on that. First the database file could be any one of a large number of versions of that database file. one. They've got, and secondly it's precisely the interaction between the personal and the server cache database file that might be of interest. It would be really nice if they were all, you know, if I merge them in memory, then I lose that if the application crashes. I don't know what was going on, but if it's all sitting on a single file on disk, I can get a copy of that. You have to compromise If you're going to update it with a complete replacement, you have to compromise on the old version versus the new version. You either have two of them at the same time or you have neither of them at the same time. The Windows way of doing things favors the zero of them at the same time, and the Unix way of doing things favors the two of them at the same time. The other way of doing it though is instead of replacing the whole file, if you want to maintain a database, representing the file as basically a database, what you'd be doing is you never delete the file, you update parts of it. So you sequester a chunk of the file in the update, yeah. Yeah, and that gets you into many management issues and allocations and regions and stuff like that, but that's where you wind it. How about this, Ro? Suppose what I did was, when you press the update cache button, I extract all of the personal information, as Bob calls it, which I think is accurate. Pull it into memory and write it to a J file. Was it 3 bang colon 1, I think. And then I download the new cache and I clobber the old one. And then I write that personal information into the new cache database. Then most of the time you have one file and it's only if it happens during that transition that you have two files. That's probably right about where you want to be, I think. And then after you'd finished that write process, you would erase that file again so it's not there. You're back to the database. Yeah, that's what I'm thinking.

Yeah.

So, Bob, I have taken up more time with this than I intended to and we're coming towards the end. What else? We can defer anything else on this to the next meeting. What else would you like to cover? And I apologize for needing you so little time. Go ahead. Actually, I think the time spent on this is much in advance of anything. The only thing I was going to talk about is whether we wanted to approach how we were going to look at templates for pages, if we're going to guide people to make a certain type of a page, but I don't think that's key right now. I think this is much more important. One question I've got, is that N-U-M-B button, what does that do, the number? Well, I sent you a note on that, and I guess I probably wasn't as clear about it as I should have been. If you haven't played with it, you should. We talked about whether the white stripe versus the gray stripe, whether the white stripe should be separate, should act differently. So I talk about coarse-grain navigation versus fine-grain navigation. If you turn the note on, it's all...

It's not working now. That's interesting. Well, when I first sent it to you (apparently I broke something), it turns off the white stripe. Oh, okay. So all navigation becomes coarse-grain navigation. I'll fix that in the next version I send you. But you had mentioned that particularly when you're down at the bottom, you want to get to something on the top. top, it's very easy, as I just did, to clobber it as you go. And that's absolutely true, and that's typical of hierarchical menu style interfaces. Would it make sense to change the label from num to course? Oh, this was just for Bob. Yeah. [LAUGHTER] And this is often the case that went right by me. Yes. In all put stuff, take an experiment. The bigger your screen, and I have the impression from other things you've said that you have a fairly large screen, I'm just operating on a laptop. The bigger your screen, the more coarse-grained navigation feels okay, I think, because you're not magnifying. I bet you that's true.

It's good seeing you. I will see you again.

Thank you, Devon. That was fun.

Oh no, num is working. Oh, that's interesting. Oh, no, that's right. It's just not supposed to do anything. Yeah. So you get your course grade navigation. And then when you're num, when num is on, nothing happens. But if you turn num off, it starts selecting again.

Yeah.

Yeah, so experiment with that. See how you feel. But again, I think your screen is probably big enough that course grade navigation is fine for you. fine for you. Yeah, I'm on a 24 inch screen and I think that would make a big difference for sure. I should get on my laptop and try it or my... Oh, we haven't tried it on iPads and stuff. I'm not sure how to approach that. But anyway, yeah, I can do it on my laptop too.

Yeah, give it a shot and see whether you still feel that you only need court-keeping navigation.

Yeah, no, I will.