Showing posts with label Sandbox. Show all posts
Showing posts with label Sandbox. Show all posts

Nov 30, 2012

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).


Dec 1, 2011

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.