search

jupyter / design

Design related materials for Project Jupyter
BSD 3-Clause "New" or "Revised" License
82 stars 59 forks source link

JupyterLab UI/UX #20

Closed cameronoelsen closed 8 years ago

cameronoelsen commented 8 years ago

Hey everyone!

Starting today, I am going to be shifting most of my focus to researching and designing the Jupyter Workbench's (name to be decided on) 1.0 initial release interface. @ellisonbg and I have started a Hackpad that outlines some common functionalities that we have seen users are accustomed to. Please feel free to add anything you might see to be a helpful feature/functionality to the end user for the initial release at https://jupyter.hackpad.com/Jupyter-Workbench-UIUX-m8yrTt4p5ZA. As I design the interface, it will be posted here for further discussion!

sccolbert commented 8 years ago

Awesome! Can we setup a hangout to sync up on ideas? This design really needs to be an open back-and-forth between what is desired, and what is reasonably implementable. It will also help inform me for required features in the dock panel, tab bars, etc...

ellisonbg commented 8 years ago

Sure, Cameron and I are around now, but we could also talk tomorrow or Friday.

On Wed, Nov 18, 2015 at 4:51 PM, S. Chris Colbert notifications@github.com wrote:

Awesome. Can we setup a hangout to sync up on ideas? This design really needs to be an open back-and-forth between what is desired, and what is reasonably implementable. It will also help inform me for required features in the dock panel, tab bars, etc...

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

Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

sccolbert commented 8 years ago

tomorrow is fine

ellisonbg commented 8 years ago

Sounds good...

On Wed, Nov 18, 2015 at 5:17 PM, S. Chris Colbert notifications@github.com wrote:

tomorrow is fine

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

Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

cameronoelsen commented 8 years ago

Here are the first iterations of the Workbench menus!

The first two screenshots below are the workbench with the top menu being shown (the menu can be hidden by clicking the arrow in the top right). 1 2

These next two screenshots are possibly what it could look like when the top menu is hidden. When the menu is hidden, the jupyter logo and menu toggle are still left in the top left and right corners. @ellisonbg and I really like how this looks, but were thinking of the complexity this may add. 3 4

Again, this is my first pass so anything you want me to try out I can get in the mockup up tomorrow!

sccolbert commented 8 years ago

Having the arrow and icon remain after hiding the menu adds substantial complexity.

cameronoelsen commented 8 years ago

@sccolbert Here is a quick update of the interface without the two icons in the top right and left. Took into account while designing that the user will, once hiding the top menu bar, they will need to hover their mouse in the general area to have it slide in from the top to reveal itself again.

When a tab on the left is opened and the top menu is in view: 1

When a tab on the left is opened and the top menu is out of view: 2

sccolbert commented 8 years ago

We may want to be careful with dedicated "hot zones" which are "always on". If the user has actual content near the top of the page they want to click on AND the menu is hidden, the menu will slide out blocking the view. We've all experienced this at one point or another, with some full-screen program. I personally would prefer a smaller band like you have on cloud 9.

However, Brian and I were talking last night, and seems like what is really wanted is a full-screen "presentation mode" for the content in a particular tab. We can do that as a separate feature without requiring a collapsibable menu bar.

My vote would be to not implement collapsing until we have a better idea of why we think we want it, and are sure there's no better alternative.

ellisonbg commented 8 years ago

Yep, I am fine waiting on the collapse behavior.

On Fri, Nov 20, 2015 at 1:30 PM, S. Chris Colbert notifications@github.com wrote:

We may want to be careful with dedicated "hot zones" which are "always on". If the user has actual content near the top of the page they want to click on AND the menu is hidden, the menu will slide out blocking the view. We've all experienced this at one point or another, with some full-screen program. I personally would prefer a smaller band like you have on cloud 9.

However, Brian and I were talking last night, and seems like what is really wanted is a full-screen "presentation mode" for the content in a particular tab. We can do that as a separate feature without requiring a collapsibable menu bar.

My vote would be to not implement collapsing until we have a better idea of why we think we want it, and are sure there's no better alternative.

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

Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

cameronoelsen commented 8 years ago

So this is my first run on the file browser (single selection file selected). I am making right now multiple selected cells as well as the controls that those come with (will be similar to the current file browser). Also will make a mockup of how the dropdowns look for both the top menu as well as the side menu. file browser

cameronoelsen commented 8 years ago

Here is the first run on the file browser with multiple selection and the controls that go along. I should also note that the controls that are in orange that have 3 dots behind the title indicates that there will be a popup that confirms with the user that they want to perform this action or it requires further information (move...) file browser - multiple select

sccolbert commented 8 years ago

@cameronoelsen do you have a color palette for this stuff? I'm ramping up on Phosphide, and will start building the example from these mockups.

cameronoelsen commented 8 years ago

@sccolbert We are going to be using the material design color specifications which can be found here: https://www.google.com/design/spec/style/color.html#color-color-palette

As to how this fits into the mockups, I posted both the most recent mockup for the UI/File Browser below along with one with color specifications on top of it that works with the material color palette.

Most recent mockup: 1

Material color specifications: 2

ellisonbg commented 8 years ago

Also, base font size will be 13px.

@sccolbert - one good way for you to get measurements of everything would be if you purchase Sketch and we share the files with you. Do you think that is an option?

On Wed, Dec 2, 2015 at 2:07 PM, Cameron Oelsen notifications@github.com wrote:

@sccolbert https://github.com/sccolbert We are going to be using the material design color specifications which can be found here: https://www.google.com/design/spec/style/color.html#color-color-palette

As to how this fits into the mockups, I posted both the most recent mockup for the UI/File Browser below along with one with color specifications on top of it that works with the material color palette.

Most recent mockup: [image: 1] https://cloud.githubusercontent.com/assets/6437976/11545765/eff99602-98fd-11e5-9fcf-a3a43caf8d8c.png

Material color specifications: [image: 2] https://cloud.githubusercontent.com/assets/6437976/11545775/00a695c2-98fe-11e5-84bd-98f97b44a966.png

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

Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

sccolbert commented 8 years ago

@cameronoelsen thanks!

Is it just me or do the borders between the sidebar buttons and the left border of the file browser look "fuzzy" compared to the right border?

sccolbert commented 8 years ago

@ellisonbg I'll look into it, good idea!

sccolbert commented 8 years ago

Ok, I just zoomed in on those left borders, and they are a 2px gradient, whereas the right border is a 1px solid.

cameronoelsen commented 8 years ago

All of the borders should be uniform in this one below using the grey 300 3

sccolbert commented 8 years ago

I think the upload failed

cameronoelsen commented 8 years ago

@sccolbert refresh :)

sccolbert commented 8 years ago

thanks :)

sccolbert commented 8 years ago

@cameronoelsen the borders are still coming out as 2px gradients for me: capture

This may be just be an artifact of the conversion to png. Should it be a single pixel border?

cameronoelsen commented 8 years ago

Yeah it must just be the conversion, the borders are all 1px

sccolbert commented 8 years ago

@ellisonbg looks like Sketch is a Mac-only app. I develop on a Windows machine.

ellisonbg commented 8 years ago

OK, we will have to figure out something else to distribute this info then...

On Wed, Dec 2, 2015 at 8:18 PM, S. Chris Colbert notifications@github.com wrote:

@ellisonbg https://github.com/ellisonbg looks like Sketch is a Mac-only app. I develop on a Windows machine.

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

Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

cameronoelsen commented 8 years ago

@sccolbert Here is the first run of the design of the Command palette! Have attached a version without the color specs as well as one with them. I will continue to iterate and start on some mockups for the dock area windows.

Without color specifications: command_pallete

With color specifications: command_pallete_colors

sccolbert commented 8 years ago

:-1: on using Mac shortcut symbols. Not everyone uses Mac. I also (personally) find those symbol unintelligible and still have no idea what they mean after using Macs for years :)

sccolbert commented 8 years ago

:+1: on the rest of it though.

sccolbert commented 8 years ago

@cameronoelsen can you also mock up a menu bar menu in the open position? And perhaps some tabs/panels.

sccolbert commented 8 years ago

Also, what font face are you using here?

blink1073 commented 8 years ago

It looks like Gray 600's color is mislabeled.

blink1073 commented 8 years ago

Unless it is meant to be the same as Gray 200.

cameronoelsen commented 8 years ago

@sccolbert All the text in the mockups are just filler, made up stuff to give any idea of what we could do. I am mocking up the open menus right now! I am using Helvetica Neue for the entire design except for the keyboard shortcuts. Helvetica Neue didn't have the right symbols for alt and command.

sccolbert commented 8 years ago

Cool. Thanks!

cameronoelsen commented 8 years ago

@sccolbert Here are two instances of the menus open, one also with a submenu. For the menu I am using: Background color: White The top two corners of the menu aren't rounded but the two corners at the bottom of the menu are rounded with a radius of 2.

I am using material design specifications for the shadowing behind the menus. They use two different shadows together to get a material shadow effect, however I don't know how it translates to web. Shadow 1: RGBA: 0,0,0,12 with a blur of 2px Shadow 2: RGBA: 0,0,0,24 with it shifted down 2px in the y direction with a blur of 2px

For the submenus, the only thing that is different is that the second shadow, instead of it being shifted down 2 pixels, is found at 3px shifted down. If we have more than one submenu coming off of a dropdown, each subsequent menu would be shifted down 1px and increase the blur by one as well.

File Browser Add Button Dropdown: file_popup

Top menu dropdown: top_popup

sccolbert commented 8 years ago

@cameronoelsen We have some more flexibility with our menus that that (formatting, shortcuts, icons, etc..). Checkout this example: http://phosphorjs.github.io/examples/menus/

ellisonbg commented 8 years ago

For shadows with CSS, material design lite has a good starting point for different shadow sizes:

https://github.com/google/material-design-lite/blob/master/src/_mixins.scss#L216

On Fri, Dec 4, 2015 at 3:57 PM, S. Chris Colbert notifications@github.com wrote:

@cameronoelsen https://github.com/cameronoelsen We have some more flexibility with our menus that that (formatting, shortcuts, icons, etc..). Checkout this example: http://phosphorjs.github.io/examples/menus/

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

Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

sccolbert commented 8 years ago

Can we treat the shadows for menus all the same for now? I currently indicate depth by physically overlapping the menu. Adding CSS classes to track the logical depth of a submenu will take extra code.

sccolbert commented 8 years ago

Also of note: Phosphor submenus are not DOM children of their parent menu. This is done on purpose. In order to reduce reflows, all Phoshphor panels and widgets have overflow: hidden by default (this is required to trigger internal browser layout boundaries). If we were to make menus DOM children of widgets, we would have to allow overflow, which would kill performance.

sccolbert commented 8 years ago

@ellisonbg nice link. Thanks.

ellisonbg commented 8 years ago

I would start with the 2 or 4 dp shadow and see how that looks.

On Fri, Dec 4, 2015 at 4:12 PM, S. Chris Colbert notifications@github.com wrote:

@ellisonbg https://github.com/ellisonbg nice link. Thanks.

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

Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

cameronoelsen commented 8 years ago

Here is a screenshot of a few revisions (shadows, grays, etc.) we did and our first pass at the text editor (without interior borders) workbench_with_windows

sccolbert commented 8 years ago

@cameronoelsen @ellisonbg For ordering of items in the command palette, were were originally talking about sorted order, but most (all) palettes I've seen order based on strength of the fuzzy match. What are your thoughts there?

ellisonbg commented 8 years ago

Would it make sense to order at the top level by categories and the by strength of the match?

On Mon, Dec 7, 2015 at 7:02 AM, S. Chris Colbert notifications@github.com wrote:

@cameronoelsen https://github.com/cameronoelsen @ellisonbg https://github.com/ellisonbg For ordering of items in the command palette, were were originally talking about sorted order, but most (all) palettes I've seen order based on strength of the fuzzy match. What are your thoughts there?

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

Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

sccolbert commented 8 years ago

That could work. We could also have a "Best Match" category at the very top, which holds the singular best match and is the default selection.

ellisonbg commented 8 years ago

I think that sounds good.

On Mon, Dec 7, 2015 at 10:37 AM, S. Chris Colbert notifications@github.com wrote:

That could work. We could also have a "Best Match" category at the very top, which holds the singular best match and is the default selection.

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

Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

minrk commented 8 years ago

Let's make sure we use the platform-defined standards for displaying shortcuts. It wouldn't be appropriate to use text labels on OS X, just like it wouldn't be appropriate to use OS X symbols on Windows.

blink1073 commented 8 years ago

WIP on the file browser redesign: https://github.com/jupyter/jupyter-js-filebrowser/pull/6

rgbkrk commented 8 years ago

At the very least, I enjoy reading this issue and its updates.

cameronoelsen commented 8 years ago

After talking with you @sccolbert and @ellisonbg about the shadows being overwhelming, I toned it down and it looks a heck of a lot better with the shadowing only on the content area windows.

New shadowing: main_window