Product Manager
From OpenQuote
The concept of a "product manager" interface that would make product development more approachable for non-technical users has been around for a while. This page serves as a place for us to gather requirements and thoughts on the subject. In time, it will become a guide on how to use the feature, for now it is very much a feature under construction.
Requirements
- Must fit into the existing OpenQuote user interface (i.e. not a separate application). It will fit into the existing application and work in a similar way with a similar look and feel. Users already familiar with OpenQuote will recognise it and feel at-home. It will not demand that product developers install any new software in their machines.
- Must allow users to create/read/update/delete product elements. This applies to questions, quote model elements, choice lists, page scripts, HTML page content and product specific reports.
- Must allow users to read/update product properties. This applies to product name, risk assessment rules, tax rules, management charge rules, commission rules, brokerage, payment option rules, broker details (name, phone etc), selected product style and email notification settings.
- Must allow users to structure product elements. This applies to questions in the pageflow, scripts in a pageflow, page order in a pageflow, page conditionality in a pageflow and questions in the quote document.
- Must allow users to manually modifying product content. Products are defined in terms of content in a CMS (Alfresco). Users will be able to freely edit this content outside of the product manager without upsetting the operation of the product manager.
- Must support product inheritance The product manager will make product relationships and inherited features clear to the user.
- Must maintain product consistency For example, not allow a script to be deleted while it is referrenced to by the pageflow.
- Must support all the life-cycles that OpenQuote supports For example, new business quote and (one day) mid term adjustments and renewal.
- Must support all the document types which OpenQuote supports For example, Quote document and (one day) invoice, certificate, policy etc.
- Must offer undo/redo on all editing functions.
- Must allow multiple users to work on the same product/element concurrently.
- Must notify users of significant changes Much as a Wiki lists recent changed.
- Must include live product management Offer a 'publish' feature to make products live, and support 'suspend' and 'remove'.
- Must offer cut/copy/paste operations on products and product elements.
- Must offer product versioning Historical versions of product elements must be maintained along with a version history.
- Must offer facilities to test drive products.
- Must offer features to export/import products. Allowing products to be backed-up and moved between instance of OpenQuote.
- Must be accessible to users with difference specialities. For example, those who design screens, those who design documents, those who design rules, those who design scripts.
For some things, like product name, OpenQuote demands that one is defined - hence it is read/update above; for other elements, like page scripts, a user can freely add and remove them - hence create/read/update/delete.
Thoughts on design
It seems from the above that some kind of web based Rich Internet Application is called for. This would certainly satisfy (1) and is probably the only way to deliver the kind of functionality that is called for and have a solution that works within OQ's existing UI. It's early days yet, but GWT looks like a front runner for implementation as it fits very well with our existing stack and is easily capable of this kind of user interface (watch this presentation on the development of google wave if you're unsure.)
To start fitting things together we need to consider what the user experience will be - very, very roughly at this stage.
Traditional IDE
Initial thoughts centre on what most developers would recognise as an IDE. It could present the user with a tree listing the available products on the left, and a large area for editing product content on the right in a tabbed style.
This style of UI has some advantages. Notably, anyone with any software development experience will feel totally at home here. However, the Product Manager isn't aimed exclusively at experienced software developers (18); it is aim at other types of user too - so this is no great advantage.
While this kind of UI is great for editing files, the units of work within a product are not always files. Frequently the units are smaller (2): questions, or attributes, model fragments or pageflows fragments etc.
Also, this style of UI doesn't focus well on the relationships between elements (6 & 4). Maintaining a mental picture of the relationships between elements as you jump from file to file is something that software developers are very used to, but to satisfy our requirements (6) these relationships must be clear.
In summary, while this style of UI is the first to come to mind when thinking about a Product Manager, this is probably simply because it is the kind of UI which we are most used to. That does not mean it is a good fit for our requirements.
Relationship centric IDE
Whilst searching the net for inspiration on the subject of relationship centric IDEs, I came across Code Bubbles which appears to address many of our requirements in a novel way. There's a video demo of it here. The concepts aren't new, but they are well presented. And it is the concepts, rather than the implementation, that we might learn from. Obviously, Code Bubbles is aimed at OO languages, and we're not doing OO but the approach to navigating and displaying the relationships between fragments does seem very appropriate.
The mockups below are the result of thinking through how products might look and how edit operations might be supported using the concepts like those used in Code Bubbles.
Taking each of the requirements in turn we'll see if/how they might be mapped to this style of user interface.
1. Must fit into the existing OpenQuote user interface (i.e. not a separate application).
This is really more about technology than concept, but a GWT application would meet the requirement. There are a number of widget libraries which may help, like SmartGWT.
2. Must allow users to create/read/update/delete product elements.
Clicking on any element brings up a bubble for editing the appropriate element type. It may be tree-view, or a rich-text editor, or a properties form.
3. Must allow users to read/update product properties.
Opening a product bubble (by clicking on it's folder in the product browser) brings up a bubble containing the product's properties. The properties can also be edited from this bubble.
4. Must allow users to structure product elements.
TBD
5. Must allow users to manually modifying product content.
TBD
6. Must support product inheritance
7. Must maintain product consistency
TBD
8. Must support all the life-cycles that OpenQuote supports
TBD
9. Must support all the document types which OpenQuote supports
TBD
10. Must offer undo/redo on all editing functions.
TBD
11. Must allow multiple users to work on the same product/element concurrently.
TBD
12. Must notify users of significant changes
TBD
13. Must include live product management
This can be done from the product properties bubble shown in 3. above.
14. Must offer cut/copy/paste operations on products and product elements.
Cut/copy/paste will work with all text and rich-text editors. In addition to this, drag 'n' drop and menu operations also make it easy and natural for product content to me moved and duplicated.
15. Must offer product versioning
TBD
16. Must offer facilities to test drive products.
TBD
17. Must offer features to export/import products.
TBD
18. Must be accessible to users with difference specialities.
TBD
