Top 10 Things We Understand When Working With Foundation for Apps

Most recently, we launched Foundation for Apps . It was great to receive feedback and suggestions from you about our latest framework!

During this short time, we have already learned a lot. Here are the first 10 things that seem important to us:

1. Flexbox is great, but hard

We started building our framework using Flexbox instead of the traditional float mesh. This allowed us to more accurately perform some things like mixing fixed and fluid width, significantly improve the source code, and reorient the grid. We realized that the Flexbox is just great, and it also has support for many different browsers . I had to understand all its subtleties, make it available for different software, but we just got a great grid!

2. People love ASCII art.

By and large, people very warmly received our ASCII-yeti, displayed when installing the framework. We tried many of its variations of ASCII but chose the simplest of them, since it is cool.
')

3. It's hard to give names

No, its true. Four years ago, when we created Foundation for Sites, the whole grid had simple and clear names for each of its elements. When we began to redo the structure and move to a vertical grid, many of these names lost their meaning (for example, columns and lines). Some ideas like 'group' and 'block' seemed too abstract to us, but, nevertheless, they became the basis for some CMS. All agreed to name everything in the format: grid- <name of what was used>. Grid-block was used to create templates, and grid-content was used for application content.

4. Namespace - even more complicated

Using Angular, we began to divide the code into separate libraries, for example, to create pop-up windows and messages. In order not to get confused, it is necessary to give all files the same prefixes. The first idea was to use ' fa- ', but then many told us that they use Famo.us or Font Awesome, whose file names begin with FA. So, we chose a particle zf- , which also coincided with the Zend Framework, but they did not use one.

5. There are no specific responsive models in the applications.

ZURB has been creating responsive templates for five years, but I have never dealt with this type of frameworks. We created models on which web applications could work. As it turned out, such applications do not have their own design language with some principles and norms. For us it became a kind of experiment, and, as we think, the experience was a success. Our developers managed to create separate elements and blocks of the web application, which change their sizes depending on the screen size of the device. There are even items that change when scrolling and drop-down lists that perform certain actions when selecting items. We are still working on this “language”, expanding it and adapting all modern web standards to it.

6. Applications are not web applications.

Foundation for Apps was created as a web application framework from day one. I repeat: Foundation for Apps was created with WEB APPLICATIONS ! We wanted to create a responsive web application that would work in most web browsers.

7. Routing is hard

Angular is beautiful, but designers had a hard time coping with some things like pagination and other links that require route knowledge. We created the Gulp plugin that deals with these things, making life easier for the developer.
You write:

 --- name: home url: /home animationIn: bounceIn animationOut: bounceOut --- 

We read:

 var routerApp = angular.module('routerApp', ['ui.router']); routerApp.config(function($stateProvider, $urlRouterProvider) { $urlRouterProvider.otherwise('/home'); $stateProvider .state('home', { url: '/url', templateUrl: 'partial-home.html', controller: 'PageController', //default controller data: { vars: { name: home, url: /home, animationIn: bounceIn, animationOut: bounceOut }} }); }); 

8. All components are simply displayed and hidden.

We concluded that all JS components simply appear and disappear on the page during the creation of Foundation for Apps. Developers have made an API that displays the right elements with a simple syntax like open , close or toggle , interacting with objects through their IDs.

9. Height - a second-class citizen

Many people who have used percentages at least once to indicate the element heights should have been very surprised. If you specify a height of 100%, then little will change. We wanted to create web applications running in full screen, which made use of VH (viewport height).

10. New Yeti

When we wanted to create a brother for our Yeti, we turned to a wonderful illustrator . Adam created a rather similar image of the Yeti, but slightly different from the first one.

These are just a few of what we have understood for the moment. The web will evolve rapidly, and Zurb Family is not going to fall behind.