Here are some criteria you might consider as you select a Table control:

1) Table Format

• is the resultant HTML formatting important. For example, do you want the resultant HTML to be a bunch of div’s or table tags

2) Performance

• what level of performance is acceptable (data retrieval, rendering, paging, filtering, etc.)
• does the table have to be performant on tablet devices, how about smart phones
• does it have to be performant on older devices or the latest browsers, IOS, and Android releases

3) Browser Support

• IE
• FF
• Chrome
• Safari
• Opera
• Tablet devices
• Smart phones

4) As a Table changes size, what should happen to the table width, scroll bars, and columns?

• table has fixed width, potentially requiring horizontal scrolling
• table has fixed width with internal table scrolling
• table has a dynamic width, where columns shrink/expand as necessary
• table has a dynamic width, where columns are added/removed as necessary
  

  if a table is defined with 5 columns in full width mode, as the dimensions of the display get smaller, perhaps from landscape to portrait display, or from being viewed on a smaller device, some of the columns might simply be removed, leaving only the most important ones to take up the remaining limited display.

• table has a dynamic width, where column widths shrink proportionally until it becomes ridiculous, then low priority columns hide altogether

5) What type of row height control is sufficient?

• table must support variable rows height
• rows must be fixed height, but each table can be defined to have its own row height
• rows must be fixed height, and all tables must support that one height

6) What level of support should the table widget provide for expanding or collapsing a row to show additional details?

NOTE: in answering this question, consider tooltips, in-line text, help systems, object view dialogs, multi-line cells, etc.

7) Column Widths

• should columns be user sizeable
• should columns be code sizeable
• fixed-width columns (may not fully fill table width, or may exceed it)
• %-width columns (all columns together fill the table width)
• both fixed width, and %-width columns

8) What properties of the row object should the Column Model support for display purposes?

• Should it show all properties automatically (do you intend to give it an array of properties)
• Should the column model allow the programmer to select a sub-set (most likely used with an Object type)

9) Similar to question #8, what properties of the row object should the remote call fetch?

• return only specified properties
• return all object properties
• return all object properties and a set of other details needed by the UI

10) Should the column model be type aware (numbers, text, dates, enums, localization, etc.) ?

11) Should the column model support hidden columns?

• hidden columns might permit the user to show addl fields as needed
• hidden columns require more time to fetch and render

12) How much data can a single cell contain/show?

• each cell represents 1 property from backing object
• each cell can contain any number of properties from the backing object
• cells can contain no properties at all from the backing object. Rather, buttons, images, addl non-object data

13) From where does a table get its data?

• table can be created using a local data source (internal javascript array)
• table can be created using a remote data source (REST or RPC call)
• perhaps the table contains both remote data and subsequently UI-added data

14) What type of paging should the table employ?

• list is fully loaded into a single table; the table is fully shown; lots of scrolling
• list is fully loaded into a single table; but the table is shown as paginated with limited scrolling. No addl calls are made to the back-end
• list loads one page at a time; moving from one page to another flushes prior pages to preserve memory; returning to a page refetches from the back-end.
• list loads one page at a time; pages are cached; moving from one page to another reuses cached pages w/o making new calls to the backend.

15) When, if ever, should the table should show scroll bars?

• table has unlimited height; no table scroll bar; page has a large vertical scroll bar as needed.
• table has a fixed height; but only allows scrolling one page at a time (you can see 25 items; but can scroll the current page: 1 to 100)
• table has a fixed height; and allows scrolling of the entire list; the scrolling action itself loads the pages as needed.

16) What is the best method for a user to move from one page to another?

• No need for any navigation control since the best choice is for the list to fully load
• table has a navigational tool bar at top or bottom of the list showing next, previous, top, bottom, page #, etc. controls
• table has no need for a navigational tool bar; The scroll bar is all you need

17) On what data should sorting be allowed?

• table cannot be sorted:
• table can be sorted one column
• table can be sorted on any property (even if not in a column)
• table can be sorted on multiple columns
• table can be sorted on multiple properties (whether in, or not within, a column definition)

18) Which component performs the sort?

• all sorting is handled by the server
• if paging via nav bar, sorting is handled locally on the currently showing page
• if paging via scroll bar, sorting is handled by the server until all pages have been loaded, then sorted locally w/o making addl calls

19) How should sorting be handled for special data types? enums, dates, dev strings, numbers, etc.

For example, for an Enum type (ENUMType.BS), should the sort be on the raw Enum or the visual text for that Enum (“Business
Service”)

• sorting is performed on the raw data type. This could cause some unusual sorting, but related items would be grouped together.
• sorting is performed based on what the user “sees” rather than data type. While very natural for the user, this is very difficult to implement when sorting on the server.

20) How should the sorting of words with numbers be handled?

• sorting is alphabetic/ASCII-based (1, 10, 100, 2, 3)
• sorting is alphanumeric ( 1,2, 3, …10, 100)

21) How should the sorting of null or empty values be handled?

• sorting places null or empty values before “A”
• sorting places null or empty values after “Z”
• sorting of null or empty values should remove those items from the list

22) How should character case affect sorting?

• sorting is case sensitive (A-Z, a-z)
• sorting is case insensitive (Aa, Zz)

23) What level of support should the table provide for “filtered” results?

Keep in mind that some cells in a table may show multiple properties/fields.

• table cannot be filtered
• table can be filtered on 1 column at a time
• table can be filtered on any set of specified columns
• table can be filtered on any set of specified fields if columns supports showing multiple fields in a single cell

24) How should the table “filter” special types of data? Enums, Dates, Numbers, localized strings, etc.

For example, for an Enum type (ENUMType.BS), should users enter the raw Enum or the visual text for that Enum (“Business Service”)

Consider this question in isolation of the similar sorting question

• filtering is performed on raw data type (enum, date, dev strings, etc.)
• filtering is performed based on what the user “sees” rather than data type (“Business Service” instead of ENUMType.BS). The UI will have to convert user-entered localized strings into DB types, or the DB will have to include all localized strings for all enums.

25) Which component performs the filtering?

• all filtering is handled by the server
• if paging via nav bar, filtering is handled locally on the currently showing page
• if paging via scroll bar, filtering is handled by the server until all pages have been loaded, then filtered locally w/o addl calls

26) What level of support should the table widget provide for “searching”?

Searching is similar to “filtering”. While “filtering” removes all unwanted items except those that match the search criteria, “Searching” keeps all the records as is, but simply highlights/selects those that match the search criteria.

Same questions for Searching as for Sorting…

27) What level of support should the table widget provide for rendering the data?

• cells are rendered using ONLY the text from the provided property
• cells are rendered with a method per column definition potentially allowing the override/conversion of a property value
• cells are rendered using templates (preferably pre-compiled templates)
• cells are rendered using all 3 methods above

28) How will the user perform actions on the given row object?

• Actions should appear at the top of the list. Users should select one or more rows, then select an action.
• Actions should appear on each row on hover (desktop) or on selection (mobile). The row actions affect only the current row object.
• Actions should appear only when drilling into a row object, on the object viewer.

29) Table Communications Architecture

• The table is provided with raw HTML which quickly builds each page of data (lightening fast!)
• The table is provided with an array of arrays (raw list of unnamed properties)
• The table is provided with an array of objects (self describing format)

30) What level of support should the table widget provide for theming?

• table uses its own built-in styling
• table exposes its style sheet which can be modified
• table permits specifying what styles to use for each element
• table supports JQuery’s ThemeRoller
• table supports JQuery Mobile’s ThemeRoller

31) How many rows are selectable?

• table does not need to support row selection
• only 1 row should be selectable at a time
• multiple rows can be selected at a time
• 1 page of rows may be selected at a time
• table supports “select all”

32) How does a user “select” a row?

• table permits row selection by clicking/pressing on a row
• table permits row selection by double-clicking on a row
• table permits row selection by long-pressing on a row
• table permits row selection by clicking a checkbox (clicking on row elsewhere drills into row object viewer)
• table permits row selection by first enabling the “selection” mode, then clicking on the row/checkbox

33) What level of support should the table widget have for JQuery?

• JQuery support is not required for the table widget
• table must be a JQuery plugin
• table must be a JQuery Mobile plugin

34) How important is it who created the table widget?

• table must be part of a well established library
• table must be proven technology, but not part of a library
• table should be created, well documented, and actively supported by someone else
• table can be home-grown

35) Should the table widget provide support for in-table/row/cell editing?

36) Should the table widget provide cursor support (the ability to focus and move between individual cells with the keyboard)?

37) Should the table widget provide an export feature? In what formats?

38) When should a table edits be committed?

• Stored locally vs stored remotely
• Committed immediately after editing vs. a formal commit phase
• Should “undo” support be provided for table edits?

39) In what format should the table’s CSS and JS be delivered to the client?

• Uncompressed
• Minified
• GZip’d
• All of the above

40) How important is the size of the table widget’s code? The size includes any HTML, CSS, and JavaScript required to use the table
widget.

Consider your answer in the previous question as you consider the size for this question.

Consider that web apps for mobile devices can be dynamically downloaded using normal Web protocols or can be part of the normal app install process

• Code size does not matter
• 30K
• 200K
• 1MB

41) What level of support should this table widget provide for alternative views?

For example: List, Details, Large Icon, Icon, Dots, etc.

• the table does not need to support alternate views
• the table should support 1 list and 1 iconic view
• the table should support multiple views of the backing list data

42) Consider the relative importance of various features?

• Performance
• Sorting
• Filtering
• Searching
• Device Support
• JQuery Support
• In-Row Editing
• Who created it
• Paging
• Scrolling
• Navigation
• Selection
• View As…
• Column Model
• Established Library
• Code Size
• Theming
• Row expansion
• Data export

43) What’s “good enough”?

44) What other feature should a table widget provide?