Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

What I'm looking for is an approach to organizing content pages on a Publishing site whose main contributor will be someone unfamiliar with Sharepoint (let alone SP2013).

The Publishing site allows just one Pages library. Within that library, I'm able to create folders and sub-folders that reflect the information architecture. However -- and this is a very big however -- the Add Page action always puts the page in the root of the Page library, making it completely confusing for this customer (and even confusing for me).

Is there some other (and maybe better) way of organizing the pages this way? I can't possibly be the first person wanting to do something like this, can I?

TIA
Josh

share|improve this question
    
You mention in one of your comments you have 3 levels of classification, are they dependent on each other (2nd level has filtered values depending on the first level) ? –  Cameron Verhelst Mar 5 at 6:26
    
"Hierarchy" is a better word for it, I guess: categories, sub-categories and sub-sub-categories, etc. Consequently there aren't really any interdependencies, although the hierarchical view of things is ingrained. –  Josh Korn Mar 5 at 21:07
    
To me it seems you first explain there is dependency, and then you say there isn't ;). To make it clear, does the list of possible options for a sub-category change when you change the chosing category ? –  Cameron Verhelst Mar 6 at 6:27

3 Answers 3

Josh - strangely enough, I am doing the exact same thing right now, and have the same concerns. I have multiple Department sites, and each department can create and post Articles (Article Pages) to view and read once in the Department site. On top of this, there are other page types.

I have opted to forgo Folders in the Pages Library, as it buys me little (except for visual organization), and instead make sure I have distinct Content Types in the Pages Library. When the end-user clicks Add Page, they see "Site Page", "Article", "Profile Page". It makes it much easier for first-time users.

Then, in the Pages Library, I have created Views, one for Site Pages, one for Articles and another for Profile Pages (each filtered by Content Type). I have removed the All Items view, to avoid confusion. To the User (and to me!) this appears as 3 separate Page Libraries.

Does this help? I still have a little cleaning up to do, but I think the end result will work well for this SharePoint newbie (and I mean that in a good way) client.

share|improve this answer
    
Does this help? Yes, very much, except for one thing: the organization has three levels of classification. By constructing content types in the page library, I'd be effectively flattening that down to one and probably making it unacceptably long. But it's an approach that I think I may turn to somewhere down the road. Thanks. –  Josh Korn Mar 4 at 19:50
    
This is also an approach we've used before. –  Cameron Verhelst Mar 5 at 6:25

I can't believe someone has not thought of METADATA yet ;) (just kidding).

No, but really, why go to folders ? Why not sub-content type the build-in Page one and add a field that maybe lists all the options that he would think of navigation wise ? If it's hierarchical, you might want to consider to use a termset instead ? This way you can still group and filter and sort whichever way you prefer :).

share|improve this answer

You could use the Content Organizer to ensure the document gets routed to the correct folder. We route the page based on a custom page property(taxonomy field) that the user enters.

Create Content Organizer rules to route documents

share|improve this answer
    
What a nugget! I'd better temper my enthusiasm with a couple of questions: Thanks very much for this. –  Josh Korn Mar 4 at 20:04
    
Oops ... the questions are: (a) are edited pages considered to be "uploaded" (I imagine they are, otherwise they wouldn't work this way, but I'd rather be on the safe side and ask anyway)? (b) do you simply add the property to the page library itself? It sounds too good to be true. Have you found any drawbacks to this scheme? –  Josh Korn Mar 4 at 20:13
    
Well, there's one drawback - you can't use a term set that's already used for Site Navigation. Grrr –  Josh Korn Mar 4 at 20:37
    
I don't believe the content organizer handles bulk updates but it has worked well for us for web content management. Too bad you can't use a term set that is already used. I haven't spent time with 2013 yet but is there a way to share those terms to a different taxonomy set so you would basically be mimicking your nav structure? Your metadata property could then point to that set. –  sween_sp Mar 4 at 21:35
    
Hmmm ... Perhaps I didn't understand this correctly. It looks like I can't just add a custom property to the Pages library -- the Content Organizer seems to want it as a part of the actual Page content type. The other problem is that the property is not front and centre when I add the page -- it's hidden (so to speak) in the Page Properties dropdown, and I'm not sure the customer would remember to fill it in. Is there a way to add it to the New Page dialog? What I'm looking for, of course, is a way to make this foolproof. –  Josh Korn Mar 5 at 15:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.