Best Practices for Print / Mobile Friendly HTML Tables (Updated)
El inglés es el idioma de control de esta página. En la medida en que haya algún conflicto entre la traducción al inglés y la traducción, el inglés prevalece.
Al hacer clic en el enlace de traducción se activa un servicio de traducción gratuito para convertir la página al español. Al igual que con cualquier traducción por Internet, la conversión no es sensible al contexto y puede que no traduzca el texto en su significado original. NC State Extension no garantiza la exactitud del texto traducido. Por favor, tenga en cuenta que algunas aplicaciones y/o servicios pueden no funcionar como se espera cuando se traducen.
English is the controlling language of this page. To the extent there is any conflict between the English text and the translation, English controls.
Clicking on the translation link activates a free translation service to convert the page to Spanish. As with any Internet translation, the conversion is not context-sensitive and may not translate the text to its original meaning. NC State Extension does not guarantee the accuracy of the translated text. Please note that some applications and/or services may not function as expected when translated.Collapse ▲
In Extension there are many times when we need to display tabular data to our users. However, large tables can be difficult to decipher, take too long to scan, or inevitably just confuse your users. We always recommend keeping your tables as small and simplistic as possible (the fewer the columns, the better), and if you can’t, you should consider separating the data into two or more tables.
There are several reasons large table(s) don’t play well on the web:
- Large tables rarely look good printed. While they may look ok on a 15″ (or larger) screen, they likely aren’t going to scale down to an 8.5″ piece of paper.
- They’re terrible for mobile. There really isn’t a great solution here, but smaller tables do fare better than larger ones, and rely less on the users short-term memory (as they scroll back and forth) on a small screen.
There are a number of considerations you can make when designing your table to ensure that it’s clean, lean, and user-friendly. We’ve created a fictitious table below about Red Beetle thresholds to show were these potential opportunities exist.
I’ve highlighted a few areas for improvement…
|Geographic Region||First Appearance||Suggested Treatments||Expected Beetles per row foot||Average Beetle Size (millimeters)||Potential Damage||Days to Eradicate|
|North Carolina||Nov. 15 to Mar. 15||Red Pepper Dust, Cobble Stone Mortar||15||6.0||—||10 – 12|
|Virginia||July 15 to Aug. 15||Nothing found to be effective||11||0.5 – 1.0||Very-High||N/A|
|Louisiana||July 1 to 15||Alligator Eggshells, Dragonstone||20||0.25 – 0.5||Medium-Low||7 – 10|
|Georgia||Aug. 1 to 15||Tall Fescue Clippings, Cinnamon||8||1.0 – 1.5||Very-Low||5 – 7|
|South Carolina||Aug 1 to 15||Green Ketchup||16||0.5 – 1.0||Very-Low||5 -7|
Remember, our goal is to reduce noise, and our keep columns as skinny as possible.
Here’s what we cleaned up:
- Two of our table headers could be more concise; We always recommend using your best discretion here (you shouldn’t place brevity above clarity). “Geographic Region” could simply be renamed “State”, and Average Beetle Size (millimeters) could simply be “Avg. Beetle Size (in mm)”
- This one is a judgment call, but you could abbreviate the names of each state if you needed additional room in your table.
- Our dates “Nov. 15 to Mar 15” can be shrunk down by using their numerical equivalents “11/15 to 3/15″. It’s extremely important NOT to use a dash in place of the word ” to ” when separating two dates, this is for accessibility.
- For Average Beetle Sizes we replaced a lot of decimals like “0.5” with their fraction equivalent ½, which cuts 3 characters down to 1. There’s also no need to represent a whole number as a decimal so 6.0 can simply be 6.
- Not only will a screen reader skip over our value of “–“, we’re completely confusing the user here. What does “–” actually mean? Is it unknown? Or was it simply not tested? It’s better to be 100% clear in this case.
- In the Potential Damage column, we could end up with a lot of re-used values, especially as our table gets larger. If we are pressed for room horizontally in our table, it can sometimes make sense to extract those values out into abbreviations and provide a key in the table footer. Note: in this particular case, that probably wasn’t necessary.
- In the Days to Eradicate column, we’ve replaced the dashes ” – ” as range dividers with the word ” to “. The primary reason for this is that most screen readers skip over the dash when reading the text aloud to a visually impaired user.
Here’s the final result!
|State||First Appearance||Suggested TREATMENTS||EXPECTED Beetles per ROW Foot||Avg Beetle Size (in mm)||Potential Damage||Days to Eradicate|
|NC||11/15 to 3/15||Red Pepper Dust, Cobble Stone Mortar||15||6||Unknown||10 to 12|
|VA||7/15 to 8/15||Nothing found to be effective||11||½ to 1||VH||N/A|
|LA||7/1 to 7/15||Alligator Eggshells, Dragonstone||20||¼ to ½||ML||7 to 10|
|GA||8/1 to 8/15||Tall Fescue Clippings, Cinnamon||8||1 to 1.5||VL||5 to 7|
|SC||8/1 to 8/15||Green Ketchup||16||½ to 1||VL||5 to 7|
Cold Tolerances: VH = Very-High; ML = Medium-Low; VL = Very-Low;