Design in the browser
For progressive visual development, you can not just implement a couple of top three chips. It is necessary to radically change consciousness and fundamentally change the approach. I will not break the process into battered hack stages. I will describe more fresh. The two main components of the aggressively new approach are: “Design in the Browser” and “Automation of the front end”.
Let's start with the first - “design”. There is a problem in relation to design as a static .psd. It feels like it should have lost its relevance at the moment when the adaptive appeared, the dynamics were added, and refinement to the live layout became a common thing. Theoretically, the death of static .psd-nis came along with the departure of tabular layout. Why try to revive what served? Then it was relevant, because in fact the layout image was piled on the table, only in a chopped form. Now the layout serves as a guide. In most cases, we do not cut a single 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 behavior that the “designers” have identified by eye in an instrument that is extremely distant from the web is stupid and unwise. The layout that came out from the designer’s screen may change on the way to the coder. And you will receive a huge number of comments and suggestions that can not be reflected in the picture. An alternative approach is to develop the design directly in the native environment, that is, in the browser. It can be seen how rapidly such an approach is gaining popularity.
The guys at the St. Petersburg WSD quite clearly showed their live prototypes of financial applications.
')
Literally at the beginning of the month there was an excellent report by Anton Vinogradov ( @awinogradov ) from Alfa Lab on BEMup , where he literally in a few minutes promptly sketched the layout of the Yandex.taxi application.
And of course, we are waiting for a bunch of domestic products from Lego + SourceJS Odnoklassniki guys . As far as I understood from a small demo in a screencast by Robert ( @operatino ), the interface will be assembled from prepared, laid out and documented blocks. In the meantime, you can restore order using the layout documentation for SourceJS . A useful habit that pays off in full.
And, of course, a report by Ilya Pukhalsky ( @pukhalski ) Rest in PS . Very nice 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 quite enough to understand the superiority of this approach. It remains to try, and it is unlikely that you will return back to the old “cave craft” of expelling .psd.
Developing web design in tools for it is not intended - a desperate and dead-end approach. If we reject the dribbling euphoria, I do not know how specifically I can call the designers of those who are considered to be such in not quite noticeable agencies. These are, as a rule, “characters”, on which unbearable duties are dumped. In general, they draw the whole look, not always based on logic, and the team blindly believes in the word. Often they climb not into their area, trying to refute the usual behavior. But at the same time the coder should send them a mock-up, which they intently inspect and say edits. The most absurd that in comparison take the .psd file as a standard. Which often contradicts sound logic. Stupid situation, isn't it?
Observing throwing designers between writing "bikes" for stubborn pseudo-design solutions and the need to please testers, it is great spurs me to incorporate logic into the process. With which the team can work on one result, and not destroy the project in favor of their ambitions.
It confuses a huge number of different tools that are used for the visual part: Axure, Sketch, Photoshop and a few lesser-known things already for an amateur.
With animation, things are much sadder. Here we are not talking about binding to the environment at all. Above the animation are perverted in the editors for the video, or they fig a few pictures to glue in .gif. But in the end, everything corresponds to HTML / CSS. Is it not a labor-intensive process with smeared intermediate stages ?!
The transition to a single development environment will qualitatively pump creative guys, add additional logic in the structure and provide a serious, more detailed understanding of what they are doing. Will open additional opportunities, both in animation, and in rubber. It will be a real product that can be reused and modified as needed. And not just another stupidity, made by short-sighted "artists" with blurred consciousness and completely atrophied logical thinking.
There is an option to do everything pretty painless. For this, it is worth discarding the cliché in the form of "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 are: headings, h1 h2 h3, paragraphs, links, lists, tables, digging, input, selects, etc. We can add basic styles to a basic CSS file. He will always lie in our starting whale.
Usually it is 20-30 marked main blocks. C which can be easily started. In the future, adding to the library, making it larger and more convenient. Storming every new project with such an arsenal will be more pleasant. For example, it may be a registration / authorization form, comments, and other blocks that are often found in your projects. All of them are carefully documented, making it easy to reuse and modify them.
We do:
Take into account the supported devices and media queries. The emphasis is on thinking through the basic foundation. For those who like to adapt, this will be as useful as possible, since there is an opportunity to focus on the frame, this will give greater meaningfulness. As an option, think over a high-quality grid (perhaps, take a ready-made solution and modify it as necessary).
There is no need to think much over the development. We simply integrate pre-prepared modules (stage 2) into our framework (stage 3). It is enough to make a couple of small dopils and admire the result. So to say, feel all the magic of the modular approach.
It is clear that to start changing the usual system as a whole is either scary or broke. But there are lots of guys promoting and enjoying the methodology. Mass is the force that pushes forward. So I will quote one designer: "well in the sect." And less statics to you.
Let's start with the first - “design”. There is a problem in relation to design as a static .psd. It feels like it should have lost its relevance at the moment when the adaptive appeared, the dynamics were added, and refinement to the live layout became a common thing. Theoretically, the death of static .psd-nis came along with the departure of tabular layout. Why try to revive what served? Then it was relevant, because in fact the layout image was piled on the table, only in a chopped form. Now the layout serves as a guide. In most cases, we do not cut a single pixel. And just keep the layout open in the next window. In order to write all this "beauty" code.
The design is changing
Today, getting a picture with a huge description of behavior that the “designers” have identified by eye in an instrument that is extremely distant from the web is stupid and unwise. The layout that came out from the designer’s screen may change on the way to the coder. And you will receive a huge number of comments and suggestions that can not be reflected in the picture. An alternative approach is to develop the design directly in the native environment, that is, in the browser. It can be seen how rapidly such an approach is gaining popularity.
Who uses a progressive approach?
The guys at the St. Petersburg WSD quite clearly showed their live prototypes of financial applications.
')
Literally at the beginning of the month there was an excellent report by Anton Vinogradov ( @awinogradov ) from Alfa Lab on BEMup , where he literally in a few minutes promptly sketched the layout of the Yandex.taxi application.
And of course, we are waiting for a bunch of domestic products from Lego + SourceJS Odnoklassniki guys . As far as I understood from a small demo in a screencast by Robert ( @operatino ), the interface will be assembled from prepared, laid out and documented blocks. In the meantime, you can restore order using the layout documentation for SourceJS . A useful habit that pays off in full.
And, of course, a report by Ilya Pukhalsky ( @pukhalski ) Rest in PS . Very nice 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 quite enough to understand the superiority of this approach. It remains to try, and it is unlikely that you will return back to the old “cave craft” of expelling .psd.
Transition to the “right” environment
Developing web design in tools for it is not intended - a desperate and dead-end approach. If we reject the dribbling euphoria, I do not know how specifically I can call the designers of those who are considered to be such in not quite noticeable agencies. These are, as a rule, “characters”, on which unbearable duties are dumped. In general, they draw the whole look, not always based on logic, and the team blindly believes in the word. Often they climb not into their area, trying to refute the usual behavior. But at the same time the coder should send them a mock-up, which they intently inspect and say edits. The most absurd that in comparison take the .psd file as a standard. Which often contradicts sound logic. Stupid situation, isn't it?
Observing throwing designers between writing "bikes" for stubborn pseudo-design solutions and the need to please testers, it is great spurs me to incorporate logic into the process. With which the team can work on one result, and not destroy the project in favor of their ambitions.
It confuses a huge number of different tools that are used for the visual part: Axure, Sketch, Photoshop and a few lesser-known things already for an amateur.
With animation, things are much sadder. Here we are not talking about binding to the environment at all. Above the animation are perverted in the editors for the video, or they fig a few pictures to glue in .gif. But in the end, everything corresponds to HTML / CSS. Is it not a labor-intensive process with smeared intermediate stages ?!
The transition to a single development environment will qualitatively pump creative guys, add additional logic in the structure and provide a serious, more detailed understanding of what they are doing. Will open additional opportunities, both in animation, and in rubber. It will be a real product that can be reused and modified as needed. And not just another stupidity, made by short-sighted "artists" with blurred consciousness and completely atrophied logical thinking.
How to implement
There is an option to do everything pretty painless. For this, it is worth discarding the cliché in the form of "designer - designer, ..., layout designer". And use the strong skills of team members. The basic steps are as follows:
1. Development of common guides
The basic elements that need to be styled are: headings, h1 h2 h3, paragraphs, links, lists, tables, digging, input, selects, etc. We can add basic styles to a basic CSS file. He will always lie in our starting whale.
2. Logical independent blocks
Usually it is 20-30 marked main blocks. C which can be easily started. In the future, adding to the library, making it larger and more convenient. Storming every new project with such an arsenal will be more pleasant. For example, it may be a registration / authorization form, comments, and other blocks that are often found in your projects. All of them are carefully documented, making it easy to reuse and modify them.
We do:
- sketch layout of the block structure;
- general stylization, taking into account guides (stage 1);
- different states and animations.
3. The very structure of the grid
Take into account the supported devices and media queries. The emphasis is on thinking through the basic foundation. For those who like to adapt, this will be as useful as possible, since there is an opportunity to focus on the frame, this will give greater meaningfulness. As an option, think over a high-quality grid (perhaps, take a ready-made solution and modify it as necessary).
4. Integration
There is no need to think much over the development. We simply integrate pre-prepared modules (stage 2) into our framework (stage 3). It is enough to make a couple of small dopils and admire the result. So to say, feel all the magic of the modular approach.
Fanatics push the idea
It is clear that to start changing the usual system as a whole is either scary or broke. But there are lots of guys promoting and enjoying the methodology. Mass is the force that pushes forward. So I will quote one designer: "well in the sect." And less statics to you.
Source: https://habr.com/ru/post/238485/
All Articles