1. 서비스 흐름-미팅반영
1.1. A.회원 가입
1.1.1. 1. 회원정보 기록
1.1.2. 2. 헬스정보기록
1.1.3. 3. 가입 선물(?)
1.1.4. 4. 알림 설정(코칭 알림 설정)
1.1.5. 5. 1차 판정 - 섭취빈도조사
1.2. B.식사 기록
1.2.1. issue items
1.2.1.1. skip 존재여부
1.2.1.2. 반찬까지 상세 기록 유도 필요
1.2.1.3. 없는 메뉴는 어떻게 등록하게 할 것인가?
1.2.1.4. 양표시는 어떻게 ?
1.2.1.5. 간식 Multi 입력은 어떻게 ?
1.3. C. 코칭(알림)
1.4. D. FoodBox
1.4.1. 1. 외관 하우징
1.4.2. 2. 아이템은 2~3개에서 선택하도록..?
1.4.3. 3. Food 보이는 전면 유리 ? - 투명하게? vs. 불투명?
1.5. E. Feedback
1.5.1. 1. 제공된 모든 식품의 Feedback을 받는다.
1.5.2. 2. 피드백이 되지 않은 Item은 Feedback을 기록하도록 알림을 주어야 함.
1.6. F. Food Quration
1.6.1. 1. 추천은 1개만 한다.
1.6.2. 2. 섭취 피드백을 반영하여 싫다는 음식을 제외한다.
2. 자판기 커스터 마이징
2.1. 자판기 UI
2.1.1. 현재)인증코드 & 비번 --> 인증코드만 입력하도록 변경 ? (암호는 disable 처리)
2.2. 통신
2.2.1. 인증 처리를 직접 AWS 로 연계
3. ATTO 시스템 개발
3.1. 1. AWS
3.2. 2. APP
3.3. 3. 자판기
4. 서비스 설계
4.1. 알고리즘
4.1.1. 영양판정
4.1.1.1. 식사기록
4.1.1.2. 섭취빈도조사
4.2. 리포트
4.2.1. 일일 리포트
4.2.2. 주간 리포트
4.2.3. 월간 리포트
4.3. 식습관 분석 요소
4.3.1. 식사를 실제 했던 시간
4.3.2. 식사 기록하는 시간
4.3.3. 식사 기록 상세화 정도
4.3.4. 영양성분
4.3.5. 식품 종류(그룹핑 Tag)
5. 메뉴 목록
5.1. 보고서
5.2. 큐레이션 피드백
5.3. 1:1 상담
5.4. 식사기록
5.5. 식품검색
5.6. 챗봇(?)
6. 나의 고려사항
6.1. 1. 보고서
6.1.1. 일일 리포트(1~2가지 속성만?)
6.1.1.1. -일 섭취 칼로리(?)
6.1.1.2. -권장 섭취 관련해서 균형적 여부 ?
6.1.1.3. 식사 기록화면에서 1~2개 정보만으로 노출은 어떨까? 별도 화면(보고서라는 명칭) 없이
6.1.2. 주간 리포트(간단 패턴만?)
6.1.2.1. -섭취 관련 패턴만 ?
6.1.2.2. -섭취 시간의 균일성?
6.1.2.3. -영양적 패턴?
6.1.2.4. -요일별 패턴 ?
6.1.2.5. 주간 요약 형식으로 간단히 정보를 노출하면 어떨까?
6.1.2.5.1. 격주간 통계를 내어, 보고서형식으로 제공은 어떨까?
6.1.3. 월말 리포트(종합적 관점)
6.1.3.1. 보고서 형식으로 필요한 것 같음. -숙대처럼 종합 보고서이면 좋을 것 같음.
6.2. 2. 큐레이션 피드백
6.2.1. 1. How to get ? - UI 설계 없음
6.2.2. 2. How to expose to customer ? - 알림? 알람? 화면 어딘가에서 ? - 입력 유도를 자연스레 어떻게 하지 ?
6.3. 3. 챗봇
6.3.1. 1. 유지? 아님 챗봇 제거 ?
6.3.2. 2. 챗팅창은 어떻게 ?
6.3.3. * 논의 조차 안됨.
6.4. 4. 1:1 상담
6.4.1. 게시판 형태 vs. 대화식 형태
6.4.2. 플친의 상담코너와 같은 상담 - 필요? vs. 불필요?
6.4.3. 이 기능은 필요 없다고 생각들 하나 ?
6.5. 5. 식사기록
6.5.1. 1. 끼니 기록은 어떻게 쉽게 상세히 기록하게 하지 ?
6.5.1.1. 숙대처럼 개별 등록?
6.5.1.2. 사진으로 찍어서 ?
6.5.1.2.1. 자체 ML 은 이제 연구를 시작해서 적용 불가
6.5.1.2.2. 구글이미지 엔진 ? - 한식 적용 불가
6.5.1.2.3. MS 이미지 엔진 ? - 아직은 인물 중심
6.5.1.2.4. 국내 다른 업체가 실제 된다면, ML을 구축 했을 것...
6.5.2. 2. 양입력은 해야겠지 ? 그럼 어떻게 입력하게 하지 ? 숙대처럼 ?
6.5.3. 식사기록 이력 UI ?
6.5.3.1. 게시판처럼 단순 목록?
6.5.3.2. 숙대처럼 전날/다음날 로 이동하는 방식 ?
6.5.3.3. 타임라인의 UI 형식으로 맨위는 오늘(혹은 어제?) 아래로 과거 이력을 조회 방식
6.5.3.3.1. 1. 타임라인 형태의 조회 방식은 ?
6.6. 6. 식품검색
6.6.1. 식품검색 제공해 vs. 하지마?
6.6.2. 검색 기능은 필요 없으까나? - 건강, 음식 레시피 등... 제공하면 우리 앱을 한번이라도 더 쓸게 만들 수 있을까?
6.7. 7. 영양판정
6.7.1. 1. 식사기록에 의한 판정
6.7.1.1. 기존처럼 3가지 영양그룹으로 판정?
6.7.1.1.1. 지금 시대에 맞는 것인것 같음
6.7.1.1.2. 비건과 관련하여 더 심도 있게 다뤄야 하지 않나 ?
6.7.1.1.3. 현재 알러지 회피로직에 추가적인 알러지 회피 항목이 더 필요한지 확인이 필요
6.7.1.2. 다른게 더 있을까 ?
6.7.2. 2. 섭취 빈도 조사 ?
6.7.2.1. 그 많던걸 다해 ? 그럼 어떻게 ?
6.7.2.1.1. 한번에 다 하지 말고, 나눠서 하면 어떨까? - 제인확인 필요
6.7.2.1.2. 항목이 너무 많으니 줄일 수 있을까? - 제인확인 필요
6.7.2.2. 빈도 조사를 꼭 해야 하나 ?
6.7.2.2.1. 안 그럼 1주차는 어떻게 추천하지? 막주나 ?
6.7.3. 3. 숙대 알고리즘을 그대로 사용이 가능할까? - 제인에게 확인 해 보자 -
6.7.3.1. Ok
6.7.3.1.1. 직장인 버젼으로 알고리즘을 발전 시킬 수 있는 방법은 ?
6.7.3.1.2. 판정 재활용 및 발전 방향은 ?
6.7.3.2. No
6.7.3.2.1. 새롭게 만든다? - 시간, 자원이 충분한가 ?
6.8. 8. UI 디자인
6.8.1. 8.1 회원가입
6.8.1.1. 1. 직원인증은 어떻게 ? - 연계 vs. 일괄로드
6.8.1.2. 2. 사번정보는 받아야겠지 ?
6.8.1.2.1. AIA 향후 내부 보고서 등에 필요한 개인을 특정하려면,,,, 필요할 것 같은데.. 주던 안주던 DB 설계만 하자 - 확인은 필요 할 듯
6.8.1.2.2. DB 식별 필요
6.8.1.3. 3. 회사 이메일 인증은? - 개인이메일 사용의 불허? 아님 허용?
6.8.1.3.1. DB식별 필요
6.8.1.4. 4. 신체정보, 알러지 등의 정보는 필수
6.8.2. 8.2 메인화면
6.8.2.1. 직관적 화면이 필요한데, 채팅창은 버리나 ?
6.8.3. 8.3 식사기록
6.8.3.1. 8.3.1 식사기록 이력보기(일별)
6.8.3.1.1. 타임라인처럼 보여주면 어떨까?
6.8.3.1.2. 일일 통계를 함께 보여주기
6.8.3.1.3. 온도 or 바람 or 해/비 정도의 간단 날씨 정보 같이 일별로 출력
6.8.3.2. 8.3.2 식사기록 하기
6.8.3.2.1. 8.3.2.1 식사 기록 구분 - 아침,점심,저녁,간식 목록
6.8.3.2.2. 8.3.2.2 아토가 준 식사로 끼니 등록하기
6.8.4. 8.4 알림
6.8.4.1. 8.4.1 푸쉬메시지 팝업화면 - 알림 수신시
6.8.4.1.1. 식습관 코칭 푸쉬메시지 ?
6.8.4.1.2. 식사 기록 유도 푸쉬메시지 ?
6.8.4.2. 8.4.2 알림 이력조회(목록) ? 필요 없나 ?
6.8.5. 8.5 알람
6.8.5.1. 사용자가 원하는 알람을 등록하는 기능 - 푸쉬가 아닌, 폰자체 알림 설정 - 본인이 알람 시간을 설정
6.8.5.1.1. 식사 skip 방지 알람 ?
6.8.6. 8.6 채팅 화면
6.8.6.1. 이건 어떻게 ? 챗팅 기능 버리는 분위기 ?
6.8.7. 8.7 큐레이션
6.9. 9. 식품DB
6.9.1. 1. 대표여부 DB Attr 추가
6.9.1.1. 대표여부 - 아메리카노 : 스벅같은 브랜드가 없는 경우 대표처리를 위해
6.9.1.1.1. UI는 그럼 어떻게 ? 디폴트는 간편조회이고, 상세 조회사 회사를 구분하여 조회?
6.9.2. 2. 분류 기준을 더 추가 필요 ?
6.9.2.1. AIA 설문 조사 결과를 가지고 추가 고려 - 불필요 할 수도 있겠지 ?
6.9.3. 3. 카페인 디비 JOIN 설정 필요
6.9.4. 4. 원재료를 조합하여 식품 레시피로 신메뉴의 영양성분을 구성 할 수 있는 기능이 필요하겠지 ?
6.9.4.1. 신선 식품을 제공하면, 필요 할 듯
6.9.4.2. OEM 납품 받는 경우 계약서에 '레시피 제공' 명시가 필요할 것 같음
6.9.4.3. 온라인으로 원재료만 넣으면, 영양성분 자동 생성 기능이 있으면 MD가 레시피 만드는 것도 문제 없을 듯..
6.9.4.3.1. 판정 알고리즘도 문제 없을 듯..
6.9.4.3.2. 객관성 확보는? - 사례 조사 필요
6.10. 10. 외부 시스템 연동 ?
6.10.1. 구글검색 연동 ? O
6.10.2. Watson 연동 ? O
6.10.3. 기상청 연동 ? X
6.10.4. FatSecret 연동 ? O
6.10.5. GTIN 상공회의소 연동 ? X
6.11. 11. 아침박스 이용 인증
6.11.1. 1. QR ?
6.11.2. 2. 인증코드 ?
6.11.3. 3. 인증코드 + 비번 ?
6.11.4. 4. 사원증(혹은 출입증) ?
6.12. 12. 핵심 서비스는 무엇?
6.12.1. 1. 큐레이션 ?
6.12.2. 2. 코칭
6.12.2.1. 코칭 방법은 ?
6.12.2.2. 어떤 방식으로 코칭을 ?
6.12.2.3. 코칭시 interrupt 즉 코칭 메시지를 보내는 시점은 어떻게 ?
6.12.2.3.1. 식사 기록 기반 유추하여 ?
6.12.2.3.2. GPS 정보와 시간대를 조합하여 ?
6.12.2.3.3. 사용자에게 입력 받은 시간으로 ?
6.13. 13. B2B 플랫폼으로 설계 방향
6.13.1. DB 설계
6.13.1.1. 금융회사의 직원 정보를 특성을 모두 속성으로 설계하되 옵션처리
6.13.1.2. 회사구분코드, 사번, 이메일 등 상세히 설계하되, 필요한 정보만 사용 할 수 있도록 설계 - 회사구분코드 필수
6.13.2. 컴포넌트설계
6.13.3. 서비스채널(OP) 설계 방향
6.13.3.1. How ? um.....