Difference between revisions of "Talk:ESciDoc Patterns"
(From abstract to specific) |
|||
| Line 8: | Line 8: | ||
- OL for the pattern category. Here: "Organizing Layout and Display" and a number for the pattern (I am going to count them) | - OL for the pattern category. Here: "Organizing Layout and Display" and a number for the pattern (I am going to count them) | ||
- SM is used for the functional part "workspace" and the existing "Use Case" number (UC_PM_SM_01 CREATE ITEM) | - SM is used for the functional part "workspace" and the existing "Use Case" number (UC_PM_SM_01 CREATE ITEM) | ||
== From abstract to specific == | |||
OK, here is a proposal to get from the abstract pattern to a specific PubMan/eSciDoc Pattern: | |||
First step would be document why a pattern has been chosen by UIE for using it within a service: | |||
- pros/cons | |||
- best fit for the use case or the situation, the user is in | |||
- all parts of the pattern are described and related to the functional need (Use Cases) | |||
- all GUI controls are separately attached to the pattern first abstract - then concrete | |||
In some cases the pattern must be adapted to be integrated with respect to: | |||
- technical | |||
- functional | |||
- usability | |||
- style guide | |||
matters. | |||
After this I would give the pattern its final look and feel where every pixel is in place. | |||
Rupert 17:29, 14 November 2007 (CET) | |||
Latest revision as of 16:29, 14 November 2007
Nomenclature would be good to have:
e.g. P_OL-02-SM_01 would mean:
- The "P" stands for PubMan - OL for the pattern category. Here: "Organizing Layout and Display" and a number for the pattern (I am going to count them) - SM is used for the functional part "workspace" and the existing "Use Case" number (UC_PM_SM_01 CREATE ITEM)
From abstract to specific[edit]
OK, here is a proposal to get from the abstract pattern to a specific PubMan/eSciDoc Pattern:
First step would be document why a pattern has been chosen by UIE for using it within a service:
- pros/cons - best fit for the use case or the situation, the user is in - all parts of the pattern are described and related to the functional need (Use Cases) - all GUI controls are separately attached to the pattern first abstract - then concrete
In some cases the pattern must be adapted to be integrated with respect to:
- technical - functional - usability - style guide
matters.
After this I would give the pattern its final look and feel where every pixel is in place.
Rupert 17:29, 14 November 2007 (CET)