For any implementers interested in having input on a new & improved administration screen, here are a couple mockups to consider:
1. Here's a mockup assuming that admins with appropriate privileges would see options to manage types, attributes, etc. when viewing data: http://jsfiddle.net/burke/yWPbg/embedded/result/ 2. Here's a mockup that duplicates the Patients, Persons, Programs, etc. in the configuration section, so, for example, managing person attributes would be under CONFIGURATION → Persons and editing/merging persons would be under DATA → Persons: http://jsfiddle.net/burke/Rj6mL/2/embedded/result/ @Vlad – if you don't get input beyond myself/Darius/Roger, then go ahead and assume #2 is the way forward. Cheers, -Burke On Mon, Oct 3, 2011 at 7:18 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > I'm with Darius. System admin, Metadata configuration, Data management.* > *** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Darius Jazayeri > *Sent:* Monday, October 03, 2011 12:18 AM > *To:* [email protected] > > *Subject:* Re: [OPENMRS-IMPLEMENTERS] Admin Interface categorization**** > > ** ** > > I think that's the wrong way to approach it. I think that depending on the > type of user you are, or the task you're doing, you'll approach the page > thinking either "I want to configure my system", or else "I'm dealing with > data that has been entered".**** > > ** ** > > But I'd be much more interested in having some actual implementers give > their opinions. Burke and I talk a lot, but we're not the domain experts > here. :-)**** > > ** ** > > -Darius**** > > ** ** > > On Sun, Oct 2, 2011 at 8:45 PM, Burke Mamlin <[email protected]> > wrote:**** > > 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]
