Question: How should Noadster list in the outline a resource that has no ? Currently, it lists its URI like a label, and makes no other distinction. Clearly: 1) Some resources have labels, and some don't 2) Distinguishing the two can (at least maybe possibly) be helpful to the user SHOULD THERE BE A DIFFERENCE? One way to look at it is risk assessment. With no distinction, the risk is that we have a GUI that looks a little less slick and that it takes a user a little longer to read through the hierarchy, because it is harder to discriminate labels from URIs. With a distinction, the risk is that people might misinterpret the style, and think only the URLs are clickable, or reversely, think the URLs are "false" hits and only click the labels. Using different colors risks stressing a difference that is potentially semantically and functionally irrelevant. Suggesting a functional and semantical difference that isn't really there in the underlying application seems counter to tons of HCI literature that proves that that is, in general, bad interface design. So as always with HCI, stating for once and for all what is good and what is wrong is not possible. Doesn't HCI thus talk about user-control, like style? For some users, there may well be an important semantic difference between labeled and unlabeled resources. Thus they can set their own options/preferences and see things as they want to. LAYERS OF STYLE AND I/F There are user issues that are fundamentally ingrained in low-level structure generation, ones that can't bubble up to style. I see our current scope as focusing on these, and making sure the other issues are style sheet-able at some particular level. Generally good interface is a noble research goal. So is user control over i/f. If we encode HCI measurable differences of our interface in CSS and XSLT, and/or in a form page, then we usefully isolate the HCI issues out and we can focus on building document structure . Might even be useful to categorize style into CSS vs XSLT vs slightly deeper aspects of structure building such as pruning, including localized grouping and sorting. We can say how to make document structure. Others can determine the best way to present it. But, of course, If there are issues that can't be cooked out in the above fashion into some category of style, then they are truly in our scope. Such as - Is document structure itself useful? - What types of document structure are useful (in any style for showing it)? - What patterns of knowledge structure generate useful document structure? - Seven really is the best number of subdivisions to have at each level of document structure There is no way to stylize the above, except at the very bottom level that is the focus of this research. These remain core user issues for us, worthy of our pursuing well-considered and well-scheduled HCI approaches. Of course the other issues higher up in the style chain are important. But by stating where they are in the chain, and by starting at the bottom, we've made it easier for us or other people to pursue higher-level HCI/style issues in future work. Thus, CSS/XSLT/XForm is a litmus test for whether an issue is an HCI/style issue or important to the user at the more foundational level we're research at (at least now for this paper). CSS This distinction can be made a style issue at the CSS level with class="URI" and class="label" (very easy to add) in HTML would let CSS define both how - Noadster currently shows it (no difference) - an alternative, such as background and font color ghosted Thus default.css and alt.css could have these differences, and much much more. We could easily pass the user CSS as a parameter for both local and global display. SORTING Another possibility is the sorting the non-labeled out of the list, which is not too hard: just do then . A template calling these could be in default.xsl and alt.xsl, one of which is included in strucProg.xsl, which calls the template. (Noadster already uses this type of XSLT modularization) I'd plan to put a style form in the demo, much like what Topia has. For example, the alternate sorting came out of varying weights based on whether a resource had a label or not, which a Topia-like form can set. We could collect in this: 1) The issues for which there are choices for style 2) Some sample choices for each (illustrating each issue)