참고 이미지가 날짜까지 정하면 곤란하다
AesCode를 보며, 시안에서 가져올 모양과 요청서에서 지킬 내용을 따로 읽게 됐다.
토요일이라고 썼는데
작은 워크숍 포스터를 만든다고 해보자. 요청서에는 토요일이라고 썼다. 생성된 시안은 마음에 든다. 제목도 큼직하고 색도 괜찮다. 그런데 아래 날짜를 읽으니 금요일이다.
그림은 벌써 행사를 하루 앞당겨 놓았다.
이 시안을 참고해서 HTML과 CSS를 만들면 무엇을 따라가야 할까. 제목의 크기와 여백은 가져오고 싶다. 금요일까지 가져오고 싶은 것은 아니다.
Microsoft의 AesCode 소개에서 눈에 들어온 구분이 이것이었다. 생성한 이미지를 디자인의 참고로 쓰되, 내용의 기준은 원래 요청에 둔다. 결과는 수정할 수 있는 HTML과 CSS로 만든다는 설명이다.
소개 자료는 참고 이미지에도 잘못된 내용이 들어갈 수 있다고 짚는다. 나는 모델을 실행해 결과를 비교한 것은 아니다. 공식 문서를 읽다가, 포스터를 고치는 이 가상의 상황을 생각했다.
예쁜 시안을 보면 통째로 따라가고 싶어진다. 그 안에 든 글자도 디자인의 일부처럼 보이니까. 다만 글자에는 모양 말고 뜻도 있다.
같은 칸에 들어 있는 다른 정보
포스터 아래의 날짜 영역을 나눠 생각해 본다. 왼쪽에 둘지 가운데에 둘지, 제목에서 얼마나 떨어뜨릴지는 배치의 문제다. 실제로 어느 날 열리는지는 행사 정보에서 받아야 한다.
한 이미지 안에서는 둘이 붙어 있다. 만드는 쪽에서는 잠깐 떼어놓을 필요가 있겠다.
가령 요청을 보낼 때 행사명과 날짜, 장소는 그대로 쓸 내용으로 주고, 이미지에서는 색과 제목의 위계, 여백을 참고하라고 적고 싶다. 시안에만 있는 주소나 참가비는 임의로 채우지 않도록 하고.
이것은 문서를 보고 떠올린 작업 방식이다. 이렇게 적기만 하면 모델이 항상 지킨다고 확인한 것은 아니다. 결과의 문구는 원래 정보와 다시 맞춰봐야 한다.
원래 요청 자체가 애매하면 거기서도 틀릴 수 있다. ‘다음 토요일’이라고만 적힌 요청을 그림이 해결해 주지는 못한다. 발행할 날짜를 확정해서 넣어야 할 사람은 여전히 남는다.
여기에 한 가지가 더 있다. 시안의 짧은 행사명을 실제 긴 이름으로 바꾸면, 아까 좋았던 줄바꿈이 달라질 수 있다. 올바른 내용으로 고친 뒤에야 그 디자인을 제대로 볼 수 있는 셈이다.
짧은 영문 제목으로는 널찍하던 칸이 한국어 행사명을 넣자 두 줄이 된다고 해보자. 글자를 작게 줄이면 겉보기는 다시 맞출 수 있다. 하지만 사람들이 그 제목을 읽기 편한지는 화면에서 봐야 한다.
그러니 시안을 닮았다는 확인과, 실제 내용을 넣어 읽을 수 있다는 확인을 따로 해보고 싶다. 두 질문이 같은 자리에서 끝나지는 않을 것 같다.
수정할 수 있다는 말의 다음
HTML과 CSS로 남는다는 점은 이런 작업에서 반갑다. 날짜 문구를 찾아 바꾸고 다시 렌더링할 수 있으니까. 이미지 위의 글자를 지우고 비슷한 색으로 덮는 일부터 시작하지 않아도 된다.
그렇다고 수정할 수 있다는 말이, 수정 뒤에도 모양이 괜찮다는 뜻까지 포함하지는 않는다. 한 단어가 길어졌을 때 아래 장소 줄이 밀리는지, 좁은 화면에서 서로 겹치는지는 다시 봐야 한다.
내가 이 포스터를 넘겨받는다면, 원래 요청의 내용과 참고 이미지, 편집할 코드가 각각 어디에 있는지 알고 싶다. 나중에 날짜를 고칠 때 무엇을 기준으로 삼을지 헷갈리지 않게.
처음의 시안으로 돌아가면 금요일을 토요일로 고치는 일은 작다. 그 작은 수정이 제대로 된 뒤에야 여백과 색을 마음 놓고 볼 수 있겠다.
그때 누군가 행사명 뒤에 한 단어만 더 붙여달라고 할 수도 있다. 코드를 다시 열고, 이번에는 제목 아래가 얼마나 내려가는지 봐야겠다.