2023/03/15 기술 검토, 디자인 가이드 결과 공유, 서비스 이름 결정

[JeongJaeSoon]

https://github.com/orgs/2P3S/discussions/2#discussioncomment-5281796

🛟 다음주까지 Goal

1. 기술검토 ( 승형 )
   • next.js 단일 프로젝트에 Front / Back-End 를 운영
2. 디자인 가이드 ( 승현 )
   • UX 라이팅
   • 아이콘
3. github issue & wiki 준비 ( 재순 )
4. 서비스 이름 생각해보기 ( ALL )

[JeongJaeSoon]

github issue & wiki 준비 ( 재순 )

성과물

• Organization 초대, Team 설정 완료
• 기본적인 팀 내 논의는 Discussions 에 정리
• GitHub Organization Discord 연동

Repo & Document 관리 방안

• 서비스 릴리즈 전까지는 document 종류는 private 로 하는 편이 좋을지도?
  • 단, Wiki 기능은 repo 가 private 면 무료로 사용할 수 없음
  • 그 외에도 private 는 몇 가지 기능 제한이 있는 듯 함...
• 실시간으로 오는 알림은 GitHub - Slack 으로 연동해서 알아차릴 수 있게 (없어져도 상관없는 내용)

기술 검토에 대해서

• NEXT.JS 안에서 따로 관리 가능할 듯...
  • 단, Socket or Back End 관련 내용은 나중에 분리가 필요할 때 관리가 용이하도록 의존하지 않게 폴더 분리 필요
• 개발 중 or 실 배포 시, 서버 운영방안 고민 필요할 듯
  • 기본적으로 자기 PC 에서 한다 해도 상호 테스트가 필요할 수 있음.
  • Docker?
  • Reverse Proxy?

[hyunnnn98]

칸반보드도 사용하자고 제안하려고 들어왔는데 이미 설정이 완료되어 있었다..!
역시 대단하군 👍

[hyunnnn98]

프론트엔드 디자인 가이드

디자이너가 없는 상황에서 효율적인 UI 개발이란?

1. UI Kit 또는 디자인 시스템 활용하기

   • UI Kit이나 디자인 시스템은 디자이너가 이미 만들어놓은 디자인 패턴과 컴포넌트를 모아놓은 라이브러리(ex.Material UI, Ant Design). 이를 활용하면 디자인의 일관성을 유지하면서도 쉽게 UI를 개발할 수 있다.

2. 디자인 컨셉과 스타일 가이드를 공유하기

   • 프론트엔드와 백엔드 개발자들끼리 서로의 개발 작업에 대해 이해하고 공유하는 것이 중요하다.
   • 디자인 컨셉과 스타일 가이드를 공유하여 프로젝트의 일관성을 유지할 수 있다.

3. 프로토타이핑 도구를 활용하기

   • 디자이너가 없는 상황에서도 프로토타이핑 도구(ex.Figma, Sketch, Adobe XD)를 활용하여 빠르게 디자인 아이디어를 시뮬레이션할 수 있다. 이를 통해 UI 디자인에 대한 전반적인 방향성을 정하고, 개발자들은 이를 기반으로 개발을 진행할 수 있다.

4. 사용자 중심의 디자인 원칙을 적용하기

   • 사용자 중심의 디자인 원칙을 적용하여 개발자들이 사용자의 관점에서 UI를 바라보고 개발할 수 있도록 한다. 이를 통해 사용자가 쉽게 이해하고 사용할 수 있는 UI를 개발할 수 있다.

5. 피드백과 수정 주기를 반복하기

   • 개발 중에 UI 디자인을 수정해야 하는 경우가 발생할 수 있다. 이때는 피드백과 수정 주기를 반복하면서 개발자들끼리 소통하고 협업하여 프로젝트의 일관성을 유지할 수 있다.

UX 라이팅

UX 라이팅이란? 사용자 경험을 향상시키기 위해 인터페이스에 텍스트를 작성하는 것 이다.
현재 프로젝트에서는 UX라이팅까지 신경 쓸 여유가 없어 보이긴 해도 (초기 프로토타입을 만들기에 있어 Must는 아니라고 생각했기에)
사용자 경험을 위해 UX라이팅을 신경 씀으로써 얻는 이점이 어떤 것인지 궁금해서 조사해봤다.

1. 목적 파악

   • 인터페이스에 작성하는 텍스트의 목적을 정확히 파악해야 합니다. 텍스트가 어떤 정보를 전달해야 하는지, 어떤 동작을 유도해야 하는지 등을 명확히 이해해야 한다.

2. 사용자 분석

   • 사용자의 니즈와 특성을 파악하여, 그들이 쉽게 이해하고 사용할 수 있는 언어와 용어를 사용해야 한다. 이를 위해 사용자 인터뷰, 설문조사 등의 방법을 활용할 수 있다.

3. 적절한 톤

   • 인터페이스의 목적과 사용자 특성에 맞는 톤을 사용해야 한다. 예를 들어, 엄격한 톤을 사용해야 하는 금융권 앱이냐, 유쾌하고 경쾌한 톤을 사용해야 하는 게임 앱이냐에 따라 텍스트의 톤을 조절해야 한다.

4. 적절한 길이

   • 텍스트의 길이는 인터페이스의 크기와 사용자가 읽는 시간 등을 고려하여 적절히 조절해야 한다. 너무 긴 텍스트는 사용자의 지루함을 유발할 수 있고, 너무 짧은 텍스트는 정보 전달이 충분하지 않을 수 있다.

5. 일관성

   • 텍스트는 일관성 있는 스타일과 용어를 사용해야 한다. 이를 위해 스타일 가이드와 용어집 등을 작성하고 공유하는 것이 좋다.

6. 테스트와 수정

   • 작성한 텍스트를 사용자들에게 테스트해보고, 필요에 따라 수정해야 한다. 사용자의 피드백을 받고, 문제점이나 개선 사항을 파악하여 텍스트를 수정하는 것이 중요하다.

도입해보고 싶은 기술

• Storybook
• Private Ui Library Package 만들기
• 반응형, 웹 접근성, 표준을 고려한 시멘틱한 HTML 작성
• 다크모드

서비스 아이콘

• Three Dice
• 주사위를 모티브로
  • https://icons8.kr/icon/16458/%EB%A9%B4%EC%B2%B4
  • https://icons8.kr/icon/nnGHHmGaVaQ5/rolling-dice

Reference

• ui-kit

https://changhoi.kim/posts/etc/great-operation-creating-react-ui-kit/

• TDS ( Toss Design System )

https://blog.toss.im/article/workflow-revolution
https://blog.toss.im/article/uxwriter-interview
https://tosspublic.notion.site/DEUS-b1eb298b1b1f45aa93cd169574afde1d

[Samsam-lee]

서버 기술 검토

1. 배포 환경
   • Vercel (구 ZEIT now)
     • 배포가 쉬움
     • 무료 버전의 경우 하루 최대 개수로 제한하기 때문에 페이지의 크기가 클 때 사용하면 좋음
     • 타 플랫폼과 다르게 서울에 CDN이 있어서 빠름
   • github page
     • BackEnd URL이나 Build 관여가 deep함
   • netlify
     • 배포가 쉬움
     • 무료 버전의 경우 한 달에 빌드 최대 시간으로 제한하기 때문에 페이지의 크기가 작은 경우 유리함
2. SSL
   • Reverse proxy를 활용하여 서버에 직접 요청을 하지 않고, proxy 에 요청하여 reverse 서버로 요청하는 방식을 사용하면 SSL 인증서를 proxy 서버에만 사용해도 됨 (NGINX로 이런 작업을 많이 하는 것 같지만 Vercel로 되는 것 같음....)
3. Socket
   • 트래픽의 격리와 전송 방식을 잘 구현해 주어야 한다.
     • 이벤트의 송수신은 각 구역마다 분리 (네임스페이스 활용) (플래닝 포커, 일정관리, 화이트보드)
     • 같은 구역이더라도 Channel 분리 (각각의 방)
   • 환경 고려
     • NodeJS의 특징인 Single Thread 기반의 Non-Blocking I/O 에서 비동기 이벤트 loop의 적인 sync한 로직 처리의 문제
     • async 메소드를 사용한 loop를 처리하지 않는다. (sync하게 처리하여 block상황을 만들지 않는다.)

Api Server / Socket Server 레포지터리를 구분해서 NextJS 내에 같이 돌려도 되지만 추후에는 서버 분리가 필요할 것 같다.

[JeongJaeSoon]

참고
웹소켓으로 개발하기 전 알아야 할 것들
https://yozm.wishket.com/magazine/detail/1911/?fbclid=IwAR1wYcS2bRVwef9lkBVm0-Hcbuq3kEEemcG2pjgdHog6AAr7Y8SKeYcA65Y

[hyunnnn98]

📝 2023/03/14 회의록

사전에 조사한 내용에 대한 디스커션

• 리포지토리 관리 방법
  • 디스커션을 각 섹션별로 활용하기
• 칸반보드
  • 리뷰어 설정도 추후 검토
• 서비스 아이콘
  • 저작권 확인
• 프로토타이핑 도구
  • ❓ 핵심부분만 피그마? 중요도가 낮은 부분은 ppt로 만들기?
  • 🥇 전체적인 UI는 피그마로 관리하기로 결정
    • 중요도가 높은 부분 : 실제 화면과 동일하게 만들고 싶다
    • 중요도가 낮은 부분 : 단순한 스케치로. ppt 에서 만드는것 처럼
• 반응형 디자인
  • 구현할때 편한거는 sp → pc 순으로 만드는게 좋을거같다
  • ❓구현하고자하는 서비스에 sp버전이 필요한것인가?
  • 🥇 pc버전을 먼저 구현하되, 추후 sp버전를 생각해서 반응형을 하기 쉽게 디자인해보자!
• 배포
  • Vercel 과 연동성이 좋아보인다
  • ❓Vercel에 배포하면 소켓서버는 어떻게 관리되는가?
    • 🥇 Vercel & Socket.io 사용해서 작동하는지 환경 검토해보기
  • 추후 배포시 proxy 설정은 필수적일듯
  • reverse proxy & forward proxy 검토
    • reverse proxy를 사용해서 SSL인증서 하나로 client, socket-server 전부 적용할 수 있다
• Socket server 과부하
  • node = 싱글 스레드 를 생각하여 서비스 규모가 커졌을때 일어날 수 있는 문제를 생각해두자
• 데이터베이스
  • 우선은 쿠키에 저장 ( 저장하려는 데이터가 보안적인 문제가 없기에 )

서비스에 넣고싶은 기능

1. 크롬 익스텐션 지원
2. room 생성 후 자동으로 클립보드에 저장
3. 투표 후 자동으로 평균 계산
4. 쉬어가기
5. 애그 타이머
6. 매회차 기록 저정해서 보여주기
   • 테이블 형식으로
   • 1회차.. 2회차.. 3회차 의 형식으로 기록되고, 해당 이름 클릭시 회차명 커스텀 가능

[JeongJaeSoon]

https://github.com/orgs/2P3S/discussions/1
논의 진행(상세 내용은 링크 참조)