Not able to understand the relationship between MDL Layout and MDL Grid components - material-design-lite

From the MDL website:
Layout: "The MDL Layout component is a comprehensive approach to page layout that uses MDL development tenets, allows for efficient use of MDL components, and automatically adapts to different browsers, screen sizes, and devices."
Further ahead -
"Use of MDL layout principles simplifies the creation of scalable pages by providing reusable components and encourages consistency across environments by establishing recognisable visual elements, adhering to logical structural grids, and maintaining appropriate spacing across multiple platforms and screen sizes."
Grid: "The MDL Grid component is a simplified method for laying out content for multiple screen sizes."
So, from the above definition of Layout, it would seem that grid behaviour is included. Not able to understand how.
I could not find any examples that use an MDL Grid and Layout together.
So, are they somehow mutually exclusive? How are the two related? What are the best practices for using each, either together or one over the other?
Please help me understand. Thanks.

MDL Layout is the container that holds different components that are enclosed between the mdl-layout class and it's essentially the structure of the project. Imagine it as outer walls to a building.
MDL Grid is a 12 column grid system where you can specifically choose where to layout certain components on the page. These are enclosed in the mdl-grid, mdl-cell, mdl-cell--#-col classes. Imagine this as the furniture inside a building and deciding where to put it.
How they differ is that MDL Layout isn't really a layout tool so you can specify where a component goes. What it is is it provides you building blocks that you can implement to your project such as a nav bar, a drawer, footer, etc. What it means when it says:
"The MDL Layout component is a comprehensive approach to page layout
that uses MDL development tenets, allows for efficient use of MDL
components, and automatically adapts to different browsers, screen
sizes, and devices."
is that when viewing on different sized screens, it will adjust some components automatically without the hassle of creating media queries for different devices. An example would be the drawer will be hidden on a phone while the desktop would show it (if specified). Or only the desktop will have a nav/header bar while the phone won't. Or even the nav/header bar will be fixed on desktop/phone while the others will scroll with the screen.
MDL Grid, however, is a way to layout your other content on the page. You want to make two things side by side on the desktop and collapse when viewing it on a phone? MDL Grid does that. Want to show three photos side by side on the desktop and then collapse to show it on different rows when looking at it on a phone? MDL Grid does that. MDL Grid doesn't provide the prebuilt components. It's just merely a tool for specifying where to lay stuff out on the page. To find more information, look for the 12 grid system. It should shed some light on it.
The blog template provided on the getmdl.io page has both of them being used in conjuction with each together: http://www.getmdl.io/templates/blog/index.html

MDL Layout will dynamically shift what you create based upon the display width of your screen.
MDL Grid is allowing you to define what will be visible at all times by setting number of columns for different screen sizes.
Example, lets say you make a page that just displays
(1, 2, 3, 4)
Under MDL-Layout if the viewing device shrinks it might change this page to display as
(1, 2,
3, 4)
Under MDL-Grid if you went and wrote mdl-cell--4-col-phone with each number in its own column, no matter how small the view area became (1, 2, 3, 4) would always display inline even if its width became reduced to the point where it was unreadable as you've defined the viewing behaviour at that screen size.
Therefore, they are mutually exclusive as you're either allowing the MDL-layout component to decide what displays at different view widths or setting it yourself with MDL-Grid. That said, I wouldn't be surprised if they acted very similarly for class'
Disclaimer, I've never used MDL-Lite but have used angular-material and have been eyeing it for future projects.

Related

How to handle css modules changes in responsive design using ooccss and smacss

I am studying CSS best practices and methodologies like OOCSS and SMACSS to use in a medium scope project that uses Twitter Boostrap 3 and LESS. I'm starting to get a grasp of these methods but I have some trouble to find out how to handle responsive design and CSS modules relationship.
For example let say I have a button module with all different kind of buttons used in the project (color, shape, size). How could I make the button change depending of the device. The same button should be large in mobile and a normal in desktop.
Following OOCSS I should have 2 skin classes like btn--default and btn--large. But as the HTML is the same for each device I can't switch this class in the HTML. Also using a media query in the module's CSS that would change the size of the button depending of the device size doesn't seem a good idea as I would be coupling the module with this specific need (and what if I want a normal button in mobile later?).
As an other example, I have product section module that have different possible layouts (vertical / horizontal). What if I want to use the vertical layout in desktop and the horizontal in mobile. I'm facing exactly the same issue. I can easily create 2 different submodules (product--horiz, product-vert) but I can't change them.
I could use javascript to switch classes but it doesn't feel right and would break the design with JS disabled. You could tell me that maybe the design is not right if an element is changing so much from one device to another but it would be a real limitation to restrain this.
So what are your thoughts about this issue. Is there any generalised practice used to face it?
To use your example for buttons:
Mobile is also tablet and tablets come in a variety of viewport sizes that are just as large as desktop. Media queries are not detecting features, like touch, so making a media query is only for visual at that viewport size. It's best practice to use large buttons and large click areas for fat fingers for every device unless you do feature detection with js such as .touch .btn- {big styles}. I use a little script to put .no-touch and .touch on my html, but I don't bother making larger areas just for .touch. I make them for everything if at all possible.
Your base button style should be defined in the button module in your 'modules.scss'. Apply any styles here that will transcend across all buttons. Then handle the differences in your smacss 'states.scss' file (compiled last). You should have one 'button' section in your states file in which you handle media queries and unique classes that will alter the appearance of the button. Hope that helps, I can elaborate more if you need.

Famo.us - Is a Gridlayout always a Gridlayout?

I am trying to ‘look’ at my screen in a grid format so I can lay out content based on that grid.
This isn’t strictly a gridlayout like having loads of photos or items evenly split across a screen, but understanding more the sizes and locations I can add surfaces or views.
Grid layout http://www.pandafinity.com/Screen-Grid.jpg
The above image is how I want to view the screen – so I can layout various items, some will span the smaller grid cells, some will be smaller (inside the grid cell), and some will span over multiple grid cells.
How would I create this approach using Famo.us? Can I use the Gridlayout for this or is it best to get the screen dimensions and do some maths to look at alignment and origins?
Thanks again :)
Going to use https://github.com/IjzerenHein/famous-flex.
Next bit is taken from the Github page (Hope Hein doesn't mind) :)
"
Flexible, animated and plugable layout-controller for famo.us, which:
Smoothly animates renderables between layouts (using physics)
Makes it easy to layout renderables (without having to create lots of modifiers)
Is shipped with various commonly used layouts
Allows you to easily create custom layouts and layout-helpers
Is very good at creating responsive designs
"
I think its a great approach and helps you split the layout from the renderables.
J. Andrew Brassington made such a thing in Famo.us already, similar to Isotope or Masonry if you about know those. He might be one to contact: https://github.com/jabbrass

Resizable html report

We’ve been looking for reporting components, and we’re having difficulty a report designer that will render reports properly on both phones and computers. We want the report to display in the same way on different screen sizes (desktop and phone), or at the very least, display on both without clipping on the phone. Our thought is the easiest way to lay out such a report is for the report designer to specify table and column sizes as a percent of the width (sort of like HTML tables) rather than hardcoded pixel sizes. So when my page is resized, my report (and content elements) also gets resized, and it continues to fit.
We tried Telerik Reporting but unfortunately they don’t support this feature. They also don’t support the feature where report is resized when window is resized. The size you lay out is the size it is. They indicated they have something that will come out in beta soon, but have given us very few details. We tried the demo for Infragistics, and it seems to have the same limitations.
Is there anything else in the development space that will allow us to produce reports with more “fluid” layout, or in the very least, zoom in on the phone instead of clipping?
is twitter bootstrap an option? tb supports responsive design which will make easier to adapt your report to any device, you just will need to adapt your media queries
kendo ui supports responsive design you may take a look, if bootstrap is an overkill you should try a separate jquery UI or JS library that helps you out with a fluid layout
hope that helps

User Interface Layout Algorithms

I am developing a UI container to hold UI components that can be dragged and dropped on to the container and also move components around within the container. The components are of various sizes. I'm doing this in flex/actionscript but I guess this problem applies to any user interface. Are there any resources (books, etc) that have layout algorithms. Any pointers on this will be a great help.
The user can drag/drop items. But the items should rearrange themselves so that there is no overlap. E.g. if a there are two items right next to each other and the user drops a third item on top of them (in the middle) the first two items should move aside to make room for the third item. (Similar to examples.adobe.com/flex3/devnet/dashboard/main.html except the item size vary).
The source code for the dashboard layout works with the assumptions all the components are the same dimensions. What I'm looking for is a way to layout components of different sizes.
Thanks
We've done some work like this in the past for a customer. What you need is an implementation of collision detection algorithm. See this http://code.google.com/p/collisiondetectionkit/
Also here is an article on code project that has some layout utilities in C# that implements this which you could probably port : http://www.codeproject.com/Articles/23871/WPF-Diagram-Designer-Part-3. Also

Flex/AIR layout for presentation tool (resize logic, aspect ratios etc.)

I'm developing a presentation tool for AIR (to be used together with, or as a replacement to, PowerPoint) but I'm quite a newcomer to flex layouting.
As you can see from the image, the presenter can open various apps from the main window.
Each of these apps open up in new windows which have different visual characteristics; some use the main content area to show graphics, others bullet points. Most app windows have buttons and view stacks with embedded Flash assets (using s:SpriteVisualElement).
My questions are the following:
1a. When developing a PowerPoint-like presentation tool with Flex, which layout type (basic, vertical etc.) will provide most flexibility?
1b. How do I make sure no clipping occurs on various projector screens - which aspect ratio should I have in mind?
2a. How can I resize children sprites in the SpriteVisualElement container proportionally to the window resolution?
2b. And where do I place this resize logic - on each component (sprite) with resizeHandlers or in one resizeHandler / window?
Please use the comment thread if you want me to elaborate further. Thanks.
Since you're new to Flex, I strongly reading up on the Flex Component LifeCycle.
1a. When developing a PowerPoint-like presentation tool with
Flex, which layout type (basic,
vertical etc.) will provide most
flexibility?
The layout you choose will depend on what you want to display. I don't see layouts as "Flexible". They do their job and position their elements appropriately. I can easily envision using all types of layouts in such a complicated application, each for different purposes.
1b. How do I make sure no clipping occurs on various projector screens -
which aspect ratio should I have in
mind?
I'm not quite sure I understand what this question means, but I take it to mean you want to avoid the presence of scroll bars in your app. To do that, you'll have to develop layout code that sizes and positions your children so that they do not extend past the height and width of your available content space. In Flex 3 (Halo) architecture, this would be done by writing an updateDisplayList() method for your component. In the Flex 4 (Spark) architecture, this would probably be done by writing an updateDisplayList() method for your skin class.
2a. How can I resize children sprites in the SpriteVisualElement
container proportionally to the window
resolution?
I believe my above answer already addresses this.
2b. And where do I place this resize logic - on each component
(sprite) with resizeHandlers or in one
resizeHandler / window?
In a resize handler, I would most likely use invalidateSkinState and/or invalidateDisplayList. The resizing code would be in the skin and/or updateDisplayList.

Resources