피그마를 활용한 어플리케이션 기획

 

 

 

피그마를 활용하여 앞으로 계획할 프로젝트의 초안에 대해 만들었다.

첫 번째 사진 우선 각 프레임이다.

 

두 번째 사진은 각 프레임간에 prototype이다.

 

마지막으로 완성된 피그마를 영상으로 첨부하였다.

 

 

 

 

버튼을 클릭하면 추가되는 영역까지는 아직 못하였지만,

충분히 할 수 있다고 생각하고

시간이 날 때 다시 도전해볼 예정이다.

 

 

 

웹 표준

웹 표준이란 W3C(World Wide Web Consortium)에서 권고하는 ‘웹에서 표준적으로 사용되는 기술이나 규칙’으로,

사용자가 어떠한 운영체제나 브라우저를 사용하더라도 웹페이지가 동일하게 보이고 정상적으로 작동할 수

있도록 하는 웹 페이지 제작 기법을 담고 있다.

웹 개발에 사용되는 언어인 HTML, CSS, JavaScript 등의 기술을 다룬다.

세 기술은 화면의 구조, 표현, 동작을 각각 담당합니다.

 

웹 표준의 장점

1. 유지 보수의 용이성

 

각 영역이 분리되면서 유지 보수가 용이해졌고, 코드가 경량화되면서 트래픽 비용이 감소하는 효과도 생겼다.

 

2. 웹 호환성 확보

 

웹 표준을 준수하여 웹 사이트를 제작하면 웹 브라우저의 종류나 버전,

운영 체제나 사용 기기 종류에 상관없이 항상 동일한 결과

 

3. 검색 효율성 증대

 

웹 표준에 맞춰 웹 사이트를 작성하는 것만으로도 검색 엔진에서 더 높은 우선순위로 노출된다.

 

4. 웹 접근성 향상

 

브라우저의 종류, 운영 체제의 종류, 기기의 종류 등 웹에 접근할 수 있는 환경은 매우 다양하고,

이 모든 환경과 사용자에 맞춰서 웹 페이지를 개발하는 일은 쉽지 않지만,

이것을 해결한다.

 

 

Sementic HTML이란?

 

semantic : 의미의, 의미가 있는 이라는 뜻의 영단어

HTML : 화면의 구조를 만드는 마크업 언어

이러한 화면을 시멘틱 요소를 통해

이렇게 분리할 수 있고 보기 편할 뿐 더러, 수정 및 관리하기도 편리하다.

 

1. 개발자 간 소통

 

여러 명의 개발자가 웹 페이지를 개발하면서 <div><span>으로만 HTML 코드를 작성한다고 해보자

그렇다면 요소의 이름을 보고서는 각 요소가 어떤 기능을 하는지 전혀 파악할 수 없기 때문에

주석을 작성해서 설명하거나 idclass를 사용해서 일일이 표기해야 한다.

 

2. 검색 효율성

 

시멘틱 요소를 사용하면, 어떤 요소에 더 중요한 내용이 들어있을지 우선순위를 정할 수 있고,

우선순위가 높다고 파악된 페이지를 검색 결과 상단에 표시된다.

 

3. 웹 접근성

 

웹 접근성은 나이, 성별, 장애 여부, 사용 환경을 떠나서 항상 동일한 수준의 정보를 제공할 수 있어야 함을 뜻한다.

예시를 들면, 시각 장애인의 경우 웹 페이지에 접근할 때 음성으로 화면을 스크린리더를 이용하는데,

화면의 구조에 대한 정보까지 추가로 전달해 줄 수 있어 콘텐츠를 좀 더 정확하게 전달

 


 

웹 접근성

 

일반적으로 웹 접근성은 장애인, 고령자 등이 웹 사이트에서 제공하는 정보에

비장애인과 동등하게 접근하고 이해할 수 있도록 보장하는 것을 뜻한다.

이런 상황을 해결하고자 노력하는 것이 바로 웹 접근성(Web Accessibility)

 

웹 접근성 실태

 

안타깝게도, 우리나라의 웹 접근성 수준은 높은 정보화 수준에도 불구하고 높지 않다.

2021년 기준, 일반 국민의 정보화 수준을 100이라고 할 때,

장애인, 고령층 등 디지털 취약 계층의 정보화 지수는 75.4점이었고,

우리나라 웹 사이트들의 웹 접근성 평균 점수는 100점 만점에 60.8점이다.

 

국내 온라인 쇼핑몰 사이트를 보면 상품의 상세 정보가 이미지로 올라와 있는 경우가 많고,

텍스트로 표시된 정보는 굉장히 제한적이다.

이런 문제점을 파악하고 이미지 속 글자를 인식하여 텍스트로 변환, 스크린 리더가 읽을 수 있게

만드는 기능을 제공하는 사이트도 있지만,

이미지 속 글자를 인식하고 변환하는 과정에서 시간이 소요되기 때문에

텍스트로 작성되어 있는 경우와 비교했을 때 정보에 접근하는데 시간이 더 걸리게 된다.

 


 

웹 접근성을 갖추면 얻을 수 있는 효과

 

1. 사용자층 확대

 

웹 접근성을 확보하면 장애인, 고령자 등 정보 소외 계층도 웹 사이트를 자유롭게 이용할 수 있게 된다.

그만큼 사이트의 이용자를 늘릴 수 있고, 새로운 고객층을 확보할 수 있게 된다.

실제로 웹 접근성 향상을 통해 매출이 증가한 외국 쇼핑몰 사례도 있으며,

국내 온라인 쇼핑몰에서도 노년층의 매출이 증가 추세를 보이고 있다.

 

2. 다양한 환경 지원

 

앞서 이야기했듯 정보 소외 계층이 아니더라도 정보에 접근하기 어려운 상황에 처할 수 있다.

운전 중이라 화면을 보기 어렵거나, 마우스를 사용할 수 없는 상황 등이 있다.

웹 접근성을 향상 시키면 다양한 환경, 다양한 기기에서의 웹 사이트를 자유롭게 사용할 수 있게 되므로

서비스의 사용 범위가 확대되고, 자연스럽게 서비스의 이용자 수 증가를 기대할 수 있다.

 

3. 사회적 이미지 향상

 

기업의 사회적 책임에 대한 중요성이 점점 증가하고 있는 상황에서,

웹 접근성 확보를 통해 기업이 정보 소외 계층을 위한 사회 공헌 및 복지 향상에 힘쓰고 있음을 보여줄 수 있다.

기업의 사회적 이미지가 향상되면 그만큼 이용자 수의 증가는 물론 충성 고객을 확보할 수 있는 가능성이 늘어나게 된다.

 

 

 

상태(state)란?

상태는 변하는 데이터입니다. 특별히 UI, 프론트엔드 개발에서는 "동적으로 표현되는 데이터"입니다.

 

로컬 상태란?

다른 컴포넌트와 데이터를 공유하지 않는 폼(form) 데이터는 대부분 로컬 상태

input box, select box 등과 같이 입력값을 받는 경우가 이에 해당

 

전역 상태란?

다른 컴포넌트와 상태를 공유하고 영향을 끼치는 상태

서로 다른 컴포넌트가 사용하는 상태의 종류가 다르면, 꼭 전역 상태일 필요는 없다.

출처(source)가 달라도 된다.

그러나, 서로 다른 컴포넌트가 동일한 상태를 다룬다면, 이 출처는 오직 한 곳이어야 한다.

만일 사본이 있을 경우, 두 데이터는 서로 동기화(sync)하는 과정이 필요한데, 이는 문제를 어렵게 만든다.

 

그렇다면 전역으로 상태를 관리해야 하는 경우는?

ex) 홈페이지 다크모드, 국제화 설정(홈페이지 영어 -> 한글로 번역 )

 

Side Effect란?

"함수의 입력 외에도 함수의 결과에 영향을 미치는 요인"입니다. 대표적으로 네트워크 요청, API 호출이 Side Effect"

 

하지만 상태 관리 툴이 반드시 필요하지는 않다.

상태 관리 툴이 없어도 충분히 규모 있는 애플리케이션을 만들 수 있다.

그러므로 장단점을 인지하고 사용해야 한다.

 

 

위 컴포넌트의 state를 props를 통해 전달하고자 하는 컴포넌트로 전달하기 위해 그 사이는 props를 전달하는 용도로만 쓰이는 컴포넌트들을 거치면서 데이터를 전달하는 현상을 의미한다.

위 그림처럼 컴포넌트 A의 state를 컴포넌트 D로 전달하기 위해선 사이에 있는 컴포넌트 B, C를 거쳐야 한다.

 

<Props Drilling의 문제점>

Props의 전달 횟수가 5회 이내로 많지 않다면 Props Drilling 은 큰 문제가 되지 않지만,

규모가 커지고 구조가 복잡해지면서 Props의 전달 과정이 늘어난다면 아래와 같은 문제가 발생한다.

 

● 코드의 가독성이 매우 나빠지게 됩니다.

● 코드의 유지보수 또한 힘들어지게 됩니다.

● state 변경 시 Props 전달 과정에서 불필요하게 관여된 컴포넌트들 또한 리렌더링이 발생.

따라서, 웹성능에 악영향을 줄 수 있다.

 

이러한 상황에 다양한 상태관리 라이브러리(Redux, Context api, Mobx, Recoil)를 사용하여 방지할 수 있다.

 


 

Redux

 

Redux에서는 컴포넌트와 상태를 분리하는 패턴을 배운다.

따라서 상태 변경 로직을 컴포넌트로부터 분리하여 표현에 집중한, 보다 단순한 함수 컴포넌트로 만들 수 있다.

 

기존에 배운 React의 데이터 흐름에 따르면, 최상위 컴포넌트에 위치시키는 것이 적절하다.

하지만 이런 상태 배치는 다음과 같은 이유로 다소 비효율적이라고 느껴질 수 있다.

 

1. 해당 상태를 직접 사용하지 않는 최상위 컴포넌트, 컴포넌트1, 컴포넌트2도 상태 데이터를 가짐

2. 상태 끌어올리기, Props 내려주기를 여러 번 거쳐야 함

3. 애플리케이션이 복잡해질수록 데이터 흐름도 복잡해짐

4. 컴포넌트 구조가 바뀐다면, 지금의 데이터 흐름을 완전히 바꿔야 할 수도 있음

 

라이브러리인 Redux는, 전역 상태를 관리할 수 있는 저장소인 Store를 제공함으로써 이 문제들을 해결

Redux의 구조 / 참조:codestates

  1. 상태가 변경되어야 하는 이벤트가 발생하면, 변경될 상태에 대한 정보가 담긴 Action 객체가 생성
  2. 이 Action 객체는 Dispatch 함수의 인자로 전달.
  3. Dispatch 함수는 Action 객체를 Reducer 함수로 전달
  4. Reducer 함수는 Action 객체의 값을 확인하고, 그 값에 따라 전역 상태 저장소 Store의 상태를 변경
  5. 상태가 변경되면, React는 화면을 다시 렌더링

   즉, Redux에서는 Action → Dispatch → Reducer → Store 순서로 데이터가 단방향으로 흐르게 된다.

 

 

 

+ https://facebookarchive.github.io/flux/docs/in-depth-overview/

+ Recent posts