Displaying of entities with many attributes

Displaying of entities with many attributes

  
Hello!

Apologies for this question, must have been asked many times before, but a search not showing anything that helps.

I have several screens where I am displaying the records of entities which have many attributes (over 20) in a Table Records widget, so each record is shown horizontally.

The trouble in displaying an entity with many attributes, is that the browser becomes wider to accommodate the extra width required, and one requires to scroll to the right to see all the data. The issue with this, is that my right hand column disappears off the screen and the user requires to scroll right to view it. The horizontal menu doesn't look too great either.

To resolve this, I would like my browser width to remain the same (i.e. no scroll bars), but the table records data to be within an internal scrollable window.

Is an iFrame the best way to do this, with the scr defined as the url of another screen, which is blank other than showing the results of the Table Records? Or is there a better way of doing this (i.e. in one screen without having to consume s/w units using two screens)?

Thank you,
Mark
Hi Mark, 
 
Lets forget the tech solution and focus on the relevant...
 
Who is going to look for a table record with dozens or hundreds of records with more then 20 attributes each record? What will the user can see? and will he be able to find what he is really looking for? I believe not.  
 
My suggestion to solve that issue is that you take a look at Tiago Simões presentation in the last Next Setps event available to download here .

Hope it help.

Cheers, 
RNA

Hello Mark,

There are several solution possible, but I go with Ricardo: is it really needed to show everything?

If you want to keep it in the screen, give your table a fixed width (in pixels and apply the style: table-layout: fixed).
You can also show the most important info in the table and use an info popup ballon to see the rest of the information.

Kind regards,
Evert

Hi Ricardo,

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"

Cheers,
Mark

you can use clienttabs for dividing the interesting parts in categories.

if it's numerical data, why not show it in a graph?

Mark,

Looking at the purpose of feature, I would suggest something like a step by step validation process and you could use Joost suggestion, use clienttabs for dividing the interesting parts in categories, and at the end of each tab have a button saying "validate and continue to the next step" and have another saying "Complete validation".

The information  should be grouped in each tab by the most important and relevant data to the Validator and this should improve the business process focusing on the key details of the report.

Cheers, 
RNA 

Small note: We're now entering in a different level of discussions in this forum, which is great. We're starting to discussing what is relevant for the success of our apps and not lock in tech specifications, and that is so cool!!! 

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.

Cheers,
Mark
 

@ Mark

Side-stepping the usability discussion, where I fully agree that you should try to reduce the amount of information on each screen as much as possible, you should be able to achieve a scrollable table using CSS alone.

Check out this sample: http://www.imaputz.com/cssStuff/bigFourVersion.html
Pedro,

Brilliant, thank you for that! Never crossed my mind that it might be achievable in a CSS.

Although your link did not show a scrollable window on my browser, IE9, I did follow your direction and found many other sites with similar outputs.
Amazing what you can do with style sheets alone, though it appears this will need testing across numerous browsers!

Will give it a go, and I will pay heed to all the advice on UIs and information presentation!

Cheers,
Mark
@Mark simple answer about scrolling: scrolling sucks :)

anyhow, about the info. I'm not sure what you meant by "validating", are the numbers compared to something else? if so what?
is there a threshold for values which should be marked red for example, and if they are below it should be green?
do the columns have a relation which other? or even the rows....

the reason I ask this is, I am wondering if the data cannot be represented in barcharts for example. (or line-charts, or even a funnel chart)


Hi Joost,

Okay, thank you, scrolling sucks. I agree, and there are other possibilities to present the data.

In the case of displaying many attributes or content (horizontally or vertically), the browser becomes a scrollable screen.
My thinking was that an internal scrollable window was less of an evil than having to scroll the browser, which results in menus and other information disappearing from view and even changing the spacing between items. Ideally, the screen should be constant and only the content in the middle should change.

If we look at any desk top application, Service Studio is a good example, all the menu pains remain in view, however, the main content pain is scrollable as is the right hand pain (v6 much better than v5 in this respect). This is common not just for IDEs, but apps such as Word or Excel. Indeed, I am far from happy with the way my app currently looks. It has the look and feel of a web site, banners, menu bars etc., whereas it should have the look and feel of a desktop app. But I will work on this!

Regarding 'validating,' my understanding of Ricardo's point, is where the user is presented a screen which confirms back to the user what they have just entered and offer them the opportunity to make corrections. In the same way, the two screen shots are just that, but validating several records at a time (several rows). If the user is happy with the information entered, they identify the state of completion of this section (Not complete (default), Partially Complete (user may want to revisit as they don't have all data available), and Complete).

These screens are within the analysis phase of the app, so there is no judgement to be made on threshholds, constraints, levels, comparisons etc. It is purely raw data obtained from analysis and interviews from departmental heads within the organsiation. They simply capture resource requirements over time required by a department in the event of an incident which denies them access to their assets.

How might one redesign Service Studio to eliminate all scrolling? The Process | Interface | Logic | Data tabs have done a huge amount to reduce scrolling (as well as making it more intuitive to new users), but the main content pain is still scrollable.

Infact, I would be happy for the browser to scroll, so long as the top menus and left & right hand columns remained static!

Cheers
Mark
Well,

I have to disagree with you there.

the right part of service studio is scrollable because there is not really a relation between every node, so there is no harm done when you don't see certain stuff.

the main content part is a different issue.
if you have to scroll, you have to rethink why you need to scroll. actions can  and should be divided so you can see in 1 splitsecond what the action does.
with screens it's slightly different, but you can use webblocks and "preview" attribute to reduce scroll in there.
ofcourse this is my opinion and it goes a long way.
it's basically inherited from my c#-past where I just hated methods/functions which were larger than my screen. you simply lose the notion of what that function really does. Exception do apply ofcourse.

That's why I say bluntly that scrolling sucks, because people forget about what is invisble. (and I am not talking about the menus)