I'm not so convinced that the division of metadata & data needs to be so strictly enforced in the UI. FWIW, I would find it natural to go to a "Person" section of the administration screen to both manage person records & manage settings affecting persons (like person attributes), since – at least in my mind – managing person records, merging persons, configuring person attributes, etc. are all about administrating persons. I wouldn't expect them all on the same screen… maybe under different tabs or pages within that admin section. Anyway...
Vlad, is this the type of layout you're considering? http://jsfiddle.net/burke/yWPbg/embedded/result/ -Burke On Sun, Oct 2, 2011 at 10:46 PM, Darius Jazayeri <[email protected]>wrote: > Re: CONTENT MANAGEMENT vs DATA MANAGEMENT, my main point is that "Manage > Encounter Types" and "Manage Encounters" should go in different places. The > former is about managing metadata or system configuration. The latter > is DATA MANAGEMENT. > > (So, yes, managing the definitions of Person Attribute Types should * > definitely* go in a different section from managing Persons.) > > -Darius > > > On Sun, Oct 2, 2011 at 7:13 PM, Burke Mamlin <[email protected]>wrote: > >> On Sun, Oct 2, 2011 at 7:57 PM, Darius Jazayeri >> <[email protected]>wrote: >> >>> Hi Vlad, >>> >>> A few comments: >>> >>> 1. I would want another high-level category for DATA MANAGEMENT. (This >>> would include managing Patient, Person, Encounter, Observation, and Order.) >>> Fixing data entry errors is distinct from configuring the lists of >>> locations, encounter types, etc. And I think I'd want a high-level category >>> for ANALYSIS & REPORTING. >>> >> >> I thought CONTENT MANAGEMENT was data management. Do we really need to >> split up managing persons & managing person attributes into separate >> sections? >> >> >>> 2. I don't love the distinction between CONTENT MANAGER and CONCEPT >>> MANAGER. Maybe just changing a name would fix it, but it doesn't feel quite >>> natural for me to have Forms go under CONCEPT rather than CONTENT. Maybe >>> rename it to CONCEPTS & FORMS. :-) >>> >> >> How about SYSTEM ADMIN → ADMINISTRATION and CONCEPT MANAGEMENT → >> CONFIGURATION? >> >> >>> 3. Add-on modules should not all go in their own special place. Rather >>> they should be encourages to plug into the relevant high-level categories. >>> E.g. all get grouped in a special place. The right approach is that modules >>> should be able to plug into the relevant high-level categories. (For example >>> a module might plug into both CONTENT MANAGEMENT *and* DATA MANAGEMENT.) >>> Obviously most modules won't naturally do this out of the box. We'll need to >>> tell them how to do so. >>> >> >> Agreed, but we will still want a "Modules" entry in the ADMINISTRATION >> section under which to enable, disable, install, and remove modules. >> >> -Burke >> >> >>> >>> -Darius >>> >>> On Sun, Oct 2, 2011 at 1:07 PM, Vlad Vega <[email protected]> wrote: >>> >>>> Hi All, >>>> >>>> I've been slowely developing a menu system and wanted to come to some >>>> initial conclusions in the what goes where problem. >>>> >>>> Please take a look and see if you believe these assignments fit. >>>> >>>> Key: >>>> ALL CAPS: Super Category >>>> Under small caps: Sub categories of links and modules. >>>> >>>> SYSTEM ADMIN >>>> Users >>>> HL7 Messages >>>> Maintenance >>>> Modules >>>> Logic Module >>>> MRN Generator >>>> HTML Form Entry >>>> Reports >>>> Analysis and Reporting >>>> >>>> CONCEPT MANAGER >>>> Programs >>>> Concepts >>>> Forms >>>> Xforms >>>> Report Definitions >>>> >>>> CONTENT MANAGER >>>> Patients >>>> Persons >>>> Encounters >>>> Locations >>>> Observations >>>> Orders >>>> Scheduler >>>> From Entry >>>> >>>> Also, I would like to put any module that the user downloads into a >>>> system >>>> admin - designated Subcategory (so that those modules will show up in a >>>> separate grouping under a subcategory in addition to the links.) >>>> >>>> Vlad >>>> >>>> _________________________________________ >>>> >>>> To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail >>>> to [email protected] with "SIGNOFF openmrs-implement-l" in >>>> the body (not the subject) of your e-mail. >>>> >>>> [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l] >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>> OpenMRS Implementers' mailing list >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list > _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
