I have been using Firebug for more years than I can count and I have been an avid supporter. In fact, Firebug is probably the one reason why I continue to use Firefox as my go to browser for web development. Today, however, I noticed a new entry in my contextual menu called “Inspect Element”.

Of course I clicked and I have to say, I really liked what I saw. The way the elements are highlighted with a lightbox effect is quite nice, and the interface just feels more mature to me then firebug or other native Inspect Element menus. It has certainly grabbed my attention, and I am definitely going to use it for the next few days.   Maybe it will win me away from my old standby.

The root site I was working from was created using the Team Site template and from there I clicked on Site Actions > New Site.  Up popped a new site creation dialog with a nice carousel effect, allowing you to scroll through a set of “Featured” templates. The templates that they choose to feature were focused on collaboration, communication and contact management. Which is inline with what I would expect when targeting small to medium size businesses wanting to consolidate these aspects of their business.

What I did not see was  the Publishing Site template in this section. So, I selected the “Browse All” tab and the view changed to the familiar Create Site dialog that listed the available Site Templates that one would normally see in SharePoint 2010. I  scrolled down to select the “Publishing Site” template, and happily created my site, vaguely wondering if I would see the Adventure Works logo or not when it was done. A second or two later the page refreshed….and…well, this is what I saw:

You are presented with what appears to be a completely empty Team Site. Nothing is quite as terrifying as staring at a white, blank page, especially if you are potentially working with a new system. I was hoping that Microsoft would have taken this opportunity to add some welcoming help content as a way to guide people through the experience. What would have been nice to see here was a bit of an explanation about how to get started with SharePoint. How to edit and publish a page, what a web part is and how to add one, or explain the difference between a site and page. Essentially information that someone new to SharePoint might find useful or necessary.

Now that I have determined that the publishing template simply creates a Team Site with the publishing features turned on, I dove in and started editing the page. I was curious to see if anything had changed from a page layout perspective. Once in edit mode, everything looked like it normally would right down to the fact that the Welcome Links page layout was the default used when you create a new publishing sub site.

I added some content to the page to test out the built in styles like the headers and callouts. Everything looked pretty standard and the classes that are applied are consistent to what are being used for SharePoint 2010. This makes me happy since I already have design patterns that target these classes and structure.

The next thing I did was create a new page. I found it curious that it used the (Welcome Page) Table of Contents page layout as the default page layout. I can’t imagine that being very useful for people that have chosen to create a publishing site. I mean, how many table of contents pages does a site actually need? So, I went ahead and changed the default page layout to something more useful for a publishing site, the (Article Page) Body only page layout.

And…that’s where I stopped for the night.

Conclusion

My first impression is that SharePoint Online is very much targeted for the quick creation of collaboration sites. Unfortunately the power of the publishing infrastructure, upon which a rich Intranet experience can be built, is not immediately evident. Imagine how improved the initial experience could be for people that have never used SharePoint before if there was a guided process to help introduce them to the power of the platform upon the creation of a site.

I will be certain to share more thoughts, tips and tricks as I dive deeper into SharePoint Online.

The Problem

Scrolling did not work when visiting the site using:

• Google Chrome
• An iPad or iPhone that was running iOS4
• Google Android phones

The Solution

I was able to identify that the source of these scrolling issues was due to the manner in which the static placement of the SharePoint 2010 “Ribbon” was implemented. Essentially the default browser scrolling behaviour has been overridden and replaced with a JavaScript solution that has a few problems. While I appreciate the improved authoring experience that the static ribbon provides for content authors, it serves no purpose for anonymous visitors to the site.

Below is what I did to hide the ribbon control, and override the JavaScript scroll bar if you are an anonymous visitor.

Let’s just jump right in, shall we?

Psst…If you don’t care about the “why?” and just want the final solution go ahead and download my updated v4.master.

Step 1: Right above the closing head tag you want to place the following LoginView snippet.

Why? Because we want to override the body.v4master { overflow: hidden; } default SharePoint declaration but only for anonymous users.

     <asp:LoginView id="LoginView" runat="server">
          <AnonymousTemplate>
               <style type="text/css">
                    body.v4master { overflow:auto; }
               </style>
          </AnonymousTemplate>
     </asp:LoginView>

Step 2: Remove that pesky scroll=”no” on the body tag.

Why? Because if we don’t then we will not be able to scroll on IE7.

Look for this:

<body scroll="no" onload="if (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();" class="v4master">

And replace with this:

<body onload="if (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();" class="v4master">

Step 3: Hide the Ribbon Control so it only appear when the user has the ability to add or remove personal Web Parts on a Web Part Page.

Why? I do not want the ribbon control to load unless the user is logged in. I tried using the AnonymousTemplate logic above but it created some other issues which will be a follow up post.

Security Trimmed Control, Permissions … What? Yeah I thought the same thing the first time I discovered this control. You can read more about the different built-in permissions available in SharePoint Foundation over here: SPBasePermissions Enumeration. It’s worth your time to take a look.

Look for the id=”s4-ribbonrow” and include the SharePoint:SPSecurityTrimmedControl above it:

<Sharepoint:SPSecurityTrimmedControl runat="server" Permissions="AddDelPrivateWebParts">
     <div id="s4-ribbonrow" class="s4-pr s4-ribbonrowhidetitle">
          <div id="s4-ribboncont">

Now to close the tag look for the closing #s4-ribbonrow div tag, and add the closing SharePoint:SPSecurityTrimmedControl tag.

                    <Triggers>
                         <asp:PostBackTrigger ControlID="WebPartAdder" />
                    </Triggers>
               </asp:UpdatePanel>
          </div>
     </div>
</SharePoint:SPSecurityTrimmedControl>

Step 4: Only display the the #s4-workspace div if the user is logged in.

Why? Because through JavaScript SharePoint adds an inline height and width to this div that is then referenced in their scrollbar JavaScript code. In my solution I did not need, or want it, for Anonymous visitors.

NOTE: The opening and close #s4-workspace divs will now appear yellow because the MasterPage will not be able to see that they are in fact matching tags. Do not worry though because once the page renders for the visitor, everything will work just fine.

Search for div that has id=”s4-workspace” and replace it with the code below.

<asp:LoginView runat="server">
     <LoggedInTemplate>
          <div id="s4-workspace">
     </LoggedInTemplate>
</asp:LoginView>

Search for the closing #s4-workspace div and replace it with the code below.

<asp:LoginView runat="server">
     <LoggedInTemplate>
          </div>
     </LoggedInTemplate>
</asp:LoginView>

Step 5: Download my updated v4.master with all the changes described above.

Caveats

While this solution worked for my scenario, I obviously can not promise it will work for you. I did notice one issue of a double scroll bar if a content author accessed the the site using IE7. This particular authoring scenario was not a requirement and the client agreed it was an acceptable trade off.

I also wanted to thank the people that took the time to create their own tutorials that helped me with my own solution.

• Hiding the SharePoint Ribbon from Anonymous Users
• SharePoint 2010 Scrolling
• Hide the Ribbon from Anonymous Users

Cheers!

Well, I was not entirely correct on that last assumption. Sure they might be easy if the author has a basic understanding of HTML, but without that knowledge these methods can become frustrating. At some point the author will perform an unexpected keystroke in the rich text editor, causing something to go awry. Maybe it’s an odd line break or a tag that will not seem to close. At that point they can delete what they have done and start again, or look at the HTML and see if they can track down the issue. For an author that only wants to have the page published as soon as possible, both options could be time consuming and less than desirable.

This is where the Summary Link Web Part comes into play. I find myself leveraging this particular web part much more often, spending the time to ensure that all the built in styles work with the overall design of the site.  This gives the author many more options to add stylized links to the page without having to fiddle with any code. They simply fill out the fields in the add new link dialog and click OK. They can also easily group and reorder links without having to deal with the mess that can happen when you copy and paste in a rich text editor.

Does the bloated mark-up still bother me? Sure it does, but when I train authors and see how much easier it is for them to use this web part compared to watching them struggle with code snippets, I feel the trade off is acceptable.

Interested in seeing what the Summary Link Web Part can do? Check out Microsoft’s “Use and configure a Summary Link Web Part or a Summary Link field control” article for a step by step explanation on how to use its functions.

After a bit of time wading through the Google Analytics interface, I was abashed to admit that I could not find the stats for screen resolutions anywhere. So, the next day I asked my workmates for some help and after a bit of time clicking around Pete was able to help me track down how to display the screen resolutions for mobile. I thought I would share it in case someone else found locating this information a bit frustrating.

Step 1

In the left hand panel of the Google Analytics Dashboard select the “Devices” section located under “AUDIENCE > Mobile”

Step 2

Click on the “Select” drop down beside the Secondary dimension label. Expand the “Technology” heading and select “Screen Resolution”

Step 3

Well there is no Step 3 to be honest except to maybe go and treat yourself to something nice for working so hard.

Well last weekend I decided to do something about it. I gave myself a deadline last Saturday to design and implement a site by this Sunday. Well it’s Sunday night and I am pretty excited to say that I met my goal! Despite the holiday parties, decorating the apartment, christmas shopping and several get together’s with friends, I was able to carve out enough time to complete the mini project.

I have a few things that I am still hoping to iron out, images I want to combine, and a mobile site to create. Overall though I am happy to finally have Brain Lava up and running. A friend once said it’s OK if the beginning is not perfect…at least it is a beginning.