Siolon » Usabilityhttp://www.siolon.com
Musings on SharePoint, User Experience, and MoreWed, 11 Mar 2015 03:49:38 +0000en-UShourly1http://wordpress.org/?v=4.1.1Abusing Ellipseshttp://www.siolon.com/blog/abusing-ellipses/
http://www.siolon.com/blog/abusing-ellipses/#commentsTue, 03 Jun 2014 18:45:45 +0000http://www.siolon.com/?p=5628Continue reading →]]>Recently amongst web developers there been a passionate conversation about the use of “hamburger” iconography for progressive disclosure usually showing navigation (for the record, I hate that name for the icon). Some have done extensive A/B testing to prove it alone doesn’t work well, and others write passionately how they have abandoned the pattern. This along with other examples like using a select menu for smaller viewport navigation highlights a problem with our community: we can all-to-quickly grab onto a fad without asking fundamental questions about whether it works or not.

The Ellipsis’ Traditional Use in Interfaces

I want to bring up another pattern that has recently become a big problem also: the humble ellipsis. I started seeing ellipsis iconography show up more and more over the last couple of years in web applications. Now the pattern has existed for a long time in desktop applications, but it has served a different purposes. For example, in the OS X Human Interface Guidelines, we read the following instructions for using ellipsis:

When it appears in the name of a button or a menu item, an ellipsis character (…) indicates to the user that additional information is required before the associated operation can be performed. Specifically, it prepares the user to expect the appearance of a window or dialog in which to make selections or enter information before the command executes.

This is also the similar usage found in Windows applications. The ellipsis is designating that if you want to accomplish “x” (i.e. “Save As”), you must give additional information through an input. Here is an example from Notepad even in Windows 8.1.

Notepad File Menu

This pattern makes sense for two reasons (beyond its convention status of course): (1) the usage of the ellipsis is consistent with what you would expect from an ellipsis—namely that more is expected through input, and (2) it is accompanied with a textual description of the interaction’s results. Microsoft IxD guidelines are very specific that you shouldn’t add the ellipsis after menu items where additional input is not immediately required.

The Ellipsis in Web Applications

Now we can turn to web applications and their use of the ellipsis. The use of this is completely different from what we have already described. Before I go further I must clarify that I’m not opposed to do something in a new way, but it must (1) be consistent with mental models and (2) you must test the fool out of it. I have a feeling what I’m about to walk you through matches neither of those criteria. Here are some examples where the ellipsis is showing up in web applications:

Ellipses in Modern Web Apps

As you can clearly see, these are not small applications. These up to multi-billion dollar applications that are relying on this method of progressive disclosure. The YouTube example use an ellipsis set vertically, which I understand to be an Android convention, but it’s still used in a similar way.

Here are my problems with that usage pattern:

From what you can see above it’s used in very different ways. While generally it points towards “settings” or “filtering,” it still is far from consistent. At least the “hamburger icon” was used to primarily designate navigation.

It lacks context. Not all of these are guilty of this: Facebook, YouTube, and SharePoint avoid this, but you can see from Yammer and Feedly that the ellipsis is next to nothing meaningful to give it context on why it is being use or what it is there for.

Lack of textual guides. This is another serious problem that the “hamburger icon” had. In every single one of these examples, there is no text to designate what it does. Would it kill you to add “filter” or “settings?” Are we so pressed for space we continually chose complexity (single, unconventional icon) over the obvious (a single word).

Progressive disclosure should be, in my mind, use smartly and sparingly and it’s best to not hide critical content underneath it. Yammer, SharePoint, and Feedly hide very important utilities behind a single ellipsis. The YouTube one doesn’t even show until you hover over the content (SharePoint does this in places as well).

As web developers we have been given text-overflow: ellipsis in CSS, and now we have to wonder how ellipsis showing up in different portions of the site obfuscate what an ellipsis should mean? It should mean only text truncation.

Hypothesis

At the end of the day as UX practitioners opinion only goes so far. Now I haven’t used an ellipsis for progressive disclosure because I obviously do not care for the pattern. However, my hypothesis is that, if tested and users were asked to find content behind the ellipsis, less than 50% would be able to do so successfully. I’m being generous in that number because the content usually hidden behind should be easily found closer to 80-90% of the time.

If anyone has tested this usage in their app, please let me know your results.

Final Takeaways

The final things we should glean from the ellipsis and hamburger icons are that we should never assume too much, and we must always test our assumptions. Also, do not introduce something complex when simplicity ensures success for your users and the applications they rely on.

]]>http://www.siolon.com/blog/abusing-ellipses/feed/5Distinguishing Between Ornamental and Functional Skeuomorphismhttp://www.siolon.com/blog/distinguishing-between-ornamental-and-functional-skeuomorphism/
http://www.siolon.com/blog/distinguishing-between-ornamental-and-functional-skeuomorphism/#commentsSun, 22 Sep 2013 02:14:04 +0000http://www.siolon.com/?p=1151Continue reading →]]>By the amount of times I’ve read the word “skeuomorphism” in the last year, it’s easy to assume the world has taken an internet in rather ethereal UX language. But of course that’s not the case. I think more tech journalists use it because they feel it gives them a sense of authority. In fact, the only thing it does is to perpetuate a common misunderstanding of the benefits of skeuomorphism, and that happens when you only focus on one implementation of this concept.

Most of the conversation has been around skeuomorphism in iOS. You can even see the Google search trends for “skeumorphism,” and it’s directly tied to the uptick in the iOS conversation. However, when most people used that term it is used to mean “ornamental skeuomorphism.” Let’s distinguish between the two for some much needed clarity.

Ornamental Skeuomorphism

Ornamental skeuomorphism is the use of real world textures and designs to mimic a physical interface. It is done purely for ornamentation and not functional. Here are a couple of examples.

< iOS 6 Calendar: Here you see the appearance of a physical calendar that adds nothing to the experience. (The page flipping animation in this app and iBooks serves more as a functional role, albeit a poor one.)

iPad Calendar in < iOS 6

Same with an iOS app called iStudiez Pro.

iStudiez Pro (iOS App)

You can see there is nothing functional about the look. It’s only made to imitate its real-life counterpart.

Functional Skeuomorphism

Functional skeuomorphism is the use of real world analogies and behaviors to help the user match a physical appearance with a digital one. The thought was that skeuomorphic functions can assist in the transition from physical to digital.

The most obvious and well used is the folder paradigm introduced way back in the early GUI days. The analogy was used to help transfer people’s thinking of storing objects in a container (the file folders). This comes from the filing cabinet in the physical world. Here is one example of this in Windows (and it’s similar in OS X).

Folders in Windows

Here is an example of “folders” in iOS that have no ornamental skeuomorphism to match the functional use. (As as side note, I wish they would’ve called these “stacks” from OS X, but you can see now why they kept the name.)

Folders in iOS

Functional skeuomorphism has other application outside of digital interfaces. Does your car really need to beep when you lock/unlock it? Of course not, but it fits our mental model of a confirmation noise, and it is, I think, appropriate (think of the noise that bolt locks made when locking and unlocking).

Skeuomorphic Iconography

An interesting application is in the realm of iconography. It’s has been an area ripe to marry functional and ornamental skeuomorphism although it probably leans more heavy on the ornamental side. There have been good critiques against using dated analogies such as the next example.

Here is the often debated floppy disk save icon in the very recent Word 2013.

Save Icon in Word 2013

I read a usability report recently on how quickly users still identified the floppy disk as a “save action.” What was supposed to only have a temporary significance has now crossed over into becoming a convention despite the fact a large majority of people using computers today have never had to use a floppy disk. When designing these icons you have ask if the relationship between the signifier and the signified is still appropriate. For more details see this Boxes and Arrows post: Optimizing UI icons for faster recognition.

Conclusion

So let’s remember there are more uses for skeuomorphism beyond green felt in an iOS app, and to write off the approach entirely is foolish. Through good user research there maybe value to be found in it to ensure we match mental models. Just remember to constantly evaluate your use of skeuomorphism to ensure its relevancy.

]]>http://www.siolon.com/blog/distinguishing-between-ornamental-and-functional-skeuomorphism/feed/0A Warning On Reusing Solutionshttp://www.siolon.com/blog/a-warning-on-reusing-solutions/
http://www.siolon.com/blog/a-warning-on-reusing-solutions/#commentsTue, 02 Jul 2013 04:34:43 +0000http://www.siolon.com/?p=919Continue reading →]]>We have all done it on projects. We have heard our clients request something and immediately think, “We can just reuse what we did for [client name].” Even though it is tempting, it can have bad results. Here is a good warning:

“If we continually institute the same code for each project, we run the risk of implementing the same solution to every problem. It can become more difficult to provide new solutions to usability concerns. We end up sizing up each user request as an exercise to prove that ‘we’ve got code for that.'” – Travis Lowdermilk, User-Centered Design (pg. 107)

So be mindful of reusing solutions for different problems to avoid potential usability issues.

]]>http://www.siolon.com/blog/a-warning-on-reusing-solutions/feed/0Evaluating Windows 8http://www.siolon.com/blog/evaluating-windows-8/
http://www.siolon.com/blog/evaluating-windows-8/#commentsThu, 27 Dec 2012 15:35:37 +0000http://www.siolon.com/?p=814Continue reading →]]>I am admittedly a much bigger fan of the Apple desktop and mobile operating systems than the Windows counterparts. However, that does not mean I don’t care at all for Windows offers, especially in the desktop space, and I actually do like Windows 7 quite a bit. That has all changed with the release of Windows 8. I honestly think that Windows 8 is the worst software released in a long time, and it is certainly the worst version of Windows I have used.

I remember playing with the beta, and after about 10 minutes I completely gave up. It was obvious that Microsoft was trying to tow the line between a touch and desktop UI, and it ultimately ending up satisfying neither audience or need. This video was shared on Twitter, and it summarizes my sentiments perfectly on Windows 8. Even though the video is a bit long (about 24 minutes), I highly suggest watching until the end.

There is also news that Microsoft is taking another page out of Apple’s book and moving to a yearly release cycle with their desktop operating systems. Whatever they might be doing, I hope that they manage to fix Windows 8. Everyone was in an uproar over Windows Vista back in the day, but I always thought those criticisms were overblown. But this time all criticism about Windows 8 is warranted.

]]>http://www.siolon.com/blog/evaluating-windows-8/feed/4Usability Testing: Why Aren’t We Doing It?http://www.siolon.com/blog/usability-testing-why-arent-we-doing-it/
http://www.siolon.com/blog/usability-testing-why-arent-we-doing-it/#commentsThu, 18 Aug 2011 15:18:05 +0000http://www.siolon.com/?p=563Continue reading →]]>I was recently selected to speak at the SPSEMEA SharePoint Saturday. For the talk I wanted to talk about the often forgotten art of usability testing on SharePoint projects. All of the content is generic and applicable enough that you don’t have to be implementing SharePoint to get something from this presentation. The content is made to be applicable to any type of application implementation.

Presentation

I made a video that was my actual presentation including going over all of the slides and analysis on the usability test. The presentation runs slightly over 50 minutes. You can also download the slides from the talk as well.

Usability Test

If you want to watch and think through the usability test in its entirety without my commentary you can view it through the UserTesting.com site.

Resources Mentioned in Presentation

]]>http://www.siolon.com/blog/usability-testing-why-arent-we-doing-it/feed/0Lost in Translation: User-Centered Designhttp://www.siolon.com/blog/lost-in-translation-user-centered-design/
http://www.siolon.com/blog/lost-in-translation-user-centered-design/#commentsThu, 20 Jan 2011 18:04:14 +0000http://www.siolon.com/?p=552Continue reading →]]>It’s very easy when you’re constantly engaged in design work to use terms and phrases that you know mean something, but consistently they are taken to mean something else. One of the worst offenders in the design world is the phrase: “user-centered design.” It has led to more misunderstandings and mistakes then I’d care to admit. I’d like to spend some time talking about pitfalls in using this language and how to make sure that when you speak with a client you avoid this costly mistake.

The Mythical End User (Who Really Is You)

We all know (at least I hope we all know) that designing by committee is a shortcut to failed design (this video nails the comedy behind it). One of the first mistakes made in design meetings and teams is that our own personal preferences and desires get projected onto a mythical end-user. How often have you heard something like this.

“Our users don’t like drop downs.”

“I don’t think our users will want to see green there.”

“You know, I’m not sure end users will like that.”

When we probe more we find out that these end-user projections are just personal preferences. The problem of going into a client and suggestion you’re focused on “the end-user” will almost instantly and unconsciously turn our design discussions into projections of this mythical end-user. The well versed usability expert Steve Krug puts it in perspective.

“And the worst thing about the myth of the Average User is that it reinforces the idea that good Web design is largely a matter of figuring out what people like. […] The problem is that there are no simple ‘right’ answers for most Web design questions (at least not for the important ones). What works is good, integrated design that fills a need—carefully thought out, well executed, and tested.”Steve Krug, Don’t Make Me Think: A Common Sense Approach to Web Usability (pg. 128)

The Misuse of End User Research

It’s not without debate that understanding what types of users that will use your application is of value. If your application has a very specific focus and niche group it makes a lot of design decisions a lot easier. However, often times a mistake made is when we start placing all types of value on suggestions and feedback we receive from users.

Don’t jump ahead on me. I’m not stating that users don’t have valuable input at many stages of the design and maintenance process. If I believed that I would also tell you that usability testing is the largest waste of time in a project which I clearly do not. But I believe that decisions made by an informed UX researcher are often negated, because end users make proclamations about how they feel an application should behave. This ultimately makes your application less worthwhile to larger groups of people. Don Norman states the following.

“Sometimes what is needed is a design dictator who says, ‘Ignore what users say: I know what’s best for them. […] The ‘listen to your users’ produces incoherent designs. The ‘ignore your users’ can produce horror stories, unless the person in charge has a clear vision for the product, what I have called the ‘Conceptual Model.’ The person in charge must follow that vision and not be afraid to ignore findings. Yes, listen to customers, but don’t always do what they say.”

When designing an application a user’s opinion should be stated and noted but not used as the barometer for our design activities. Let’s face it, if we’ve done any work designing application the one thing that that will show up time and time again is that end users don’t know what they want. It’s not their fault either they are simply caught in the middle. Successful applications help users through accomplishing what they need to do without an unfair focus on what they think they want to do.

The Better Emphasis: Designing for Activities

In the article mentioned above by Don Norman he goes on to explain more of why designing for activities is better than user-centered (he uses “human-centered” terminology). All applications exist for a reason, and that reason is to help someone accomplish a task or achieve a goal. It doesn’t matter whether the activity is buying clothes, researching movie times or playing games online. If designers were more honest with themselves and spent less time laboring in Photoshop they’d realize that better time is spent thinking about design in terms of what goals and activities need to be accomplished by your users.

It is this focus that really helped me see a new light in designing user experiences. When I was liberated to think more about designing applications that accomplished goals and less about whether they application used Verdana or Arial I became much more effective. All of the sudden the applications I worked on delivered more utility and saw users returning more often. It is the reason I implore designers everywhere to not use “user-centered design” but instead turn your clients attention to “activity/goal-centered design.”

Conclusion

The astute reader will notice nothing I’ve said here goes against the classically defined tenants of user-centered design, but I wanted to illustrate why using that language with less educated clients doesn’t ultimately help you in your design activities. Be intentional and careful with the words you use, and I guarantee you will find more success in your projects.

]]>http://www.siolon.com/blog/lost-in-translation-user-centered-design/feed/0Making DHTML Menus Suck Lesshttp://www.siolon.com/blog/making-dhtml-menus-suck-less/
http://www.siolon.com/blog/making-dhtml-menus-suck-less/#commentsThu, 03 Jun 2010 01:41:39 +0000http://www.siolon.com/?p=456Continue reading →]]>There are designers on both sides of the DHTML menu issue. Some are liberal to use them and have no issue with them, and there are others (including myself) who think it’s not the ideal solution to a navigational structure. Navigation is unquestionably the most important part of any web application, and if it is poorly implemented it makes your application unusable and, more often than not, no one will use it.

I think most DHTML menus are simply a band-aid for poorly conceived information architectures. There also is this idea that has stuck for the last decade that everything should be “within three clicks” as if have four clicks suddenly means the application is less usable. In truth it is a myth: “The reality is that users have no problem with clicking, as long as they are confident they’re heading in the right direction.” Since most of the time designers simply use existing complex information architectures instead of honing and refining them they default to DHTML to expose all of their site structure.

Let’s look at of the reasons that DHTML menus suck, and I will elaborate on several below:

As mentioned, often times DHTML menus are used to hide bad information architectures.

Many DHTML menus have no visual indication that there is a menu beneath it.

Users become frustrated when they have to follow a complex path for a sensitive menu.

Navigating by a keyboard loses its luster when using DHTML.

DHTML menus are often not built with the ability to designate where the user is at in the site structure.

These menus are often inadvertently activated by a browsing user leading to a jarring experience.

Even though this is less of a problem then it was even five years ago many DHTML menus use horrendous markup, inline styles, and inline behaviors that fail to degrade gracefully.

Some DHTML events, such as onmouseover, are becoming obsolete with the rise of multitouch devices.

DHTML Menus and Information Architecture

Before deciding that a DHTML is the way to go most designers don’t want to work a client through a process of investigating the information architecture to see if the application even needs the DHTML. Do you really need three different levels in your menu? Have you done a proper card sorting exercise to determine the ideal labels and structure for your navigation? Can you implement secondary navigation on pages that will compliment a more global navigational structure instead of having to expose all that content in a single menu? These are some of the questions to consider if your application truly needs the DHTML.

DHTML Menus and Indicators

I am literally amazed at the amount of sites I visit that fail to use any kind of indicator in their DHTML menu to tell the user there is content to be exposed. Most commonly when an indicator is used a down arrow or something close is used to designate that there is content beneath the navigation element. Below are two screenshots of sites that do and don’t use the indicator.

No indicators on Best Buy, Microsoft, and even Portal Solutions.

Sites with indicators include SharePoint 2010, Reuters, and Google.

DHTML Menu Sensitivity

Another issue that frusturates users is how sensitive DHTML menus are. If a mouse cursor accidentally slides off the menu the entire thing collapses and you have to start over. If the DHTML menu has multiple levels this can be even more frustrating! The complexity of so many DHTML menus is often the thing that makes them the least usable.

In addition to the menu accidentally collapsing, DHTML menus also have a tendency to expand even when the user had no intention of opening it by initiating the onmouseover event unknowingly which can be a jarring experience. This is especially bad when it is coupled with no indicators as mentioned in the last point.

Getting Lost in the Navigation Structure

One of the primary purposes of navigation is to inform the user where they are at in the site structure. DHTML menus are notorious for never showing where some is at in the site/navigation structure or where they’ve gone (the latter is less of an issue in my opinion for a navigation structure). A user is often left asking themselves, “Where Am I?” Proper and helpful navigation should at the very least designate where they are in the site as it corresponds to the navigation.

Often this has to be done with a dynamic programming language to allow the menu to show where the user is at in the navigation. An example I can show is how WordPress chooses to implement this functionality.

A Remedy: Superfish

One of the best implementations I’ve seen of DHTML is the jQuery plugin Superfish. It is based on the Suckerfish style of markup which is ideal when putting together navigation on the web. While I don’t gravitate towards DHTML, if you’re forced to use it by a client or some other circumstance then this is the best solution I’ve found.

Suckerfish is an ideal solution, because it deals with many of the issues I’ve mentioned above.

There is an option for timed delay on mouseout. This alleviates the issue of someone accidentally mousing out and not having to start the menu traversal all over again. It can be adjusted to the best timeout for your audience.

Keyboard navigation is fully supported.

It supports the awesome hoverIntent jQuery plugin so it won’t accidentally fire when moused over. It also supports a new variation on the hoverIntent plugin called $.event.special.hover.

It can automatically add arrows for you when there are menus beneath, but it also has a specific CSS class attached to those nodes that you can add whatever you’d like to designate content beneath the current menu item.

It uses solid markup, and it offers a lot of custom classes added throughout the menu to style various states and elements.

There are many examples showing you horizontal, vertical, and other variants on the menus appearance (check out the “nav-bar” example which I like a lot).

Conclusion

While I still firmly believe DHTML menus are not the best solution to the problem, Suckerfish at least provides as usable as an alternative as I’ve seen. DHTML still, I believe, is not necessary when constructing good user interfaces with good information architectures. It is a quickly deteriorating technology due to the use of multitouch devices, but if we’re going to use it we might as well make is as usable as possible.

]]>http://www.siolon.com/blog/making-dhtml-menus-suck-less/feed/0User Experience Presentationhttp://www.siolon.com/blog/user-experience-presentation/
http://www.siolon.com/blog/user-experience-presentation/#commentsWed, 25 Mar 2009 20:51:37 +0000http://www.siolon.com/?p=333Continue reading →]]>I was asked to give a presentation recently at the Cincinnati .NET User’s Group. I created a screencast of that presentation. Please bare with the editing, as I dove into the world of iMovie, and my UX was less than optimal.

I was recently tagged to “brand” a SharePoint installation for Hirsch Pipe & Supply Co. I knew it would be an interesting challenge, but I had no idea how bad it truly would be.

SharePoint is built on ASP.NET 2.0 which I had worked with in my previous job. I found ASP.NET very powerful and flexible. Master pages, App_Themes, CSS Friendly Adapters, and more made working on ASP.NET interfaces relatively painless. Knowing that SharePoint utilized master pages I thought it would be much easier than it was. However, it turned out to not be the case.

The Default Master Page

I was immediately struck by the mess that is the default master page. The master page is laid out with, of course, tables which is reminiscent of why Microsoft is such a joke in the designer world. Well, I decided to rip out the tables, and surely that would make it easier right? No. It turns out that SharePoint only uses one standard ASP.NET control (the navigation control), and the rest are SharePoint specific “delegate” controls which made layouts with CSS difficult. These are of course stored on the file system, and the only way to edit them is to create painful features. It looked as though I was stuck with extensive tables for much of the layout.

When I did yank out much of the table layouts it only opened up a headache down the road. It was actually more painful to try and layout it with CSS then just sticking with the table layouts. What made it difficult are the extensive nuances in the SharePoint interface that are dependent on others. For instance, I would lay it out in CSS, but when I went to edit the page to add web parts everything went awry due to dependencies on extensive tables for layout. I was able to lay out the majority of the default master page with CSS, but I ended up reverting to tables for the main content area due to pain after pain. I did go with Heather Solomon’s minimal base master page for publishing sites which was a better start then I had.

The CSS

The fun doesn’t stop there. SharePoint has a core stylesheet that is over 4,000 lines long. I’ve dealt with more styles in one shot, but looking at the stylesheet you would think a 10th grader created them. There is a lack of shorthand, units of measure, and extensive IE proprietary styles. Add onto the fact there are no comments in the stylesheet it is absolutely useless to attempt to decode it. You also can’t simply remove the core styles; well, you could, but it’s another headache that is ultimately not worth tackling. It’s again easier to deal with the bad then try to make it better.

SharePoint does allow you to specify an alternate stylesheet which does, thankfully, get rendered after the core styles. The cascade becomes your best friend in altering the styles. You’ll also notice the “classitis” that abounds in the master page and core styles. They all have a prefix of ms- which is unneeded and unhelpful. I wasn’t surprised to find a lack of advanced CSS 2 selectors due to the pressure to support IE 6, but they are hardly any descendant selectors which would drastically decrease the amount of classes in the markup.

The JavaScript

I know Microsoft is now supporting jQuery which we can only hope will reduce the amount of “obtrusive” JavaScript through the site. It reminds me of how I wrote JavaScript back in the day. Attempting to decode the core JavaScript is a puzzle I didn’t even attempt. You are once again forced to use proprietary JavaScript instead of taking it on to write it any better. If they did abstract the obtrusive JavaScript it would drastically decrease the complexity of the markup sent to the browser. I did end up using jQuery to set the size of certain divs, and I also attempted to clone() and append() DOM elements but it proved fruitless.

Hope for SharePoint vNext

I hope, first that I never have to alter the SharePoint UI again, but that the next version of SharePoint will construct a better default UI with the following changes.

Use CSS for layouts.

Ditch the delegate controls to use more of the standard ASP.NET controls (or at least improve them).

Use a well-commented core CSS file with advanced selectors to eliminate the need for classes.

Switch to an unobtrusive JavaScript model.

An increased focus on accessibility for public-facing sites.

]]>http://www.siolon.com/blog/the-pains-of-altering-the-sharepoint-ui/feed/7The SharePoint Grade Cardhttp://www.siolon.com/blog/the-sharepoint-grade-card/
http://www.siolon.com/blog/the-sharepoint-grade-card/#commentsThu, 11 Sep 2008 16:59:46 +0000http://www.siolon.com/?p=181Continue reading →]]>I have now had a much larger exposure to SharePoint’s product offering, and I feel in a much better and knowledgeable place to assess the strength and weaknesses of the technology. Like any product that attempts to serve a wide range of functionality there are going to be stronger and weaker areas. One thing the SP team at Microsoft does well is addressing shortfalls in the technology as it matures.

I’ll evaluate each of, what I deem to be, the major functions and tools of SharePoint. OK, let’s get started.

Windows SharePoint Services – A

Windows SharePoint Services or WSS is now in its third major iteration. It is the core that MOSS is built upon, and it is where the strength of SharePoint lies. From it’s incredible Office integration, task and document management, and web part personalization options WSS is what caught my eye and made me desire a career change.There are some minor headaches and pitfalls, but certainly not enough to warrant anything less than an “A” in this category.

Social Networking Capability – B-

Unfortunately, SP didn’t do what I would’ve liked to see in this category. They introduced “My Sites” in MOSS, but adding colleagues isn’t intuitive and the feature turns into a personal SharePoint site instead of a robust social networking tool for the enterprise.

Blogs and wikis were also introduced in WSS 3, and the inclusion of them is promising but the implementation is poor. The blog is feature-less allowing only categories and less than impressive personalization features. The wiki is super basic, and it leaves me confounded on how it seems so quickly implemented. A look at the benchmark, MediaWiki, will show the lack of robustness in the SP implementation.

Enterprise Search – B+

The MS work on their search in MOSS is surprisingly amazing. While many companies introduce search replacements for MOSS, often times they are trying to fix poorly architect edsearch solutions with the MS offering.

The search in SP offers many options for optimal information architecture including best bets, search logging/analysis, search scopes, and much more. It’s impressive to say the least. The crawler is also very, very effective with filters to spider other forms of content. They even introduced federated search to this offering, and it makes it all-the-more impressive.

The only reason this doesn’t get an “A” is the search results and placing search in the default interface isn’t worth the high grade although this can be edited by any capable designer.

Business Intelligence – C+

Default business intelligence in SP is less than stellar. Although key performance indicators (KPI) are in the offering it is simply a graphical display of business data. Corporations need far more robust diagramming and analysis tools for true business intelligence, and it has been a ripe area for other companies to pick up what is lacking in this feature.

Excel Services is an interesting addition to this as it allows the graphing and analysis of Excel data which is the most rudimentary of business database and business intelligence applications. I look forward to this being beefed up in the next version of SP.

Web Content Management – B

Web Content Management or WCM was one of my specialties in my last business that shares the name of this site. I chose WordPress as my tool of choice, but there are fantastic tools including Drupal, Dot Net Nuke, Graffiti CMS, and many others that do a fantastic job with each having their own strengths and weaknesses.

The SP offering of WCM has moved them from solely a intranet/extranet tool into the Internet realm. WCM is also done differently than or web CMS’. SP uses metadata in a single list to control what content is available to the page creator in SP Designer. Creating page layouts then becomes foundational to all SP WCM. Even though pages can be created and metadata is more focused on then other tools such as WordPress or Drupal it still leaves much to be desired.

The workflow of creating metadata to then be used on any form of WCM pages I find quite restricting, and it ultimately slows down the contributor who understands nothing about the WCM architecture. Inline editing of the content is also less than impressive. The rich text editor is shaky at best, and the constant need for modal windows hinders usability for the contributor. To edit the “backend” is only a list without a robust administration interface found in other popular CMS’.

SharePoint Designer and Interface – D

I’m putting both the default interface and SP Designer in the same category since they are so inter-related. The default interface is clunky, navigation is abundant but poorly implemented, and the “obviousness” of the SP interface is less than obvious. Also, in the interface the markup is absolutely horrendous. Typical of ASP.NET controls it outputs horrendous markup. This hinders accessibility, ease of branding, and even in the realm of SEO when using SP for public-facing sites. The markup reminds me of what MS is all-to-often ridiculed for lack of web standards awareness.

SP Designer is the approved tool to brand the SP interface. It’s built on the legacy of FrontPage, and it’s capability and interface is very reminiscent of FrontPage. However, seemingly they are learning from their rich IDE in Visual Studio and allowed it to influence the designer options and functionality. If it weren’t for the ability to open up the content database I would never, ever use the tool. It is expensive, bulky, and there are free editors that make SP Designer look amateur.

The ability to do XSLT in a GUI manner is an interesting perspective, and it makes such a difficult topic somewhat attainable by a non-XML/XSLT expert. Also, the workflow wizard is actually quite impressive. Although it has limitations I was able to create a rather complex workflow with logic rather painlessly.

Looking Forward

I’m hoping that these deficiencies will be address and strengths strengthened in the next version of SharePoint. I understand much of what I criticized is still “version 1.0,” and I expect it to mature. SharePoint is a powerful platform, and I expect it to continue to dominate the ECM market for years to come.