Quote
Talking about Home – SharePoint Joel’s SharePoint Land
Given the tradeoff of server assemblies or someone using designer to create a dataview or create a workflow, almost all would choose the educated trusted power user with SharePoint Designer.
I would love to see the SharePoint Designer debate take on the same proportions as the custom site definition debate did previously (I am very muhc in agreement with Joel on that one) if for no other reason than to provide a louder voice of feedback to the SPD team. SharePoint Designer is many things and had great potential as evidenced in the dataview webpart and dataform webparts. However, the trade-off on larger environments (watch someone do a misguided SPD backup on a 25 gb site collection for example) can be very risky.
This comes to my point. SharePoint Designer points out the great misses of what could have been possible in SharePoint. There are options for the now, however. Instead of pushing SPD for the dataview and dataform webparts, for little money the same components can be purchased from Bamboo and used through the browser. Instead of ever using SPD for workflow creation, implement Nintex and enjoy what I firmly believe should have been the Microsoft implementation to begin with,
My requests of the SPD Team
1) Provide more granular security controls to limit the functions that can and cannot be used in SPD.
2) Implement a feature export function to provide SharePoint Solution packaging as a native feature of SPD (solves many of the arguments up front)
3) Remove the SPD specific "gunk" from designer created files. I should not have to refactor my workflows and master pages to remove references that would not have been created using visual studio (and which do not exist in the OOTB versions)
SharePoint Designer is a designer tool, but with some assistance and developer focus it could become the great hope that was there originally. We’re a far cry from the days of frontpage but with equally as far to go.
