[WIP] Notebook design idea

tclem commented 9 years ago

Hi all. Similar to the conversation going on in #6, I spent a small amount of time thinking about the design and layout of notebooks and thought I'd share a little bit of my work in progress.

I wanted to reduce some of the boxes, slim up the header space to bring the content up on the page, and make the Input and Output feel a bit more like an editor and be full-width/responsive.

Feedback welcome

jupyter notebook

minrk commented 9 years ago

Slimming the prompts is nice. There's one (IPython-specific) disadvantage of switching to I/O, and that's that IPython caches input and output in variables, so you can access them with in1 = In[1] and out2 = Out[2].

In general, I like this a lot.

damianavila commented 9 years ago

In general, I like this a lot.

I agree... it feels really nice...

Carreau commented 9 years ago

Awesome !

Like this a lot too, the gain of vertical space is nice. I'm wondering though where we would place, the login/logout/collaborator avatar once in a multi-user context.

I guess the In/Out are in any case not use a lot in notebook so we could rename to I/O. Imho though, the O in above draft look too much like a 0 (zero).

I guess the green border if for selected cells ?

What's the green √ for ?

tclem commented 9 years ago

There's one (IPython-specific) disadvantage of switching to I/O, and that's that IPython caches input and output in variables, so you can access them with in1 = In[1] and out2 = Out[2].

Cool, I wasn't aware of this. Is there an equivalent in the other kernel languages? Sounds like a feature that could be hinted at in a number of ways or maybe just via tooltip. I'm happy to spell out In and Out though

I'm wondering though where we would place, the login/logout/collaborator avatar once in a multi-user context.

I was thinking that your avatar would go upper right, but that maybe we could play with the collaborator avatars going more inline with where an individual's cursor was focused (hackpad style). Is this something you all are interested in seeing some design options for too?

I guess the green border if for selected cells ?

Yep.

What's the green √ for ?

I should further sketch out my ideas there, but that is intended to replace the kernel status dot. I figured the status is pretty closely tied to the actual kernel and wanted to make it a bit more accessible (don't just rely on colors for the various states for things like color blind individuals).

I was wondering if there is any usage data lying around that I could dig through? Is the tool bar actually used? I imagine post people spend the majority of their time focused in one of the input cells. Any other data or feedback you all have collected would be interesting to look through.

jhamrick commented 9 years ago

I like this a lot!

One thing regarding the green check being next to the save stuff -- I initially parsed that as the green check meaning the document was saved, and then read "unsaved changes" and was confused. I think for other applications I've used, checkmarks have been used to indicate that everything is up-to-date, which is why I have that association.

Maybe for the kernel indicator, it would be better to just have no indicator when it's idle? Then it's more obvious when it's running (maybe we could have a spinny icon or something for this) or dead (an x would probably work ok? Personally, I don't think it's particularly obvious that the current "bomb" icon means "dead").

jhamrick commented 9 years ago

Also, how will this look when cell toolbars are activated?

rgbkrk commented 9 years ago

This is definitely a wonderful design, particularly how the cells get laid out. Seems like we'd have a lot more room for code editing here.

I assumed the green check mark was saving as well.

tclem commented 9 years ago

I initially parsed that as the green check meaning the document was saved, and then read "unsaved changes" and was confused

Ah, yes. That makes sense and perhaps the you all are correct that the default should be to assume that the kernel is functioning so maybe we can drop it entirely and only display something when you've lost connection or when the kernel is busy? Are kernel status and saved status entirely separate from each other? Could you save a document when the kernel is down? A separator or some additional space between the kernel dropdown and the document saved state might help too. I'll play with some other options, thanks for the feedback there!

Also, how will this look when cell toolbars are activated?

I didn't get that far, but was hoping to move cell toolbars somewhere closer to the content if at all possible.

jhamrick commented 9 years ago

Are kernel status and saved status entirely separate from each other? Could you save a document when the kernel is down?

Yeah, they're separate. You can always save, provided you can connect to the notebook server, even if there is no kernel or the kernel is disconnected.

Carreau commented 9 years ago

Cool, I wasn't aware of this. Is there an equivalent in the other kernel languages? Sounds like a feature that could be hinted at in a number of ways or maybe just via tooltip. I'm happy to spell out In and Out though

I think that a detail and few people use that in notebook, it's mostly convenient in terminal case.

I was thinking that your avatar would go upper right, but that maybe we could play with the collaborator avatars going more inline with where an individual's cursor was focused (hackpad style). Is this something you all are interested in seeing some design options for too?

I would like to see that. I personally like the Medium style comment on the right too.

I should further sketch out my ideas there, but that is intended to replace the kernel status dot. I figured the status is pretty closely tied to the actual kernel and wanted to make it a bit more accessible (don't just rely on colors for the various states for things like color blind individuals).

Like @jhamrick I think I was confused with the saved state. I don't think we should prominently show that kernel is ok (if should be ok most of the time) the real distinction I think is between busy/not busy. the √/x has no common "third" state, but it's an area to explore.

I was wondering if there is any usage data lying around that I could dig through? Is the tool bar actually used? I imagine post people spend the majority of their time focused in one of the input cells. Any other data or feedback you all have collected would be interesting to look through.

Unfortunately we haven't done user testing. From talk/demo I saw people are using toolbar a lot. Some heavy user don' event use Shift-Enter, and click on run button for almost every cell. But we will do user testing.

Maybe for the kernel indicator, it would be better to just have no indicator when it's idle

I think that get annoying because the layout keep "jumping", we could leave it blank with same size though. I don't like bomb for dead either, and the "spinning wheel" was too distraction (for Brian IIRC) the other issues is that Chrome seem to have a bug where all infinite css transform like spinning wheel consume much more CPU than they should which 1) is too much CPU 2) drain battery. (see https://github.com/ipython/ipython/pull/7306#issuecomment-69222743)

jhamrick commented 9 years ago

I think that get annoying because the layout keep "jumping", we could leave it blank with same size though.

Oh, yeah, I was thinking something blank and the same size, just not visible.

I don't like bomb for dead either, and the "spinning wheel" was too distraction (for Brian IIRC) the other issues is that Chrome seem to have a bug where all infinite css transform like spinning wheel consume much more CPU than they should which 1) is too much CPU 2) drain battery.

Hmm, that's too bad. Well, maybe the current dot is fine for that, then -- if there is not indicator when the kernel is idle then at least it'll be more prominent... currently I think most people don't notice that there's a difference.

ellisonbg commented 9 years ago

Tim, thanks so much for working on this. Fernando and I have been completely occupied with writing our next big grant - starting to dig out of email now..

For the purpose of this discussion, here is a screenshot of our current UI:

screen shot 2015-02-15 at 11 30 09 am

Your design brings up some of the main design challenges we have. I thought it would be useful to summary those here...

vertical space

We are really trying to create a design that minimizes the extra vertical space taken up by the toolbar/menus/etc. Your design does a good job of this by moving to 2 rather than 3 horizontal areas at the top of the page for toolbar/menu/etc. I think that using the entire page width for these control areas makes lots of sense.

I think we do need the full toolbar to end up in a new design - as well as the notification area (the empty space to the R of the menus will show temporary notifications to the user).

usability testing

You brought up the question about usability testing. This is something that we are thinking a lot about for all the reasons you can imagine. We plan on starting to do this in a more formal way, but at this point are limited by our lack of time our existing staff has to put into this. Our new grant will have funding for this type of thing though.

In the meantime though, we have taught lots of new users in different contexts and watched how they use the notebook. This informal data suggests that new users do use the toolbar extensively - so much so that I think we need to provide more of that in the future. In particular, we probably need to have a per-cell UI that allows users to perform various common actions on cells without going all the way to the toolbar above. This per-cell UI would allow us to reduce the number of buttons in the global toolbar though.

Prototypicality and typography

Right now, we deliberately limit the main notebook area width to reduce the line length of narrative text. Even with this choice, we end up with line widths that are longer than is reasonable from a Typographical perspective (long lines of text are difficult to read):

screen shot 2015-02-15 at 11 47 04 am

Moving to a more full width design would make this problem worse. Thus, while I think we could make much better use of the full width of the page, I don't think the solution is to simply make everything wider.

The other part of this is the idea of prototypicality. We have recently made small changes that make the notebook area look more like a "prototypical" document (the grey background with subtle drop shadows around the notebook area):

screen shot 2015-02-15 at 11 45 37 am

The reason we made these changes is that users didn't understand that the notebook was a document that could be edited - to them it looked just like a web page. This was made worse by the almost completely similarity between the live notebook (which can be edited) and nbviewer (which can't). We wanted to communicate to users in a very clear way "this is a document, edit me!" I think we want to preserve these visual clues moving forwards.

How to use the full width

But I do think we need to think more about how we can use the full page width. One possibility is for presence and comments. Another thing we are thinking about is a full blown paneled layout using phosphor.js (https://github.com/phosphorjs).

tclem commented 9 years ago

Thanks for the really great feedback @ellisonbg!

Right now, we deliberately limit the main notebook area width to reduce the line length of narrative text. Even with this choice, we end up with line widths that are longer than is reasonable from a Typographical perspective (long lines of text are difficult to read):

What about something like what text editors do with a vertical gutter at some fixed length (80 chars)? Atom does this to a nice effect with soft wrapping at preferred line length for prose.

The reason we made these changes is that users didn't understand that the notebook was a document that could be edited - to them it looked just like a web page.

Interesting. I wonder if we should move the viewer experience further away from the editing experience to help this. There are definitely some basic UI cues we can give to hint at edit-ability. Things like a blinking cursor go a long way (you have to click or double click to get one now on a notebook I think).

But I do think we need to think more about how we can use the full page width. One possibility is for presence and comments.

Agree that the full width page will open up great possibilities with presence and comments. The vertical gutter might work well with this.

Another thing we are thinking about is a full blown paneled layout using phosphor.js

The challenge here will be deciding if you really want to go the full IDE route. Might be better to stay focused on the context.

ellisonbg commented 9 years ago

Tim, it looks like we are going to do a medium sized usability study in two university courses starting in April. This will better enable us to answer some of the usability questions you posed above. Cheers, Brian

On Thu, Feb 19, 2015 at 3:40 PM, Timothy Clem notifications@github.com wrote:

Thanks for the really great feedback @ellisonbg https://github.com/ellisonbg!

Right now, we deliberately limit the main notebook area width to reduce the line length of narrative text. Even with this choice, we end up with line widths that are longer than is reasonable from a Typographical perspective (long lines of text are difficult to read):

What about something like what text editors do with a vertical gutter at some fixed length (80 chars)? Atom does this to a nice effect with soft wrapping at preferred line length for prose.

The reason we made these changes is that users didn't understand that the notebook was a document that could be edited - to them it looked just like a web page.

Interesting. I wonder if we should move the viewer experience further away from the editing experience to help this. There are definitely some basic UI cues we can give to hint at edit-ability. Things like a blinking cursor go a long way (you have to click or double click to get one now on a notebook I think).

But I do think we need to think more about how we can use the full page width. One possibility is for presence and comments.

Agree that the full width page will open up great possibilities with presence and comments. The vertical gutter might work well with this.

Another thing we are thinking about is a full blown paneled layout using phosphor.js

The challenge here will be deciding if you really want to go the full IDE route. Might be better to stay focused on the context.

— Reply to this email directly or view it on GitHub https://github.com/jupyter/design/issues/10#issuecomment-75162720.

Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

jdfreder commented 9 years ago

Hey @tclem , do you remember what font you used? I really like that font (and the design)!

tclem commented 9 years ago

The menus (File, Edit, View, etc) are Helvetica Neuve and the code is Meslo LG - one of my favorite monospaced fonts.

rgbkrk commented 9 years ago

If this was a PR, I'd be kicking the tires on it right now. I still think this is absolutely wonderful to view and would likely be perfect for exploring+authoring.

damianavila commented 9 years ago

If this was a PR, I'd be kicking the tires on it right now. I still think this is absolutely wonderful to view and would likely be perfect for exploring+authoring.

I could not agree more on these thoughts...

rgbkrk commented 9 years ago

Sitting down with @willwhitney and @odewahn, looking over this design.

Thinking about the ':floppy_disk: | :heavy_plus_sign:' toolbar,

Adding a cell with a plus icon at the top breaks the context of where you're inserting a cell. You end up having to click a different cell to add a new cell. In the cell input label, there should be a contextual gutter for working with that cell. As for save, we already autosave and they can also click File->save, there's a save shortcut (ctrl/cmd-s).

rgbkrk commented 9 years ago

Having a contextual cell gutter could also expose the split cell action.

neilpanchal commented 9 years ago

Overall, I love the proposal.

My feedback as follows:

The lime green line on the left edge of the window: is this an indication of active cell?
Fantastic use of white space.
Opportunities for reducing vertical space. I am not sure where and how to achieve that, but vertical space as previously mentioned has a profound impact on large and lengthy notebooks.
Vertical alignment of notebook name "Welcome" and the left edge of the code block / + sign.
I like that the design does away with shadows. Flat design is this decade's graphic design trend from big UI developers such as Apple, Android, etc. It really looks pleasant.

Logo Design

Any thoughts on the current logo design?

We are getting into a highly subjective matter, but my personal take on the current logo is that it falls in one of the following generic categories: http://www.gtgraphics.org/genericlogos.html

Don't kill me :-)

I can put some options together for something more iconic, unique and striking if there is enough interest.

Typography

I think we can do a lot better: http://blog.typekit.com/2012/09/24/source-code-pro/ However, disadvantages of fonts such as Source Code Pro or Bit-Stream Vera is that they take up a bit of horizontal space.

Jupyter Color Palette

Perhaps we can use a palette that is intelligently and procedurally generated in CIE-L_a_b space. I have been working on a Processing language library for procedural color generation that is perceptually uniform and as distant as possible from a given gamut.

CIE-L_a_b color generation: https://github.com/neilpanchal/Chroma Procedural Palettes in CIE-L_a_b: https://github.com/neilpanchal/Luma

Visual hierarchy can then be precisely established using luminosity as primary modulator and chromacity as secondary.

Another option is to use a palette generator from real Jupiter planetary images! I think that would be really cool but Jupiter is pretty bland looking.

jdfreder commented 9 years ago

We are getting into a highly subjective matter, but my personal take on the current logo is that it falls in one of the following generic categories: http://www.gtgraphics.org/genericlogos.html

Don't kill me :-)

Agreed, looks like 3 that are before the last.

neilpanchal commented 9 years ago

I don't want to pollute this thread from its original topic but may be I can slip a quick mockup based on the nounproject icon:

Minimal (Ignore the font please)
Contour lines signify the scientific and numerical computing motifs.
Faster recognition from Matlab user base and it mimics their 3d plot logo.
May be it looks like that giant storm of the size of earth on Jupiter, aka "The Giant Red Spot"
Iconic and unlike anything else. Instantly recognizable.

Perhaps I can add contour colors but it will convolute the simplicity of the logo. Jupyter Logo

Back to the original topic. Here is what my Jupyter environment looks like. I got rid of the box-shadows and using a custom palette that I have been using for a few years in Sublime text environment. I am one of those guys who spends hours and hours making sure the environment is PERFECT before I start coding. It is really a curse.

Notebook Design Screenshot

Palette

YELLOW      = #D9AA00
ORANGE      = #CF5804
RED         = #D43132
MAGENTA     = #C74483
VIOLET      = #975DDE
BLUE        = #2B88D9
CYAN        = #00A397
GREEN       = #688A0A

Carreau commented 9 years ago

1) Logo

We spent enough time bikesheding on the logo a year ago , and it's already everywhere, we won't comme back on it now. The question about wether we like it or not, is unrelated.

Though thanks for it, I (personal opinion), like it. Not more or less than current one though. I think the width of the line would be too small for favicon or small version of it.

2) Theme.

I like it. We would definitively like to have people designing them (crosslinking https://github.com/jupyter/notebook/issues/119) as relevant. I think it would be nice to have a matplotlib default colorscheme to have the same kind of colorsby default that the notebook.

Thoughts ? @njsmith, @stefanv and @tacaswell ? Will default matplotlib color change (beyond colormap).

neilpanchal commented 9 years ago

@Carreau Logos are profoundly important than most people realize. They mark the identity of the project and care must be taken in designing them. The current logo to be honest is lacking from all aspects. My $0.02. Big corporations spend millions of dollars on this stuff. I agree, the lines are too thin to be used as favicon. It is not great but if we are not open for discussion, it is a moot point :-).

Regarding the matplotlib, see how Gadfly generates colors using CIE color spaces: https://github.com/dcjones/Gadfly.jl/issues/602

minrk commented 9 years ago

@neilpanchal thanks for your input, but we are not considering a new logo at this time.

tacaswell commented 9 years ago

@Carreau There is talk of changing the default color cycle for lines which will probably happen. Changes to the default background color, grid state are much less likely, or font are much less likely.

Carreau commented 9 years ago

Logos are profoundly important than most people realize.

We realize. But we don't have millions, and we already got a designer and spend time with the current one. The fact that we were choosing a logo was public, and it would have been nice to have the discussion at the time we choosed. I think it is worse changing logo every years, than having a maybe-not-perfect-logo. So at least for now it is a closed conversation, though other side-related project might need logo.

Regarding the matplotlib, see how Gadfly generates colors using CIE color spaces: dcjones/Gadfly.jl#602

I don't decide how Matplotlib choose colors, I just think it would be nice to match.

@Carreau There is talk of changing the default color cycle for lines which will probably happen. Changes to the default background color, grid state are much less likely, or font are much less likely.

Great, that sufficient IMHO, it would be nice to have uniformity of color between lines and syntax-highligh, so that matplotlib graph look nice in notebook. Let us know if you make such decision. I'm not opposed either at having a theme closer to gadfly, or even try at some point to get consistency across plotting library among languages.

@neilpanchal is your custom css availlable somewhere ?

neilpanchal commented 9 years ago

@minrk @Carreau About the logo design, I understand and concede.

@Carreau It is not nicely formatted and I am not too familiar with the overriding mechanism for the custom.css in the iPython profiles. I used a bunch of !important tags to make it work. Here you go: https://github.com/neilpanchal/iPython-Notebook-Theme

Great, that sufficient IMHO, it would be nice to have uniformity of color between lines and syntax-highligh, so that matplotlib graph look nice in notebook. Let us know if you make such decision. I'm not opposed either at having a theme closer to gadfly, or even try at some point to get consistency across plotting library among languages.

Since there is no control over how matplotlib generates colors, perhaps we can try to match the luminosity of the color palette so that the UI of the notebook would look coherent. The assumption here is that matplotlib color palette would be based on perceptually uniform colors and not using RGB/HSL/HSV color space. Here is an example of what I am trying to convey:

Top: RGB/HSL, Bottom: CIE

Luminosity is apparent when converting to grayscale in photoshop (which uses CIELab transformations I believe). Top: RGB/HSL (large differences in luminosity) , Bottom: CIE (same luminosity)

This is the key to creating pleasant coherent colors. I am not too involved in the matplotlib project but we should keep an eye out for how they are going to change their default color palette and match the luminosity to ours.

tacaswell commented 9 years ago

@neilpanchal I am one of the core MPL devs and there is an active discussion (http://matplotlib.1069221.n5.nabble.com/RFC-candidates-for-a-new-default-colormap-td45652.html and links contained with in) about changing the default color map should be.

The current plan is to version bump mpl to 2.0 'soon' (where soon means once the bike shedding is done) purely to be able to change the default colors.

neilpanchal commented 9 years ago

@tacaswell Great. I like where MPL is heading with the color maps (Option D is good). However, are there any plans for changing discrete colors (for e.g. pie charts) that require visually distinct colors? I built one using k-means-clustering to group colors into distinct voronoi clusters. It would horrendously slow & unrealiable but linking it nevertheless: https://github.com/neilpanchal/Luma/blob/master/src/com/luma/Luma.java#L178-319

If the discrete colors are generated using some clever way, Jupyter can benefit from using the same basic palette for code coloring.

tacaswell commented 9 years ago

The color brewer color maps are already included.

As I said above changing the default color cycle is on the radar, but has not been discussed much (as there have not been any serious proposals other than the deep palette from seaborn).

Carreau commented 9 years ago

As I said above changing the default color cycle is on the radar, but has not been discussed much (as there have not been any serious proposals other than the deep palette from seaborn).

Where is the discussion for that, the thread you point to seem to be only colormap ? It seem to me that if version bump there is to change default colormap, it should be a unique bump to change default color-map and color-cycle (and other default if other default to change there is).

neilpanchal commented 9 years ago

@tacaswell Color Brewer is a fixed palette just like Option D in the current proposal. I really like how Gadfly is going with both color cycles and color maps. https://github.com/JuliaLang/Color.jl#color-scales

Excellent paper that talks about procedurally generating color maps that look like manually picked Color Brewer maps: http://magnaview.nl/documents/MagnaView-M_Wijffelaars-Generating_color_palettes_using_intuitive_parameters.pdf

ellisonbg commented 9 years ago

Thomas,

Are you aiming to change everything related to the default style for the 2.0 release (colormap, colorcycle, etc.) or just the colormap? While I know that these discussions can get lengthy, it seems like it would make sense to try to do them all at once...

I am wondering if there would be support for making tick marks point outwards by default...

Cheers,

Brian

On Sun, Jun 7, 2015 at 12:57 PM, Neil Panchal notifications@github.com wrote:

@tacaswell https://github.com/tacaswell Color Brewer is a fixed palette just like Option D in the current proposal. I really like how Gadfly is going with both color cycles and color maps. https://github.com/JuliaLang/Color.jl#color-scales

— Reply to this email directly or view it on GitHub https://github.com/jupyter/design/issues/10#issuecomment-109793439.

Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

tacaswell commented 9 years ago

@ellisonbg The goal is to roll all of the style changes into one api breaking release.

I am personally against changing the tick directions, but not sure of the general support for that.

The idea of the style module (which can load from a URL) is to make it easier to tune the rcparams (with nominally stackable styles) to get around these sorts of discussions :wink: .

From @Carreau 's traitlets + mpl demo I suspect style will have to get a major overhaul.

njsmith commented 9 years ago

I am wondering if there would be support for making tick marks point outwards by default...

HOORAY I'M NOT ALONE

Carreau commented 9 years ago

Sidenote, here is about 80% of @tclem mockup theme as css for the notebook.

ellisonbg commented 9 years ago

Here we go:

https://github.com/matplotlib/matplotlib/issues/4502

On Sun, Jun 7, 2015 at 5:21 PM, Matthias Bussonnier < notifications@github.com> wrote:

Sidenote, here https://gist.github.com/Carreau/6e8e929b2b62f56ce5b0 is about 80% of @tclem https://github.com/tclem mockup theme as css for the notebook.

— Reply to this email directly or view it on GitHub https://github.com/jupyter/design/issues/10#issuecomment-109817142.

Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

neilpanchal commented 9 years ago

@Carreau Hi Matthew, found this bug that shifts the cell by 2 pixels if it is selected vs. unselected.

Unselected Cell Height = 99.98px

Selected Cell Height = 97.98px

CSS Changes to address this problem:


div.cell.selected {
    border:none;
    border-left: solid thick #9c3 !important
}

div.cell {
   border:none;
   border-left: solid thick transparent !important

}

Modified CSS

https://gist.github.com/neilpanchal/c9dddb4017c727069746

Also, I quickly made some changes to the top header. I think the Jupyter logo is huge and the letters are part of the svg. So I got rid of it to make a point. The notebook name and the logo font size do not match. I think that is really ugly. Also, the drop shadows...

Before:

After:

Removed the top border-shadow.
Removed the container border border-top: 17px solid #DDD;
Added header & toolbar margins for some negative space
Increased toolbar margin-bottom from -3px to 5px. Currently the top margin is greater than bottom.
Sorry, I had to get rid of the logo to exemplify the uniformity of the fonts in the header.
Notebook name, align it to the left edge of the cell. Right now, I just renamed the notebook to "Jupyter - Sample Notebook".

Carreau commented 9 years ago

Yeah, that why I said 80%, some things definitively need change in the JS, and I'm not sure we want that theme by default (plus other point above). I was just giving the link in case some people want to improve, and also get some idea of what need to change in the JS.

njsmith commented 9 years ago

There's even an argument for just sticking a logo in the corner unobtrusively and leaving out the letters "jupyter" entirely. Firefox doesn't put the word "FIREFOX" in big letters on top of every page, because I know I'm using firefox. Granted people might sometimes need a reminder how "jupyter" is spelled, but probably there are higher priority things those pixels could be used for :-)

Now that I look I see that the original proposal at the top of the thread also did this :-)

dunovank commented 8 years ago

Not sure if anyone's still interested in this thread, but the flat style and layout of the design proposed above bears some similarity to my jupyter-themes (now pip installable thanks to @miraculixx). Just thought I'd post the link in case anyone is interested in grabbing some of the css or whatever. Cool design by the way, @tclem I especially like what you've done with the layout of the toolbar, logo, etc! Have you implemented this anywhere? I'd really like to incorporate some of these design ideas in the repo mentioned above. Thanks!

tclem commented 8 years ago

Have you implemented this anywhere? I'd really like to incorporate some of these design ideas in the repo mentioned above. Thanks!

I haven't implemented this anywhere, please feel free to use anything that inspires!

neilpanchal commented 6 years ago

@tclem @ellisonbg @Carreau

I've just recently done a complete overhaul of the Spinzero jupyter theme: https://github.com/neilpanchal/spinzero-jupyter-theme

If there is any interest in adopting some of these ideas (there is no javascript), I would really love to contribute. Jupyter has a really wide reach and I think good design would have a tremendous impact.

rgbkrk commented 6 years ago

I think if you make small PRs to improve the classic notebook iteratively, they'll be well received. I can't imagine everything will get brought in en masse, and there's probably a bit of learning about some of the tradeoffs we have to make relative to current usage, patterns, and expectations.

Also feel free to contribute to the other frontends, nteract and jupyterlab.

Carreau commented 6 years ago

Thanks @neilpanchal,

For the context, I'm guessing this is due to my comment on https://www.reddit.com/r/Python/comments/7q99ev/spinzero_a_minimal_jupyter_notebook_theme/.

I don't have much time to respond and will be back online likely only in 48h; but one thing I would love is for a way to distribute, build and select themes for the notebook; there are already various themes lurking around on the internet; and it should not be too hard to do, I even believe JupyterLab have already a built-in theme switcher.

I think some of our docs could need design, and nbviewer could (IMHO) get a lift.

There is also quite a bit of activity on https://mybinder.org/ (https://github.com/jupyterhub/binderhub)

Of course you need to find something to do that you like, and there is no small task, from completely redesigning the notebook theme, or even just putting christmass hat on the Jupyter avatar on Facebook, Twitter and Youtube.

Thanks !

jupyter / design