22. The Building Blocks
Components are the smallest, discrete reusable
chunks of the user interface.
Containers are used to specify the arrangement and
interaction of components.
Pages correspond to a unique URL. They contain
one or more Screens and broker the interaction
between them.
Screens are a container for Regions and the expose
an API for Pages to hide and show them.
Regions are containers for components. They are
normally styled as columns, rows, and provide basic
structure for layout.
Intro, I’m Dan Imal, UX Dev at Toura. Thanks for coming out.\n\nI’m going to talk about the challenges we faced when developing a mobile app interface in HTML5, particularly UI problems, and some of the ways that Mulberry helps deal with them.\n\nI’m going to describe some of the high level concepts the Mulberry gives you, so you don’t have to think about low level stuff.\n\nHow many are designers who code? How many are coders who design?\n\n
We’ve tried to reduce repetitive, boring stuff to a minimum. \n\nFor UI development, you code > refresh > repeat\n\nOnce you learn a few concepts and conventions, you can be surprisingly productive with Mulberry. Helps with repetitive tasks.\n\nSolve nasty problems once.\nMake the computers do dumb stuff, so you can focus on interesting stuff.\n
\n
\n
Mulberry does a lot behind the scenes to handle this and more.\n\nBut to be honest, other UI frameworks do too\n
In a traditional web page, we generally don’t usually think about the viewport. \n\nWe use CSS3 flexible box model heavily to deal with this. Flex-box is weird, but we try to make normal.\n\nDeveloping maintainable applications with reusable parts is complicated. How do reuse code without creating a tangled mess of dependencies?\n
Application logic in JS & presentation logic in CSS\nThis vocabulary and set of abstractions let the application layer and presentation layer play nicely and remain decoupled\n\nWe don’t have a lot of abstractions for low level UI widgets like checkboxes. High level abstractions for high level problems \n
Before describing how mulberry solves these problems, I need to quickly tell you about one of the tools we use\n\nWho has used Sass? \nSass is a CSS preprocessor, which just means that this is output by the processor as CSS.\n\n- nested selector syntax\n - let’s you be more explicit about the intention of the code, that you’re specifying the display of a particular component\n- it has variables\n- mixins\n
Mixins let you reuse styles without forcing you to use a classname as a hook.\n\nWe give you a set of mixins that handle common mobile layout issues\n
Now that we can create rounded corners (or whatever) in a sane way, it’s not that interesting technically. \n\nThis a case where we can focus on making something look good instead of worrying about all the implementation details.\n\n\n
It’s less important to remember all those crazy hacks you had to do just to get simple things to work, and it becomes more important to structure of your application well.\n\nHow do you use all those new features in a reliable, reusable way? How do you write code that can be changed in a reliable way?\n\nIf you do a crazy hack, how can you keep it segregated in your codebase?\n\nHow do you craft your DOM so that your application code and presentational code are completely decoupled? \n\nThis is what mulberry helps with \n\nClear conventions and consistent DOM structure:\n- lets the application layer really not care about presentation\n- lets you scope your styles properly\n- gives the application layer and presentation layer a common vocabulary\n
Containers are the skeleton\nComponents are the meat.\n
This is the page I’m going to break down to describe the major concepts in a mulberry UI\n\nSHOW actual app in simulator. Demonstrate swiping, scrolling, switching screens\n
\n
The application layer takes that page definition and \nconstructs the dom in a consistent wat\nsets up / tears down event handlers\nkeeps scrollers working\ngives everything within the page an API for communicating with each other\n
Once we have a consistent dom structure, we have a clear way of scoping all of our styles accordingly\n\nThe application layer (JS) and the presentation layer (CSS) are talking the same language, so the application layer can easily communicate it’s intentions to the presentation layer, but leave the implementation details up to the presentation layer.\n\nWe provide some Sass mixins for handling those layout issues I talked about earlier\n\nWithin the component, that’s where almost anything goes\n\nThis makes maintainability much easier, because you always know where to look to know how something is being styled. It’s never styled using JS.\n
Point out header fading in on detail screen.\n\nThis is saying that you should apply this fade transition depending on whether the component is hidden.\n\nThe application is saying what it wants, and leaving it to the presentation layer to handle the rest.\n\nCSS3 gives you all kinds of crazy selectors to help style things based on application state.\n\nThis not yet in the framework. I’m working out the right abstraction and syntax, but this type of stuff will be coming. \n
\n
TODO: update text and image once I change url\n
Those are the basic concepts in a Mulberry user interface. We’ve only scratched the surface.\nThanks, hope it was helpful\nMulberry is open source and in constant development\n- love to hear feadback, ideas, feature requests, bug reports\n\nQuestions?\n
\n
TODO: explain Page Definitions\n
TODO: more stuff in bottom area to demonstrate scrolling.\nTODO: Remove sibling nav? or remove border explaining it because it’s wierd\n