Suggestions for Public Hubs

Based on common problems seen in hubs, here are some recommendations from the UCSC Genome Browser engineers:

Have no more than 10 tracks on by default.
Have a description page for every config page (composite or stand alone track).
The description page preferably contains our standard sections as defined here under "html": http://genome.ucsc.edu/goldenPath/help/trackDb/trackDbHub.html#commonSettings
The description page MUST have contact email address prominently displayed.
Note that multiple composites/tracks can use the same description page by using the html setting.
Related tracks should be combined into composites where appropriate. The hub track group should not be overwhelming with individual tracks when they can be combined into a meaningful composite organization. This will make user configuration easier.
Extremely large hubs may use superTracks as well to achieve a meaningful hierarchy.

Guidelines for Composites:

Have multi-view only when there is more than one view. Views ideally give alternate access to the same data (e.g. signals and called peaks). The value of views is that they allow for more than one data/configuration type (e.g. bigBed and bigWig) in a single composite. All subtracks of a view must have the same data type. Likewise, all subtracks of a non-multi-view composite must be the same type.
There should be no single entry dimensions (only one cell line should not be represented in dimX=cell) unless data growth is expected to fill in additional entries.
Never represent the same subgroup in both view and as a dimension (e.g. NOT dimensions dimX=view). For that matter a subgroup should never be in 2 dimensions (e.g. NOT dimensions dimX=cell dimY=mark dimA=cell). The composite will appear to function but multiple ways of selecting the same thing will create a confusing and inconsistent UI.

Only 1: prefer dimX (e.g. dimensions dimX=cell). This saves vertical UI space, but is not always the best choice.
Two dimensions: use dimX, dimY (e.g. dimensions dimX=cell dimY=mark)
More than two: use dimX, dimY on most important dimensions, then dimA,B,C as needed on lesser dimensions. (e.g. dimensions dimX=cell dimY=mark dimA=donor_id)
The ABC dimensions should probably use filterComposite (e.g. filterComposite dimA)
Each dimension and views should be represented in sortOrder, ideally in order of dimX, dimY, dimA,B,C, view (e.g. sortOrder cell_type=+ mark=+ donor_id=+ view=+). But the hub user may wish for a different sortOrder, which is fine.
SubGroup/dimension tags should be short and sweet with no special chars. Also labels can have HTML codes embedded (e.g. NOT CPG_methylation_%=CPG_methylation_% but mpct=CPG_methylation_&_#37; Note the embedded code in the example has been mangled intentionally.)
The use of metadata lines can be supported, users need to be well aware that support may be replaced by another system in the future.