Adaptive web design

Adaptive web design works to detect the screen size during the HTTP GET request, prior to the page being served and load the appropriately designed page specific to the user-agent. With adaptive standard layout, "generally you would design an adaptive site for six common screen widths: 320, 480, 760, 960, 1200, and 1600”.[7][8] This was not only common practice for mobile optimization, but the transition period between 4:3 low resolution CRT monitors and high resolution 16:9 LCD monitors. Standard adaptive web design was necessary to create fluid layouts for the various monitors available.[7]

In the very early days of smartphones, like the BlackBerrys of the mid- to late 2000s, screen dimensions were highly varied, and in addition, mobile browsers on these devices lacked the advanced functionality and plugins used to create rich environments in desktop browsers. Additionally, data was a high-priced commodity and very slow so it was necessary to design special "stripped-down" mobile pages, with fewer images (or lower quality ones) and sharp text-wrapping for easy readability, ads needed to be scaled considerably as well. HTML at the time only allowed for fixed coordinates and no scaling (which is the reason websites were almost always bound to the top left, or top right in certain regions—responsive web design allowed for centering and relative coordinates, which led to the change to centered content pages). So in order to achieve pages which would load on mobile, developers had to design completely new pages for mobile viewing, more often than not needing to start from scratch; since these browsers were often difficult to navigate, creating large, easily seen links was also necessary.[3] The next major change to adaptive standard web design came in more recent years, particularly with the rise of the iPhone and two years later widespread 3G availability dramatically increasing connection speeds and available bandwidth, a two design dynamic system became the most utilized, a mobile layout (usually with the subdomain prefix "m") optimized for iPhone and a desktop layout. The mobile versions were still usually "scaled-down" with lower quality images and sometimes content such as videos removed to decrease loading time. This was also the first time web developers had to design with a touch screen in mind, using larger clickable links and buttons to facilitate the use of fingers as pointers.[3] As Google's Android OS rose to popularity and introduced more variation in the market share of smartphones, along with the widespread implementation of 4G LTE's ultra fast mobile broadband, it was no longer necessary to downgrade mobile media quality or trim content to deal with slow connection speeds, and, with so much variation in devices, the multi-page paradigm of Standard Dynamic web design widely lost favor with developers. While some still use the concept to completely separate touch-screen content design from desktop design, responsive web design has nearly all the tools necessary to perform nearly any manipulation in response to a large variety of factors, allowing for one page to serve all purposes. When integrating with material design or device specific layout and color schemes, some developers find it simpler to create three page templates (Android, iPhone/iOS, desktop) changing the icons and colors between each, while using media queries to determine layout. The practice results in much simpler page design and code, but updating requires editing all 3 templates. There are variations on this concept that blur the lines between AWD and RWD, like Django's "views."[3][8][9][2]

While there isn't a consensus on naming, as both adaptive and responsive could be used to represent the same behavior, what is commonly called responsive design uses fewer page layouts than standard adaptive design, typically (in nearly all cases) only one. Adaptive design is considered less future-proof and a far less efficient design model than responsive design because the screen sizes of common devices are constantly changing and highly variable. In the very early days of mass smartphone adoption, the simple 2-site model worked well (a media rich, widescreen page for desktop viewing; a smaller size (in terms of the quality/file size of loaded assets- to save data) page formatted for small screen viewing, with less clutter, larger fonts and tighter text-wrapping constraints for mobile viewing). Additionally, in the first few years of the smart-phone boom, only a few models made up the majority of the market share, so mobile pages were designed for best viewing on those devices- ignoring the minor glitches when the pages were loaded on less popular devices. With the rise of the iPhone, many developers began tailoring their mobile sites specifically to the iPhone and touch screens. Responsive Design is built on a fluid grid vs. adaptive design’s fixed grid.[3] The hybrid Adaptive/Responsive design model involves multiple pages formatted in responsive web design layout, when the nearest appropriate layout is served, then the page responds to the user's device.[7]

Standard Adaptive layout (screen-dependent multi-page) can also use viewport responsive scaling of the page in conjunction (as in responsive web design), but new responsive web design strategies and technology have all but made the need for separate multi-screen pages obsolete except where the site wishes to target users of non-smart internet-capable mobile devices and obsolete smartphones which do not respond to new responsive design scripts.[7] As previously stated, things like Django's "views" concept and some aspects of AJAX blur the lines, as they serve different versions of pages, for many reasons, but some can be for fluidity on different devices, however, pages are generated dynamically, not statically (though one could argue that the "views" are static templates to be filled with content. In the end, it is all up to the developer how he or she feels is the most appropriate way to target the devices their content will be viewed on in the most fluid, clean and integrated way. There is certainly more than one way to skin the cat of dynamic web development.[3][8][9][2]