Richards Calculator

Moved from WhatIsInteractionDesign

If I were to design a software calculator, it would present lines of operands and results, much like ancient paper calculators. So instead of a single row and large fake, useless, buttons, the output of a number of computations would look something like:

        1000  1000
       + 200  1200
        <CE>	0
         666	666
        ** 2	443556
        sine	0.5877852522924729
And it would be interactive so that you could cut and paste whole lines or modify the past and have all the results be automatically recalculated. Basically, it would function like a very specialized, easy to use spreadsheet. It's a spreadsheet with exactly two columns where the right-hand column has locked in equations and all of the HCI drives the left-hand column solely. The left hand cells always contain curried functions and the right hand cells always contain "apply the left-hand cell to the upper cell".

Additionally, the math functions like sine and cosine and squared wouldn't be given buttons nor would they occur on a palette. They would be placed in a WheelMenu so the total number of functions would be limited to 8 categories of 8 functions.

The result of this design are various concepts of: which are nowhere found in a typical software calculator. It also reuses a general-purpose HCI design (wheel menus).

Any other cases you want me to deal with? Coming up with these is FUN.

Oh, and I prefer to be referred to by RK, Richard or RichardK than Kulisz. One's my name, the other's not. -- RK

I invented Richard's design 25 years ago by just programming. No interaction design required. Actually my calculator is much more powerful than Richard's. I wonder how he would do the expense report example I wrote my calculator to solve. See Not only am I a nicer guy than Richard, I'm a better designer and I implement my designs. -- WardCunningham

Nice try. :)

As for your expense report, that'd probably have something to do with the fact that yours is an expense report generator and not a, well, a calculator. -- RK

Do you consider the above description of RichardsCalculator to be complete? If not, I'd like to see a complete definition (is that the right word?) of RichardsCalculator. This is fascinating, both from an academic point of view and from a purely personal one: I'm incapable of mental arithmetic and rely heavily on calculators and spreadsheets for even the simplest calculations.

-- DaveVoorhis

It's pretty complete. I can't think of anything else to add or subtract at the moment. It was sufficiently complete to send off to the programmers when I just had the calculations and history, without the HCI. At this point, only the layout of the math functions still has to be determined.

Oh yeah, and the layouts (business, mathematics, scientific) aren't mixed up together, nor are they available in modes. If there are different layouts then there is a "business calculator" separate from a "math calculator" and from a "scientific calculator". People install and use the precise one they need and forget the rest. They never, ever need them all at the same time. -- RK

To me, it seems sufficiently complete to send off to a software architect -- who should produce use cases, storyboards, CRC cards, UML diagrams, scraps of toilet paper, backs of envelopes, ER and DFD diagrams, eighty pages of specification docs, or whatever design artifacts are appropriate to the preferred development process. These, then, should go to a programmer. Alternatively, ExtremeProgramming could be used -- I suppose we'd need two of me and one of you sitting over our shoulder whilst we code the thing.

Of course, this assumes that the designer or coding team appreciates the concepts and has the imagination, experience, and understanding of usability issues to translate the interaction design (above) into something that reflects the original design intent. I would argue that the requisite collection of abilities to effectively turn the above into code (or something code-able) are relatively rare and expensive, even using XP. Furthermore, I have a sneaking suspicion that what I create from this will not reflect the RichardsCalculator vision, no matter how well I appreciate the concepts. After all, my experiences are unquestionably different from Richard's, and I believe it is in translation of abstract concepts to concrete structures where these differences, and their effects, will become most apparent.

In other words, while I'm sure we both understand "history of calculations" in concept, our different backgrounds may mean that my implementation of "history of calculations" meets the letter of the concept (and suits my imagination of what "history of calculations" should be), but may not suit your vision of it.

To me, this suggests a need for clear, unambiguous, formal interaction design methodologies, processes, and notations.

-- DaveVoorhis

That's AlanCooper's gig.

Then is InteractionDesigner a specific development role, with well defined responsibilities and activities, or is it essentially another way of saying "the dude who comes up with the software ideas?" I'd like to be able to tell a design team (a collection of AlanCooper instances, if you like) or a development team that as of Marchuary 32nd, for each new project they will be receiving an InteractionDesignSpecification? from the InteractionDesigner, and it will have the following 'n' characteristics, which look like 'x', 'y', and 'z'.

Or, will an InteractionDesignSpecification? always, by its nature, be an ad hoc document? Is any form of waterfall model incompatible with the RK view of InteractionDesign, such that you anticipate always (or only) working interactively with the development team as a surrogate user?

-- DaveVoorhis

Interaction design is "what the dude who comes up with the software ideas does". CooperInteractionDesign provides a specific development role with well-defined responsibilities and activities. AlanCooper is very much into WaterFall so there's nothing in the field or his process that's against it. I personally prefer XP. -- RK

[As a programmer, I would have questions about corner cases and ambiguities in the definition. Would your model of software development include Q&A sessions, or how would you resolve these sorts of things? Depending your response I'll either ask them here or just not ask until you've seen what Dave ends up with.] -- ChrisMellon?

What do you mean by Q&A sessions? If this is a general question then you should keep in mind that I'm not a methodologist. I don't have a method of software development or even of interaction design. I just do the stuff. If you have specific questions about the calculator or something else then here's as good a place as any.

-- ChrisMellon?

I would definitely be interested in using it, and I have no preferred OS. I use Linux and Windows XP equally. One windowing, filesystem based operating system is pretty much like another. I'm fully intending to code the thing, once I have a clear enough picture of the details and some spare time. I'll probably use Java. -- DaveVoorhis

You realize that I'll be taking substantial credit for it, don't you? :)

In either case, my part in RichardsCalculator is close to done. What's next in RichardsSuiteOfTools?

I have two implementations, one is "real" but incomplete (I'll try to finish it soon, but no promises), one is theoretical. They both have the same underlying concepts.

The "real" one is an implementation of the concepts Richard spells out above, but on a standard (Windows) OS and the interface maintaining the standard conventions and concepts of that platform. That means using a context menu instead of a WheelMenu, sorry. Similar chording is possible, though.

The theoretical one I'll describe here as how I would implement it in a NakedObject? environment such as I understand BlueAbyss to be. I do this so that Richard can tell me if I've understood his concepts, at least sufficiently to implement them.

	 lookup: aSymbol

(MathSelectors? includes: aSymbol) ifTrue: [^self standardMath: aSymbol]. (CustomSelectors? includes: aSymbol) ifTrue: [^self customMath: aSymbol]. self invalidSymbol: aSymbol.
-- ChrisMellon?

The way you'd implement calculator modes in BlueAbyss is precisely that you have multiple calculators. How those different calculators are actually implemented (if they share 100% of code then the different calculators are only notional) is immaterial.

What matters is that the .calculation files are the same, with the same file extension. The variable is in the association of the .calculation files to the application. One user may choose to associate them with business, another with scientific, and yet another with all three.

When you've got multiple associations for an object type, the most specific is used by default and the user can switch between applications by flipping the object. This general system of modes (types) are the only modes permitted so that users never have to learn to control modes in another way, and so that the software developer is forced to use a very small number of modes, preferably one.

The differences between "multiple calculators" and "multiple modes of a single calculator" might seem notional but they are not. One consequence of multiple applications is that you can't have an unbounded combinatorial explosion of applications, modes interact but applications never do. Another consequence is that the user has full control over which applications are present in their system. Someone who will never, ever use a scientific calculator simply never has it installed in their system.

-- RK

For a user interface design class in college, I actually wrote a calculator just like this in our custom environment. It was quite fun. But, after I wrote it I found it was missing two major pieces of functionality.

I added a persistent store of constants. Constants were uppercase alpha values (and underscores). They were saved between calculator sessions and were incredibly useful. They allowed me a mechanism to define things like SPEED_OF_LIGHT_MS and FEET_TO_METERS_FACTOR. The system supported autocompletion of constants (but there was no way to enumerate them). The system was defaulted to have several useful constants (speed of light, pi, e, etc.). Any value could be overridden.

The other was session saving. The calculator had another persistent store of named scenarios that were actually entire calculator sessions. You could freeze the current session into a named persistent slot (the HOME and END keys were what started and created saved sessions, but I never liked this solution and wanted something more elegant). Saving the session would clear the interface and start from scratch. Restoring would bring back the entire scrollback and state. The sessions also kept copies of used variables so that it could reproduce the constants, but it patched them in as constant numbers to avoid confusion (only if the variables changed though).

It was one of the more popular programs of the class. I've been thinking it'd make a swell Apple DashboardWidget?, and I might re-create it in that environment. -- DaveFayram

The .calculator objects described above are more elegant than using named slots or special keys. You'd be offloading session management to the desktop and filesystem, where there are already standard tools for object management. The cost of learning your new and improved object (session) management design is not worth any benefit it can bring. And if you really want to build an object management design, then a calculator isn't the place for it. -- rk

I'd concede to that. The environment we ran it in was simple and lacked many of the features you'd need to do a more elegant solution. It was a student-written OS running a student-hacked version of X11. Smalltalk image this was not. Such is the life of a student. However, I do like the constant loading. I found this to be an extremely elegant way to handle it, and I'd say that feature is necessary. It's especially elegant if you can give the users a way to manage the constants that is consistent with all other object manipulations. -- DaveFayram

Just for the record, I did consider variables but I didn't think they were sufficiently important to design in.

Having to add constants actually simplifies the design since it means you get one WheelMenu for constants (for up to 8*8 constants) and another wheel menu for functions. This way, the two wheel menus are strikingly dissimilar and we don't have to agonize over any artificial division of functions. -- RK

MayZeroFive CategoryInteractionDesign CategoryProject

EditText of this page (last edited April 3, 2011) or FindPage with title or text search