ESCAPE VELOCITY

1 - "Allowing users to Cut a document from a view with a simple gesture is bad. Bad bad bad. It bypasses soft deletes. It doesn't ask for confirmation. It bypasses the QueryDocumentDelete event."

I had no idea about any of that. I suppose I'm fortunate that I've never been bitten by that. One question about that, though. If you cut something and close Notes, does it warn you that you have documents on the clipboard?

2 - "does it warn you that you have documents on the clipboard?"

Nope.

3 - Nathan this was my response..I think a step back should be taken to unify the model and entry points (your Cut example).. Bob?


"Margo the development environment should be changed in the following way so that becomes somewhat of a "moot" issue and allows this "problem" to be solved *for all applications* that invariably run into the same general issue...

In 8.0 there was a checkbox added to enable/disable *all* the system commands for right-click menus.

In 8.0.1 this should be changed to be a list that allows individual system menu items to be selected. Like you can select certain capabilities for RichText Lite fields.

You are never going to get this correct. By expanding it to a list it can be changed in the template by those that aren't happy with whatever decision gets made.

And just as importantly other applications can also benefit from doing it this way.

I realize you can turn off the default system commands and then re-implement just some of them but that is a much bigger maintenance/coding solution than just making it a list. And if there is no corresponding command (as we had with copy to table for the longest time) your out of luck in that situation.

I realize you were asking a slightly different and specific question but I think the energy would be better spent improving the design element and therefor solving this issue as well."

P.S. Nathan, of course it could be generalised further in allowing it to be based on formula and/or roles etc as well..having it based on the action model of shared action and local actions would be better than my list idea...but just solving it by hard coding is a short term answer..

4 - A couple of comments.

Having forward next to reply is fine when the document in context is a mail document. But, Notes can forward any document, so in the Notes case Forward is an action that is equally applicable as open, edit and print to any other document.

As I read more of your comments, this same theme applies. The actions that are not as relevant to mail, are very relevant to documents.

Changing delete to move to trash is a problem if the application has no trash UI.

So the key becomes to separate the generic document context from a document inside a mail file. Is that likely to be less or more confusing for users ? Two context sensitive menus for mail vs non-mail documents.

I think Create Bookmark is extremely useful for mail. Ever receive an email that you refer to over and over. I just moved roles and got an email with an org chart that I refer to more frequently than most mail. Yes I could move that content somewhere else, with a cut ;) and paste, or use the create menu, but its handy to have it bookmarked. Same theme again, relevance to mail vs other document types.

5 - ...which is precisely why the default (i.e. those that automatically display in any view / folder) context options should all become "system commands" for each view / folder, allowing us to decide which make sense to display, when (hide-when formulas), where (actions menu, context menu, action bar)... and in WHICH ORDER. In email, Forward would be placed near the top, but in an application it'd be demoted to the bottom of the list.

6 - @4 - The problem here, David, is that striving for consistency between the mail interface and every other Notes app means sacrificing quality of the mail interface. After all, you and I understand that mail is just a set of documents in a view, but does a user? Of course not. The desire for some sort of cross-compatibility is artificial. It's based on the underlying design construct of the platform, not the best way for users to work. What's confusing for users is that the Notes mail experience is burdened by some sort of "this is how Notes applications have to work" mentality on the part of the template designers.

So yes, absolutely two totally different context menus for mail vs. non-mail. In fact, how about totally different context menus for every Notes application?

Cut, paste, edit -- these are concepts that may or may not be relevant to other applications, and I can assure you that I will NEVER, EVER keep the default menu items in any Notes application I ever build from now on. In the unlikely event that I think Paste is a good thing to have in the menu, I'll manually create a shared action with @Command([EditPaste]), and stick it in my views. Then I'll thank my lucky stars that I get to decide for myself whether this is an important command.

Stuff like changing Delete to Move to Trash -- I'm not suggesting they change what's coded by default in C++. I'm suggesting removing that altogether, and then creating a specific action that's revealed on the context menu by the template developer that says "Move to Trash."

@3 - You can determine based on roles now by using hide-whens on the actions. This already works. And frankly, I think you and I and every Notes developer should have to reimplement all the default commands each and every time we want to see them. Why? Because everything in the context menu should have to justify it's own existence to the point of AT LEAST being willing to put a shared action on the view's action list. It's not that hard, and if you think it's too much trouble for the command, then it's probably a bad idea to show that command to the user anyway!

7 - You wrote: "CUT...It bypasses soft deletes. It doesn't ask for confirmation. It bypasses the QueryDocumentDelete event."

Au contraire mon ami! Yes, you will have to put code in the QueryDocumentDelete event of the database script to catch cuts, but it is triggered by cuts. And you can even make it work well with Soft Deletions enabled. I know because I spent a good bit of time two weekends ago making it work.

I wrote about this a while back here: { Link }

For a more recent, and much more advanced, example, check your email for a sample. You too Charles.

The code I put together is part of a much larger OpenNTF project I've been working on called "SuperNTF". No public releases yet, but if anyone is interested in kicking the tires while I polish things up, feel free to contact me directly. I'd love to have some pre-release feedback.

Kevin

8 - Okay, I did get it to trigger the QDD event. So that's SOMETHING. I stand corrected on that.

It doesn't ask for confirmation though. You'd have to build that yourself. Think about how different that experience is from the basic Delete behavior in Notes.

So I'll upgrade it from Stalin-evil to maybe just a Hussein-evil. Still has no business in a default context menu.

9 - @6 - valid points - I was offering an opinion on why it is the way it is today.

10 - While I agree with many of your points there are a few that I don't.
" WE CAN ALWAYS GO WRITE A LITTLE CODE IN THE ACTIONS TO PUT WHAT WE NEED BACK IN. "
we shouldn't need to reinvent the same code when the product can already do it, that's wasted effort. The menu items should be individually selectable. System Actions are like that, context menu should also be like that.

firefox and office are quite different applications to notes generally and mail specifically. I understand that you were citing those as good use of context menus but the Windows Explorer right click menu is a closer comparison and the notes rc menu is quite similar to that albeit with a grouping of commands that needs a redesign.

A right click menu should give a user the options of "what are the common functions that I can do to the currently selected object(s)". most users now refer to the right-click menu first, before looking anywhere else. severely limiting the menu is as bad as overcomplicating it.

11 - @10 - And every common function that someone would want to do with email is -- an email action. It's the same stuff that they've bothered to put in the action bar. Not Cut, Edit, or Open in New Window.

Shall we put document properties, Copy Selected as Table, and Create Bookmark in the action bar too? Why not? What's the justification for presence in one vector and absence in another?

12 - I totally agree !!! IBM/Lotus need to keep focusing on the mail client as that is what staff use 95% of the time !

Pete

13 - @11 indeed, as I said I agree with you.
My belief is that individual elements should be switchable in the same way that system actions are rather than turning it all off. Have I missed something?
The action bar is significantly smaller than the RC menu and as such it is forced to have far fewer options displayed.

14 - Ummmm Nathan aren't you a design partner on Notes 8 with IBM? Did they not ask for the kind of feedback during the beta?

15 - @14 - Y'know, one might think. But that's not exactly how the DP program works. Maybe it's how it SHOULD work. Or maybe it's how I should have worked IT. But we really don't get engaged that way.

I'll have to talk to them about how this might fit better in that process.

16 - Instead of Lotus trying to design one right-click menu for all Lotus Notes applications (including the Mail template), my suggestion is that Lotus should make this a Database AND a View attribute (database by default, but being overridden by the view attribute if configured).

In that way the right-click menu for the mail template can be tailored and simplified for the email template specifically, without screwing up all of the other Lotus Notes database designs with quick commands that are not necessary or as Nathan suggests downright dangerous.

The reason that I have suggested making the righ-click menu a view attribute also is there are some situations where right-click menu commands can cause data integrity problems in some Notes views. For example allowing an end user to delete a "parent" document and making "child" documents orphans in a hierarchical view. I know that a developer can currently code around this in the view formula, but I feel that my suggestion would be simpler and more consistent to apply.

17 - Good stuff. I will disagree on the doc properties though for one reason.

The doc properties can be used to view field values of a document without having to actually open it. In terms of mail it isn't hard to figure out how that might be a good thing to have readily available.

I do suggest that this be used only by those who actually have the ability to understand it, however, and as such typically only share that information with my technical people.