CRUD 응용을위한 유창한 리본 디자인
데이터베이스를 통해 작업하는 CRUD 응용 프로그램을 위해 Fluent ( "Ribbon") 스타일 UX를 디자인하고 있습니다.
문서 기반 응용 프로그램을위한 리본을 디자인하는 방법에 대한 많은 정보가 있습니다. Microsoft Guidelines 는 표준 탭과 그룹도 지정합니다.
그러나 이러한 표준 그룹은 비 문서 상황에 적합하지 않은 것 같습니다. 예를 들어 "찾기"명령은 "편집"그룹 내에 있어야합니다.
검색 within 문서와는 관련이 있지만 for 레코드와는 관련이 없습니다.
비 문서 응용 프로그램에 리본을 사용하기 위해 어떤 리소스 및/또는 예가 있습니까?
업데이트 27/9 : 예, 개발중인 응용 프로그램에 리본이 적합하다고 확신합니다. 문서 중심은 아니지만 순수한 CRUD도 아닙니다. 비즈니스 행동이 많은 복잡한 응용 프로그램입니다. 사전에 지침을 제공 할 수 있다면 리본 배열에 대한 워크샵을 진행하는 것이 더 쉬울 것입니다. 따라서 리소스 및 예제에 대한 원래의 질문에 대한 답변을 기대하고 있습니다.
가장 좋은 예는 MS Access라고 생각합니다. 모든 CRUD 명령은 Records 그룹에 있고 찾기 명령은 Find 그룹에 있습니다!
리본은 많은 명령을 가진 프로그램을 위해 설계되었습니다. CRUD 응용 프로그램에는 명령이 거의 없으므로 리본이 UI에 적합하지 않을 수 있습니다.
MS가 리본을 설계 할 때 수행 한 작업을 수행 할 수 있으며 가능한 한 많은 사람 (현장, 고객을 선호하는 고객)이 탭/그룹 목록과 몇 가지 명령을내어 가장 논리적 인 장소를 선택하도록 할 수 있습니다. 명령.
그리고 가장 중요한 것은 맹목적으로 지침을 따르지 말고 (이유가 없으면 무시하지 마십시오) 개인적인 취향을 사용자가 직관적으로 찾는 것과 혼동하지 마십시오.
나는 당신이 내 응용 프로그램과 "리본"인터페이스를 디자인하는 것과 거의 같은 상황에 처해 있습니다. 핵심 "비즈니스"개체를 기반으로 리본에서 명령을 그룹화하는 상황을 고려했습니다. 다시 말해, 내 응용 프로그램에서 사용자가 클라이언트 및 공급 업체를 관리 할 수 있도록 허용 한 경우 일반적으로 호출하는 모든 명령과 다양한 명령을 사용하여 공급 업체 전용의 다른 리본 그룹을 사용하여 클라이언트 전용 리본 그룹을 갖는 것이 합리적입니다. 해당 객체/레코드에 대해 실행해야합니까?
내가 이것을 스케치 할 때 하나의 리본 만 제공하고 사용자보다 도움이되는 경우 화면 관리 가이 스타일로 매우 까다로워지는 것이 분명해졌습니다 (적어도 나에게).
이 문제를 해결하는 데 가장 적합한 UI는 Outlook 2010 인터페이스입니다. Outlook은 별도의 탐색 요소를 사용하지만 예를 들어 메시지에서 연락처로 전환하면 리본 메뉴가 변경되어 당시 작업중인 인터페이스에 대해 지원되는 명령이 표시됩니다.
다시 예를 들어 보면 특정 레코드를 찾는 것은 사용자가 원하는 레코드 유형을 알고 있음을 의미합니다. 사용자가 핵심 개체 (예 : 고객보기)로 이동 한 다음 리본과 함께 고객과 관련된 일련의 명령을 표시 할 수 있도록 먼저 내비게이션 시스템을 갖추는 것이 좋습니다. 찾기는 실제로 "편집"그룹에 속할 수 있지만 컨텍스트는 고객보기에만 해당됩니다. 응용 프로그램 내의 다른 엔티티와 관련된 편집 그룹에 다른 찾기 명령이있을 수도 있습니다.
나는 이것에 대해서도 생각하고 있으며, 내가 생각해 낸 주요 아이디어는 Tim Lentine이 설명 한 것과 비슷합니다 : 각 주요 비즈니스 객체에 대한 탭을 가지고 있습니다. 예를 들어 해당 개체에 대해 가장 일반적으로 수행되는 명령을 탭에 넣었습니다. 예를 들어 "주문"개체에는 상태 변경 (예 : 취소, 배송 등), 청구서, 송장 보내기 등의 명령이있을 수 있습니다.
그러나 Windows Live 사진 갤러리의 리본이 작동하는 방식에 대해서도 생각했습니다. 어떤 방식으로, 사진과 메타 데이터의 데이터베이스를 관리합니다. 관심의 대상은 홈, 찾기 및보기 탭입니다. 또한 나타나는 검색/필터 상자에 대한 아이디어가 마음에 들었습니다.
이것들은 내가 숙고 한 CRUD 응용 프로그램에 대한 두 가지 주요 리본 아이디어입니다. 그래도 아직 아무것도 결정하지 않았습니다.
사진 갤러리 라인을 따라 특정 데이터 목록을 검색하고 삭제하는 등 하나의 탭을 수행 할 수 있습니다 (창의 메인 패널에 객체 목록을 표시하도록 계획했습니다). 필터링/그룹화를위한 또 하나가있을 수 있습니다 (WLPG의 '보기'탭과 유사). 보고서에 대한 다른 탭이있을 것입니다. 첫 번째 단락에서 설명한대로 상황 별 탭을 사용하여 선택한 객체에서 공통 명령을 수행 할 수도 있습니다.
리본이 달린 CRUD 앱에 대한 광범위한 경험이 없지만 몇 가지 아이디어가 있습니다 ...
읽기-사용자가 특정 개체를 찾는 표준 방식으로 하나 이상의 탭을 커밋합니다. 예를 들어 대학 데이터베이스 인 경우 학생/교수 용 탭 하나, 수업 용 탭, 건물 용 탭이 있습니다. 탭의 개체를 학생용 및 직원 용 등 더 미세한 수준으로 그룹화합니다. 간단한 필드 쿼리 인 경우 일반 텍스트 컨트롤을 직접 넣거나 복잡한 검색 대화 상자를 팝업 할 수 있습니다.
Create-삭제할 탭이 하나만 있거나 읽기 탭에 넣습니다. 별도의 작성 탭을 수행하면 그룹이 탭에 맵핑되고 구분 기호를 추가하여 미니 그룹을 작성하십시오.
pdate-이것에 대한 상황 별 탭을 심각하게 고려할 것입니다. 객체 유형 당 하나의 컨텍스트. 양식에 여러 유형이있는 경우 키보드 초점으로 컨텍스트를 구동해야합니다. 별로 재미 있지 않습니다. 이러한 업데이트 작업은 양식 자체에 적용 할 수 있습니다. 특히 적용과 같은 대화 '명령'옵션에 잘 매핑 된 경우 특히 그렇습니다.
Delete-기본적으로 리본이 아닌 명령이 잘 묻혀 있습니다. 데이터를 폐기하는 것은 권장하지 않습니다. 대신 사용자가 데이터를 '보관'또는 '비추천'또는 '학부'데이터로 유도하여 특정 쿼리에만 표시되도록하십시오. 이러한 작업은 일반적으로 개체별로 다르므로 양식 또는 상황에 맞는 탭에서 작동합니다. 주간 백업, 보관 및 유지 관리 작업이 삭제를 수행하도록합니다.