On Mar 13, 2012, at 6:27 PM, BGB wrote: <SNIP> > the issue is not that I can't imagine anything different, but rather that > doing anything different would be a hassle with current keyboard technology: > pretty much anyone can type ASCII characters; > many other people have keyboards (or key-mappings) that can handle > region-specific characters. > > however, otherwise, typing unusual characters (those outside their current > keyboard mapping) tends to be a bit more painful, and/or introduces editor > dependencies, and possibly increases the learning curve (now people have to > figure out how these various unorthodox characters map to the keyboard, ...). > > more graphical representations, however, have a secondary drawback: > they can't be manipulated nearly as quickly or as easily as text. > > one could be like "drag and drop", but the problem is that drag and drop is > still a fairly slow and painful process (vs, hitting keys on the keyboard). > > > yes, there are scenarios where keyboards aren't ideal: > such as on an XBox360 or an Android tablet/phone/... or similar, but people > probably aren't going to be using these for programming anyways, so it is > likely a fairly moot point. > > however, even in these cases, it is not clear there are many "clearly better" > options either (on-screen keyboard, or on-screen tile selector, either way it > is likely to be painful...). > > > simplest answer: > just assume that current text-editor technology is "basically sufficient" and > call it "good enough".
Stipulating that having the keys on the keyboard "mean what the painted symbols show" is the simplest path with the least impedance mismatch for the user, there are already alternatives in common use that bear thinking on. For example: On existing keyboards, multi-stroke operations to produce new characters (holding down shift key to get CAPS, CTRL-ALT-TAB-whatever to get a special character or function, etc…) are customary and have entered average user experience. Users of IDE's like EMACS, IntelliJ or Eclipse are well-acquainted with special keystrokes to get access to code completions and intention templates. So it's not inconceivable to consider a similar strategy for "typing" non-character graphical elements. One could think of say… CTRL-O, UP ARROW, UP ARROW, ESC to "type" a circle and size it, followed by CTRL-RIGHT ARROW, C to "enter" the circle and type a "c" inside it. An argument against these strategies is the same one against command-line interfaces in the CLI vs. GUI discussion: namely, that without visual prompting, the possibilities that are available to be typed are not readily visible to the user. The user has to already know what combination gives him what symbol. One solution for mitigating this, presuming "rich graphical typing" was desirable, would be to take a page from the way "touch" type cell phones and tablets work, showing symbol maps on the screen in response to user input, with the maps being progressively refined as the user types to guide the user through constructing their desired input. …just a thought :) <SNIP> On Mar 13, 2012, at 6:27 PM, BGB also wrote: > > >> I'll take Dave's point that penetration matters, and at the same time, most >> "new ideas" have "old idea" constituents, so you can easily find some matter >> for people stuck in the old methodologies and thinking to relate to when >> building your "new stuff" ;-) >> > > well, it is like using alternate syntax designs (say, not a C-style "curly > brace" syntax). > > one can do so, but is it worth it? > in such a case, the syntax is no longer what most programmers are familiar or > comfortable with, and it is more effort to convert code to/from the language, > … The degenerate endpoint of this argument (which, sadly I encounter on a daily basis in the larger business-technical community) is "if it isn't Java, it is by definition alien and to uncomfortable (and therefore too expensive) to use". We can protest the myopia inherent in that objection, but the sad fact is that perception and emotional comfort are more important to the average person's decision-making process than coldly rational analysis. (I refer to this as the "Discount Shirt" problem. Despite the fact that a garment bought at a discount store doesn't fit well and falls apart after the first washing… not actually fulfilling our expectations of what a shirt should do, so ISN'T really a shirt from a usability perspective… because it LOOKS like a shirt and the store CALLS it a shirt, we still buy it, telling ourselves we've bought a shirt. Then we go home and complain that shirts are a failure.) Given this hurdle of perception, I have come to the conclusion that the only reasonable way to make advances is to live in the world of use case-driven design and measure the success of a language by how well it fits the perceived shape of the problem to be solved, looking for "familiarity" on the part of the user by means of keeping semantic distance between the language concepts and the problem concepts as small as possible. To that end, "familiarity" in terms of "uses comfortably oldskool syntax/algorithm, etc" is vastly subordinate in importance to "the shape of the problem domain and domain-appropriate solution behaviors are instantly recognizable in the syntax and semantics of the language." So use the syntax whose shape most becomes invisible to the reader and best exposes the shape of the domain it is representing. Sometimes, this IS a traditional syntax. In other cases, it's not because the traditional syntax is laboring under other burdens (not enough bracket characters in the graphology, for example) that cause it to ultimately do a poor job. _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
