개발 이외 카테고리 분류에 대한 논의

[JuneParkCode]

현재 dev 사이트를 보면 분류가 개발 세부 카테고리로 한정되어있습니다.
본래 기획에는 취미, 학문, 언어 등 다양한 분야를 아우르고 싶다는 바램이 있었는데요.
이게 빠지니까 좀 아쉽다는 생각이 드네요.

제가 생각한 방안은 두 가지 입니다.

첫번째는 현재 카테고리를 소분류로, 그리고 다시 대분류로 묶어보면 어떨까 싶습니다.

예를 들어,

카테고리 상위의 어떤 테이블
개발 id = 1 )
커리어 id =2
크리에이티브 id =3
언어 id =4
학문 id = 5
.
.
.

카테고리
웹 id =1 outer =1
모바일 id =2 outer =1
영어 id =3 outer = 4
일본어 id =4 outer =4
미술 id =5 outer =3
취업 id =6 outer =2
수학 id=7 outer =5
.
.
.

이런식으로 묶고

그리고 보여줄 때는

개발 / 커리어 / 크리에이티브 / 학문 / 언어 / ...
이렇게 한번 셀렉하고,
개발을 클릭하면
웹 / 모바일 / ...

이렇게 다시 나오도록 하는겁니다.

만들 수는 있으나, 프론트 / 백 모두 별도 개발의 시간이 필요합니다.

두 번째는 지금 방식을 그대로 사용하여 하는 겁니다.

그냥 카테고리에

42, 게임, 그래픽스, 네트워크, 웹, 모바일, 보안, 창업, 취업, 예술, 언어, 클라우드, 하드웨어, ...
이렇게 범주를 넣고 알아서 해시태그를 달고 처리하는거죠.

단점은 범주별로 묶어서 보여주기가 어렵다는 것과 카테고리가 자칫하면 너무 많아질 수 있다는 겁니다.

어떤 방식이 조금 더 낫다고 생각하시나요?
(단순히 좋은 것도 좋은 거지만, 개발 기간이나, 전체 구조 고려도 해주셨으면 합니다.)

@falconlee236 @koreanddinghwan @9utty @obvoso @jinaji

[JuneParkCode]

[falconlee236]

유지보수 측면이나 외관상 측면 모두 고려해서도 첫번째 안이 좋지않을까 싶어요
2번째 안이 서비스가 커지면 수많은 해시태그가 생겨날텐대 그럼 홈 화면도 난잡해질수가 있을거 같습니다. 안그러면 여기서 해시태그 목록같은것도 사용하누있을텐데 너무 많으면 그것도 내용찾기에 불편하고요
첫번째가 추가로 개발 비용이 들지만 오랫동안 쓸수있을것같습니다

[JuneParkCode]

유지보수 측면이나 외관상 측면 모두 고려해서도 첫번째 안이 좋지않을까 싶어요 2번째 안이 서비스가 커지면 수많은 해시태그가 생겨날텐대 그럼 홈 화면도 난잡해질수가 있을거 같습니다. 안그러면 여기서 해시태그 목록같은것도 사용하누있을텐데 너무 많으면 그것도 내용찾기에 불편하고요 첫번째가 추가로 개발 비용이 들지만 오랫동안 쓸수있을것같습니다

한다면 따로 범주 묶는 작업이랑 내부에 어떤 것들이 들어올지도 좀 고민해봐야겠네요...

---

나머지 분들도 의견 부탁...
@koreanddinghwan @obvoso @jinaji

[koreanddinghwan]

배포기간이 지금 상당히 미뤄진걸로 아는데, 일단 유저 확보하고, 실제 데이터가 어떻게 모이는지 확인한 후에 해도 늦지 않다고 생각합니다.
다음 스프린트에서 해도 될 것 같아요

[JuneParkCode]

이건 그럼 백로그로 남겨두고, 다음 스프린트떄 한번 해봅시다...