▼
Posts: 1,278
Threads: 44
Joined: Jul 2007
So since this seems to be an item of passion for most, lets have a discussion about soft menus! :-)
I personally think those that say "soft menus are the most perfect interface" are cutting themselves short and not thinking broadly enough. While a good mode of operation, they really came into existence basically ONLY because you were limited to physical keys at the bottom of the screen.
Since you now can use the whole screen instead, and there is more need for flexibility to do other future things, all of that needs to be thought about together.
Advantages of soft menus:
1. Traditional HP calc style interface.
2. Remain on screen for quick re-use of this *particular* set of commands. If you are reusing *this* set, it is great.
Disadvantages of soft menus:
1. Traditional HP calc style interface (unfamiliar to vast majority)
2. Quite limited space for text/icons/things. Most commands are more then a few characters...
3. Nested soft menus are difficult to learn. I personally always found myself searching for things on the 48 series except for a small set of those I used very frequently. Diving into the math menu and trying to locate the location of an unfamiliar matrix command for example... :-(
4. Limited to "6" at a time.
5. Navigation around is not very quick. If you are doing one thing, and switch to a completely different set of commands, this is not exactly amazingly fast. Might be "only 4 keystrokes", but not exactly the best UI ever invented.
Other items to think about:
1. There is no need to limit to the bottom of the screen with a touch screen. While still a good location for finger proximity reasons, technically "menus" could now be anywhere.
2. What about when prime or something similar to it moves to a pure touchscreen? Does the traditional "soft menu" idea make sense or how does that modify/multiply/adapt?
I think there is plenty of space for some really interesting discussions and thinking around these and other related topics.
TW
Edited: 4 Oct 2013, 1:13 p.m.
▼
Posts: 37
Threads: 7
Joined: Sep 2013
Tim,
Thanks for requesting feedback on this. I had a couple of thoughts after my first week with the device and emulator:
1. The APPS key icons layout is not too bad to navigate. Perhaps other menu launching keys (Vars, Chars, Toolbox, Mem, Units...) could also use (nested?) icons to navigate? Apple IOS "folders" might be a good benchmark to shoot for.
2. It would be handy if the 4 way nav rocker would allow Left/Right movement on the MAIN soft menu of the VARS and TOOLBOX keys.
3. Some more description of whats in the soft menus/trees would be handy. For example, showing the VALUE of whats in the Real "A" register would be good. A preview of the user functions might be helpful too.
Best,
Carl
Posts: 349
Threads: 66
Joined: Apr 2007
Hi Tim,
I agree that for a large touch screen, limiting soft menus to the bottom row and only 6 positions is artifically restricting one's self. I wholeheartedly agree that having to traverse through groups of 6 functions at a time - either "sideways" to another row of the same menu or "downwards" to sub-menus - was a nice solution for a single row of physical keys, but is an unnecessary limitation for a two-dimensional screen. In fact, I'd think that the native programming of the machine should enable users to create "soft keys" anywhere on the screen with customized labelling in order to accept touch input for various aspects of a program. On a "touch-only" implementation on (let's say) a tablet, perhaps menu choices could occupy several rows and/or columns of choices, should they be necessary. Maybe multiple windows should be available on a large screen, each of which could have its size controlled and scrolled through by the user - one with soft key rows and columns; one with data, like an RPN stack whose displayed size could be controlled by the size the user chooses for that window; and one with graphic plots, among others. Each could occupy the entire screen or a subset of it and the user could use some touch sequence to step through these windows individually. Just some ideas off the top of my head.
Thanks for listening,
Jake
Posts: 2
Threads: 0
Joined: Jun 2013
Hi, Tim
I disagree with you in that soft menus are outdated, or that people are unfamiliar because they are almost exclusive to HP calculators.
Soft menus were on the PC long before the HP48, my GWBASIC had the programmable function keys at the bottom of the screen, so did most DOS applications.
Clam shell cell phones from 10 years ago had soft menus (mine had only 2 soft menu keys, but it counts).
Now fast forward to the present, and you can see Android tablets with soft keys at the bottom of the screen ( for home, back, etc. not quite like the old soft menus but somewhat similar). We also got brand new IP phones at my office this week and guess what: they have a color screen with soft menus at the bottom.
Soft menus use a small amount of space. Anything "modern" takes up a lot of screen. The menu is not what you are trying to display, but you equations, your code, etc. In that regards, soft menus are out of the way. Often, showing a full menu won't let you see what you are working on (happens too often on tablets and phones with those huge virtual keyboards).
I don't think soft menus are bad. You could try to reorganize on the edges of the screen, perhaps making them at the bottom but multiline to have more than 6, etc. but don't go too far.
In my opinion the "cool" UI's end up being too slow to use and often impractical.
Just my 2 cents.
Claudio
Posts: 291
Threads: 63
Joined: Jan 1970
This Message was deleted. This empty message preserves the threading when a post with followup(s) is deleted. If all followups have been removed, the original poster may delete this post again to make this placeholder disappear.
▼
Posts: 709
Threads: 104
Joined: Nov 2005
Quote:
Tim,
What's that "something similar" and "pure touchscreen"?
Do you guys have some more goodies up your sleeves?
Chris
Well, I sorta hope it doesn't go pure touchscreen. One of the reasons physical keys are nice is that you don't have to look to know whether you typed something. Imagine using an iPad that had a keyboard displayed on the screen. I don't think I could type well without looking at the keyboard in that case.
▼
Posts: 1,278
Threads: 44
Joined: Jul 2007
So this statement is more centered around the idea that you have two ways to do a "software only" version of something. Either it looks like the physical device (an emulator on a tablet with a picture of the device and "buttons" to click on), or else a more "native" version that uses the system widgets and similar.
The first is is basically how all the "calculator" emulators act right now. The second is how "tablet designed" math stuff works.
Both have many advantages and many drawbacks in different ways. Thinking about both forms is important I think.
TW
Edited: 4 Oct 2013, 2:38 p.m. after one or more responses were posted
▼
Posts: 709
Threads: 104
Joined: Nov 2005
Ahh... I see... well, that does leave me in a dilemma as I actually like both =)
Edit: is this going where I think it might be going? Will we see an HP Prime app for tablets? That would be an immediate hit with teachers who already own tablets. I know I'd buy it! Especially if they can also beam their screen to an overhead projector and/or sync with an actual calculator (i.e. use the calculator keys to control the tablet screen) -- not to mention the class room software manager.
Sorry, I digress...
Edited: 4 Oct 2013, 2:40 p.m.
Posts: 709
Threads: 104
Joined: Nov 2005
Since we have a touchscreen, you are right in that "soft menus" don't have to be anything like the ones from the old days. That said, I do think it is important to consider things like:
1. "Soft menus" enabled users easier navigation to commands WITHOUT covering the screen. Yes, that makes them harder to read, but they can still access the menu without the menu hiding their work. As a simple example, press [Toolbox] [6] [8] to bring up the polynomial algebra submenu. The screen is filled with nothing but menus! :-)
2. I don't think the directional left/right should switch menus in the main screen; they should be left to switch to submenus or back to the parent menu. On the other hand, using a swipe on the title of a menu perhaps could be turned into change into a different menu. Or even swiping the menu could be the equivalent of the [NXT] button on the older HP48. This, of course, assumes we keep with the old HP menu concept. I am not particularly attached to a particular form of a menu so long as #1 above is accounted for.
3. We aren't limited to "6" items any more -- just swipe left/right on the menu to load up the next page. This way, you could even make each menu wider (say 5 or even 4 per screen) and just have little arrow indicators indicating to swipe left/right for more.
Edited: 4 Oct 2013, 2:29 p.m.
Posts: 528
Threads: 40
Joined: Dec 2008
There are really two issues that soft keys address.
-
NAVIGATING a hierarchy of functions to get to the one you want.
- Making a set of functions easily accessible because you want to use them to solve the current problem.
Navigation can be done with drop down menus like the Prime.
The real problem with these machines is that the "right" set of functions never seems to be shown. We've argued over which functions are "right" forever, but the answer is actually simple: the right set of functions is a PERSONAL CHOICE that depends on the problem being solved, and user solving it. Everyone's idea of "right" is different.
One thing that would make soft keys more useful is if pressing [shift] would automatically change the labels to the shifted function. Now you have 12 easily accessible functions instead of 6. Another would be if holding the shift key also changed the labels. Now there are 18 functions easily accessible. I think this would be a lot more useful than the 48/48/50 [Nxt] button.
But I think the real boom in interface design is in user assignable keys. Imagine this:
-
You press the [USR] key
- The screen changes to a map of the keyboard showing the functions currently assigned to each key.
- If you now press [SHIFT], the map changes to show the shifted functions
- When you select a function, the screen returns to its previous state.
If there isn't enough room on the screen for a full keyboard map then it could show just part of it. For example, on the Prime, it might show just the white and gray keys.
The beauty of this solution is that you don't have to remember which key is assigned where. The display would show you.
The calculator would come with several possible user key assignments built it - the Programming keyboard, the Calculus keyboard, the Financial keyboard, the Statistics keyboard, etc.
The real power would be in letting the user create their own mappings. On the Prime, there are 36 white and gray keys, excluding [shift]. That gives 72 possible functions. I suspect that most problem domains don't need more than 72 functions.
On a tablet, pressing [USR] would change the labels on the keys themselves, assuming that there are keys or buttons or something.
▼
Posts: 153
Threads: 7
Joined: Jun 2008
I agree 110% with David Hayden regarding user customization, but I'd like to focus here on customizing the screen. I should be able to put any function or feature anywhere on the screen, simply by dragging it there.
Here's my dream: I just drag the functions I need, off the Toolbox Catalog (or from anywhere else), and onto a menu button, to customize that button (having blank buttons is crazy!). I can also drag functions to the top of the screen instead, to create a new "tile" (a flat button, à la Windows 8) because I need my tools more than I need a dozen lines of history (what a waste of space!). The buttons & tiles are as wide as their name. I can rearrange my buttons and tiles by simply dragging them around. And when I'm done with a button or tile, I just drag it offscreen, and *poof* it's gone.
Dave's idea is great: When Shift is pressed, all the buttons and tiles change to show their shifted names, which of course are also customizable.
I can quickly toggle all the buttons and tiles on and off whenever I want to access the entire screen.
The buttons & tiles can also have named macros... not just programs, but ANY key sequences, like the HP 50g can.
That's my dream.
-Joe-
Posts: 64
Threads: 10
Joined: Sep 2013
So far my biggest issue with this calculator is that I'm always swimming around and taking too much time to do so. Soft keys seem much faster to me and if I could put what I want in my own menus, I would be much faster! And its done without interrupting my work on the stack.
For example, presently I hit the toolbox, then hit user, then hit my program, then hit the thing again because it seems to want me to select the function in the program ... too much in my opinion. I want to run a calculation over and over with out working for it. With soft keys once I have my own dir open, I can easily do many programs in one key stroke and its not interrupting my work flow as the stack is fully functional. I would like the ability to put anything in the soft menus as well, not just my stuff. I could really rig a dir tree right for a test this way.
Another example of soft key being superior in my opinion is base conversions. This calculator has me working for my super but the soft keys on the 48 had me doing it all without breaking a sweat.
Bells and whistles are nice but I don't like to leave the stack unless I have to as its costly. If I take the time to go to an app its because there's a particular question on the test that its very useful for, just as it was on the 48, but I only want to waste the time because its extremely beneficial. Another thing that wastes my time is requiring me to use the ' ' (its actually two stokes as shift is needed) keys to enter a formula in an app in RPN mode. The 48 did it for me, but this calculator has me hitting extra keys.
Now its not like I'm some super fast and extra efficient A++ student, but what I need is to not think extra as it drags my grade down further LOL. I wanted a new and improved HP RPN calculator along the same philosophical lines as I've seen in the past and I think this calc may be geared toward a different crowd. I'm not taking this calculator with me to any more tests at the moment due to this. It really makes things keystroke intensive in my opinion. It sure is a beautiful calculator and I'm going to keep trying to get used to it.
Thanks for asking and that's my two cents :)
Edited: 5 Oct 2013, 12:03 a.m.
Posts: 764
Threads: 118
Joined: Aug 2007
This is tough because I believe a balance is needed. I prefer soft keys and menus to "traditional TI-80s menus" because they don't take up the whole screen - you can see what you are doing.
Having said that, I like the grid for math and Greek characters. We should have one for common International characters (dependent on the language setting).
I like the idea of User keys. I think for the next calculator, User is not a shifted function. User gets its own key, like the HP 41C.
Posts: 18
Threads: 2
Joined: Sep 2013
I've been enjoying this discussion. I think the new Prime is great and it is fun adapting to it. I come from the more traditional background of the HP-67 and 28s. I missed the 48-50 generations, but I had experience with early versions of user soft-keys, directories, etc with the 28s. So it has taken me a little while to adjust my thinking.
I think there are two separate but related issues: (1) user-definable soft-keys, and (2) a hierarchical directory structure where soft-keys, etc, are automatically set up on each level in the directory structure based on the definitions at that level.
Regarding 1 - soft-keys: I like the idea of having user-defined soft keys available. I think having user-defined functions available via a button on the screen essentially treats the user functions as first class functions available in the same way that normal (physical) un-shifted keys. I think this capability (in one form or another) is really important for the Prime to be treated as a great calculator for professionals. However, I also agree that since they are just buttons drawn on the screen, I have no problem drawing them anywhere on the screen as long as they could be activated with single touch. We need more capabilities to do that.
I noticed that there is a DRAWMENU() function that I've played around with a bit, so it seems like someone is thinking that users may eventually be able to define semi-classic soft-keys. What is missing is a simple way to attach functions to be invoked with the soft-keys are pressed.
On the other hand, I think a lot of the types of functionality that we wrote into old user soft-key libraries can be done with the new and powerful Apps functionality of the Prime. But I'm not convinced that all user applications will fit so cleanly into the Apps concepts with its buttons and views (as implemented on the Prime). Even if Apps are the answer to all user applications, they will probably need soft-keys of their own in many cases, and the tools for users to define soft-keys for their Apps is currently mostly missing.
Regarding 2 - User directories: I am a bit concerned about this. My current understanding of the Prime is that most everything in terms of functions and variables is in the global namespace (for the most part, ignoring differences between Home and CAS views). And yes, I'm aware that Apps have their own namespaces, which may reduce the validity of some of my arguments.
One the the great features of the hierarchical directories is that scope of your functions and variables was controlled in clear, predictable way. If you wanted things to be globally available, you put them at the top of your directories. But if you had functions that were specific to a particular problem, you could put them deeper in the directories without worrying about polluting the global namespace. I do not see anything quite like that in the Prime (other than the App namespaces, which I'm not yet convinced will be enough).
The evolution of computer science in the last few decades has made it clear that (for the most part) having all of your functions or data in a global namespace will eventually lead to trouble. I think the prime needs some way of partitioning user functions and data (like hierarchical user directories!). I like the LOCAL declaration in programs/functions and it is a valuable addition to PPL that will help with this issue. Note that in a lot of more modern languages (eg, Python and Modula-2), data is modularized and imported as needed and there is very little global data. It might be a bit much to incorporate some of those features into PPL, but it is worth thinking about.
I really appreciate the thought and work that has gone into the design of the Prime and I look forward to its evolution in the coming months and years!
-Jonathan
Edited: 4 Oct 2013, 11:58 p.m.
Posts: 79
Threads: 3
Joined: Jun 2010
I like soft menus, they are straightforward to use. About your list of disadvantages, please take a look at the TI 86 (85 too), IMO they got it right: Nested menus appear as double menus, the parent on top, with a highlighted cell for the selected item. If the row has more than 5 items, there is an arrow pointing to the right, you get to the rest of them by pressing 'MORE' (the equivalent of 'NXT', I never understood why the 50G doesn't have this visual cue). You get out from the submenu by pressing 'EXIT'. Of course, with a touch screen you don't need dedicated keys for these actions.
They should be at the bottom of the screen if you don't want to lose sight of the command line/history. If they were at the top of it you would be looking at your hand instead. At the sides it seems kind of awkward for a number of reasons.
Posts: 1,089
Threads: 32
Joined: Dec 2005
Quote: What about when prime or something similar to it moves to a pure touchscreen?
Then you could sell apps instead of calculators as the hardware is already there in abundance. Not a bad idea as the target audience are students used to smartphones and tablets anyway.
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
Disadvantages of soft menus:
4. Limited to "6" at a time.
Not necessarily. Please look up the 43S design study. With a touch screen you can save the top row of keys there.
Quote: Other items to think about:
1. There is no need to limit to the bottom of the screen with a touch screen. While still a good location for finger proximity reasons, technically "menus" could now be anywhere.
The results could be anywhere as well. What a mess! Some screen structure shall remain IMHO.
Quote:
2. What about when prime or something similar to it moves to a pure touchscreen? Does the traditional "soft menu" idea make sense or how does that modify/multiply/adapt?
You'll gain a lot of flexibility but don't expect selling HW anymore then. There will be smartphones hosting calculating apps replacing traditional calculators. Simply less HW to carry with. 'Calculators' will become a pure SW business. Expect lots of computing power but less functions per surface area than via keys. Structuring the UI and giving a real good overview over the function set will become more important. BTW, do we know anything like a touch screen with tactile feedback? It may come.
At the bottom line, it's all a matter of cost again. When touch screens become cheaper and more durable than arrays of physical keys (and as reliable as these were) the market will flow there as it did before.
Just my 2 cents.
d:-/
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
Quote: BTW, do we know anything like a touch screen with tactile feedback? It may come.
Vibration! And it works if it doesn't lag behind.
OT: Unfortunately, the go* kind of emulators always vibrate, no matter if you hit or miss a key.
Posts: 15
Threads: 3
Joined: Aug 2013
I think softmenu keys should remain at the bottom of the screen, and that they vary in width to accomodate their text. Multiple pages of keys should be accessible by swiping right and left. An ability to show more rows of keys should be possible, to a maximum of about 3 rows.
Softkeys should be able to trigger commands, bring up menus and toggle state - as they do now. Other types of widgets should be introduced like sliders, visual iphone like toggles and even read only and also user editable numeric and text input and output fields perhaps. These widgets would live in the same area as the buttons at the bottom of the screen, but also be able to be placed elsewhere on the screen if one went to the effort of programming it. It should however be easy for the user to define the softmenu area at the bottom of the screen and slightly harder to position these widgets anywhere on the screen.
I guess in traditional GUI’s and Desktop and Web Applications, forms, menus, toolbars and other ‘more advanced’ widgets are the ways we interact with the application. Hp Prime softkeys should borrow from all these paradigms, to the degree that it makes sense.
And no matter how many widgets are developed, the primary metaphor I believe should be several rows of widgets, at the bottom of the screen, that can be paged through by swiping and maybe even rearranged to the user’s desires, so that the most often used widgets are grouped together. And it should be up to the user to show more widgets per page by increasing the number of rows visible per page. Screen real estate in some cases may not be as important as having ready access to all the important soft keys/widgets without needing to swipe.
Not sure about nesting widgets into hierarchies - I think that might be going a step too far and simpy having different ‘sets’ of widgets that can be enabled is enough - keep it flat.
Thanks for asking for the communities input, Tim!
▼
Posts: 1,278
Threads: 44
Joined: Jul 2007
The big issue always boils down to "the more customizable you make it, the more chances to screw up a lot of stuff" and hence much more time needing to spend making sure every possible combination works, is thoroughly tested, doesn't break something completely and so on.
TW
▼
Posts: 64
Threads: 10
Joined: Sep 2013
Without softkeys what do we have though? We can go Shift User to access a reassigned key that we have to remember that we wrote a program for. Lots of key strokes and its not easy to remember beyond a few reassignments.
Posts: 3,229
Threads: 42
Joined: Jul 2006
My usage of the 28 and 48 series avoided softkeys almost entirely. I found it much faster to switch into alpha mode and type the function name directly. Especially on the 28 with its second keyboard.
Part of this was learning where all the commands were in the menu hierarchy of course.
- Pauli
▼
Posts: 37
Threads: 7
Joined: Sep 2013
It might be nice if the PRIME could suggest auto fill based on first few alpha letters keyed in.
Posts: 125
Threads: 9
Joined: Oct 2011
Quote:
...
1. There is no need to limit to the bottom of the screen with a touch screen. While still a good location for finger proximity reasons, technically "menus" could now be anywhere.
2. What about when prime or something similar to it moves to a pure touchscreen? Does the traditional "soft menu" idea make sense or how does that modify/multiply/adapt?
I think there is plenty of space for some really interesting discussions and thinking around these and other related topics.
TW
I thought that the two-level nested soft menus of the HP 48 family onwards were too cumbersome and hard to remember. So I went back to the HP28s which is generally fine for an interface driven by calculator buttons.
On the other hand, if you are able to utilize the whole screen for touch-screen user interaction then you can make good use of input forms with buttons, prompts or pop-up menus. With the right level of abstraction it should also be possible to allow straightforward user-generated dialogue boxes, input forms, prompts and menus. Some good precedents for this aspect already exist in the HP 48GX onwards as well as in the early releases of the Smalltalk language/environment in which a GUI prompter was as easy to write as a print and input command in a traditional command line interface. Unlike the HP 48GX, users with this proposal would then be able to touch directly on a input field to start entering data, rather than fiddling with keys to move around the fields which was a truly cumbersome experience. The advantages of a tactile keyboard are retained for the actual data entry, numeric as well as symbolic expressions etc., and for inputting alphabetic strings directly.
Nick
Edited: 7 Oct 2013, 3:30 a.m.
Posts: 113
Threads: 20
Joined: Sep 2013
I would leave the soft keys the way they are now - - six at the bottom of the screen - - aesthetically, that matches the upper rows of keys, starting with A, . . . , E, and DEL. Otherwise, things could quickly degenerate into a chaotic display, and not nice to look at. And, my screen is already full of greasy fingerprints!
The only thing I'd change would be a user option to define his/her own soft key (if there is an unused one, which there seem to be quite a few).
Never liked pure touch screen devices . . . I prefer the tactile feedback from hard keys. And here, the Prime is about perfect!
|