Friday, August 22, 2008
#
One common situation I see with many clients I interact with is that their SharePoint sites are loaded down with wordiness. It's my opinion that sites that are overly wordy can kill usability fast, and it seems to me that SharePoint lends itself easily to be an extremely wordy application. This to me is the biggest issue that faces the SharePoint user interface (UI). Why don't people like SharePoint's UI? Too Wordy!
When you start dragging those ListViewWebParts on your pages, you quickly become a very textual site. For example, a few months ago I wrote a blog post about implementing a better Announcements web part because the one that comes out of box is SOOOO wordy and takes up a ton of real estate. See below:
Out of box look and feel:
Customized Look and Feel:
I think the difference is striking. The out of box one is so wordy, you don't know where to start, whereas the bottom is clear and articulate, allowing for the user to quickly scan through the information. Most of the out of box SharePoint web parts are overly wordy like this in my opinion, that is why I suggest you don't clutter your pages with too many web parts! This is especially true for things like calendars, documents, and discussion boards. As soon as you start dropping those on the page, end users are lost in a wordy mess and will have a harder time finding information. The trick is that you NEED to make it EASY for them to find stuff.
Instead, I suggest a approach that leverages the left navigation to drive users to content, especially for calendars, documents, and discussion boards and other built in lists/libraries. Those three especially should never be on main landing pages. Rather, link the user straight to the library or list itself. The user is less likely to glaze over information because there's only one type of information on the page and that makes it easier to know what they are looking at.
Another big area that people need to pay attention to is using graphics, not words, to drive users to the main areas of the site. Like I said earlier, people glaze over text and it is rarely ever even read! So don't rely on it! However, people's eyes connect well with graphics, which draw their attention much more easily. Use graphics, not words to drive navigation and highlight main areas/features of your sites.
The image below features a site I put together for a company (logo and name of company removed) that uses graphics to help drive end users to the main areas of the site. Rather than cram a ton of info on one page, I'm using the left nav to link to all the activities and content, as well as using graphics in the main area to call out "featured activities". This is a much more usable approach because users are drawn to the graphics to tell them what they can do, and are not bogged down with a wordy page that they won't read (in which case they'll feel lost and get mad).
(click image for full size)
With just a few seconds of looking, a user can quickly identify the value of the site and what they can do with it. If you have an overly wordy and overly crowded SharePoint site, it won't be used or adopted, and it will leave a bad taste in your end user's mouths. This is because they can't quickly find what they want and they give up. Do you remember what first attracted people to Google, amidst notable competition? Less is more.
I believe the same is true for your SharePoint sites. However, that is "just my 2 cents" J.
Phil
[this post was cross-posted from http://philwicklund.com]
Friday, August 15, 2008
#
When it comes to displaying SQL data (really any data set), there are two main approaches to take to get that data in your SharePoint Sites. The first is the SPGridView, and the Second is the DataFormWebPart. Both approaches have very clear strengths and weaknesses, and this is what I intend to discuss in this post. Here's a summary of my findings (otherwise click here to view the full article):
DataFormWebPart
Advantages
- Very Flexible Presentation – With XSL you can do almost anything. The base GridView control, conversely, is rather limited in how the DataSet that is bound to the control can be rendered. With a DataFormWebPart, all that data comes back as XML and can be transformed any way you like. See the Approaches in Action section to view some examples.
-
Sorting, Filtering, and Grouping with the DataFormWebPart is a no-brainer, it is all done for you, automatically! The only drawback is that it forces a post back, so if your requirements need AJAX, you're out of luck.
Disadvantages
- A lot of overhead required to get a DataFormWebPart to connect to a SQL resource. However, this "overhead" is about the same as the other approach, so it is more of a mute point. I point it out though, just to say it is not your typical SharePoint Designer experience that you may be used to.
-
No debugging. You can't debug XSL (step through XSL), so this leaves you needing to take the Pac-Man approach to development. Build a little. Test a lot. Rinse, lather, and repeat.
Main Business Driver
Your usability requirements will usually cause you to choose the DataFormWebPart over the SPGridView. The XSL is INCREDIBLY flexible, allowing you to do all kinds of cool things that you may not be able to do with a GridView control, for example.
SPGridView
Advantages
Disadvantages
- Not a very flexible user interface. If you have complicated usability requirements or UI Mock-ups, the SPGridView may not be flexible enough for you.
- A lot more overhead is required for sorting, filtering, and grouping, whereas the DataFormWebPart is seamless in this regard.
Main Business Driver
The relative ease of use of a SPGridView is a large bonus, and what is even bigger is the ability to debug and step through your code. People without a lot of XSL experience will want to go this route as well.
READ FULL POST...
[this post was cross-posted from http://philwicklund.com]
Thursday, August 07, 2008
#
Hey All! I’ve been REALLY heads down lately, putting in big hours at a company, and I haven’t had much free time to blog over the past couple weeks. Sorry for that! However, I’ve been keeping busy with some really cool stuff!
I’m on a Business Intelligence (BI) project right now, and I’m writing some web parts that present data via Dundas OLAP Services from some SQL Analysis Services cubes. Tangent – BI work rocks! It’s been my most fun project to work on, to date!
Here are some screen shots of my web parts:
Dundas is a great tool to leverage. They have inherit SharePoint web parts, right out of box. Unfortunately, my business requirements were too complicated to leverage these, but they also publish the base OLAP services charting that can be leveraged programmatically via any ASP.NET application. In my case, I simply dropped the Dundas chart on a CONTROL TEMPLATE, and loaded that template via my web part. So easy! Notice the red box, you can load many reports into one chart, and the end users can toggle between them. Also, you through that toolbar, the end user can toggle chart colors as well as chart type (bar, line, area, etc.). Very slick indeed.
Here’s a sample of some averages plotted with a column chart:
What’s REALLY SWEET is that you can drill into the data. For example, if you click on a date or a column, you can see how that metric is composed. For me, when the user clicks the column, they get an hourly breakdown for that day’s data (it’s in military time – gotta fix that J):
So, to summarize, Microsoft is getting it right with the track they’re taking on business intelligence – and I totally see why they bought out Dundas, it’s an impressive tool!
Good luck!
Phil
[cross posted from http://philwicklund.com]
Monday, July 21, 2008
#
I'm a big fan of delegation and accountability when it comes to governance strategies, and the SharePoint development lifecycle stands for no exception. If any of you remember, I lead a large SharePoint team at a fortune 500 company for a few years, and I have some battle wounds to prove it. Fortunately for me, the IT department had great senior management, who valued environment isolation which saved us a lot of pain in the end, and I was able to glean some great wisdom from their experiences. However, looking back to those days I can't help but to wish I had done a few things differently. I can't help but to think that more accountability and even more environment isolation would've been a great asset to us, despite what could've been perceived as an inconvenience.
Many companies I see don't even have a development lifecycle governance plan, and those that do typically structure it so that Production servers are locked down, but everything else is fair game. Developers, testers, business analysts, and all their moms are all poking around in the various environments and before you know it, you have a mess to clean up and you're always crossing your fingers when you make a production change. I definitely know from experience that when I was working in a test environment, I would often get frustrated because my web front end's configurations are not consistent and didn't know why, or something was working a few days ago, but for some reason it is not now. The of the root problem always goes back to there are just "too many hens in the kitchen". You can spend a lot of wasted time fighting fires in environments, and a little more governance can save you a lot of money when you think of how much that time is costing you.
The figure below is my White Ivory Tower model of how I would structure the deployment process in a medium or large server farm. Much of this article isn't necessary SharePoint specific, but I am often surprised as how often people ask me how I would go about this, so it seemed like a relevant "brain dump" for a SharePoint blog nevertheless.
You'll notice the three recommended farms for any one production farm, as well as the different "gates" where I will later be describing the roles of the different gate keepers and how those individuals will fit into the proposed governance model.
READ MORE...
[this post was cross posted from http://philwicklund.com]