Sharepoint 2013 and Responsive Web Development

"Depending on what channels you define, you may want several designs, and so several HTML files, where each file gets converted into a separate master page. Also, each HTML file (and so each master page) can reference its own CSS file. Before you design your site, device channels are one of the first things to consider." Sharepoint 2013 Design Guide

Never let it be said that there was ever any party, anywhere, to which Microsoft could not be late. It could be at eight PM on a Thursday next to a transit stop, and they would take the streetcar in snow. Invited to an auto show, they would purchase a BMW, cheering as they did so BMW's long association with not only jerks, but jerks lacking the confidence and funding for an Audi.

Microsoft has missed the invitation once more, and this time, with responsive web programming.

via @Stammy

This is what the web looks like. Planning a resolution to display at and then laying out careful HTML for each view is unfettered nonsense, like trying to make Windows Forms work on the internet, or relying on the Table Ta-
I'm just going to pour some rum in this nog before we continue because of course they did this on purpose. The M in Microsoft stands for Malice Aforethought.

People, the internet is not static. It's controllable, but the control isn't yours and never will be. The control belongs to the people with money, which, even if you are a market capitalized publicly-traded corporation, you still can't control the other companies with money, and they are going to make tiny glass panels in every size they think will make a dime. Planning for a specific device resolution is insane, because you have no idea what people are reading their e-mail on. You could plan for the models on the left, but your interns own the things on the right, and you have no budget to buy an intern a phone. This means there's no device resolution planning, unless your organization wishes to both sign an exclusive contract whereby Apple gets to spy in every one of your supposedly private company documents, and then pay for you - and your intern - to have an iPhone. Your organization has no money for that! They can't even get it together to buy printers.

Microsoft has the power to repair this type of boondoggle, because they have the money to churn out Sharepoint, and that means that if they had the willpower, they could almost certainly pre-populate Sharepoint with actually functional responsive web layouts. They simply don't want to do that, because it would mean admitting that they are no longer the most important or most relevant company on the block.
You can tell they're trying to do better with usability, and also that they would rather chew off their own tits than cooperate with Apple and Google. Sometimes I find condescending phrases like "This shouldn't take long" with no process timer on a job that runs for an indeterminate length of time, so I know they mean well.

One layout, perfect mobile, served from inside the house. They could almost certainly put the work in to crack "automatically responsive image down-sampling" or "web fonts" or "any actual web problem," and for the moment, this sort of nonsense is just embarrassing. It's straight admitting they think they have a hope in Hell to be cool or useful or the company they were when they had a visionary running them and Douglas Coupland writing positive books about their nightmarish corporate culture as though it were a good thing.

Of course, Sharepoint is popular with organizations such as the NSA, where Edward Snowden was a systems administrator. So let it never be said that good things cannot come from purposefully obfuscated and repulsive bureaucracy: if it weren't for Sharepoint, we may never have known that the NSA loves spying through MS products like Skype best of all.

System Account Needs Permission to Everything.

When you first set up Sharepoint, you will notice that it has the threat detection model of a particularly twitchy cockatoo, or possibly the NSA. It simply doesn't handle threats appropriately. People are locked in or out, permissions and abilities are set up strangely, and you may need to grant people List Management instead of Contribute to make sure that you can use lists to track data at all.

Sharepoint! It is working on it, okay, it is not its fault.

So! You have set up a list and some automagical workflows, and those workflows do automagical document approval, or possibly pass information to people's cellphones. But you are personally not logged in! Even though sometimes you just do it all yourself because it's simpler than trying to create an adequate permission system within the system.

You could maybe foist that one off on whomever manages your Active Directory, but knowing your "organization," a loosely-defined term if ever we've heard one, that's you.

The account that by default is assigned to permit and handle all automated flows within your organization is known as System Account, and it is absolutely essential that you don't kick it off your subsites or all of your automated approval workflows will break, because they do not inherit the AD permissions of the person to whom the approval task was assigned.

I am certain this is for good reasons, well, reasonably sure, and therefore, don't remove System Account.

What's that, you say? This superuser account which is specifically named by default to every library, group, list and site in the build may be a security issue?

Excellent.

Take careful note of it, least you ever need sell insurance paperwork from the mid-2000s to the Russians, and leave it on your structures. Taking it out causes headpain.

Upload Tracking Without Analytics

Sharepoint does a lot of enterprise-level things well, assuming you have many enterprise trained technicians to operate it, and learn the hidden languages of Exchange Server. Or whatever they're using back there, I assume it's something related to SQL. But let's say you're cut off from your out of the box analytics and you still want to be able to see each and every document uploaded into the site. Then you want to copy and paste that information into an excel table, presumably for Metrics.

There is probably a better way to do this sort of Metrics, but the thing about a closed development environment like MS is that it is not so hot at the SEO, and that means I can't find anything of value by googling "Sharepoint 2010 track user uploads." I have to believe this is traced in the logs somewhere, but really: there's faster way.

Here is where we get into customising the CQWP, or the Content Query Webpart, also known as the webpart that lets you see what is going on in your installation. The CQWP is the backbone of Sharepoint list investigation, and can be transformed to do a vast number of data-display tasks, as Heather Solomon once recorded (gosh she's great).

So. Open up Sharepoint Designer. Be prepared to revert everything, an awful lot. I recommend doing this in, say, a totally separate Sharepoint from your main one, because borking this will bork the site.

1. Go to your Style Library.
2. Copy your XSL Style Sheets Library into a new sub-folder so you can edit the CQWP main styles without destroying all your pre-exisiting content rollups for your whole site.
1. Failed at that? Revert everything to the site definition in Designer. You saved your code, it'll be fine.
3. Create a content webpart wherever you want it to live, note dismally that you will be writing some new styles for this, and export it.
4. Open that sucker in Designer (Notepad++) and find the <MainXSLLink> XML tag - it should be Line 69. Replace it with:
• <property name="MainXslLink" type="string" >/Style Library/XSL Style Sheets/EditedStyles/ContentQueryMain.xsl</property>
• If you want to be fancy, you can replace <ItemXSLLink> as well. It's not as important, because it simply provides a list of item styles for your site as a whole, where the MainXSL is a control document that dictates how all your CQWP display.
• Don't fuck with that. Really.
• <property name="CommonViewFields" type="string">Author, Text;</property>
5. Save that webpart and put it into your development page. 
• I like to set a new title, limit the items displayed to 5 for testing purposes.
6. Open your new EditedStyles/ItemStyle.xsl in Designer/Notepad++
7. Add the Debug style because you'll be wanting it.
8. Check in everything and publish major versions of them, or else nothing will change and you will be mightily confused.
9. Reopen  EditedStyles/ItemStyle.xsl and add this to it:
• https://gist.github.com/pretentiousgit/6003434#file-xsl-tablegenerator
10. Publish that.
11. Go to your content editor webpart and edit its properties to be the table generator. It should be displaying your author, the date the thing happened, and a link to the file's title.

You have now stripped off the reporting privacy of anyone who ever uploaded a thing to their corporate intranet. The HR department can see _all_. So can you! Someone probably programmed this in C# once! But it wasn't you! And now you've reproduced their work except sort of slow and front-end style.

Congratulations! We're part of the problem.

Helpful Link:
http://sharepoint.stackexchange.com/questions/55128/remove-li-wrapper-from-content-query-web-part-contentquerymain-xsl

Helpful Link #2:
Here's some stuff from Heather Solomon:
New blog: http://blog.sharepointexperience.com/
Evidence of smarts: http://blog.sharepointexperience.com/2012/03/introducing-the-magic-data-view-builder/

Force Infopath Form to Open in Browser

Approval workflows are tricky and fragile and counterintuitive, and a lot of what I do on the daily is customize them to get around that issue. I repair issues like how they don't approve content but instead set an approval on a whole new unrelated field, or how when you set them up on Infopath forms, those forms show up inside whatever damn application they please regardless of even system-wide settings that are clearly tickyboxed to "Open In Browser, Not Everyone Has Or Uses Infopath."

Tricky.

1. Open Sharepoint Designer.
2. Open the offending workflow.
3. Open the workflow within that workflow that contains the renamed out-of-the-box Approval workflow.
4. Tricky.
5. Click "Change the Behaviour of an Individual Task."
6. Find the one that sends an e-mail to a Task Approver.
7. In the first line of the utterly useless bullet points is something that, nominally, will allow people to open a form for review.
• It is not a form for review, it is a portal to a severe system lockup.
8. Change the link from whatever nonsense it is using to
   [%Current Item:Encoded Absolute URL%]?OpenIn=Browser
9. Celebrate, as this actually works.

Now your infopath document-style XML form opens in the browser for all your users who have InfoPath installed but not the system resources to run it. Good day!

Content Approval Tasks Followup

Content Approval Workflows, or the automation of pushed paper, remain the full meat of my daily life. This is because everyone wants signatures on everything in a bureaucracy, and yet they drown in the wash of paper involved in telling their coworker that it is okay to leave the office. The jealousy involved in a coworker being permitted to leave the building may involve a grievance.

There are, no lie, people in bureaucracies who take their vacations in half-hour chunks on Friday afternoon, and we are here to make that process, of shredding edges off their lives through meaningless, grotesque task-management, we are here to make that process smooth like hot butter and twice as scalding.

The underlying theory here is pretty straightforward. The content approval task, as written, has two elements: Content approval and task approval. This is used to control Sharepoint's extensive performance management metrics systems, which can be shattered like glass with a breath of air.

It is barely possible that these might be reusable, however: this builds on the Content Approval post a ways back.

Here is what we're doing: normally, the content approval workflow is decoupled from the task assigned by the process. We are hooking the two together, so that when your manager Opens the Task in their e-mail and hits Approved, they're approving the actual vacation request they just reviewed.

This is necessary because Sharepoint, by default, hides its content approval buttons in the task ribbon amid a broad swath of other clutter. It also likes to hide the "Open Tasks" button, which: I don't even care any more, you know? I've been learning Ruby. And Node. And they're much more fun than this business, as well as being better paid and generally not having a lot to do with Sharepoint, which is a career glass ceiling for practically everyone. There are better things to care about, so here is the step-by-step.

1. Sharepoint Designer
2. List you want to add the workflow to
3. Add new workflow, on creation or change of list item Start Approval Workflow
4. Rename Approval(22) something useful.
5. Open Approval(22). 
6. Edit individual Task Behavior, because we're linking the Task to the Approval, as versus keeping the two separate.
7. Under Task Completion If Approved, add an item, Set Content Approval Status... and then...
8. Under Task Completion If Rejected, set _that_ status to Rejected.

Now, let's clean up that list.

1. Second workflow, dead vacation clearing
2. On item created or changed and manual start
3. If this CURRENT ITEM APPROVAL STATUS 
• Approval status is a uniform column unaffected by the addition of other workflows, and it is what controls whether things go live or not.
4. CONTAINS Rejected
• Contains is important here, as is the capitalisation, because all of these methods act on slightly dodgy returns, and you can't tell if the thing is reading the ;#0Rejected or the actual string Rejected.
5. Delete list item CURRENT ITEM
• I'm presently favouring this because it works nicely on individual items, but I have been known to use un-limited scripts that wipe all rejected requests on the arrival of any new request.
• Tryin' a catch me ridin' dirty...

This is more or less how you automate vacation requests.

Now you can watch people ask for half an hour off to go pick up their kids, and privately decide that, douchey as San Francisco may seem, at least they're not measuring your pee breaks.