Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Has anyone given thought to some keyboard shortcuts they'd like to have in NORMA? I'm an avid Photoshop user, and they way you can access almost every command via mouse UI and keyboard shortcuts is fantastic. It lets beginners see what they can do, but doesn't tie the power users into mousing back and forth on the drawing surface.
Since NORMA is a very spatially-oriented design surface, I think it's appropriate to not have to leave the area you're working in just to change tools. Right-clicking has its uses too, but that can get old really quickly.
To the development team: Is there anything preventing us from listening in on keystrokes when the design surface is active?
To everyone else: What shortcuts would you like to see?
In my mind, you press the keyboard shortcut and it's equivalent to clicking on one of the Toolbox icons. It activates the creation of that element for the next time you click on the design surface.
Here's my wish list:
o - Object Type
O (shift-o) - Subtype connector
f - Fact Type
u - Internal uniqueness constraint
U (shift-u) - External uniqueness constraint
r - Inclusive Or
R (shift-r) - Exclusive Or
b - Subset constraint
g - Ring constraint
q - Frequency constraint
n - Model note
N (shift-n) Model note connector
In my list I've tried to keep with obvious mneumonics for English, but those break down quickly where you have overlapping letters, eg. equality, exclusion, exclusive or, external uniqueness. To help avoid these collisions and to keep conceptually similar things on the same key, I've added the shift key as a modifier.
There's room for debate whether, for example, "Object Type" and "Subtype connector" are conceptually similar-- in that case I needed something that wasn't "s", and the connector didn't fit in well with anything else except "Fact Type". So are you modifying the object type by making it a subtype, or are you declaring a subtype fact type? I know what's going on under the covers, but I liked "O" better than "F" for the subtype connector. Maybe "O" is better off as "Value Type", since "o" in this case is really selecting "Entity Type". As I said, lots of room to debate that one.
For cases where you can choose from a small, finite set of options, maybe ctrl-up and ctrl-down could go through the list. An example would be when an internal uniqueness constraint is selected. Ctrl-up or ctrl-down toggle "is primary", perhaps. That has implications if there's already a primary identifier specified, so maybe it's disabled until you toggle the other one "off". Cycling through the ring constraints this way could be nice. Maybe the inclusive/exclusive or? How about incrementing/decrementing a frequency constraint this way?
Apologies for the long post, but having some of these "power user" features would be helpful to my efforts. I usually end up modeling with a Wacom tablet so I can "mouse" around faster. Thanks in advance to any discussion or critique of this suggestion!
-- Tyler Young
I don't know what shortcuts are already in place. There have been some mentioned in release notes, forum posts and replies, etc..., but I don't think there's a published list of what's running currently. Not knowing, I tend to look for context menus by default. Maybe the tool isn't at the point where shortcuts should be used - how would you feel if ones you got used to were changed in a later version?
Giving some thought to using NORMA on a notebook PC would be another consideration. While most modelers are likely to do the heavy lifting on at a workstation, at least some preliminary, or modification work at a client's site may be called for. Having diagram manipulation options to suit the task and the hardware couldn't hurt.
Then there is the current tie in to VS. Do you reinforce the links and dependencies to the VS IDE, or should the tool be weaned away from that platform?
BTW, I envy your expertise in Photoshop. Must be nice to able to keep your mind on the task at hand, and not have to constantly be thinking about HOW to do what you THINK there is a way to do something. I've played with GIMP some, but never got very far along on the learning curve. BRN..
Hey Brian! Thanks for the quick feedback.
Funny you should mention using NORMA with a client on a notebook. One of the big drawbacks I've had in demos is that on my laptop's track pad it takes a painfully long time to enter even simple models. I usually build a very simple model as a demo then pull out a bigger model that I made before. Sitting down with a client and modeling is a serious pain at the moment because all that mousing takes time! I don't know if they notice, but I certainly do.
I haven't been keeping up with the release notes as I should be... naughty me for not doing the homework before posting. I don't know what the current keyboard shortcuts are, if any. You're right that context menus are a good place to look for the shortcuts. Photoshop, again, is my gold standard on this one. If you hover over the icons in the tool windows the tool tips include the keyboard shortcuts. Each menu item that has a shortcut is labeled appropriately.
Something I hadn't thought of until just now is that Photoshop hardly uses -any- right-clicking. This comes from its legacy as an Apple application, and the more I think about it the more I like it. When you consider a tablet PC format, it's even more appropriate. Now, with a tablet PC I don't know what keyboard modifiers you can do.... Ctrl and alt are used as click modifiers in Photoshop, and depending on which tool you're using it can perform different functions. It's quick, easy, and very powerful if you're an advanced user.
In a pure tablet PC format (no keyboard modifiers) we might need more floating toolbars, or maybe I just need to use the ones we have in a non-docked way. My complaint about the floating windows in VS is that you can't collapse them. You can dock and hide, you can float and move, but you can't collapse a floating window to reduce its size when you don't need it. Not something that I expect can be changed in NORMA unless it's decoupled from VS. Also with a tablet, double-clicking can be a trick. Maybe it's because I'm not using Windows Tablet edition, but when I try double-clicking with my Wacom tablet I often miss. Double-clicking is heavily ingrained in NORMA. Look at http://dontclick.it for UI alternatives to double-clicking, or even clicking in general! Until docking toolbars and the heavy double clicking can be addressed, I don't see NORMA as being a great tablet PC app. Which is not a big problem in my opinion, because that audience is so small that it's not worth the team's limited resources to cater to.
For NORMA, focusing on tool-sensitive ctrl and alt modifiers for left-clicks is probably not appropriate either. (Except for the "duplicate drawing shape" ctrl-click gesture-- genius points to whoever picked that one!) Windows users, and especially Visual Studio users, are accustomed to right-clicking. Heck, I expect it as part of my VS experience!
So key-click modifiers are out, collapsing tool windows are out, avoiding right-clicks and the whole no-click paradigm is out. That leaves us with keyboard shortcuts! I agree that learning the shortcuts and having them change in a later version is annoying. On the other hand, not having them at all forces you to complete a relatively long mouse gesture to perform each action. Think about it-- each time you want to express something in NORMA you have to "hunt and peck" on the "keyboard" that is the toolbox. You can't use muscle memory, you can't improve your "object types per minute" speed. I'll quit with the analogies here while I'm ahead, as I tend to beat them to death.
I'm liking "O" (shift-o) as the Entity Type shortcut, which I guess puts the subtype connector as "F" (shift-f). Not entirely pleased with subtypes ending up there, but I can't think of anything else at the moment. Earlier I mentioned ctrl-up and ctrl-down, which is inconsistent with the "no modifiers" rule. I think capturing unmodified arrow keys interfere with scrolling on the design surface. Maybe shift-arrows? "`"? Tab? ";"? I'm not in love with any of them. Either way, what about using them to change directions on subset constraints? For making fact types derived or derived and stored? Objectifying fact types could use a shortcut. For frequency constraints it'd be nice if you could just type in a number for the simple cases. A toggle key for alethic/deontic might be nice.
I'm just tossing out ideas for shortcuts, and I'd love to hear somebody disagree with me. I know it'll be waaaay down on the priority list for the team (if it even makes the list!), but it would be good exercise if there's a group of new guys who need something simple to get their feet wet. If they wanted to get really fancy, they could make a menu where you can assign keyboard shortcuts to common actions. ;-)
So you really didn't have much to say on the subject after all - with Jolt cola, one can before bedtime should suffice.
I have been planning on doing a NORMA demo/presentation for the local INETA chapter, for a while, but have been sans notebook for a some time. I just bought a low cost (but well appointed), Compaq laptop (I hadn't realized it before, but Notebooks must be under 6 lbs, this is 6.5). In a "what's this" moment, I realized that the touch pad has a vertical and a horizontal scrolling edge - tilt wheel mouse button on a notebook, that is "laptop" - very handy.
As you use graphics pads a lot, would using a stylist with a notebook touch pad work at all with doing NORMA demos? Not having a tablet, I thought it might be useful for the graphic intensive manipulations. As the touch pads are designed for fingers, I'd be concerned about the stylist possibly damaging the device (then you'd end up with a notebook without a touch pad - not good). Other than that, and picking up and putting down the stick, it should work.
It's good that you brought up the question about the device/tool interface. It's like developing a website with one configuration, then realizing that it may not look or work that well when accessed through another. Also, though not as much of an issue as with websites, but provisions of the Americans with Disabilities Act, ought to be considered at some point too. I hadn't payed much attention as to how well VS takes these into account, but that might have some bearing on NORMA VS linkage too.
crud... "o" as Entity Type, "O" (shift-o) as Value Type. I should not be allowed to post after midnight. Including this one.
I have no disagreements in principle with this discussion at all. There are some practical issues with using single keystrokes. For example, if an ObjectType is selected, typing 'N' will rename it to 'N'. Visual studio, however, is quite good at defining double (and I believe even triple) key commands. Some common ones are Ctrl-K,Ctrl-D (type by holding down 'Control' and pressing KD) to format a document and Ctrl-KC to comment a section of code. Obviously, you need lead characters that would interfere with other existing common ones (Ctrl-C is out as the first character in the chord), but this could definitely be investigated.
As for right-click, most of the time I use the context menu key (between the right Alt and Ctrl keys on most keyboards). This will open the context menu immediately below the current primary selection, or in the upper left of the diagram if this is what you've selected. You can easily use arrow keys or keyboard shortcuts from there to navigate the menu. For example, Context-T-Z will activate the verbalization window.
I also did a little experimenting with the toolbox. [Technical note: we'd had a number of problems with the toolbox, especially with auto-activating items. Most of this centered on our inability to programmatically select DSL-based toolbox items (crashes somewhere it VS, both DSLTools and VS teams denied it was there problem). This led to some state checks in the docview that would not normally be necessary, which is highly likely complicate this issue.] Ctrl-Alt-X, select the item you want with tab or the keyboard, then hit Enter will drop the item in the upper-left corner of the diagram, which is not what you want. However, try the following sequence:
1) Ctrl-Alt-X to activate the toolbox
2) Arrow down to an item not the pointer
3) Move the mouse off the design surface and back on (I need a ViewMouseEnter event)
4) Now, you can arrow to any item on the toolbox and click the mouse to get that toolbox item (note that this is the first mouse click, you only moved it in #3). Note that wiggling the mouse at any time will update the cursor to correspond to the selected toolbox item.
Most of this procedure is not dreadful, but there are some obvious issues:
1) Obviously, #3 (make the mouse reenter the design surface once after a non-pointer item has been arrowed to) needs to go.
2) You should not have to 'wiggle the mouse' to make the cursor change
3) The toolbox items should be selectable based on letter, not just arrow (not sure if VS will do this, I haven't tried putting &accelerators on toolbox item names)
I think it would be best if we could do most of this in the context of the toolbox. At some point, we would like to investigate toolbox customization (you would be able to add your own common patterns), and these customizations should be available with any keyboard mechanism you come up with. I think this is probably cleaner in the long run than trying to duplicate the toolbox UI using some other approach. I'll try to look at the toolbox issues to see if there is a way to fix the main issues here, which would leave you in a situation where some keystrokes and a single click on the design surface would get you the full functionality.
Other ideas on UI/keyboard interaction are very welcome. I'm also the type of guy who is annoyed when I have to mouse too much (although I'm very comfortable and fast with a properly configured touchpad. I get lots of students chuckling at me when I navigate the file system at a command prompt instead of with Windows Explorer).
Would the toolbox improvements mentioned here keep you happy for a while?
Thanks for the info! I tried out the existing shortcuts, and I'm not all that enthusiastic about them. To open the tool box I hit one series of keys, then use the arrows for another series of keys. I'm just trading off moving my mouse finger back and forth for moving my left hand all over the keyboard. Then I have to mouse around anyways. Obviously that's improved if the mouse move is fixed and tool box items are selectable by letter, but I still loathe having to do a 3-sequence keyboard gesture to get to my shortcuts. Way too much finger traveling to do without thinking. Multi-chord gestures work well when you're coding because both hands are already on the keyboard, but when you ORM (when I ORM, at least) there's usually one hand on the mouse-like input device of the day at all times. This really hampers my ability to do ctrl- alt- gestures. Some would counter that you just make sure the keys in the gesture are close together, but then I pull out my trusty Devorak keyboard. ;-)
I don't think single-key gestures are a real problem. After the first couple times of renaming an OT people would probably catch on. Users of keyboard shortcuts are generally more aware of what context they're in. When you're on an OT and typing would rename it, you generally clicked it on purpose. Typing is not a "normal" activity in graphical environments unless you've deliberately focused on something that's going to capture it. Think about how you clicked on the text box in the web browser browser to reply to my post, then clicked off it to scroll around the page and submit it. You're intuitively aware that different events will happen if you use the same gesture while focused on different page elements.
Customizing the tool box might work... are you saying I could then customize it so that I could access it at any time, or I could execute the customized routines only after focusing on it with ctrl-alt-x? Those 3 keys are a pain on Devorak (ctrl-alt-b). Not unusable, just awkward. I'd still prefer single-key access whenever the design surface is selected, but I understand if there are hurdles to that.
I really appreciate being able to have this discussion in the forum, because I have my strong opinions that need to be put in check by the rest of the user base. :-)
A stylus on a touch pad generally doesn't work. They operate on capacitative resistance (I think?), and don't respond to plastic. I'm curious, now that you mention it-- I've never had mine respond to anything other than human touch. Not that I've tried a cat tongue or anything.... Oh, the experiments to be done!
You wouldn't want to use a stylus on a touch pad anyways. The nice thing about tablets is that when you move your pen to the middle, it's -always- the middle of the screen. The device is mapped 1:1 to the surface of your screen, and you can use a bit of muscle memory to improve your workflow. With a touch pad or mouse there's no "absolute positioning". All movement is relative to where the cursor is at the moment, which forces you to track the cursor with your eye. On a tablet you can know where you want to go, then put the pen right there because you intuitively know which spot on the tablet corresponds. It's a happy thing-- everyone should pick up a cheap one and try it out!
On a personal note, no Jolt for me! :-) No caffeine at all, actually. Been having trouble sleeping this week because I was up late (4-6 a.m.) a few nights in a row working and helping my wife with wedding shower stuff for her aunt. Crazy!! I'll be glad when it's done with because having chocolate-dipped oreos around the house is dangerous. As if oreos didn't have enough calories already!
Thanks again for everyone's interest in this topic!
> I'm just trading off moving my mouse finger back and forth for moving my left hand all over
This, I think, is the main issue. dontclick.it is interesting as
much for how much you can do with just one hand as it is for
avoidance of clicking.
The goal of this kind of usability design must be to minimise the
time spent reconfiguring your hands (and brain!) to make the next
action. An all-keys system works, but isn't an efficient way to
position things on the surface. And all-mouse system would work,
but isn't an efficient way to enter names of things.
Any action that is neither positioning nor text-entry should be
efficiently available either to the mouse hand, or to a single
keyboard hand, and only if absolutely necessary, to both hands
on the keyboard (that's why the multi-key combinations aren't the
BTW, on trackpads etc, there are many systems, and some interesting
support for gestures and multi-finger combos. If you haven't used
a Mac's trackpad with all the gesture support enabled, you should
really give it a try - most impressive what can be achieved. The
equivalent of scrolling in 2 dimensions, clicking, control-click,
as well as simple positioning, are efficiently supported with the
gentlest of gestures - almost imperceptible motions. It's great to
watch someone who's skilled with this interface - many times more
powerful than a traditional trackpad, and with practise, relatively
quick and accurate also.
As far as positioning things on a diagram goes, a constraint-based
system that doesn't allow things to overlap could be implemented,
such that when I grab something and drag it through a mesh of other
things, they push out of the way, and glide back to their former
positions when I've gone past - or find new homes when I stop. A
system like this can be implemented using formulae like atomic
attraction & repulsion, and would allow one to get a pleasing
arrangement of a new item by moving only that one item, instead of
having to move a lot of things around.
After I posted note on using a stylist, I did try it (and a few other things), and found what you stated: that it doesn't work. Out of curiosity, found that the edge of a fingernail doesn't work, and the point of a knuckle doesn't work. My guess is that there is a minimum surface area that must remain in contact thought the motion; maybe the differential between the center and the edges of the digit in question plays a role. Next stop, Wikipedia!
More apropos to this forum, I'll have to keep in mind the various environments and situations in which the NORMA tool might be used. Glad you brought it up.
Do you mean like this?....
I agree. Higher priority needs to be given to keyboard shortcuts within NORMA in general.
What's interesting is that high-end features overall won't influence as many users as ease of use and utility.
Do I need to give an example? Rolls Royce->VW Beatle (who do we know sold more cars?).
Software users are even more critical...they'll just hit the delete key.
I believe, the only way keyboar shortcuts will happen in NORMA is if kudos is put on those coders who introduce easy ways to do things,
and if as many people as possible support posts like yours. As much kudos needs to be put on that as those that write the code generators or DDL scripts.
Matt and team....here's a challenge....put kudos on the most brilliant ideas and coders who introduce ease of use features. It'll pay dividends.
Has anyone considered "mouse gestures" for simple things like:
1) Adding Constraints: click once to select constraint area of fact, then click and hold down mouse while dragging over top of role(s) (in constraint area) to add constraint to.
2) Adding an Entity: Click and draw a circle with the mouse, and could immediately take you into editing entity name mode when shape is added.
3) Re-Order Roles: Click, hold for more than 600ms and drag..
While some things require keyboard while modeling, many tasks DONT HAVE TO. :):)