` 'Palm' 태그의 글 목록 :: Black Sheep Wall!

앞서나간 컨셉이었지만 3여년 간의 짧은 생애를 마치고 죽어버린(?) HP가 죽도록 방조한 (?) 故WebOS에서의 좋았던 기능들을 잘 살려보자는 Lukas Mathis 씨의 가슴 짠한 글 번역, 

확실히 User Interface 측면에서는 사용하는 것 자체가 즐겁고, 편리한, 천지창조설이 나도는 iOS와는 다른 방향으로 앞서나간 모바일OS였고, 그대로 다 사라지게 하기에는 아쉬운 부분이 많았다. 그런 의미에서 다시 한번 ㅠ

지금 번역을 하면서 보니 재밌게도, 안드로이드 ICS부터는 webOS UX 수장이었던 Matias Duarte 씨가 Android로 옮긴 후 영향력을 행사하면서 webOS의 그 진수를 그대로 이식해서 이어가고 있구나, 즉 이 글의 webOS를 기능만이라도 다른 OS에 이식해서 그 뜻을 기리자는 (?) 의도는 android가 그 정통성(;)과 유지를 받들어 잘 이어가고 있다는 훈훈한 결말 ㅠㅠ 

갤럭시 만드는 그 회사는 모하고 있니? 좀 이런거라도 잘 발굴해서 그놈의 "터치위즈 TouchWiz" 좀 개선해다오 ㅠㅠ (98년도 스타일의 촌스러운 네이밍부터 어떻게 젭알좀ㅠ)

원문은 http://ignorethecode.net/blog/2012/02/21/steal_webos_features/


Please Steal These webOS Features 제발 이 webOS 기능들을 훔쳐가 주세요

When Apple introduced the first iPad in 2010, I bought one immediately. I didn’t know what I’d use it for, but I was sure that I would find some use for it. I never did. I played around with it, wrote some code for it, but eventually stopped using it. I would pick it up from time to time to read something or watch a YouTube movie, but even that was a rare occurrence. I have since picked up an iPad 2, and I’m using it a lot more than the first iPad, but again, I’m pretty much only using it to consume content.

애플이 2010년에 처음으로 첫번째 아이패드를 발표했을 때, 나는 바로 구매했지. 어디다 사용해야 할 지 몰랐어, 하지만 어딘가 쓸 곳을 찾을 수 있을거라고 확신했었지. 하지만 그러지 못했어. 가지고 놀았고, 몇가지 코드를 작성해서 돌려 보기도 했지만, 결국 사용하는 걸 멈추게 되었지. 어떤 것들을 조금 읽거나, 유튜브 영상을 보거나 했는데, 그것조차 아주 가끔씩 사용했었어. 아이패드2를 산 뒤엔, 첫번째 아이패드 보단 더 많이 사용하긴 했지만, 역시 그저 컨텐트를 소비하는 용도로만 사용하게 되었지.


I suspect that most people use their iPads similarly: to surf the web, watch movies, play games, read books, and graphic novels. Essentially, to consume. Of course, there are always exceptions. There are great music and painting apps for the iPad, for example. But how many iPad owners are musicians or like to paint with their fingers? In the grand scheme of things, not many, I suspect.

난 대부분의 사람들이 그들의 아이패드를 비슷하게 사용하고 있을 거라고 생각해: 웹서핑을 하거나, 영화를 보거나, 게임을 하거나, 책을 읽거나, 그래픽 소설을 읽거나. 본질적으로 소비를 하는 기계로 사용을 하지, 물론 몇가지 예외가 있긴 있어. 아이패드용으론 멋진 음악, 그림 그리기 앱들이 있지. 하지만 아이패드 보유자 중에 음악가나 손가락으로 그림을 그리는 사람이 몇명이나 될까? 내 추측으론 많진 않을 거야.


So when I bought a TouchPad after HP discontinued it, I never assumed that I would use it for actual work. But I am doing just that. I’m using it to respond to email, to do research on the Internet, to take notes during meetings.

그래서 HP가 TouchPad를 단종시킨다고 한 뒤로, 그걸 샀지. 몬가 실사용을 위해서 쓸거라고 생각하고 산 건 절대 아니야. 하지만 난 실제로 사용을 하게 되었지. 이메일 답장을 하기 위해서, 인터넷에서 어떤 정보를 찾아보고, 회의시간에 노트를 적기 위해서 실제로 사용을 하게 되었다고.


So why was it so easy for me to use the TouchPad for work, but not the iPad? I think it’s because there are a number of things the TouchPad does that make it more suitable for work.

왜 업무를 위해서 아이패드가 아닌 터치패드를 사용하는게 편했을까? 난 업무를 위해 좀 더 적합하게 사용할 수 있는 터치패드의 몇가지 기능들 덕분이라고 생각해.


Now that it is becoming increasingly obvious that HP won’t do anything useful with webOS, it’s time to start stealing1 the things it does well. Here are some of these things.

자 이젠 HP가 webOS를 가지고 어떤 유용한 것에 사용하진 않을 것이라는 것이 점점 명확해지고 있지. 이런 좋은 기능들을 훔쳐가야할 시간이야. 여기 그 기능들을 소개할께.


(훔친다는 것은 Brian Ford씨가 정의한 단어의 의미로 사용할께 : 아이디어를 보고, 네 것으로 소화시켜서, 완전한 너의 아이디어로 만들어라, 단순하게 베끼지 말고, 그 아이디어로 영감을 얻고, 그 영감을 토대로 더 나은 아이디어로 만들라구) 



Switching Apps 앱간 전환

Sometimes, you agonize over how something should be designed. And then you come up with an idea, or see somebody else’s solution, and you’re just blown away by how obvious it seems. The cards UI for switching between apps in webOS is such an idea. I don’t think I need to elaborate.2 Nothing else I’ve seen comes close. By now, many other platforms have implemented their own versions of this concept, but the original remains the best.


때때로 어떤 것들이 어떻게 디자인 되어야만 하는지 때문에 골치 아플거야. 그리고 나선 네가 어떤 아이디어를 떠올리거나, 다른 사람의 해결책을 보았을 때, 그게 어떻게 확실하게 해결 될 수 있는지 깜짝 놀라겠지. webOS에서 앱간 전환을 위한 카드 UI가 바로 그런 아이디어이지. 애써 정교하게 만들 필요는 없다고 생각하는데 내가 본 어떤 것도 근처까지 구현하지도 못했어. 현재까지 많은 다른 플랫폼에서 이 컨셉의 다른 버전들을 만들어 내곤 있지만, 여전히 오리지날이 최고라구.



One App, Many Screens 많은 화면들로 이루어지 하나의 앱


Almost every time I try to use the iPhone or iPad for writing a response to an email that is longer than «Okay» or «I’ll be there», I have this problem: I need to refer to another email. Maybe it’s something somebody said in an earlier conversation. Maybe it’s something from the mail I’m replying to, and I’ve already deleted it. Regardless, it constantly happens to me.


오케이나, 알겠어 거기로 갈께 같은 짤막한 말보다 더 긴 내용을 이메일로 답장하려고 아이폰이나 아이패드를 사용하는 경우의 대부분 나는 이런 문제가 있어: 대부분 다른 이메일을 참조해야 하지. 아마도 누군가와 전에 이야기 했던 내용중에서 어떤 부분이겠지. 어쩌면 이미 지워버린 지금 답장하려는 메일의 어떤 부분이거나. 어찌됐든  매번 그런 경우가 나에겐 생기더라구.


On iOS, it’s almost impossible to leave a draft, read another mail, and go back to the draft. It can be done, but it’s ridiculously cumbersome.3 On webOS?


iOS에선 임시본을 잠깐 남겨 놓고, 다른 메일을 읽고난 뒤, 다시 작성중인 드래프트로 돌아오는 것이 거의 불가능한데, 이런 멍청하게시리 귀찮은 방법으론 가능하긴 하지. webOS에선?


email appemail app

Yep, the new email opens in its own card that’s attached to the Mail application’s card. You can easily go back to your other mails, search them, read them, copy text from them, do whatever you want. You can even start writing another mail, and easily switch between the two drafts.


이옙. 새로운 이메일 창은 메일 어플리케이션 카드에 붙어있는 고유의 카드로 열리게 되지. 넌 그냥 쉽게 다른 메일로 돌아가서, 필요한 것을 찾고, 읽고, 복사해 올 수 있어. 그냥 너가 원하는 모든지 할 수 있다고, 다른 메일을 아예 새로 쓰기 시작해서, 두 임시본을 쉽게 왔다갔다 할 수 있는거야.



Organizing Windows 윈도우들 관리


Recently, I was in a meeting where we discussed color schemes for an application. We wanted to keep the number of colors as low as possible, but still have enough color to clearly show the difference between content foreground, content background, and application chrome. It occurred to me that 90s videogames did a pretty good job differentiating between layers — characters, environment, background, HUDs — using a very limited color palette. I wondered how they achieved this. So I did a quick Google search for screenshots from different games, and opened a few of them. Here’s what this looked like in webOS.


최근에 나는 어떤 어플리케이션의 칼라 스킴 셋을 논의하는 회의에서 있었어. 가능한 사용하는 컬러의 갯수를 줄여야 했지. 하지만 여전히 컨텐츠 앞단, 컨텐츠 배경, 어플리케이션 틀 간의 차이점들을 명확히 보여주기엔 컬러가 너무 많았지. 마치 매우 제한된 수의 컬러 팔렛트만을 가지고 캐릭터 들과 스테이지, 배경, HUDs이미지들의 레이어들을 구현해 내었던 90년대 비디오 게임들은 정말 대단한 일들을 했었구나 라고 느꼈어. 어떻게 예전에 이런 작업들을 할 수 있었는지 궁금해 했지. 그래서 난 재빨리 다른 게임들의 스크린 샷을 구글해서 찾아봤지, 그것들 중 몇가지를 열었고. 그것들은 webOS에서 이렇게 보여졌어.


Web BrowserWeb Browser

I’m looking at six different web pages at the same time. I can easily switch between them, add new ones, or removes ones I don’t need anymore. On the iPad, I’d be looking at a bunch of tabs with cryptic names.


동시에 여섯개의 다른 웹 페이지들을 보고 있다고. 쉽게 전환해 가며 돌려 볼 수 있고, 새로운 화면을 추가할 수도 있고 필요없는 화면을 쉽게 닫아 버릴 수도 있지. 아이패드에선 숨어있는 분간하기 어려운 이름만으로 탭의 묶음들을 돌려가며 봐야 한다고.



Accounts 계정

Document management on iOS is a mess. Every application implements its own scheme. They all work differently. Some allow you do open documents in other applications that support a matching file format. Others don’t. Some support Dropbox, or other services. Others don’t. Some allow you to organize your documents hierarchically or spatially, others don’t.


iOS에서 문서관리는 복잡하지. 각 어플리케이션 마다 각자의 모양새를 구현해 놓고 있엉. 제각각 다 다르게 동작하지. 어떤 것들은 파일 포맷이 맞으면 다른 앱에서 문서를 열 수 있도록 하지만, 어떤 것을은 아니지. 어떤 것들은 DropBox를 지원하거나 다른 서비스를 지원하는데, 또 어떤 것들은 그렇지 않지. 어떤 것들은 문서들을 계층적으로 혹은 공간적으로 정리할 수 있도록 하지만 또 어떤 것들은 그렇질 않아.


In webOS, you can set up different system-wide accounts.

webOS에선, 다른 시스템 계정들을 전반적으로 설정할 수 있어.


Synergy accountsSynergy accounts

Each of this account can provide a number of different services.

각 계정들은 여러개의 다른 서비스들을 제공하고 있지.

Google account settingGoogle account setting

These services are immediately available in all webOS applications. QuickOffice doesn’t need to support Dropbox, or your Google Documents account; webOS handles this. QuickOffice just has to be a good citizen, support the proper webOS APIs, and it gets access to all of these services automatically.


이 서비스들은 모든 webOS 어플리케이션에서 바로 사용할 수 있어. QuickOffice는 Dropbox나 Google 문서 계정이나를 지원할 필요가 없지. webOS가 이것들을 해줘. QuickOffice는 단지 webOS API들을 올바르게 지원하기만 하면, 이런 서비스들을 자동적으로 사용할 수가 있는 거야.

QuickofficeQuickoffice

Related to this, Windows 84 has a concept called «contracts», which allows applications to interact with each other, and provide services that can be used by each other. This way, a photo application can call upon a Twitter application to share a picture on Twitter without implementing any Twitter-specific code, or a text editor can open a file from a Dropbox application without knowing what Dropbox is.


이것과 연관해서, 윈도 84에는 앱간에 서로 상호작용하고 서로 서비스를 제공하는데 쓰이는 <계약>이라고 불리는 컨셉이 있었어. 이 방법으로 사진 어플리케이션은 어떤 Twitter 종속적인 코드를 구현하지 않고도 Twitter 어플리케이션을 통해 사진 공유를 하거나, 텍스트 편집기는 Dropbox가 뭔지 몰라도 Dropbox 어플리케이션으로 부터 파일을 열 수 있게 되지.


Neither of these two solutions are perfect, but both are much better than simply providing a global way of storing Twitter credentials.



이 두가지 솔루션들이 완벽하진 않더라도, 두가지 다 트위터 자격 증명을 글로벌하게 저장하는 방법보다는 훨씬 더 간편한 방법이지.



Aside: I don’t think either webOS or Windows Phone 7 (even with contracts) «solve» the «documents problem» on mobile devices, though. Documents should not be relegated into applications. Documents should be a first-level OS concept, the same way apps are. Document management, including document creation, should be handled by the system.



webOS나 Windows Phone 7 (contracts 컨셉을 가지고 있다고 하더라도) 모바일 기기에서 <문서문제>를 <해결>했다고 생각하진 않아, 그럼에도 문서는 어플리케이션 들에 위임해선 안되는 거야. 문서는 OS컨셉의 가장 기본적인 레벨에 포함되어야 한다고, 문서 생성이나 관리도 역시 마찬가지로 시스템 레벨에서 (하나로) 다루어 져야해.



Splitting document management up into two parts, the way Windows and the Mac do it (with parts of it happening in the Finder, and parts of it happening in applications’ open/save dialogs) is one of the dumbest things desktop systems do. It’s probably a result of technical constraints, rather than a conscious design decision (there wasn’t enough RAM to keep the Finder and an app in memory at the same time, thus apps had to replicate parts of the Finder). But somehow, it has survived into the present day.


문서 관리는 두가지 부분으로 나뉘게 되지, 윈도와 맥이 사용하고 있는 방법이 데스크탑 시스템이 하고 있는 제일 멍청한 한가지 방법이야. (Finder에서 일어나는 부분과 어플리케이션의 Open/Save 다이얼로그에서 일어나는 부분) 아마 심각한 디자인 결정이라기 보단 기술적인 제약의 결과인데 (Finder와 어플리케이션이 동시에 메모리를 점유할 만큼 충분한 RAM이 없었기 때문에, 앱은 Finder의 부분을 반복해서 따라해야만 했지) 하지만 어찌됐든, 오늘날까지 살아남게 된 것이지.



The Keyboard 키보드

For a long time, Apple had the best touchscreen keyboard, bar none. Recently, others have caught up. The keyboard in Windows Phone 7 is fantastic, and the one in webOS also does a number of things right.



오랫동안, 애플은 가장 좋은 터치화면 키보드를 가지고 있었어. 최근엔 다른애한테 선두를 뺏겨버렸지만, Windows Phone 7의 키보드는 환상적이라고, 그리고 webOS의 키보드도 몇가지 좋은 점들이 있지.


On screen keyboardOn screen keyboard

To begin with, it has a number row. No more switching between different modes to type numbers. You can access them directly.


일단 숫자 열이 있어. 숫자 모드로 더이상 변환하지 않아도 되지. 숫자를 바로 입력할 수 있다공


My biggest problem with text input on iOS is its flaky autocorrection. I’m regularly typing words iOS doesn’t auto-correct properly, so I need a simple, quick way to revert autocorrection. iOS doesn’t have that. webOS does. Simply hit delete after webOS corrects something. Rather than deleting the last character, this undoes the autocorrection. Boom. Done.


iOS에서 키보드 사용할 때 가장 큰 문제는 별난 자동 고침 기능이야. 난 그냥 단어들을 입력하고 있는데, iOS는 적절하게 자동으로 고쳐주지 못하고 있지, 그래서 난 단순한 방법으로 해결했지 자동 고침 기능을 꺼버렸어. 마지막 글자를 지우는 것 보단 자동 고침을 사용하지 않는게 낫지. 아자 ㅋㅋ


But quite often, I type a lot of text, and don’t pay any attention to autocorrection. On iOS, this means I have to go back and closely read through my text to find every instance where iOS made a ducking error. Not so on webOS.


하지만 나는 꽤나 종종, 많은 글씨를 타이핑 하는데, 자동고침에 아무런 관심을 기울이지 않을 순 없어. iOS에서 이는 즉, 매번 찬찬히 타이핑 한 내 글을 다시 읽어 보면서 iOS가 멍청하게 자동으로 단어들을 고치진 않았는지 살펴봐야 한다는 거야. webOS에선 그럴 필요가 없다구


autocorrectionautocorrection

Autocorrections are underlined, can be easily identified, and, if necessary, quickly reverted. webOS will even make a small noise when it auto-corrects something, so you know when to pay attention.


자동고침 된 단어들은 밑줄이 가져, 쉽게 눈치 챌 수 있게, 그리고 필요하다면 빠르게 자동고침하기 전 상태로 되돌릴 수 있지. webOS는 어떤 단어들을 자동 고침으로 수정할 때 조그만 소리를 내서 알려주기까지 한다고, 그때만 넌 관심을 가지고 살펴보면 되는 거지.



Notifications 알림

This could be an essay all on its own. iOS 5 has introduced a system for managing notifications, and it’s not bad.5 But webOS still wins, doing a number of things that make notifications less intrusive, more useful, and more manageable.


이 기능은 그 자체만으로 에세이를 쓸 수 있을 정도야. iOS5가 알림을 관리하는 시스템을 선보였고, 나쁘진 않더라구, 하지만 여전히 webOS께 훨씬 좋아, 사용할 때 덜 방해하면서도 더 유용하고, 더 관리하기 편하면서도 많은 일들을 할 수 있다고. (이 글 쓸 때, 이전 버전에선 이 자리에 안드로이드 알림 시스템에 대해 불평하는 내용을 적었었는데, ICS를 사용해 보고선 불만을 지웠어. 안드로이드의 새 버전에서 수정이 된 부분에 대해 불평하는 건 불공평해 보이더라구) 


One feature I particularly like is that you can just «shove» a notification away with your finger if you don’t want to see it anymore. It’s just a tiny thing, but it feels so much better and more satisfying than carefully hitting the tiny «delete» button on iOS.


내가 특별히 좋아하는 기능 한가지는 어떤 알림이 보고 싶지 않을 때, 손가락을 사용해 휙 날려버릴 수 있는 기능이야. 매우 작은 부분일뿐인데도, iOS에서 그 조그만 <삭제> 버튼을 조심스럽게 누르는 것보단 훨씬 더 좋고 나은 만족감을 주는 부분이지. (역주. webOS UX팀장이었던 Matias Duarte가 Google의 UX팀장으로 이직한 뒤 ICS에서 그대로 이식됨.)


Another neat feature is that webOS apps can resize to pretty much any size. So when a new notification appears, it doesn’t cover the application. Instead, the application shrinks a bit to make room for the notification.


또 다른 멋진 기능은 webOS 앱들은 어떤 크기로든 리사이즈가 가능한 부분이야. 새 알림이 발생했을 때, 어플리케이션을 덮지 않아도 되지. 그냥 어플리케이션이 줄어들면서 새 알림을 위한 공간을 넓혀주면 되는 거야.



Quick Access to Regularly Changed Settings 최근 변경된 셋팅에 대한 쉬운 접근


On my iPhone, I’m using David Barnard’s Launch Center to get to the Brightness setting. I don’t know if the people at Apple never change their phone’s brightness, but I do this quite often. It’s a chore.


내 아이폰에서는 밝기 셋팅 조절에 접근하기 위해 David BarnardLaunch Center를 사용하고 있어. 애플에서 일하는 사람들은 폰 밝기 조절을 절대 사용하지 않는진 모르겠지만, 나는 꽤나 자주 변경하거든, 귀찮지.


On webOS? webOS에선?


brightness settingbrightness setting

Much easier.


훨씬 편하지.



Just Type 타이핑


It’s a bit like a simple version of Quicksilver, except it’s built right into the OS. Of course, this works best with a hardware keyboard.


OS에 녹아들어 간 것만 제외하면, 퀵실버의 단순 버전에 가까워. 물론 하드웨어 키보드일 때 가장 잘 동작하지.



This Isn’t All 

이것이 전부는 아냐


Of course, this article doesn’t list all of the amazing things webOS does. These are just some of the things that made it easier for me to do actual work on a TouchPad, compared to an iPad. But there’s a lot more webOS does right. For example, I really love the way you develop applications for webOS. And I actually think that the Veer is a pretty great phone.6


물론, 이 글이 webOS에 있는 멋진 기능들을 모두 소개하고 있는 것은 아냐. 이것들은 내가 실제 업무를 하면서 iPad를 사용할 때 보단, TouchPad를 사용하면서 훨씬 편하게 느껴졌던 부분들일 뿐이지. 하지만 webOS가 더 좋은 점은 아직도 많이 남아 있어, 예를 들면, 나는 webOS 용 어플리케이션 개발하는 방식을 진짜 좋아하지. 그리고 실제로 Veer가 진짜 멋진 폰이라고 생각해!
(확실히, 이부분에 있어선 마이너한 취향 일지도 모르지, 하지만 나느 모든 폰이 아이폰 처럼 보일 필욘 없다고 생각한다궁; 더작거나 큰 기기들을 위한 시장이 필요한거야. 모두가 같은 니즈를 가지고 있다고 가정하더라도, 그들이 모두 같은 크기의 손을 가지고 있진 않잖아. 그런 까닭에 나는 또 다른 형태의 입력폼과 입력 방식을 가지고 있는 기기를 위한 시장도 필요하다고 생각해. 개인적으로 나는 하드웨어 키보드와 스타일러스 펜을 진짜 좋아하지; 내 아이패드에서 압력 감지 되는 펜을 이용해서 글도 적고 그림도 그릴 수 있었으면 좋겠다구)



The Future 미래

webOS isn’t quite dead yet. It’s just being open-sourced, which, when it happens to commercial software, often turns out to be the digital equivalent of being reanimated as a walking corpse in a George Romero movie. You’re still shuffling around a bit, and occasionally making some (mostly incomprehensible) noises, but you probably won’t make it too far anymore.


webOS는 아직 전혀 죽지 않았어. 단지 오픈소스화 되었을 뿐이라고, 상용 소프트웨어가 다시 될 수 있을때, 조지 로메오의 영화에서의 움직이는 시체로 다시 살아 나는 것의 디지탈화 된 형태가 될 거야. 조금씩 다리를 질질 끌면서 가끔 (대부분 이해할 수 없는) 소음을 내면서, 하지만 아마도 더이상 멀리까지 갈 순 없겠지. 


Of course, it’s not assured that this is the end of webOS. Maybe open-sourcing it will be the best thing that ever happened to webOS.7 But maybe it just means that HP doesn’t care anymore, and that webOS won’t receive much attention anymore. This would be unfortunate, because webOS is one of the few current mobile operating systems that are actually a joy to use. It’s been hurt by HP’s incompetent management, rather than any egregious faults of its own.


물론 이게 webOS의 마지막 모습이라곤 확신할 수는 없지만 아마도 오픈 소스화 되는 것이 webOS에게 일어날 수 있는 가장 긍정적인 일일 것이야. (그리고 나는 HP 내부 관계자 한테 긍정적인 이야기를 들었지, 모든 희망이 완전히 살아진 것은 아니라구) 하지만 아마도 HP는 더이상 신경을 쓰지 않는 다는 의미겠지, webOS는 더이상 많은 관심을 받기도 어려울 거야. 불행한 일이지, 왜냐면 webOS는 사용하는 게 즐거운 몇 안되는 최근 모바일 OS들 중 하나였거든. 그 자체의 끔찍한 문제라기 보단 단지, HP의 무능한 관리때문에 그렇게 된 것이었다구.


The least we can do now is to keep its best ideas alive, even if webOS itself won’t make it.


지금 최소한 우리가 할 수 있는 것은 그 webOS의 좋은 아이디어들을 계속해서 이어나갈 수 있게 하는 거야, webOS자체에서 볼 수는 없을지라도 ㅠ


You can discuss this article on Hacker News.


이 글은 Hacker News에서 토론할 수 있어.

Tech at 2012. 10. 15. 21:27