Irvin R. Katz
Has also published under the name of:
"I. R. Katz"
Publications by Irvin R. Katz (bibliography)
Katz, Irvin R., Petre, Marian and Leventhal, Laura Marie (2001): Editorial: Empirical Studies of Programmers. In International Journal of Human-Computer Studies, 54 (2) pp. 185-188.
Katz, Irvin R. and Bauer, Malcolm I. (2001): SourceFinder: Course preparation via linguistically targeted web search. In Educational Technology & Society, 4 (3) .
Katz, Irvin R., Mack, Robert L., Marks, Linn, Rosson, Mary Beth and Nielsen, Jakob (eds.) Proceedings of the ACM CHI 95 Human Factors in Computing Systems Conference May 7-11, 1995, Denver, Colorado.
Katz, Irvin R. (1995): FRADS: A System for Facilitating Rapid Prototyping by End Users. In: Proceedings of the Sixth International Conference on Human-Computer Interaction July 9-14, 1995, Tokyo, Japan. pp. 53-58.
“While user interface toolkits and managers facilitate prototyping by programmers, few systems allow nonprogrammers to create their own applications. In this paper, we report some techniques that bring prototyping to nonprogramming domain experts, namely professional test developers at Educational Testing Service. The Free-Response Authoring and Delivery System (FRADS) allows professional test developers to create dynamic, working prototypes of computer-based test questions. FRADS was designed to leverage nonprogrammers' experience with commercial graphics packages. Test developers create questions by importing graphics and other user-interface objects, choosing the tools to provide to students in responding to the question, and delineating -- via dialog boxes and specially designed graphical objects -- how the tools and provided interface objects interact. With FRADS, we explore how much "programming power" can be obtained by using direct, graphical specification of applications.”
© All rights reserved Katz and/or Elsevier Science
Kaplan, R. M. and Katz, Irvin R. (1995): Designing Interfaces for Computer-Based Assessments. In: Proceedings of the Sixth International Conference on Human-Computer Interaction July 9-14, 1995, Tokyo, Japan. pp. 83-88.
“Over the last several years we have developed many new constructed-response items types. Part of our efforts in this process has been to develop, in conjunction with the item types, automatic or semi-automatic means for scoring these items. The development of scoring processes feeds directly back to the interface design process. Because creating complex intelligent applications to analyze a particular item can be time consuming, costly, and result in a process that cannot be generally applied, this approach to scoring these items is not a viable approach. An alternative to this is to constrain the item interface in such a way as to assist the scoring process while at the same time leaving the task realistic. We have shown two item types for which this type of development process took place. The first is a graphical task for architects. Rather than allow an architect to develop a completely open-ended solution, the item interface collects the same information while constraining the activities of the architect. Similarly, the second item, in the domain of writing, constrains the activities of the writer while collecting information like that which would be produced in a completely open-ended writing task.”
© All rights reserved Kaplan and Katz and/or Elsevier Science
Katz, Irvin R. and Anderson, John R. (1987): Debugging: An Analysis of Bug-Location Strategies. In Human-Computer Interaction, 3 (4) pp. 351-399.
“This article presents a series of four experiments investigating students' debugging of LISP programs. The experiments involve a population of subjects who know LISP reasonably well and whose errors are best classified as slips (Brown&Van Lehn, 1980). That is, students are unlikely to repeat the same errors either within their program or across programs (Experiment 1). The students' understanding of LISP is also reflected in their debugging behavior: They can usually fix a bug once they locate it. Students' difficulties are in locating the erroneous line of code. We observe that students use a variety of bug-location strategies during debugging (Experiment 2) and that the choice of strategy differs depending on whether students are debugging their own programs or other students' programs (Experiment 3). In addition, we observe that although the different bug-location strategies affect which lines of a program are searched, once students decide on a line, their ability to judge whether or not the line is correct and their ability to correct an error are not substantially affected by the strategy being used to locate the line (Experiment 4). Finally, we argue that our results have implications not only for debugging in other computer languages, but for the general processes involved in troubleshooting as well.”
© All rights reserved Katz and Anderson and/or Taylor and Francis
Show this list on your homepage
Knowledge wants to be free !
We have decided to give away world-class educational materials
because we believe that universal access to high quality education is key to the building
of peace, sustainable social and economic development, and intercultural dialogue.
To calculate just have much we have saved you, our wonderful readers, we compare our free encyclopedia to two
books we love:
$110: Human-Computer Interaction by Dix et al (a great textbook but without video interviews)
$116: Shneiderman's Designing the User Interface
(a great textbook but without video interviews).
As you are reading our encyclopedia on your iPad/tablet (and saving a few trees), we estimate that the price would be $90 if sold as an eBook.
With that number, we can calculate how much money we have saved our readers, based on calculating the number of readers.
How we calculate readership
Because of our online and tablet/iPad approach to publishing, we are able to precisely measure reading behaviour across hundreds of parameters in realtime: Anything from reading
speed, drop-off points in the text, reader demographics, and much more.
Based on our server logs and the Google Analytics API,
we calculate the number of readers as described in the calculation method below.
A reader is not the same as a simple pageview and a reader is not the same as a
website visitor (as described in our calculation method below).
We calculate readership for two types of readers:
- Readers that have read our whole encyclopedia, much the same way you read a printed book
- Readers that have reader an individual chapter
Calcalution method: How we define a reader
- First we use the Google Analytics API to get a report of the number of unique human visitors to a chapter/page. Google runs its business on ads and thus completely relies on the ability to distinguish between a human visitor and an automated request. If not, you could earn millions on automating clicks on Google Ads.
- We then compare that number to our Apache webserver logs, which report the much higher number of actual visits to a chapter/page (both human and automated). We calculate the difference in percent, which we call an "exaggeration factor", which we use in step 6 below.
- With a large part of the visitors excluded, we further exclude any visitor who:
- has not remained on the page for at least 3 minutes (this factor is calculated by recording visit durations of 1000 randomly selected visitors) or has not printed the page (i.e. has not visited the printerfriendly version of the chapter/page)
- has not scrolled the page (this factor is calculated by recording scroll movements on 1000 randomly selected visitors)
- We then further exclude "double readers", i.e. readers who read a portion of a chapter and then returns in,
say, a week or a month to read the rest.
Although this person's reading activity spans multiple server sessions, the person is only counted as a single reader.
We categorize a "double reader" as a visitor who:
- visits a page, or multiple pages, across multiple server sessions
- qualifies to be defined as a reader, cf step 1-3 above, in all server sessions
- uses the same originating IP address
- We then subtract 5% from the final number to counter-balance a last remaining factor, namely the situation where one reader reads a chapter on his/her tablet
using a WiFi connection (and counted as one reader) but then picks up his other tablet using a 3G dongle
(with another IP address) and re-reads some of the chapter. That will equal two readers, not one. We have no way
of calculating how many times this situation arises, but to be on the safe side we subtract 5%
from the final number.
- We then take half of the "exaggeration factor" from step 2 and substract from the final number. We do this for no rational reason. We do it only as a further measure to be certain that our number of readers is not inflated.
- To qualify as a reader who has read our whole encyclopedia - much the same way you read a printed book - that person must have qualified as a reader (cf. 1-6 above) of at least 80% of the encyclopedia chapters.
As a result, we have eliminated everything from automated requests to the more casual visitors. That leaves us with what we can safely call readers.
Changes to this page (author)
26 Feb 2010: Enabled abstracts to be shown on Irvin R. Katz's author page.12 Jun 2009: Author was edited (approved by an editor)31 May 2009: Author was edited
29 Jun 2007: Author was added to the bibliography
29 Jun 2007: Author was edited
29 Jun 2007: Author was edited
28 Apr 2003: Added the author to the bibliography
Page Information
Page maintainer:
The Editorial TeamHow to cite/reference this page
URL: http://www.interaction-design.org/references/authors/irvin_r__katz.html
