들어가며


지난 글, “스타일 가이드로 웹서비스 개발하기”를 통해 스타일 가이드가 무엇인지, 그리고 웹서비스 개발에 스타일 가이드가 얼마나 중요한지 알아보았습니다. 스타일가이드는 단순히 디자인과 프론트엔드 개발의 참고안이 아닌, 서비스와 함께 성장하는 역할을 합니다. 서비스의 운영과 함께 지속적으로 업데이트되며 성장합니다. 

사용자에게 일관된 사용자 경험을 전달하기 위해 UI의 통일성과 확장성은 필수적입니다. 스타일 가이드는 이를 체계적이고 쉽게 할 수 있도록 도와줍니다. 또한, 점점 비대해지는 서비스의 뿌리 역할을 합니다. 

이번에는 스타일 가이드를 실제로 어떻게 작성하고 유지해가야 하는지 알아보겠습니다. 



어떻게 시작할까


하얀 캔버스 위, 비어있는 텍스트 에디터를 보면 난감합니다. 무엇을 만들지 먼저 고민해야 합니다. 먼저 스타일 가이드에 무엇이 들어가야 할지 구상해 봅니다. 서비스의 와이어프레임이나 화면설계가 미리 준비되어 있다면 매우 좋습니다. 그러면 이를 분해하는 작업부터 시작할 수 있습니다. 






화면설계에서 시작하기


서비스가 완성품이라면 스타일 가이드는 ‘조립’을 위한 ‘부품’의 모음입니다. 따라서 완성품을 분해하여 부품을 유추하는 과정으로 시작합니다.


화면설계를 분석하여 UI단위를 분리합니다. 버튼을 하나하나 따로 분리할 수도 있고, 버튼의 모음으로 분리할 수도 있습니다. 화면에서의 역할이나 목적으로 분리할 수도 있고, 개발 관점에서 <table>이나 <form>과 같은 HTML 태그 단위로도 분리할 수 있습니다. 어쨌든 부품을 만들기 위해 분해를 해야 합니다. 이 분해된 단위를 컴포넌트라고 합니다. 


컴포넌트를 나누는 기준은 매우 중요합니다. 너무 작은 단위로 나누면 “가이드”라는 말이 무색할 정도로 어렵고 복잡해질 것이고, 너무 큰 단위로 나누면 상황별로 재사용하기 어려울 수 있습니다. 저는 가장 중요한 기준은 ‘독립성’과 ‘재사용성’이라고 생각합니다. 분해된 ‘부품’은 너무 작지 않아야 합니다. 스스로 독립적인 “상태”를 가지고, “동작 또는 표현”할 수 있어야 합니다.


버튼을 예로 들어 보겠습니다. 버튼은 활성화, 비활성화, 마우스 오버에 대한 반응, 클릭 이후의 변화 등의 상태를 갖습니다. 그리고 가로, 세로, 여백(padding)과 품고 있는 텍스트의 크기와 같은 표현 값을 가집니다. 버튼의 역할을 부연설명하는 아이콘이 들어갈 수도 있습니다. 이 버튼은 독립적으로 존재하므로 하나의 컴포넌트라고 부를 수 있습니다. 버튼에 상태와 표현을 조금씩 변경하면 다른 상태, 모양의 버튼을 몇 번이고 재사용할 수 있습니다. 


화면설계서의 분해



화면설계가 없다면?


화면설계를 분해하면서 컴포넌트들을 정의하는 방법이 좋긴 하지만, 화면이 설계되기 전에 미리 스타일 가이드를 구성할 수도 있습니다. 웹서비스에 쓰일 부품부터 미리 정의해보는 겁니다. 웹서비스에서 자주 쓰이는 버튼, 드롭다운, 목록, 테이블, 양식(form)등을 미리 구상하여 통일성 있게 구성합니다. 

완성품을 예측하여 부품을 만들기란 매우 어려운 과정입니다. 설계 전에 정확히 어떤 요소가 필요할지 미리 알 수 있을까요? 설계하면서 변경되는 경우도 많을 것입니다. 잘 설계된 부품을 조합했을 때 원하지 않은 모습이 나올 수도 있습니다.


그럴 때는 공개된 스타일 가이드를 참고하는 것이 좋습니다. 유명한 Bootstrap이나 Foundation과 같은 프레임워크의 구성을 살펴보겠습니다. bootstrap이나 foundation은 그 구성이 매우 방대하고, 많은 테스트를 거쳐 견고한 상태입니다. 처음부터 이런 완성도를 기대할 수는 없고, 작은 부분부터 참고합니다. 


방대한 프레임워크 안에서 우리에게 필요한 것들을 추리고, 여기서 우리의 부품 만들기를 시작합니다. Bootstrap의 CSS를 보면 기본적인 헤딩의 타이포그래피부터 테이블 양식(form), 버튼 등 기본 UI들이 미리 구성되어 있습니다. 세부 내용을 보면 상황에 맞게 적용할 수 있도록 여러 크기와 상태로 구성된 것을 볼 수 있습니다. 여기서 우리에게 필요한 것들만 취해봅니다. bootstrap에서는 4가지의 크기와 5가지의 상태를 가진 버튼이 있지만 우리 서비스에 필요한 것은 3개라면? 그냥 그렇게 구성하면 됩니다. 스타일 가이드는 언제든 추가, 보완할 수 있으니까요.



프레임워크의 구성 참고



컴포넌트 + @


우리 서비스는 매우 단순하니까 몇 가지 기본 컴포넌트만 넣기로 했습니다. 계속해서 Bootstrap의 CSS를 살펴보는데 “Helper classes”라는 것이 보입니다. 구성에는 텍스트 색상, 정렬, 상자의 정렬, clearfix 등이 있습니다. 이건 어떻게 쓰는 것이고, 어떻게 우리 서비스에 도움이 될까요? 디자이너와 개발자의 취향의 문제이지만, 컴포넌트 외에 서비스 구성을 돕는 이런 “헬퍼”가 필요합니다. 이 헬퍼는 컴포넌트처럼 명확히 눈에 띄고 독립성을 가지진 않습니다. 다만 여러 컴포넌트에게 두루 적용할 수 있는 정렬이나 자주 쓰이는 색상과 상태를 미리 준비해 놓은 것입니다. 이런 헬퍼들이 있어야 통일성있는 CSS 코드를 작성할 수 있습니다. 무엇보다도, 편합니다. 


컴포넌트의 공통적인 상태를 정의하는 헬퍼



HTML, CSS 작성하기 


컴포넌트 구성이 끝났다면 실제 서비스에 적용할 코드를 작성해야 합니다. 서비스의 동적인 부분은 우선 무시하고 HTML과 CSS로 컴포넌트. 즉, 부품들을 작성합니다. HTML 마크업을 할 때는 되도록 컴포넌트 단위로 작성하고, 이후 쉽게 복사하여 사용할 수 있어야 합니다. 컴포넌트의 역할과 상태를 정확하고 알기 쉽도록 class 이름를 지어줍니다. box, area와 같이 혼동할 수 있는 이름보다는 heading-box나 contents-area와 같은 구체적인 이름이 좋습니다. 


CSS는 컴포넌트의 복잡한 정도에 따라 길어질 수 있습니다. 다양한 상태를 표현해야 한다면 코드는 복잡해지고, 다른 컴포넌트의 스타일 간섭이 있을 수 있습니다. 이를 막기 위해 SASS와 같은 전처리기를 사용합니다. CSS 전처리기는 간결한 문법으로 작성하고 이를 CSS로 변환하여 적용하는 개발 편의 도구입니다. 대표적으로 SASSLESS가 있습니다. 작성하기 쉽고, 무엇보다 유지보수가 편합니다. 코드의 가독성도 매우 좋습니다. 컴포넌트의 이름 단위로 nesting한다면 굉장한 업무 효율을 기대할 수 있습니다. 



SASS로 간결하게 




마치며


세상에 100가지 웹서비스가 있다면 개발방식도 100가지가 있을 것입니다. 어쩌면 100가지를 넘을 수도 있습니다. 디자이너와 개발자의 취향에 따라 많은 선택지가 있어 같은 사람이 같은 서비스를 만들어도 다른 결과물이 나올 수 있기 때문입니다. 내 머릿속에 서비스의 지도가 한 번에 그려진다면 어쩌면 스타일 가이드는 필요하지 않을 수 있습니다. 하지만 점점 커지는 서비스의 구석구석을 모두 기억하는 것은 불가능합니다. 무엇보다 우리는 혼자가 아니어서 하나의 결과물을 다수가 만들고 있습니다. 

여러 사람이 만들어도 마치 한 명이 작업한 것처럼 UI의 품질과 통일성이 보장되고, 지속적인 확장이 가능한 이유는 이런 스타일 가이드가 존재하기 때문입니다. 


스타일 가이드는 그 자체로 영감의 원천이 될 수도 있습니다. 컴포넌트를 분리하고 조합하는 과정에서 새로운 아이디어를 얻을 수 있고, 지속적으로 업데이트를 통해 서비스 품질을 향상시킬 수 있기 때문입니다. 아주 작게 시작할 수 있습니다. 스크린 단위의 화면을 디자인하기 전에 스타일 가이드를 고려해 보는 것은 어떨까요.





작성: 문윤기


Posted by slowalk

지난 포스팅에서 개발자와 대화하고 싶은 비 개발자를 위한 참고서에 대한 글을 작성했습니다. 이번 포스팅에서는 개발자와 기획자 간 원활한 커뮤니케이션을 위해 저희 팀 내에서 초기 사용했던 방법이 현재는 어떻게 바뀌었는지 사례를 통해 보여드리겠습니다.

주의! 이 방법은 주로 슬로워크 1팀 기획자인 저와 개발자들이 사용하는 방식으로, 회사별로 팀별로 방법이 다를 수 있습니다. 가장 좋은 방법은 팀 내에서 서로 많은 대화를 해보는 것입니다.




1. 기획자와 개발자의 시간은 다르게 간다.

“이거 금방 되죠?” vs “이거 오래 걸려요”



초기에 기획자로서 흔히 했던 실수는, 개발자에게 정확한 기간이나 요건을 설명하지 않고 금방 될 것이라 추측한 것입니다. ‘금방’, ‘오래'와 같은 단어는 주관적입니다. 내가 생각하는 금방은 하루지만 상대방이 생각하는 금방은 3일일 수 있습니다. “이거 금방 되죠?"와 같은 질문을 받은 개발자는 당연히 금방 되지 않으니 오래 걸린다고 답할 수밖에 없습니다. 그러다 보니 서로 갈등과 오해가 생기게 됩니다. 기획자는 ‘분명 이전 프로젝트에서는 금방 해주었던 것 같은데, 왜 오래 걸린다는 거지’ 혼자 생각하고, 개발자는 ‘지금 요건에서 그 기능은 금방 추가할 수가 없는데 왜 금방 된다는 거지’ 하며 답답해 합니다.


시간에 대해 설명할 때는 구체적인 언급이 필요합니다. 모호하고 주관적 단어 대신 구체적인 단어를 선택해야 합니다.


“이런 기능 요건이 추가되었는데, 3일 안에 가능할까요?”

“이 기능은 지난 프로젝트에서 사용했지만, 이번 프로젝트 개발 구조와 달라 수정이 필요할 것 같아서 3일은 어렵고 5일이 소요될 것 같아요.”


위와 같이 서로 구체적인 기간을 언급하고, 그 이유를 설명해야 불필요한 오해의 소지를 줄일 수 있습니다. 또한, 고객에게 일정을 설명할 때도 정확한 기간을 언급해주는 것이 신뢰의 기본입니다.




2. 개발자와 기획자의 서로 다른 언어

이해관계자와 수많은 커뮤니케이션 vs 프로그래밍 언어로 컴퓨터와 커뮤니케이션




기획자는 여러 이해관계자와 다양한 수준의 커뮤니케이션을 합니다. 이를 통해 일을 정리하고 상대방을 설득하며, 개발자에게도 설명합니다. 즉 기획자가 하는 모든 일은 다른 사람들에게 상대방의 생각을 올바르게 커뮤니케이션해주는 과정에 있습니다. 개발자는 해당 내용을 결과물로 보여주기 위해 일반인이 이해하기 힘든 프로그래밍 코드를 작성하고, 컴퓨터와 대화를 주고 받습니다. 기획안을 오랫동안 설명하였는데 나의 기획과 다른 개발 결과물이 나오는 일도 있고, 반대로 기획자가 가져온 그대로 개발하였는데 번복하는 상황이 생기기도 합니다.


서로가 대화하는 대상이 다름을 인지하는 것이 가장 중요합니다.

기획자는 자신뿐만 아니라 상대방의 생각도, 고객의 요구도 반영해야 합니다. 개발자는 그러한 결과물을 구현해주기 위해 컴퓨터와 끊임없이 대화하고 수정합니다. 그렇기 때문에 서로의 커뮤니케이션 대상자가 다름을 이해할 때 서로 불필요한 오해를 줄일 수 있습니다. 특히 개발언어는 정량적 측정이 어렵기 때문에 정확한 기간을 말하기 힘들 때가 있습니다.


커뮤니케이션 대상자는 다르지만 하나의 결과물을 위해 함께 협업해야 한다는 점을 기억하세요.



3. 개발자와 기획자의 논리적인 대화를 위한 3단계

“이 기능 간단하죠? 전에 한 거랑 같은데.” vs “이거 달라요, 여기엔 안 돼요.”




기획과 개발은 서로 함께 하나의 목표를 위해 달려가는 협업과정입니다. 그 과정에서 서로가 생각하는 바가 다르기도 하고 머릿속에 있는 것을 말로만 설명해서는 이해하기가 어렵습니다. 막바지에 이르러 서로 다른 결과물을 가지고 볼 수도 있습니다. 따라서 대화 전에 아래와 같은 사전 기획서 혹은 간단한 문서를 통해 대화하면 조금 더 논리적이고 오해가 적은  커뮤니케이션을 할 수 있습니다.


1) 자신의 생각을 정리한다

2) 생각을 구체적으로 손으로 그리거나 툴을 이용해 누구나 이해할 수 있게 그린다

3) 1:1로 직접 보고 대화한다


<실제 1팀에서 기획자와 개발자 간에 대화를 위해 작성한 페이퍼프로토타입, ppt 문서>



슬로워크 1팀에서 기획자는 주로 moqups.com과 ppt를 사용합니다. 와이어프레임을 그려 디자이너와 개발자에게 전달하고 내부 세미나를 합니다. 또 역으로 개발자가 기획자에게 관리자 화면이나 기획안 수정 및 요청을 할 때가 있습니다. 주로 직접 그려서 주거나 엑셀 표에 작성해서 전달합니다. 또 가까운 공간에 서로 함께 일하기 때문에 끊임없이 이야기하면서 커뮤니케이션 능력을 서로 업그레이드시키고 있습니다. 특히 제가 개인적으로 선호하는 방식은, 개발자에게 먼저 묻고 일정과 협의를 진행하는 것입니다. 그렇게 되면 일정이나 서로 개발범위에 따른 오해의 소지가 반 이상 줄어들고, 서로 존중하는 프로젝트가 진행됩니다. 개인적으로 짐작하거나 말을 걸기 두려워 지레짐작하다 보면 프로젝트는 산으로 가기 십상입니다. 최근 1팀의 대화는 이렇습니다.


“ A와 B를 통해서 C가 나오도록 해주세요, 10일간의 일정에 가능할까요? “

“네, A와 B를 OO코드로 C가 나오도록 구현할게요. 일정은 10일이면 가능할 것 같아요. ”



4. 마무리

‘우리는 모두 한 배를 타고 있다.’ 서로의 언어에 관심을 가지는 것이 시작입니다.



사실 커뮤니케이션 방법에 정답은 없습니다. 우리 팀에서 잘 맞고, 우리 팀원들과 적합한 커뮤니케이션 방식을 찾아가는 것 또한 업무의 일환이라고 생각합니다. 다만 서로에 대한 배려와 이해하고자 하는 마음 그리고 조금 더 구체적으로 서로의 업무를 설명하는 것이 신뢰를 위한 첫 걸음입니다.



Posted by slowalk

이메일마케팅의 진정한 재앙, 스팸신고.

수신거부를 제대로 유도하면 스팸신고를 막을 수 있다.



스티비를 운영하다 보면 이런 질문을 가끔 받습니다.

“이메일에 수신거부 링크를 꼭 삽입해야 하나요?”

“수신거부 링크를 아주 작게, 잘 안 보이게 해도 될까요?”


수신거부 링크가 거슬리는 것, 이해합니다. ‘수신거부 링크가 잘 보이고 누르기 편할수록 수신거부하는 구독자가 늘어나지 않을까?’하는 고민이 생길 수밖에 없습니다.


일반 상식과는 약간 다른 접근법을 제안해 드립니다. 수신거부보다 스팸신고가 더 큰 재앙이기 때문입니다. 스팸신고를 막기 위해 수신거부를 적절히 이용할 필요가 있습니다.  왜 스팸신고가 재앙인지, 스팸신고를 막기 위해 수신거부를 어떻게 활용할지 알아보겠습니다.


1. 스팸신고가 왜 재앙인가?

수신거부는 이메일 수신을 중단하고 싶은 의사가 있는 구독자 1명에게만 영향을 미칩니다. 구독자 A가 수신거부를 했다고 해서 다른 구독자들에게 미치는 영향은 전혀 없습니다.


그러나 스팸신고는 다릅니다. 만약 Gmail을 사용하는 구독자 A가 스팸신고를 한다면, Gmail을 사용하는 모든 구독자들에게 영향을 미칠 수 있습니다. Gmail과 같은 메일박스 프로바이더(Mailbox Provider; 이메일 주소를 생성하여 이메일을 보내고 받고 보관하게 해 주는 서비스)는 스팸신고가 많이 들어온 이메일 발신자를 학습해서 스팸 필터링에 활용합니다. 즉 Gmail을 사용하는 구독자가 특정 이메일의 스팸신고를 많이 한다면, 스팸신고를 하지 않은 다른 Gmail 사용자에게도 이메일이 도달하지 않고 스팸편지함에 빠질 수 있는 것입니다. 이렇듯 한명 한명의 스팸신고가 누적되면 발신자의 평판이 낮아져서 원래 이메일을 잘 받아보고 있던 구독자에게도 도달하지 못할 수 있습니다.


Gmail이 스팸을 인식하는 방법



2. 점점 쉬워지는 수신거부

스팸신고라는 재앙을 피하기 위해 다양한 해결책이 등장하고 있습니다. Gmail과 iOS10 기본 메일앱 등에서는 일부 이메일에서 ‘수신거부’ 또는 ‘구독 취소' 기능을 이메일 상단에서 쉽게 사용할 수 있도록 제공합니다. 스팸신고보다 수신거부를 유도하기 위해서입니다. (자세한 내용 보기: 9 Things You Need to Know About Email in iOS 10)


Gmail에서 ‘수신거부' 기능을 제공한다


iOS10의 기본 메일앱에서 ‘구독 취소' 기능을 제공한다


3. 수신거부 문구도 색다르게

아무리 스팸신고라는 대재앙을 피했다 하더라도, 설레는 마음으로 이메일을 보냈는데 수신거부가 되돌아오면 마음이 아픕니다. 이럴 때 “수신을 원치 않으면 수신거부를 클릭하세요”처럼 딱딱하고 건조한 문구로는 아쉬운 마음을 전할 수 없습니다. 아쉬운 마음을 담은 부드럽고 진지한 수신거부 문구를 소개합니다.


“이메일을 그만 받고 싶으면, 수신거부 하세요. 서로 감정 상하지 않기로 해요.” NextDraft

“떠나는 게 아쉽긴 하지만, 언제든 바로 수신거부 할 수 있어요.” Hitne’s SaaS Weekly

“만약 도움이 되지 않는다 생각하시면 구독해지를 해주세요.” 오픈서베이



수신거부를 확인하는 랜딩페이지에서는 더 많은 메시지를 전달할 수 있습니다. 동영상을 활용하는 것도 좋은 방법입니다.


“가까웠던 우리 사이가 벌써 그리워요.” HubSpot (클릭하면 동영상을 확인할 수 있습니다.)



스팸신고를 막기 위해 수신거부가 왜 중요한지 알아봤습니다. 중요한 내용만 요약하면 아래와 같습니다.


수신거부가 편해야 더이상 관심없는 구독자를 떨궈내고 핵심 구독자에게 집중할 수 있다.

수신거부 링크를 못 찾은 구독자가 귀찮은 마음에 스팸신고를 눌러버리면 그것이야말로 진정한 재앙이다.

한명 한명의 스팸신고가 누적되면 발신자의 평판이 낮아져서 핵심 구독자의 메일함에서도 스팸처리되는 재앙이 생길 수 있다.


더 읽어보기: Why an Unsubscribe is Better Than Being Marked as Spam ― Litmus

참고: 수신거부 문구의 재발견 ― 스티비 블로그




작성: 조성도
Posted by slowalk

 

인터랙티브 미디어(Interactive Media)란 무엇일까요? 인터랙티브 미디어는 커뮤니케이션 수단의 하나로 사용자의 동작에 프로그램이 반응하고 프로그램의 반응에 사용자가 영향을 받는 상호작용하는 미디어를 뜻합니다.


우리가 흔히 접하는 웹사이트나 게임 등이 이 인터랙티브 미디어의 한 종류인데요. 요즘에는 웹 디바이스 안에서 뿐만 아니라 3차원의 물리적인 공간에도 적용되는 경우가 많아지고 있습니다. 기술에 대해서는 1도 모르는 디자이너이지만 디자인에 효과적이고 입체적으로 접근하는 방식으로서 인터랙티브 미디어에 관심을 갖게 되었는데요. 디자인 기반의 스튜디오 Dalziel and Pow가 인터랙티브 미디어 월(Interactive Media Wall)을 만든 과정을 소개합니다.

 

Storytelling through playful interactions from Dalziel & Pow on Vimeo.



Dalziel and Pow에서는 런던에서 열린 <리테일 디자인 엑스포 2015>에서 ‘전자잉크(E-ink)*’를 활용하여 주목할 만한 디스플레이 작업을 만들었습니다. 사용자는 회로와 움직이는 다양한 요소로 완성된 부스 벽의 일러스트 이미지를 터치할 수 있습니다. 2d 그래픽에 손을 대면 빛과 소리가 나니 마치 만화 속의 주인공들이 현실로 걸어 나온 것 같은 즐거운 경험을 할 수 있는데요. 사용자는 스위치를 켜 전구의 불을 밝히거나 실로폰을 연주하기도 하고, 손을 대면 광선을 쏘는 경험을 할 수 있습니다.

 *전자잉크는 인쇄필름과 종이 등에 특수 전자잉크를 인쇄하는 간단한 공정만으로 다양한 전자부품소재에 적용이 가능한 잉크를 통칭하는 말입니다. 과거 전극을 만드는 방식에 비해 전자잉크 프린팅 방식은 전자잉크로 바로 프린팅해 건조시키는 단순 공정만으로 원하는 전극을 형성할 수 있어 제조시간을 단축하고, 원가를 낮출 수 있는 장점이 있습니다. 친숙한 재료는 아니지만 대표적으로 휴대용 전자책(e-book) 단말기에 쓰입니다. 출처: 디지털타임스

  

디자이너와 프로듀서로 구성된 Dalziel and Pow 스튜디오는 이 작업을 디지털, 인테리어, 그래픽 팀의 도움을 받아 인하우스 프로젝트로 진행했습니다. 런던 스튜디오 협회의 디지털 디자인 디렉터인 로스 필립스(Ross Phillips)는 “우리의 주요한 목적은 전략적인 경험을 만드는 것이었습니다. 우리는 종종 얼마나 더 놀랍고 상상해보지 못한 것을 보여줄 수 있을 지에 대해 이야기합니다.”라고 말합니다. 이들이 사용한 전자잉크는 더욱 더 전통적이고 친숙하고 따뜻한 재료에 기술을 접목할 수 있게 합니다.

 

 

큰 합판을 캔버스 삼아, 제작자는 실크스크린 프린트 스튜디오와 함께 전자잉크로 전시의 벽이 될 판에 인쇄합니다. 필립스는 “우리는 물리적인 공간 안으로 기술을 결합하는 새로운 방법을 발굴하여 사용자가 흥미롭게 느끼면서 직접 체험하도록 합니다.”라고 말합니다.

 

주문 제작으로 인쇄된 디자인은 제작자의 의도대로 다양한 터치와 인터랙션이 가능합니다. “리테일의 미래”라는 전시 주제에 맞게 이야기 보따리를 풀어놓고 가능한 인터랙션을 구상했습니다. 그리고 이 이야기에 기초하여 디스플레이에 나타날 48개의 애니메이션 시리즈를 그렸습니다. 필립스는 “다양한 종류의 내용이 담긴 벽과 함께 사용자가 놀고 경험하고 발견하는 공간을 계획했습니다. 그러나 우리에게 정말 중요한 도전은 이러한 대규모의 콘텐츠를 생산해보는 것입니다. 대부분의 그림이 하나 당 3개의 다른 애니메이션을 보여줍니다. 전체 합치면 250개가 넘는 양이지요.”라고 말했습니다. 제작자들은 이전 작업에서 피드백을 받아 이번에는 움직이는 애니메이션과 함께 믹스 영상을 추가했습니다.

 

인쇄 작업은 한 번의 공정을 더 거칩니다. 전자잉크로 스크린 인쇄를 한 후에 일반 하얀색 잉크로 레이어를 씌웠습니다. 이는 프로젝터로 쏜 영상이 보일 수 있게 하기 위해서 입니다. 이때 주의할 것은 회로가 사용자의 터치에 여전히 반응할 수 있도록 얇게 씌어야 된다는 점입니다. 


 

전자잉크는 ‘Ototo’라 불리는 터치를 소리로 바꾸어 주는 장치와 연결합니다. Ototo는 전도성이 있는 물체와 연결한 뒤에 그 물체에 터치하면 입력해 놓은 소리가 나도록 만들어진 장치입니다. 필립스와 그의 팀은 합판과 Ototo가 잘 연결될 수 있게 제작 주문하여 사용자가 전시를 보며 상호작용할 수 있게 만들었습니다. Ototo와 연결하면서 사용자는 다양한 소리와 시각적 요소가 어우러진 마치 살아있는 듯한 벽을 경험하게 됩니다.


Ototo Introduction from Dentaku on Youtube.

 

 

애니메이션은 ‘VJ’라고 불리는 프로젝션 매핑 소프트웨어 사용을 조절하기 위해 다중 최적화된 프로젝터를 통해 영상을 재생합니다. VJ 프로젝션 매핑 소프트웨어는 우리가 주로 클럽이나 공연 등에서 음악과 함께 보이는 시각 효과를 보여줄 때 주로 쓰인다고 합니다. 주로 많이 쓰는 소프트웨어에는 맥에서는 Mad Mapper, Millumin 등이 있고, 윈도우즈 용으로는 Touch Designer, Resolume Arena 4 등이 있습니다.

 

 

여기까지 Dalziel and Pow가 인터랙티브 미디어월을 만드는 과정을 살펴보았는데요. 매력적인 경험을 제공하는 인터랙티브 미디어 월은 조금 어려워 보이지만 찬찬이 살펴보니 생각보다 이해하기 어렵지 않았습니다. 점점 더 발달하는 3차원 공간에서의 인터랙티브 미디어는 앞으로도 우리의 삶을 더욱 흥미진진하게 할 것이라 기대됩니다.


참고: How Dalziel and Pow Realized This Awesome Interactive Touch Wall

 


작성: 김한솔


Posted by slowalk



슬로워크의 스티비 팀에서는 디자인 작업을 할 때 스케치(Sketch)를 적극적으로 활용하고 있습니다. 와이어프레임을 만드는 일부터 GUI를 입히고 간단한 아이콘을 만드는 일까지, 스케치로 시작해서 스케치로 끝난다고 할 수 있을 정도입니다.


스티비 팀이 쓴 스케치 관련 글



스케치로 작업 중인 새로운 스티비의 와이어프레임(좌)과 GUI(우)



스케치를 사용하다보면 가끔씩 ‘이런 기능도 있으면 참 좋을텐데'하는 생각이 들 때가 있습니다. 이런 부족함을 충족시켜주는 것이 스케치의 플러그인*입니다. 스케치 외에도 대부분의 유사한 애플리케이션들(포토샵, 일러스트레이터 등)이 플러그인 기능을 가지고 있지만, 고작 6년 밖에 되지 않았고(26년 된 포토샵과 비교하면 ‘고작 6년’) 19명 밖에 되지 않는 작은 규모의 팀이 만들고 있는 스케치 입장에서, 플러그인의 다양성은 다른 애플리케이션들과의 경쟁에서 앞서나갈 수 있는 좋은 무기 중 하나일 것입니다.


* 플러그인이란 애플리케이션이 제공하지 않는 기능을 사용하기 위해 설치하는 일종의 확장 프로그램을 말합니다.



스케치 공식 홈페이지에는 무려 366개의 플러그인이 소개되고 있습니다. 이제 여기에 소개되는 일만 남았습니다!



스케치 플러그인을 직접 만들어볼 수는 없을까요?


아티스트라면 자신이 사용하는 도구 정도는 직접 만들 줄 알아야 한다는 말이 있듯이, 디지털 시대의 기획자라면 자신의 제품을 만드는 도구를 만들지는 못하더라도 그 도구의 손잡이 정도는 만들 수 있어야 하지 않을까 싶지만, 물론 코알못(‘코딩을 알지 못하는 사람’의 줄임말) 입장에서 플러그인을 만든다는 것은 손잡이는 커녕 정말이지 상상도 안 되고 감도 잡히지 않는 것입니다. 플러그인은 누군가 만들어놓은 걸 내려받아서 설치해서 사용해보기만 했지, 그걸 직접 만든다는 생각은 해본 적이 없으니까요.


하지만 스케치 플러그인은 비교적 접근하기 쉬운 CocoaScript*로 만들 수 있다는 사실에 약간의 흥미가 생겼고(정확히 말하면 두려움이 줄어들었다는 게 맞겠네요), 마침 개발 과정을 아주 쉽게 소개한 글을 발견하고 도전해보기로 했습니다.


* CocoaScript는 스케치가 실행되는 MacOS의 개발 언어인 Objective-C와 Cocoa의 코드를 비교적 쉬운 Javascript 문법으로 사용할 수 있게 해주는 프레임워크입니다.


그럼 시작합니다.


  1. 코알못이 무작정 도전해본 스케치 플러그인 개발 과정을 연재할 예정입니다. 코알못이 쓴 글이니 코알못이 아닌 분의 입장에서는 지루할 수 있습니다. 물론 저같은 코알못인 분의 입장에서도 지루할 수 있습니다.

  2. 스케치는 MacOS용 애플리케이션이며 플러그인도 MacOS에서만 개발할 수 있습니다. 이 글도 MacOS를 기준으로 작성됐습니다.

  3. 중간에 포기한다면 이 글이 마지막이 될 수도 있습니다.



준비하기


1. 텍스트 에디터를 설치합니다.

글을 쓰려면 노트가 필요하듯 코드를 쓰려면 에디터가 필요합니다. 프론트엔드 개발자들이 가장 많이 사용하는 에디터 중 하나인 Sublime Text 3를 추천합니다.


2. '콘솔(Console)'을 실행합니다.

디버깅(코드를 실행한 결과를 확인하는 과정)을 위해 MacOS의 기본 애플리케이션인 콘솔을 실행합니다. MacOS의 ‘Spotlight’(단축키 control+space)에서 ‘콘솔’ 또는 ‘console’을 검색하면 실행할 수 있습니다. 콘솔이 실행되면 왼쪽 사이드바에서 ‘리포트'의 ‘system.log’를 선택합니다. 여기에서 스케치 플러그인을 개발하면서 작성한 코드가 어떤 결과를 출력하는지 확인할 수 있습니다.


콘솔은 이렇게 생겼습니다. 외계어 같은 것이 써있네요. 검색 창에 ‘sketch plugin’를 입력하면 스케치 플러그인과 관련된 로그만 따로 볼 수 있습니다.



3. 스케치 플러그인 폴더를 찾아갑니다.

스케치 플러그인 폴더의 경로는 다음과 같습니다. (이 폴더는 스케치 플러그인을 개발하면서 자주 확인해야 하므로 파인더(Finder)의 즐겨찾기에 추가해두면 좋습니다.)

/사용자/[사용자 이름]/라이브러리/Application Support/com.bohemiancoding.sketch3/Plugins


이미 설치한 플러그인이 있다면 스케치 플러그인 폴더에 ‘.sketchplugin’이라는 확장자를 가진 파일이 있는 것을 확인할 수 있습니다.



플러그인 만들기


스케치 플러그인은 ‘.sketchplugin’이라는 확장자를 가진 패키지 파일로 존재합니다. 이미 설치한 플러그인이 있다면 ‘.sketchplugin’ 파일을 오른쪽 클릭한 뒤 ’패키지 내용 보기'를 선택하면 플러그인을 구성하는 파일들을 확인할 수 있습니다.


스케치 플러그인의 파일 구조는 다음과 같습니다.



‘.sketchplugin’ 아래 ‘Contents’ 폴더가 있고 그 아래 ‘Sketch’ 폴더가 있습니다. ‘Sketch’ 폴더 안에는 플러그인의 기본 정보를 담고있는 ‘manifest.json’ 파일과 플러그인이 실제로 작동하는 코드를 담고있는 js 파일이 있습니다.


위 구조를 참고하여 ’MyPlugin’이라는 샘플 플러그인을 만들어보겠습니다.


1. ‘Plugins’ 폴더 아래 ‘MyPlugin.sketchplugin’이라는 폴더를 만듭니다.


2. ‘MyPlugin.sketchplugin’을 오른쪽 클릭한 뒤 ’패키지 내용 보기'를 선택합니다. (‘MyPlugin.sketchplugin’은 확장자를 가지고 있기 때문에 더블클릭하면 파일이 실행됩니다. 폴더를 탐색하려면 ’패키지 내용 보기'를 선택해야 합니다.)




3. 이 안에 ’Contents’라는 폴더를 만듭니다.


4. ‘Contents’ 폴더 안에 ’Sketch’라는 폴더를 만듭니다.


5. 이제 ‘manifest.json’ 파일과 js 파일을 만들 차례입니다. js 파일의 이름은 편의상 ‘MyScript.js’로 하겠습니다. js 파일의 이름은 원하는대로 수정해도 되지만 ‘manifest.json’ 파일 안에 js 파일의 이름이 정의되어있기 때문에 함께 수정해야 합니다. 설치한 텍스트 에디터를 실행하고 각각 아래 코드들을 붙여넣어 저장합니다.


먼저 ‘manifest.json’ 파일입니다.



'manifest.json' 파일은 플러그인에 대한 기본적인 정보와 실제 플러그인을 실행하기 위한 플러그인 파일 정보, 스케치 애플리케이션에 표시할 메뉴 구성, 단축키, 플러그인 식별 값 등 일종의 트리거(trigger)를 담고 있습니다.


그리고 MyScript.js 파일입니다. js 파일의 이름을 수정하면 ‘menifesto.json’의 ’“script” : “MyScript.js”’ 부분을 함께 수정하면 됩니다.



'MyScript.js' 파일이 담고있는 이 코드가 실제로 플러그인이 동작하는 내용입니다. 코드의 내용에 대한 자세한 설명은 우선 건너뛰겠습니다. 



플러그인 실행하기


이제 스케치의 ’Plugins’ 메뉴를 열어보면 ’My Plugin’이라는 플러그인이 설치된 것을 확인할 수 있습니다. ‘My Plugin’의 ‘Get Page Names’를 선택하면 ‘MyScript.js’의 코드가 실행됩니다. 




플러그인 실행 결과 확인하기


플러그인이 실행된 결과는 ‘준비하기’ 단계에서 미리 열어놨던 콘솔에서 확인할 수 있습니다. 왼쪽 사이드바에서 ’리포트’의 ‘system.log’를 선택하면 나오는 화면에 아래와 같은 내용이 출력됐다면 플러그인이 정상적으로 실행된 것입니다.


플러그인을 실행할 때 선택되어있던 페이지 이름인 ‘Page 1’이 출력됐습니다!!



여기까지 문제없이 잘 따라오셨나요? 이제 스케치 플러그인을 생성하고 코드 실행 결과를 확인하는 방법을 알게 됐을 뿐입니다. 하지만 일단 이 과정을 이해했다면 적어도 다른 플러그인의 구조를 뜯어보는 것까지는 가능할 것입니다. 


이어지는 글에서는 플러그인을 통해 스케치의 기능을 어떻게 제어하는지, 그것을 코드로 어떻게 구현하는지 알아보겠습니다. 그 전까지 제가 포기하지 않는다면…



참고

The Beginner’s Guide to Writing Sketch Plugins Part 1 — Getting Started

Sketch Developer



Posted by slowalk

[2016 TEDC Boston]

스티비 조성도 총괄과 임호열 기획자가 이메일마케팅 컨퍼런스의 왕중왕, TEDC에 다녀왔습니다. 그곳에서 얻어오는 이메일마케팅 노하우와 실질적인 팁이 궁금하신 분들은 콘텐츠 하단의 프로젝트에 참여해주세요.

(이 글은 콘텐츠 크라우드펀딩 플랫폼 PUBLY에도 발행되었습니다.)



94.2억 달러

스티비 자체 조사 결과 2010년부터 2016년 7월까지의 전세계 이메일마케팅 업계 M&A 규모는 약 94.2억 달러이다. 원화로는 10조 원이 넘는다. 인수금액이 공개된 것만 이렇다. 구글의 Sparrow 인수(2012년)나 드롭박스의 Mailbox 인수(2013년), MS의 Accompli 인수(2014년) 등 이메일앱 M&A를 제외하고 마케팅 서비스만 조사한 결과이다. 이메일마케팅 업계 M&A는 IBM, Salesforce.com 등 B2B IT 서비스 업체들이 주도하고 있지만 Deutsche Post(2013년에 Optivo 인수)와 같은 의외의 플레이어도 있다.


왜 이렇게 이메일마케팅 업계의 M&A가 활발할까? 이메일은 가장 보편적인 마케팅 채널이고, 스마트폰이 보급되면서 더 각광받고 있다. 잠깐, 이메일이 각광받고 있다니 뭔가 이상한가? 그런 생각이 드는 게 맞다. 한국에서는 별로 각광받고 있지 않기 때문이다.



70.3%

스티비가 2015년에 마케터들을 대상으로 조사한 '이메일마케팅 현황 및 인식 보고서'에 따르면 응답자의 70.3%가 현재 이메일 뉴스레터를 발행하고 있거나 발행할 계획을 갖고 있다고 답했다. 그렇지만 페이스북, 인스타그램, 유튜브 등 다른 디지털마케팅 채널에 비해 이메일에 대한 논의는 찾아보기 어렵다. 마케터들이 이메일은 이미 잘 알고 있어서일까? 나는 그렇게 생각하지 않는다.

수많은 마케팅 이메일을 보내고, 또 받고 있지만 이메일마케팅에 대해서 한국어로 알 수 있는 팁과 트렌드는 제한적이었다. 그동안 이메일마케팅의 최신 트렌드에 대해 전문적으로 다루는 매체를 찾아볼 수 없었기 때문이다.

그래서 이메일마케팅 서비스 스티비를 출시하기 전, 우리는 이메일마케팅에 대한 정보를 알려주는 뉴스레터 발송부터 시작했다. 잠재고객을 확보하는 좋은 방법이라고 생각했다. 덕분에 별다른 마케팅 활동 없이도 뉴스레터 발송 1년 만에 구독자를 2,000명 넘게 확보할 수 있었다.

뉴스레터를 발행하기 시작하니 많은 사람들이 우리에게 이메일마케팅에 대해 질문해오기 시작했다. 이메일마케팅은 늘 해오던 것이고, 딱히 그만둘 이유가 있는 것도 아니지만 늘 궁금증은 간직해오고 있던 것이었다.

"이게 효과가 있는 것인가?"

"내가 잘 하고 있는 건가?"

"어떻게 하면 더 효과를 높일 수 있는가?"

이런 질문들이 몰려들었다.

나뿐만 아니라 스티비의 다른 팀원까지에게도 강의 요청이 많이 왔다. 지금껏 패스트캠퍼스, 어벤저스쿨, 사회복지웹기획자모임, 서울시 청년허브, 수원시평생학습관 등에서 강의했는데 예상 외의 호응에 우리도 놀랐다. 이메일마케팅에 대해 궁금한 게 많은데 어디 물어볼 데가 없는 것이었다. 논의할 데도 없고 고민을 나눌 데도 없었다. 스티비는 마케터들의 그런 욕구를 충족시켜 주고 싶었다.



이메일은 죽지 않았다. 다만,

이메일마케팅에 대한 리서치를 하다 보면 많이 접하는 문구가 있다.

"Email is not dead."

물론 이메일마케터들의 주장이다. 심지어 저 문구를 타이틀로 내건 사이트도 있다. 이메일마케팅에 대한 긍정적인 팩트를 모아 놓은 곳이다.


그러던 중 이번에는 약간 다른 제목의 글을 발견했다.

"Email isn't dead, but your strategy might be."

Action Rocket이라는 이메일마케팅 에이전시와 Taxi for Email이라는 이메일콘텐츠 관리 서비스의 창립자 Elliot Ross가 쓴 글이다. '이메일은 죽지 않았다. 다만 당신의 전략은 죽었을지도 모른다'는 제목이 현재 이메일마케팅의 상황을 여실히 보여주고 있다.

'살아있는 이메일', 즉 마케팅 목표를 달성하는 이메일을 보내려면 어떻게 해야 할까? 기획, 콘텐츠, 디자인, 개발 어느 하나 신경쓰지 않으면 안 된다. 이번에 열리는 TEDC(The Email Design Conference)는 그 모든 것을 다루는 컨퍼런스이다. 다른 디지털마케팅 컨퍼런스처럼 마케터들만 모이는 곳이 아니라 콘텐츠 에디터, 개발자, 디자이너가 함께 모인다.



'이메일계의 WWDC', TEDC

WWDC(Worldwide Developers Conference)는 애플에서 매년 6월에 개최하는 개발자 컨퍼런스이다. WWDC에 MacOS/iOS 생태계와 관련된 모든 사람들이 모이듯이 TEDC에는 이메일마케팅과 관련된 모든 사람들이 모인다. 그래서 작년에 스티비 개발을 시작하면서 "내년에는 꼭 TEDC에 가야지"하고 다짐했었다.

보스턴 행사에 앞선 런던 컨퍼런스(7.26-27)가 열리는 동안 트위터에서 #LitmusLive 해시태그를 지켜봤는데, 그 중에서 유용한 것 몇 가지를 골라봤다.


이미지를 누르면 해당 트윗 창으로 가실 수 있습니다. - PUBLY ⓒCatalin Bridinel

이메일 발송 48시간 이후에는 오픈&클릭률이 0.1%로 뚝 떨어진다. 오픈하지 않은 사람들에게 같은 내용을 제목만 다르게 해서 재발송해라.

이미지를 누르면 해당 트윗 창으로 가실 수 있습니다. - PUBLY ⓒJustine Jordan


오픈하지 않은 사람들에게 같은 내용을 다른 제목으로 재발송하니, 컨버전이 35% 증가했다.

이미지를 누르면 해당 트윗 창으로 가실 수 있습니다. - PUBLY ⓒLauren Smith



같은 내용의 이메일을 재발송해도, 평판이 나빠지진 않는다. 두 메일을 모두 열어보는 구독자는 전체의 0.09% 뿐이다.

이미지를 누르면 해당 트윗 창으로 가실 수 있습니다. - PUBLY ⓒLauren Smith



트윗 몇 개만 봐도 매우 유용해 보이는 컨퍼런스인 TEDC. 그곳에 가기 위해 우리는 Stibee 전용 명함을 만들었다.


ⓒStibee

귀여운 컨셉으로 디자인된 이 명함은 TEDC에 오는 이메일마케팅 전문가들과 친분쌓기용으로 만들어졌다. 이런 교류를 통해 그들이 한국 시장에 진출할 때 스티비가 도움을 줄 수 있으리라 기대한다.

또한 아래 예고된 탐나는 선물도 TEDC 보스턴이 기다려지는 이유 중 하나다.



이미지를 누르면 해당 인스타그램 창으로 가실 수 있습니다. - PUBLY ⓒagainstsoph

[2016 TEDC Boston]

스티비 조성도 총괄자와 임호열 기획자가 이메일마케팅 컨퍼런스의 왕중왕, TEDC에 다녀왔습니다. 그곳에서 얻어오는 이메일마케팅 노하우와 실질적인 팁이 궁금하신 분들은 프로젝트에 참여해주세요.




Posted by slowalk


카드뉴스 자주 보시나요? 저는 출퇴근 길에 즐겨봅니다. 가만히 보다 보면, 하고 싶은 얘기와 간단한 이미지가 있다면 누구나 어디서든 만들 수 있겠다는 생각이 듭니다. 물론 조금 시간이 들겠지만요... 실제로 슬로워크에서 지속적으로 사용 가능한 카드뉴스 템플릿에 대한 요청이 많이 들어옵니다.


그래서 준비했습니다. 비디자이너도 쉽게 따라할  있도록 파워포인트로 카드뉴스 만드는 법을 알아봅시다.


1. 사이즈 정하기



카드뉴스 형태는 정방형, 가로로 긴 직사각, 세로로 긴 직사각이 있습니다. 기본적으로 정방형을 많이 사용하고, 직사각형은 페이스북에 게시할 때 활용하면 특히 좋습니다. 콘텐츠 노출 시 강조하기 위해서인데요, 2, 3번 사례처럼 표지만 직사각형으로 게시하면 내지보다 큰 사이즈로 노출됩니다. 형태별 사이즈는 비율만 맞춘다면 더 크게 조정해도 됩니다.



2. 대지 만들기


파워포인트 > 디자인 > 슬라이드 크기 > 사용자 지정

(단위를 픽셀로 바꿀 수 없어 임의로 20cm로 지정)

          

카드뉴스를 디자인하는 툴은 어도비 포토샵, 어도비 일러스트레이터, MS 파워포인트, Google 프레젠테이션, 심지어 그림판까지 여러 종류가 있습니다. 그중 파워포인트를 이용해 대지를 만들어보겠습니다.



3. 이미지 찾기



이미지를 구해야 한다면 퍼블릭 도메인 이미지를 추천합니다. 제공 사이트는 여러 곳이 있지만, 저는 Pexels 자주 이용합니다. 모든 이미지가 CC0 라이선스이며 무료로 다운받을 수 있습니다. 자세한 내용과 다른 사이트는 '저작권 걱정 없이 자료 찾기' 포스팅을 참고해주세요. 카드뉴스를 다루는 내용이니, 휴대폰을 들고 있는 이미지로 예시를 만들어보겠습니다.



4. 이미지 배치


이미지를 다루는 방식을 크게 두 가지로 나눠봤습니다. 배경에 맞게 채우는 방법과 도형 안에 넣는 방법입니다. 배경으로 채울 때는 텍스트가 잘 읽히도록 어둡게 조정하는 게 좋습니다.

 

이미지 채우기: 배경 서식 > 그림 또는 질감 채우기


이미지 어둡게 하기: 삽입 > 대지크기에 맞게 도형 생성 > 도형 서식 >

단색 채우기-블랙 > 투명도 50% > 이미지 위에 덮기

 

도형 안에 이미지 넣기: 삽입 > 원하는 모양으로 도형 생성 > 도형 서식 > 그림 또는 질감 채우기




5. 콘텐츠는 짧고 굵게 편집하기



준비된 콘텐츠의 길이가 너무 길진 않은지 체크합니다. 제목은 20자 이내, 본문은 150자 이내로 되도록 간결할수록 좋습니다. 내용이 길면 지루함의 문제도 있지만, 텍스트 크기가 너무 작아져 가독성이 떨어집니다. 콘텐츠의 상세함보다는 이미지와 함께 어우러져 제공되는 재미가 가장 크니까요.

 


6. 텍스트 배치


 

크기: 텍스트 크기는 제목용, 본문용으로 나눴습니다. 상황에 따라 중간 크기의 부제목용(인용구 등의 표현도 가능)도 추가할 수 있죠. 저는 제목용은 48포인트로, 본문용은 25포인트로 정했습니다. 크기가 가늠이 안 된다면 이미지로 추출한 후 모바일로 보면서 적절한지 체크하는 방법도 있습니다.


폰트: 가지고 있는 폰트 혹은 무료 폰트 중 가독성이 좋은 폰트로 고릅니다. 상업 목적이 있는 콘텐츠라면 무료 폰트라도 저작권 내용을 꼼꼼히 읽어보는 게 좋습니다. 저는 네이버에서 제공하는 나눔스퀘어 폰트를 택했습니다(오픈 라이선스여서 자유롭게 사용 가능합니다).


여백: 이미지나 텍스트를 배치할 때 여백을 넉넉히 확보해야 안정감 있게 디자인할 수 있습니다.




7. 출처 & 라이선스 표기하기



출처를 표기해야 한다면 해당 콘텐츠가 있는 카드 가장자리에 넣어줍니다. 자체 콘텐츠일 경우에는 로고와 함께 라이선스를 표시해주는 것이 좋습니다. 라이선스는 크리에이티브 커먼즈 코리아 사이트에서 적용 방법과 아이콘을 다운로드할 수 있습니다.

 


8. 레이아웃 잡기


텍스트 정렬과 이미지 처리 방식이 서로 다른

 

텍스트와 이미지를 조합하는 방법은 수없이 많은데요, 중요도에 따른 강약 조절과 적절한 간격을 유지하면 같은 콘텐츠로도 여러 레이아웃이 나올 수 있습니다. 디자인은 자유롭게 할 수 있지만, 하나의 카드뉴스 세트에는 한 가지 컨셉의 통일된 레이아웃을 적용하는 것이 좋습니다.




9. PNG 파일로 내보내기


파일 > 내보내기 > 파일 형식 변경 > 이미지 파일 형식 중 PNG선택

 

카드를 다 만들면 웹상에서 활용하기 좋은 PNG 이미지로 추출해줍니다. 이미지가 모바일에서 잘 나오는지 확인하면 끝!





10. 아무리 생각해도 어렵다면, 서비스 이용하기

 

타일(Tyle)


스텐실(Stencil)

 

파블로(Pablo)

 


이러한 작업도 도통 엄두가 안 나신다고요? 그래도 카드뉴스를 만들 방법은 많습니다. 텍스트만 입력하면 되는 카드뉴스 제작툴이 있습니다.


타일(Tyle): 다양한 디자인 템플릿과 폰트, 이미지를 비교적 자유롭게 이용할 수 있는 카드뉴스 제작툴이며, 유료 서비스입니다.

스텐실(Stencil): 다양한 디자인 템플릿에 이미지 보정과 아이콘까지 쉽게 적용 가능한 카드뉴스 제작툴입니다. 유료지만 첫 10장은 무료로 이용할 수 있습니다.

파블로(Pablo): 텍스트를 SNS에 적절한 크기로 이미지와 조합해주는 툴입니다.

 


카드뉴스 디자인 어렵지 않죠? 저는 이 포스팅을 작성하기 위해 처음으로 파워포인트로 디자인을 해봤는데요, 기능이 많고 디자인하기 꽤 좋다는 걸 처음 알았습니다. 저도 하나씩 배워가네요(?).

모바일을 통해 사람들의 생활이 바뀌고, 그로 인해 정보의 형태가 하루가 다르게 바뀌는 것이 참 재미있습니다. 이 포스팅을 보고 더 많은 분이 쉽게 콘텐츠를 만들 수 있게 되길 바랍니다!




작성: 곽지은

Posted by slowalk


요즘 워드프레스와 같은 CMS(Contents Management System)를 기반으로 홈페이지를 제작하는 경우가 많아지면서, 콘텐츠를 관리하기가 더욱 수월해졌습니다. 개발자나 제작사를 거치지 않고 직접 글을 게시하거나 편집할 수 있게 되었지요. 

그래서 웹사이트 제작 프로젝트를 진행할 때 관리자의 글 편집 기능을 좀 더 신경 쓰게 되는데요. 슬로워크에서는 콘텐츠를 깔끔하게 정리하여 게시할 수 있는 본문 작성의 가이드를 드리기도 합니다. 가이드에 맞춰 공지나 새 소식에 게시할 글을 작성하면, 별도의 디자인이나 퍼블리싱 과정 없이 본문의 요소를 표현할 수 있습니다.


본문 스타일가이드의 예본문 스타일가이드의 예



본문의 스타일을 고민하기에 앞서, 게시물의 원고를 준비하는 단계를 생각해봅시다. 스타일 가이드를 잘 만들어두었다고 해도, 원고의 적절한 가공이 없으면 그 내용을 효과적으로 전달하기 어렵습니다. 


제목은 어떻게 쓸 것인지, 단락은 어떻게 나눌 것인지, 어느 부분에 표와 이미지를 활용할 것인지 고민해보셨나요? 또한, 종이 위의 보고서를 만드는 것이 아니라 웹사이트에 글을 올릴 것이므로 웹의 속성을 고려할 필요가 있습니다. 적절한 콘텐츠 표현을 위해 어떠한 고민이 필요한지, 요소별 체크포인트를 알아봅시다.



텍스트 - 소제목을 활용하거나 단락을 구분합니다.텍스트 - 소제목을 활용하거나 단락을 구분합니다.


1. 텍스트

- 제목과 본문을 구분하였는가: 제목의 단계를 활용하여 내용의 상하/포함 관계를 나타냅니다.
- 소제목으로 구분하였는가: 내용이 길고 단락마다 주요 내용이 다르다면 소제목으로 구분해보세요.
- 요약글을 더했는가: 가독성이 높아집니다.
- (본문 영역의 너비가 넓다면,) 단을 나눠서 글을 썼는가: 가독성을 높이는 데 도움이 됩니다.
- 전체 글의 양이 적절한가: 웹은 스크롤이 되기 때문에 본문의 양이 많아도 괜찮을 것 같지만, '스크롤의 압박'이라는 말도 있지요. 읽기 부담스러운 양의 본문은 사이트 이탈을 유발할지도 모릅니다.



표 - 데이터의 정렬을 확인합니다표 - 데이터의 정렬을 확인합니다


2. 표

- 표의 형태로 표현하기 적합한 콘텐츠인가: 단순히 레이아웃을 위해 표를 사용하지는 않았나요? 행과 열로 구분할 수 있고 여러 항목의 비교가 필요한 내용인지 살펴봅시다.
- 행과 열의 수가 적절한가: 행과 열이 너무 많으면 특히 모바일 디바이스에서 표에 담긴 내용을 파악하기 어려울 수 있습니다.
- 데이터의 정렬을 확인했는가: 숫자 데이터는 오른쪽 정렬을, 일반적인 글자 데이터는 왼쪽 정렬을 합니다. 표의 제목 행은 그 데이터 정렬과 같이 합니다. 되도록 가운데 정렬은 사용하지 않습니다.





3. 도식

- 도식으로 표현하기 적합한 콘텐츠인가: 도식은 주로 그룹 사이의 관계를 나타내거나, 구조, 변화를 나타낼 때 유용합니다. ex) 조직 구조도
- 다른 요소로 대체할 수 있는가: 웹상에서 도식을 사용하기가 쉽지는 않기 때문에 꼭 필요한 부분에만 사용하세요. 절차나 순서를 알려주는 내용에는 화살표 특수기호만 이용해도 좋습니다. 
- 도식의 크기와 형태가 웹사이트에 적절한가: 표와 마찬가지로, 도식을 가로나 세로로 너무 길게 표현하면 오히려 내용을 파악하기 어렵고, 모바일 환경에서는 별도의 도식 이미지를 준비해야 할 수도 있습니다.



이미지 - 이미지에 대한 설명을 캡션으로 표기합니다(예: 슬로워크 블로그)이미지 - 이미지에 대한 설명을 캡션으로 표기합니다(예: 슬로워크 블로그)




4. 이미지

- 캡션을 표기하였는가: 사진이나 이미지에 설명을 덧붙이면 본문 내용의 이해에 도움이 됩니다. 
- 이미지와 텍스트를 섞어 작성하였는가: 되도록 본문 전체를 웹 포스터 형태의 단일 이미지로 게시하거나, 이미지만 올리는 경우를 피하세요. 로딩 속도를 지연시킬 수도 있고, 특정 내용을 찾기 위한 검색에도 큰 도움이 되지 않습니다. 
- 이미지의 비율이 적절한가: 반응형 웹의 경우, 가로로 긴 와이드 이미지는 모바일 환경에서 너무 작게 보일 수도 있습니다. 



링크 - 링크를 단락과 구분하여 구분한다(예: DMZ국제다큐영화제 웹사이트)링크 - 링크를 단락과 구분하여 구분한다(예: DMZ국제다큐영화제 웹사이트)




5. 링크

- 링크와 링크가 아닌 요소를 구분하였는가: 링크 텍스트를 밑줄이나 다른 색상으로 구분해주세요. 클릭할 수 있는 것인지 명확히 해주는 것이 좋습니다. 링크를 단락과 구분하여 별도로 표시하는 것도 좋습니다. 이미지 자체에 링크하기보다는 텍스트로 링크를 표시하여, 사용자가 실수로 클릭하거나 이미지 확대 보기와 혼동하지 않도록 하세요.




웹상에서 글쓰기도 다른 글쓰기와 크게 다르지 않습니다. 다만 몇 가지 특징을 알고 준비한다면, PC와 모바일 모든 환경에서 보기 좋고 이해하기 쉬운 글을 쓸 수 있습니다. 사이트를 통해 제공하는 정보는 결국 방문자들을 위한 것입니다. 같은 내용이라도 쉽고 적절하게 표현하였는지 한 번 더 확인해보세요.







작성: 오예슬


Posted by slowalk