Fix "Wiki Pages" as a label

[james_graham1]

  This idea has been developed and deployed to Canvas

  Idea open for vote Wed. February 3, 2016 - Wed. May 4, 2016  Learn more about voting...

Canvas is inconsistent and sometimes refers to  "Pages" as "Wiki Pages".  Since "Pages" are not really "Wiki" pages, I recommend changing the instances of "Wiki Pages", such as on the "Insert Content into the Page" panel to "Pages".  This will reduce confusion (including mine!).

Thanks,

Jim

  Comments from Instructure

For more information, please read through the Canvas Production Release Notes (2016-08-27)

[James]

Part of the problem is that "page" is a bad term to use without a qualifier. Many people refer to every item delivered through and viewed inside a browser as a "page" (excluding file downloads). For example, "Look at the grades page." That is the common usage of the term.

Then there are "Wiki Pages", which are actually wiki pages, but are just labeled as "Pages" in the course navigation menu. Internally (and externally through the api), these are called wiki_pages, so programmers are going to refer to them as "wiki pages". Because the regular user doesn't see the internal workings and most use them to display content but not allow students to use them, they consider them "Pages".

Furthermore, the discussion here suggests that many faculty don't enable the "Pages" navigation menu, so students may not even be aware that there is a construct of a page separate from what they consider to be a page (anything they're supposed to click on and read in the browser).

On the other hand, if you do have "Pages" enabled in the navigation menu, you probably don't want it to say "Wiki Pages" or "Wiki" because many faculty don't enable student editing and that's what students would expect to be there.

So while I will agree that the terminology is confusing, I don't think it is as simple as renaming them to just be "pages" because of the broader understanding of that term.

Some have written that there are at least three different terms used in the documentation, but there is no reference here to where those are. Can someone point out the three places so we can see if someone has posted comments in the guides? In the past, the documentation team has been fairly responsive when someone has left comments. But it seems that wasn't what the original requester was asking for either.

[davidnas]

All fair points James, and I agree with most everything you said.  I am not necessarily advocating for only using the term "pages," but rather to decide on a single term and apply it uniformly.  When you create a page from the Modules view, you have to select "Content Page."  When linking to content from within the rich content editor, you have to select from "Wiki Pages."   Everywhere else in the system, they are simply referred to as "Pages" (although I may be forgetting other places where it is inconsistent).  That's part of the problem... since it's not consistent I have trouble remembering where all the places are where it might be listed differently and thus, can't be sure that I'm giving fair warning to the instructors I'm training (not that I should have to, imo).

You are correct... from a student perspective, they will never see these inconsistencies.  However, from an instructor standpoint, this is very confusing and aggravating.

[kmeeusen]

Part of my concern, David, is that not everybody see this as a problem, a bug to be fixed, nor an idea to be implemented. This is clearly demonstrated in the numbers of votes. Our school has been using Canvas for four years, and have had no concerns expressed about this by either our faculty or students.

I believe that  @James ​ has stated very well, both how complex this issues really is, and how little a problem it is for users.

KLM

[davidnas]

While I appreciate your point of view, Kelley, I would respectfully disagree.  While it may not have proven to be an issue at your school, I can assure you that it has been at mine, and clearly others who have posted here feel the same way.  YMMV. 

If it's not flawed design (meaning it was purposefully designed that way), then Instrcuture should share that purpose with us so that we can help our users make sense of it.  Otherwise, it makes no sense (and goes against very basic UI/UX design best practices).

If an instructor asks me to show them how to create a wiki page from the Modules index page, at not point in that process will they ever see the term Wiki Page.  By contrast, they have to create a Content Page.

If they ask me to show them how to link to one of the Content Pages they created, at no point do they see the term Content Page.  By contrast, they have to look under the Wiki Pages menu.

You have to select a new Content Page to make a Wiki Page (from modules), and you have to look in the Wiki Pages menu to link to a Content Page (in the content editor).

How is any of this intuitive?

And, while James brought up a good point about the inadequacy of "pages" as a singular label, especially from a programmer/API perspective, I'm not so sure he was pointing to "how little a problem it is for users."  While it may not be generally noticeable to students, it's definitely noticeable to instructors.  And to be honest, I'm not sure how less adequate using a single less-than-perfect term consistently would be than using three less-than-perfect terms in multiple places is.  I'd rather see consistency, and so would my users.

In terms of getting votes, it's one thing to ask faculty to vote for new functionality or improvements on existing functionality, it's totally another to tell them they have to find time to come here and vote if they want to see a flaw/bug get fixed.  And, since Instructure has provided no information at all about why it was designed this way (and I can think of no logical explanation to share with them), they see it as a bug or a flaw in the design, not an enhancement.

So, again, I ask Instructure:  Explain to me the purpose behind this design, change it, or tell my why you can't/won't.  I don't think that's unreasonable.

[leward]

I consider inconsistent use of tool names labels across the application to be bugs and wish Instructure would treat them as such, rather than requiring feature request votes to meet a quota before working on them.  

[Renee_Carney]

We appreciate you, and the submission of your idea. Your dialogue helps our product teams prioritize feature development. Unfortunately, this idea has been archived because it did not meet the 100-vote threshold within the 3-month voting period. Learn more at: How does the voting process work for feature ideas?

Can archived ideas still become a feature?  Potentially, yes. Archived ideas can be resubmitted by Community members. As people’s needs change, previously submitted ideas may gain additional traction. Feature ideas are evaluated as a whole and influence product direction.

[Renee_Carney]

  This idea has been developed and deployed to Canvas

For more information, please read through the Canvas Production Release Notes (2016-08-27)

[Renee_Carney]

Thank you to jgraham for submitting this idea, as well as,  @kmeeusen ​, macaulayl​,  @davidnas ​,  @dgray ​,  @kona ​,  @ljp1 ​,  @James ​, &  @leward  for your contributions. Your investment in this idea helped refine a feature which is now part of the Canvas!

[johnmartin]

I love the respectful, deep point/counterpoint of these discussions from various parties (including Canvas!).

I too had still not figured out where or what Wiki Pages were...