04 March 2014, 11:41

See https://bugs.launchpad.net/mahara/+bug/1282219

For Mahara 1.9, we're looking to rename the "site pages" feature ( http://manual.mahara.org/en/1.8/administration/config_site.html#index-16 ). This is the feature that lets admins edit the content of several parts of their Mahara instance:

• "About" page
• "Privacy statement" page
• home page for logged-out users
• the top part of the home page for logged-in users (above the user-editable content)
• "Terms and conditions"
  • Shows up as the "Terms and conditions" page if you activate that via "Configure Site -> Menus"
  • Is inserted into the user registration page if you activate the setting that requires self-registering users to agree to terms & conditions

Each of these can be edited with a single TinyMCE text field. So, they're not normal Mahara portfolio "Pages" with blocks and everything.

This was already confusing because there's also the feature of Pages (real portfolio Pages) owned by the site admins. Which also tend to be referred to as Site Pages. In 1.9, it would have been even more confusing, because the "site pages" can now be customized by individual institutions. Which would give you "institution site pages"!

So, we're looking to rename them. In the current code they're called "general pages", but I'd like to find a more self-explanatory name. Preferrably one that doesn't contain the term "pages" at all, because 1) these aren't "Pages" in the Mahara portfolio sense, and 2) two of them are not standalone pages at all but are just text snippets inserted into other pages.

So, does anyone have any suggestions?

(Edited to reflect that "Terms & conditions" is used as an optional standalone page and as a text snippet in the registration page)

04 March 2014, 11:44

After pondering several terms on the Launchpad bug page, I'm now leaning towards calling them static pages. Even though it contains the word "pages", I think it still may be the most self-explanatory term for these. And since it says that they're static, it can't be confused with portfolio Pages because those are by definition editable.

04 March 2014, 12:52

I prefer general or generic, but I could live with static (though editing static pages seems like an oxymoron). I agree that pages should be part of the term, despite the snippet exceptions...you are editing content on those pages, if not the whole page

04 March 2014, 12:56

But as I ponder, why can't  these pages include blocks such as RSS, or something like that?

A big deal, coding wise?

I could see having newsfeeds on the Dashboard, for example.

Just spitballin'...

04 March 2014, 14:00

My main objection to using "___  pages" is that I don't want to confuse them with portfolio pages (i.e. what we used to call "views"). Perhaps I'm too concerned about that, though.

Regarding the idea of making these into full-featured portfolio pages with blocks and everything... it's certainly possible. My gut feeling is that there would be a few tricky bits relating to it the management of these pages at the site & institution level, just enough to make it not an easy task.

It would be one way to address the longstanding feature request to be able to alter the blocks on existing users' homepages, though.

Cheers,

Aaron

05 March 2014, 3:44

Why not just create a flag called "Static page" for any page regardless if the page is associated with a site, group, insitution, or user?  What that would indicate is that the page can be cached without worrying that its contents will change.  Maybe even put in a time frame, so that when that timeframe expires, a message can be sent to whoever is responsible for that page that it needs to reviewed.

For example, you have a page or collection called "Student Handbook" and you have the policy that the student handbook needs to be reviewed once a year in July.  So a message is sent out in July indicating that the page needs to be reviewed.

There are legitimate reasons why a site, insitution, or groiup would want files and pages with feeds and pages that are templates.

1. File of Map of the United States.  This is constant no matter what the institution is.  If we require each institution of upload their own, it wastes disk space.

2. Template for a Book Report.  The basic format of a book report does not change, for the most part.  Why does each institution need to create their own?

I am thinking about things from a scenario of homeschoolers where there would be a lot of "institutions" or "groups" with a few students in each.

Melissa

05 March 2014, 12:26

Why not scrap this feature altogether and build a feature that would allow institutional pages to be included into a footer or header menu? Could be as simple as making any number of institutional pages, copy its URL and paste it into something similar to the links and resources block, except make that block so it shows in the footer or header and so that it allows child items.

05 March 2014, 13:03

(I'll call the things I want to rename "sitepages" (all one word) for now, in order to differentiate them from full-on portfolio pages with blocks.)

Hm, I guess I'm getting a vision here of a system where we could replace sitepages with portfolio pages... add something like a selector that lets you map certain Pages to certain "key pages". i.e., "This Page will be the logged-out user homepage, this Page will be the terms & conditions, etc". Unfortunately... it would not be trivial to implement, and we've already implemented, tested, and upstreamed this version that simply expands the existing "edit site pages" system to allow institutions to customize sitepages. So replacing sitepages with portfolio pages will probably have to be something for 1.10.0 at the soonest. (The migration path would be to replace each of them with a Page containing a single text block with the sitepage's current content.)

Which still leaves my original question, what should we call the "edit site pages" link now that they can be customized by institutions?

Cheers,

Aaron

05 March 2014, 13:05

As an aside, you can already override the footer links with a chosen portfolio Page. "Configure Site -> Menu" gives you options to enable or disable the footer links, or change them to an arbitrary URL.

However, it lacks the ability to add more links or rename the existing links, and it can't be customized by institutions. Those are certainly features it would be nice to have.

06 March 2014, 5:54

Okay, now I get what I meant by "site pages" (logout, about, home, privacy, terms and conditions.  

Although, I would never connect "site pages" with those items, if that is the terminology that everybody is used to, I vote for leaving it "site pages" and just having that option available under institutions.  Or just use "Institution pages" under institutions.

If you look at Schema.org, they call those pages

* creative work -> Web Page -> About 

* creative work -> Web Page -> Contact Page

Which leads to the question, will those pages have the appropriate "Rich Snippets", so that Google and other search engines can appropriately find the information?

Melissa