Trying to Be Twitterific

I’ve decided to try out this Twitter thing that all the kids are talking about.  On my recent vacation, I made a concerted effort to imagine having Twitter available as we went around doing things: “Just saw a monkey cross the road”, “Ziplining ought to be a verb because it is so much fun”, “Boy, this is good pineapple”, “Good programming practices can’t fall by the wayside with today’s fancy tools”.  OK, I have trouble turning off my work brain sometimes, I admit it.

I’ve signed up with Twitter, added the Twitter widget to my blog’s sidebar, downloaded the GeoTwitter (I love the geocoding idea!) and Tweeter apps for my iPhone, and I’m good to go.  Now the test will be if I can come up with good “work” stuff to tweet about.  No monkeys crossing the road here.

I’ve heard some interesting stories about what *not* to do with Twitter: tweeting about the great sales meeting you just had with client X (the competition *loves* to hear about that — watch them swarm), mixing work and pleasure too much (“My wife and I just took a great bubble bath” doesn’t really give you much street cred around the office), “My boss sux” (Gee, do you think she needed to hear that???).

You can watch me learn here http://twitter.com/sympmarc or in my sidebar.  Maybe I’ll think of some useful things to say.  If not, well then at least it’ll be a fun experiment.

Exciting News: SharePoint Designer Is Now Free!

I’d heard the rumors, but now it’s apparently true: My favorite Microsoft development tool is now free.  This seems like a shift in strategy for Microsoft, but they try to explain their reasoning in a Letter to SharePoint Designer Customers.

If you follow my blog at all, you know that I think you can do a heck of a lot with SharePoint Designer, and that it’s a good thing.  (See my diatribe entitled SharePoint Designer: Useful Tool or Spawn of the Devil?)  Opening SharePoint Designer up to all takers has got to have a lot of SharePoint administrators quaking in their boots, though.  Many governance policies will have to be rewritten as well.

Let me stress what may have been the most important point I made in my Tool/Devil post above:

Keep in mind that in SharePoint, EVERYTHING — let me repeat — EVERYTHING is security trimmed.  If you don’t have permission to access something through the UI, you won’t be able to access it through SharePoint Designer, either.

If you’ve been sloppy with permissions, then you may have some issues with folks using SharePoint Designer when you weren’t expecting it.

I’d recommend, though, that instead of panicking about this shift, you should think about what great capabilities it will put into the hands of your user base.  Power to the people doesn’t have to be a scary thing.

Hiding Permission Groups for Your WSS-Based Extranet

We’re using our hosted WSS site for our Internet site, our Intranet, and our Client Extranet.  This is a very cool use of WSS, IMHO.  Not only do we have all of the great content management capabilities for our external site, but we have the team-based capabilities which we can use to interact with our clients and amongst ourselves.

One of the tricky bits to this configuration is of course to get the permissions right.  Because WSS was built fundamentally as a collaboration platform, your users often see things that you don’t really want them to.  One specific thing you probably don’t want to expose is the permission groups.  For instance, if you have a group called Clients – Client A, you probably don’t want the members of that group to know that the group Clients – Client B even exists, not to mention its membership.

The solution for this isn’t totally obvious.  By default, every user who has access to a site can also see the permission groups and users from that site.  Since permission groups are managed at the Site Collection level, that means that they can see all of the groups, not just the ones that have permissions on the current site.  Sure, you might say, just create separate Site Collections.  That’s one answer, but since we want to be able to enable collaboration not only between us and our clients, but potentially also amongst our clients (should they decide they want to be a part of that community), separate Site Collections would be limiting.  We want this all to work within one Site Collection.

Removing the People and Roles link on the Quick Launch hides the visible navigation, but any user who has spent any time with SharePoint is likely to know that the page lives at /_layouts/people.aspx.  (You will want to remove the People and Groups link, though, so that the users won’t get the unsightly

Error: Access Denied

error page.)  Never forget that obscurity isn’t security!

To clean this up, I created new roles called Read – No Browse User Information and Contribute – No Browse User Information.  (See this previous post about managing roles.)  These are copies of the Read and Contribute roles, but with Browse User Information removed:

We have a permission group called Clients, and I assigned the Read – No Browse User Information role to that group on the Extranet site.  Each client sub-site has a permission group like Client – Client A which is assigned the Contribute – No Browse User Information role.  Now the users can read or interact with all of the content, as appropriate, but they can’t “see” each other. 

If you do this, make sure that you make the change for any child sites which don’t inherit permissions as well!