무시하지 마십시오...모두가 무시하지만 똑바로 하는 사람은 잘 없습니다. 그래도 html 프로그래머는 좀..ㅎㅎ;;
1. 문제의 발단
2개의 프로젝트를 끝낸 지금, 가장 필요한 것은?? 당근 복습이다. 했던 거 또 하고 또 하고 또 한다.
프로젝트를 진행할수록 이미 다 배웠지만 빈틈이 더 느껴지기 시작했고, 그렇기 때문에 다시 복습하고 정리하기 위해 돌아왔다.
처음 시작은 html 태그의 심오함이다. 생각보다 태그들을 잘 나눠 사용하지 않았던 기억이 있다. 대부분은 div로 처리하고 css로 조절해 버렸기 때문이다. 이는 검색과 가독성, 유지보수에 몹시 안 좋다. 그래서 습관처럼 사용할 수 있도록 확실히 태그에 대해 알고 가면 좋을 것 같다.
2. Semantic Tags
'의미'가 있는 태그를 말한다.
제목(h 태그), a(링크), button 등의 다양한 종류의 의미가 있는 태그들을 뜻한다.
이들은 각자의 모양이 있고 따로 css를 설정하지 않아도 그 모양대로 처음부터 나타난다.
3. Tag의 종류
<html /> : html 문서의 최상단을 나타내는 태그. 모든 태그들은 이 태그의 자손들이어야 한다는 규칙이 있다.
<header /> : 브랜드 로고, 사용자에게 나타나야 할 메뉴
<nav /> : 메뉴 안의 요소들
<footer /> : 가장 하단의 링크나 재작자의 시그니처들
<main /> : 중요 콘텐츠
<aside /> : 콘텐츠와 관련없는 광고 같은 것들
<article /> : 콘텐츠와 독립적으로 구성될 수 있는 요소들
<section /> : 문서와 문서를 분리하여 주제가 다른 문서를 쓰는 경우 사용할 수 있음
article VS section : 가장 큰 차이로는 article은 혼자만 딱 때와서 내용을 보아도 이해가 되어야 한다. 독립적인 내용이기 때문에 요소 안에 모든 것 내용들이 다 있어야 하기 때문이다. 그에 비해 section은 같은 카테고리 안의 주제가 다른 경우, 마치 우리가 들여 쓰기를 하듯이 사용할 수 있다. 그렇기 때문에 section이 여러 개인 상황에 그 section안에 독립적으로 article이 존제하는 형태가 자주 보인다.
<div /> : 그저 의미 없이 요소를 묶기 위해 사용하는 태그
<span /> 그저 의미 없이 요소를 묶기 위해 사용하는 태그
<div /> VS <span /> : div는 brock 속성으로 한 줄의 모든 부분을 차지한다. span은 inlien 속성으로 콘텐츠의 사이즈만큼만을 차지한다.
<address /> : 주소, 연락에 관련한 내용
<h1~6 /> : 제목. 번호가 커질 수 록 사이즈는 줄어든다.
<em /> : 강조를 포함한 기울임체(이탤릭체)
<i /> : 강조 없이 그저 시각적으로만 기울임체(이탤릭체)
폰트 어썸 : 주로 <i />를 이용하여 표현한다. 역시 태그의 의미 그대로 강조 없이 일반적인 내용들과 차이를 표현하기 위해 <i /> 태그를 사용하며, <span />를 사용해도 되지만 검색 툴들이 정확한 의미를 이해하고 사용할 때 더 유리하므로 <i />를 사용한다고 한다.
<strong /> : 강조를 포함한 굵은 체(볼드체)
<b /> : 강조 없이 그저 시각적으로만 굵은 체(볼드체)
<ol /> : 순서가 필요한 목록을 나타내는 태그
<ul /> : 순서가 없는 목록을 나타내는 태그
<li /> : list item
<dl /> : 어떤 단어의 설명이 필요할 때 설명할 대상의 제목과 내용을 묶는 태그
<dt /> : 설명할 대상의 타이틀
<dd /> : 설명할 대상의 내용
<img /> : 콘텐츠에 중요한 내용이 될 이미지
<img /> VS CSS background-image 속성 : 콘텐츠의 내용이 아니며 배경이 강조될 필요가 없고, 이미지가 없다고 해서 콘텐츠에 내용에 영향을 미치지 않는다면 태그로 만들지 말고 css 속성으로 넣는 것이 맞다. 그래야 검색 툴이 헷갈리지 않는다.
<button /> : 유저의 행동이 발생할 경우
<a /> : 페이지를 이동하는 등의 링크
<table /> : 중요한 데이터가 표에 들어가서 의미가 있을 경우
의미가 없는 데이터의 경우(보기 편하게 하기 위해서 사용할 경우)는 css flex-box로 조절하는 것이 역시나 검색 툴이 안 헷갈린다.
<br /> : 텍스트의 줄 바꿈
<cite /> : 출처를 나타내는 태그. 제목을 반드시 포함해야 한다.
<ruby /> : 주석. 혹은 동아시아 문자의 발음을 나타낼 때 쓴다고는 하는데... 주석으로 더 쓸 것 같다.
<samp /> : 출력의 예시나 인용문을 나타내는 태그
<s /> : 취소선
<small /> : 덧붙이는 글이나 저작권 및 법률에 관한 표기를 하는 태그
<sub /> : 글자 아래에 작게 숫자나 글자를 쓰고 싶을 때 쓰는 태그 Ex) 화학기호나 수학 기호를 표시할 때, 산소(O2)의 경우 숫자 2를 작게 쓰는 것이 맞다.
<sup /> : <sub />의 반대로 위로 쓰는 경우 사용한다. 제곱을 표현할 수 있다.
<time /> : 시간을 표현할 때 사용하는 태그
<audio /> : 소리
<track /> : <audio />나 <video />의 자식으로 사용해서 시간별로 저장할 위치에 사용한다.
<canvas /> : 캔버스 스크립팅 API나 WebGL API와 함께 사용하여 그림이나 애니메이션을 그릴 때 사용한다.
<noscript /> : 페이지 스크립트 유형을 지원하지 않거나 스크립트를 비활성화한 경우 보여줄 것을 넣는 태그이다.
<script /> : 자바스크립트 코드를 넣을 곳
이때까지 사용하지 않은 태그들이 엄청 많다는 것을 다시 느꼈다. 역시 기본이 중요하다는 것을 다시 확실히 깨달았고, 천천히 부족한 디테일을 채워나가자.
분명 우리는 다짐했다. 첫번째 프로젝트 이후 체력이 하나도 남지 않은 팀원들은 '아... 적당히 하자', '우리 할 수 있는 만큼만 하자!'라고 이야기하고 있었고, 아이디어를 모으기 시작했다. 하지만 '기부'와 '리뷰' 심지어 라임까지 비슷한 이 두 단어가 합쳐지니 너무 매력적으로 보였고 우리는 어차피 고통은 미래의 내가 책임진다...!라는 이야기를 하며 기획에 들어갔다. 물론 결과는 대성공...
이번 프로젝트에서 잘 한 점은?
- 아이디어가 참신하다. 처음부터 우리는 두가지 중에 선택하기로 하였다. 이미 나와있던 서비스이지만, 더 뛰어나고 쓰기 편한 서비스를 우리 형식대로 만들면 좋겠다는 의견과 아예 세상에 없는 것을 만들어 세상에 본때를 보여주자!라는 의견이었다. 결국 후자가 이겼고, '기부 플랫폼'이라는 생소한 주제로 관심을 돌렸다. 그러나 일반적인 기부 플랫폼이 아니라 서로 기부한 사람과 기부받은 사람이 연결되어 자신의 기부가 어떻게 쓰이는지 알 수 있다면 좋겠다고 생각했고, 기부를 받는 사람과 기부를 주는 사람만 뿌듯한 것이 아니라, 그 중간에 기부를 제공하는 사람도 행복할 수 있는 시스템이 좋겠다고 생각했다. 그래서 Meal To Meal의 경우 음식을 기부받은 후 필수적으로 리뷰를 남기도록 하여 가게 사장님 또한 음식이 맛있어서 기부하고 싶은 음식점, 진정성 있는 리뷰를 모을 수 있으므로 맛집의 증거가 될 수 있는 것이다.
- 유저의 응답에 의한 사소한 디테일을 잘 챙겼다. 가게 사장님이 자신의 가게에서 먹기 버튼을 눌러 기부받은 음식을 주지 않고 소모시켜 버리면 어쩔까? 아이디를 하루에 1000개 씩 가입해서 돈을 안 내고 음식을 계속 먹는 사람이 있으면 어쩔까? 가게 사장님은 어떻게 주문한 사람을 확인해야 할까? 등등 사소하게나마 플랫폼을 악용할 수 있는 부분을 최대한 막으려고 노력했다. 그러다 보니 기능들이 점점 늘어나기도 했지만 디테일을 유저 입장에서 생각할 수 있었던 점이 좋았다.
이번 프로젝트에서 아쉬운 점은?
- 역시나 끝없는 욕심으로 인한 탈진이 아쉽다. 하지만 이번 기회로 깨닳은것도 있다. 욕심을 막을 수 없다면, 더 자세히 SR을 해서 최대한 시간을 벌고 능률적으로 개발하는 것이다.
- 랭킹 시스템을 만들지 못 했다. 기부 플랫폼이니 누가 가장 많은 기부를 하였는지 보여줄 수 있다면 경쟁심을 유발해 더 많은 기부를 유도할 수 있을 것이라고 생각하였다. 하지만 시간의 부족으로 만들지 못했다. 추후에 진행할 수 있을 것이다.
- seed 파일로 찍혀있는 가게의 마커들이 주소가 올바르지 않다. seed 파일을 만들었을때, 좌표는 서울 안에서 렌덤으로 주고 주소는 전부 통일시켰다. 그래서 seed를 없애고 다시 만들면 마커의 위치가 바뀐다. 그렇게 테스트를 위한 seed를 만들다 보니 주소까지는 정확히 받아올 필요가 없다고 생각하였다. 하지만 이왕이면 그것도 정확히 받아 올 수 있다면 좋겠다고 생각하였다. 물론, 새롭게 가게를 등록하여 새로운 마커를 만들 때는 정확히 주소를 검색하여 좌표까지 검색하기 때문에 정확한 주소와 위치에 마커가 찍히도록 되어있다.
몇 번의 side 프로젝트들을 스터디에서 진행했고, 그때 함께 했던 팀원들과 그대로 다시 팀을 꾸려 작업을 시작하게 되었다. 그랬던 덕분에 커뮤니케이션 문제는 전혀 없었다. 서로 하고 싶은 말을 편하게 할 수 있었고 부족한 점과 잘한 점, 그리고 서로의 도움이 필요할 때도 눈치 보지 않고 언제나 서로가 서로를 도우며 작업할 수 있었다. 그래서 정말 즐겁게 작업할 수 있었고 결국, 기획단계에서 계획했던 것보다 더 괜찮은 결과물을 만들 수 있었다.
이번 프로젝트에서 잘 한 점은?
- 구현하고자 하는 모든 기능들을 구현하였다. 처음에는 Spotify API를 통해 음악을 재생하고 검색시스템을 넣으려고 했지만, 가장 중요한 것을 잊고 있었다. 바로, 팀원들 중 아무도 Spotify를 사용하는 사람이 없었다는 것이다...! 국내 서비스인 Melon은 API 시스템을 더 이상 제공하지 않는다고 하였다. 하지만 이전부터 생각한 대체안이었던 YouTube API를 이용해 심지어 무료로 양질의 음악을 찾아 재생시키는 기능을 넣을 수 있었다. 이처럼 '안 되면 어쩌지'라는 작은 의심에 하나하나 대책을 세워놓았기 때문에 문제가 생겼을 때 빠르게 정상적인 궤도에 다시 올라올 수 있었다.
- Wireframe과 Flow Chart를 사전에 확실하게 구성하였다. 덕분에 프로젝트 개발에만 온전히 집중할 수 있었다. 물론 Wireframe에 적혀 있는 그대로 만들지는 않았다. 점점 컴포넌트들이 완성되는 과정에서 더 나은 부분이 있다면 계속 팀원들과 상의를 통해 개선해 나갔기 때문이다. 덕분에 더 새련된 디자인을 얻을 수 있었다. Flow Chart는 이전에 했던 side 프로젝트의 교훈이었다. 그때는 백엔드 작업을 했었는데 주도적으로 어떻게 유저가 사용할까?라는 것을 따라가면서 기능을 확실히 잡고 진행했던 것이 도움이 되었기 때문이다.
이번 프로젝트에서 아쉬운 점은?
- 역량과 시간을 고려하지 않은 계획의 설정이 아쉽다. 처음 기획단계에서 각오도 단단히 했고, 분명 작업량이 많다는 것도 알고 있었지만 그래도 욕심이 너무 많았던 프로젝트였다. 덕분에 계획했던 Advanced List를 전부 해치우지 못해서 아쉽다! 이는 점점 채워나가도 괜찮을 것 같다.
- 배포과정에서 UX를 편하게 만드는 기능 몇 가지가 작동하지 않았다. 분명 로컬에서 작업했을 때에는 마커를 생성하거나 삭제 시 바로 화면이 redirect 되면서 변경사항을 바로 보여줬었는데, 그 부분을 구현하고 배포를 진행하고 나니 작동하지 않았다. 이 부분도 고쳐봐야 할 부분이다.
