Progressive enhancement + mobile first = responsive web design

5 months, 26 days and a few hours have passed since the first lines of the Futubra code have been committed to git. It took us so much time to assemble a team, conduct a series of studies, work out a concept and implement a project that would make people's lives more interesting.

Over the past six months, we have already encountered (and continue to face every day) with a variety of tasks and problems of a logical, interface, technical and organizational nature. We will share the experience of solving the most interesting of them in this blog.
')
I would like to devote the first post to the most important - the basic principles on which Futubra is built:

• progressive enhancement
• mobile first
• responsive web design

Futubra is a multimedia microblogging service, a public beta version of which we opened yesterday.

Creating Futubru, we, first of all, thought about people like you and me - active, interested in new technologies, mobile, eager to keep abreast of events that explore the world and are open to everything new. Such an audience has a pronounced need to live more interestingly and Futubra is created to satisfy this need. We are doing a project that we ourselves will be happy to use and which we can be proud of.

The first principle that we agreed to adhere to when creating the Futubra was ...

Progressive enhancement

This principle was formulated by Steven Champeon in 2003, and it consists in using a simple semantic html layout to represent all the content and functionality, and CSS and JS should be just a pleasant improvement in user interaction. In other words, your service must be complete and full-featured even with CSS and javascript disabled on the client side.

This principle is the opposite of the traditional principle of graceful degradation , when developers are guided by the most advanced browsers, and the correctness of the project in old browsers or not supporting any features is implemented according to the residual principle.

Motive

New models of mobile phones appear every day, the number of mobile platforms and browsers of various capacities in them is also constantly changing. In addition, recently there has been a tendency to embed browsers into devices that are still unknown, for example, on-board computers of cars or televisions.

We wanted Futubroy to be used from any device with a browser and Internet access, so we decided to adhere to the principle of progressive enhancement.

pros

• Guaranteed work of the project in any browser that supports html . Any functionality is first designed and implemented in the semantic html-code without CSS and JS, and only then styles and interactive interaction with JS are added to it.
• Ability to roll out new features and changes before . Since the most basic version of the functionality on bare html is quickly implemented first, without any Ajax and beautiful things, you can immediately roll out the project update for users and immediately start receiving feedback without waiting for JS.

Minuses

• Increasing the complexity of implementing a back-end . Most modern projects very actively use JS to improve user interaction: dynamically loading blocks, sending forms, displaying notifications without reloading pages, ... And all these functions need to be implemented for both the non-JS version and the full version. To avoid duplication of the template code and the backend, you have to come up with a coherent architectural solution.

Our experience

We were twice glad that we were applying progressive enhancement, and not graceful degradation.

First, when they defined the browser support policy. Layout under IE6 doesn’t give pleasure to any of the coders, and eats up a lot of extra time, and the tendencies of its use speak of almost complete demise . Therefore, we artificially turned off support for CSS and JS. Opening Futubru in IE6, you will see not the most beautiful, but fully functional service.

Then, when they realized that we did not have time to “zayaksit” everything, everything, but the basic version works completely (even if the page is reloaded, but it works).

The technical implementation of uniform templates for backend and frontend was hard for us, we changed the template engines several times and cannot say that we are completely satisfied with the current solution. But this is a topic for a separate article.

The second basic principle, which we agreed on "on the coast", became ...

Mobile first

This is an approach in which you start designing a service from a mobile version, and not from a version for large screens, as is done everywhere. You can read more about this approach on Luke Wroblewski’s blog or in his Mobile First book.

Motive

We did not have a question whether we should, in principle, make a mobile version of Futubra or not - we immediately relied on mobility for several reasons.

First, the explosive growth of the mobile Internet, which began a long time ago in the world, began to reach Russia. Already, almost 8% of all visitors in Runet go to websites from smartphones and tablets, which is more than 5 million devices (actually, more, because not all phones with opera mini / mobile are counted).

Secondly, the target audience of the project (18-45, active, progressive), which, in part, is the driver of the growth of the mobile Internet, stemmed from the basic need (I want to live more interestingly).

Thirdly, the very essence of the service implies the use of "on the go" - I saw something interesting on the way to work or study, sfotkal, post it. It’s boring, there’s nothing to do at the store, while the girl is trying on a dress — Futubra opened and read.

But even without the “big” web version, the project cannot exist, since social services users spend a good half of their time at home or at work.

We, as always, had a shortage of workers and time, so it was necessary to choose which version to start doing first. We decided to follow the concept of mobile first, i.e. start design and development with a mobile web version.

pros

• Focus on the most important thing . The small size of the screen, willy-nilly, makes you focus on the essence and leave only the most important thing in the project - there is simply no room for the secondary on the screen. The logic of the project began to be worked out in detail, the scarce space on the screen was used wisely and thriftly, and all “here let us clothe the little girl” went to the forest :)
• Full featured mobile version . Since we initially did only the mobile version, all the existing functionality of the service in it is there, and you will not have such a situation when you can do some action from a large web, but not from a mobile one.
• Mobile version can work well in the “big” web . Developing only the mobile version, we checked and used it mainly from our work computers and this did not cause rejection.

Minuses

• You will not immediately have a version for a large web . If you realize that you cannot do without a separate version for a large web, you will not get it soon. And if in your project the main bet is placed on the big web, and the launch dates are too tight, you can simply not have time to make two versions.
• The approach is difficult to apply for spreading portals with hundreds of entities . If you are developing Amazon, Ebay, or Yelp, designing with this approach can take a very long time and fail.

Our experience

The limited space helped us a lot to build the logic and not to allow anything extra in the project. We defined the minimum supported resolution — 240 pixels in width — and began to prototype:




And somehow, without even noticing it, we came to use ...

Responsive web design

The essence of this principle is that you make one version of your web project for all devices with any screen size, and make it so that it looks good both in a small window of a mobile phone and on a designer 27 'monitor.

Hellcunt has written about this principle well and in sufficient detail; you can also read a good book .

Motive

Over time, we realized that we didn’t need a separate version of Futubra for the “big” web - we were very accustomed to a super-focused and laconic design in one column and did not want to give it up. Therefore, we decided to simply develop our mobile version so that it works well on all devices.

pros

• One version of the site . One set of templates and controllers, which facilitates support and development, minimizes the likelihood of “underground knocks” in individual versions of the project.
• Continuity of the interface . On any device you will see a familiar and intuitive interface. Users will appreciate it.

Minuses

• One version of the site . One set of templates and controllers leads to the complication of logic inside the code - if you do not manage this complexity correctly, support and development will become a headache.
• Non-optimal use of the capabilities of all devices . You enter the path of compromise in the interface. You will have to choose not the best solution for the screen of a particular device, but the optimal one for a whole range of sizes.
• Requirements for the development of the interface and design are increasing . When designing any piece of service, you will always have to remember about all the devices on which this functionality should work. At first it may seem tedious, but over time a habit develops and everything falls into place.

Our experience

We abandoned the m.futubra.com subdomain, rendered all the code on the main domain, defined 3 screen size ranges in pixels:

• from 240 to 320
• from 320 to 480
• from 480 and more

And using media queries and fluid images, we optimized the problem blocks for each range:


Notice the top menu, the action links below the message and the background image on the larger version. All this is the same version of Futubra, no magic :)

Not without problems - in the design of some blocks of the site, we did not take into account all possible screen sizes, so now there are artifacts on the smallest screens. We are working to eliminate these flaws.

findings

Mobile first , progressive enhancement and responsive web design are the three pillars on which Futubr stands. Instead of a massive and classic “top-down” approach (graceful degradation, we first design the desktop, then a separate mobile version) we applied the “bottom-up” approach and are very pleased with the result. Having experienced this approach, we recommend that you choose such a foundation in your projects.

If you are interested in learning more about any particular aspect - ask, be sure to answer in the comments or write a detailed review.

PS: if you have any comments or suggestions about Futubre herself , be sure to write them in the comments or at info@futubra.com. Your opinion is very important.