Microsoft – a future vision

이제 검색도, 정보수집도 실시간으로

실시간 검색이란 개념이 있습니다. 트위터에 올라오는 데이터를 검색하거나, 구글이 SNS에 올라오는 데이터들을 수 분내로 검색결과에 반영하는 것들이 실시간 검색의 대표적인 모습이었습니다.

그런데 엄밀히 이야기하면 실시간은 아니고, ‘거의 실시간’ 검색입니다. 올라오는 족족 바로 바로 검색되는 것은 아니고 검색엔진이 크롤링 한 후 인덱싱해야 검색이 되는 것이기 때문에 실시간은 있을 수 없겠지요. 기존의 검색 패턴과는 확연히 다른 검색 속도 때문에 실시간이라는 수식어가 붙었을 뿐입니다.

이번에 새롭게 발표되어 관심을 모으고 있는 라이브K라는 서비스도 실시간 검색을 표방하고 있습니다.

관련 주소 : http://www.livek.com

라이브K가 구체적으로 어떻게 동작하는지 기술적인 부분은 모르겠으나, 기존의 검색엔진들이 사용하는 크롤링하여 DB에 저장한 후에 이를 인덱싱하는 과정을 생략하거나, 혁신적으로 개선하여 거의 실시간으로 검색을 하는 것이 아닌가 싶습니다.

라이브K에는 실시간 검색 위젯도 제공하고 있습니다. 아래와 같이 이러닝이라는 키워드를 검색하여 블로그에 붙일 수 있도록 지원합니다. 이러닝 블로그에도 붙여 놓았습니다.

‘이러닝’ 관련 실시간 검색 : http://www.livek.com/#%EC%9D%B4%EB%9F%AC%EB%8B%9D

아이폰앱도 제공하는 군요. 이슈가 되고 있는 기사나 정보를 보여줄 수도 있고, 자신이 관심 있는 키워드에 대한 검색 결과도 보여줍니다. 아래는 이러닝이라는 키워드의 실시간 검색 화면입니다. 실시간으로 ‘감시 중’이라는 표식으로 아이콘이 뱅글뱅글 돕니다.

바야흐로 실시간이 대세인 시대입니다. 구글의 RSS 리더인 구글 리더도 pubsubhubub이라는 프로토콜을 통해 실시간 정보를 구독할 수 있다고 합니다. RSS 피드도 실시간으로 받아볼 수 있는 시대에 이제 검색도 실시간 검색이 점점 활성화 되어가고 있는 듯 합니다.

관련 글 : http://kr.geek2live.org/303

정보의 활용 주기가 점점 짧아지고, 정보 축적의 양도 비약적으로 증가할 것입니다. 이러한 세상에서 우리가 어떻게 정보를 습극하여 활용할 것인지 나름의 전략을 세워놓지 않는다면, 머지 않은 시대에 도태될지도 모릅니다. 예전에는 ‘우리 부장님은 너무 고리타분해…’라고 이야기하던 윗세대의 안타까움이 나에게 언제 닥칠지 모릅니다. 그 전에 준비해야 할 것 입니다. 끊임없이 변화하고, 노력하면서 말이죠.

 

 

출처 : http://www.heybears.com/2512777

미래의 인터넷은 ‘아우터넷’

요즘 아이폰의 등장으로 우리 사회에는 여러 분야에서 새로운 변화가 싹트고 있습니다. 그 중 하나로, 물론 스마트폰에서만 가능한 기술은 아니지만 스마트폰이 그 중 특히 아이폰에서 ‘증강현실’이라는 새로운 분야의 기술이 떠오르고 있습니다.

증강현실은 ‘Augmented Reality’를 우리말로 번역한 용어인데, 사실 처음 들어서는 이해하기가 쉽지 않은 것 같습니다. ‘augment’는 늘리다, 증가시키다 라는 뜻의 단어로, 여기에 ‘-ed’를 붙여 형용사를 만든 것입니다.

아이폰을 구매하신 분들은 아마 증강현실 관련 어플리케이션을 하나쯤은 사용해 보셨을 겁니다. 아이폰 카메라로 길거리를 촬영하였을 때 그 곳에 있는 커피숍을 보여주고 그 곳 정보도 카메라 화면에 띄워주는 어플리케이션도 있지요.

이 기술이 요즘 기술의 발전이 가져올 폭발력 때문에 많은 관심을 받고 있는 중입니다. 가장 쉽게 상상해 보건대, 앞으로 내비게이션은 모두 스마트폰으로 대체될 것으로 보입니다.

영어 단어의 앞자만을 따서 요즘은 증강현실을 AR이라고도 표기합니다. 이 AR에 대한 글들이 꽤 많이 쏟아지고 있고요. 그 신기함을 보여주는 동영상들도 많이 등장하고 있습니다.

그런 동영상 중 하나를 트위터에서 소개받아 얼마전 보게 되었습니다.

그 내용은 미래 AR 기술로 인해 어떤 것이 가능해 질 것인가를 초반에 보여주고 있는데요. 앞으로는 콘택트 렌즈를 끼고 그 렌즈에 이 기술이 응용되어 잠에서 깨어 우리가 보는 모든 것에 정보가 함께 눈앞에 나타나는 세상이 된다는 것입니다.

잠에서 깨어 눈을 뜨면 눈앞에 시간을 알려주는 정보와 날씨를 알려주는 정보가 뜨고, 부엌에 가서 요리를 할 때 쳐다보는 음식 재료들은 칼로리 정보가 보여지고, 뭐 이런 식 입니다. 이거 뭐 어지러워서 살지 어렵지 않을까 하는 생각도 드네요.

그런데 사실 이 동영상의 이런 내용보다 제 눈을 사로잡은 것은 바로 그 동영상에서 나타난 영어단어였습니다.

‘아우터넷’(Outernet)이라고 쓰여진 단어를 보면서, 아 저 단어가 ‘증강현실’이라는 말보다도 더 쉽게 미래의 인터넷 모습을 설명할 수 있겠구나 하는 것이었죠.

미래의 인터넷은 이제 컴퓨터 안에 갇혀 있는 사이버 세상이 아니라 우리의 현실 세계를 더욱 윤택하게  만들어 주게 될 거라는 겁니다. 길거리가 게임의 배경이 되어 길거리를 다니면서 우주 괴물과 전투를 벌이는 게임도 나타날 것이고, 사진을 찍기 위해서 그저 원하는 곳에 손으로 표시를 하면 사진이 찍히게 되는 것도 가능해집니다. 내 손바닥에 글을 쓰면 그 문장이 자동으로 컴퓨터에 저장되고, 외국인과 대화를 할 때 실시간 번역도 가능해집니다. 그동안 컴퓨터 안에서만 가능했던 일이 현실 세계에서도 가능해 지는 것이 바로 AR이며, 그것이 바로 ‘아우터넷’입니다.

www.showpd.pe.kr 쇼피디 고찬수

AR, Augmented Reality, Outernet, 아우터넷, 증강현실

트랙백 : http://www.bloter.net/archives/25900/trackback

삼성, 첫 바다폰 ‘웨이브’ 공개…HW 사양·디자인 ‘호평’

삼성, 첫 바다폰 ‘웨이브’ 공개…HW 사양·디자인 ‘호평’

  주민영 2010. 02. 15 (167) 뉴스와 분석 |

삼성전자가 자체 모바일 플랫폼인 ‘바다’를 탑재한 첫 스마트폰 ‘웨이브(모델명 S8500)’을 공개했다. ‘웨이브’의 유려한 디자인과 강력한 하드웨어를 기반으로한 빠른 동작 속도는 좋은 평가를 받았지만, 뒤늦게 등장한 바다 플랫폼이 시장에 안착할 수 있을지 여부에 대해서는 회의적인 시각이 많았다.

삼성전자는 ‘모바일 월드 콩그레스(MWC) 2010′의 개막을 하루 앞둔 14일(현지시간) 스페인 바르셀로나 현지에서 ‘삼성 모바일 언팩’ 행사를 열고, 첫 바다폰 ‘웨이브’와 풀터치폰 ‘몬테’ 등 다양한 신제품을 공개했다.

이날 행사의 스포트라이트는 삼성의 독자플랫폼인 ‘바다’를 처음으로 탑재한 ‘웨이브’에 쏠렸다. ‘웨이브’는 한 눈에 보기에도 얼마 전에 공개된 삼성의 첫 안드로이드폰 ‘SHW-M100S’와 비교해 훨씬 유려한 디자인을 자랑했다. 특히 다이아몬드 모양의 홈버튼과 매끈한 뒷태가 인상적이었다.

‘웨이브’는 하드웨어 측면에서 최근에 출시된 어떤 스마트폰에도 뒤지지 않을 만큼 강력한 모습을 보여줬다. 넥서스원에 장착된 퀄컴의 스냅드래곤 칩과 동일한 속도를 자랑하는 1GHz의 프로세서를 장착으며, 블루투스 3.0과 Wi-Fi 802.11n을 지원해 무선통신 속도에서도 날개를 달았다. DivX, Xvid, MP4, WMV 등 다양한 동영상 포맷을 지원하며 HD급(720p) 화질로 동영상을 녹화하고 재생할 수 있다. 멀티태스킹도 가능하다.

또한 세계 최초로 ‘슈퍼 아몰레드’를 탑재해 넓은 시야각과 선명한 색감을 자랑했다. 삼성에 따르면 수퍼 아몰레드는 기존 아몰레드폰 대비 5배 이상 선명한 화질을 제공하며 야외시인성도 20%이상 개선됐다고 한다. 삼성의 TV 화질 기술인 mDNIe(mobile Digital Natural Image engine)을 휴대폰에 적용해 화질 향상 효과는 더욱 두드러졌다.

삼성이 ‘웨이브’에서 처음으로 탑재한 통합형 메시징 서비스인 ‘소셜 허브(Social Hub)’도 예상보다 좋은 평가를 받았다. 휴대폰 주소록을 통해 주요 사이트의 이메일, SNS, 메신저 등의 정보를 일괄적으로 관리할 뿐만 아니라 트위터, 페이스북 등의 실시간 업데이트, 이메일 작성, 채팅 등을 주소록에서 바로 이용할 수 있다.

그러나 ‘웨이브’도 단점은 있었다. 선명한 수퍼 아몰레드를 탑재했지만, 화면 크기가 3.3인치에 불과해 3.5~4.3인치에 이르는 최근의 스마트폰 화면과 비교하면 답답한 느낌을 준다. 멀티터치가 지원되지 않는 점도 아쉽다.

삼성의 터치위즈 3.0 UI는 빠른 프로세서 덕분인지 과거와 비교해 속도가 매우 향상됐지만, 그럼에도 불구하고 종종 느려질 때가 있으며, 인터페이스의 직관성 측면에서는 여전히 부족했다. (블로그 기반 미디어인 인개짓이 재빠르게 동영상을 올렸다. 동영상 보기 클릭)

삼성전자의 신종균 무선사업부장은 전세계 통신업계의 이목이 집중된 이날 행사에서 “삼성전자가 특정 소비자들에게 국한됐던 스마트폰의 영역을 모든 소비자로 확산하는 스마트폰 대중화 시대를 주도해 나가겠다”며 자신감을 피력했다.

신 사장은 “독자 모바일 플랫폼인 바다(bada) 등을 중심으로 ‘개방’을 키워드로 하는 스마트폰 에코 시스템을 만들어 가겠다”며 애플리케이션 마켓과 개발자 커뮤니티 등 모바일 생태계 구축에 박차를 가하겠다는 계획을 밝혔다. 또한  2010년에 5~7개 가량의 바다폰을 출시하겠다는 계획도 전했다.

그러나 외신의 반응을 살펴보면 전체적으로 ‘웨이브’에 대해서는 긍정적인 평가가 많았지만, 바다플랫폼에 대해서는 아직 의구심을 떨치지 못하는 모습이었다. PC월드의 지니 미스 기자는 “웨이브는 대단히 유혹적이었지만, 모바일 업계에 바다 플랫폼이 과연 필요한가에 대해서는 여전히 확신할 수 없다”고 말했다.

CCS 인사이트의 벤 우드 책임연구원은 로이터통신과의 인터뷰에서 “개발자 커뮤니티를 얻기 위한 삼성의 여정은 험난한 오르막길이 될 것”이라며 후발주자의 에코시스템 구축이 쉽지 않을 것이라고 내다봤다.

▲ 삼성전자 ‘웨이브’  세부사항 보기

bada, MWC 2010, S8500, wave, 바다폰, 삼성, 수퍼 아몰레드, 웨이브, 터치위즈 UI

트랙백 : http://www.bloter.net/archives/25663/trackback

윈도우 폰 7, 무엇이 달라졌나?

마이크로소프트(MS)가 소문대로 윈도우 폰 7의 데모를 공개했다. 기존의 윈도우 모바일 6 시리즈는 잊어도 좋다. 모든 것을 다 바꿨다. 소프트웨어 공룡 MS의 저력이 다시 한번 모바일에서도 통할 수 있다는 가능성을 보여준 것으로 평가받고 있다.

윈도우 폰 7이 보여준 변화의 핵심은 ‘라이브 타일’과 ‘윈도우 폰 허브’ 두 가지 기능에 있다. 시작 화면을 책임지는 ‘라이브 타일’과 6가지 주제별로 통합적인 사용자 경험을 제공하는 ‘윈도우 폰 허브’ 기능을 집중적으로 살펴본다.

▲ ‘라이브 타일’, 아이콘에 대한 고정관념을 깨다

윈도우 폰 7의 시작화면을 책임지는 라이브 타일은 애플리케이션을 실행시키는 정적인 역할에 머물렀던 기존의 아이콘에 대한 인식을 깨뜨렸다. 시각적으로 끌리는 레이아웃과 디테일한 움직임을 제공할 뿐만 아니라, 각각의 타일과 연관된 콘텐츠를 실시간으로 업데이트해 보여준다.

지인의 개별 타일을 생성해두면 그 사람이 최근에 업로드한 글과 사진을 실시간으로 시작화면에서 확인할 수도 있다. 이는 휴대폰을 소셜 네트워크의 터미널로써 활용하고자 하는 사용자들의 수요를 적극적으로 반영한 결과다.

▲ 통합 UX의 편리함, ‘윈도우 폰 허브’

윈도우 폰 7은 웹, 애플리케이션, 서비스의 연관 콘텐츠를 한 화면에 볼 수 있도록 ‘윈도우 폰 허브’로 통합했다. 윈도우 폰 허브는 ▲사람(People) ▲사진(Picture) ▲게임(Game) ▲뮤직+비디오(Music+Video) ▲오피스(Office) ▲마켓플레이스(Marketplace) 등 총 6개의 허브로 구성되어 있으며, 사용자들이 가장 빈번하게 활용하는 주제를 반영했다. MS는 윈도우 폰 허브를 통해 사용자에게 통합 사용자경험( UX)의 편리함을 제공하고자 했다.

1. 사람(People) 허브

지인들로부터의 실시간 피드나 사진자료 등 사람에 기반한 연관 콘텐츠를 한 화면에 묶어 보여준다. 사람 허브는 지인들의 글을 읽기만 하는게 아니라 페이스북과 윈도우 라이브에 직접 포스팅할 수도 있어 편리하다.

2. 사진(Picture) 허브

사진 허브는 웹과 PC를 폰과 연동시켜 사진 자료를 한 곳에 모아준다. 개인이 소장한 모든 사진과 영상 자료를 모아볼 수 있을 뿐만 아니라 사진이나 동영상 등을 지인들과 즉시 공유하는 기능도 있다.

3. 게임(Game) 허브

휴대폰에서 엑스박스(Xbox) 게임을 즐길 수 있다. 물론 모든 Xbox 게임을 즐길 수 있는 것은 아니다. 그러나 Xbox 라이브를 탑재해 스포트라이트 피드, 아바타, 도전 과제 목록을 확인하고 Xbox를 함께 즐기는 게이머들의 프로필도 조회할 수 있다. 휴대폰을 통해 전세계 2천 300만 이상의 XBox LIVE 가입자와 연결할 수 있게 된 것. 기존 Xbox 라이브 사용자들의 큰 호응을 받을 것으로 보인다. 이미 자사가 확보한 사용자 네트워크와 콘텐츠, 서비스를 결합시키겠다는 것. 이는 애플이 만들어 낸 전략과 유사하다.

4. 뮤직+비디오 허브

음악과 비디오에 관한 모든 것을 한 곳에 모았다. 호평을 받았던 MP3, 준HD에서 비롯된 기능이다. 단순히 음악과 영상을 감상하는 데에 그치지 않고 준 소셜(Zune Social)을 실행해 음악과 추천목록을 공유하는 기능도 갖췄다.

5. 오피스 허브

MS 오피스를 윈도우 폰에서 보다 편리하게 사용할 수 있게 됐다. 원노트, 쉐어포인트 워크스페이스 등에 연결해 문서를 손쉽게 읽고 편집, 공유할 수 있으며, 아웃룩 모바일도 지원해 메일과 일정관리도 편리하게 할 수 있다.

6. 마켓플레이스 허브

MS의 윈도우 마켓플레이스에 접속해 MS가 인증한 애플리케이션을 쉽게 찾고 설치할 수 있다. 이번 발표에서 MS는 윈도우 폰 7의 마켓플레이스 운영 정책에 대해서 구체적으로 밝히지 않았다.

15일(현지시간) 모바일 월드 콩그레스(MWC) 2010 행사에서 공개된 윈도우 폰 7은 UI 컨셉과 데모 영상에 불과하다. 따라서 구체적으로 윈도우 폰 7의 아키텍처가 어떻게 돼 있는지, 소프트웨어 개발 키트(SDK)는 언제, 어떤 모습으로 배포되는지, 윈도우 폰 7의 애플리케이션 마켓은 어떤 정책으로 운영될 지 등에 대해서 아직까지 공식적으로 확인된 바가 없다.

MS 측은 다음달에 있을 게임 개발자 컨퍼런스(GDC) 2010과 MIX 10 행사에서 게임 기능과 개발자들을 위한 정보를 구체적으로 공개하겠다고 밝혔다. 그러나 이미 외신들은 공개된 UI 컨셉과 별도 채널로 입수한 정보를 바탕으로 이 부분에 대한 보도를 쏟아내고 있다. 여러 외신의 자료를 모아 윈도우 폰 7이 추가로 변화된 점을 정리해봤다.

▲ 모든 윈도우 폰 7 시리즈 전면부에 ‘빙’으로 연결하는 하드웨어 버튼 탑재

어떤 메뉴에서건 한 번의 클릭으로 손쉽게 빙 검색을 활용할 수 있도록 했다. 이는 휴대폰 환경에서 사용자들이 더욱 손쉽게 검색을 할 수 있게 할 뿐만 아니라, 모바일 검색 분야에서 MS의 점유율을 높이는 두 마리 토끼를 잡을 수 있는 기능이다.

▲ 마켓플레이스를 통한 애플리케이션 검증, 구 버전 소프트웨어 호환 불가?

과거 윈도우 폰 시리즈가 설치파일만 있으면 출처와 관계없이 사용자가 마음대로 애플리케이션을 설치할 수 있었다. 그러나 윈도우 폰 7부터는 윈도우 마켓플레이스를 통해서 검증된 애플리케이션만 설치하는 방식으로 운영될 가능성이 높다.

또한 윈도우 폰 7이 현격한 변화를 가져온 만큼 윈도우폰 6 이하 버전과의 하위 호환성을 확보하는 것도 쉽지 않을 전망이다. 기즈모도 등 일부 외신은 MS가 하위 호환성에 발목잡혀 혁신을 하지 못했던 과거의 문제를 털어내고 과감히 하위 호환성을 포기했다고 전하기도 했다.

MS 측은 이 부분에 대해 구체적인 입장을 밝히지 않았으며 MIX 10 행사에서 전반적인 설명이 있을 것이라고 전했다.

▲ 하드웨어 요구사항 명확히 규정

MS는 윈도우 폰 7을 공개하며 각 제조사에 하드웨어의 요구사항을 명확히 규정했다. 이는 PC 운영체제가 권장사항과 필수사항을 공개하는 방식과 유사하게 OS의 원할한 구동을 위한 최소 규격을 제조사에게 요구한 것이다. 과거 윈도우 폰 6 이하의 버전이 제각각인 하드웨어로 인해 충돌과 다운이 잦았던 점을 보완하기 위한 정책으로 보인다.

chassis 1 스펙으로 알려진 이 규정에 의하면 윈도우 폰 7을 탑재하는 휴대폰은 암(ARM) v6 이상의 프로세서와 3.5인치 이상의 멀티터치 디스플레이, 512MB 이상의 플래시 메모리를 기본으로 장착해야 한다. 그 밖에 카메라와 각종 센서, 블루투스, 와이파이 등의 요구 사항도 구체적으로 명시됐다. 향후 개발 과정에서 chassis 2, chassis 3 등 각기 다른 버전의 하드웨어 요구사항이 나올 가능성이 높으며 세부사항도 조금씩 변경될 수 있다.

▲ 멀티태스킹 미지원?

외신들은 윈도우 폰 7은 과거 버전과 같은 전통적인 의미의 멀티태스킹을 지원하지 않을 것이라고 전했다. 그러나 한 애플리케이션이 실행 중일 때에도 라이브 타일과 피드를 통해 다른 애플리케이션도 사용자와 정보를 주고 받을 수 있어 모바일 환경에 걸맞는 다른 의미의 멀티태스킹의 한 유형을 보여줬다고 평가할 수도 있다. 이부분도 MIX 10에서 개발자들을 대상으로 새로운 커널과 아키텍처가 공개돼야 구체적으로 확인할 수 있을 전망이다.

▲ 실버라이트 기본 탑재. 플래시 미지원?

윈도우 폰 7은 MS가 개발한 리치인터넷아키텍처(RIA)인 실버라이트를 탑재하고 있다. ‘라이브 타일’ 기능이 실버라이트를 기반으로 제작됐다. 반면 아이폰의 경우와 마찬가지로 플래시를 지원하지 않는 것으로 알려졌다. 그러나 chassis 2 이후에는 플래시가 지원될 가능성도 열려있다

▲ 제조사나 사용자의 커스텀 UI 불가?

구 버전에서는 제조사나 사용자가 터치플로우나 모바일쉘 등 UI쉘을 설치해 시작화면을 손쉽게 변경할 수 있었다. 그러나 윈도우 폰 7은 라이브 타일 시작화면을 포기하지 않을 전망이다. 그러나 이 부분도 chassis 2 규격 이후에서는 유동적으로 변화될 여지가 있다.

▲ IE 기반의 새로운 웹 브라우저 탑재

윈도우 폰 6 시리즈는 기본 브라우저로 인터넷 익스플로러(IE) 6 버전을 탑재해 원성을 샀다. 사파리 등 경쟁사의 브라우저와 비교해 현격히 느린 성능을 보여줬기 때문이다. 알려진 바에 따르면 윈도우 폰 7에는 새롭게 개발된 모바일 버전의 브라우저가 탑재될 것이라고 한다. IE 7 데스크톱 버전에 IE 8의 기능을 가미하고 멀티터치가 가능한 빙 지도를 포함한 것으로 알려졌다.

▲ 준 음악, 비디오 서비스, 윈도우 폰 7 출시 국가로 확대

기존에 미국에서만 서비스되던 mp3 플레이어 준 HD의 음악, 비디오 서비스가 윈도우폰 7의 출시와 함께 세계 각국으로 확대될 예정이다. 애플의 아이튠즈 서비스와 유사한 모델이라고 할 수 있다. 데스크톱 애플리케이션과 모바일 애플리케이션을 통해 준 서비스를 이용하게 될 것이다. 또한 윈도우 폰의 데이터 백업 프로그램인 ‘마이폰’도 준 애플리케이션에 통합될 가능성이 높다.

[관련기사]

• MS, ‘윈도우 폰 7 시리즈’ 공개…제국의 역습 시작됐다

MS, 라이브 타일, 빙, 윈도우 모바일, 윈도우 폰 7, 윈도우 폰 허브

트랙백 : http://www.bloter.net/archives/25760/trackback

Pattie Maes and Pranav Mistry demo SixthSense

http://www.ted.com/talks/pattie_maes_demos_the_sixth_sense.html

Windows Phone 7 series

 

 

 

이러닝 환경에서 학습을 촉진시키기 위한 방법

이러닝 환경에서 학습을 촉진시키기 위한 방법

e-learning 2010/02/02 12:34 Posted by 엉뚱이

이러닝에서 환경에서 학습을 촉진시키기 위한 방법에는 어떤 것들이 있을까요? 학습을 촉진하기 위해서 고려해야 할 것들은 정말 많겠으나 동기, 시각적 요소, 사회적 상호작용, 융합 등과 같이 4가지의 관점에서 정리해 보겠습니다.

1. 동기 촉진

이러닝은 자기주도적으로 학습을 하는 환경입니다. 따라서 스스로 학습을 해야만 하겠다라는 내적인 동기가 활활 타오르면 학습은 촉진될 수 있습니다. 물론 외적인 동기를 촉진하는 것도 도움은 될 수 있습니다. 학습을 어느 정도 하면 포인트나 마일리지를 주거나 승진에 가산점을 주는 등의 방법입니다.

내적인 동기의 촉진은 꼭 학습에만 적용되는 것은 아닙니다. 우리가 적극적인 삶, 목표지향적인 삶을 살아가는 데 중요한 요인임에는 분명해 보입니다. 당연히 업무 환경에도 적용이 됩니다.

관련 글 : http://www.heybears.com/2512685

 

2. 시각적 요소 촉진

현재의 이러닝이 활용하는 오감은 시각, 청각에 국한되어 있습니다. 향후에는 모션센서, 중력센서, 진동 등을 활용한 촉각적인 요소도 많이 발전하겠지요. 그러나 아직은 시각과 청각에 의존하고 있는 것이 현실입니다. 그 중에서도 시각적인 요소가 가장 영향을 많이 줄 겁니다.

따라서 시각적 요소를 통해 학습을 촉진시킬 수 있습니다. 비주얼 검색엔진, 태그클라우드, 마인드 맵 등을 학습에 적용시켜 보는 겁니다. 단순히 머리 속으로 생각만 하고 있던 것을 시각적으로 표현하여 보여줌으로써 학습자의 생각의 확장을 가져오게 할 수 있을 것입니다.

 

3. 사회적 상호작용 촉진

상호작용도 다양한 방식으로 이루어질 수 있습니다. 최근에는 특히 사회적 상호작용에 대한 관심이 높아지고 있지요. SNS와 같은 사람과 사람 사이의 관계를 중시하는 서비스들이 인기를 얻으면서 학습에 있어서도 사회적 상호작용의 중요성이 높아지고 있습니다. 사회적 상호작용을 중심에 놓고 학습을 촉진시키는 방법을 소셜 러닝(social learning)이라고 표현하기도 합니다.

전달형 이러닝 서비스에서 참여형 이러닝 서비스로의 전환이 이루어지기 위해서는 이러한 사회적 상호작용이 필수적이라 생각합니다. 참여의 방식이 관계중심이든, 정보중심이든, 역할중심이든 간에 사람과 사람을 연결하여 학습이 촉진될 수 있는 전략의 수립은 점점 더 중요해지고 있습니다.

 

4. 융합 촉진

모든 것을 직접 만들지 않아도 되는 시대에 우리는 살고 있습니다. 이미 만들어진 것들을 잘 조합하고 융합하여 새로운 가치를 창출할 수 있습니다. 이를 매시업(mash-up)한다라고 하기도 합니다. 기술을 융합하고 생각을 융합하고 가치와 서비스를 융합하여 새로운 학습자 경험을 유발하는 것이 교수설계자의 중요한 역할이 될 것입니다. 

참고 글 : http://theelearningcoach.com/elearning2-0/10-ways-to-learn-in-2010/

Adobe AIR

어도브 에어에 대해 관심을 갖게 된 포스팅 : http://www.choboweb.com/388

어도브 에어. 이거 물건인 듯.

<Adobe사에 소개되어 있는 Air관련 내용>

어도브 사의 에어에 대한 설명
출처 : http://www.adobe.com/kr/products/air/business/

Adobe® AIR™ 런타임을 사용하면 데스크탑에 브랜드 가치를 높여주는 리치 인터넷 애플리케이션(RIA)을 제공할 수 있습니다. 이를 통해 고객과 보다 긴밀한 관계를 형성할 수 있습니다.

Adobe AIR는 웹 애플리케이션을 구축하는 데 사용한 것과 동일한 기술로 업계에서 입증된 비용 대비 효율적인 기술을 사용하므로 개발 및 배포 시간을 단축하고 리스크도 줄일 수 있습니다. 또한 기존의 웹 개발 리소스를 그대로 사용하여 모든 주요 데스크탑 운영 체제에서 실행되고 브랜드의 가치를 높여주는 매력적인 애플리케이션을 제작할 수 있습니다.

RIA 전략의 일환으로 Adobe AIR를 사용하면 생산성 향상, 시장 영역 확대, 고객 만족도 개선, 고객 로열티 증가, 비용 감소, 수익 증대 등의 다양한 혜택을 누릴 수 있습니다.

관련 글1 : Silverlight와 Adobe AIR, 구현 사례를 모아 볼까요?
관련 글2 : Adobe AIR 에 낚이다.. 퍼덕퍼덕..

이러닝 업계에 있는 사람도 관심을 가질만한 물건으로 생각된다. 이런거 보면 삘이 팍 온다. 별거 아니라고 생각해 봤는데, 웹초보님께서 소개한 DestroyFlickr를 설치하고 몇 번 깔짝 거려본 결과 삘이 온다. 관심있는 사람들은 적용해 보기를...아... 이럴 때는 정말 기술 하나 쯤은 배우고 싶다. 생각한거 그냥 내가 구현해 보게...

<Adobe Air로 개발한 DestroyFlickr라는 놈. air라는 검색어로 검색한 결과 화면이다.>

Silverlight와 Adobe AIR, 구현 사례를 모아 볼까요?

최근 Silverlight와 Adobe AIR에 대한 관심이 매우 높습니다. 두 회사의 치열한 경쟁과 홍보전 덕에 많은 이가 이에 대해 이야기 하고 있죠. 그리고 그 근간에는 UX와 시각화에 대한 꽤 오래된 트렌드가 존재합니다. HCI (Human-Computer Interaction)라는 이름으로 오랫동안 연구되어 온 주제죠. 그리고 그러한 연구 결과가 소프트웨어와 하드웨어의 발달에 힘입어 최근 구체화 되고 있는 것이라 볼 수 있습니다.
 
그렇다면 이러한 트렌드가 확고히 존재한다는 관점에서 Silverlight와 AIR의 성공 가능성을 사례 중심으로 한 번 살펴 보는 것도 의미 있는 일일 것입니다. 혹시나 모르고 있는 케이스가 있다면 서로 내용을 공유하는 것도 좋겠죠.
 
우선 얼마 전 공개 된 SBS의 NView입니다. Silverlight 기술을 적용한 케이스죠. 유사한 형태의 인터페이스를 많이 보아 왔기 때문에 감탄사가 절로 나올 정도는 아닙니다만, 날씨와 관련 영상, 투표 등을 한 화면에서 기존에 보던 동영상을 바꾸지 않고도 확인할 수 있다는 점은 꽤 유용합니다. 그리고 일반인을 대상으로 하는 서비스 중 나름 대형 업체가 채택한 사례라는 점이 의미가 있겠습니다.
 

[그림 1 : SBS Nview]

해외 사례로는 얼마 전 화제가 되었던 Tafiti를 들 수 있겠군요. 검색 결과를 시각화하여 보여 주고, 그 프레임웍으로 실버라이트를 적용한 사례입니다. 사실 기능적으로 뛰어나다기 보다는 새로운 형태의 UX 가능성을 보여 주는 사례로 생각하는 것이 좋겠습니다.
 

 [그림 2 : Microsoft Tafiti]

Adobe 기술의 경우 웹 애플리케이션에 적용된 사례는 너무나도 많습니다. Flash를 부분적으로 채용한 경우는 셀 수 없을 만큼 많고, Flex도 최근에는 많이 사용되고 있습니다.
 
GSeshop의 경우 많은 기능을 Flex를 이용하여 제공하고 있습니다. 이러한 기술을 채택함으로써 사용자에게 한 화면에서 편리하게 물건을 검색하고 구매할 수 있게 해 주는 것이죠.
 

[그림 3 : GSeshop]

또한 얼마 전 개편한 Yes24의 영화 섹션 역시 Adobe의 기술을 적용하여 한 화면에서 모든 예약 프로세스를 처리할 수 있게 되어 있습니다. CGV가 이러한 개념을 도입한 후, 대부분의 영화 사이트가 채용하고 있는 방식입니다.
 

 [그림 4 : Yes 24 영화]

AIR의 특징인 데스크탑과의 연동에 관해서는 국내 사례를 발견하지 못 했습니다. 해외의 경우라면 Digg의 설립자인 케빈 로즈가 만든 Pownce를 예로 들 수 있겠습니다. P2P로 메시지, 링크, 파일, 이벤트 정보 등을 공유할 수 있는 서비스이죠. Digg만큼의 성장을 거둘 것인가는 의문이긴 합니다. 하지만 로컬 파일을 마음껏 접근할 수 있다는 점을 보여 준 것을 그 의미로 볼 수 있겠습니다.
 

[그림 5 : Pownce ]

이런 사례들은 상기한 기술들의 현 상태를 보여 줍니다. 사례들을 가지고 이야기 해 본다면, Flash와 Flex는 이미 어느 정도 확산되어 있는 상태로 일반적인 사용자에게 거부감 없이 받아 들여지는 수준까지 와 있다고 볼 수 있습니다. 반면에 Silverlight와 AIR는 아직 대중적으로 받아 들여지는 상태까지는 오지 못 했고, 그 선을 넘으려고 하는 상태로 보입니다.
 
이 선을 넘기 위해 각 사는 자사 기술을 도입한 사례를 Showcase를 통해 알리고 있습니다. 이러한 사례들을 제공함으로써 자사 기술을 도입하는 결정을 내리게 하고 싶은 것이죠. 다음의 링크에서 Showcase 포함된 사례들을 확인하실 수 있습니다.

Silverlight Showcase : http://silverlight.net/showcase/Default.aspx
Adobe AIR Showcase : http://labs.adobe.com/showcase/air/
 
이렇듯 RIA 기술을 이용한 사례는 늘어나고 있고, 이는 사용자의 사용성 강화와 감성적 충족이라는 트렌드에 매우 잘 부합합니다. 또한 국내에서도 다양한 시도들이 진행되고 있는 것으로 알고 있습니다. 혹시 Silverlight와 AIR 관련 사례를 알고 계시다면 댓글과 트랙백을 남겨 주세요. 정보를 모아 국내 적용 사례 Showcase를 한 번 만들어 보죠. :)

 

RIA 플랫폼 전쟁을 바라보며…

김도형 dynaxis@alticast.com 양방향 TV 솔루션 개발을 해 왔고 현재는 DMB를 위한 자바 규격 표준화와 제품 개발을 맡고 있다. JSR 242, JSR 272 등 방송 관련 JSR에 전문가로 참여했으며, 자바 외에 프로그래밍 언어 전반, XML 등 다양한 분야에 걸쳐 관심을 가지고 있다. 2007년 6월 12일

RIA(Rich Internet Application)는 웹 서비스의 장점은 유지하면서 기존 웹 브라우저 기반 인터페이스의 단점인 늦은 응답 속도, 데스크톱 애플리케이션에 비해 떨어지는 조작성 등을 개선하기 위한 기술을 말한다. 원래 2002년에 매크로미디어(2005년에 어도비가 매크로미디어를 인수했다)가 자사의 플래시를 활용한 웹 인터페이스를 지칭하기 위해 만들어낸 용어지만, 관련된 시도는 이미 1990년대 말부터 있었으며 지금은 AJAX, 플래시, 자바 애플릿 등 얼핏 연관 없어 보이는 기술을 통칭하는 느슨한 용어로 쓰이고 있다. 최근 마이크로소프트는 실버라이트(Silverlight)라는 RIA 기술을 소개하면서 Rich Interactive Application이라고 풀어 쓰기도 하니 참고하자.
원래 문서 형태로 공유하기 위해 만들어진 웹이 졸지에 애플리케이션 플랫폼 역할까지 하다 보니 여러 장점에도 불구하고 슬슬 사용성 등에서 불만이 터져 나올 때가 되기는 했다. 이런 상황에서 최근 업계에서는 RIA라는 이름 하에 다양한 솔루션을 내어 놓고 있지만 가만히 살펴보면 각양각색이다.
구글은 AJAX를 바탕으로 가능한 브라우저 기반 서비스를 개발하는 것으로 유명하다. 특별한 경우가 아니면 플래시 사용까지도 자제한다. 최근에는 아예 브라우저에 없는 요소를 추가로 개발, 공개해 개발자를 자기 편으로 끌어 모으는 좀 더 적극적인 전략을 펴고 있다. 한편 플래시라는 훌륭한 무기를 가지고도 어딘지 밀리는 느낌이 들었던 어도비도 최근 자사 소프트웨어 일부를 오픈소스로 풀면서 상황 반전을 꾀하고 있고, 썬으로 대표되는 자바 진영, 그리고 마이크로소프트도 본격적으로 RIA 시장에 뛰어들었다.
그야말로 차세대 애플리케이션 플랫폼 정복을 위한 RIA 전쟁의 시작이라 해도 과언이 아닐 것이다. 하지만 RIA를 외치는 오늘에는 그에 이르게 한 과거와 배경이 있고, 각 해법에는 자기 입장대로의 꿍꿍이 속이 있고 허점이 있기 마련이다. 이 시점에서 오늘에 이르게 된 배경을 살피고 그를 바탕으로 각 기술의 장단점과 허점을 조명해 보는 것은 나름대로 의미가 있을 것이다.

위로

서비스 구조 변천사

개인용 컴퓨터의 성능이 비약적으로 발전한 오늘날도 우리는 여전히 서버에 접속하고 있다. 초기에는 혼자 쓰기에는 컴퓨터가 너무 비싸서 공유해야 했고, 컴퓨터가 어느 정도 대중화된 후에도 기업 내에서 정보를 통합 관리하고 공유할 필요가 있었다. 이 때문에 서비스를 제공하는 컴퓨터와 사용자가 접하는 단말까지를 어떻게 구성해야 하는가에 대해 다양한 시도가 있어 왔다.

터미널 시대
1970년대에 등장해 메인프레임 내지 서버에 직렬 통신으로 연결돼 서버가 전달하는 문자나 제어 문자를 해석해 화면에 뿌려주고 사용자가 입력하는 키를 서버로 전달해 주던 텍스트 터미널이나, 1990년대 전성기를 맞아 얼마 간의 CPU와 메모리, 흑백 내지 컬러 그래픽 장치와 키보드, 마우스를 장비하고 그저 LAN으로 연결된 서버가 보내는 명령을 해석해 그림을 그리고 키/마우스 입력을 서버로 보내기만 했던 X 터미널(X11 기반)은 그저 단말 가격조차 부담스럽던 시절, 단말의 기능을 최소화하려는 노력이었다.
하지만 이런 구조는 웹 애플리케이션과 마찬가지로 단말 관리가 쉽고 애플리케이션을 갱신하는 부담이 없다는 숨은 장점이 있었다. 거기다 조작성도 좋았다. 이 때문에 씬 클라이언트(thin client) 개념이 대두되면서 윈도 터미널의 등장으로 한번 더 조명을 받게 되는데 불행히 그 장점만 내세우기에는 시대가 한참 앞서나간 후였다.

팻 클라이언트 시대
그 후 클라이언트/서버 구조, 다운사이징이 화두가 되면서 굳이 다수가 공유하는 정보가 있거나 서버만 처리할 수 있는 특수한 일이 아니면 업무를 클라이언트 측에서 분산 처리하게 됐다. 그러다 보니 클라이언트 애플리케이션이 오늘날의 데스크톱 애플리케이션과 마찬가지로 작성돼야 했다. 따라서 최소한 응답성과 사용성은 비교적 만족스러웠다. 하지만 패키지 소프트웨어와 달리 서비스를 위해서는 전용 애플리케이션이 있어야 했고 변경이 잦아야 했기에 파워빌더, 델파이, 비주얼 베이직 같은 RAD(Rapid Application Development)가 전성기를 누렸다.

웹 애플리케이션 시대
이러던 것이 웹이 등장하면서 웹 브라우저를 범용 클라이언트로 사용하는 웹 애플리케이션 개념이 주목을 받기 시작했다. 웹 브라우저는 많은 사람들이 익숙한 클라이언트였고 OS 등 플랫폼을 타지 않았다. 굳이 별도로 애플리케이션을 배포, 갱신할 필요도 없었으며 무엇보다도 정형화된 시스템 구조와 개발 절차를 제시함으로써 서버 및 클라이언트 쪽 모두를 아우르는 전체 시스템 개발과 테스트 복잡도를 낮춰주었다. 또한 적절한 규모의 기업 시스템은 물론이고 대규모 인터넷 서비스에도 잘 맞았다. 하지만 결국 다시 사용성과 응답성이 문제가 되기 시작했고, 네트워크가 끊어졌을 때도 사용할 수 있었으면 좋겠다는 요구가 자연히 머리를 들게 되었다. 이 때문에 나온 개념이 RIA다.

웹을 건너뛸 수도 있었던 자바
이런 흐름 속에서 놓쳐서는 안 되는 것은 자바의 등장과 데스크톱에서의 실패다. 물론 자바 UI 수요가 없다는 말은 아니니 민감하게 반응하지 말자. 하지만 자바 초기에 썬은 분명 모든 자원을 서버 쪽에 쏟았고 그 때문에 데스크톱 플랫폼으로서 자바는 분명히 부족했으니 말이다.
사실 자바는 제대로만 움직였다면 “X 인터넷”에서 이야기하는 실행 가능한 객체로 구성된 인터넷 시대의 만국 공통어가 됐을지도 모른다. 개인적으로는 1995년 자바 애플릿을 처음 접했을 때 HTML을 중심으로 하는 웹의 종말을 머리에 떠올렸다. HTML 기반의 밋밋한 웹 페이지(당시 HTML은 특히 그랬다)를 화려하게 바꿔 놨던 자바 코드는 알고 보면 웹 브라우저의 테두리를 벗어나서도 존재할 수 있었고, 클라이언트 소프트웨어 배포 문제를 해결함과 동시에 웹 브라우저의 제한된 틀을 언제든지 깨어버릴 수 있는 잠재력이 있었다. 막말로 HTML이 맘에 안 들면 뭔가 다른 형식을 만들고 그 브라우저를 자바로 만들어 배포하면 그만이 아닌가.
실제 썬은 순수하게 자바로 작성되고 확장 가능한 핫자바(HotJava)라는 브라우저와 함께 자바를 세상에 데뷔시켰고, 자바로 애플리케이션을 돌리는 디스크 없는 네트워크 컴퓨터를 만들어 이러한 기대를 일부 현실화하려고 노력했다. 물론 실패했지만 말이다. 이러한 자바의 실패에서는 배울 점이 많다. 뒤에 언급하겠지만 요즘 RIA 바람을 타고 자바도 이 분야에서 재기를 노리고 있다. 하지만 성공 여부는 미지수다.

미래는?
2000년 시장 조사 회사인 포레스터(Forrester Research, Inc.)는 "X 인터넷"이라는 개념을 주창했다. 문서를 교환하는 웹의 시대는 가고 실행 가능한 객체에 기반한 더 나은 상호작용과 더 풍부한 경험을 얻을 수 있는 새로운 인터넷의 시대가 올 거라고 예측했다(http://www.forrester.com/ER/Marketing/0,1503,214,00.html). 흔히 "X 인터넷"을 RIA 개념을 최초로 제시한 것으로 보기도 해서 RIA와 “X 인터넷”을 동의어로 취급하기도 한다. 하지만 자세히 읽어 보면 자바 같은 모델에 가까운 좀 더 구체화된 비전 제시라고 볼 수 있다. 그렇다면 오늘날 RIA가 만족시켜야 할 요구사항은 무엇일까? 포레스터의 예측처럼 실행 가능한 인터넷의 시대가 올까? 아니면 기존 웹의 틀을 가능한 지키되 보완해 나가는 형태가 될까?

위로

RIA가 갖춰야 할 덕목

과거와 현재까지 이어지는 흐름을 볼 때 새로 등장하는 RIA 전쟁의 승자는 어떤 덕목을 갖춰야 할까?

애플리케이션의 쉬운 배포
클라이언트 쪽에 많은 기능이 실리기 시작하면서 굳이 별도로 배포할 실체가 없던 이전 터미널 시대에는 겪지 못했던 문제가 대두했으니 바로 “애플리케이션 배포” 문제다. 다양한 형태와 구성의 단말에 항상 최신 소프트웨어 패키지를 배포, 설치하는 것은 생각보다 골치 아픈 문제다. 여기서 몇 년에 한번씩 업그레이드되는 패키지 소프트웨어를 떠올렸다면 곤란하다. 서비스 애플리케이션은 항상 새로운 요구 사항, 오류 등으로 지속적으로 갱신되기 마련이다. 웹 애플리케이션이 각광을 받기 시작한 이유 중 하나는 브라우저만 설치돼 있으면 별도로 애플리케이션을 배포하거나 설치할 필요가 없기 때문이었다.

조작성, 빠른 반응 속도
사실 기존 웹 애플리케이션의 조작성과 반응 속도는 이전 터미널이나 데스크톱 애플리케이션에 가까운 팻 클라이언트(fat client)에 비해 좋지 않았던 것이 사실이다. 마우스로 링크나 버튼을 클릭하고 폼을 채워 넣어야 하는 구질구질한 인터페이스는 그렇다고 치고, 항상 뭔가 변화를 보기 위해서는 서버에 접속해 처리한 후 결과를 가져와야 한다. 이런 단순한 모델은 웹을 작은 조직을 대상으로 한 서비스부터 인터넷을 매개로 한 거대한 규모의 서비스까지 두루 적용할 수 있게 한 힘이었지만 가장 큰 약점이 되기도 했다. 데스크톱 애플리케이션 수준의 조작성과 반응 속도 개선은 다름아닌 RIA를 대두시킨 주된 모멘텀 중 하나다.

오프라인 사용성
최근 네트워크 사정이 괜찮아졌다지만 그와 동시에 사람들은 더 이상 컴퓨터를 책상 위에 놔 두지만은 않게 됐다. 개인용 컴퓨터 시장의 대세는 노트북 컴퓨터고 이동성이다. 네트워크만 달랑 끊어지면 속수무책이 되어서는 이런 시대에 살아 남기가 난감하다. 개인적으로 무료면서 쓸만한 일정 관리 프로그램을 찾으면서도 구글 캘린더 같은 온라인 서비스를 이용하지 않는 이유는 바로 오프라인 사용이 불가능하기 때문이다. 물론 이런 상황은 최근 구글이 발표한 구글 기어의 등장으로 나아질 기미는 보이고 있다.

풍부한 미디어
PC와 웹의 발전이 상호 견인한 가장 큰 변화는 그 어느 때보다 미디어가 풍부한 환경을 대중화했다는 점이다. 개인 영역은 물론이고 업무 영역에서도 동영상, 애니메이션 등을 수반하는 풍부한 미디어가 일상적이게 되었다.

플랫폼 독립성
이제 더 이상 PC 하나만을 지원해서는 안 되는 시대가 왔다. 리눅스, 맥 등 다른 플랫폼을 사용하는 삶들도 존중 받아야 한다. 또 요즘 휴대전화에는 대부분 WAP 브라우저와 자바가 탑재되어 있고, 최근에는 HTML 4.01을 지원하거나 일반 웹 사이트를 브라우징 할 수 있도록 풀 브라우징(full browsing) 개념까지 들어가고 있다. DTV에도 휴대전화보다는 데스크톱에 가까운 자바와 HTML 브라우저가 탑재되고 있다. 그뿐 아니라 최근 나오는 HD-DVD는 XHTML에 SMIL 등이 탑재되어 있으며, 경쟁자인 블루레이(Blu-Ray)에는 DTV와 비슷한 형태의 자바가 탑재된다. 앞으로는 동일한 서비스를 휴대전화는 물론이고 PDA, TV 등 다양한 형태의 똑똑한 단말에서 사용할 수 있어야 할 것이다.

콘텐츠 친화적인 구조
보통 RIA는 “X 인터넷”에서 제시한 미래와는 달리 HTML 기반의 웹을 대체하는 수단으로 거론되고 있지는 않다. 문서 교환 구조인 웹과는 달리 애플리케이션 플랫폼으로서 별도의 영역을 구축할 것이라는 것이 일반적인 예측이다. 하지만 개인적으로는 RIA도 상당 경우 문서나 각종 미디어 콘텐츠를 담게 될 것이고 이런 경우 기존 웹만큼이나 검색, 링크에 의한 외부 참조 등이 중요해질 것이라고 생각한다.

웹 인프라의 활용
소규모에서 전세계적인 규모의 서비스까지 가능하게 한 웹 서비스의 단순한 구조적인 특성은 당연히 살려야 할 것이다. 단말 내부에서 어떤 형식으로 서비스가 구현되든 서버와의 연결은 기존 웹 서비스의 틀을 지켜야 할 것이다.

위로

어떤 요소가 필요한가?

앞서 언급한 덕목을 갖추기 위해서는 단순히 단말 쪽에 그럴 싸 해 보이는 그래픽을 표시하는 것만으로는 부족하다. RIA를 둘러싼 환경에 어떠한 요소가 필요할지를 생각해 보자.

저작 도구
뜬금 없이 저작 도구가 튀어 나와 어리둥절해 할지도 모르겠다. 개발 도구도 아닌 저작 도구다. 콘텐츠가 아닌 웹 애플리케이션의 경우인데도 개발 과정에 UI 전문가, 디자이너 등 개발자가 아닌 다양한 사람이 참여하는 것이 일반적이다. 더욱이 일반적인 데스크톱 애플리케이션과 과거 팻 클라이언트가 명백히 차이를 보였듯이 서비스를 위한 RIA는 계속 새로 만들어지고 더 자주 변경될 것이 분명하다. 기획 단계에서 UI 동작 때까지 복잡한 하부 로직이 붙기 전의 UI는 굳이 프로그래머가 참여하지 않더라도 쉽게 작성하고 동작해 보고 피드백 받을 수 있어야 한다. 또한 앞서 언급했듯이 풍부한 미디어가 어우러져야 하는 것은 당연하다. 이런 상황에서 도구 지원이 부실해서는 시작하기도 전에 지는 셈이 될 것이다.

플랫폼 독립적인 고속 실행 엔진
자바와 같은 플랫폼 대비 웹 브라우저의 장점은 상대적으로 단순하면서도 플랫폼 독립적이고 어디서나 비교적 동일하게 동작한다는 점이었다. 하지만 그건 웹 초기의 이야기일 뿐이다. 이미 최근 웹 애플리케이션이 브라우저를 혹사하는 수준은 도를 넘었다. 브라우저마다 다른 온갖 기능을 다 끌어다 쓰고 어마어마한 분량의 스크립트가 브라우저에서 실행된다.
주요한 하나 이상의 브라우저에서 제대로 표시되는 웹 페이지를 만들라 치면 사실상 브라우저 별로 페이지를 따로 작성하는 것과 마찬가지가 되는 경우가 허다하다. AJAX를 화려하게 구사하는 구글 서비스들도 사실 알고 보면 쉬운 일을 무척 고통스럽게 하고 있다고 볼 수도 있다(http://skyul.tistory.com/175).
그뿐인가? 이제 브라우저에서 실행되는 로직의 복잡도가 높아져 그저 스크립트 몇 줄만 실행하면 될 거라고 생각하고 만들어 놓은 스크립트 엔진들의 성능에도 빨간 불이 켜지고 있다. 최근 모질라에서는 어도비에서 기증 받은 코드로 이른바 자바스크립트 가상기계라는 것을 만들어 자바처럼 기계어로 JIT(Just-In-Time) 컴파일도 한단다. RIA 내에서는 말 그대로 포맷이 있는 문서를 표시할 일이 있는 경우가 아니라면 스크립트를 빼곡히 박아 넣은 HTML 페이지는 배제해야 하지 않을까 한다. 논쟁의 여지가 있겠지만 개인적으로는 자바나 .NET CLR(Common Language Runtime) 같은 플랫폼 독립적인 고속 실행 엔진과 잘 디자인된 라이브러리를 기반으로 하되 UI 설계시는 XML 등으로 구성된 보조적인 문법을 지원하는 편이 맞는 방향이라고 생각한다.
이는 오프라인 사용성 측면에서도 마찬가지인데 오프라인에서 동작하려면 필연적으로 단말 단의 처리 로직이 복잡해질 수 밖에 없다. 이런 경우 프로그램 로직 작성을 위한 튼튼한 기반을 가지고 있는 편이 아무래도 유리하다. 원래 서버 쪽에서 많은 처리를 하는 웹 애플리케이션이 오프라인 상태에서 동작할 때 서버 쪽 로직까지 가져올 수는 없는 법이다. 단순히 일부 자원을 단말 쪽에 가져다 둔다고 만사 해결되는 것은 아닐 테니까 말이다.

작은 플랫폼
RIA 플랫폼도 널리 퍼지려면 어쨌든 배포를 해야 한다. 이를 위해서는 RIA 플랫폼이 공룡이 되어서는 곤란하다. 초기 자바는 기능이 너무 부족해서, 그리고 오늘날에 와서는 수십 MB짜리 공룡이 된 것이 RIA 플랫폼으로 눈에 들지 못하는 것이 아닐까 한다. 어디까지가 적절한 선인지는 단언할 수 없지만 RIA에서 접근 가능한 라이브러리는 신중하게 작게 유지되어야 할 것이다. 또, 플랫폼이 커지면 거기에 수반하는 어려움이 있기 마련이다. OS가 바뀌거나 했을 때 미묘하게 다르게 동작한다거나 기능이 확장됐을 때 모든 플랫폼을 지원하기가 어려워지기도 한다. RIA 플랫폼은 데스크톱의 모든 애플리케이션을 작성할 수 있는 만능 플랫폼일 필요는 없다.

UI 및 기타 프레임워크 및 컴포넌트
RIA를 만드는 사람들은 맥가이버가 아니다. UI나 네트워킹, 데이터 처리 등의 동작을 하기 위한 컴포넌트들이 잘 디자인된 프레임워크 위에 풍부하게 제공되어야 한다. 이런 프레임워크의 존재는 다양한 컴포넌트들이 추가로 개발되고 공유될 수 있는 토양을 마련해 준다는 점에서 매우 중요하다.

미디어 엔진
풍부한 미디어는 RIA에서 필수적인 덕목이 되었다. 이런 관점에서 최소 비디오, 오디오의 효율적인 통합이 불가능해서는 게임이 되지 않는다. 최근 플래시의 약진이 다름 아닌 유튜브(YouTube) 등이 사용해 널리 알려진 플래시 비디오에 있다는 점을 잊지 말자.

위로

각 기술들의 허와 실

최근 많은 RIA 플랫폼이 출사표를 던졌다. 개인적으로 제한된 경험과 지식으로 이들을 판단하고 누군가의 손을 들어주기에는 무리가 있을 것이다. 또한 기술적인 면 이외에 플랫폼의 성공에 영향을 끼칠 수 있는 다양한 요소가 있으니 이 글에서의 평가는 그저 개인적인 평가라고 생각하고 참고만 하길 바란다.

어도비 플렉스/아폴로
RIA라는 말을 먼저 만들어 낸 어도비는 플래시라는 든든한 배경을 바탕으로 일찌감치 플렉스(Flex)라는 제품으로 RIA 시장에 뛰어들었다. 플렉스는 플래시 플레이어를 런타임 엔진으로 사용하며, 개발시 이미 만들어진 풍부한 컴포넌트를 MXML이라는 마크업 언어와 액션스크립트로 배치하고 이어 붙여 두면 최종적으로 플래시 파일 형식으로 컴파일된다. 그뿐 아니라 웹 서비스 등 다양한 데이터 소스와 UI 컴포넌트에 쉽게 연결할 수도 있다.
어도비의 장점은, 저작 도구에 가까운 도구를 가장 잘 만든다는 점과 최상의 RIA 플랫폼이라고 하기 어렵지만 버전 9까지 오면서 꾸준히 발전시켜 왔고 인터넷에 연결된 PC의 97%에 설치되어 있다는 점을 자랑하는 플래시 플레이어라는 플랫폼을 가지고 있다는 점이다. 플래시는 비디오 등 미디어 지원에 있어서도 뛰어나다.
하지만 반면에 어도비는 프로그래밍 도구나 제대로 된 단말 플랫폼, 서버 제품 등을 만드는 데는 아무래도 약점이 있다. 이런 탓에 어도비는 부쩍 오픈소스 커뮤니티와의 연대를 꾀하고 있다. 지난해 11월에는 플래시 플레이어 9에 들어 있는 액션스크립트 엔진인 AVM2(ActionScript Virtual Machine 2)를 모질라 쪽에 기여해 타마린(Tamarin)이란 이름의 프로젝트(http://www.mozilla.org/projects/tamarin)를 시작하더니, 결국 4월에는 플렉스까지 오픈소스로 공개했다.
거기다 올 초 DEMO 07에서 아폴로(Apollo)라는, 브라우저가 별도로 필요 없는 RIA 플랫폼을 데모했는데 그 자체가 오픈소스는 아니지만 내부 HTML 엔진은 오픈소스인 웹킷(맥의 사파리, KDE의 KHTML 브라우저에 사용하는 HTML 툴킷이다)을 사용하고 있으며 아폴로 개발에 따른 결과를 역으로 기여도 할 예정이란다.
이 플랫폼은 RIA 내에서 HTML을 자유롭게 사용하고 PDF 등 어도비가 가지고 있는 자원을 다 통합할 예정이다. 또, 궁극적으로 파일 I/O 등의 API를 추가해 완전한 런타임 시스템으로 거듭나려고 하고 있다.
개인적으로는 저작 도구의 지원이라는 측면에서 HTML, 플래시를 비롯한 많은 도구를 가지고 있다는 점에서 비교적 높은 점수를 주고 싶다. 하지만 궁극적으로 컴포넌트를 확장하는 사람이 늘고 단말 쪽 로직이 복잡해질 경우는 필연적으로 전문 프로그래밍 도구에 대해 목마르기 마련이다. 이런 경우 결정적인 약점이 드러나게 될 것이다. 또 한 가지 약점은 그저 벡터 그래픽에 부수적으로 붙어 있는 스크립트를 수행하기 위한 아주 기본적인 스크립트 엔진에서 시작해 큰 비전없이 확장해 온 플래시 엔진이다. 과연 얼마나 복잡한 일을 단말 측에서 하게 될 지가 관건이지만 과연 액션스크립트를 돌리는 가상 기계가 궁극적으로 성능이나 멀티쓰레딩 등을 수반하는 프로그래밍 모델에서 JVM이나 .NET CLR과 경쟁을 할 수 있을지는 의문이다. 연계된 문제점으로서는 애당초 완전한 플랫폼으로 시작하지 않은 플래시가 파일 I/O 등 API들을 붙여 나간다고 했을 때 이미 완전한 API를 정의해 충분한 시간 동안 발전해 온 타 플랫폼에 비해 역부족이지 않을까 한다.
개인적인 평을 하자면, 어도비의 접근법은 웹 상에서 플래시 플레이어의 궁극적인 경쟁자가 나타나 승승장구하지 않는 한 웹사이트의 UI를 풍부하게 하는 용도로는 활발하게 사용될 것이라고 본다. 하지만 브라우저 밖으로 벗어나는 아폴로 같은 접근법은 그다지 성공할 것 같아 보이지 않는다. 아울러 플래시도 계속해서 약점을 보강해 나가지 않는다면 어느 이상의 복잡도를 가진 웹 UI에서조차 선두를 빼앗길 수 있을 것이다.

마이크로소프트 실버라이트
한편 4월 30일부터 5월 2일까지 미국 라스베가스에서 열린 마이크로소프트의 MIX 컨퍼런스를 전후해서는 실버라이트라고 부르는 기술이 선보였다. 윈도 비스타에 포함된 WPF(Windows Presentation Foundation)의 축소판으로 코드명이 WPF/E(E는 Everywhere)였던 실버라이트 1.0은 XAML과 JScript 기반으로 벡터 그래픽 기반의 화려한 UI를 갖추고, 윈도 미디어를 통합, 답답한 버퍼링 없이 매끈하게 돌아가도록 했다. XAML은 일면 플렉스의 MXML과 비슷한 면도 있어서 플래시의 경쟁자임과 동시에 플렉스가 가진 속성까지 동시에 갖추었다. 윈도는 물론 맥OS X에서도 사용할 수 있고 인터넷 익스플로러 외에도 파이어폭스, 오페라, 사파리 등 다양한 브라우저를 지원한다.
마이크로소프트는 이에 한발 더 나아가 .NET CLR의 축소 버전을 포함시킨 1.1 버전까지 들고 나왔다. .NET CLR의 지원은 실행 엔진과 라이브러리 등의 면에서 최소 플래시와 기반이 다른 환경이라는 것을 의미한다. 1.0에 대해서는 MIX 전에 언급이 있었지만 1.1에 대해서는 “Technology X”라는 말로 궁금증만 돋우었다. 그만큼 .NET CLR의 탑재는 무게가 다르다. 전체 다운로드 크기가 .NET CLR을 포함하고도 4~5MB 수준인 만큼(윈도 기준) 무거운 자바나 .NET 풀 버전과 차별화되는 균형 감각도 보인다.
전통적으로 마이크로소프트는 단말 쪽 플랫폼과 개발 도구 쪽으로는 강점이 있고 서버 쪽도 강하다. 물론 실버라이트는 서버 측에서 마이크로소프트 제품을 사용하지 않고도 동작하도록 되어 있지만 기본적으로 개발 도구, 기반 런타임 엔진, 라이브러리, 서버 모든 면에서 충분한 지원을 제공할 수 있다는 점에서 초기 확산에는 도움이 될 것이다. 문제는 저작 도구인데 이 부분에 있어서 잘하고 있다고는 평가하기에 이르나 나름대로 해법은 내어 놓고 있다. 익스프레션 블렌드 2(Expression Blend 2)와 익스프레션 디자인(Expression Design)이라는 디자이너 도구를 내놨다. 블렌드는 플래시에 플렉스 빌더(Flex Builder)를 합쳐 놓은 것 같은 도구고 디자인은 일러스트와 포토샵을 합쳐 놓은 것 같은 도구다. 개인적으로 도구를 사용해 볼 기회는 없었는데, 디자인은 모르겠지만 블렌드의 경우 어차피 RIA를 새로 구축하는 입장이라면 충분히 승산은 있지 않을까 한다. RIA에서는 애니메이션 등의 그래픽적 요소보다는 컴포넌트를 배치하고 상호작용과 데이터를 연결하는 작업이 우선이기 때문이다.
개인적인 평가로는 현존하는 기술로는 1.1 버전을 놓고 보면 가장 막강한 RIA 환경이라고 평가한다. 마이크로소프트는 이 환경을 통해 .NET CLR, XAML 등 자사 기술의 영역을 넓혀 궁극적으로 윈도를 비롯해 모든 제품군의 입지를 다지는 계기로 삼으려는 의도가 있을 것으로 생각한다.

JavaFX
자바 쪽에서도 가만히 있지는 않았다. 올 5월 열린 자바원 컨퍼런스에서는 JavaFX가 이슈가 됐다. JavaFX는 통합 브랜드로 JavaFX 스크립트(예전의 F3 스크립트)는 자바로 플래시와 유사한 현란한 UI를 쉽게 만들 수 있도록 하는 스크립트 언어이고, JavaFX 모바일은 예전 SavaJe라는 회사의 기술을 썬이 인수해 만든 자바 기반의 휴대전화 플랫폼이다. JavaFX 스크립트는 오픈소스로 공개되어 있다.
사실 자바는 데스크톱 환경에서 RIA 플랫폼으로 의미를 가지기에는 JRE(Java Runtime Environment) 자체가 너무 크고 애플리케이션 시동이 늦는 등 몇 가지 치명적인 단점들이 있는데 이를 해결하기 위해 수 MB로 최소한의 JRE만 내려 받은 후 애플리케이션 별로 필요한 API는 필요할 때 추가로 내려 받는 등의 해법을 제시한 Consumer JRE도 함께 소개 됐다. 썬의 자바 홈페이지 우측에는 JavaFX가 Java SE/EE/ME와 나란히 걸려 있어 나름 썬의 진지함을 엿볼 수 있다. 여기서는 RIA라는 관점에서 JavaFX 스크립트와 Consumer JRE에 대해서만 살펴 보도록 하자.
우선 저작 도구나 개발 도구 측면에서 보면 여전히 부족하다. JavaFX 스크립트는 그저 그래픽 표현이 쉬운 자바의 대체 문법일 뿐 아직은 저작 도구는 차치하고 개발 도구 지원도 미흡하다.
플랫폼 자체로 봐서는 Consumer JRE가 전형적인 Swing 애플리케이션 실행을 위해 3~4MB 다운로드만 필요로 하도록 줄이고, 디스크 캐시에 미리 자바를 올려 두고, 윈도에서 좀 더 그래픽을 가속화하는 등의 노력으로 작은 플랫폼으로서의 면모를 달성하면 상황은 많이 좋아질 것이다. 거기다 야금야금 필요한 API를 받아오다 보면 궁극적으로 실버라이트와 달리 어느 플랫폼보다 풍부하고 방대한 라이브러리에 접근할 수 있게 된다. 하지만 약점은 엉뚱한 곳에 있다. 비디오, 오디오 등 멀티미디어 지원 면에서는 현재 자바는 플래시나 실버라이트에 비할 바가 못 된다.
개인적인 평가로는 지금 같은 접근법으로는 썬이 자바로 RIA 시장에서 두각을 나타내기는 어려워 보인다.

구글 방식
구글은 고집스럽게 브라우저 자체를 고집하는 것으로 유명하다. 하지만 앞서 언급했듯이 이미 웹 애플리케이션은 브라우저를 한계까지 밀어 붙이고 있다. AJAX를 구현하는 몇 가지 방법 중 하나인 XMLHttpRequest 객체의 경우 마이크로소프트가 추가한 것을 다른 브라우저에서 지원하기 시작하더니 W3C에서 표준화까지 되고 있는 경우다. 이 같이 브라우저 기능 확장은 피할 수 없는 대세다.
마찬가지로 구글은 최근 구글 기어라는 브라우저 확장을 내 놓고 이를 이용해 오프라인 동작이 가능하고 멀티쓰레드를 활용, 좀 더 반응성이 있는 AJAX 애플리케이션을 만들 수 있도록 하고 있다. 한 가지 중요한 것은 기어가 엄연히 플랫폼마다 포팅되어야 하는 브라우저 확장이라는 점이다.
이러한 시도는 구글 서비스를 활용하거나 하는 경우에는 활발히 사용될 수는 있겠지만 궁극적인 해결책은 되지 못할 것이라는 점이다. 특히 RIA라는 용어의 정의를 앞서 언급한 바와 같이 확장할 경우 현 업계의 요구 사항을 만족시키기는 어려울 것이다.

위로

마치면서

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

RIA라는 흐름은 피할 수 없는 움직임일 것이다. 아마도 위에 언급한 기술 중 한 두 가지는 분명히 열세를 면치 못할 것이다. 하지만 유력한 몇 기술은 시간을 두고 공존하지 않을까 생각한다. 개인적으로는 플래시와 더불어 실버라이트는 분명히 자기 자리를 잡을 것이라고 생각한다.
불행히도(?) 지금까지 언급한 기술들은 얼마간은 특정 회사의 자산이며, 열린 기술이라고 하기는 어렵다. 하지만 구현이 하나인 편이 분명한 장점은 있으니 다음과 같은 조건이 만족된다면 우리는 앞으로 더욱 향상된 인터넷을 사용할 수 있게 되지 않을까 한다.

• 리눅스, 맥 등 윈도 이외의 플랫폼에서도 항상 최신 버전의 RIA 엔진을 만날 수 있어야 할 것이다. 참고로 플래시 플레이어조차도 리눅스 버전이 나오는 건 항상 늦다.
• 플랫폼 내에 문서와 같은 콘텐츠를 포함할 수 있도록 지원이 향상되고 이런 요소에 대해 검색 엔진이 검색하고 해당 부분에 대해 RIA 자체에서 문제가 되지 않는 범위 내에서는(로긴이 필요하다든지 하는 문제) 직접적인 링크를 걸 수 있는 방법에 대한 표준이 정해져 서로 다른 형태의 RIA 플랫폼 간에서 공히 지켰으면 한다.
• 기왕이면 많은 기술 요소가 공개되고 가능하면 오픈소스화 되었으면 한다. 각 기술을 개발한 개발사가 기본적으로 챙겨야 하는 이득 외에는 과감하게 공개해야 해당 기술도 살고 플랫폼 활용도도 높아지지 않을까 한다.

Flex's coopetition: HTML5

It won't be ready for prime time this year, and probably not next year, but the HTML5 specification is firming up and current implementations suggest a that HTML5 will be a strong platform for RIAs. People familiar with other versions of HTML might assume that Flex would have a few advantages over HTML5: AIR (no browser required) and data services (distributed computing.) The neologism ' coopetition' might be an apt term for the relationship between HTML5 and Flex.

Here is the current HTML5 spec. WHATWG, the organization behind HTML5, describes themselves as "founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organizations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

"It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today." Market forces may accelerate the WHATWG projected time line somewhat.

I was interested to read about the HTML5 datagrid in the spec, as well as support for off-line web applications, undo support, message channels and message queues.

Here's a little fun for you (use Firefox 3.5+, Safari 4 or betas of Google Chrome or Opera. Imagine how much better the graphics would be once WebGL 3D is integrated with HTML5. That would give Flash a run for the money.

WebKit is implementing HTML5 rather quickly. WebKit is the core around which Google's Chrome and Apple's Safari browsers are built. Microsoft is sitting on the proverbial fence.

AIR uses a customized version of WebKit for HTML rendering. Every time the AIR runtime is updated, the latest version of WebKit is incorporated. Currently, the AIR documentation on how to work with the embedded WebKit engine is sparse.

How long before a software organization uses HTML5 in a non-browser container, I wonder? Oh, right, it's already been done, although that project requires software that most Windows users do not have, such as Python.  Fluid suffers from only working on Macs. Mozilla Prism is an interesting experiment, but has not gathered much momentum since it became available nearly two years ago. Appcelerator's Titanium is most promising, however.

How long before a mature HTML5-based distributed computing framework becomes a viable contender? Appcelerator's Entourage look interesting.

The future of RIA sounds like it might get very interesting, and possibly a bit more complex.

_______________________________

Mike Slinn
Independent full-service software contractor and author
Certifiied Adobe Flex 3 with AIR ACE
http://slinnbooks.com
http://mslinn.com

Rich Internet Applications Archetype

Rich Internet Applications Archetype

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

Objectives

• Define a rich Internet application (RIA).
• Understand key scenarios where RIAs would be used.
• Understand the components found in an RIA.
• Learn the design considerations for RIAs.
• Learn the guidelines for performance, security, and deployment of RIAs.
• Learn the key patterns and technology considerations for designing RIAs.

Overview

Rich Internet applications (RIAs) support rich graphics and streaming media scenarios, while providing most of the deployment and maintainability benefits of a Web application. RIAs run in a browser plug-in, such as Microsoft® Silverlight®, as opposed to extensions that utilize browser code, such as Asynchronous JavaScript and XML (AJAX). A typical RIA implementation utilizes a Web infrastructure combined with a client-side application that handles the presentation. The plug-in provides library routines for rich graphics support as well as a container limiting access to local resources for security purposes. RIAs have the ability to run more extensive and complex client-side code than possible in a normal Web application, thus providing the opportunity to reduce load on the Web server.


Figure 1 Architecture of a typical RIA implementation

Design Considerations

The following design guidelines provide information about different aspects you should consider when designing an RIA. Follow these guidelines to ensure that your application meets your requirements and performs efficiently in scenarios common to RIAs:

• Choose an RIA based on audience, rich interface, and ease of deployment.** Consider designing an RIA when your vital audience is using a browser and operating system that supports RIAs. If part of your vital audience is on a non-RIA-supported browser, consider whether you can influence limiting browser choice to a supported version. If you cannot influence the browser choice, consider if the loss of audience is significant enough to require choosing another application type, such as a Web application using AJAX. With an RIA, the ease of deployment and maintenance is similar to that of a Web application, assuming that your clients have a reliable network connection. RIA implementations are well suited to Web-based scenarios where you need visualization beyond that provided by basic HTML. They are likely to have more consistent behavior and require less testing across the range of supported browsers when compared to Web applications that utilize advanced functions and code customizations. RIA implementations are also perfect for streaming-media applications. They are less suited to extremely complex multi-page user interfaces (UIs).
• Design to use a Web infrastructure utilizing services.** RIA implementations require an infrastructure similar to Web applications. Communication to the business layer of your application is usually through services, which allows reuse of existing Web application infrastructure. Transferring logic to the client should only be considered later in the design process. Only transfer logic for performance optimization and UI responsiveness reasons.
• Design for running in the browser sandbox.** RIA implementations have higher security by default and therefore may not have access to all devices on a machine, such as cameras and hardware video acceleration. Access to the local file system is limited. Local storage is available, but there is a maximum limit.
• Determine the complexity of your UI requirements. Consider the complexity of your UI. RIA implementations work best when using a single screen for all operations. They can be extended to multiple screens, but this requires extra code and screen-flow consideration. Users should be able to easily navigate or pause, and return to the appropriate point in a workflow, without restarting the whole process. For multi-page UIs, use deep-linking methods. Also, manipulate the Uniform Resource Locator (URL), the history list, and the browser’s back and forward buttons to avoid confusion as users navigate between screens.
• Use scenarios to increase application performance or responsiveness.** List and examine the common application scenarios to decide how to intelligently divide and load modules, as well as how to cache or move business logic to the client. To reduce the download and start-up time for the application, intelligently segregate functionality into separate downloadable modules. Initially load only code stubs, which can lazy-load other modules. Consider moving or caching regularly used business layer processes on the client for maximum application performance.
• Design for scenarios where the plug-in is not installed. Because RIA implementations require a browser plug-in, a you should design for non-interruptive plug-in installation. Consider whether your clients have access to, have permission to, and will want to install the plug-in. Consider what control you have over the installation process. Plan for the scenario where users cannot install the plug-in, by displaying an informative error message, or by providing an alternative Web UI.

RIA Frame

There are several common issues that you must consider as your develop your design. These issues can be categorized into specific areas of the design. The following table lists the common issues for each category where mistakes are most often made.

Table 1 RIA frame

Category	Key issues
Business Layer	Moving business operations to the client for reasons other than improved user experience or application performance
Failing to use profiling to identify expensive business operations that should be moved to the client
Trying to move all business processing to the client
Failing to put business rules on the client into their own separate components to allow easy caching, updating, and replacement
Using less powerful browser-supported languages instead of considering windowless RIA plug-ins written in rich programming languages to provide client side processing
Caching	Failing to use isolated storage appropriately
Failing to check and request increase of the isolated storage quota
Failing to intelligently divide large client applications into smaller separately downloadable components
Downloading and instantiating the entire application at start-up instead of intelligently and dynamically loading modules
Communication	Trying to use a synchronous communication model
Using an incorrect strategy to bind to the service interface
Attempting to use sockets over unsupported or blocked ports
Controls	Adding custom control behavior through sub-classing instead of attaching new behavior to specific instances of controls
Incorrect use of controls for a UI type
Implementing custom controls when not required
Composition	Incorrectly implementing composition patterns, leading to dependencies that require frequent application redeployment
Using composition when not appropriate for the scenario
Not considering composition, and completely rewriting applications that could be reused with minimal or no changes
Data Access	Performing data access from the client
Failing to filter data at the server
Exception Management	Failing to design an exception-management strategy
Failing to trap asynchronous call errors and unhandled exceptions; for example, not using the OnError event handler supported by Microsoft Silverlight to trap exceptions in asynchronous calls
Logging	Failing to log critical errors
Failing to consider a strategy to transfer logs to the server
Segregating logs by machine instead of by user
Media & Graphics	Failing to take advantage of adaptive streaming for video delivery
Assuming access to hardware acceleration on client
Presentation	Not pixel-snapping UI elements, which results in degraded UI appearance
Failing to handle the forward and back button events
Not considering and designing for deep linking when necessary
Portability	Failing to consider the cost of testing for each platform and browser combination in a Web application compared to using an RIA interface
Using platform
Using less powerful browser
State Management	Failing to use isolated storage
Using the server to store frequently changing application state
Failing to synchronize state between the client and server when user configuration must be available on multiple clients
Validation	Failing to identify trust boundaries and validate data that passes across them
Failing to validate data on both the client and the server
Failing to collate extensive client-side validation code into a separate downloadable module

Business Layer

RIA implementations provide the capability to move business processing to the client. Consider moving logic that improves the user experience or performance of the application as a whole.

Consider the following guidelines when designing the business layer:

• Consider starting with your business logic on the server exposed through services. Use scenario-based profiling to discover and target routines that cause the heaviest server load or have the most impact on UI responsiveness. Consider moving or caching only those routines to the client.
• When locating business logic on the client, consider putting business rules or routines in a separate assembly that the application can load and update independently.
• If your business logic is duplicated on the client and the server—for instance, if you are processing business rules on the client for performance but implement the same rules in the service for integrity—use the same code language on the client and server if your RIA implementation allows it. This will reduce any differences in language implementations and make it easier to be consistent in how rules are processed.
• If your RIA implementation allows creation of an instance without a UI, consider using it intelligently. You can keep your processing code in more structured, powerful, or familiar programming languages (such as C#) instead of using less flexible browser-supported languages.
• For security reasons, do not put highly sensitive unencrypted business logic on the client.

Caching

RIA implementations generally use the normal browser caching mechanism. Caching resources intelligently will improve application performance.

Consider the following guidelines when designing a caching strategy:

• Cache components of your application for improved performance and fewer network round trips. Allow the browser to cache objects that are not likely to change during a session. Utilize specific RIA local storage for information that changes during a session, or which should persist between sessions.
• Use installation, updates, and user scenarios to derive intelligent ways to divide and load application modules.
• Load stubs at start-up and then dynamically load additional functionality in the background. Consider using events to intelligently pre-load modules just before they may be required.
• To avoid unintended exceptions, check that isolated storage is large enough to contain the data you will write to it. Storage space does not increase automatically; you must ask the user to increase it.

Communication

RIA implementations must use the asynchronous call model for services to avoid blocking browser processes. Cross-domain, protocol, and service-efficiency issues should be considered as part of your design. If your RIA implementation allows it, consider using threading for background operations.

Consider the following guidelines when designing a communication strategy:

• If you have long-running code, consider using a background thread or asynchronous execution to avoid blocking the UI thread.
• If you are authenticating through services, design your services to use a binding that your RIA implementation supports.
• Ensure that the RIA and the services it calls use compatible bindings that include security information.
• If your RIA client must access a server other than the one from which it was downloaded, ensure that you use a cross-domain configuration mechanism to permit access to the other servers/domains.
• Consider using sockets to push data to the client if client polling causes heavy server load. Consider using sockets to push information to the server when this is significantly more efficient than using services; for example, real-time multi-player gaming scenarios utilizing a central server.

Controls

RIA implementations usually have their own native controls. You can often mix RIA-based and non-RIA-based controls in the same UI, but extra communication code may be required.

Consider the following guidelines when designing a strategy for controls:

• Use native RIA controls where possible.
• If the appropriate control is not supplied with your RIA package, consider third-party RIA-specific controls.
• If a native RIA control is not available, consider using a windowless RIA control in combination with an HTML or Windows Forms control that does have the necessary functionality.
• If your RIA controls support the ability to attach added behaviors, use that ability and avoid sub-classing the controls to extend functionality.

Composition

Composition allows you to implement highly dynamic UIs that you can maintain without changes to the code or redeployment of the application. You can compose an application using RIA and non-RIA components.

Consider the following guidelines when designing a composition strategy:

• Evaluate which composition model patterns best suit your scenario.
• If an interface must gather information from many disparate sources, and those sources are user-configurable or change frequently, consider using composition.
• When migrating an existing HTML application, consider mixing RIA and the existing HTML on the same page to reduce application reengineering.

Data Access

RIA implementations access data in a similar way to normal Web applications. They should request data from the Web server through services in the same way as an AJAX client. After data reaches the client, it can be cached to maximize performance.

Consider the following guidelines when designing a data-access strategy:

• Use client-side processing to minimize the number of round trips to the server, and to provide a more responsive UI.
• Filter data at the server rather than at the client to reduce the amount of data that must be sent over the network.
• For operation-based applications, utilize services to access data.

Exception Management

A good exception-management strategy is essential for correctly handling and recovering from errors in any application. In an RIA, you must consider asynchronous exceptions as well as exception coordination between the client and server code.

Consider the following guidelines when designing an exception-management mechanism:

• Do not use exceptions to control business logic.
• Only catch internal exceptions that you can handle. For example, catch data conversion exceptions that can occur when trying to convert null values.
• Design an appropriate exception-propagation strategy. For example, allow exceptions to bubble up to boundary layers where they can be logged and transformed as necessary before passing them to the next layer.
• Design an approach for catching and handling unhandled exceptions. Unhandled exceptions in RIAs are passed to the browser. They will allow execution to continue after the user dismisses a browser error message. Provide a friendly error message for the user if possible. Stop program execution if continued execution would be harmful to the data integrity of the application or could mislead the user into thinking the application is still in a stable state.
• Design an appropriate logging and notification strategy for critical errors and exceptions that does not reveal sensitive information.
• Design for both synchronous and asynchronous exceptions. Use try/catch blocks to trap exceptions in synchronous code. Put exception handling for asynchronous service calls in the separate handler designed specifically for such exceptions; for example, in Silverlight, this is the OnError handler.

Logging

Logging for the purpose of debugging or auditing can be challenging in an RIA implementation. For example, access to the client file system is not available in Silverlight applications, and execution of the client and the server proceed asynchronously. Log files from a client user must be combined with server log files to gain a full picture of program execution.

Consider the following guidelines when designing a logging strategy:

• Consider the limitations of the logging component in the RIA implementation. Some RIA implementations log each user’s information in a separate file, perhaps in different locations on the disk.
• Determine a strategy to transfer client logs to the server for processing. Recombination of different users’ logs from the same machine may be necessary if troubleshooting a client machine–specific issue.
• If using isolated storage for logging, consider the maximum size limit and the requirement to ask the user for increases in storage capacity.
• Consider enabling logging and transferring logs to the server when exceptions are encountered.

Media and Graphics

RIA implementations provide a much richer experience and better performance than ordinary Web applications. Research and utilize the built-in media capabilities of your RIA platform. Keep in mind the features that may not be available on the RIA platform compared to a stand-alone media player.

Consider the following guidelines when designing for multimedia and graphics:

• Design to utilize streaming media and video in the browser instead of invoking a separate player utility.
• To increase performance, position media objects on whole pixels and present them in their native size.
• Use adaptive streaming in conjunction with RIA clients to gracefully and seamlessly handle varying bandwidth issues.
• Utilize the native vector graphics engine for the best drawing performance.
• If programming an extremely graphics-intensive application, find out if your RIA implementation provides hardware acceleration. If it does not, create a baseline for what is acceptable drawing performance. Consider a plan to reduce load on the graphics engine if it falls below acceptable limits.

Mobile

RIA implementations provide a much richer experience than an ordinary mobile application. Utilize the built-in media capabilities of the RIA platform you are using.

Consider the following guidelines when designing for mobile device multimedia and graphics:

• When an RIA application needs to be distributed on a mobile client, research whether an RIA plug-in implementation is available for the device you want to support. Find out if the RIA plug-in has reduced functionality compared to non-mobile platforms.
• Attempt to start from a single or similar codebase. Branch code as required for specific devices.
• Re-examine UI layout and implementation for the smaller screen size.
• RIA applications work on mobile devices, but consider using different layout code on each type of device to reduce the impact of different screen sizes when designing for Microsoft Windows Mobile®.

Portability

One of the main benefits of RIAs is the portability of compiled code between different browsers, operating systems, and platforms. Similarly, using a single source codebase, or similar codebases, reduces the time and cost of development and maintenance, while still providing platform flexibility.

Consider the following guidelines when designing for portability:

• Design for the goal of “write once, run everywhere,” but be willing to fork code in cases where overall project complexity or feature tradeoffs dictate that you do so.
• When comparing an RIA and a Web application, consider that differences between browsers can require extensive testing of ASP.NET and JavaScript code. With an RIA application, the plug-in creator, and not the developer, is responsible for consistency across different platforms.
• If your audience will be running the RIA on multiple platforms, do not use features available only on one platform; for example, Windows Integrated Authentication. Design a solution based on standards that are portable across different clients.
• When possible, use richer development languages that are supported for both rich clients and RIAs. See the Technology considerations in this section for recommendations.
• Make full use of the native RIA code libraries.

Presentation

RIA applications work best when designed as one central interface. Multi-page UIs require that you consider how you will link between pages. Positioning of elements on a page can affect both the look and performance of your RIA application.

Consider the following guidelines when designing for presentation:

• To avoid anti-aliasing issues that can cause fuzziness in RIAs, snap UI components to whole pixels. Pay attention to centering and math-based positioning routines. Consider writing a routine that checks for fractional pixels and rounds them to the nearest whole pixel value.
• Trap the browser’s forward and back button events to avoid unintentional navigation away from your page.
• For multi-page UIs, use deep-linking methods to allow unique identification of and navigation to individual application pages.
• For multi-page UIs, consider the ability to manipulate the browser’s address text box content, history list, and back and forward buttons in order to implement normal Web page–like navigation.

State Management

You can store application state on the client by using isolated storage if the state changes frequently. If application state is vital at start-up, synchronize the client state to the server.

Consider the following guidelines when designing for state management:

• Store state on the client in isolated storage to persist it during and between sessions.
• Store the client state on the server if loss of state on the client would be catastrophic to the application’s function. Consider that isolated storage is deleted when the browser cache is cleared.
• Store the client state on the server if the client requires recovery of application state when using different accounts, or when running on other hardware installations
• Verify the stored state between the client and server at start-up, and intelligently handle the case when they are out of synchronization.
• Design for multiple concurrent sessions because you cannot prevent multiple RIA instances from initializing. Design either for concurrency in your state management, or to detect and prevent multiple sessions from corrupting application state.

Validation

Validation must be performed using code on the client or through services located on the server. If you require more than trivial validation on the client, isolate validation logic in a separate downloadable assembly. This makes the rules easy to maintain.

Consider the following guidelines when designing for validation:

• Use client-side validation to maximize the user experience, and server-side validation for security. Use isolated storage to hold client-specific validation rules.
• In general, assume that all client-controlled data is malicious. The server should re-validate all data sent to it. Design to validate input from all sources, such as the query string, cookies, and HTML controls.
• Design to constrain, reject, and sanitize data. Validate input for length, range, format, and type.
• For rules that require access to server resources, evaluate whether it is more efficient to use a single service call that performs validation on the server.
• If you have a large volume of client-side validation code that may change, consider locating it in a separate downloadable module so it can be easily replaced without downloading the entire RIA application again.

Performance Considerations

Properly using the client-side processing power for an RIA is one significant way to maximize performance. Server-side optimizations similar to those used for Web applications are also a major factor.

Consider the following key performance guidelines:

• Cache components of your application for improved performance and fewer network round trips. Allow the browser to cache objects that are not likely to change during a session. Utilize specific RIA local storage for information that changes during a session, or that should be persisted between sessions.
• Use installation, updates, and user scenarios to derive intelligent ways to divide and load application modules. Load stubs at start-up and then dynamically load additional functionality in the background. Consider using events to intelligently pre-load modules just before they may be needed. For example, in a merchant application, wait to load checkout functionality until sometime after a user has added an item to the shopping cart.
• Use scenario-based profiling to discover and target routines that cause the heaviest server load, or that have a major impact on UI responsiveness. Consider moving or caching these routines on the client. When locating business logic on the client, place business rules or routines in a separate assembly that the application can load and update independently.
• Position media objects on whole pixels and present them in their native size. Do not blend them with other objects, such as progress bar controls.
• Be aware of the size of your drawing areas. Only redraw parts of an area that are actually changing. Reduce overlapping regions when not necessary to reduce blending. Use profiling and debugging methods—for example, the “EnableRedrawRegions = true” setting in Silverlight—to see what areas are being redrawn. Note that certain effects, such as blurring, can cause every pixel in an area to be redrawn. Windowless and transparent controls can also cause unintended redrawing and blending.

Security Considerations

RIA applications mitigate a variety of common attack vectors because they run inside a sandbox in the browser. Access to most local resources is limited or restricted, which minimizes opportunities for attacks on the RIA and the client platform on which it runs.

Consider the following restrictions:

• Applications run inside a sandbox in the browser, within a memory space isolated from other applications.
• Browsing of the local client file system is restricted.
• Access to specialized local devices such as Webcams may be limited or not available.
• Access to domains other than the one that delivered the application is limited, protecting the user from cross-site scripting attacks

Protect sensitive information using the follow methods:

• The isolated storage mechanism provides a method for storing data locally, but does not provide built-in security. Do not store sensitive data locally unless it is encrypted using the platform encryption routines.
• Create an exception-management strategy to prevent exposure of sensitive information through unhandled exceptions.
• Be careful when downloading sensitive business logic used on the client because tools are available that can extract the logic contained in downloaded XAML Browser Application (XBAP) files. Implement sensitive business logic using Web services. If the logic must be on the client for performance reasons, research and utilize any available obfuscation methods.
• To minimize the amount of time that sensitive data is available on the client, utilize dynamic loading of resources and overwrite or clear components containing sensitive data from the browser cache.

Deployment Considerations

RIA implementations provide many of the same benefits as Web applications in terms of deployment and maintainability. Design your RIA as separate modules that can be downloaded individually and cached to allow replacement of one module instead of the whole application. Version your application and components so that you can detect the versions that clients are running.

Consider the following guidelines when designing for deployment and maintainability:

• Consider how you will manage the scenario where the RIA browser plug-in is not installed.
• Consider how you will redeploy modules when the application instance is still running on a client.
• Divide the application into logical modules that can be cached separately, and that can be replaced easily without requiring the user to download the entire application again.
• Version your components.

Installation of the RIA plug-in

Consider how you will manage installation of the RIA browser plug-in when it is not already installed:

• Intranet. If available, use application distribution software or the Group Policy feature of the Microsoft Active Directory® directory service to pre-install the plug-in on each computer in the organization. Alternatively, consider using Windows Update, where Silverlight is an optional component. Finally, consider manual installation through the browser, which requires the user to have Administrator privileges on the client machine.
• Internet. Users must install the plug-in manually, so you should provide a link to the appropriate location to download the latest plug in. For Windows users, Windows Update provides the plug-in as an optional component.
• Plug-in updates. In general, updates to the plug-in take into account backward compatibility. You may target a particular plug-in version, but consider implementing a plan to verify your application’s functionality on new versions of the browser plug-in as they become available. For intranet scenarios, distribute a new plug-in after testing your application. In Internet scenarios, assume that automatic plug-in updates will occur. Test your application using the plug-in beta to ensure a smooth user transition when the plug-in is released.

Distributed Deployment

Because RIA implementations move presentation logic to the client, a distributed architecture is the most likely scenario for deployment.

In a distributed RIA deployment, the presentation logic is on the client and the business and data layers reside on the Web server or application server. Typically, you will have your business and data access layers on the same server, as shown in Figure 2.


Figure 2 Distributed deployment for an RIA

Consider the following guidelines:

• If your applications are large, factor in the processing requirements for downloading the RIA components to clients.
• If your business logic is shared by other applications, consider using distributed deployment.
• If you use sockets in your application and you are not using port 80, consider which ports you must open in your firewall.
• Ensure that you use a crossdomain.xml file so that RIA clients can access other domains where required.
• Design the presentation layer in such as way that it does not initiate, participate in, or vote on atomic transactions.
• Consider using a message-based interface for your business logic.

Load Balancing

When you deploy your application on multiple servers, you can use load balancing to distribute RIA client requests to different servers. This improves response times, increases resource utilization, and maximizes throughput. Figure 3 shows a load-balanced scenario.


Figure 3 Load balancing an RIA deployment
Consider the following guidelines when designing your application to use load balancing:

• Avoid server affinity. Server affinity occurs when all requests from a particular client must be handled by the same server. It is most often introduced by using locally updatable caches or in-process or local session state stores.
• Consider storing all state on the client and designing stateless business components.
• Consider using network load balancing software to implement redirection of requests to the servers in an application farm.

Web Farm Considerations

Consider using a Web farm that distributes requests from RIA clients to multiple servers. A Web farm allows you to scale out your application, and reduces the impact of hardware failures. You can use either load balancing or clustering solutions to add more servers for your application.

Consider the following guidelines:

• Consider using clustering to reduce the impact of hardware failures.
• Consider partitioning your database across multiple database servers if your application has high I/O requirements.
• If you must support server affinity, configure the Web farm to route all requests for the same user to the same server.
• Do not use in-process session management in a Web farm unless you implement server affinity, because requests from the same user cannot be guaranteed to be routed to the same server otherwise. Use the out-of-process session service or a database server for this scenario.

Pattern Map

Table 2 Pattern map

Category	Relevant patterns
Business Layer	Service Layer
Caching	Page Cache
Communication	Asynchronous Callback
Command
Controls	Chain of Responsibility
Composition	Composite View
Inversion of Control
Presentation	Application Controller
Model-View-Controller

Pattern Descriptions

• Application Controller.** An object that contains all of the flow logic and is used by other Controllers that work with a Model and display the appropriate View.
• Asynchronous Callback.** Execute long-running tasks on a separate thread that executes in the background, and provide a function for the thread to call back into when the task is complete.
• Chain of Responsibility.** Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.
• Command.** Encapsulate request processing in a separate command object that exposes a common execution interface.
• Composite View. Combine individual views into a composite view.
• Inversion of Control.** Populate any dependencies of objects on other objects or components that must be fulfilled before the object can be used by the client application.
• Model-View-Controller.** Separate the UI code into three separate units; Model (data), View (interface), and Presenter (processing logic), with a focus on the View. Two variations on this pattern include Passive View and Supervising Controller, which define how the View interacts with the Model.
• Page Cache.** Improve the response time for dynamic Web pages that are accessed frequently, but that change less often and consume a large amount of system resources to construct.
• Service Layer.** An architectural design pattern where the service interface and implementation is grouped into a single layer.

Technology Considerations

The following guidelines discuss Silverlight and Microsoft Windows Communication Foundation (WCF) and provide specific guidance for these technologies. At the time of writing, the latest versions are WCF 3.5 and Silverlight 2.0. Use the guidelines to help you to choose and implement an appropriate technology:

• At the time of this guide’s release, Silverlight for Mobile was an announced product and in development, but not released.
• Silverlight currently supports the Safari, Firefox, and Microsoft Internet Explorer browsers though a plug-in. Through these browsers, Silverlight 2.0 currently supports Mac, Linux, and Microsoft Windows®. Support for Windows Mobile was also announced in 2008.
• The local storage mechanism for Silverlight is named “Isolated Storage.” The current initial size is 1 megabyte (MB). The maximum storage size is unlimited. Silverlight requires that you ask the user to increase the storage size.
• Silverlight only supports Basic HTTP binding. WCF in .NET 3.5 supports Basic HTTP binding, but security is not turned on by default. Be sure to turn on at least transport security to secure your service communications.
• Silverlight does not obfuscate modules downloaded as XBAPs. XBAPs can be decompiled and the programming logic extracted.
• The .NET cryptography APIs are available in Silverlight and should be utilized when storing and communicating sensitive data to the server if not already encrypted using another mechanism.
• Silverlight contains controls specifically designed for it. Third parties are likely to have additional control packages available.
• Use Silverlight windowless controls if you want to overlay viewable HTML content and controls on top of a Silverlight application.
• If you want to provide rich control functionality in cases when WPF is not available (such as when Microsoft .NET Framework 3.5 is not installed on the machine), you can embed a Silverlight application in Windows Forms and run it in the Web Browser control.
• Silverlight allows you to attach additional behaviors to existing control implementations. Use this approach instead of attempting to subclass a control.
• Silverlight supports only asynchronous calls to Web services.
• Silverlight calls use the OnError** event handler for an application when exceptions occur in services, or when synchronous exceptions are not handled.
• Silverlight does not currently support SOAP faults exposed by services due to the browser security model. Services must return exceptions to the client through a different mechanism.
• Silverlight supports two file formats to deal with calling services cross-domain. You can use either a ClientAccessPolicy.xml file specific to Silverlight, or a CrossDomain.xml file compatible with Adobe Flash. Place the file in the root of the server(s) to which your Silverlight client needs access.
• In Silverlight, you must implement custom code for input and data validation. Check documentation to verify whether this is true for later versions.
• Silverlight performs anti-aliasing for all UI components, so consider the recommendations in the Presentation section about snapping UI elements to whole pixels.
• Consider using ADO.NET Data Services in a Silverlight application if large amounts of data must be transferred from the server.
• Silverlight logs to an individual file in the user store for a specific logged-in user. It cannot log to one file for the whole machine.
• Silverlight supports the languages of C#, Iron Python, Iron Ruby, and VB.NET. Most XAML code will also run in both WPF and Silverlight hosts.

Additional Resources

• For official information on Silverlight, see the official Silverlight Web site at http://silverlight.net/default.aspx
• For Silverlight blogs, see http://blogs.msdn.com/brada/ and http://weblogs.asp.net/Scottgu/

Last edited Dec 19 2008 at 10:16 PM by prashantbansode, version 9