Different views in table - omit column without relevance?

Question

In a user interface, I am showing a table with a list of broken links and their context. It is possible to select the depth of the pages, based on the current page. For example you can show all broken links on the current page or on the current page and all direct subpages (level 1) etc. up to "infinite".

The result looks like this:

• column 1: Page, the button opens a layout view
• column 2: Element on page, the pencil button opens an edit form
• column 3: Element and Field Type
• column 4: last checked
• column 5: URL, buttons to recheck the URL and exclude the URL from checking
• column 6: type of error message

So, for every broken link we are showing the context, in which element it exists and on which page.

This is actually hierarchical information:

- page
  |
  -> language
      | 
      -> content element
         |
         -> field
            |
            -> broken link 
            -> broken link

The content elements are all attached to one page and one language. There are several fields in the content elements, where links can exist. Broken links can also exist directly in a page (e.g. if of type "shortcut"). That is why the Type (column 3) is also included.

A "flat" table view is used so that the table can be sorted by any column.

The problem currently: the table looks a bit cluttered and visually distracting. I already minimized the output, but I would like to minimize it even more - as much as possible.

My question: Is it a good idea to omit the first column "page" if the user selects a depth "current page".

because for "current page" only, the left column "page" is irrelevant. The same page title would just repeat itself and the user already has the information which page he is on.

However, this would result in different output (and position of other columns moving around) depending on the selection of the depth. This might confuse users.

---

In any case, I am currently not very happy with this list. It has been proven useful for the task at hand but I assume there are still several optimizations that could be made (especially to simplify and make it more intuitive). I am trying to break this down into individual optimizations but I realize it might be a good idea to look at this on a more general level and rethink what output is necessary and in which form.

Answer 1

This might not answer the question directly, but hopefully it will help you think about what the solution should look like.

Without an appreciation for how you got to the current design, I think it is important to consider whether there is a clear relationship between the way that the data is structured (i.e. the levels of hierarchy and the depth of navigation required to get the each node). You are always going find that certain people will find it harder to find the information they need if you have a single structured view of the data, and you are trying to use it to cater for many different use cases.

A very basic example is the difference between a list view and a card view. In a simple list view you basically have a linear list of elements that is traversed in one way only. You can increase the complexity by having a table, which can be read linearly but also across the columns. You can then create tables that have nested rows or columns, which is similar to a card in that information relating to a single line item or element is grouped but not arranged linearly (but often in a grid that can't be easily sorted).

So your question:

Is it a good idea to omit the first column "page" if the user selects a depth "current page".

Will have a different answer depending on whether it is still possible for the user to understand the context within the existing or current use case. Then you also have to consider whether changing the structure and hierarchy of how the data is presented will lead to some potential confusion to the users (as you pointed out).

But there isn't a right or wrong answer here as long as there is a logical connection that can be understood by the end-user. Otherwise you will get into a tricky issue of customizing the design to show information in lots of different ways depending on the context, which you can avoid by having a sound underlying IA and structure that you can progressively disclose or hide if it is not necessary.