미 로그인한 메인 페이지 자체의 고유한 기능은 설계상 존재하지 않는다. 사이트 로고와 검색, 로그인 기능은 네비게이션 바의 고유한 기능이다.
네비게이션 바
검색창
사실상 메인 페이지에서 제대로 구현해야 할 대상.
검색이라는 것이 positive case(올바른 역 이름만 들어온다)만 생각한다면 편하겠지만, negative case(역 이름 오타, 이름이 같은 역이 존재하는 경우 등등)역시 고려해야 함.
하지만 시간이 촉박하므로 positive case만 구현. 심한 경우 시연 동영상에 보여질 정도로 특정 역만 구현. ← 소스 코드를 제출해야 하므로 대충 봤을 때 걸리지 않는 방향으로 구현해야 함. ex) “건대입구역”인지 아닌지 검사하는 logic이 뻔히 보인다면 안되겠죠?
로고
메인 페이지로 이동할 수 있도록 구현하면 좋을 것 같다. 하지만 #4에서 필수적으로 구현해야 하는 내용은 아님
로그인 기능
#4에서는 구현하지 않을 예정. 버튼을 남겨둘 지 말지는 구현상 편리한 대로 하면 될 듯.
페이지 중앙
페이지가 휑해보이지 않을 정도로만 적당히 사진 넣기. 여기 넣는 사진을 S3에서 관리하면 될 듯.
페이지 레이아웃 (검색 기능)
현재 계획 상 네이버 지도를 따라하기 위해 왼쪽 위에 검색창을 두었다. 결국 검색에 대한 기능을 두 번 만들겠다는 뜻이다. (나머지 하나는 네비게이션 바) 여차하면 디자인을 변경하여 검색 페이지에도 네비게이션 바를 만들어둘 수 있을 것 같다. 그렇게 되면 왼쪽에는 정보만, 중앙에는 지도만 나온다.
검색 기능
네비게이션 바를 쓰던 검색창을 따로 만들던 검색 기능을 구현해야 한다.
구성할 정보
혼잡도 API 사이트 링크
위 사이트에서 혼잡도 API를 통해서 받아옴. 기본적으로 파일데이터를 제공하고 있기 때문에 API조차 적용할 여력이 없다면 이용이 가능하다.
애초에 실시간 데이터가 아니기 때문에 실시간 정보를 제공할 수 없음. 이건 최종 제출까지 갔을 때도 변하지 않는 사실이기 때문에, 이 점이 부각되지 않도록 신경쓸 필요도 있을 듯. 아무래도 API까지 사용하는데 실시간 데이터 제공이 안 되는 것은 아쉽긴 하다.
인증키(Encoding): ohjRTrtJoB63cu1%2F4ea6Dvjy%2B3O%2F%2BwXeZhWAoyEsZDrYAk3MYP4tmDUiTi%2BCxfcock57Vhgk3%2F9KFsjxrEgAhQ%3D%3D 인증키(Decoding): ohjRTrtJoB63cu1/4ea6Dvjy+3O/+wXeZhWAoyEsZDrYAk3MYP4tmDUiTi+Cxfcock57Vhgk3/9KFsjxrEgAhQ==
요청 URL 예시:
https://api.odcloud.kr/api/15071311/v1/uddi:b3803d43-ffe3-4d17-9024-fd6cfa37c284?page=(6)&perPage=(2)(&returnType=XML)&serviceKey=ohjRTrtJoB63cu1%2F4ea6Dvjy%2B3O%2F%2BwXeZhWAoyEsZDrYAk3MYP4tmDUiTi%2BCxfcock57Vhgk3%2F9KFsjxrEgAhQ%3D%3D
perPage는 페이지당 표현되는 역 수이고 page는 페이지 넘버이다. 상행 하행으로 나뉘어 있어 perPage를 2로 잡고 page를 조작하면 page번째 역의 상/하행을 검색할 수 있다.
역은 총 1704 아이템, 상/하행, 평일/토요일/일요일을 나누면 284개의 역을 제공 중인것으로 추정, 실제로 역과 number를 맵핑해야 하기 때문에 전처리 과정이 필요하고 전처리 하다 보면 정확히 알 수 있을 것 같다.
일단은 브라우저 확인 편의 상 XML로 요청했는데, 기본값이 JSON이라서 returnType는 빼고 보내서 JSON결과를 얻을 수 있다.
공기질 API 사이트 링크
인증키 이용해서 공기질 받아와서 구성하면 된다. 다만 테스트해보니 xml밖에 안된다. 물론 json으로 변환하면 되니 큰 문제는 아닌 듯.
1호선부터 8호선까지 역 순서대로(완벽히 일치하는 것은 아님) 번호가 1부터 245까지 매겨져 있음. 최종적으로 이용할 경우 이 번호를 맵핑해서 사용해야 쿼리 날려야 할 듯.
PMq – 0~15 좋음 16~35 보통 36~75 나쁨 76~ 매우나쁨
사이트 설명에는 시간단위로 제공된다고 나와있으나, 실제로 조회해 보니 분단위로 제공됨.
인증키: 7963444664796a703130395845777855
요청 URL 예시: http://openapi.seoul.go.kr:8088/7963444664796a703130395845777855/xml/airPolutionInfo/(시작역 번호)/(끝역 번호)/
노선도
#4에서는 네이버 지도 API를 이용하지 않을 계획이다. 따라서 현재 계획은 검색할 역에 대해서만 노선도 사진을 S3에 넣어 두고, 페이지 레이아웃 상 상세정보 페이지 이동 버튼을 가운데 두는 것이 좋을 것 같다. 노선도가 사진이라는 것은 굳이 밝히지 않는 것이 유리할 듯.
상세정보 페이지 이동 버튼의 경우도 타협이 가능하다. 화면 중앙(아마 검색한 역이 화면 중앙에 표시될 테니)에 location을 맞추는 작업이 어렵다 싶으면 정보 제공하는 쪽에 넣어버릴 수 있음.
정보 제공
어차피 정보는 서버에서 내려줄 테니 페이지 레이아웃 구성이 메인이 된다고 생각함. 다만 html CSS까지 다룰 여력이 없으므로 예제 코드 가져다가 사용할 텐데, 기존의 디자인을 유지할 수 있을 지 모르겠음. 거의 힘들 것으로 예상. 따라서 새로운 약식 디자인에 대응할 수 있어야 함.
노선도
정보제공보다 더 문제가 크다. 사진을 가져와서 보여주는 행위가 디자인적으로 어떤 영향을 미칠지 아직 나는 모르겠음. 그래도 좀 디자인에 신경쓰려면 페이지 마진 정도는 조절해 줘야 할 것 같다.
상세정보 페이지 이동
버튼의 위치를 결정해야 하는 문제가 있음. 궁극적으로는 네이버 API내 커스텀 버튼을 이용할 계획임. 다만 #4에서는 커스텀 버튼은 커녕 API조차 이용하지 않기 때문에 약식으로 구현하는 방향으로.
정보 구성
정보 구성 방법 자체는 검색 기능과 일치한다. URL자체에 검색어가 있기 때문에 정보를 얻어오는 과정 자체는 노선도 페이지와 크게 다르지 않을 것으로 예상.
정보 제공
UI에 대해서 궁극적으로는 충분한 고민이 필요함. 정보의 수가 충분해야 하나의 페이지를 풍성하게 채울 수 있을 것 같다. #4 에서는 편의시설 정보는 가져오지 않으므로, 아예 더미 정보를 던져주는 방식으로 시연 동영상을 퉁치는 방안이 있을 수 있음. UI구성 역시 최종 과제에서는 우리가 수정해볼 여지가 있지만, #4에서는 가져오는 예제 코드에 따라 달라질 수 있다는 점이 있다.
웹 서비스 이외에도 공공데이터포털처럼 API를 통해서도 정보를 얻을 수가 있다.
혼잡도
API통해서 가져온 정보 전체를 보여준다
/api/complexity/all
API통해서 역 하나의 정보를 받아와 보여준다
/api/complexity/station/:stationName
하나의 역에 대해 가장 혼잡한 시간과 가장 여유로운 시간을 상선/하선별로 보여준다.
/api/complexity/time/:stationName
하나의 역에 대해 현재 상태를 하나의 문자열로 표현해 준다. (여유/보통/혼잡)
/api/complexity/value/:stationName
공기질
API통해서 가져온 정보 전체를 보여준다.
/api/finedust/all
API통해서 역 하나의 정보를 받아와 보여준다
/api/finedust/station/:stationName
하나의 역에 대해 현재 상태를 하나의 문자열로 표현해 준다. (좋음/보통/나쁨)
/api/finesut/value/:stationName