Design Review of Dialogs
Closed this issue · 76 comments
Provide screenshots of existing Dialogs for @cameronoelsen.
Here is my first pass at the dialogs:
Close Without Saving
Create New Notebook
Error
Restart Kernel
Shutdown Kernel
Trust Notebook
I am still unsure if the cancel button should be on the right or if the done button should be, as well as which button the accent color should be on. I put the accent color on the Cancel button throughout the designs since I have seen a few other websites do this and I am assuming that this is being done so that if a user accidently clicks on something, when you click "Enter" on your keyboard, it cancels the action to ensure that the user meant to perform the task. But, I will need to do some further research to make sure that these user interactions are correct. Besides this, what are your guys' thoughts?
Thanks @cameronoelsen, see jupyter/notebook#742 for @ellisonbg's thoughts on the matter. My preference would be for the "do action" to be highlighted, and take on an appropriate color based on whether the action is "dangerous".
Also, the "refresh error" should probably have a better name/explanation. What it really means is that we lost our connection to the server and were unable to refresh the directory listing. Maybe:
Title: Server Connection Lost
Body: Unable to refresh the directory listing due to lost server connection.
Also note that the dialogs should be modal only to their respective pane.
Awesome, here are the changes. The insight/article Safia posted about the buttons fixed that problem and I made sure that the modals are only in their respective windows. I like the look of these more already!
Close Without Saving
Create New Notebook
Error
Restart Kernel
Shutdown Kernel
Trust Notebook
Looking good, got some colors for me 😄?
@blink1073 Making a specification sheet as we speak :)
Dialog Color Specification
Dialog Margin/Padding
Sweet, great work as usual Cameron, I'll style them tomorrow.
Thanks, @cameronoelsen!
One more for you @cameronoelsen:
Status:
@ellisonbg, it looks like the preference is to give the "action" button focus based on the existing ui, do we want to add outline styling?
I wouldn't do the extra outline styling. Both Material Design and Metro
don't add any additional styling to the default button. They don't even
always style it differently...
On Tue, Mar 22, 2016 at 9:04 AM, Steven Silvester notifications@github.com
wrote:
@ellisonbg https://github.com/ellisonbg, it looks like the preference
is to give the "action" button focus based on the existing ui, do we want
to add outline styling?[image: screen shot 2016-03-22 at 11 04 21 am]
https://cloud.githubusercontent.com/assets/2096628/13958381/da6387ea-f01d-11e5-86b2-2ba8e7beacba.png—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#115 (comment)
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, any thoughts on centering the buttons vertically rather than pinning them to the left?
@blink1073 Definitely think that all of the content should be left justified (title, description, buttons). It also seems that the buttons are a little too big. Also, the dialogs shouldnt have a border but rather just a shadow.
Ah! I totally missed that text and header were left-justified.
There was still a bit of padding on the button, fixed:
@blink1073 Is there a way to make the input field line up with the right side of the OK button? Also lookin' slick.
All that's missing is dropdown styling ;)
@blink1073 Looks like there is some extra padding or margin on the right side of that, the left and right side don't look equal. Also, it looks like there is an outside border on the dialog, can we swap that out for like a 2px box shadow and see how that looks? Figuring out right now how I want the dropdown to look like 👍
Thanks, tweaking some more...
This is with box-shadow: 2px 2px 2px black;:
Try this out box-shadow: 0px 2px 2px 0px rgba(0,0,0,0.5);
That looks great but I only want the shadow to be in the y-direction and not the x-direction
Oh, I had updated just the color:
Beautiful 😍
Thoughts on using cap-case and using "Okay"?
Are we able to change the OK button per different dialog? You can see in my mockups that, if possible, we can put the action in that box
I personally have no preference on OK vs OKAY but have seen OK used more in interfaces in the past
Yes, the dialogs have the action text you used above. I mean capitalizing just the first letter.
I am 👍 on capitalizing the entire word. This is one of the conventions I used from material design and I think it makes the buttons look standardized
Also:
Selecting kernel
Getting the colors of that right now, it uses the same margins as the other dialogs
Sweet! Adding standard dropdown selector now.
Also wasn't sure if you had control over the arrow in the dropdown so I just colored it. May want to change the margins depending what it looks like when you make the other styling
Did you want to define the <input> tag similarly?
I think the input tag looks pretty good actually, looking at that, I made a change to the background color of the dropdown so it is lighter than the dialog (looks nicer and tells the user that it is it's own element). The color is just white #FFFFFF
Also there is a 2px border radius that I accidently left out. That should be applied to the tag
2px border radius on the input field and that should be good!
My demo doesn't have a dropdown in it, adding one...
The arrow can't be styled from what I can tell:
Slimmed down the text-based one:
Even slimmer (now all the dialogs are 290px wide):
Whoops, it is supposed to be 300px, now finished:
The left aligned dismiss button looks weird to me. I think most dialogs
right align the buttons, right?
On Mar 22, 2016 3:30 PM, "Steven Silvester" notifications@github.com
wrote:
Whoops, it is supposed to be 300px, now finished:
[image: screen shot 2016-03-22 at 3 30 06 pm]
https://cloud.githubusercontent.com/assets/2096628/13966989/fd377644-f042-11e5-800c-cb2c5f6853ef.png—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#115 (comment)
"Button alignment: Right edge for LTR scripts"
I opened this newer issue about dialogs here: jupyter/jupyter-js-ui#98
Where is the right place for JupyterLab issues? Central? Per repo, depending on what it is?
@ellisonbg @blink1073 Is the warning about trusted notebooks accurate? It reads a little funny. I would think that an 'untrusted' notebook could be malicious.
It could perhaps be worded better. The point is, if it is marked as trusted, any malicious code that it happened to contain would be executed. I had copied the phrasing from the existing notebook.
@ellisonbg, I would argue that jupyter-js-ui, jupyter-js-notebook, and jupyter-js-plugins should be merged into a single jupyterlab with appropriate subfolders, the same way we are squeezing phosphor down. The current split is causing a lot of confusion.
👍 to fewer repos. Let's just use well-named paths and rely on webpack to pare things down. Any argument about saving disk space is null and void when you look at the dependency graph of a typical node package :)
Or maybe jupyter-js-jupyterlab as we will likely have a jupyterlab python
package?
On Fri, May 27, 2016 at 1:52 PM, S. Chris Colbert notifications@github.com
wrote:
👍 to fewer repos. Let's just use well-named paths and rely on webpack to
pare things down. Any argument about saving disk space is null and void
when you look at the dependency graph of a typical node package :)—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AABr0FYTNKN1YpEjFejD2rJ9jQ3Sx1yKks5qF1mYgaJpZM4H0C0v
.
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
Shouldn't the python portion be minimal? We could just include the Python in the same repo.
It makes sense for the server extension python to be with the javascript of jupyterlab.
If we want to separate things, we could have that javascript be minimal and only be the webpack bundler + package.json listing the plugins located in separates repos.
I can make a JupyterLab meeting this Friday 9-10am. Would be great to talk
about the package/repo organization.
On Mon, May 30, 2016 at 5:46 PM, Sylvain Corlay notifications@github.com
wrote:
It makes sense for the server extension python to be with the javascript
of jupyterlab.If we want to separate things, we could have that javascript be minimal
and only be the webpack bundler + package.json listing the plugins located
in separates repos.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AABr0EWGWodPETm_M0sh0zs92Rg2rRxfks5qG4TugaJpZM4H0C0v
.
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
Before I continue to iterate on the dialogs, I wanted to know what we think about where dialogs should be displayed (within each plugin or the entire screen):
Within the plugin
Version 1 (Popup Dialog)
Version 2 (Inline/dropdown Dialog)
Covering the entire environment
Version 1 (Popup Dialog)
I personally like the approach of covering the entire environment for all dialogs, seeing I haven't seen any other platform do per-plugin dialogs. I talked with Matt as well and he agrees. I just think using the fullscreen, full attention dialog is standard. What do you guys think? I am not set on all of the colors, but I made the buttons drastically smaller and made the fonts standardized with the rest of JupyterLab. We also were straying away from the orange highlight color for the actions and highlights!
I like Version 1 or Version 3. Version 3 is simpler to implement, though not by all that much. Who is Matt?
@sccolbert Matt is one of the new design interns that sits next to me in the SLO office, just happened to be passing by as I was writing the comment 👍 I like version 3 as well @sccolbert
I probably prefer 3 as well. Issues with 1:
- We will end up trying to show dialog in very small panels sometimes. That
is a pretty miserable user experience. - Most of these dialogs are should to be globally-modal, and block the rest
of the entire UI until the user deals with it. An example: if a user has a
notebook opened twice in two different panels (same model & 2 views), what
happens when one panel shows a dialog? Does the other show the same dialog?
What happens if a use interaction messes up the state implied by the dialog.
So strong preference for 3.
On Thu, Jun 2, 2016 at 1:31 PM, Cameron Oelsen notifications@github.com
wrote:
@sccolbert https://github.com/sccolbert Matt is one of the new design
interns that sits next to me in the SLO office, just happened to be passing
by as I was writing the comment 👍 I like version 3 as well @sccolbert
https://github.com/sccolbert—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AABr0LH2Ehfu-INa86OJoI-xBYawZiLjks5qHz2lgaJpZM4H0C0v
.
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
@ellisonbg brings up some great points. They increase my preference to a strong vote for version 3.
Version 3 works for me as well.
+1 for version 3 if there is a good way to indicate which panel the dialog is for. The other ways make it clear which tab the dialog is acting on. With option 3, there's no way to know other than trying to remember.
That's one thing I really like about OS X modal dialogs that drop down in the application window - it's very clear what is going to be affected, and it's easy to do other stuff while that particular window is on hold waiting for an answer.
For example, perhaps the panel causing the dialog to appear can have a heavy bright border or something. I don't think it's necessary to be able to see clearly everything in the tab, but some coarse-grained indication of which tab I'm interacting with would be a huge help.
+1 for version 3 if there is a good way to indicate which panel the dialog is for.
I would encourage some sort of indication within the dialog box too. Perhaps the name(s) of the tabs impacted by the dialog action could also be listed.
Closing, as design has moved to JupyterLab.