Brainstorms on a Future UI

Multiple UIs vs One UI

Before deciding on a future direction for the DSpace UI(s), we have to face up to the "elephant in the room". We currently are building, maintaining and supporting two UIs (JSPUI & XMLUI) under a single Committers group.

Therefore, in order to move forward, we must make a decision on whether this direction is the best one for DSpace.  As such, here's some pros/cons to multiple vs single UIs...(feel free to add your own)

Possible Benefits of Multiple UIs

• Choice: Having multiple UIs provides users & developers with a choice. They can choose which UI better fits their needs or their local technology expertise.
• Competition: Having multiple UIs provides friendly competition between UI developers. As one UI makes improvements / enhancements, it encourages the other to do the same (or risk losing users to the "better" UI).

Possible Disadvantages of Multiple UIs

• Developer Resources: Building, supporting & maintaining two UIs essentially requires twice as many developer resources. If the community is large enough (which arguably DSpace is), there may be enough developers to support this. However, this becomes less maintainable when a single Committers group is expected to be knowledgeable enough on both UIs to support/build/maintain both simultaneously.  Two UIs really requires two committers teams (one specifically devoted to each UI).

Possible Benefits of a Single UI

• Developer Resources: Obviously, one UI requires less developer resources to build, support and maintain.
• Easier to "Roadmap": It is much easier to plan out a long term roadmap/plan for DSpace if we have a single UI which all features must integrate into. It becomes harder to plan out features that must be supported in multiple UI frameworks / infrastructures

Possible Disadvantages of a Single UI

• One UI technology must rule them all : Can we all come together to decide on a common technology framework that actually will meet all our needs?  Or are there actually separate needs / use cases that warrant the building of distinct UIs (similar to Hydra project)

Proposal for a single out-of-the-box UI

Given the benefits and disadvantages above, one thing seems abundantly obvious: We cannot reasonably expect to continue supporting two UIs with a single Committers team. Or to restate that, it is unreasonable to expect any Committer (who are all volunteers, working at their own jobs) to be well versed enough to support, maintain, develop and review fixes for multiple UIs simultaneously.  This is an obvious misuse of the volunteer resources provided. Each institution has already made their own personal decision on which UI they wish to use, yet we are essentially forcing some institution's developers (e.g. Committers) to also be knowledgable on the other UI (which they never use on a day to day basis).

Given this, it only seems reasonable to also conclude:

• Conclusion: One DSpace Committers group can only reasonably build/support/maintain a single, out-of-the-box DSpace UI.
  • Please note this does NOT state there should only be ONE UI (as noted above there are some advantages to multiple UIs).  It simply states that there will only be one out-of-the-box UI.  
  • If there are enough developers/institutions who see an ongoing need for a secondary UI, they are welcome to build, support and maintain a secondary, optional UI with their own, separate group of developers/committers.
    • A sidenote of sorts: If a secondary "committers group" were to form around a secondary UI, it may someday make sense to "split" the "DSpace Committers Group" into several "sub-teams":  One team in charge of the underlying API / REST API, one team in charge of the primary, out-of-the-box UI, one team in charge of the secondary UI (if any).  These teams would likely have some overlapping members, but they'd each be self-sufficient and more tailored to the needs of each individual sub-modules.