Recommendations are that a web ui (and specifically the XMLUI is of interest in this case) be constructed not on the "Xml files" themselves, but utilizing the DSpace Configuration Service.
http://scm.dspace.org/svn/repo/modules/dspace-services/trunk/api/src/main/java/org/dspace/services/ConfigurationService.java http://scm.dspace.org/svn/repo/modules/dspace-services/trunk/impl/src/main/java/org/dspace/servicemanager/config/DSpaceConfigurationService.java An enhancement to the ConfigurationService would support retaining the origin of DSpaceConfig values so that they may be serialized by the implementation no matter their origin (database, xml file, properties files, etc) http://scm.dspace.org/svn/repo/modules/dspace-services/trunk/impl/src/main/java/org/dspace/servicemanager/config/DSpaceConfig.java An implementation can be written against the dspace-services addon module with standalone tests independent of dspace-api, dspace-xmlui-api, or dspace-jspui-api. Interfaces can then be designed against the dspace-xmlui-api or dspace-jspui-api. Considerable thought and redesign needs to go into the "separation" between "configuration state" that is properties based vs "application state" which, at this point, should be targeting the use of spring framework for definition. This means that, for instance, in the case that workflows are being assigned to specific collections, should be preserved as configuration properties attached to those collections, serialized into the database. Current prototyping to consider in this avenue are the following DSpace 2.0 technologies. http://scm.dspace.org/svn/repo/modules/storage-db/ http://scm.dspace.org/svn/repo/dspace2/core/trunk/impl/src/main/java/org/dspace/services/storage/MemorySimpleStorageService.java The definition of the actual workflow is captured in spring where the application of IoC and DI can be harnessed to allow the wiring of complex workflows to be captured via a combination of spring definition files and/or annotations. @mire will be providing a contribution of a Configurable Reviewer Workflow for DSpace 1.8 later this spring, it should exemplify some of this conceptually, students applying in this area will be able to review it as a model for the clean separation of configuration state from application structure and some mentoring will be available on the topic. It is important to clarify that we need more than just a simple editor of XML files to properly refactor the configuration support in DSpace to be enterprise grade. I highly recommend considering this in your application. Mark On Tue, Apr 5, 2011 at 9:15 AM, Vibhaj Rajan <vibh...@gmail.com> wrote: > Hello Andrea and Tim, > > Thank you very much for the support and suggestions for the project idea. > > With the background provided regarding Web UI for editing XML Configuration > Files, I admit on your view regarding its complexities, however I would like > to play with that idea and come up with suggestions and contribute to it, if > possible. > > Currently, I am getting myself familiar with the DSpace architecture and > exploring a local installation particularly looking into concrete ideas to > support the main idea of improving the Submission UI. > > I would be really happy to know more about the usability studies done at > OSU. Do we have any more institutions doing such studies ? These information > , I hope, will be able to clearly define the project, that is to be > completed within scope of GSoC, in my application. > > Thank you once again for encouraging help from your side. > Hope to give my best. > > Regards, > > > On Tue, Apr 5, 2011 at 8:23 PM, Tim Donohue <tdono...@duraspace.org> wrote: >> >> Hi Vibhaj, >> >> As Andrea mentioned, it's great to see you are interested in GSoC! I've >> added a few extra comments to what Andrea mentioned below. I also copied in >> the 'duraspace-gsoc' listserv, which is our DuraSpace GSoC list (however, it >> is good that you posted this message initially to 'dspace-devel' as that is >> probably the best place to get general comments from DSpace developers). >> >> On 4/4/2011 11:39 PM, Andrea Schweer wrote: >>> >>> On 05/04/11 16:13, Vibhaj Rajan wrote: >>>> >>>> In addition, I would like to know whether the project shall be >>>> targeted to making changes to the UI level only, or whether well >>>> planned modifications to underlying logic, without interfering with >>>> the workflow process but only to improve the UI will be allowed ? >>> >>> I assume that modifications to the underlying logic will also be >>> acceptable, as long as there is a good reason for the change. I expect >>> that this is something that would be worked out between the student, the >>> mentor(s) and the DSpace committers during the project. >> >> Andrea is correct -- changes to underlying logic would also be allowed, >> provided that the mentor(s) and DSpace committers were in favor of those >> changes. However, there are some issues around keeping this project well >> "scoped". I'd worry about trying to do *both* UI usability modifications, >> and major underlying logic changes, as I feel that would be too large of a >> project for just one summer. The project as it is now, was meant to >> concentrate more on improving the usability of the Submission UI, and >> perhaps other areas of the general DSpace UI (rather than completely >> reworking the underlying submission logic). >> >> More on this below.. >> >>>> I would be happy to get suggestions regarding this project idea. >>> >>> What I would really like to see in proposals for this project are >>> answers to the following questions: Where do you see the biggest >>> problems at the moment? How do these problems impact the experience of a >>> submitter? Do you have concrete suggestions for improvements? >>> >>> You may also have seen my comment on >>> https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas >>> about making the submission process configurable via the web interface. >>> At the moment, the submission forms are defined using a couple of XML >>> files (see >>> https://wiki.duraspace.org/display/DSDOC/Submission+User+Interface if >>> you haven't found that page already). Only someone with shell access to >>> the DSpace server can change these files, and changes to the files >>> typically require DSpace to be restarted. Consequently, the people who >>> know best what metadata fields etc should be populated during submission >>> can't actually customise the submission process at all. The EasyDeposit >>> >>> (http://blog.stuartlewis.com/2010/02/03/easydeposit-sword-deposit-tool-creator/) >>> administrator interface is a good example for a more user-friendly >>> variant, I think. >> >> Andrea gave you some ideas of places to potentially get started. Though, >> I'll admit, the idea of making the submission process configurable via the >> Web Interface is potentially a bit complex (i.e. it's likely out-of-scope >> for this particular GSoC project). For background on the complexities, see >> discussion here: >> >> https://wiki.duraspace.org/pages/viewpage.action?pageId=23268096&focusedCommentId=25068048#comment-25068048 >> >> So, a part of me feels that this particular GSoC project would need to be >> more tightly scoped to Improving UI Usability (or Accessibility or both). It >> would likely need to avoid digging into deeper issues of reworking the >> entire underlying workflow logic, as that could be a rather large project in >> itself. However, that being said, if we found a DSpace committer/mentor >> interested in mentoring that larger 'underlying logic' project, we could >> likely pull together a separate GSoC project which could *begin* that >> refactoring work (If any committer is interested in this, please get in >> touch!). But, I feel that's a separate GSoC project altogether, and >> shouldn't be combined with improvements to UI Usability or Accessibility. >> >> As you may be able to tell, this "Improve Submitter User Experience" >> project idea is less "defined" than some of the others, as it came up during >> discussions just last week. However, we do have some institutions (namely >> Ohio State University) which have done some recent usability studies on the >> Submission User Interface, who may be able to help us better define what >> areas of the UI may require extra work. >> >> Peter Dietz, one of our DSpace Committers, may be able to add more details >> around usability studies/work done at OSU, and what work he feels this GSoC >> project may encompass (I've copied him on this message). >> >> Please let us know if you have further questions about this project idea, >> Vibhaj. You are also welcome to apply for a different project idea, if you >> feel this one is not very well defined. >> >> - Tim >> >> -- >> Tim Donohue >> Technical Lead for DSpace Project >> DuraSpace.org >> > > > > -- > Vibhaj Rajan > > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Technologielaan 9 - 3001 Heverlee - Belgium ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
