Use this to demonstrate Adaptive, Responsive, Static and Liquid(liquidapsive.com)
liquidapsive.com
Use this to demonstrate Adaptive, Responsive, Static and Liquid
http://liquidapsive.com/
7 comments
I've never heard this distinction between adaptive and responsive. The article claims that responsive layouts are series of liquid layouts while adaptive layouts are series of static layouts. I was under the impression that "responsive" refers to all usage of media queries to swap layouts, and it just so happens that most of the time liquid layouts are used.
I haven't heard of adaptive before either, but I kind of like it. The original book on responsive design spent a lot of time talking about how to correctly make liquid layouts, and heavily advocated for their use along with media queries. It wasn't until Bootstrap that responsive design also started meaning static layouts with media queries.
It's nice... and also very wrong, if you take the initial definition of adaptive web design!
Adaptive web design as introduced by Aaron Gustafson in the "Adaptive Web Design" book has little to do with layout design, and everything to do with progressive enhancement and adapting the website's behavior to the browser's abilities (geolocation, ...)
But I guess, most people didn't read the book, and now everyone has their own definition for it, so in effect, it doesn't mean much anymore; some say it's non-fluid RWD (like here), some say it's server-side components (like most people), some say it's exactly the same as RWD... oh well, pick your favorite!
Adaptive web design as introduced by Aaron Gustafson in the "Adaptive Web Design" book has little to do with layout design, and everything to do with progressive enhancement and adapting the website's behavior to the browser's abilities (geolocation, ...)
But I guess, most people didn't read the book, and now everyone has their own definition for it, so in effect, it doesn't mean much anymore; some say it's non-fluid RWD (like here), some say it's server-side components (like most people), some say it's exactly the same as RWD... oh well, pick your favorite!
I had this idea about using a "utility" function to represent how useful a given amount of screen space is to each widget, and then choosing the layout that maximizes the sum of the utility functions. It hasn't gained any traction, and I haven't had time to implement it myself.
See http://gtk.10911.n7.nabble.com/Idea-for-automatic-widget-lay... for more details.
See http://gtk.10911.n7.nabble.com/Idea-for-automatic-widget-lay... for more details.
I quite like this idea. A lot of toolkits already allow a widget to specify a "preferred size." I wonder if a simpler approach to your idea would be similar to e.g. the Accept-Content-Type HTTP header; a widget lists a series of preferred widths (or width ranges) with weights.
preferred-width: 300px, 1.0; 200px..299px, 0.7; 100px..199px, 0.5;
When do you use em for height/width on boxes? And why not use % instead?
Most illustrative. Thanks!
Did this site really deserve its own domain? We (as the internet) really ended up misusing the domain system and the only one benefiting from it are those selling domains.
I can't really see a downside to this page having its own domain name. Also your point makes no sense... clearly liquidapsive.com is much more memorable than
http://www.yahoo.com/geocities/en/us/~liquidapsive/home.html
So, no, domain (re)sellers aren't the only ones benefiting. And TBH the credibility of your statement is questionable given that ICANN doesn't directly sell domain names anyway.
So, no, domain (re)sellers aren't the only ones benefiting. And TBH the credibility of your statement is questionable given that ICANN doesn't directly sell domain names anyway.
Well as a common practice seems to be to always go trough google for everything, I'm actually not sure if it does matter?
Besides, even if it where some github.io page or something, I got the link here, now I can bookmark it.
Half a year from now i wont remember liquidapsive.com or http://www.yahoo.com/geocities/en/us/~liquidapsive/home.html anyway.
I actually don't think using domains instead of paths or sub-domains makes things easier at all. Here's an example. Lets say you wan't to know about the latest playstation. Where do you go? ps.com, playstation.com, playstation4.com or sony.com? As a non gamer, I have no idea but I know its made by Sony so I guess that's where I'd go.
Besides, even if it where some github.io page or something, I got the link here, now I can bookmark it.
Half a year from now i wont remember liquidapsive.com or http://www.yahoo.com/geocities/en/us/~liquidapsive/home.html anyway.
I actually don't think using domains instead of paths or sub-domains makes things easier at all. Here's an example. Lets say you wan't to know about the latest playstation. Where do you go? ps.com, playstation.com, playstation4.com or sony.com? As a non gamer, I have no idea but I know its made by Sony so I guess that's where I'd go.
To be fair, the odds of somebody else wishing they could have purchased "liquidapsive.com" for a different purpose are fairly low.