Based on feedback from the structural suggestions page, the following Target Audiences have been suggested by Jeremy Thake
, Rick Kierner and Erica Toelle.
A point to remember is that this is the SharePoint Dev Wiki and therefore is focussing on Development and will not cover all angles of SharePoint as this is too large. Therefore the main target audience is SharePoint Developers, but it is important to define the alternatives approaches to Development and their pros and cons.
SharePoint User
This is the non-developer power user and content recipient. These users are one with MS Office and have may or may not have done some List management but have never opened Visual Studio. They sometimes have ventured to SP Designer though.
Sample Content may include:
- What the limitations are of only using SharePoint Web UI (e.g. no features, event receivers, custom web parts, etc.)
Note, this does overlap with EndUserSharePoint.com which is geared towards this User. I think if there is a section that can allow the explanation of the need for Development over UI Customisations which will be primarily targetted at this audience that is enough. This is something that is currently not explained very well anywhere!
SharePoint UI & Designer
This is all the front end stuff. User interaction, graphics, layout, and visual structure.
Sample Content may include:
- How to do Workflows in Sharepoint Designer
- How to do Business Forms in InfoPath with Forms Services
SharePoint Developer
Application builder, gets into the nitty-gritty of the object model and Solution Packages and Features. Uses SharePoint Designer, Visual Studio, power shell, STSDev, WSPBuilder, SPSource, VSeWSS etc.
Sample Content may include:
- Solution Packages 101
- Features 101
- Development Tools to help
SharePoint Administrator
Infrastructure person responsible for deploying the updates between Test, Staging and Production Environments.
Sample Content may include:
- Pros and Cons of different deployment techniques (Solution Packages, Scripts, Manual UI Changes, Database backup/restore, Content Deployment)
- Security Models (Active Directory Groups vs SharePoint Groups)
Comments (19)
Dec 03, 2008
Brian Farnhill says:
I don't think that this wiki would contain a lot of content for the end user, I ...I don't think that this wiki would contain a lot of content for the end user, I think we should be focussing more on the other 3 (specifically the developer since this is the dev wiki!). I think there is a lot of value in having the administrator and UI tasks included in the wiki though, because lets face it, most developers who work with SharePoint will probably find themselves coming across a lot of issues from both of those areas during projects. I know I have had to set up and configure servers before, as well as create and deploy UI elements, even though doing things like that isn't my primary role - so I have picked up a lot of those skills by default while doing development.
Dec 04, 2008
Jeremy Thake says:
I actually agree with you Brian. Opening the wiki up to End Users opens it up to...I actually agree with you Brian. Opening the wiki up to End Users opens it up to the entire platform more or less. The idea of the "dev wiki" was that it was focused at Development. The problem being is defining the grey area between Customisation and Development which leads to an end result of an Implementation of SharePoint from the usual blue and white out of the box SharePoint site. Pretty much all implementations aren't just going to have Content in them without some sort of artifacts being created such as Master Pages, Page Layouts, Custom Web Parts, List templates, Site Templates, Site Definitions etc. etc. This is something we need to define and also distinguish where this can and cannot be done. Also what technologies are required for each say e.g. XSLT, XML, C#, SharePoint Object Model, etc.
I've created a new Defining SharePoint Development page.
Dec 04, 2008
Mark Miller says:
Ouch! You guys are killing me! Jeremy, you of all people... oh well, I g...Ouch! You guys are killing me! Jeremy, you of all people... oh well, I guess I'll just go back and hide in my hole in the ground and hope that one day End Users and Information Workers will be recognized as the broadest base in need of SharePoint resources. Sigh....
Let me know if you need any help. Good luck on the new project. -- Mark
Dec 04, 2008
Brian Farnhill says:
Sorry Mark! I just don't really think the SharePointDEVWiki (big emphasis on...Sorry Mark! I just don't really think the SharePointDEVWiki (big emphasis on the dev part) is the best place for that type of content. Don't get me wrong, I think that getting something similar together that was focused on the end users and business information users would be a great idea, but I think that for this site we should focus on the development aspects of SharePoint rather than trying to cover every possible angle of the software.
Dec 04, 2008
Mark Miller says:
Brian, no offense taken. I just wanted to be part of the discussion. I agree... ...Brian, no offense taken. I just wanted to be part of the discussion. I agree... if you guys are concentrating on the dev aspect, go for it. At EndUserSharePoint.com we have focused exclusively on OOTB content, to the point of refusing to publish any articles where the user would have to 'touch' the server.
I'm looking forward to following your progress here. -- Mark
Dec 04, 2008
Jeremy Thake says:
You can still do some scary stuff with OOTB stuff which I believe is development...You can still do some scary stuff with OOTB stuff which I believe is development don't get me wrong...e.g. JQuery posts you've recently put up. It's just there's certain things you can't do without "touching the server". That's actually quite a good way of thinking about it or atleast half the line in the sand
To make that line in the sand solid we need to define the boundaries on UI stuff e.g. adding web parts to pages and setting properties is fine, but exporting them and fiddling with stuff under the covers is certainly development as you need XML skills and SharePoint object model skills. Same goes for customising the look and feel by modifying OOTB stuff in SharePoint Designer...this requires XHTML, JavaScript, CSS, ASP.NET and XSLT knowledge as a minimum...not stuff for "end users".
Thanks again Mark, we'll be sure to link off to you guys where its relevant anyway.
Dec 07, 2008
Keith Dahlby says:
A big part of developing on a platform like SharePoint is knowing what the platf...A big part of developing on a platform like SharePoint is knowing what the platform can do for you. That includes leveraging the OOTB features - what excels at what, what limitations are, how to properly integrate OOTB stuff into a comprehensive solution, etc. To draw an artificial line at "touching the server" seems counterproductive when a fully-functional prototype could be built entirely in SPD. Sure, keeping it there isn't the best practice, but a big part of our job is to know when to use what tool and how they all fit together. I think "touching the server" is a useful conceptual line between the realm of Power User and Developer, but to exclude the former because this is a "dev" wiki would be silly.
We certainly don't need in-depth tutorials about "End User" tasks like building a custom list through the interface, but I see no reason not to document how OOTB features can be used for serious development (clever uses of CEWP, DVWP, CQWP, SPDataSource, whatever) and how they would manifest in a repeatable deployment scenario.
Dec 07, 2008
Jeremy Thake says:
Thinking about it, you're right, I've recently been doing some work with OOTB st...Thinking about it, you're right, I've recently been doing some work with OOTB stuff such as the CQWP and didn't realise how much it could do. The biggest mistake I've made has been to jump straight into writing my own rendering for a solution rather than re-using what is there OOTB. So I can see the advantage in the prototype approach to get things up and running and coming back to Development. The big danger with prototyping is that you set the expectations of the business so high with turnaround of solutions when really in the long run it just doesn't cut it for deployment and the "version 2.0" scenario. So yes, I agree, we do need to cover off the OOTB Web UI stuff and that's why I've included it in the structure, the thing is knowing what bits to leave out...e.g. what stuff would we never use as Developers?
Dec 07, 2008
Keith Dahlby says:
Well it's hard to identify any SharePoint knowledge that a developer will never ...Well it's hard to identify any SharePoint knowledge that a developer will never use, so at some point you have to make base assumptions of knowledge that is already covered elsewhere:
So anything that falls only into those categories would not seem appropriate. However, I could definitely see room for specific applications as they apply to SharePoint:
And in all cases, there should be related discussion of how to integrate or emulate these techniques in a "real" developer solution.
Dec 04, 2008
Jeremy Thake says:
"You guys are killing me! " ... not at all, completely different content...h..."You guys are killing me! " ... not at all, completely different content...hence SharePointDevWiki!
"Jeremy, you of all people"...LOL what do you mean by that exactly?
Dec 04, 2008
Rick Kierner says:
I am drawn. I think that a lot of power users would benefit from a wiki li...I am drawn. I think that a lot of power users would benefit from a wiki like this. However, if endusersharepoint.com produces the content that that type of user needs then it would be silly to replicate the information. Not being that type of user, I'm not sure I can claim that though.
On the other hand, the fact that it is a /dev/ wiki, then wouldn't it also exclude administrators? They aren't dev-ing.
Just a thought: I think this wiki is a great tool and it may be a good idea not to restrict it all. People who participate can put any SharePoint related material up here that they see fit. Organic growth may be healthy for a site like this.
Dec 04, 2008
Rich Finn says:
Very true. It will most likely be difficult to keep this a dev related sit...Very true. It will most likely be difficult to keep this a dev related site just because of the nature of the topic. With organic growth, this wiki could possibly become an all encompassing repository for community knowledge. Think of an article about a 3rd party tool for SharePoint. There could content releated to Admins, Devs, and End Users.
Dec 04, 2008
Jeremy Thake says:
LOL one step at a time Rich and Rick but yes I hope this will help the c...LOL one step at a time Rich and Rick
but yes I hope this will help the community out whatever walk of life they are in SharePoint. I just figured that there is a niche with the lack of a true resource for SharePoint Development and I am getting more and more questions around when to use Dev over Customisation etc. If there are more demands then we can fill those too. This platform is able to handle that type of thing very well.
Dec 04, 2008
Brian Farnhill says:
"On the other hand, the fact that it is a /dev/ wiki, then wouldn't it also excl..."On the other hand, the fact that it is a /dev/ wiki, then wouldn't it also exclude administrators? They aren't dev-ing."
I do sort of agree with that, but given that most SharePoint developers will do some sort fo admin tasks when it comes to their setting up and configuring thier own dev environments (such as virtual PCs they use for dev work). So just on that basis I think we should be including at least the common administrative stuff that a developer would need to know.
Dec 04, 2008
Jeremy Thake says:
Yes I agree completely. I get this a lot...how do you build a dev environment? T...Yes I agree completely. I get this a lot...how do you build a dev environment? To explain this in detail you'd also need to cover off basic SharePoint admin. I also find myself putting on the admin hat to validate what a SharePoint Admin has done to ensure that I don't burn hours of time troubleshooting my work when it is something that is configured wrong.
I think it is unrealistic to assume that people are in complete silos and don't touch the servers and hand Admins the WSP files and script files (STSDEV). In a perfect world this might happen, but in reality it just doesn't. Mainly due to the complexities of doing things using WSPs over manual scripts (powershell) and doing it in the UI (e.g. Central Admin etc.).
Dec 05, 2008
Rick Kierner says:
This drives home my point exactly. A dev is commonly responsible for the e...This drives home my point exactly. A dev is commonly responsible for the entire product. Not only will they be doing some administrative stuff, they'll be doing some power-user-ish functions as well.
Dec 04, 2008
Anonymous says:
I agree that the focus of this wiki show be the last three options...but I LOVE ...I agree that the focus of this wiki show be the last three options...but I LOVE endusersharepoint.com - thank goodness it exists already!
Dec 04, 2008
Erica Toelle says:
Oops, thought I was logged in...that anonymous comment was meOops, thought I was logged in...that anonymous comment was me
Dec 08, 2008
Harish Mathanan says:
So it may come down to Developer/Designer/Administrator which is all well and go...So it may come down to Developer/Designer/Administrator which is all well and good. But will these be broken down by skill-level? Eg: Beginer, Professional and Master. Point to note is, there are already numerous high-level resources out there. But what about the entry-level developer intrested in getting dirty with SharePoint Dev?