숨겨진 영역의 사이트로 수납이 잘못된 구성 요소 정리하기

개시하다

다국적 고니코니코에서 생중계된 인터넷 서비스 엔지니어 미쓰킨입니다.
이번에 소개한 것은 웹 서비스 데스크톱의 구성 요소 디자인에서 숨겨진 영역의site를 사용하여 일반적으로 수납하기 어려운 구성 요소를 쉽게 수납할 수 있는 방법이다.
이 방법은 대응요법이 아니라 도메인 이름의 본질을 바탕으로 한 디자인이기 때문에 팀의 인정을 받기 쉽고 장기적으로 다양한 안정을 가져올 수 있기를 기대한다.

불량 조립품 수납

당신이 운영하는 사이트에는 이 이름의 구성 요소 이름이 없습니까?

Header

Footer

NavigationBar

SideMenu

만약 이 구성 요소들이 Atomic Design으로 제작된다면 organisms에 있는 것으로 여겨지지만 디렉터리 트리에서 다른 구성 요소에 묻혀서 흐릿해졌을 것이다.

- footer
- g*****
- header 
- i*****
- ~
- m*****
- navigation-bar
- o*****
- ~
- r*****
- side-menu

수납하기 어려운 부품들을 어떻게 포착하는지 수납이 쉽다는 것을 설명해 드리겠습니다.

불량한 조립품들의 특징 수납

수납 불량 부품들이 가지고 있는 특징은 다음과 같다.

도메인별 컨텐츠 포함

도메인은 시간에 따라 변경될 수 있음

도메인이 없는 경우도 있습니다

.

기존 단일 도메인으로 축소할 수 없음

각 분야의 존재를 관리하거나 서비스 내의 분야와 전혀 무관한 존재라고 할 수 있다.

웹 사이트의 존재 만들기

사이트를 구성하기 위해 필요하거나 편의성을 높이기 위해 존재한다는 공통점이 있다.

웹 사이트이기 때문에 필요합니다

이를 통해 사이트의 편의성이 향상되었다

는 사이트 특유의 관심사

모든 사이트에 유사한 존재

어떤 의미에서 사이트의 도메인 이름 유형(사이트 개념 중의 유형의 인상)이라고 할 수 있다

이런 정보가 없으면 사이트에 정보를 공개해도 방문이 불가능할 수 있어 매우 사용하기 어려운 사이트다.
이 숨겨진 영역의 사이트가 수납이 잘못된 구성 요소를 잃어버릴 수 있는지의 관건입니다.

오토매틱 기어도 편의성을 높이는 존재입니다.

설명할 필요도 없이 사이트 지도는 확실히 사이트의 편의성을 높이는 존재이다.
사이트맵-page(사이트맵의 페이지)와site-map-section(사이트맵의 부분) 같은 구성 요소를 사이트의 도메인 이름 유형으로 이해하면site-header와site-footer도 그곳에 똑같이 존재하는 것이 뚜렷하다.
또 여러 사이트를 만들 때 사이트 내용을 검색하는 창을 유니버설 이름으로 설정하려면site-content-search-form으로 사이트 도메인 이름에 추가할 수 있다.웹사이트의 편의성을 높이는 존재이기도 하다.

sit e역의 분류 사용

sit e역으로 분류된 디렉터리 구조는 다음과 같습니다.

- a***
- ~
- r***
- site-content-search-form
- site-footer
- site-header
- site-map-section
- site-navigation-bar
- site-side-menu

뚜렷하고 수려하다.

책도 같은 방법을 포착할 수 있다

예를 들어 책을 구성 요소로 만들면 도메인 이름 내용 외에도 책 자체를 구성하는 일반적인 부품이 있을 것이다.책이라는 도메인이 없으면 흥미가 분산될 뿐만 아니라 index와 같은 짧은 이름도 사용하기 어려운 상태에 빠질 수 있다.

- back-cover 裏表紙
- cover 表紙
- d****
- ~
- h****
- index  索引
- information (書籍)情報
- j****
- ~
- v****
- wraparound-band 帯

책 영역을 명시하고 다음과 같이 분류하면 애매성이 생기지 않고 질서를 가져올 수 있다.

- book-back-cover 裏表紙
- book-cover 表紙
- book-index  索引
- book-information (書籍)情報
- book-wraparound-band 帯
- c****
- ~
- v****

비시트

site 이외에도 유사한 숨겨진 영역이 존재합니다.
이것들은 모두 규약을 돕고 사용하는 서비스에 의존한다.이런 것들을 서비스-help-*와 서비스-tos-*로 분류하면 더욱 예쁘게 분류할 수 있다.
상담(contact) 같은 건 사이트를 위한 상담일까, 서비스를 위한 상담일까 조금 고민해보는 게 좋을 것 같다.

URL과의 관계

URL이 *.com/service-help이 아니라 *.com/help인 것 같아서 거기는 도메인 초과 형태로 문제 없겠죠.
URL의 참조 객체는 라우팅으로 표현된 객체를 결정하는 상징적 링크입니다.
권한이 있는 사람에게는 HTTP의 상태 코드 200, 권한이 없는 사람에게는 403페이지가 표시되는 등 원래 URL이 그대로 놓여 있지 않기 때문에 URL은 URL이고, 구성 요소 이름은 구성 요소 이름으로 분리해 고려하면 관리하기 쉽다.(적절한 이름으로 관리하면 일정한 관계성은 알 수 있는 범위 내에서 안정된다)

BCD Design과의 관계

이번 사이트는 BCD Design에 대한 지식이 있으면 도움이 될 수 있다는 것을 알아야 한다.
BCD Design에서 헤더와 footer 등의 단어는 기본적으로 대응하는 단어로, 이 단어들은 내부에 Case Common Domaain의 성분(의존)이 있어 무엇을 의미하는지 이상하다.
즉, 헤더 내부에user-login-anchor와 같은 구성 요소가 있으면user역을 알고 사용하는 쪽의 입장이어야 하기 때문에 헤더 측은 Domain의 단어가 부족하다는 것을 명확히 나타낸다.
헤더라는 구성 요소는 어느 사이트에서든 작용으로 결정되지만 내용에 대해서는 각 사이트에 따라 결정된다.많은 로고와 검색 폼이 있을 수 있지만 무엇을 표시하고 어떤 기능을 제공하는지 사이트의 공백과 목적에 따라 결정된다.
anchor와button은 구체적인 베이스이고 헤더와footer는 추상적인 베이스입니다.
나비게이션과side 같은 단어(분류하면 Case)도 너무 모호하다. 나비게이션-menu와side-menu만 작용을 알 수 있지만 구성 요소의 내부 구성은 확실하지 않다.(조합 영역의 내부 구성이 완전히 다르기 때문에)
사이트-*(엄밀히 말하면 그 앱의 사이트) 조합을 할 때 내부 구성을 확인할 수 있기 때문에 조합 전 단계에서도 Domain의 단어를 파악할 수 있는 것이 부족하다.
따라서 BCD Design과 구성 요소의 분류에 도움이 되고 도메인 이름 관계에 대한 이해도 촉진된다.아토믹 디자인으로 써도 BCD 디자인이라는 생각에서 받은 은혜가 적지 않기 때문에 부족한 단어를 보완해 기분 좋은 카탈로그 트리를 받아보는 건 어떨까.