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.

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

updating markdown options panel to EUI #18580

Closed
wants to merge 11 commits into from

Conversation

ppisljar
Copy link
Member

@ppisljar ppisljar commented Apr 25, 2018

TODO:

  • tests

screenshot-localhost-5601 2018 05 03 21-04-18

@ppisljar ppisljar added review Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins. Feature:Visualizations Generic visualization features (in case no more specific feature label is available) v6.4.0 labels Apr 25, 2018
@ppisljar
Copy link
Member Author

ppisljar commented Apr 25, 2018

should we use panels to contain options ? (something like that is used in many visualizatons)

screenshot-localhost-5601 2018 04 25 15-12-24

@ppisljar
Copy link
Member Author

yeah, i think it looks better

screenshot-localhost-5601 2018 04 25 15-20-14

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@cchaos
Copy link
Contributor

cchaos commented Apr 26, 2018

@ppisljar Are the three buttons above the settings a global component or are they manually added to each viz editor?

@cchaos
Copy link
Contributor

cchaos commented Apr 26, 2018

@ppisljar Overall this is looking better. I found a few bugs and can offer a few suggestions for layout.

First, the bugs

1. Font size slider's initial state is wrong

When loading this screen the slider's handle is always on the far right no matter the actual font-size value.

Note: Eventually EUI will have a stepped slider to use for the font-sizes as increments.


2. Links in new tab switch doesn't take effect until after you refresh the page


3. When resizing the two panes, it will update the preview without having to press the update button

This seems like unexpected behavior to me as I feel like the only thing that should allow updating is the auto-update or update buttons.


4. Starting around 991px wide window size and below, we completely lose the preview

screen shot 2018-04-26 at 16 13 11 pm


5. Adjusting the size of the textarea can mess up the pane sizing and cover up the preview


6. The help link is missing

screen shot 2018-04-26 at 16 11 13 pm

However, the current help link is incorrect as it just goes to Github help and not markdown help. My suggestion is to change the textarea label text to "Content" and add the following link to the far right of the label.

<EuiLink href="https://www.markdownguide.org/cheat-sheet"><EuiIcon type="help" /> Syntax help</EuiLink>


Layout

7. If I could have my way 😁 I'd like to set up the layout like this:

screen shot 2018-04-26 at 17 11 07 pm

Both the settings and preview are in a panel and the settings panel has the scrollbar. It also overrides some background colors and pushes the floating toggle buttons into the resizing area to maximize space and minimize overlapping.

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more thing I saw there is a console error about supplying the rows property to the textarea as a string vs number.

@ppisljar
Copy link
Member Author

ppisljar commented May 3, 2018

thanks a lot for your feedback @cchaos

i will work on this today and try to move it forward, but in general i will try to keep the scope of this:

  • to only markdown visualization, so everything that is general for all visualizations will not be handled here
  • to only bugs introduced with this PR (so existing markdown bugs will not be fixed here, unless trivial)

ps: yes, the 3 buttons are the global editor. as well as panel resizing and floating toggle buttons.

maybe it would make sense to approach this from other direction and first EUIfy the editor (so everything around the actual option panels) ?

@ppisljar
Copy link
Member Author

ppisljar commented May 3, 2018

fixed:

  • help link
  • font slider is initialized
  • resizing works ok
  • styles updated a bit

not fixed:

  • when resizing changes get applied (problem on master)
  • open links in new tab has no effect until refreshing (problem on master)
  • on mobile we loose preview (problem on master)

no design changes were made to anything but the actual option panel of markdown editor

@elasticmachine
Copy link
Contributor

💔 Build Failed

@cchaos
Copy link
Contributor

cchaos commented May 3, 2018

Understandable about the scope issue for this PR. I'll leave it up to you in which order is best to progress with EUI-fying.

I really like your solution to the textarea sizing 🥇

The one other thing I'd really like to do is put the syntax link inline with the textarea label. This way it's always connected to the input (where they're actually writing the markup) in case more options are added in between.

I'd use <EuiFlexGroup> and <EuiFlexItem>s to wrap the label content and then just set the prop grow={false} on the flex item holding the link so that it sits at the far right.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@timroes
Copy link
Contributor

timroes commented May 4, 2018

My suggestions regarding that PR:

  • Could we remove the "Markdown" header? We don't put a header with the vis type in any other editor, and imho we are just using space here. If we really want to print this somewhere (just for the markdown vis), I would rather have one editor tab named "Markdown" instead and being visible, but I really wouldn't like to have that huge title in the editor. (@cchaos your opinion on that?)
  • As already commented in the code, I think we should build that help text functionality into EUI, since we will have that same look and feel in many places in the editor. If we implement it everywhere like that, it makes it way harder to later change the styling of all those places in case we figure out a nicer way to have that hint texts. Also currently all of that will be in the "label" for the input field, which is kind of not the best accessibility, since it will always read out the textarea as "content syntax help", which might be confusing. Putting it into EUI, we could extract that help link in that (and all other places) from the label. (also pinging @snide on this one, because .. why not :D)

Besides those two suggestions, the general approach and look and feel looks good for me. Would rather have some decision on those two points before approving the PR :)

@cchaos
Copy link
Contributor

cchaos commented May 4, 2018

@timroes

I'm fine with removing the large "Markdown" header. I agree that it is just taking up space. I'm not sure we needs to add tabs to just to add a heading and especially if there will only be one tab.

My one concern about removing it, though maybe we just move it to the textarea label ("Markdown content" or something), is that I was hoping that when we re-do the viz selector, we can change the "Markdown" option to just "Text". The reason being that, since we are now gearing Kibana towards non-engineer users, most people won't know what "Markdown" is, but if they see the option for "Text" they'll know what that is.

Kind of like in this mock:
screen shot 2018-05-04 at 12 20 09 pm

As for you second bullet, I responded to your original about the helpText prop on EuiFormRow. We could just go ahead and use that though I'm concerned about pushing it to the bottom of a very long textarea.

@timroes
Copy link
Contributor

timroes commented May 4, 2018

I would be fine renaming the Markdown component to Text already, that would be an easy rename.

Regarding the adding one tab. Peter and I also discussed the possibility of splitting things up into two tabs, so we would have one tab "Text" or "Template" with just the input box available (and the help link) and a second tab "Options" to properly split the options, like we do in all other visualizations. In my opinion it was kind of an mistake we just plugged them all in that one tab. Do you think that would be a viable solution?

@elasticmachine
Copy link
Contributor

💔 Build Failed

@timroes
Copy link
Contributor

timroes commented May 9, 2018

Could you rebase on master to get rid of some of the test failures?

<EuiPanel
grow={false}
className="editorOptionsGroup__panel"
className={`editorOptionsGroup__panel ${props.className}`}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would write editorOptionsGroup__panel undefined to the class if the property hasn't been specified. We usually use classnames for concatenating (and conditionally) apply classnames.

import className from 'classnames';

const panelClass = className('editorOptionsGroup__panel', props.className);

return <EuiPanel className={panelClass} />;

@@ -18,10 +20,10 @@ import {
* to produce an aligned look and feel.
*/
function EditorOptionsGroup(props) {
return (
const collapsibleOptionGroup = (
<EuiPanel
grow={false}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to use prop.grow here too :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

grow on panel with accordion doesn't make any sense as accordion does not grow

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case I would add the following to the propType definition of grow: "Only applies when collapsible is set to false."

</EuiFlexItem>
</EuiFlexGroup>

<EuiSpacer size="m"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Panel layouts it's content different than accordion. Looking in the rendered result, I would suggest that we remove the EuiSpacer in this case, since it would introduce noticeable more spacing than the EuiAccordion variant would have.

const params = this.props.scope.vis.params;

const markdownLabel = (
<EuiLink className="markdown-vis--help" href="https://www.markdownguide.org/cheat-sheet" target="_blank">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the class name can be removed. It doesn't seem to be used anywhere.


.markdown-vis-editor textarea {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could instead of needing the nested query, just using className to apply a class name to the EuiTextArea instead.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Contributor

@timroes timroes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add some tests and that LGTM

@ppisljar ppisljar requested a review from nreese May 10, 2018 13:38
@nreese
Copy link
Contributor

nreese commented May 10, 2018

You can put the UI in a weird state by editing the markdown, then clicking Apply changes, and finally clicking the settings tab. Notice how the settings are not contained in the general panel are instead displayed on the grey background.

screen shot 2018-05-10 at 7 55 15 am

@timroes
Copy link
Contributor

timroes commented May 10, 2018

So this is also blocked by elastic/eui#805

@elasticmachine
Copy link
Contributor

💔 Build Failed

@ppisljar
Copy link
Member Author

closing, as the bug in eui will not be fixed and we will not be euifying our editor for now

@ppisljar ppisljar closed this Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Feature:Visualizations Generic visualization features (in case no more specific feature label is available) review Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins. v6.4.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants