5 ms·

Soulver seems mindblowing; I wish the article included more examples of radical divergence from dominant UI trends to reach something even more usable. Mostly

Soulver seems mindblowing; I wish the article included more examples of radical divergence from dominant UI trends to reach something even more usable. Mostly I wish Soulver was available on Android or PC... http://www.acqualia.com/soulver/ http://www.acqualia.com/soulver/

comex 14y ago
The comparison is blatantly unfair, though: the first two examples are iPhone apps that require large touch targets, while Soulver, an OS X app, requires none. A Soulver-like app for iPhone would benefit from history and extended functionality, but for optimal usability, it would still need a screen mostly full of buttons.
- tene 14y ago
  The normal on-screen keyboard (or physical keyboard for those few phones that have one any more) works just fine for text input to an app like soulver. There's no need for huge dedicated buttons when the normal text input works just fine.
- cormullion 14y ago
  Soulver also has iPad and iPhone versions.
- coob 14y ago
  What, you mean like this? http://www.acqualia.com/soulver/iphone/ http://www.acqualia.com/soulver/iphone/
ditoa 14y ago
While not as clean or powerful as Soulver, OpalCalc looks quite interesting http://www.skytopia.com/software/opalcalc/ http://www.skytopia.com/software/opalcalc/
mpyne 14y ago
Interestingly (IMHO), the issue with skeuomorphic calculator apps had been noted by a KDE developer in 2004 (http://dot.kde.org/2004/09/27/kcalc-modest-usability-improvement http://dot.kde.org/2004/09/27/kcalc-modest-usability-improve...), and probably by others even earlier. Unfortunately Roberto's blog post doesn't remain online (Archived here: http://web.archive.org/web/20041010185905/http://www.pycs.net/lateral/stories/33.html http://web.archive.org/web/20041010185905/http://www.pycs.ne...) This lead to the development of several calculator replacements to take advantage of the fact that a desktop has perfectly good keyboards hooked up, can afford to show good history, etc. I wrote one (which is now being maintained and ported to QML by someone else), but the most popular one seemed to be SpeedCrunch (http://code.google.com/p/speedcrunch/ http://code.google.com/p/speedcrunch/) or Qalculate (which KDE's KRunner supports using for inline expression evaluation nowadays, IIRC).

comex 14y ago

The comparison is blatantly unfair, though: the first two examples are iPhone apps that require large touch targets, while Soulver, an OS X app, requires none. A Soulver-like app for iPhone would benefit from history and extended functionality, but for optimal usability, it would still need a screen mostly full of buttons.

tene 14y ago
The normal on-screen keyboard (or physical keyboard for those few phones that have one any more) works just fine for text input to an app like soulver. There's no need for huge dedicated buttons when the normal text input works just fine.
cormullion 14y ago
Soulver also has iPad and iPhone versions.
coob 14y ago
What, you mean like this? http://www.acqualia.com/soulver/iphone/ http://www.acqualia.com/soulver/iphone/

ditoa 14y ago

While not as clean or powerful as Soulver, OpalCalc looks quite interesting http://www.skytopia.com/software/opalcalc/ http://www.skytopia.com/software/opalcalc/

mpyne 14y ago

Interestingly (IMHO), the issue with skeuomorphic calculator apps had been noted by a KDE developer in 2004 (http://dot.kde.org/2004/09/27/kcalc-modest-usability-improvement http://dot.kde.org/2004/09/27/kcalc-modest-usability-improve...), and probably by others even earlier. Unfortunately Roberto's blog post doesn't remain online (Archived here: http://web.archive.org/web/20041010185905/http://www.pycs.net/lateral/stories/33.html http://web.archive.org/web/20041010185905/http://www.pycs.ne...) This lead to the development of several calculator replacements to take advantage of the fact that a desktop has perfectly good keyboards hooked up, can afford to show good history, etc. I wrote one (which is now being maintained and ported to QML by someone else), but the most popular one seemed to be SpeedCrunch (http://code.google.com/p/speedcrunch/ http://code.google.com/p/speedcrunch/) or Qalculate (which KDE's KRunner supports using for inline expression evaluation nowadays, IIRC).