I like the spirit!
> I would recommend a reasonably modern single-page app for
> <docs.schemers.org <http://docs.schemers.org>> since that
> address would be the obvious starting
> point for newbies and many programmers expect something quite
> modern
> nowadays. It gives a good first impression if we have something
> modern
> there, in any case. Another reason is that the API will have a wide
> variety of information. It will be hard to present all of it in an
> interactive form unless we use a single-page app (there's just
> so much
> of it).
>
> It would be nice to specify exactly what the app will do, though.
> Will it be primarily a search UI with a text box and a few
> controls? (That's what I implemented for SRFIs at srfi.schemers.org
> <https://srfi.schemers.org>.) Or will it be something more elaborate?
>
> Exactly.
That's a fair question. I think it would be best if I did a mock-up or
prototype to illustrate it.
Yes, we could start by just sketching the sitemap or navigation elements.
What kind of website is it?
A "landing-page" the equivalent of click-bait titles, somewhat like
this regard and I will prolly add a link to scheme doc when it is
ready.
A vitrine or brochure kind of app. Where Scheme language
and its particularities are more detailed with several call-to-actions
sits nicely between the landing page and the brochure which opens
up to a few internal links including a wiki and some documentation.
The other example I have in mind are websites like racket, python or php.
By the way racket website is, for some reasons, undergoing a rework
Among interesting features from those sites I like:
- The fact the documentation of the language can be found in both
html and pdf that can be downloaded or consulted online.
- Documentation is available for several versions of the language
- Also the websites / documentations are supported by a (home made)
search index.
- PHP last time I checked supported comments with code snippets in
the documentation.
- Also, recently Python started translating and hosting documentation
translations.
- At least Python has a wiki, but it is mostly dead.
- They also have planets aka. blog aggregator. In this regard,
kernel.orgI like the idea of activitypub (I would prefer real peer-to-peer ;)
The other things I think of are community websites or forums like:
- news.ycombinators, lobster or lambda the ultimate
but proprietary)
I also much like discourse forum, written in Ruby, user experience. It game-ify the
forum ux a little, but not too much and also offers a "mailing list bridge".
Some local communities run their own software that takes inspiration
Many also provide paste/pastebin service even it might have some legal concerns...
Talking of legal concerns I really like the idea of getting another bibliography together.
That is a strength of Scheme community compared to other popular languages.
It's hard to convey with words alone... I'd
like to have a mash-up of <docs.racket-lang.org>,
<pkgs.racket-lang.org>, <quickdocs.org>, <quicklisp.org>. But that
doesn't really communicate, because with Scheme we have to present
multiple implementations.
Yes that is difficult task. My idea boils down to building a killer app that
would allow to crowd source all the energy around scheme (possibly
by remaining a distributed effort and without me making my own scheme!)
I keep reading that what killed lisp is the lack of killer app(s)... nevermind.
It would also be nice to present cookbook and tutorial material (e.g.
if someone looks at an API reference for a
procedure, there could be
a link "hey, did you know there's a tutorial
on this topic?"). So basically
all package info and documentation the
API knows about, with all aspects
deeply hyperlinked.
That again is subject to legal concerns IIRC. Whether it is R5RS, R6RS, R7RS
or implementation specific documentation.
This could be the most ambitious site for any language to date, but I
think we should still aim for it :) If we miss the goal, we'll still
have an excellent site.
I like ambitious projects. Thought there is a great change also that we
get lost with fatigue and burn out... just saying.
If we aim lower, we'll have less enthusiasm and will produce a site
that is not even on par with the average language
site of today.
Some people say: step by step!
I know I am contradiction myself in the same email, sometime in the
same paragraph :)
What are your preferred ways of working on this? I can produce the
mock-ups but it will take some time (at least a week or two) to get
anything done.
I guess we keep sharing what we have, it will be good.
If you are enthusiastic to start already, we can think of
another approach. And if you think the above plan is too ambitious or
dumb, that's fine too and we can do it another way :)
It seems the current process is good.
The nice thing is that with all the data in the API, experimenting on the UI is a lot cheaper.
I am still not up-to-date to what the API contains :-/
> I created a repository with XHR GET support, if someone wants to play
> with it:
>
> https://github.com/scheme-live/ff.scm/commit/2cdb99105bf905d1eede18a3422aa8efd6959c62
>
> After git clone, I run: python3 -m http.server and then what is
> interesting happens in the
> web developer console but you need to input something in the input text
> box to trigger the
> XHR GET foo.js.
>
> I had some bad luck so you might want to run it in private browsing mode.
>
> The interesting code is main.js and main.scm.
>
> Another thing that is not described in the commit message is the use of
> custom reactjs
> components, right now I only tried basic stuff like div, input etc... I
> never tried third party
> widgets.
>
> You might need to run npm install. not sure about that. I think I
> commited the "helpers"...
Amazing. You work really fast!
That was just a few lines!! 20% of the effort 80% of the features,
the excellence is in the last 20% features which are if my math
are correct 80% of the effort :)
I regret that there's so much good stuff that I don't have time to look
at this in proper detail. I'll try to make time later this week.
Currently stuck with getting the GraphQL/API started and trying to get
to the OS/archive stuff as fast as possible.
Good luck!
I attached a mockup of a thing I made using the "framework" I call ff.scm
the successor of forward.scm. I will continue to work on ff.scm to bridge
the gap with its javascript counter-part.