Martin Fowler says in UML Distilled:
Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition.
View Contact and
View Documentation don't appear to be used more than once, so this isn't really a good use of
include according to this advice.
The answer is probably in the text of your use cases. If the only way to View a Contact is through the Send email use-case, then by virtue of it only being used once, you just make it part of (an alternative flow of) the Send email use-case, without a separate Use Case name.
On the other hand, if it's possible to View a Contact outside of the Send email use case and the steps are identical (and thus you don't want to repeat yourself), then using
include is OK.
extend, the advice from Fowler is (emphasis mine):
The UML includes other relationships between use cases beyond the simple includes, such as «extend». I strongly suggest that you ignore them. I've seen too many situations in which teams can get terribly hung up on when to use different use case relationships, and such energy is wasted. Instead, concentrate on the textual description of a use case; that's where the real value of the technique lies.
The advice speaks for itself.