The "Software" page should link to GitHub more prominently.

[hjellinek]

This came up in our U Alberta meeting this morning:

People who visit https://interlisp.org/software/ should see a more prominent link to our
GitHub without having to first visit the "Install and Run" page.

[hjellinek]

See PR #269.

[pamoroso]

The header of every page of the site also has a GitHub icon next to the search box but it may be more subtle.

[nbriggs]

Unfortunately, you don't see the header on the page if you don't have your browser window wide enough - I think that's probably another bug report though. This browser window below is 1150 px wide on a 1366 px wide laptop screen. There's plenty of space for the header items to slide left on a narrow page, but they don't.

[nbriggs]

And on the Software page in particular, because it has an additional item in the header that pushes everything to the right, you can't see the "Github" and "Search" options (or many other things) unless your browser window is at least about 1740 px wide, which is not practical on a 1366 px wide laptop display.

[stumbo]

Also, the footer of every page has a link to the GitHub site - and this one behaves better and doesn't get clipped on narrower renderings of the page.

[stumbo]

This came up in our U Alberta meeting this morning:

People who visit https://interlisp.org/software/ should see a more prominent link to our GitHub without having to first visit the "Install and Run" page.

I'm not against putting a more prominent link on the page. But, what should go around it? Why would someone that has Interlisp running in the browser visit the GitHub site? What is the exact issue we're trying to solve? Right now just plopping in a link seems incongruous, it needs more context..

[masinter]

I agree with Bill for the reason that the link to the GitHub pages should point to the Maiko README documentation on how to build Maiko yourself primarily in the cases where you're trying to run on a system that we don't build installers for. And the systems we regularly build installers for changes from time to time.

Building Medley doing your own loadups is going even farther, and only really interesting if you want to modify meddley directly.

[hjellinek]

I agree with Bill for the reason that the link to the GitHub pages should point to the Maiko README documentation on how to build Maiko yourself primarily in the cases where you're trying to run on a system that we don't build installers for. And the systems we regularly build installers for changes from time to time.

Building Medley doing your own loadups is going even farther, and only really interesting if you want to modify medley directly.

I can't presume to know which aspect of building Medley interests someone who lands on the Software page, but since they're on the "Medley" software page, I linked to the organization's GitHub page, https://github.com/interlisp/. That page does include prominent links to the Maiko and MEdley repos. But it's all the same to me. If you'll approve this PR with that link, I'll make the change.

It's true that the header does link to GitHub, but Nick pointed out a major problem with this. The footer links to GitHub as well, but it's invisible on the Software page unless you scroll vertically, and perhaps horizontally as well. (I was using a 1660-pixel high browser window.)

Whether in the header or footer, someone arriving at thee Software page expects to read about where to find our code. We witnessed this in real time during our last student meeting, as I said.

The important thing is to get the link on the Software page; we can play with the phrasing later.

p.s. I recommend removing the GitHub link from the page header and moving the one in the footer to the left side with the other link icons.

[pamoroso]

When researching an open-source software package I routinely check the GitHub repo even if I don't plan to contribute. The repo gives me clues on the system requirements, how to build from source if no prebuilt binaries are available for my setup, issues I may bump into, the status of the project, whether I can report bugs, additional documentation, and more.

[hjellinek]

Merged PR.