Currently I have a data structure in the form of a tree view. Eg.

enter image description here

Right now I am using a collapsible accordion view to show each field to input data.

Scenario - I have about up to about 1000 fields and up to a depth of about 11 levels deep, but mostly about 30 fields on average to fill in, and because it is dynamic and optional, it can go up to a 1000 fields (worst case scenario) depending on requirements / scenario selected. Basically it is a loan processing system, so a lot of information is required by certain banks, and this is a dynamic form generator, with CONTEXT built using the parent node.

It is mainly used for validation, say I chose the wrong country code, I need to show the validation error and I need to know that it belongs to Customer John, not the address for Customer Mary etc... I need a good way to show CONTEXT. There can be complicated scenario like Customer John can have 2 addresses as well etc...

I am currently showing everything, up to a 1000 fields depending on what went wrong, as I cannot think of a better way to show the context, but it is causing performance issues in Angular UI binding / rendering when too many fields are shown at once.

Any advice would be much appreciated, in terms of UX and design alternatives.

  • Can you add a screenshot of how you are showing it currently? It is hard to visualize the use of tree for this kind of information, especially as you have mentioned accordion.
    – Harshal
    Commented Mar 10, 2015 at 12:38
  • Something like that 4.bp.blogspot.com/-61rWZzrJ8RA/UIC_JsnP5JI/AAAAAAAACEM/…
    – Joshscorp
    Commented Mar 10, 2015 at 13:18
  • is it a touch interface, mouse-driver, or both?
    – Dvir Adler
    Commented Mar 10, 2015 at 15:35
  • also, do you validate the data on the fly (in-line) or when the user clicks "submit" or "validate"?
    – Dvir Adler
    Commented Mar 10, 2015 at 15:37
  • Sounds like a good case for breadcrumbs & dropdowns on desktop (like every other address-picker), or a navigation stack of editable tableviews (mobile) instead of nesting & displaying everything. That would help w/performance issues. A tree option to visualize maybe 2 levels at most might be helpful. Showing everything would be overwhelming & unnecessary - only show what's relevant to the error or current field & a parent node or 2 to help locate it. ...Perhaps in miniature like the tiny document view panel in Sublime Text? Also, 2nd the call for inline validation vs. waiting for "submit"
    – mc01
    Commented Mar 10, 2015 at 16:00

2 Answers 2


If you really, really, really have to use a tree view with hundreds of nodes, then it needs to be just that: a very basic tree view and absolutely nothing more.

Sometimes this situation is unavoidable. A tree view is often used for expert users who want to be able to navigate a complex hierarchy quickly, without waiting for page reloads.

In this scenario, I would urge you not to use the accordion. You are overloading the already-complex tree view with even more complexity.

One alternative is to use the tree for navigation, and include a workspace for viewing and editing nodes. A good example is the Microsoft Registry Editor, a tool for expert users to navigate a complex hierarchy of system settings for Windows:


The tree appears on the left, and the node editor is the right panel. If you have warnings associated with particular nodes, you can place an icon (e.g. !) next to the important nodes.

I'd further recommend:

  • Add a searchbox with auto-complete to help users find nodes quickly.
  • If you are asking users to process a queue of erroneous nodes, then add a panel on top with the failing nodes. Clicking on the node navigates to the correct tree node so the user can take action. This allows users to process the queue in a straightforward workflow without having to scroll a gigantic tree.

I may not solve your problem with the following approach, but I am fairly certain that the current implementation is overwhelming to the user. It adds a lot of performance issues. It is also hard to comprehend if I want to have a look at more data in one go.

Let us start with 80:20 rule.

When I design something, I generally make sure that my solutions perfectly fits 80% of my users or 80% of their requirements. Although I do not ignore the remaining 20%, I try to provide workarounds or alternatives to meet their needs without significantly impacting the streamlined system built considering the 80%. In other words, I tend to design for probabilities and not possibilities. This pretty much answers your worst case scenario of 1000 fields at one point on UI. Definitely 1000 fields will create multiple bindings on Angular and would be a huge performance hit too.

Establish an Information Architecture or Hierarchy.

Naturally, it is not necessary to replicate your data structure on the UI. I would try to segregate the possible 1000 fields into categories. I would try to find common traits between them and group them accordingly. This will provide my first level of filtering. I will bring the fields to manageable set and probably show those in editable grid (say, contact information). I am not sure in your case, but generally your core data which you manipulate and edit has a lot of attributes and modifiers which help you enrich the data, but you can drill down to your absolute core. I just took an example of contact information.

A User Roles System

As you mentioned that there would be 1000 fields which you need to act upon. I have a gut feeling that not all 1000 would be editable for all the type of users, all the time. An effective user role management will help you segregate the responsibilities and design the Information Architecture better for each user role.

View Options

Also, based on the Information Architecture, you can come up with sets of views with which you want to present the same data. With this approach you can still allow editing of all the fields without the performance hit. For example in a loan processing systems, a user might be interested in working on contact addresses management, a contact EMIs and finances management, various branches and nodal offices management etc. These and many other views will have specific fields grouped together offering your users a way to maintain context and work on smaller chunks of data at a time. This should help improving the overall performance too.

Strong Search

You could augment the system by providing an advanced search using the knowledge of dependencies between various fields. This will help user to get a manageable data set to work with at any point of time.

My suggestions may not solve your specific problem, but all of them have a common trait. I am trying to classify your data to make it less overwhelming to the user, and less taxing on the system. I am sorry if I am way off mark, but if you can explain your system more in comments, I might be able to edit this answer later.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.