Indie UI review

From Education & Outreach

Nav: EOWG wiki main page


Comments from EOWG on Indie UI: Events 1.0 Draft of 30 July 2013.

Note: EOWG review of technical documents should focus on understandability, approachability, and ease-of-use. Look especially at the introduction, background, use cases, and other such sections. Make sure the Overview page is linked early in the Introduction and in the Abstract, as appropriate. (If you have comments on technical aspects beyond the education & outreach perspective, please submit them yourself.)

Draft of comments to submit

  • ...comment {name}
  • Link to Overview — Add link to the IndieUI Overview ... @@
  • "See the introduction for background and usage examples." @@
  • "This section is non-normative." only needed under "1. Introduction" and not the subsections. (If you determine it's important to repeat it under each subsection, it's missing under "1.4 Usage Examples")
  • @@

Abstract

EOWG minutes 13 Sept for discussion

  • The language used here is rather dense. "...user idiosyncratic heuristics…" is perfectly descriptive, but not very friendly. It reads a bit like a research paper. It was the end of a very long day for me, and this was the first time I've ever looked at this draft, but I had to re-read the abstract a couple times to properly digest it. Practical examples salvage the abstract, making the purpose of IndieUI clear. {Paul 2013-09-12}

Introduction

  • ...comment {name}
  • [no change] 1.1 states the problem space nicely, establishing the need for IndieUI {Paul, 2013-09-12}
  • [no change] 1.2 clearly and simply states three goals. Very nice. {Paul, 2013-09-12}
  • [@@SLH consider starting with a statement about what is in scope] 1.3 I expected a bit more detail in this section. The only thing mentioned is a single out-of-scope item: decisions about mapping of physical interactions to trigger IndieUI events. What is IN scope? {Paul, 2013-09-12}
  • [@@ Paul & Sharron will draft suggestions] 1.4 usage examples are good generic code samples that build on section 1.3, but sitting in their own section seems slightly "contextless." {Paul, 2013-09-12}
  • [@@ replace "in order words" with "Therefore" or "Specifically" or "that means that"] 1.5 paragraph one leans on dense language again. Use of the phrase "in other words" admits that the preceding sentence might be too complicated or jargony. Paragraph two is complex, but does not have that "dense" feeling to me. {Paul, 2013-09-12}

UI Actions

  • [@@ CSS for code is hard to read...]
  • QUESTION: is the text color / font for "MUST" and "SHOULD NOT" a W3C convention? I may not have seen enough of these docs :-) {Paul, 2013-09-12}
  • The red text for code within the narrative makes sense to me. {Paul, 2013-09-12}
  • [no change] 2.2 Example 3 and the NOTE in green are clear and helpful.{Paul, 2013-09-12}

UI Request Events

  • ...comment {name}
  • The interface names are pretty self-explanatory, but it might be helpful to include a sentence or two at the beginning of each subsection to describe in general terms what each collection does.{Paul, 2013-09-12}
  • Will the editorial notes be converted into narrative? They seem to be written that way and would provide some introduction / context for this section. {Paul, 2013-09-12}
  • 3.1.2 is an example where technical language should be used to describe how determining the event receiver works, i.e. recursively traverse up the element hierarchy to the root element.{Paul, 2013-09-12}

Other

  • ...comment {name}