September 29, 2014 at 11:45Design in the browser
For progressive visual development, you can’t just introduce a couple of three chips. It is necessary to radically change consciousness and fundamentally change the approach. I will not break the process into hackneyed hackneyed stages. I will describe it more freshly. The two main components of the aggressively new approach: “Design in the Browser” and “Automation of the front end”.
Let's start with the first - “design”. There is a problem regarding design as a static .psd. It felt like it should have lost its relevance at the moment when the adaptive appeared, dynamics were added and refinement to the living layout became commonplace. Theoretically, the death of static .psd-sheks occurred along with the departure of the table layout. Why try to revive what has served ?! Then it was relevant, since in fact the picture of the layout was smelling into the table, only in a cut form. Now the layout serves as a guide. In most cases, we don't crop a pixel. And just keep the layout open in the next window. In order to write all this "beauty" code.
Today, getting a picture with a huge description of the behavior that the "designers" have identified by eye in an instrument extremely remote from the web is silly and unreasonable. The layout that came out of the designer’s screen may change along the way to the layout designer. And you will receive a huge number of comments and suggestions that cannot be reflected in the picture. An alternative approach is to develop the design directly in the native environment, that is, in the browser. One can see how rapidly this approach is gaining popularity.
The guys at the St. Petersburg WSD amply demonstrated their living prototypes of financial applications.
Literally at the beginning of the month, there was an excellent report by Anton Vinogradov ( @awinogradov ) from Alpha Lab on BEMup , where he literally in a few minutes quickly drafted the layout of the Yandex.Taxi application.
Well and of course, we are waiting for a bunch of internal products of the guys from Odnoklassniki Lego + SourceJS . As far as I understood from a small demo in the screencast from Robert ( @operatino ), the interface will be assembled from prepared, imposed and documented blocks. In the meantime, you can clean up using the layout documentation on SourceJS. A good habit that pays off in full.
And, of course, a report by Ilya Pukhalsky ( @pukhalski ) Rest in PS . Very cool and clearly explained a similar topic.
This is the most noticeable thing I have seen lately. Plus a few points discussed in private conversations. These arguments and examples are enough to understand the superiority of this approach. It remains to try and it is unlikely that you will return to the old "cave craft" of yelling .psd.
Web design development in tools not intended for him is a desperate and dead-end approach. If we discard dribbling euphoria, I don’t know how specifically I can call the designers those who are considered to be such in not very noticeable agencies. These are, as a rule, "characters" on whom dumping excessive duties. In general, they paint the whole appearance, not always relying on logic, and the team blindly believes in the word. Often they do not climb into their area, trying to refute the usual behavior. But at the same time, the layout designer should send them a layout, which they carefully examine and say edits. The most absurd thing is that, in comparison, they take their .psd file. Which often runs counter to sound logic. Stupid situation, right?
Watching the coders throw between writing “bicycles” for hard-boiled pseudo-design decisions and the need to please testers, it really encourages me to introduce logic into the process. With which the team can work on one result, and not ruin the project in favor of their ambitions.
It confuses a huge number of motley tools that are used for the visual part: Axure, Sketch, Photoshop, and a few other lesser-known things that are already amateurish.
With animation, things are much sadder. Here we are not talking about binding to the environment. Above the animation, they are perverted in the editors for the video, or several pictures are shown to glue in .gif. But in the end, everything is rewritten in HTML / CSS. Is it a very laborious process with spread out intermediate steps ?!
The transition to a unified development environment will qualitatively pump creative guys, give additional logic to the structure and provide a serious, more detailed understanding of what they are doing. It will open additional opportunities, both in animation and in rubber. This will be a real product that can be reused and modified as needed. And not just another stupid thing done by shortsighted “artists” with blurred consciousness and completely atrophied logical thinking.
There is an option to do everything quite painlessly. To do this, discard the cliche in the form "designer - designer, ..., layout designer". And use the strong skills of team members. The basic steps are as follows:
The basic elements that need to be styled: headings, h1 h2 h3, paragraphs, links, lists, tables, digits, inputs, selects, etc. We can put the basic styles into a basic CSS file. He will always lie in our starting whale.
Usually these are 20-30 marked up main blocks. C which you can easily start. In the future, replenishing the library, making it more large-scale and convenient. Storming every new project with such an arsenal will be more pleasant. For example, it can be a registration / authorization form, comments and other blocks that are often found in your projects. All of them are carefully documented, which makes it easy to reuse and modify them.
We do:
We take into account supported devices and media queries. The emphasis is on thinking through the basic foundation. For fans of adaptive, this will be most useful, since there is the opportunity to focus on the frame, this will give more meaningfulness. As an option, think over a high-quality grid (perhaps take a ready-made solution and modify it if necessary).
There is no need to think a lot about development. We simply integrate pre-prepared modules (stage 2) into our framework (stage 3). It is enough to make a couple of small dopil and admire the result. Feel the magic of a modular approach, so to speak.
It is clear that starting changing the familiar system as a whole is either scary or breaking. But there are lots of guys who propagandize and enjoy the methodology. Mass is a force that pushes forward. So I will quote one designer: "Wellcome to the sect." And you have less statics.
Let's start with the first - “design”. There is a problem regarding design as a static .psd. It felt like it should have lost its relevance at the moment when the adaptive appeared, dynamics were added and refinement to the living layout became commonplace. Theoretically, the death of static .psd-sheks occurred along with the departure of the table layout. Why try to revive what has served ?! Then it was relevant, since in fact the picture of the layout was smelling into the table, only in a cut form. Now the layout serves as a guide. In most cases, we don't crop a pixel. And just keep the layout open in the next window. In order to write all this "beauty" code.
Design is changing
Today, getting a picture with a huge description of the behavior that the "designers" have identified by eye in an instrument extremely remote from the web is silly and unreasonable. The layout that came out of the designer’s screen may change along the way to the layout designer. And you will receive a huge number of comments and suggestions that cannot be reflected in the picture. An alternative approach is to develop the design directly in the native environment, that is, in the browser. One can see how rapidly this approach is gaining popularity.
Who uses a progressive approach?
The guys at the St. Petersburg WSD amply demonstrated their living prototypes of financial applications.
Literally at the beginning of the month, there was an excellent report by Anton Vinogradov ( @awinogradov ) from Alpha Lab on BEMup , where he literally in a few minutes quickly drafted the layout of the Yandex.Taxi application.
Well and of course, we are waiting for a bunch of internal products of the guys from Odnoklassniki Lego + SourceJS . As far as I understood from a small demo in the screencast from Robert ( @operatino ), the interface will be assembled from prepared, imposed and documented blocks. In the meantime, you can clean up using the layout documentation on SourceJS. A good habit that pays off in full.
And, of course, a report by Ilya Pukhalsky ( @pukhalski ) Rest in PS . Very cool and clearly explained a similar topic.
This is the most noticeable thing I have seen lately. Plus a few points discussed in private conversations. These arguments and examples are enough to understand the superiority of this approach. It remains to try and it is unlikely that you will return to the old "cave craft" of yelling .psd.
Transition to the “right” environment
Web design development in tools not intended for him is a desperate and dead-end approach. If we discard dribbling euphoria, I don’t know how specifically I can call the designers those who are considered to be such in not very noticeable agencies. These are, as a rule, "characters" on whom dumping excessive duties. In general, they paint the whole appearance, not always relying on logic, and the team blindly believes in the word. Often they do not climb into their area, trying to refute the usual behavior. But at the same time, the layout designer should send them a layout, which they carefully examine and say edits. The most absurd thing is that, in comparison, they take their .psd file. Which often runs counter to sound logic. Stupid situation, right?
Watching the coders throw between writing “bicycles” for hard-boiled pseudo-design decisions and the need to please testers, it really encourages me to introduce logic into the process. With which the team can work on one result, and not ruin the project in favor of their ambitions.
It confuses a huge number of motley tools that are used for the visual part: Axure, Sketch, Photoshop, and a few other lesser-known things that are already amateurish.
With animation, things are much sadder. Here we are not talking about binding to the environment. Above the animation, they are perverted in the editors for the video, or several pictures are shown to glue in .gif. But in the end, everything is rewritten in HTML / CSS. Is it a very laborious process with spread out intermediate steps ?!
The transition to a unified development environment will qualitatively pump creative guys, give additional logic to the structure and provide a serious, more detailed understanding of what they are doing. It will open additional opportunities, both in animation and in rubber. This will be a real product that can be reused and modified as needed. And not just another stupid thing done by shortsighted “artists” with blurred consciousness and completely atrophied logical thinking.
How to implement in work
There is an option to do everything quite painlessly. To do this, discard the cliche in the form "designer - designer, ..., layout designer". And use the strong skills of team members. The basic steps are as follows:
1. Development of general guides
The basic elements that need to be styled: headings, h1 h2 h3, paragraphs, links, lists, tables, digits, inputs, selects, etc. We can put the basic styles into a basic CSS file. He will always lie in our starting whale.
2. Logical independent blocks
Usually these are 20-30 marked up main blocks. C which you can easily start. In the future, replenishing the library, making it more large-scale and convenient. Storming every new project with such an arsenal will be more pleasant. For example, it can be a registration / authorization form, comments and other blocks that are often found in your projects. All of them are carefully documented, which makes it easy to reuse and modify them.
We do:
- a sketch of the layout of the block structure;
- general stylization, taking into account the guides (stage 1);
- different states and animations.
3. The grid structure itself
We take into account supported devices and media queries. The emphasis is on thinking through the basic foundation. For fans of adaptive, this will be most useful, since there is the opportunity to focus on the frame, this will give more meaningfulness. As an option, think over a high-quality grid (perhaps take a ready-made solution and modify it if necessary).
4. Integration
There is no need to think a lot about development. We simply integrate pre-prepared modules (stage 2) into our framework (stage 3). It is enough to make a couple of small dopil and admire the result. Feel the magic of a modular approach, so to speak.
Fanatics sell the idea
It is clear that starting changing the familiar system as a whole is either scary or breaking. But there are lots of guys who propagandize and enjoy the methodology. Mass is a force that pushes forward. So I will quote one designer: "Wellcome to the sect." And you have less statics.