It looks like Microsoft has finally put together the first installment of a true Resource Center focused on SharePoint. It has direct links to a lot of existing content that was previously scattered all over MSDN, some of which you might not have seen before.
http://msdn2.microsoft.com/en-us/sharepoint/bb964529.aspx
It is still kind of light on content but we can hope that Microsoft will continue the effort and turn this into a key launch point for all things SharePoint related.
I started using Windows Live Writer late last week to author my blog entries and have to say that I am very impressed. In fact, the last 3 posts on this blog were all done with it. Once configured, it is fast, extremely easy to use and focuses solely on the task of editing and posting blog entries. This means that there is no menu/UI clutter from a bunch of bloat (yet) so it is pretty easy to find what you are looking for.
Some of the cool things I've found so far:
To make blogging even easier, I've discovered a few related goodies that work well with pretty much any blog editor.
Wonderfulness (?) aside, this is still a "dot OH!" product from Microsoft so there are a few small bugs yet to be worked out as well as the occasional crash but it is a strong enough product that I can easily overlook those. I've been spoiled now and can't see myself ever going back to Word or OneNote to compose my blog posts.
It is great when you are in a field where you can learn at least one new thing every day. For example, I've been using generics since they became available in .Net 2.0 and yet, somehow, this was the first time I've seen this particular way to use one of them:
Dictionary<string, object> oProps = new Dictionary<string, object>();
This creates a strongly-typed dictionary object and that uses a string as the key and an object as a value. Super simple and wonderfully powerful yet I had missed that in all of my readings and experimentation. This just made my day!
Whenever you customize the default list forms (NewForm.aspx, Dispform.aspx, or EditForm.aspx) in SharePoint designer, never, ever, under penalty of torture using Ed Wood movies, ever, I mean ever, delete the default ListFormWebPart that is on those pages. Doing this will subtly corrupt how your list is defined in SharePoint and can cause you all sorts of grief.
The most minor problem I've seen is that you lose the ability to specify the Supporting Files for the list. Oh sure, it will look like you can set them and it will even save and refresh properly in Designer. However, SharePoint will simply ignore that and go right along showing the default files instead.
The bigger problem is that deleting the ListFormWebPart from the NewForm.aspx page can effectively disconnect the "New" option on the list toolbar resulting in the ever annoying "Invalid page URL" dialog box when anyone clicks on it. This is a known issue and the only way to fix it is to delete and recreate the list. Not Fun.
Instead, save yourself some grief when editing these pages and just leave those web parts on there and add a new DataFormWebPart above or below it and customize that to your liking.
Note: make sure that you insert the new web part into the existing WebPartZone or else you will lose the 'Edit Page' option for that page on the Site Actions menu.
Once you have the customizations you want in place, you will need to hide (not delete!) the original ListFormWebPart. To do this in Designer, simply change the IsVisible element in the WebPart XML to 'false'
Alternatively, you can hide it using a browser as well. Simply browse the page and edit it, either by using SiteActions -> Edit Page or by adding "&PageView=Shared&toolpaneview=2" to the querystring in the browser.
Then edit the web part properties for the original ListFormWebPart and hide it
This keeps the original web part on the page which keeps SharePoint happy. Your users only see the customized list view that you want them to see, which keeps everyone else happy.
I've been using SnagIt for years and absolutely love it. Recently, I needed to grab a picture of menus but also needed to apply some effects to the unimportant areas so as to draw more attention to the menus themselves. I stumbled a bit with the freehand selection tool, largely because I can't draw a straight line for diddly. The rectangular selector was *so* close to what I wanted but it kept bringing in parts of the image that I didn't want to highlight. Out of curiosity, I tried the old Shift trick and it worked exactly like I'd hoped!
What is the Shift Trick?
This allows for some really odd selection shapes but is quite handy when you need to outline complex areas. In this picture, I was able to select just the menus and then dim and blur the background.
(and for the record, yes, I could have applied the Torn Edge effect to the selected area which resulted in torn edges on each of the menus. Interesting, but lost clarity)
Just for fun, I wanted to see what I could do with this – pretty neat, actually.
A few days ago, my journey through the vast wasteland of dysfunctional RSS readers took an unexpected turn for the better. After my most recent experiment (FeedReader) ate its own database, I decided to take a look at one that I have been seeing a lot of in my blog stats – JetBrains Omea Reader. So far, I really like what I see. The tool is visually appealing and is the first Reader I've tried in years that didn't leave me saying: "Oh, how I wish SharpReader was being updated…"
It has everything I expect from an RSS Reader and does most of it pretty well and pretty darned fast. One of the nicest features I've found is the ability to create a View based on search criteria, allowing you to keep an eye on any hot items/keywords that you might be interested in, automatically. Now I can easily keep tabs on how Visual Studio is going to take over World of Warcraft add-in development.
As a bonus, Omea also has a good Usenet News reader built into it. This is something I had pretty much given up on since Anawave Gravity (the greatest Usenet reader of all time) was killed off.
I have tried quite a few RSS readers over the past few years but none quite fit what I was looking for. Here are a few of them:
SharpReader – My personal favorite because of its speed and the tight focus on the tasks related to RSS but it has not been updated in quite some time. It also suffers from the rather annoying habit of corrupting its own database every few months or so. It recovers from this but it does require that I go through and mark thousands of entries as read.
Google Reader – fast but far too few options for managing large numbers of feeds. Nice if you only have a few feeds or if you need access to feeds from multiple computers that you might not have control over (i.e. kiosk/walkups/guest machines). The UI does take a little bit to get used to.
NewsGator – As a consultant, I rarely have Outlook open as most of my clients either use Notes or don't allow consultants to have accounts on their Exchange servers. As such, I really don't like being that tightly tied to an app I never use (Outlook). It also had WAY too few features for me to use to manage the number of feeds that I have. I have read that it does work very well for consultants who travel a great deal because it caches feeds so that they can then be read while disconnected, like while on a plane. My only travel is the drive to work and I'm pretty sure the other drivers would get a little upset if I was reading news feeds during that time.
FeedReader – good generic reader but pretty shallow on the features. It lasted several months but then terminally corrupted its database – no recovery whatsoever.
Omea – This is day three for this reader so only time will tell. So far, it is very good.
After searching the net, it appears that the generic "RENDER FAILED" message (below) appears when customizing certain views for a multitude of reasons, each with its own unique combination factors and its own solution. So, here is one more set of parameters / solution to add to the chorus.
I had a view that was grouping on a single field and also had to provide the AVERAGE of a number field. When trying this with the default Group By settings, I would get the <!– #RENDER FAILED –> error message.
The fix was obscure but simple. Change the Group By options to Expanded and the problem was solved.
There has been a lot of discussion over software bloat over the years (the latest entry at: http://www.codinghorror.com/blog/archives/000973.html) The question is not whether it is bloated or not, it is. The question is, how did it get that way?
The biggest reason software gets bigger over the years is because companies keep adding features (duh!). Yet, people condemning "bloat" in all forms seem to think that companies and marketing departments exist in a vacuum and just pull new features out of the amazingly thin air of said vacuum. The truth is that most of these features are requested by end-users and they are adding in order to keep the customer base happy. A pretty important point in a market economy.
Once software is released in the wild, it tends to take on a life that the original developers never dreamed of. People come up with all sorts of creative ways to use it and, naturally, hit limitations that they think should be removed. With each broadening of the software's focus comes the infinite loop of new uses followed by further broadening. Over time, you get products like Word and Excel which do pretty much everything but make mounds and mounds of Julienne french fries.
Not all products should have all features and the business should exercise restraint on many of the features that are added. You might want to add that as a standard question in your feature review: Should WordSheetViewer Deluxe Pro XXL be able to broast chicken while still fitting into a pocket and alleviating lower back pain?
It's hard to say "No" to a paying customer but perhaps the business should look on those situations as opportunities. Each of those requests is a customer telling you that they have a need, and that your product is very close to filling it. They are also telling you that you have achieved a modicum of trust in the relationship as well, otherwise they wouldn't talk to you at all. What is the feasibility of some of those requests being rolled up into stand-alone products? Even niche products have a market. The benefit here is that development time would likely be small since you already have a substantial amount of the code written. Support costs would also be reduced because the new product is based on a (hopefully) proven code base.
Where do we go from here?
I think that the add-in model is the way to go but instead of installing everything but the kitchen sink as part of the base product, include only the barest minimum as the core. Then make all of the other features available as free or easily accessible add-ins. That way, people who only use 50% of the functionality will only need to install 50% of the features.
Most importantly, make the API for your App and Add-ins detailed and readily available so that third parties can easily extend the product. You might just gain a loyal following from people who would have been your competition's testimonials.
I have been a user of Gmail for years and still love it as much today as I did back when I was able to first sign in. That's why I was pleasantly surprised when I came up with yet another way to use it.
I deal with many servers that cross numerous system boundaries and I find myself occasionally having to copy textual information from one server to another and, in some configurations, mapped drives and copy-paste simply aren't available. This leaves the old stand-by of manually re-typing the information or getting a server support monkey involved and spending an hour talking it through a 3 minute change. However, almost all of these systems have internet access, which is where I my idea came in.
The problem with commonly available internet applications is that there is no quick, easy and reasonably secure way to put data onto a public server on the internet that can be easily managed from multiple locations. Those that are available involve setting up some form of CMS or FTP, and FTP is almost always disabled or blocked at the firewall. Then my idea struck – use the drafts feature of Gmail to move data across systems.
How it works
Advantages
Ok, so how does this even remotely touch on SharePoint? One word: Web.config . The changes that often need to be made in the SharePoint Web.Config tend to be rather difficult to type without error. Things like GUIDs and Keys abound and are amazingly annoying to type. This way, those items can be copied intact and I won't have to spend hours troubleshooting a fat-fingered GUID.
Obviously, this will not always work due to firewall, proxy, policy and security restrictions but it has worked well the few times I've needed it. Also, be aware that it likely a violation of company policy to host confidential data on a public server (even temporarily) so be careful what you use this for.
Sharepoint likes to use the Embedded version of SQL Server when you choose a stand-alone install of WSS. Normally, this is not an issue but there are times when you need to get into that database. Unfortunately, getting into that database is considerably more difficult than you might expect.
Why would you want to get into a database that Microsoft keeps you out of intentionally? In my case, I had to switch an existing installation from using the default NETWORK_SERVICE account to a domain account. An account that had no permissions in the WSS databases whatsoever.
In order to get into MICROSOFT##SSEE
From there, I just added my domain account with the proper permissions and WSS was happy again.
davidwise