Genii Weblog


Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.


Mon 27 Mar 2006, 01:32 PM
Lotus Advisor Editors Choice 2006Genii Software's CoexEdit gets another award, this time the Lotus Advisor Editors' Choice Award in the category of Application Development Tools.  This follows CoexEdit being named a Lotus Award 2006 finalist at Lotusphere this year, and confirms that the message is getting out.  

Even better, from my perspective, is the news that a large customer wants to buy more several more licenses for CoexEdit.  Awards are great, and make me feel proud (although not quite as excited as 
Wild Bill, I don't think), but customer satisfaction is the best award.



Update:  There is now a 
direct link to the Genii Software award page.

Copyright © 2006 Genii Software Ltd.

Thu 23 Mar 2006, 11:29 AM
Show and Tell ThursdayThis is a repeat of one of my more popular tips (see here), but since people never see it until I point them to it, it probably deserves repeating:

It has always surprised me how many questions are raised in the various Notes/Domino forums about hide-when formulas.  No, I don't mean the (many) about hide-when formula bugs.  I mean the basic process of creating a hide-when formula that does what the user wants.  I think that part of the problem is that many non-developers have the need to create a hide-when formula on occasion, and that another part is that people think in terms of "Show When", not "Hide When".  In any case, I thought I would write a short primer about hide-when formulas to link to when people are confused.







Basic Rules for Hide-When formulas
  1. Hide-when formulas effect entire paragraphs (a table cell starts with a paragraph, so this is true in table cells as well, although a table cell may have multiple paragraphs.  See more on paragraphs).
  2. A hide-when formula should always either be a condition (e.g., Status = "Pending") or return a @Yes or @No (or @True or @False, which are equivalent).
  3. Multiple conditions should be combined with an ampersand, &, if all the conditions must be true in order to hide the paragraph, or with a vertical bar, |, if any one of the conditions must be true to hide the paragraph.  For example, if we should hide the paragraph when either Status is "Pending" or Override is "Denied", the formula should be Status = "Pending" | Override = "Denied".
  4. If you have mixed conditions, use parentheses to separate the "and" and "or" parts.  For example, if the paragraph should be hidden when either Status is "Pending" or Override is "Denied, but not when the document is being edited, the formula should be (Status = "Pending" | Override = "Denied") & !@IsDocBeingEdited.

Tips for Simpler Hide-When formulas
  1. Do not use an @If unless you really, really need to.  The formula @If(Status = "Pending"; @True; @False) should be simplified to Status = "Pending".
  2. Formula language allows you to check against a list of names at one time, so the formula Status = "Pending" | Status = "Denied" | Status = "Reviewed" should be simplified to Status = "Pending":"Denied":"Reviewed", with the colon between the items being a list separator.
  3. If it is very hard to describe the "hide when" condition, but easy to describe the "show when" condition, just put the "show when" condition in parentheses and use an exclamation mark, which means "not" in front.  Thus, if the paragraph should be shown (not hidden) when the Type is 1 or the document is being edited, you can use !(Type=1|@IsDocBeingEdited) instead of trying to figure out the inverse.
  4. Beware of mixed conditions.  If you have a formula which says Status = "Denied" | Type = 3 & @IsDocBeingEdited, how do you know whether the proper meaning is (Status = "Denied" | Type = 3) & @IsDocBeingEdited or Status = "Denied" | (Type = 3 & @IsDocBeingEdited), which have very different meanings.  If you assume the first interpretation, your paragraph may be hidden whenever you are in edit mode, but if you assume the second, it will only be hidden in edit mode when the Type is 3.
  5. Try "talking the formula".  If you have a formula which says Status = "Denied" | Type = 3, and you try to say it out loud as "Hide this paragraph if Status is "Denied" or Type is 3", you may catch that what you wanted was "Hide this paragraph if Status is "Denied" and Type is 3", which should be Status = "Denied" & Type = 3.

Special Tips for Hide-When formulas in rich text fields

While most people use hide-when formulas on forms, pages and subforms, they are also used in regular rich text fields.  Additionally, a rich text field on a form with a hide-when formula inherits that hide-when formula.  These tips are particularly useful for hide-when formulas in rich text fields and for hide-when formulas on forms which include rich text fields.

  1. Include a "back door".  A hide-when formula on a form includes an implicit assumption that you can always see the hidden paragraph when designing the form.  There is no such assumption with rich text fields.  If your formula would have been Donations = 0.0, make it Donations = 0.0 & (!@IsDocBeingEdited).  Then, you can still see the paragraph when editing.  Another option is to check a special role, so that when that role is set, you can see all hidden paragraphs.  If you don't do this, you may find hidden paragraphs that you can't ever find again.
  2. Be clear you are using hide-when formulas with users (or admin or somebody).  People don't expect hide-when formulas, and won't be very happy if they feel "fooled".

Tidbits from the Gold Forums

These are tips from others posting in the Gold Forums.  They offer different ideas and suggestions that might be useful.  I provide links back to the original post to allow reading the whole thread.

Bill Ernest 10.Feb.04 - Another way to use "show when" logic: 
I usually find it a lot easier to write them like this...

Show := @IsMember("{IT]";@UserRoles) | @IsMember("[VisSystemBoard]";@UserRoles);
!Show
Andre Guirard 05.Apr.04 - @ThisName doesn't work in hide-whens: 
The problem in this case is that the hide formula is not considered a formula of the field. There is no field context in which this formula executes. The hide formula applies to the text paragraph. In your case, perhaps there's nothing in the paragraph except one field. But there might be several fields and some text or other objects besides. In that case, to which field does @This... refer?

Warren Gamley 19.Feb.04 - Easy way to refresh hide formula from a button: 
I have a button that I need to click in order to display a hidden paragraph. I have it working so that when I click the button, I have to then click somewhere on the form before the paragraph is displayed. Is there a way to do it so that it appears immediately when the button is pressed?

... [Warren answers his own question] ...

I think I figured out a way.  Placing...

@Command([RefreshHideFormulas]);

... on the button seems to do the trick.

This post is likely to be a work in progress.  Any other tips or hints or strong suggestions about writing better hide-when formulas hide-when ?

Copyright © 2006 Genii Software Ltd.

Wed 22 Mar 2006, 01:53 PM
As I was working on the documentation for CoexLinks 2.6 (which should be available on our website later today, or early tomorrow) over the past several days, I realized that we need to rethink the documentation.  I don't mean rethink whether it is a Notes database or a Word document or a PDF document, but the basic structure of how we organize the growing number of options.  When CoexLinks 1.0 was released in April, 2003, there were only a few options available, but as more companies have started using CoexLinks as part of their coexistence strategy, there have been more nuances, features, desired restrictions, etc. etc.  Mind you, it is still simple to configure and use for the average administrator, but aside from the three options that practically everybody uses, COEXDoclinkType, COEXPrependDocLink, COEXPrependDocLinkText, there are twenty one other possible options, and some can have a fairly major impact on how CoexLinks operates.  That is starting to be enough to confuse people, and it is certainly enough to make it possible that people might start missing out on important functionality which they could use if they knew about it.

But what is the best way to address this?  The twenty four options are documented in the CoexLinks User Manual, but even if somebody were willing to read through them all, it is not always easy to absorb the importance of one or another option, and it is even harder to understand how some interact with each other.

1) Categorization: My first thought was to split the options up into groups or categories, which should certainly be done if nothing else is.  Options such as COEXExcludeHintServer, COEXIncludeHintServer, COEXExcludedLinkText, COEXExcludedDocLinkPreserve and COEXIncludeReplicaID are all closely related, so they should be grouped together, but what of COEXLimitToDB? It could easily be used together with those, but it could also be used for completely different purposes.  Should an option be contained in multiple categories?

2) Scenario Solutions: Mark Ramos, whose Granite Software provides support and also sells CoexLinks along with Genii, suggested scenario based documentation.  It would be possible to describe various scenarios that most companies who use CoexLinks face, and the options they would use to help face that scenario could be explained together.  That seems like a good plan.  I am not sure what to do about the companies who fall between the scenarios or who have overlapping scenarios, but I guess they could recognize themselves in more than one place.  I am working on coming up with scenarios now.
 
3) Wizard configurator:  Mark and I also discussed some sort of a wizard that would help people through the process.  This could be an automated wizard or even just a paper based wizard, but a series of question would help establish which options make sense for your company.  One advantage to this approach is that if a new problem appears, you can go to that problem solving item and find the option, rather than having to re-envision the scenario.  For example: 
 
Issue: Doclinks that are simply pointing back to the e-mail responded to are becoming attachments and confusing people.  They were easy to ignore as doclinks, but not as attachments, and the user can never really access them as they go back to a different user's mailbox.  
 
Solution: Use COEXExcludeHintServer statements to exclude each of your mail servers, as that is where these doclinks will point back.  If you have specific database that should be on the mail servers and render doclinks, use COEXIncludeReplicaID statements to allow those doclinks to be included while others from the mail server is skipped.
 
So, does one of these seem best?  If I do all three, will it just make the documentation bigger and more cumbersome.  Any thoughts?
 

Copyright © 2006 Genii Software Ltd.

Tue 21 Mar 2006, 11:36 PM
On March 16th, Microsoft announced the launch of a $500 million ad campaign with the tagline of "Microsoft: Software for the people-ready business", according to Steve Balmer, CEO of Microsoft.  Yet, on March as reported in this CNN article, Microsoft is yet again, not ready for the people.  Windows Vista has been delayed to January 2007.  Now, I have no objection to delays in order to make a product better, safer and more reliable, but it feels a bit like Microsoft just can't seem to get unmired from the slithy toves of Quality Assurance.  C'mon, they had to know this delay was going to happen on the 16th, but they chose to go forward with their ad campaign, even as they proved that despite being the largest software company in the world, they are sometimes not ready for prime time.  There are excellent people at Microsoft, skilled developers, creative thinkers and even a few careful QA people, but the "people-ready" tag may seem a bit ironic to those companies waiting to see the return for their subscription maintenance.

As for the picture, I guess these two gentlemen are indicating that "Windows Vista is out there, somewhere".



Copyright © 2006 Genii Software Ltd.

Tue 21 Mar 2006, 11:30 PM
OK, so I am mixing metaphors, but it has been a long week.  We emerged from the dark side of the moon, missing a few heat panels but mostly intact.  Our fax line is still somewhere in outer space, but we should have it back sometime this week.  Otherwise, things are getting back to normal.  A whole bunch of new stuff is coming out very shortly, as if to celebrate the move.  More later.

Copyright © 2006 Genii Software Ltd.

Thu 16 Mar 2006, 09:50 AM
It is always a dramatic moment in space dramas, that brief period when the space ship is out of touch, whether behind the moon or entering Earth's atomosphere.  Everybody holds their breath, the tension mounts, the deadline passes (if only by a few seconds), then contact is made and everybody erupts in cheers and jubilation.  From Apollo 13 to the latest Mars explorer, the scene is remarkably similar.

Well, that point has come for our move to a new office.  The phones have been shut off to the old office.  They are due to be turned on at the new office sometime today.  In the meantime, we hold our breath, the tension mounts, etc. etc.  Talk to you on the other side (or you can leave a message, but that hardly goes with the suspense of the moment).  If this is a CoexLinks support question, you can also call our support organization, Granite Software, at +1 508-883-7335.

Copyright © 2006 Genii Software Ltd.