Understanding the Web Interface Architecture
Good afternoon, colleagues.
Among the new releases of O'Reilly publishing house, our next book by Micah Godbolt, which, despite its small volume, can open a new page in the history of web development, attracted our attention.
UPDATE under the cut
')
UPDATE: They sent us a sample list of topics that are planned to be considered in this book. Among them are: working with Sass, writing documentation, templates library, testing (visual regression, modular, end-to-end), assembly management, continuous integration, deployment, justification for leadership, why such an architecture is needed
The web is evolving, and during this process, individual roles in the modern web development team are changing.
As each of these specialists improved and increased their professionalism, not only new roles but also new disciplines began to form on the Web.
About those who make decisions regarding content
At the very earliest stages of the development of the Web, a stratum of people formed who seemed to really believe that the lexical content of any particular page is just as important as its design, code, and even search engine optimization. Before they came on the scene, the content was considered such a problem that can be safely postponed until later. “Just hammer into the design of lorem ipsum and move on.” When the time comes, the client will replace this template with real, high-quality, inspired content, before the site goes to work. ”
These philanthropists gradually began to emphasize that the web is content, and the content requires sufficient time and due attention. The controversy did not subside, but sometimes such people were invited to meetings for early planning, sometimes they were consulted about SEO techniques or asked to develop a general tone and style for the entire site’s editorial strategy. The affair was moving, and although the struggle was difficult, and it was mostly lonely, the results can be proud of.
So each of these single warriors went their own way until that fateful day, when he met his brother in interests, and they both realized that they were not alone in this fight. The first friendly contact gradually acquired a whole network of dating. Finally, a large community of similar philologists was formed, who were increasingly promoting the idea that content is a valuable asset, and not just a filler.
We’ve passed dozens of years, and the struggle for content is far from over. But whenever a web designer is once again asked to “bungle something else” for the main page of the site, it seems again that everyone will hear his woeful cry. And so, one day on December 16, 2008, an article by Kristina Halvorson appeared on the main page of the blog “A List Apart”. In it, the author proclaimed that the selection of content requires a special strategy. Christina asked readers to “catch the torch” and “begin to treat content as a critical resource requiring strategic planning and a reasonable investment.” Those involved in the content strategy are encouraged to "Learn, Practice, Promote." So a new discipline was born on the Internet.
Mrs. Halvorson's article was not the first one where the need for a strategic approach to content was voiced, but it was how the meaning, spirit and purpose of the content strategy were described, and the requirements for a specialist in such work were outlined. The next morning, a whole cohort of web content workers realized that they had a name, a profession, and a common vocation. Such specialists appeared in the era in the era of blogs, podcasts and video conferences, and the reason for their relevance is that the content is really important.
Adaptive Web Appearance
At about the same time, a man in a black turtleneck appeared on the scene and simply turned over the general ideas of what a “device with Internet access” was. For the first time in the history of the Web, we were practically forced to admit that websites can be viewed not only on a 1024 x 768 pixel monitor, comfortably sitting in an office or home chair, and the content itself can be served not only via the voluminous broadband Internet channels. With the advent of the iPhone, a new era of the mobile Web has arrived, with a variety of screen resolution options, widely differing device capabilities, jumping connection speeds and rather chaotic input modes. We, the developers, could no longer guess who our user is and what are the properties of his gadget, from which he goes to our site.
In response to this shakeup, we tried several new solutions. We tried to implement scaling on the screen with the help of a gesture-pinch or double-click, almost without changing the site itself. In other situations, a custom agent string detector was implemented to redirect users of any mobile devices to "truncated" mobile-oriented versions of sites. Both of these solutions were not good enough.
On sites where scaling was done with a pinch gesture, there were difficulties with navigation, which means with making purchases, ordering services. Accordingly, the growth of mobile traffic meant growing losses. To create separate versions of sites specially adapted for working with mobile devices, it was necessary to recruit a separate development team, that is, to support two versions of sites at once.
Many mobile sites were gradually abandoned, they did not have time to update as quickly as the main version, or the feature set on the mobile site turned out to be so scanty that users had to put off the phone and turn on the computer if the site needed to do something more complicated. than navigate with the route or call. The situation required some kind of solution. At first, many believed that the iPhone was a passing whim, but it soon became apparent that the future of the Web was contained in these miniature personal devices.
Three years after the release of the iPhone, the web development community finally found the long-awaited solution to all these problems. On May 25, 2010, Ethan Marcott posted a long article on the “A List Apart” blog, which was simply called “Adaptive Web Design”. This article did not describe any new discipline, did not proclaim slogans, under which the naval web developers had to rally. Instead, “responsive web design” (abbreviated as “RWD”) described methods for creating a new generation of sites that could take into account the size of the screen on the user device and automatically fit into the existing viewing area. The author describes this process not as an innovative technology, but rather as a set of already existing tools and techniques.
Responsive web design is nothing more than a combination of the following features:
All of these features existed in browsers for years before the appearance of an article by Mr. Marcott. But this work on responsive web design, just like the article on content strategies, explained in an easy way how to combine all these tools and achieve a result that everyone desperately wanted.
How the concept of web interface architecture was born
I first thought about the concept of a web interface architecture in mid-2013. At that time I was developing a client interface on Drupal and from my own experience I knew all the troubles and sorrows that content strategy specialists have to face. The design of the interface (theme) has always been thought out already after the fact. It was a kind of makeup, applied to the finished markup after the designers and developers of the machine interface finished their work. Nothing so eloquently describes the challenges that we faced on the project, as the procedure for attracting employees to this project. The project was launched, then it was discussed its design, the functional elements were developed ... after which a frontend specialist was invited to the project in order to implement exactly the design that was lowered to us from above, to pull it onto any existing markup.
Having survived this process several times, I firmly remembered the hardships I had to endure in order to reassemble a theme from the mass of photoshop documents for mobile devices and PCs that could be applied to the Drupal div-brow. Discussing with friends Rails specialists all the problems that one has to face when designing the navigation panel of a site in Drupal, I confessed that they are not for everyone and have not exaggerated at all! As soon as the markup was ready, and the developer proceeded to the solution of another task, all that remained was to dream about somehow correcting the resulting combination of divs, lists, and links. Inevitably, one had to resort to ridiculous CSS-level tricks in the design, without even expecting that the default navigation marking could work in production.
For many years, the professionalism of a web interface developer has been judged by its ability to create such golemic design patterns. “I insert a pseudo-element into the 3rd nested div, take a background image from this sprite ...” is a brief description of our combat techniques that, frankly, were good for nothing. We just patched the holes, hoping only that the site could still be launched before it was finally buried under a huge technical debt.
I knew that such a website development process could not remain stable, since our tasks were constantly becoming more complex. Therefore, instead of working in the old-fashioned way, I decided to dream up how the project could have turned out if (paraphrasing Cristina) the development of web interfaces would turn into a “critical process requiring strategic planning and reasonable investments”. What if we could participate in the development of CSS frameworks, documentation tools, the build process, propose naming conventions, and even work at the markup level ?! I imagined what the project might look like if the development of the UX defined the structure of the machine interface, and not vice versa.
Would the revolution happen then? Would anyone pick up our torch with the words "Learn, Practice, Promote"? But before we could gather under a common banner, it was necessary to decide for the sake of which we were raising it. What are our requests? How are we going to achieve our goals? What will it be called?
What's in a name
Realizing that in my current company there is no special position for a person who would be engaged in such work, I began to look at vacancies, trying to find at least something similar. Having a little rummaged on different sites, I found out that the next step in the hierarchy after the senior developer is an architect. When I read the job description, my heart beat faster. Indeed, in the very early stages of the project, a special architect should be connected to it, who would discuss the client's needs in the context of a specific platform. What technology stack are we going to use? What content types will have to work with? How will content be created, stored and displayed on screen? I realized that with the participation of the architect, nothing will be created spontaneously, all elements will be woven into the global structure. Quickly enough, it was possible to convert the database and web server into the structure of Sass-directories, and a new profession was born - the architect of web interfaces.
So, having come up with a name, I began to adjust the job description, thinking about the benefits such a specialist would bring, how he would be able to influence the project if he were given the necessary opportunities. These thoughts resulted in a brief explanatory conversation about the architecture of web interfaces, held at the next annual corporate meeting. Then I sent a request for CSS Dev Conf, it was accepted, after which I had to briefly, for forty minutes, present my ideas in a specially prepared presentation.
My report “Raising a Banner for Front-End Architecture”, read to the full of new Orleans audience, has become a program document of web-interface developers, who can be said to have already fought at the forefront. I wanted to convey to them that they are not alone, that there are people who are ready to support and insure them. In addition, I spoke with project managers and sales specialists, describing to them the potential of a properly built front end and the benefits that such a practice could bring to the team and the customer. The only way to influence the projects was to work on the architecture at the very beginning of the project, that is, customers have to pay for these hours, and managers are ready to properly plan resources for this work.
Subsequently, I listened to a lot of stories from developers who finally understood who they are, what role they play in the organization. Many realized that they were working as architects of web interfaces, but they simply did not use this term before, while others felt themselves able to do this kind of work. I, being one of the founders of these changes, prefer not to look back. It doesn’t matter exactly what the position I’m working at is called, the main thing is that I’m the web interface architect.
Among the new releases of O'Reilly publishing house, our next book by Micah Godbolt, which, despite its small volume, can open a new page in the history of web development, attracted our attention.
UPDATE under the cut
')
UPDATE: They sent us a sample list of topics that are planned to be considered in this book. Among them are: working with Sass, writing documentation, templates library, testing (visual regression, modular, end-to-end), assembly management, continuous integration, deployment, justification for leadership, why such an architecture is needed
The web is evolving, and during this process, individual roles in the modern web development team are changing.
As each of these specialists improved and increased their professionalism, not only new roles but also new disciplines began to form on the Web.
About those who make decisions regarding content
At the very earliest stages of the development of the Web, a stratum of people formed who seemed to really believe that the lexical content of any particular page is just as important as its design, code, and even search engine optimization. Before they came on the scene, the content was considered such a problem that can be safely postponed until later. “Just hammer into the design of lorem ipsum and move on.” When the time comes, the client will replace this template with real, high-quality, inspired content, before the site goes to work. ”
These philanthropists gradually began to emphasize that the web is content, and the content requires sufficient time and due attention. The controversy did not subside, but sometimes such people were invited to meetings for early planning, sometimes they were consulted about SEO techniques or asked to develop a general tone and style for the entire site’s editorial strategy. The affair was moving, and although the struggle was difficult, and it was mostly lonely, the results can be proud of.
So each of these single warriors went their own way until that fateful day, when he met his brother in interests, and they both realized that they were not alone in this fight. The first friendly contact gradually acquired a whole network of dating. Finally, a large community of similar philologists was formed, who were increasingly promoting the idea that content is a valuable asset, and not just a filler.
We’ve passed dozens of years, and the struggle for content is far from over. But whenever a web designer is once again asked to “bungle something else” for the main page of the site, it seems again that everyone will hear his woeful cry. And so, one day on December 16, 2008, an article by Kristina Halvorson appeared on the main page of the blog “A List Apart”. In it, the author proclaimed that the selection of content requires a special strategy. Christina asked readers to “catch the torch” and “begin to treat content as a critical resource requiring strategic planning and a reasonable investment.” Those involved in the content strategy are encouraged to "Learn, Practice, Promote." So a new discipline was born on the Internet.
Mrs. Halvorson's article was not the first one where the need for a strategic approach to content was voiced, but it was how the meaning, spirit and purpose of the content strategy were described, and the requirements for a specialist in such work were outlined. The next morning, a whole cohort of web content workers realized that they had a name, a profession, and a common vocation. Such specialists appeared in the era in the era of blogs, podcasts and video conferences, and the reason for their relevance is that the content is really important.
Adaptive Web Appearance
At about the same time, a man in a black turtleneck appeared on the scene and simply turned over the general ideas of what a “device with Internet access” was. For the first time in the history of the Web, we were practically forced to admit that websites can be viewed not only on a 1024 x 768 pixel monitor, comfortably sitting in an office or home chair, and the content itself can be served not only via the voluminous broadband Internet channels. With the advent of the iPhone, a new era of the mobile Web has arrived, with a variety of screen resolution options, widely differing device capabilities, jumping connection speeds and rather chaotic input modes. We, the developers, could no longer guess who our user is and what are the properties of his gadget, from which he goes to our site.
In response to this shakeup, we tried several new solutions. We tried to implement scaling on the screen with the help of a gesture-pinch or double-click, almost without changing the site itself. In other situations, a custom agent string detector was implemented to redirect users of any mobile devices to "truncated" mobile-oriented versions of sites. Both of these solutions were not good enough.
On sites where scaling was done with a pinch gesture, there were difficulties with navigation, which means with making purchases, ordering services. Accordingly, the growth of mobile traffic meant growing losses. To create separate versions of sites specially adapted for working with mobile devices, it was necessary to recruit a separate development team, that is, to support two versions of sites at once.
Many mobile sites were gradually abandoned, they did not have time to update as quickly as the main version, or the feature set on the mobile site turned out to be so scanty that users had to put off the phone and turn on the computer if the site needed to do something more complicated. than navigate with the route or call. The situation required some kind of solution. At first, many believed that the iPhone was a passing whim, but it soon became apparent that the future of the Web was contained in these miniature personal devices.
Three years after the release of the iPhone, the web development community finally found the long-awaited solution to all these problems. On May 25, 2010, Ethan Marcott posted a long article on the “A List Apart” blog, which was simply called “Adaptive Web Design”. This article did not describe any new discipline, did not proclaim slogans, under which the naval web developers had to rally. Instead, “responsive web design” (abbreviated as “RWD”) described methods for creating a new generation of sites that could take into account the size of the screen on the user device and automatically fit into the existing viewing area. The author describes this process not as an innovative technology, but rather as a set of already existing tools and techniques.
Responsive web design is nothing more than a combination of the following features:
- Rubber mesh, the width of which is calculated in percent, and does not have rigidly defined dimensions in pixels.
- Flexible images that fill containers allocated for them 100% in width, and then scalable as the parameters of the viewing area change.
- Media queries - the ability to set different styles depending on the size of the viewing area. Now the page layout can be changed depending on the screen size.
All of these features existed in browsers for years before the appearance of an article by Mr. Marcott. But this work on responsive web design, just like the article on content strategies, explained in an easy way how to combine all these tools and achieve a result that everyone desperately wanted.
How the concept of web interface architecture was born
I first thought about the concept of a web interface architecture in mid-2013. At that time I was developing a client interface on Drupal and from my own experience I knew all the troubles and sorrows that content strategy specialists have to face. The design of the interface (theme) has always been thought out already after the fact. It was a kind of makeup, applied to the finished markup after the designers and developers of the machine interface finished their work. Nothing so eloquently describes the challenges that we faced on the project, as the procedure for attracting employees to this project. The project was launched, then it was discussed its design, the functional elements were developed ... after which a frontend specialist was invited to the project in order to implement exactly the design that was lowered to us from above, to pull it onto any existing markup.
Having survived this process several times, I firmly remembered the hardships I had to endure in order to reassemble a theme from the mass of photoshop documents for mobile devices and PCs that could be applied to the Drupal div-brow. Discussing with friends Rails specialists all the problems that one has to face when designing the navigation panel of a site in Drupal, I confessed that they are not for everyone and have not exaggerated at all! As soon as the markup was ready, and the developer proceeded to the solution of another task, all that remained was to dream about somehow correcting the resulting combination of divs, lists, and links. Inevitably, one had to resort to ridiculous CSS-level tricks in the design, without even expecting that the default navigation marking could work in production.
For many years, the professionalism of a web interface developer has been judged by its ability to create such golemic design patterns. “I insert a pseudo-element into the 3rd nested div, take a background image from this sprite ...” is a brief description of our combat techniques that, frankly, were good for nothing. We just patched the holes, hoping only that the site could still be launched before it was finally buried under a huge technical debt.
I knew that such a website development process could not remain stable, since our tasks were constantly becoming more complex. Therefore, instead of working in the old-fashioned way, I decided to dream up how the project could have turned out if (paraphrasing Cristina) the development of web interfaces would turn into a “critical process requiring strategic planning and reasonable investments”. What if we could participate in the development of CSS frameworks, documentation tools, the build process, propose naming conventions, and even work at the markup level ?! I imagined what the project might look like if the development of the UX defined the structure of the machine interface, and not vice versa.
Would the revolution happen then? Would anyone pick up our torch with the words "Learn, Practice, Promote"? But before we could gather under a common banner, it was necessary to decide for the sake of which we were raising it. What are our requests? How are we going to achieve our goals? What will it be called?
What's in a name
Realizing that in my current company there is no special position for a person who would be engaged in such work, I began to look at vacancies, trying to find at least something similar. Having a little rummaged on different sites, I found out that the next step in the hierarchy after the senior developer is an architect. When I read the job description, my heart beat faster. Indeed, in the very early stages of the project, a special architect should be connected to it, who would discuss the client's needs in the context of a specific platform. What technology stack are we going to use? What content types will have to work with? How will content be created, stored and displayed on screen? I realized that with the participation of the architect, nothing will be created spontaneously, all elements will be woven into the global structure. Quickly enough, it was possible to convert the database and web server into the structure of Sass-directories, and a new profession was born - the architect of web interfaces.
So, having come up with a name, I began to adjust the job description, thinking about the benefits such a specialist would bring, how he would be able to influence the project if he were given the necessary opportunities. These thoughts resulted in a brief explanatory conversation about the architecture of web interfaces, held at the next annual corporate meeting. Then I sent a request for CSS Dev Conf, it was accepted, after which I had to briefly, for forty minutes, present my ideas in a specially prepared presentation.
My report “Raising a Banner for Front-End Architecture”, read to the full of new Orleans audience, has become a program document of web-interface developers, who can be said to have already fought at the forefront. I wanted to convey to them that they are not alone, that there are people who are ready to support and insure them. In addition, I spoke with project managers and sales specialists, describing to them the potential of a properly built front end and the benefits that such a practice could bring to the team and the customer. The only way to influence the projects was to work on the architecture at the very beginning of the project, that is, customers have to pay for these hours, and managers are ready to properly plan resources for this work.
Subsequently, I listened to a lot of stories from developers who finally understood who they are, what role they play in the organization. Many realized that they were working as architects of web interfaces, but they simply did not use this term before, while others felt themselves able to do this kind of work. I, being one of the founders of these changes, prefer not to look back. It doesn’t matter exactly what the position I’m working at is called, the main thing is that I’m the web interface architect.
Source: https://habr.com/ru/post/260169/
All Articles