Issue
Article
Vol.28 No.3, July 1996
Article
Issue
Issue |
Article |
Vol.28 No.3, July 1996 |
Article |
Issue |
Once upon a time there was a group of anxious Bullets. They were anxious because another SIGCHI Bulletin deadline was approaching and the cupboard was looking distinctly bare...
But then one of them had an idea. So excited did a number of the other Bullets get about this idea that they spent several days arguing about what should go in it and how it should be structured. Eventually they managed to reach some sort of consensus on what the article should look like. However, they had been arguing for so long that the deadline had crept horribly close and so anxiety again began to creep in.
Just then The Editor came to their rescue by pointing out (as had been mooted by a number of the Bullets) that the kind of article they wanted to do would be much better if it had a little longer to gestate and a bit more input from the SIGCHI community as a whole. Instead, he thought, why not do an article that used a tidied up version of the email exchanges to show how a bunch of student editors do, usually, get the job done. This would make clear how we worked around our differences of opinion, narrowly avoided a flame war and focused on our topic before making decisions about who was to do what in order to get the article to press.
And so that is exactly what we have done.
As you will see, a relatively simple proposal for an article for this edition of the Bulletin demonstrated some of the differences of opinion on how to categorise and survey the range of software tools that we all, as HCI students or practitioners, have used. By making public the discussion the Bullets would like to try to extend the debate on these issues by drawing in the opinions and experiences of the SIGCHI community as a whole. We hope that this article will serve as a launch-pad for such a debate.
You should remember that the gently edited messages quoted below were made in the context of semi-private email exchanges -- their content should not be held too seriously against the authors!
The curtain rises on a group of people round a virtual table. You can see the faces of five of them in the light, a number of others are in shadow. In the background a shadowy figure lurks. One of the five leans forward and speaks:
Bowden Wise: So, while the deadline is still two weeks away... are any of you Bullets interested in writing something for the July issue?
Ben Anderson: OK, here's one that shouldn't tax us too much, and should give us a good article pretty quickly. I assume that most of us have done/are doing some interface coding for our thesis work -- why not write a sort of software review of all the languages/toolkits/packages we're using so that students starting projects have some information on which they might base their choice of tools (and pointers where to go for more information). If, say, 8-10 of us can contribute a paragraph each, we should have an article in no time.
Possibilities include: Tcl/Tk (I can do this), Hypercard, SuperCard, X ;-), Visual Basic, Tkperl, Java, ... there must be loads more.
Here's a suggested format for each contribution:
Without more ado, I'll do my bit on Tcl/Tk. If you want to write a bit on your favourite toolkit (or whatever), circulate it to the list (or direct to me) and I'll collate them. When there's enough I'll send out the compilation for comments, and we should be done by the deadline. Whaddya say?
Blair MacIntyre: I would be willing to contribute to this, especially since the languages (Modula-3, Obliq) and some of the packages (Obliq-3D, FormsVBT) I'm using are not widely used or known about.
But I have a small request. I would insist that we each be allowed to add comments to each others sections. And, somehow, to do it without starting a religious war. In particular, if there was some reason one of us didn't choose a language or toolkit, we may want to include it.
Using your example, any discussion of Tcl/Tk must point out that the cool thing about it is Tk: Tcl is an absolutely, ungodly, horrible language. I would concede to the tone of this comment being lessened, but not the basic message :-) Tk has been embedded in other, better languages (such as Scheme). Tcl is good for embedding into a program for use in tiny configuration scripts and such, but is not appropriate for anything larger, despite what the big boys at Sun would say.
Such an article must be low on hype, and in fact should be heavy on anti-hype. For example, Java proponents incorrectly claim that it is a "distributed language," perhaps by virtue of the fact that it provides a thin veneer over basic TCP sockets. Thus, it is misleading and students should be warned of this.
I also don't think that a "standard example" is a good idea. Tcl is ugly, for example, and that alone may turn people off it for the wrong reason. Or, the ease of creating a small, useless example may encourage someone to use a language that is unusable for larger programs :-)
Rodney Fuller: This, in my opinion, is a very good idea. But does it make more sense to organize the article based on the types of user behaviors you could prototype?
For example:
Now I'm not saying that Ben's idea needs refinement. But, I think that focusing on "code sets" and "toolkits" focuses it toward a small CS percentage of the student readers.
And while toolkits die quickly (remember SUIT and GARNET?) the problem of designing rapid UI's for those areas will not.
What does everyone think?
If it really came down to the wire I could do something on either Hypercard, SuperCard, Perl, or HTML.
Don Winiecki: Nice ideas Rodney.
In the venue of instructional design, we're always reminding our students of the need to choose tools based on instructional purposes and learner attributes, instead of on the capabilities of the tools themselves. Such a shift in classification would tend to diffuse the "my tool is better than your tool" chauvinism, also.
Blair MacIntyre: Actually, nothing can diffuse that chauvinism, just shift it. :-) When I gave my opinion on Tcl in my message, I could have couched it in any way I wanted --- bad language design, unsuitable for reusable coding, etc.
More importantly, remember that anything is technically possible in any programming language, given enough work. Certain prototyping tools (Hypercard, etc.) are better for prototyping interface concepts, but not very good for large programs.
However, just because one of us was successful using a particular tool does not mean we should be recommending it! I've built large programs in a variety of languages that I wouldn't (and actively don't) recommend to others.
Furthermore, I think the focus of the article should be a bit better defined. Do we want toolkits for prototyping GUIs? Or do we want environments for prototyping UI software?
I have no experience with the former (I've seen Hypercard and Director, for example, but never used them.) All of my experience is with the latter, with building (usually large) interactive system prototypes.
Rodney mentioned SUIT and Garnet as examples of things that come and go. They are both (more or less) GUI toolkits. I could conceivably use them from C, C++, Java, Modula-3, Scheme, Lisp, etc.
So, what do we want to focus on? GUI or interactive software prototyping? It definitely has something to do with what each of our backgrounds is, and what we are doing right now. I'm building augmented reality UIs, which is all 3D with a little 2D, and I'm spending most of my time dealing with the large scale distributed systems issues right now.
I'd also like to say that Rodney's comments about it being too focused on CS students is vaguely annoying. The CS student readers are perhaps a small percentage, but not having an article because it focuses on their needs is ridiculous. If anything, it's a good reason to have it, especially if it is written by CS students and addresses their particular interests.
We CS students are in an annoying position. Other CS students consider our work unimportant because it is not "hard" enough. Other CHI students loving refer to us as wireheads, since our work is not "soft" enough (I'm using hard to refer to things techy, soft to refer to things human). In the past, I've worked on psych experiment systems and small UI prototypes to explore specific interface issues or concepts, but I'm currently working on large, distributed interactive applications (for distributed, multi-user augmented reality, as I've said).
One of the things important to this group of students is what environments to use to build their software. This is completely different than the sort of tools Rodney is discussing, or at least the particular attributes of some of them.
If we are going to have an article on UI prototyping, make it explicit. To this I will not be able to contribute (since it's not in my current realm of experience.)
If we are going to have an article on prototyping whole, large, interactive systems (not just the interface, but prototypes of the whole system), I would like to contribute. But something that can be coded in 4000 lines of anything is not in this category and the tools that are needed are not the same.
Specifically, for the class of software I write, Perl/HTML/Tcl/etc. are not appropriate.
Perhaps we have two articles here. Is anyone interested in helping me write an article (for a future issue) that specifically geared towards wire-heads like me? :-)
Ben Anderson: Since I started this, perhaps I can try to draw the threads together.
I like the ideas for re-organisation made by Rodney and Don. To draw in Blair's thoughts, I'd like to cover everything from UI prototyping (or even UI mock-ups for psych experiments) to serious system prototypes, so we reach predominantly "soft" research, and "wireheads" too. This is a stop-gap, after all.
Perhaps we can structure it as follows:
This will be harder, as each section needs to draw in everyone's comments and suggestions. I have an offer from a student here to give me some info on Visual C++, I can cover Tcl/Tk and HTML, perhaps Rodney could offer some Perls and Blair could cover section 4? (I don't touch real code :-) Gimme your suggestions and scribbles and I'll try to write something.
I know this is going to get kind of religious, but perhaps we can come close to a consensus by the deadline ... ;-)
By the way, perhaps we should also make it clear that we in no way endorse any of these as products, nor have we received any sponsorship nor immense bribes for recommending them. Unfortunately.
Rodney Fuller: I think that this revised scope of the article is much too ambitious to do in a week, and we should scale it down. Blair has offered the only suggestion so far for doing so --- that of splitting the article into "cute, simple" solutions and then to those for "wire heads".
Let me say a few things:
So dividing the world into "simple and cute" and "real" work does not represent any form of reality in UI design.
Blair MacIntyre: Yes, of course.
Rodney Fuller: Having said that, there is a very real trade-off in the power of these languages. If it is big and complex, then you never do it in anything but C. If it is a simple, single-user or small group project, and you can define the platform and conditions of use, then you can mock up something in Supercard. It's not a question of testosterone, but of design needs and other contingencies, which are completely separate from the application or the implementation language.
Blair MacIntyre: Regarding your "never in anything but C" comment, I completely disagree, but we won't get into that here.
Rodney Fuller: And yes, all areas of HCI have an "identity" crisis --- not just "hard" and "soft" CS, but in psychology, and media studies, and graphical design, etc. We have talked about this before.
So, while I understand Blair's criticisms, and agree with him, I think that splitting the article into "hard" and "soft" versions is not the best solution. Rather I would like to see both the hard and soft trade-offs presented for the first three of Ben's sections.
Blair MacIntyre: I was thinking about the fact that we only have a small space, and given 3 or 4 reviews the size of Ben's, we are out of space.
What I think the best split might be (which I may have not conveyed properly) is between tools for UI prototyping (which, as I've confessed, I'm really not doing very much of right now) and tools for building interactive applications.
Rodney Fuller: Let's face it, if you ever get into the situation where you have to work on a 800,000 line program, someone else will have made the decisions about how you all coordinate with a common set of UI objects, and you won't be able to just create your own (those are the worst bugs to find; three programmers independently create an object called myscrollbar, which in one crucial dialog box overwrites the values of the three fields.) These decisions are not made by UI designers and we don't have to worry about them for this article.
Blair MacIntyre: While trying to prototype AR applications in my first 3 years here, I wrote about 70K lines of hideous C code (mostly to implement graphics and distributed client/server glue). I'm now building a testbed for those kinds of applications (actually, I'm hoping it will be useful for any distributed, multi-user 3D application), having thrown out all of the old code, not just a large part of it.
What I want to say in an article is, basically, don't do what I did. If we had used a proper, distributed infrastructure at the beginning, I would be much further along and experienced much less stress. My "thing" these days seems to be distributed 3D applications, and there are few (if any) really useful off-the-shelf tools.
Rodney Fuller: And I really don't want to do the section on Perl.
Blair MacIntyre: Who would? :-)
Bowden Wise: I have to agree that Ben's revised scope is too ambitious, although I do not really like the idea of two articles. I think that Ben's in-depth article would make more sense as a stand-alone article. However, since we are short on time here, perhaps we can publish it in two-parts.
Keep in mind, though, if we do this we won't be able to put the second part in the October issue, since that is supposed to be the CHI issue, and we are hoping to get some student volunteers to write that article.
In terms of where my research fits in, I am building a user interface toolkit/framework for developing multimodal applications that run on an MS Windows platform. It is supposed to be a prototype, but I am doing it in C++ with Borland's Object Windows toolkit. I am not using any "prototyping" tools! So, I suppose I fit into the "Serious Systems" category.
Rodney Fuller: On a related point, can we do a fun article on "The HCI of Star Trek," spoofing the recent book "The Physics of Star Trek?" I'll take the negative side: I have lots of examples of why Star Trek HCI sucks.
Bowden Wise: I like that idea! I got that book for Christmas, but didn't read all of it. I have a BA in Physics, so ... :)
Ben Anderson: I like it!
Rodney Fuller: But back to our discussion: I think we need to keep any article that is due next week very simple.
Ben Anderson: Indeed. I propose we devote this article to looking at a few UI prototyping tools. We can set it up as part one of a two part introduction to the tools in use in HCI at the grad student level. This first article should appeal to most of the readers of SIGCHI Bulletin, while the next article, for "wireheads," looks at tools to support more "serious" systems and provides a more reasoned discussion about what the trade-offs are.
So stepping back a bit:
Name your UI prototyping tools: Hypercard, Metacard, SuperCard, Visual Basic, Tcl/Tk, HTML (with Perl as back-end) ... any more?
Article structure:
Blair MacIntyre: I like it. I'll handle part two, and recruit some people for it.
Rodney Fuller: I think Ben's focus is right on, but I don't think we should decide now that we have to back off of mentioning code. Any mention of code will limit the readership (to those who know it) and triple the length, but by adding a touchstone we can illustrate the differences in feature sets.
For example, getting the third word from a string in a field in Hypercard, regardless of the complexity of the interface, is:
get field1
put the third word of it into temp
while in Perl (coming from a HTML front end) it becomes: [whereupon Rodney treated us to a load of Perls]
The shadowy lurker moves into the light:
Steven Pemberton (for it is he): Excuse me for butting in, but if you'll allow me...
I think this discussion is great. Some really nice opinions are coming out that you seldom hear in a public place. I think you should edit the discussion down to the interesting parts, and use that for this issue; then you've got 6 months to actually write the article itself.
In that way we have interesting discussion, a view on the processes (and deadlines!) that you go through when producing articles for the column, and a lead in to the final article in 6 month's time, which will be much better than if you try to write it in three weeks.
Blair MacIntyre: Also, we could add a request to the end for students to contribute comments about their experiences with various software systems and tools, instead of restricting it to what we few people have used.
I like Steven's suggestion. Anyone else?
Rodney Fuller: It seems weak to me, but if it were packaged as follows, maybe not:
We have not published the call for articles in the SIGCHI Bulletin. We could do that, with this exchange as an example of how the editors can help focus an idea, etc.
Ben Anderson: I think it might fly.
Rodney Fuller: It still seems weak, but we are running out of time.
Ben Anderson: Quite.
Is that Blair I hear volunteering? Thought not. Since I started all this, I'll hack at it this week and send it out ASAP.
Unless anyone else feels better qualified ;-)
Blair MacIntyre: Actually, I'll help you. It sounds fun.
Why don't we both look at it and try to decide what the focus should be. Looking at my Tcl comments, I think I may get hate mail from the religious fanatics when this comes out. Not that I care ... :-)
Bowden Wise: This is a great idea, Steven! In spite of Rodney's feeling that it is weak, how often do you see a behind-the-scenes look at how a group of editors come to grips with getting out an article? It will be an informative and interesting article!
I think asking students to contribute comments is a good idea too, given that there are 3-4 months between when this article is published and the deadline for the final article. That should give us plenty of time to collect comments from other readers.
And it sounds good to include the Call; it would be nice to have it in print somewhere to catch those people that are not reading the CHI mailing lists and other electronic forums.
The curtain falls.
As a result of these various discussions, the Bullets (seemed to have) reached the conclusion that two articles would be needed which, when taken together, would provide general guides as to what sort of software tools are available for, and usable by, students in the CHI community. The idea would be to split these into "UI Prototyping" tools and "UI Engineering" tools. As we have seen, however, the differences are somewhat blurred.
It is at this point that the Bullets would like to invite the SIGCHI community as a whole to contribute comments and opinions about the utility and content of these two proposed articles. The Bullets can be reached at:
We would also like to encourage discussion of these issues (as they relate to students making decisions about project software tools) on the CHI students mailing list:
Without Don Winiecki, Rodney Fuller and Bowden Wise this conversation would not have taken place. We'd also like to thank Steven Pemberton for suggesting that we turn the discussion into this article and, in particular, for transforming our first fumbling attempts into the initial version of the finished script!
Ben Anderson is a Doctoral Student in Computer Studies at Loughborough University of Technology. His research interests focus on the design of CSCW systems that can support the flexible nature of everyday work; e-mail: B.Anderson@lut.ac.uk
Blair MacIntyre is a Doctoral Student in Computer Science at Columbia University. His doctoral research interests are in the area of distributed, augmented reality; e-mail: bm@cs.columbia.edu
The student editorial board, collectively called the SIGCHI Bullets, invites interested students to submit articles for possible publication in the Students column of the SIGCHI Bulletin. A list of possible topics can be found at the url:
It is suggested that authors intending to submit an article contact the student editors at sigchi-bullets@cwi.nl as early as possible to confirm their topic selection and verify submission deadlines.
Issue |
Article |
Vol.28 No.3, July 1996 |
Article |
Issue |