Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New Jupyter.org Website Design #49

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

New Jupyter.org Website Design #49

wants to merge 6 commits into from

Conversation

tgeorgeux
Copy link

@tgeorgeux tgeorgeux commented May 15, 2020 •
edited by Carreau
Loading

--

EDIT From Matthias, The diff has a text file, here is the content:

Jupyter Website Re-Design Implementation Process.

Item Value
JEP Number 10
Title Jupyter Website Re-Design Implementation Process.
Authors Tim George @tgeorgeux
Status Draft
Created 15 May, 2020
History 15 May, 2020

Problem

Technical: The existing Jupyter Website is a mix of Jekyll templates and bespoke hand-crafted Javascript. Over time the templates have experienced bit-rot and the website is difficult to update significantly without breaking it.

Design: The design of the existing Jupyter Website is dated, and doesn't reflect the complexity of the existing organization, nor does it help outsiders onboard to Jupyter's software or community sufficiently.

Proposed Enhancement

Over the summer of 2019 a team from UCI performed research then designed a new website including an MVP set of pages, templates for future pages, and a style guide for components.

I propose we use this design work as a template for a new Jupyter.org website using a stable static website generator, with a few hard-hitting interactive elements to help users discover Jupyter Projects that would be useful to them. I propose we use Gatsby.js to generate pages via a markdown converter, this will allow us to seemlessly integrate with the moreinteractive elements.

Detailed Explanation

Design details

The design of this new website is finished and be viewed here.

Here's some screenshots of the design:



Development details

Development is the next step. We need a static site generator. (@marwahaha made an initial prototype) There is (at least) one custom component in the current design that requires some custom Javascript. Preferably, we could write such components using a well-known framework like ReactJS.

I propose we use GatsbyJS to achieve this.

  • Gatsby is a simple framework based on ReactJS. We can leverage existing GatsBy templates for the basic structure of the website.
  • Website content will be written in Markdown and parsed using Gatsby's gatsby-transformer-remark native plugin.
    • Jupyter projects maintain a markdown page.
    • Content is submitted via pull requests.
    • We'll provide a specific editorial guideline and rubric for content submission and review.
  • Since Gatsby is based on ReactJS, we can easily create custom React components—like the pivot table for Jupyter projects in our current design.

Implementation

There is decent amount of developer time needed up front. This will pay-off in the long run as the maintenance cost is low after initial development.

Approach to rallying developer time+efforts:

  • We will need an individual or committee to commit to pushing forward on this.
  • We will need expertise in the following areas: Design, Technical, and Content
  • I (Tim George) am happy to serve as a single 'champion' of this project or on a comittee with a technical and content expert.

Pros

  • Website Design
    • Explains the 'what Jupyter is' narative.
    • Serves to offer the community different types of engagement
      • History, events, software, community, Governance, notable contributors.
    • It really is a killer design.
      • And cool illustrations.
  • Low maintenance cost in the long run.
    • Up to date with modern web development standards.
    • Design is made to scale up.
    • Gives rubric for incoming PRs.

Cons

  • High development demand up front
    • There's a bit of a chicken-egg problem here, it's hard to get commitment on a large enough scale to complete this work without explicit agreement this is the direction to go.

@tgeorgeux
Copy link
Author

I don't think the screenshots are rendering in the Diff, so here's the screenshots mentioned.
Home
Documentation
Technologies
JupyterHub

@Zsailer Zsailer changed the title New Jupyter.org Website New Jupyter.org Website Design May 15, 2020
@Carreau
Copy link
Member

Carreau commented May 16, 2020

Thanks @tgeorgeux, what kind of feedback are you looking for ? Is that a mockup that need to be coded, or is that screenshot of an existing prototype ?

Thanks !

@Carreau
Copy link
Member

Carreau commented May 16, 2020

Misc comments, Personal thoughts not requests for changes (sorry I just saw that the diff have a text file in int) :

  • Not many places with current Jupyter logo.
  • Some layout will be tough to do in html/css, especially if we have text that "wrap" around non square images, I see the prototype manage to do it, but the cost is that there is responsiveness on mobile.
  • I don't like documentation categorized by alphabetical order, user will likely need to get a guide by topics ? I prefer the "tools and customisations" one.
  • "Jupyter workspace on shared resources" is unclear IMHO.
  • I'm not sure event should be the fist things on "community".
  • no opposition to gatsby, it should be relatively feasable with the desing I see to separate data from layout.
  • Yes I agree with you it's going to be a lot of work.
    Do you think that we can do by chunks and do only a subset ? I don't see any reason why we could not build some pages with jekyll and some pages with gatsby of whatever and progressivley replace them

@tgeorgeux
Copy link
Author

That's a mockup that needs to be coded. Some of the website has been prototyped here: https://guarded-sands-77993.herokuapp.com/ . That prototype isn't generated through any static generator, but it's a great proof of concept.

I want to push for development on this, I think it would be best if we could approve the design, and then moving forward the discussions would be around how to implement it most efficiently.

I think there may be institutional partners interested in helping out with this effort, but I think approaching them with a community and steering council approved design makes the proposal more interesting.

@choldgraf
Copy link
Contributor

choldgraf commented May 16, 2020 •
edited
Loading

Just a quick thought from me:

I think in the spirit of JEPs, the vote here is not on the small details of the implementation (and as @Carreau notes, this is just a mock-up, not an implementation). The vote is on the initiative and the broad contours of the idea, and anyway the design team did a nice job of soliciting feedback already. (@tgeorgeux let me know if you disagree with that and I am happy to rescind the point).

I don't have a vote but I would +1 the JEP if I did.

That said, I think that there are at least 5 things involved in the website refactor

  1. Content
  2. Structure (of the website)
  3. Structure (of individual pages)
  4. Design
  5. Implementation (with a particular SSG etc)

Many of these points can be accomplished now, and with the current skillsets that we have available. Many of these points in-fact have different groups of people best-suited to tackle them. The design team did a great job knocking out some prototypes for 4, and I think that many of 1-3 could be done fairly quickly on the infra that we already have. Number 5 will be the most complex (if the decision is to switch to a new SSG) but then again much progress can be made before we get to it.

So, my suggestion is that we try to:

  • break this problem down into component parts (maybe like the ones described above)
  • empower a group of people to have merge-authority over the current website without going back to the SC each time (maybe with some scope)
  • try to make a series of improvements to the current website, and then transition this into some new website structure like Gatsby as appropriate

@westurner
Copy link

westurner commented May 16, 2020 via email

@westurner
Copy link

westurner commented May 16, 2020 via email

@westurner
Copy link

westurner commented May 16, 2020 via email

@westurner
Copy link

westurner commented May 16, 2020 via email

@willingc
Copy link
Member

willingc commented May 16, 2020 •
edited
Loading

I'm a bit confused if we are approving the design as rendered (which is nice and clean) or the concept that we should refactor the website or something else entirely. If this is a JEP, shouldn't it have some prose to say "hey we want to do a website refactor" and what it will include (@choldgraf has mentioned).

I fully support the website refactor as a +1 as a JEP this would receive a -1 from me since it is missing clarity on what we are being asked to vote on.

PS Thanks for the work on this @tgeorgeux - nice design and @choldgraf on providing some helpful context.

@Carreau
Copy link
Member

Carreau commented May 16, 2020

I think the problem is the following:

This pull request have a text file with is hard to spot with all the images.

I'll update Tim's messgae at the beginning with the content of this text.

@Carreau
Copy link
Member

Carreau commented May 16, 2020

Thanks Chris and Carol for your comments.

I definitely agree that for me it's a +1 on having a general refactor and update of the website, though I want to understand what we are buying into.

I'm also worried if what you propose requires a JEP. And generally I would prefer to have a plan on how to progressively get from where we are now to where we want to be. I don't want to have this be a second version of getting JupyterLab 1.0 through the door with a big swap at the end.

I'm pretty sure we can avoid this "large upfront commitment" with a more progressive changes ALmost quasi static. Typically I would love a plan where each step is minimal and self contained where each step can be finished and deployed, for example:

  • migrate from jekyll to gatsby (no content or design changes)
  • Move content of Hub into it's own page.
  • Change the footer to be the new design.
    ...

It will also make it much easier to digest.

One thing which has also not been mentioned is compatibility with previous website. There are potentially a large number of link to current jupyter.org.

Will the URLs change ? Will some information already present be removed ? If so how will that be handled ?

If the project is "create the new website and on Jan 1st 2021 switch to the new design", then i'll 1) not trust you that this will happen 2) likely to be against it.

I'm happy to help with technical guidance and make sure we keep the complexity down. I'm not good at deciding whether the design or content is acceptable though.

THanks for working on this !

@ivanov ivanov added the SSC_propose_deferred A proposal to defer this proposal due to inactivity label Aug 23, 2023
@ivanov ivanov mentioned this pull request Aug 23, 2023
Open
@Zsailer Zsailer mentioned this pull request Jan 3, 2024
Merged
18 tasks
@gabalafou gabalafou mentioned this pull request May 16, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
SSC_propose_deferred A proposal to defer this proposal due to inactivity
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
6 participants
@tgeorgeux @Carreau @choldgraf @westurner @willingc @ivanov