It's incredibly difficult to talk about use case diagrams because they don't contain sufficient information to be useful or to have a meaningful discussion beyond conformance to the specification. For example, in this particular example, I can't tell you if the Extend or Include relationship is correct because I cannot see if the behavior defined in Update Status can truly be inserted into the View Properties use case at at least one extension point. This information would be captured somewhere else, probably using one of the textual or tabular use case templates.
If what you are trying to show is indeed an Extend relationship and the View Properties use case has the appropriate extension points documented, then if I were to draw a use case diagram, I would probably draw it like this:
Although it has a lot of lines on it, the diagram makes it clear to a reader that there are going to be conditional extension points within the View Properties use case where actors of different types can split off into different paths and perform additional actions or functions. The reader would then go to the View Properties details to understand more about how that works.
However, my normal caveats apply:
Since it appears this is a school project, you should ask your instructor what they are looking for.
In the real world, you may need to balance following the UML specification and creating a perfectly valid and compliant model with creating a model that is readable and communicates the intent to others who use it in the future.
I totally agree with Martin Fowler that Use Case diagrams are often a waste. They add very little value for the time spent creating and maintaining them. A table of contents of well-written use case titles is often more useful and easier to generate and maintain.