HowTo port a screen from Old Petra: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
# Start | ==Old screen== | ||
# Make a screenshot | # Start Petra 2.3 (perhaps in a virtual machine). | ||
# If the screen contains a Table scroll | # Make a screenshot of the screen you are going to port to OpenPetra. Copy the screenshot into a word document or into a graphics processing program and save it. | ||
# Also make | # If the screen contains a Table, scroll the Table to the right and make several screenshots in order to capture the headers of all columns and the format of the data of all the columns (e.g. bool, decimal, text, date). | ||
# | # Try to operate the screen and to perform the obvious actions that it offers (eg. add a record, edit a record, delete a record). Use the Petra User Guide for the Module in which the screen is located to get the instructions that a user is presented with for this screen. Try to get a 'feel' for how the screen operates, how it accepts and rejects data, the options it presents to the user and what - if anything - is special about that screen. | ||
# Create a | # Also check the menus for any special menu items that are not normally present in screens like the one in question and note them down. | ||
# The | # If the screen opens other screens (Forms or Dialogs) as a result of an action of the user make screenshots of those screens as well as you will need to port those too if they don't already exist in OpenPetra. | ||
# After | # Finally, open Menu Help->About Petra. In the dialog that opens you can find the name of the 4GL program for the screen. Note this down as you will need this in order to open that 4GL file to read through the full screen logic (i.e. if values of Labels or TextBoxes are calculated, to check if the program has some extraordinary behaviour that isn't obvious from operating the screen, how the screen validates its values, or how the screen is set up or parametrised). You will also need to do this for any detail screen(s) and other screens that are opened from this screen and which don't already exist in OpenPetra. | ||
# In theory you could now close Petra 2.3 (and the virtual machine) and start to think about the development of the new screen. However, in practice you will want to keep them open to see how the user interaction with the screen works out in detail and how the screen's program code is reflected in the behaviour of the screen. | |||
==New Screen== | |||
* Compared to Petra we have vastly different capabilities for layout and screen design in OpenPetra! | |||
** We can have much larger screens! | |||
*** In general we should aim for a screen to work well on a 1024x768 resolution (it really needs to work on a 800x600 resolution!), that is to make sure that the user is not forced to scroll through the screen on such resolutions for the normal operation of the screen. | |||
*** In OpenPetra the screens should hardly ever be fixed in size (in Petra they were often fixed to 640x480!) and thus the user can make them larger, and we can and should make use of that for improving the layout of the screen. | |||
** OpenPetra screens can contain Tabs and UserControls. | |||
** Whereas in Petra there was often a combination of a 'Browse' and an 'Edit' screen, in OpenPetra we have reduced that to one screen for such purposes. Such an OpenPetra screen contains both the Table ('Browse') and the Details ('Edit') (in the Grid and Details Panels, respectively). | |||
===(Re-)Design decisions=== | |||
# Ask yourself the question how usable the Petra 2.3 screen was and if it can perhaps be done better in OpenPetra by using a different approach. The focus should be on usability and on reducing the 'clicks' and other operations such as keyboard strokes or scrolling that are needed to perform a certain functionality in that screen. | |||
## Put yourself in the position of a new OpenPetra user that will open the new screen in question for the first time and ask yourself: | |||
### is everything logically arranged; | |||
### should some user interface elements be grouped into GroupBoxes for clarity; | |||
### is there something that could be confusing or that will need explanation; | |||
### are the Labels descriptive and not technical; | |||
### are user interface elements enabled which should be initially disabled; | |||
### are there buttons that aren't self-explanatory; | |||
### are buttons positioned well; | |||
### is the formatting of the data good and helpful; | |||
### etc. | |||
## Some screens in Petra 2.3 were done in a way that was technically easy to do, but this often resulted in a screen that was more confusing and 'technical' for new users than it needs to be ('the DB design bleeds through to the GUI'). Try to avoid that in OpenPetra! | |||
## 'Mover Dialogs' that feature buttons for moving items from one list to another are perceived more complex by the average user - usability research has shown that. Avoid those in OpenPetra (in many cases a Grid with CheckBoxes in the first column can be substituted for such a functionality and that is easier to program, too). | |||
## If you are in doubt about whether to stick to the Petra 2.3 screen layout or to create a new layout, or if you are not sure how it should be done differently, consult another experienced OpenPetra developer. | |||
# Create a YAML file for the new screen. There is a very good long description for this in [[How-To: Creating a Maintain Table screen]]. | |||
## The YAML files reference Templates (located in [projectroot]\inc\template\src\Winforms) and you have to find out which is the right Template for the ported screen. Ask yourself... | |||
### will the new screen be a Window, a Dialog, or will it be embedded in an other window (=UserControl)? | |||
### does it need to contain a Grid? | |||
#### if so, will it need to contain an additional Details Panel? | |||
### is the underlying DataTable part of a larger Typed DataSet or is it used on its own? | |||
## Consult another experienced OpenPetra developer if you are unsure which Template to use! | |||
## After the decision for the right template, find a screen where this template is already used and copy its YAML file and its *.ManualCode.cs file to the location in the file system where your new screen needs to be located. (The *.ManualCode.cs file is needed nearly always). Adopt the copied files to your purposes. | |||
### Again, consult another experienced OpenPetra developer if you run into trouble with the new screen as some hurdles are easier to overcome that one might think - that is, if one already knows about them! |
Revision as of 09:06, 14 February 2013
Old screen
- Start Petra 2.3 (perhaps in a virtual machine).
- Make a screenshot of the screen you are going to port to OpenPetra. Copy the screenshot into a word document or into a graphics processing program and save it.
- If the screen contains a Table, scroll the Table to the right and make several screenshots in order to capture the headers of all columns and the format of the data of all the columns (e.g. bool, decimal, text, date).
- Try to operate the screen and to perform the obvious actions that it offers (eg. add a record, edit a record, delete a record). Use the Petra User Guide for the Module in which the screen is located to get the instructions that a user is presented with for this screen. Try to get a 'feel' for how the screen operates, how it accepts and rejects data, the options it presents to the user and what - if anything - is special about that screen.
- Also check the menus for any special menu items that are not normally present in screens like the one in question and note them down.
- If the screen opens other screens (Forms or Dialogs) as a result of an action of the user make screenshots of those screens as well as you will need to port those too if they don't already exist in OpenPetra.
- Finally, open Menu Help->About Petra. In the dialog that opens you can find the name of the 4GL program for the screen. Note this down as you will need this in order to open that 4GL file to read through the full screen logic (i.e. if values of Labels or TextBoxes are calculated, to check if the program has some extraordinary behaviour that isn't obvious from operating the screen, how the screen validates its values, or how the screen is set up or parametrised). You will also need to do this for any detail screen(s) and other screens that are opened from this screen and which don't already exist in OpenPetra.
- In theory you could now close Petra 2.3 (and the virtual machine) and start to think about the development of the new screen. However, in practice you will want to keep them open to see how the user interaction with the screen works out in detail and how the screen's program code is reflected in the behaviour of the screen.
New Screen
- Compared to Petra we have vastly different capabilities for layout and screen design in OpenPetra!
- We can have much larger screens!
- In general we should aim for a screen to work well on a 1024x768 resolution (it really needs to work on a 800x600 resolution!), that is to make sure that the user is not forced to scroll through the screen on such resolutions for the normal operation of the screen.
- In OpenPetra the screens should hardly ever be fixed in size (in Petra they were often fixed to 640x480!) and thus the user can make them larger, and we can and should make use of that for improving the layout of the screen.
- OpenPetra screens can contain Tabs and UserControls.
- Whereas in Petra there was often a combination of a 'Browse' and an 'Edit' screen, in OpenPetra we have reduced that to one screen for such purposes. Such an OpenPetra screen contains both the Table ('Browse') and the Details ('Edit') (in the Grid and Details Panels, respectively).
- We can have much larger screens!
(Re-)Design decisions
- Ask yourself the question how usable the Petra 2.3 screen was and if it can perhaps be done better in OpenPetra by using a different approach. The focus should be on usability and on reducing the 'clicks' and other operations such as keyboard strokes or scrolling that are needed to perform a certain functionality in that screen.
- Put yourself in the position of a new OpenPetra user that will open the new screen in question for the first time and ask yourself:
- is everything logically arranged;
- should some user interface elements be grouped into GroupBoxes for clarity;
- is there something that could be confusing or that will need explanation;
- are the Labels descriptive and not technical;
- are user interface elements enabled which should be initially disabled;
- are there buttons that aren't self-explanatory;
- are buttons positioned well;
- is the formatting of the data good and helpful;
- etc.
- Some screens in Petra 2.3 were done in a way that was technically easy to do, but this often resulted in a screen that was more confusing and 'technical' for new users than it needs to be ('the DB design bleeds through to the GUI'). Try to avoid that in OpenPetra!
- 'Mover Dialogs' that feature buttons for moving items from one list to another are perceived more complex by the average user - usability research has shown that. Avoid those in OpenPetra (in many cases a Grid with CheckBoxes in the first column can be substituted for such a functionality and that is easier to program, too).
- If you are in doubt about whether to stick to the Petra 2.3 screen layout or to create a new layout, or if you are not sure how it should be done differently, consult another experienced OpenPetra developer.
- Put yourself in the position of a new OpenPetra user that will open the new screen in question for the first time and ask yourself:
- Create a YAML file for the new screen. There is a very good long description for this in How-To: Creating a Maintain Table screen.
- The YAML files reference Templates (located in [projectroot]\inc\template\src\Winforms) and you have to find out which is the right Template for the ported screen. Ask yourself...
- will the new screen be a Window, a Dialog, or will it be embedded in an other window (=UserControl)?
- does it need to contain a Grid?
- if so, will it need to contain an additional Details Panel?
- is the underlying DataTable part of a larger Typed DataSet or is it used on its own?
- Consult another experienced OpenPetra developer if you are unsure which Template to use!
- After the decision for the right template, find a screen where this template is already used and copy its YAML file and its *.ManualCode.cs file to the location in the file system where your new screen needs to be located. (The *.ManualCode.cs file is needed nearly always). Adopt the copied files to your purposes.
- Again, consult another experienced OpenPetra developer if you run into trouble with the new screen as some hurdles are easier to overcome that one might think - that is, if one already knows about them!
- The YAML files reference Templates (located in [projectroot]\inc\template\src\Winforms) and you have to find out which is the right Template for the ported screen. Ask yourself...