SENCHA TOUCH - 네이티브처럼 보이는 웹앱 프래임워크
http://www.sencha.com/products/touch/
http://dev.sencha.com/deploy/touch/examples/kitchensink/ (크롬, 사파리)
장점 : 다양한 UI와 훌륭한 성능과 기능을 보입니다. 하단 탭바 형태를 기본으로 지원합니다.

특정영역 스크롤 기능을 내장합니다(iscroll과 같이). zoom, pinch 기능을 제공합니다.
단점 : 아이폰에서 돌린다해도 기본 로딩시간이 깁니다. 모두 JS를 돌아가기 때문에 브라우저의 back 버튼을 지원하지 않습니다.

안드로이드에서 화면전환 번쩍거림이 있습니다. ExtJS 라이브러리 중심으로 구성되어 EXTJS를 능통자가 아니면 매우 어렵다고 합니다.

라이센는 소스를 공개할 경우 상업적으로 이용가능하다고 합니다.

Android/iOS계열/블랙베리 지원

Sencha Touch - ExtJS를 기반으로 jQTouch, Raphael이 결합된 프레임워크
- ExtJS는 대화명 웹 어플리케이션 제작을 위한 자바스크립트 라이브러리로 AJAX, DHTML, DOM 등을 사용한다.
- jQTouch는 오픈 소스 jQuery 플러그인의 하나로 HTML, CSS, Javascript 등을 사용하여 Touch UI를 강화하는 기능을 한다.
- Raphael은 SVG(Scalable Vector Graphic, 2D 벡터 그래픽 지원을 위한 XML 기반의 파일 형식)를 지원한다.
- 자료를 주고 받는 방식으로는 key와 Value 구조를 가진 JSON(JavaScript Object Notation)을 사용한다.

JQUERY MOBILE - 터치에 최적화된 웹 프래임워크
http://jquerymobile.com/
http://jquerymobile.com/demos/1.0b1pre/ (익스, 크롬, 사파리, 오페라, 파폭)
장점 : HTML 중심의 마크업 언어라서 기존에 개발하던대로 바로 개발할 수 있습니다. 그럭저럭 괜찮은 기능들을 제공합니다(아이폰만).
단점 : 하단 탭바를 지원하지 않습니다. 특정영역 스크롤 기능이 없습니다. 아직까진 알파버전이라 버그가 많고 정식 공개되지 않았습니다. (베타 출시예정) 안드로이드에서 깜빡임 현상이 있습니다.

게시판용이나 화면뷰만을 위한것으로는 추천하고 가장 많이 쓰인다고 합니다.

Android/iOS계열/블랙베리/심비안/Palm WebOS/Windows Mobile/Opera Mobile/Firefox Mobile 지원
(베타 버전에서는 Window Phone7까지도 지원하겠다고 하고, 삼성의 bada또한 테스트계획이 있다고 합니다.)

http://brooky.cc/2011/04/23/jquery-mobile-cheat-sheet/ - jQuery mobile cheat sheet

JQUERY MOBILE과 SENCHA 둘다 아이폰은 어떤 프레임웍을 사용해도 모두 잘 돌아가는데 안드로이드에서는 문제가 많다고합니다..
대체로 아이폰을 위한것이고 안드로이드를 위한 하이브리드 프레임웍은 제대로 나온 것이 없다고합니다.
프레임워크 없이 그냥 html5, css3로만 사용해도 안드로이드에서는 문제가 많이 발생하고 폰마다 차이가 심합니다.

jqtouch - SENCHA에 인수되서 개발중단되었습니다.
http://www.jqtouch.com/
http://www.jqtouch.com/preview/demos/main/ (크롭, 사파리, 오페라, 파폭)
장점 : jQuery의 모바일용 플러그인으로 SENCHA와 JQM 보다는 가볍습니다. 참고자료가 가장 다양합니다.
단점 : 개발중단. 가볍다고는 해도 역시 안드로이드에선 버그가 많다고..

jquery, 제이슨 등의 자바스크립트 라이브러리는 무겁고 지원하는 라이브러리가 폰의 브라우저 마다 상이하기 때문에 사용을 지양합니다.
필요한js는 가급적 그때그때 코딩하는 편이 사용자 측면에서 유리하고 불필요한 UI 용 js 는 지양해야 합니다. DOM 객체를 이용한 표준 스크립트 사용을 권장합니다.
table 코딩시 마크업페이지 용량이 증가하며, 비표준이므로 지양합니다. 가급적 맞는 태그 사용을 하셔야 렌더링 속도가 빨라지며 용량 감소 및 유지관리가 편해 집니다.

==참고 페이지========================================================================================
http://openweb.or.kr/?p=1703                                               웹앱 추천게시글 _ 09년 12월 게시
http://lifehack.kr/90097555023                                               디자인 포인트 7 _ 10년 10월 게시
http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=36538 마소 센차터치 소개칼럼 _ 10년 12월 게시
http://w3labs.kr/?p=326                                                        jQuery Mobile 과 Sencha Touch 비교 게시글 _ 11년 3월 게시
http://www.w3c.or.kr/Translation/mwbp_flip_cards/               모바일화를 위한 10가지 가이드
http://www.slideshare.net/guruguru/html5-on-mobile              HTML5 on Mobile _ 10년 7월 게시
http://www.slideshare.net/guruguru/2011-web-technologies   웹&모바일 기술전망 2011 _ 11년 2월 게시

== 정의 ============================================================================================
모바일 웹
브라우저에서만 실행이 되고 가장 일반적인 웹

네이티브앱
응용프로그램을 폰으로 다운받아서 설치하여 사용하는 어플

웹앱
웹앱은 만드는것은 모바일 웹과 같다고 보시면 됩니다. 여기에서 웹을 실행하는 방법이 다르다고 생각하시면 될듯합니다.

예를 들어 아이폰 같은 경우 브라우저에서 웹을 보시면서 홈으로 가기 버튼을 만들수 있습니다.

거기서 홈으로 가기 버튼을 누르고 바로가기 버튼을 만들게 되면, 실제로 만들어진 것은 웹이지만 실행하는 것은 앱과 같은 방식이 되게 됩니다.
여기서 일반 앱(네이티브 앱)과 다른 점이 연락처, 메일, 문자보내기등 Device의 기능을 사용하지 못하는 것이 가장 큰 차이점입니다.

하이브리드 앱 (적용 사이트 m.gsshop.com)
웹표준을 준수한 모바일 웹을 만든 이후에 앱에 연동하는 형태로,
어플을 다운받거나 도메인을 입력해 접속해도 동일한 형태의 모바일 페이지를 볼 수 있습니다.

Javascript, CSS, Html로 개발을 하지만 웹앱의 단점인 Device의 기능을 Appspresso의 프레임 워크를 이용하여 사용합니다.
꼭 앱내에 폰갭이나 에스프레스를 이용하여 html, css, js를 심으실 필요는 없고 앱에 웹뷰를 설치하고 디폴트 주소설정을 원하는 url로 해도된다고 합니다.
1. 앱내에 심을 경우
- 이미지, HTML, CSS등이 자체내에 심어져 있어 로딩속도가 빠릅니다.
- 수정변경 사항이 발생시 앱 업데이트를 통해 진행해야 하므로 즉시성이 떨어진다.
- 확장성이 약하다.(앱내 삽입이므로)
2. 서버호출의 경우
- 3G망이 점점더 과부하 상태가 지속되는 상황에서 로딩속도가 느리다.
- 수정변경 사항 발생시 앱 업데이트 없이 자체 html등 수정으로 즉시 처리가 가능하다.
- 앱과 별도로 서버에서 수정이 가능하므로 확장성이 강하다.



출처: http://blog.naver.com/rasany/40130027896

그냥 일반적으로 검색해서 나오는 word-wrap 방법들은 뭔가 하나씩 안됨.

테스트 결과 다 되는 것 찾았음..

<style type="text/css">

table {

 table-layout:fixed;

}

p {
 width: 300px;
 border:1px solid red;
 word-wrap:break-word;
 word-break:break-all;
}
.wordBreak {
 font-size:0;
 line-height:0;
}

</style>

<script type="text/javascript">
//<![CDATA[
function wordBreak(element) {
 element.innerHTML = element.innerHTML.split('').join('<span class="wordBreak"> </span>');
}
//wordBreak(document.getElementsByTagName('div')[0]);
wordBreak(document.getElementsByTagName('p')[0]);
//]]>
</script>

<table border="1" width="500px">
 <tr>
  <td width="100px">가나다라</td>
  <td width="300px"><p>
 http://search.naver.com/search.naver?where=nexearch&query=%BC%D2%B3%E0%BD%B4%EB+%C4%AB+%B8%F1%B7%CF&sm=top_hty&fbm=1
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 일이삼사오육칠팔구십일이삼사오육칠팔구십일이삼사오육칠팔구십일이삼사오육칠팔구십일이삼사오육칠팔구십
 </p>

</td>

  <td width="100px">가나다라</td>
 </tr>
</table>

</body>
</html>


출처 :  http://blog.naver.com/yjhyjh5369/80112540094

png의 용량을 가볍게 줄여주는 프로그램. png건틀렛.

포토샵에서 png를 저장할 경우 파일에 포토샵등등의 시리얼? 등이 붙어 파일이 무거워 지는데 그런것들을 모두 지워 가볍게 줄여주는 프로그램이라고 한다. 즉 파일을 어떻게 저장했는지 추적이 불가능하게끔 만들어 어둠의 경로(?)로 포토샵을 쓰는 사람들에게 아주 유용한..-ㅅ-;ㅋ 프로그램이라고.

방법은 드래그앤 드랍으로 파일을 올리고 Main Option에서 저장될 브라우저를 지정해준 후 (드래그앤드랍한 폴더..즉 같은경로에 저장하려먼 Overwrite 을 체크해주면 된다.) Optimize!를 눌러주면 된다.

PNGGauntlet-2.1.3.exe

몰랐습니다.........예전부터 있었다는데 -ㅅ-;ㅋ
이미지가 없을경우 대체 이미지로 뜨는것. 이걸로 해결 할수 있음. 그런데 이게 표준이 맞는걸까? 일단 4대 브라우저에서 모두 되는것을 확인.




# 예시

<img src="XXX.jpg" onerror='this.src="http://xxx.com/image/public/illust_picture2.gif"' />

# Script

<script language="JavaScript　" type="text/JavaScript　">
function imgError()
{
event.srcElement.src = "http://xxx.com/image/public/illust_picture2.gif";
}
var all_img=document.getElementsByTagName("IMG")
if(all_img.length > 0)
{
 for(var i=0;i<all_img.length;i++)
 {
  all_img[i].onerror=imgError;
 }
}
</script>



/***************************************************************************************/

http://pat.im/801

위 주소에서 자세한 내용을 확인할 수 있었다.

표준에서는  구조와 동작을 분리하기에 img 안에 스크립트 넣는것을 오류로 처리한다.
이것 하나 때문에 여러가지 처리를 해주는 것에 대해 의견이 분분한듯. 위 링크에서 해결책을 제시해주었다.

http://www.ilovepc.co.kr/bbs/tb.php/software/603/7ede72fea18a5799f5d3c660a2f7899a

재배포 금지 -ㅅ-???

점점 사람이 덜 필요한 방향으로 진화하는듯...

예전에 링크해놨던 글인데 다시 읽어봐도 많은걸 생각하게 한다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ



지금 만들고 있는 사이트 (오픈해야 url을 연결할..텐... OTL) 마무리단계에서 시각장애인 실제 사용성 테스트를 맡기고 검사 결과에 대해 이야기하기 위해 시각장애복지관에 다녀왔었습니다.

스크린리더기는 현재 이슈 된 장차법과 연관되어 테스트를 해보고 싶어하는 분들이 많을꺼라 생각되어, 사이트에도 내용 정리해서 올라가지만 먼저 블로그에 짧게 리포팅 해봅니다.

그 전에 시각장애인의 웹 이용에 대해 이해를 위해 http://www.iabf.or.kr/ 사이트 메인에 보면 "웹 접근성 동영상, 시각장애인의 컴퓨터 활용-전맹, 시각장애인의 컴퓨터 활용- 저시력인" 동영상 3가지 있는데 보시면 도움이 많이 됩니다. (백문이불여일견! 있는 자료들을 최대한 활용해 보아요) /*  명함사이트로 바뀌었네요.. */

위 영상과 중복되는 내용도 조금있을 수 있으며, 기본적으로 시각장애가 있는 경우 웹 이용시 바라는 점에 대해 적고 있는 부분도 있으니 그 부분에 대해 양해를 먼저 바랍니다.

1. 테스트한 스크린리더 프로그램: 센스리더 프로페셔날 (옵션은 기본 설정) 
   주로  테스트한 부분은 메인, 회원가입, 게시판 글 남기기, 검색
   브라우저의 타이틀부터 읽어 내려갑니다.
   페이지내 이동은 키보드 방향키로 동작. (상하좌우)
   참고: 스크린리더가 브라우저 전체를 쭉 읽는 것과 키보드로 위치 이동할 때 읽는 방법이 약간 차이 납니다.
   (title과 label 읽는 것이 틀려짐)
   
2. h을 어떻게 읽을까? 
   - <h2><img src="h2_title.gif" alt="회사소개"></h2> : ♪ 헤딩이 회사소개 이미지
   - <h2>회사소개</h2> : ♪ 회사소개 헤딩이
   위와 같이 이미지와 텍스트인 경우 읽는 순서가 틀리므로, 헤딩들끼리의 규칙성 등을 염두하여 문서 구조화 알기 쉽게 헤딩을 이미지 또는 텍스트로 통일하였으면 하셨음. (한 페이지내 헤딩이 너무 많은 경우도 좋지 않다고 함)  개인적인 의견으론 센스리더 제작사에 통일 요청을 드리는 것이 좋겠다는 생각을 합니다. 개발하는 입장에서도 이용하는 입장에서도 약간 혼동의 소지가 있는 것 같습니다.
   
3. alt와 title의 혼재 시
   <a href="notice.html" title="공지사항"><img src="moer.gir" alt="더보기"></a>: ♪ 공지사항 그래픽 링크
   이전 버젼에서는 a태그 내의 타이틀을 처리하지 않았으나, 접근성에서 타이틀의 비중이 높아집에 따라 타이틀의 처리 순서를 상위로 배치 하면서 이미지의 alt 태그를 읽어주지 않는 현상이 있었음. 이 부분도 h와 같이 의견을 드려보는 것이 좋을 것 같다는 생각입니다. 다른 문제가 없다면요.
   
4. 스크린리더의 옵션들에 대해
   - ctrl + F6키의 조합으로 헤딩간 이동 가능 (시멘틱마크업의 필요성을 다시 한번!)
   - display 속성을 읽거나  읽지 않도록 선택 가능
      (디자인적으로만 안보이게 하는 경우는 display: none 아닌 visibility: hidden 속성을 이용하도록 하자)
   - 프로그램 실행시 포커스가 안 보이나, 옵션에서 가상커서 보이게 하면 나타남.
   - 링크는 띄어 읽음. (키보드로 한줄 내려야 인식)
     예)  네이버바로가기<a href="http://naver.com">네이버</a> :  ♪ 네이버바로가기 (멈춤) 네이버 링크
   - 특수기호 및 부호들은 옵션에서 읽기 설정해 주어야지 인식.
     예) 처음 -> 끝 :  ♪ 처음 끝 (중간에 있는 기호들은 기본 설정은 안 읽게 되어 있음)
   
5. 대체 텍스트, 테이블에 대한 설명은 간단, 명료하게.
   - 게시판 설명은 굳이 필요없게 느껴진다는 의견.
   - 게시판 버튼의 경우 일반 링크와 input 버튼 속성이 혼재되어 사용하였는데, 하나로 통일하는 것이 좋을 듯.
   - 대체텍스트가 굳이 필요없는 경우는 (텍스트와 중복 설명이 되는 경우가 간혹 발생할 수 있음) alt="" 이런 식으로 처리하는 것이 도움이 나음.
   - 첨부파일이 만약 3개인 경우 첨부파일하고 한 영역에 3개의 첨부파일폼을 넣는 것 보다, 첨부파일1 -첨부파일 입력폼1 이런식으로 각각 매칭시켜주는 것이 인식에 더 용이.
   
6. alert?
   - 접근성 항목 중 자바스크립트 부분에 대해 예민하게 고려하게 되너 alert를 거의 배제 하고 작업 진행 함.
   - 로그인 성공 시 자동으로 로그아웃으로 설정이 바뀌는 것 외에 추가로 로그인 되었다고 알려주는 정보가 없음.
   - alert 같은 경고창으로 소리와 함께 로그인 되었다는 상태를 안내해 주는 것이 직관적으로 로그인 되었음을 느낄 수 있음.
   
7. 추가 이야기들.
   - 시각장애인 전용 사이트는 본 웹사이트와 동일한 정보 제공 및 업데이트가 이루어지지 않는다면 있어도 도움을 직접적으로 받기 어렵다고 합니다. 개인적으로도 시각장애인 전용 사이트를 두고 있는 곳들을 보아도 정보의 차별과 업데이트의 문제점을 가지고 있는 경우가 많았습니다. 그리고 TTS 솔루션을 이용하여 편의를 높였으나 스크린리더와 충돌을 막지 못하는 경우도 있었고요.
   
   - 브라우저 어떤 버젼을 많이 사용하시는지 여쭈어 보니 IE 6을 주로 사용한다고 합니다.
   IE7 등의 화면확대 등 부가 기능과 IE 6의텍스트 확대 기능을 쓰시는지에 대해서도 이야기를 나누었는데, 새로운 운영체제의 발표와 실제 스크린리더기의 업데이트 기간의 차이에 대해 이야기를 주신후 손에 익은 부분도 있어 쉽게 업데이트하기 어렵다는 이야기를 하셨습니다. 이 부분은 보편적인 사용자들도 큰 혜택등을 느끼지 못하면 업데이트를 하지 않기도 하죠 ^^; 웹 개발자를 살려주세요! 캠페인 생각도 잠깐 났습니다 :)
   
   - 웹사이트 내에서 글자색, 배경색, 크기를 조절할 수 있는 기능을 제공하는 것이 도움이 된다고 합니다.
   테스트를 하여주신 분은 약시로 흰색바탕에 검은 글씨는 눈이 부셔서 보기 어렵다고 합니다. 외국의 화면확대 프로그램에서 화면 반전모드를 이용하여 보는데, 그런 경우 일반 사진들도 반전 된 칼라로 나와 아쉽다고 하네요.
   
   - 이용하기 좋았던 웹사이트가 있었는지에 대한 물음에는 먼저 이용할 수 있는 사이트들이 제한적이며 네이버, 다음 같은 경우 많이 좋아졌다는 이야기를 주셨습니다. (모두 화이팅!)

음.. 몇가지 더 메모한 것들이 있는데 수첩을 회사에 두고 와서 -_-;; 잘못 된 내용이 있으면 정정해 놓겠습니다;;

일단 여기까지 정리해 보겠습니다.

시각장애인복지관 엘레베이터안 교육일정 안에는 스크린리더 교육도 있었습니다.

국내 시각장애인 분들 중 컴퓨터를 이용하시는 분들은 소수입니다. 그 중에서도 웹에 접속하고 시각장애인 전용 사이트가 아닌 일반 웹을 서핑하시는 분들은 얼마나 될까요? 대략 천여명 안팎일꺼란 이야기들 들었습니다.

'에이. 이 소수의 사람들 때문에 (일명)크로스브라우징 맞추기도 힘든데 우리가 이런 고생을 해야해?' 이런 생각보단

'최소한의 접근성이라도 보장되는 사이트들이 많이 늘어나서, 사이트 이용에 두려움 없이 자유롭게 웹을 이용할 수 있는 환경을 만들어야 겠구나' 란 생각을 해 보는 것은 어떨까 합니다. 웹의 탄생과 기본 배경을 생각해 보는 것도 좋겠죠 ^^

개인 공간이니 사족이 길어졌지만, 모두 힘내서 좀 더 나은 웹을 만들어 봅시다~ 아자