Are there any blogs, guides, checklists, or controls we should be using to ensure our SharePoint implementation is accessible?
Preferrably to the W3C double A standard, or as close to that as we can get.
We're implementing an extranet solution.
This study has already been funded by Microsoft, and unfortunately the results only seem to be online in a Word Document.
The document is hosted on this blog:
http://blog.mastykarz.nl/best-practices-for-developing-accessible-web-sites-in-microsoft-office-sharepoint-server-2007/
And the path to the document is here:
http://go.microsoft.com/fwlink/?LinkId=121877
I'm unsure on whether it would be a good thing to copy the contents of that into here to fully answer the question in a way that will be indexed by search engines, but I'll play safe as it's not my content.
The best place to start is the Accessibility Kit for Sharepoint. With this, you may reach single A standard, but in my experience, you will find it very tough to reach AA.
Microsoft didn't factor in accessibility in Sharepoint, and even 2007 suffers from a huge overdependence on table layout.
Good luck!
How are you deploying the implementation? Is it as an Intranet, or, is it as a public facing website.
I think one of the first rules is to be extremely selective with the use of out of the box web parts. Many of the web-parts I looked at weren't compliant even on a basic level.
Andrew
The best way is to run checks as you develop so you know where your pain points are.
The next step maybe to start with a minimal masterpage so you can choose what elements are presented to the user.
More advanced you can override the render methods to remove or change bits of the page that are not compliant with your checks. EG changing the case of tags (XHTML does not like all caps)
A bit more in this guide.
http://techtalkpt.wordpress.com/2008/06/18/building-accessible-sharepoint-sites-part-1/
http://techtalkpt.wordpress.com/2008/08/07/building-accessible-sharepoint-sites-part-2/
I recently read the MOSS book by Andrew Connell (www.andrewconnell.com) and it has a chapter dedicated to accessibility and SharePoint sites.
Simply put SharePoint sites are very difficult to generate W3C AAA standards, but the Accessibility Kit is one of the best starting points.
Stronly recommend his book for this chapter (http://www.amazon.com/dp/0470224754?tag=andrewconnell-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470224754&adid=18S6FKQJR5FZK56WHH6A&)
It depends how much of Sharepoint out of the box you are intending to use. In implementing our public facing site we managed to achieve AA compliance, although the amount of custom development required has raised questions over the benefits we are actually gaining from using Sharepoint in the first place.
A few pointers:
We made heavy use of SPQuery/SPSiteDataQuery to render site data to screen using xslt which gave us full control over the output. I found this link helpful:
http://blog.thekid.me.uk/archive/2007/02/25/xml-results-using-spsitedataquery-in-sharepoint.aspx
Check out RadEditor for Sharepoint for a nice accessible rich text editor for publishing.
For xhtml compliance, things were a little more tricky, we had to override most of the Sharepoint publishing controls' render methods to correct dodgy output.
If you are wanting to leverage the portal like capabilites of Sharepoint in your extranet it is more problematic. The web part framework is not accessible and I have not yet found a way to make it so. Any suggestions welcome!
Related
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
We are currently in the process of drawing up a solution for an existing client, creating a number of eServices. The client currently have MOSS 2007. The proposed solution is to use MOSS as the launching pad for the eServices…
The requirement involves drawing up several online forms which provide registration facilities as well as facilitating a workflow of some sort. I have been told that the proposed solution requires complex web forms.
Most are complex forms with parent child details that have multiple windows. The proposed solution is to do some bespoke development, developing ASP .NET forms. These forms would be deployed under the _layouts folder of the current MOSS portal, inheriting the master page design on the current site.
I have been told that this approach make development and deployment more simple, as well has having ‘complete integration’ with MOSS.
My questions are:
Is this the best way to leverage SharePoint – it seems like the proposed solution is not leveraging MOSS at all..! I thought perhaps utilizing Web Parts would be better, but I have been told that this is more complex and developing more smarter intuitive UI is more difficult. Is this really the case? If not, what should be the recommended approach?
We will be utilizing Ultimus as the workflow engine. However, I have been recommended K2 Workflows. Anyone used both/have any opinions on either?
Many thanks in advance!
Kind Regards,
If they have MOSS 2007 Enterprise, you might consider if web rendered InfoPath forms can meet your needs for "complex web forms". When it comes down to it, probably all of these technologies can meet the neeed it is just a matter of what skill sets you and your customer have and how that will facilitate keeping this solution up to date.
Asim, what they propose is a possible solution. They can however provide the same functionality by making use of webparts. With the details you are giving us that isn't really possible to decide which option would be easier. I used both approaches in the same project depending on the requirements of each functionality.
I can understand that it doesn't seem like they are leveraging MOSS, but they actually are building pages within the context of MOSS.
I haven't really heard about Ultimus, I did use K2 in a proof of concept and I was quite happy with it. Then again, choosing the right workflow solution depends on your requirements.
Basically need to use SharePoint (because we promote MS yay!) as a content management system for an internet facing site.
How do I get rid of the default SharePoint look and feel and make it look like however I want it to?
I know the process involves creating a new masterpage with SharePoint Designer. However I prefer to code webpages rather than use a visual editor. Is this possible? Do I need knowledge of .NET?
Just check out ferrari.com for a very well made redesign of a SharePoint site.
Heather Solomon's Branding SharePoint series would be a good place to start. There's a lot you can do just with CSS, JS and HTML, but the most complete solutions (like Ferrari) require some pretty extensive customization with .NET and other SharePoint development techniques (features and delegate controls, in particular).
Your branding effort will be a lot easier if you only need to heavily brand the public-facing "publishing pages", from which you can remove most of the SharePoint-specific elements that make branding difficult.
Also, SharePoint Designer has a source view if you don't like the visual editor.
Yes it is possible to make it look like however you want it to (as you've seen from the Ferrari site). However to create that sort of site takes a lot of work.
Microsoft recommend the use of SharePoint Designer for 'designing' pages and layouts. However changing their behaviour almost always needs Visual Studio and development in .NET. You can largely avoid SharePoint Designer (which may worth considering as it can be a PITA) with an open source tool such as SPVisualDev. Use this with WSPBuilder for packaging your solutions (and avoid VSeWSS where possible).
Considering it sounds like you're just getting started, be aware this is a big topic with a reasonable learning curve. Read a good book on the topic such as Professional SharePoint 2007 Web Content Management Development: Building Publishing Sites with Office SharePoint Server 2007 by Andrew Connell. It takes you through most things you will encounter from the ground up.
I'm working my way through Real World Branding by Andrew Connell at the moment. It seems like a good demonstration, with code.
Plus the Heather Solomon articles as suggested by dahlbyk are always informative.
Just changing the theme, or creating a custom theme for the site, can go a long way towards making SharePoint look a lot better. It's also a lot less intensive then changing the master pages.
How to create a theme
How to deploy a theme
Example customization you can do with just CSS
Does the EULA allow you to disguise the fact that it's MS software?
Remember, you didn't buy the software, you're just paying for the privilege of using it.
This question already has answers here:
Developer Documentation: Sharepoint Document Management vs. ScrewTurn Wiki [closed]
(11 answers)
Closed 7 years ago.
Duplicate
Developer Documentation: Sharepoint Document Management vs. ScrewTurn Wiki
I have been tasked with picking a wiki tool for a development organization, comprised of several different development teams. Sharepoint is installed and upper management would prefer this to be used, but in the past it has only used when PMs are forced to use it. None of the developers will update it with content that needs to be shared. I developed in Sharepoint and I liked it, so I have nothing against it. But for this to work I need something I can get everyone using, so Sharepoint will not work.
Step one is to convince management why Sharepoint will not work. We need the typical wiki features:
WYSIWYG, Clean interface, Easy to use, Attach Files to pages, Support for groups of users, Open source, Hosted Locally. (Maybe others I am not considering now?)
Can anyone provide a list of objective reasons why Sharepoint is not the solution we can use to take our first step?
There are many such products out there so step 2 should be easier.
SharePoint is the exact opposite of a wiki: A wiki is lightweight, easy to use, obvious, quick, doesn't get in the way.
To elaborate: A wiki allows your to jot down an idea quickly and moving details to the next page. In SP, people start to create processes, editing rights, workflows.
Wikis are designed to not get in the way. SP is designed to prevent you from doing "something bad"; whatever that might be. Wikis are driven by the idea that brainstorming works in open space while SP is driven by FUD: Who can see this information? Can it be used against me? How can I prevent someone to see/edit something?
Note: This is not a critique of SP per se; it's just how it used in most organizations. If you look at the security settings and edit rights, you sometimes feel like the workers of the company must all have been inmates in some high-profile prison (or should be).
I have absolutely no sharepoint-foo at all, but the sharepoint setup by IT at my employer has a wiki that we can use for documentation. Wouldn't that be good enough? Works ok-ish in firefox on mac, so I'm a happy camper.
SharePoint is best when using many of it's features (eg DM, WCM, workflow, collaberation etc) - you get a lot of it's benefits from the synergy of using all these things together with a common interface.
In any one area though, it's far from the 'best of breed' application - so, if you want a product for a specific job (eg a wiki), SharePoint isn't the most fully-featured/easy-to-use/delete-as-applicable product to be using - there will be products that do that (single) job far better.
You could also try looking at this question to see others experiences with SharePoint wiki's
I have used MediaWiki, Instiki and Sharepoint. Sharepoint does not work correctly with firefox on purpose. Its wiki functionality is an after thought. All kinds of additional features nobody use. But it does appeal to managers.
Instiki can be up and running in less than a minute and MediaWiki has everything you could need. Sharepoint annoyed most people on our team so nobody wanted to use it which meant a lot of knowledge was lost.
Which version of SharePoint are you using WSS 3.0/MOSS 2007 includes both wiki and blog functionality.
Although the SharePoint wiki isn't as feature-rich as most, the fact is that if your developers would not update a SharePoint wiki, chances are that they would not update any other kind, either.
I recommend creating a SharePoint wiki, and then actually reading the starting page, where it gives the definition of wikiwiki. I recommend only using a wiki (of any kind) for documents that can be written quickly, so that developers can get back to developing as soon as possible. Let the structure and accuracy grow over time. Just get the facts into the wiki quickly.
Wikis offer workflows, Document management and more too. I would disagree with those who say you can't do this in a wiki. Check out Confluence by Atlassian
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm trying to wrap my head around SharePoint. Why is it good? Why is it bad?
At a glance it appears to offer some incredible collaboration tools. However, the cost looks astronomical and it seems to be rigid & difficult to customize.
To those who've worked with SharePoint; please describe something good and something bad about it.
Pros:
Document management is its most well-known
function and integrates extremely
well with Office 2007.
Create group calendars that can be
overlayed onto your personal Outlook
and managed on the web.
Notifications in response to certain
actions on the group website
Wiki-type functionality with full
integration into the Office stack.
Full database backend which gives
you the reliability and safety of a
true RDBMS.
Extremely customizable if you choose
to develop custom websites using
ASP.NET (not the built-in wizard/gui
editor).
Form-data collection
Cons:
Freebie version is somewhat limited
on customization.
How to handle multiple editors to a
single file is not obvious.
Workflow for offline editing of
documents is non-obvious.
Very steep learning curve to use it
the right way.
Getting people to use it is like
getting people to go to the dentist.
Out-of-the-box templates don't do a
lot.
Customizing without writing code
really limits your options.
Integration with older versions of
office is ugly
Mac integration is non-existant (has
this changed recently?)
It has pretty good Office 2007 integration. As an example, Excel understands when you have a file checked out and will let you check it in (with comments) when you close it. The document management features simplistic version control (although it's not required; you can go with a single version for each file).
In SharePoint, everything is essentially a list internally and it's very easy to create a custom one. On a related note, I haven't used either yet, but it supposedly works well with workflows and InfoPath.
On the downside, it's pretty much a resource beast. It requires multiple machines with powerful specs, particularly if you want to "really" use it for document management and to be the backbone of your intranet/internet site. It scales to an extent, but it's not pretty from my vantage point.
Customizing it presents it's own challenges. You really need people focused on it full time, as both administration and customization require their own impressive learning curves.
Lastly, some of the out of the box parts are poorly implemented. The wiki is a prime example; it's basically useless in my opinion. So one thing to keep in mind is that some may consider SharePoint as a whole package as "best in class" (not saying I do!), its individual features often are not.
Good
Out of the box, it offers a ton of functionality and power, even for the stock web parts. Just creating a library of documents that anyone can open/edit/upload to is simple...even for those non-web-savvy amongst us.
Bad
Pretty much everything else.
The "Discussion Board" is a glorified Outlook email chain.
The disconnect between achieving similar results in SharePoint Designer 2007 and using the web interface are jarring and annoying
Attempting to customize the look and feel of a SharePoint site usually ends in complete disaster. Especially with WSS 3.0.
The nickel & diming scheme between the WSS 3.0 and MOSS 2007 tiers is absolutely painful; WSS 3.0 is just barely functional enough to be extremely frustrating to use
Changing MS styles is almost impossible due to their horribly-laid-out and obnoxiously large CSS file.
IT IS 2009...GET RID OF THE TABLES FOR NON-TABULAR DATA ALREADY!
It's a beast to use. And handing two complete rebranding projects for two totally different areas of the company is driving me to the point of a nervous breakdown. Especially when opening the core.css file occasionally results in all the styles I've redefined getting reset to the defaults. Without anything done by me other than just OPENING the file. And there is no ability to undo these changes.
Good thing: Great communication tool. Instead of sending out a company wide email you can post an announcement to your SharePoint site. Users can subscribe to an RSS feed of the announcements or have a email alert sent to them when the list is updated.
Bad thing: Error messages displayed on a SharePoint site are generic and the link to help resolve the issue rarely is of any help.
Good:
It can be a great collaboration tool. Beginning developing for sharepoint is simple, assuming you are familar with ASP.NET webparts.
Bad:
The development lifecycle isn't fully implemented. There are no built-in facilities for testing, among other things.
SharePoint is evolving and becoming a better collaboration tool for Microsoft Office environments. It plays well in a small to medium sized business setting. It is critical to implement “best practices” on setup; otherwise it will quickly become a nightmare to maintain and to use.
For “best practices” here are two books that I recommend for SharePoint 2007:
Essential SharePoint 2007
Sharepoint 2007
A lot of the cool things in Sharepoint are avaialable in Windows Sharepoint Services 3.0, which is free with windows server 2003/2008. All you need extra is a license for SQL Server 2000 and later, which most mirosoft shops have. In WSS you can do document management, workflows, custom sites, blogs, wiki's, etc.
If you need Excel Services, Forms Server, CMS, or some of the other MOSS features, then that's another thing. And yes, it does cost a lot of money, but it' cheaper than doing it from scratch in most cases.
Pluses:
- Great object model.
- A lot of good features just come out of the box.
Minuses:
- Steap learning curve to do things the right way.
- It's very easy to hang yourself by doing things the wrong way.
- Debugging and deployment is about as pleasurable as root canal.
good :
A lot of things can be done. Wokflowks, InfoPath forms, Excel Services, Business Data Catalogs and etc.
Bad :
You won't be able to do these described easily. Must have sharepoint administrative and development skills for good solutions that don't improve quickly.
If you have a license for Microsoft Server 2003 then you can install the standalone version of Sharepoint for FREE!
Download Sharepoint
The install is very simple when using the internal database.
Microsoft Office Sharepoint Designer 2007 is a must have for any customization.
I have created a couple Company Intranets using Sharepoint and have been very pleased with its features.
Microsoft Office 2007 interfaces nicely with sharepoint.
I have found Sharepoint to be very powerful and easy to learn. There are lots of people developing sites using sharepoint. The level of customization is awesome. The simplest customization is done in your browser, the next level is using Microsoft Sharepoint Designer 2007, and finally using Visual Studio to create new apps(webparts).