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. 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. :-) 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. -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] > _________________________________________ 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]
