Test REST Server
In order to properly evaluate jqGrid, DataTables, and SlickGrid against our “good enough” criteria, I set up a test REST server that returns “real” JSON data. The server contains a list of over 10,000 objects.

While the data is real, the response time is not. The test REST server pre-fetches all real data from back-end services, then cache’s that data internally in order to eliminate server response time in the evaluation. While real server calls are measured in 10ths of seconds, my test REST server’s average response time is 3ms for any given page of 50 objects.

I had to create unique REST end-points for each of my tables in this evaluation because each uses different parameters to control the list behavior. They all pull from the same list of cached objects.

jqGrid Links

- Home: http://www.trirand.com/blog/
- Wiki: http://www.trirand.com/jqgridwiki/doku.php
- Examples: http://www.trirand.com/blog/jqgrid/jqgrid.html
- Addl Examples: http://www.trirand.net/demo.aspx
- Code: http://www.trirand.com/blog/jqgrid/downloads/jqgrid_demo38.zip
- Column Model: http://www.trirand.com/jqgridwiki/doku.php?id=wiki:colmodel_options
- Params: http://www.trirand.com/jqgridwiki/doku.php?id=wiki:options
- Themes: NOTE: jqGrid uses jQuery UI – ThemeRoller to style its table. This could be a problem for us because JQuery UI and JQuery-Mobile don’t play well together. We’ll see…
- Commercial Web Site: http://www.trirand.net/

Evaluation

I created a test html file which creates a jqGrid table and loads 50 objects at a time from the REST end-point mentioned above. Remember, it’s a cache’d list.

1) Performance is #1

• Like DataTables, performance is outstanding …actually, when fetching records, it’s identical because it’s the same back-end
• 50 records: desktop, round-trip is 3ms, iPad3 is about .3s – .5s
• 500 records: desktop, round-trip is 15ms, iPad3 is about 1s
• Unlike SlikGrid and DataTables, jqGrid does not implement Virtual Rendering. As far as I can tell, it renders the full result set as soon as it’s received. Don’t know how much of a performance hit this is, but it could be a big deal depending on what you put in your cells.
• However, with jqGrid’s gridview parameter, it is able to “append” all the rows with a single call …making it a very fast operation. Note that this choice comes with some limitations: for example, no afterInsertRow event, etc.
• I do not like how jqGrid handles the scroll bar on an iPad3. While it appropriately hides the scroll bar, the table does NOT take over the available space. Further, when scrolling, it does not use the iPad3′s “thin” scroll bar. Finally, when fast swiping, it stops scrolling immediately after you’ve quit touching …to smooth scroll stop like you’d expect.

2) Device requirements: performance and functionality will be determined by low-powered, ICS-based tablets, not older Honeycomb devices, nor smart phones

• As noted above, performance on an iPad3 is outstanding
• Performance on a Honeycomb smart phone (Galaxy S2 on T-Mobile) is acceptable (but not part of our required criteria)

3) Table paging and navigation will be performed by next, prev, first, last, and #’s links

• jqGrid supports both paging-via-navigation-controls and paging-via-scrollbar
• Here’s an example: Can do this: http://trirand.com/blog/jqgrid/jqgrid.html look at Advanced/Master Detail

4) The table will load 1 “page” of data at a time, if the rows don’t “fit” the vertical table size, users may scroll to see the rest of the page

• jqGrid will load 1 “page” of data at a time
• If the fetched rows don’t “fit” the vertical table size, users may scroll to see the rest of the page. Note my “scrolling” comments in the Performance section above.
• The table can be sized such that it grows as needed to accommodate all rows

5) The table will not cache previous requests (to protect mobile devices; and if #1 is met, no need)

• jqGrid by default does not cache previous requests
• I am uncertain if jqGrid can be set up to pre-fetch addl pages or not ??????

6) All paging, filtering, sorting will be performed by the back-end; none in the client

• jqGrid supports paging, filtering, and sorting in both the UI and the back-end

7) We will filter on only string data originating from the server for now

• According to its doc, developers can specify sorting for various types including string, number, boolean, link, select and percent. However, I believe this is for client-side processing only, and is not part of ajax-based solutions.

8) Code size should not exceed 200K (minified and gzip’d); the smaller the better

• File size: File size: CSS: 12K; JS 430K raw / 270K minified / 68K gzip’d;
• 3 times larger than DataTables

9) We will only select a mature, well supported Table widget. We will not make our own.

• jqGrid is currently in version 4.4.0 (released in June 2012)
• and has been developed now for at least 3 years, since 2009 …but I actually suspect much longer since that was version 3.5.x
• has over 8,500 threads (27,000 posts) in its on-line forums
• Unknown number of unit tests …I’m uncertain how rock-solid this product is. Probably pretty good.
• It does not provide very many pre-built examples …but the ones that are there suffice

10) Theming Support :

• DataTables supports ONLY JQuery UI ThemeRoller classes
• However, with the rich set of overridable events, I believe we could add/remove any styles we want …just like DataTables

11) Table must by stylable to may our particular look and feel

• jqGrid does not specifically provide APIs to apply the styles we want throughout the table. However, with the rich set of overridable events, I believe it can be styled to match our needs …just like DataTables.
• jqGrid provides a very rich Column Renderer which is passed the backing row Object and the property value …giving the renderer the opportunity to display addl fields in each cell
• jqGrid does not really permit row expansion showing more details about a row Object. Any examples I’ve seen add additional rows …kinda klunky.

12) Row selection (single select for now; multi-select for future)

• jqGrid supports single selection via row-selection or checkboxes
• I do not believe jqGrid supports multi-select across page boundries like DataTables does. Not sure I care though either

13) Links / Actions – in-row actions for now; likely top-of list actions for future

• With its column renderers, jqGrid supports placing any data into a cell, including buttons/actions
• jqGrid will use any specified Object value (for example: id) as the row’s ID attribute
• jqGrid supports a very rich set of custom events which code can bind to

14) Editing: no in-cell editing for now

• jqGrid supports in-cell / in-row editing
• 2 method exist: see “Row Editing -> In-Line Navigator” and “Live Data Manipulation -> Navigator” examples

15) Alternate Views: no “View As…” alternate views for now

• jqGrid does not directly support alternate views for its tables

16) No conclusion on table width handling. However, most people would like to see columns shrink until it’s ridiculous, then hide low-priority columns altogether

• A jqGrid table normally sizes to the combined widths of its visible columns
• However, you can also set the grid width, and the columns will adjust accordingly
• I have not seen any example where the table’s width sizes dynamically. Seems to always be based on the grid’s “set Width”
• Data within a jqGrid cell by default does NOT wraps unto addl lines (However, I’m sure we could easily change this with the CSS whitespace property). By default, when a cell’s data exceeds the cell bounds, ellipses show…
• Uncertain if jqGrid could auto-show/hide low priority columns based on table width

17) The table needs to support a distribution-friendly license

• jqGrid is licensed under the free MIT license
• However, they have also launched an official commercial website http://www.trirand.net

Special Notes

• jqGrid supports a truly awesome Column Model
• I’m not too impressed with its “row” editor …adequate, but not beautiful. Of course, we can style any way we want.
• I don’t know why jqGrid’s “row expansion” feature simply adds more rows. In my testing, I learned that I can place any amount of data into each cell, independent of the other cells. In other words, rows can have variable row height, and I could auto-expand the current row if I wanted to. I think they should specifically make an “expand” feature for rows to show addl detail.
• jqGrid supports a grid within a grid!
• jqGrid support a “tree” control by adding additional rows with indented values. Kinda cool!. Check out the “simple” example at: http://www.trirand.net/demotreephp.aspx
• jqGrid has launched an official commercial website http://www.trirand.net. Check it out; there are some impressive demos there. You’ll note that they’ve spent considerable time trying to make a list and tree out of the same control. IOW, if you need a tree control, this is one is pretty good.

Notable Params

- 100 params
- 20 Events
- over 50 Triggered Events !!

ajaxGridOptions  - override all AJAX parameters including: error, complete, and beforesend events
altclass         - specify the class you want for the "alternate/zebra" rows.  Hmmm ...do they have this for all styles?
autowidth        - table auto-sizes (width) according to the size of its parent div
cellEdit         - enable editing
cellsubmit       - when editing, determine where the edits are saved (remote or clientArray/local)
colModel         - array which describes the parameters of the columns
deepempty        - uses JQuery to empty a row; prevents memory leaks
direction        - good support for Right-to-Left and Left-to-Right languages
forceFit         - all columns will always consume 100% of the table width (adjacent columns adjust as needed)
hoverrows        - enable row hover effects
idPrefix         - add a prefix to a row's ID
loadui           - control what to do while loading: disabale, enable, block
mtype            - HTTP GET or POST
pager            - enable paging controls.  NOTE: this also controls into what HTML div to place the pager
pgtext           - show details about the current list
prmNames         - controls the names of all the parameters sent to the server
scroll           - tells jqGrid to disable paging controls and to enable paging-via-scrollbar
shrinkToFit      - recalculate column widths as the table shrinks
sortable         - uses JQuery UI to permit reordering of the columns.  Since we're trying to be JQuery Mobile compliant, we do not want this.
toolbar          - defines the tools available in the toolbar
treeGrid         - enable the "tree" aspects of the grid control
url              - the source of the ajax data
userData         - addl data to make part of the request
afterInsertRow   - method gets called after a row is created
beforeRequest    - before a request is made
beforeProcessing - after a response is received (but before doing anything with it)
gridComplete     - after all received data is fully processed
onPaging         - after selecting a paging options, but before processing the data
resizeStop       - fires after resizing event has taken place (resizeStart also)
tons and tons of other options and events

While the data is real, the response time is not. The test REST server pre-fetches all real data from back-end services, then cache’s that data internally in order to eliminate server response time in the evaluation. While real server calls are measured in 10ths of seconds, my test REST server’s average response time is 3ms for any given page of 50 objects.

DataTables
- Home: http://datatables.net/
- Examples: http://www.datatables.net/examples/
- Tests: https://github.com/DataTables/DataTables/tree/master/media/unit_testing
- Params: http://datatables.net/ref (125 params supported)
- Themes: http://datatables.net/styling/themes/ui-darkness

I created a test html file which creates a DataTables table and loads 50 objects at a time from the REST end-point mentioned above. Remember, it’s a cache’d list.

1) Performance is #1

• performance is outstanding
• 50 records: desktop, round-trip is 3ms, iPad3 is about .3s – .5s
• 500 records: desktop, round-trip is 15ms, iPad3 is about 1s
• Like SlikGrid, DataTables implements Virtual Rendering with its bDeferRender parameter Rendered rows/cells are retained for 1-page scrolling
• I like how it handles the scroll bar on an iPad3. With no addl coding, it auto hides the bar, and lets the table take over the available space. Further, when scrolling, I like how it uses the iPad3′s “thin” scroll bar. Finally, it uses the device’s fast swipe gesture to continue to scroll the list even after you’ve quit touching; obviously it stops after a second or two …just as you’d expect.

2) Device requirements: performance and functionality will be determined by low-powered, ICS-based tablets, not older Honeycomb devices, nor smart phones

• As noted above, performance on an iPad3 is outstanding
• Performance on a Honeycomb smart phone (Galaxy S2 on T-Mobile) is acceptable (but not part of our required criteria)

3) Table paging and navigation will be performed by next, prev, first, last, and #’s links

• DataTables supports both paging-via-navigation-controls, and paging-via-scrollbar

4) The table will load 1 “page” of data at a time, if the rows don’t “fit” the vertical table size, users may scroll to see the rest of the page

• DataTables will load 1 “page” of data at a time
• If the fetched rows don’t “fit” the vertical table size, users may scroll to see the rest of the page
• The table can be sized such that it grows as needed to accommodate all rows

5) The table will not cache previous requests (to protect mobile devices; and if #1 is met, no need)

• DataTables by default does not cache previous requests
• DataTables can be set up to pre-fetch addl pages as needed

6) All paging, filtering, sorting will be performed by the back-end; none in the client

• DataTables supports paging, filtering, and sorting in both the UI and the back-end

7) We will filter on only string data originating from the server for now

• DataTables has made some effort to support sorting and filtering on representations of the data other than what’s displayed (Enums vs their string implementation; dates; etc.) However, I believe this is for client-side processing only, and is not part of ajax-based solutions.

8) Code size should not exceed 200K (minified and gzip’d); the smaller the better

• File size: 68K minified / 20K gzip’d. This is outstanding !!
• With addl plugins (FixedColumns, Scroller, etc.), + 20K minified / 6K gzip’d

9) We will only select a mature, well supported Table widget. We will not make our own.

• DataTables is currently in version 1.9.2
• and has been developed now for 4 years, since 2008
• has over 10,000 threads in its on-line forums
• backed by a suite of 2800 unit tests
• provides over 130 pre-built examples

10) Theming Support :

• DataTables supports JQuery ThemeRoller classes
• DataTables allows users to specify what class names to associate with HTML elements
• DataTables can render its add-on widgets (nav bar, search field, etc.) in HTML-provided div’s

11) Table must by stylable to may our particular look and feel

• With DataTables liberal handling of class names (user-definable globals hold class names), I believe it can be styled to match our needs
• DataTables provides a Column Renderer which is passed the backing row Object and the property value …giving the renderer the opportunity to display addl fields in each cell
• DataTables permits row expansion showing more details about a row Object

12) Row selection (single select for now; multi-select for future)

• DataTables supports single selection via row-selection or checkboxes
• DataTables supports multi-select across page boundries (sending selections to server)

13) Links / Actions – in-row actions for now; likely top-of list actions for future

• DataTables supports any buttons you need to place in a row
• If requested, DataTables will add unique IDs to each row in a paged table
• DataTables also supports custom events which code can bind to

14) Editing: no in-cell editing for now

• With its Editor plugin, DataTables does support in-cell editing if desired

15) Alternate Views: no “View As…” alternate views for now

• DataTables does not directly support alternate views for its tables

16) No conclusion on table width handling. However, most people would like to see columns shrink until it’s ridiculous, then hide low-priority columns altogether

• DataTables supports a dynamic width for its tables
• Columns resize when the table resizes
• Data within the cells re-wraps unto addl lines as needed (IOW, row height is not fixed when paginating via the navigation bar)
• Uncertain if DataTables could auto-show/hide low priority columns based on table width

17) The table needs to support a distribution-friendly license

• DataTables is dual licensed under the GPL v2 license or a BSD (3-point) license
• I’m no lawyer, but I suspect the BSD license is sufficient

Notable Params — 125 params exist!!

sServerMethod    - HTTP method to use GET | POST
bAutoWidth       - enable auto col width calculation; disable if col widths are in aoColumns
bProcessing      - show a "processing request" message
bPaginate        - enable pagination
sPaginationType  - style of pagination buttons/links; two_buttons
bLengthChange    - show the page size combo; requires bPaginate
aLengthMenu      - [[values], [display]]: [[10, 25, 50, 100, -1], [10, 25, 50, 100, "All"]]
iDisplayLength   - size of a page
bFilter          - show the search box; to remove box but keep filter ability, use sDom
bRegEx           - interpret search string as a regEx expression
bSmart           - use DataTable's smart filtering methods to match words at any point in the data
bJQueryUI        - enable JQuery UI ThemeRoller support; affects visibility of prev/next links
bInfo            - Show status bar details about the current table data; 1 to 10 of 100 (# filtered)
bScrollInfinite  - Pagination by using only the scroll bar
iScrollLoadGap   - Amount of scrolling left to go before pre-fetching the next page
bScrollCollapse  - Controls if the table's viewport should be shrunk on the last page
sScrollX         - Specify horizontal scrolling; blank = disabled
sScrollY         - Specify vertical scrolling
bSort            - Enable sorting; individual cols can be disabled /w bSortable option on each col "bSortClasses"
bStateSave       - Enable state saving; uses cookies
bDeferRender     - Only draw those rows that are visible; draw addl as needed
bServerSide      - filter, sort, page on server; must be used with sAjaxSource
sAjaxSource      - URL: /rest/service/endpoint
aoColumns        - Define column model
fnServerParams   - Define any addl data to send with page request
sDom             - Tell DataTables in what div's to render it search, msgs, & nav bar widgets
fnRender         - Rendering function used to draw cell contents

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?