Overload of contents tends to slow down most animation

[wellingguzman]

I don't now you guys but when I test some effects on the site if I am on "home" page, everything is slow because of the overload of contents, but if I am on a specify page everything run smoother.

[benfields]

@WellingGuzman I have had this problem too, especially when trying to look at the animations on a mobile device.

[grayghostvisuals]

Sounds like it may be that time to have a main index that leads to these singles currently being created instead of jamming it all on one page. Just a thought here.

[wellingguzman]

@benfields that too, but some element on demo.scss need to be adaptive to mobile device as well, maybe this isn't helping some animations on mobile.

@grayghostvisuals same thought here.

[grayghostvisuals]

@WellingGuzman How would you see this laid out? Thinking index.html contains small boxes for each effect category containing links to each of these individual examples :\ Not rocket science I know. :dancers:

[grayghostvisuals]

@jonschlinkert Is it possible to restructure Assemble with this project to accomplish what we're thinking above?

[doowb]

@grayghostvisuals are you looking to just show the list of links to the other demo pages that are created? That would be pretty simple to do with assemble, and it would remove the requirement of loading the pages as partials. I can take a shot at it if you have an example of what the html for the links should look like.

[jonschlinkert]

If I understand correctly, yes... this would be pretty easy.

But to re-cap, it sounds like you're just looking for a way to:

• build each component to a separate page?
• automatically add a link to each component on an index page?

how about also building all of the components to a single page (as it is currently)?

[jonschlinkert]

lol

[wellingguzman]

@grayghostvisuals haha I forgot to tell you how would I laid this out. well basically what you said, use the main page as an Index with bunch of links to an specific animation collection.

@jonschlinkert I think what he is trying to ask is:

automatically add a link to each component on an index page?

If is not, is what I am trying to looking for as well. :smile:

[wellingguzman]

I know you can just puts links on a page to direct you to another specific page and all pages will be build it anyways.

[chriscoyier]

if this turns into a discussion about structure, on the list is getting rid of that /dist/ directory that we really don't need anymore.

[grayghostvisuals]

Everything you guys said above is correct and also +1 to what Chris just stated.

I'm voting Yes To all this!

build each component to a separate page? automatically add a link to each component on an index page?

Each category has a header of what that category is and inside a box are the links to each individual items.

<section class="effeckt-category">
    <header>
        <h1>Modals</h1>
    </header>
    <div class="effeckt__category-box">
        <ul>
            <li><a href="YougotaURI">...links yo!</a></li>
            <li><a href="YougotaURI">...links yo!</a></li>
        </ul>
    </div>
</section>

Thinking layout is a 3,2,1 column structure possibly using Harry Roberts Grid System.

[doowb]

So each page right now is a category and you'd like to see each example in a category have it's own page?

Removing the /dist folder is easy too. I'm assuming that you'd like the css and js files to stay at the root also, so we can remove the copy task.

@jonschlinkert care if I work on this, or do you want to do it? I don't want to step on each other.

[andymcfee]

Just as another argument for separating the sections into separate pages: Some of these effects - modals and page transitions come to mind - require some global-ish markup like wrappers and hidden divs that make tracking down the relevant markup a bit of a pain when everything is on a single page.

If each section were on it's own page, or at least some sections on their own page, then it would be easier to say "ok, this is how page transitions are working because this is all the markup for a page transition" or whatever the effect. Or "effeckt" I guess.

Is this relevant? I feel like it's relevant. If not, let me know and I'll go make a new thread.

[jonschlinkert]

@doowb go for it, it's all you!

[grayghostvisuals]

@doowb Don't know how everyone feels about this, but what @andymcfee just said above is so spot on it ain't even funny yo. Keeping things quarantined is way cool (css, js etc.).

[grayghostvisuals]

@doowb @jonschlinkert Thanks for the help as always you guys :heart_eyes:

[jonschlinkert]

No problem at all! we love doing this stuff! and @doowb does amazing work, so that keeps it fun. speaking of which, if you're going to make some changes, might as well try to come up with other stuff related to this that you'd like to improve in the project

[doowb]

@grayghostvisuals I think what @andymcfee said is exactly why we built assemble in the first place. @jonschlinkert and I discussed this a little and we'll be working together on it. We're shooting to have a PR this weekend, so as @jonschlinkert said, let us know if there's anything else you'd like to see in the demo pages.

[grayghostvisuals]

Awesome sauce gentlemen! @chriscoyier any requests besides dist directory? @WellingGuzman notes? @paulirish? Bueller?

[paulirish]

If what we're trying to fix here is just a perf issue when it comes to a heavy page.. It would be better to solve it by removing elements from the render tree.

I think keeping things on the same page provides a better UX for people browsing the library than separate pages.. But we can do things to improve the perf.

display:none removes items from the render tree and kills any GPU layers associated, so if something is hidden, it shouldn't affect the rest of the page.

How about a simple landing view with navigation.. And then navigating with #anchors and using :target to show effect demo categories one by one? Should solve the perf issue. And seems better, UX-wise. Ya?

[chriscoyier]

Sounds good to me. (display: none; ing stuff)

Here's what I think would be a sweet directory structure

• Effeckt
  • .editorconfig
  • .gitignore
  • index.html
  • Gruntfile.js
  • License.md
  • package.json
  • readme.md
  • js
  • demo
  • libs
  • modules
  • styles
  • css
    • demo
    • modules
    • each-individual-effect.css
  • scss
    • _variables.scss - REMOVE, put relevant variables in individual effects
    • effeckt.scss - REMOVE, no need to create squished version, demo can load each individually
    • demo
    • modules
    • each-individual-effect.scss
  • src
  • REMOVE mid-level "templates" folder
  • layouts
  • pages
  • parts - rename "layout-parts" so it's more clear

[wellingguzman]

This is awesome :+1:

display: none; seems like an great choice to me too.

How about a simple landing view with navigation.. And then navigating with #anchors and using :target to show effect demo categories one by one?

This is what I think would be a cool implementation but this can be done, instead of "insert" each section on the main page, just put a link which send us to a category.

@chriscoyier just my thought about the directory tree, I wonder if each individual effect is an type of an animation, e.g. modal-slide, modal-fade, I believe it would be more organized if it's included in a directory that grouped it by module BUT if it's not what i thought it ok.

aside from that Cool! :+1:

[grayghostvisuals]

Last breath before things are finalized. I still agree with what @andymcfee stated. It is hard to find and decipher the relevant markup and correlating files for the examples. An issue that I've already raised https://github.com/h5bp/Effeckt.css/issues/187

However the dist directory still needs to be removed either way

[jonschlinkert]

just wanted to check in and let you know we're still happy to help once there is a decision on how you want to do this.

Just my 2c, but the patterns we use for markup and organizing the project should have little bearing on the user experience. You can use whatever component pattern or separation of concerns you want to make the project easier to manage and build that into the single page experience that @paulirish advises.

My suggestion is to separate this into two decisions:

• what is the pattern that we'd like to use to make the project easier to maintain. which should, by proxy, make the code easier for others to consume
• what is the user experience we want

I don't think we need to compromise on either of these things to achieve the other

[grayghostvisuals]

Dir structure has now changed and our interests need to be focused on how to actually package this and if we are gonna package this for authors at all.