Before I begin however I’d like to make a caveat: there are exceptions to this. There are cases of organizations using internal social media successfully, but those companies are often smaller and have a younger demographic. The points I’m going to make are for the majority and not the occasional success. I also envision that in the long-term (hopefully) social media technology will be more prominent in enterprises, but I believe it’s a ways off.

Social Media Has a Professional Stigma

Sites like Facebook and Twitter are often banned either by company policy or forcibly by the company firewall. They are seen as productivity killers, and often punishment is threatened against those that are found abusing it. Naturally when the company then says, “I know we said Twitter could get you fired, but we are pushing this SharePoint tool that provides the same functionality” (although not nearly as well as Twitter). Wouldn’t any reasonable employee be skeptical of that?

Repeated Stories in the Media of Retribution from Social Media

We hear time and time again in the news about people being laid off for comments made on social media sites or people never being hired after viewing content on social media sites. Employees become more cautious about what they post in their own private social media sites, and this makes it even more difficult to get them to use internal social media.

My friend Susan Hanley posted an article about content ratings “inside the firewall,” and her observation is that a lack of anonymity leads to less people giving useful feedback. She even mentions in the article attempting to find a successful using of content ratings in the enterprise and was unable to find one.

The Majority of the Decision Makers Are Older in Age

Selling a vision for social media in the enterprise has to go through executives, and most of them now are older in age and don’t feel comfortable exposing social media technologies in their company. Technology consultants know that without commitment from management and maintaining them as a sponsor and avid user the technology will go no where. You might find a CEO of a large company posting an external blog occasionally, but I’d challenge anyone to find a CEO who on a regular basis updates internal social media regularly.

Enterprise Social Media Technology Always Lags Behind

Microsoft announces Twitter-like functionality in SharePoint 2010, and the rest of the world says, “so what?” It’s been out for years, and by the time Microsoft gets around to cloning the technology it’s nowhere near the current standard. Enterprise technology often gets stuck at a point in time, and they work toward that until release. Microsoft is too large of a company to constantly be reinventing their approach to social media in SharePoint when they do major point releases every 3–4 years.

Enterprise Social Media Lacks Emotional Connection

How exciting is it to go to your SharePoint My Site and see that one of your colleagues added “project management” to her profile as a skill? Not at all. However on Facebook, Flickr or other public social media sites you can interact with family, see pictures of grandchildren and re-kindle long-lost connections. It has more perceived value in your personal life, because it retains an emotional connection. No amount of Twitter-like clone technology in the enterprise is going to make it as exciting as our personal lives. And no Microsoft I don’t think that organizational browser is very exciting regardless of whether or not it’s in Silverlight.

Most People Just Don’t Care

Unless a technological solution is actually being used after implementation then it was a failure. There’s no way around that fact, and I wish more consulting companies would own up to that truth. The fact is that the majority of people don’t care about social media. We read news stories that make it seem as though the world revolves around Twitter, but the fact is that it doesn’t.

Our company recently began using Yammer which is another Twitter clone for an enterprise audience. Even though the majority of our company are in their 20s they don’t participate. Why? They don’t care. The only time they do update is when a director mentions we should use it more. Most of them use it out of obligation and not out of a desire to share and communicate.

Social Media Burn-Out

Earlier this decade those who were interested in social media signed up for every site possible. After a while (much like the cycle in enterprise IT) we realize we have too many dis-unified services. This lead to sites like FriendFeed and Lifestream.fm that sought to aggregate all of our social media in a single place. After this roller coaster we become burnt-out and disenchanted and return to our regular lives.

Is There a Future for Social Media in the Enterprise?

You would think by the points I’ve listed above that I’m convinced it will never happen, but that’s not my sentiment. I believe it has an opportunity to be successful, but those issues mentioned above must be dealt with in a reasonable manner. I would also like to see companies making enterprise-grade software to start to innovate and not just play catch-up all the time. It would go along way to capturing the interest of users.

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.

The Controversy

SharePoint 2007 brought us great improvements to how we think about storing and viewing information. With powerful options such as extensive metadata options, content types, and countless numbers of lists and libraries there were many options available to us. The folder paradigm to storing information was still present in SharePoint mostly to ease the transition from a file share to a web-based application, and it led to a debate amongst information architects on whether folders were a best practice for storing information in SharePoint.

There were people on different sides such as Paul Culmsee who see the issue differently than myself, but the good news is that SharePoint 2010 adds functionality to alleviate some of my concerns in using folders.

Setting Metadata with Folders

One of the things I was concerned about was that folders would remove the desire to create custom content types and metadata and instead use the folder paradigm that they were used to from the file share. In SharePoint 2010 we can specify metadata for a folder (which has always been a content type), and it will be propagated to the documents contained within the folders.

Setting metadata with folders

Views Without Folders

In SharePoint 2007 was an explicit option to not include folders within a view. This seems to me to be the best balance between those who prefer a folder view to those, like myself, who prefer views that are grouped. I always disliked folders (inside or outside of SharePoint), because I felt it an impediment to optimal findability (have you ever tried to navigate someone else’s document folder?). This strikes the balance between those who like folder views and those like myself who prefer grouped views.

Folder settings for views.

Metadata Navigation

Now navigation can be modified out-of-the-box in SharePoint to allow navigation by metadata and content types. Now I don’t have to mess with the terrible tree view, but now instead I can focus on utilizing metadata to optimize the navigation experience. This adds quite a bit of versatility in constructing the user experience for your end users.

Metadata navigation in 2010

Conclusion

The SharePoint team has improved the use of folders in SharePoint 2010, and they’ve also improved the experience to not use folders if you so choose such as large list throttling so folders don’t become a necessity. I hope you get a chance to play with the next version of this exciting platform.

Unlike the author’s recommendation in this post I would venture on the side of over-architecting then under architecting. Let me justify it by the following reasons.

Necessary Granularity

Creating content types that are generic work very well as parent content types that you can leverage the power of metadata inheritance on the children, but it doesn’t do justice to the variety of content most SharePoint instances contain. For instance, associating a content type entitled “News Story” to all sub-sites where a department can have their own content greatly increases content query complexity. You could add a metadata column specifying the department or query the library, but what if HR decides they want a custom expiration policy that the other departments don’t need? A new content type is necessary to support this.

Content Types for Each List/Library

Stephanie questions Shawn Shell in the article on a few points one of which being limiting a list/library to a single content type to avoid confusion to the user. First, it needs to be established that every list comes OOTB with at least two content types which are a folder content type and the generic content type for the content (document, item, etc). While you want to not associate a lot of content types to a library I see no reason a single content type to a library is a bad solution. I would be careful about creating 20 content types and then by apparent necessity creating 20 document libraries, because SharePoint provides us the ability to attach multiple content types. Shawn warns against this by being aware that the content types then guide classification. While it’s true that content type architecture has a direct relationship on classification you can’t make a blanket decision such as every content type deserves its own list/library.

Maintenance Complexity

Shawn makes a good point that content types are site collection bound and having to mirror content types between site collections can be an administrative nightmare. I attempt to mitigate this by ensuring that as much as possible that a certain type of content is bound to a single site collection. While this isn’t always the best solution, often a content type such as “HR Policy” will be bound to a single instance to store these content items to reduce content management overhead.

Choosing the Right Designation

I also believe that a lot of the confusion around where content goes in SharePoint can be greatly reduced when you take the time to correctly name both the list/library and the corresponding content types. Nothing makes me cringe more than a generic “Documents” library with nothing other than the default content types. The user is then forced into the same folder structure they had on a file share. While this might be an easy transition for an end user it’s not the optimal solution in the new SharePoint paradigm.

Conclusion

All of the people in this conversation wish to optimize the user experience of SharePoint as well as utilizing all the great capabilities inside of the platform. While each SharePoint IA is unique I would favor more content type granularity for the reasons stated above.

“To ensure the best possible experience across multiple browsers we’re focusing our SharePoint 2010 engineering efforts on targeting standards based browsers (XHTML 1.0 compliant) including Internet Explorer 7, Internet Explorer 8 and Firefox 3.x. running on Windows Operating Systems.  In addition we’re planning on an increased level of compatibility with Firefox 3.x and Safari 3.x on non-Windows Operating Systems.  Due to this focus Internet Explorer 6 will not be a supported browser for SharePoint Server 2010.”

Amazing! Even IE6 is seen as a dead technology by Microsoft’s standards. Hopefully with news like this and Windows 7 pre-release excitement the browser might finally be relegated to the hall of technological mistakes. They also announced the WCM features in the next version will allow much greater control over the markup which may finally make SharePoint a real candidate for WCM for public-facing sites!

The announcement does also focus that the technological requirements will be all 64 bit and based on Windows 2008 as the host platform.

Presentation Resources

• ASP.NET CSS Friendly Adapters (Examples)
• xhtmlConformance Setting
• W3C Markup Validation Service
• Presentation Slides

If you don’t have Quicktime you can view the presentation on Vimeo in Flash, and my slides are available on SlideShare.

Because we often don’t fit well into a nice category we are responsible for a much larger part of designing information systems. Nothing makes this more evident than the process of creating wireframes, and I’m going to address the debate on interactive vs. static wireframes in the context of our role in the development process from the perspective of designers, customers, and managers. The time has come to more clearly define who we are, the role we play in the development process, and be sure that we satisfy all interested parties in the process.

The following quote from Rosenfeld and Morville in their IA magnum opus will be expounded upon:

Wireframes represent a degree of look and feel, and straddle the realms of visual design and interaction design. Wireframes (and page design in general) represent a frontier area where many web design-related disciplines come together and frequently clash. The fact that wireframes are produced by an information architect (i.e., a non-designer) and that they make statements about visual design (despite being quite ugly) often makes graphic designers and other visually oriented people very uncomfortable. For this reason, we suggest that wireframes come with a prominent disclaimer that they are not replacements for “real visual design.” The fonts, colors (or lack thereof), use of whitespace, and other visual characteristics of your wireframes are there only to illustrate how the site’s information architecture will impact and interact with a particular page. Make it clear that you expect to collaborate with a graphic designer to improve the aesthetic nature of the overall site, or with an interaction designer to improve the functionality of the page’s widgets. (pgs. 308–9)

Are We Interaction Designers?

The answer is yes and no. We certainly have a role in the overall user experience process, but we are not responsible for how a user actually interacts with an information system. Let’s face it our annotations don’t replace the role of a qualified interaction designer. I will be focusing on the fact that our value-added proposition is that we can effectively lubricate the evolution from a stiff business requirements document into something reminiscent of a usable system that is then passed onto the programmers, designers, and usability gurus.

Please understand that I understand that the field of IA, UX, and all other aspects of architecting interfaces often happens with just a single person. I don’t want to minimize that as I myself served all these hats. I’m simply pointing the role of a wireframe in the overall interface design life cycle.

There are an abundance of tools that purport to aid architects in creating interactive wireframes, but then what does that display to our team members? Does a designer want to be handed a garbled, poorly-coded, auto-generated layout with cookie-cutter interactions? I know when I was a designer I wanted at least some liberty in what the interaction and user experience ended up looking like. It’s true that in most design shops that the designer serves an IA role, but when we have dedicated information architects shouldn’t we stick to doing what we do best? Don’t we deliver more value in designing taxonomies, labels, navigation, and conceptual layouts?

The Customer’s Perspective

The customer will always prefer something interactive—that isn’t a question. Looking at a bland Visio document doesn’t exactly inspire someone, but what is the purpose of the wireframe? Are we not trying to get the customer to focus on the layout, labels, etc and not how the interaction will take place? When we design interactive wireframes doesn’t it also pigeon-hole the designers to design around the interactions from the IA’s wireframe?

Here is what usually happens when you give anything interactive to a customer when you’re trying to do IA and not interaction design/user experience. They will spend more time clicking around complaining about the pop-up windows and the way it looks and not what we actually want them to be looking at? The value in static, seemingly dry wireframes is that they have no choice but to focus on what we bring to the table in terms of IA and not user experience.

The Designer’s Perspective

Designers are artists in their trade. They make money, because they know typography, colors, interactions, and all the other unique challenges to being a designer. I can’t tell you how many times I’ve asked for wireframes when what I was given was a poor mockup. Let us answer once-for-all that a mockup and wireframe are not the same thing. The designer does not want to be given a mockup—that is the very thing they are experts in. The problem only escalates when an information architect tries to tread too much on what the designers are supposed to do.

When an information architect goes out and converses with the customer, interacts with the functional business requirements, and creates and receives buy off on a wireframe that it is almost invaluable to a designer and the other programmers. A programmer can then focus on database schemas, object orientation, while the designer can worry about the aesthetics of the interface. You will become a programmer/designer’s best friend if you can abstract the job of creating labels while not dictating how the interaction and how it will actually look.

The Project Manager’s Perspective

Project Manager’s are often the hardest to sell on the value of IA. They look at IA as something the designer does, and that only contributes to the difficulty of selling the importance of our field. They are likely to look at the designer and say: give me a mockup to send to the customer, and when money becomes an issue in the project they’ll cut IA’s always before designers. I have never heard of a designer being cut in place of an IA. It has never happened.

We need to carve out what we do best. Designing information systems amongst different skill sets is not reminiscent of some measure of unrelated diversification—everything we do as IA’s is related to everything else. We just need to be sure that what we do we do as well as we possibly can while enabling our fellow designers and programmers while appeasing our customer.

Conclusion

The thesis of this essay was to define what our role is in the wider scope of the development process, and address just one small part of our value added proposition in the development of wireframes. We have so much to offer, but we must be careful on where we tread because we fill such a political position in the development process.

Of all places Wikipedia has a great outline of governance goals as applied to the IT arena.

The primary goals for information technology governance are to (1) assure that the investments in IT generate business value, and (2) mitigate the risks that are associated with IT. This can be done by implementing an organizational structure with well-defined roles for the responsibility of information, business processes, applications, infrastructure, etc.

The more and more I do true implementations of IT whether it be SharePoint, WordPress, or any similar technology is the role of governance. Items from controlled vocabularies to usage policies are essential the sustainability of an IT initiative especially in terms of ensuring that IT investments generate true business value. A lack of governance is always a primary reason why IT projects fail.

The Wikipedia Manual of Style

Wikipedia has an extensive governance model outlined in their Manual of Style. Everything from abbreviations, punctuation, etc is included in this one of many operating documents for Wikipedia.  It is clear not only reading this document that it has been carefully thought out, but the power of their guidelines comes from adherence to the document.

In a policy and guidelines document it is noted on who is responsible for enforcing these policies.

You are a Wikipedia editor. Since Wikipedia has no editor-in-chief or top-down article approval mechanism, active participants make copyedits and corrections to the format and content problems they see. So the participants are both writers and editors.

Books such as Wikinomics probe how such a mass scale collaborative project doesn’t turn itself upside down, and it’s truly a site to behold.  It becomes apparent that Wikipedia editors tend to enjoy adhering to the governance model, because they understand it is crucial to the long-term sustainability of the project. The editor therefore become stakeholders in there edits, and they understand that if they want their work to not be lost is an adherence to the governance documents.

That is of course not the whole story behind Wikipedia. The Wikimedia foundation does have a small army of administrator that constanty patrol the recent changes list, and ensure that the governance model is actually being utilized.  So actually ensuring that certain individuals are empowered to a special degree of administrative rights also becomes a crucial factor in its success.

Applying a Best Practice in Your Organization

Let’s face it, none of will ever be doing something as wide-scale as Wikipedia (although never say never), and so the question becomes how can we apply the best practice from Wikipedia governance to our individual IT endeavors? Thinking through this I came to this short list.

1. Governance guides need to be thoroughly thought through and documented.
2. Those who contribute information need to be made aware of the governance guidelines.
3. A governance document should not be seen as a barrier to creativity and collaboration.
4. Certain individuals should be wholly devoted to the task of enforcing governance.
5. Those who consume information should have confidence that governance is being enforced to maintain findability, accuracy, etc.

I’d be interested to know how these overriding principles are being used in other successful governance implementations. I’d venture to bet that successful initiatives mimic much of the list above.  Whether SharePoint or Wikipedia the same governance principles apply and are necessary.

That being said, making the migration is painful in some areas. One of which was how I handle the lack of productivity software I had in Windows—namely Microsoft Outlook.  As I search around there are a few options in attempting to tackle this problem.

1. Use VMWare Fusion or Crossover to load Windows and then Outlook.
2. Use Microsoft Entourage.
3. Find a way to use the native OS X applications (iCal, Mail.app, and Address Book).

Using Virtualization Technology

This seems straight forward enough on the surface, but on the inside it’s fraught with problems.  First, the idea of using a virtual machine to load productivity software doesn’t seem, well, productive.  This is especially true when I have to dedicate a gig of precious memory to the VM (granted I have 4 GB).  I tried it, and I was able to use it without problem but I wasn’t happy with this option.  I became discontent with it when I started using Mail.app for my personal e-mail. I love the simplicity of the application, and I wanted to use it full time.  I should say I tried Crossover, and I didn’t like it at all. VMWare’s unity feature is far better.

Use Microsoft Entourage

I went out and got a license of MS Office 2008 for Mac.  Word, Excel, and PowerPoint aren’t bad, but they pale in their Windows counterparts. After using the ribbon for so long now I love it. Office 2008 has a “ribbon” of sorts, and it’s not that bad. For quick document work it works fine. If I need more then I can use my virtual machine. However, this isn’t the case for Entourage.

Microsoft Entourage has to be one of the worst e-mail clients I’ve ever used. Sure, it connects to Exchange without a problem, but when you have expectations it will work like Outlook it is very disappointing.  I tried it for a while, and I decided it simply doesn’t cut it. The way you add recipients in e-mail is awful, and I quickly found out that you can’t do HTML e-mail in Entourage which means no embedded links. Epic fail. I hated it, and it made me look to the third option.

Faking Exchange Support

I say “faking,” because the support isn’t native to the OS X apps. Recently, Apple unveiled that the next version of the OS dubbed “Snow Leopard” will have native support for Exchange 2007 in their apps similar to the iPhone (which I use without complaint). But right now my company uses Exchange 2003 which I don’t know if it will be support in Snow Leopard, and it isn’t to be released until next summer.  That leaves a long time for frustration. Surely, there must be a way to do this right?

After searching extensively I discovered I’m not the only who has struggled through this. What surprises me even more is the lack of a third party vendor to fill this void. I would’ve happily paid several hundred dollars for this, but there is nothing out there to accomplish this. It is obvious that only until recently is Apple taking the enterprise environment seriously with Exchange support (no matter how much they may despise it).  I fortunately was able to find a solution in the mean time. Here is my recipe:

Ingredients

1. Microsoft Entourage (bear with me)
2. Mail.app
3. IMAP enabled in Exchange
4. Dock Dodger

Preparation

The preferences pane in Entourage

I discovered that Entourage supports sync services to send calendar events and contacts to the native OS X programs. OK, this is a good start.  As you can see in the screenshot go to Entourage — Preferences and select Sync Services in the left panel.  Then check both boxes to send calender events and contacts to the native applications.  This will via a background service take care of the synchronization from the native apps to Exchange. When you select the option to sync you will receive a prompt, and you will want to choose “Merge Entourage items with Sync Services items” which will allow bi-directional sync between the two. So if you add an event in iCal it will go to Entourage and then Exchange, and if I add an event in my iPhone it will go from Exchange to Entourage to iCal. Not pretty but it works.

Then we have the e-mail issue. This was by far the most difficult and frustrating part. When you create accounts in Mail.app it allows you to create Exchange accounts which is a misnomer. What it means is it will attempt to use Outlook Web Access to send/receive, but it also means you’ll be really using IMAP on an Exchange server.

I found an article which outlines setting up IMAP on Exchange. I had to sweet talk my boss, and he sympathized and helped.  They set up IMAP (Exchange is above me), and that led me to now getting closer to being free of Entourage.  When you set up an account under the Exchange heading you’ll be asked to specify a mail server (such as mail.yourdomain.com) which will come from your Exchange admin. You will also give it the address where you access Outlook Web Access (your webmail address). I was then able to successfully download messages. I had some problems with SMTP. My company uses RPC over HTTPS to connect so I had to use the Password option and specified my credentials (for the username I had to use domain\username).  Then I was up and running!

Cleaning Up

Now it’s working. It’s not pretty, but I wasn’t expecting it to be. It was a utilitarian effort, and it succeeded in accomplishing my goal. But it wasn’t as seamless as I wanted. Entourage would always show up in the dock and also the application switcher. Now I never want to see Entourage anywhere, and I found Dock Dodger. This is a freeware program that removes running applications from the dock and application switcher. By simply dragging the Entourage icon into the app it removed it. Before I did that I click on the icon in the dock and decided to open it at login (as I’ll always need it).

You’ll also notice dialogue windows for the send/receive. I haven’t found a way to completely remove them, but if you close it when it’s running it will go away. Unfortunately, on reboot it comes back. I hope to find an answer to get rid of the dialogue.

Concluding Thoughts

I can now use the native apps, and I am up and running. Entourage now uses around ~75 MB of memory which is much better than the 1 GB option with VMWare Fusion.  I am happy for now, and I look forward to Snow Leopard when I can completely axe Entourage from my life.

I would like to thank Nick Dawson (my Pownce buddy) for empathizing with my struggle and pointing me in the direction I needed.