Just a post to highlight my presentation tonight for SouthColorado.NET User Group – I'm speaking on an "Introduction to SharePoint for .NET Developers". See www.southcolorado.net for details. The two communities (SharePoint & .NET Dev) seem to be separate. While some of that is certainly specialty focus, my feelings are that the two groups have a lot more in common than not. The development platform in the .NET arena is rapidly expanding to demand collaborative data sources and platforms. Blogs, Twitter, Facebook, LinkedIn, MySpace, forums are all the information stores of 2009+. .NET skills are expanding to a wider environment than ever.
All right, to start out with I have to admit that although my day-to-day career is very much in the applied science software development area, my background in my undergrad work is in Math – totally a pure science. This means that I tend to think in more of a pure model approach as opposed to inherently accepting applied models. This has its pluses and minuses at times, but we all work with what we have.
I was thinking recently “Why the success of SharePoint in the enterprise?”. Of course all the standard arguments of Enterprise 2.0, collaborative environments, information sharing surfaced as an answer. But as I am delving into the software development aspects of SharePoint 2010 and starting to see a little deeper into the platform, I’m starting to realize a more basic reason.
In reality, I think one of the major contributing factors to the success of SharePoint in the enterprise as a platform has to do with how poor the user interface paradigm of a file system really is. Now this is taking a lot of reflection, because I trace my beginnings back to Fortran 4 and being a so-called BSD Unix hacker in the 80’s and early 90’s. So in other words, directories and files are ingrained pretty deeply in my “taken for granted” psyche. When you think about it, from a user’s perspective a filing system such as the one they use or have used in the past for paper looks like this:
Note the external enclosure with clean lines, the drawers, the ability to place decorations on top of it to facilitate good feng shui. To access information in a filing cabinet, you need to physically approach it, pull out a drawer, and then start to look for the particular document you desire. 95% of all filing cabinets have folders organized in an alphabetical order, so you know what to expect. Some of the other 5% and later filing systems would organize cabinets or sections of cabinets into different purposes, like “day to day” or “long term”.
Now a “filing system” on a computer looks and acts much differently than the above. It looks like this:
I think after the 4998765555th time of helping someone not very computer literate find the document they were working on and saved but didn’t know where they saved it to and couldn’t quite get the picture that they might have saved it so someplace different than “My Documents” it started to dawn on me that this whole “file system” paradigm really wasn’t a very good one at all. When you think about it a file system on a computer is the simplest way that “developers” could organize a pointer in memory to a location – by using a string. The forward slashes in a string are a “developer’s” organizational construct, not an intuitive one.
This relates in my mind to some different books I’ve read on the topic of HCI or Human-Computer Interaction and the interrelated field of “UX”. A couple of the first books I read were “The Inmates Are Running the Asylum” and “About Face” by Alan Cooper, which I purchased shortly after being at an architecture conference and having lunch with Alan and about 6 other known tech industry leaders with Alan being on a soapbox about how developers cannot design user interaction because they think differently than end users. Alan’s known as the “Father of Visual Basic” as he designed the first UI interface for Basic that he sold to Microsoft.
So to bring these thoughts and this discussion full circle, I think one of the successes of SharePoint in the enterprise has to do with the fact that a large number of information workers in your enterprise environment are not developer types, and to successfully interact with computers they need paradigms that they can relate to. Most users are familiar enough with the Internet by this point that navigating to a website to procure information is not that foreign at all to them. So if they can browse to a “HR” website, or a “Finance” website they have a head start on finding their document. But a “shared drive”? Not so much. I think organizing information content through a web interface is a UX paradigm that is slightly better than a file system. I think your average information worker “gets this” a little better than a file system. So in my opinion, that is one core fundamental reason that SharePoint has in starting to tie together the enterprise. Network shared drives that are maintained by departments are starting to be replaced with SharePoint document libraries and team sites.
Now maybe you might say that I have too narrow of a view of the skills of an information worker, and that power users or anyone that has used a computer successfully understands the file system. I would respond that first my viewpoints on this have been developed over many years of watching and helping people interact with computer systems and software, and second that a UX paradigm that is “natural” or “intuitive” helps UX flow and facilitates interaction much more than any paradigm that presents an obstacle.
Until next time, happy UX and SharePoint design and development!
I just learned that Channel9 has put up a new site for a SharePoint Learning Center for SharePoint 2010. A number of people are responsible for this, including Paul Stubbs, Girish Raja, Steve Fox, Donovan Follette, and Chris Mayo. It looks to be a video based course center with topics on SharePoint 2010 like:
The SharePoint community and Microsoft is rolling out well ahead of the SharePoint 2010 beta release a number of resources to help developers come up to speed quickly on SharePoint 2010.
For the Channel 9 site, they are first rolling out video examples of all of these sessions and then in about a week or 2 after the beta is released they will release labs with updated code that is compliant with the beta release.
Of course starting to blog about a journey in SharePoint or a re-focus to that product really drives blogging about experiences and things from the ground up. What I've found is that while a couple books walk you through setting up a SharePoint dev environment, and one or two blog posts I've seen out there do the same thing, there are several very basic things that are usually either assumed, implied, or buried 30 feet into the middle of a chapter or post. So I'm going to focus on answering basic practical questions that I had first. In going through this I've developed some opinionated answers, which as my style is I will present with colorful mind pictures.
Q. What Operating System do I need for SharePoint development?
A. People will say you can either do SharePoint development from Visual Studio on any O/S, or to do the development in a server type environment. They are huffing glue. While it is possible to do development for SharePoint in Visual Studio 2008 installed on Windows XP, or Windows 7, or Vista 64 bit, if you do so you will be crawling like a turtle through coding, testing, deploying, testing, etc. You will be slower than a 90 year old who hasn't quite yet had their driver's license revoked. You'll be working at the pace of molasses on the North Slope, Alaska on a cold December morning. You get the point. For any kind of reasonable development pace, you will need to develop on Windows Server 2003 (or stay tuned because SharePoint 2010 will facilitate Windows Server 2008). You need to have pertinent libraries handy, be able to debug, and to deploy to an environment you see the result in a timely fashion. This doesn't happen outside of a server setup for SharePoint development.
Q. OK – I'm going to go with Windows Server 2003 / 8. What else do I need installed?
A. SharePoint 2007, Microsoft Office, SQL Server 2005, Visual Studio 2008 SP1, updates. Don't bother installing the SharePoint SDK or those VSeWSS12 / 13 templates. They don't work very well. Install WSPBuilder for deployment tools from Codeplex. This is not an easy answer to put up with, because it goes against the grain. It takes too !@#$ long to do all those installs just for one stupid dev box. Suck it up, Eggbert, and do the installs. It takes less time to do it right once than wrong three times, and don't ask me how I know. Also you can customize your environment for all the cool little tools you know you always need – like Fiddler, IE Dev Toolbar, SPDisposeCheck, etc.
Q. What about Virtual PC 2007 and using Virtual Machines?
A. Yes, absolutely. They run pretty well from my experience with most of what you're doing in SharePoint. Also, if you keep a copy of your .vhd's every step of the way after building servers (after OS install, after MOSS install, etc.) you can save yourself some duhhhh time. Again, don't ask me how I know. You can also in theory download VM's for SharePoint from Microsoft. I say in theory because they are in 7 parts at over 800MB each and not on MSDN, so you can't use the File Transfer tool. Then you have to piece them together. And it's an eval license on SharePoint so it expires. All those hurdles pointed me towards just building one good MOSS development environment and then backing up the .vhd.
Q. How much space do I need to allocate for the hard drive for my Virtual Machine?
A. My fully loaded dev VM has a VHD that is 14.3GB. This information is nowhere else on the web that I could find. I found it through trial and error. After allocating VHD's of 5GB, 10GB, 40GB, and 20GB. Also after purchasing 2 8GB USB keys which are worthless for SharePoint. Yes a 16GB USB key is plenty to store one good copy of your dev environment Virtual Machine. I don't have info for this yet on the 2010 environment, but I'm going to start testing it at 16GB, and if it doesn't work, try 20GB. A good sturdy external USB hard drive is a good thing to have for storing all these. If you've never been a big fan of virtual machines before, believe me you will be now.
Q. How much RAM does my Virtual Machine need?
A. If you can spare 2GB, by all means do it. If you're RAM challenged (is that an underprivileged class?) than you can squeak by with 1GB, and depending on your box it may not be too slow. If you have the option, get the most RAM you can handle on a machine. If this means a custom order for a laptop with 16GB RAM and Windows Server 2008 as your OS, go for it. You know you want to anyway just to look cool at user's groups and conferences. And put a custom sticker of Wolverine from an old comic release on it too, just to stand out.
Q. These .vhd files have the same extension as the ones I see on Windows Server 2008 in Hyper-V. Can I use my Virtual PC .vhd's on a Hyper-V server?
A. Yes you can, Captain America. What a great excuse to upgrade your dev and test front end servers to Hyper-V.
After thinking about it for quite a while, I've decided to change the direction in which I am going to pursue blogging. Previously, with 3 Degrees of .NET, the blog served more as an information collection and link list type of service. However, with the rise of other social media such as Twitter, this purpose has become obsolete.
Also, I've been more recently focusing in my development on SharePoint, WSS 3.0 and MOSS2007. So I am going to migrate the content of my blog over towards my learning journey in SharePoint. With the product positioning, I'm right on the tail end of an old product and right on the verge of a new product. MOSS is going away, and Microsoft SharePoint 2010 is the official new product, as highlighted here in a note from Tom Rizzo: http://blogs.msdn.com/sharepoint/archive/2009/04/14/microsoft-sharepoint-14-is-now-microsoft-sharepoint-2010.aspx