Constraints

Comments on the paper Interactive Beautification: A Technique for Rapid Geometric Design, by Takeo Igarashi, et. al., in Proceedings of UIST '97: the ACM Symposium on User Interface Software and Technology, Banff, Alberta, Canada, pp. 105-114, October, 1997.

Good points

  1. Great paper! The authors appear to have produced a very comprehensive range of drawing constraints. The ability to recognize symmetry and and interval equality is remarkable, I think.
  2. The way the system provides a best-guess default but with the choice of alternatives that may have been the intended effect, and particularly the ability to proceed with the best guess without having to do any additional work to "get the system out of the way."
  3. A floating menu with commands that are too hard to think up meaningful gestures for!

Bad points

  1. Ultimately, I imagine that stroke recognition is going to have to be context-sensitive or modal in some way to deal with different types of drawing, and with particular regions of complex drawings.
  2. It is not clear to me why they chose such simple drawings for their user evaluation -- they seem to be too simple to be able to draw useful conclusions. (They do say that their experiment is preliminary.)
  3. I didn't understand their description of the constraint solver at all. What, for example, does "x0 = const; y0 = const" mean? Are x0 and y0 the difference between coordinates of candidate points?


Comments on the paper Ultra-Lightweight Constraints, by Scott E. Hudson and Ian Smith, in Proceedings of UIST '96: the ACM Symposium on User Interface Software and Technology, Seattle, pp. 147-155, November, 1996.

Good points

  1. Focus on reducing size and complexity of constraint solvers, which I gather is a problem.

Bad points

  1. As described, this algorithm appears to work only for a linear sequence of interactors -- i.e. a row or column. I am somewhat confused as to whether uconstraints are more useful than that (implied on page 153) or not.
  2. Lazy evaluation has no advantages if you have to compute all the data anyway, which seems likely for UIs. I would have thought an eager evaluation algorithm would have been just as efficient.
  3. Doesn't Java already have constraint-based layout support? What can uconstraints do that I can't do with (apparently) simpler solutions like Tk's pack or grid? Overall, I guess I don't understand the point of uconstraints -- they appear to limit constraints to a small set, yet be more difficult to use than solutions targetted specifically. Perhaps the paper just didn't explain it well.

John Reekie, March 3rd, 1998.