Thank you for your reply and appreciated the link for the design impaired, which includes myself! Very useful.
In this case, the user will never have 100s, let alone 1000's of records to browse through. At the most, there might be a few dozen, broken down by business function, so each list might have at the most 10 or so lines. And yes, that is still over 200 bits of discrete data. However, some fields will be blank and most of the column data is segmented by time intervals, to produce in one instance, a resource recovery table.
The purpose of viewing this information, is primarily for checking outputs and enabling corrections or modifications to be made, prior to producing a much larger report (printed), which deals with the analysis phase of the project.
Infact, putting the data into such an internal scrollable window, gives a greater priority to the consistency of the screen design, providing a view that does not change based upon how many columns are to be displayed. The user has the option to scroll with such a window, but in the current case, the user has no option, and is forced to scroll if they want to see the right hand column, which contains guidance notes.
Hope this answers your question and allays your concern of a screen comprising 10s of thousands bits of data!
How might you approach this, and I take on board as well, "wait costs"
Grrr, just spent an hour typing a reply and lost it all! Teach me to copy / paste to notepad more often!
Evert, Joost, Ricardo,
Thank you for your replies.
Here is an example table:
Ref (SmallInt) | Business Area (Char50) | Business Function (Char50) | Critical Activity (Char50) | Impact Measured (Char200) | 1hr (SmallInt) | 2 hrs| 4 hrs | 6 hrs| 24 hrs | 48 hrs | 3 Dys | 1 Wk | 10 Dys | 2 Wks | 3 Wks | 4 Wks | MTPD | RTO | Notes Char(2000)
For ease of visualisation I have attached two screen shots, one showing an abbreviated version of the above.
Some notes on the screen shots.
1. I decided to lose the left hand menu to free up screen equity. Happy with this, as this is not a focus of these screens. Also, further equity could be released by losing the first two columns and making them into section titles instead.
2. The tables are fixed width. Whilst that keeps my browser the same size, it presents challenges on displaying the text fields, especially the Notes column. Evert, thank you for your suggestion. I will give some more thought on using popups. Furthermore, on producing reports to fit on A4 paper, I can reduce the font, however, I would rather not do that on screen. Also, if the time columns became text fields, we would face even greater challenges!
3. Please excuse the test data, just coding to test that everything ends up in the right place!
Joost, thank you for your suggestion of using tabs. This will definitely help on some other tables. Not sure if tabs will help in this table however, and would take away the ability of the user to have an overview of the table. If anything could be tabbed, then 'Notes' would be the most likely candidate. The information gathering and display has already been 'chunked' into manageable and common themed sections. For example, there are a number of resource recovery tables, for workspaces, communications, etc. Hence each table will unlikely exceed 10 rows for each business function.
Ricardo, yes there are many validation points. In fairness they are more completion points, which are all viewable on a dash board. The Recovery Table is in itself a validation point, which would be 'signed off' on completion. Is it possible to break it down further? Everything up to and including Impact Measured has already been validated before this screen, but they are still required for display, as it against these headings we are measuring recovery times or resource requirements.
Regarding your note, I agree. For myself, I have spent the last two months learning the technology. Now that I am more familiar and confident with it (though still have lots to learn), my thoughts (at least 90%) are very much on useability and the end user, and not the technology battles :)
Another thought is to use grouping, in the same ways as one can group columns and rows in Excel, which can be expanded or collapsed. Not wanting to bring up technology, but I sense that the advise is to avoid using iFrames, or at least an internal scrollable window? Is there a reason for this (other than that being part of my original question)?
Thank you for your thoughts and suggestions.