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

Start from a layout template #1857

Closed
ripla opened this issue Sep 17, 2018 · 14 comments
Closed

Start from a layout template #1857

ripla opened this issue Sep 17, 2018 · 14 comments
Assignees
Milestone

Comments

@ripla
Copy link
Contributor

ripla commented Sep 17, 2018

When creating a new design,
I want to be able to choose from a list of predefined layouts,
so that I can get started faster

It should be easy & fast for the user to get started with Designer. The Designer should provide a way to select a base layout to get started

UX

@ripla ripla added the Epic label Sep 17, 2018
@ripla ripla changed the title New Design wizard Start from a template Sep 17, 2018
@ripla ripla changed the title Start from a template Start from a layout template Jul 1, 2019
@ripla ripla added enhancement and removed Epic labels Jul 1, 2019
@ripla
Copy link
Contributor Author

ripla commented Jul 4, 2019

Initial design from @anssit
Screenshot 2019-07-04 at 8 25 30

@jouni
Copy link
Member

jouni commented Jul 4, 2019

Has there already been a discussion about what presets to offer there?

The current ones in the mockup seem like a nice starting point. I might want to add “Form” there as well, as I would expect that to be one of Designer’s primary use cases? Also, would the header/footer/sidebar layouts utilize App Layout somehow, or would the plan be to create something custom? App Layout doesn’t have a footer.

@ripla
Copy link
Contributor Author

ripla commented Jul 4, 2019

The presets in the design are the initial suggestion, but we could have others as well. The idea is to offer shortcuts for layouting. We can use whatever we want for the contents, although a combination of VL+HL would play nicely to the upcoming drag'n'drop functionality.

@ripla ripla added this to the Designer Q3 / 1 milestone Jul 5, 2019
@jouni
Copy link
Member

jouni commented Jul 8, 2019

I didn’t have any improvements ideas for this at this point. Just some minor visual design things.

Frame 2

Hover and drag over styles. I’m not certain similar styles are in use in the app at the moment (using the blue color for interaction cues), so be critical about that. If it seems to stick out, let’s find something that is more aligned with the existing visuals.

Frame 2 1

Figma: https://www.figma.com/file/X7eKoiF0T7Jp36BGOqlPHupC/Designer-Select-View-Layout?node-id=44%3A2

@tanbt tanbt self-assigned this Aug 6, 2019
@szolo szolo self-assigned this Aug 7, 2019
@szolo
Copy link
Contributor

szolo commented Aug 21, 2019

Hello, I implemented some snippets and would like to receive the feedback:

Vertical:

<vaadin-vertical-layout class="content" style="width: 100%; height: 100%; background-color: var(--lumo-contrast-10pct)">
</vaadin-vertical-layout>

vertical

Horizontal:

<vaadin-horizontal-layout class="content" style="width: 100%; height: 100%; background-color: var(--lumo-contrast-10pct)">
</vaadin-horizontal-layout>

horizontal

Header & footer:

<vaadin-vertical-layout style="width: 100%; height: 100%;">
    <vaadin-horizontal-layout class="header" style="width: 100%; min-height: 50px; background-color: var(--lumo-contrast-50pct)"></vaadin-horizontal-layout>
    <vaadin-vertical-layout class="content" style="flex: 1; width: 100%; background-color: var(--lumo-contrast-10pct)"></vaadin-vertical-layout>
    <vaadin-horizontal-layout class="footer" style="width: 100%; min-height: 50px; background-color: var(--lumo-contrast-50pct)"></vaadin-horizontal-layout>
</vaadin-vertical-layout>

header_footer

Sidebar:

<vaadin-horizontal-layout style="width: 100%; height: 100%;">
    <vaadin-vertical-layout class="sidebar" style="width: 100px; background-color: var(--lumo-contrast-30pct)"></vaadin-vertical-layout>
    <vaadin-vertical-layout class="content" style="flex: 1; background-color: var(--lumo-contrast-10pct)"></vaadin-vertical-layout>
</vaadin-horizontal-layout>

sidebar

Header & footer and sidebar:

<vaadin-vertical-layout style="width: 100%; height: 100%;">
    <vaadin-horizontal-layout class="header" style="width: 100%; min-height: 50px; background-color: var(--lumo-contrast-50pct)"></vaadin-horizontal-layout>
        <vaadin-horizontal-layout style="width: 100%; height: 100%;">
            <vaadin-vertical-layout class="sidebar" style="width: 100px; background-color: var(--lumo-contrast-30pct)"></vaadin-vertical-layout>
            <vaadin-vertical-layout class="content" style="flex: 1; background-color: var(--lumo-contrast-10pct)"></vaadin-vertical-layout>
        </vaadin-horizontal-layout>
    <vaadin-horizontal-layout class="footer" style="width: 100%; min-height: 50px; background-color: var(--lumo-contrast-50pct)"></vaadin-horizontal-layout>
</vaadin-vertical-layout>

header_footer_sidebar

@jouni
Copy link
Member

jouni commented Aug 21, 2019

Make sure we have enough contrast for the content users will most likely place in the layout.

As a rule, the body text color in Lumo should be sufficient on top of contrast-20pct, but not the darker ones. White (primary-contrast perhaps) could be used after contrast-70pct). The shades in between should be avoided as background color.

Is the reason for setting the background color for vertical and horizontal layouts to give a stronger indication that something happened? Or is it to show an example how to add inline styles in general? My intuition said I would avoid setting the bg color in those simple cases.

Why class="content" in those simple cases?

Make sure you use flex: 1; vs flex: auto; on purpose. The former sets flex-basis: 0; and the latter keeps flex-basis: auto;.

Same with flex: 0; vs flex: none;, which should be used for the header and footer parts IMO.

Should we use Lumo size properties instead of fixed pixel sizes for the widths/heights?

@szolo
Copy link
Contributor

szolo commented Aug 21, 2019

@jouni

As a rule, the body text color in Lumo should be sufficient on top of contrast-20pct, but not the darker ones.

I'll check how it will look like and use contrast-20pct if everything will be ok.

Is the reason for setting the background color for vertical and horizontal layouts to give a stronger indication that something happened?

Yes, it's for the purpose of the stronger indication. There is no guarantee that user will continue with our background colors. But at least at the starting point user will see how the structure looks like.

Why class="content" in those simple cases?

What do you mean? I can remove it, but its more explicit.

Make sure you use flex: 1; vs flex: auto; on purpose. The former sets flex-basis: 0; and the latter keeps flex-basis: auto;.

Yep, I tested it. Behaves like it should. Thanks for pointing on this.

Same with flex: 0; vs flex: none;, which should be used for the header and footer parts IMO.

Will do.

Should we use Lumo size properties instead of fixed pixel sizes for the widths/heights?

Yeah, why not. Any recommendations?

@jouni
Copy link
Member

jouni commented Aug 21, 2019

I'll check how it will look like and use contrast-20pct if everything will be ok.

Note, that this only applies for one layer of that color. As it’s semi-transparent, once you start stacking more layouts with this background color, the contrast (for body text) will go below requirements. Therefore, I would suggest first trying with contrast-5pct which can be stacked more times.

@jouni
Copy link
Member

jouni commented Aug 21, 2019

With class="content" I mean that it seems unnecessary when it’s just one layout that you are adding, just one container, where “content” obviously will be added. When there are nested “parts” like header and footer, then it makes sense to label the “content” layout.

That said, it’s your decision.

@jouni
Copy link
Member

jouni commented Aug 21, 2019

Should we use Lumo size properties instead of fixed pixel sizes for the widths/heights?

Yeah, why not. Any recommendations?

Not really. Again, I think I can leave the decision to you.

@szolo
Copy link
Contributor

szolo commented Aug 26, 2019

@tanbt

  1. Verify visuals with Jouni.
  2. Add analytics for the snippets usage.
  3. Add snippet for the form layout.

@tanbt
Copy link
Contributor

tanbt commented Aug 26, 2019

Talked to Jouni, we agreed to remove Form template for now until Jouni comes up with more detail use-cases.

The starting page looks bad in mobile size, I'll try these two solutions in order:

  • putting layout templates into a scrollable area (as we may have more templates in the future)
  • replace the dropping area with a text or drop a snippet anywhere in this page to continue.

@jouni
Copy link
Member

jouni commented Aug 26, 2019

until Jouni comes up with more detail use-cases.

Small correction: until we have a better understanding how to help in creating forms with Designer 🤗

@tanbt
Copy link
Contributor

tanbt commented Aug 27, 2019

@jouni So this is how scrollable area looks like:
image

Styling:

    .layout-wrapper {
      display: flex;
      flex-wrap: wrap;
      justify-content: center;
      overflow-y: auto;
    }
    .layout-wrapper::-webkit-scrollbar {
      width: 10px;
    }
    .layout-wrapper::-webkit-scrollbar-track{
      -webkit-box-shadow: inset 0 0 6px rgba(0,0,0,0.3);
      background-color: rgba(0, 0, 0, 0.1);
    }
    .layout-wrapper::-webkit-scrollbar-thumb{
      border-radius: 10px;
      -webkit-box-shadow: inset 0 0 6px rgba(0,0,0,.3);
      background-color: rgba(0, 0, 0, 0.3);
    }

You can check it by yourself via the repo
https://github.com/vaadin/vaadin-designer-layout-picker/tree/add-layout-picker
Run it by npm i then polymer serve --npm then access http://127.0.0.1:8081/components/@vaadin/vaadin-designer-layout-picker/demo/.

@szolo szolo assigned anssit and unassigned szolo Sep 3, 2019
@szolo szolo modified the milestones: Designer Q3 / 1, 4.3.5 Sep 5, 2019
@szolo szolo modified the milestones: 4.3.5, Designer Q3 / 1 Sep 5, 2019
@szolo szolo closed this as completed Sep 5, 2019
@ripla ripla removed this from the Designer Q3 / 1 milestone Sep 5, 2019
@szolo szolo added this to the 4.3.5 milestone Sep 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants