Its all about transitions! Lets talk about Slicer's landing page

(Beatriz Paniagua) #1

Hi all,

I would like to bring up again the topic of transitioning the Slicer.org landing page to a place that facilitates collaboration.

As you know, @rkikinis appointed me to start looking into showcasing the different slicer-communities in the Slicer landing page. We created a mockup in January during project week that planned to show different slicer user communities directly in the landing page.

@jcfr and I have discussed before about moving slicer.org to github pages within the Slicer github group. I know this has been a topic of discussion for a while.

Are there any supporters for conserving the current structure, or to move towards github pages? Are there any general ideas on how to move forward with this?

Thank you!
Bea

4 Likes
(Bill Lorensen) #2

What is wrong with the current technology.

(Jean Christophe Fillion Robin) #3

Hi Bill,

Thanks for commenting on the new Slicer Discourse forum :slight_smile:

Overview

The current website already successfully presents Slicer and its outstanding community. It served us well and is still serving us and our users.

That said, considering what is possible today, the current infrastructure doesn’t allow to easily experiment and improve the website. I think it is important to enable everyone to do so. In the long run, it will make the Slicer platform and associated projects more useful.

Current infrastructure

It consists of html pages (and few wiki2web pages) stored on a server that have to be updated by a single person (without relying on version control).

While the individual(s) helping in the process are awesome and responsive, the process is quite daunting and involves often a lot of emails.

Next

@bpaniagua will help us move forward and improve the user experience related to the main Slicer website.

(Bill Lorensen) #4

I see. I thought the discussion was about the wiki. I agree that html is
old technology.

(Jean Christophe Fillion Robin) #5

It is not that HTML in itself is old technology, I think there are more modern ways for collaboratively managing the associated code and assets.

Otherwise, you will find below the list of pages I compiled back in 2015 when we moved pages from wiki2web technology to the wiki.

It illustrates that all the pages except the top level one are now hosted on the the wiki (with redirect in place when needed)

To get started, I just:

The website have been published bu GitHub is now served from http://slicer.github.io/slicer.org/

If we all agree to move forward with this experiment and adopt GitHub to host and serve our website, I wonder if Mike and/or Greg could setup the redirection ? (cc: @pieper ?)

About Slicer

Publications

Documentation

Help

Links

(Jean Christophe Fillion Robin) #6

The only downside (if an issue at all) is that we can not redirect https://slicer.org to https://github.com/Slicer/slicer.org

HTTPS is not supported for GitHub Pages using custom domains.

Source: https://help.github.com/articles/securing-your-github-pages-site-with-https/

That said, there are ways to enable this:

But these come with trade-off too.

(Michael Halle) #7

Actually, this is going to be tricky, possibly too tricky to have github.io hosting be viable.

slicer.org (which forwards to www.slicer.org as per best practices) is now hosted on Digital Ocean. www.slicer.org/wiki points to the wiki, also hosted on digital ocean. There are a bunch of rules on the slicer.org web server that keep old links working while allowing current, consistent, cleaned up wiki URIs. Backward compatibility was one of our goals in the re-architecture of the wiki.

If we moved slicer.org to github, we don’t have a place to put those Apache configurations, since slicer.org is top-level. Right now I don’t see how it can be done.

An alternative would be to author the site on github, and pull it over to the main site where our existing slicer.org HTTP server would serve it. That would also take care of the SSL configuration, which is working and continuously maintained using letsencrypt.

Let me know your thoughts.
–Mike

(Andrey Fedorov) #8

Yet another alternative is to declare everything-wiki “legacy”, and move on with hosting documentation using ReadTheDocs or GitBook, as some of the folks discussed earlier.

Do we have any idea of who is using Slicer wiki, how it is used (editors/readers ratio), what pages are being accessed, etc? My guess is that it could be the case that most of the wiki content is not used either because it is obsolete, not searchable, or for various other reasons.

Just wanted to float this idea around.

(Steve Pieper) #9

@fedorov in fact, we do now have some good data on that via google analytics, at least on page views and it’s in the thousands per day (see below). I would not want to move to either gitbooks or readthedocs because either one would be a disruptive change that doesn’t offer enough advantages at the moment.

I like the idea of hosting the repository for slicer.org static pages on github and then using the existing digital ocean infrastructure that already handles the wiki to host that content under https.

@mhalle it sounds like we could set up something like:

github.com/SlicerExample/example.slicer.org => https://example.slicer.org

where “=>” means a githook publishes every commit over to the digital ocean host and “example” can be any community that wants to participate, is that right?

(Andrey Fedorov) #10

@pieper it is great that we have analytics set up! It should be very helpful to prioritize migration, if there is ever agreement to do it.

I disagree though about “a disruptive change that doesn’t offer enough advantages”. I think it is an opportunity to bring some order to the various resources that piled up over the last decade, and improve the appeal of these resources. By making documentation more accessible for both users and developers, we have a chance to attract more people and grow the community, and there are few things that are more valuable than that. I think there is also relatively low risk if wiki is maintained in read-only legacy mode, as the content is migrated/populated.

But I also think that, as we have experienced already, reaching consensus on what will be the new platform is challenging.

(Jean Christophe Fillion Robin) #11

@mhalle Thanks for the investigating. It all makes sense.

Agreed.

Look like this tools should be helpful: https://github.com/adnanh/webhook

It should allow to easily create endpoint and execute command based on the payload.

For example, here is a hook definition for GitHub payload.

In other word, it is a generalization of the flask app I put together to trigger generation of apidocs.

We should make sure the end points we setup:

(Jean Christophe Fillion Robin) #12

During the weekly developer hangout, @bpaniagua and I talk about this, and we suggest to setup a cron job on the server that is currently serving “slicer.org” ?

A cron job like this one (running every minutes) should do the work:

SITE_DIR=/path/to/slicer.org
if [[ ! -d $SITE_DIR ]]; then
  git clone https://github.com/Slicer/slicer.org $SITE_DIR
fi
cd $SITE_DIR
git fetch origin
git reset --hard origin/gh-pages
2017.05.16 Hangout
(Steve Pieper) #13

I just talked with @mhalle about this and it sounds like the digital ocean instance is now set up and would be ready to start autopulling from github.com/Slicer/Slicer.org. As I understand it @freephile has a git repository of what is currently hosted on https://slicer.org which I think is similar (identical?) to what is currently on github.

So I think we are ready for the plan to make the github.com/Slicer/Slicer.org repository become the official one and use github issues and pull requests to maintain it.

2 Likes
(Greg Rundlett) #14

I haven’t compared them bit by bit, but the index.html content does look similar between https://slicer.github.io/slicer.org/ and https://slicer.org/index.html

There is a bunch more file content in the live slicer.org site. Some of which just needs to be purged (e.g. DownloadSlicer.php). Some may be desired, but ignored in the repo (e.g. doc), in which case we’ll just use the .gitignore file to avoid collision. And some would be candidates for addition to the repo (e.g. robots.txt).

Also, @mhalle I noticed that https://download.slicer.org/ is different from http://download.slicer.org/

git ls-files|grep -v doc/
.gitignore
DownloadSlicer.php
css/basic.css
css/basic.css~
css/ie.css
css/ie5mac.css
css/styles.css
css/styles.css.bak
css/styles.css~
favicon.ico
img/3DSlicer-DesktopIcon.png
img/3DSlicer4Logo-H-218X144.png
img/3DSlicerLogo-H-Color-218x144.png
img/Logo-Slicer.png
img/Logo-Slicertext.png
img/Search.png
img/Slicer4Announcement-HiRes.png
img/animated_favicon1.gif
img/bullet_more2.gif
img/bullet_style1.gif
img/bullet_style1.png
img/bullet_style4.jpg
img/bullet_style5.jpg
img/bullet_style6.jpg
img/dl-l.png
img/doc-l.png
img/favicon.ico
img/fb-l.png
img/focal/js/config.php
img/focal/js/download.php
img/icons612.png
img/logo2_slicer.png
img/logo_slicer.png
img/misc/Bugtracking-hover-old.png
img/misc/Bugtracking-hover.png
img/misc/Bugtracking-l.png
img/misc/Bugtracking-old.png
img/misc/Bugtracking.png
img/misc/Documentations-hover-old.png
img/misc/Documentations-hover.png
img/misc/Documentations-l.png
img/misc/Documentations-old.png
img/misc/Documentations.png
img/misc/Download-hover-old.png
img/misc/Download-hover.png
img/misc/Download-l.png
img/misc/Download-old.png
img/misc/Download.png
img/misc/DownloadNav-hover.png
img/misc/DownloadNav-hover.png.bak
img/misc/DownloadNav.png
img/misc/DownloadNav.png.bak
img/misc/Slicer3.6Release.png
img/misc/Slicer4Announcement-612x362.jpg
img/misc/SlicerExtensions-612.png
img/misc/Tutorial-hover-old.png
img/misc/Tutorial-hover.png
img/misc/Tutorial-l.png
img/misc/Tutorial-old.png
img/misc/Tutorial.png
img/misc/bugtracker.png
img/misc/bugtracker1.png
img/misc/documentation.png
img/misc/documentation1.png
img/misc/download.png
img/misc/download1.png
img/misc/slicer4Announcement612px-i-mj.png
img/misc/tutorial1.png
img/misc/tutorials.png
img/re/chunk1.png
img/re/chunk10.png
img/re/chunk11.png
img/re/chunk12.png
img/re/chunk2.png
img/re/chunk3-blank.png
img/re/chunk3-orange.png
img/re/chunk3.png
img/re/chunk4-blank.png
img/re/chunk4-orange.png
img/re/chunk4.png
img/re/chunk5-blank.png
img/re/chunk5-orange.png
img/re/chunk5.png
img/re/chunk6-blank.png
img/re/chunk6-orange.png
img/re/chunk6.png
img/re/chunk7.png
img/re/chunk7r.png
img/re/chunk8-blank.png
img/re/chunk8-orange.png
img/re/chunk8.png
img/re/chunk8r-orange.png
img/re/chunk8r.png
img/re/chunk8r2.png
img/re/chunk9.png
img/re4.1/Bugtracking-hover.png
img/re4.1/Bugtracking.png
img/re4.1/Documentations-hover.png
img/re4.1/Documentations.png
img/re4.1/Download-hover.png
img/re4.1/Download.png
img/re4.1/Tutorial-hover.png
img/re4.1/Tutorial.png
index.html
robots.txt

(Steve Pieper) #15

Thanks Greg. I’m not sure what all is in the existing slicer.org folder,
but based on the toplevel page it looks like most links to go the wiki or
to the download site, so perhaps we just start fresh with just index.html
and its assets. On the other hand it doesn’t look huge, so we could commit
it all and then clean up.

Either way I understand that github.com/Slicer/Slicer.org is a placeholder
that can be overwritten by the content of the currently non-public
slicer.org git.

(Greg Rundlett) #16

@jcfr I made a pull request to update index.html Do you want to make me an editor on the repo, so I can push, or if you want I can continue to issue pull requests.

With that merged, I can pull the github repo and setup cron on https://slicer.org

I’ll simply archive the existing content listed above (it’s all legacy by the looks of it), and add in the .gitignore, favicon and robots.txt files to the github repo.

(Jean Christophe Fillion Robin) #17

Thanks Greg. PR merged :slight_smile:

1 Like
(Jean Christophe Fillion Robin) #18

@freephile I also just sent you an invite to join https://github.com/orgs/Slicer/teams/slicer-website-maintainers

@mhalle Similarly you also have a pending invitation …

1 Like
(Greg Rundlett) #19

OK, this is done. The website is pulling every 5 minutes from the repo. Any merged changes into the repo will go live automatically.

The repo has been updated with a README etc. And unused content has been moved aside on the server for eventual deletion.

1 Like
(Jean Christophe Fillion Robin) #20

Very nice :thumbsup:

Now that we have the sync setup, what do you think of:

  • we rename gh-page branch to slicer-org
  • create a branch preview-slicer-org that would allow to try changes on “preview.slicer.org” (or we could have the preview rendered by Github configured at as github page)