Turn Off "Smart Quotes" in PowerPoint 2013

There are so many times when software is designed to do “smart” things for you. In many cases, those things aren’t as smart as they seem in actual practice.

image

Here’s an example of something that really gets in my way. Microsoft Office loves to convert “straight quotes” to “smart quotes”. If you’ve ever wondered why your single or double quote characters seem to curl up after you type the closing one, this is what is going on. It’s probably great if all you ever type is prose, but almost everything I type into Microsoft Word or PowerPoint has at least some code in it. When the straight quotes are converted into smart quotes, the characters are no longer valid code in almost every programming language.

Here’s how you can turn off this “smart” behavior in Microsoft PowerPoint 2013. (Sadly, with every new release of Office, this type of little setting seems to move to a new “undisclosed location”.)

SNAGHTML17f6b789

image

SNAGHTML17f85464

SNAGHTML17f91783

Uncheck the “Straight quote” with “smart quotes” box.

SNAGHTML17eea994

SharePoint-Videos.com: JavaScript and jQuery for SharePoint 2013 Training – Online Class

SharePoint-Videos.comNext Thursday, May 23rd, 2013, I’ll be teaching a class for SharePoint-Videos.com called “JavaScript and jQuery for SharePoint 2013″. It’s an online class that is available to everyone, but it’s filling up fast.

This will be my first class fully focused on jQuery with SharePoint 2013, and I’ve had a lot of fun putting it together. SharePoint 2013 is more geared for great client-side programming opportunities than prior versions. Adding these development techniques to your toolkit can really help solve business requirements and improve the SharePoint user experience.

Here’s the registration link if you’d like to join us, and the class outline is below.

Class Outline

A jQuery Primer for SharePoint

  • Learn the important functionality of jQuery in SharePoint context
  • Find the parts of the page you need to work with using selectors
  • Traverse the Document Object Model (DOM) to act upon related elements
  • Manipulate elements to change their behavior, look, or structure
  • Bind to DOM events to add behavior and functionality
  • Use jQuery effects to add pizazz
  • Interact with the SharePoint server or other external services using AJAX
  • Improve the user experience and process by using deferred objects

SharePoint Client-Side Programming

  • Discuss the different client-side options: CSOM, REST, and SPServices (SOAP) and how to use each approach
  • Review examples of equivalent functionality using all three methods
  • Discover when each approach is best
  • Overview of the new App model
  • Find out when client-side programming makes sense and when it doesn’t

Richer UIs Using jQueryUI and Other Script-Based Plugins

  • Configurable dialogs
  • Improved calendaring
  • Drag and Drop
  • Autocomplete
  • Image Rotators

SharePoint 2013’s Search Continuous Crawl: An Enigma

I’m doing some work in SharePoint 2013 and we want to take advantage of as many out of the box capabilities as possible. We’re replacing an existing Intranet that has grown up in SharePoint from 2007 to 2010, and we’d like to rebuild with as little custom code as possible, since SharePoint 2013 now contains features that had to be custom built in the past.

The Intranet is build using a Publishing Portal and we want to use the Content Search Web Part (CSWP) to surface content in places like a home page rotator (the latest stories of certain Content Types within relative date ranges), in several “archive pages” (a list of the historical content, sorted by descending publishing date), and using search with the Search Results Web Part (SRWP) and the Refinement Web Part (RWP) in a page. The user stories and use cases here are not really all that complex: let’s show people the latest content of predetermined types regardless where it was created in the Publishing Portal.

The new Continuous Crawl capability in SharePoint 20103 sounds like it will fit the bill for us. We want the content that users see to be as fresh as possible. In fact, the TechNet article I link to below says that with Continuous Crawl “[t]he search results are very fresh, because the SharePoint content is crawled frequently to keep the search index up to date.” Sounds perfect, but we need to understand more about it.

We haven’t done much at all with the Search Service Application. We’ve got one Content Source, which is “Local SharePoint Sites”. In other words, it couldn’t be much simpler. Since search will underlie so much of the functionality, we need to understand exactly how the crawls are going to work and what sort of lag time we can expect users to have before they see content that is published. We can’t figure out exactly how Continuous Crawl works under the hood, so today I tried to do some experiments.

I set things to have no schedules to start out just to make things as fresh as possible, and just in case, I did a Full Crawl.

clip_image002[6]

clip_image004

When the Full Crawl was done, the Content Source showed this status:

clip_image006

Next I clicked the Enable Continuous Crawls radio button. Note that when I did this, the Incremental Crawl schedule was automatically set to every 4 hours. This can be changed, but the incremental schedule cannot be set to “None” while the Enable Continuous Crawls radio button is selected.

clip_image008

The Content Source status changed to this:

clip_image010

In the log, it looks like an Incremental Crawl fired off when I saved that change at 11:34.

clip_image012

I waited for the Incremental Crawl to complete and published a new News Item at 11:37. The new content showed up in the CSWPs and the search results around 11:55. For some reason, a new Incremental Crawl started at 11:55 (21 minutes after the previous crawl).

clip_image014

clip_image016

I added some more new content at 11:58. That content showed up in the CSWP by 12:09. (I’m not sure exactly how many minutes it took to get there, but it was less than 12.) There’s nothing in the logs to indicate that a crawl occurred:

clip_image018

At 12:30, There was still nothing new in the logs:

clip_image020

All in all, this is still confusing to me. Continuous Crawl seems to be working, but at some underlying schedule which isn’t visible. There have been some suggestions that the Continuous Crawl schedule is set to every 15 minutes by default, and the evidence above seems to support that since the second piece of content showed up in 12 minutes, about 15 minutes after the last crawl that was visible in the logs.

There is some PowerShell you can use to get at properties of the Continuous Crawl, but it’s not totally clear what impact they have on the schedule.

$ssa = Get-SPEnterpriseSearchServiceApplication

$ssa.SetProperty(“ContinuousCrawlInterval”,1)

Another thing that’s not clear is how many Continuous crawl threads might stack up if things get backed up. One person has suggested an unlitimited number and someone else told me there’s a maximum of 8 threads. Obviously, there’s not a clear understanding of this, either.

In researching things, there articles/posts seem useful:

This TechNet article is way too vague and only focuses on what buttons to push to turn Continuous Crawl on or off:

In my opinion, we need some much clearer documentation from Microsoft to explain how all of this holds together and I’m trying to track down the right people to see if I can help to make that happen. If you know who those people are an could give me an introduction, I’d appreciate it.

jQuery Library for SharePoint Web Services (SPServices) 2013.01 Released

Tonight I’ve released SPServices 2013.01. If you are using an earlier version of SPServices, I strongly suggest that you upgrade to this version, as you will see some performance improvements and there is some nice new functionality. Thanks to everyone who downloaded the beta and provided feedback.

jQuery Promises

By far the most exciting thing in this release is jQuery promises, or deferred objects. I’ve written about this several times already herehere and here. I won’t belabor the point too much, but if you’re interested in increasing the efficiency of your code and getting ready for the way you are likely to work with the REST Web Services in SharePoint 2013, you should get familiar with using promises.

Other Release Notes

There are other goodies in this release, and you can see the full list of enhancements and improvements on the download page. Note the link to the Issue Tracker items for this release. I’ve gotten a bit lazy with the release notes, so for this release the items in the Issue Tracker contain all of the details.

Determine if a SharePoint Publishing Page Is in Design Mode (Edit Mode) with Script

Today I was working on some script for the home page of a SharePoint 2013 site which added the jQueryUI accordion behaviour to all of the Web Parts within a Web Part Zone. When I went into edit mode, it was pretty frustrating to have the accorsdions kick in, so I looked around for a way to check to see if a publishing page is in editing mode with script. I’m pretty syure I’ve done this before, but it’s been a while and I couldn’t find anything in my kit.

Somewhat to my surprise, there were a lot of questions about how to do this out there, but not a lot of good answers. Most of them came down to looking for some element that would only be in the page in edit mode and sounded a little kludgy.

However, I found one over at SharePoint Stack Exchange from Andrey Markeev in a thread called How do I know if the page is in Edit Mode from JavaScript? that looks pretty solid to me.

I’m taking the liberty of including the code here, since this is the first place I look for answers!

var inDesignMode = document.forms[MSOWebPartPageFormName].MSOLayout_InDesignMode.value;

if (inDesignMode == "1")
{
    // page is in edit mode
}
else
{
    // page is in browse mode
}

This will refer to value of the following html input control, which is rendering on the page when it is in edit mode:

For wiki pages, you will need the _wikiPageMode parameter:

var wikiInEditMode = document.forms[MSOWebPartPageFormName]._wikiPageMode.value;

if (wikiInEditMode == "Edit")
{
    // wiki page is in edit mode
}
else
{
    // wiki page is not in edit mode
}