Wednesday, October 12, 2011

Sparking your interest?

While Autodesk Labs is one of my favorite places to visit, sometimes they have a project that just makes me go: "Wha....?" Spark is one of those projects from my perspective. It certainly caught my interest when I read about it. The tag line is quite catchy:

"Project Spark is a technology preview of a simplified 3D building information modeling (BIM) solution. Using Project Spark, building professionals can create designs efficiently with real world building objects, produce more reliable documentation faster, and share files with consultants using Revit or AutoCAD based products."

Naturally, I downloaded it and spent a couple of days fiddling with it. Unfortunately, I was largely disappointed with the implementation of the idea. Spark is really a pared down version of Revit. While I appreciate the idea, taking Revit and removing some core functionality isn't a way to make a "simplified" 3D BIM solution. It is a way to make a less functional BIM solution. But, the devil is in the details.  So, what exactly did get removed?


That's the short list. I've got my analysis of each item below if you're interested, but the core problem I see is that the foundation of the project seems to be summed up by this equation: Revit - Features = Simplified, and Simplified = Better. The math geek in me doth protest. The problem with Revit generally isn't that it has too many features, it is that the features it has are too hard to learn and use consistently. If Autodesk really wants Spark to succeed they need to look at this differently: Revit - Inconsistency + Ease of Use + Ease of Training = Better. That's the key to making Spark really catch fire. Also, I question what  success is in this context. Creating a new software offering or providing a tested to make the Revit platform easier to use? Either way it is an interesting concept, although I certainly prefer the latter from an end user perspective.

  • No Worksharing – Makes perfect sense. I get removing this for a “simple” program and this does actually simplify things a bit. It works like sketchup, FormZ, Bonsai, Rhino, Etc...
  • No Photorealistic Rendering – I wouldn't call the rendering in Revit “complicated” by any means, so it seems odd this was removed. Rendering is a basic function of most competing “simple” BIM tools as well. Since all the rendering related information is still in the materials dialog to support textured viewing, I really don't see the payoff.
  • No View Filters – This is an overly complicated part of Revit, so I get removing it as is. However, the functionality represented in filters is absolutely necessary to get decent visual graphics out of Revit in an efficient manner. So, I really think the Labs team should spend some time “innovating” how that core functionality of selection sets and visual overrides are accomplished in a BIM environment. This would have a huge positive impact flowing back into Revit as well.
  • No Groups – What? Again, grouping is a core “feature” for modeling in almost any application. Sketchup has a corollary, FormZ and Bonsai have a corollary, Rhino has a corollary. They aren't that hard to use outside of having to enter the group edit mode. Again, this is an area that feels necessary and just needs a little tweaking to be simplified and still available.
  • No In-Place Families – who do I have to pay off to get this removed from Revit as well? Hehe. Happy to see this gone, we just need to be able to edit family content with the project context in the background. That's the only real benefit to In-Place Families.
  • No Massing – I sort of get this, and sort of don’t. Massing can be complex, and this isn't targeted as a conceptual design tool since that's Vasari’s realm. However, it leaves Spark without the ability to create so many basic forms that are just necessary in today’s design/construction environment. Opportunity wise, this is another area where innovations in Spark to support "complex" forms like slanted walls without needing massing would benefit the core platform.
  • No Analysis – I can see this as extraneous to those I see as the targeted end users of Spark, plus the analysis features are generally more easy to use than a lot of the core features are thanks to Vasari so they need less attention to make simpler.
  • No Trusses – Personally I think trusses are the most important structural element to have in any design or production software as they are the element least likely to be hidden behind ceilings and most likely to be incorporated into the design direction. However, the truss tool in Revit needs some work to make it more usable and is quite complicated at the moment so the factory is probably better off removing it. Long term, this would be a good thing to simplify and include.
  • No Shared Coordinates – I get that shared coordinates are complicated. However, by removing this Spark models are basically UNUSABLE in any downstream process. I want you to know that  because I think it is an inexcusable omission. This is one place where the Revit platform could really use some UX level thought in making multiple coordinate systems less confusing to the average user. It is an absolutely necessary evil to be able to define multiple coordinate systems so you guys ought to be Labbing it up in my book.
  • No Point Clouds – What? Why? Ok, it makes sense. But I love me some point clouds…
  • No Sunpath – Makes some sense along with the analysis, although this is arguably one of the easiest things to use in the whole platform.
  • No API - I don’t really understand the benefit to removing this other than it probably makes it simpler for the factory to work with. Unfortunately, it prevents us from using plugins that might make Spark even simpler than it already is..
  • No Parts / Assemblies – I kind of get this one, although as the confusion about parts/assemblies/groups/etc… gets worked out in the main platform I would expect to see either assemblies or groups in something like Spark.
  • No Design Options – Removing one of the most complicated and difficult features in the platform makes a lot of sense. With worksharing removed so it makes sense to run multiple sequential files from a workflow perspective anyway. However, I’d really like to see the factory take a look at this and make Design Options much much better long term. Spark may not be the project for it, perhaps Vasari is a better home for that project. One of those two projects ought to take a close look at the intent of DO and actually deliver upon it one of these days…
  • No Adaptive Components - This makes sense in the light of massing and general conceptual design features being removed across the board, although as more of the main platform transitions to adaptive components as core content and not just design-centric content I might begin to question this decision sooner than later. AC’s are arguably simpler to build and more flexible content wise.
  • Simplified Export – Makes sense in general, although again the no API thing means no exporting to things like NWC, and leaving IFC out is just inexcusable all over again. The implementation here once again really limits the use of anything created in Spark downstream.
  • Simplified Links – I shockingly have no issues with this, though perhaps the factory didn't go far enough. I mean, what is that CAD stuff for? That's SO 1990's.
  • Simplified Content – I'm not entirely sure what this references. I haven’t noticed a substantive difference yet outside of less categories being available. I’d love to know more if there are some changes I just haven’t noticed yet. I don't think removing categories should count as making the process of creating content "simplified", so I hope that something else is there.
  • Simplified Phasing – Again, I didn't notice anything on the surface that was in any way simpler. Phasing is already pretty simple as is. Again, I think phasing could use a UX eye to make better, but it isn’t a high priority compared to some other features.
  • Simplified Materials – Not really much simpler actually, it’s still pretty complex and since textured display is still supported the whole rendering backend which makes the materials dialog so complicated is still basically there. So, I question this being “simpler” outside of a missing tab and button or two that are outside of the core materials workflow anyway. There is a lot of opportunity here to make the materials dialog more like selecting a material in a material library in real life.
Long story short, I really like the idea of Spark I just don't think the path it is on right now is the right path. It seems like "limited" is a far better descriptor for Spark than "Simple" in the current incarnation. This doesn't change the need for a truly easy to use, interoperable, and inexpensive BIM solution. So, I'm hopeful that Autodesk can get on the right path to delivering such a solution. Otherwise I'm going to have to keep fighting the Sketchup battle for another 10 years. Sigh...

Wednesday, October 5, 2011

The Future...

After all, that is the whole point of this blog right??? (Yes, it is.)

So, I had the privilege of flying up to Denver two weeks ago to present on technology and process trends in "our" industry for the next 10 years. Aside from running a little long, I felt the presentation went really well. It was my first time using a mind map as my presentation tool instead of just as a planning tool. So, I was a little nervous but more excited. It was nice to finally have a presentation topic again that lent itself to a less linear presentation technique... I thought I'd share the presentation map, and a few tidbits along with it on the blog.

So, the presentation itself is on Mindomo, which is a web hosted mind mapping tool that I prefer to some of the more "traditional" mind mappers out there. However, it has a ways to go to really be perfect (who doesn't?).
Here's the link if you want to follow along: DBIA Regional Presentation


So, at a glance, five topics:
  1. My own little soapbox about BIM, Integration, and Sustainability (Or "SustainaBIMegration" as I like to call it when my boss isn't around - sorry Peter!). 
  2. Some pertinent trends in the AEC world that relate to the real focus of the presentation (not an exhaustive list by any means!).
  3. Now - which is what it sounds like, things we are doing now in this industry that you'd better be on board with or risk falling behind.
  4. Soon - things that are three to five years out in my estimation, just held back a bit by technology or our slow to change industry.
  5. Not Soon Enough - things that are in the ten year time frame, but I wish would get here sooner.

What I love about these maps is that I can embed a TON of detail in them:


Here are the two into topics expanded one level deep. Each of those sub-topics have four or five notes under them, and some may even go deeper. The sky is the limit, and what is great is that you only have to go as deep as time (and the audience) permits. Plus, you can embed videos, audio, or hyperlinks into any one of these topics or sub-topics for a really rich presentation (even if you're not around to give it).

Here's the blow up of the 10 year discussion points:



Anyway, LOTS of information, though it can certainly get better! The last image is the full map:


Thanks!

Monday, October 3, 2011

To Cloud, or not to Cloud, that is the question...

if Shakespeare were alive today, perhaps he'd be asking that very question (to himself) about publishing and writing his works in the wonderful mess of data centers and switches we call the cloud. Despite being a technophile; I'm not a tweeter nor am I a rabid fan of the cloud. But why???
  • Ownership of content is still fishy. Depending on which cloud service you're working with, ownership of the materials you place on the cloud may or may not reside with the hosting service. So, if you write that sequel to Hamlet you've been thinking about (or not) then Google might just own your book. "Not Cool" says Willie S.
  • Access to content is also a little fuzzy in my book. To make an example a little closer to home, what happens when you've got 15 people across 4 offices working on one project and POOF there goes the cloud? If your host goes into bankruptcy how do you and your project team access the files you need to continue doing your job? What happens if they have a colossal failure at multiple data centers (for any reason) and you can't send out those CDs on a project with penalties for later submittals? Good luck convincing the owner that the cloud ate your homework.
Now, that said, the cloud offers some amazing potential. To throw a shout out at Autodesk, their new "Autodesk Cloud" and the features that come bundled with it make the first hint of a compelling reasons to have all our employees use the single sign on. (Bluestreak was not enough, sorry). Hosting DWFs on the cloud that can be accessed and marked up simultaneously on multiple platforms (from iPads to Win7 Tablets to my brick of a laptop) is a huge benefit. Cloud based rendering (ala project Neon) is also interesting, although Neon never got to the point where it provided compelling results for me. But, as it progresses further I can see where the "Unlimited Computing" the Carl Bass likes to talk about can come into play. Now, Autodesk Cloud still has some issues to deal with...

  • Everything is still managed through single file interactions, so sharing 725 DWF sheets with 14 people is a complete waste of time if they're packaged as individual files. Same thing for uploading new versions. Actually, they need a desktop sync system like Box.net or Dropbox.
  • Storage on the cloud is parsed out by user (???) instead of by firm/project/etc... I can't even finish uploading all 725 DWFs with my 3 Gigs of apportioned storage as a subscription user. They really need some solution for project level storage, as well as firm level storage; that is in addition to user level storage of course.
  • What about network licenses? We have roughly 55 Revit licenses at last check. We have roughly 75 full time Revit users. I'm not clear if we can only have 55 subscription sign ins with 3 gigs and the rest will have only 1 gig of storage, or if all of our employees can have 3 gigs.
  • How about viewing Revit files natively? I'm only exporting to DWF to get them on the cloud, I'd love to be able to upload the Revit file and be done with it.
  • DWFs are good for markups if they're separated. No one wants to mark up 725 sheets as one DWF. However, all the associative linking in DWFs across multiple sheets is lost when you export individual DWFs. It would sure be nice if the Cloud was smart enough to recognize links across multiple DWF files and let you still hop around between them without the restriction of one uber DWF set for the whole project. 


  • The cloud is great and all, but the apps really need to support local storage. If I don't want to use the cloud for some crazy reason like security requirements, I should still be able to use the design review app to view my own files by synching them to my iPad in iTunes.
  • And, to add to that, we should be able to specify our own "cloud" and pull files from it. If we have our own net-accessible file server, why can't I point to that and pull files down???
Issues aside, the Superintendents on the project I'm working on LOVE being able to access up to date DWFs on their iPads, including the 3D models. So, it's a big hit in that regard. A few tweaks and I think Autodesk could have something really useful on their hands. It is a great first try! Good job factory. Now, I just need to actually read that darn EULA...

My two cents on the cloud for today...