분류 전체보기 (328)
.NET (111)
S/W tip (35)
etc (63)
DB (34)
HOT item~! (48)
Disign pettens (4)
UX (6)
나의 S/W (2)
개발관련 이슈 (16)
Diary (1)
웹플러스 (1)
calendar
«   2024/05   »
일 월 화 수 목 금 토
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
tags
archive
link
ColorSwitch 00 01 02
▣  UX - 해당되는 글 6건
▣  유니버설 디자인을 위한 실전 UI(HTML/CSS)개발 가이드 - UX - 2011. 5. 12. 21:15

출처 : http://cafe.naver.com/homilhodo.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=1852&

유니버설 디자인을 위한 실전 UI(HTML/CSS)개발 가이드

  1. 문서형(DTD)을 꼭 선언해야 하나요?
  2. 문서형(DTD)의 종류가 많던데 권장하는 것은 무엇입니까?
  3. XHTML의 문법은 HTML과 비교해서 무엇이 다른가요?
  4. HTML과 XHTML 가운데 어떤 문서형(DTD)을 사용하는 것이 좋을까요?
  5. 문자셋(charset)으로 UTF-8을 권장하는 이유는 무엇인가요?
  6. 휴먼 랭귀지(human language)가 무엇인가요?
  7. 문서의 제목 <title>...</title>을 어떻게 작성하는것이 가장 좋을까요?
  8. 의미론적 마크업(semantic markup)이란 무엇입니까?
  9. 제목 요소 <hx>...</hx>는 어떻게 작성하는 것이 가장 좋을까요?
  10. 의미론적 마크업을 잘 하는 방법이 있을까요?
  11. 논리적인 순서란 어떤 것입니까?
  12. 논리적 마크업을 위해서 화면 배치를 위한 <table>...</table>을 사용하지 않기로 했습니다. 이제 무엇으로 마크업 하나요?
  13. 논리적인 마크업 예제를 한번 볼 수 있을까요?
  14. 컬럼 구조 레이아웃을 위한 CSS 기법이 궁금합니다.
  15. 'id/class' 선택자 사용 기준은 무엇이고 어떻게 네이밍 하는것이 좋을까요?
  16. 이미지 대체 텍스트 속성 alt="*" 어떻게 작성하는 것이 가장 좋은가요? title="*" 속성과는 어떻게 다르죠?
  17. 이미지에 포함된 텍스트의 양이 너무 많습니다. 어떻게 처리하죠?
  18. 모두가 이용할 수 있는 longdesc 텍스트를 제공하고 싶습니다.
  19. 웹 브라우저 호환성을 유지하기 위한 CSS 기법은 무엇이 있나요?
  20. IR(Image Replacement) 기법이란 무엇입니까?
  21. Image Sprite 기법이란 무엇입니까?
  22. 동영상 대체 콘텐츠는 무엇이고 어떻게 처리해야 합니까?
  23. 프레임셋 <frameset>...</frameset>의 문제는 무엇인가요?
  24. 프레임셋 <frameset>...</frameset>을 사용한다면 무엇을 주의해야 하나요?
  25. 내용 없는 빈 <iframe>...</iframe>을 사용하고 있습니다. 이런 빈 프레임에도 title="*" 속성을 이용해서 설명해야 하나요?
  26. 모든 기능을 키보드로 이용할 수 있도록 하려면 무엇을 주의해야 하나요?
  27. onclick과 onkeypress, onkeydown, onkeyup 이벤트 헨들러를 함께 사용하면 안되는 이유가 무엇입니까?
  28. <a>...</a> 요소를 마크업 할 때 href 속성의 값으로 "#"을 사용하면 안되나요?
  29. <button type="button">...</button> 요소의 의미와 사용법을 알려주세요.
  30. <button type="button">...</button> 요소의 디자인을 CSS로 제어할 수 없나요?
  31. CSS 기반의 가변폭 텍스트 버튼을 만들고 싶습니다.
  32. 키보드의 논리적인 접근 순서를 위해 tabindex="*" 속성을 사용해도 될까요?
  33. 건너뛰기 링크는 어떻게 구현하는 것이 가장 좋을까요?
  34. 자바스크립트를 이용한 팝업 띄우기는 무엇이 문제인가요? 어떻게 하면 되죠?
  35. 데이터 테이블 <table>...</table>을 의미있고 논리적으로 작성하는 방법은 무엇인가요?
  36. 탭 메뉴 형태의 네비게이션은 무엇으로 어떻게 마크업 해야 합니까?
  37. <label>...</label> 요소는 어떻게 사용하나요?
  38. 플래시 <object>...</object> 네비게이션의 문제는 무엇인가요?
  39. 겸손한 자바스크립트(Unobtrusive JavaScript)란 무엇입니까?
  40. Ajax의 접근성 문제는 무엇입니까?
  41. 시각 장애인을 위하여 CSS { display:none } 처리된 콘텐츠를 제공하는 것이 왜 나쁜가요?
  42. CSS Framework이란 무엇 입니까?
  43. 드림위버와 같은 위지윅(WYSIWYG) 도구는 웹 표준이나 접근성을 지원 하나요?
  44. 드림위버는 너무 무거운 프로그램 아닌가요?
  45. CSS 파일을 부를 때 <link />와 @import의 차이는 뭔가요? 어떤 방법이 더 좋죠?
  46. 인쇄용 CSS를 어떻게 작성하는 것이 좋을까요?
  47. IE 6 브라우저는 #id.class 다중 선택자 조합을 지원하지 않습니다.
  48. IE 6 브라우저는 .class.class 다중 선택자 조합 일부를 지원하지 않습니다.
  49. IE 6 브라우저는 float 처리된 요소의 margin을 두 배로 처리하는 버그가 있습니다.
  50. IE 6~7 브라우저는 float된 요소의 문자를 복사하는 버그가 있습니다.
  51. IE 6~7 브라우저는 float된 요소 주변에 등장하는 absolute 요소를 표시하지 않는 버그가 있습니다.
  52. 도움 주신 분들.
출처 : http://naradesign.net/open_content/lecture/wp/#section1 

[출처] 유니버설 디자인을 위한 실전 UI(HTML/CSS)개발 가이드 (호두과자 _호밀로만든) |작성자 미미


top
:
▣  RIA - UX - 2010. 3. 31. 15:26

http://dbxo.egloos.com/1449354
top
:
▣  RIA세상으로의 초대 - UX - 2010. 3. 31. 15:25

http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=31750
top
:
▣  클라이언트의 아키텍쳐 선택 방법과 UX/RIA 도입 가이드 - UX - 2010. 3. 31. 15:10

꺄 김영욱 차장님 블로그.. 크크

http://winkey.tistory.com/222
top
:
▣  RIA 플랫폼 전쟁을 바라보며..... - UX - 2010. 3. 31. 15:08
http://www.ibm.com/developerworks/kr/library/dwclm/20070612-2/
top
:
▣  RIA프로젝트 실패하게 만드는 10가지 - UX - 2009. 4. 21. 16:18
http://gongdosoft.com/392

effectiveui사의 CEO인 Anthony Franco가 발표한 10 Ways To Ensure RIA Failure 요약본이에요. 물론 야매TM 영어로 들은거라 엄청나게 오해한 내용도 있을테니 비디오를 직접 보시길…^^;; videos.visitmix.com/MIX09/c06f
 

시작 할 때 나오는 인상적인 도표.


UX를 말할 때 항상 나오는 "사용자". 하지만 좋은 사용자 경험을 제공하는 애플리케이션을 개발 하는 것은 결코 쉽지 않은 일이죠.
앤써니는 RIA를 개발 할 때 실패하고 싶다면 다음과 같이 하라고 역설하고 있어요. 노파심에서 얘기하지만 다시 말해, 아래에서 굵고 크게 붉은 글씨로 표시한 표제들을 하지 말라는 거에요^^ 물론 그 외의 굵은 글씨는 중요한 것을 의미하고요;
1. 최종 사용자를 고려하지 말 것. 
DO NOT UNDERSTAND THE END USER

70%에 가까운 IT 프로젝트가 실패하는 이유는 실제 사용자가 받아들이지 않았기 때문이라는군요. 그러면서 예를 든 유명한 사례는 미국의 최초의 MP3P인 Diamond Rio인데요, Apple의 아이팟에 비해 모든 스펙이 앞서 있었을 뿐만 아니라 2년 동안이나 시장을 장악하고 있었지만 결국 지독하게 나쁜 사용성때문에 아이팟에세 떠밀리고 말았다고 해요.
결론으로 소프트웨어 개발의 새로운 황금률을 제시하는군요.
최종 사용자에게 강하게 집중하라!
  • 다른 모든 규칙은 부차적일 뿐이다
  • 다른 모든 실패는 절대적으로 이 조언을 무시했을 때 돌아오는 결과이다
 
2. 개발자들이 좋은 디자인 결정을 내릴거라고 믿을 것. 

TRUST DEVELOPERS TO MAKE GOOD DESIGN DECISIONS

개발자들에게 UI를 맡겼을 때 나오는 결과. 왜 이런 결과가 나오냐에 대해 다음과 같이 정리하네요.
개발자들은 정말 좋지 않은 결정을 조장한다
  • 개발자들의 결과물은 프로젝트 계획이나 기능이나 일정에 기반한다
  • 개발자들은 데드라인에 맞출 수 없게 되면 최종 사용자가 진짜로 바라는 것에 집중하기 보다는 기능 구현에 전력을 다한다
이것은 디자이너와 개발자가 가지는 생각의 차이Mind Gap 때문인데 이런 생각의 차이를 메꾸기 위해 다음과 같이 제안하죠.
디자이너를 믿어라
  • 사용자는 애플리케이션이 Silverlight, AJAX, Flash, .Net… 어떤 것이든지 상관하지 않는다
  • 정치나 사조직이 끼어들도록 하지 말라
  • 기술적인 과제를 놓고 허심탄회하게 디자이너와 얘기하고 알려라, 그러면 디자이너는 싸우는게 아니라 함께 일하게 될 것이다
  • 좋은 디자이너는 최종 사용자와 그들의 요구를 뭔가 쓸만한 것으로 옮기는 데 도움을 줄 것이다
  • 의심이 들면 사용자에게 물어보라
 
3. 기적같은 아이디어의 디자인을 기대하라. 

HOPE FOR A SILVER BULLET DESIGN
 
때로는 엄청난 아이디어가 중요하기도 하고 작은 변화가 큰 결과를 만들기도 하지만 기본적으로는 '효과'가 아닌 '내용'에게 집중하라는거죠. 정리하자면,

사용자를 믿어라
  • 공감이란 단어를 새겨놓고 사용자와 대화하여 행동하라
  • 사용자의 피드백을 바탕으로 자발적으로 아이디어를 내놓아라
  • 포트폴리오에 신경쓰지 말라
    • 만약 사용자가 UI에 신경쓴다면 분명히 실패할 것이다
음… 알아듣기 힘드네요. 어쨌든 그 외에도 사용자의 피드백을 문자 그대로 받지 말고 정확히 어떤 것을 원하는지를 생각하라는군요.
4. 모두를 위한 애플리케이션을 만들어라. 

BUILD FOR EVERYONE
"모두를 위해 만든다면 아무에게도 필요없게 된다."

왜 아이폰 사례를 소개하는지 잘 못들었지만(=_=), 제목이 "iPhone의 저주"네요. 여기에서 왜 아이폰을 디자인의 사례로 생각하면 안되는지를 설명하는데요,
  • 애플은 엄청난 비용을 디자인에 쏟아 붓는다
  • 모든 컨트롤들이 과도하게 통합되어 있다
  • 사용하기 어렵다 ? 직관적이지 않다
  • 익숙하게 하기 위해 마케팅에 비용을 쏟아 붓는다
그러니까 애플은 디자인과 사용자 경험으로 성공한 사례로 칭송받지만 사실 애플처럼 할 수 있는 기업은 거의 없다는 것을 지적하는 것 같네요. 특히 사용자 경험에 대한 관점이 그런데요, 사실 아이폰의 플립 슬라이드의 동작 방식이 경험이 없다면 어떻게 알 수 있겠어요? 바로 직관적이지 않다는 얘기죠. 그리고 애플은 그런 약점을 커버하기 위해 아이폰의 광고 대부분을 아이폰을 어떻게 사용하는지 애플리케이션을 어떻게 동작하는지에 할애하고 있다는 거죠. 그것도 엄청난 비용을 들여서요.
어쨌든 다음과 같이 결론을 내리는데요,
다음의 사항에 노력을 집중하라
  • 사용자가 공감할 수 있게
  • 하나의 프로젝트에 최대 3개의 페르소나Persona만 정의하고 그들에게 강력하게 집중하라
 
5. 런칭하고 잊어버려라. 

LAUNCH & FORGET
뭐어… 런칭하고 나서도 꾸준히 사용자의 행동을 측정하고 분석하고 그런 피드백을 바탕으로 향상시킬 수 있게 하라는거죠.
 
6. 성공을 정의하지 말라. 

DO NOT DEFINE SUCCESS
성공을 정의하려면, 기능이 아니라 이득benefit에 대해 토론하라
  • 질적인 이득
    • 고객이 빠른 업무 처리를 인지한다
    • 고객이 이 소프트웨어를 친구에게 추천한다
    • 브랜드 일관적이고 신뢰할 수 있는 경험이 되어야 한다
  • 양적인 이득
    • 배송을 추적하는데 드는 시간이 20% 감소한다
    • 선결제가 50% 증가한다
    • 고객 서비스 전화가 50% 감소한다
 

성공은 충돌을 수반한다, 적당한 균형을 찾아라
7. 모든 충돌을 피하라. 

AVOID ALL CONFLICT
"충돌없는 진행는 없다" 
"모든 사람이 동의한다면 프로젝트에 문제가 있다는 신호이다"
8. 아이디어까지 팔 필요는 없다고 믿어라. 

BELIEVE YOU SHOULDN’T HAVE TO SELL YOUR IDEAS
아이디어를 팔기 위해서:
  • 프로젝트에 연관된 개인들을 이해하고 그들이 반대 의견과 걱정을 가져오기 전에 먼저 말하라
  • 고객의 의견을 듣고 당신의 의견이 그들과 일치한다는 것을 확신시켜라, 그리고 다른 고객들의 말을 빌어 말하라("전에 우리의 고객들이 얘기해준 것과 같네요…")
  • 겸손하지만 정렬적으로 아이디어를 말하라
  • 공격적으로 팔라
 
9. 완벽한 계획을 세워라. 

PLAN FOR PERFECTION
심지어 길을 찾는 것도 많은 변수가 있고 변경이 있으니 개발은 어떻겠느냐는 거죠. 뭐 많이 얘기되었던 사항이죠.
 
10. 제품보다 프로세스에 가치를 두라. 

VALUE PROCESS OVER THE PRODUCT

엄청나게 많은 프로세스 다이어그램이 있지만 어떤 것도 실제 프로젝트와 일치하지 않는다는군요. 제 아무리 좋은 프로세스와 방법론으로 '제 시간에' 개발 했을지라도 제품이 엉망이면 아무 의미가 없다고 정리하네요.


우리가 '아이디어'를 스케줄에 포함 할 수 있다면 좋겠지만 좋은 아이디어는 절대로 스케줄을 잡는다고 나오는게 아니죠. 소프트웨어 프로젝트는 건설 프로젝트와는 달리 완벽하게 설계하거나 예측할 수 없죠.

사람들은 전혀 기대하지 못한 상황에서 문제를 해결하는 경우가 많다고 해요.
뭐 그 뒤로는 회사 자랑이 조금 이어지고요^^
암튼, 몇몇은 이제 꽤나 잘 알려진 사항이지만 한번 쯤 들어볼만해요. 시간도 40분정도 밖에 안되니까요.
top
:
articles
recent replies
recent trackbacks
notice
Admin : New post
BLOG main image
 

  rss skin by  m22m
tistory 티스토리 가입하기!

티스토리툴바