Archive for the ‘ SharePoint ’ Category

HTML5 and Silverlight (It’s been a long summer)

Ever since Microsoft unveiled an early build of Windows 8 in a video back in June, there has been rampant speculation on what the emphasis on HTML5 and Javascript means for the future of software development in the Microsoft world.  Specifically, what happens to Silverlight?  What happens to .NET?

There has been commentary from just about every corner:  from toolset makers such as Telerik, to ex-Microsofties, such as Scott Barnes.

And of course Microsoft has been pretty silent on all this.  The BUILD conference is coming up in about 2 weeks, but we’ve been waiting all summer, and it’s quite fun to practice Kremlinology anyway, right?

There seem to be several main theories on Microsoft’s plans:

  • .NET and Silverlight are going to wither on the vine.  The future is HTML5, Javascript, and C/C++.  The Windows division has taken over and they never appreciated .NET.
  • .NET and Silverlight will continue to exist, but they are going to be lesser stars in the MS galaxy.
  • .NET and XAML are at the heart of Windows 8 and something called Project Jupiter.  They’ll get to play on an even field with C++ at last.
Since the evidence is so scarce, we should focus on what Microsoft has actually said.
  • The future of the web is HTML5
  • SharePoint is big, and it’s going to the cloud with Office 365
  • Office 15 is on the way and SharePoint is the nerve center of Office
Okay, no point in belaboring it.  HTML5 is going to be a big focus.  SharePoint is a HUGE business for Microsoft, and it’s founded on .NET.  Throw in Dynamics and a bunch of other MS products.  .NET is not going away.
I’m excited to see what Microsoft unveils at the BUILD keynote on the 13th.
Next post:  What I HOPE Microsoft is thinking about.

SharePoint Designs – Keep it simple, but don’t go cheap

Let’s face it – OOB SharePoint has very ugly UI.  It is plain, boring and colorless.  I am by no means a design person (quite frankly, if it weren’t for my house having it’s own ‘out of box’ design too it, it would be relatively plain and boring itself).  I am one of those many people that can only tell you what I like/don’t like once it is in place.  Thankfully we have designers that thrive off of making sites (and houses) colorful, attractive and appealing to the naked eye.  The one problem, however, is that both clients and designers alike can get a little too excited about design without thinking about maintenence once the design is in place.  Perfect case in point – putting rounded corners on web parts.  I am not sure what started the trend – it is definitely prettier – but this is probably the most  common request I get across the board.  This looks great when first built, but the problem is it isn’t extensible.  As soon as you want to add content to these boxes,therefore  expanding the part, it breaks the site build.  While not impossible to do (knowing HTML/CSS this can be managed), the typical end user finds this impossible to manage and you lose an important part of what SharePoint is here to do; you suddenly require a developer to make the updates rather than doing it yourself.

Another request, while understandable, is to keep the design implementation as cheap as possible (of course, this is after the design has been determined).  Oftentimes this can be done by using content editor web parts.  This seems like an obvious solution, and sounds simple on it’s surface to update (it allows the user to insert content of almost any type – links, images, text, photos, etc) and all the site builder/dev needs to do is stylize the part.  The problem again is in order to keep this part looking nice the end user must know HTML.  Also, they will have to always go into the web part to edit, and they will have to be very careful with the size of the content they are adding so as to not cause the site build, again, to ‘break’.  I would recommend one of two alternatives:

1. Use a design that compliments the OOB web parts (i.e. a lone video viewer web part, a seperate links web part, announcements web part, etc)  this can still be stylized, but it works with SharePoint rather than trying to invent your own combined part.

2. Use lists that pull in data to the parts.  While more expensive, this is much much easier to the end user and a much more sustainable, and clean solution.  This is a dream come true to the end user.  We have used this solution anywhere from pulling data into Featured News silverlight parts to modified Team Announcements on a home page.  What this means is:  the developer/site builder will implement styles on the pages so you can have your fancy design.  The site/page owner will go to the list as indicated by the dev.  They will simply select ‘add new item’ on their list.  Based on the design, they will then add whatever content is needed (photo, description, title, etc) and save.  The end user never actually touches the part! This process will populate the ‘fancy webpart’ on it’s own.  No worries on breaking the design, no knowledge of HTML and no formatting necessary.

Also note, what I have seen happen many times with trying to take the ‘cheaper route’ of content editor parts or even hard coding HTML on the page, is that this actually ends up being a more expensive solution, because they end up realizing that they can’t update and need to find a dev to make the udpates for them.  Alternatively, they ask to have the entire page re-done, the ‘right’ way.

Three of the biggest recommendations I hope you can take from this when brainstorming on design/budget for your SharePoint site:

  • Do NOT use rounded corners on your design
  • Avoid Content Editor web parts unless you know HTML
  • Cheaper initially does not always mean cheaper in the end

You can see all sorts of examples on our company site

I hope this proves helpful and best of luck on your site coming to life!

SharePoint Groups – They Exist With Good Reason

When you become accustomed to best practices it is easy to start thinking that the knowledge you have obtained is general common knowledge.  This is especially true when walking in to a large company in IT where you would expect these best practices would have been adopted.  Much to my surprise, this often is not the case.  Over a year ago we worked with a company where they did not utilize SharePoint groups to manage permissions.  Rather, there were thousands of users listed individually with broken inheritance across the site.  Not only does that become horrendous to manage, but since SharePoint sites by default will inherit permissions from their master sites, to try to lock down permissions on any sublevels becomes a time-consuming and tedious task.  Permissions weren’t meant to be used this way – with thousands of individuals listed, in order to reduce permissions we had to select small groups at a time( i.e. all users with the last names A and B) and then remove their permissions.  Something that should take seconds to manage suddenly becomes an hour long ordeal – and that is only if SharePoint doesn’t time out on you!  It seems like a quicker solution at the time, but in the long run, adding an individual will end up being much more difficult to manage.

An area where SharePoint doesn’t help encourage the proper behavior is when you turn on access requests.  Inevitably, a user requests access to a site or library, the site admin approves via the email link, and by default, the individual gets added to the site as an individual user rather than added to a group.  Do not follow this practice!  Instead, when you receive a request, review the location they are attempting to obtain access to (which itself can be tricky), and then add them to the proper group.  Also, always ensure that you are only putting the user into the group with the permission level necessary for them to perform their tasks.  Permissions are easily abused on SharePoint so this is critical.  Also, if you have the ability to use AD groups to add user groups to SharePoint groups, this is preferable as all permission management will be done via AD, and you won’t have to worry about turning on/off permissions through SharePoint at all!

SharePoint – Getting a Fresh Start to Save from Future Pain

As great as SharePoint 2010 is, it is not a magic bullet.  You can’t just push a button and have an intranet up and running.  Well, it is nearly that easy, but having it up and running successfully is another story.   In the past 3 years of working on dozens upon dozens of  SharePoint 2007 and 2010 projects I have run into many instances of the same problem:  Clients hear SharePoint is easy install, they rush to get it up and running (understandably they are excited to do so!), and then give all employees full reign to do what they want with it.  End results:  An IA nightmare.  A perfect example is a client we worked with that wanted to migrate from 2003 to 2007.  We came in and found that they had over 1800 subsites built, subsites on top of subsites, and the permissions structure was such a disaster (not utilizing SharePoint groups at all) that they didn’t know how even to obtain access to a majority of the sites.

When it gets to this point I strongly recommend starting from scratch – migration is not always the best answer.  Inevitably so much time, money and effort is spent trying to undo the mess post-migration that it is difficult if not impossible to rectify.

Many clients do not want to spend a lot of money on an intranet site because they don’t see the financial benefit in doing so.  However, it is a lot less expensive to plan and do it right then ending up with this type of mess.  Often times a phased approach works great.  Finding a group in your organization that really is anxious to get the intranet going, one that understands the value of losing the shared drives and the benefits of managing data, collaborating and sharing on the web is a great way to start.  It is less overwhelming for you, as well as the organization as a whole and ensures that the efforts keep moving forward.

%d bloggers like this: