어떤 레이아웃이든지 3단의 레이아웃을 만들기는 까다롭습니다. 두개의 사이드바가 어느 한쪽으로 붙어있다면 기존의 2단 레이아웃을 수정해서 사이드바영역 안에 두개의 사이드바를 만들면 간단하게 해결되지만 사이드바가 양쪽으로 나누어지면 약간 복잡해지죠. 우선 하나의 사이드바 안에 두개의 사이드바를 만들어서 어느 한쪽으로만 사이드바가 두개 있는 레이아웃을 만들어보고 두개의 사이드바가 양쪽으로 나누어지는 레..
왜 지난 10여 년 전부터 성공한 기업의 창업자들은 모두 컴퓨터 프로그래머들인가? 애플의 ‘스티브 잡스’나 마이크로소프트의 ‘빌 게이츠’의 어린 시절의 장난감은 컴퓨터이었고, 그들이 장난감을 가지고 노는 방법은 프로그래밍이었다. 빌 게이츠는 그 또래 최고의 프로그래머였고, 다니던 대학을 중퇴하고 창업 했다. 아마존을 창업한 ‘제프 베조스’는 제대로 컴퓨터 공학을 전공한 프로그래머였다. 구글의 창업자인 ‘레리 페이지’와 ‘세르게이 브린’도 소프트웨어 엔지니어, 즉 프로그래머이다. 이들은 각각 미시간 대학과 메릴랜드 대학에서 정규 컴퓨터 공학을 전공했고, 서부의 스탠포드 대학교의 컴퓨터 공학 석사 과정에서 서로 만났다. 그것이 ‘우리 시대의 새로운 행위’라는 ‘구글링’이 만들어진 계기가 되었다. 이뿐인가? 전기 자동차를 만드는 ‘테슬러(Tesler)’의 회장이라는 ‘앨런 머스크(Elon Musk)’도 10살 때부터 프로그래밍을 한 프로그래머이다.
이 주제에 대한 논쟁은 이제 끝났다고 생각 됩니다. 얼마전에 있었던 하코사 세미나에서의 멀더끙님의 발표에서도 나온 이야기 이듯이 이미 외국의 많은 회사에서도 우리나라의 웹퍼블리셔와 비슷한 직군의 채용공고 요구사항에 javascript 개발에 대한 명확한 조건이 기재되어 있었으며, 심지어 디자이너에게도 어느정도의 이해가 필요하다고 쓰여 있었습니다.
html, css, javascript 는 우리에게 매우 강력한 언어이며 중요한 수단이라고 생각 됩니다.html 과 css 조차도 완벽히 마스터 하지 않은 상태에서 javascript 를 시작하는 것은 옳지 않다라고 말씀하시는 분들 역시 이제 생각을 조금만 바꾸셨으면 합니다. 어떤 한가지 것을 완벽하게 마스터 하기란 쉽지 않습니다. 또한 html 과 css를 마스터 하기까지의 시간동안 회사는 혹은 클라이 언트는 분명 그 이상을 요구하거나 원할 것입니다.
좀더 쉽게 말하자면 이것은 자신의 가치를 높이고 올라간 가치만큼의 연봉을 높일 수 있는 방법입니다. 물론 그렇다고 해서 html 과 css ...좀더 자세히 들어가서 표준화와 접근성을 소홀히 하라는 말은 아닙니다. 처음 이쪽일을 시작하면서 부터 html, css, javascript, 웹접근성과 웹표준화를 동일선상에 두고 똑같이 중요한 것으로 생각하는 인식으로 바뀌어야 합니다.
이제 더이상 자바스크립트는 중,고급 자원들만 할수 있는 영역이 아닙니다. 우리가 할수 있고, 해야하는 범위가 늘어났다는 것은 퍼블리셔라(UI개발자건, front end developer 이건간에)불리는 직군의 미래가 매우 밝아졌다는 것을 의미하며, 보다 전문적인 직군이 되었다는 것을 의미합니다.
웹퍼블리셔의 자바스크립트 범위는 어디까지 인가
굉장히 민감하고 조심스러우며, 논쟁이 많은 부분중 하나 입니다. 사실 이부분에 대한 정답은 없습니다. 지난 세미나에서 멀더끙님께서 재미있는 이야기를 해주셨습니다.
웹개발자 역시 javascript 는 생소하다. 다만 서버언어등을 공부하고 사용했기때문에 논리적으로 풀어나가는 능력이나 문법에 대한 이해가 조금 수월할 뿐이다.
개발자 분들 역시 자신의 분야와 밀접할 뿐 따로 공부를 하셔야 하는 부담은 같다는 거죠. 과거에는 간단한 롤링베너나 아코디언메뉴, 탭메뉴처럼 화면상에서 이미 만들어진 html 을 시각적으로 표현하는 부분에 대해 제한적으로 웹퍼블리셔가 기능을 만들곤 했으며, 딱 거기까지가 우리가 해야할 일이라고 말하곤 했습니다. 하지만 정작 해당 스크립트를 제대로 사용하기 위해서는 html 이 만들어지기까지의 일련의 과정에서 다른 방식이 사용된다면(예를들어 컨텐츠를 ajax 처리 한다거나, 숨겨진 메뉴를 비동기 로드 한다거나) 우리가 만들어 놓은 함수는 새로 만들거나 쓰지 못하게 되는 경우가 굉장히 많아지게 됩니다. 그리고 실제로 그런 일들이 많이 있었죠.
저역시 수없이 많은 시행착오과 오류를 범해오면서 '개발자 탓' 만 해오던 때가 있었습니다. 하지만 지나고 보면 다 그럴만한 이유와 사정이 있었던 건데요...
이부분의 정답은 없으나 현재의 제가 생각하는 웹퍼블리셔의 프론트 개발 관여 범위는 이렇습니다.
' 화면에 뿌려지는 컨텐츠 중 퍼블리셔가 관여해야 하는(롤링 베너나 동적으로 움직이는 컨텐츠, 혹은 탭과 같은) 이벤트 처리는 data를 받아와 뿌리고 동작하는 부분까지 모두 관여해야 한다. 이때 웹개발자에게 요청하거나 역으로 보내줄수 있는 부분은 json 등으로 가공된 javascript 파일이며, 개발자는 해당 데이터만 정상적으로 넘겨주면 된다.'
예를 들어 우리는 컨텐츠 제일 하단에 롤링베너를 만들어야 합니다. 좌,우측으로 클릭하면 다음 페이지에 존재하는 컨텐츠가 화면에 뿌려집니다. 과거에 우리는 ul태그 등으로 리스트를 만들고 좌,우측 버튼을 클릭하면 필요한 컨텐츠는 보여주고 필요없는 컨텐츠는 숨기는 방법을 주로 사용했습니다. 이제 아래와 같은 방법이 더 좋은 방법이 아닐까 합니다.
banner 데이터를 받거나 혹은 만든다(샘플)
베너의 갯수를 확인하여 좌,우 버튼이 필요한지 필요없는지 파악한다.
좌,우 버튼이 필요하다면(갯수가 화면에 뿌려지는 것보다 많다면) 좌우 버튼의html 을 만들고 이벤트를 추가한다.
최초 화면에 뿌려질(필요한 베너만)정보만 html 을 만들어 화면에 뿌린다.
좌,우 버튼이 클릭되면 필요한 html 영역이 있는지 확인하여 없다면 동적으로 해당 html 을 생성한다. 이때 불필요한 베너는 숨긴다.
만약 버튼이 클릭되었을때 필요한 html 이 이미 만들어져 있다면 해당 베너를 보여주고 기존 베너들은 숨긴다.
업체마다 개발자 마다 다르지만 통상은 아래와 같은 데이터를 받아와 html 을 생성할 수 있습니다.
이런 데이터는 보통 banner.js 등과 같이 js 파일로 전달 받을 수 있으며, 혹은 html 문서내에 추가되어 받을수도 있습니다.그리고 js 파일로 넘겨 받는다면 우리는 document.createElement('script') 와 같이 스크립트엘리먼트를 동적으로 생성하여 해당 엘리먼트에 속성을 추가해 동적으로 js 파일을 로드할 수도 있습니다. 당연히 로드가 완료되면 필요한 스크립트가 실행되도록 콜백함수도 만들어 낼 수 있습니다. 이 방법은 초기에 과도한 데이터 파일(많은수의 js 파일)이 로드됨으로써 발생되는 블럭킹 현상을 어느정도 감소시킬 수 있습니다.
동적으로 스크립트를 로드하고 콜백함수를 실행하는 샘플파일을 첨부합니다. 제가 작성한 부분이며 발견되지 않은 오류가 있을수 있습니다. 문서에도 표기하였으나 MIT 라이센스 규약을 따릅니다.
또한 우리는 위와같은 방법으로 불필요하게 로드되는 컨텐츠(display:none 이적용되었을 이미지들)의 수를 상당수 줄여 불필요한 트래픽 방지 및 페이지 로드속도가 줄어드는 이득을 얻을 수 있습니다.
이후 부터는 매우 간단한 일들입니다. 지금까지 어느정도의 UI를 개발해본 분들이라면 아시겠지만, htm 배열에 저장되어 있는 html 태그들을 그냥 꺼내서 필요할때마다 꺼내쓰면 되기 때문입니다.
최근 이미지를 많이 사용하는 사이트의 경우 이러한 패턴으로 페이지 제작을 하는 경우가 많이 있습니다. 과거처럼 자바스크립트를 껐을경우도 정상적으로 접근해야 한다는 조항이 현재는 절대적이지 않으므로(그리고 이러한 방법으로 얻을 수 있는 이점이 매우 크기때문에), 현재도 그렇지만 향후에도 javascript (혹은 ECMAscript)의 의존도는 더 커질것이라고 생각됩니다.
결론
안타깝게도 아직까지 많은 분들이 자바스크립트와 담을 쌓고 계시거나 혹은 html , css 가 가장 중요하며 웹접근성과 웹표준, 그리고 크로스브라우징같은 이슈가 가장 큰 이슈라고 생각하십니다. 그러나 웹은 이미 웹을 뛰어 넘어 매우 빠르게 발전하고 있으며, html5 에 추가된 매우 많은 api 관련 태그들 역시 대부분 javascript 를 통해 컨트롤 됩니다.
우리가 해야하는 일, 할수 있는 일이 많아지는 만큼 우리는 보다 전문적인 직업이 될 수 있으며, 우리에게 의존하게 만들 수 있습니다. 그것은 우리가 그렇게 할때 가능한 것입니다.
제가 적은 이글이 결코 html, css, 접근성, 표준화를 소홀히 하라는 말은 아닙니다. 단지 너무 얽메이지 말고, 열린 마음으로 도전하시길 바라는 마음에 적은 글입니다. 저역시 html, css, 접근성 등과 관련된 이슈에 대해 짬짬히 공부를 하고 새로운 이슈에 대해 검토하고 있습니다. 웹에서는 모든것이 중요합니다.
현재의 내가 하고 있는일도 벅찬데...라는 생각은 자신을 가둘뿐 아무런 도움이 되지 않습니다.
- 형상관리기존에는 웹서버에 바로 붙어서 (FTP)작업하는 방식으로 웹서버에 올라간 파일이 곧 최종본이었습니다. 신규프로젝트에서 크게 문제되는 부분은 없었지만 운영으로 넘어가면 진행되던 건이 홀딩 되거나 딜레이 되면서 현재의 운영버전과 코딩본간의 싱크가 틀어지는 문제가 종종 발생했습니다. 협업도 문제였습니다. 같은 파일을 서로 열어 작업 하거나, 예전 파일을 덮어 써 버리면 복구 할 수 있는 방법이 없었습니다.
해결을 위해 git 을 도입하면서 문제가 해결 되었습니다. 운영중인 건에 대해서는 master 브런치를 유지하고 추가 운영이슈에 대한 브런치를 추가하여 작업하고 운영배포시 master 브런치에 merge 하는 방식으로...언제나 이전 버전에 대한 형상이 남아 있기때문에 더이상 같은 파일을 덮어쓰거나 하는 등의 문제를 고민하지 않아도 되며, 작업자가 어떤부분을 어떻게 수정했는지 히스토리가 남기때문에 문제되는 부분은 없었습니다.
- 로컬서버git 을 사용하게 되면서 작업은 서버에 붙어서 하던 방식 에서 로컬에서 작업후 push 하는 방식으로 변경되었습니다. 그로인해 로컬에서 절대경로 확인을 위해 혹은 include 를 사용하기 위해서 각각 개인 PC 에 서버 셋팅이 필요하게 되었습니다.
- node.js 위의 문제를 해결하기 위해 node.js 환경을 구축 했습니다. asp, php, jsp 에서 사용되는 모든 include 문법을 사용할 수 있고, package.json 의 설정을 해 놓으면 다른 인원들도 해당 레포지토리를 clone 받아 npm install 하게 되면 모두 동일한 환경이 구축되어 작업이 수월해 졌습니다.
- less ( + Gulp)git 을 사용하더라도 동일한 css 나 파일을 수정하게되면 merge 시에 충돌이 날 가능성이 있습니다. 따라서 각각 섹션별 작업을 진행하고, 업무 효율을 높이기 위해 less 를 도입하게 되었습니다. less 의 빌드를 위해 gulp 를 사용하기로 했으며, 최초 셋팅시의 시간은 조금 걸렸으나 향후 동일한 셋팅을 사용하면 되기때문에 많은 부분에서 +a 가 되었습니다.
- bower프로젝트를 진행하다보면 다양한 자바스크립트 라이브러리들 끌어와야 합니다. 우리는 bower 를 이용해 해당 문제를 해결하기로 했고, 이 부분은 현재 진행형 입니다.
- hologram (+ ruby)신규 프로젝트 종료 후에는 반듯이 가이드 문서를 제작해야 하는데, 이는 여간 까다롭고 귀찮은 일이 아닐 수 없습니다. css, js 파일에 직접 마크다운 문법으로 주석을 달아 놓은뒤 빌드하면 가이드 문서를 제작해 주는 홀로그램을 도입해 가이드 문서 제작에 드는 시간과 비용을 어느정도 줄일 수 있었습니다.
회사 내부에서 window 사용자와 OS X 사용자가 있기 때문에 두가지 환경에서 모두 테스트 및 셋팅이 이루어 졌으며, 현재까지 발생한 이슈는 없었습니다.
-- git :
http://www.git-scm.com/
-- node.js :
http://nodejs.org/
-- gulp :
http://gulpjs.com/
-- gulp less :
https://github.com/plus3network/gulp-less
-- bower :
http://bower.io/
-- ruby :
https://www.ruby-lang.org/ko/
-- hologram :
http://trulia.github.io/hologram/
[출처] frond-end developer 작업 환경 구축. (하드코딩하는사람들) |작성자 정상현
UX 디자인이요? 한국말로는 사용자경험디자인, 영어로도 사용자경험디자인이죠. 하하. 과거에는 UI디자인, 유저리서치, 비주얼디자인, 인더스트리얼디자인, 이런식으로 디자인 도메인들이 테스크에 맞추어져 있었고 디자이너들은 그 테스크에 따라 타이틀을 가졌다면, UX디자이너라는 타이틀은 하는 일이 약간은 모호하고 어쩌면 브로드할 수 있어요.
결국 UX디자이너가 궁극적으로 해야 하는 일은 더 나은 사용자의 경험을 만드는 것이에요. 즉, Goal이 있는거에요. 그냥 Tasks가 아니라 그 Goal에 맞춰서 필요한 Tasks를 자기가 찾아야 하는 일이에요. 단지 비주얼디자인만 하는게 아니라 그 외에 플래닝과 유저리서치도 해야해요. 그러다보니 자연스레 해야 하는 일들이 넓어지는 거죠. 그래서 과거에는 작은 다이어그램으로 도메인들이 있었다면, UX디자인은 좀 더 넓은 디자인 시스템이라고 많이 말하죠. 학계 간 연계 디자인시스템이라고 해도 되겠네요.
단, 한가지 일이 아니라 다양한 일을 해야 하고 그만큼 디자이너에게 요구되는 스킬셋이 많습니다. 그 중 가장 중요한 스킬은 '본인의 아이디어를 어떤식의 비쥬얼 언어를 사용하여 표현해 낼 줄 아는 가'인것 같아요. 비쥬얼 커뮤니케이션 디자인 스킬이라고나 할까요. 표현하는 방식은 정말 디자이너 개개인에 달려있어요. 본인이 생각하기에 비주얼로 표현하는것이 좋다면 비주얼로 표현하는 것이고, 와이어프레임으로 표현하는 것이 편하다면 와이어프레임으로 표현하는 거죠. 대신 그것을 잘 팔아야하죠. 프로덕트 매니저와 엔지니어들과 옆에 앉아 함께 일도 많이 해야 해요. 그렇기에 UX디자이너는 과거 비주얼 디자이너들이 하던 일보다 더 많은 일을 할 수 있고, 자기가 욕심 부리는 만큼 더 크게 성장할 수도 있다고 봅니다.
디자이너를 보는 관점도 많이 달라졌죠. 한국에서 UX디자이너로 일하고 계신 분들을 보면 보통은 과거에 디자인 기획, 와이어프레임 짜시던 분들과 많이 다르지 않은 것 같아요. 즉, 누군가가 ‘이런 디자인을 했으면 좋겠다’라고 디자인 Tasks를 주면 그것을 완성하시는 것 같아요. 반면 미국에서 UX디자인을 잘 하시는 분들을 보면 아무도 그 사람들에게 무엇을 하라고 하지 않아요. 저의 경우에도 처음에 Flash팀에 들어갔을 때 저에게 주어진 Tasks가 없어서 당황했던 적이 있었어요. 그런 경우에는, 본인이 ‘내가 이런 일을 해야 한다, 이건 이렇게 바꿔야 한다.’라고 직접 PM에게 들고 가서 설득하고 아이디어를 제시해야 하는거죠.
예를 들어 이미 한 5~6년 된 오래된 어플리케이션에서 뭘 바꾸겠어요? 이미 잘 돌아가고 있고 사용자들도 익숙해진 상황에서 디자인 할 것이 딱히 없어요. 그렇지만, 그럴 때 UX디자이너가 나서서 ‘내가 생각할 땐 이러이러한 것이 문제인 것 같다, 이렇게 바꾸면 달라질 것 같다’하고 문제 의식을 가지고 어떻게 하면 사용자의 경험이 더 나아질 수 있을까를 계속 연구하는거죠.
참고: http://blog.naver.com/jobsticks/220062868982
Web publisher Hye Jin Lee @hjportfolio - Tumblr Blog | Tumgag
yousharknotpass
origamiaround
romaincrisis
ellievsbear
pixelskylines
prguitarman