이전 회의 정리
1.
와이어프레임 내용 구체화
2.
앱 최초 유입 구체화
본론
와이어 프레임 구체적 논의 - 2
상세주소 , 장소선택
1.
장소검색 후 해당 결과에 맞는 주소를 사용한다.
•
단점
모임을 만들 때, 항상 주소를 검색해서 입력해야 한다.
•
장점
모임의 정확한 위치를 알 수 있다.
1.
핀 찍으면 나오는 주소를 사용한다.
•
단점
정확히 해당 위치에서의 어떤 장소에서 만나는지 애매할 수 있다.
예) A건물에 2층 스타벅스이면 주소만 적으면 A건물 위치까지만 알 수 있다. "스타벅스"에서 만날건데 그 사실을 어떻게 전달할 지 애매함
•
장점
주소를 입력하는 번거로움을 없앨 수 있다.
→ 두개 다 쓸 것인가? 아니면 하나만 선택해서 할 것인가?
우리의 앱은 지도중심인가? or 상세정보 중심인가? (feat. 젠리와 당근마켓)
•
지도 중심이다라고 지난번 회의때 얘기가 나왔었음
스케쥴 뷰는 풀스크린인가? 반반인가?
•
우선은 풀 스크린으로
•
너무 많은 기능을 넣지 말자 → 스케줄 뷰는 언제든 바뀔 수 있는 부분
1. 핀으로 선택 vs 검색으로 선택
핀으로 선택할 시 상호명을 가져올 것인가?
영훈 : 핀 찍으면 스타벅스(상호명)로 고정되는 것은 하지 않는 건가요?
수형 : 넵 고려안하고 있었습니다.
의민 : 그럴 경우 스타벅스가 뜨지 않는데 개선할 방법은 없나요?
수형 : 따로 적어야 한다. ⇒ 모든 지번에 장소들을 대입해야 하는 번거로움. 아니면 아예 검색으로 가져올 수 밖에 없다. 예를 들어 만들기 버튼을 누르면 제목에 스타벅스를 적고 스타벅스 위치에 핀을 찍고 글을 쓴다.
의민 : 스타벅스처럼 유명한 위치는 핀으로 찍으면 자동으로 보정해주는데 그 부분은 제작하기 힘든가?
수형 : 젠리처럼 최대한 간소화하여 띄울 예정이기 때문에 만드는게 어렵다기 보단 우리 앱의 컨셉에 적용하기 힘들 것 같다. 그리고 지도 api에서 어떤 정보를 띄울 지 정할 수 있기 때문에 추후에 고려해봐야겠다.
영훈 : 가져올 수 있다는게 지역 근처의 상호명들을 가져올 수 있다는 말인가요?
수형 : 지도 api에서 등록된 정보들은 우리가 알고리즘(반경이라던지)을 만들어서 가져올 수 있다.
우리의 목적은 지도중심인가? 상세정보 중심인가?
영훈 : 이미 집에 와서 지도뷰 상에 나온 정보들을 굳이 다시 검색으로 찾아가는 것은 불편할 것 같다.(ex : 집근처에서 스타벅스를 검색할 시)
의민 : 젠리처럼 아무것도 안뜨는 지도 위에서 검색하기에도 쉽지 않을 것 같다.
영훈 : 모임을 만드는 사람의 입장에서는 이미 그 위치를 알고 핀으로 찍을 것이다. ⇒ 약속 장소를 정하고 우리 어플을 사용할 것이기 때문에
의민 : 
. 우리 앱의 목적이 진지한 모임을 타겟으로 하기 때문에 영훈이 말에 동의한다. 그럼 검색만 가능하게 하는 것은 어떨까요?
. 우리 앱의 목적이 진지한 모임을 타겟으로 하기 때문에 영훈이 말에 동의한다. 그럼 검색만 가능하게 하는 것은 어떨까요?수형 : 그래서 하나만 할지, 둘다 적용할지 고민중이다.(핀 vs 검색)
영훈 : 젠리 화면을 보니 확실히 이것만으로 지도에서 길을 찾기는 어려울 것 같다. 지금당장 역도 안나오고 랜드마크와 같은 표시도 없기 때문에 핀이 찍혀 있어도 찾기 어려울 것 같다. 그렇다고 여러 정보들이 잔뜩 떠있는 지도 위에서 핀을 찾는 것도 어려울 것 같다. ⇒ 지도의 복잡함과 심플함 사이에서 어떻게 절충할 지 고려해봐야 할 것 같다.
의민 : 젠리 지도는 친구의 위치를 대충 보기 위해 사용한다. 카카오맵과 같은 지도를 사용하는 이유는 그 곳으로 길을 찾기위해 사용한다. 따라서 우리도 어느쪽이 더 방향성이 맞는지 고려해보자.
수형 : 그럼 우리 어플은 사람들이 길을 찾도록 서비스 하는 것에 당위성이 있는가?⇒ 길찾는건 네이버지도나 구글지도를 사용하도록 하면 되지 않나? 그래도 직관적으로 여기가 어딘지는 알아야 할 것 같다.
젠리는 나를 기준으로 주변 사람들의 위치를 보게 된다. 다른 지도들은 랜드마크를 기준으로 주변을 보게 된다.
만기 : 그럼 우리 지도를 사용할 사람들은 모두 자기를 중심으로 지도를 사용할 사람들인가?
수형 : 직접 해보지 않아서 잘 모르겠다. 일단은 젠리처럼 가는 것이 좋을 것 같다.
규호 : 먼저 도착한 사람이, 해당 장소를 찍은 사진을 업로드시키고, 나중에 오는 사람은 해당 장소 사진을 보고 상세하게 찾는 방법도 있을 것 같다.
영훈 : . 다보여주는 것은 지양하고 줌 레벨에 따라 다르게 보이는 것이 좋을 것 같다. (줌 인 ⇒ 상호명들이 보임, 줌아웃 ⇒ 도로들만 보임.) 그리고 글씨로 하는 것 보단 아이콘으로 표시하자.
. 다보여주는 것은 지양하고 줌 레벨에 따라 다르게 보이는 것이 좋을 것 같다. (줌 인 ⇒ 상호명들이 보임, 줌아웃 ⇒ 도로들만 보임.) 그리고 글씨로 하는 것 보단 아이콘으로 표시하자.2. 만들기 뷰 구체화
상세정보(상호명) 수기작성 vs 자동작성
영훈 : 추가적으로 핀을 찍었을 때 상세주소 외 정보를 알려주는 작업이 필요해 보인다.
수형 : 네이버지도는 특정 건물을 잡고 상세보기를 하면 주변 건물들과 정보들이 표시된다. 그러면 우리도 핀으로 찍고 주변 정보들을 표시하는 것은 어떤가?
영훈 : 그런데 모든 상호가 다 api로 따와지는 것이 아니니 상호명이 표시되지 않는 경우 따로 적을 수 있는 칸을 마련하는 것은 어떤가?
수형 : 일단 구현 가능성은 배제하고 말한 것이니 넘어가쥬.
영훈 : 그럼 상세주소를 쓰는 것으로 하고 추후에 추가할 지 생각해보자.
수형 :
영훈 : 그럼 검색과 핀을 찍었을 때 등장할 ui들이 조금 다르겠네요. 핀으로 찍을 때는 상호명을 따로 입력할 수 있게 도 해줘야 하니까.
수형 : 동의합니다.
만들기뷰 상세(제목, 시간, 상세주소)
수형 : . 만들기를 할 때 위에 그 위치의 지도가 나오게 하는 것이 좋을까요? 다른 어플들의 만들기 기능들을 참고해보자.
. 만들기를 할 때 위에 그 위치의 지도가 나오게 하는 것이 좋을까요? 다른 어플들의 만들기 기능들을 참고해보자.영훈 : 만들기 뷰에서 어떻게 인원, 제목, 시간 등의 정보를 쉽게 적을 수 있을지 고민해보자. ⇒ 시간의 경우 키보드로 입력 vs 다이얼로 선택
규호 : 제목에는 상호 + 목적 정도 아닐까 싶습니다.
영훈 : 제목에는 목적만, 상호명은 따로 칸을 만들어서 사람들이 적을 수 있도록 독려하는 방향이 좋을 것 같다.
규호 : 그런데 유저가 값을 입력하게 하면 값이 회손되는 경우들이 있어서 유저가 건드리지 못하도록 하는 것이 좋을 것 같다. 아니면 자동으로 입력되는 부분과, 수기로 입력하는 부분은 구분되면 좋겠다.
수형 : 그러면 자동 입력칸, 수기 입력칸 이렇게 두가지를 두는 것이 좋을 것 같다.
만기 : 상세주소 대신에 만남을 독려시킬 수 있는 특징을 알려주면 좋을 것 같다. ex) 저는 빨간 옷을 입고 있습니다. 등등
수형 : 그러기엔 너무 자율성을 주는 것이 아닌가 싶다.
영훈 : . 상세주소는 상세주소로 사용하도록 유도하는 것이 맞는 것 같다.
. 상세주소는 상세주소로 사용하도록 유도하는 것이 맞는 것 같다.수형 : 그럼 상세주소는 input box, 시간은 check box 가 좋을 것 같다.
영훈 : 시간은 얼마나 상세하게 할 지 정하자. (년, 월, 일, 분단위 까지 모두 사용하게 할 것인지) 년까지는 좀 그렇더라고 월 정도? 아니면 캘린더도 추가해야 하는가?
수형 : 캘린더로 한다면 1주일 단위가 적당할 것 같다.
영훈 : 시간 칸에 시작시간, 끝시간 둘 다 작성해야 할 것 같다. 일단 지금 캘린더와 같은 내용들은 더 깊숙히 들어가봤자 의미가 없을 것 같다. 일단은 시, 분만 정하고 나중에 언제든지 수정할 수 있는 방향으로 가는 것이 좋을 것 같다.
수형 :
영훈 : 스케쥴뷰 일단 리스트로 할까요? 어차피 상세주소가 있으니까. 수형 :
3. 메인 뷰 3기능
메인뷰 UI
소원 : 첫번째 메인 화면 하단의 3 개 버튼에서 모션이 어떻게 되는 것인지 궁금하다.
수형 : 왼쪽 버튼은 왼쪽에서 날아오고 오른쪽 버튼은 오른쪽에서 날아오는 방식이다.
소원 : 그럼 뒤로가기 버튼도 만들어야 하는가? 젠리의 경우 계속 하단에 위치해있어 이동이 된다.
수형 : 어떤 방식이 더 이쁠지 모르겠다. 좀 더 고민해봐야 할 것 같다.
규호 : <-| 스와이프는, 꺼내기
|->, o-> 스와이프는, 넣기 위아래 스크롤은, 리스트 돌리기 라고 하는 방법도 있습니다.
만들기(+) 버튼의 필요성 및 부드러운 조작
영훈 : 모임 만들기 프로세스를 좀 더 명확히 해야 할 것 같다. 핀을 꾹 눌러서 모임을 만드는 경우라면 굳이 메인 화면에 버튼이 따로 떠다닐 필요가 없을 것 같고 검색하고 만들기를 할 경우에도 검색한 후에 (+)버튼이 있어야 유의미하지 않나 ⇒ 결론은 메인화면에 (+)버튼이 없어도 될 것 같다.
수형 : 지도에서 핀을 찍고 만드는 행위를 많이 사용할까?
영훈 : 꾹 눌렀을 때 핀이 뜨는 것은 유용하지 않을 것 같다.(사용자가 핀이 뜬다는 사실조차도 모를 것 같다는 우려) 그냥 간단한 터치로 핀이 뜨는 것이 더 유저에게 유용하지 않을까.
만기 : 최근에 인상깊었던 지도 사용 방식으로 카카오 택시가 있다. 카카오 택시는 핀이 중심에 있고 지도를 끌어서 움직인다. 이 방식을 가져오는 것은 어떤가?
영훈 : 좋은 것 같다. 상세주소로 검색하는 것은 모임을 찾을 때의 용도이고 모임을 만드는 프로세스로 연결 짓기 애매한 것 같다. 그런데 지금처럼 핀이 고정방식이라면 모임만들기 버튼을 메인화면에 만드는 방식에 타당성이 생길 것 같다. 추가로 카카오지도를 보니 핀이 도로위만 움직이면서 주변의 상호명들을 끌어오는 방식을 적용해도 좋을 것 같다.
수형 : 그런데 카카오 택시는 도로를 다니기 때문에 주변 상호를 가져와도 크게 무리없지만 우리의 경우 2층이냐 지하1층이냐 등 지형적 높이에 따라 다른 모임이 되기 때문에 적용하기에 의문이 든다.
영훈 : 상세주소는 다시 쓰게 하는 것이 맞는가? 만약 스타벅스를 찍고 상세주소에 '스타벅스' 라고 적은 뒤 핀을 옮겨서 커피빈에 위치했을 경우 상세주소에 스타벅스를 그대로 남겨두는 것이 맞는가? ⇒ 상세주소를 자동으로 맞춰줄 것인가? 수동으로 작성하게 할 것인가?
수형 : 일단은 자기가 쓰도록 하자
수형 : 그런데 (+) 버튼을 누르면 나오는 만들기 뷰에서 상단의 지도를 조금씩 옮겨도 되지 않을까? ( ⇒ 거시적 위치 이동은 검색뷰를 활용 하도록 하고 미시적 위치 이동은 만들기 뷰 상단의 지도를 활용하도록 독려)
영훈 : (+) 버튼은 오른쪽에 두는 것이 좋은 것 같다. 스케쥴은 그 위에 작게 만들기. 그리고 각 뷰별로 뒤로가기 버튼 추가
수형 : 그 외에는 애플지도의 여러기능 가져와요.
4. 플로우 정리
플로우 정리(내용 보충 해주세용)
메인지도에서 (+)를 누르면 만들기로 감 제목, 시작시간, 끝시간 적을 수 있고 고유지번은 적어줌. 카카오처럼 핀중심으로 움직임. x를 누르면 홈으로 돌아감 만들기를 누르면 스케쥴뷰에 등록됨
스케쥴을 누르면 스케쥴뷰로 이동(오른쪽에서 튀어나 x를 누르면 오른쪽으로 들어감)
(+)는 아래에서 위로 튀어나옴
검색창은 애플지도 그대로 차용
모임들 각각 누르면 모임들의 정보가 하단에 뜨는 방식 x를 누르면 다시 돌아감
참여를 누르면 스케쥴뷰로 넘어감
ETC
와이어프레임 회의는 여기까지
일요일 2시에 db회의 있음
이후에는 개발에 들어가야 하니 스위프트 공부해와주세용
다음 회의때 할 내용
•
DB 모델링 연습해보기
•
멘토님에게 물어볼 DB관련 질문 정리하기
◦
통계를 위한 데이터를 수집하는 것, 로그관리 생각해보기
•
쪼갠다면 어떻게 무엇으로 어느만큼 쪼갤지
1.
DB 작동 원리
2.
고정키, 관계, 쿼리, 등 이런 DB용어들을 알아오시면 좋습니다.
