cshop 님의 반응형 웹 관련 댓글을 토론으로 이어가고자 글로써 올립니다. 정보
cshop 님의 반응형 웹 관련 댓글을 토론으로 이어가고자 글로써 올립니다.
본문
참고로 이 글을 읽으시는 분들은,
글도 읽으시면 좋습니다. :)
cshop 님이 제게 댓글로 쓰신 글을 우선 그대로 옮깁니다.
아... 사실 저도 현재 지운아빠님하고 매우 비슷한 입장입니다. 아마 내년 2월까지 (예정대로라면 그때 프로젝이 끝나는데...) 저도 몸이 메여 있는 상태구요... 그래서 사실 지운아빠님이 고민하시는 부분들이 남의 일 같지가 않은.....
이런 얘기는 정말 조심스럽지만,... 사실 제 자랑하는 것 같기도 하고....
구글에서 "Safest width and height for ipad" 라고 검색하시면 제 글이 첫페이지에 뜹니다. (3번째로 뜹니다.)
그래서 지금도 여러 웹디자이너들로 부터 질문도 많이 받기도 하는데, 가장 많은 질문이 현재 지운아빠님 처럼 기존에 사이트를 어떻게 반응형으로 탈바꿈 하느냐에 대한 질문입니다.
sir.co.kr 을 반응형으로 바꾸시는 작업을 하셔야 하는 것 같던데, 만약 제가 지운아빠님이라면 저는 이렇게 작업을 하겠습니다.
지극히 제 개인적인 생각이니 그냥 이런 의견도 있구나 하고 참고만 해주셨으면 하는 바람입니다.
/////////////////////////////////
viewport tag 을 메타에 declare 하신다면 (물론 당연히 하셔야 겠죠) 결국 아이패드에서는 페이지의 넓이를 768px 까지만 줄여주면 되는 문제입니다.
현재 sir.co.kr 의 메인 div 넓이가 970px 네요. 970px 에서 768px 까지 반응형으로 만드시는 문제는 어렵지 않으실 겁니다.
그냥 단순하게 페이지의 왼쪽 두 파트는 놔두시고, 가장 오른쪽 좁은 (검색어 가 있는 부분) 만 재배열을 하셔도 아이패드는 쉽게 대응을 하실수가 있죠.
문제는 970px 에서 스마트 폰의 가장 좁은 넓이인 320px 까지 어떻게 줄이느냐, 이게 관건이실 겁니다.
정말 이문제로 기존 사이트를 반응형으로 탈바꿈해야 하는 입장에 놓인 웹디자이너들이 고심을 많이 합니다.
지운아빠님 + 전진님 vs. 저, 이렇게 서로 몇년째 동의하지 못하는 부분이 RESS 에 관한 부분이죠. 네. RESS 는 분명히 순수한 반응형은 아닙니다.
하지만 이렇게 기존의 사이트 수정시 매우 유용하게 써먹을 수 있는 기법입니다.
header 와 footer 를 모바일 resolution 에 맞는 형태로 다시 별개/별도로 새로 짜시고, main 부분 역시 스마트 폰에 최적화된 형태의 css 로 다시 모습을 갖춘 상태로 불러오시면,
1. 스마트폰에서 로딩속도 향상
2. 스마트폰에 최적화 된 레이아웃
의 benefit (잇점) 이 생기십니다.
더구나 970px 를 320px 까지 줄여야 하는 "골아픔" 에서 벗어나실 수 있습니다.
기존 레이아웃을 970px 에서 768px 까지만 줄이시고, 또 별도로 320px 에서 대략 600px 까지 대응하는 asset 들을 만드시는게한번에 970px 에서 320px 까지 커버하는 걸 만드시는 것 보다 훨씬더 결과물이 좋게 나옵니다.
성능면이나 디자인 모두 이 방식이 더 유리합니다. 시간 절약도 많이 되구요.
구글이 바로 이렇게 하고 있습니다.
구글이 이렇게 하니까 무조건 이게 옳다, 이 얘기는 절대 아닙니다. 단지 저의 경험상 수차례 작업을 해보니, 이 반응형 + RESS 조합이 이런 상황에서 (그러니까 기존 사이트를 반응형으로 만들어야 하는 상황) 가장 ideal 한 해결책이 되었다는 것 입니다.
////////////////////////////////////////////////////////////////////////
* 일을 많이 한다고 일을 잘하는건 아니라 생각합니다. 좋은 해결책을 제시하고, 좋은 결과물을 내놓는게 일을 잘하는 거라 저는 생각합니다.
속는셈 치고, 한번만 RESS + 반응형으로 작업해 보세요. 절대 후회 안하실겁니다. end-user 입장에서 사이트가 순수 반응형인지, RESS + 반응형인지, 무슨 상관입니까? 사이트만 깨지지 않고, 사용하기 편하고 예쁘면 그게 최고 아닐까요?
단언컨데, RESS + 반응형은, 순수 반응형과, 별도 모바일페이지 구축 형식, 이 양쪽의 단점은 모두 버리고 장점만을 살린 최고의 방법이라 저는 생각합니다.
추천
0
0
댓글 21개
저는 RESS 에 대해 특별히 어떤 입장을 이야기한 바는 없었던 것 같은데요. ^^;;
내용이 여러가지 이야기들을 더 덧붙일만하다 여겨져서 글로 새로 등록을 했습니다. 양해해주시고, 한번 좋은 토론의 장이 되었으면 좋겠네요.
내용이 여러가지 이야기들을 더 덧붙일만하다 여겨져서 글로 새로 등록을 했습니다. 양해해주시고, 한번 좋은 토론의 장이 되었으면 좋겠네요.
예전 반응형 관련 토론글에서도 언급되었지만 기술적인 접근보다는 콘텐츠에 입각한 관점에서 접근하는게 반응형을 가장 효과적으로 구현할 수 있는 방식인 것 같습니다. 말인즉슨 RESS 냐 순수한 반응형이냐 가 문제가 아니라, SIR 의 콘텐츠가 모바일로 이동했을 때 누가 그리고 왜 SIR 에 모바일로 접속하게 될까? 를 고민하는게 우선이라는 생각입니다.
RESS 에 대한 설명을 조금 찾아봤는데, 간단히 요약하면 HTML 의 선택적 전송이라고 할 수 있을 것 같은데요.
솔직하게 말해서 여지껏 제가 노력해 온 부분이 가능한 하나의 코드를 가지고 여러 환경에 대응하려던 것이어서 쉽게 받아들여지지는 않습니다.
SASS 를 선택한 cshop님이 LESS 로 넘어가기가 주저되는 것과 비슷하달까요?
(가능한 한, 최대한 http://minsup.kr 처럼 하나의 코드로 작업하고 싶네요.ㅋㅋㅋ)
그런데 재밌는 건, 이 글을 쓰다 보니 처음에 언급한 콘텐츠 관점에서 바라봤을 때 RESS 가 상당한 이점을 가진 것은 분명하다는 생각이 든다는 것입니다. 직접 구현해보다 보면 보다 명확한 관점이 생길 것 같습니다. 지금은 예열만 하는 상태니까요.
RESS 에 대한 설명을 조금 찾아봤는데, 간단히 요약하면 HTML 의 선택적 전송이라고 할 수 있을 것 같은데요.
솔직하게 말해서 여지껏 제가 노력해 온 부분이 가능한 하나의 코드를 가지고 여러 환경에 대응하려던 것이어서 쉽게 받아들여지지는 않습니다.
SASS 를 선택한 cshop님이 LESS 로 넘어가기가 주저되는 것과 비슷하달까요?
(가능한 한, 최대한 http://minsup.kr 처럼 하나의 코드로 작업하고 싶네요.ㅋㅋㅋ)
그런데 재밌는 건, 이 글을 쓰다 보니 처음에 언급한 콘텐츠 관점에서 바라봤을 때 RESS 가 상당한 이점을 가진 것은 분명하다는 생각이 든다는 것입니다. 직접 구현해보다 보면 보다 명확한 관점이 생길 것 같습니다. 지금은 예열만 하는 상태니까요.
RESS 의 가장 매력적인 장점은 URL 이 분산되지 않는다는 것인 것 같네요. (모바일 버전을 따로 제작하는 것에 비해)
가장 치명적인(개인적으로) 단점은 앞선 댓글에서 언급한 코드가 나뉘는 것이구요.
가장 치명적인(개인적으로) 단점은 앞선 댓글에서 언급한 코드가 나뉘는 것이구요.
찾아보니 제가 오래전 주장했던 것은 "RESS 는 절충안 (hybrid) 이고 좋은 방식이라고 생각합니다." 이 부분이네요. 그리고 이 생각은 지금도 동일합니다.
그리고 절충안이라고 해서 완전한 responsive design 으로 넘어가는 단계의 전 과정 기법이 아니냐고 말씀하시는 것 같은데, 아뇨. 완전한 반응형 전 단계가 아닌, 근대 웹의 최종 도착지라고 저는 주장하는 것 입니다.
RESS 에도 여러가지 flavor 가 존재합니다.
일단 "HTML 의 선택적 전송" - 역시 한국어를 참 잘하신다는.. ㅎㅎㅎㅎ
한국어의 위대함을 느낍니다. 너무나 명확한 설명입니다.
header, footer 등, 예를들어 A,B,C,D,E,F 이렇게 6가지의 element 가 존재한다면 접근하는 기기에 따라서 가장 최적화된 asset 을 내보여 주는게 RESS 입니다. 데스크탑에서는 B, C,D,E,F 를 불러다 보여주고, 아이패드에서는 B,C,D 만 골라서 불러오고, 스마트폰에서는 A,B 만 불러오는 식으로..
이때 가장큰 장점은 페이지의 로딩속도 입니다. 필요한것만 불러오니까 빨리 페이지가 로딩됩니다. 두번째로는 디자인적 측면에서 어떤 기기에서든 완벽한 모습을 보여줄 수 있다는 것 입니다.
반면 반응형은, A,B,C,D,E,F 이렇게 6가지 element 를 어떤 기기로 접근하든 상관없이 다 꺼내 보여 줍니다. 한마디로 접근기기에 따른 생각/ 선별적 선택을 못하는 것 입니다. 그리고 모바일에서는 A,B, 만 보여주면 되니까 나머지 4개는 display:none;
이게 얼마나 비효율적 입니까?
이게 기술적으로 들리실지 모르겠지만, 저는 컨테츠 측면에서 얘기를 하는 겁니다. 970px 넓이의 컨텐츠를 320px 넓이의 resolution 에서 보여주려면 결국 어떻게 해야 합니까?
아래로 내리고 내리고 내리고, 데스트탑 PC 에서 보여지는 컨텐츠를 모바일폰에서도 다 보여주려면 페이지가 한도 끝도 없이 길어 집니다. 그러니 어떻게 합니까? 필요없는 요소들은 display:none 할수 밖에 없죠.
이래서 순수한 반응형은 usability 에서도 꽝인겁니다.
RESS 는 어떤 한가지 방법만 존재하는 것이 아닙니다. 각 사이트의 상황에 맞추어서 RESS 기법 (선택과 집중) 을 사용하는 것 입니다.
요즘 구글을 비롯해 모든 사이트들이 이런 선별적 선택과 집중의 전략으로 바뀌고 있습니다. 순수반응형은 대형사이트들이 고려도 하지 않습니다.
http://mobile.smashingmagazine.com/2013/10/08/responsive-website-design-with-ress/
수치까지 제시하면서 왜 사이트들이 이 RESS 기법을 사용해야 하는가를 설명하고 있습니다.
마지막으로 caveat 이라고 하죠. 짚고 넘어가야 할 부분?
순수 반응형은 front-end 개발자/웹디자이너 입장에서 가장 쉽게/안전하게 느껴질 수 밖에 없습니다. 그냥 css 만 열심히 짜면 되는거니까요.
반면 이 RESS 기법을 부분적으로라도 사용하려면 내가 사용하고 있는 CMS 라던지 솔루션에 대한 정확한 이해가 있어야 합니다.
그러니까 제 경우는 워드프레스가 어떤식으로 어떤 element 들이 조합되어 페이지가 만들어지는가를 명확하게 알아야 했습니다.
지운아빠님도 그누보드에 대한 정확한 이해도가 있으셔야 사용이 가능한 기법입니다. 하지만 그누보드의 경우, index.php 에서 head.php 와 tail.php 가 불려와지는 정도로 매우 단순해서 이 문제로는 큰 골머리를 앓게 되시지는 않을 겁니다.
접근기기에 따라서,
if (아이패드나 모바일 폰일 경우)
{
include_once 'header_m.php';
}
else
{
include_once('header.php'); // 원래 대로
}
?>
이런 수준의 간단한 로직이 필요할 뿐 입니다.
제가 생각하는 그누보드는 대한민국을 대표하는 게시판 솔루션이라는 상징성이 있습니다.
저의 바람은 그누보드가 계속 발전하고, 그래서 대한민국에서 최소한 게시판 솔루션 하나 만큼은 그누보드가 쓰여지길 바라는 것 입니다.
////////////////////////////////////////
정말 정말 제가 하고 싶은 얘기는, RESS 기법이, 절대 순수한 반응형 기법보다 더 어렵지 않다는 것 입니다. 더 복잡하지도 않구요.
단지 약간의 server-side 코딩이 필요할 뿐 입니다.
결국 나중에 다 작업해놓고 보면, 오히려 시간이 절약되었음을 느끼시게 될 겁니다. 더구나 기존 사이트/ 기존 빌드가 존재하는 경우, 더욱더 그렇다는 것 입니다.
그리고 절충안이라고 해서 완전한 responsive design 으로 넘어가는 단계의 전 과정 기법이 아니냐고 말씀하시는 것 같은데, 아뇨. 완전한 반응형 전 단계가 아닌, 근대 웹의 최종 도착지라고 저는 주장하는 것 입니다.
RESS 에도 여러가지 flavor 가 존재합니다.
일단 "HTML 의 선택적 전송" - 역시 한국어를 참 잘하신다는.. ㅎㅎㅎㅎ
한국어의 위대함을 느낍니다. 너무나 명확한 설명입니다.
header, footer 등, 예를들어 A,B,C,D,E,F 이렇게 6가지의 element 가 존재한다면 접근하는 기기에 따라서 가장 최적화된 asset 을 내보여 주는게 RESS 입니다. 데스크탑에서는 B, C,D,E,F 를 불러다 보여주고, 아이패드에서는 B,C,D 만 골라서 불러오고, 스마트폰에서는 A,B 만 불러오는 식으로..
이때 가장큰 장점은 페이지의 로딩속도 입니다. 필요한것만 불러오니까 빨리 페이지가 로딩됩니다. 두번째로는 디자인적 측면에서 어떤 기기에서든 완벽한 모습을 보여줄 수 있다는 것 입니다.
반면 반응형은, A,B,C,D,E,F 이렇게 6가지 element 를 어떤 기기로 접근하든 상관없이 다 꺼내 보여 줍니다. 한마디로 접근기기에 따른 생각/ 선별적 선택을 못하는 것 입니다. 그리고 모바일에서는 A,B, 만 보여주면 되니까 나머지 4개는 display:none;
이게 얼마나 비효율적 입니까?
이게 기술적으로 들리실지 모르겠지만, 저는 컨테츠 측면에서 얘기를 하는 겁니다. 970px 넓이의 컨텐츠를 320px 넓이의 resolution 에서 보여주려면 결국 어떻게 해야 합니까?
아래로 내리고 내리고 내리고, 데스트탑 PC 에서 보여지는 컨텐츠를 모바일폰에서도 다 보여주려면 페이지가 한도 끝도 없이 길어 집니다. 그러니 어떻게 합니까? 필요없는 요소들은 display:none 할수 밖에 없죠.
이래서 순수한 반응형은 usability 에서도 꽝인겁니다.
RESS 는 어떤 한가지 방법만 존재하는 것이 아닙니다. 각 사이트의 상황에 맞추어서 RESS 기법 (선택과 집중) 을 사용하는 것 입니다.
요즘 구글을 비롯해 모든 사이트들이 이런 선별적 선택과 집중의 전략으로 바뀌고 있습니다. 순수반응형은 대형사이트들이 고려도 하지 않습니다.
http://mobile.smashingmagazine.com/2013/10/08/responsive-website-design-with-ress/
수치까지 제시하면서 왜 사이트들이 이 RESS 기법을 사용해야 하는가를 설명하고 있습니다.
마지막으로 caveat 이라고 하죠. 짚고 넘어가야 할 부분?
순수 반응형은 front-end 개발자/웹디자이너 입장에서 가장 쉽게/안전하게 느껴질 수 밖에 없습니다. 그냥 css 만 열심히 짜면 되는거니까요.
반면 이 RESS 기법을 부분적으로라도 사용하려면 내가 사용하고 있는 CMS 라던지 솔루션에 대한 정확한 이해가 있어야 합니다.
그러니까 제 경우는 워드프레스가 어떤식으로 어떤 element 들이 조합되어 페이지가 만들어지는가를 명확하게 알아야 했습니다.
지운아빠님도 그누보드에 대한 정확한 이해도가 있으셔야 사용이 가능한 기법입니다. 하지만 그누보드의 경우, index.php 에서 head.php 와 tail.php 가 불려와지는 정도로 매우 단순해서 이 문제로는 큰 골머리를 앓게 되시지는 않을 겁니다.
접근기기에 따라서,
if (아이패드나 모바일 폰일 경우)
{
include_once 'header_m.php';
}
else
{
include_once('header.php'); // 원래 대로
}
?>
이런 수준의 간단한 로직이 필요할 뿐 입니다.
제가 생각하는 그누보드는 대한민국을 대표하는 게시판 솔루션이라는 상징성이 있습니다.
저의 바람은 그누보드가 계속 발전하고, 그래서 대한민국에서 최소한 게시판 솔루션 하나 만큼은 그누보드가 쓰여지길 바라는 것 입니다.
////////////////////////////////////////
정말 정말 제가 하고 싶은 얘기는, RESS 기법이, 절대 순수한 반응형 기법보다 더 어렵지 않다는 것 입니다. 더 복잡하지도 않구요.
단지 약간의 server-side 코딩이 필요할 뿐 입니다.
결국 나중에 다 작업해놓고 보면, 오히려 시간이 절약되었음을 느끼시게 될 겁니다. 더구나 기존 사이트/ 기존 빌드가 존재하는 경우, 더욱더 그렇다는 것 입니다.
html 의 선택적 전송은 제 표현이 아니라 신현석 씨의 표현이었습니다. ㅎㅎ
오늘 RESS 를 알아보느라 읽은 글이 세개인데 순서대로,
http://www.lukew.com/ff/entry.asp?1392
http://www.creativebloq.com/responsive-web-design/getting-started-ress-5122956
http://hyeonseok.com/soojung/mobile/2011/10/11/677.html 이렇습니다.
저도 이미 RESS 쪽으로 사실 마음이 많이 기울고 있습니다.
그런데 기법의 어렵고 쉽고보다 URL 이 분산되지 않는다는 점을 빼면 (사실 이점이 가장 중요한 장점일 수 있지만) 모바일 버전을 새로 제작하는 것보다 RESS 가 나은게 무엇일까 하는 의문이 듭니다.
어쩌면 m.~ 도 cshop 님이 말한 RESS 와 유사한 형태이겠군요.
그런데 코드를 하나로 유지하려는 이유는 단순히 CSS 만으로 모든 걸 해결보려는 이유만은 아닙니다.
CSS 만으로 해결보는게 어쩌면 더 빡쎄고 힘들죠. 그마만큼 마크업과 스크립트 구조가 튼튼하면서 유동적이어야 하니까요. (쓰고 보니 이게 가능한 얘기야? 라는 생각이 들지만 ㅡㅡ;;)
다수의 코드는 유지/보수에 있어서 필연적 고충을 내포하게 되기 때문에 가능한 하나의 코드로 제작하려는 노력을 하고 있습니다.
근데 또 쓰고 보니 이래저래 반응형 들어가는 순간 유지/보수는 지옥길이겠구나란 생각이 드네요. 아놔
오늘 RESS 를 알아보느라 읽은 글이 세개인데 순서대로,
http://www.lukew.com/ff/entry.asp?1392
http://www.creativebloq.com/responsive-web-design/getting-started-ress-5122956
http://hyeonseok.com/soojung/mobile/2011/10/11/677.html 이렇습니다.
저도 이미 RESS 쪽으로 사실 마음이 많이 기울고 있습니다.
그런데 기법의 어렵고 쉽고보다 URL 이 분산되지 않는다는 점을 빼면 (사실 이점이 가장 중요한 장점일 수 있지만) 모바일 버전을 새로 제작하는 것보다 RESS 가 나은게 무엇일까 하는 의문이 듭니다.
어쩌면 m.~ 도 cshop 님이 말한 RESS 와 유사한 형태이겠군요.
그런데 코드를 하나로 유지하려는 이유는 단순히 CSS 만으로 모든 걸 해결보려는 이유만은 아닙니다.
CSS 만으로 해결보는게 어쩌면 더 빡쎄고 힘들죠. 그마만큼 마크업과 스크립트 구조가 튼튼하면서 유동적이어야 하니까요. (쓰고 보니 이게 가능한 얘기야? 라는 생각이 들지만 ㅡㅡ;;)
다수의 코드는 유지/보수에 있어서 필연적 고충을 내포하게 되기 때문에 가능한 하나의 코드로 제작하려는 노력을 하고 있습니다.
근데 또 쓰고 보니 이래저래 반응형 들어가는 순간 유지/보수는 지옥길이겠구나란 생각이 드네요. 아놔
RESS 를 기술적으로만 치부한 것은 콘텐츠 전략이 확실히 선 다음에 선택 전송을 하든 전부 다 보여주든 결정하는게 낫지 않을까? 라는 생각 때문이었습니다.
조금 더 생각을 발전시켜 보니, SIR의 경우 navigation, 아웃로그인, 인덱스 정도가 반응형에서 주요 이슈가 될 것 같고, 이 부분은 RESS 로 작업을 해야 할 것 같네요.
나머지 게시판 콘텐츠들은 RESS 라기보다는 쿼리수 감소와 밀접할 것 같구요.
나머지 게시판 콘텐츠들은 RESS 라기보다는 쿼리수 감소와 밀접할 것 같구요.
http://www.lukew.com/ff/entry.asp?1392
제일 처음 "선택적 전송" 의 개념을 RESS 라는 명사화 한 글이고....
http://www.creativebloq.com/responsive-web-design/getting-started-ress-5122956
이거는 Requires: PHP, Twitter Bootstrap, Modernizr, Swipe.js, WURFL 여기서 웃어야죠.
왜 WURFL 이 필요한데? ㅎㅎㅎ
저로서는 뭐 하나 가르쳐 주는 척 하면서 저 서비스 팔아먹을려고 작성한 악의적 블로그 글, 그냥 광고글 이라고 볼수 밖에.....
http://hyeonseok.com/soojung/mobile/2011/10/11/677.html
이게 한글로 정말 잘 정리 되어 있네요!!!
단지 "UAS 판별 방법" 에서 user-agent search? user-agent service? 어떤 약자를 쓰신건지 명확하게 밝히지 않았는데,
php 로 실수 없이 모든 UA 를 찾아내는 부분은 지운아빠님이 직접짜지 않으셔도 됩니다.
사용하기 쉬운 각종 UA detecting 해주는 php library 들이 존재하기 때문에....
https://github.com/serbanghita/Mobile-Detect/tags
아, 혹시 홍사장님이 다른 library 를 쓰면 안돼! 라고 하신다면, (잘 모르지만, 3rd party library 를 쓰지 말라고 하실수도...) 이런식으로
<?php
// 웹 UA 확인
$iphone = strpos($_SERVER['HTTP_USER_AGENT'],"iPhone");
$android = strpos($_SERVER['HTTP_USER_AGENT'],"Android");
$palmpre = strpos($_SERVER['HTTP_USER_AGENT'],"webOS");
$berry = strpos($_SERVER['HTTP_USER_AGENT'],"BlackBerry");
$ipod = strpos($_SERVER['HTTP_USER_AGENT'],"iPod");
if ($iphone || $android || $palmpre || $ipod || $berry == true)
{
include_once 'header_m.htm';
}
else
{
include_once 'header.htm';
}
?>
하셔도 99% 이상의 모바일 기기는 다 잡아내실 수 있으십니다.
구글로 찾아보시면 더 섬세한 script 들이 나와 있을 겁니다.
결국 server-side 쪽에서 해주는거는 UA 분별해서 UA 에 맞는 asset 들을 찾아 넣어주는 것 밖에 없는겁니다. That's it!!
/////////////////////////////////////////////
마지막으로 이부분을 꼭 생각해주셨으면 좋겠습니다. 지금 각종 resolution 의 모바일기기들이 쏟아져나오고 있습니다.
작년까지만 해도, 순수 반응형이라고 해봐야 3 break-point (3단계?), 로 대응하면 충분했지만, 앞으로는 더욱더 복잡해 집니다.
순수 반응형의 css 부분이 더욱더 복잡해질수 밖에 없습니다. 그래서 css 를 최대한 단순화 하기 위해서라도 서버쪽 도움을 받는게, 유리할거라 생각합니다.
제일 처음 "선택적 전송" 의 개념을 RESS 라는 명사화 한 글이고....
http://www.creativebloq.com/responsive-web-design/getting-started-ress-5122956
이거는 Requires: PHP, Twitter Bootstrap, Modernizr, Swipe.js, WURFL 여기서 웃어야죠.
왜 WURFL 이 필요한데? ㅎㅎㅎ
저로서는 뭐 하나 가르쳐 주는 척 하면서 저 서비스 팔아먹을려고 작성한 악의적 블로그 글, 그냥 광고글 이라고 볼수 밖에.....
http://hyeonseok.com/soojung/mobile/2011/10/11/677.html
이게 한글로 정말 잘 정리 되어 있네요!!!
단지 "UAS 판별 방법" 에서 user-agent search? user-agent service? 어떤 약자를 쓰신건지 명확하게 밝히지 않았는데,
php 로 실수 없이 모든 UA 를 찾아내는 부분은 지운아빠님이 직접짜지 않으셔도 됩니다.
사용하기 쉬운 각종 UA detecting 해주는 php library 들이 존재하기 때문에....
https://github.com/serbanghita/Mobile-Detect/tags
아, 혹시 홍사장님이 다른 library 를 쓰면 안돼! 라고 하신다면, (잘 모르지만, 3rd party library 를 쓰지 말라고 하실수도...) 이런식으로
<?php
// 웹 UA 확인
$iphone = strpos($_SERVER['HTTP_USER_AGENT'],"iPhone");
$android = strpos($_SERVER['HTTP_USER_AGENT'],"Android");
$palmpre = strpos($_SERVER['HTTP_USER_AGENT'],"webOS");
$berry = strpos($_SERVER['HTTP_USER_AGENT'],"BlackBerry");
$ipod = strpos($_SERVER['HTTP_USER_AGENT'],"iPod");
if ($iphone || $android || $palmpre || $ipod || $berry == true)
{
include_once 'header_m.htm';
}
else
{
include_once 'header.htm';
}
?>
하셔도 99% 이상의 모바일 기기는 다 잡아내실 수 있으십니다.
구글로 찾아보시면 더 섬세한 script 들이 나와 있을 겁니다.
결국 server-side 쪽에서 해주는거는 UA 분별해서 UA 에 맞는 asset 들을 찾아 넣어주는 것 밖에 없는겁니다. That's it!!
/////////////////////////////////////////////
마지막으로 이부분을 꼭 생각해주셨으면 좋겠습니다. 지금 각종 resolution 의 모바일기기들이 쏟아져나오고 있습니다.
작년까지만 해도, 순수 반응형이라고 해봐야 3 break-point (3단계?), 로 대응하면 충분했지만, 앞으로는 더욱더 복잡해 집니다.
순수 반응형의 css 부분이 더욱더 복잡해질수 밖에 없습니다. 그래서 css 를 최대한 단순화 하기 위해서라도 서버쪽 도움을 받는게, 유리할거라 생각합니다.
네 예전 전진님 강좌글을 보더라도 break-point 가 점점 늘어날 것이라는 예상 때문에 경계치를 320 480 딱딱 짜르지 않는 경우도 있다는 내용이 있었죠.
사실 cshop님의 표현대로 순수 반응형이라는 게 앞서도 언급했지만 css 작성이나 마크업에서 더 골머리를 앓게 되는 건 사실인 것 같습니다.
사실 cshop님의 표현대로 순수 반응형이라는 게 앞서도 언급했지만 css 작성이나 마크업에서 더 골머리를 앓게 되는 건 사실인 것 같습니다.
토론에 자세히 참여해야 하는데, 막 나가봐야 해서.. 간단히 몇자 남깁니다.
- "지운아빠님 + 전진님 vs. 저, 이렇게 서로 몇년째 동의하지 못하는 부분이 RESS 에 관한 부분이죠."
아마도 이제는 모두들 다르게 생각하는 것은 아니지 않았나 생각합니다.
cshop2님은, "RESS 는 절충안 (hybrid) 이고 좋은 방식이라고 생각합니다." 로 기억하고 계신반면
저는 cshop님의 초기 입장이 "RESS는 엄격한 의미에서 반응형 웹이 아니다" 라고 기억하고 있기는 하지만..
어짜피 초기 생각들이고, 이제는 생각의 차이가 크게 있지는 않는것 같습니다.
- "UAS 판별 방법" 에서 UAS의 원단어는 아마도 user-agent string 일겁니다. 보통은 UA 또는 UA string이라고 하더군요.
- 아주 rough 한 서버측 vs 클라이언트측 반응형 웹 구현의 차이
우선은 서버측의 경우, '선택적 전송'을 하기에 전송량에서 서버측에 장점이 있겠죠.
하지만 그렇다고 기기마다 또는 기기크기마다 (거의) 통째로 다른 코드를 보내주는 것은 아니지 않나 생각됩니다.
현재까지 개인적으로는, "RESS기반 반응형 이미지"가 의미있는 활용이 아닐까 생각합니다.
그럼 다녀와서 저녁에 또 들리겠습니다. ^^
- "지운아빠님 + 전진님 vs. 저, 이렇게 서로 몇년째 동의하지 못하는 부분이 RESS 에 관한 부분이죠."
아마도 이제는 모두들 다르게 생각하는 것은 아니지 않았나 생각합니다.
cshop2님은, "RESS 는 절충안 (hybrid) 이고 좋은 방식이라고 생각합니다." 로 기억하고 계신반면
저는 cshop님의 초기 입장이 "RESS는 엄격한 의미에서 반응형 웹이 아니다" 라고 기억하고 있기는 하지만..
어짜피 초기 생각들이고, 이제는 생각의 차이가 크게 있지는 않는것 같습니다.
- "UAS 판별 방법" 에서 UAS의 원단어는 아마도 user-agent string 일겁니다. 보통은 UA 또는 UA string이라고 하더군요.
- 아주 rough 한 서버측 vs 클라이언트측 반응형 웹 구현의 차이
우선은 서버측의 경우, '선택적 전송'을 하기에 전송량에서 서버측에 장점이 있겠죠.
하지만 그렇다고 기기마다 또는 기기크기마다 (거의) 통째로 다른 코드를 보내주는 것은 아니지 않나 생각됩니다.
현재까지 개인적으로는, "RESS기반 반응형 이미지"가 의미있는 활용이 아닐까 생각합니다.
그럼 다녀와서 저녁에 또 들리겠습니다. ^^
"하지만 그렇다고 기기마다 또는 기기크기마다 (거의) 통째로 다른 코드를 보내주는 것은 아니지 않나 생각됩니다." -
위에서도 말씀드렸듯이"RESS 에도 여러가지 flavor 가 존재합니다."
"RESS기반 반응형 이미지"가 의미있는 활용이 아닐까 생각합니다." - 지금 제 Nginx 서버에서 구글의 PageSpeed 를 이용하고 있기 때문에,
https://developers.google.com/speed/pagespeed/module
말씀하시는 RESS 기반 image optimization 을 모르는 바가 아니지만, 나혼자 쓰는게 아닌 그누보드처럼 여러사람에게 배포되어야 하는 오픈소스에 PageSpeed 를 어떻게 적용해야 할까요?
http://www.sencha.com/learn/how-to-use-src-sencha-io/ 이것 역시 마찬가지 문제 입니다.
여러사람에게 배포되어야 한다는 점을 잊으시면 안됩니다.
image optimization 은 각자 알아서 해결해야 할 문제이지 오픈소스가 해결해 줄수 있는게 아닙니다.
모바일용 header 나 footer 는 일단 이미지나 자스 사용없이, 또 더 간략한 css 코딩으로 만들어 질 수 있습니다.
사실 이부분이 핵심인 것 입니다.
데스크탑 용 header 나 footer 에 jQuery 가 몇개 들어간다고 문제가 되지 않습니다. 하지만 이 resource 들이 그대로 모바일로 접속했을때도 똑같이 로딩이 되면, 엄청나게 버벅거립니다.
이미지 역시 (로고를 예로 들자면) 모바일용의 조그만 이미지를 모바일 플랫폼에서만 별도로 로딩되게 해주면 페이지가 가벼워지는데 큰 도움이 됩니다.
여러사람들에게 배포되는 솔루션에서 RESS 로 해줄 수 있는 기법들은 이런 부분들 입니다.
위에서도 말씀드렸듯이"RESS 에도 여러가지 flavor 가 존재합니다."
"RESS기반 반응형 이미지"가 의미있는 활용이 아닐까 생각합니다." - 지금 제 Nginx 서버에서 구글의 PageSpeed 를 이용하고 있기 때문에,
https://developers.google.com/speed/pagespeed/module
말씀하시는 RESS 기반 image optimization 을 모르는 바가 아니지만, 나혼자 쓰는게 아닌 그누보드처럼 여러사람에게 배포되어야 하는 오픈소스에 PageSpeed 를 어떻게 적용해야 할까요?
http://www.sencha.com/learn/how-to-use-src-sencha-io/ 이것 역시 마찬가지 문제 입니다.
여러사람에게 배포되어야 한다는 점을 잊으시면 안됩니다.
image optimization 은 각자 알아서 해결해야 할 문제이지 오픈소스가 해결해 줄수 있는게 아닙니다.
모바일용 header 나 footer 는 일단 이미지나 자스 사용없이, 또 더 간략한 css 코딩으로 만들어 질 수 있습니다.
사실 이부분이 핵심인 것 입니다.
데스크탑 용 header 나 footer 에 jQuery 가 몇개 들어간다고 문제가 되지 않습니다. 하지만 이 resource 들이 그대로 모바일로 접속했을때도 똑같이 로딩이 되면, 엄청나게 버벅거립니다.
이미지 역시 (로고를 예로 들자면) 모바일용의 조그만 이미지를 모바일 플랫폼에서만 별도로 로딩되게 해주면 페이지가 가벼워지는데 큰 도움이 됩니다.
여러사람들에게 배포되는 솔루션에서 RESS 로 해줄 수 있는 기법들은 이런 부분들 입니다.
으 내용 중 오해가 있으신 것 같은데 냑에서 배포하는 솔루션은 반응형 웹을 적용할 계획이 없습니다. 현재 제가 하고 있는 고민은 SIR 공홈에 대한 것입니다. ㅠㅠ;;
Aㅏ...................... ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
그럼 image optimization 도 하시면 좋죠. 구글의 PageSpeed 는 주로 Nginx 기반에서 자주 쓰이는데 아파치로도 배포되는게 있는걸로 알고 있습니다.
그럼 image optimization 도 하시면 좋죠. 구글의 PageSpeed 는 주로 Nginx 기반에서 자주 쓰이는데 아파치로도 배포되는게 있는걸로 알고 있습니다.
하지만 g5 의 경우 서버사이드에서 모바일 감지를 통해 선택적 전송이 이미 이루어지고 있어서, g5 를 활용한 반응형 웹 적용을 고려하시는 분들께는 이번 글이 여러모로 참고가 될 것 같네요.
점심먹으로 잠깐 들렀습니다. ^^;
네, RESS 기법들이 많이 있으니 잘 골라서 사용하면 좋을것 같습니다.
RESS기반 반응형 이미지는, 말씀하시는 PageSpeed의 image optimization과 어떻게 연결이 될지 잘 모르겠지만,
제가 말씀드렸던것은, '기기/통신속도에 따라서 적절한 이미지를 선택적으로 전송'하는 기법들을 말씀드린것입니다.
이런 기법들 중 특정 사이트 하나에만 적용하기 쉬운 경우도 있지만,
배포되는 솔루션(예, CMS나 wp)에 적용가능한 경우도 있습니다.
특히 대부분의 솔루션의 경우, 업로드되는 이미지를 여러 크기로 변환/저장하기에 적절한 상황에 맞게 보내는 것이 더 쉬워 보이고요.. (예: http://mobile.smashingmagazine.com/2012/06/14/responsive-images-with-wordress-featured-images/ )
네, RESS 기법들이 많이 있으니 잘 골라서 사용하면 좋을것 같습니다.
RESS기반 반응형 이미지는, 말씀하시는 PageSpeed의 image optimization과 어떻게 연결이 될지 잘 모르겠지만,
제가 말씀드렸던것은, '기기/통신속도에 따라서 적절한 이미지를 선택적으로 전송'하는 기법들을 말씀드린것입니다.
이런 기법들 중 특정 사이트 하나에만 적용하기 쉬운 경우도 있지만,
배포되는 솔루션(예, CMS나 wp)에 적용가능한 경우도 있습니다.
특히 대부분의 솔루션의 경우, 업로드되는 이미지를 여러 크기로 변환/저장하기에 적절한 상황에 맞게 보내는 것이 더 쉬워 보이고요.. (예: http://mobile.smashingmagazine.com/2012/06/14/responsive-images-with-wordress-featured-images/ )
아........ 반응형 이미지 = image optimization 인거죠. Of course!!
I wasn't connecting the dot even though that's what I am doing. Of course responsive image results in lighter load.
Sometimes, I do things w/o realizing what I am doing even though I am doing it already. LOL
I wish we could have this conversation in English and not have so much confusion & misunderstanding in communicating with each other.
I wasn't connecting the dot even though that's what I am doing. Of course responsive image results in lighter load.
Sometimes, I do things w/o realizing what I am doing even though I am doing it already. LOL
I wish we could have this conversation in English and not have so much confusion & misunderstanding in communicating with each other.
Ah.. I doubt that.
Since I quit my previous job, I haven't used English as much as used to..
so probably I would cause more confusion and misunderstanding with my poor English..
Anyway it seems there are so many ways to get to 'RWD', so we'd better follow the way we feel most comfortable and confident with.. , not arguing about which one is best for everybody. :)
Since I quit my previous job, I haven't used English as much as used to..
so probably I would cause more confusion and misunderstanding with my poor English..
Anyway it seems there are so many ways to get to 'RWD', so we'd better follow the way we feel most comfortable and confident with.. , not arguing about which one is best for everybody. :)
I totally agree. There isn't a right or a wrong of doing anything.
Just as you said, I feel that if the person developing the site isn't comfortable with any particular technique, then that's not the best method for him. Ultimately, you have to stick with what you are comfortable with.
Having said that, my argument is (and I've been arguing this point for years now) that using server-side scripting to selectively load the most appropriate asset is the final destination of RWD.
And I realize I keep repeating this but just look at google!!
https://news.google.com/
If my argument is incorrect, and "one layout fits all solution" w/o any server-side scripting is the way to go, why is google utilizing the server-side scripting to selectively load assets on its page?
I am not saying google is always right & I am not saying what I am proposing is a perfect solution.
My point is, this method is good enough for google. That's why google is using this method. With all the money & resource, this is what google settled on.
Obviously, it's good enough for me & it should be good enough for many sites out there including sir.co.kr.
This method does not cost more money/time compared to "one layout responsive design." This is especially true when you are dealing with an existing site which is non-responsive such as sir.co.kr.
Just as you said, I feel that if the person developing the site isn't comfortable with any particular technique, then that's not the best method for him. Ultimately, you have to stick with what you are comfortable with.
Having said that, my argument is (and I've been arguing this point for years now) that using server-side scripting to selectively load the most appropriate asset is the final destination of RWD.
And I realize I keep repeating this but just look at google!!
https://news.google.com/
If my argument is incorrect, and "one layout fits all solution" w/o any server-side scripting is the way to go, why is google utilizing the server-side scripting to selectively load assets on its page?
I am not saying google is always right & I am not saying what I am proposing is a perfect solution.
My point is, this method is good enough for google. That's why google is using this method. With all the money & resource, this is what google settled on.
Obviously, it's good enough for me & it should be good enough for many sites out there including sir.co.kr.
This method does not cost more money/time compared to "one layout responsive design." This is especially true when you are dealing with an existing site which is non-responsive such as sir.co.kr.
그리고 end-user 들은 이런 RESS 기법이 적용된 오픈소스를 받게 되면, 모바일 페이지에 아무런 부담을 주지 않고, 얼마든지 편하게 자신들이 원하는 여러가지 데스크탑 용 효과들 (결국 jQuery 죠) 을 넣을수 있게 됩니다.
그누보드는 워드프레스 처럼 page template 형식? 조합형으로 페이지가 구성되지 않습니다. 그누보드 구조 자체가 include 들로 페이지가 구성되는 단순한 형식이니 여기에 적용되는 RESS 기법도 이에 맞춰가는게 센스있는 방법일 겁니다.
그누보드는 워드프레스 처럼 page template 형식? 조합형으로 페이지가 구성되지 않습니다. 그누보드 구조 자체가 include 들로 페이지가 구성되는 단순한 형식이니 여기에 적용되는 RESS 기법도 이에 맞춰가는게 센스있는 방법일 겁니다.
결국 배포되는 솔루션에 대한 고민이 아닌, sir.co.kr 공홈에 국한된 고민이시라면, 문제는 간단해지네요.
지운아빠님은 이 2가지에 대한 결정만 하시면 될 것 같습니다.
1.
320px 에서 부터 970px 까지 반응하는 하나의 레이아웃을 짜는 일이 더 쉬운 일인가,
아니면, 970px 에서 768px 까지 반응하는 레이아웃 하나와, 320px 에서 600px 까지 반응하는 레이아웃 하나, 이렇게 두개를 짜는 것이 더 쉬운/효율적인 일인가?
2. 순수 반응형 으로만 만들어진 사이트가 모바일에서 더 빠르게 로딩될 것 인가, 아니면, "HTML 의 선택적 전송" 의 방식이 모바일에서 더 빠르게 로딩될 것 인가?
저 개인적으로서는 이 두가지에 대한 답변이 너무나도 crystal clear (명확) 하지만, 지운아빠님이 결국 결정하셔야 할 문제 같습니다..
지운아빠님은 이 2가지에 대한 결정만 하시면 될 것 같습니다.
1.
320px 에서 부터 970px 까지 반응하는 하나의 레이아웃을 짜는 일이 더 쉬운 일인가,
아니면, 970px 에서 768px 까지 반응하는 레이아웃 하나와, 320px 에서 600px 까지 반응하는 레이아웃 하나, 이렇게 두개를 짜는 것이 더 쉬운/효율적인 일인가?
2. 순수 반응형 으로만 만들어진 사이트가 모바일에서 더 빠르게 로딩될 것 인가, 아니면, "HTML 의 선택적 전송" 의 방식이 모바일에서 더 빠르게 로딩될 것 인가?
저 개인적으로서는 이 두가지에 대한 답변이 너무나도 crystal clear (명확) 하지만, 지운아빠님이 결국 결정하셔야 할 문제 같습니다..
사실 저도 방향은 거의 잡았었는데요. 다만 이걸 용어로 표현했을 때 어떤 용어가 적절한지를 몰랐던 것 같네요. ㅎㅎ
어쨌든 덕분에 생각도 한번 더 써보고 이래저래 도움이 되었네요. ㅎㅎ
어쨌든 덕분에 생각도 한번 더 써보고 이래저래 도움이 되었네요. ㅎㅎ
