개념업ㅂ은 디자이너...

temper의 이미지

780*133 짜리 메인화면에 들어갈 플래쉬를 만들랬더니
760Kbyte 짜리 swf 파일을 보내놓고,
절대로 않된다고 다시만들랬더니, 이이상은 않된다고 뻑뻑우기는
이분을 어떻게 할까요? ㅠ.ㅠ 울.고.싶.다.

maylinux의 이미지

계속 그러면 데이트신청한다고 하세요...

그러면 아마도.. 고쳐지거나, 애인이 되겠지요 8)

아바타 제작기간~~ 무려 5초!!!

kirrie의 이미지

예전에 파트타임으로 Html코딩 하던 때가 떠오르는군요.
저도 싸우다 싸우다 지쳐서 나중에는 그냥 시키는 대로만 했습니다.

한때는 200메가가 넘는 wmv 동영상 파일을 메인화면에서 embed태그를 사용해 넣으라더군요.
죽어도안된다고, (더군다나 progressive downloading으로 인코딩 되지도 않은걸) 차라리 날 죽이라고 했는데 결국은 넣고 말았습니다.
다음날 클라이언트 왈, "아 메인에 동영상 안떠요! 어찌된겨!"
기획자는 제게 와서 막 화를 내더군요.
그래서 그랬죠.
"10분만 기다리세요."
10분 정도 기다리니까 정말 동영상 나오는걸 보고 기획자가 제게 뭐라 하지도 못하고, 클라이언트에게 전화를 걸어서 '동영상 용량이 커서 그러니까 좀 기다리면 나옵니다..' 라고 양해를 구하더군요.

이런 곳에서 일했었습니다.
좀 이상한 곳이었죠. :twisted:

--->
데비안 & 우분투로 대동단결!

세벌의 이미지

개념 업ㅂ는 ?

개념 없는 이란 뜻이겠죠?

오타인지 일부러 그런 건지 모르겠지만 kldp에서는 그런 요상한 말 안 쓰셨으면 좋겠네요.

일하다 보면 별 이상한 경우도 많지요. 말도 안 되는 억지 주문을 하는... 그럴때는 그 주문에 따르는 수 밖에... 나중에 뭐라고 하면 시킨대로 했는데요 그러면서 발뺌을 -.-

k2hyun의 이미지

그 디자이너는 왜 개념을 업고 일할까요??

SI쪽에서 일하다보면 온갖 "갑"을 만나는데 다들 나름대로의 이유를 갖고 뭔가를 주장하더군요.
물론 우리들 입장에서 보면 택도 없는 말들이 대부분이구요.
디자이너가 보기엔 프로그래머가 이해가 안될수도 있겠죠.

더 이상 없다.

bear의 이미지

분명히 다시 요청을 하셔야 할것 같네요..

그리고, 처음에 말씀 하실때 어느 정도용량으로 해주세요 라고 했으면 이런일은 없었을 텐데..^^;;;

디자이너 입장에서는 좀더 멋있게 좀더 이쁘게 만들려고 노력을 했을테니까요..^^;;

두분에서 토의나 협의를 하셔서 고치는게 좋을 듯합니다.

싸운다고 해결될 문제도 아니고요..^^;;

잘 이야기 하셔서 해결 하세요..^^

행복한고니의 이미지

수없이 일을 하면서도 아직 감을 못잡은 부분이 바로 그겁니다.

디자이너에게 어느정도까지 요청해야 할 것인가?
왜 나는 디자이너의 코드를 받아서 재코딩하는 일따위를 하고 있어야 하는가?

처음 웹이라는 녀석을 접하고 취미삼아 홈페이지라는 것을 만들때만 해도 "첫페이지는 30Kbytes 이하" 라느니 "3번 클릭이내에 사이트의 모든 컨텐츠에 접근 가능해야 한다"거니 하는 얘기들이 많았는데, 최근엔 디자이너건 프로그래머이건 별로 신경쓰는 사람이 없는 듯 합니다. 웹(거미줄)이라는 말에 충실해가듯 모든 사이트들이 어지럽게 얽혀있기만 한 것 같구요.

디자이너에게는 어느정도까지 요구해야 할까요?
디자이너들 사이에서는 "이쁘게 만드는 것도 어렵다. 그것만으로도 벅찬데, 내가 프로그래머냐 어째서 나에게 코드의 정리까지 요구하는가" 등의 이야기도 간혹 나온다고 합니다(어디까지나 간혹...). 용량이니 코드니 확장 혹은 유지보수의 편리함 등은 과연 개발자들만의 고민거리여야 하는건지...

얘기를 하면 분명 약간의 해결은 있을겁니다.
그러나 일일이 얘기할 수도 없는 것이 너무 많!습!니!다!
그걸 전부 다 얘기했다가는 매일같이 잔소리하는 사람으로 보일 겁니다. 말하는 저로서도 그러려니와 듣는 사람도 스트레스겠죠.

가장 힘든 것은 "사람 대하는 것" 같습니다.

__________________________________
나는 세상에서 가장 중요한 사람이다.

logout의 이미지

엔지니어와 디자이너는 기본적으로 갈등관계입니다... 디자인은 본질적으로 어느정도 퍼포먼스와 trade-off 관계에 있으니까요.

trade-off 관계의 해결책은 심플하게 서로서로 적당한 수준에서 합의를 보면 됩니다. 다만, 그 이전에 사이즈가 큰 플래쉬 파일이 어떤 문제점을 일으키는지 정확히 주지시키는 일이 필요하겠죠. 제일 무서운 것은 아무것도 모르는 인간이 쓸데없는 자존심 세우면서 끝까지 버티는 것 아니겠습니까.... 처음에는 플래쉬 파일 이렇게 큰 것 때문에 웹 서버가 노가다 하다 뻗으면 당신이 책임질 수 있느냐고 슬쩍 부담을 준 다음에 사이즈 얼마 아래까지는 괜찮다는 식으로 한발 빼주는 게 어떨까 싶네요.

"I conduct to live,
I live to compose."
--- Gustav Mahler

ironiris의 이미지

메인화면에서 760KByte짜리 플래시 파일이 있어서는 안되는 이유에 대해서 차분하게 설명을 해주시면 납득할 것입니다.
760KByte 짜리 플래시 파일을 안쓰겠다고 한 발언에 대해서 자존심이 상했다고 느꼈다면 버티기 모드로 들어갈테지만 차근차근 이유를 말해주면 쓰레기가 아닌 이상 양보하게 되어있습니다.
그래도 못하겠다고 한다면 실력이 없는 디자이너라고 동네방네 광고하고 다니셔도 무방합니다.
플래시로 애니메이션을 만드는 분들의 데이터를 보면 배경음악에.. 음성대사에.. 5분~10분 플레이가 되는데도 2M를 잘안넘기더군요.
그 잘난 메인인트로에 뭐가 들었길래, 얼마나 오랬동안 새로운 것이 계속 나오길래.. 730K나 되는지 원...

maylinux의 이미지

요즘 디자이너의 가장 맘에 안드는것이 통짜 이미지를 쓴다는겁니다..

팝업은 전부 통짜구... 사이트맵, 심지어.. 회사소개부분까지도 모두 통짜로 쓰는경우를 많이 봤습니다...

링크는 드림위버로 이미지맵으로 전부 처리 :?

서버부하, 속도저하에는 전혀 신경쓰지 않는 모습이지요.....

설명해주면..

시간=돈 이라는 논리로 그냥 하던데로 합니다...

시간=돈 은 맞지요..
서버부하 = 돈, 속도저하=웹사이트이미지저하

라는것도 사실인데...

아바타 제작기간~~ 무려 5초!!!

oneday의 이미지

전 작업중 이미지 큰거 만나면....
머리부터 아픕니다. jpeg로 저장할 부분 gif로 저장할 부분을 잘 골라야겠죠.
컬러수가 많고 이미지가 두리둥실 살짝 뭉개져도 표시가 안나는 부분과
컬러수가 적고 텍스트같이 확실하게 보여야 할 부분..
이걸 직사각형으로 자알 잘라서...
테이블로 만들어냅니다.

얼마전에 하나 했었는데...
이젠 익숙해져서 그런지 editplus에서 테이블 그냥 만들어지더군요. rowspan colspan을 자유자재로 써가며.. ㅡㅡ;;;

이번엔 어쩔수 없이 html 코딩을 하긴 했지만..
1픽셀에 신경쓰면서 작업하긴 이젠 좀 지쳐버렸습니다.
하~~~~~

maddie의 이미지

maylinux wrote:
계속 그러면 데이트신청한다고 하세요...

그러면 아마도.. 고쳐지거나, 애인이 되겠지요 8)

짝짝짝...정답입니다. 8)

저는 중요한 부분은 아예 디자이너가 포토샵으로 그려주면 제가 코딩까지 다합니다.
차라리 그게 더 빠르더군요. 드림위버가 뿜어대는 코드는 전혀 이해할수가... :evil:
그 대신 가안을 3개씩 요구합니다. 그래서 회의해서 젤 좋은거를 뽑지요. 그 편이 더 좋은거 아닐까요? 물론 사장의 "빨리 해라"의 압박이 있지만..뻐튕깁니다. :twisted:
그리고 왠만하면 플래쉬 쓰지 맙시다..윽...로딩의 압박..

힘없는자의 슬픔

shyxu의 이미지

보통 대부분의 웹디자이너들은 컴퓨터에 대해 많이 아는 사람이 없습니다.
전 뭐 겪어본지 별로 안되지만
웹사이트 기획에 조차 아무런 생각이 없는 사람들도 있죠.

그럴수밖에 없는게 디자이너는 엔지니어가 아니라
꾸미는 사람이기 때문에 그렇지 않을까 싶군요.
(프로그래머들중에서도 그런사람 많은거 같던데)

헌데 진짜 문제는 그런게 아닌 거 같습니다.

3년 경력인 분하고 일하다가
html 하나도 모르는 사람하고 일한적이 있었는데
그래서 제가 html 코딩도 하고 했었는데...

맨날 대화합니다.
일에 관련된 대화보다는 잡담이 더 많은 편이었죠 -_-;;

지금 일하는 회사에서도..
잡담 참 많이 합니다.

일부러 더욱 그러는 것도 있는데,
서로 뭔가 잘 맞는 점도 찾으면서
서로의 성격이라던가 그런걸 파악해두는게 좋거든요.
거 왜.. 친구끼리 하면 뭔가 더 잘맞는거.. 그런거 있잖습니까.
익숙하다는 느낌이랄까요?

하루이틀 작업하고 말것도 아니니깐..
앞으로 같이 일을 해야할 "동료"라는 점에서
서로 많이 다가가는게 중요하다고 생각합니다.
머 일하다보니 그런 생각이 들더라구요.

불만있으면 술한잔 하면서
서로 얘기하면서 풀고..

전 대강 그런식.. 입니다..

위에 760kb짜리 플래쉬 얘기 같은 경우는 "그 디자이너분"의 마인드가 부족하다고 볼 수 밖에 없네요.
좀 많이 알아보면 풀 수 있는 문제일거 같은데, 귀찮아 하는 거 같네요.

하지만 위에 분 얘기처럼 ... 잘 얘기를 해주면 노력해보지 않을까요.
그런거 갖구 화를 내면 좋지 않습니다 ^^
오히려 디자이너분에게 용량을 줄이는 방법을 생각해보게 해주는게
디자이너분에겐 새로운걸 알 수 있는 좋은 기회가 되니까요.

정말 정 얘기가 안먹히면 술이라도 한잔 하면서 얘기해보는게 어떨지...
고집이 세다면 구슬려본...달까 그런 방법을....

Since 2003.
지금은 맥유저...
---
http://jtjoo.com

훌륭한녀석의 이미지

약 3년전쯤에 웹에이전시에 있었던적이 있습니다.
그 때도 요즘과 다를바 없이 디자인과 프로그래밍의 관계에 오묘한 부분이 있었습니다. 디자인과 웹프로그래밍은 교집합이 존재하며 두 사람 모두에게 그 교집합에 대한 이해는 반드시 있어야 한다고 생각하고 디자이너에게 차근차근 가르쳐줬던 생각이 납니다. 저도 또한 디자인에 대한 것들을 배웠던 적이 있고요.
그분은 지금은 잘 나가는 디자이너가 되었더군요. 저는 뭐하는건지.. -_-;;

좀 더 친밀감을 가지고 접근을 해보심은 어떠신지.. 그런일이 있으면 술도 한잔 하면서 서로에 대한 이야기를 하면서... 상대방에 대한 이해가 일을 좀더 쉽게 처리하는 방법이 되지 않을까 생각합니다. ^^;

shyxu의 이미지

문득 이 글을 디자이너들이 보면 기분이 어떨지 궁금하네요 :shock:
전 옆에 디자이너 언니에게 별로 보여주고 싶지 않은.. --;

Since 2003.
지금은 맥유저...
---
http://jtjoo.com

imcrazy의 이미지

아무리 생각해도 나는 복받은겨..

울디자너..

간단한 자바스크립트는 직접 공부해서 만들고..

플래시는 용량과 cpu점유율까지 고려해서.. 머리 쥐어짜면서 만들고..

내 코딩 스타일에 맞게 소스 들여쓰기 전부 정리해주고..

템플릿 처리하기 쉽게 주석으로 다 구별해놓고..

것도 모자라서.. 레이아웃 테이블은 대문자로, 일반 컨텐츠 테이블은 소문자로 정리 해주고..

레이아웃 테이블 잡기전에 테이블 분할 정도를 미리 상의하고..

심지어 기획 프리젠테이션용 파워포인트도 디자이너가 다 작성해 줍니다.
(전 그냥 메모장에 프로그램 등 필요한 내용 끄적거려서 넘겨주고..)

원래가 하드코딩으로 디자인을 시작했다고 합니다..

지금도 사이트 수정은 에디트 플러스에서 ftp로 열어서 직접 수정합니다.

전에 같이 일하던 디자너
'그건.. 드림위버에서 안되는데요.. 못합니다.'
와 정말 비교를 거부하는.. 지금 디자이너..

난.. 복받은겨.. 복받은겨..

warpdory의 이미지

kirrie wrote:
예전에 파트타임으로 Html코딩 하던 때가 떠오르는군요.
저도 싸우다 싸우다 지쳐서 나중에는 그냥 시키는 대로만 했습니다.

한때는 200메가가 넘는 wmv 동영상 파일을 메인화면에서 embed태그를 사용해 넣으라더군요.
죽어도안된다고, (더군다나 progressive downloading으로 인코딩 되지도 않은걸) 차라리 날 죽이라고 했는데 결국은 넣고 말았습니다.
다음날 클라이언트 왈, "아 메인에 동영상 안떠요! 어찌된겨!"
기획자는 제게 와서 막 화를 내더군요.
그래서 그랬죠.
"10분만 기다리세요."
10분 정도 기다리니까 정말 동영상 나오는걸 보고 기획자가 제게 뭐라 하지도 못하고, 클라이언트에게 전화를 걸어서 '동영상 용량이 커서 그러니까 좀 기다리면 나옵니다..' 라고 양해를 구하더군요.

이런 곳에서 일했었습니다.
좀 이상한 곳이었죠. :twisted:

4년전쯤 총선때 아버지 친구분의 친척이라는 분이 국회의원 나간다고 서버 관리 좀 해달라고(말 그대로 시스템 관리, 게시판 관리가 아니라....) .. 해서 관리한 적이 있는데, 웹 호스팅 업체에 맡겼는데, 하루 트래픽이 5 기가바이트 든가 였는데, 아침 9시도 안돼서 트래픽 초과라고 나와서 뭔가 하고 봤더니 ... 성장기 였나... 하여간에 자기 소개 비스무레한 곳에 약 500 메가짜리 .mpg 파일이 있더군요.... 비디오 편집한 걸 그대로 변환시킨 거 -_- 해결책은 ... 돈 들여서 하루 몇십기가 이상으로 트래픽 양을 늘린 거였습니다. .asf 나 .wmv 로 바꿀 생각은 아예 안하더군요. 이유는 .. '화질이 안 좋아져서 얼굴이 뭉게져서 유권자들이 못 알아본다.' 였던 걸로 기억합니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

lunarainbow의 이미지

buttfly wrote:
이번엔 어쩔수 없이 html 코딩을 하긴 했지만..
1픽셀에 신경쓰면서 작업하긴 이젠 좀 지쳐버렸습니다.
하~~~~~

1픽셀 신경쓰는것이 저뿐만이 아니었군요!

전 저의 실력이 좋지 않아 저만 삽질하는줄 알았는데...

이거 맞추려고 항상 계산기와 A4용지 꺼내놓고 픽셀 계산해가며 했었는데...

뭐.. html 만져보는 일이 자주 있는것은 아니지만, 가끔 재미삼아 할때 이것땜에 꽤 고생스럽더군요. :wink:

jachin의 이미지

컴퓨터에 대한 개념이 없을 뿐입니다. -_-a

용량에 대한 내용도 없습니다.

다만 자신이 볼 수 있게 만들어 놓은 것 뿐이니...

받으셔서 감사합니다~ 라고 한 다음에,

자신이 수정할 수 밖에요. -_-;;;

아니라면 세세한 표현의 오브젝트는 스칼라 이미지로 만들어서 추가하도록 해달라고 하시면 될 듯 합니다. -_-a

아니면, 다음 부터는 절대로 컴퓨터로 작업하지 말고,

종이에 그려서 스캐너로 달라고 하십시오. -_-a

confide의 이미지

temper wrote:
780*133 짜리 메인화면에 들어갈 플래쉬를 만들랬더니
760Kbyte 짜리 swf 파일을 보내놓고,
절대로 않된다고 다시만들랬더니, 이이상은 않된다고 뻑뻑우기는
이분을 어떻게 할까요? ㅠ.ㅠ 울.고.싶.다.

글만봐서는 어느분이 잘못했는지 판단할수가 없군요 :)

제약사항을 말씀해 주셨어야 ^_^

잘 해결하시길~

------------------
나는 바보

monpetit의 이미지

지금쯤 그 디자이너도 어디 가서 성토하고 있을지도 모르죠.
처음부터 제대로 말해 주지... 하구요. :)

elfs의 이미지

행복한고니 wrote:

디자이너에게 어느정도까지 요청해야 할 것인가?
왜 나는 디자이너의 코드를 받아서 재코딩하는 일따위를 하고 있어야 하는가?

:shock: 욱..너무 강한 표현이 아닌가요? 따위..라니요...디자이너는 프로그래머의 하급직업이 아닙니다. 서로의 일에대하여 존중했으면 좋겠습니다.

그리고 통짜이미지 쓰는것에 대해서..
어느때 부턴가 경력디자이너들도 통짜 이미지를 넣는것을 잘 하더군요. 그래서 물어봤지요..왜 이미지를 통짜로 넣느냐..라고요..

그닥 크지 않은 이미지를 잘라서 넣을경우 브라우저에서 깨져서 보이는 경우가 많다고 합니다. 저도 확인한 부분입니다만 요새 익스가 버전업이 되면서 없던 버그도 많이 생겼지요..디자이너들이 분명 제대로 html 태그를 넣었음에도 불구하고 캐쉬가 없는 상태에서 처음 페이지를 열면 내용이 많은 사이트의 경우 이미지가 깨지는 경우가 다반사입니다. 그것때문에 디자이너들이 욕먹는일도 다반사 라더군요. 브라우저의 잘못이지만 디자이너가 증명해 보일 방법이 없으니까요..믿지도 않구요..

팝업같은경우 정말로 이미지의 사이즈를 적당하게 줄여서 통짜로 넣을경우, 테이블넣고 짤라서 넣는것보다 빨리 뜨는 경우도 있습니다. 그리고 무엇보다 안정적입니다. 이미지가 깨져서 보이는 경우가 아예 없으니까요..
실제로 그다지 크지 않은 이미지를 불러오기 위해서 느린회선 또는 패킷로스가 종종 나는 회선에서 웹서버에 여러번 접속커넥션을 요구하는것은 별로 좋은 방법이 아닙니다. 배보다 배꼽이 커져버릴수도 있으니 잘 조절해야 하지요..

물론 경우없이 통짜는 넣는건 삼가해야겠지만 디자이너들의 말도 반드시 들어야 하는 것이라고 봅니다.
웹이 우리나라에 정착된것도 거의 십년에 가까워지는데(넘었나요?) 아직까지 톰과제리처럼 디자이너 못났네 프로그래머 잘났네 하는건 좀 우습지 않을까요?

몇몇 분들께 올리는 글이었습니다.. :wink:

lacovnk의 이미지

text 기반의 사용자는 어째야 되는지 -_-;

당장, 제 pda에서 web page를 clip해서 보려면.. 상당히 손을 봐야 합니다.

차라리 txt로 긁고 마는데...

언제부턴가 menu는 그냥 flash 쓰더군요 -_-;

ps. css 표준 안지키는.. 브라우져 밉습니다. 구현하기가 그렇게 어려운가...

jedi의 이미지

점점 편을 가르고 싸우는 분위기로 바뀌어 가고 있군요.

제가 보기에는 처음 사이즈를 봐서 메뉴인것 같습니다. 아닌가?

메뉴는 플레시로 안만들어 주엇으면 하는 바램이 있죠.

싸우지들 마시기 바랍니다. 대화와 타협으로 충분히 극복 가능한 문제로 보입니다.

참고로.

제가 싫어하는 사이트 순위

1위 - 배경음악 등 소리가 나오는 사이트 (최대한 빨리 다른 곳으로 이동합니다. 최대한 그런곳 안갑니다.)
2위 - 메뉴가 플레시인 사이트..(가끔 인트로를 통과 못하고 나온 경험도 있습니다.)
3위 - 새창 자꾸 여는 사이트.

이런 사이트만 아니라면 어느정도 용서합니다.....

좋아하는 사이트는 그림이 최소로 들어 있는 사이트죠. 그림 덕지덕지 있는 곳 치고 유용한 곳을 본적이 별로 없습니다.

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

죠커의 이미지

elfs wrote:
그닥 크지 않은 이미지를 잘라서 넣을경우 브라우저에서 깨져서 보이는 경우가 많다고 합니다. 저도 확인한 부분입니다만 요새 익스가 버전업이 되면서 없던 버그도 많이 생겼지요..디자이너들이 분명 제대로 html 태그를 넣었음에도 불구하고 캐쉬가 없는 상태에서 처음 페이지를 열면 내용이 많은 사이트의 경우 이미지가 깨지는 경우가 다반사입니다. 그것때문에 디자이너들이 욕먹는일도 다반사 라더군요. 브라우저의 잘못이지만 디자이너가 증명해 보일 방법이 없으니까요..믿지도 않구요..

어떤 경우에 그런가요? 제가 레이아웃을 잡을때 통짜를 안해봤는데 깨지는 경우를 못본것 같아서요.

elfs의 이미지

CN wrote:
elfs wrote:
그닥 크지 않은 이미지를 잘라서 넣을경우 브라우저에서 깨져서 보이는 경우가 많다고 합니다. 저도 확인한 부분입니다만 요새 익스가 버전업이 되면서 없던 버그도 많이 생겼지요..디자이너들이 분명 제대로 html 태그를 넣었음에도 불구하고 캐쉬가 없는 상태에서 처음 페이지를 열면 내용이 많은 사이트의 경우 이미지가 깨지는 경우가 다반사입니다. 그것때문에 디자이너들이 욕먹는일도 다반사 라더군요. 브라우저의 잘못이지만 디자이너가 증명해 보일 방법이 없으니까요..믿지도 않구요..

어떤 경우에 그런가요? 제가 레이아웃을 잡을때 통짜를 안해봤는데 깨지는 경우를 못본것 같아서요.

깨져보일때 있고 안깨져 보일때 있습니다. 어떤 경우인지를 파악할 수 있었다면 그런 문제를 만들지도 않았겠죠...

주로 ping rose 율이 좀 있을때 그런 증상이 나타나곤 합니다. 통짜레이아웃(?-설마 그렇다고 모든 사이트를 통짜로 하겠습니까..팝업등,메뉴의 특정부분을 말하는것이지요.)은 그런상황의 경우 비교적 안정적입니다. 서버의 커넥션수가 상대적으로 적으니까요..

박영선의 이미지

방법이 있습니다.

압축을 하세요...

^^;;

죠커의 이미지

elfs wrote:
깨져보일때 있고 안깨져 보일때 있습니다. 어떤 경우인지를 파악할 수 있었다면 그런 문제를 만들지도 않았겠죠...

주로 ping rose 율이 좀 있을때 그런 증상이 나타나곤 합니다. 통짜레이아웃(?-설마 그렇다고 모든 사이트를 통짜로 하겠습니까..팝업등,메뉴의 특정부분을 말하는것이지요.)은 그런상황의 경우 비교적 안정적입니다. 서버의 커넥션수가 상대적으로 적으니까요..

어떤 경우인지 모른채 나타난다면 정말 귀찮은 것이 겠군요. 이 부분에 대해서 잘 아시는 분이 답글을 달아 주셨으면 좋겠네요 :-)

codebank의 이미지

CN wrote:
어떤 경우인지 모른채 나타난다면 정말 귀찮은 것이 겠군요. 이 부분에 대해서 잘 아시는 분이 답글을 달아 주셨으면 좋겠네요 :-)

제가 아는것은 아니고 ping lose율이 높을때라니까 갑자기 생각난게 있어서요...
제가 알고 있기로는 Mozilla계열은 모든 페이지를 가져온다음 분석해서 보여주는것로
알고 있었습니다. 물론 속도증가 때문에 바뀌었다고 들었지만요...
IE의 경우는 좀더 빠르게 보여주기 위해서 html코드를 따로 받고 먼저 그것을 보여준후에
이미지를 받아서 보여준다고 들은것 같습니다.
HTML코드에는 이미지의 크기가 들어가 있는경우도 있고 그렇지 않은 경우도 있겠죠.
만일 코드에 크기가 들어가 있다면 분석하는 상태에서 이미지의 자리가 미리 잡히고
출력이된 연후에 이미지를 받아서 그리기 때문에 그러한 일이 일어나기가 힘들지 않을까
생각됩니다. 하지만 이미지 사이즈가 들어있지 않다면 그건 나중에 이미지가 들어온
후에 계산이 되어야하기때문에 이곳에서 그런 현상을 일으킬 수 있는건 아닌가요?

사실 어떠한 프로그램을 사용할때도 가끔 일어나는 버그를 찾아내기란 여간 힘든게
아니죠.
아~ 위에쓴말은 그냥 글을 읽다가 생각나서 주절거려본 것입니다. 즉, 정확하게
저것이 원인이다라는 말도 아니고 위에 쓴말이 사실에 기인해서 쓴말도 아니라는
것을 밝혀둡니다.

------------------------------
좋은 하루 되세요.

purple의 이미지

제가 느끼기에는 모질라와 ie가 화면 그리는 것이 반대로인 것 같은데요.

웹 페이지를 받아서 그리는 것이 실제 내부는 어떻게 구현되었는지는 모르겠지만, 속도가 느린 사이트에서 화면이 그려지는 것을 보면, 모질라의 경우 그림이 하나씩 로드되면서 화면이 그려져 나갑니다. ie의 경우는 하얀 화면이었다가 한번에 그려지죠. 이것 때문인지는 몰라도 웹서핑을 할 때는 모질라가 좀더 시원시원한 느낌을 줍니다.

실제로 어떤지는 모질라의 경우는 소스를 보면 알 수 있겠지만요...

bubicom의 이미지

elfs wrote:

그리고 통짜이미지 쓰는것에 대해서..
어느때 부턴가 경력디자이너들도 통짜 이미지를 넣는것을 잘 하더군요. 그래서 물어봤지요..왜 이미지를 통짜로 넣느냐..라고요..

그닥 크지 않은 이미지를 잘라서 넣을경우 브라우저에서 깨져서 보이는 경우가 많다고 합니다. 저도 확인한 부분입니다만 요새 익스가 버전업이 되면서 없던 버그도 많이 생겼지요..디자이너들이 분명 제대로 html 태그를 넣었음에도 불구하고 캐쉬가 없는 상태에서 처음 페이지를 열면 내용이 많은 사이트의 경우 이미지가 깨지는 경우가 다반사입니다. 그것때문에 디자이너들이 욕먹는일도 다반사 라더군요. 브라우저의 잘못이지만 디자이너가 증명해 보일 방법이 없으니까요..믿지도 않구요..

팝업같은경우 정말로 이미지의 사이즈를 적당하게 줄여서 통짜로 넣을경우, 테이블넣고 짤라서 넣는것보다 빨리 뜨는 경우도 있습니다. 그리고 무엇보다 안정적입니다. 이미지가 깨져서 보이는 경우가 아예 없으니까요..
실제로 그다지 크지 않은 이미지를 불러오기 위해서 느린회선 또는 패킷로스가 종종 나는 회선에서 웹서버에 여러번 접속커넥션을 요구하는것은 별로 좋은 방법이 아닙니다. 배보다 배꼽이 커져버릴수도 있으니 잘 조절해야 하지요..

물론 경우없이 통짜는 넣는건 삼가해야겠지만 디자이너들의 말도 반드시 들어야 하는 것이라고 봅니다.
웹이 우리나라에 정착된것도 거의 십년에 가까워지는데(넘었나요?) 아직까지 톰과제리처럼 디자이너 못났네 프로그래머 잘났네 하는건 좀 우습지 않을까요?

몇몇 분들께 올리는 글이었습니다.. :wink:

그런 대화가 가능하면 말도 안합니다.......
물어봐도...대답도 못합니다....

차라리... 바빠서...시간상 그랬다고 하면 이해라도 하죠..

-------------------------
모든것에 감사합니다.
http://bubicom.winmir.com

elfs의 이미지

얼마전 정글에서 웹디자이너를 위한 프로그래밍 강좌가 신설된걸 본적이 있습니다.

디자이너들은 작업의 원활화 (모 그 이외의 목적도 있겠지만 )를 위해서 프로그래밍 (php, asp)의 기본개념을 배우는 노력을 하고 있습니다.

프로그래머들은 디자이너들과의 원활한 작업을 위해서 어떤 노력을 하는지 한번 생각해 보아야 하지 않을까..싶습니다.

사실 개념없는 디자이너만큼 개념없는 프로그래머들도 천지에 깔렸습니다..^^
우리는 그들을 프로그래머가 아니라 망나니라고 부릅니다.

디자이너들은 기본적인 웹의 작동에 대한 이해도 없이 마냥 이미지의 퀄리티만을 중시하는 엉터리 디자이너들을 디자이너로 인정하지 않습니다.

개념없는 디자이너, 개념없는 프로그래머...똑.같.다.고 생각합니다.

:!:

mycluster의 이미지

Quote:
웹 페이지를 받아서 그리는 것이 실제 내부는 어떻게 구현되었는지는 모르겠지만, 속도가 느린 사이트에서 화면이 그려지는 것을 보면, 모질라의 경우 그림이 하나씩 로드되면서 화면이 그려져 나갑니다. ie의 경우는 하얀 화면이었다가 한번에 그려지죠. 이것 때문인지는 몰라도 웹서핑을 할 때는 모질라가 좀더 시원시원한 느낌을 줍니다.

이걸 보니까 생각나는 것이, 94년에 처음으로 웹이라는 것을 모자익를 통해서 볼때(그당시는 제일 빠른 네트웍이 10Mbps였지만, 거의 모뎀 수준...) 그림을 보면 모자익은 한참동안 그림이 아무것도 안나오다가 갑자기 뿅하고 나타났었죠... (보통 몇분은 기달려야죠...)

그러다가, 넷스케이프라는 것이 얼마후에 나왔는데, 그걸 보는 순간 너무 감격했읍니다... 꼼지락거리면서 한줄씩 이미지가 로딩되는 것이 보이더군요... 그래서, 커피한잔 먹고 오면... "음 반쯤 그림이 왔네" 하면서 또 기달리죠...

아마 그 시절과 비슷한 상황인 듯 하군요.

--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러

elfs의 이미지

purple wrote:
제가 느끼기에는 모질라와 ie가 화면 그리는 것이 반대로인 것 같은데요.

웹 페이지를 받아서 그리는 것이 실제 내부는 어떻게 구현되었는지는 모르겠지만, 속도가 느린 사이트에서 화면이 그려지는 것을 보면, 모질라의 경우 그림이 하나씩 로드되면서 화면이 그려져 나갑니다. ie의 경우는 하얀 화면이었다가 한번에 그려지죠. 이것 때문인지는 몰라도 웹서핑을 할 때는 모질라가 좀더 시원시원한 느낌을 줍니다.

실제로 어떤지는 모질라의 경우는 소스를 보면 알 수 있겠지만요...

모질라는 모르겠지만 ie 의 경우 모두 불러온 후 뿌려주는것은 아닙니다.
불러와 지는대로 출력됩니다.

한번에 보여지는 사이트들은 사이트 자체에서 이미지가 모두 로딩된 후 화면을 뿌리게 하는 스크립트를 썼거나 할경우 그렇게 작동되는 것이구요..

ie 에서 가로 10열 세로 10열 정도의 테이블을 만든 후 각각의 td 에 좌로부터 순서대로

01.jpg , 02.jpg, 03.jpg ..............10.jpg
11.jpg.........................................20.jpg
....
...
..

식으로 넣으신 후 로딩 해 보시면 순서대로 이미지가 불려지는대로 바로바로 출력되는걸 보실 수 있습니다. 물론 속도가 빠른 회선에선 한번에 퍽 하고 뜨겠지만 이미지하나의 크기를 100k 이상으로 하고 해 보시면 왼쪽부터 주르륵 하고 뜨는걸 보실 수 있을 겁니다.

이 경우 td 에 미리 witdh 값을 모두 부여한 상태에서 화면을 출력한다면 이미지가 처음 뜨는 위치는 마지막까지 그대로 일 것이고
만약 td 에 width 값이 없는 상태라면 이미지가 한쪽으로 쏠렸다가 그 다음이미지가 나타남으로서 비로서 제 자리를 찾아가는 현상을 보실 수 있습니다.

에러가 나는경우도 이런 경우에 종종 나는데 html 의 코드의 용량이 큰데다가 이미지의 width 값 그리고 td 의 width 값을 ie 가 스스로 판단해야 할 경우에 많이 일어나는 것으로 알고있습니다.

예전에 어디서 읽은것 같은데 html 의 한 코드라인이 줄바꿈없이 너무 길거나 할 경우 파서가 제대로 읽어들여서 분석하는데 지장이 있다는걸 본 적도 있구요.

그런것 때문인지 사실 똑같은 코드를 작성할때 어쩔땐 editplus 등으로 코딩한것보다 드림위버 같은것으로 코딩할때 좀 더 안정적으로 출력되는 경우가 있습니다. 기본적으로 드림위버같은 gui 툴에서 만들어내는 코드는 쓸데없이 크긴 하지만 완전 FM을 지향하는 것이기 때문이 아닐까 합니다.

logout의 이미지

elfs wrote:
얼마전 정글에서 웹디자이너를 위한 프로그래밍 강좌가 신설된걸 본적이 있습니다.

디자이너들은 작업의 원활화 (모 그 이외의 목적도 있겠지만 )를 위해서 프로그래밍 (php, asp)의 기본개념을 배우는 노력을 하고 있습니다.

프로그래머들은 디자이너들과의 원활한 작업을 위해서 어떤 노력을 하는지 한번 생각해 보아야 하지 않을까..싶습니다.

:!:

사실은 디자이너와 개발자의 갈등에서는 디자이너가 우위를 점하고 있다고 봐야 합니다... 왜냐하면 프로그래밍은 A가 배우든, B가 배우든, C가 배우든 누구나 노력만 하면 기본적인 레벨까지는 실력의 차이가 없이 배울수 있는 객관적인 지식입니다. 그러나 디자이너의 기본이 되는 창조적인 능력과 소위 말하는 센스는 그렇지 않죠. 물론 노력 없이 디자이너가 될 수는 없겠지만 개발자가 디자이너를 이해하는 것은 본질적으로... 무리수가 따르는 면이 있습니다. 디자이너가 끝까지 버티면 개발자는 별 수 없습니다. --;

그런 까닭에, 개발자에게 디자이너를 이해하는 노력을 요구하는데는 근본적인 한계가 있습니다. 오히려, 디자이너가 기본적인 프로그래밍 지식을 배우는 것이 맞습니다. 프로그래밍까지는 아니더라도 개발자들은 어떤 requirement를 중요시한다는 것을 경청할 필요는 있는 것이죠. 개발자들이 디자이너에게 할 수 있는 노력은 디자이너의 업무를 이해한다기보다는 개발자의 객관적인 requirement를 디자이너에게 이해시키는 것이 중요하겠죠... 이래저래 개발자는 힘든 위치입니다.

"I conduct to live,
I live to compose."
--- Gustav Mahler

elfs의 이미지

logout wrote:
elfs wrote:
얼마전 정글에서 웹디자이너를 위한 프로그래밍 강좌가 신설된걸 본적이 있습니다.

디자이너들은 작업의 원활화 (모 그 이외의 목적도 있겠지만 )를 위해서 프로그래밍 (php, asp)의 기본개념을 배우는 노력을 하고 있습니다.

프로그래머들은 디자이너들과의 원활한 작업을 위해서 어떤 노력을 하는지 한번 생각해 보아야 하지 않을까..싶습니다.

:!:

사실은 디자이너와 개발자의 갈등에서는 디자이너가 우위를 점하고 있다고 봐야 합니다... 왜냐하면 프로그래밍은 A가 배우든, B가 배우든, C가 배우든 누구나 노력만 하면 기본적인 레벨까지는 실력의 차이가 없이 배울수 있는 객관적인 지식입니다. 그러나 디자이너의 기본이 되는 창조적인 능력과 소위 말하는 센스는 그렇지 않죠. 물론 노력 없이 디자이너가 될 수는 없겠지만 개발자가 디자이너를 이해하는 것은 본질적으로... 무리수가 따르는 면이 있습니다. 디자이너가 끝까지 버티면 개발자는 별 수 없습니다. --;

그런 까닭에, 개발자에게 디자이너를 이해하는 노력을 요구하는데는 근본적인 한계가 있습니다. 오히려, 디자이너가 기본적인 프로그래밍 지식을 배우는 것이 맞습니다. 프로그래밍까지는 아니더라도 개발자들은 어떤 requirement를 중요시한다는 것을 경청할 필요는 있는 것이죠. 개발자들이 디자이너에게 할 수 있는 노력은 디자이너의 업무를 이해한다기보다는 개발자의 객관적인 requirement를 디자이너에게 이해시키는 것이 중요하겠죠... 이래저래 개발자는 힘든 위치입니다.

우위를 점한다고 하셨지만 대부분의 회사에서 팀장급은 대부분 프로그래머가 90% 이상이며 급여또한 프로그래머가 디자이너보다 높지요.

디자이너가 프로그래밍을 배울 필요다 있다고 생각하시는 만큼 프로그래머는 왜 디자이너가 어떤것을 고집하는가를 이해하기 위해 노력해야 한다고 봅니다.
어느건 힘들고 어느건 안 힘든건 없습니다. 디자이너를 이해하는데는 근본적인 한계가 있다는 말은 풀어서 보면 별로 이해하고 싶지 않다라는 느낌이 바닥에 깔려있는 것 같습니다.

디자이너 커뮤니티에서 디자이너가 프로그래머에대하여 흉을 보는 경우는 극히 드문데 이상하게 프로그래머들이 디자이너를 욕하는 경우는 많더군요.

뭐..물론 저도 프로그래머라 디자이너 동호회를 열심히 보고 다니는것은 아니지만 분명 디자이너보단 프로그래머가 디자이너에게 불만을 더 갖습니다.

코딩이 엉망이라는둥. 네트웍개념이 있냐는둥..

솔직히 디자이너 입장에선 짜증나는 일입니다. 웹디자인 학원에서 네트웍에 대한 전반적인걸 가르치고 웹디자인을 가르치는것이 아니기때문이지요..미대에서도 안갈치지요..어디서 배워서 알겠습니까..그냥 인터넷이라곤 웹서핑이랑 학원에서 배우는 html, 이미지툴이 다인걸요..학원문제지요..

제 개인적인 생각으론 프로그래머와 디자이너가 공통적으로 TCP/IP 정도는 같이 떼어야 하지않나..라고 생각합니다. :)

그럼 지금의 서로간의 짜증은 훨씬 줄어들지 않을까요..

redbaron의 이미지

maylinux wrote:
계속 그러면 데이트신청한다고 하세요...

그러면 아마도.. 고쳐지거나, 애인이 되겠지요 8)


동성이면 어떻합니까?

이성인 웹 디자이너와 일해본 횟수가 얼마 안되서..(쿨럭)

그런데 역시 한쪽에서 경험이 좀 많아서(경험만으로 될 문제는 아니겠지만)

그런 서로의 요구들을 어느정도 수용해주는 방안이 제일 편하던것 같던데요.

zepinos의 이미지

처음 회사에 입사했을 때...디자인팀장 이하 5명의 디자이너 모두 한 소리를 하더군요.
"아니...디자이너가 디자인을 잘라서 html 코드로 뽑아주는 회사가 어디있어요?"
덕분에 초반에는 포토샵 화일(PSF 였나요?) 하나 떨렁 받아서 이미지레디로 잘라서 html 만드는 작업에 심취했었습니다. :evil:
지금도 포토샵은 회사의 프로그래머들 중에서 가장 잘 씁니다. 생각해도 한심하네요.
3개월 정도 흐른 후에, 너무 열이 받아서 저희 팀의 팀장이신 이사님께 무지 투덜거려서 디자인팀장(차장)까지 불러서 며칠간 회의를 했습니다. 결론은 디자인을 html 로 뽑아줄 코더를 한 명 뽑자는 것이었는데...실현 불가능하다고 생각했고...결국 디자인팀 사람들이 하나, 둘 그만두더군요. :shock: 제가 너무 갈궈서 그런 것이었을까요?
디자이너나 기획자들은 언제나 화면의 멋 등을 먼저 고려합니다. 그리고 실용성을 생각하고, 마지막으로 구현 가능성을 생각하죠. 하지만, 프로그래머는 항상 구현 가능성을 먼저 생각하고, 그 다음에 실용성, 마지막으로 멋을 생각합니다.
그렇기 때문에 항상 마찰이 있는 것이라고 저는 생각하고 있습니다.

그래도...요즘 감사원 감사를 받고 있는데...기관 놈들하고는 정말 일 못하겠네요. 하루에도 열두번씩 화면 수정, 기능 수정 해달라고 난리입니다. 개발비 책정을 하나도 안해놓고...수주 딴 업체만 들들 볶아서...벌써 개발자만 5명이 6개월 째 투입되고 있습니다. 벌써 30 Members 인가요? 이게 도대체 얼만인거야. 그리고 얼마나 말은 안통하는지... T.T 차라리 디자이너랑 싸울 때가 더 좋았군요. 그 땐 그래도 동등한 위치에서 마찰이 생기는 것이었는데. 일반 기업 상대로 일하는 것보다...기관 상대하는 건...정말 못할 짓이네요. 그것도 컴퓨터에 관한 지식이 전무한 행정직(엄밀히 이야기 하지만 학자)하고 말이죠.

fender의 이미지

저는 오히려 디자이너가 html을 코딩 안하는게 좋습니다. 가장 좋은 방법은 html/css를 제대로 아는 코더를 두는 것이지만 현실적으로 쉽지가 않고 그렇다면 차라리 프로그래머가 템플릿/인클루드 파일 등을 고려해서 페이지를 나누고 입력폼, 리스트 형태 등 크게 유형을 나누어 css를 제대로 하나 만들어 두는게 여러모로 편합니다.

저는 대부분의 프로젝트를 계속 이런 식으로 진행했는데 일반적으로 같은 페이지라면 디자이너가 드림위버 등으로 작업한 경우보다 코드 라인 수가 1/3 수준으로 줄어들고 무엇보다 인라인 스타일이나 font, br &nbsp 등의 쓸데없는 군더더기가 없어 프로그램 작업하기가 한결 수월합니다.

가장 큰 장점은 새로 페이지를 만들 때마다 일일이 디자이너가 작업한 수백 줄 되는 코드에 일일이 tr, td 짝 맞춰가며 (대부분 디자이너들은 하다못해 여백 좀 주려고 해도 td를 넣는 식이라 5-6중으로 테이블이 겹치는 경우도 많더군요 -_-) 코딩하는 것보다 css로 깔끔하게 구성된 그냥 비슷한 유형의 다른 페이지 복사해서 코딩만 바꾸는게훨씬 빠릅니다. 여기에 jsp를 쓴다면 커스텀 태그 등 템플릿팅을 이용해서 웹단에 스크립틀릿이 단 한 줄도 안들어가게 작업할 수 있습니다.

결론적으로 가능하면 프로그래머와 디자이너 이외에 css를 제대로 아는 전문 코더가 있다면 최선이고 그렇지 못하다면 css와 템ㆅㅍㅡㅍ릿 구성은 프로그래머가, 디자인과 그림 자르는 작업은 디자이너가 맡는 것이 이상적인 분담 방식 같습니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

brianjung의 이미지

디자이너들은 개발쪽을 많이 이해하려고 노력하던데, 개발자들은 디자이너 이해하려는 노력을 하는 것을 별로 본 기억이 없습니다.

"개념"예기를 하시는데, 그 "개념"은 개발자의 "개념"이지 디자이너의 "개념"이 아닙니다. 디자이너가 성능에 문제되는 오브젝트를 뽑아낸다면, 당연히 거기에 대해서 조언하고 문제가 된다는 설득을 하는것도 개발자의 능력이라고 봅니다.

제 경우엔 항상 용량과 사투하는 디자이너들만 봐온지라...

maylinux의 이미지

redbaron wrote:
maylinux wrote:
계속 그러면 데이트신청한다고 하세요...

그러면 아마도.. 고쳐지거나, 애인이 되겠지요 8)


동성이면 어떻합니까?

이성인 웹 디자이너와 일해본 횟수가 얼마 안되서..(쿨럭)

그런데 역시 한쪽에서 경험이 좀 많아서(경험만으로 될 문제는 아니겠지만)

그런 서로의 요구들을 어느정도 수용해주는 방안이 제일 편하던것 같던데요.

동성이라면..... 고치겠죠 :?

설마.. 데이트하자고 하겠어요?
만일 응하면.. 낭패..

아바타 제작기간~~ 무려 5초!!!

낙엽의 이미지

codebank wrote:
사실 어떠한 프로그램을 사용할때도 가끔 일어나는 버그를 찾아내기란 여간 힘든게 아니죠.

갑자기 얼마전에 "갑" 회사에서 버그 리포트에 대해 요구사항이 온것에 대해 반응한 것이 생각나네요. :-)

시험 방법 및 결과 - 재현 불가이므로 시험할 방법이 없음.

shyxu의 이미지

maylinux wrote:
redbaron wrote:
maylinux wrote:
계속 그러면 데이트신청한다고 하세요...

그러면 아마도.. 고쳐지거나, 애인이 되겠지요 8)


동성이면 어떻합니까?

이성인 웹 디자이너와 일해본 횟수가 얼마 안되서..(쿨럭)

그런데 역시 한쪽에서 경험이 좀 많아서(경험만으로 될 문제는 아니겠지만)

그런 서로의 요구들을 어느정도 수용해주는 방안이 제일 편하던것 같던데요.

동성이라면..... 고치겠죠 :?

설마.. 데이트하자고 하겠어요?
만일 응하면.. 낭패..

저 같은 경우
미소년이면 데이트합니다 :oops:

Since 2003.
지금은 맥유저...
---
http://jtjoo.com