Ok, so I don't like KCalc much. I think that usability-wise, it's the worst KDE application ever. So here's a proposal for a replacement. And since code speaks louder than words, here's an implementation too (PyQt).
[Ed: Screenshot of Roberto?]
Dot Categories:
Comments
Didn't you just reinvent bc(1)? Anyway, what you wrote is an alternative, not a replacement. Replacement requires a functional equivalent, and to many people, a CLI style interface is not functionally equivalent. (I, on the other hand, use bc(1) all the time.)
Remember derive.exe?
An algebraic calculator that made you derive functions, plot functions and so on. algebraic transformations
Heard of it, never used it, though.
I generally agree that KCalc is inefficient to use for a an experienced user. I would probably prefer bc instead. Does anyone know of a calculater with a command-line interface that can handle units? Something like Mathematica's 'Units' package would be very nice.
Handles unit conversion and anything you can throw at it.
perl -e 'use CGI::Util qw(escape);print "Eval: ";while(<>){chomp;open(G,"lynx -source \"http://www.google.com/search?q=".escape($_)."\"|");while(){if(/<\/td> <\/td>(.*)<\/b><\/td><\/tr>/){$r=$1;$r=~s/<(.*)>//g;print "$r\nEval: ";}}close(G);}'
Nice one!
hmm.. As far as I can see no one has actually proposed the rather simple usability improvements that needs to be done.
* All functions but addition, division, multiplication and substraction must be removed. Most people don't know how to use the other functions, so they will get in the way for 95% of the instances the calculator is used. Add a button for "scientific functions" to unfold those. Memory functions can stay as well.
* rename the program to Calculator. KCalc is not very elegant, and is also somewhat disctracting, since it isn't clear what purpose it has to name it in this fashion.
You want a real calculator?
This is a REAL calculator:
http://futureboy.homeip.net/frinkdocs/
Add it to your Sidebar/navigation panel and voila a sensational calculator integrated into KDE.
Right click on empty sidebar and click Add New then Web Sidebar Module. Use this URL:
http://futureboy.homeip.net/fsp/sidebar.fsp
Hey, why don't you do the same think with the KDE CD player? People can type in "start 4" to listen to the 4th track, "random" for shuffle mode, "stop" and "eject". Why using buttons at all?
Why do we use a _G_UI at all? The shell is enough.
If you really want to be serious, you have to think a little bit more to provide real improvements.
Ok, go read the article carefully, then the rest of this post.
Done yet?
Here´s why play/ffwd/etc buttons on the CD player make sense:
Your keyboard usually doesn´t have a play button.
Come on. My keyboard doesn't have a Pi button, nor Sinus/Cosinus buttons.
As many posters pointed out, extensions like a payroll are nice. Removing the buttons would confuse the majority of users.
The app you see there is just a quick hack. The article says that.
Your keyboard lacks a pi button. However, your keyboard has a P and a I buttons. You can click them in sucession, and you end with pi. Guess what, that´s pi ;-)
But I kinda agree that maybe **some** buttons would be a good idea. I am not a goddamn taliban of buttonlessness. However, those buttons should only be enabled in a trig mode. On the usual 6-operations use (and come on, almost nobody uses calculators for anything else), those buttons are only clutter (and kcalc doesn´t show them by default either, or does it? (not on Linux right now)
When I first read your article I thought you were kidding. Well there are numerous reasons why you are wrong for most people. I give some of them:
a) People have been trained to use physical calculators with kcalc's current layout since years. They are used to a calculator with such a layout/look and feel and that makes them feel comfortable when using kcalc -- they feel right at home. Actually that is the best thing that could ever happen when it comes to usability.
b) already mentioned: accessibility
c) While the user might use the keyboard in your approach he's completely lost when it comes to the available _valid_ set of keys. Which keys that I see on my keyboard are valid numbers and operations in the respective mode?
Am I allowed to type #66, &, **, ^, ~, ++, a, b, c, A, B, C, $, <, °, ?, !, ... or any other possbible key that I find on my localized physical keyboard? Am I allowed to use the A-Key (Hex) while being in decimal or binary mode? With the valid keys still appearing on the screen in their respective disabled/enabled state the user can _SEE_ what input might be valid and which isn't. That way he has full control over the possible actions he might take.
On the other hand it's true that kcalc needs improvments:
- The Trigonometrie, Statistics, Logical, Exp/log and Constant -buttons menuentries should go into a settings-dialog.
Instead kcalc should default to a simple mode and have menu-items called "Simple calculator", "Scientific Calculator", "Ticket-Tape" and "Custom" available (with custom being the tweaked layout in the settings-dialog).
In addition kcalc should have a history and should be renamed to kcalculator to avoid confusion.
In addition developers should look at the layout of current physical calculators and match their average common layout as close as possible.
If there are common well-accepted layout-standards like this available it's complete nonsense to reinvent a new "standard" that nobody but KDE is using.
Greetings,
Torsten Rahn
I will try to reply to your points:
Yes, I am joking, partly. More on what I proposed as a solution than on what I see as a problem, but on both sides I am joking somewhat.
Here's some more serious reply:
a) No, sorry, you are confusing usable with used to. Something can be more usable and yet not be practical because of habit. That doesn' t mean that it is any less usable. It only means that achieving adoption is harder.
Otherwise, we should all use windows, and KDE should clone it. Everyone has years of training on windows, after all.
b) The accesibility argument is wrong. What is so special about a calculator? I enter numbers on my phonebook. Why doesn't my phonebook have a on-screen keypad?
If on-screen input is so important and the current accessibility solutions don' t fix it, then then the right thing to do is work on the accessibility solutions, not on the calculator.
c) Every key is valid. It doesn't have modes. Modes are usually considered bad usability anyway. And you can trivially do wrong input in kcalc. 2/0. Error.
I don' t see any actual usability rationale in your post except "people are used to physical calculators", and I don't think much of that one.
d)
> a) No, sorry, you are confusing usable with used to.
Usability is not only about doing things the easiest way. It's _also_ about ways that people are used to. Otherwise KDE would have explored a much more radical approach to offering a GUI right from the start. But as we knew that acceptance is also about delivering solutions that the user is used to and where he feels right at home we went for the "clone a Windows/OS2/Mac-Interface with improvements"-way.
> Something can be more usable and yet not be practical
> because of habit.
If that habit has become a widely used standard that is considered to be easy to use by the general public then it makes absolutely no sense to reinvent the wheel. I wouldn't even be surprised if there existed ISO-Standards around calculators already.
Do you really believe that the manufacturers of physical calculators will adopt your layout? No? Then you are in trouble, because it will mean that people who are used to the usual layout will have to relearn the way they treat their calculator every time they use KDE.
> Otherwise, we should all use windows, and KDE should clone it.
> Everyone has years of training on windows, after all.
Just in case you missed it: We do already clone Windows most of the time for the reasons stated above. And most of the customers of the company I work for chose KDE just for that particular reason.
> It only means that achieving adoption is harder.
s/harder/close to impossible/
> b) The accesibility argument is wrong.
> What is so special about a calculator?
If you don't show the number keys then it will mean that people with disabilities which make it impossible for them to use a keyboard won't have a way to make their input. Of course they could use an on screen-keyboard but then they have to worry about switching between the calculator and the onscreen-keyboard which is rather an unnecessary pain. Also on an onscreen-keyboard you have about 104 keys they will have to choose from and the additional keys that exist on your calculator - makes about 124 keys to choose from. That's actually twice more than choosing from the about 50 keys on kcalc in scientific mode!
Also people with cognitive or learning disabilities find it difficult when the presentation, interaction style or task flow varies. If there is no consistency between different calculators, users will have to repeatedly relearn the procedure.
On the other hand blind users will definately be happy to use the keyboard, but they can do this with the current calculator already
> I enter numbers on my phonebook.
> Why doesn't my phonebook have a on-screen keypad?
It should. That's why even PDA's which optionally can be used as mobiles emulate the well-known phone-layout on the screen (even if they offer the numbers on the physical qwerty-keyboard). And that's also the reason why ATM's don't use the button-order of a qwerty-keyboard but that of a phone/calculator instead.
> c) Every key is valid. It doesn't have modes.
> Modes are usually considered bad usability anyway.
No. While this sentence might be true in some situations it is false for many others.
Take konqueror for example: currently it doesn't offer any real modes.
Therefore while in "webbrowsing-mode" it still offers lots of operations which only make sense in "file-browsing-mode". That's why many users feel that the interface becomes cluttered with unnecessary options and feel lost because of the overwhelming number of menu-entries.
Once konqueror will offer true seperation between webbrowsing and filebrowsing mode it will offer less menu-entries which are better focused on the task.
Same for the calculator: They are using modes because the prevent errors for the very same reasons why programmers like a language to be type-safety.
> And you can trivially do wrong input in kcalc. 2/0. Error.
Just because you can already do wrong input it doesn't mean that you shouldn't try to guide a user to prevent wrong input.
Actually I think that your proposal would harm usability of kcalc because
- people would have to choose from 104 keys to find their needed keys. People who work on notebooks don't even have a easily accessible number-pad so they are f**cked.
- people don't see which inputs are valid and feel overwhelmed by the number of possible or not so possible keys they can or can not use as an input. They don't feel guided at all.
I seem to have missed where I said KCalc should be replaced. I only said it sucks, and Usecalc sucks less :-)
why not have a look at Qalculate! (http://qalculate.sourceforge.net/). it uses gtk+ for the gui, but it wouldn't be hard to make a kde version.
Roberto was *obviously* just making fun of the KDE usability "experts". He applied literally a few rules found in some book somewhere, to an app that is very special. The result was, ofcourse, that it became not only useless but also redundant (you can get the same thing with Alt+F2 or Google or bc or dc or python or lisp or.......)
This was just a joke on some recent events here on the dot, like when venerable Mattias Etrich proposed that KMail keybindings should strictly follow focus, or when a bunch of loosers cried that amaroK interface sucks because it doesn't have a proper menubar or toolbar.
Well as I always say, when you do something you do it right! So Roberto, for start, your Usecalc doesn't seem to have a toolbar? You absolutely need a toolbar or it's not a proper KDE app! The toolbar can have buttons for Copy, Paste, Print and other such stuff but also a Go button, just like the one seen in Konqueror besides the URL bar - that button would Perform The Calculation.
Also please make sure that the arrow keys scroll the history only when it has focus! When the entry textbox has the focus, you can do something else e.g. you can do like bash, just bring whatever was typed earlier or something.
:)))))))))
The history has NoFocus policy, it has no toolbar because I don' t want to put "1" "2" "3" and so on in it, and I posted it before the amarok thing, but you are **partly** right.
Why partly?
a) It is actually a quite nice calculator. I *do* like it more than kcalc.
b) No, Alt+F2's calculator (which I didn't know) is too limited (no floating point?)
c) It is nicer to use than bc/dc/lisp/python because you can fetch the results for reuse in a much nicer manner.
d) I am kinda partial to providing a trig toolbar and a statistics toolbar (which would start disabled). I may release usecalc 0.2 someday (Now with kicking power actions!)
I really like KCalc as it is, except the fact that when you do things like: 2.0 + 2.0 you get 4.000000000000001 to the screen. It may not seem that annoying, but it can become very annoying when just trying to balance the checkbook. I do some programming and I know it wouldn't be that hard to add a persistant mode, so that KCalc can watch the precision coming in and make sure that the number going out is matched to the largest precision when it is displayed to the screen. This means that if you enter 1.2 + 1.24 you should get 1.44 or 2.0 + 2.0 will be 4.0, just my take.