Developers have a much deeper understanding of systems and at times, that can really hurt them. We know quite often that a limitation is stupid. Either something is broken in the code and nobody wants to fix it, or business simply doesn't understand what makes sense to do.

Either way, this history functionality is still a feature. And if you explain it in a marketing sense, now you can view up to ten records at once! How many history records could the user view at once before? One? Zero?

Either way, make sure to show them this information as robustly as possible. Make them feel like 10 is a lot, because it actually is. Remember, the mind can't process more than 3-5 things at a time. 10 is an automatic overload if it all pops up at once.

So, you can do a number of things:

1. Create a button that "activates" history mode, and then display some text above your data-table saying "Select Up to 10 Records" and disable all other rows once ten items are selected.
2. Only allow 10 records to display per page (kinda annoying solution, but a solution nonetheless).
3. Have the history button show how many more records can be selected in the label, then have it count down to zero until the limit is exceeded, in which it becomes disabled.

If you feel the users of your app will definitely need more than 10 and you want to get around this limit, you can be crafty and do one of the following:

1. Allow them to open up your software in more than one window or tab.
2. Have each history record open in its own window or tab.
3. Have them go back and forth easily where opening up sets of ten becomes really simple. Maybe create a queue where the user can select more than 10, but only view 10 at a time.

Also, you might want to think about how you present your controls in the list. GoodUI's 19th rule could come in handy here: Try Direct Manipulation. Have your controls scoped to the item you wish to interface with. If you want to select multiple items, you can still allow the checkboxes, but keep the controls within or near what they're controlling.

A good example of this can be found in the WordPress backend. Controls for a particular item in a list are visible only when it's hovered over, but the ability to make a series of edits are still available either way.

Developers have a much deeper understanding of systems and, at times, that can really hurt them. We know quite often that a limitation is stupid. Either something is broken in the code and nobody wants to fix it, or business makes arbitrary rules or guidelines in absences of any true understanding of how software actually works.

Either way, this history functionality is still a feature. And if you explain it in a marketing sense, now you can view up to ten records at once! How many history records could the user view at once before? One? Zero?

Either way, make sure to show them this information as robustly as possible. Make them feel like 10 is a lot, because it actually is. Remember, the mind can't process more than 3-5 things at a time. 10 is an automatic overload if it all pops up at once.

So, you can do a number of things:

1. Create a button that "activates" history mode, and then display some text above your data-table saying "Select Up to 10 Records" and disable all other rows once ten items are selected.
2. Only allow 10 records to display per page (kinda annoying solution, but a solution nonetheless).
3. Have the history button show how many more records can be selected in the label, then have it count down to zero until the limit is exceeded, in which it becomes disabled.

If you feel the users of your app will definitely need more than 10 and you want to get around this limit, you can be crafty and do one of the following:

1. Allow them to open up your software in more than one window or tab.
2. Have each history record open in its own window or tab.
3. Have them go back and forth easily where opening up sets of ten becomes really simple. Maybe create a queue where the user can select more than 10, but only view 10 at a time.

Also, you might want to think about how you present your controls in the list. GoodUI's 19th rule could come in handy here: Try Direct Manipulation. Have your controls scoped to the item you wish to interface with. If you want to select multiple items, you can still allow the checkboxes, but keep the controls within or near what they're controlling.

A good example of this can be found in the WordPress backend. Controls for a particular item in a list are visible only when it's hovered over, but the ability to make a series of edits are still available either way.

Developers have a much deeper understanding of systems and at times, that can really hurt them. We know quite often that a limitation is stupid. Either something is broken in the code and nobody wants to fix it, or business simply doesn't understand what makes sense to do.

Either way, this history functionality is still a feature. And if you explain it in a marketing sense, now you can view up to ten records at once! How many history records could the user view at once before? One?

If you feel the users of your app will definitely need more than 10, (1) allow them to open up your software in more than one tab, (2) have each history record open in its own tab, or (3) have them go back and forth easily. Show them this information as robustly as possible. Make them feel like 10 is a lot, because it actually is.

Also, you might want to think about how you present your controls in the list. GoodUI's 19th rule could come in handy here: Try Direct Manipulation. Have your controls scoped to the item you wish to interface with. If you want to select multiple items, you can still allow the checkboxes, but keep the controls within or near what they're controlling.

A good example of this can be found in the WordPress backend. Controls for a particular item in a list are visible only when it's hovered over, but the ability to make a series of edits are still available either way.

Developers have a much deeper understanding of systems and at times, that can really hurt them. We know quite often that a limitation is stupid. Either something is broken in the code and nobody wants to fix it, or business simply doesn't understand what makes sense to do.

Either way, this history functionality is still a feature. And if you explain it in a marketing sense, now you can view up to ten records at once! How many history records could the user view at once before? One? Zero?

Either way, make sure to show them this information as robustly as possible. Make them feel like 10 is a lot, because it actually is. Remember, the mind can't process more than 3-5 things at a time. 10 is an automatic overload if it all pops up at once.

So, you can do a number of things:

1. Create a button that "activates" history mode, and then display some text above your data-table saying "Select Up to 10 Records" and disable all other rows once ten items are selected.
2. Only allow 10 records to display per page (kinda annoying solution, but a solution nonetheless).
3. Have the history button show how many more records can be selected in the label, then have it count down to zero until the limit is exceeded, in which it becomes disabled.

If you feel the users of your app will definitely need more than 10 and you want to get around this limit, you can be crafty and do one of the following:

1. Allow them to open up your software in more than one window or tab.
2. Have each history record open in its own window or tab.
3. Have them go back and forth easily where opening up sets of ten becomes really simple. Maybe create a queue where the user can select more than 10, but only view 10 at a time.

Also, you might want to think about how you present your controls in the list. GoodUI's 19th rule could come in handy here: Try Direct Manipulation. Have your controls scoped to the item you wish to interface with. If you want to select multiple items, you can still allow the checkboxes, but keep the controls within or near what they're controlling.

A good example of this can be found in the WordPress backend. Controls for a particular item in a list are visible only when it's hovered over, but the ability to make a series of edits are still available either way.