Our Ops team just put out a new white paper that should help you understand the level of seriousness with which we treat the security and availability of our customers' data on Constructware and Buzzsaw.
Enjoy!
Our outstanding team of developers have found a hole in the space-time continuum which has managed to speed up Buzzsaw loading times and make the general Buzzsaw experience faster, especially at login.
Please go to www.getbuzzsaw.com to download the latest version of the Buzzsaw client, and just enjoy all that extra time we're giving you back.
We all know that Buzzsaw is operated by a top-notch, highly trained, well-run, SAS-70 audited group of IT commandos. We call them "IT Operations" or "Service Delivery" or sometimes just "Delta Force".
But we get confirmation every once in a while from outside Autodesk, that these guys are doing as good a job as we think they are. Sometimes it comes in the form of an audit, sometimes a customer (or potential customer) has a bunch of questions for us to answer, which we always seem to be able to do.
But just the other day I heard that a major IT services and software company was implementing Autodesk Buzzsaw for its own project collaboration needs. This is a company that is used by the biggest Fortune 100 types, and has some really cool online meeting software and remote access software. They wanted to do some white hat testing on their own, before they decided our stuff was secure.
Hmmm. I was a bit nervous. After all, these guys are leaders in SaaS and are probably some of the experts in online security. They've been doing this a long time. THEY were going to be probing our systems? We were going to be subjected to THEIR automated hacking and port sniffing and TCP/IP fu? This might not be good...
Well, breathe easy, o Buzzsaw fanbase. Below is a screen shot of the email they sent us last week, regarding the results of their testing. Bravo, boys! Special thanks to Bill Higgins, James Landis, and Paul Cochrane for their tireless work in keeping our data safe and sound!
People tell me from time to time that they want to print out the contents of a Buzzsaw directory. Don't ask me why; to me, printing is soo 2005.
Anyway, if you're looking to do that type of thing, the ever-handy Webdrive, plus a copy of the free JR Directory Printer, should do the job. Let me know how that works out for you, OK?
Lots of you IT types need to deploy Buzzsaw across your corporate network using Microsoft SMS (Site Management Server is what I think that stands for.)
This white paper will help you accomplish that. Do what it says and you'll have all your corporate drones hapless slobs valuable employees on the same page with the Buzzsaw client install in no time.
In other news, Autodesk Design Review 2009 requires Administrator rights to install. I'm still waiting on word from our product team on when that might change, or how you might work around it if you don't have those kinds of privileges on your machine.
I'm happy to report that a new release of Buzzsaw hit the servers over the weekend and was available to all clients as of yesterday. This new release includes some nice enhancements in addition to correction of defects.
The highlights are:
Document Register Enhancements: We have address numerous usability and quality issues to better support construction industry document management processes. Enhancements include attribute display control, required attribute entry, "quick add" attribute population during file upload, and linking a document register to a specific location in the project file hierarchy.
Support for Autodesk 2009 Design applications: Buzzsaw 2008.2 is now fully compatible with AutoCAD 2009 (including Save to Buzzsaw and Edit Lock functions from directly inside of AutoCAD). We also support design review and redlining the latest versions of Autodesk design applications with full integration with Autodesk Design Review 2009 and DWG TrueView 2009.
Hidden Groups: This was actually added in a point release earlier this year. You can read my notes about this here.
Submittal Package Enhancements: We have updated the Submittal Package feature to allow all reviewers to add attachments (at every step of the Submittal Package Review work flow).
You can download the entire What's New document here.
No, I'm not talking about Zelda. I'm referring to the ability to link files to forms in Buzzsaw Professional. We had a release a while back that included this great enhancement and I wanted to make sure everyone knew about it and what it offered.
Previously you could attach a file to a form, but not link to a file that lived in the folder structure. What this meant was that a copy of the file was attached to the form and it was a reflection of where that file was at that moment in time. This works great for many situations, but others call for a more flexible option. This is where file linking comes in.
With links you have the option to associate a form to specific file. Essentially the form will include a pointer that directs the user back to where the file lives in the folder structure. This offers lots of advantages. For one, the user can follow the link to the file and then use the Buzzsaw viewing and markup tools to redline it. The redline is then saved in the normal Buzzsaw Markup tab. Additionally the link can point to either the most current version or a specific version of the file. This way if the file is updated with a new version, the link will automatically point to the new version.
As you can see there are situations where both links and attachments have their advantages...and now you have both options!
If you haven't used the new hidden group feature to hide some of your groups, you might want to consider it. This new group type allows you to create a group that can't be seen and therefor emailed by anyone other than an admin. So for instance if you have an "all users" group to share standard documents with everyone you might wnat to consider hiding it. This way, nobody can just decide to send an email to everyone on your site.
You can read the details about this group and the other two group types here:
In a site level, private or hidden group the members can only be seen by site administrators and the owner of the group. In a project level private or hidden group the members can be seen by the site administrators, groups owners, and project administrators with access to that project. Private and hidden groups are distinguished from general groups by a different icon. A private or hidden group cannot be expanded unless you are the owner of the group or are a site administrator.
Open group — the group and its members can be seen by everyone who has access to the same projects.
Private group — the group can be seen by everyone. However the members of the group can only be seen by site administrators, the group owner, and project administrators associated with that project (if a project level group).
Hidden group — the group and its members cannot be seen by anyone except site administrators, the group owner, and project administrators associated with that project (if a project level group).
In a private or hidden group, members of the group cannot see each other's name or contact information. Private and hidden groups can be created by site administrators and project administrators (who have the privilege to create members and groups). Project administrators can edit and delete groups that have been defined for thier project. Group owners can edit and delete groups that they own. Site administrators can edit and delete all groups.
When used in conjunction with the deposit permission, a private or hidden group is useful if you want members to be able to update project files but you don't want them to see who else is updating documents. For example, if you are asking members to bid on a project, you want them to be able to add a document detailing their bid, but you don't want them to see who the other bidders are, or their contact information. Thus, creating a private or hidden group, used in conjunction with the deposit permission, allows you to do this. Private or hidden group members can add a document to the project, but they can't see other documents in the project nor can they see who the other members in the group are. Note that they can still see other project members, but not the other members of the private or hidden group.
When sending email through Buzzsaw, a private or hidden group is automatically placed in the BCC field. This prevents the names and email addresses from being exposed to other mail recipients. It is not recommended that you assign a form to a private or hidden group. Doing so exposes the names and email addresses of private or hidden group members in the routing tab of forms and in various dashboards. When a private or hidden group is added to a discussion only the group name is displayed in the participants field.
While a private or hidden group can be an effective way of maintaining confidentiality, there are limitations. The member names of a private or hidden group do appear in certain places across the site (such as a document's author). In order to maintain confidentiality within the private or hidden group, you must give each member deposit permission. In this way, when a document is added to a project, the private or hidden group members can not see the document or the author. The author's name can be seen by members who are not in the private or hidden group.
It is also recommended that you do not assign a form to a private or hidden group. Doing so exposes the names and email addresses of private or hidden group members in email notifications. Forms can only be assigned to hidden groups by administrators of the project containing the form log.
So there's a bug in Buzzsaw that makes it difficult to drag and drop folders to your desktop, if the path to them is very long. In other words, if a folder is contained within a nested tree of subfolders, and if the overall path of all of them together is very long (more than 250 characters or so), you'll get an error when you try to drag and drop or copy and paste them to your desktop. Our best people are working on the bug.
In the meantime, you can fix the problem (if you run into it frequently by doing the following):
1. Install the latest version of Buzzsaw (www.getbuzzsaw.com)
2. Open Registry Editor (Start/Run/"regedit")
3. Search the Registry for this string: "\Application Data\ProjectPoint-2008\". Use Ctrl+F to search. Or you can navigate to HKEY_CURRENT_USER/Software/Autodesk/ProjectPoint-2008/Settings/Initial/RootLocation. When you find it, it will be part of a key that has the "cache" or "temporary" path for ProjectPoint.
4. Change the entire path to something short, like "c:\temp\". Exit Registry Editor.
Part of your problem is now solved. Of course, if the path on the Buzzsaw server is *really* long, you might still get errors, even if your local path is short.
Hope this helps!
Our marketing all-stars just posted a brand new case study on one of my favorite builders, Veridian Homes, who are the largest builders in Wisconsin.
In this excellent case study, Dan Gorski, Veridian's Vice President of Estimating, Purchasing, and Design (pictured, at right) is quoted:
“Most of the guesswork has been taken out of our building equation. The cost, the performance, even the appearance of the house—they’re all built into the Revit platform model, so there’s less chance for error—resulting in a better product for our customers.”
and
“We have over 250 users—from roofers to cabinet manufacturers to appraisers—using Autodesk Buzzsaw,” reports Gorski. “With Autodesk Buzzsaw, we can get project information to them faster and more economically.”
I said it yesterday, I'll say it again: Excelsior!
