List with Paging on the Bottom Control Template

One of our customers wanted to use the List with Paging control display template on their news page. For some strange reason this template positions the paging in the top right corner of the web part instead of at the bottom of the list, and preferably horizontally in the center.

I fugured there were two options to do this:

1) Use CSS only (usually my preferred way)

2) Create your own display template for the purpose

Now the problem with approach #1 is that there are other content search web parts on the page too, so if you make general rules to create space at the bottom of the ul.cbs-List, this will be applied to all of those CSWPs. There is no special CSS class to hook into in the paging template ul. So even at best, this approach is a bit of a hack because in order to target it properly, you would need to use some container identifier and thus cause the whole hack to break if the web part is moved to a different zone on the page.

Number 2 seems easy enough, though, and replicable, which is even better. I set to action, downloading the original Control_ListWithPaging.html template file and opening it for editing in Expression Web and saving it with a new name. 

First, I added another class to the ul.cbs-List element, in order to be able to target rules only to the CSWPs using my new template. Small enough change, don't you think? 

<ul class="cbs-List pagingbtm">

Of course I also changed the title of the html document to List with Paging on the Bottom.

<title>List with Paging on the Bottom</title>

No biggie, right? I then uploaded the file, just to check that it works. Which it didn't! This puzzled me immensely, especially since the error message said, that the div, body and html tags have not been closed. They are not closed in the original control template (at least not when I opened it in notepad to check) but that works fine. 

So fine, I closed those tags at the end of my new template file. The error message disappeared and instead my template worked perfectly. Well, almost. The little arrow icons weren't visible but at least there was no error anymore. I decided to ignore that for the time being and finalize my control template changes. 

As said, I could've done it all in CSS only (after adding the new class), but I decided to make one more minor change in html to make the css shorter and less vulnerable and avoid the extra space when there are less items than the paging limit. I moved the resultset to the beginning of the list, so that the paging became the last node instead of the first one.

The results are displayed by this variable:

_#= ctx.RenderGroups(ctx) =#_

It is originally right before the closing ul tag. By simply moving it right after the opening ul tag, the order is reversed.

<ul class="cbs-List pagingbtm>

_#= ctx.RenderGroups(ctx) =#_

When this was done and tested, I started looking into that arrow icon issue. Quirkily, the img src was pointing to a nonexistent file on my own computer! This can be blamed on Expression Web. It's a first, though! I'm quite used to SharePoint Designer pulling off sh*t like this, but Expression Web has generally been a very reliable editor and loyal to the original code. Not this time. 

I opened the original file in notepad and sure enough, the correct source string was there, intact. 

<img class="_#= $htmlEncode(nextPageImageClassName) =#_" alt="_#= $htmlEncode(lastPage.title) =#_" src="_#= $urlHtmlEncode(GetThemedImageUrl('spcommon.png')) =#_">

So I copied and pasted it to my template and all was well in SharePoint Land again.

Here's the CSS:

ul.cbs-List.pagingbtm li.ms-promlink-header {

    text-align: center;

}

ul.cbs-List.pagingbtm .ms-promlink-headerNav {

    float: none;

    margin-top: 6px;

}

SharePoint Dev Kitchen 2016

I was really happy when I heard that the embargo was being lifted on the current SharePoint development stuff, and I could finally tell the wolrd about the amazing SharePoint Dev Kitchen experience of this past March in Brussels. An invitation only -event for SharePoint dev community, the bootcamp was full of people with ideas, views and passion, and the core of the Microsoft SharePoint team.

The big meeting room was buzzing with electricity as we all settled into our seats to hear what the SharePoint team wished to share with us. The preparation emails had given but a little hint on what was happening in our SharePoint world. 

When the keynote ended, I felt a whoosh of delight. The SharePoint team was not only being candid with us but also looking to get feedback, thoughts and ideas from us who crowded the room. Still, the most exciting thing was the message [NOTE: this is purely PRE-RELEASE info]:

SharePoint is going towards more and more open source coding
Instead of doing a whole lot of behind the scenes closed-cirquit development, the SharePoint team has adopted the usage of JavaScript libraries and frameworks that enable the third-party developers to create add-ins and solutions for SharePoint with any JavaScript framework they wish to use.  

Mobile leads development
They were pretty clear on this one. All develoment is done mobile first. Not desktop first keeping mobile in mind but actually mobile first, then desktop experienve. 

SharePoint Home
If I had a euro for each time a customer has asked me: "But where's the SharePoint here in O365? There's only this Sites... is that it? But how do I find my workspaces if I haven't followed them?" As far as I understood, SharePoint Home will asnwer this question once and for all. It's where SharePoint is, it's where the workspaces are. 

A lot of nice new features are coming to SharePoint
Document libraries will get a bunch of new features. Publishing sites will get a new page model as an addition to the current one (i.e. the current publishing pages aren't going anywhere; your data is safe) with the feel of Sway to them - adding modules (or cotnrols or web parts, whatever the name will be) to a page canvas (or several). Publishing sites will get a gallery of these modules - new web parts - that are fully JavaScript based. 

Office UI Fabric
In addition to this new more open way of developing for SharePoint, Microsoft is providing a "fabric" of CSS and (HTML) controls for unified look and feel of any app or add-in that made for Office environments. It provides a grid for responsive design, fonts, animations etc. to be used freely - but no one is forcing it either.

One thing the Microsoft people really emphasized: the old way is not going away; this new model simply enable more.

Dev Kitchen was a very social three day "training". Sure, Microsoft people were giving sessions on what they are working on, the technologies that are used and there were hands-on labs to try out the things in a test environment. However, there was also a lot of discussion of ideas and questions and priorities and wishes and whatnot. There were a lot of people already getting their hands dirty with the new stuff, trying out real life scenarios and showing their work in demo sessions. 

Now the team is ready to come out with the stuff, but this is only the beginning. A lot is brewing in the SharePoint Dev Kitchen and it will be truly interesting to see the outcome! 

SharePoint Branding and the winds of change

Not that long ago, it was quite typical to create a major SharePoint UI solution for a SharePoint intranet. It would contain one or more Master Pages, CSS stylesheets, images, JavaScript, Page Layouts etc. The solution package was deployed to the server, the feature activated and automagically the intranet got its fancy custom UI and functionalities. A slight inconvenience though, that even the smallest change or improvement in any of the shipped files required updating the whole package.

It hasn’t been too long since I last was involved in such a big intranet solution. These days such projects are more of the exception than the rule. So, what’s changed?

One thing, or maybe I should say THE thing is Office 365. Cloud is becoming more and more popular and doesn’t even allow such huge full-trust solutions. Sandbox solutions are still an option, though according to Microsoft they are not the technology of the future – they already once declared them deprecated, but actually had to take it back pretty quickly. However, apps and other alternative ways of doing things (PowerShell, Azure powered functionalities etc.) are the modern and flexible way to build stuff on top of SharePoint, while keeping it separate from SharePoint.

I believe it’s not inaccurate to say that all the rest is just a byproduct of this. While more and more companies are switching to the cloud environments and Microsoft is developing “cloud first”, it is only natural for attitudes and ways to adapt to this change. Lightweight tweaking as opposed to heavy – especially with a heavy update process – custom software development sounds quite enticing.

Years ago, when SharePoint 2010 was launched and companies started to migrate from the old 2007 environment to the shiny new SharePoint in a fast pace, the game of the day was using OOB where ever possible and doing as little customization as possible. Mostly this still meant creating easily retractable solution packages for UI and custom web parts and services, distributed as features. SharePoint wasn’t re-coded anymore as it used to be in many cases with MOSS 2007; the solutions were built on top of SharePoint without touching the OOB stuff.

Then, along came SharePoint 2013. For quite some time the development and customization story was pretty same as with 2010, up until Online made its breakthrough and started to mold the models towards the more lightweight facelifts, apps, external services etc. The process of UI customization, branding, has shrunk from a heavy solution package to creating themes, some custom CSS and maybe a bit of JavaScript.

A color theme is a rather easy and quick way to apply the company branding colors to SharePoint. It already takes you a long way – the company colors are applied to the top suite nav, links, emphasis colors, headings etc. Creating a font scheme adds to this by implementing the company font – even a custom one – everywhere with one setting. What cannot be done by a theme is changing the placement and fancier styling of page elements.

The current default Master Pages seattle and oslo are built using div elements. This means that working with them – the placement, float, etc. – is pretty flexible and easy without needing to change the HTML of the Master Page, i.e. there is no need to create custom Master Pages simply to change how and where the elements are rendered on the page. There are limits to this, but you can do a lot with CSS.

Themes and an alternate CSS stylesheet are easy to implement in the UI of SharePoint, in the site settings, and they are inherited by any subsites with publishing feature activated. Implementing them to sites without publishing feature is a bit more work. Generally, this means pushing the inheritance from the top level each time a new site has been created.

JavaScript adds its own challenge to the equation. It is possible to globally inject JavaScript to all sites in a site collection using PowerShell. However, this should then be done for each new site too, when one is created. In single pages the Script Editor Web Part works nicely, but the global injection is always a bit of an issue. Mainly the options apart from the manual PowerShell injection are adding the script links to the Master Pages or creating an Azure powered service for provisioning the sites. 

The latter option is actually something to consider. Basically the idea is that people don’t create their sites manually but order them by creating a new item into an order list. A timer job polls the list and notices a new site order and launches a PowerShell script that then provisions the site with the exact settings, stylesheets, logos, Web Parts, lists, JavaScript links that are needed for each new site. 

Add responsive design to the equation. Currently SharePoint Online offers two view for mobile devices and the possibility to switch between them. One is the mobile list oriented view, the other one the full desktop view. The list oriented view works fine in team sites where all the content is mainly in lists, but publishing sites, the informative intranet pages, need to be viewed in full desktop experience on mobile devices too – in a responsive way so that it actually is readable.

Unfortunately, responsive SharePoint is still a bit of a everyone for their own – or has been, but I have just discovered that PnP has actually come forth with an awesome fully responsive solution that is purely CSS based! Previously the options have been e.g. bootstrap (heavy version), a responsive SharePoint solution from Codeplex (kinda heavy solution too); both of these require changes to the MasterPage. A bit of a no-no. 

Be as it may, responsive design is always more expensive for a customer than the basic design only. However, as the costs of branding have come down significantly with the lighter approach, it most definitely pays off to invest in responsive design, if not go mobile first. That’s where this world is headed anyway. 

[Originally published in Finnish in our company blog]

Javascript world clock with automatic time zones

One would imagine that getting a world clock - real time with automatic time zones including daylight savings - wouldn't be that difficult to include on your web site. On a standalone web site it probably isn't since there are several free or low cost solutions available. But in SharePoint it wasn't quite as straightforward.

One of my customers, a global company, already has one solution implemented on their intranet site, but there are two problems with it: it only refreshes the time on page refresh and the daylight savings (i.e. offset for each time zone) need to be adjusted manually every half a year. So I began to look into the options for modernizing this world clock of theirs.

First thing I realized was that most of the ready made solutions rely on PHP. This is already a no-no in SharePoint. Then I came accross this very cool site http://www.clocklink.com/ which has built in time zones and a multitude of analaog clocks (using html5 or flash). These could be used in SharePoint quite easily per se, and I even found a pretty neat solution using a SharePoint list to create a multitude of easily maintainable clocks. Check it out at Path to SharePoint. 

However, this requires cross-domain queries and moreover, when working in e.g. SharePoint Online, queries from https to http wich pretty much is a showstopper here. 

At this point I was starting to be pretty frustrated. Being so close and still so far away from a working solution. Then along came moment.js. A life saver, so to speak. Plus a very elegantly written tutorial for creating an analog clock using javascript and html5 canvas.

Combining all this plus a little bit of jquery I finally came up with a fully SharePoint (Online) compatible world clock solution (though I actually ripped the canvas part away, as I only needed a digital time display with some additional info). So, let's do a walk through for the benefit of the next one needing to do something similar:

1) Download moment.js (or min) and the suitable version of moment-timezone (from the Moment and Moment Timezone pages). Optionally also download jquery-file to avoid any cross-domain calls.

2) Upload the js-files into a suitable library in SharePoint, eg. Site Assets on the site.

3) Create a test file for compiling all the needed code to add to the script editor web part on your page and first off, add references to the js-files in the SharePoint library.

<script type="text/javascript" src="../SiteAssets/jquery-1.10.2.min.js"></script>

<script type="text/javascript" src="../SiteAssets/moment.min.js"></script>

<script type="text/javascript" src="../SiteAssets/moment-timezone-with-data.min.js"></script>

4) Add a bit of CSS:

<style type="text/css">

.current-time {

display: block;

font-weight: bold;

text-align: center;

width: 200px;

padding: 10px;

}

.clockcontainer {

  background-color: lightblue;

  border: 1px solid blue;

  border-radius: 5px;

  float: left;

  margin: 5px;

}

</style>

5) Add the javascript logic:

<script type="text/javascript">

document.addEventListener('DOMContentLoaded', startTimer);

function startTimer() {

    setInterval(displayTime, 1000);

    displayTime();

} 

function displayTime() {

jQuery(".clockcontainer").each(function(){

var timezone = jQuery(this).attr("title");

var zonetitle = jQuery(this.firstElementChild).attr("title");

var now = moment().tz(timezone).format("h:mm:ss A");

var day = moment().tz(timezone).format("dddd MMMM DD, YYYY");

jQuery(this.firstElementChild).html(zonetitle + "<br/>" + day + "<br/>" + now);

});

}

</script>

(Note the jQuery instead of $ - in SharePoint this generally works more reliably)

6) Copy and paste all of the above to a Script Editor web part on the page where you are adding the world clocks, preferably somewhere close to the bottom of the page.

7. Add a Content Editor web part on the page where you want to display the clocks.

8) Edit the source of the CEWP content and add the clock elements (as many as you wish, but note the highlighted parts):

<div class="clockcontainer" title="Europe/London">

<div class="current-time" title="London">

time</div>

</div>

9) Modify each element to put out the correct time zone (title of the clockcontainer element) and the label for the clock (title of the current-time element). Check proper time zone names at the momentjs site.

That should be it, folks. Now, your SharePoint page should display correct times for your chosen time zones, e.g.

Momentjs offers plenty of options for time and date formatting. 

Tip: Targeting a specific SharePoint site with global CSS

Just a little css tip, that came out handy today. Generally, with a global css (say, an alternate style sheet that is deployed throughout the site collection), you don't even attempt targeting some specific site, but go with the global styles instead. Today, however, I was struggling to display the titlerow (logo and navigation) in the enterprise search center without having it become visible in the dialogs as well.

Some Microsoft logic it is, I guess, that the search center by default hides the site collection navigation using the same class as the dialogs, the .ms-dialogHidden. And as anyone working with SharePoint CSS knows, the sites have no IDs in the body tag so that you could e.g. tell your css to display the navigation in search site but not in the dialogs. None, except for the action attribute in the form tag.

I guess it never was as big of an issue before, since I never thought of it before, but indeed, in a site collection already populated with sites, you can target one specific site by using the attribute selector for form tag in your css rule, for the form action contains the relative address of the site in it + in SharePoint, the whole page is always inside of that form tag. So here's the rule for un-hiding the titlerow for this specific search center, just as an example:

form[action*="searchcenter"] #s4-titlerow.ms-dialogHidden {

    display: block !important;

}

And, yey, the dialogs remain untouched and furthermore, there is no need to impelemnt page level css on each and every search center page.

Going HTML with MasterPages?

One of the big new things in SharePoint 2013 is option too create MasterPages as plain old HTML files and let SharePoint then convert them to .master files, adding all necessary asp.net code into the file. How this works, is that basically any web developer can create a master frame in HTML, without needing to worry about the SharePoint specific stuff at all at that point. Then that file can be converted in SharePoint, and the needed SharePoint controls can be added to it as ready-made snippets.

As a professional doing SharePoint branding solutions, my first question here was "why? why would I want to do it like that?" And after trying it out, I concluded that most probably in most cases I wouldn't. But it doesn't mean that someone else wouldn't.

Let's take a look at this scenario:

There is company A who decides to go into SharePoint Online with their intranet site. They use an advertizing company B in all their design, web and otherwise. So with this new intranet project they turn to their ad company B for a fresh design for the intranet in Office 365 SharePoint Online.

With 2010, what would've happened is that the ad company B would've made a nice intranet site design, which would've been delivered to company A as image files and probably a PhotoShop layout file. The company A would've partenerd up with company C to create the branding for the site as a sandbox solution since you cannot deploy farm solutions to SharePoint Online.

With SharePoint 2013 one would need to rethink the usage of sandbox solutions: Microsoft claims in msdn and technet articles that sandbox solutions have been depracated in SharePoint 2013 [edit. Jan.3rd 2013: this information does not exist anymore], but there is controversial information around the interwebs about whether they actually are dead or not. Be as it may, we pretty much ought to forget about creating a sandbox branding solution for SharePoint 2013. So then, what are the options?

1. The ad company B designs the layout as a PhotoShop file, delivers it to company A, who then delivers it to company C where the branding dude creates a MasterPage out of the layout file. And if and since sandbox solutions are out of the equasion, the branding package will most probably be created as a Design Package. (Stay tuned: I will be posting an article about them too sometime in the near future)
   
   The branding dude (or dudette ;) ) here has an option: (s)he can either go with a .master MasterPage, or create an HTML MasterPage and use the SharePoint conversion and the snippets provided by SharePoint in Design Manager.
2. The ad company B has a web designer who goes to the extent of creating the HTML frame (and probably also the CSS style sheet) and delivers these to company A together with all the graphics that are needed.
   
   Now, if company A happens to have an employee, who understands enough both SharePoint and HTML (and CSS) to go through creating the Design Package himself, probably the task would stay in-house. Pretty much the same way as some companies have created their SharePoint (Online) 2010 UIs with SharePoint Designer 2010 when there was a capable person on the payroll.
   
   If they don't have the recourses to do this in-house, then the HTML and CSS etc. would again need to be delivered to company C, to the hands of the branding dude(tte). And then again, (s)he would still have the choice to extract and import the HTML to a .master or to use the HTML as is and let SharePoint take care of the conversion.

On both occasions, I have stressed the still standing option of creating and using a .master instead of the HTML with the snippets. The reason behind this is that I don't see the latter option necessarily as the best one when the one creating the MasterPage is actually capable of doing it the old-fashioned way. Why is this?

Because, even though the converted HTML Master is a completely valid MasterPage, and the snippets relatively easy to add per se, the process is not an altogether simple one. 

The look and feel of the controls can be customized before copy-pasting the code snippet to the MasterPage. But this creates a whole lot of inline styling to the control, on the MasterPage, so if later on company A decides to do a facelift to their site, instead of some centralized changes in the CSS file, the actual MasterPage needs to be edited.

With this, I also encountered a problem that if I changed the inline code straight on the MasterPage, my changes did not take effect; I needed to customize and copy-paste the snippet all over again (don't know if that was some bug of that specific environment; it was RTM, though).

You can preview the MasterPage in the browser while working with the snippets. But in order to do that, you need to open the converted HTML file for editing ( edit the masterpage, you DO NOT open the .master file). 

Which means that you need to open the file form the Master Pages and Page Layouts Gallery. Unfortunately there still is no way to open a file for editing if you open this gallery in the browser (like the Design Manager suggests), so you are faced with a few options:

• you can download a local copy of the HTML file, insert the snippets, save locally and occasionally upload a new version of the file to the gallery. This takes away from the instant preview, though.
• you can map the gallery as a network drive in your Windows Explorer. This may not be the first thing I would reccomend, but it allows you to open the HTML file in your preferred HTML editor, whether it be Notepad or Dreamweaver or Expression Web or whatnot - but not SharePoint Designer 2013, not with this option.
  This enables the instant preview since you are editing the file straight from the gallery.
• you can open the Site Collection in SharePoint Designer 2013, navigate to the Master Pages Gallery and open your HTML file for editing in SPD. This prevails the instant preview. But remember, there is no wysiwyg editor in SharePoint Designer anymore in version 2013.

After tackling these two issues in a satisfactory manner, you are well on the track with creating the MasterPages as HTML instead of using Visual Studio to create .master files. There is a time and a place for everything, and that applies to HTML MasterPages too. Oh, and mind you: the Design Manager is only available on publishing sites (or when publishing infrastucture is enabled).

[More articles on SharePoint 2013 Branding,
e.g. Going HTML with MasterPages?

Creating a Design Package for SharePoint 2013
How to Create HTML Page Layouts for SharePoint 2013

The Anatomy of SharePoint 2013 Display Templates
How to Deploy Display Templates via SharePoint feature]

First Touchdown With Napa - Building Apps for SharePoint 2013

"Napa" is the new tool set for building cloud based apps for Office and SharePoint 2013, hosted in Office 365. Getting hands-on with it, I was quite impressed. See instructions for how to get started on the MSDN Office Developer site, where you can of course also find more detailed documentation on building the apps.

I signed up for my own developer site yesterday, and tried it out today for the first time. And I must say, it is a nice and fluent way of creating apps for SharePoint!

Once you have the site and Napa all set up in your development environment, you will find the Napa tools in the Site Contents:

After launching the tools, you can create a new app project with a couple clikcs, and later on, you will find all your apps here, in the Napa Tools.

You can create both different types of Office apps and SharePoint Apps by clicking Add New Project.

The most simple way to create your app is to do it right in the browser! The default SharePoint app has several sample files to get you started:

The references between these files have already been made, so add your stuff an click Run Project:

and Napa takes care of packaging and installing, and uninstalling the old version when needed.

Just to get a small taste of how this thing works, I did a couple small customizations to the project, like 

• adding some text, an iFrame to display the web part, an a button on the default page

• a little bit of JavaScript in the App.js file to display the web part on the page (displaying the initially hidden iFrame)

• adding an editable paragraph in the web part 

• and slightly changing the css style of the Web Part content and adding some styling for the button.

There is something of an intellisense and error checking in the browser editor too; not full, e.g. it will not supply you with intellisense for JavaScript (most editors don't), but it does give hints and notify about errors:

When this little demo is run, this is how it looks after clicking the button to display the Web Part:

If you want to, you can also open a copy of the project to VisualStudio for editing.

VisualStudio11 and SharePoint Online

Since there already is a good article about the VisualStudio 11 for SharePoint Online solutions and since I myself haven't got around to actually even install the developer preview yet, let me point you to the said article on the Office365 site:

How to: Use Visual Studio 11 to publish solutions to SharePoint Online
http://community.office365.com/en-us/b/office_365_technical_blog/archive/2012/01/11/how-to-use-visual-studio-11-to-publish-solutions-to-sharepoint-online-grid-user-post.aspx

I found it enlightening and thus wanted to share it!

Design and Development in SharePoint Online vs. On-premises

And a little bit about planning the mobile sites as well. That was what I had a session about at the TechNet Helsinki 2011. You can find the presentation slides (.pdf) on the TechNet site (in Finnish) and the presentation video in Channel9 (also Finnish of course).

The important things to remember about SharePoint Online in sense of customizations, design, development, are that 1) there is no Farm Administrator role for the SP Online customer, only the SharePoint Online Administator, and 2) the things you can do with your SP Online site depend partly on the lisence you pay. So what it means, is that you are not able to install anything on the SharePoint server, nor change any server settings in SharePoint or IIS, and also that the license really does matter. Whereas of course, if you host your own SharePoint server, there are no such limitations. (See more about SharePoint Online licensing)

Customizations compared, in the browser your possibilities are equal with these two - and in a sense here lies the true power for SharePoint Online development: utilizing the power of the client! You can use e.g. JavaScript, including jQuery etc. in the browser, in Content Editor Web Part for example, but the real power comes with VisualStudio and the client object model.

With SharePoint Designer you can do a lot in both (including harm), but there already are some limitations to this in SP Online. The SP Online adminitrator has the most permissions to SPD, as well as the permission to grant or restrict the use of SPD (fortunately, by default, the admin is the only one who is allowed to use SPD). 

With VisualStudio (i.e. development tools and possibilities), you run into the most limitations. But don't let them fool you. There's a lot that can be done developmentwise with SharePoint Online too.

1. The Sandbox model. It is a subset of the complete SharePoint develpment toolset. I doesn't allow you to deploy anything in the GAC, and it doesn't allow you to access any services. It can use a basic set of objects within the Site Collection. You can make your own web parts, access lists, handle events etc.
   Update (Dec. 8, 2011): As of this autumn, Business Connectivity Services (BCS) are available for developers in SharePoint Online (see more about SPO update and BCS & SPO)
2. The client object model. This, since it is run on the client side, in many cases can pretty much cover the shortcomings of the Sandbox model when it comes to e.g. accessing external data and using web services. It includes .NET Framework Managed, JavaScript and Silverlight. 

So as a conclusion, combining both development models, you can have your SharePoint Online site customized pretty effectively. As for the SharePoint Designer, I generally don't recommend it as a tool for the things that can better be done in a controlled and managed way with development tools in SP Online anymore than on-premises. But it can be used by advanced power users for customizing list views, creating workflows, creating list templates in a more lightweight manner, possibly on top or in addition to what has been done by development tools, globally. And the latest addition to this is that from autumn 2011 on, Business Connectivity Services are available in SharePoint Online, and you can set them up in SPD unlike before.

For more information on both and the whole picture, see the TechNet Library article on SharePoint Online development.

So how to fit the mobile view into all this? What should you know and take into consideration when planning the mobile usage of your SharePoint site, whether it be Online or on-premises? There is a very good blog post on this subject by Mike Hacker, I won't go into as much detail here. But a couple thought on that subject here too.

First of all, you might want to evaluate the most probable mobile usage for your site. If it is all about team sites and document management, it is probably enough to enable mobile views in your SharePoint environment (enabled by default in SP Online) and make sure that all of the newly created list get mobile view activated as well (the default ones have this feature enabled by default but new ones don't).

If we are talking about a publishing site, or sites, the question of the mobile view, or mobile site, gets whole new angles. Should we force the complete web site to mobile users too (needs some adjustments on the server, so this is not supported in SP Online)? Or should we then create another css stylesheet for mobile users (which is probably the easiest way to make changes for the mobile users in terms of detecting the device, but then again doesn't give the mobile user a choice)? Or make a completely different set of masterpages? And what about our web parts? Are they mobile compatible?

Make it this way or that, my personal opinion is: give the users a choice. Don't force a mobile view on mobile users, thinking that you're doing them a favor by making browsing easier. Not all mobile users like mobile views. And even more so, there's a whole lot of mobile devices with approx 10" displays which is quite enough for a full scale web experience.  

With SharePoint Online - on on-premises with the default mobile view settings enabled - it depends a bit on the device which way it will show the site by deafult. As the user with the device, you can switch them either way by changing the ?Mobile= -parameter in the URL string. The zero is the full view, one is the mobile view. So e.g. http://url/?Mobile=1 would be the forces mobile version for the site, whereas http://url/?Mobile=0 would be the forced full version of the site.

Hmph. SharePoint Designer failed me (again) and the photographer was there to document the moment.